Anyone working in regulated production thinks in versions. A system is specified, tested and released, and every later change goes through change control. This way of thinking has proven itself. With AI, it reaches a limit.
What can change with AI
An AI model is the product of code, training data and settings. If any of the three changes, the behaviour changes. Add a fourth factor that plays no role in classic systems: the data in operation. When raw materials, plants or processes change, a model that was good at release can slowly get worse. Specialists call this drift.
For validation, this means: the release describes a state that does not stay stable on its own.
Three kinds of change
For an AI system in a regulated environment, it helps to distinguish three kinds of change:
- Planned change to the model. A model is retrained, extended or replaced. That is a change like any other and belongs in change control, with assessment, testing and release.
- Change at the supplier. If the AI sits inside purchased software or a cloud service, the supplier can swap the model. Whether and how they announce it belongs in the contract and the supplier assessment.
- Gradual change in operation. Nobody changes anything, but the results shift. This kind is the most dangerous, because no change request triggers it.
Monitoring instead of a one-off acceptance
The answer to the third kind is ongoing monitoring. Before release, you define how the quality of the model is measured and from which deviation you act. In operation, this indicator is checked regularly. If it crosses the threshold, that is an event with a defined procedure: assess, roll back to the last released version if needed, retrain, release again.
This is not foreign to validation. It is the consistent application of periodic review to a system that can change in operation. The relevant industry guidance now addresses AI and machine learning explicitly as well.
Where an AI management system helps
ISO/IEC 42001 looks at AI across its entire life cycle: from intended purpose through data and development to operation, monitoring and decommissioning. Connecting validation to it gives you both: the rigour of the GxP world and a structure that can cope with how AI moves.
What follows
- Version models like software, including training data and settings.
- Define before release how quality is measured and from which deviation you act.
- Oblige suppliers to announce model changes.
- Define a fallback: the last released version or a process without AI.
With AI, a release is not an end point. It is the start of observation.