EU AI Act Deployer Obligations After the Omnibus (2026)

Surya Koritala
23 Min Read

The Digital Omnibus pushed most high-risk duties to December 2027, but a hard core of EU AI Act deployer obligations still bites in 2026. Here is what slipped, what stayed, and a build-ready checklist.

What changed: the Digital Omnibus in one paragraph

The Digital Omnibus, agreed provisionally by the Council and Parliament on 7 May 2026, pushed the bulk of the EU AI Act’s high-risk obligations back by 12 to 16 months, but it did not erase the 2 August 2026 milestone. Stand-alone high-risk systems listed in Annex III now have until 2 December 2027 to comply, and AI embedded in regulated products under Annex I gets until 2 August 2028. The Commission’s original 19 November 2025 proposal floated a conditional, standards-readiness trigger; the co-legislators replaced it with these fixed dates because the supporting standards and tooling were simply not materializing on schedule.

Two nuances matter for anyone planning around this. First, the agreement is provisional: it still needs formal approval by both the Council and the Parliament and publication in the Official Journal before it is law. Until that happens, the original timeline technically governs. Second, the delay is targeted at the heaviest conformity machinery, not at the entire Act. Several deployer-facing duties either are already live or arrive in 2026 regardless of the Omnibus, which is why reading the headline as ‘we have until 2027’ is the single most dangerous misreading of the EU AI Act deployer obligations landscape right now.

European Union flag and regulatory documents on a desk representing AI Act compliance work
Image.

The 7 May 2026 deal is a provisional political agreement, not enacted law. If formal adoption stalls, the original 2 August 2026 high-risk deadline applies. Build to the strict date and treat any slippage as headroom.

What slipped to December 2027 versus what stays in 2026

What slipped: the full conformity obligations for Annex III high-risk systems (to 2 December 2027) and for Annex I product-embedded AI (to 2 August 2028), plus the national regulatory-sandbox deadline (to 2 August 2027). What did not slip: the prohibitions on unacceptable-risk practices (Article 5) and general-purpose AI model obligations (Articles 51–56), both of which have been in force since 2025, and the bulk of the Article 50 transparency rules.

The transparency picture is the easy thing to get wrong. The Omnibus did not postpone Article 50; it shortened the grace period for machine-readable watermarking of AI-generated content from six months to three, setting a new deadline of 2 December 2026 for systems already on the market. So a duty arrived sooner, not later. For deployers, the practical takeaway is that the EU AI Act deployer obligations you must plan around in 2026 are transparency, prohibited-use compliance, GPAI-linked duties, and the foundational governance hygiene that makes the December 2027 deadline survivable.

The table below maps the moving pieces. Treat dates as the current provisional position; legislative figures move, and the Official Journal text is the only one that ultimately counts.

ObligationPre-Omnibus datePost-Omnibus dateStatus for deployers
Prohibited practices (Art. 5)2 Feb 2025UnchangedIn force now
GPAI model obligations (Art. 51-56)2 Aug 2025UnchangedIn force now
Watermarking grace period (Art. 50(2))~6 months3 months, due 2 Dec 2026Tightened, arrives 2026
Annex III high-risk full duties (incl. Art. 26)2 Aug 20262 Dec 2027Delayed ~16 months
Annex I product-embedded AI2 Aug 20272 Aug 2028Delayed ~12 months
National regulatory sandboxes2 Aug 20262 Aug 2027Delayed 12 months
EU AI Act timeline after the Digital Omnibus (provisional, as of 30 May 2026)

The core EU AI Act deployer obligations under Article 26

Article 26 makes deployers of high-risk AI responsible for using the system per the provider’s instructions, assigning competent human oversight, retaining auto-generated logs for at least six months, monitoring operation, and informing affected workers before workplace deployment. These are the obligations whose full enforceability the Omnibus pushed to 2 December 2027 for Annex III systems, but every one of them produces an artifact that takes real engineering time to build, so the runway is for execution, not for waiting.

Concretely, the EU AI Act deployer obligations under Article 26 break into duties you implement in the product and duties you implement on paper. The product-side duties are human-oversight controls and tested log retention; the paper-side duties are the classification rationale, the instructions-for-use trail, worker notifications, and incident procedures. The Fundamental Rights Impact Assessment under Article 27 sits alongside these for a specific subset of deployers, covered in the next section.

There are eight Annex III high-risk domains that trigger this regime: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential public and private services (including creditworthiness and health/life insurance pricing), law enforcement, migration and border control, and the administration of justice and democratic processes. If your system touches one of these, the Article 26 deployer duties apply to you even if you bought the model from someone else.

