“AI Was Used” Tells a Rejected Applicant Almost Nothing

Consider the rejection email at the end of a common hiring workflow. An applicant uploads a resume to an applicant tracking system, software parses the document into fields, an assessment or ranking tool produces a score, and the employer applies that output before sending a rejection. A disclosure saying that artificial intelligence “may have assisted” somewhere in this chain names a technology category. It does not tell the applicant which result to challenge.

That rejection email is the concrete test for employment transparency. Could its recipient identify the automated decision stage, understand the categories of information that mattered, reach a person with authority to reconsider the outcome, and correct an erroneous input? If not, the notice may satisfy a narrow disclosure rule while remaining operationally useless.

This distinction matters because US requirements are fragmented. New York City enforces a rule covering certain automated employment decision tools, while Colorado has enacted a broader framework for high-risk AI systems used in consequential decisions. The European Union’s AI Act adds another model for high-risk employment systems, with obligations taking effect on a staged timetable. None creates a universal explanation right for every rejected US applicant.

Start with the decision stage

“AI was used in recruiting” could describe a chatbot that scheduled the interview. It could also mean that software rejected the application before a recruiter opened it. Those are materially different uses, even if the employer bought both from the same vendor and placed both under one AI policy.

A useful notice names the stage and the system’s function in ordinary language: resume fields were extracted and compared with minimum requirements; an online assessment was converted into a score; recorded answers were classified; or applicants were ranked for recruiter review. The notice should then state whether the output triggered rejection, set a threshold, changed the applicant’s position, or appeared as a recommendation that a person could disregard.

New York City’s Local Law 144 illustrates both the value and the limit of advance notice. Before using a covered automated employment decision tool, an employer or employment agency must notify a New York City resident that “such tool will be used in connection with the assessment or evaluation” of the person. The notice must also identify “the job qualifications and characteristics” the tool will use. Enforcement began in 2023, alongside requirements for an independent bias audit and publication of audit information.

That is more specific than a generic AI label. Yet it does not require an individualized post-rejection explanation showing how the tool affected a particular applicant. The law also lets a candidate request an alternative selection process or accommodation, but it does not require the employer to offer an alternative process merely because one was requested. The gap between permission to ask and a defined remedy is consequential.

Return to the rejection email. If it says the employer used an automated tool to rank applicants for recruiter review, the recipient now knows where to look. If the email says only that AI supports hiring, the scheduling chatbot and the rejection model remain indistinguishable.

Name data categories without pretending to expose the model

The next field should identify what information entered the automated assessment. “Application data” is too broad. An actionable notice separates categories such as employment history, education, location, answers to screening questions, assessment responses, or inferred features derived from recorded speech or video.

An inferred feature is information the system generates rather than information the applicant directly supplied. A model might infer a skill category from job descriptions, for example, even though the resume never uses that label. These transformations deserve attention because an applicant can verify a degree or employment date more easily than a vendor-generated classification hidden behind a score.

Colorado’s enacted AI law offers a useful design specification here, although it is not a nationwide rule and its implementation timetable has been revised through later legislation. For an adverse consequential decision, the law calls for disclosure of the “principal reason or reasons,” including the “degree to which and manner in which” the high-risk AI system contributed, the type of data processed, and the data’s source. A high-risk AI system, under that framework, is one that makes or substantially influences a consequential decision such as an employment decision.

This approach does not require releasing model weights, source code, or every mathematical feature. An employer can state that the system compared parsed resume fields and screening answers with role criteria, assigned a recommendation, and routed applicants below a threshold away from recruiter review. That explanation reveals the operative path without publishing the vendor’s full scoring logic.

There is a real tradeoff. Detailed thresholds can help applicants manipulate a screening process, while broad descriptions can conceal defective inputs. The workable boundary is to disclose enough for error detection: the categories used, their sources, any important inferred fields, and the role of the output. “Proprietary system” should not become an answer to all four.

Human review must change something

A notice often promises that a person was “involved.” That phrase can cover a recruiter who designed the process, an employee who occasionally checks aggregate results, or a reviewer who clicked approve after seeing the system’s recommendation. None necessarily gives the rejected applicant a review path.

