After Go-Live: Keeping a Validated AI Model in a Validated State in Pharma Manufacturing

The validation report describes one moment in time

On the day an AI model goes live in a GMP process, the validation report describes one fixed moment. One model version was tested on one set of data, on equipment set up one way, by people trained on the procedure as it stood that week. The report proves the model was fit for its intended use at that moment. Month 7 needs its own evidence.

Everything around the model starts to move as soon as the project closes. Raw material suppliers change, cameras get replaced, an IT team updates an image server and the software supplier ships a new release. A conventional computerised system behaves the same way on Tuesday as on Monday unless someone changes it. An AI model's behaviour depends on the data it sees, so it can move even when nobody touches it.

The FDA's January 2025 draft guidance on AI to support regulatory decision-making for drugs has a section on life cycle maintenance. It says that in pharmaceutical manufacturing, changes to the AI model, or changes in manufacturing that may affect its performance, should be evaluated through the manufacturer's change management system within the pharmaceutical quality system [1]. The draft EU GMP Annex 22, published for consultation in July 2025, closes with an operation section that covers change control, configuration control, performance monitoring and monitoring of input data [2]. Both texts are still drafts as of October 2026. The underlying duty is older, though. 21 CFR 211.68(a) already requires automatic and electronic equipment to be "routinely calibrated, inspected, or checked according to a written program" [3].

The illustration used below is hypothetical: a vision model on a blister packaging line that rejects packs with missing or broken tablets. The same logic applies to models that support batch record review or deviation trending.

Write the monitoring plan before go-live

The monitoring plan belongs in the validation package, approved alongside the summary report. If it's written after go-live, the thresholds tend to be drawn from the first few weeks of live data, and they end up describing whatever the model happens to be doing. Limits taken from the validation results hold the model to what was actually proven.

The plan says what is measured and where the data comes from, what the limits are and who set them, who reviews the results and how often, and what happens when a limit is crossed.

For the packaging line, the most direct measure is performance against a human answer. A trained inspector re-examines a fixed daily sample of the packs the model accepted and the packs it rejected. That gives a running estimate of missed defects and false rejects to set against the validation figures. The validation acceptance criteria become the action limits. A tighter alert limit is set inside them, so the team gets a warning before the model reaches the edge of what was proven. Each limit has a written rationale, because an inspector will read it.

Other measures come straight from the line, such as the reject rate by shift and simple image checks for brightness and focus. They give an early signal when something upstream has changed, and the daily human sample then confirms whether the model is still right.

Name the owners before the project team leaves

Most AI projects are delivered by a team that disbands at go-live. The data scientist moves to the next model, the vendor's consultant goes home and the monitoring plan passes to whoever is left. A planned hand-over keeps the monthly review running after the project team has gone.

Four roles are worth naming in writing. A process owner in operations owns the intended use and the decision to keep using the model. A system owner in IT owns the platform, the pipeline and configuration. A named technical owner, internal or contracted, can investigate model behaviour and run a retraining. Quality assurance approves the plan, the limits and every change. If a supplier provides the technical expertise, the quality agreement says so, including response times when a limit is crossed.

Retraining goes through change control

A retrained model is a new model. It may use the same architecture and the same code, but different training data gives different behaviour, and the validated state belonged to the old version.

Draft Annex 22 deals with this by scope. It covers static models whose parameters are fixed once training ends, and it says models that keep learning during use should not be used in critical GMP applications [2]. In practice, almost every model in a GMP process today is locked. It changes only when someone retrains it and releases a new version on purpose.

That makes retraining a planned change, and it can be planned long before it is needed by writing a retraining protocol into the change control procedure. The protocol defines what can change, such as new images of the same defect classes, and what stays fixed (the intended use, the defect classes and the acceptance criteria). It also fixes how a new version is tested. The most useful element is a frozen challenge set held under quality control, which the training team never sees. Every candidate version is tested on it and compared side by side with the version in service, and the new version is released only if it meets the same acceptance criteria. Figure 1 shows how monitoring, triage and this kind of change fit together as one loop.

The medical device world has a formal mechanism for this idea. The FDA's final guidance of December 2024 on predetermined change control plans (PCCPs) lets a device maker describe planned modifications to AI-enabled device software, the protocol for making them, and an impact assessment, all agreed in advance in the marketing submission [4]. A PCCP is a device concept. A drug manufacturer can still apply the same thinking to its in-house models. For drug products, ICH Q12 established conditions and post-approval change management protocols are the nearest regulatory tools, and the FDA draft guidance mentions established conditions as an option for AI models [1, 5]. For most site-level models, the retraining protocol is an internal procedure within the quality system.

Figure 1. The post-go-live control loop for a locked AI model. Monitoring results, supplier notices and site changes all feed one triage step, and anything that changes the model or its inputs passes through change control and re-verification before the baseline is updated.

A supplier's model update is a change at the site

Many manufacturing AI models arrive inside a supplier's product, such as a camera system or an MES module. The supplier retrains and ships new versions on its own timetable, so the site's validated state can change through an ordinary software update.

The contract and quality agreement provide most of the control here. The site needs advance notice of any change to a model, release notes that say what changed and how performance was measured, and the right to hold a version until its own testing is complete. That testing means the frozen challenge set again, run on the new version before it touches product. A supplier's performance data from other customers is useful context. The site's own test shows how the model performs on this line, under this lighting. The ISPE GAMP Guide: Artificial Intelligence, published in July 2025, sets out supplier responsibilities across the AI life cycle and gives a sound basis for those terms [6].

Changes upstream can shift what the model sees

For operations, the practical point about drift is that most of it has a cause that someone, somewhere, recorded as a change.

