Regulators Are Asking a Runtime Question

Across Europe and the Gulf, supervisors have stopped asking to see the policy and started asking for the proof. Almost every obligation now arriving describes something that can only be true while a system is running — and the market has answered it with documents.

Something changed in the last eighteen months, and most AI governance programmes have not caught up to it.

When DORA became fully applicable in January 2025, the first wave of work was documentary: registers of information, contractual clauses, exit strategies, third-party inventories. By 2026, supervisors across the EU had moved past the paperwork. National competent authorities are now examining how firms actually manage incidents, oversee providers and operate under real conditions — not whether the policy binder is complete. In Belgium, the first NIS2 enforcement deadline required essential entities to submit documentation verified by an accredited body or the national cybersecurity centre. Self-declarations were not accepted.

That is the shift. Not more rules. A different kind of question.

The old question was: do you have a policy governing this? The new one is: show me what actually happened, and show me that it matched what you said would happen.

Almost nothing in the AI governance market answers the second question.

The deferral changed the date, not the obligation

The most-reported regulatory event of this year was the EU's Digital Omnibus on AI, given final approval by the Council at the end of June. High-risk obligations for stand-alone Annex III systems moved from 2 August 2026 to 2 December 2027; for AI embedded in regulated products under Annex I, to 2 August 2028. The Article 50 transparency obligations did not move.

The headline was read as a reprieve. It isn't one, and reading it that way is a strategic error.

Look at what the deferred obligations actually require. Article 12 requires that high-risk systems automatically record events across their lifetime. Article 14 requires human oversight — including the ability of a designated person to intervene in, or interrupt, the operation of the system. Article 26 puts duties on the deployer, the organisation actually running the thing, including retention of the logs it generates.

Every one of those is a runtime property. A system either records what it did as it did it, or it doesn't. A human either can interrupt an action before it completes, or the oversight is theatre. You cannot satisfy Article 14 with a governance committee. You cannot satisfy Article 12 with a policy document that says logging is enabled.

Sixteen extra months is time to build that. It is not permission to keep writing about it.

The same structure repeats everywhere I look.

DORA requires threat-led penetration testing on live production systems and an incident reporting cascade measured in hours. The register of information describes your contractual arrangements; the obligation is about what your systems do when something goes wrong at three in the morning. Since the European Supervisory Authorities designated the first critical ICT third-party providers in November 2025, the concentration question has become concrete: not have you documented the dependency, but can you demonstrate control when that dependency fails.

NIS2 is now transposed in the large majority of member states, with enforcement active and the first fines issued. Article 21 sets baseline risk-management measures, incident reporting carries a 24-hour early warning, and management bodies carry personal liability for gross negligence. Liability is the tell. You do not attach personal liability to a document.

In the Gulf, the direction is the same and the timeline is shorter. Saudi Arabia's National Cybersecurity Authority has a draft set of AI cybersecurity guidelines out for consultation this summer that speaks directly to generative and agentic AI — systems capable of acting independently. SDAIA consulted in the spring on a draft Responsible AI Policy that tiers systems by risk and attaches proportionate obligations for testing, monitoring and documentation. Those sit alongside PDPL and the NCA's existing controls, and beneath them sit sector regulators. In the UAE, DIFC's AI-specific Regulation 10 has been in force since January, PDPL applies onshore, and the Cabinet has approved a framework to deploy agentic AI across half of all government services within two years. In Türkiye there is still no standalone AI statute; KVKK remains the operative rulebook, supplemented by a generative AI guide issued in late 2025, and the national direction emphasises keeping critical AI infrastructure under domestic jurisdiction.

Different instruments, different legal traditions, different levels of maturity. One shared property: the obligations describe behaviour at the moment of action.

And the standards bodies are arriving at the same place from the technical side. NIST's National Cybersecurity Center of Excellence published a concept paper in February on identity and authorization for software and AI agents — an explicit acknowledgement that the existing frameworks do not answer how you authorize an agent to act. In December, CISA and allied agencies issued joint guidance on securing agentic AI in operational technology.

Everyone is converging on the same unanswered question. Nobody is converging on an answer.

Why the market answered with documents

I want to be fair about this, because the documentary response was not laziness.

When the first wave of AI regulation arrived, the buildable artifacts were documents. Model registries. AI inventories. Impact assessments. Data protection assessments. Vendor questionnaires. Policy libraries. A whole category of AI governance platforms grew up to produce them well, and they do produce them well. If you need to demonstrate that you know which systems you operate, who owns them, what risk tier they sit in and what your stated controls are, that market serves you.

It is genuinely necessary work. Article 26 does require the deployer to know what it is deploying. ISO/IEC 42001 does require a management system. None of that is wasted.

But every one of those artifacts describes intended behaviour. It is a statement about what the organisation means to do. Regulators accepted that as a proxy for a while because nothing better existed and because the systems being governed were slow enough for periodic review to be meaningful.

Autonomous systems broke the proxy. When an agent chains twenty tool calls in four seconds, decides which arguments to pass, delegates a subtask to another agent and touches a production system at the end of it, the gap between intended behaviour and actual behaviour is no longer a rounding error. It is the entire risk surface. And it opens and closes faster than any review cycle can observe.

