Intended Use and Context of Use

The intended-use statement is the anchor for AI requirements, risk, data, evaluation, human oversight, monitoring, and change control. This chapter shows how to write one that is precise enough to validate.

Published: September 4, 2026 | Version 1.0

Editorial owner: CSV to CSA Knowledge Hub | Review status: Open for practitioner peer review

LEARNING OBJECTIVES

• Convert an AI idea into an assurance-ready intended use
• Define operating conditions, users, decisions, and prohibited use
• Connect context of use to model credibility and performance criteria
• Identify hidden scope changes before deployment

THE TEN-ELEMENT STATEMENT

An effective intended use should identify:

1. Business or regulated process

2. User and required competence

3. Input data and source

4. AI function

5. Output and how it is presented

6. Decision or action influenced

7. Human review and authority

8. Operating population and environment

9. Downstream record or system

10. Explicit exclusions and prohibited use

WEAK AND STRONG EXAMPLES

Weak: “Use AI to improve deviations.”

Strong: “The system retrieves approved site procedures and produces a nonauthoritative draft checklist for trained deviation investigators. The investigator must compare every item with the cited controlled source before copying selected text into the eQMS. The system does not determine root cause, product impact, CAPA, or disposition.”

Weak: “AI predicts equipment failure.”

Strong: “A static anomaly-detection model scores one-minute vibration windows from filling-line motor sensors and alerts maintenance when the threshold is exceeded. The alert schedules inspection but does not stop equipment, change parameters, or determine batch disposition. Use is limited to Models A and B operating within the evaluated speed and load ranges.”

CONTEXT OF USE AS A CREDIBILITY QUESTION

Context of use describes how a model’s output will be used to answer a question or support a decision. The credibility required depends on the consequence of being wrong, the degree of reliance, and the availability of independent controls.

Ask:

• Is the output advisory, determinative, or action-taking?
• Is it used once, repeatedly, or continuously?
• Can an error be detected before it affects quality or safety?
• Is the user capable of independent review?
• Are rare or difficult cases the most consequential?
• Does performance vary across sites, products, languages, equipment, or time?
• What evidence is available at the moment of decision?

APPROVED OPERATING ENVELOPE

Define the conditions under which evidence supports use:

• Included products, sites, instruments, populations, and languages
• Minimum input completeness and quality
• Model, prompt, retrieval, and application versions
• Allowed temperature, speed, range, data age, or technical limits
• Confidence or uncertainty treatment
• Required human review and escalation
• Allowed tools and permissions
• Availability and fallback

An output outside this envelope should be rejected, flagged, or routed—not silently processed.

PROHIBITED-USE DESIGN

A prohibition is credible only if it is communicated, technically constrained where feasible, monitored, and enforced.

Examples:

• Not used for batch disposition
• Not used to determine reportability of a complaint
• Not used with patient-identifiable data
• Not used to generate final approved procedures
• Not used outside English source documents
• Not permitted to execute an eQMS transaction

Controls may include disabled features, access restrictions, prompt guardrails, blocked tools, interface labels, training, usage analytics, and periodic review of actual queries.

REQUIREMENTS FLOW-DOWN

From the intended use, derive:

Functional requirements

What the system must retrieve, predict, generate, display, block, record, and route.

Data requirements

Required fields, acceptable missingness, age, format, source, lineage, quality, and representativeness.

Performance requirements

Metrics, subgroup limits, uncertainty handling, error tolerance, latency, availability, and robustness.

Human-control requirements

Source display, override, reason capture, escalation, review independence, and decision authority.

Record requirements

Input reference, model version, prompt version, output, citations, user action, timestamp, and final decision where applicable.

Monitoring requirements

Operational metrics, limits, review frequency, alert owner, and action.

WORKED EXAMPLE: GENERATIVE SOP COMPARISON

Proposed use: Compare a revised SOP draft with the currently approved SOP and identify potentially meaningful changes for a document owner.

Important boundaries:

• Both documents must come from the controlled repository
• The tool may highlight additions, removals, and semantic changes
• The output is a review aid, not the official redline
• The document owner must confirm every cited section
• The system cannot approve, release, or replace the controlled document
• Tables, images, formulas, and scanned pages require separate handling
• Confidential content cannot be retained for provider training

Evaluation must include missed negation, changed numbers, reordered steps, table changes, embedded images, formatting-only changes, contradictory sections, and unsupported summaries. A general “helpfulness” score is inadequate.

INTENDED-USE CHANGE TRIGGERS

Treat these as potential scope changes:

• Advisory output becomes an automatic action
• New product, site, language, or data source
• User population changes
• AI output becomes part of a regulated record
• A new integration removes an independent check
• An optional feature is enabled
• Model output is reused for a second decision
• Review time is reduced or reviewers lose source visibility

INTENDED-USE REVIEW FORM

System and feature:

Process:

User and competence:

Inputs and authoritative sources:

AI operation:

Output:

Decision or action:

Human review:

Operating envelope:

Prohibited use:

Records created:

Failure and consequence:

Fallback:

Owner and approval:

PRACTITIONER REVIEW QUESTIONS

1. Could a new team member determine exactly what is approved?

2. Is reliance on the output explicit?

3. Are important exclusions technically enforced?

4. Can evaluation data represent the approved envelope?

5. Does monitoring detect use outside the envelope?

PROFESSIONAL INTERPRETATION

The intended-use statement is not introductory prose. It is the first control and the organizing logic for the validation package. If performance cannot be evaluated against it, rewrite it.

PRIMARY SOURCES

FDA CSA final guidance on identifying intended use:

www.fda.gov/media/188844/download

FDA draft guidance, Considerations for the Use of AI to Support Regulatory Decision-Making for Drug and Biological Products. Draft; not for implementation:

www.fda.gov/regulatory-information/search-fda-guidance-documents/considerations-use-artificial-intelligence-support-regulatory-decision-making-drug-and-biological

FDA and EMA, Guiding Principles of Good AI Practice in Drug Development:

www.fda.gov/about-fda/artificial-intelligence-drug-development/guiding-principles-good-ai-practice-drug-development