Deployer Checklist

What your organization owes once you deploy an HR AI system that touches EU-based workers or candidates. This is the employer-side counterpart to the vendor intake.

Mapped to Article 26 of the EU AI Act, with hooks into GDPR and existing HR practice. Not legal advice. Pair with Legal, Privacy, Works Council liaison, and HRBP review.

Timing

High-risk obligations for HR systems under Annex III apply from 2 December 2027 instead of 2 August 2026, under the AI Omnibus simplification package. The Omnibus is now law: Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force since 27 July 2026 (verified against the regulation text on EUR-Lex). December 2027 is a fixed calendar date, not a conditional one: the Commission’s original proposal would have tied the deadline to standards readiness, and the final agreement rejected that mechanism in favor of a fixed date, so don’t plan around further slippage. Embedded high-risk AI under Annex I (regulated products) gets a separate deferral, to 2 August 2028. Build the practice now. Vendors and customers are already asking for the evidence trail.

The deployer obligations, in plain English

1. Use the system per the instructions for use

Article 26(1). The deployer must use the high-risk system in accordance with the vendor’s instructions for use, and assign human oversight to people who have the competence, training, authority, and support to do it.

Action items:

• Store the version-locked instructions for use alongside the use case card.
• Re-confirm the use case still matches the intended purpose after every vendor model update.
• Confirm the named oversight owner has read the instructions and signed off.

2. Input data quality and control

Article 26(4). Where the deployer controls input data, the deployer must ensure input data is relevant and sufficiently representative for the intended purpose.

Action items:

• Document the data feeding the system: source, refresh cadence, quality checks.
• Note any input data the vendor controls and that the deployer cannot fix.
• Run a representativeness check before go-live and at every major change.

3. Monitor operation and pause when needed

Article 26(5). The deployer must monitor the system’s operation based on the instructions for use, and, where a risk arises, inform the provider and pause the use of the system.

Action items:

• Set monitoring cadence: weekly review of override rates, monthly fairness check, quarterly calibration.
• Pre-define the criteria that trigger a pause. Examples: override rate exceeds threshold, demographic disparity widens, vendor reports an incident, regulator opens an inquiry.
• Name who can press the pause button without further approval.

4. Keep the logs

Article 26(6). The deployer must keep the logs generated by the system for at least six months, unless other Union or national law requires longer. GDPR retention rules often require longer.

Action items:

• Confirm log export is enabled and tested.
• Set retention to at least six months. Many HR contexts will require longer under GDPR.
• Document where logs live, who has access, and the audit trail on the logs.
• Include log preservation in any vendor termination plan.

5. Inform workers and their representatives

Article 26(7). Before putting a high-risk system into service in the workplace, deployers that are employers must inform workers’ representatives and the affected workers that they will be subject to the system.

Action items:

• Identify the channel per jurisdiction: works council, union, employee representative body, direct notice where no body exists.
• Notice content covers: what the system does, what decision it influences, what data it uses, what the worker can do (review, contest, appeal), the oversight owner.
• Notice timing meets the longest applicable local requirement. Some jurisdictions require pre-deployment consultation, not just notice.
• Track sign-off per jurisdiction.

6. Use system output responsibly under Article 22 GDPR

When the system contributes to a decision with legal or similarly significant effect on a person, GDPR Article 22 protections may apply on top of AI Act duties. This is not a future obligation tied to the AI Act’s Annex III clock. Article 22 has been enforceable since May 2018, and regulators are actively saying so: at a July 2026 Parliament conference, the EDPS and EDPB stated that the AI Act Omnibus’s delay to December 2027 creates no GDPR safe harbor. Separately, the EDPB’s 2026 Coordinated Enforcement Framework covers GDPR transparency obligations broadly (Articles 12 to 14) across roughly 25 national DPAs, not an AI-hiring-specific audit, but recruitment and AI hiring notices are among the areas likely to draw scrutiny.

Action items:

• Determine whether the decision is solely automated. Override that exists but is rarely exercised does not save you. Regulators describe this as the “rubber stamp” problem: a reviewer who approves or rejects primarily on the algorithm’s output, without independently reviewing the underlying file, is not providing meaningful human review.
• If Article 22 is in play, ensure the legal basis is sound (explicit consent, contractual necessity, or authorizing law), provide meaningful information about the logic, and provide the right to obtain human intervention, express a point of view, and contest the decision.
• Confirm who holds Article 22 controller status when a vendor’s score materially shapes the outcome. Under the CJEU’s SCHUFA ruling, the vendor producing the score, not just the employer making the final call, can itself be the controller. Get this allocated in the vendor contract rather than assuming it defaults to you.
• Document the Article 22 analysis in the use case card.

7. Run a DPIA where required

GDPR Article 35 requires a DPIA when processing is likely to result in high risk. HR AI systems generally meet this threshold.

Action items:

• Run a DPIA before go-live.
• Consult the DPO during the DPIA, not after.
• Re-run the DPIA when the system changes materially or the deployment scope expands.
• Where required by national law, consult the supervisory authority.

8. Fundamental rights impact assessment (Article 27)

For certain deployers, including bodies governed by public law and private actors providing public services, a fundamental rights impact assessment is required before first use of a high-risk system.

Action items:

• Determine whether your organization falls in scope.
• If yes, complete the assessment covering: process for using the system, deployment period, categories of natural persons likely to be affected, specific risks of harm, human oversight measures, measures to be taken if risks materialize.
• Notify the market surveillance authority of the results.

9. Cooperate with authorities and respect transparency duties

Article 26(11) and Article 26(12). Deployers must cooperate with competent authorities and follow the transparency rules in Article 50 for systems generating or manipulating content, deepfakes, or emotion recognition.

Action items:

• Name the regulatory liaison for AI Act inquiries.
• Cover transparency requirements in the use case card if the system generates synthetic content or is used for emotion recognition (the latter is broadly prohibited in the workplace under Article 5).

10. Stop if the system causes serious incidents

Article 26(5) and Article 73 reporting obligations.

Action items:

• Define “serious incident” in your incident playbook, aligned to AI Act and GDPR.
• Reporting timeline: serious incidents to the provider, and (in some categories) to the market surveillance authority.
• Run a postmortem using the incident report template and update the use case card.

Worker notice template (starting point)

Adapt per jurisdiction and consult Works Council liaison.

[Company] uses [system name] to support [decision stage, for example: first-pass screening of inbound applications]. The system [what it does, for example: scores applications against role requirements]. A [oversight role, for example: senior recruiter] reviews the system’s outputs and is responsible for the final decision. The system uses [data categories, for example: information from your application and résumé]. You can: request a human review, contest a decision, ask what data was used, and ask how the system reached its result. To exercise these rights, contact [named role and channel]. This notice is provided ahead of deployment on [date], in line with our obligations under the EU AI Act and GDPR. The system version is [version], dated [date].

Monthly monitoring template (starting point)

Metric	Threshold	This month	Owner	Action if breached
Override rate	5 to 15 percent		Oversight owner	Investigate calibration
Disparity ratio (4 / 5ths rule, where applicable)	0.80 or higher		HRBP	Pause and rerun fairness audit
Incident count	0		Oversight owner	Postmortem and provider notification
Worker queries	Track only		HR Ops	Quarterly review
Model version	Unchanged or noted change		Oversight owner	Re-confirm IfU and intake card

Cross-links

• EU AI Act intake template: the per-use-case card that this checklist operationalizes.
• Vendor intake checklist: the evidence you collect from vendors before this checklist applies.
• Risk assessment template: the broader fairness and incident process.
• AI use policy: the organizational frame.