An AI tool that passed validation in March can fail an inspection in October without anyone touching it, and the reason is the quiet thing that separates AI assurance from classical software assurance: the validated state can erode while everyone is looking elsewhere. A vendor ships a model update that nobody in the function noticed. The writing group starts feeding the tool a new study type it was never qualified on. The retrieval index behind the grounding quietly fills with stale documents. None of these trips an alarm, because classical software does not drift and the function's quality system was built for software that does not drift. This lesson is about the control that catches the erosion before an FDA investigator does: ongoing performance monitoring with deliberate drift detection, organized around acceptance criteria for production performance, explicit re-validation triggers, logging that satisfies a Pre-Approval Inspection, and the adoption of the predetermined-change-control-plan pattern, borrowed from the FDA's framework for adaptive AI/ML medical-device software, as the working model for any learning AI in a regulated workflow. A validation protocol proves the tool was safe on one day. Monitoring is what keeps the claim true.

Why a Validated State Erodes, and Classical QA Does Not Notice

The deepest reason monitoring is non-negotiable for AI is that the validated state of an AI tool is a moving target in a way the quality system was never designed to track. Classical computerized-system validation rests on an assumption so basic it is rarely stated: the software behaves the same way today as it did when you validated it, so a one-time qualification plus change control on visible code changes is sufficient. That assumption holds for deterministic software and fails for AI in three distinct ways, each invisible to a quality system that is watching for the wrong thing. The first is vendor-driven model change, where an LLM behind a vendor API shifts behavior when the vendor updates the underlying model, sometimes without a version bump the function can see. The second is input drift, where the data the tool is fed in production gradually diverges from the cases the validation characterized. The third is silent degradation in the surrounding pipeline, where a retrieval index, a grounding source, or a configuration drifts out from under the model.

What makes all three dangerous is that none of them produces an error message. The tool keeps producing fluent, confident, structurally correct output the entire time it is degrading, because fluency is decoupled from correctness in a language model, so the surface signal a human would normally use to notice a problem is exactly the signal that stays constant while the substance rots. A quality system tuned to deterministic software waits for a change event, a code deployment, a configuration change ticket, a documented update, and none of the AI drift modes necessarily generates one. The function can be fully compliant with its classical change-control SOPs and still be running a tool whose behavior has shifted materially since validation, which is the precise scenario that converts a clean validation history into an inspection finding when an investigator samples recent output and finds it no longer meets the criteria the validation claimed.

This is why monitoring is not an optional enhancement to validation but a structural requirement of validating AI at all. The validation protocol establishes the baseline, the characterized performance on a known test set in a pinned configuration, and the monitoring program is what detects departure from that baseline in production. Without monitoring, the validation is a photograph of a moving object, accurate the instant it was taken and decreasingly trustworthy every day after. The FDA-EMA Guiding Principles name this explicitly through the model-performance-monitoring and ongoing-lifecycle-monitoring principles, which exist precisely because the agencies understood that AI assurance cannot be a point-in-time event. The strategist's job is to translate those principles into a concrete monitoring program, and that program begins with deciding what to measure.

Acceptance Criteria for Production Performance

Monitoring is only as good as the acceptance criteria it monitors against, and production acceptance criteria are a different object from the ones in the validation protocol. The protocol's acceptance criteria are property invariants checked against a curated test set with known correct answers; production acceptance criteria have to be computable from the live workflow, where there is no answer key sitting beside each output, only the record of what the tool produced and what the humans did with it. The strategist's task is to identify metrics that are both meaningful proxies for tool performance and actually available from the production audit trail, because a metric you cannot compute from the record you keep is a metric you do not have. This constraint shapes the whole program: you monitor what the workflow can observe.

