Ask a mid-sized company whether it has AI governance and the answer is usually yes. There is a committee, a two-page acceptable-use policy, a risk register reviewed every quarter and, in the more advanced ones, someone with the title of AI lead. All of that exists and all of it is paper.
Ask next what happens when an agent connected to the CRM tries to delete a thousand contacts at three in the morning, and the answer is different: nobody knows, because nothing is watching.
That gap between what is written and what happens is the problem operational governance exists to close. It does not replace the committee or the policy. It is the part missing underneath.
Three verbs
Operational governance comes down to three verbs, and each one produces something you can show an auditor, a customer or a board.
Decide. Someone has written down what each AI system may do on its own, what needs approval and what is off limits. Not in the abstract: for this agent, with these tools, over this data. The artifact is a policy a machine can evaluate, not a paragraph a person interprets.
Watch. Something outside the system checks every relevant action against that policy before it happens. If the action cannot be undone, it stops and waits for a person. The artifact is a runtime control point, what the OWASP GenAI Security Project calls a Guardian Agent.
Prove. Every decision, human or automatic, leaves a record that lets you reconstruct what the system did, with what data and under which rule. The artifact is a trace your SOC already knows how to read and an auditor can verify without asking for screenshots.
When any of the three is missing, what you have is something else. Policy without watching is a wish. Watching without policy is an arbitrary filter every team configures its own way. And both without evidence are useless the day someone asks what happened.
How it differs from document governance
Classic AI governance was designed for models that were trained, validated and deployed once. It makes sense that its tools work at that scale: an impact assessment before going live, an annual review, a committee approving use cases.
Agents break that rhythm. An agent decides on every turn which tool to call and with which arguments, and those arguments may come from an email, a web page or a document someone left on a SharePoint. The use case approved in January does not describe what the agent will do in March, because what it does depends on what it reads.
So the questions change scale:
- Document governance asks whether the use case is approved. Operational governance asks whether this specific call to this specific tool is within what was approved.
- Document governance reviews the system every quarter. Operational governance reviews every action before it runs.
- Document governance produces minutes. Operational governance produces traces.
Neither is good or bad. It is that the first without the second no longer describes what happens in production.
What each layer produces
It is worth going into detail, because "governance" is a word that admits anything and here we want it to admit very little.
Decide
- Inventory with owners. Every AI system, including the ones that arrived inside a SaaS, with a named person who answers for it and can switch it off. How to build one in five days is in an AI system inventory in a week.
- Autonomy limits per system. A three-column table: what it does alone, what it does with approval, what it never does. Written for each agent, not for the company.
- Evaluable policy. The rules in a language an engine can execute: Cedar, Rego or whatever your platform already uses. A policy in prose cannot be enforced at runtime, and therefore is not enforced.
Watch
- A control point outside the agent. The agent proposes, something external decides. If the control logic lives in the same process as the model, the model can talk it round.
- Least privilege per tool. An identity of its own for each agent and only the credentials its task needs. It is the control that fails most often in practice and we give it its own article: tool permissions for agents.
- Human approval where there is no way back. Payments, deletions, external sends, permission changes. The person does not oversee everything, they oversee the irreversible.
Prove
- A trace per action. What was requested, which rule was evaluated, what was decided, what ran. With the provenance of every argument, because the argument is where the attack gets in.
- Exportable evidence. If only the agent platform can see the trace, it is not evidence. It has to leave for wherever the company's security already lives: the SIEM, in a format like OCSF.
- Coverage metrics. What share of actions goes through the control point. Governance that covers 40 % of tool calls is not governance, it is sampling.
Why it lines up with regulation now
It is no coincidence that the three layers resemble what Regulation (EU) 2024/1689 asks of high-risk systems: continuous risk management (Art. 9), event logging (Art. 12) and human oversight with a real ability to intervene (Art. 14). Nor what an ISO/IEC 42001 auditor looks for when asking about operational control.
The difference is that regulation describes the outcome and does not say how to get there. Operational governance is the how, and it has the advantage that the evidence it produces for the business is the same evidence that serves compliance. Which obligations apply and from when is in what the AI Act requires; if you are unsure of your system's category, the EU AI Act risk calculator settles it in a few minutes.
Where to start
With the inventory. It is the cheapest layer and the only one without which the rest makes no sense: you cannot write the policy for a system you do not know exists.
Then one agent. Not the whole company: the agent with the most access to real systems. Write its limits, put the control point in front of it and check that the trace reaches the SIEM. With one working, the second costs a fraction.
And before all that, a measurement. We have prepared an agent control checklist with forty yes-or-no checks across eight areas. It takes an afternoon, needs no new tooling and the score tells you which of the three layers to start with. If you would rather we did it with your team on your systems, that is exactly the control diagnostic.