The shared-responsibility trap

Enterprises share AI for good reasons. A common model gateway can enforce approved providers and regions. A retrieval platform can standardise provenance. An evaluation service can make regressions visible. A tool registry can constrain actions. Shared capabilities reduce repeated engineering and create a place to improve controls once for many users. The CNCF platform guidance captures the basic operating principle: a platform is a product for internal users, and those users should not have to operate every underlying service themselves.[7]

Yet a shared component also joins failure domains. Sculley and colleagues described how machine-learning systems accumulate system-level debt through entanglement, undeclared consumers, data dependencies and boundary erosion.[9] A model route that is harmless for meeting summaries may be material for credit decisions. A retriever that is fresh enough for a help page may be stale for a policy-controlled workflow. Reuse increases the number of consumers while making the consequences less uniform.

Thought experiment one: hold the model fixed

Give the same foundation model, prompt template and gateway to two applications. Application A drafts an internal meeting summary that a participant can edit. Application B drafts a notice that could alter a customer’s access to credit, although a reviewer must approve it. Nothing about the model component has changed. Only the consequence, affected party and reliance path have changed.

If the platform owner were accountable for both outcomes merely because it owns the model route, the organisation would assign decision risk to a team that may not know the policy, customer context or human-review conditions. If each domain team were accountable for the model route, the organisation would assign infrastructure and provider risk to teams that cannot inspect or roll back the shared service. Component ownership and decision ownership are different because the same component can participate in unlike consequences.

Why “the AI CoE owns it” is an incomplete answer

Full centralisation looks attractive because one group can set standards and remove ambiguity. It works reasonably well for the model gateway, registry, common evaluation tooling and control plane. It fails when the centre is asked to own local process truth, customer consequence, operational fallback or policy interpretation. The centre then becomes accountable for facts it cannot observe and changes it cannot authorise.

Full federation has the opposite defect. Domain teams understand consequences, but duplicate model access, evaluation machinery, incident integrations and security controls. Variance grows, and failures in a common provider or model are discovered separately. The useful design is neither a compromise slogan nor a fixed hub-and-spoke chart. Centralise the surface whose controls and evidence are genuinely common; keep accountability local where consequence and meaning remain local.

The assignment test: control, evidence and mandate

An accountable label is credible only when three conditions meet on the same bounded surface. First, the owner has control: authority to change, stop, restrict or recover the surface. Second, the owner has evidence: timely signals that reveal its condition and effects. Third, the owner has a mandate: delegated responsibility, competence and resources for the consequence.

The expression is Boolean rather than a maturity score. If any term is false, the role may coordinate or advise, but it cannot carry sole accountability for that surface.

Thought experiment two: move one authority

Return to the credit incident. In version one, operations sees the behavioural alert and understands its severity, but only the platform team can roll back the route. Operations is an informed coordinator, not the containment owner. In version two, operations receives a scoped kill-switch for that domain route. Evidence and mandate stay constant; only containment authority moves. Operations can now act as incident commander while the platform team executes or supports a rollback under the commander’s decision.

This does not mean every owner needs direct production credentials. Control can be implemented through an approved command path with tested response time. The essential property is that the owner’s decision reliably changes the system. A committee that must reconvene after an incident has already spread does not possess operational control. A risk function that can block release but cannot judge a customer effect does not possess the consequence mandate. A platform team that sees uptime but not decision quality lacks the relevant evidence.

The test also exposes a common misuse of RACI. RACI can index who is responsible, accountable, consulted and informed. It does not state what the accountable party may stop, which evidence it receives, how quickly another team must execute its decision, or when acceptance expires. RACI is a directory. The operating contract is the executable relationship.

