A board asked its CTO a simple-sounding question in the spring of 2026: “Are we ready for the AI Act?” The honest answer was three questions of its own. Ready as what — a provider of an AI system, or a deployer of someone else’s? Ready for which deadline, when one of them might be about to move? And ready in what sense — a binder of policies, or a pipeline that can actually show, on demand, what a model did and who signed it off? The teams that answered well were not the ones with the most legal memos. They were the ones whose delivery system could already produce the evidence the law was about to ask for.
A note on timing, written in June 2026: the regulatory picture is genuinely moving, and anything below should be read as the state of play now, not a settled timetable. The point of this piece is not legal advice — it is what an engineering organisation should build regardless of how the politics land.
What actually changes on 2 August 2026
The EU AI Act applies in phases. The prohibitions on unacceptable-risk uses already took effect in early 2025. From 2 August 2026 the next major tranche lands: the obligations on general-purpose AI models, the Act’s governance and enforcement powers, and — as originally scheduled — the duties for high-risk systems listed in Annex III. The complication is that, as of mid-2026, a proposed package known informally as the Digital Omnibus would defer the high-risk obligations (potentially into 2027) and simplify parts of the regime. So the safe planning assumption is this: the model-level and governance obligations are arriving now; the high-risk obligations are arriving — the only live question is exactly when.
| If you… | You are likely a… | Core duties that touch engineering |
|---|---|---|
| Train or substantially modify a model you offer to others | Provider (incl. of a general-purpose model) | Technical documentation, training-data summary, copyright policy, transparency |
| Build an AI system used in a high-risk domain (hiring, credit, essential services) | Provider of a high-risk system | Risk management, data governance, logging, human oversight, accuracy and robustness, conformity assessment |
| Deploy someone else’s AI system in your operations | Deployer | Human oversight, monitoring, keep logs, follow the instructions for use |
| Use AI to help write software internally | Generally out of scope as a regulated use | No specific Act duties — but the software you ship may itself be in scope |
That last row matters and is widely misread. Using AI to help write your code does not, by itself, place you under the Act — coding assistance is not a regulated high-risk use. The Act bites on what you ship and where it operates. The obligations arrive because the software you build is a high-risk AI system, or because you deploy one — not because your developers use an agent.
Why most of the obligations are already engineering work
Read the high-risk duties as an engineer rather than a lawyer and they stop looking alien. Nearly every one maps onto a delivery-assurance practice that is good engineering in its own right:
- Record-keeping and logging (Art. 12) → the audit trail for agentic delivery: who or what did what, when, on which version.
- Human oversight (Art. 14) → the human acceptance gate: a person accountable for accepting an AI-influenced decision, with the evidence to do it meaningfully.
- Risk management, accuracy and robustness → evals as the specification: a test harness that defines acceptable behaviour and runs on every change.
- Data governance and technical documentation → provenance: where data and artefacts came from, versioned and signed.
We have written about each of these as good practice in its own right — the audit trail, the human acceptance loop, evals as the spec, provenance engineering. The Act’s contribution is to make them non-optional for systems that matter, and to require that you can produce the evidence on demand, not merely assert it.
The law is, in the end, asking the question we already ask at every acceptance gate: can you show what the system did, and who took responsibility for letting it. If your pipeline can answer that on a normal Tuesday, the AI Act is mostly an exercise in writing down what you already do.
What to do now, before the dust settles
You do not need the final text of the Digital Omnibus to act, because the no-regrets moves are the same under every version of the timeline.
- Classify your systems by role and risk: for each AI system, are you provider or deployer, and does it operate in a high-risk domain? This single map drives everything else.
- Make the evidence a by-product of delivery: ensure logging, provenance and human sign-off are produced automatically by the pipeline, not assembled for an audit.
- Stand up evals as your accuracy-and-robustness story: a versioned test harness is both good engineering and your conformity evidence.
- Watch the Omnibus, but build to the stricter case: it is cheaper to relax a control you already have than to retrofit one under deadline.
The teams that treat the Act as a paperwork problem will spend 2026 producing documents. The teams that treat it as a delivery-assurance problem will spend 2026 building a pipeline that happens to be compliant — and is better engineering regardless of what Brussels finally decides. Build for the question underneath the law: show what the system did, and who was accountable for it.
Frequently asked
- What changes in the EU AI Act on 2 August 2026?
- The obligations on general-purpose AI models and the Act’s governance and enforcement powers take effect, and — as originally scheduled — the duties for high-risk systems in Annex III. As of mid-2026 a proposed “Digital Omnibus” may defer the high-risk obligations into 2027, so the model-level and governance duties are the firm part of the date; the high-risk timing is in flux.
- Does using an AI coding assistant put my team under the AI Act?
- Generally no. Using AI to help write software is not a regulated high-risk use in itself. The Act applies based on what you ship and where it operates — so obligations arise if the software you build is a high-risk AI system or you deploy one, not because your developers use a copilot.
- Am I a “provider” or a “deployer”?
- You are a provider if you develop an AI system (or substantially modify one) and put it on the market under your name; you are a deployer if you use an AI system someone else provides. Providers of high-risk systems carry the heavier duties — risk management, documentation, conformity assessment — while deployers must ensure human oversight, monitoring and logging.
- How do we prepare without the final rules?
- Act on the no-regrets moves: classify each AI system by role and risk, make logging, provenance and human sign-off automatic by-products of your pipeline, and stand up evals as your accuracy-and-robustness evidence. These are required under every version of the timeline and are good engineering regardless.