A quality lead asks you to "validate the AI tool" before it touches a Module 2.5, and if you have come up through computerized-system validation you reach instinctively for IQ, OQ, and PQ: Installation Qualification, Operational Qualification, Performance Qualification. The instinct is correct, but applying the classical model to an LLM-augmented workflow without translation produces a validation that is simultaneously too much and too little. Too much, because you will waste effort trying to qualify a non-deterministic model as if it were a deterministic instrument that gives the same answer every time. Too little, because the thing that actually carries regulatory risk, the AI-augmented workflow with its verification gates and its human signatories, is not the binary you installed but the system of model, prompts, sources, gates, and people operating together. This lesson translates IQ/OQ/PQ from a calculus that assumes determinism to one that assumes probabilistic output bounded by human controls, and it anchors the whole exercise to the FDA-EMA "fitness for purpose" principle, which is the standard that decides whether your validation is adequate or theater.

Why You Validate the Workflow, Not the Model

The first translation is the most important and the most resisted: you do not validate the model, you validate the workflow. A large language model is non-deterministic by design, as the temperature lesson in Level 1 established, so demanding that it produce identical output on identical input the way a qualified balance produces identical mass readings is a category error. The model will give you a different draft on a second run, and that variability is not a validation failure, it is the nature of the instrument. What you can validate, and what regulatory risk actually attaches to, is the workflow that wraps the model: the defined intended use, the loaded sources, the verification gates from the previous lesson, the human signatories, and the audit trail. The workflow is the thing whose behavior is bounded and demonstrable even though the model inside it is not.

This reframing resolves a confusion that paralyzes many teams. They ask "how can I validate something that gives a different answer every time," and the answer is that you are not validating the answer, you are validating that the system catches and corrects the answer when it is wrong, and that a named human owns the output that advances. A workflow is fit for purpose not because the model is always right but because the controls reliably convert a probabilistic draft into an attestable record. The acceptance criterion of the workflow is never "the model produced the correct hazard ratio"; it is "every hazard ratio the model produced was reconciled to source by a named verifier before it advanced, and the gate blocked advancement when it was not." Validation, in this framing, is the demonstration that the human-and-controls layer performs reliably around an inherently unreliable generator.

The consequence for scope is sharp. Your validation package is scoped to a workflow with a stated intended use at a specific step, not to a product name across all possible uses. "Validate CoAuthor" is not a validatable statement; "qualify the AI-augmented TLF-to-narrative drafting workflow for Module 2.7.3 efficacy sub-summaries, with the gate, sources, and signatory defined" is. This is the IQ/OQ/PQ expression of the step-level governance from the first lesson of this chapter and the gate design from the second: the unit of validation is the same unit you mapped and gated, the intended-use-bounded step, and the validation either demonstrates that this bounded workflow is fit for that purpose or it does not.

Installation Qualification: Is the System Built and Configured as Specified

Installation Qualification in classical CSV asks whether the system is installed and configured according to specification, and the translation to an AI workflow is more substantive than it first appears, because an LLM workflow has configuration that is invisible and consequential. IQ for an AI workflow documents and verifies the model identity and version, the system prompt content and version, the temperature and other sampling parameters, the retrieval configuration if RAG is used, the connection to the source-of-truth repositories, the connection to the records system such as Veeva Vault QualityDocs, and the configuration of the verification gates including which transitions enforce a record before advancement. Each of these is a configuration item that determines workflow behavior, and IQ establishes that they are set as the specification requires and that they are under change control so that an undocumented change to any of them is detectable.

The model version and the system prompt deserve special IQ attention because they are the two configuration items most likely to change silently and most consequential when they do. A vendor model update can alter behavior without any action on the sponsor's part, and the Level 1 lesson on the hidden system prompt established that the system prompt does much of the work that determines whether output is grounded. IQ therefore captures the exact model version and the exact system prompt as installed, establishes the baseline against which the OQ tests were run, and ties both to change control so that a model update or a system prompt edit triggers a re-qualification assessment rather than passing unnoticed. A workflow whose model version is "whatever the vendor is serving today" has no stable IQ baseline, which means its OQ and PQ evidence expires the moment the vendor pushes an update, and the FDA's PCCP framing, which the program treats as the working model for managing learning AI, is the discipline that makes this manageable rather than chaotic.

IQ also documents the human side of the installation, because in an AI workflow the trained verifier and the authorized signatory are part of the installed system in a way they are not for a passive instrument. The IQ record establishes who is qualified to perform the verification at each gate, what their training comprised, and what authority they hold to sign under Part 11 Subpart C. This is the point where the gate design from the previous lesson is bound to named, trained, authorized people, so that when OQ tests whether a gate fires correctly, there is a qualified person on the other side of it. An AI workflow installed with perfect technical configuration but no qualified verifiers is not correctly installed, because the control that carries the regulatory weight has no one competent to operate it.

