Enterprise AI agents need clear governance: which data may they use, which actions may they take, and when must a human approve?
Editorial team: mAItflow · Publisher: Masterplan Tech Solutions GmbH · Updated: 2026-08-26
Without governance, AI agents are risky. With roles, audit and approvals, they become productive.
Governance has a reputation as the tax paid after the interesting work. For AI agents it is the other way round: the absence of governance is what prevents deployment, because an agent that can act on production systems cannot be switched on until someone can say what it may touch and who answers for it.
The concrete blocker is nearly always the same. A pilot works, someone asks who approved the agent writing to the CRM and what would happen if it wrote something wrong, and there is no answer — so the pilot stays a pilot. The governance work is what converts a demonstration into something that can run.
It is also lighter than it sounds, because most of it is a list: what is deployed, what it may reach, what is logged, who owns it, and what stops for a human.
Under the EU AI Act, a provider develops an AI system and places it on the market under its own name; a deployer uses an AI system under its own authority. Almost every company buying AI is a deployer, and deployer obligations are materially lighter than provider obligations — a distinction worth establishing early, because a great deal of compliance anxiety comes from reading provider duties as if they applied.
The line moves if you substantially modify a system or put your own name on it. Building an internal product on a vendor's API and offering it to other organisations can make you a provider of that system.
Risk classification attaches to the use case, not the tool. The same workspace is minimal-risk for drafting marketing copy and high-risk if used to screen job applicants — so classification is a per-workflow judgement, made by the deployer, and it needs revisiting whenever a workflow's purpose changes.
Five, in order of how often their absence blocks a deployment.
An inventory. Which AI systems are in use, for what purpose, by which team. Required for AI Act record-keeping and for GDPR Article 30 where personal data is involved, and impossible to reconstruct later.
Scoped permissions per agent. Access to the data a workflow needs and no more.
Per-action logging. Which agent, on whose behalf, what it read, what it changed, who approved.
Named approval points. For irreversible and outbound actions. Article 22 GDPR is directly relevant where a decision produces legal or similarly significant effects on a person; Article 14 of the AI Act requires high-risk systems to be designed for effective human oversight, applying from 2 December 2027 for standalone Annex III systems.
An accountable owner per workflow. Not a committee. A named person who can decide to change or stop it.
The organisation that deployed it. Not the model vendor, and not the platform. That is uncomfortable and it is also the practical reason approval points and audit trails matter commercially rather than merely legally: without them there is no way to demonstrate what happened, on whose authority, and whether the control that should have caught it existed.
Where personal data is processed and the risk to individuals is likely to be high, Article 35 GDPR requires a data protection impact assessment — again an obligation of the deploying organisation. A vendor can supply the information the assessment needs; it cannot perform it for you.
Frameworks help structure this without inventing it: the NIST AI Risk Management Framework is a widely used, non-binding reference for mapping, measuring and managing these risks, and it is a reasonable backbone for an internal policy.
All links verified on 26 August 2026. Prices are vendor list prices as of that date and do change; the vendor's own page is authoritative.