Governing AI-Enabled Operations

Who can authorize the operation—and change that decision?

An AI-enabled service may have an approved model, a business sponsor and documented controls. Yet the next difficult operating decision can still have no clear owner: a shared data source becomes unreliable, reviewers cannot keep up, or a team wants permission to act beyond the original scope.

Enterprise governance must answer four connected questions: which operations may run, who is accountable for their consequences, what evidence leaders require, and when the operation or its authority must change. The answer includes funding, policy, review and a usable route for intervention.

My perspective

I would test governance by tracing one difficult decision from the leadership mandate to what people and systems actually do. If a decision to narrow authority does not change permissions, queues and instructions, the enterprise has recorded an intention without changing the operation.

Bounded Autonomy specifies the boundaries around delegated decisions. This framework connects those boundaries to enterprise accountability, policy ownership, funding and independent challenge. It governs the whole service: people, knowledge, models, tools, data and dependencies through to an accepted business outcome.

Connect the mandate, the evidence and the operation

Authority to operate remains justified while accountable ownership, funded capacity, enforceable boundaries and current evidence support it. An authorization therefore names its conditions, its decision owner and the events that reopen it.

The loop is RePerspective Labs’ synthesis. NIST AI RMF 1.0 provides voluntary guidance on executive accountability, inventory, ongoing review and risk response; it does not prescribe this decision model. [1]

Give each service an accountable, funded mandate

State the commitment and its limits

Start with the intended outcome, who accepts it, affected parties, operating scope and constraints. Enterprise leadership sets risk appetite and reserves decisions that exceed local authority: accepting exposure outside delegation, changing enterprise policy, committing shared funding, or allowing consequential new uses. A Sponsor secures decisions and resources through that mandate.

Name the Outcome owner accountable for the business result and acceptance criteria; the Operating owner responsible for day-to-day performance, exceptions and recovery; the Knowledge owner responsible for authoritative sources and their maintenance; and the Technology owner responsible for the technical service and its dependencies. The Control lead coordinates control requirements, evidence and challenge under a stated mandate. Preserve distinct Legal, Privacy, Security, policy and audit responsibilities.

Record who may accept residual risk, within which limits and for how long. No owner title—including Sponsor or Control lead—automatically confers that power. Where business authorization and risk acceptance belong to different people, both decisions must be present. Risks beyond delegation return to the enterprise authority; a prohibited use cannot be approved through risk acceptance.

Fund the capability that will actually run: review capacity, support, knowledge maintenance, oversight, necessary assurance and recovery. If reviewer capacity falls, revisit the permitted workload or operating design. A budget decision can invalidate an authorization as directly as a technical failure.

Cost per accepted outcome = total recurring cost of running the capability in a period ÷ outcomes accepted by the owner in that period. Include failed attempts, review, correction, support and recovery in recurring cost. Keep one-time build investment separate; align scope and period. When no outcomes are accepted, report cost and the absence of accepted outcomes without calculating the metric. Use this evidence to revisit the commitment, alongside consequences and service quality.

Make the inventory useful at the next decision

Give each end-to-end service a stable identifier. Link its outcome, owners, users, lifecycle state, funding responsibility, current authorization, policy versions, exceptions and review date. Include people and review queues, models, tools and permissions, data and knowledge sources, suppliers, upstream inputs and downstream recipients.

Use existing service-management, configuration and risk records where they are authoritative. Link them through stable IDs and named maintainers. Inventory completeness means being able to answer an operating question, rather than filling every field in a duplicate catalog.

For example, when a shared model or receipt-data feed changes, the inventory should identify affected services, their owners and the authorizations that relied on it. Leaders can then coordinate restrictions, review evidence across the exposed estate and assign the cost of remediation. Reconcile the authorization of any service missing from the inventory, and contain activity whose permission cannot be established. NIST addresses inventories and their resourcing in GOVERN 1.6. [1]

Separate enterprise decisions from local discretion

Enterprise leadership sets non-negotiable constraints, policy ownership, delegation, shared-service obligations and escalation routes. Operating teams choose methods, schedules and routine adjustments inside that mandate. A local improvement that changes affected parties, permissions, downstream commitments or aggregate exposure may exceed it.

Translate policy into the decision arrangements Recommend · Act · Escalate · Never Delegate. These are arrangements, not maturity levels. Specify the permitted task and conditions using the Bounded Autonomy authority record. Information access does not itself grant permission to act. A policy statement becomes operational through permissions, validation, approval gates and usable human intervention, as developed in Controls by Design.

Use existing executive, operating and risk forums when their remit and attendance let them make the required decision. Give each forum an explicit decision purpose, required participants, delegated powers, evidence requirements and escalation route. Create an additional forum only to close an identified decision gap. A meeting that can recommend but cannot authorize must say so.

