ISO 42001 AI Relationships: Suppliers, Customers and Shared Responsibilities

Map the relationship before negotiating the detail

Start with the intended system and use. Identify which parties provide components, information, decisions and ongoing support. Determine where one party's work becomes another party's dependency. This map can reveal gaps that a list of suppliers misses, such as an unclear owner for evaluating a model update or informing users about a changed limitation.

A.10.2 concerns allocating responsibilities between the organisation, partners, customers and third parties. Make the allocation understandable and consistent with the activities involved. Some responsibilities may be expressed in contracts; others may need operating procedures, technical information or an agreed escalation route. A contractual statement is useful only when the relevant parties can apply it in practice.

The normative Annex B guidance must be considered under clause 6.1.3, while B.1 allows tailored implementation. The guidance does not prescribe one contract template or transfer all accountability to the party with the most technical expertise. Where privacy or other legal roles matter, determine them from the actual processing and applicable obligations with appropriate specialist input.

Select suppliers against the intended integration

A.10.3 concerns processes that align supplied products and services with the organisation's approach to responsible AI. The assessment should reflect what is being obtained and how it will be used. A dataset, an external model and a complete operational service present different questions. Applying an identical questionnaire to all three can obscure rather than clarify the significant issues.

Define the requirements that matter to the integration. These may concern relevant information, evaluation evidence, limitations, support, change communication or the ability to meet particular obligations. The selected questions should follow the risk and impact context. Do not ask for information solely because it appears in a generic supplier checklist, and do not interpret an unanswered question as automatically harmless.

Examine evidence for relevance as well as availability. A supplier's certification, benchmark or policy may contribute to an assessment, but it may not cover the particular system, scope or intended use. Understand what it demonstrates and what remains for the organisation to evaluate. Neither a certificate nor an impressive demonstration removes the need to assess the integrated arrangement.

Illustrative manufacturing example: buying an inspection application

A manufacturer buys an AI application that supports visual inspection. The supplier provides a model, software and operating guidance, while the manufacturer controls image capture, production conditions and final inspection responsibilities. Initial discussions focus on the application's advertised performance. A responsibility review shows that several important decisions sit at the boundary between the parties.

The manufacturer clarifies who evaluates the application in its production context, who maintains relevant operating information and how changes in materials or conditions are handled. The supplier explains the supported conditions and provides agreed information about updates and limitations. The manufacturer retains responsibility for its own workflow and does not treat the purchase as independent approval of product quality.

When a new production condition creates uncertain results, the parties have a defined route for investigation and support. The organisation can decide whether to adjust the use, obtain further evidence or pursue a technical change. The relationship works because responsibilities and information needs were established before the issue, not because a contract broadly declared that the supplier was responsible for “AI performance.”

Understand customer needs without promising unsupported outcomes

A.10.4 concerns considering customer needs and expectations in relation to responsible AI. Those needs can influence design, contracts, instructions and general use arrangements. A supplier should understand the intended customer context sufficiently to recognise relevant responsibilities and limitations. That does not mean promising suitability for every use a customer might later invent.

Be clear about what the supplied system is intended to support and what the customer must establish. Relevant information may include evaluated conditions, limitations, operating requirements and responsibilities for integration or oversight. Avoid language that implies an assurance broader than the evidence. A commercial promise can create governance problems if delivery teams cannot support it.

Customer feedback should have a route into assessment and improvement. A report from one customer may indicate a local integration issue or a wider limitation affecting other users. Determine the scope through evidence rather than assuming either conclusion. Connect the relationship with the information and reporting controls so that findings can lead to appropriate communication.

Illustrative software example: supplying a service built on another supplier

A software company offers an AI-assisted document service using an external model provider. Its customer expects useful summaries for a defined workflow, while the model provider supplies general capabilities and service information. The software company sits between the two and cannot simply pass every responsibility upstream or downstream.

The company defines the integrated service's intended use, evaluates relevant performance and provides customer information appropriate to that use. It establishes what evidence and change information it needs from the model provider. It also explains which customer inputs, configuration choices and review arrangements affect the service. The customer receives a usable account of the boundary rather than a chain of disclaimers pointing at another party.

A model-provider update then affects a supported document category. The software company assesses the implications for its service and determines whether customer communication or further evaluation is needed. Its records connect the supplier change with the customer-facing decision. This demonstrates why responsibility allocation must continue through operation, not end at the initial purchase order.

Manage relationships after selection

Supplier assessment should connect with ongoing performance, relevant changes and emerging concerns. Determine what information is needed during the relationship and who reviews it. A supplier that was appropriate at selection may change its service, support, data arrangements or operating conditions. The organisation's own intended use may also change.

Where supplied products or services no longer align with the responsible approach, evaluate a proportionate response. Options may include clarification, corrective action, changed integration, additional controls or reconsideration of the supplier. These are implementation possibilities to assess, not a requirement to terminate every relationship after an issue. The response should address the actual risk and obligations.

Consider dependencies and exit needs where relevant. A critical external component can constrain the organisation's ability to change or discontinue a service. Understand those constraints before they become urgent. This is practical governance advice within the relationship context; ISO 42001 does not prescribe one universal exit-plan template for every supplier.

Evidence and common relationship failures

Useful evidence may include responsibility allocations, supplier requirements and assessments, relevant agreements, integration decisions, customer information and records of significant changes or issues. The evidence should explain the arrangement in operation. A large supplier file is weak if nobody can identify who owns a consequential update.

Common weaknesses include assuming that supplier certification proves the integrated system's suitability, leaving operating responsibilities implicit, obtaining information that is never evaluated and promising customers outcomes beyond the supported use. Another is treating external hosting as proof that the organisation has no AI governance duties. The organisation still needs to manage its own role and decisions.

A practical review traces one requirement through the relationship: who supplies the evidence, who evaluates it, who decides and who is informed when it changes? Then test one adverse-effect report across the same boundary. These suggested checks expose gaps more directly than counting contract clauses. Use life-cycle controls, data controls and the Annex A overview to complete the context.

Individual controls in this theme

Why AI supply chain controls matter to the business

Hardly any AI service is built by one party alone. Data, models, tooling, hosting and support often come from different companies, while a customer may add its own judgement on top. The three controls in this group deal with who is responsible for what, how supplied products are assessed and how customer expectations are understood. For a business, the benefit is avoiding the gap where each party assumes another is watching. It also helps in tenders and contracts, because responsibilities can be described accurately instead of generically. Auditors read this group to see whether the organisation understands its own role in each relationship and whether supplier assurance is matched to the actual use.