Where AI governance came from

On 2 August 2026 the AI Act’s transparency obligations began to apply. The obligations most teams had spent two years preparing for, the ones that attach to high-risk systems, did not. Six days earlier, Regulation (EU) 2026/1744 had moved those to December 2027 and August 2028.

If you run the traffic and colleagues have started forwarding you links to that regulation, this is the background everyone assumed you already had. It names no product.

The difference between the obligations that moved and the one that stayed is not a legal difference, and it got less attention than it deserved. It takes a detour through where this discipline came from, because almost nothing in it was invented for the AI you are running now.

Where it came from

On 4 April 2011 the Federal Reserve and the Office of the Comptroller of the Currency issued supervisory guidance on model risk management, and handed the industry its vocabulary. A model inventory. Validation by people independent of the developers. Effective challenge, meaning criticism by someone competent enough to be inconvenient. Ongoing monitoring, periodic review, and a policy naming who owns each. It was written about credit and capital models: things a bank built, or bought and could take apart.

A second lineage arrived from research organisations around 2018 as responsible-AI review, and brought the impact assessment, the fairness test and the committee that meets before launch. A third came from GRC, which had already spent two decades turning obligations into controls with owners and evidence, and absorbed the other two because the shape fit.

All three govern an artifact: a thing that gets built, assessed, approved, deployed, and then watched.

What a programme contains

Six parts, and different people own them.

An inventory of AI systems, which is a spreadsheet more often than it is a system. A classification for each entry, deciding what it could do to a person and which regime it falls under. A policy saying what is allowed. A set of controls, which are named requirements with owners and identifiers like AI-07. Evidence that each control operated, collected into a binder. And a review cycle, plus a trigger for material change.

An engineer usually meets this twice. Once at classification, as a questionnaire about a system she is still building, and once at evidence, as a request for logs covering a quarter that has already happened. Everything in between lives in documents she never sees, so the programme often arrives as a surprise.

What the frameworks oblige

NIST’s framework, ISO/IEC 42001 and the AI Act do most of the work, and they oblige you differently.

NIST’s AI Risk Management Framework, released on 26 January 2023, is voluntary and cannot be certified against. Its four functions are govern, map, measure and manage, and they are where a lot of internal policy language comes from. Nobody audits you to it.

ISO/IEC 42001:2023 is a management system standard, and the one you can hold a certificate for. Its requirements run through clauses 4 to 10 in the usual shape: context, leadership, planning, support, operation, evaluation, improvement. Certification means a stage 1 and stage 2 audit and someone returning annually for the life of the certificate. It assesses whether your management system works, not whether any particular model is good.

The AI Act binds. It sorts systems into prohibited, high-risk, systems with transparency obligations, and everything else, and the high-risk tier is where the weight sits: a risk management system, data governance, technical documentation, record-keeping, human oversight, conformity assessment before the system goes on the market, and registration in an EU database.

Those are the obligations that moved to 2027 and 2028.

The obligations describe systems

Consider what did not move. Article 50 requires that people are told when they are interacting with an AI system, and that providers of systems generating synthetic audio, image, video or text “ensure that the outputs of the AI system are marked in a machine-readable format and detectable as artificially generated or manipulated”. Whether it binds you as a provider or a deployer is a question for a lawyer. The shape of it does not change with the answer. It is discharged at the moment a person meets the output, and no version of it can be satisfied in a binder.

A conformity assessment can be deferred by sixteen months because it is a piece of work about an artifact, and the artifact will still be there. A disclosure at the moment of use cannot be deferred in the same way, because there is nothing to defer it to.

The second document has the same shape from the other side of the Atlantic. On 17 April 2026 the Federal Reserve, the OCC and the FDIC issued revised guidance on model risk management, superseding the 2011 letter after fifteen years. Footnote 3 reads: “Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance.” The section on vendor products still asks a bank to develop “an understanding of the vendor model, including its conceptual soundness, design, development data, and performance”, two paragraphs after acknowledging that the bank may never receive the code, the data or the methodology.

Neither of those is bad drafting. Both are the honest position of a discipline built to validate a model you can take apart, now meeting a model you rent by the token.

Follow that through your own programme and the same crack opens at every step. The inventory has an entry, and the entry names a vendor. The classification describes a use case rather than a system. The documentation covers weights nobody at your company has seen, behind a model name that was silently repointed last Tuesday. The gate before deployment held once, in March, and the agent picked which tool to call this morning. Everything the programme knows was true at review time, and what goes wrong happens in a request nobody has made yet.

The unit of risk moved from the system to the call. The frameworks are still describing systems, and the two documents above show what that costs.

Data protection

One regime never described the system at all. Data protection law has regulated flows of personal data since long before any of this, and it has no artifact to inspect. It attaches to a disclosure, at the moment the disclosure is made, whoever built the thing that made it.

So it needed no deferral. Saudi Arabia’s Personal Data Protection Law reached the end of its transition period on 14 September 2024, and SDAIA’s regulation on transferring personal data outside the Kingdom asks for an adequacy finding or approved safeguards, with a risk assessment before the transfer is made. The GDPR has said something structurally similar since 2018. A prompt sent to a hosted model is a disclosure of whatever it contains to a processor, usually across a border, and that obligation attached the first time one of your applications did it, without waiting for anybody’s assessment.

So the first AI control most organisations have to operate is a data protection control, and it is live now, not in December 2027. It has the same shape as Article 50. No document satisfies it after the fact, because the transfer has already happened.

If your AI is a feature you bought

Then most of this is not your problem in the way this series means it. If AI at your company is a vendor’s product with a summarise button, the risk lives in the contract, the data processing terms and the list of who has an account. Procurement, a DPIA and an access review answer that, and no gateway helps. The rest of this series is for organisations whose own applications make the calls.

The gap

A programme can decide what should be true. An auditor can ask, afterwards, whether it was. Between those two something has to make it true while the request is in flight, and none of the documents above says what that thing is or where it runs.

All posts