Executive briefThere is no responsible single owner of all AI

An enterprise AI incident often prompts a deceptively simple demand: appoint one executive who owns AI. The demand is understandable. Boards want a visible escalation point, management wants budget clarity and delivery teams want decisions faster than a committee cycle. Yet the phrase combines incompatible accountabilities. Operating an identity gateway is not the same work as deciding a credit policy. Setting a privacy standard is not accepting the customer consequence of a release. Validating a model is not assuring the governance system that commissioned the validation.

Giving all of those decisions to a CIO, CTO, CDO, risk function or central AI office creates an apparent answer while concealing conflicts. One unit can become proposer, builder, approver, risk accepter and evidence narrator. Domain leaders can then describe consequential choices as platform matters, even though the platform cannot know the intended use, local data meaning or affected workflow. Conversely, unconstrained federation can produce incompatible controls, missing evidence and no reliable kill path. Neither a large central box nor a loose network is an operating model.

The better unit of ownership is the decision. The Control Plane Decision-Rights Charter in this article allocates ten families of decision across platform, domain, specialist, executive and assurance actors. A Decision-Right Record makes the allocation operational for a particular policy, service, release, exception, incident or retirement. Five ownership tests determine whether authority belongs centrally, locally, independently or in a deliberately split arrangement. Each split still names one accountable decider for the bounded object.

The strongest rival: one executive owner

Single executive ownership has a legitimate case. A smaller organisation or an enterprise early in its programme may lack specialist capacity. Concentrating roadmap, standards, procurement and delivery under one leader can shorten escalation and establish shared services before local teams are ready. It can also provide one management voice to the board. Rejecting that model on principle would ignore the cost of premature federation and the value of clear leadership during formation.

Treat concentration as an explicit transitional design, not a permanent transfer of every consequence. Domain outcome owners remain named. Risk acceptance has documented bounds. Independent challenge cannot report to the release operator for the decision it challenges. Internal audit does not design the gates it later assures. The charter records a federation review date and the evidence required to distribute rights, such as stable machine-enforced standards, competent domain owners, repeatable receipts and effective escalation. Central ownership expires or is renewed on evidence.

Control Plane Decision-Rights CharterAllocate ten decision families

The charter is an enterprise design for authority, not an organisation chart. It can place several decisions in one team where competence and scale justify that choice, while preserving their distinct records. It also prevents the opposite mistake of inventing a committee for every question. The object and scope determine the decider. A shared gateway policy, a regulated underwriting model, an experimental assistant and a retirement dispute may travel through different routes even when they use the same technical platform.

These families interact, but interaction is not a reason to collapse them. A release may require a platform operator, domain product owner, data owner, security control owner, model validator and risk accepter. The record links their decisions in sequence. If a threshold is missed, the failure lands with the decider responsible for that threshold. If several objects are disputed, executive escalation resolves the allocation or risk, rather than retroactively declaring a committee collectively accountable.

Operational artefactWrite a Decision-Right Record

A RACI chart can show who participates while leaving the consequential verbs ambiguous. Responsible may mean drafting, operating, approving or accepting risk. Accountable may name a committee with no member authorised to decide. Consultation may hide a legal or security veto that appears only at release. The Decision-Right Record replaces those ambiguities with a bounded object and explicit powers. It does not abolish collaboration; it makes collaboration auditable.

Start with the decision object and scope. Name the policy clause, platform service, model release, exception, incident action, vendor commitment or retirement proposal. Define affected products, principals, data, jurisdictions and time. Name one accountable decision owner. Then name the proposer and consulted expertise, implementer or service operator, domain outcome owner, affected-party representative, risk accepter and delegation limit, independent challenger, evidence custodian, veto or kill authority, escalation forum, appeal route, exception expiry and review date.

The record must distinguish advice from authority. Legal counsel interprets obligations and can hold a formal stop right where management has assigned one, but an undocumented concern should not drift into a permanent shadow veto. Security owns specified standards and may stop a release that breaches a non-negotiable control. Risk challenge tests the proposal and its evidence. Management decides within appetite and accepts only the residual exposure delegated to it. The governing body oversees material appetite and management performance rather than becoming the routine release desk.

Evidence is part of the right. The decider receives the relevant test results, control receipts, known limitations, affected-party analysis, financial commitments, incident history and dissent. The custodian preserves versions, access and decision lineage. A supplier may generate telemetry or attestations but cannot be the only keeper of evidence needed to challenge the supplier. If the required evidence is unavailable, the record says whether the decision pauses, proceeds reversibly under a bounded exception or escalates.

