Book a 30-min call
← cd ../blogs
$ cat posts/eu-ai-act-the-deadline-moved.mdx

The EU AI Act deadline moved: the engineering did not

August 7, 2026 · ImmovableTech Team

  • Compliance
  • Production AI

Sixteen extra months changed our plan by about a fortnight

On 27 July 2026, Regulation (EU) 2026/1744 — the Digital Omnibus on AI — entered into force and rewrote the AI Act’s timetable. Obligations for standalone high-risk systems under Article 6(2) and Annex III, which were due to bite on 2 August 2026, now apply from 2 December 2027. High-risk AI embedded in products already covered by EU harmonisation legislation, under Article 6(1) and Annex I, moves to 2 August 2028.

That is settled law rather than a proposal. The amending regulation was adopted on 8 July 2026, published in the Official Journal on 24 July and has applied since 27 July. We say so plainly because much of the writing from the first half of 2026 described these same dates as pending, and was right at the time: political agreement came on 7 May 2026 and the text did not become law until late July. Check whether any timeline you are reading predates the Official Journal.

We got roughly sixteen extra months on the part of the Act that requires the most engineering, and it moved our roadmap by about two weeks. That is the whole argument of this post. Nothing here is legal advice — we are describing what we build, not what you are obliged to do.

Three buckets, and you have to know which one you are in

The most common mistake we see is a team holding one mental “AI Act deadline”. There are three categories and they behave differently.

Already in force and being enforced. The prohibited practices and the AI literacy duty have applied since 2 February 2025. General-purpose AI model obligations have applied since 2 August 2025. On 2 August 2026 the AI Act reached its general application date, the AI Office and national authorities began enforcing, and the Article 50 transparency obligations started to apply. Non-compliance with Article 50 sits in the fine tier of up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher.

In force but with a later application date. The Chapter III requirements for high-risk systems — risk management, data governance, technical documentation, record-keeping, human oversight, accuracy and cybersecurity, conformity assessment, registration — are law today and apply from 2 December 2027 or 2 August 2028 depending on which classification route you are on. Two narrower dates are worth diarising: providers of generative systems already placed on the market before 2 August 2026 have until 2 December 2026 to meet the Article 50(2) marking obligation, and the new prohibition on systems generating non-consensual intimate material and child sexual abuse material applies from 2 December 2026.

Not settled yet. The supporting standards. CEN and CENELEC approved EN 18286, on quality management systems for AI Act regulatory purposes, in June 2026, and it has since been published — the first European standard developed to support the Act, aimed at the Article 17 quality management requirement. The Commission is expected to publish the reference to it in the Official Journal later in 2026. That last step is the one that counts: a harmonised standard confers a presumption of conformity only once its reference is cited in the Official Journal, so treating a published standard as a settled compliance route today is premature. The delayed availability of exactly these standards is the reason the Commission gave for moving the dates.

If a plan does not say which bucket each item is in, it is not a plan.

Classification is an architecture question

“Is our system high-risk?” gets treated as a question for the legal team. It is not. Article 6(2) points at Annex III, and Annex III is a list of application areas: recruitment and worker management, education and vocational training, creditworthiness assessment for natural persons, eligibility for essential public benefits, emergency call triage, biometrics, critical infrastructure, law enforcement, migration. Whether you land there is a function of what your system is pointed at and what its output is allowed to influence — which are architecture decisions someone on your team already made, possibly without noticing.

The uncomfortable version of this: an internal summarisation tool is not high-risk, right up until someone routes candidate CVs through it and pipes the summary into a shortlisting screen. Nothing about the model changed. The classification did.

Article 6(3) gives a derogation for Annex III systems that do not pose a significant risk of harm — narrow procedural tasks, improving a completed human activity, detecting deviations from prior decision patterns without replacing human review, or preparatory tasks. It has a hard edge: a system that performs profiling of natural persons is always high-risk regardless. And the derogation is not free. Under Article 6(4) the provider has to document that assessment before the system is placed on the market or put into service, and produce it on request from a national competent authority.

The practical output of a classification exercise is therefore a written architecture argument about what your system does and does not influence. We run it at design time and per integration rather than per system, because the integration is where the tier gets decided. It takes an afternoon and has twice made us change where a model output was allowed to flow.

Article 50 is a product feature, not a policy document

Article 50 has been enforceable since 2 August 2026 and applies regardless of risk tier. Read it as a spec.

Article 50(1) says providers must design systems intended to interact directly with natural persons so those people are informed they are interacting with an AI system, unless it is obvious to a reasonably well-informed, observant and circumspect person. Article 50(2) says providers of systems generating synthetic audio, image, video or text must mark the outputs in a machine-readable format, detectable as artificially generated or manipulated, with solutions that are effective, interoperable, robust and reliable as far as technically feasible. Article 50(4) puts a disclosure duty on deployers for deepfakes and for AI-generated text published to inform the public on matters of public interest. Article 50(5) requires the information to be clear and distinguishable, provided at the latest at the time of first interaction or exposure, and conforming to applicable accessibility requirements.

None of that is satisfied by a paragraph in a terms-of-service page. “At the latest at the time of first interaction” is a rendering requirement. “Machine-readable” and “interoperable” means an actual marking scheme in your generation pipeline, applied at the point of output, surviving whatever your CDN and image processing do downstream. “Accessibility requirements” means the disclosure has to work in a screen reader.

