Authority Before Autonomy in Enterprise AI
Enterprise AI does not become safe or useful through a single autonomy setting. Authority must be earned action by action: observe, recommend, simulate, write with approval, then operate within measured limits. We use this progression to connect technical capability with accountable operations.
The Wrong Question About Agents
Leadership teams are often asked whether they want an AI agent to be autonomous. The question is too broad to support a decision. An agent may read inventory safely while being unqualified to change a reorder point. It may draft a customer response well but lack authority to send it. It may reconcile known payment patterns reliably while escalating an unfamiliar fee.
Autonomy is not a property of a model or an application. It is a permission attached to a defined action under defined conditions. The same system can hold different authority levels for retrieval, analysis, communication and mutation. Treating these as one switch either blocks useful automation or grants more power than the evidence supports.
The distinction matters as organisations move from pilots toward scaled adoption. The BCG and Consumer Goods Forum report published in June 2026 describes a widening gap between experimentation and value at scale, with governance and operating-model changes central to the transition. We read that as an execution problem: organisations need a repeatable way to turn model performance into bounded operational authority.
Capability, Permission and Accountability
Three layers are frequently collapsed.
Capability asks whether the system can produce an acceptable result. Can it classify an exception, find the right policy, calculate a proposal or construct a valid API request?
Permission asks whether it may perform the action in this context. Does the data residency policy allow this model? Is the account in scope? Is the value below a threshold? Is a human approval required?
Accountability asks who owns the outcome and how it can be reconstructed. Which team accepts the risk? What evidence is logged? Who responds when a write is wrong? How is access revoked?
A high benchmark score answers only part of the capability question. It does not grant permission and it does not create accountability. Our approach to agent harness and model routing starts with privacy and residency gates for exactly this reason: the eligible execution path must be established before quality, latency or cost can be compared.
An Authority Ladder for Each Action
We use five levels. A workflow can occupy several levels at once because each action is assessed independently.
1. Read-only
The system can retrieve approved data and observe events but cannot propose an operational decision through a production channel. This level establishes identity, scope, logging and data handling. It is where teams discover that “read” is not automatically low risk: customer records, employee data, pricing agreements and security logs still require field-level controls.
Success means the system accesses only the intended sources, cites or records provenance, respects tenancy and retention, and fails closed when identity or scope is unclear.
2. Recommend
The system produces a suggested action for an authorised person. The recommendation must include enough context to judge it: inputs, policy basis, confidence or uncertainty, material alternatives and expected effect. A bare “approve” or “reject” transfers cognitive work without transferring understanding.
At this level, we measure recommendation quality and reviewer behaviour. Acceptance rate alone is misleading; a fatigued reviewer may accept poor proposals, while a careful reviewer may correct a useful system. Sampled independent review and outcome tracking matter.
3. Dry-run
The system constructs the exact proposed write and validates it without changing production state. For an API, that may be a validation endpoint. For a data pipeline, it may be a shadow table and a deterministic diff. For customer communication, it may be rendering the final message with recipients resolved but sending disabled.
Dry-run exposes integration failures that offline evaluation misses: invalid identifiers, stale state, permission mismatches, rate limits and unintended fan-out. The validate_only pattern in our Google Ads API operations guide is one concrete example. Simulation is valuable only when it is close enough to the real write path to reveal the same constraints.
4. Approved write
The system may execute a specific change after approval by an accountable person or policy service. Approval should bind to the reviewed payload, not merely to a conversation. If price, recipient, quantity or underlying state changes after review, the approval should expire.
The write path needs idempotency, preconditions, least-privilege credentials, an audit record and a defined recovery operation. “Human in the loop” is not a control unless the human sees the consequential fields, has time and competence to assess them, and can stop execution.
5. Bounded autonomy
The system may execute without case-by-case approval inside an explicit envelope. Bounds can include action type, accounts, time window, value, volume, confidence, data freshness and exception class. Everything outside the envelope is rejected or escalated.
Bounded autonomy is earned with production evidence from the earlier levels. It is not permanent. Authority can expand, contract or return to recommend-only based on measured performance and environmental change.
Define the Action Contract
Before evaluation, we write an action contract. It is a compact specification shared by the business owner, risk owner and builder.
| Contract field | Question |
|---|---|
| Intent | What business outcome is the action meant to advance? |
| Target | Which system, object and fields may change? |
| Eligibility | Which accounts, cases and data classes are allowed? |
| Preconditions | What must be true and fresh at execution time? |
| Bounds | What value, volume, time and confidence limits apply? |
| Evidence | Which inputs, rules, model and approvals are recorded? |
| Recovery | Can the action be reversed, compensated or contained? |
| Owner | Who accepts the outcome and responds to failure? |
This contract prevents a common failure: evaluating a broad conversational task while granting a narrow technical credential that can do much more. The credential should implement the contract. A pricing workflow that may update one approved field should not receive general catalogue administration access.
Contracts also make portfolios comparable. Executives can see why one action remains at recommend while another advances to bounded autonomy. Builders can translate policy into assertions, schemas and tests.
Evidence That Authority Has Been Earned
Offline task success is necessary but insufficient. We combine four evidence groups.
Decision quality: accuracy against reviewed cases, severity-weighted errors, calibration, policy adherence and performance across important segments.
Execution quality: valid payload rate, precondition failures, duplicate prevention, integration latency and recovery success.
Operating quality: escalation rate, reviewer correction, exception ageing, downstream outcomes and incident response.
Control quality: access violations, missing provenance, stale inputs, unapproved scope changes and audit completeness.
Measures need denominators and cohorts. “Ten errors” is uninterpretable without action volume and severity. Aggregate accuracy can conceal a dangerous minority class. A workflow can be correct in normal cases yet fail every time data is delayed.
Where internal scale is confidential, we report normalised indices. If severity-weighted intervention volume at the start of a controlled trial is Baseline = 100, later periods can be compared with that baseline. The movement is evidence for a review, not automatic proof of model causality. Process changes, case mix and reviewer learning may contribute.
Promotion and Demotion Must Be Symmetric
Teams commonly define how automation gains authority but not how it loses it. That creates one-way risk. Every authority level needs promotion and demotion criteria agreed before launch.
A promotion gate might require a minimum sample across representative cohorts, zero unresolved critical errors, an acceptable severity-weighted rate, tested rollback and sign-off from the action owner. Time alone is not evidence. Neither is a high acceptance rate without outcome review.
Demotion should be automatic for clear control failures: missing or stale source data, policy-version mismatch, anomalous action volume, failed reconciliation, unavailable rollback, a material distribution shift or expired credentials. The safe response may be to fall from autonomous write to approved write, recommend-only or read-only rather than shutting down the entire system.
This graceful degradation is easier when the ladder is designed from the start. A workflow that can only be fully on or off has no operationally useful fallback.
Separate Models From Deterministic Controls
Authority should attach to the action gateway, not to the model. Models can interpret unstructured input, retrieve candidate evidence, classify cases and draft proposals. Deterministic services should enforce identities, schemas, thresholds, allowed fields, state preconditions and idempotency.
This separation limits blast radius and makes model replacement practical. A stronger model does not bypass the action contract. A cheaper or local model can be introduced for an eligible task without redesigning permissions. Our domain-specific agent skills guide describes the value of packaging instructions and tools around bounded workflows; the authority layer adds the production control surface.
Builders should assume that model output is untrusted input. Parse it into a typed proposal. Resolve references against current systems. Recalculate material values where possible. Reject unknown fields. Recheck policy at execution time. Store both the proposal and the final action so transformation is visible.
The Human Role Changes by Level
At recommend, the human evaluates individual decisions. At approved write, the human also verifies the exact consequence and authorises execution. Under bounded autonomy, human attention moves to envelope design, sampled review, exceptions and system health.
That is not removal of accountability. It is a change from repetitive case handling to control ownership. Reviewers need training, workload limits and a clear escalation route. Owners need dashboards that show cohorts and severity, not a reassuring average. Risk and compliance teams need evidence they can inspect without reconstructing an agent conversation.
The organisation should also protect dissent. If operators repeatedly override recommendations, the signal should trigger investigation rather than pressure to increase acceptance. Front-line corrections often identify missing context earlier than aggregate metrics.
A Practical Rollout
We use the following sequence for a new action:
- Define the action contract and accountable owner.
- Apply privacy, residency, identity and data-readiness gates.
- Establish a reviewed evaluation set, including rare and adverse cases.
- Run read-only and recommendation modes with full provenance.
- Exercise the real integration through dry-run and deterministic diffs.
- Enable payload-bound approvals with rollback and incident procedures.
- Grant a narrow autonomous envelope to a representative cohort.
- Review outcomes, exceptions and control health; promote or demote by rule.
The goal is not to make every action autonomous. Some writes are rare, irreversible or too context-dependent for case-by-case approval ever to be removed. The ladder still creates value by improving recommendations and making approved execution faster and more reliable.
The Executive Decision
Enterprise AI governance becomes concrete when leaders stop approving “agents” and start approving action contracts. Budget can then follow measurable operating outcomes. Risk discussions can focus on scope, reversibility and evidence. Technology teams can compare models within an eligible pool while keeping authority stable.
The central principle is straightforward: capability earns consideration; evidence earns permission; ownership sustains authority. Organisations that preserve this sequence can increase useful automation without confusing speed with control.