Allocation logicApply five ownership tests

Information proximity asks who can observe the facts necessary to decide and detect change. A domain often knows customer consequence, workflow reality and data meaning; a platform often sees shared service performance and cross-product demand. Proximity supports ownership only if the information can reach the decider reliably. Hidden local knowledge is an argument to repair the information contract, not an excuse for undocumented authority.

Technical competence asks who understands the control mechanism and can judge evidence. Gateway routing, identity enforcement, model evaluation and incident containment require specialised capability. Competence may justify central operation or an independent validator. It does not automatically transfer the right to choose a business policy, approve an affected-party consequence or accept exposure beyond delegated limits.

Consequence accountability places intended use and outcome with management responsible for the affected service, customer, employee or public decision. This is the antidote to a domain sending a model to the platform and treating approval as an accountability transfer. Central specialists may stop unsafe or non-compliant use, but the first line still owns whether the system should be used and what happens in its workflow.

Control consistency favours central ownership where variation undermines interoperability, evidence or enterprise protection. Principal identity, core entitlement vocabulary, baseline telemetry, incident severity and supplier exit data are candidates. Consistency does not require every parameter to be central. A shared invariant can expose bounded local configuration, with machine checks revealing deviation before production.

Independence and conflict prevents an actor from approving or assuring its own work where effective challenge is required. The control author may advise implementation. The operator may produce evidence. The validator needs sufficient separation from development and use. Internal audit independently assesses governance and controls rather than designing daily gates. Where a small organisation cannot separate people, the record declares the combined hats, alternate reviewer and trigger for structural separation.

No test yields a score. A consequential choice can require a split because different rights satisfy different tests. The platform may operate the service; the domain may decide use and own outcomes; security may own an invariant; model risk may validate; an executive may accept residual risk inside board appetite; audit may later assess the system. The record makes their order, stop rights and evidence dependencies executable.

Responsibility seamsSeparate operation, challenge and assurance

Management remains responsible for achieving objectives and managing risk. Product and domain leaders are first-line actors when they choose intended use, data, workflow, human authority and customer response. A central platform team is also first line for the services it operates. It owns availability, secure implementation, supported interfaces, evidence production and incident action within the platform boundary. It does not become the first line for every adopter’s outcome.

Specialist risk, security, privacy, legal, compliance and model-risk functions may form second-line roles where the operating model assigns them independent monitoring or challenge. They translate enterprise appetite and obligations into standards, advise decision owners and test whether evidence supports management claims. They should not quietly absorb routine product operation. A second-line team that writes a control, configures the production service, approves the release and validates the outcome has removed the separation its challenge was meant to provide.

Internal audit provides independent assurance to the governing body and management. It needs access to records, systems, people and supplier evidence proportionate to its remit. It should not choose model thresholds, design the platform release process or own issue remediation, because those acts compromise later assurance. Audit can advise on auditability without becoming the control owner. Management owns closure; audit assesses whether closure is supported.

The three lines are relationships, not rigid departments. A person may hold several roles in a small entity, and a security team may be first line for security operations while challenging product implementation elsewhere. The Decision-Right Record identifies the role played for the specific object. Conflict safeguards include alternate approval, external validation, direct governing-body access, recusal and a threshold at which additional separation becomes mandatory.

Worked allocationTest the charter against real conflicts

Shared gateway

The central platform owner operates routing, tenancy, metering, common evaluation hooks and service recovery. Security owns identity and privileged-access standards. Enterprise risk sets the minimum control envelope and escalation thresholds. Each domain owns intended use, source declarations, local tests, user communication and outcomes. Provider choice can be delegated to the platform inside approved categories, while a novel consequential use returns to the domain, procurement, specialists and risk accepter for a specific decision.

Credit decision

The credit business owns policy, use, customer treatment and first-line monitoring. Data owners determine meaning and authorised purpose. The platform supplies identity, release, evidence and rollback services without accepting credit risk. Independent model risk validates within the applicable banking framework, but it does not operate the model or decide the business appetite. A named senior manager accepts residual risk within board-approved bounds. Material departures, adverse evidence or disputed customer consequences follow the declared escalation and appeal route.

Low-risk experiment

A domain can proceed under a thin baseline when the object is reversible, affected parties and data are bounded, spend is capped and prohibited actions are enforced. The record names the experiment owner, outcome measure, evidence location and stop date. Central review is unnecessary for every configuration if the invariant contract is machine checked. Expansion to sensitive data, external users, consequential decisions or material vendor commitment creates a new object and decision.

