ISO 42001 Annex A.8.2: Give AI Users Information They Can Apply

What control A.8.2 requires in practice

Control A.8.2 asks the organisation to work out what information users of an AI system need and then give it to them. Both halves count: deciding and delivering. Annex B guidance says the information can include that the person is dealing with an AI system, its purpose and how to interact with it, when and how to override it, technical conditions and limits, the need for human oversight, accuracy and performance, benefits and harms from impact assessment, changes over time, contact details and learning material. It adds that the criteria for choosing what to share should be written down, drawing on intended use, foreseeable misuse, user expertise and impact. The information must also be reachable and understandable, including for people needing accessibility features. The outputs are documented criteria, user-facing material and checks that users can find and apply it.

Start with the user's task and knowledge

Annex B.8.2 considers information about AI interaction, purpose, instructions, oversight, performance, impacts, updates and contact routes. It also addresses accessibility and criteria for deciding what to provide. This guidance must be considered under clause 6.1.3(e), with implementation tailored under B.1.

A practical design question is what the user could reasonably misunderstand at the point of action. A specialist administrator and a front-line employee may need different explanations. Information should be understandable for its audience without removing important qualifications.

Why control A.8.2 matters to the business

A tool's limits are only useful to the people who know them. When users are not told clearly what a system is for, where it struggles and who to call, they rely on it in ways nobody planned, and the business absorbs the consequences. Good user information reduces support load, avoids disputes about who was responsible and strengthens the case that the organisation acted reasonably. It also matters commercially, since clients increasingly ask for operating instructions before approving an AI feature. Auditors test this control by asking a real user a real question and seeing whether the published material helps.

How to implement control A.8.2

Design the information around the moment a user must decide something. Information that is correct but buried does little good, so judge the result by whether a busy person can apply it, and involve the people who handle user questions because they know where confusion actually arises.

1. Identify each user group and the task they perform with the system.
2. For each group, list what they could reasonably misunderstand at the point of action, including limits and when to escalate.
3. Write the criteria for what is shared with whom, covering intended use, foreseeable misuse and expertise.
4. Draft the material in plain language and place it where the work happens, such as in the interface, rather than only in a manual.
5. Check accessibility, including format, language and findability.
6. Test with representative tasks and a few real users, and fix what they misread.
7. Tie updates to the change process so instructions are revised when behaviour changes, and withdraw the old versions.

Illustrative IT example: the limitation appears too late

Illustrative manufacturing example: reviewers do not understand their role

A manufacturer introduces an AI inspection aid and tells operators that they remain responsible for final decisions. The instructions do not explain which uncertain cases need review or what information is available to support it.

The organisation provides task-specific information about the approved use, limitations and review route. It checks understanding with representative cases. A broad statement about human responsibility cannot compensate for missing operating guidance or insufficient competence.

Choose information using clear criteria

The guidance supports documenting the criteria used to determine whether and what information is provided. Intended use, foreseeable misuse, user expertise and impacts can inform that decision. This creates a reasoned approach rather than a standard brochure reused for every audience.

Some information can be provided through instructions, alerts or other accessible channels. Whatever the method, examine whether users can obtain it and whether it is complete, accurate and current for the relevant purpose. Avoid claiming universal explainability when the available information does not support it.

Communicate changes and qualified claims

A change to performance, operating conditions or a benefit claim may alter what users need to know. Connect updates with technical documentation and operating change processes. A new model version should not leave users relying on instructions for a materially different behaviour.

Relevant impact findings may need to inform the explanation, especially where effects differ in particular contexts. Sharing the useful conclusion does not necessarily require publishing all sensitive assessment detail. Choose appropriate information for the audience and obligations.

Evidence and common failures