Shared responsibility starts at the AI service boundary

Buying an AI service creates responsibilities across several parties. A provider may secure its endpoint, a firm may control the documents supplied, and an integrator may connect the workflow. A restricted document reaching the wrong employee exposes a service-level failure even when individual component checks have passed.

Record the operational handovers between those parties: who decides, who acts, which evidence they need and when it must be available. The buyer should review this map before production so that supplier and internal assumptions can be tested against the same service boundary.

Start with the control, then assign the owner

The Cross Market Operational Resilience Group published an AI Shared Responsibility Model as baseline guidance for understanding AI security responsibilities between client firms and AI service providers. Its scope is the security of foundation models delivered as a service. The model is voluntary guidance, not a set of regulatory rules or supervisory expectations. It is a useful prompt, but the firm still has to analyse its contract and workflow. The boundary may also include a cloud host, retrieval system, tool provider and staff who approve or override results.

illustrative fixture

Guidance is a map to test

Swipe or scroll for the full diagram →

Assign operational handovers across the complete service.

Observed

CMORG describes a voluntary security-responsibility model for foundation models delivered as a service.

Inference

Use it to identify and rehearse the buyer’s access, incident-evidence and recovery handovers.

Evidence boundary

The model does not establish a provider’s security, fulfil every conduct or privacy duty, or prove a real incident response.

For data access, distinguish protection of storage and transmission from the decision about who may receive a record. Provider encryption cannot correct an erroneous retrieval-permission mapping. Assign that control to the party able to maintain and enforce the mapping, and verify the denied-request path.

For a suspected exposure, identify the records each party holds. The provider may know the model version while the firm holds the prompt, retrieved material and subsequent decision. Establish where those records meet and who can obtain them. Recovery needs the same clarity about suspension, alternative work routes and reopening authority.

Consider a retrieval connector installed by an integrator. The provider can authenticate the connector, yet only the firm knows which employees may see a customer file. If a group membership changes, the firm must update the source permission, the connector must carry it through and the AI service must enforce it at retrieval. The handover is incomplete until a denied request is tested at each point. A supplier’s encryption certificate cannot answer that access question.

Make each handover executable

Give each consequential handover four entries: its trigger, the party authorised to act, the evidence required and the recipient with the agreed response time. If only the provider can obtain a record, rehearse that request with a plausible case. Contract language should be supported by a demonstrated route to the evidence.

Put those entries into a short control table that an incident team can use. For the connector, it should name the owner of the identity mapping, the party that holds access logs and the person authorised to disable retrieval. Then rehearse a permission leak. Can the firm detect an exposure from its own telemetry? Who can retrieve the provider-side trace? Who closes the connector while the investigation runs? Record the elapsed time and the missing data.

Separate ownership from participation. A provider can supply logs without owning the customer’s decision to notify affected people. A firm can own the decision to pause a workflow without being able to disable a hosted feature on its own. If either action depends on another party, the dependency belongs in the operating runbook and the agreement.

The Bank of England’s prudential supervision report notes the model’s publication in the context of operational resilience. That mention does not turn voluntary guidance into a contract term. The buyer still has to decide whether its service design, supplier rights and internal teams can carry the assigned work.

CMORG’s scope also sets a boundary for this article. Investigating harmful outputs and deciding on customer remedies may require model-risk, conduct, privacy and service processes beyond a security control map. Those decisions must have owners too, but they should not be presented as requirements from the CMORG model. The security handovers are a starting point for a fuller operating agreement.

What this does not establish

A control map does not prove that a provider’s implementation is secure, that a firm meets sector rules, or that a third party will respond during a real incident. It gives reviewers a testable account of who is meant to do what. Assurance needs evidence from rehearsals, contracts, architecture and actual operation. Sector-specific duties and legal responsibility require separate assessment.

The CISO and service owner should leave the review with agreed handovers and evidence from the relevant tests. Where trace retrieval, suspension or recovery remains unowned, hold the affected scope or record a justified restriction. A completed questionnaire cannot close an operational gap.

illustrative diagram

Four parts of a deployment evidence map

Intended use

Name the target population and operating boundary.

Evaluation

Compare with the incumbent and separate group and time boundaries.

Oversight

Name the decision owner, review and abstention paths.

Operations

Retain provenance and monitor material changes.