The richest available signal is usually the human-edit pattern, because the verification step that the validation depends on also produces data about how the tool is performing. The rate at which verifiers correct quantitative values, the frequency of finding-attribution corrections, the proportion of cross-references that fail to resolve, the volume of substantive edits versus stylistic ones, all of these are observable from the edit record and all of them move when the tool drifts. A sudden rise in the quantitative-value correction rate is a signal that the tool's fidelity has changed; a rise in unresolved cross-references is a signal that its citation behavior has shifted; a change in the overall human-edit burden is a signal that something in the tool, the inputs, or the pipeline is different. These are the production acceptance criteria, expressed as thresholds on observable metrics: the cross-reference resolution rate shall remain above a defined floor, the quantitative-value correction rate shall remain below a defined ceiling, and a breach triggers investigation.

Setting the thresholds is the strategic act, and it requires the baseline that the validation produced, because a threshold without a baseline is a guess. The validation characterizes the tool's normal performance, the expected human-edit rate, the expected resolution rate, the expected correction frequency, and the monitoring thresholds are set relative to that characterized normal, with a margin that distinguishes genuine drift from ordinary variation. Set too tight and the program drowns in false alarms that train the function to ignore the signal; set too loose and real degradation slips under the threshold until it shows up as bad submission content. The strategist also has to decide the cadence, the window over which metrics are aggregated, because a daily rate is noisy and a yearly rate is too slow to catch drift before it does damage, and the right window is the one that surfaces a real shift within a period short enough to act on it before the affected content reaches a submission.

What Triggers Re-Validation

Monitoring detects change; re-validation is what the function does about it, and a monitoring program without defined re-validation triggers is an alarm with no response attached. The triggers fall into two categories, and the strategist has to specify both, because relying on only one leaves a gap an inspector will find. The first category is performance-based triggers: a monitored metric breaches its threshold, indicating the tool's behavior in production has departed from the validated baseline, and the breach itself is the trigger regardless of whether anyone can point to a cause. The second category is change-based triggers: a known change occurs that could affect the validated state, a vendor model update, a system-prompt revision, a retrieval or grounding change, a new study type or document type entering scope, and the change is the trigger regardless of whether a metric has yet moved. Performance-based triggers catch drift you did not cause; change-based triggers catch drift you did cause before it shows up in the metrics.

The change-based triggers are where the discipline from the validation and CSA lessons pays off, because they depend on the configuration being pinned and the changes being visible. If the function has pinned the model version, the system prompt, the grounding configuration, and the temperature, then any change to those is a discrete, detectable event that fires the trigger. If the function has not pinned them, a vendor update can change the tool with no event to detect, which is exactly why version pinning is a monitoring prerequisite and not merely a validation one. The vendor-driven change case is the hardest, because the function may not control or even be notified of the vendor's update, which is why the monitoring program needs both the change-based trigger, fired when the vendor announces an update, and the performance-based trigger, fired when the metrics move whether or not the vendor told you, as a backstop for the updates the vendor ships silently.

Re-validation does not always mean repeating the full performance qualification; the response should be proportionate to the trigger, which is the same risk-based logic that CSA brings to initial assurance. A minor, well-characterized change to a low-risk tool might warrant a targeted re-test of the affected behavior; a vendor model update to a higher-risk tool, or a metric breach whose cause is unknown, warrants a fuller re-qualification against the test set. The strategist defines this response matrix in advance, mapping trigger type and tool risk to the required re-validation scope, so that when a trigger fires the function executes a predetermined response rather than improvising under time pressure. An improvised response to a drift event is both slower and less defensible than a planned one, and the plan is what an investigator wants to see: not that drift never happens, but that the function has a defined, proportionate, documented way of handling it when it does.

Logging That Satisfies an FDA Inspector at a PAI

Everything in the monitoring program rests on logging, and the standard the logging has to meet is concrete: it has to satisfy an FDA investigator who arrives for a Pre-Approval Inspection and asks to see how the AI tool that touched the submission was controlled. That investigator is not interested in the function's intentions; they are interested in the record, and the record either demonstrates control or it does not. The PAI is the forcing function that determines what the logging has to capture, because the investigator's questions are predictable even if their arrival is not: which model and version produced this content, what sources was it given, what was the human verification, who performed it, what did the monitoring show, and what happened when a threshold was crossed. A logging design that cannot answer those questions on the specific content in the submission is a logging design that fails the inspection.

