What does the inspection layer do when the copilot retrieves a candidate resume with demographic indicators?

The classifier detects the demographic-indicative content in the retrieval (names that statistically correlate to protected characteristics, school names that correlate, location indicators). The policy applies the redaction rule before the prompt reaches the model. The record captures the redaction with the specific fields redacted, so the audit can confirm the model did not see the demographic indicators at decision time.

How does the inspection layer handle the NYC LL 144 bias audit requirement?

The audit records carry the per-decision evidence the bias audit reads. The audit firm queries the record store for the relevant period, runs the four-fifths-rule analysis against the records, and produces the bias audit report the law requires. The records also provide the supporting evidence for the candidate-by-candidate disclosure the law requires.

What about copilots that use the candidate's video interview transcript?

The policy classifies the transcript content with the behavioral data category. The classifier identifies any demographic indicators in the transcript. The policy enforces the redaction and the records capture the action. The Illinois AIVIA notice and consent framework runs through the application's intake process before the transcript reaches the copilot.

Does the inspection layer change the recruiter's workflow?

The layer adds under 50 ms to the request path, which is invisible against the LLM's response time. The workflow changes when the policy blocks or modifies. A block surfaces as a structured error the copilot UI handles. A modify (the demographic redaction) surfaces as an indicator the user sees showing redaction happened. The user experience is intentional.

How does the inspection layer integrate with the existing HRIS audit trail?

The audit records feed the existing HRIS audit repository through the standard event bus. The policy authoring lives in the same change-management process the HR organization uses for the existing AI screening tools the company audits. The inspection layer's classifier signals integrate with the existing recruiting analytics through a shared signal bus.

AI Security for HR Recruiting: The Identity, Bias, and Audit Controls a Production Deployment Has To Run

HR recruiting copilots reach across the data surfaces a talent organization has collected from candidates under specific privacy commitments and applicant-screening statutes. The copilot reads into the applicant tracking system, the resume corpus, the assessment vendor data, and the interview transcript store. The decisions the copilot supports fall inside the EU AI Act Annex III high-risk classification for employment, the EEOC's adverse-impact enforcement perimeter, NYC Local Law 144's automated employment decision tool audit requirement, and Illinois Artificial Intelligence Video Interview Act notice obligations. A model invocation that uses candidate data to produce a screening score, ranks the candidate pool, or recommends a rejection is a sequence the EEOC will read against if the adverse-impact statistics surface a disparity and the EU AI Act will read against starting August 2, 2026.

I want to walk through the identity-aware policy decisions an HR recruiting deployment has to commit at the request boundary, the audit record format that survives an EEOC complaint and an EU AI Act review, and the architectural pattern that closes the post-authentication gap most recruiting copilots leave open.

The data the HR recruiting copilot reads at request time

The copilot reads four categories of data that map directly to employment-law surfaces. The first is the candidate identifying data (name, contact information, location, demographic data the candidate elected to disclose). The second is the candidate qualification data (resume content, work history, education, skill assessments). The third is the candidate behavioral data (interview transcripts, video interview clips, structured assessment scores). The fourth is the recruiter and hiring manager context (job description, role evaluation criteria, hiring committee feedback).

Each category carries an explicit access-control and use posture. The identifying data is restricted under privacy commitments the candidate consented to. The qualification data is restricted to the recruiting team and the hiring manager. The behavioral data is restricted under the recording-consent framework the state and federal statutes establish. The recruiter context is restricted to the hiring committee.

A copilot that reads any of these categories into the prompt at request time and produces a scoring, ranking, or filtering decision is making an automated employment decision the EEOC and the EU AI Act both have jurisdiction over. The reconstruction of the decision has to include the user identity, the data class, the model endpoint, and the policy state at the moment.

The identity-aware policy decisions

The decisions the deployment commits at the request boundary cover three orthogonal axes. The first is user-against-data. A recruiter sourcing for a specific requisition can read the qualification data for candidates in that requisition. A hiring manager on the requisition can read the qualification and behavioral data for candidates the recruiter has surfaced. A recruiter for a different requisition cannot read data for candidates in the first requisition without the candidate's consent.

The second is data-against-action. A prompt that uses candidate demographic data to produce a screening recommendation crosses the EEOC adverse-impact rule and the EU AI Act prohibition on inferring protected characteristics for ranking. The policy blocks the action. A prompt that uses qualification data for ranking, with demographic data redacted from the prompt context, is permitted. The policy enforces the demographic redaction at the request boundary.

