Last month I wrote about the Instagram takeovers, where attackers talked Meta's AI support bot into handing over accounts because the bot had the authority to change account recovery and no rule about who it would do it for. The argument was simple. An agent with a powerful capability and no guardrail is not a feature, it is a social-engineering target with API access. Capability is easy. Governance is the part everyone skips.
A few weeks later, the European Union published the same argument as law.
On May 19 the Commission released draft guidelines on which AI systems count as high-risk under the AI Act, with a consultation running to June 23. Read past the bureaucratic surface and the high-risk requirements are a description of exactly the governance the Instagram bot did not have. Article 12 wants record-keeping and traceability, the ability to reconstruct what the system did. Article 14 wants human oversight, a person in the loop for consequential actions. Article 15 wants accuracy, robustness, and cybersecurity. That is not a compliance abstraction. It is the post-incident review of every ungoverned agent, written as a checklist before the incident instead of after.
So the regulation caught up to the engineering. Good. Here is where it goes wrong.
The compliance theater trap
The moment a regulation lands, an industry forms around making it go away cheaply. For the AI Act that industry is already selling governance binders: policy templates, classification questionnaires, a PDF that says you have a risk management system, a slide that says human oversight. Buy the bundle, file it, move on.
The problem is a category error. The AI Act's high-risk requirements are not document properties. They are runtime properties. They describe what the system does at the moment it acts, not what a folder says about it.
You cannot satisfy traceability with a Word document. Traceability is whether your system actually logged the action, immutably, in a way you can produce later. You cannot satisfy human oversight with a policy that says a human is involved. Oversight is whether the system actually stopped and waited for a person before it did the irreversible thing. You cannot satisfy robustness with an attestation. It is whether the thing holds when someone pushes on it.
A binder is not a control. It is a description of a control that may or may not exist. The Instagram bot's operator could have had a beautiful binder. The binder would not have sent that one-time code to the attacker any less.
If you build agents, this is you
There is a comfortable assumption among people building on top of foundation models that the AI Act is someone else's problem, a thing for the labs. It is not.
If you wire an agent on top of a model and ship it, you are a deployer under the Act. Whether you carry the heavy obligations depends on what the agent does. Land in one of the high-risk categories, hiring, credit scoring, critical infrastructure, and the full weight applies. Modify the model substantially through heavy fine-tuning and you can be reclassified as a provider, with more. The line between deployer and provider is genuinely murky right now, which is part of why the Commission is publishing guidelines and asking for feedback at all. And the Act reaches you wherever you sit. It applies to any system that touches people in the EU, regardless of where your company is. The penalties at the high-risk tier run to tens of millions of euros or a slice of global turnover, which is not a number a small team litigates its way around.
But forget the penalty for a second, because it is the least interesting reason to care. The controls the Act asks for, traceability, oversight, robustness, are the exact controls that stop your agent from becoming the next Instagram story. They are what you would build anyway if you were honest about what an autonomous system with real capabilities can do, and your classification is not frozen, it changes as your product does. The regulation is not asking you to bolt on paperwork. It is asking you to be able to answer, at runtime, what is this agent allowed to do, did a human approve the dangerous parts, and can you prove what happened. If you cannot answer those, you do not have a compliance problem. You have an engineering problem that compliance noticed.
The delay is runway, not reprieve
Here is the part that will be misread. The Digital Omnibus, agreed in May, pushed the high-risk deadlines back: standalone systems to December 2027, systems embedded in products to August 2028. Cue the exhale, the "we have years" shrug, the quiet deprioritization.
That is the wrong read. The deadline moved. The exposure did not. Every month you run an agent with real capabilities and no runtime governance is a month you are one clever prompt away from the failure the Act exists to prevent, deadline or no deadline. Prohibited practices and the rules for general-purpose models are already in force. Enforcement powers switch on this August. And the controls take real time to build, which is the actual reason the deadline moved, not a gift of idleness but an admission that doing this properly is not a weekend of paperwork.
Treat the runway as what it is. Time to build the controls before you are forced to, while the cost of getting it wrong is still just your users and not also a regulator.
What to actually build
The same thing I have been saying since the Instagram post, now with a legal deadline attached.
Scope every capability to least privilege, so an agent can only ever do the narrow thing its task needs. Put a policy layer in front of every consequential action, so the system decides whether an action is permitted before it runs and refuses what does not meet the rules. Require a human for the irreversible things, money, identity, anything you cannot take back. And log every action in a tamper-evident, signed record, so traceability is a property of the system rather than a promise in a document.
That list is not my invention. It is Articles 12, 14, and 15 described from the engineering side instead of the legal one. They converge because they are describing the same reality from two directions.
This is what I build with WasmBox: a sandboxed tool launcher for agents where every capability runs behind policy, inside a sandbox, and lands in a signed audit log. Not because the AI Act requires it, but because it was the right way to run an agent before the AI Act existed, and the Act has now made the right way also the legal way. The binder is downstream of the control.
The honest version
The AI Act is not perfect and the timeline is a mess. But strip the politics and it asks agent builders to do the one thing that was always correct: know what your agent can do, gate what matters, and be able to prove what happened. The companies that treat that as a documentation exercise will produce excellent binders and ungoverned systems. The ones that treat it as an engineering requirement will be compliant almost by accident, because they built the controls the paperwork is only describing.
A binder is not a control. Build the control, and the binder writes itself.
metaend