If your team spent the first half of 2026 preparing for an August deadline, there is news: it moved. If you concluded from that news that there is nothing to do, there is more news.
This is an engineering read of a legal text, not legal advice. If you are deploying into a regulated domain, get counsel. What follows is the part that turns into tickets.
The deadline you were preparing for has moved
Under the Digital Omnibus, a provisional political agreement reached on 6 May 2026 and confirmed by the Council a week later, the high-risk obligations for Annex III systems move from 2 August 2026 to 2 December 2027. Annex I moves from 2 August 2027 to 2 August 2028. Regulatory sandboxes shift by a year. Gibson Dunn’s summary of the agreement.
Two things about that word "provisional" matter. At the time of writing the agreement had not been formally adopted or published in the Official Journal, so the dates are the expected ones rather than the settled ones. And a deadline that has moved once can move again, in either direction — which is an argument for building the durable parts now rather than timing a scramble.
The high-risk deadlines moved. Nothing that was already in force moved with them.
Prohibited practices have been banned since February 2025. General-purpose AI model obligations have applied since August 2025 and were explicitly left unchanged. And two new Article 5 prohibitions — covering AI-generated non-consensual intimate imagery and child sexual abuse material — arrive with a transitional period running to 2 December 2026. That last date is sooner than the one you just stopped worrying about.
Four tiers, read as engineering consequences
The Act classifies systems, not technologies. The same model behind a spam filter and behind a hiring decision sits in two different tiers, and the tier is decided by what the system does to a person — not by how large the model is or which vendor supplied it.
For most teams shipping an AI feature into an existing product, the honest answer is the third row: limited risk, where the obligation is disclosure. Users must know they are dealing with an AI system, and generated content must be marked as such. That is a day of work, and it is a day of work that most teams have not done.
The row above it is where budgets change by an order of magnitude, and teams land in it more often than they expect. Anything that filters job applicants, scores creditworthiness, allocates access to education or public services, or sits in critical infrastructure is a candidate. "We only rank them, a human decides" does not automatically exempt you — the question is how much that human can realistically override.
The practical way to settle your tier is to read the Annex III list against your own feature list rather than reasoning from first principles. The domains named there are concrete: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services including creditworthiness, law enforcement, migration and border control, and the administration of justice. If your product touches one of those, assume high-risk until somebody senior has written down why not.
Are you a provider or a deployer?
This is the single most useful distinction in the whole text, and it is usually settled in one sentence: if you call somebody else's model through an API, you are a deployer. Your obligations centre on telling users what they are talking to, providing genuine human oversight, keeping records, and confirming that the model provider has published the documentation they owe.
The trap is that the boundary is crossable. Fine-tuning a model, or modifying it substantially, or shipping it under your own name, can make you the provider of a new system — and the provider obligations are considerably heavier. Before a team starts fine-tuning to squeeze out a few points of accuracy, it is worth asking out loud whether that decision also changes which column of the diagram above you are standing in.
Being a deployer does not mean the provider's obligations are irrelevant to you — it means you depend on them. Their documentation is an input to your compliance, so it belongs in your vendor assessment alongside uptime and price. Ask for the model documentation, the training-data summary, the copyright policy, and the intended-purpose statement, and ask what happens to all four when they deprecate the version you are on.
What high-risk classification costs you to build
Read that list as a backlog rather than as a legal summary and its shape changes. Four of the six are engineering deliverables with a schema, a test suite or an interface attached, and none of them can be produced retroactively the month before an audit.
- Accuracy has to be declared. You must state metrics and defend them, which means holding an evaluation set that is representative and versioned. If you do not have one, that is the first ticket.
- Data governance is provenance work. Where each training or retrieval corpus came from, on what basis you may use it, and what you did to examine it for bias. Mostly a records problem, and much cheaper to record as you go.
- Risk management is a loop, not a document. It has to be re-run when the system changes, which for an AI feature means at least whenever the model or the prompt changes.
The sixth item is the one with the longest lead time and the least engineering content. Conformity assessment happens before the system reaches the market, the system is entered in an EU database, and post-market monitoring runs afterwards. For many Annex III systems the assessment is a self-assessment against the requirements rather than an external audit — which sounds cheaper until you notice that self-assessing means producing all the evidence yourself, on a schedule, with somebody willing to sign it.
Logging is a schema decision you are making today
High-risk systems must keep automatic records over their lifetime. Read plainly, that is a retention policy and a table definition — and the table definition is the part that becomes impossible to fix later, because you cannot backfill a field you never captured.
The field teams forget is retrieved_doc_ids. Without the evidence the model saw, an entry records that a decision happened but not why, and reproducing it a year later is guesswork. This is the same discipline that makes a retrieval system debuggable at all — the trace-level detail we argued for in the cost breakdown is, it turns out, most of what the regulation asks you to keep.
Two design notes that save pain. Pseudonymise the subject identifier at write time rather than storing raw personal data you will later have to erase on request. And store the model and prompt versions as identifiers you can resolve, not as free text — "gpt-latest" is not a record of anything.
Retention is where this collides with the rest of your obligations. The AI Act wants records kept; the GDPR wants personal data not kept longer than necessary, and erased on request. Those are reconcilable — pseudonymise, separate the identifier mapping, and set retention per field rather than per row — but they are reconcilable at design time and expensive to reconcile afterwards. Decide the retention period in the same ticket that creates the table.
Human oversight is an interface, not a policy
The requirement that a human can oversee the system is routinely satisfied on paper by a sentence in a process document, and routinely unsatisfied in the product. The test is not whether a human is nominally in the loop. It is whether that human can see what the system decided, understand why, and overrule it without filing a ticket.
- Show the evidence, not just the verdict. The reviewer needs the retrieved documents and the confidence, on the same screen as the decision.
- Make the override a first-class action. One button, logged, with a reason field. If overriding is harder than accepting, nobody overrides, and your oversight is decorative.
- Watch your override rate. If it is near zero, either the model is excellent or the interface is rubber-stamping. Those look identical in a dashboard and very different in an audit.
The Act names the failure directly: automation bias, the tendency of people to defer to a machine's output precisely because a machine produced it. Oversight designed without accounting for it produces a reviewer who clicks approve four hundred times a day. Presenting confidence honestly, surfacing disagreement, and occasionally requiring a written reason are the cheap countermeasures — and they are interface decisions, made by whoever designs the review screen, not by whoever writes the policy.
What the penalties are actually for
The headline number circulating in compliance write-ups is up to €35 million or 7% of global turnover — a figure worth treating as the ceiling for the most serious category, prohibited practices, rather than as the expected cost of a paperwork gap. It comes from secondary summaries rather than the law firm note cited above, so treat it as indicative.
The more useful way to think about exposure is that enforcement follows complaints, and complaints follow visible harm. A system that can explain its decisions, shows its evidence, and has a working override path is unlikely to generate the complaint in the first place. That is the same property that makes it a good product.
There is also a commercial argument that lands better with a budget holder than a fine does. Enterprise procurement in the DACH region has already started asking these questions in security reviews — which tier is this, where are the logs, who can override. A team that can answer in a meeting rather than in a follow-up email closes faster. The compliance work and the sales enablement work turn out to be the same artefacts.
What to do with the extra time
- Classify every AI feature you already ship. One line each, with the tier and the reason. Most will be limited risk, and finding the one that is not is the entire point of the exercise.
- Ship the disclosure now. Telling users they are talking to an AI is the cheapest obligation in the Act and the one most often skipped.
- Fix the log schema before the volume arrives. Adding a field is a migration; adding it retroactively to two years of history is not possible.
- Build the eval set you will need anyway. Declared accuracy requires measured accuracy. This is the obligation with the longest lead time and the most product value outside compliance.
- Re-read the dates in six months. They moved once under a provisional agreement that was not yet in the Official Journal when this was written.
Almost everything on that list is something a careful team would build regardless of the regulation. That is the most reassuring thing about the AI Act, and the reason a moved deadline changes the schedule rather than the work.