This means the audit trail has to be both complete at the individual-output level and aggregable at the program level, and these are different requirements that the logging must serve simultaneously. At the individual level, each piece of AI-touched content in the submission must trace to its full provenance: the model and version, the configuration, the sources, the raw draft, the human edits and the verifier, and the final approved text, all attributable, contemporaneous, and enduring under 21 CFR Part 11. At the program level, the same records must roll up into the monitoring metrics, the resolution rates and correction frequencies over time, so the function can show not just that one document was controlled but that the tool's performance was tracked across all the work it did. The investigator who asks about one document is testing the individual trace; the investigator who asks how you know the tool stayed in spec is testing the program-level rollup, and a logging design that serves one but not the other passes half the inspection.

The hardest part of the logging to get right is the evidence of action, the record of what the function did when monitoring detected something, because that is where intentions and reality diverge and where an investigator probes hardest. A monitoring program that detected a threshold breach and shows a documented investigation, a root-cause determination, and a proportionate re-validation is a program demonstrating control. A monitoring program that detected the same breach and shows nothing, or shows that the data sat unreviewed, is worse than no monitoring, because it proves the function had the signal and did not act on it, which is the kind of finding that escalates. The logging therefore has to capture not only the metrics but the review of the metrics, the decisions taken, and the closure of each triggered event, so that the record tells a complete story of a control that operates rather than a dashboard that merely exists. The strategist who designs logging for the PAI designs it to answer the question the investigator will actually ask, which is not "do you monitor" but "show me what you did the last time monitoring caught something."

The PCCP Pattern as the Working Model for Learning AI

For AI that learns, that updates its behavior as it ingests data rather than holding fixed weights, the entire monitoring frame has to deepen, and the most useful available model for doing so is the predetermined change control plan. The PCCP is the FDA's framework for adaptive AI/ML medical-device software functions, finalized for that device context, and its conceptual move is precisely the one a learning AI in a regulated workflow needs: instead of validating a fixed state and re-validating after every change, you specify in advance the envelope of permitted change, the modifications you anticipate, the protocol by which they will be made and tested, and the assessment of their impact, so that change within the envelope is pre-authorized and governed rather than requiring a fresh validation each time. The PCCP validates a trajectory of permitted evolution rather than a single point.

Borrowing the PCCP pattern for non-device production AI is exactly that, a borrowing of the conceptual framework, and the strategist must be precise about the boundary, because the PCCP is a device-software construct and CSA, which governs the production-software side, explicitly does not apply to medical-device software. The function is not filing a PCCP with the FDA for its internal drafting tool; it is adopting the PCCP's three-part logic, anticipated modifications, modification protocol, and impact assessment, as the internal governance pattern for any tool whose behavior is permitted to evolve. A learning AI without this pattern is unvalidatable in the classical sense, because the thing you validated is changing underneath you and a point-in-time qualification describes a system that no longer exists; the PCCP pattern is what makes a learning tool governable, by defining the bounds within which it may change and the evidence that change within those bounds remains acceptable.

The practical translation is a governance document, internal to the function, that does for the learning tool what the validation protocol does for the static one. It states what kinds of behavioral change are anticipated and permitted, the protocol by which the tool's performance is re-characterized after each change, and the impact assessment that determines whether a change keeps the tool within acceptable performance or pushes it outside, in which case the change is rejected or the tool is taken out of the validated workflow until re-validated. This document binds directly to the monitoring program, because the monitoring is what verifies that the evolving tool stays inside the envelope the PCCP-pattern document defines, and to the change-control logic, because change-within-envelope and change-outside-envelope get different responses. For most regulated functions in 2026 the safest posture is to prefer static, version-pinned models precisely because they are governable with classical change control, and to adopt the PCCP pattern deliberately and with full monitoring only where a learning tool's value justifies the additional governance burden, which is a strategic judgment the function must make consciously rather than inheriting by accident when a vendor enables continuous learning by default.

Integrating Monitoring Into the Quality System