Vendor platform

Outsourcing operation does not transfer management accountability or applicable provider and deployer duties. The enterprise still decides intended use, data access, evaluation, incident response, customer remedy, exit and evidence retention. Procurement owns negotiation and commercial process, not permissible use. The platform owner integrates supplier controls and monitors service. Risk and legal specialists challenge the arrangement. The contract must give the evidence custodian and independent assurance functions practical access, including after termination.

Second-line conflict

A risk function authors a model-evaluation standard because it has the competence and independence to interpret appetite. If it also implements the evaluation service, another qualified actor validates the implementation and exceptions. Release remains a management decision within delegated limits, subject to the formal stop rights in the standard. Where capacity forces temporary role combination, the record names the conflict, compensating review and separation date rather than pretending the line remains independent.

Small organisation

One executive may own platform service, domain product and budget while serving as risk accepter. The organisation documents each hat, uses an external or board-level reviewer for material releases and defines triggers for separation, such as regulated scope, irreversible action, sensitive affected groups or growing supplier commitment. Simplicity comes from fewer people, not fewer decisions. Evidence and appeal remain available even when the chart is compact.

Federation failure and direct-provider exception

If local teams interpret one standard differently, leadership should repair the standard, reference tests and escalation path before recentralising every decision. Persistent variance may reveal ambiguous semantics or a missing service. A domain seeking direct provider access receives an explicit accepter, data and spend envelope, compensating controls, evidence return, expiry and reintegration route. A permanent exception with no review is a competing platform without accountable ownership.

Retirement dispute

A platform may propose removal because a route is uneconomic. A regulated domain may depend on it for a small but consequential workload. The platform product owner provides cost, service and migration evidence. The domain owns the operational consequence and funds requirements beyond the common contract when approved. An executive decider resolves the portfolio trade-off within risk appetite. The result records continued service, bounded domain ownership, migration or retirement, with dates, customer obligations and evidence preserved.

Prepared authorityDesign the incident before the alarm

A cross-enterprise incident is the worst time to discover that the gateway operator can observe failure but cannot stop a provider, or that a domain can stop a workflow but nobody can notify affected customers. Pre-declare kill rights by object. The platform may suspend a model version, route, credential or provider across products when a specified technical or security threshold is met. A domain may suspend its workflow and initiate customer protection. Executives arbitrate wider business continuity and risk when containment creates material secondary harm.

Detection opens one incident record with links to local cases. The detector need not be the decider. Triage identifies scope, evidence confidence, affected principals and reversibility. Kill authority contains the smallest adequate object. Platform and domain owners confirm propagation rather than assuming a central toggle reached every cached or embedded instance. Notification owners apply contractual, regulatory and customer criteria. Remediation changes the relevant service, source, policy, model or workflow, then registered tests and independent checks govern restoration.

Rollback and replay are separate rights. Technical rollback restores a version; the outcome owner decides which past decisions require review, correction, compensation or communication. Issue closure names evidence for containment, root cause, recovered service, affected-party response and control improvement. The evidence custodian retains dissent and failed actions. Kill authority is tested through exercises, because a right that cannot be executed through current identities, dependencies and supplier contracts is only a sentence in a policy.

Enforceable federationMake central invariants and local duties test each other

Federation is not a softer synonym for decentralisation. It is a contract between shared services and accountable local execution. Central owners publish machine-testable identity, evidence, evaluation registration, incident, metering and lifecycle invariants. Domain owners supply source, purpose, policy, scenario, outcome and affected-party declarations in defined forms. The release path tests both. Local extension points are versioned, and failures identify which owner must act.

The contract includes exception creation, renewal and return. A domain cannot bypass the baseline by labelling a route specialised. The centre cannot reject a legitimate requirement merely because the common abstraction lacks it. Evidence from exceptions and shadow services informs platform roadmap, domain capability or retirement. Review distinguishes useful diversity from repeated reintegration. A central standard with no service, reference implementation, test or escalation mechanism is advice, not a functioning control-plane decision.

Evidence returns in both directions. The platform supplies service version, inherited controls, route, provider, cost, trace and incident receipt. The domain supplies intended use, data and policy versions, local evaluations, outcome monitoring and exception status. Specialists receive the subset needed for challenge. Internal audit receives access sufficient to reconstruct allocation and performance without becoming an operator. Protected customer or security evidence remains purpose and role constrained.