Operational Qualification: Does the Workflow Behave as Intended

Operational Qualification in classical CSV challenges the system across its operating range to confirm it behaves as intended, and for an AI workflow OQ tests the controls, not the model's accuracy. The central OQ question is whether the verification gates and the audit trail operate as designed under controlled, representative conditions. OQ confirms that a gate fires at every AI touch-point, that advancement is technically blocked when the reconciliation record is incomplete, that the disposition fields cannot be left empty, that the audit trail in Veeva Vault QualityDocs captures the model version, system prompt identity, sources loaded, dispositions, verifier, signatory, and timestamps, and that the exclusion-boundary gate at a prohibited step records the human authorship of the conclusion. These are deterministic properties of the workflow even though the model is not deterministic, and they are exactly what OQ can and must establish.

A particularly important OQ test is the negative test, the deliberate injection of a known error to confirm the workflow catches it. You construct a representative input where the correct hazard ratio is known, run the workflow, and confirm that when the model produces a wrong or fabricated value, the gate's reconciliation step surfaces the discrepancy and blocks advancement until it is corrected, producing a "corrected against source" disposition in the record. This is the AI-workflow analogue of challenging an instrument with a known standard: you are not testing whether the model is accurate, you are testing whether the control catches the model's inaccuracy. A workflow that passes its OQ only on clean inputs has demonstrated nothing about the failure mode that matters, because the entire reason the controls exist is the model's capacity for confident invention, and OQ must prove the controls engage precisely when that capacity manifests.

OQ also establishes the acceptance criteria that PQ will measure against in production, and writing these criteria is where the fitness-for-purpose principle becomes concrete. An acceptance criterion for an AI-ready TLF-to-narrative workflow might be that every factual claim in the output is reconcilable to a loaded source and that the gate blocks any output containing an unreconcilable claim, with a target that no unreconciled claim ever advances. An acceptance criterion for an AI-assistive consistency workflow might be that the AI surfaces a defined minimum proportion of seeded inconsistencies in a challenge set, establishing that the assistive function adds genuine detection value rather than false reassurance. These criteria are intended-use-specific, measurable, and tied to the purpose the workflow serves, which is the operational meaning of fitness for purpose, and a validation that omits measurable acceptance criteria has skipped the step that makes it real.

Performance Qualification: Does It Hold Up Under Real Workload

Performance Qualification in classical CSV confirms that the system performs reliably under actual operating conditions over time, and PQ is where an AI workflow is most different from a deterministic instrument, because the population that PQ observes is not "did the readings stay in spec" but "did the human-and-controls layer keep catching the errors the workflow exists to catch." PQ observes the workflow over a real production run, a real set of Module 2.7.3 sub-summaries or a real CSR cycle, and measures whether the gates fired as designed, whether the disposition record shows a credible rate of caught-and-corrected errors, whether any output advanced without a complete record, and whether the verifiers and signatories performed their roles. The disposition-rate signal from the previous lesson is a primary PQ metric: a workflow whose production record shows zero corrections across a large body of complex drafts is failing PQ even if no error reached the submission, because the absence of corrections more likely reflects perfunctory verification than a flawless model.

PQ also confronts the dimension that classical CSV barely contemplates, which is drift. A deterministic instrument drifts mechanically and is recalibrated; an AI workflow can drift because the vendor updated the model, because the source documents changed character, or because the human verifiers, lulled by months of mostly-correct drafts, relaxed their reconciliation. PQ is therefore not a one-time event but an ongoing monitoring obligation, which aligns directly with the FDA-EMA principle of ongoing lifecycle monitoring and with the PCCP model for managing AI that changes after deployment. The PQ design specifies what is monitored, at what cadence, and what triggers re-qualification: a model version change, a sustained shift in the disposition rate, a change in the source corpus, or an audit finding. This is the point where the validation stops being a document filed once and becomes a living control that tracks a moving system.

The fitness-for-purpose principle reaches its sharpest expression in PQ, because PQ is where you demonstrate, with production evidence rather than design intent, that the workflow is fit for the purpose you scoped it to. Fitness for purpose is not a property the model has; it is a property the validated workflow earns by showing, over a real run, that its controls reliably bound the model's output to the standard the purpose requires. A TLF-to-narrative workflow is fit for the purpose of drafting Module 2.7.3 sub-summaries when the production record demonstrates that no unreconciled claim advanced, that errors were caught at a credible rate, and that named humans owned every output, all under an audit trail an inspector can read. That demonstration, not the model's benchmark scores and not the vendor's marketing, is what "validated" means for an AI workflow, and it is what survives the Day 74 question about how the sponsor knows its AI-assisted summaries are trustworthy.

Writing the Intended Use and Fitness-for-Purpose Statement