Three questions a document cannot answer

Strip away the framework-specific language and the same three questions sit underneath the EU AI Act, DORA, NIS2, the NCA's draft guidelines and every serious supervisory conversation I have had in the last year.

Was this specific action permitted, for this principal, on this resource, at the moment it happened? Not: is there a policy covering this class of action. Was this one authorized, under a policy version you can name, at a timestamp you can produce.

Did what executed match what was approved? This is the question almost nobody can answer. An approval was given for a transaction. Something then executed. Were they the same thing? If the arguments changed between the decision and the execution — if the amount, the destination, the record set moved — does anything in your stack know?

Can someone other than you verify the answer? A regulator, an auditor, a customer's security team. If the only evidence is a log written by the system that took the action, and that system is also the system you are asking them to trust, you have not produced evidence. You have produced an assertion.

Traditional logging fails all three. A log is a reconstruction written about an action after the fact. SIEM correlates those traces at human timescales, which is the wrong timescale, and it is fundamentally investigative — it helps you understand what happened after the payment left. It cannot stop the payment.

The obligations live at runtime, so the control has to as well

This is why we build what we build.

Governed execution means carrying out an action under the exact policy and scope that authorized it, while producing its own evidence. Not deciding, then hoping the agent complies. Not executing, then reconstructing a record of what probably happened.

Concretely: an agent doesn't hold the credential that reaches the protected system. A request becomes a canonical action request, evaluated against a signed mandate and current context. When it's allowed, the system issues a short-lived permit bound to that exact action and that exact set of arguments — so a permit approved for one transaction cannot execute a different one. Execution happens through an enforcement point the agent cannot route around. The evidence record is created as part of execution, signed under a key the customer controls, and verifiable by someone who has no access to our systems at all.

Map that back to the three questions. Was it permitted? The policy version and the decision are in the record. Did execution match approval? The permit is bound to the argument digest; a mutated argument fails validation. Can an outsider verify? The evidence is signed under the customer's trust chain, not ours.

That is what a runtime answer looks like. It is not a better document.

The Gulf makes this concrete faster than anywhere else

There is a reason this argument lands differently in Abu Dhabi and Riyadh than it does in Brussels.

Europe is regulating AI that is largely being deployed by private enterprises at a pace those enterprises choose. The Gulf is deploying autonomous systems into government services on a published timetable, at national scale, as a matter of state policy — while simultaneously writing the rules that govern them. When a state commits to agentic AI across half of its public services within two years, the question of what authorizes each action, and who can prove it afterwards, stops being a compliance exercise and becomes an operating requirement.

It adds a second dimension too. In a sovereign deployment, "verifiable" has to mean verifiable under national trust roots, in jurisdiction, without dependency on a foreign vendor's continued availability or goodwill. Evidence signed by a key you do not hold, stored in a system you cannot operate independently, is not sovereign evidence — whatever the data residency clause says. That is a hosting arrangement with a compliance narrative attached.

What runtime governance does not do

I want to be precise here, because overclaiming in this territory is both easy and corrosive.

Runtime evidence supports a management system. It does not create compliance. Compliance is an organisational outcome involving people, process, legal interpretation, system classification and scope decisions that no platform makes for you. A control plane can supply technical controls and verifiable records that map to obligations under the AI Act, DORA, NIS2, ISO/IEC 42001, the NCA controls or PDPL. It cannot tell you whether you are a provider or a deployer, whether your system is Annex III, or whether your legal basis holds.

Nor does governed execution make an action correct. It makes the action authorized, bounded, and provable. An agent operating entirely within its mandate can still do something commercially foolish. That is a different problem, and anyone who tells you their platform solves it is selling you something.

What it does do is close the gap between what your governance documents say and what your infrastructure actually does — which is precisely the gap supervisors have started to probe.

Questions worth asking your vendors

If you are accountable for any of these obligations, these are the questions I would put to anyone selling you AI governance — including us.

Which of your controls operate at the moment of action, and which operate before or after it?

When your system returns an authorization decision, what makes that decision unavoidable? Can the requesting system reach the target another way?

Can you demonstrate that the arguments which executed are the arguments that were approved?

Who holds the key that signs your evidence?

Can a third party validate an evidence record without access to your vendor's infrastructure?

What happens to enforcement and to evidence during a network partition, or if the vendor becomes unavailable?

Which systems in scope can still be reached with a standing credential or a direct network route?

Question seven is the one I would ask first. Every architecture claim in this space is only as strong as the answer to it, and it is the question that most demonstrations quietly avoid.

The deferral bought sixteen months. Used well, that is enough time to build the runtime layer these obligations describe. Used as relief, it is sixteen months closer to a supervisory conversation nobody is ready for.

Regulators are asking a runtime question. It deserves a runtime answer.

Own your runtime. Govern your future.

---

This article is commentary, not legal advice. Regulatory positions are described as at July 2026 and timelines in this area move — the EU high-risk deadlines have already moved once. Organisations should confirm their obligations, classification and applicable deadlines with qualified counsel in each jurisdiction.