HR Hiring AI Under the EU AI Act: The Bias Question Becomes a Logging Question
The EU AI Act classifies AI used to screen and evaluate job candidates as high-risk under Annex III, which brings record-keeping, logging, and human-oversight duties. Bias mitigation is model and data work, but proving a hiring decision was accountable is a logging problem. This article separates the two and shows which obligations a policy gateway produces evidence for on the AI request path.
The EU AI Act lists AI systems used to recruit, screen, and evaluate candidates among its high-risk categories in Annex III. High-risk classification pulls in a specific set of duties: automatic logging of events over the system's lifetime, human oversight of consequential decisions, and the ability to show a regulator what the system did. The Digital Omnibus adopted in 2026 moved the standalone high-risk compliance deadline to December 2, 2027, which the deadline deferral analysis covers in detail. The extra time changes when the paperwork is due. It does not change what a defensible hiring-AI deployment has to be able to produce, and much of that is a logging capability you build now.
Two problems that get conflated
Hiring-AI risk splits into two problems that require different controls. The first is whether the model produces biased outcomes: does the screening system disadvantage a protected group. That is a data-science and model-governance problem, addressed through training data audits, fairness testing, and model selection. A policy gateway does not evaluate a model for disparate impact, and it would be dishonest to claim it does. The second problem is whether each hiring decision is accountable: can you show which candidate was evaluated, by which system, on what inputs, under which policy, and when. That is a logging problem, and it is the one the AI request boundary answers. Keeping these separate is the first step to a compliant deployment.
What Article 12 asks for
Article 12 of the EU AI Act requires automatic recording of events over the lifetime of a high-risk system to ensure traceability. For a hiring system, that means a durable record of the AI evaluations it performed. The record has to capture the period of use, the input data involved, and the identification of the natural persons connected to the decision. Application logs from an ATS rarely hold this. They record that a candidate advanced or was rejected, not the identity and policy context of the model call that informed it. The logging Article 12 describes has to be written where the AI call happens, with the identity and input context attached.
Human oversight needs a decision record
The Act requires that high-risk systems allow for meaningful human oversight. Oversight is only meaningful if the human can see what the system did. A reviewer asked to sign off on a rejection needs the record of what the model was asked and what it returned for that candidate. Without a per-decision record, oversight collapses into rubber-stamping, because there is nothing specific to review. The audit trail is therefore not only an after-the-fact compliance artifact; it is the input to the oversight process the Act mandates. A record written at the model-call boundary gives a reviewer the specific decision to examine.
Controlling what reaches the model
There is an input-side control too. A hiring model does not need a candidate's full application to score a specific criterion, and some data should never reach an external model at all. Policy on the request path can hold back categories of candidate data that are irrelevant to the evaluation or legally sensitive, which reduces both discrimination exposure and data-protection risk. This is the same minimum-necessary logic that applies in regulated data handling, expressed as a decision on the content of each AI call. It sits alongside the model-governance work, not in place of it.
The penalty context
The EU AI Act sets high-risk non-compliance penalties at up to 15 million euros or 3% of global annual turnover, whichever is higher, under Article 99. The number is large enough that "we could not produce the logs" is an expensive answer to a supervisor's question. The logging capability is cheaper to build into the AI request path than to reconstruct under a deadline. For the full enterprise picture, see the EU AI Act high-risk deadline pillar.
DeepInspect
This is the gap DeepInspect closes for the logging half of the problem. DeepInspect sits inline between your hiring systems and the models they call. For every evaluation call it records the calling identity, the model, the input policy applied, and the outcome, which produces the traceable, per-decision record Article 12 describes. It also applies policy to the content of each request, so candidate data categories you choose to withhold never reach an external model.
DeepInspect does not test your model for bias; that stays with your model-governance program. What it produces is the evidence layer that program and the Act both depend on: a durable record of what each hiring AI call did, and control over what data those calls carried. The bias work and the logging work are different jobs, and the gateway does the second one on the path where the AI decisions actually happen.
If you are mapping hiring AI to the EU AI Act, let's talk today.
Frequently asked questions
- Does the EU AI Act cover HR and hiring AI?
Yes. Annex III lists AI used for recruitment, candidate screening, and evaluation among the high-risk categories. That classification brings duties including automatic logging under Article 12, human oversight, and the ability to demonstrate to a regulator what the system did. The Digital Omnibus moved the standalone high-risk deadline to December 2, 2027, but the obligations themselves stand.
- Can a policy gateway detect hiring bias?
No, and it should not claim to. Detecting disparate impact is a model-governance and data-science task, handled through fairness testing and training-data audits. A gateway addresses the separate, accountability side: recording which candidate was evaluated, by which system, on what inputs, and under what policy, so each decision can be reviewed and demonstrated.
- What does Article 12 require for a hiring system?
Automatic recording of events over the system's lifetime, capturing the period of use, the input data, and the natural persons involved, so the system's behavior is traceable. ATS application logs rarely hold this, because they record outcomes rather than the identity and policy context of the model call. The record has to be written where the AI evaluation happens.
- How does logging support human oversight?
Oversight is only meaningful when the reviewer can see the specific decision. A per-call record of what the model was asked and what it returned gives the human something concrete to examine before approving a consequential outcome. Without it, oversight becomes a rubber stamp, because there is no decision-level detail to review.