There's an obligation under the AI Act whose difficulty changes — not its content — when the system moves from suggesting to acting. It's in Article 26(1), and it reads:
"Deployers of high-risk AI systems shall take appropriate technical and organisational measures to ensure they use such systems in accordance with the instructions for use accompanying the systems."
As in the previous article in this series, it's worth saying up front: there is no separate regime for agents in the AI Act. This obligation is the same with or without an agent, and it carries two limits the text itself sets: it reaches only high-risk systems — no other — and it applies from 2 December 2027 for those of Annex III. What changes is who upholds it in practice.
With a system that suggests, a person upholds it
If the tool proposes and someone decides, using it in accordance with the instructions rests on that person. If the system suggests something outside its intended purpose, whoever uses it notices and doesn't apply it. Control is continuous and built into the flow: there's a human at every step.
That's the model most organisations have in mind when they read Article 26(1). And that's why the article looks easier than it is.
With a system that acts, the permissions uphold it
An agent executes. If it has access to a tool, it can use it; if it has a goal, it will look for a way to reach it with whatever it has at hand. There's no moment where someone approves each step, because removing that moment is exactly what it's deployed for.
That's where the real problem comes from, and it isn't hypothetical: an agent with permissions broader than its purpose can drift outside it without anyone deciding it should. Not because the model fails or acts in bad faith: because the permission was there and the action fit the goal.
An agent designed to answer customer queries that also has write access to the CRM will end up writing to the CRM the day it seems useful to do so. Nobody decided to expand its purpose. It expanded on its own, as far as its permissions reached.
And this is where Article 26(1) stops being trivial: if actual use exceeds the intended purpose set out in the instructions, the organisational measure that was upholding it no longer upholds anything.
What the article actually requires, literally
Two words that tend to get skimmed over: "technical and organisational measures".
With a system that suggests, organisational measures are almost always enough — instructions to the team, criteria for use, training. With one that acts, the technical measure stops being optional: the permission is the only thing standing between the agent's goal and an action outside its purpose.
It isn't a new obligation. It's the same obligation, whose compliance has shifted from the organisation to the system.
What that means in practice
Three things, and none of them comes from an article specific to agents, because none exists.
Scope permissions to the purpose, not to convenience. The natural impulse when deploying is to grant broad access so the agent "doesn't fall short." That's exactly what breaks the fit with the instructions for use — and what nobody reviews afterwards.
Test before expanding, not after. A new permission changes the set of possible actions, and that set doesn't grow linearly: one more tool is enough for the agent to reach goals by paths nobody foresaw. Deploying in phases — minimum permissions first, observed expansion after — isn't generic caution: it's the only way to know what it actually does before it does it on real data.
Record what was authorised, and why. Not as a formality: because when someone asks whether the use matched the instructions, the answer is the list of permissions and the criteria each one was granted under. Without that, the only evidence available is what the agent did — which is exactly what you'll be trying to justify.
Where the limit of what the Regulation says sits
It's worth being precise, because this is an area where the opposite is common.
The Regulation doesn't say how many permissions an agent should have, or that it must be deployed in phases, or that an authorisation matrix must exist. None of that is in Article 26, or in any other article.
What it says is that you adopt appropriate technical and organisational measures so that use matches the instructions. How you achieve that is up to you — and Article 26(3) itself expressly preserves your "freedom to organise its own resources and activities".
Everything else is a known way of achieving it. Good practice, not obligations. Confusing the two is the mistake of attributing to the deployer what binds the provider, in its most tempting form: inventing a legal requirement because the measure is sensible.
Being sensible doesn't make it mandatory. And not being mandatory doesn't make it any less necessary the day an agent does something nobody explicitly authorised, and someone has to explain why it could.
Content in accordance with Article 26 of Regulation (EU) 2024/1689.
This article is for informational purposes only and does not constitute legal advice.