Context of use statement for an AI tool: how to write one

Sources checked October 26, 2026. FDA’s AI guidance and Annex 22 are both drafts, so nothing below is a requirement yet. The sample statement is my own, not an official template.

A context of use statement says what an AI model does, how its output is used, and what other information informs the decision. FDA’s January 2025 draft guidance defines context of use as the model’s specific role and scope for a question of interest. Draft EU Annex 22 asks for the intended use, the input sample space with its variations, and, with a human in the loop, the operator’s responsibility. Write it before testing, and size the testing from it.

What a context of use statement is

It is a short, approved document that fixes what an AI tool is for. FDA’s draft guidance on AI to support regulatory decision making (January 2025) makes it step 2 of its seven step credibility framework and says “The description of the COU should describe in detail what will be modeled and how model outputs will be used.”

I covered the definition and the matching Annex 22 wording in the context of use section of my ChatGPT and Copilot article. One scope point is worth knowing before you start. The FDA guidance “does not address the use of AI models (1) in drug discovery or (2) when used for operational efficiencies (e.g., internal workflows, resource allocation, drafting/writing a regulatory submission) that do not impact patient safety, drug quality, or the reliability of results from a nonclinical or clinical study.” Most internal generative AI tools sit outside that scope. The method still works for them, and I use it for non GxP tools as a plain scope document. The status of both drafts is in AI validation in GxP has no settled playbook.

The parts of a statement

I write eight parts, in this order:

1. The question the tool helps answer or the task it supports.
2. The model’s role: what it produces, and whether it decides, recommends or drafts.
3. Scope and exclusions: what the tool is for, and what it must not be used for.
4. Inputs and their variations, including the rare ones.
5. How the output is used, and by whom.
6. Other information that informs the decision alongside the output.
7. Human responsibility: what the reviewer or operator must check before acting.
8. Owner and approver of the statement.

Parts 2, 5 and 6 come from FDA’s wording. Parts 4 and 7 come from draft Annex 22 section 3, which asks for “a comprehensive characterisation of the data the model is intended to use as input and all common and rare variations”, and says that with a human in the loop “the description of the intended use should include the responsibility of the operator”. Part 3 is my addition. The exclusions are where most statements I review are weakest.

A context of use statement example

Say a team wants a drafting assistant that turns approved change requests into first drafts of SOP revisions. Here is the internal version.

Context of use: SOP revision drafting assistant

Question or task

Produce a first draft of an SOP revision from an approved change request and the current SOP.

Model role

Drafts text only. It does not decide what changes, approve anything or release a document.

Scope and exclusions

For SOP revisions in the document system. Not for batch records, specifications, deviation conclusions or any text sent outside the company.

Inputs and variations

One approved change request and one current SOP. Covers short and long SOPs, tables, and change requests that touch several sections. A change request with no clear target section is out of scope.

How output is used

The document owner edits the draft and submits it through the normal review and approval workflow.

Other information

The change request rationale, the owner's process knowledge and reviewer comments decide the final text.

Human responsibility

The owner checks every changed statement against the change request and the process before submitting.

Owner and approver

Owned by the document control lead. Approved by the process owner and QA.

For a GMP use, I would tighten three fields. The exclusions name the GMP documents the tool may draft, such as GMP SOPs, and keep the rest out. Human responsibility names the qualification the reviewer needs, matching draft Annex 22’s “personnel with adequate qualification and training” for non critical use. The approver line adds that the statement is approved before acceptance testing starts, as draft section 3 asks.

What makes a statement fail

Three gaps come up again and again. The first is no exclusions. A statement that only says what a tool is for gives a reviewer nothing to point at when someone uses it for something else.

The second is vague users. “Staff” is not a user group. Name the role, so training and access can follow it.

The third is no operator responsibility. If the statement says a human reviews the output but not what they check, the review becomes a click. Draft Annex 22 asks for the operator’s training and performance to be “monitored like any other manual process”, and you cannot monitor a check nobody defined.

How the statement drives risk and testing

Everything after the statement is sized from it. The risk class depends on what the output is used for, the test set depends on the inputs and variations, and the acceptance criteria depend on the model’s role. I walk through the risk classification in How much validation does your AI need, and the inventory that the statement plugs into in Start with the inventory: AI use cases and risk tiers. Current Annex 11 clause 4.4 already asks for user requirements “based on documented risk assessment and GMP impact”, so a good statement does double duty.

If you want a second pair of eyes on a statement before testing starts, get in touch.

Frequently asked questions

Is context of use the same as intended use?

They are close. Draft Annex 22 uses intended use and asks for the tasks, the input data with its variations and, with a human in the loop, the operator’s responsibility. FDA’s context of use goes a little further. It also asks how the output will be used and what other information is used alongside it. Writing to the FDA wording covers both.

Does FDA's AI guidance apply to internal GenAI tools?

Usually not. The January 2025 draft guidance excludes AI used “for operational efficiencies”, naming internal workflows and drafting a regulatory submission as examples, when they do not affect patient safety, drug quality or study reliability. Most internal drafting assistants fall in that group. The guidance is still a draft, and its context of use method is useful even where it does not apply.

Who approves the statement?

No source I have found names a role. I have the process owner and QA approve it, and the owner of the tool keep it current. The process owner knows what the output feeds, and QA checks that the scope and the human responsibility match the risk. For a non GxP tool, the business owner and whoever runs AI governance is enough.