Every validated AI workflow rests on two short documents that most teams write last and should write first: the intended use statement and the fitness-for-purpose statement. The intended use statement says precisely what the workflow is for and, just as importantly, what it is not for. "This workflow drafts first-draft Module 2.7.3 efficacy sub-summary narrative from finalized TLF tables, for human reconciliation and sign-off; it does not author efficacy conclusions, benefit-risk integration, or any content for which loadable ground truth does not exist." The boundary clause is the load-bearing part, because it is what prevents the validated workflow from being stretched, after the fact, onto a step it was never qualified for, which is the most common way a validated workflow becomes an unvalidated one without anyone noticing.

The fitness-for-purpose statement then asserts, and the IQ/OQ/PQ evidence substantiates, that the workflow is adequate for that stated use given the risk of that use. This is the direct application of the FDA-EMA fitness-for-purpose principle, which holds that the rigor of validation should match the risk and the role of the AI in the decision, so a workflow that produces a first draft for full human reconciliation requires a different and lighter validation than one whose output would advance with lighter human review. The statement names the risk, names the controls that bound it, and asserts that the demonstrated performance meets the acceptance criteria for that risk level. Writing this statement first disciplines the entire validation, because it forces you to decide what the workflow is for and how much rigor its risk demands before you design the qualification, rather than discovering after the fact that you qualified the wrong thing to the wrong standard.

These two statements are also what an inspector reads first, because they tell the inspector what claim the sponsor is making and therefore what evidence to demand. A crisp intended-use statement with a clear boundary clause, backed by IQ/OQ/PQ evidence proportioned to a stated risk, presents an inspector with a coherent validation story: here is what the workflow does, here is the line it does not cross, here is why the rigor matches the risk, and here is the production evidence that it performs. A validation that opens with "we validated the AI tool" and cannot state a bounded intended use or a risk-proportioned fitness-for-purpose claim presents the inspector with the opposite, an assertion of compliance with nothing underneath it, which is the validation that fails at exactly the moment it is needed.

The PCCP Mindset for a Workflow That Changes

The hardest thing about validating an AI workflow is that the thing you validated does not hold still, and this is where the FDA's Predetermined Change Control Plan framing, finalized for AI-enabled device software functions and adopted by the program as the working model for any production AI in regulated content, earns its place in the IQ/OQ/PQ mindset. A PCCP-style approach anticipates the changes the workflow will undergo, the model version updates, the system prompt refinements, the expansion to an adjacent step, and specifies in advance the protocol for assessing and qualifying each kind of change, the acceptance criteria the changed workflow must still meet, and the impact assessment that decides whether a change is within the pre-authorized envelope or requires fresh qualification. This converts the moving-target problem from a recurring crisis into a managed lifecycle.

Without this mindset, every model update is an emergency: the vendor pushes a new version, the IQ baseline is invalidated, the OQ and PQ evidence is suddenly stale, and the team either scrambles to re-qualify or, worse, keeps operating on expired validation because re-qualifying is too disruptive. With the PCCP mindset, the workflow's validation includes a modification protocol that says, in advance, what happens when the model version changes: re-run the OQ negative tests against the new version, confirm the acceptance criteria still hold, document the assessment, and either confirm the existing fitness-for-purpose claim or re-qualify. The change is expected, the response is specified, and the validation stays current because currency was designed into it. This is the mature expression of the IQ/OQ/PQ mindset for AI: not a one-time qualification of a static system, but a designed, monitored, change-controlled lifecycle for a system that learns and updates, which is the only honest way to validate something that, by its nature, will not be the same next quarter as it is today.

Key Takeaways

• Validate the workflow, not the model. The model is non-deterministic by design, so demanding identical output is a category error; what you validate is that the gates, sources, signatories, and audit trail reliably convert a probabilistic draft into an attestable record, scoped to an intended-use-bounded step rather than a product name.
• Installation Qualification captures the invisible configuration and the human side. Model identity and version, system prompt content and version, sampling parameters, retrieval and repository connections, gate configuration, and the trained, authorized verifiers and signatories, all under change control so an undocumented change is detectable and triggers re-qualification.
• Operational Qualification tests the controls, not the model's accuracy, including a negative test. Confirm gates fire, advancement blocks without a record, dispositions cannot be empty, the exclusion boundary is recorded, and a deliberately injected known error is caught and corrected, because the controls exist precisely for the model's capacity for confident invention.
• Performance Qualification proves fitness for purpose with production evidence and confronts drift. The disposition-rate signal is a primary metric, a zero-correction record on complex drafts fails PQ, and PQ is an ongoing monitoring obligation aligned to the lifecycle-monitoring principle with defined re-qualification triggers, not a one-time event.
• Write the intended-use and fitness-for-purpose statements first, and adopt the PCCP mindset. The boundary clause prevents a validated workflow from being stretched onto an unqualified step, the fitness-for-purpose claim proportions rigor to risk per the FDA-EMA principle, and a predetermined change-control protocol keeps the validation current through model updates rather than letting every update become an emergency.