ISO 42001 Annex A.10.4: Understand Customer Needs for AI Products and Services
ISO 42001 control A.10.4 concerns considering customer expectations and needs within the organisation's responsible approach to AI development and use. It is especially relevant when the organisation supplies an AI-related product or service. Understanding the customer's intended use helps prevent a technically accurate description from becoming an unsupported delivery promise.
What control A.10.4 requires in practice
Control A.10.4 asks the organisation to make sure its responsible approach to developing and using AI takes customer expectations and needs into account. It bites hardest when the organisation is itself a supplier of an AI-related product or service. Annex B guidance says those expectations may arrive as design requirements, contract terms or general usage agreements, and that one organisation can have several customer types with different needs. It stresses understanding where responsibility sits with the provider and where it sits with the customer while still meeting needs. The organisation therefore has to learn what each customer plans to do with the system and decide what it can support. The outputs are recorded customer needs, agreed conditions and evidence that these shaped design, information and delivery.
Clarify what the customer expects to do
Annex B.10.4 considers requirements arising during design, contracts and general use arrangements, including the division of responsibility between supplier and customer. It also connects risk treatment with appropriate information about use limits. The guidance must be considered under clause 6.1.3(e), with implementation tailored under B.1.
As an original discovery approach, ask which decision the customer expects the output to support and which people will rely on it. Two customers can purchase the same feature while using it in materially different ways. A generic product description may not reveal that difference.
Why control A.10.4 matters to the business
Two customers can use the same feature for very different decisions, and only one of those uses may be supported by evidence. If sales descriptions run ahead of evaluation, the supplier inherits disputes about promises it never meant to make. If customers are not told the limits, they may apply a feature in settings it was never tested for. Understanding customer intent protects both sides, supports realistic proposals and helps teams decide when a request needs further assessment or a different scope. Auditors trace a significant customer expectation from the first conversation through to the delivered service and its documentation.
How to implement control A.10.4
Learn the customer's real decision before agreeing what the service will do. Keep the commercial and technical teams in the same conversation, since promises made in a proposal are the ones most likely to outrun the evidence, and capture any customer assumption that was corrected along the way.
- During scoping, ask which decision the customer expects the output to support and who will rely on it.
- Record the customer's requirements and compare them with what has been evaluated and can be substantiated.
- Agree conditions, limits and divisions of responsibility in the contract and in operating instructions.
- Send requests beyond the evaluated use, such as new populations or automated decisions, for assessment, not just commercial approval.
- Give customers the limits and conditions in a form the people configuring the service will actually see.
- Align sales and marketing statements with the evaluation evidence and review them regularly.
- Treat customer complaints as signals about misunderstood limits and feed them back into assessment.
Illustrative software example: a search aid becomes decision support
A software provider offers AI search over technical documents. One customer wants faster navigation by specialists; another wants front-line staff to use generated answers as final instructions. The second use places different demands on evidence, information and oversight.
The provider clarifies the evaluated domain and limitations and examines whether the proposed use can be supported. It should not quietly accept a customer's interpretation that exceeds the evidence. The response may involve different conditions, further evaluation or a decision that the requested use is outside the offer.
Illustrative BPO example: the client assumes the service includes assessment
A BPO firm adds AI-assisted summaries to a client service. The client assumes the BPO has assessed all effects on its downstream decisions, while the BPO assumes the client will perform that work. Neither assumption is discussed.
The organisation clarifies responsibilities and the information each party needs. It explains its own assessment boundary and the conditions of the service. A contract can support that understanding, but operational teams also need to know how the responsibilities work in practice.
Connect customer requirements with design and operation
Customer needs can inform requirements and specification, evaluation and support. Distinguish a requested capability from a commitment the organisation can substantiate. Relevant obligations and the responsible approach still constrain what can be agreed.
Where customer expectations change, examine the effect on intended use and assessment. A request to extend the population, automate a decision or use a different data source may require more than a commercial change order.
Provide information that enables responsible use
The guidance recognises that supplying appropriate information can contribute to treatment of risks arising from customer use. Explain relevant domain limits and conditions in a form the customer can apply. A statement buried in a technical appendix may not reach the person configuring the service.
Connect with user information and allocated responsibilities. Information is a contribution to risk treatment, not a universal transfer of all responsibility to the customer.
Evidence and common weaknesses
Useful evidence includes clarified needs, agreed conditions, relevant evaluation and communications. Trace a significant customer expectation from initial discussion into the delivered service and supporting information.
Common failures include assuming every customer uses a feature identically, allowing sales claims to exceed evaluated capability and treating a disclaimer as a substitute for a suitable offer. Another is ignoring complaints because the customer technically accepted terms. Customer experience can reveal a limitation or misunderstanding that deserves assessment.
Management-system certification does not certify every customer application or remove the need for appropriate legal and professional decisions. Keep the scope of assurance clear in proposals and ongoing communications.
Frequently asked questions
Must we accept every requested AI use?
No. Clarify the request and assess whether it fits the evidence, responsibilities and applicable requirements. Conditions or a different scope may be needed.
Can the same product need different customer arrangements?
Yes. Intended use, expertise and consequences can differ. Preserve consistent product facts while addressing relevant conditions.
Does providing a disclaimer transfer all risk?
No. Information can contribute to treatment, but responsibilities and suitability still depend on the actual relationship and use.
Align an AI promise with the evidence behind it
Discuss a customer AI expectation or delivery boundary with Sterling. Scoped support can connect requirements, documentation and Effivity ISO & GRC automation software. AI Risk & Impact Assessment helps teams examine proposed uses. See the relationship theme and the full library.