Who is responsible for what in the AI value chain? ISO 42001 Annex A.10

As soon as something goes wrong with an AI system, the same question surfaces: who should have caught this? The supplier training the model, the party providing the data, or the organisation that put the system into its own process. In most contracts the answer is absent, and in the contracts where it appears, a closer look shows it covers availability and security rather than model behaviour. Annex A.10 of ISO/IEC 42001 addresses exactly this.

What Annex A.10 covers

The domain holds three controls. A.10.2 requires responsibilities across the life cycle of your AI systems to be allocated between the organisation, its partners, suppliers, customers and other third parties. A.10.3 requires a process ensuring that your use of services, products or materials from suppliers aligns with your own approach to responsible development and use of AI. A.10.4 requires that approach to take account of your customers' expectations and needs.

Three controls, two sides of the chain: what you buy and what you supply. Organisations almost always arrange the first side and forget the second.

Allocating responsibilities: which activities exactly

A split that says the supplier owns the model and the customer owns the usage solves nothing. The allocation becomes usable once you make it per activity.

Five subjects belong in it at minimum. Who performs the risk assessment and who implements the resulting controls. Who owns data quality, data provenance and privacy compliance. Who validates the model, who measures performance and who detects drift. Who detects an incident, who notifies whom, and within what timeframe. And who meets which regulatory obligation, which matters most when one party is the provider and the other the deployer under the EU AI Act.

Shared responsibilities are the hard part. The classic gap: both parties assume the other monitors for bias. Every shared task therefore needs one party as owner, even when both do something.

What you record, and where

The allocation belongs in the contract or data processing agreement, backed by a responsibility matrix per AI system. Generic IT service agreements do not cover this: they address availability, support and security, not model validation or bias monitoring. Missing AI governance terms in supplier contracts is among the most frequently recorded nonconformities under A.10.2.

Update the matrix when the relationship or the system changes. A supplier moving from its own model to an underlying third-party model changes the chain, and with it the allocation.

Suppliers: beyond the standard questionnaire

A.10.3 asks for a process, not a one-off assessment. At the start you assess the supplier's AI governance maturity, data practices, security posture and regulatory compliance. The contract carries requirements on transparency, performance guarantees, bias testing commitments, incident notification and audit rights. Monitoring follows: periodic performance review, reassessment on change, and deeper scrutiny of the suppliers that matter most.

Include supply chain risk explicitly. Dependence on a single model provider, the risk of losing access to a model version, and deteriorating data quality from a data supplier are risks no contract clause resolves. Those need scenarios and fallback options. For the assessment mechanics, your existing third-party risk management is the starting point; A.10.3 adds the AI-specific requirements on top.

Customers: the side usually missing

A.10.4 is the control organisations get challenged on most during the audit, because there is rarely anything to show. If you ship a product or service with AI inside it, your customers need information to use it responsibly.

In practice: state that AI is present and where. Describe what the system can do and, more importantly, what it cannot do and what it is not intended for. Set out the human oversight you expect from the customer and why. Name the known limitations and risks, including the conditions under which performance degrades. And record how a customer reports a problem and what happens next.

There is a second reason to get this right. Customers deploying your AI system carry obligations of their own, for instance as a deployer under the EU AI Act. Without documentation from you they cannot meet them, and the question lands on your desk anyway, usually inside a procurement process under time pressure. A model description, a list of limitations and a short responsible use guide save a great deal of ad hoc questionnaire work later.

What an auditor asks

How are responsibilities split between you and your AI suppliers, and where is that written down? How do you check that a third party actually does its part? What information do you give customers about the AI in your product, and who reviews whether it is still accurate? How are customer-reported AI issues logged and followed up? And on chain changes: when was the allocation last revised?

That last point is where it usually breaks. The matrix was drawn up a year ago, the supplier has shipped two model versions since, and a new data provider joined the chain.

Nonconformities auditors record

Under A.10.2: responsibilities not allocated in contracts, shared tasks without an owner, and no verification at all that the third party honours its commitments. Under A.10.3: no AI-specific due diligence, contracts without transparency or bias testing requirements, no supplier register and no assessment of supply chain risk. Under A.10.4: customers unaware that AI sits inside the product, documentation lacking limitations and the required form of human oversight, and customer reports tracked nowhere.

Documents to have ready

Contracts with AI governance terms, responsibility matrices per AI system, the supplier management procedure, completed due diligence records, a supplier register with risk ratings, monitoring reports, customer documentation covering limitations and conditions of use, and the register of customer-reported AI issues.

Start with the systems you supply to customers. The supplier side you probably have partly covered through existing third-party management; the customer side is missing entirely in most organisations, and it takes the longest to build.