This article covers a fast-moving regulatory area. The EU AI Act and Digital Omnibus dates below reflect the position as of August 12, 2026 — the timeline has already shifted twice in the preceding three months and is worth re-checking against a primary source before you act on it.

The AI Act was delayed. That is not what most people think it means.

If you read one headline about AI regulation this year, it was probably that the EU delayed the AI Act. A lot of teams filed that under "not urgent until 2027" and moved on.

That reading is half right and expensive.

Here is what actually happened. The European Commission proposed the Digital Omnibus on AI on 19 November 2025, after it became clear the compliance ecosystem wasn't ready — harmonised standards from CEN-CENELEC were behind, Commission guidelines were still in draft, and many member states hadn't designated or resourced their market surveillance authorities. Political agreement followed on 7 May 2026, the Parliament endorsed it on 16 June by 423 votes to 57, the Council gave final approval on 29 June, and it entered into force on 27 July 2026.

The delay is real and substantial. High-risk obligations for standalone Annex III systems — hiring tools, credit scoring, biometric identification and similar — moved from 2 August 2026 to 2 December 2027. High-risk AI embedded in regulated products under Annex I moved to 2 August 2028.

But the delay is narrow, and this is the part that got lost:

Article 50 transparency obligations took effect on 2 August 2026. Ten days ago. Telling users they are interacting with an AI system. Labelling synthetic content. These did not move. The Article 4 AI literacy duty did not move either. And there's a second wave on 2 December 2026: Article 50(2) transparency requirements extend to systems already on the market before August, and new prohibitions — including on AI-generated non-consensual intimate imagery and CSAM — take effect.

So the position for anyone shipping AI into the EU market is: the heavy conformity-assessment regime bought you sixteen months, and the transparency obligations are live now.

That gap between what people heard and what actually applies is a good illustration of the wider problem with responsible AI. It gets treated as a compliance calendar to be managed rather than an engineering practice to be built — and calendars are exactly the thing that changes underneath you.

The three frameworks, and what each is actually for

Most teams encounter three names and aren't told how they relate. They are not competitors; they do different jobs.

The EU AI Act is law. Binding, risk-tiered, extraterritorial in effect if you serve the EU market. It tells you what you must do for a given risk classification. It does not tell you how to build an organisation capable of doing it.

The NIST AI Risk Management Framework is a method. Voluntary, published January 2023, structured around four functions — Govern, Map, Measure, Manage — with a Playbook of practical guidance and a Generative AI Profile added later. There's no certification and no auditor. It's free, and it's the fastest way to get a shared vocabulary and a lifecycle discipline into an engineering team.

ISO/IEC 42001 is a management system, and it's certifiable. It uses the familiar ISO clause structure and trades ISO 27001's 93 information security controls for 38 AI-specific ones. Crucially, it produces a certificate — third-party assurance you can hand to a procurement team.

The practical distinction is who you're talking to. NIST is the path to a self-attestation document. ISO 42001 is the path to a certificate. Lead with NIST when your audience is your own engineers and you want internal risk discipline first. Lead with ISO 42001 when your audience is procurement, customers or regulators wanting third-party proof — and especially if you already hold ISO 27001 or 9001, where the harmonised structure makes 42001 a much smaller delta than starting from scratch.

The good news is that they converge rather than conflict. Published crosswalks show substantial overlap, and one workable sequence is: use ISO 42001's management system structure as the skeleton, NIST's four functions as the risk methodology inside it, and layer the AI Act's prescriptive obligations on top for anything high-risk. A commonly cited rough shape for a moderately complex organisation is a few months for NIST adoption, a few more to reach ISO certification, and a similar block again for AI Act work — call it most of a year end to end, though this varies enormously and is the sort of estimate to treat as directional rather than plannable.

One caution about relying on frameworks as legal cover. Colorado's original 2024 AI Act offered an affirmative defence for organisations demonstrating compliance with NIST AI RMF or ISO 42001. That law was repealed and replaced by SB 26-189 before it ever took effect, and the safe harbour did not survive into the new statute. Frameworks remain excellent backbones for the documentation and disclosure duties that follow. They are not a shield you can assume will be there.

The gap the frameworks don't close

Here is the number that should shape how you read all of this. Vanta's State of Trust research found that while 79% of businesses are using or planning to use agentic AI, only 48% have a framework in place to govern and limit its autonomy.

79% of businesses are using or planning to use agentic AI. Only 48% have a framework in place to govern and limit its autonomy. That gap is where the actual risk sits.

That gap isn't primarily a legal gap. An agent that can act — call tools, write to systems, send messages, move money — introduces failure modes that a classification exercise doesn't touch. Singapore published the first agentic-specific governance framework in January 2026, which tells you how new this territory is: the major frameworks were written for AI systems that produce outputs, not for systems that take actions.

If you're deploying agents, the questions that matter are ones no compliance calendar asks:

  • What is this system permitted to do, and what is it architecturally prevented from doing?
  • When it takes an action, is there a record of what it did and why?
  • What happens when it's wrong — who finds out, how fast, and what can be reversed?
  • Who is accountable for its behaviour by name?

Those are engineering questions. Which brings us to the argument I actually want to make.

Governance is mostly the same work as reliability

The framing that makes responsible AI feel like a tax is that it's a separate workstream — safety people doing safety things, adjacent to the team shipping the product.

In practice, almost everything on a governance checklist is something you need anyway to run a system you can trust in production.

Evaluation sets. Governance frameworks want evidence your system performs as claimed. Engineering wants to know whether a change made things better or worse. It's the same artefact: a scored set of real cases with known-correct outcomes. Without one you can neither prove compliance nor ship confidently, and teams that skip it end up guessing at both.

