Enterprise Agentic AI Governance: an operating model, not a policy document

The question enterprises are actually asking when they say "we need AI governance" is this: how do we know what the agent is doing, and how do we stop it from doing something we did not authorize?

The answer to both parts is the same. You need a decision-authority layer: a decision rights model that specifies, for each agent in your stack, exactly what it is authorized to decide, under what conditions, and who or what can authorize it to do more. Without that decision-authority layer, you do not have operational governance. You have policy language and hope.

What agentic governance is not

It is not model governance. Model governance is concerned with how the underlying model was trained, evaluated, and monitored for bias and accuracy. Agentic governance is concerned with what the agent built on top of that model is authorized to decide in your organization. They overlap, but they are not the same problem.

It is not human-in-the-loop. Human-in-the-loop is one governance mechanism. It is appropriate for Tier 2 decisions. It is too slow and expensive for Tier 1. It is insufficient for Tier 3, which requires a named owner, not just a reviewer. Calling something human-in-the-loop does not constitute governance.

It is not an AI risk checklist. A risk checklist tells you what could go wrong. Operational governance tells you who is authorized to decide what, under what conditions, and what happens when something does go wrong. A checklist is a useful input to governance, not a substitute for it.

It is not a RACI. A RACI assigns responsibility, accountability, consultation, and information for a process. That is useful context. It does not specify the decision authorization logic, the monitoring requirements, or the rollback procedure for a specific agent deployment. Those require something more operational.

The NIST AI Risk Management Framework (AI RMF 1.0) provides a complementary structure for organizational AI risk posture. What this model adds is the operational layer: how you classify and authorize specific agent decisions, what controls each tier requires, and how you detect when the authorization boundary has been crossed in practice.

The three-tier authorization model

Every agent decision in your enterprise belongs in one of three tiers. The tier determines the required controls. Assign tiers before deployment, not after the first incident.

Two tests determine tier assignment. First: if the agent is wrong, can you recover from it within your tolerance window? If yes, Tier 1 or 2 depending on stakes. If no, Tier 3. Second: is this decision one you are actually authorized to delegate in your organization? Legal, regulatory, and contractual constraints sometimes make Tier 1 inappropriate regardless of technical reversibility.

Decision rights: who authorizes what

A decision rights model specifies, for each agent and each decision type, who has the authority to approve it running autonomously, who can expand that authorization, and who must be notified when the boundary is approached.

The model has four elements. The authorization scope is what the agent is permitted to decide, defined in operational terms, not capability terms. "The agent can process customer routing decisions for inbound support volume under 500 per day" is a scope. "The agent is capable of routing customers" is not a governance statement. The authorization owner is the person in your organization who approved that scope and is accountable for its outcomes. Not the AI team. A named business owner with a name and a role. The expansion gate is the process by which the scope can be extended: what changes require reauthorization, who signs off, and how fast can that happen. The boundary monitor is how you detect when the agent is approaching or exceeding its authorized scope, and what triggers an alert or a pause.

Required controls at each tier

Monitoring and observability

Agents drift. Output quality changes as the underlying model is updated, as production data shifts, and as edge cases accumulate that were not represented in the pilot. Monitoring has three components: automated metric tracking against defined thresholds, periodic accuracy review against a human-baseline holdout, and anomaly alerting when output distribution shifts in a way that suggests something has changed.

The monitoring cadence should be proportional to the tier. Tier 1 deployments with high volume and reversible outcomes typically tolerate longer review intervals, with real-time alerting for anomalies. Tier 2 deployments with external exposure need more frequent human review, with real-time alerting for anomaly events. Tier 3 is always human-reviewed, so monitoring focuses on audit quality rather than accuracy drift.

Audit records

At minimum, an audit record should contain: what decision the agent made, on what input, using which model version and prompt version, at what time, with any available output quality signal, and whether a human reviewed it before it was executed. For Tier 2 decisions, add: who reviewed it and when. For Tier 3, add: who signed off and the timestamp.

Audit records exist to answer two questions after an incident: what did the agent decide, and who authorized it? If you cannot answer both, your governance is incomplete. Retain records for at least as long as the decisions remain consequential. The right retention window varies by regulatory environment, industry, and contract terms; many enterprise contexts apply the same retention standards as other business records with equivalent legal exposure.

Rollback procedures

Every agent deployment needs a rollback procedure defined before it goes live, not written afterward when something goes wrong. A rollback procedure answers four questions: how do you detect that a rollback is needed, who has the authority to trigger it, what does reverting to the pre-agent state actually require, and how do you handle the outputs the agent already produced during the rollback window?

The last question is the hard one. For high-volume Tier 1 deployments, reverting to human production may not be feasible at speed. The rollback may actually be a pause-and-review: agent output is flagged for human review rather than reverted. Define this before you need it.

Escalation ownership

Every agent deployment needs a defined escalation path specifying: who gets notified when an anomaly is detected, who has authority to pause the agent, who has authority to roll it back, and who is accountable if outputs that crossed the external boundary need to be corrected or recalled.

Escalation ownership should be documented at the business-owner level, not just the technical level. The person who can pause the agent and the person who must answer for what it did are sometimes different people. Both roles should be named before deployment.

The three governance anti-patterns

Tier inflation. Governance documents say Tier 2 but the operational reality is Tier 1 because the review process is nominal. Reviewers approve agent outputs without meaningful review because the volume is too high, the review interface is inconvenient, or the outputs are unfamiliar. Fix: reduce volume to what reviewers can genuinely process, redesign the review interface, or reclassify to Tier 1 with proper monitoring. Do not maintain a fiction of human oversight that is not actually happening.

Authorization scope creep. An agent is authorized for one decision type and over time is used for adjacent decisions without a formal reauthorization. This is how you end up with agents making Tier 3 decisions under a Tier 1 authorization. Fix: a quarterly authorization review in which you compare what the agent is actually being used for against its documented scope, and close any gap through the expansion gate process.

Governance documentation lag. The agent gets deployed, the documentation gets written three months later, the rollback procedure is written in response to the first incident, and the audit records are designed reactively. Fix: treat governance documentation as a deployment precondition. No agent goes live without a completed tier classification, authorization scope, named owner, monitoring plan, and rollback procedure.

Implementation checklist

One checklist per deployment, completed before the agent goes live.

The checklist is intentionally operational. It does not ask you to list risks. It asks you to make specific decisions and assign specific ownership. Governance that remains at the level of "we will monitor this" is not complete. Governance is complete when you can answer who monitors it, how, on what cadence, using what metric, with what threshold, and who gets called when the threshold is crossed.

Disclosure: I lead go-to-market strategy for enterprise agentic AI at UiPath. The framework here is based on what I have observed across enterprise deployments, and reflects my practitioner view, not UiPath product documentation.