ISO 42001 Annex A.10.2: Allocate Responsibilities Across the AI Supply Chain

What control A.10.2 requires in practice

Control A.10.2 asks the organisation to make sure responsibilities across the life of its AI system are shared out between itself, partners, suppliers, customers and other third parties. The expectation is that allocation is deliberate and understood, not assumed. Annex B guidance observes that duties may be split among those supplying data, those supplying models or algorithms, and those developing or using the system, and asks the organisation to record the parties involved and their roles. Where it supplies a system to others, it should act responsibly in development and be able to provide documentation to them. For personal information, it points out that duties are usually divided between controllers and processors, so the organisation should determine its own role. The outputs are an identified set of parties, agreed responsibilities and evidence that the interfaces work.

Map the parties to actual activities

Annex B.10.2 considers parties supplying data, models and systems, and parties developing or using them. It connects allocation with relevant documentation and privacy roles where personal information is involved. The guidance must be considered under clause 6.1.3(e), while B.1 permits suitable implementation.

As an original mapping method, follow one output from data source to the decision it influences. Identify where responsibility changes hands and which information needs to accompany it. A list of companies is insufficient if it does not explain their role in the activity.

Why control A.10.2 matters to the business

Shared work breeds shared assumptions. A client expects the provider to have assessed everything; the provider assumes the client will check outputs; the supplier changes a component without telling either. Clear allocation prevents these gaps and shows who acts when something goes wrong. It supports sharper contracts, faster handling of incidents and more accurate representations to customers. It also limits a common mistake, believing accountability moves to a supplier along with the work. Auditors look for allocations that match how the arrangement operates and for evidence that information passes across the boundaries.

How to implement control A.10.2

Follow one output through every party before drafting any agreement. Where a relationship is small, the allocation can be a short written understanding rather than a long schedule, as long as it names the decisions that cross the boundary and the person on each side who answers for them.

1. Trace one AI output from its data source to the decision it influences and list every party along the way.
2. Record each party's activities: supplying data, changing the model, operating the service, reviewing outputs.
3. Agree who evaluates, who communicates changes and who investigates concerns, at each boundary.
4. Reflect the allocation in contracts or operating agreements, and check that they do not contradict each other.
5. Cover the whole relationship, including evaluation, deployment, monitoring, change and end of service.
6. Make sure each party receives the information it needs to carry out its part, such as limits and update notices.
7. Determine privacy roles from actual processing with specialist input, then test the arrangement with a supplier update or complaint.

Illustrative software example: the customer controls the final decision

Illustrative BPO example: three parties share a workflow

A BPO firm uses a technology supplier's AI service to support a client's customer process. The client supplies reference material, the supplier changes the service and the BPO controls employee review. A misleading output could arise at several points.

The parties clarify who maintains reference information, who communicates technical changes and who investigates operating effects. They also determine how concerns are exchanged. The BPO's internal accountability cannot be reduced to forwarding every issue to the vendor when its own review process may contribute.

Make interfaces specific enough to work

A useful allocation identifies duties and the decision route when information is missing or a condition changes. It can be reflected in contracts, operating agreements or other controlled arrangements. The control does not prescribe one universal responsibility matrix.

Check whether the arrangement covers evaluation, deployment, monitoring, change and end-of-service activities relevant to the relationship. An agreement focused only on initial delivery may leave ongoing responsibilities undefined.

Provide information that enables the other party's role

A responsibility cannot be fulfilled if necessary information is withheld or unclear. Link allocation with technical documentation and user information. A customer expected to apply an operating limit needs an understandable explanation of that limit.

Where personal information is involved, relevant privacy responsibilities depend on actual processing and applicable requirements. Do not assign legal roles solely from a commercial title. Obtain appropriate expertise and align the practical interface with the resulting obligations.

Evidence and common failures