Enterprise AI: Ownership, Access and Operating Handover

When an AI assistant moves into everyday work, someone has to own its access, quality, running cost and failures. An enterprise AI operating model assigns those responsibilities and the evidence required before permissions or scope change. Start with the workflows already in use, including informal trials, and record who can support or disable each one.

NIST’s Generative AI Profile is useful here because it frames AI risk management as an ongoing set of activities to govern, map, measure and manage. NIST, AI RMF It is voluntary guidance, rather than a prescriptive enterprise blueprint. The implementation work is therefore local: product, risk, engineering and operations must agree what those activities mean for their own workflows.

Start with a portfolio, not a platform

Many firms begin with a platform decision: choose a model provider, buy an assistant, build a retrieval layer, or publish a prompt policy. Those choices matter, but they do not answer what work is being changed or who accepts the resulting risk.

The first useful artefact is a living use-case register. It should include:

Use the register to identify duplicate work, trials without an owner, and services whose operating cost or support needs have not been assessed.

Use risk tiers that change the work

The following tiers are a suggested planning aid, not an official classification. Adjust them to the consequences of an error and the data involved. Even a summarisation tool can be high risk if it handles sensitive material.

1. Productivity assistance: drafting, search and summarisation with no direct customer or regulated decision.
2. Operational assistance: classification, extraction or routing where an error can delay or misdirect work.
3. Customer-facing assistance: systems that shape customer communication, onboarding, complaints or service.
4. Decision support: tools that influence fraud, credit, compliance, pricing, eligibility or a material operational decision.
5. Action-taking agents: systems that invoke tools, modify records, initiate a payment or create an external commitment.

Each tier should change the required evidence. A Tier 1 drafting tool may need approved data handling, user guidance and a basic quality check. A Tier 5 agent needs those controls plus least-privilege access, explicit authority boundaries, auditability, exception handling and a tested kill switch.

OWASP’s agentic guidance calls out goal hijack, tool misuse, and identity and privilege abuse as distinct concerns for systems that can act. OWASP, Agentic Applications Top 10 The practical implication is simple: evaluate the connected tools and permissions, not just the model response.

Define the shared services once

Product teams should own their workflow decisions. They should not each reinvent identity, data controls, evaluation storage or incident handling. An enterprise operating model normally needs shared services for:

• approved model and vendor routes, with procurement and resilience records;
• identity, role-based access and secrets management;
• approved data connectors and retention rules;
• logging, traceability and a place to retain evaluation evidence;
• red-team and release support for higher-risk use cases;
• monitoring, incident escalation and disable controls.

Centralising these foundations does not mean centralising every product decision. The platform team provides safe building blocks; the workflow owner remains responsible for whether a system helps their people and for responding when it does not.

Assign an owner to each control decision

The following allocation is illustrative. Replace function names with accountable people and give them the access, time and authority to act.

The evaluation contract records the evidence for a particular release. AI task economics makes review and exception-handling costs visible. Neither replaces a named owner who can hold a release or disable a failing route.

Worked example: procurement support versus purchasing authority

Illustrative example, not a reported implementation. Consider a procurement assistant. In its first release it reads approved catalogues and drafts a comparison for a buyer. That is an operational-assistance use case: test source accuracy, data access and escalation, but the buyer still makes the purchase.

Later, the business asks it to reorder supplies automatically. The risk tier changes. The assistant now needs a purchase authority that names the business principal, permitted suppliers or categories, all-in spending limit, frequency, expiry and approval route. A final cart must be checked against that authority before an order is created; a price change or unapproved seller must trigger a hold.

The Agent Payments Protocol v0.2 specification, reviewed on 24 October 2026, distinguishes checkout mandates from payment mandates bound to a particular checkout. Record the protocol version used by an integration; a mandate’s signature does not replace your checks on supplier eligibility, spending limits, current cart contents and revocation. The enterprise still needs a person who can withdraw the agent’s authority.

That example illustrates why a single “AI policy” is insufficient. The same assistant crosses a material control boundary when it moves from advice to action.

Make vendor concentration visible

AI services introduce dependencies beyond the chosen model: cloud regions, orchestration frameworks, vector stores, prompt stores, evaluation products, connectors and specialist tooling. A model outage, a change to an API, or a retrieval outage can become an operating incident.

For each material service, keep a dependency record that answers:

• What workflow fails or degrades if this service is unavailable?
• Can the workflow run without AI, use a manual queue, or fail over safely?
• What data crosses the boundary and what is retained?
• Who receives change notices and evaluates material vendor changes?
• Who can disable the route, and how will users be informed?

This is ordinary resilience practice applied to a new stack. It prevents a useful assistant from becoming an opaque single point of failure.

Run a real operating cadence

The operating model needs a cadence, not just a committee. Weekly, workflow owners should review quality failures, user feedback, escalations, cost and unresolved risks. Monthly, the portfolio forum should review new proposals, tier changes, vendor dependencies, material incidents and use cases ready to expand or retire. Quarterly, executives should see the portfolio’s value, risk posture, concentration and capability gaps.

The forum should make decisions: approve a limited release, hold a use case, require a new control, reduce a permission, or retire an experiment. Record the decision, owner and required evidence so the next review can establish whether the agreed action happened.

Handover before the delivery team moves on

Ask the receiving operations team to run a short recovery exercise: remove access to a source, simulate an unavailable model route, submit an unsupported request and disable a tool. Verify that the user sees a useful fallback and the owner receives enough evidence to investigate, without logging unnecessary sensitive content.

The handover should contain the access matrix, connector identities, approved data sources, release and evaluation records, support queue, cost limits, escalation contacts and recovery steps. Budget for review time as well as inference. Agree which changes the owner can make and which need engineering or risk review. A named owner without time, access or authority is not an effective handover.

A practical first 90 days

Days 1–30: inventory live and proposed use cases; name owners; set initial risk tiers; identify unapproved data and vendor exposure.

Days 31–60: establish the release evidence required by tier; choose shared logging, access and incident patterns; run one low-risk workflow through the process.

Days 61–90: put a higher-consequence workflow into shadow mode; test fallback, disable and escalation paths; convene the first portfolio review with evidence rather than demos.

This sequence produces a usable minimum system. It can become more sophisticated as the organisation gains evidence, but it avoids waiting for a perfect enterprise architecture before learning from one controlled production path.

FAQ

Who owns an enterprise AI operating model? Executive sponsorship is needed, but ownership is shared: a central platform or governance group owns common controls, and each business owner owns the outcome and operating performance of their use case.

Does every AI use case need the same review? No. The review should scale with consequence and authority. What matters is that the tier changes the evidence, permissions, monitoring and recovery expected.

What is the first sign that governance is not working? The organisation cannot reliably answer which AI systems are in use, what data and vendors they depend on, who owns them, or how a harmful output is stopped.