ISO 42001 Annex A.9.4: Keep AI Use Within Its Intended Conditions
ISO 42001 control A.9.4 concerns using an AI system according to its intended uses and accompanying documentation. The practical issue is whether actual work remains inside the conditions that support the use. Approval of a tool does not automatically authorise every purpose or input that employees can technically connect to it.
What control A.9.4 requires in practice
Control A.9.4 asks the organisation to make sure that an AI system is used in line with its intended uses and the documentation that comes with it. The focus is real behaviour: whether daily work stays inside the conditions that support the system. Annex B guidance links this to deploying as the instructions describe, providing the resources a deployment needs, applying human oversight where it is part of the intended use, and making sure the data the system works on matches what the documentation assumes. It expects operation to be monitored and says concerns should be raised with relevant colleagues and suppliers even when instructions were followed. It also asks for event logs or other documents that can show intended use. The outputs are use that matches documented purpose, monitoring records and communicated concerns.
Understand the conditions behind intended use
Annex B.9.4 connects use with instructions, relevant resources, human oversight and appropriate data. It also considers monitoring, reporting concerns and retained operating evidence. The guidance must be considered under clause 6.1.3(e), while B.1 permits suitable implementation.
As an original operating test, compare a typical user action with the documented purpose and conditions. Identify where staff make assumptions that the documentation does not support. A purpose described too broadly may conceal significant differences between workflows.
Why control A.9.4 matters to the business
Most AI incidents in day-to-day business do not come from broken technology. They come from a tool doing something nobody tested, such as a summariser quietly becoming a basis for staffing decisions. Keeping use inside its documented boundaries protects clients, employees and the business's own legal position. It also means performance claims continue to rest on evidence. When a use does need to change, the organisation can route it through assessment first instead of defending an unreviewed practice afterwards. Auditors compare instructions with observed behaviour, interview users and ask about busy-period workarounds.
How to implement control A.9.4
Compare what people do with what was approved, and close the gaps early. The goal is not to police staff but to keep the approved picture and the real picture aligned, so treat discovered drift as information about unmet needs and respond by adjusting either the use or the approval.
- Write the intended use of each system in terms of task, users, inputs and the decisions the output may influence.
- Make sure staff can see those boundaries in simple instructions where they work.
- Observe real use through interviews and sample outputs to find assumptions the documentation does not support.
- Define what counts as a change of use and route it through the use approval process before it starts.
- Provide the resources the deployment needs, including trained reviewers where oversight is required.
- Give users a clear way to raise concerns, even when they followed instructions, and pass supplier-related ones on.
- Keep operating records proportionate to the use and review them for drift and workarounds.
Illustrative BPO example: summarisation becomes judgement
A BPO provider approves AI to summarise customer conversations for employee review. Supervisors begin using the summary's tone to decide which complaints deserve priority. The tool has not changed, but its output now influences a different decision.
The organisation recognises the changed use and routes it through appropriate assessment and authorisation. It does not rely on the original product approval as evidence that this purpose was evaluated. Operating records and staff discussions can reveal the difference before it becomes an entrenched practice.
Illustrative construction example: correct use still raises a concern
A construction consultancy uses an AI image-analysis service according to the supplied instructions. The resulting report nevertheless misrepresents progress where important work occurs outside the visible area. The team cannot dismiss the concern merely because it followed the documented steps.
The guidance supports communicating such concerns to relevant internal people and suppliers. The organisation examines the actual effects and determines appropriate conditions while the issue is assessed. Intended use is a boundary for responsible operation, not a guarantee that every output is suitable.
Connect data and resources with the conditions
Inputs can fall outside documented assumptions even when the user's purpose is unchanged. Different languages, image conditions or source formats may matter. Users need a practical way to recognise relevant limits and seek help.
Required oversight also needs to be applied where it forms part of the intended deployment. Connect with responsible-use objectives and user information. A control that depends on review is not implemented merely because a policy says reviewers exist.
Monitor practice and preserve evidence
Monitoring can reveal scope drift, workarounds and changed performance. Relevant logs or other operating records can help demonstrate how the system was used and support communication of concerns. Retention depends on intended use, organisational policy and applicable requirements rather than a universal number of years.
Choose evidence proportionate to the question and protect sensitive information. The event-logging control gives a related perspective; a log should be interpreted according to what it actually records.
Evidence and common mistakes
Compare instructions, approved conditions and actual user behaviour. A useful review includes an exception or busy-period workaround, not only the demonstration case. Staff may use an output differently from the process owner's description.
Common weaknesses include treating technical capability as permission, assuming supplier instructions cover local obligations and continuing a concerning use because the manual was followed. Another is changing local purpose without reconsidering the data and evidence behind the original approval.
Frequently asked questions
Can we use the same tool for a new purpose?
Do not assume prior approval covers it. Examine the proposed use, documentation, risks and required authorisation through the AIMS.
What if following instructions still produces a concerning result?
Raise the concern through appropriate internal and supplier routes and assess the consequence. Correct use does not prove every result is acceptable.
Does intended use depend only on the vendor's description?
The supplied documentation is relevant, but your organisation also needs to understand its actual purpose, requirements and operating decisions.
Check where actual AI use exceeds its evidence
Discuss a changed AI purpose or operating limitation with Sterling. Scoped support can connect use assessment, documentation and Effivity ISO & GRC automation software. ISO/IEC 42001 Awareness helps users recognise the boundary. See the use controls and the full library.