Shared responsibility starts at the AI service boundary

A firm buying an AI service can collect a long list of supplier controls and still leave the most important questions unowned. The vendor secures its model endpoint. The firm controls the documents sent to it. A systems integrator connects the endpoint to a customer workflow. When a restricted document reaches the wrong employee, all three can truthfully say that their own control worked.

The gap lies in the interfaces. Shared responsibility should be recorded as a set of operational handovers: who decides, who acts, what evidence each party can see and how quickly it moves. The buyer needs that map before production, not when the first incident reveals that the provider and the firm assumed different owners.

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.

Take data access first. The provider may protect storage and transmission, while the firm decides which records the AI service may receive. If retrieval permissions are copied incorrectly, encryption at the provider does not stop the system returning material to the wrong employee. The control owner is the person able to correct the permission mapping, not the party whose security statement mentions data protection.

Take a suspected exposure next. A model provider may know the deployed model version but not the customer’s prompt, retrieved documents or decision that followed. The firm may know the customer impact but have no access to a model change log. An investigation requires both records to meet at a named point. The same reasoning applies to service recovery: who can suspend the feature, route work back to a human process and decide when the AI path can reopen?

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

For every consequential control, write four short entries. First, the event that starts it: an access change, model release, anomalous output, complaint or outage. Second, the party with authority to act. Third, the evidence the party must receive. Fourth, the next party and the deadline for handing it over. Where the provider retains sole access to evidence, test the request process with a plausible case rather than accepting a contractual adjective.

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 supplier review with a short list of handovers they can test. If no one can name who retrieves an output trace, authorises suspension or restores the manual route, the system is not ready for a production decision, however complete the supplier questionnaire looks.