Human oversight (Art. 26(2))Assign named natural persons with the competence, training, authority, and support to actually intervene. Auditors want the named reviewer, their decision authority, the intervention triggers, the escalation route, and records of how the team responded to abnormal behavior. An org chart is not an oversight control.
Log retention (Art. 26(6))Keep logs automatically generated by the high-risk system, to the extent they are under your control, for a period appropriate to the purpose and at least six months. Mid-market teams usually have a retention policy but cannot prove it covers the specific in-scope system or retrieve those logs on demand. Make it a tested config, not a sentence in a policy PDF.
Input data and monitoring (Art. 26(4)-(5))Where you control input data, ensure it is relevant and sufficiently representative for the intended purpose. Monitor operation and inform the provider per Article 72; if you spot a risk to health, safety, or fundamental rights, notify the provider, distributor, and market surveillance authority without undue delay and suspend use.
Worker and data-protection duties (Art. 26(7)-(9))Before deploying a high-risk system in the workplace, inform workers’ representatives and affected workers. Use the Article 13 information to meet your GDPR data-protection-impact-assessment obligations. Public bodies must not use Annex III systems that are not registered in the EU database.

When a Fundamental Rights Impact Assessment is mandatory

A Fundamental Rights Impact Assessment (FRIA) under Article 27 is mandatory, before deployment, for public bodies, private entities delivering public services, and any deployer of high-risk AI used for creditworthiness or credit scoring, or for risk assessment and pricing in life and health insurance. The credit and insurance triggers apply regardless of whether you are public or private, which catches a lot of fintech and insurtech teams that assume FRIAs are a government-only chore.

The FRIA must describe how and when the system will be used, who it could affect, the specific risks of harm to fundamental rights, the human-oversight measures in place, and the steps you will take if those risks materialize. Results are reported to the market surveillance authority unless an exemption applies. Practically, the FRIA overlaps heavily with a GDPR data-protection impact assessment, so build them as one connected exercise rather than two parallel documents that drift apart.

Because the Article 26 and Article 27 deadlines for Annex III moved together to December 2027, you have time to do the FRIA properly. Do not confuse that with optionality. The assessment is the artifact that demonstrates you understood your system’s fundamental-rights footprint before you shipped it, and retrofitting it after an incident is the worst possible time to be writing it.

“The credit and insurance FRIA triggers apply to private firms too. A lot of fintech teams assume this is a government-only obligation. It is not.”

On the most-missed Article 27 trap

What non-compliance costs and who enforces it

EUR 15M / 3%

Max fine for Article 26 deployer breaches

Whichever is higher, of global annual turnover (Art. 99)

2 Dec 2027

New Annex III high-risk deadline

Pushed from 2 Aug 2026 by the Omnibus

6 months

Minimum log retention

Under Article 26(6), to the extent logs are under your control

8 domains

Annex III high-risk categories

From biometrics to administration of justice

Breaching the Article 26 deployer obligations exposes an organization to administrative fines of up to EUR 15 million or 3% of total worldwide annual turnover, whichever is higher, under Article 99. That is the second-highest penalty tier in the Act; only prohibited-practice violations sit higher, at up to EUR 35 million or 7% of turnover. Supplying incorrect or misleading information to authorities is a separate, lower tier of up to EUR 7.5 million or 1%.

Enforcement runs through national market surveillance authorities. Once the relevant obligations are live, they can request information from providers and deployers, order corrective measures up to withdrawing a system from the market, and levy the Article 99 fines. The Omnibus delay shifts when the high-risk enforcement clock starts for Annex III systems to December 2027, but it does not soften the penalty exposure once it does. And the duties already in force in 2026, the prohibitions and the transparency rules, are enforceable now.

The figures and tiers here reflect the current statutory text; like all regulatory numbers, they can be amended, and member states retain discretion on how they apply penalties to public bodies. Treat the EUR 15 million / 3% figure as the ceiling that should anchor your risk modeling, not as a prediction of any specific fine.

A deployer compliance checklist you can build against

Use the delay as runway, not as a snooze button

The Digital Omnibus bought Annex III deployers until December 2027, but the prohibitions, GPAI duties, and tightened watermarking are live in 2026, and the agreement is still provisional. The organizations that win are the ones that spend the runway turning intentions into artifacts: a register, classification rationales, oversight assignments, tested log retention, and FRIAs where required. The EU AI Act deployer obligations are not waiting for you; they are waiting on you to write them down.

Start with a complete AI system inventory, classify each system against Annex III, then assign oversight, wire log retention, run any required FRIA, and capture every decision as an artifact. The recurring failure pattern auditors describe is not bad intentions; it is organizations that did the thinking but never turned it into a register, a classification rationale, an oversight assignment, a retention setting, and an escalation record. The checklist below sequences the work so the EU AI Act deployer obligations become tractable engineering tasks rather than a wall of legal text.

Work top to bottom. Each step produces a durable artifact, and the artifact, not the activity, is what you show a market surveillance authority. Pseudocode is offered for the inventory step because a maintained machine-readable register is the foundation everything else hangs off.

