Intended Use of the AI System
Make 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.
Plain language
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.
Framework
ISO/IEC 42001:2023
Control effect
Preventative
Classifications
N/A
Official last update
01 Dec 2023
Control Stack last updated
19 June 2026
Official control statement
The organisation shall ensure that the AI system is used according to the intended uses of the AI system and its accompanying documentation.
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.
Operational notes
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.
Implementation tips
- 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.
- Askwhoever 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.
Audit / evidence tips
- AskAsk for the intended-use statement for a named AI system and the vendor or developer documentation it is based on.GoodThe 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.
- AskAsk how a request to use an existing AI system for a new or different purpose is handled, and to see a recent example.GoodA 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.
- AskAsk to see the technical guardrails that keep the AI system inside its intended use.GoodConfiguration or access settings are in place that block off-topic or out-of-scope requests, keeping the system within its documented intended use.
- AskAsk for evidence that actual use of an AI system has been checked against its intended use, such as a usage sample or monitoring record.GoodA monitoring or sampling record shows usage was reviewed against intended use, out-of-scope use was identified, and action was taken to stop it.
- AskAsk the people who operate the AI system day to day what it is and is not approved to be used for.GoodOperators can clearly state what the AI system is approved for and what it must not be used for, matching the documented intended-use statement.
Cross-framework mappings
How Annex A 9.4 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(1)expand_less | ||
| Annex A 5.14 | Annex A 9.4 requires the organisation to ensure an AI system is used only as intended per its documentation, which includes constraints o... | |
handshakeSupports(2)expand_less | ||
| Annex A 5.10 | Annex A 9.4 requires the organisation to ensure an AI system is used only in accordance with its intended use and accompanying documentat... | |
| Annex A 8.30 | Annex A 9.4 requires that the AI system be used according to its intended uses and documentation, which depends on clear design assumptio... | |
ASD ISM
| Control | Notes | Details |
|---|---|---|
handshakeSupports(3)expand_less | ||
| ISM-0027 | Annex A 9.4 requires controlling AI system use so it aligns with intended use and documented constraints | |
| ISM-0042 | Annex A 9.4 requires the organisation to ensure the AI system is used only as intended, which often needs operational procedures, configu... | |
| ISM-0072 | Annex A 9.4 requires AI systems to be used according to intended use and documentation, including constraints relating to confidentiality... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ISO 42001 controls in A.9 Use of AI systems
See all A.9 Use of AI systems controls, or browse the full ISO 42001 Annex A library.
Want to implement this AI control?
Mindset Cyber runs PECB-accredited ISO/IEC 42001 training that maps directly to the AI controls in this library.