The responsibility map every AI partnership needs

AI partnerships often look clear at the work-package level and ambiguous at the decision level. One party configures the model, another owns the application, a third provides data, and an internal committee approves “AI.” Yet nobody is named to accept a particular agent action, verify a release condition or stop the system during an incident.

A responsibility map should make those moments visible. A conventional RACI chart—responsible, accountable, consulted and informed—is useful, but it needs three additions for an AI system: the authority being exercised, the evidence that completes the work, and the escalation trigger when reality does not match the plan.

Map decisions before activities

Begin with decisions that change the system’s authority or exposure. Typical rows include approving the use case, accepting evaluation criteria, granting tool permissions, approving data use, accepting a release, responding to a severe incident, approving a material model change and retiring the service.

Activities sit beneath those decisions. “Run tests” is an activity. “Accept the observed failure rate for this bounded pilot” is a decision. A partner can run the tests; the operating organisation should name who accepts the result.

The NIST AI RMF Core calls for clear roles, responsibilities and lines of communication across the AI lifecycle, as well as documented human oversight and third-party controls. A map turns those expectations into an operating interface between teams and organisations.

Use RACI-plus for the consequential rows

For each decision or control, record seven fields:

Field	Question
Accountable	Which one role owns the decision or control outcome?
Responsible	Who performs the work required to reach it?
Consulted	Whose evidence or specialist judgement is required?
Informed	Who must know the result in time to act?
Authority	What may this decision grant, restrict, spend or expose?
Evidence	What artefact demonstrates the work and decision occurred?
Escalation	Which condition moves the issue to another owner or stops work?

Avoid naming whole departments as accountable. “Security” cannot answer a phone during an incident. Use role names that can be resolved to a person through the organisation’s authoritative directory, while keeping personal details out of public or broadly shared artefacts.

Build one map that crosses the boundary

Separate client and partner charts create gaps. Use one joined map for the workflow.

Decision or control	Client owner	Partner role	Evidence	Escalation trigger
Define acceptable actions	Product or operational owner (A)	Method specialist (C)	authority matrix	action outside approved set
Configure controls	Technical owner (A)	Engineer (R)	versioned configuration and test	control cannot be enforced
Accept evaluation design	Release owner (A)	Evaluation lead (R)	approved evaluation plan	material case lacks coverage
Approve production release	Release owner (A)	Evaluator (C)	signed decision and conditions	severe unresolved finding
Respond to incident	Incident commander (A)	Technical responder (R/C)	incident log and recovery evidence	data exposure or unsafe action
Retire access	Service owner (A)	Partner administrator (R)	access review and deletion record	account remains after deadline

The letters matter less than the conversations needed to agree them. If two parties both expect the other to make a decision, the map has found a control gap before an incident does.

Do not outsource the wrong accountability

A contract can assign a supplier responsibility for service levels, secure configuration, evaluation execution or prompt remediation. It cannot erase the deploying organisation’s accountability for choosing the system and granting it authority.

The UK National Cyber Security Centre’s supply-chain guidance notes that customer and vendor security responsibilities should be clearly defined while ownership remains with the organisation. This is especially important when consultants or maintainers receive privileged or remote access.

Make “shared responsibility” concrete. Shared work does not mean shared accountability for every outcome. Divide the system into control decisions and assign each one. Where legal responsibility depends on jurisdiction or contract, obtain appropriate advice; the operational map should not pretend to settle legal status.

Attach evidence to every important handoff

Verbal confirmation is fragile across organisations. Pair each handoff with a small, controlled artefact: approved scope, access grant, dataset manifest, test run record, severity decision, remediation verification, deployment approval or access-revocation receipt.

The NIST Privacy Framework describes a complex data-processing ecosystem in which organisations, service providers, developers and partners can hold different roles. It recommends using profiles to communicate privacy requirements between those entities. A responsibility map can play the same connective role for a specific AI workflow by showing who communicates a requirement, who implements it and what proves the handoff completed.

Evidence should be proportionate. A low-consequence content assistant does not need the same approval ceremony as an agent that changes customer accounts. But both need enough traceability to reconstruct who authorised the deployed behaviour.

Design escalation for uncertainty, not only failure

Teams usually define escalation for an outage. AI partnerships also need triggers for ambiguous evidence: a test cannot be reproduced, a model version changes without adequate notice, representative data is unavailable, a severe case has disputed classification, or the system begins using a new tool.

For each trigger, specify the immediate containment action, next decision owner and maximum time before an explicit accept-or-stop decision. “Discuss in the steering committee” is not sufficient if the agent can continue acting meanwhile.

The UK Sourcing Playbook recommends an explicit risk-allocation matrix and resolution planning for complex services. The responsibility map is where that allocation becomes executable day to day.

Exercise the map before relying on it

Run a tabletop scenario. Announce that a model update produces a high-impact false action in a restricted workflow. Ask each named role what they receive, decide, record and hand off. Then trace a second scenario in which evidence is incomplete rather than clearly bad.

Measure whether the team can identify the accountable decision-maker, suspend relevant authority, locate the correct evidence, contact the partner, preserve records and authorise recovery. Update the map when the exercise exposes delays or circular escalation.

Test routine handoffs as well as emergencies. Ask who approves a new evaluation case, who determines that a retried failure is fixed, who communicates a supplier model change, and who closes a temporary account. Small ambiguities accumulate into shadow processes long before they become an incident.

Keep contractual, operational and technical maps aligned without pretending they are identical. The contract may allocate liabilities; an operating runbook routes actions; a system diagram shows components. Cross-reference their authoritative locations and resolve contradictions through the appropriate owners. The responsibility map is the readable index that tells a participant where to act and where the binding detail lives.

Review it when the workflow, data, model, tool permissions, partner team or contract changes. ISO 44001 treats collaborative relationships as a managed lifecycle that includes partner selection, working together and exit. Responsibility should move deliberately across that lifecycle, including during transition and handback.

A good map does not eliminate overlap. It makes collaboration safe by showing where expertise combines and where one named owner must decide. When authority, evidence and escalation are visible, the partnership can move quickly without confusing motion for accountability.