Answer capsule
New York City conditions covered AEDT use on a recent bias audit, a public summary, and notice. Meeting those conditions does not establish that a tool is accurate, job-related, accessible, lawful in every respect, or appropriate for a specific employment decision.
What the source establishes
- New York City Local Law 144 addresses certain automated employment decision tools used by employers and employment agencies.
- The city says a covered tool cannot be used unless it has undergone a bias audit within one year of use.
- Information about the bias audit must be publicly available, and required notices must be provided to employees or job candidates.
- The city’s educational material states that notice must be provided 10 business days before use of a covered tool.
Decide whether the actual use is covered
The direct CHRO task is to map the configured workflow, not classify a vendor brand once. The same platform may support sourcing, screening, ranking, scheduling, assessment, or communication in different ways. Coverage and risk turn on what the tool does, how its output influences an employment decision, who uses it, and which people and locations are affected.
The inventory should name the feature, version, input data, output, decision stage, human role, employer or agency, and deployment geography. A vendor’s generic statement about Local Law 144 readiness cannot substitute for the employer’s facts or for current legal analysis.
The accountable team should translate this point into a named workflow, affected population, source data, human owner, approval right, exception path, retained evidence, and review date. That translation is what separates an interesting AI development from a decision that can be governed and evaluated.
Tie the audit to the deployed tool and period
The city describes a bias audit within one year of use. HR should verify that the public summary and underlying audit correspond to the tool, version, data categories, selection process, and use now being considered. A prior audit of a materially different configuration or workflow may not answer the current decision.
The audit record should preserve scope, methodology, data limits, excluded groups, result date, independent-auditor facts where required, and unresolved findings. It should also state what the audit did not test, including accuracy, accessibility, job relatedness, privacy, security, or the quality of the underlying employment criteria.
The accountable team should translate this point into a named workflow, affected population, source data, human owner, approval right, exception path, retained evidence, and review date. That translation is what separates an interesting AI development from a decision that can be governed and evaluated.
Operate notice as a workflow control
A notice posted somewhere on a careers site is not automatically evidence that each affected person received the required information on time. Recruiting and employee workflows should identify who receives notice, when the clock starts, which tool and job or decision it concerns, what alternatives or accommodation routes exist, and how delivery is recorded.
Changes to the tool, job family, candidate flow, language, agency, or geographic scope should reopen the notice review. HR, talent acquisition, accessibility, legal, procurement, and the hiring owner need a shared record so that a vendor launch or workflow edit does not silently bypass the approved path.
The accountable team should translate this point into a named workflow, affected population, source data, human owner, approval right, exception path, retained evidence, and review date. That translation is what separates an interesting AI development from a decision that can be governed and evaluated.
Keep compliance conditions separate from the employment decision
A completed audit, public summary, and notice are use conditions described by the city; they are not a substantive endorsement of the tool or a finding that a particular decision is fair. The CHRO still needs evidence that the assessment serves a valid job purpose, that people can seek accommodation or correction where applicable, and that humans can challenge unsupported outputs.
The approval should state the lawful and evidence-based purpose, permissible inputs, decision weight, review path, monitoring plan, and stop conditions. If outcome patterns, complaints, inaccessible interactions, unexplained exclusions, or model changes emerge, the organization should investigate the actual workflow rather than pointing to the existence of a bias-audit page.
The accountable team should translate this point into a named workflow, affected population, source data, human owner, approval right, exception path, retained evidence, and review date. That translation is what separates an interesting AI development from a decision that can be governed and evaluated.
Decision test
Ask whether the source changes the decision itself, the evidence required, the implementation sequence, or only the language used to describe an existing capability. Record which claims are directly supported, which are provider statements, which require an independent test, and which remain unknown. A source-linked review should make uncertainty easier to see, not bury it inside a blended score.
Questions to take into review
- Does the tool materially influence who advances?
- What validated job criteria support the output?
- Which roles and tasks change?
- How are workers or representatives involved?
- Which data is job-related and known to employees?
- How are context and accommodations represented?
- Could a person be reidentified?
- What was the stated collection purpose?
The publication supports research and executive decision preparation. It does not provide legal, financial, accounting, employment, clinical, cybersecurity, investment, procurement, or implementation advice.