By PowerQuant | Updated June 2026 | Reading time: ~8 minutes
When the EU AI Act is discussed in board rooms, the conversation usually centres on providers — the vendors who put AI systems on the market. That focus is understandable: providers carry the bulk of the design-time obligations (risk management, technical documentation, conformity assessment, CE marking). But the Act draws a deliberate line between provider and deployer, and the deployer stack is where most enterprise HR teams under-prepare. Below are the obligations we see overlooked most often, drawn from the Act itself rather than a vendor pitch deck.
Who is a "deployer"?
A deployer is any natural or legal person using an AI system under its authority, except where the use is in a personal non-professional activity (Art. 3(4)). If your organisation buys an HR AI system from a vendor and runs it on your candidates or workers, you are a deployer — even if you never touch the model weights and even if you are using a managed SaaS tool. Deployer status is about who controls the use, not who hosts the inference.
1. AI literacy applies right now — not in 2026
Article 4 — "AI literacy" — has applied since 2 February 2025. It requires providers and deployers to ensure, "to their best extent", a sufficient level of AI literacy among their staff and other people dealing with the operation and use of AI systems on their behalf. The text is short but the practical scope is wide: it covers internal staff, contractors and service providers who interact with the system in any meaningful way.
What teams miss: Art. 4 is not satisfied by a one-off 10-minute e-learning. Regulators and enterprise buyers expect a documented programme — who needs training, at what depth, when they were trained, and when the training is refreshed. By the time you reach 2 August 2026 the programme should already have a history.
2. The worker-information obligation (Art. 26(7))
Before putting a high-risk AI system into service or use in the workplace, deployers of high-risk AI systems that are employers shall inform workers' representatives and the affected workersthat they will be subject to the use of the high-risk AI system. This is in addition to GDPR information duties, not a substitute for them.
What teams miss: the obligation runs before first use, not after, and it is targeted — workers themselves and their representatives (works council, union, employee delegates). A line in the employee handbook is not the same thing as a documented, dated notification to a named works council. National employment law layered on top will usually require consultation, not only information.
3. Human oversight is a role with authority, not a checkbox
Article 26(2) requires deployers to assign human oversight to natural persons who have the necessary competence, training, authority and support. Article 14 — the design-side counterpart — clarifies what those humans must be enabled to do: properly understand the relevant capacities and limitations of the system, remain aware of the possible tendency to over-rely on its output ("automation bias"), correctly interpret its output, decide not to use it or to disregard, override, or reverse its output, and intervene or interrupt operation.
What teams miss: an oversight role with no authority to actually stop or override is not oversight. Recruiters who can flag a candidate but not remove them from a ranking, or schedulers who cannot deviate from an algorithm's output without manager approval, do not satisfy Art. 26(2). The role must be named, trained, and empowered — and that empowerment must be visible in your process documentation.
4. Input data is your problem, not just the provider's
Article 26(4) requires deployers to ensure that input data is relevant and sufficiently representative in view of the intended purpose of the high-risk AI system, to the extent the deployer exercises control over the input data.
What teams miss: this is the obligation that bites in HR. You control which CV fields are sent to a screening tool, which historical hires are used to fine-tune a matching model, and which workforce signals feed a productivity dashboard. If those inputs are biased, unrepresentative of your applicant pool, or stale, that is on you — not your vendor. Document the input-selection decisions, including what you deliberately exclude and why.
5. Log retention for at least six months
Article 26(6): deployers shall keep the logs automatically generated by the high-risk AI system, to the extent such logs are under their control, for a period appropriate to the intended purpose of the AI system — of at least six months, unless provided otherwise in applicable Union or national law.
What teams miss: SaaS vendors often retain logs by default for 30–90 days. If you have not contractually extended retention to ≥6 months and confirmed where the logs live, you do not meet Art. 26(6). For HR-tech this overlaps with GDPR storage-limitation analysis — different purposes, but the retention decision needs to be coherent.
6. Fundamental Rights Impact Assessment (Art. 27)
Art. 27 introduces the FRIA — a Fundamental Rights Impact Assessment that deployers must carry out before first use of certain high-risk AI systems. The hard requirement applies to bodies governed by public law and to private entities providing public services, as well as to certain Annex III use cases (e.g. creditworthiness; insurance risk and pricing for life and health).
What teams miss: even where Art. 27 does not strictly require a FRIA, doing one as a documented impact assessment is rapidly becoming the de-facto evidentiary standard for enterprise procurement and for showing a national authority that you took the rights of affected persons seriously. If you consciously choose not to do one, document that decision and the reasoning.
7. Incident reporting up the chain (Art. 26(5) + Art. 73)
Deployers shall monitor operation and, where they have reason to consider that the use in accordance with the instructions may result in the AI system presenting a risk within the meaning of Art. 79(1), inform the provider or distributor and the relevant market-surveillance authority without undue delay and suspend use. Serious incidents are reported to the provider, and providers in turn report under Art. 73.
What teams miss: "without undue delay" is not a calendar quarter. Build the reporting path into your incident-management runbook now, with the named provider contact and the relevant national authority identified per Member State of use. For Danish HR-tech deployers, that authority will be the body designated under the Danish national implementation of the AI Act.
8. The right to explanation (Art. 86) — deployers must enable it
Art. 86 gives any affected person subject to a decision taken by a deployer on the basis of the output of a high-risk AI system listed in Annex III (with exceptions) the right to obtain from the deployer clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken.
What teams miss: this lands squarely on the employer, not the vendor. Your HR processes need a path for a rejected candidate or a disciplined worker to request — and receive — a meaningful explanation, in language a non-technical person can act on. "The algorithm decided" is not a meaningful explanation; it is an admission of non-compliance.
9. The provider-flip trap (Art. 25)
Article 25 sets out the conditions under which a deployer is reclassified as a provider — and inherits the much heavier provider obligation stack. You become a provider if you put your name on the system, substantially modify it, or modify the intended purpose of a system that was not classified as high-risk so that it becomes high-risk.
What teams miss: enterprise customisation of an HR tool — building your own scoring layer on top of a vendor's candidate-matching API, or fine-tuning a foundation model on your own performance-review corpus — can flip you into provider status. If you customise, get a written analysis on file before you go live.
10. Penalties are real — and tiered
Art. 99 sets the maximum administrative fines:
The higher of the absolute figure or the percentage applies. For SMEs and start-ups, lower of the two applies (Art. 99(6)). These caps coexist with national enforcement choices, which can stiffen the penalty in practice.