The third is decision-against-disclosure. A copilot that produces a rejection recommendation triggers the NYC LL 144 notice obligation if the role falls inside the law's scope and the EU AI Act Article 86 right-to-explanation if the candidate falls inside the EU jurisdiction. The action requires a routing step the policy enforces that ensures the notice and the explanation production travel with the decision.

The three axes compose. A user (recruiter, sourcing for a specific requisition) asks (a question about candidate qualifications) against (qualification data with demographic data redacted, routing to a model with appropriate processing terms). The combination produces a pass. A change on any axis (the user shifts to a non-authorized requisition, the demographic data appears in the prompt, the model selection moves to a non-covered endpoint) produces a block or a modify.

The audit record format for EEOC and EU AI Act review

The record at decision time carries the seven fields an EEOC complaint investigation, an EU AI Act Annex III review, and an NYC LL 144 bias audit would each read. The identity carries the natural-person identifier (the recruiter or the hiring manager) and the agent identifier when the copilot acts on behalf of the user. The route carries the route identifier (which copilot function, which requisition context) and the policy bundle binding active at decision time. The data classification carries the inspection layer's classifier output on the prompt and the retrieved context (demographic, qualification, behavioral). The policy version carries the version of the policy bundle the policy decision point read at decision time. The decision outcome carries pass, block, or modify with the rule identifier that produced the outcome. The model and version carries the upstream LLM the request forwarded to. The integrity metadata carries the cryptographic signature and the hash chain link.

The record satisfies the EU AI Act Article 12 record-keeping obligation for high-risk Annex III systems. The record satisfies the NYC LL 144 bias audit requirement because the audit can run statistical analysis against the per-decision evidence the records contain. The record supports the EEOC adverse-impact analysis because the records produce the per-decision evidence the four-fifths rule analysis runs against. The record supports the Illinois AIVIA notice compliance because the records establish the candidate-by-candidate evidence of when AI processing occurred.

The post-authentication gap recruiting copilots leave open

Most recruiting copilots integrate with the HRIS or the ATS, propagate the user identity into the application session, and then call the model API with the application's service account. The model provider's logs carry the application's identity. The application's logs carry the user identity but lack the model selection, the classifier output on the prompt content, and the policy state.

The investigator who asks "what demographic data entered the prompt context when recruiter X produced the ranking on requisition Y" reads two log streams that were never designed to be joined. The EEOC complaint that surfaces months later has no defensible record to rest on. The gap is the same post-authentication gap that shows up across regulated workflows; in the recruiting context, the gap directly threatens the employer's defense against discrimination claims.

The architectural pattern that closes the gap

The pattern is an inspection layer at the HTTP boundary between the copilot's application and each upstream the copilot calls. The layer reads the prompt, the retrieved context, the identity the application propagates, and the policy state. The layer evaluates the user-against-data, data-against-action, and decision-against-disclosure policies. The layer applies pass, block, or modify and commits the per-decision audit record before the response forwards.

The layer enforces the demographic data redaction at the request boundary. The redaction means the model receives a prompt with demographic indicators removed. The redaction is recorded in the audit so the record shows the redaction occurred and which data class was removed. The redaction is the technical control that supports the deployer's position that the model did not score based on the protected characteristics.

DeepInspect

This is the gap DeepInspect closes for HR recruiting copilots. DeepInspect sits inline between the copilot's application and any HTTP upstream the copilot calls. The inspection layer reads the prompt, the retrieved context, and the user identity the application propagates. The layer evaluates identity-bound policy against the data classification (including demographic redaction) and the policy state. The layer applies pass, block, or modify and commits the per-decision audit record to durable, append-only storage with a cryptographic integrity signature before the response forwards.

The record series carries the natural-person identifier the user authenticated with, the requisition identifier, the copilot session identifier, the route, the data classification, the policy version, the decision outcome (including the redaction event), the upstream model and version, and integrity metadata. The series satisfies EU AI Act Article 12 for Annex III high-risk employment systems, NYC LL 144 bias audit evidence, EEOC adverse-impact analysis evidence, and Illinois AIVIA notice compliance from a single pipeline.

If you are running an AI copilot inside the recruiting organization and the EEOC complaint or the EU AI Act review would read your application logs as insufficient evidence, let's talk today.