Logging and traceability. Regulators want to know what the system did and on what basis. Your on-call engineer wants exactly the same thing at 3am. Trace every decision, every tool call, every input that influenced an output — and you have satisfied an audit requirement and a debugging requirement with one piece of work.

Human oversight. The frameworks ask where a person can intervene. Good system design asks the same question, because a system with no escalation path fails badly the first time it meets a case it can't handle. Confidence thresholds, escalation routes and approval gates on consequential actions are reliability engineering that happens to also be compliance.

Documented scope. "What is this system for, and what is it not for" appears in every framework. It's also the single most useful thing to write down for the engineer who inherits the system in eighteen months.

Change control. Version your prompts, your models, your tool definitions and your evaluation results. Required for auditability, and the only way to answer "what changed?" when quality drops.

Data provenance. Where the training or retrieval data came from and on what basis you hold it. A legal question and a debugging question — most retrieval quality problems are provenance problems in disguise.

Roughly four of five items on a governance checklist are things a careful team builds regardless. The work isn't additional. What's additional is writing it down in a form someone else can inspect — and that overhead is small compared to building the capability itself.

Which suggests a better sequencing than most teams use. Don't start with the regulation and work backwards to engineering. Start with the engineering practices that make a system reliable, then document them into whichever framework your buyers and regulators need. Teams that do it in that order find the certification work substantially easier, because the evidence already exists — they just have to organise it.

Transparency: what it actually requires

Since Article 50 is the obligation that's live now, it's worth being concrete about what transparency means in practice, because it's frequently reduced to a disclaimer in a footer.

Disclosure that people actually receive. The requirement is that users know they're interacting with an AI system. A line in the terms of service is not disclosure. Disclosure is at the point of interaction, in language a normal person parses, before they've told the system something they'd not have told a machine.

Synthetic content labelling. Where content is AI-generated or manipulated, it needs marking. This is straightforward for images and audio and messier for text, where a partially-generated document raises questions the guidance doesn't fully resolve. Decide your policy deliberately rather than by default.

Explaining decisions, not architecture. Nobody affected by an automated decision benefits from a model card. They benefit from knowing what information was used, what the outcome was, and how to contest it. Explainability that serves the affected person is different from explainability that serves your engineers, and most teams build only the second.

Honest capability description. The most commonly breached transparency principle isn't legal — it's marketing. Gartner's assessment of the agentic market found that of thousands of vendors claiming agentic capabilities, only around 130 were building the real thing, with the rest rebranding chatbots and RPA — the same agent-washing problem that distorts AI roadmaps also shows up here, aimed at buyers rather than users. If your marketing describes a system your engineering doesn't ship, no compliance programme fixes that.

Stated limitations. What the system does badly, where it should not be relied on, and what it can't see. Publishing limitations feels like weakness and reads as competence — and it's the thing that protects you when something goes wrong, because you told them.

What to actually do, in order

For a team shipping AI into production now, without a governance function and without the appetite to build one:

  1. Classify what you have. For each AI system: what it does, what it can act on, who it affects, and whether any use touches a high-risk category under the AI Act or an equivalent regime where you operate. Most teams have never written this list down, and writing it down is where the surprises surface.
  2. Handle the transparency obligations that are live. Disclosure at the point of interaction, synthetic content labelling, and the AI literacy duty for staff. These apply now, not in 2027.
  3. Build the evaluation set. Real cases, known-correct outcomes, scored. This is the highest-leverage single artefact in the entire practice — it serves compliance, quality, debugging and procurement simultaneously.
  4. Instrument for traceability. Log decisions, inputs, tool calls and outputs, with retention you can defend. Do it before you need it, because retrofitting traces onto a live system is painful and partial.
  5. Define the boundaries architecturally. What the system may do, enforced by permissions and gates rather than by instructions in a prompt. Irreversible actions behind human approval by default.
  6. Name an accountable owner. A person, not a committee. Frameworks call this governance; in practice it's the difference between something being someone's job and being everyone's concern.
  7. Adopt NIST's four functions as vocabulary. Free, fast, and it gives your team a shared way to talk about risk without a consultant.
  8. Decide whether you need a certificate. If procurement teams are asking, ISO 42001 has real commercial value and your NIST work feeds directly into it. If nobody is asking, don't buy a certificate to feel governed.
  9. Set a review cadence. The regulatory position moved twice in three months this year. Anything you write down now needs revisiting on a schedule, not when someone remembers.

The uncomfortable conclusion

Responsible AI has an image problem, and it's partly self-inflicted. Presented as ethics-committee work, it invites teams to treat it as something to be survived rather than built.

The version that survives contact with a real deployment is unglamorous: know what your systems do, measure whether they work, log what happened, define what they may not touch, tell people the truth about them, and put a name against each one.

That list makes systems more reliable, easier to debug, easier to sell to a security-conscious buyer, and — almost incidentally — compliant with most of what the frameworks ask. The teams doing it well mostly aren't doing it because a regulation told them to. They're doing it because a system nobody can explain, measure or reverse is a system nobody should be running.

The sixteen-month delay is real. It is not time off. It's the window in which the ecosystem catches up and expectations harden — and the teams that use it to build the practice will find December 2027 an administrative exercise rather than an emergency.

Sources: European Commission Digital Omnibus on AI; EU AI Act (Regulation 2024/1689) and its Article 50 transparency obligations; NIST AI Risk Management Framework; ISO/IEC 42001; Vanta, "State of Trust Report 2025"; Gartner press release, 25 June 2025. General information, not legal advice.

Shipping AI into production and not sure where governance actually bites? Get in touch.