ISO 42001 Annex A 9.4 Intended use of the AI system
What it says
The organization shall ensure that the AI system is used according to the intended uses of the AI system and its accompanying documentation.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishMake sure each AI system is only used for the purposes it was actually designed and approved for, and stay inside the limits set out in the documentation that came with it.
Every AI (artificial intelligence) system is built for a specific job and comes with accompanying documentation: the instructions, user guides, model cards, terms of use and operating limits that the developer or vendor supplies. That documentation describes the intended uses: what the system is meant to do, the conditions it was tested under, and what it should not be relied on for. This control asks you to make sure your organisation actually uses the AI inside those boundaries. The reason this matters is that an AI system behaves predictably only within the situations it was designed and validated for. Push it outside that envelope and it can produce confident but wrong answers, because no one ever checked whether it was safe or accurate for that new purpose. For example, a chatbot tested and approved only for answering questions about opening hours may give plausible-sounding but unvetted responses if staff or customers start asking it for financial or medical advice. Using the system that way breaches the vendor's documented intended use and shifts the risk (and the liability) onto your organisation. So the job here is to know what each AI system is approved for, tell the people who use it where the limits are, and put checks in place so it does not quietly get used for something it was never meant to do.
Free. Save your status, tasks and notes.
Why it matters
A chatbot signed off only for answering opening-hours queries gets used by staff to give customers financial or medical guidance it was never tested for; the answers are wrong, the use breaches the vendor's accompanying documentation and terms, and the organisation (not the vendor) carries the liability for the harm. Off-label use like this can produce decisions affecting customers that no one validated, drawing complaints to the OAIC and forcing the system to be pulled from service while the damage is unwound.
How to implement
Have the product owner write a short intended-use statement for each AI system that pins down its approved purposes and its explicit limits, taken straight from the vendor or developer documentation, so a chatbot approved only for opening-hours and product questions is on record as not for financial, legal or medical advice.
Make sure the people who actually use the system know where the line is by putting the intended uses and the off-limits uses into onboarding, quick reference guides or an in-tool notice, so nobody discovers the boundary by accident after they have crossed it.
Set up a simple approval step so that any request to point an existing AI system at a new purpose has to be checked against its intended use and accompanying documentation before it goes live, rather than new uses spreading informally team to team.
Ask whoever owns security and technical controls (often the head of IT security, or CISO) to build guardrails that hold the system inside its approved scope, such as a system prompt, content filters or access limits that stop a customer-service bot from wandering into off-topic or out-of-scope answers.
Have the AI lead sample real usage at regular intervals (reading a batch of recent interactions or logs) to catch the system being used outside its intended purpose, and feed anything off-label back into either tighter guardrails or a decision to formally approve and validate the new use.
Keep it running
Treat the intended-use boundary as something to actively police, not just declare once. When a team asks to use an existing AI system for a new purpose, run that request through an approval step rather than letting it spread informally. Re-check the vendor's accompanying documentation at each version update or licence renewal, because intended uses and stated limitations can change, and update your own usage rules and any technical guardrails to match.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the intended-use statement for a named AI system and the vendor or developer documentation it is based on.
Look at
Whether the statement names the approved purposes and explicit limits, and whether those limits actually match what the vendor's accompanying documentation or terms of use say the system is for.
Good evidence
The intended-use statement clearly lists what the AI system is approved to do and what it must not be used for, and those boundaries line up with the vendor's accompanying documentation.
- Check 2 of 5What an auditor asks for
Ask for
Ask how a request to use an existing AI system for a new or different purpose is handled, and to see a recent example.
Look at
Whether there is an approval step that checks the new purpose against the system's intended use before it goes ahead, rather than teams adopting new uses informally.
Good evidence
A documented approval record shows a proposed new use was assessed against the system's intended use and accompanying documentation and was formally approved or rejected.
- Check 3 of 5What an auditor asks for
Ask for
Ask to see the technical guardrails that keep the AI system inside its intended use.
Look at
Whether there are real controls, such as configuration settings, a system prompt or access limits, that stop the system answering or acting outside its approved scope.
Good evidence
Configuration or access settings are in place that block off-topic or out-of-scope requests, keeping the system within its documented intended use.
- Check 4 of 5What an auditor asks for
Ask for
Ask for evidence that actual use of an AI system has been checked against its intended use, such as a usage sample or monitoring record.
Look at
Whether someone reviews real interactions or usage logs for use outside the approved purpose, and what happens when off-label use is found.
Good evidence
A monitoring or sampling record shows usage was reviewed against intended use, out-of-scope use was identified, and action was taken to stop it.
- Check 5 of 5What an auditor asks for
Ask for
Ask the people who operate the AI system day to day what it is and is not approved to be used for.
Look at
Whether staff can describe the system's intended use and its limits, or whether they treat it as a general-purpose tool for anything.
Good evidence
Operators can clearly state what the AI system is approved for and what it must not be used for, matching the documented intended-use statement.
Mappings
Closest match in ISO/IEC 27001: A.5.10, Acceptable use policies for information and assets, which this control supports.
ISO/IEC 27001: 1 mapping
This control supports A.5.10.
Annex A 9.4 requires the organisation to ensure the AI system is used only in the ways it was designed and approved for, consistent with its documentation. Annex A 5.10 supports this by requiring acceptable use rules for information and assets, which can codify permitted and prohibited AI uses (e.g., banning use for hiring decisions if not approved). Annex A 5.10 applies across all assets, whereas Annex A 9.4 is specific to AI system intended-use constraints.
ASD Information Security Manual: 1 mapping
This control depends on ISM-2084.
Annex A 9.4 requires the organisation to ensure an AI system is used only for its documented intended uses and within documented limits. ISM-2084 mandates creating and maintaining AI model/system documentation (e.g., model cards/system cards) that defines use cases, characteristics and risks, which is a prerequisite for communicating and enforcing “intended use”. Annex A 9.4 focuses on controlling use in operation, while ISM-2084 focuses on producing the artefacts that make intended-use boundaries explicit and auditable.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.
Get help with this control
ISO 42001 training
Mindset Cyber runs PECB-accredited ISO/IEC 42001 training that maps directly to the AI controls in this library.
Turn this control into your AI policy
PolicyMint writes customised ISO 42001 policy documents for your business, audit-ready and exported in your branding (Word, PDF, Excel). Skip the blank page and the boilerplate that does not fit. First document free.
Draft your ISO 42001 documents