Disagreement does not enlarge local permission. Record the disputed issue and take it to the authority able to resolve the policy, funding or risk conflict. Until resolved, retain the last valid, supportable scope or narrow it. Pre-authorize the Operating owner and Technology owner to pause affected routes when stated conditions fail. Give control and specialist functions explicit powers to require restriction where their mandates warrant it, and a direct escalation route when they do not hold that power.

Make exceptions specific and temporary

The policy owner defines how policy becomes operating boundaries and which deviations may be considered. An exception needs a lawful, permitted scope; a reason; alternatives considered; compensating controls; an accountable owner; the authorized approvers; an expiry; and earlier withdrawal triggers. The policy owner confirms permissibility; the designated risk acceptor and service authorization owner approve within their mandates. These may be different people.

Communicate the exception to everyone implementing or relying on it. At expiry, the temporary permission ends unless renewed through an explicit review. Repeated renewals should prompt a policy or operating-design decision. No exception can waive a legal prohibition or a boundary the enterprise has designated non-exceptable.

Match scrutiny to the actual consequences

Consider consequence, reversibility, exposure, scale and uncertainty together. Who could be harmed? Can the action be reversed before harm occurs? How many cases, people or connected services are exposed? Can repeated small actions create a large commitment? What remains untested or difficult to observe?

Use those answers to choose reviewers, specialist participation, evidence depth, deployment limits and review frequency. A reversible internal draft may justify local review. Privileged changes to a shared production service can require stronger evidence, independent challenge and senior authorization, even when the expected number of actions is small. Hard boundaries are checked first; an average score cannot cancel them. No universal risk tiers or numerical thresholds are implied here.

Give evidence an owner, a recipient and a consequence

Separate three responsibilities. The IIA’s Three Lines Model distinguishes management’s delivery and risk responsibilities from independent internal audit assurance to the governing body. This is professional guidance, not a mandatory organization chart for every enterprise. [2]

• Operation: the Operating owner and service team produce evidence, handle cases, operate controls and implement decisions. Evidence covers accepted outcomes, failures, human review, exceptions, costs and dependency changes.
• Oversight: the Control lead and relevant risk, policy or specialist functions challenge whether evidence is sufficient and boundaries remain appropriate. They track unresolved findings and escalate to the mandated decision authority. Combining roles in a small team must not hide self-review or conflicts.
• Independent assurance: internal audit or another appropriately independent provider examines whether governance and controls work, with access and reporting protected from those being assessed. Findings reach the governing body or its delegated audit/risk committee, as well as management for action. Assurance does not take management’s service-authorization or risk-acceptance responsibility.

The decision owner needs a clear account of what was examined, which versions and case populations it covers, who produced and challenged it, what failed, and what remains uncertain. Commission assurance over boundary enforcement, evidence reliability, human response capability, dependency and change controls, continuity, and whether previous decisions were implemented. Detailed evaluation design belongs in a separate assurance method.

For every material finding, name the management response owner, due date, interim restriction and escalation if unresolved. Accepting a report does not close its findings. The authorized risk acceptor must explicitly accept any remaining exposure within mandate; otherwise the service is narrowed, redesigned or stopped.

Keep external sources distinct. NIST AI RMF is voluntary guidance. ISO/IEC 42001:2023 is a management-system requirements standard; this article uses its public overview, not a clause-by-clause conformity assessment. [3] Legal obligations, including relevant AI Act obligations, depend on the applicable law, use and organizational role. Assign qualified specialists to establish them for the actual service. [4] This framework does not establish compliance or certification.

Govern the whole operating life

Before entry into service, accept the operating design, current evidence, staffing, support and recovery arrangements. Name material-change triggers in advance: model or supplier changes, new tools or permissions, altered knowledge or data, different case types, increased scale, changed policy, and loss of review capacity. Routine maintenance stays local only while the authorization’s assumptions remain valid.

Periodic review catches gradual change; incidents and dependency changes bring it forward. NIST’s MANAGE guidance covers residual-risk documentation, third-party risk, deactivation, monitoring, recovery and change management. [1] Choose a formal decision: Expand the permitted scope on supporting evidence; Continue within valid conditions; Narrow authority or exposure; Redesign the operation; or Stop. Specify what happens to current work during redesign. Pause, rollback and resume remain precise operational instructions.

The table is an adaptable decision record. Assign real people or existing forums under written delegation; its role labels do not grant authority.

After an incident, restoring technical availability does not by itself authorize restart. Reconcile affected cases, verify corrective action and controls, establish funded response capacity, and have the named authority accept the remaining limits. Retire deliberately: settle or transfer work, notify dependent owners, withdraw credentials and routes, and retain required evidence.

