The EU AI Act Was Written for Models. Your Agents Need Runtime Compliance

What actually changed in June, and what did not

On 16 June 2026 the European Parliament formally endorsed the Digital Omnibus AI simplification package; the Council gave final approval on 29 June. If you read the headlines as “the AI Act got easier,” you read them right — the deadlines moved, the documentation burden was trimmed, and relief for smaller firms was widened. But if you read them as “the AI Act now covers what my agent does in production,” you read them wrong.

Here is the substance, kept to what is settled. The application dates for high-risk systems were extended — to 2 December 2027 for stand-alone high-risk AI systems and 2 August 2028 for high-risk systems embedded in regulated products. The transparency grace period for marking artificially generated content was compressed from six months to three (deadline 2 December 2026). Prohibitions on the worst-case content categories were confirmed. And the simplified-compliance track for SMEs was widened toward larger mid-caps. Useful, real, and worth planning around.

But notice the shape of every one of those obligations. They attach to a provider, and they attach at the point of placing a system on the market. Conformity assessment, technical documentation, risk-management files, data governance, intended-purpose declarations — these describe and certify an artefact. The Omnibus rescheduled and streamlined that certification. It did not move the point of control any closer to the moment an agent actually acts.

Certification is a snapshot. An agent is a stream.

A conformity assessment evaluates a system as it stands at a moment in time: its documentation, its guardrails, its intended use. That is a reasonable thing to certify for a model, because a model is a relatively fixed artefact. You can inspect it, test it, and sign off on it.

An agent is not that. An agent is a loop that takes fresh input — a customer email, a web page, a ticket, a tool result — and decides what to do next. Much of that input is untrusted, and some of it is authored by someone who wants the agent to misbehave. The certified artefact and the running agent are related, but they are not the same thing, and no amount of pre-market paperwork evaluates the decision the agent has not made yet.

So you can hold a valid conformity assessment and still, in production, watch your agent wire a payment it should have held, email data across a trust boundary, delete a record on a misread instruction, or call a tool that was never supposed to be reachable from that context. The certificate was honest. It just answered a different question.

Runtime compliance is the missing layer

Runtime compliance is the discipline of enforcing your policy at the moment of action, not at the moment of certification. It does not compete with the AI Act — it sits underneath it, in the place the Act cannot reach. Where a conformity assessment asks “is this system, as built, fit to place on the market?”, runtime compliance asks a narrower and more operational question, over and over: “is this specific action, right now, allowed?”

The only way to answer that reliably is with deterministic code in front of the action — a pre-execution gate the model cannot argue its way past. The model proposes; the gate disposes. If a proposed action crosses a policy line, the gate blocks it before it executes, regardless of how convincingly the input talked the model into it.

# pip install constitutional-agent
from constitutional_agent import Constitution

constitution = Constitution.from_defaults()

async def guarded_action(action, ctx):
    """Evaluate the decision at runtime, not at certification time."""
    decision = constitution.evaluate({
        # Was this turn shaped by untrusted input?
        "failing_tests": ctx.get("untrusted_input_present", 0),
        # How consequential / sensitive is the action?
        "proposed_spend": action.impact_score,
        "approved_budget": ctx.get("approved_impact", 0),
        # Is it reaching outside the sanctioned scope?
        "gate_override_without_amendment": action.is_out_of_scope,
    })

    if decision.system_state.value == "FREEZE":
        # Policy line crossed at runtime -> do not execute.
        return Blocked(reason=decision.gate_results)

    return await action.execute()

That is the whole idea. The certificate says the system is fit to ship. The gate says this action, in this context, may proceed — and it says it every single time, deterministically, in code you own. One is compliance as a document. The other is compliance as behaviour.

The Omnibus changed when you have to certify your model. It did nothing about the moment your agent decides to act. Only a runtime gate governs that moment — and that moment is where the risk actually lives.

Why this matters now, not in 2028

It is tempting to read the extended deadlines as breathing room and put agent governance on the same 2027–28 calendar. That is the wrong lesson. The deadlines that moved are the ones for certifying the artefact. The risk that did not move — the risk of a deployed agent taking an action it should not — is live the day you put an agent in front of real inputs, which for most teams is already.

Runtime compliance is also what a regulator, an auditor, or an incident review will eventually ask you to demonstrate: not just that your model was certified, but that you can show, per action, what was permitted and why. A deterministic gate produces exactly that record as a side effect of doing its job. Certification proves diligence about the system. The gate proves control over its behaviour.