Meaningful human review requires a named route, a defined scope, and authority to alter the decision. The reviewer needs access to the original application, the data sent to the tool, the resulting score or recommendation, and the rule that connected the output to rejection. Without those records, the reviewer can only repeat the result.

Colorado’s framework pairs an appeal opportunity with human review “if technically feasible.” That qualifier matters. It describes an enacted requirement with a limitation, rather than an unconditional promise that every automated decision will receive fresh human judgment. Employers using systems that cannot reconstruct inputs or explain how a recommendation entered the workflow may struggle to make review more than procedural theater.

The engineering constraint appears before the rejection. If the employer does not log the system version, input categories, output, threshold, timestamp, and any human override, the later reviewer cannot reliably reproduce what happened. An audit log, meaning a time-ordered record of system actions and decisions, costs storage and integration work; support staff also need time to handle appeals. The cheaper setup is a generic mailbox attached to no decision records.

It is also close to useless.

The rejection email should therefore identify where a review request goes, how long the applicant has to submit it, what material can be considered, and whether the reviewer can reverse the result. A human who lacks that authority is an escalation contact, not an appeal mechanism.

Correction needs a route back into the workflow

Automated hiring systems can act on incorrect data even when the model behaves as designed. A parser may place an employment date under the wrong employer, drop text from a multi-column resume, misread a credential, or treat an unanswered field as a negative response. A purchased data source can attach information to the wrong person.

A correction process should let the applicant see or meaningfully identify the disputed category, submit replacement information, and learn whether the employer reran the assessment. Correcting a database after the position has closed may improve future records, but it does not remedy the decision described in the rejection email.

This is where disclosure design meets workflow design. The employer must decide whether a corrected input automatically triggers rescoring, returns the application to a recruiter, or merely enters a support queue. Each choice has a cost. Rescoring can produce inconsistent results if the vendor has updated the model, while manual reconsideration consumes staff time and can introduce a different set of judgments.

Leaving the path undefined makes the applicant carry the delay while the employer retains the original outcome.

A strong notice also separates employer-held data from vendor-held data. Applicants should not have to guess whether the employer, assessment provider, background screening company, or applicant tracking platform can correct the disputed field. Other laws, including rules governing consumer reports, may impose separate adverse-action duties in particular workflows. Applicability depends on the facts, and this analysis is not legal advice.

The practical test is whether the notice supports action

The rejected applicant does not need a general lesson about machine learning. The applicant needs a compact record of what happened in this application: which automated step mattered, which data categories entered it, how the output affected the decision, and where an error can be reviewed.

Employers can test the rejection email before debating broader AI principles. Give the notice and the underlying application record to someone outside the hiring team. Ask that person to locate the decision stage, identify a potentially incorrect input, and submit a review request to someone who can change the outcome. If the exercise stops at “AI was used,” the organization has disclosed a label while withholding the interface needed to act on it.

Questions people ask

Does an employer have to tell me that AI rejected my application?

There is no single US rule covering every employer and hiring system. New York City requires advance notice for covered automated employment decision tools, while other duties may arise under state laws or rules governing particular data and reports. A notice requirement does not always include an individualized explanation after rejection.

What should I look for in an AI hiring notice?

Look for the stage where automation entered the decision, the data categories and sources, the system output’s role, and a review or correction route. A notice that names AI but omits those details may establish that software was present without showing whether it screened, ranked, scored, or merely scheduled applicants.

Does human involvement mean the decision received human review?

No. A person may monitor the system or approve a batch without reconsidering an individual application. Useful review gives a person access to the relevant inputs and output, along with authority to correct data, rerun an assessment, restore an applicant to consideration, or reverse the decision.

Can an applicant demand the model’s source code or scoring formula?

The transparency frameworks discussed here do not generally require employers to publish source code or model weights. Actionable disclosure can instead identify the system’s function, the information it processed, the source of that information, and how its output contributed to the adverse decision, while leaving proprietary implementation details undisclosed.