Make the decision reach the work

Issue one versioned decision with its service ID, permitted scope, effective time, conditions, expiry or next review, and action owners. The Technology owner changes permissions and workflow gates; the Knowledge owner updates authoritative guidance; the Operating owner changes queues, runbooks and staffing and briefs operators. Notify dependent teams and suppliers where their behavior must change.

Require confirmation that these changes are effective, with evidence appropriate to the consequence. Check the resulting configuration and an affected route, including the blocked action. Retain that confirmation alongside the decision. An unimplemented restriction remains an open governance issue and may require the route to stay paused.

A receipt feed fails after authorization

Hypothetical operating scenario. The following mandate and exception rules are assumptions for illustration, not a client account or measured result.

A mid-sized enterprise proposes an invoice evidence assistant. It may gather approved source evidence and prepare internal drafts. Payment approval and supplier bank-detail changes are Never Delegate. The Finance director is Outcome owner, the AP manager is Operating owner, and named Knowledge owner, Technology owner and Control lead responsibilities are funded.

An existing operations/risk forum has delegated authority to authorize this service. A separately designated finance risk authority may accept residual risk within stated limits. Both accept the readiness evidence for the defined scope, including source checks, reviewer capacity, escalation and a tested manual fallback. The authorization links to the inventory and configuration; the Technology owner verifies that payment actions are unavailable.

Later, the goods-receipt feed fails. AP requests permission to bypass missing receipts to maintain throughput. The Operating owner withholds the affected automated route under the agreed intervention rule. The inventory identifies other dependent services and routes the issue to their owners.

Assume the receipt policy permits temporary manual verification against an authoritative receiving record. The policy owner confirms that route is permissible. The forum and finance risk authority approve a time-limited exception only for cases with that evidence and funded reviewers. Cases lacking it remain held; unrelated work may continue within its authorization. If the policy were non-exceptable, the requested deviation would be refused.

The decision names the affected case type, alternative evidence, reviewer, effective version, expiry and withdrawal triggers. Knowledge guidance, workflow gates and operator instructions change together; implementation checks confirm that missing evidence cannot silently pass. Payment and bank-change authority remain unchanged.

When the feed returns, the team reconciles held and manually reviewed cases and verifies source integrity and controls. The named restart authority reviews that evidence before allowing the ordinary route to resume. The exception closes, or expires and removes the temporary route if no further decision is made. The next formal review can choose Continue or require Redesign of the dependency and fallback. No benefit or successful outcome is assumed.

Leadership takeaway

Choose one AI-enabled service and ask its owners to trace the latest authorization through the mandate, inventory, current evidence and implemented controls. Then change one assumption: a source fails, a reviewer leaves or a supplier changes the model. Can the right people decide, fund and enforce the response?

The practical output is a service whose permission can be explained and changed: a named decision authority, a funded operating commitment, evidence that reaches a responsible recipient, and confirmation that the decision changed the work.

Where to go deeper

Leading the Change to AI-Enabled Operations connects this work to employee consequences, sponsor commitments, manager routines and evidence of appropriate use.

• Bounded Autonomy defines decision-level boundaries; Controls by Design connects them to enforceable controls and evidence.
• Authority & controls in the Operating Blueprint, Operating Model Redesign and Redesigning Work Around Outcomes connect governance to the wider operating design.
• Explore Authority & boundaries, Monitoring & adaptation and Safe resumption. Use Define the authority to frame the next discussion.
• Apply the planning guidance at Design the Operating Model, Deploy into Operations and Improve Continuously. For a shorter orientation, read Governance by Design, Not by Default.

Sources and further reading

This framework, decision table and hypothetical application are RePerspective Labs’ editorial synthesis. They do not claim independent method validation, client validation or compliance certification. Detailed assurance methods, broader organization design and portfolio prioritization are separate treatments.

1. NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), January 2023. GOVERN 1.1, 1.3, 1.5–1.7 and 2.1–2.3; MANAGE 1.1, 1.4, 2.3–2.4, 3.1 and 4.1. Voluntary guidance. The NIST AI Resource Center states that version 1.0 is being revised; status checked October 11, 2026.
2. The Institute of Internal Auditors, The IIA’s Three Lines Model, July 2020, terminology updated September 2024; principles and key roles, printed pages 4–11. Professional guidance on governing bodies, management and independent internal audit.
3. ISO/IEC 42001:2023, Artificial intelligence management system, official public overview. Identifies a management-system requirements standard. The full licensed standard is outside this article’s source review.
4. European Commission, AI Act overview, checked October 11, 2026. Orientation to a legal framework; actual applicability and obligations require the operative legal text and service-specific assessment.