Federation reviews ask whether local owners have competence and operating capacity, whether common contracts are stable, whether exceptions converge or proliferate, and whether incidents expose ownership gaps. The answer may move one decision centrally while moving another outward. Federation is deliberate when each movement has evidence, a date and a preserved escalation route. It fails when an organisational slogan substitutes for enforceable interfaces and named decision owners.

Operating evolutionMove from scarce central capacity to deliberate federation

Early programmes often need a central nucleus. It can establish provider contracts, core identity, reference evaluations, evidence formats and the first paved route. The charter should record why central authority is necessary, which decisions remain domain owned and the conditions for reassignment. Useful conditions include trained domain decision owners, stable interfaces, adequate incident response, common control tests, accessible evidence, demonstrated local monitoring and a functioning appeal path.

Transition decision family by decision family. A platform team may retain gateway and telemetry operation while domains gain authority to configure approved routes and release lower-consequence changes. Model validation may remain specialist and independent. High-consequence risk acceptance may remain with named executives. Budget allocation may shift after unit economics become observable. A single date for federation is less credible than a set of reviewable rights with evidence thresholds.

Capacity is not merely headcount. A domain owner needs time, information and authority to monitor outcomes and act. A second-line challenger needs access, competence and freedom from delivery pressure. A platform owner needs a product mandate, service resources and the ability to retire unsupported paths. Internal audit needs access and independence. Assigning a right without those conditions produces nominal accountability and practical escalation to whoever still has the tools.

Board reporting should show material ownership gaps, conflicts, expired exceptions, unresolved escalations, kill tests, evidence access and transitions. It should not compress them into a maturity score. Management can attest that rights are assigned and operating, while independent assurance tests selected claims. The governing body evaluates whether appetite, resources and accountability remain appropriate as the portfolio, jurisdictions, providers and consequences change.

Retirement is a decisive test. The platform can recommend removal and show cost, demand, support and migration evidence. It should not unilaterally strand a regulated workflow. The domain cannot require indefinite subsidy without naming consequence, funding and exit. A named executive resolves the cross-portfolio conflict. The resulting record specifies service period, investment, migration, acceptance and preserved evidence, allowing each owner to perform a bounded obligation.

Management routineKeep decision rights current in ordinary work

Ownership records should enter portfolio planning, architecture review, release, supplier management and incident exercises rather than live in a separate governance library. New services declare their decision families before procurement or build commitment. Material changes reopen the affected rights, not every historical choice. Quarterly service reviews examine stale owners, inaccessible evidence, combined roles, expired delegations and untested escalation. Business planning connects capacity and funding to the obligations each owner has accepted.

People also need usable routes to contest a decision. Product teams can challenge a central standard with evidence of domain harm or missing capability. Specialists can challenge weak local monitoring without taking over the product. Affected-party representatives can surface consequences that technical measures omit. The accountable decider records the response, dissent and appeal. This discipline turns escalation into a designed feedback mechanism instead of a personal contest between senior functions.

Interactive instrumentControl Plane Ownership Resolver

Choose the decision object, consequence, competence, consistency, independence and operating conditions. The Resolver returns one of exactly five routes plus a Decision-Right Record, conflict safeguard, evidence owner and escalation. It does not produce an ownership-fit or maturity score.

Exactly five outcomesReturn an authority route, not a fit score

Evidence boundaryRoles inform allocation without deciding it automatically

NIST and ISO sources support lifecycle governance, named actors, organisational responsibility, measurement and management. The IIA Three Lines Model and COBIT support distinctions among management, governance, challenge and independent assurance. They do not prescribe one universal AI organisation. NIST security and zero-trust records inform separation, least privilege, policy decisions and continuous evaluation rather than assigning product outcomes to security.

PRA and Federal Reserve guidance supports senior accountability and effective independent validation within its financial-services scope. Those records are not general mandates that every enterprise create an identical model-risk function. DORA and FinOps inform platform-product and collaborative commercial responsibilities. Production-ML research supports explicit tests, dependencies and organisational seams, but it does not prove central ownership.

GDPR, DORA and the EU AI Act distinguish roles and duties when their provisions apply. Outsourcing and platform use do not erase accountable enterprise responsibilities. Applicability depends on processing, entity, system, actor, jurisdiction, provision and timing. The Control Plane Decision-Rights Charter, Decision-Right Record, five ownership tests and Ownership Resolver are this article’s synthesis.

The practical test is not whether an AI office appears on the chart. It is whether every material object has one authorised decider, informed proposers, capable operation, bounded risk acceptance, independent challenge where required, accessible evidence, executable stop rights and a known escalation path. The enterprise control plane is owned decision by decision.