An intended use statement says precisely what an AI system is for, who uses it, on what inputs, what decision it informs and what it must not be used for. Without it you cannot set acceptance criteria, assign a risk tier or design a test. The draft EU GMP Annex 22 starts with intended use, and the FDA's credibility framework begins with the same idea, which it calls context of use.
Why does everything start here?
Every later question depends on it. How good does the AI need to be? That depends on what it is being asked to do. What tests are fair? Those that resemble the intended use. How much human review is needed? That depends on the consequence of a wrong output in that use. If the use is vague, every one of those answers is vague too, and an inspector can reasonably ask what you were testing against.
What goes in an intended use statement?
- Purpose. The task, in one or two sentences.
- Users. Who uses it, and what training they need.
- Inputs. What data and documents it receives, and from where.
- Outputs. What it produces and in what form.
- Role in the decision. Does it assist a person, recommend an action or decide? Who acts on the output?
- Consequence of error. What happens if the output is wrong, and which risk tier that implies.
- Exclusions. What it must not be used for, stated plainly.
- Human oversight. Who reviews what, and what they sign.
- Owner and version. A named owner, a version number and a date, under change control.
A worked example
Here is a weak statement: "The AI assistant supports quality investigations." It names a tool and a department, and says almost nothing a test could be built against.
Here is a stronger one: "The assistant retrieves related deviation records, CAPAs and SOP sections from the approved library and prepares a structured summary for the investigating quality professional. It is used by trained QA investigators on deviations classified as minor or major. It does not propose root causes, classify deviations, or contribute to batch disposition. Every summary cites its sources and is reviewed and accepted by the investigator before use. Owner: Head of Quality Systems. Version 1.0."
The second version tells you what to test (are the retrieved records the right ones, are the citations accurate), what the consequence of error is (a missed record that the investigator would still be expected to catch), and what would take the use outside its boundary (anything touching root cause or disposition).
How it drives the rest of the work
- Risk tier. The role in the decision and the consequence of error set the tier.
- Acceptance criteria. What counts as good enough follows from the use.
- Test data. You test on cases that look like the intended use, not on convenient ones.
- Monitoring. You know what drift would matter, because you know what the use is.
Keep it alive
A statement written once and filed is not enough. When the use changes, when the model changes or when an incident occurs, the statement is revisited under change control. A common failure is a statement that describes the use the team intended a year ago, while the tool has quietly been put to new work.
Where teams go wrong
- Describing the tool rather than the use.
- Skipping exclusions, which are the part that stops scope creep.
- Forgetting AI that arrives switched on inside software you already own. It needs an intended use too.
- Writing it without the process owner, so the people who rely on the output never agreed to it.
Frequently asked questions
How long should an intended use statement be?
Usually one page. It should be long enough that a tester could build acceptance criteria from it, and short enough that the process owner has actually read it.
Who should sign an intended use statement?
The process owner who relies on the output, the system owner, and a representative of Quality. For higher risk uses, the person who accepts the residual risk should sign it.
Do AI features inside software we already own need an intended use?
Yes. If an embedded feature affects work in your organisation, someone should define what it is used for, who owns it and what evidence shows it is fit for that purpose, even if the supplier switched it on by default.
Sources and further reading
- European Commission: consultation on draft Annex 22 (Artificial Intelligence), revised Annex 11 and Chapter 4
- ICH quality guidelines, including Q9(R1) Quality Risk Management
- ISPE GAMP 5 Guide, Second Edition
This article is general information, not legal or regulatory advice. Regulatory texts change, and some discussed here are drafts: check the current official text before relying on any detail.