A new blister foil supplier changes reflectivity. A replacement camera has a slightly different lens. An IT team changes an image compression setting to save storage. An upstream system renames a field that a batch review model reads. Each of these changes the images or data the model receives.

The fix is to treat the data pipeline as part of the validated system. Cameras, lighting, image servers, interfaces and preprocessing settings go under configuration control, in line with the configuration control expectation in the draft Annex 22 operation section [2]. The site change control form then asks a plain question for every change: does this affect any input to an AI model? Monitoring then acts as a second check.

When the model gets it wrong

Sooner or later a model will make a mistake that matters. A pack with a missing tablet reaches a customer, or a trend review shows that false rejects have doubled over a month.

An escaped defect is a deviation and is investigated like any other. 21 CFR 211.192 requires a thorough investigation that extends to other batches that may be affected [3]. For an AI model the question becomes: which batches did this model version inspect, and since when could the cause have been present? A site that keeps a version register, showing which model version was in service on which line and on which dates, can answer it in an afternoon. A site without one may have to treat every batch since go-live as suspect. Part 11 already expects revision and change control over systems documentation, and the version register is part of that record [7].

Root cause analysis needs some categories beyond those of a conventional CSV investigation: a change in inputs, errors in the training labels, an operating threshold set in the wrong place, or a defect type the model has never seen. Each leads to a different CAPA. Retraining fixes a gap in the training data, while a moved camera needs an engineering fix and a re-check. Interim controls, such as 100% manual inspection of accepted packs or a narrower intended use, keep product moving while the CAPA is worked.

A rising false reject rate is a quality signal too, even when every defective pack is caught. It costs yield and shows the model has moved, so it goes through the same quality event process as an escaped defect.

Plan the rollback before it is needed

Every live model needs a tested rollback route. The previous validated version should stay deployable for a defined period after a new release, and the team should have shown during validation that switching back works.

The manual method the model replaced is the other route back. If the model has to be suspended, the site must still be able to inspect packs the old way, with a current procedure and trained staff. Two years after go-live, the people who knew the manual process may have moved on, so the fallback is worth rehearsing.

Decommissioning follows the same discipline as any GxP system retirement. The model files, the training data references, the challenge set and the validation and monitoring records are kept for as long as the batches they supported need records.

Periodic review of an AI system

EU Annex 11 has required periodic evaluation of computerised systems since 2011, and ICH Q10 expects management review of process performance [8, 9]. An AI system's periodic review covers the usual CSV ground and then a few things more. Is the intended use still accurate? How does the performance trend compare with the validation baseline? Is the challenge set still representative of today's products and defects? Taken together, how much have the small changes since go-live added up to? And are the people who review model output still trained and still checking?

The first review is worth doing earlier than it would be for a conventional system. The first months of live data are where the gap between validation data and production data shows up.

What an inspector asks for a year after go-live

At go-live, an inspector reads a validation package. A year later, the questions are about control over time. Figure 2 lists the questions that come up and the records that answer them. A site that builds these records as it goes can answer each question on the day.

The FDA's Computer Software Assurance guidance, finalised in September 2025 and revised in February 2026, puts assurance effort where risk is highest [10]. It was written for device production and quality system software, and the same principle applies to AI models. For an AI model, much of that risk comes after go-live.

Figure 2. What an inspector asks for one year after go-live, and the records that answer each question.

A validation package shows the model worked on the data the project team chose. The records of the following year show the organisation kept it working on the data the plant produced.

References

1. US Food and Drug Administration. Considerations for the Use of Artificial Intelligence to Support Regulatory Decision-Making for Drug and Biological Products. Draft guidance for industry, January 2025 (docket FDA-2024-D-4689; draft, not for implementation, as of October 2026). https://www.fda.gov/media/184830/download
2. European Commission. EudraLex Volume 4, EU GMP Guidelines, Annex 22: Artificial Intelligence. Draft for stakeholder consultation, published 7 July 2025, consultation closed 7 October 2025; not adopted as of October 2026. https://health.ec.europa.eu/consultations/stakeholders-consultation-eudralex-volume-4-good-manufacturing-practice-guidelines-chapter-4-annex_en
3. US Code of Federal Regulations. 21 CFR Part 211, Current Good Manufacturing Practice for Finished Pharmaceuticals, sections 211.68 and 211.192. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-C/part-211
4. US Food and Drug Administration. Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions. Final guidance, December 2024. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/marketing-submission-recommendations-predetermined-change-control-plan-artificial-intelligence
5. International Council for Harmonisation. ICH Q12: Technical and Regulatory Considerations for Pharmaceutical Product Lifecycle Management, 2019. https://database.ich.org/sites/default/files/Q12_Guideline_Step4_2019_1119.pdf
6. International Society for Pharmaceutical Engineering. ISPE GAMP Guide: Artificial Intelligence, July 2025. https://ispe.org/publications/guidance-documents/gamp-guide-artificial-intelligence
7. US Code of Federal Regulations. 21 CFR Part 11, Electronic Records; Electronic Signatures, section 11.10(k). https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
8. European Commission. EudraLex Volume 4, Annex 11: Computerised Systems, 2011. https://health.ec.europa.eu/system/files/2016-11/annex11_01-2011_en_0.pdf
9. International Council for Harmonisation. ICH Q10: Pharmaceutical Quality System, 2008. https://database.ich.org/sites/default/files/Q10%20Guideline.pdf
10. US Food and Drug Administration. Computer Software Assurance for Production and Quality Management System Software. Final guidance, September 2025, revised February 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/computer-software-assurance-production-and-quality-management-system-software

The packaging line used throughout this article is a hypothetical illustration, not an account of a specific site or client.