A monitoring program that lives in a strategist's spreadsheet is not a control; it becomes a control only when it is integrated into the function's quality system with assigned ownership, defined cadence, and a real escalation path, and that integration is the final piece that converts the design into something durable. The reason integration matters is the same reason the logging has to show evidence of action: a monitoring activity that depends on one person remembering to look is a monitoring activity that lapses the moment that person is on vacation, reorganized, or overloaded, and a lapsed monitoring program is exactly the gap an inspection finds. Embedding the monitoring in the quality system, with a named owner of the review, a defined review cadence tied to the metric window, and an escalation path that routes a threshold breach into the existing deviation and CAPA machinery, makes the control survive the people who run it.

This integration is also what makes the monitoring program legible to the rest of the organization, which matters because the AI tool's assurance does not live in isolation from the function's broader quality posture. When a threshold breach escalates through the same deviation process the function uses for every other quality event, the AI tool's monitoring becomes part of the quality system the inspectors already understand, rather than a novel parallel process they have to evaluate from scratch. The Quality Council sees AI monitoring in the same management-review cadence as everything else; the QA function audits it the way it audits any control; the deviation owners handle an AI drift event with the same rigor as any deviation. This normalization is strategically valuable, because it moves the AI tool from being a special, suspect thing that the organization is nervous about to being a controlled system handled by the machinery the organization trusts.

The strategist's deepest responsibility here is to ensure the monitoring program is honest about its own limits, because an over-claimed monitoring program is its own liability. Monitoring on human-edit signals detects drift that changes what humans correct, but it is blind to a failure mode where the tool degrades and the humans degrade with it, accepting worse output without correcting it, which is why the program should include periodic independent checks against known-answer cases as well as the live-signal monitoring. Monitoring tells you the tool has changed; it does not by itself tell you the change is acceptable, which is the judgment the re-validation makes. And monitoring is a detection control, not a prevention control, so it reduces the time a drifted tool operates undetected but does not prevent the drift, which is why it sits alongside the verification step rather than replacing it. A strategist who presents monitoring as a complete answer over-claims; a strategist who presents it as the detection layer in a defense-in-depth that includes verification, version pinning, change control, and re-validation has described a system an inspector will recognize as genuinely controlled.

Key Takeaways

• A validated state for an AI tool erodes in ways classical QA does not notice, which makes monitoring a structural requirement of validation, not an enhancement. Vendor model updates, input drift, and silent pipeline changes shift the tool's behavior without producing an error message, because fluency is decoupled from correctness, so a function fully compliant with classical change control can still be running a drifted tool that fails when an investigator samples recent output.
• Production acceptance criteria must be computable from the live audit trail, and the richest signal is the human-edit pattern. Quantitative-value correction rate, unresolved cross-reference rate, and overall edit burden are observable proxies that move when the tool drifts, expressed as thresholds set relative to the validation baseline with a margin that distinguishes genuine drift from ordinary variation, monitored over a window short enough to act before affected content reaches a submission.
• Re-validation needs both performance-based and change-based triggers, with a proportionate predetermined response. Performance triggers fire on a metric breach regardless of cause and catch drift you did not create; change triggers fire on a vendor update, prompt revision, or new document type regardless of whether metrics have moved; version pinning is what makes change triggers detectable, and a response matrix maps trigger and tool risk to re-validation scope so the function executes a plan rather than improvising.
• Logging has to satisfy a Pre-Approval Inspection, which means complete individual-output provenance, program-level rollup, and above all evidence of action. The investigator's real question is not "do you monitor" but "show me what you did the last time monitoring caught something," so the logging must capture the metrics, the review of the metrics, the decisions, and the closure of each triggered event, because a detected breach with no documented response is worse than no monitoring.
• The PCCP pattern, borrowed from the FDA's adaptive AI/ML device framework, is the working model for learning AI, but the SaMD boundary stays sharp. For a tool permitted to evolve you adopt the three-part logic of anticipated modifications, modification protocol, and impact assessment internally to validate a trajectory rather than a point, while most regulated functions in 2026 should prefer static, version-pinned models and adopt the learning pattern only deliberately, with monitoring integrated into the quality system as the detection layer in a defense-in-depth, not as a standalone answer.