flowchart LR
  A["Everyone was accountable until<br/>something changed"] --> B["On this page"]
  B --> C["The shared-responsibility trap"]
  C --> D["The assignment test, control,<br/>evidence and mandate"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#007D68,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Six ownership surfaces that must not collapse

The practical unit is not “AI” as a single object. A deployed system combines model routes, context, tools, evaluation, operations and business decisions. Raji and colleagues’ end-to-end audit framework is useful here because it treats accountability as a lifecycle process that leaves inspectable artefacts, rather than as a post-deployment review.[8] The operating model extends that lifecycle view into live service ownership.

These surfaces can have different accountable owners. That is not ambiguity if the seam is explicit. The platform product owner can be accountable for the runtime route. A domain product or process owner can be accountable for intended use. A data owner can authorise a purpose and withdrawal condition. An evaluation lead can own test integrity and a release veto without accepting the business risk. Operations can command incidents. A named business risk owner can accept the residual consequence.

The control functions remain important precisely because they are not the operators. Independent validation, security, privacy, compliance and audit should challenge claims, test evidence and preserve separation. The PRA’s model-risk policy illustrates the distinction between ultimate board responsibility, delegated execution and evidence of effective oversight.[10] The exact regulatory scope varies, so the transferable mechanism is separation between operating ownership, independent challenge and risk acceptance.

The operating contract: what a RACI leaves out

An operating contract is a versioned record for one shared service and one consuming use. It does not replace organisational policy, an architecture decision record or a risk register. It joins them at the point where a live service can change a business outcome. Each contract should be short enough to review and precise enough to test.

The contract has six linked records. The ownership record names the bounded surface and accountable role. The authority record states the commands that role may issue and the service level for execution. The objective record defines indicators, thresholds and windows. The evidence record names the telemetry, evaluation run and receipts that support the claim. The change record lists events that reopen review. The risk record states the remaining risk, acceptor, expiry and trigger.

Authority must be stated as verbs

“Owns the platform” is too broad. Write the decision rights as verbs: approve a model route, block a release, revoke a tool, withdraw a data purpose, switch to degraded mode, declare severity, command containment, reconcile external effects, accept a bounded risk, or retire the use. The verb should name an observable system transition. NIST’s zero-trust architecture provides a useful adjacent principle: access should be decided for resources and requests, not inferred from network location or broad ownership.[6] The same discipline helps operating authority. A title does not imply a production capability.

Where authority crosses teams, record a response objective. If the domain incident commander can request a platform route rollback, the platform must commit to execute or reject that command within a defined interval and preserve the reason. Otherwise the domain owner has nominal control. For irreversible or fast-moving effects, an automated policy gate may be the only authority path that meets the required time.

Residual risk is a decision, not a parking place

NIST defines residual risk as risk remaining after responses or controls have been applied, and its AI RMF playbook prompts organisations to document who maintains, monitors and updates the system as well as which risks are accepted or transferred.[2][5] A residual-risk entry that says “hallucination risk accepted” is not decision-ready. It must identify the failure, affected use, control boundary, supporting evidence, acceptor, expiry and event that reopens the decision.

Acceptance belongs with the role that has the mandate over the consequence. The platform owner may accept a bounded availability trade-off for the shared service. It should not accept the risk that a credit reviewer will miss an unsupported covenant. A domain executive may accept that use with mandatory review and measured sampling, but should not accept an unbounded provider-retention configuration. The two risks are related yet owned on different surfaces.

Third-party contracts do not erase this distinction. DORA, for financial entities in scope, treats ICT third-party risk as part of the entity’s own risk-management framework.[11] The broader lesson is operational: a supplier can own its service obligation, while the consuming organisation retains the decision about whether the remaining dependency risk is acceptable for its use.

SLOs for AI must reach beyond uptime

Google’s SRE guidance uses service level objectives to make reliability decisions explicit and error budgets to align product and operational incentives.[4][12] Shared AI needs that discipline, but a single availability target is insufficient. A service can return a fluent response on time while violating the claim for which the business relies on it.

An AI operating contract therefore needs a stack of indicators. Infrastructure indicators cover availability, latency and capacity. Behavioural indicators cover task success, refusal, calibration or harmful failure for the declared use. Evidence indicators cover citation support, source freshness and trace completeness. Authority indicators cover entitlement decisions and blocked actions. Human-operation indicators cover queue age, evidence engagement and fallback capacity. Outcome indicators cover the business effect that justified the service.

The objectives need a release consequence. A target without a pre-agreed response is a dashboard. The contract should state whether a breach blocks new releases, reduces autonomy, shifts traffic, increases human sampling or suspends the use. The measurement owner must be able to reproduce the indicator from governed evidence. The accountable owner must have authority to invoke the response.

Not every indicator is suited to an error budget. A small number of policy breaches or unauthorised data accesses may have a zero-tolerance stop condition rather than an allowable failure budget. Behavioural quality can require stratified thresholds because a high aggregate score can hide a critical cohort. Human queue capacity needs peak and absence scenarios. The objective is not to force every risk into one metric; it is to pre-decide what evidence changes what action.

Incident command must follow effects, not only exceptions

Probabilistic systems can fail while every API returns 200. A behavioural incident may begin with an unusual refusal distribution, unsupported claim, stale source, tool sequence or human override pattern. NIST SP 800-61 Revision 3 treats incident response as part of the wider cycle of preparation, detection, response and recovery.[13] Shared AI adds the need to reconcile which decisions and external effects were touched by a changed component.

The operating contract names one incident commander for a severity class. The commander need not perform every task. The platform team can isolate a route. The data owner can revoke a purpose. The domain team can stop a workflow and inspect affected cases. Legal or compliance can determine notification. The commander owns prioritisation, containment choice, cross-team coordination and closure criteria.

Severity should combine service degradation with consequence. A model gateway outage may be a high operational event but produce no incorrect decisions because the domain falls back cleanly. A 0.5 per cent unsupported-claim rate may look small yet be severe if it affects legally significant notices. The severity policy should name affected parties, action reversibility, data sensitivity, scale, detectability and recovery cost.

Closure requires four receipts. A containment receipt proves the risky path stopped. An effect receipt identifies what the system actually changed. A recovery receipt proves the replacement path meets its objectives. A learning receipt links the event to a regression case, control change or consciously renewed acceptance. Closing the ticket without effect reconciliation leaves the business incident open.

Two worked systems

Minimal example: a shared policy summariser

A platform team offers an internal summarisation API over approved policy documents. One operations team uses it to draft a daily digest for staff. The digest links every statement to a source and cannot write to operational systems. A staff editor publishes the final message. The current process is reversible and low consequence.

The platform owner is accountable for model routing, access control, source ingestion and technical recovery. The operations product owner is accountable for the digest’s purpose, editorial review and usefulness. The data owner approves which policy collection may be retrieved. A lightweight operating contract defines a 99.5 per cent request-success objective, a source-support threshold on a sampled set, a source-freshness check, and a fallback to manual compilation. The product owner accepts the bounded risk of omission until the next scheduled review.

Notice what the contract does not create. It does not add a permanent AI council, independent model validation or twenty-four-hour specialist on-call. Consequence is low, effects are reversible and the human editor sees the sources. Proportionality means preserving the ownership join without importing the full control stack of a consequential decision system.

Production-shaped example: a shared credit-memo service

Now consider a synthetic commercial-credit workflow. A shared platform provides a model gateway, document extraction, governed retrieval, financial calculation tools, trace storage and evaluation execution. The domain application gathers evidence and drafts a memo for a competent credit reviewer. It cannot approve credit or change a limit. Even so, omissions can shape reviewer attention, delay a case or introduce unsupported rationale into the decision record.

The platform product owner is accountable for the common runtime, tool registry, trace integrity and platform SLO. The credit product owner is accountable for intended use, reviewer workflow, cohort definitions, local quality thresholds and fallback. Credit policy owns rule interpretation and supersession. Data owners approve customer and policy data purposes. The evaluation lead owns locked cases, adjudication and release-gate integrity. Operations commands incidents. A delegated credit-risk executive accepts the remaining risk for the bounded use.

A model-route change triggers platform canaries and every consuming domain’s declared impact pack. For credit, that pack includes scanned documents, covenant extraction, refusal behaviour, material-claim support and reviewer handoff. The platform may promote the route only when the generic gate and all material consumer gates pass, or when affected consumers remain pinned. This prevents a common component decision from silently rewriting a local risk acceptance.

Suppose the route still reaches the credit application through a configuration error. The behavioural monitor detects the refusal shift while uptime stays green. Operations declares a domain-severity incident. The platform owner pins credit to the previous route. The credit team identifies affected cases and prioritises manual review. Evaluation adds the exact document layouts as regression cases. The risk owner decides whether the new route may return after evidence is complete. Every step is possible because the contract joined authority to evidence before the incident.

stateDiagram-v2
  [*] --> Claim
  state "Thought experiment one: hold<br/>the model fixed" as Claim
  state "Why “the AI CoE owns it” is an<br/>incomplete answer" as Test
  state "Thought experiment two, move<br/>one authority" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

Negative control and failure boundary

A case where the full mechanism should add little

Take a research team running a local, non-shared model in a disposable sandbox on synthetic data. It produces exploratory notes that cannot leave the workspace or call a tool. One team owns the code, data, runtime and interpretation. No external party relies on the result. Standard repository ownership, access control and experiment logging may be enough. A multi-surface operating contract with independent evaluation and an incident commander would create ceremony without materially improving control.

This negative control matters because the proposal is not “more governance for every model”. Its predicted value rises when reuse, consequence, organisational distance and change frequency rise. If one team can observe and control the whole low-consequence system, the ownership join already exists. The mechanism becomes useful when those properties separate.

Where the mechanism breaks

The operating model cannot rescue an organisation that withholds authority or resources from named owners. It also fails when telemetry cannot connect a shared component version to affected decisions, when shadow use bypasses the inventory, when outsourced services expose no workable containment path, or when domain experts cannot maintain labels and thresholds. A signed contract over absent capabilities is theatre.

There is also a knowledge boundary. Not every harmful effect is immediately measurable, and not every evaluator is independent in a meaningful sense. Correlated model judges can miss the same defect. Human reviewers can disagree. Long-latency harms may appear after the acceptance window. The contract should preserve uncertainty and specify information-seeking actions rather than convert missing evidence into a green status.

Executable artefact: validate the operating contract

The following Python artefact turns the central claim into assertions. It uses synthetic roles and systems. A contract passes only when accountable owners hold required authority, SLOs name measurement owners, consequential surfaces have independent evaluation, incidents have command and containment rights, and residual-risk acceptance is authorised and unexpired.

The positive case represents a shared gateway, a credit use and a customer-data entitlement. The negative case deliberately assigns everything to an AI council that has no operational authority. Run the script with Python 3.10 or later. It uses only the standard library.

#!/usr/bin/env python3
"""Validate a synthetic operating contract for a shared AI service.

The validator checks whether accountability is backed by authority, evidence,
service objectives, incident command, independent evaluation and time-bounded
residual-risk acceptance. It uses only the Python standard library.
"""

from __future__ import annotations

from dataclasses import dataclass
from datetime import date
from typing import Any, Iterable


@dataclass(frozen=True)
class Finding:
    code: str
    path: str
    message: str

    def __str__(self) -> str:
        return f"{self.code} at {self.path}: {self.message}"


def _missing(mapping: dict[str, Any], keys: Iterable[str]) -> list[str]:
    return [key for key in keys if mapping.get(key) in (None, "", [], {})]


def validate_contract(contract: dict[str, Any], *, as_of: date | None = None) -> list[Finding]:
    """Return all findings. An empty list means the contract passes."""
    as_of = as_of or date.today()
    findings: list[Finding] = []

    roles = contract.get("roles", {})
    surfaces = contract.get("surfaces", [])

    if not roles:
        findings.append(Finding("ROLE-000", "roles", "No roles are defined."))
        return findings

    for index, surface in enumerate(surfaces):
        path = f"surfaces[{index}]"
        missing = _missing(
            surface,
            (
                "name",
                "accountable",
                "responsible",
                "consequence",
                "authorities_required",
                "slo",
                "evidence",
                "change_triggers",
            ),
        )
        if missing:
            findings.append(
                Finding("SURFACE-001", path, f"Missing required fields: {', '.join(missing)}.")
            )
            continue

        accountable = surface["accountable"]
        role = roles.get(accountable)
        if role is None:
            findings.append(
                Finding("OWNER-001", f"{path}.accountable", f"Unknown role '{accountable}'.")
            )
            continue

        required = set(surface["authorities_required"])
        held = set(role.get("authorities", []))
        absent = sorted(required - held)
        if absent:
            findings.append(
                Finding(
                    "AUTH-001",
                    f"{path}.accountable",
                    f"'{accountable}' lacks required authority: {', '.join(absent)}.",
                )
            )

        slo = surface.get("slo", {})
        slo_missing = _missing(slo, ("indicator", "target", "window", "measurement_owner"))
        if slo_missing:
            findings.append(
                Finding("SLO-001", f"{path}.slo", f"Incomplete SLO: {', '.join(slo_missing)}.")
            )
        elif slo["measurement_owner"] not in roles:
            findings.append(
                Finding(
                    "SLO-002",
                    f"{path}.slo.measurement_owner",
                    f"Unknown measurement owner '{slo['measurement_owner']}'.",
                )
            )

        if surface["consequence"] in {"material", "irreversible"}:
            evaluator = surface.get("independent_evaluator")
            if not evaluator:
                findings.append(
                    Finding(
                        "EVAL-001",
                        path,
                        "Material or irreversible surface has no independent evaluator.",
                    )
                )
            elif evaluator not in roles:
                findings.append(
                    Finding("EVAL-002", f"{path}.independent_evaluator", "Unknown role.")
                )
            elif evaluator in {surface["accountable"], surface["responsible"]}:
                findings.append(
                    Finding(
                        "EVAL-003",
                        f"{path}.independent_evaluator",
                        "Evaluator is also the accountable or responsible builder/operator.",
                    )
                )

    incident = contract.get("incident", {})
    incident_missing = _missing(
        incident,
        ("commander", "containment_owner", "effect_reconciliation_owner", "severity_policy"),
    )
    if incident_missing:
        findings.append(
            Finding(
                "INC-001",
                "incident",
                f"Incomplete incident contract: {', '.join(incident_missing)}.",
            )
        )
    else:
        commander = incident["commander"]
        commander_role = roles.get(commander)
        if commander_role is None:
            findings.append(Finding("INC-002", "incident.commander", "Unknown role."))
        elif "command_incident" not in commander_role.get("authorities", []):
            findings.append(
                Finding(
                    "INC-003",
                    "incident.commander",
                    f"'{commander}' cannot command an incident.",
                )
            )

        containment_owner = incident["containment_owner"]
        containment_role = roles.get(containment_owner)
        if containment_role is None:
            findings.append(Finding("INC-004", "incident.containment_owner", "Unknown role."))
        elif "contain" not in containment_role.get("authorities", []):
            findings.append(
                Finding(
                    "INC-005",
                    "incident.containment_owner",
                    f"'{containment_owner}' cannot contain the service.",
                )
            )

    for index, risk in enumerate(contract.get("residual_risks", [])):
        path = f"residual_risks[{index}]"
        missing = _missing(risk, ("id", "statement", "acceptor", "evidence", "accepted_until", "review_trigger"))
        if missing:
            findings.append(
                Finding("RISK-001", path, f"Incomplete residual-risk record: {', '.join(missing)}.")
            )
            continue

        acceptor = risk["acceptor"]
        acceptor_role = roles.get(acceptor)
        if acceptor_role is None:
            findings.append(Finding("RISK-002", f"{path}.acceptor", "Unknown role."))
        elif "accept_risk" not in acceptor_role.get("authorities", []):
            findings.append(
                Finding(
                    "RISK-003",
                    f"{path}.acceptor",
                    f"'{acceptor}' has no delegated residual-risk authority.",
                )
            )

        try:
            accepted_until = date.fromisoformat(risk["accepted_until"])
        except (TypeError, ValueError):
            findings.append(
                Finding("RISK-004", f"{path}.accepted_until", "Use an ISO date such as 2099-12-31.")
            )
        else:
            if accepted_until < as_of:
                findings.append(
                    Finding(
                        "RISK-005",
                        f"{path}.accepted_until",
                        f"Acceptance expired on {accepted_until.isoformat()}.",
                    )
                )

    if not contract.get("residual_risks"):
        findings.append(
            Finding(
                "RISK-000",
                "residual_risks",
                "No residual-risk record exists; use an explicit 'none identified' record if applicable.",
            )
        )

    return findings


def print_result(name: str, contract: dict[str, Any]) -> None:
    findings = validate_contract(contract)
    if not findings:
        print(f"{name}: PASS")
        return
    print(f"{name}: FAIL ({len(findings)} finding(s))")
    for finding in findings:
        print(f"  - {finding}")


GOOD_CONTRACT: dict[str, Any] = {
    "roles": {
        "platform_owner": {"authorities": ["change_runtime", "contain", "command_incident"]},
        "domain_owner": {"authorities": ["change_use", "accept_risk", "reconcile_effects"]},
        "data_owner": {"authorities": ["approve_data_use", "withdraw_data_use"]},
        "evaluation_lead": {"authorities": ["approve_evidence", "block_release"]},
        "operations_lead": {"authorities": ["command_incident", "contain"]},
    },
    "surfaces": [
        {
            "name": "model gateway and routing",
            "accountable": "platform_owner",
            "responsible": "platform_owner",
            "consequence": "material",
            "authorities_required": ["change_runtime", "contain"],
            "slo": {
                "indicator": "eligible requests with a supported model response",
                "target": ">= 99.5%",
                "window": "rolling 28 days",
                "measurement_owner": "platform_owner",
            },
            "evidence": ["route manifest", "canary results", "runtime telemetry"],
            "change_triggers": ["model version", "routing policy", "provider region"],
            "independent_evaluator": "evaluation_lead",
        },
        {
            "name": "credit-memo intended use and outcome",
            "accountable": "domain_owner",
            "responsible": "domain_owner",
            "consequence": "material",
            "authorities_required": ["change_use", "accept_risk"],
            "slo": {
                "indicator": "reviewed memos without a material unsupported claim",
                "target": ">= 98.0%",
                "window": "monthly risk-stratified sample",
                "measurement_owner": "evaluation_lead",
            },
            "evidence": ["adjudicated sample", "decision receipts", "override review"],
            "change_triggers": ["credit policy", "customer cohort", "review workflow"],
            "independent_evaluator": "evaluation_lead",
        },
        {
            "name": "customer-data entitlement",
            "accountable": "data_owner",
            "responsible": "platform_owner",
            "consequence": "irreversible",
            "authorities_required": ["approve_data_use", "withdraw_data_use"],
            "slo": {
                "indicator": "requests with valid purpose and entitlement decision",
                "target": "100%",
                "window": "per request",
                "measurement_owner": "evaluation_lead",
            },
            "evidence": ["policy decision log", "purpose code", "entitlement receipt"],
            "change_triggers": ["data purpose", "legal entity", "role mapping"],
            "independent_evaluator": "evaluation_lead",
        },
    ],
    "incident": {
        "commander": "operations_lead",
        "containment_owner": "platform_owner",
        "effect_reconciliation_owner": "domain_owner",
        "severity_policy": "Severity follows affected decisions and data, not only uptime.",
    },
    "residual_risks": [
        {
            "id": "RR-17",
            "statement": "A supported model can still omit a material covenant in an unusual document layout.",
            "acceptor": "domain_owner",
            "evidence": ["locked evaluation run EV-204", "mandatory competent review"],
            "accepted_until": "2099-12-31",
            "review_trigger": "material omission, document-template change, or model-route change",
        }
    ],
}


BAD_CONTRACT: dict[str, Any] = {
    "roles": {
        "ai_council": {"authorities": []},
        "platform_team": {"authorities": ["change_runtime"]},
        "domain_team": {"authorities": ["change_use"]},
    },
    "surfaces": [
        {
            "name": "all shared AI",
            "accountable": "ai_council",
            "responsible": "platform_team",
            "consequence": "material",
            "authorities_required": ["contain", "accept_risk"],
            "slo": {"indicator": "uptime", "target": "99.9%", "window": "monthly"},
            "evidence": ["dashboard screenshot"],
            "change_triggers": ["major release"],
            "independent_evaluator": "platform_team",
        }
    ],
    "incident": {
        "commander": "ai_council",
        "containment_owner": "platform_team",
        "effect_reconciliation_owner": "domain_team",
        "severity_policy": "Use infrastructure severity only.",
    },
    "residual_risks": [
        {
            "id": "RR-X",
            "statement": "Unknown behavioural risk.",
            "acceptor": "ai_council",
            "evidence": ["meeting note"],
            "accepted_until": "2000-01-01",
            "review_trigger": "annual review",
        }
    ],
}


if __name__ == "__main__":
    print_result("GOOD_CONTRACT", GOOD_CONTRACT)
    print_result("BAD_CONTRACT", BAD_CONTRACT)

The validator is intentionally narrow. It does not prove that thresholds are correct, evidence is unbiased or an acceptor is competent. It proves a prior condition: the organisation has not assigned accountability to a role that lacks the declared means to exercise it. The next extension should connect each evidence field to machine-readable run IDs and each authority to a tested policy or workflow command.

A decision instrument for the operating-model workshop

Begin with one use and one end-to-end failure, not an enterprise org chart. Bring the platform owner, domain owner, operations, data, evaluation, security and risk roles into the same session. Walk the failure through the six surfaces. The following questions expose most ownership gaps.

End the workshop with a versioned contract, not minutes. Every unresolved item should have an owner and stop condition. Every accepted risk should have an expiry. Every SLO should have a response. Every cross-team command should have a tested path. Every shared component should know its material consumers, and every consumer should know which shared changes can alter its evidence.

This operating rhythm should then enter ordinary work. Quarterly review alone is too slow for provider changes and incidents. Review is event-driven when a declared trigger fires, with a periodic check to catch silent drift. Platform planning uses consumer SLOs and incidents to prioritise shared improvements. Domain planning funds labels, reviewer capacity and fallback. Risk forums review residual decisions, not replace service ownership.

Make ownership executable before making AI shared

Shared AI is not governed by deciding whether the platform or the domain owns “the AI”. That question is too coarse. The runtime, tools, context, evaluation, service and business decision are different control surfaces. They fail at different speeds, produce different evidence and carry different consequences.

Assign accountability only where authority, evidence and mandate meet. Where they do not meet, split the surface and write the interface between owners. The platform owns common capabilities and their operability. The domain owns intended use, human process and business effect. Data owners govern purpose and withdrawal. Evaluation owns test integrity and release evidence. Operations commands incidents. One authorised role accepts each bounded residual risk.

The architecture decision that changes is concrete. Do not launch a shared model gateway, tool layer or context service with only a central RACI and generic uptime target. Launch it with consumer-specific operating contracts, behavioural and evidence objectives, material-change triggers, a cross-team incident command path and effect reconciliation. Then prove the model through failure injection. When a shared change produces a local consequence, the organisation should already know who can see it, who can stop it, who repairs it and who decides whether the remaining risk is worth taking.