An AI application can produce a well-written answer and still be unsuitable for the work a team expects it to perform. Before assessing risk or writing test cases, establish what the application will do, which information it will use and how its results will affect the process.
This chapter explains how to define that intended use. You will follow a fictional supplier-assessment application from an initial business idea to a clear statement of scope. You will also see how the same approach applies to reviewing validation records.
By the end, you should be able to describe the application boundary, separate generated information from authorized action, identify human responsibilities and write an intended-use statement that supports the next stages of assessment.
The examples describe proposed practices for a defined application. They are not universal regulatory requirements or evidence that a particular product is validated. The diagrams use fictional workflows and do not represent any employer's internal process.
1 Start with the decision the application will support
A project often begins with a broad request: “Use AI to automate supplier qualification.” That request describes an ambition, but it leaves the important questions unanswered. Will the application collect documents, extract certificate dates, draft findings, recommend a risk rating or approve the supplier? Will a person inspect the original records? What happens if an audit report is missing?
Each answer changes the scope of the work. A tool that locates documents needs evidence that it selects the right records. A tool that recommends a rating also needs an assessment of the criteria and information used to reach that recommendation. A tool that changes supplier status introduces questions about permissions, approval authority and recovery from an incorrect action.
Begin by describing the existing process. Identify the information entering it, the work performed, the decision made and the record that captures the result. Then show which activity the proposed application will support. This avoids assessing a product name while overlooking the actual function people intend to rely on.
In our example, a Supplier Quality engineer reviews a questionnaire, certification records and an audit report. The engineer prepares an assessment, resolves missing information and submits the assessment to an authorized approver. The proposed AI application assists with preparation. The business decision remains in the existing approval process.
The first question is therefore: What will change in the work, and which decision could be affected if the application is wrong or incomplete?
2 Distinguish information support from action execution
An AI application can perform several kinds of work in the same process. Describe each function separately before considering the combined workflow.
Extract information. The application reads a certificate and identifies the legal entity, site address and expiry date. The relevant question is whether those fields are taken from the correct record and represented accurately. An unreadable date should remain unresolved rather than being guessed.
Prepare content. The application drafts a summary of the supplier's audit findings. Several wordings may be acceptable, but significant information must not be omitted or presented with a different meaning. A fluent paragraph does not establish that the summary is complete.
Recommend a decision. The application suggests a supplier rating using defined criteria. This requires more than accurate extraction. The team must understand which criteria apply, how missing information is handled and who evaluates the recommendation before use.
Perform an action. The application creates a draft record, sends a message or changes a status through an integration. These actions need explicit scope. Permission to create a draft assessment does not imply permission to approve a supplier.
A system may combine extraction and drafting without recommending a rating. Another may recommend a rating without being allowed to execute it. Record these distinctions instead of describing all behavior as “AI assistance.”
The term “agent” is useful when software selects or performs actions through connected tools, but the label does not define its authority. Write down the actual tools, targets and permitted operations. A restricted agent and an unrestricted integration can create very different conditions even when they use the same model.
3 Identify the complete application boundary
The model is one component of the application. The result also depends on what information reaches it, the instructions it receives, the surrounding software and how people use its output.
For the supplier assistant, the assessed workflow includes document selection, text extraction, source retrieval, draft preparation and presentation to the reviewer. The document repository and supplier-management system may be separate systems, but their interfaces and relevant dependencies still need to be understood.
An error can arise before text generation begins. For example, a scanned audit table may be omitted during extraction. The generated summary may accurately reflect the extracted text while missing a significant finding in the original document. Testing only the summary's grammar would not detect the underlying problem.
For each component, identify its function and owner. Establish which configuration is controlled by the organization and which depends on a supplier. The organization may control the document collection and prompts while a service provider controls the hosted model. This division affects later supplier assessment and change control.
Human review belongs in the workflow description even though the reviewer is outside the software boundary. If the proposed control depends on a person comparing the draft with source records, the interface must make that work possible. Merely placing an approval box after an AI box does not show that review will be effective.
Keep the boundary diagram simple enough for business and technical reviewers to agree on it. It should reveal information sources, main processing functions, outputs, people and connected systems. Detailed implementation records can support the diagram without turning it into an unreadable architecture map.
4 Define inputs and operating conditions
An intended use should describe the conditions for which suitability will be assessed. The same application can perform differently when document format, language, source quality or user behavior changes.
For the first deployment in our example, assume the team proposes English-language digital PDFs associated with one supplier site at a time. Scanned documents and mixed-site packages are excluded until separately assessed. These are fictional project choices, not recommended restrictions for every application.
| Element | Definition for the example | Why it matters |
|---|---|---|
| Source identity | Records associated with a specified supplier and site | Prevents evidence for one site from supporting another |
| Required inputs | Questionnaire, applicable certificates and required audit evidence | Establishes what must be present before assessment completion |
| Document condition | Readable digital PDFs in English | Defines the conditions represented in evaluation |
| Source status | Identified records selected under the supplier process | Makes current, superseded and unresolved records distinguishable |
| Users | Authorized Supplier Quality personnel | Identifies expected knowledge, access and responsibility |
| Output destination | Draft assessment workspace | Prevents a draft from appearing as an approved record |
Required inputs should reflect the actual supplier process. A certificate is not automatically sufficient evidence of supplier suitability, and every supplier may not require the same documents. The example assumes the required document set has already been established through the applicable process.
Describe what happens to information as it moves through the application. If a long report is divided into sections for processing, determine how findings across those sections are retained. If the application retrieves only selected passages, explain how it identifies whether required assessment areas were considered. These questions will inform requirements and testing later.
Also distinguish information that is unavailable from information that was checked and found acceptable. “Audit evidence not provided” is not equivalent to “No significant audit findings.” The intended behavior should preserve that difference for the reviewer.
5 Define the output and the human decision
A useful output definition identifies both the format and its permitted use. “Generate a report” is incomplete because it does not explain what the report contains or what a person may conclude from it.
For the supplier assistant, the proposed output is a draft containing extracted information, summarized findings, source references, missing items and unresolved discrepancies. It does not state that the supplier is approved. The engineer checks the draft, resolves gaps and submits a completed assessment through the established process.
The engineer's review and the final supplier decision are separate activities. Review establishes whether the assessment is supported and complete for its purpose. The authorized approver makes the supplier disposition decision. Neither activity should be assumed to be performed by the application unless that function is explicitly proposed and assessed.
Consider what happens when the application cannot complete its task. If the required audit report is absent, it may prepare available sections while displaying an incomplete status and identifying the missing evidence. The draft must not conceal the gap or imply that the unsupported area was accepted.
The business process determines whether a missing item can be addressed through alternative evidence or another justified disposition. The application should not invent that disposition. Define who may make it and how it is recorded.
Finally, identify where the accepted assessment and decision are retained. A draft in a chat history, an approved assessment in a quality system and a supplier-status record are different objects. The team should be able to explain which is authoritative and how they relate.
6 Write a complete intended use statement
An intended-use statement should be short enough to read and specific enough to support assessment. Supporting records can contain detailed document rules, interfaces and technical settings. Avoid expanding the statement into the entire specification.
A practical writing structure is: The application supports [users] in [process] by using [inputs] to perform [functions] and produce [outputs]. The results are used for [purpose] under [conditions]. [Human role] performs [review or decision]. The application is not authorized to [excluded actions].
Worked example
The application assists authorized Supplier Quality engineers with preparation of supplier assessments. It extracts information and drafts findings from identified supplier questionnaires, certification records and audit evidence associated with one supplier site. The initial scope covers readable English-language digital PDFs selected under the supplier process.
The application produces a draft with source references, missing items and unresolved discrepancies. The engineer verifies the draft against the source records and resolves gaps before submitting the assessment through the established approval process. The application may save a draft assessment but cannot approve suppliers, change supplier status or send external communications. Missing required evidence keeps the assessment incomplete.
This statement identifies the supported task and leaves the final business authority clear. It does not claim that the application is suitable merely because the scope has been written. That conclusion depends on the assessments, controls and evidence developed in later chapters.
Check the statement against observable behavior
Ask whether a reviewer could determine when the application has exceeded its scope. In the example, sending a supplier email, processing unsupported scanned records or changing an approval status would be visible departures. A phrase such as “assist with supplier activities as needed” would not provide the same clarity.
Check that exclusions are reflected in the design and operating process. Where an application can technically perform an excluded action, record how that action will be prevented or controlled. Describing a restriction in a document is only the first step.
7 Apply the approach to validation record review
The same questions can be applied to a validation-document assistant. Assume the proposed application reads requirements, test execution records and deviation records, then prepares a list of items for a Validation engineer to review.
A suitable initial scope might permit the application to flag missing references, identify inconsistent execution statuses and list unresolved deviations. It would not independently approve deviations or conclude that the system is suitable for release.
Suppose a protocol exists in the repository, but execution is incomplete. Document presence supports the conclusion that a protocol is available. It does not support the conclusion that all tests passed. The intended use should distinguish checking whether a record exists from interpreting what its execution evidence demonstrates.
Example statement: “The application assists Validation engineers by identifying missing or inconsistent references across specified requirements, execution records and deviation records. It produces a review list linked to the relevant sources. The engineer determines the significance and disposition of each item. The application does not approve test results, close deviations or authorize system release.”
If the team later asks the application to write the final acceptance conclusion, assess that proposed function separately. It may require different source coverage, evaluation rules and controls from those used for reference checking.
This comparison shows why copying an intended-use statement between applications is rarely sufficient. Similar technology can support different decisions and require different evidence.
8 Recognize when the intended use changes
An application can expand beyond its assessed use without a new product name or model version. Users may submit new document types, rely on recommendations differently or connect another system. Identify those changes before treating existing evidence as applicable.
In the supplier example, enabling external email changes the application from preparing internal information to communicating with another organization. The team needs to consider recipients, attachments, approval, confidentiality and the consequences of an incorrect message. The fact that the model remains unchanged does not resolve those questions.
Adding another language also changes an operating condition. Evidence from English digital PDFs may be relevant background, but it does not establish suitability for every language or scan quality. Assess what is affected and identify the additional evidence needed.
When actual use has already expanded, consider the impact on work completed under the new conditions. Determine whether restrictions, record review or other actions are needed while the change is assessed. A future update to the intended-use document does not by itself address previous use.
9 Avoid common scope errors
| Weak description | What is missing | Better direction |
|---|---|---|
| Improve quality using AI | Defined activity and decision | Identify the task, output and person relying on it |
| Draft only | How the draft affects the process | State what is reviewed and how the result is used |
| Human approval required | Review activity and authority | Identify the source checks and final decision role |
| Uses approved documents | Identity, status and completeness | Define which records apply and how gaps are handled |
| Vendor says it is validated | Applicability to the configured use | Identify which evidence supports the intended functions |
| Same model as before | Changes outside the model | Review inputs, permissions, interfaces and user reliance |
These weaknesses often arise because the description follows product features rather than the business process. Walk through a real example from source records to final decision. Where the team disagrees about what should happen, record and resolve that uncertainty before proceeding.
10 Practice writing the intended use
Scenario
A Quality team proposes an AI application that reviews open quality events and prepares a weekly summary. The initial description says: “The application will analyze all quality data and identify issues requiring management attention.”
The team plans to provide open event records from one system. The application will summarize event status and flag records that meet predefined escalation criteria. A Quality engineer will review the output before the weekly meeting. The application will not change records or determine final escalation decisions.
Your task
Write an intended-use statement that identifies the users, source information, permitted functions, output, review responsibility and excluded actions. Explain what should happen if the source export is incomplete or the escalation criteria are unavailable.
Suggested answer
The application assists Quality engineers in preparing a weekly review of open quality events from the specified system. It uses an identified export and predefined escalation criteria to draft a status summary and flag records for review, with references to the relevant event identifiers.
The engineer verifies the completeness of the input set and reviews the draft before it is used in the management meeting. The application does not modify event records, close investigations or make final escalation decisions. If source completeness cannot be established or the applicable criteria are unavailable, the output identifies the limitation and remains incomplete for the intended management review.
This answer is stronger because it defines the data boundary and the decision supported. It also identifies the condition under which a normal-looking summary would be insufficient. The precise completeness check would be defined in requirements and evaluated later.
11 Confirm that the scope is ready for assessment
Before progressing, confirm that the team can answer the following questions consistently:
- What process and decision will the application support?
- Who will use it, and what will they rely on?
- Which information sources and operating conditions are included?
- What will the application extract, prepare, recommend or execute?
- Which components and interfaces affect the output?
- What remains with the reviewer and authorized decision-maker?
- What happens when evidence is missing, conflicting or unreadable?
- Which uses and actions are excluded, and how will restrictions be addressed?
- What changes would require reassessment?
Retain an agreed intended-use statement, a workflow or boundary diagram and the relevant assumptions and exclusions. These can be incorporated into existing system records rather than maintained as new standalone forms.
The next chapter uses this defined scope to assess quality impact and applicable requirements. A clear intended use gives that assessment a concrete starting point and helps prevent later testing from answering the wrong question.
References and reading
The chapter's workflow, examples and diagrams are original educational material. The following primary sources provide broader context; neither prescribes the fictional supplier workflow or the exact statement format used here.
- FDA Computer Software Assurance for Production and Quality Management System Software ↗, February 2026. Describes a risk-based assurance approach for software within its medical device production and quality management system scope.
- NIST Artificial Intelligence Risk Management Framework 1.0 ↗, January 2023, particularly the Map function. Provides context for understanding AI use, operating conditions and impacts as part of risk management.
Reference review date: 29 September 2026.