The business unit that uses an AI agent should own the policy it enforces: what counts as an acceptable exception, what must be escalated, and who signs off. IT and compliance should own the machinery that enforces that policy and the controls around it, not the content. Most companies do the opposite by default, because whoever deployed the agent ends up writing its rules.
That default is understandable. IT built the integration, so IT gets the config file. But a refund threshold, a discount exception, or a rule about which customer complaints reach a lawyer is not a technical setting. It’s a business judgment, and someone who doesn’t make that judgment daily will get it wrong in ways nobody notices until later.
The team that deployed the agent ends up writing rules it can’t judge
Picture the usual sequence. A pilot goes live, someone needs to decide what the agent may do without asking, and the engineer who wired it up picks numbers that seem reasonable. Refunds under $500 go through. Anything else gets flagged. Nobody in finance or customer operations ever sees those numbers.
Three failure modes follow. The policy is wrong on day one, because the engineer doesn’t know that a $400 refund to a strategic account is a call the account manager wants to make. The policy drifts, because the business changes its pricing or its risk appetite and nobody tells IT. And when something goes wrong, nobody in the business can say what the agent was allowed to do, because the rules live in a repository they can’t read.
Handing it to compliance doesn’t fix this. Compliance can say what a regulation requires, but it rarely knows which exceptions are routine and which are dangerous inside a specific workflow. You get a policy that is defensible on paper and either useless or paralysing in practice.
The business unit writes the rules; governance tooling enforces them
The workable model splits the job three ways. The business owner, usually a named head of the function the agent works in, defines the policy: thresholds, exception categories, escalation paths, and who approves what. Compliance sets the floor: the rules that no business owner can waive. IT owns enforcement: making sure the policy is applied exactly as written and can’t be quietly bypassed.
This is the point of governance as a principle. An approval gate is only as good as the policy behind it, and that policy has to be legible to the person accountable for the outcome. If the head of customer operations can’t read the rules in plain language and change them through a controlled process, they don’t own them. They just live with them.
It also depends on identity. When each agent has its own scoped credentials, a policy can be attached to that specific agent and its permissions. A shared API key can’t carry a policy, because nothing distinguishes what the agent is allowed to do from what anyone else using the key can do. Our piece on what an agent should never be allowed to do covers the floor compliance should set.
And it depends on audit. Ownership means little if you can’t see the policy being applied. In our deployments, every action is written against the specific policy version and the reason at the moment it happens, so a business owner can ask why a $480 exception was approved and get an answer that references their own rule, not an engineer’s interpretation. For where the gates themselves should sit, see approval gates and where AI agents actually need a human.
In practice, that means three things. The policy is written in the business owner’s language and stored somewhere they can review. Changes go through a named approver, with a record of who changed what and when. And the enforcement layer applies the policy without reinterpreting it. If the tooling quietly “improves” a rule, the business owner no longer owns it.
Business ownership still fails when the owner isn’t equipped for it
This model has real costs. Business owners are busy, and many have never written a policy precise enough for a machine to enforce. “Use judgment on large refunds” isn’t a rule. Someone has to translate vague intent into thresholds and conditions, and that translation is where a lot of the work in a deployment goes.
Owners also tend to err in one of two directions. Set the gates too loose and the approval step is decoration. Set them too tight and every action lands in a queue, and the automation saves nobody any time. There’s no formula for the right setting. It takes a few weeks of watching real exceptions and adjusting, which is why policies should be treated as living documents with scheduled reviews rather than something signed off once.
Then there’s the accountability problem. If a business owner is named but never looks at the policy again, ownership is nominal. This is one of the places pilots stall: the policy exists, but no one with authority will stand behind it.
Ask who would sign their name under the policy
If you’re planning a deployment, or already running one, the first step is finding out who currently owns the rules. Our diagnostic covers exactly this: who wrote the policy, who can change it, and whether the person accountable for the outcome has ever read it. You can Book a diagnostic call if you want a second set of eyes on it.
Either way, try this: pick one thing your agent does without asking a human, and find the person who decided it should. Would they recognise the rule if you showed it to them?
Related: ISO 42001 readiness for AI agents.