Does the Annex III point 4 classification apply to AI-assisted resume screening?

Yes. The text covers AI systems used to "analyze and filter job applications." Resume screening AI falls within that scope regardless of whether the AI makes a final rejection decision or only ranks applications for human review. The classification turns on the use case, not on the degree of automation.

What about AI used for promotion decisions inside the company?

Annex III, point 4(b) covers AI systems used to make decisions affecting terms of work-related relationships, including promotions. Internal mobility tools, performance management AI, and succession planning AI fall within scope when they influence promotion decisions.

How does this interact with GDPR Article 22 automated decision-making?

GDPR Article 22 prohibits decisions based solely on automated processing that produce legal or similarly significant effects. Employment decisions almost always qualify as having significant effects. Most HR AI deployments rely on the human-intervention exception in Article 22. The EU AI Act Article 12 logging applies on top of GDPR Article 22 documentation requirements. The same per-decision audit record supports both.

What about worker monitoring AI?

Annex III, point 4(b) covers AI to "monitor and evaluate the performance and behavior of persons" in work-related relationships. Employee productivity monitoring, sentiment analysis on internal communications, and similar surveillance AI applied to workers fall within scope. The classification has implications for the works council notification process and the lawfulness of the monitoring under EU member state labor law.

What is the deadline?

The high-risk system requirements take effect August 2, 2026. AI systems placed on the market before that date fall under the Article 111 transition period. New HR AI deployments after August 2, 2026 must comply from the start. Existing deployments must come into compliance during the transition.

EU AI Act for HR: Annex III Point 4 and the High-Risk Recruitment Stack

Annex III, point 4 of the EU AI Act classifies AI systems used in employment, workers management, and access to self-employment as high-risk. The scope covers two categories: AI for recruitment or selection (including advertising vacancies, applicant screening, and evaluation), and AI for making or assisting decisions on terms of employment, promotion, termination, task allocation, and worker monitoring. The high-risk system requirements take effect August 2, 2026 with penalties under Article 99 reaching €15 million or 3% of global turnover.

The HR AI stack is wider than most compliance teams recognize. The applicant tracking system uses AI to rank resumes. The interview platform uses an LLM to summarize candidate transcripts. The skills assessment platform scores responses with a model. The internal mobility tool recommends promotions with a recommendation engine. The performance management tool drafts review summaries. Each one falls under Annex III, point 4.

I want to walk through what the classification covers across the recruitment and employment lifecycle, what Article 12 logging requires, and what the architecture for compliant HR AI use looks like.

Mandate

Annex III, point 4 covers two sub-categories:

4(a): AI systems intended to be used for the recruitment or selection of natural persons, in particular to place targeted job advertisements, to analyze and filter job applications, and to evaluate candidates.

4(b): AI systems intended to be used to make decisions affecting terms of work-related relationships, to promote and terminate work-related contractual relationships, to allocate tasks based on individual behavior or personal traits, and to monitor and evaluate the performance and behavior of persons in such relationships.

The classification triggers the Title III, Chapter 2 obligations. The articles that operate at the request layer are Articles 12, 13, 14, and 26.

Article 12 logging

The AI system must automatically record events over the lifetime of the system. Article 19 specifies the log content: period of use, reference databases checked, input data leading to a match, and identification of natural persons involved in result verification.

Article 13 transparency

The HR AI provider must supply instructions for use covering the system's intended purpose, its limitations, the human oversight measures, and the technical and organizational measures the deployer should take.

Article 14 human oversight

The system must be designed so that natural persons can effectively oversee its operation. The HR context emphasizes the automation bias risk: the hiring manager who accepts the AI's ranking without independent assessment.

Article 26 deployer obligations

The employer (the deployer) must use the system in accordance with the instructions, assign human oversight, monitor operation, retain logs for at least six months, and inform workers and their representatives about the high-risk AI system before it is put into service.

Compliance gap

HR AI deployments today have several structural gaps under Article 12.

The application stack is fragmented

A typical HR AI footprint touches an applicant tracking system (Workday, Greenhouse, Lever), a video interview platform (HireVue, modernHire), an assessment platform (Pymetrics, Plum), and an internal LLM-based summarization tool. Each one writes its own logs. The composite picture of a candidate's journey through AI-assisted evaluation lives across multiple log streams, none of which were designed for Article 12.

Worker representative notification is a process gap

Article 26 requires the deployer to inform workers and their representatives about the high-risk AI system before it is put into service. The notification is a procedural obligation that maps to the works council and union processes in EU member states. The compliance program needs to address the procedural side alongside the technical side.

Adverse outcome documentation is application-controlled

When the AI assists in a hiring rejection, a promotion denial, or a termination, the candidate or worker has rights under Article 86 to receive an explanation of the decision. The explanation must reference the role of the AI in the decision. Application-controlled logs rarely contain the per-decision detail needed to produce the explanation.

Cross-border deployment complicates oversight

A multinational employer running the same HR AI stack across EU and non-EU jurisdictions faces different obligations per geography. The audit record must support the EU-specific obligations for EU-applicable decisions without requiring a separate technology stack.

Mandate vs. Compliance

The letter of Article 12 reads at one level of abstraction. The architecture to survive a Data Protection Authority or labor regulator review operates several levels lower.

The questions a regulator will ask

The questions that follow a regulatory inquiry into an HR AI decision are specific. Which AI-assisted evaluations touched this candidate? Who initiated each request? What input data was used? What was the model's output? How did the human reviewer use the output? Can you produce, in writing, a tamper-evident record showing all of the above?

What surviving a review actually requires

An architecture that satisfies Article 12 for HR AI produces, for every model request, a record containing:

A verified identity for the natural person behind the request (the recruiter, hiring manager, or HR business partner)
The role and authorization context
The data sources consulted
The candidate or worker the decision pertains to
The data classification applied
The policy version that governed the decision
The model output
The decision the human reviewer recorded
A timestamp
A cryptographic signature

That record is independent of the application that made the request. It supports Article 86's explanation-on-request obligation. It supports the works council notification process under Article 26.

DeepInspect

This is the architecture DeepInspect was built to provide. DeepInspect sits at the AI request boundary as a stateless proxy between HR applications and the LLM or model APIs they call. Every request is evaluated against per-route, per-role policies using the identity context the application supplies. Candidate or worker context is captured. The audit record is signed and tamper-evident, committed before the model response returns.

The Article 12 fit is structural. The recording is automatic, covers the lifetime of the deployment, and produces records detailed enough to reconstruct each AI-assisted evaluation. Article 86 explanation requests can be served from the audit record without manual archeology across multiple HR tool logs.

If you are facing the August 2 EU AI Act deadline for HR AI use cases and your architecture relies on application logs across a fragmented HR stack, the audit record gap shows up the first time a candidate exercises rights under Article 86 or a works council requests an Article 26 notification record. Book a demo today.

Beyond Article 12

The same architectural pattern satisfies adjacent obligations on HR AI. The New York City AEDT law (Local Law 144) imposes bias audit and notification requirements on automated employment decision tools used for hiring or promotion in NYC. The Illinois Artificial Intelligence Video Interview Act applies to video interview AI. The California AB-2930 (Workplace Technology Accountability) is in legislative development. The same per-decision audit record supports all of these.