If you only get one document right when you validate an AI system, make it this one. The intended use statement is short — often a page — but everything else hangs off it. Your risk assessment, your GAMP category, your test set, your acceptance criteria, even what the inspector asks you first. Get it vague and every document after it inherits the vagueness.
We see the same pattern a lot. A team is excited about what the AI can do, so they write down everything it could do. That's the wrong way round. An intended use statement is about what you will actually rely on it for — and, just as important, what you won't.
What goes in it
Keep it plain. Someone outside your team should understand it in two minutes.
- The task. One sentence. "Drafts first versions of OQ test scripts from an approved requirements list." Not "supports validation" — that could mean anything.
- The inputs. What goes in, where it comes from, what format. If it only works on your template, say so.
- The output. What comes out and who receives it.
- The human step. Who reviews the output, what they check, and who approves. This line matters more than any other.
- The decision it feeds. What happens because of this output? A draft that a person rewrites is very different from a classification that goes straight into a record.
- The limits. What it must not be used for. Out-of-scope inputs. What happens when it isn't sure.
The 'must not' section is the one people skip
Honestly, this is where most statements fall short. Teams describe the happy path and stop. But an inspector — and your own QA — will want to know where the edges are.
Write it down plainly: it does not approve anything. It does not decide GAMP category, only proposes one. It is not used on batch release decisions. It is not used on documents in languages it wasn't tested on. Each of those sentences removes a question you'd otherwise have to answer on the spot.
There's a regulatory reason too. Under the draft EU GMP Annex 22, generative and continuously learning models are not expected in critical GMP decisions — where they're used in lower-risk work, a qualified person reviewing the output is the control. Your intended use statement is where you show which side of that line you're on. (Annex 22 was still a draft at the time of writing, so check its current status.)
How it sets your risk and GAMP category
Once the intended use is clear, the risk assessment almost writes itself. Ask two questions. If the output is wrong, what's the worst realistic outcome? And would a person catch it before it mattered? A draft that a trained reviewer checks line by line is lower risk than a score nobody looks at twice. See GxP risk assessment.
GAMP category follows the same logic. An off-the-shelf AI feature you configure but don't change is usually treated like other configured software, around Category 4. A model you trained or tuned on your own data behaves much more like custom software and is usually treated as Category 5, with the extra evidence that brings. Don't argue about the category in the abstract — let the intended use and how much you've changed the model settle it.
Wording that causes trouble later
- "Assists" or "supports". Assists how? These words hide the one thing you need to state — who decides.
- "Reviewed as needed". Reviewed by whom, every time or sometimes? If it's sometimes, say how you choose.
- "High accuracy". Leave numbers out of the intended use. They belong in the acceptance criteria, where you can justify them. See acceptance criteria for AI.
- A list of future uses. If you plan to extend it later, that's a change, and it goes through change control when it happens. Don't pre-validate a wish list.
Our approach is simple: write it, then hand it to someone in QA who wasn't in the project and ask them what the AI is allowed to do. If their answer doesn't match yours, the statement isn't finished. Next step: building the test set. The wider picture is in GxP AI.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.