The Commission published guidelines on Article 50 on 20 July 2026 and has said compliance with the marking and labelling duties can be demonstrated through adherence to the Code of Practice on transparency of AI-generated content — with the explicit corollary that providers who do not adhere have to demonstrate compliance by alternative, equivalently adequate means. More than 180 organisations had signed that code by the time enforcement began. Whichever route you take, the artefact you produce is code.

Provenance you did not capture is gone

This is the part that is genuinely not a deadline problem, and the reason we did not slow down when the dates moved.

Article 10 requires that training, validation and testing data sets be subject to governance practices covering, among other things, data collection processes and the origin of the data, the original purpose of collection where personal data is involved, the preparation operations applied — annotation, labelling, cleaning, updating, enrichment, aggregation — and an examination for biases. Article 11 requires technical documentation drawn up before the system goes to market, containing at minimum the elements of Annex IV, kept up to date.

Every one of those is a question about the past. If you did not record which snapshot of which source produced the rows you trained on, you cannot answer it later. Not expensively — at all. A retrospective lineage exercise on a dataset assembled from ad-hoc extracts is archaeology, and it terminates in a document that says “we believe” rather than one that says “this is”.

We learned this on our own retrieval infrastructure rather than on a high-risk system, which was lucky. We were logging the final answer, a prompt hash and a latency figure. The index was rebuilt nightly, in place, unversioned. When we needed to reconstruct why a specific answer had come out the way it did six weeks earlier, we could not: the documents that produced it had been superseded and the retrieval set was unrecoverable. The fix was not hard — content-addressed index snapshots, with the snapshot ID recorded against each response — but it only fixed the future. Six weeks of history stayed unexplainable, and no budget was going to change that. The hallucination detection work we did later depends entirely on that provenance existing. Our streaming-first architecture with CDC into Iceberg was built for product reasons, and its table-level snapshot history has turned out to be the most useful compliance asset we own.

Logging that survives someone else reading it

Article 12 requires high-risk systems to technically allow automatic recording of events over the lifetime of the system, at a level of traceability appropriate to the intended purpose. Article 19 requires providers to keep those logs for a period appropriate to the intended purpose and at least six months. Article 26(6) puts the same at-least-six-months duty on deployers for logs under their control.

Six months of retention is the easy half. The hard half is that the record has to let a reader who was not there reconstruct a specific decision. Application logs almost never do. Ours did not — they were written for us, on the day, with the context in our heads.

What we settled on is a decision record written at inference time, separate from the application log, with everything needed to replay:

{
  "decision_id": "01K2E9...",
  "occurred_at": "2026-08-05T09:14:22.481Z",
  "system_version": "scoring-svc@4.2.1",
  "model_ref": "internal-registry://scoring/2026-06-18",
  "input_digest": "sha256:9f2c...",
  "retrieval_snapshot": "idx-2026-08-04T02:00Z",
  "features_used": ["tenure_months", "prior_outcome", "region"],
  "output": { "score": 0.62, "band": "review" },
  "threshold_config": "policy-2026-07-01",
  "human_review": { "required": true, "reviewer_id": null, "decision": null }
}

The two fields that cost the most to add were retrieval_snapshot and threshold_config, because both required something upstream to become versioned that had not been. They are also the two that answer the question an auditor, or an affected person, will actually ask: not “what did the model output” but “why that, then”. The human_review block exists because Article 14 requires human oversight measures, and an oversight process that leaves no trace of whether a human looked is indistinguishable from one that does not exist.

Most of this is what a competent team wants anyway

Strip the legal framing off the high-risk requirements and you get: know where your data came from, record how it was prepared, document what the system is for and what it is not for, keep evaluation records, log decisions so you can reconstruct them, and make sure a human can meaningfully intervene. We would argue for every one of those on a system with no regulatory exposure at all, and we have — the agentic systems we run in production needed most of it before the AI Act was relevant to any of them.

That is easy to say from a team with the headcount to do it. For a five-person company shipping into a regulated area the burden is real: conformity assessment, registration, a quality management system under Article 17, post-market monitoring. The Digital Omnibus extended the simplified technical documentation route from SMEs to small mid-cap companies and requires the Commission to provide a simplified form, but a simplified form is not the same as a small job.

The honest position is narrower than “you wanted this anyway”. It is: the subset of these requirements that is expensive to retrofit and cheap to build in from the start is large, and it is exactly the subset that a moved deadline tempts you to defer. Data lineage and decision logging cost close to nothing at design time and are sometimes impossible later. Conformity assessment costs what it costs, whenever you do it. Sequence accordingly.

What we’d do differently

We treated classification as a one-off. It should be a gate on integration changes, not a document produced once during a discovery phase. The Annex III question is settled by where an output flows, and outputs get rerouted by people who have never read Annex III. A design review checklist item is a better control than an annual review.

We should have separated the decision record from the application log from day one. We spent real effort deriving audit-grade records from structured application logs, on the theory that we already had the data. We did not. Application logs are sampled, rotated, tuned for volume and full of fields that made sense to whoever was debugging that week. We abandoned the derivation and rebuilt it as a separate append-only stream. The rebuild took about three weeks; the failed attempt took longer.

And we were slow to notice that Article 50 applies to systems that are not high-risk. Our planning was organised around the high-risk deadline, so transparency work sat behind it in the queue. That was backwards: Article 50 is what actually became enforceable in August 2026, and it lands on ordinary chatbots and generative features nobody had flagged as regulated. We caught it by reading the regulation rather than by our process.

References

We build auditable, production-grade AI systems as part of our AI & Machine Learning Engineering practice. Talk to us if you need data lineage and decision logging in place before a classification question forces the issue.