# ai-system-register.yaml — the artifact everything else depends on
systems:
  - id: resume-screener-v3
    purpose: "Rank inbound applications for shortlisting"
    annex_iii_domain: 4              # employment / worker management
    classification: high-risk
    rationale_doc: docs/class/resume-screener.md   # not 'it's just a model'
    provider: external-vendor-x
    human_oversight:
      named_owner: "hiring-ops-lead"
      intervention_triggers: ["score<0.3 auto-reject", "protected-class skew"]
      escalation: "#ai-governance -> DPO"
    log_retention_months: 12         # >= 6 required; tested retrieval path
    fria_required: false             # employment != credit/insurance/public
    incident_runbook: runbooks/ai/resume-screener.md
    worker_notice_sent: 2026-04-15
1. Inventory every AI systemEnumerate all systems, including pilots, contract-classification tools, and shadow deployments. Teams typically name the obvious three or four and miss the rest. You cannot comply for what you cannot see.
2. Classify against Annex IIIFor each system, document the intended purpose, function, use context, and whether it lands in one of the eight high-risk domains. Record a written rationale with named approval, not an assumption.
3. Assign and document human oversightName the reviewer, define their authority and intervention triggers, set the escalation route, and start logging responses to abnormal behavior for the highest-risk systems first.
4. Configure and test log retentionSet retention to at least six months for each in-scope system, then actually test retrieval. Prove the policy covers the specific system and that you can produce logs on request.
5. Run the FRIA where requiredIf you are a public body, a private provider of public services, or you do credit scoring or life/health insurance pricing, complete the Article 27 FRIA before deployment and connect it to your GDPR DPIA.
6. Notify workers and stand up incident responseInform worker representatives before workplace deployment. Replace the generic cyber playbook with an AI-specific runbook: suspension thresholds, escalation paths, and an event-recording template for risky or unexplained outputs.

Builder’s take

I run Cyntr, an agent-orchestration runtime, and Loomfeed, both of which touch users in the EU. I read the Omnibus the morning the provisional deal landed, expecting relief, and walked away with a longer to-do list, not a shorter one. The delay is real but it is narrow, and the parts that survived are exactly the parts engineers under-build.

  • Treat the December 2027 delay as runway for the conformity-assessment machinery, not as permission to defer your deployer hygiene. The artifacts that prove human oversight, log retention, and classification take months to retrofit into a live system, and auditors want the paper trail, not your good intentions.
  • Build a system inventory before anything else. When I audited Cyntr’s own surfaces I found two features I would not have flagged as in-scope under a casual read; you cannot classify what you have not enumerated, and ‘it is just a chatbot’ is not a legal analysis.
  • Wire log retention as a config flag with a tested retrieval path, not a vague policy. Six months minimum under Article 26(6) is meaningless if you cannot pull the logs for a specific system on demand, which is the exact gap surveillance authorities probe first.
  • Watch the formal adoption, not the headline. The Omnibus is provisional until it hits the Official Journal, and if it stalls, the original 2 August 2026 high-risk deadline snaps back. I am building to the strict timeline and treating any slippage as a bonus.

Frequently asked questions

Did the Digital Omnibus cancel the EU AI Act high-risk rules?

No. It postponed the full compliance deadline for Annex III stand-alone high-risk systems from 2 August 2026 to 2 December 2027, and for Annex I product-embedded AI to 2 August 2028. The rules still apply; the dates moved, and the agreement is provisional until formally adopted and published in the Official Journal.

What EU AI Act deployer obligations still apply in 2026?

The prohibitions on unacceptable-risk practices and general-purpose AI model obligations have been in force since 2025, and most Article 50 transparency duties apply in 2026. The Omnibus actually shortened the watermarking grace period to three months, with a 2 December 2026 deadline for systems already on the market.

What are the main Article 26 deployer obligations?

Deployers must use high-risk systems per the provider’s instructions, assign competent human oversight, ensure input data is relevant where they control it, monitor operation, retain auto-generated logs for at least six months, and inform workers before workplace deployment. Public bodies must also avoid using unregistered Annex III systems.

Who has to do a Fundamental Rights Impact Assessment?

Public bodies, private entities delivering public services, and any deployer using high-risk AI for creditworthiness, credit scoring, or life and health insurance risk assessment and pricing. The credit and insurance triggers apply to private firms too, and the FRIA must be completed before deployment under Article 27.

What are the penalties for deployer non-compliance?

Breaching Article 26 deployer obligations can trigger fines of up to EUR 15 million or 3% of total worldwide annual turnover, whichever is higher, under Article 99. That is the second-highest tier; prohibited practices carry up to EUR 35 million or 7%. National market surveillance authorities enforce these.

Should I wait until December 2027 to start compliance work?

No. The artifacts that prove compliance, such as a system inventory, classification rationales, oversight assignments, tested log retention, and FRIAs, take months to build into a live system. The delay is runway for execution, and the agreement could still slip back to the original 2026 timeline if formal adoption stalls.

Primary sources

Last updated: May 30, 2026. Related: Governance.

Share This Article
Leave a Comment