When an AI Model Is Retrained: A Change Control Decision Tree

Why Retraining Is the Change That Breaks Change Control

A conventional change control system is built around a stable assumption: the thing being changed is described by a specification, the change is a difference from that specification, and the assessment asks what the difference touches. Change a chromatography method parameter and you can point at the parameter. Change a line of configuration in a manufacturing execution system and you can point at the line. The assessment scopes itself.

A retrained model breaks that assumption in a specific way. Nothing in the specification changes. The intended use is the same, the input sample space is the same, the acceptance criteria are the same, the user interface is the same, the integration points are the same. What changed is a set of numeric parameters that no one can read and that the specification never described in the first place. The system behaves differently and the documentation says nothing has changed.

This is why so many retraining decisions in life sciences get made informally. A data science team notices performance sliding, adds three months of new images to the training pool, retrains, sees a better number on their internal test split, and asks quality to approve a like-for-like change. Quality has no basis to disagree and no basis to agree. The change record ends up saying something close to nothing, and the organization has quietly moved to a model that no one has independently tested.

The second reason retraining is hard is that the evidence supporting the original model was never organized in a way that makes partial reuse possible. A validation package written as one document, for one model, at one point in time, cannot answer the question “which of these sections still holds.” That question is the whole of retraining change control. If your package cannot answer it, every retrain looks like a full revalidation, and the practical result is that models do not get retrained at all. They sit in production, degrading, because updating them is more painful than tolerating the drift.

Retraining is a GxP event even when performance improves

There is a persistent belief that a retrain which improves a metric is self-justifying. It is not, for two reasons that matter to an inspector.

First, the improvement was measured on something. If the new test set is not independent of the new training data, the improvement is an artifact of measurement rather than a property of the model. Data leakage is not a hypothetical failure. A systematic survey of machine learning based science identified 17 fields with documented leakage errors, collectively affecting 329 papers, in some cases producing conclusions that did not survive reanalysis.¹⁵ Those were published papers under peer review. A retrain done under schedule pressure inside a company has fewer checks, not more.

Second, an aggregate improvement can hide a subgroup regression. A model that gains two points of overall accuracy while losing sensitivity on a rare but critical defect class has become worse at the thing it exists to do. Aggregate metrics are the wrong unit of analysis for a GxP acceptance decision, and the draft EU GMP Annex 22 is explicit that acceptance criteria may differ for specific subgroups within the intended use.¹

What the Regulatory Documents Say, and What Status They Hold

Before building a decision tree, it is worth being precise about what is actually in force, what is draft, and what applies to a different product category entirely. Getting this wrong in a validation rationale is an easy finding for an inspector to write.

Draft EU GMP Annex 22 is still a draft

The European Commission released a draft Annex 22 on artificial intelligence for public consultation in July 2025, alongside a revised draft Annex 11 on computerised systems and a revised draft of Chapter 4 on documentation.¹⁴ The consultation closed on 7 October 2025. As of September 2026 there is no adopted final text and no published implementation date. EMA’s GMP and GDP inspectors working group has continued to work the file, including a multistakeholder workshop in mid-2026 on how generative models might be handled, and the HMA and EMA AI group has continued meeting with industry.¹⁸ Nobody should be writing a procedure that claims Annex 22 compliance as a current regulatory obligation. It is entirely reasonable to design toward it, and we think teams should, but the status has to be stated accurately in the document.

What the draft says about change is short and unusually direct. Section 10.1 places the tested model, the system it runs in, and the whole process it automates or assists under change control before deployment. It then requires that any change to the model, the system, or the process, including any change to the physical objects the model uses as input, be documented and evaluated to determine whether the model needs to be retested. A decision not to retest has to be fully justified.¹

That single clause is the legal shape of the decision tree. The draft does not tell you when to retest. It tells you that you must decide, in writing, with a rationale, every time. The tree in this article is a way of making that decision reproducible rather than personal.

The joint FDA and EMA principles put lifecycle management on the record

In January 2026 EMA and FDA published a joint set of ten guiding principles of good AI practice in drug development, covering AI used to generate or analyze evidence across nonclinical, clinical, post-marketing, and manufacturing phases.²³ These are principles, not requirements, and both agencies said they are not prescriptive. They still matter, because they are the clearest signal yet of what two major regulators expect a lifecycle argument to look like.

Principle 9 is the relevant one. It calls for risk-based quality management systems implemented throughout the AI technology’s life cycle, including support for capturing, assessing, and addressing issues, and it says the technologies undergo scheduled monitoring and periodic re-evaluation to ensure adequate performance, giving data drift as the example.² Principle 2 sets the risk-based approach with proportionate validation. Principle 10 asks for clear, accessible information to the intended audience about the technology’s context of use, performance, limitations, underlying data, and updates.

Read together, those three principles say that a retrain is expected, that its depth of assessment should be proportionate to risk, and that the people relying on the model are entitled to know it happened. Most retraining procedures we see satisfy the first, gesture at the second, and forget the third entirely.

ICH Q10 supplies the change management system the tree plugs into

None of this replaces the pharmaceutical quality system. ICH Q10 already defines a change management system as one of the four elements of a pharmaceutical quality system. Section 3.2.3 requires that quality risk management be used to evaluate proposed changes with the level of effort and formality commensurate with the level of risk, that proposed changes be evaluated by expert teams contributing appropriate expertise from relevant areas, that prospective evaluation criteria for a proposed change be set, and that after implementation an evaluation be undertaken to confirm the change objectives were achieved and that there was no deleterious impact on product quality.¹⁰

Two of those four are the parts most AI retraining procedures skip. Setting prospective evaluation criteria means the acceptance criteria for the retrained model are agreed before the model exists, which is exactly what stops a team from choosing the metric that makes the candidate look best. And the post-implementation evaluation means a retrain is not finished when the model is released: Q10 expects a look back to confirm the change did what it was supposed to do. For a model, that means a defined post-release monitoring window with pre-agreed metrics, not a general intention to keep an eye on it.

FDA’s PCCP is a useful analogy and it is device guidance, not drug guidance

The structure is the useful part. A PCCP has three components: a description of the planned modifications, a modification protocol setting out the methods used to develop, validate, and implement those modifications, and an impact assessment. The final guidance broadened scope from machine learning specifically to all AI-enabled device software functions, and added recommendations that manufacturers consider the characteristics of their intended use populations and environments.⁶

What a PCCP does conceptually is move the regulatory conversation forward in time. Instead of assessing each change when it happens, the sponsor agrees in advance on the envelope of changes that are permitted and the protocol by which they will be qualified. Anything inside the envelope proceeds under the protocol. Anything outside it is a new conversation.

The drug side has had that concept for years under different names. ICH Q12 provides the post-approval change management protocol, a regulator-agreed protocol that defines the proposed change, the supporting studies, the acceptance criteria, and the intended reporting category before the change is made.¹¹ FDA’s 2022 final guidance on comparability protocols does the same thing for CMC postapproval changes, describing a comparability protocol as a comprehensive, prospectively written plan for assessing the effect of a proposed change.¹²

The pattern in all three is identical, and it is the pattern a retraining procedure should follow: decide the rules before the change, so that the change itself becomes an execution rather than a negotiation.

GAMP and the international device principles fill in the method

GAMP 5 second edition supplies the risk-based validation approach and the critical thinking framing that a proportionate retraining assessment depends on, and ISPE’s GAMP Guide on Artificial Intelligence, published in July 2025, extends that into model-specific territory. ISPE’s own formal comments on the draft Annex 22, submitted at the close of the consultation, are a good read on where industry thinks the draft is workable and where it is not.⁵

Two of the ten Good Machine Learning Practice guiding principles published by FDA, Health Canada, and MHRA in October 2021 speak directly to retraining. Principle 4 is that training data sets are independent of test sets. Principle 10 is that deployed models are monitored for performance and re-training risks are managed.⁸ Those principles were written for devices, but principle 4 in particular is a statement about the validity of measurement that does not change when the product category changes. The draft Annex 22 arrives at the same requirement through its own route, and goes further, requiring procedural or technical controls to prevent staff who have seen the test data from working on training and validation of the same model, with a four-eyes arrangement where that separation is impossible.¹

Six Retraining Cases That Are Not the Same Change

The first job of the tree is to identify which retrain you are actually doing. In practice, teams describe every one of these as “we retrained the model,” and the description hides the differences that determine the assessment.

Classifying the cases

A three-level classification is enough for most organizations, and more levels make the tree harder to apply consistently. We use like-for-like, minor, and major. The classification is a starting position, not a conclusion: any case escalates a level if the model supports a batch release decision, a product disposition, or a regulatory submission, and any case escalates if the post-retrain test shows a subgroup regression.

Why the scheduled versus drift-triggered distinction matters more than it looks

A scheduled retrain is a maintenance activity. A drift-triggered retrain is a response to something having gone wrong in the process, the instrument, the material, or the population. The retrain may still be the right response, but retraining against drift without investigating the drift means the model absorbs a process change that nobody has explained. If a camera’s illumination has degraded, retraining the classifier on the degraded images makes the model tolerant of a broken camera. That is not a model improvement. It is a masked equipment problem.

The draft Annex 22 anticipates this by requiring two separate monitoring streams: system performance monitoring against the defined metrics, with degradation or change of lighting conditions given as an explicit example, and input sample space monitoring with defined metrics for drift in the input data.¹ Those two streams answer different questions. Performance monitoring asks whether the model is still right. Input monitoring asks whether the world it was built for still exists.

The clinical machine learning literature is instructive on how much difference the trigger makes. A study of 143,049 adult inpatients across seven hospitals, published in JAMA Network Open in 2025, built a label-agnostic monitoring pipeline to detect harmful data shifts without waiting for outcome labels. It found significant shifts driven by demographic changes, hospital type, admission source, and changes to critical laboratory assays. Transfer learning improved performance at community hospitals by a modest margin, while drift-triggered continual learning during the COVID-19 period produced a far larger recovery in discrimination.¹³ The point for a GxP setting is not the specific numbers. It is that the retraining strategy which works depends on what caused the shift, which means you have to know what caused it before you choose.

The Decision Tree: Nine Steps from Trigger to Release

This is the operating procedure. It is written as an ordered sequence because the order matters: several steps exist specifically to stop the team from moving forward before a question has been answered. In practice these steps map onto a change request form with sections that cannot be signed out of order.

What Evidence Survives a Retrain and What Must Be Regenerated

This is the table that makes proportionate assessment possible. It only works if the original validation package was structured so that its parts can be cited individually. If your package is a single monolithic report, the first improvement to make is not a retraining procedure. It is breaking that report into addressable sections with their own version numbers.

The rows people argue about

Three rows generate most of the discussion in a review meeting.

Test data independence controls, case A. Teams want this to survive because nothing about the test set changed. But independence is a property of the relationship between two datasets, and one of them just changed. The evidence that has to be produced is a fresh check that the enlarged training pool does not intersect the test set, including near-duplicates. In an image application this means checking that the new images are not additional photographs of objects already represented in the test set. The draft annex makes this explicit for physical objects: objects used for the final test should not previously have been used to train or validate, unless features are independent.¹

Explainability evidence, case C. A hyperparameter change feels too small to disturb which features the model relies on. Sometimes that is true. Class weighting changes and augmentation policy changes are the exceptions, because both deliberately alter what the model pays attention to. The cheap protection is to keep a small fixed explainability sample, twenty to fifty records, and regenerate attribution on it after every retrain of any type. It takes an afternoon and it catches the case where the metrics held steady while the model started reading a different part of the image.

Confidence thresholds, everywhere. Thresholds are the most commonly forgotten artifact. A retrained model is usually better calibrated in some regions of its output range and worse in others, so a threshold tuned for the old model can push more cases into automated decisions than intended or fewer. Any change to the threshold is itself a change to the operating point and should be recorded as part of the change, not as a configuration detail.

Approval Authority and What the Release Record Must Contain

Classification without differentiated approval authority achieves nothing. If every retrain goes to the same board, the board becomes a rubber stamp for the routine cases and has no capacity left for the ones that matter.

Who approves what

• Like-for-like (case A with an unchanged sample space). System owner approves. QA reviews the change record and the test results, with authority to escalate. The process subject matter expert confirms in writing that the sample space is unchanged. No board.
• Minor (case C). System owner and QA approve jointly. Data science signs the parameter rationale. The process subject matter expert approves any change to the operating point, because that is a change to how the process behaves, not to how the model is built.
• Major (cases B, D, E, and anything escalated). Change control board including the process subject matter expert, QA, data science, IT, and the system owner. For case E, supplier quality attends. The board’s specific job is to decide whether the change is a change at all or the introduction of a new model that needs its own validation identity.
• Any case with a subgroup regression. Escalates to the board irrespective of starting classification, and the board decides whether to accept the regression with a documented rationale, reject the candidate, or accept it with a compensating control such as increased human review on the affected subgroup.

The release record

The release record is the document an inspector will ask for, and it should be readable on its own without requiring someone to reconstruct the story from a dozen systems. At minimum it contains:

• Model identity. A unique version identifier for the model artifact, the identifier of the model it replaces, a cryptographic hash of the deployed artifact, and the date and time it entered production.
• Case classification and rationale. Which of the six cases, why, and the written confirmation of whether the input sample space moved.
• Trigger record. What prompted the retrain, with a link to the deviation if the trigger was a drift or performance alarm.
• Training data manifest. The dataset version, record counts by subgroup, the date range covered, inclusion and exclusion rules applied, and the justification for any exclusion.
• Independence attestation. The evidence that test data did not enter training, the access control and audit trail records for the test repository, and the names of staff on each side of the separation.
• Approved protocol reference and any deviations from it.
• Test results. Aggregate and per-subgroup metrics against acceptance criteria, with pass or fail stated per criterion rather than summarized.
• Benchmark comparison. The frozen benchmark version, the incumbent’s score, the candidate’s score, the difference, and the disagreement analysis with the subject matter expert’s conclusions on the disputed records.
• Confidence and explainability artifacts. The threshold before and after, the undecided rule, and the attribution evidence at whatever depth the case required.
• Approvals. Named individuals, roles, and dates, matching the classification’s required approval level.
• Rollback plan. The retained prior artifact’s location, the trigger conditions for reverting, the technical steps, and the named decision-maker.
• Post-implementation review. The metrics, the window, the scheduled date, and later the outcome.
• User notification. What was communicated to the people who rely on the model’s output, and when.

That list looks long. In practice it fits on four pages and most of it is populated automatically from the model registry and the training pipeline. The effort is in building the record structure once, not in filling it in each time.

Two Worked Examples: A QC Image Classifier and a Document Classifier

The tree is easier to judge against concrete cases. Both examples below are constructed illustrations, not accounts of any particular organization’s system.

Example one: a QC image classification model for visual inspection

A model classifies images of filled vials into accept and reject categories, with reject subdivided into defect types: particulate, cosmetic, fill volume, and closure. It runs on an inspection line, output feeds a human reviewer who confirms rejects, and the model’s role in the process description is to reduce the volume of images requiring human review while maintaining the line’s established defect detection performance. Acceptance criteria are set per defect type, with the tightest criterion on particulate because that is the safety-relevant class.

The trigger. Monthly input monitoring shows a shift in the image brightness distribution starting eleven weeks ago. Model performance monitoring shows overall accuracy stable but a two-point decline in sensitivity on cosmetic defects.

Step 1. This is a drift-triggered retrain, case F modifier. A deviation is opened before any retraining work begins. The investigation finds a partial degradation in one of the inspection station’s LED arrays. That finding changes everything downstream: the correct first action is to repair the illumination, not to retrain the model to tolerate a failing light. The engineering fix is made. The model is then re-evaluated on post-repair images and found to be performing within criteria again.

What actually happens next. The deviation closes with an equipment CAPA and an added preventive control: illumination intensity is added to the input monitoring metrics with an alert threshold set below the level at which model performance was affected. No retrain occurs. This is the outcome a good decision tree produces most often, and it is the one that never appears in vendor material about model lifecycle management.

A second trigger, three months later. A new vial presentation is introduced on the same line, with a different glass supplier and a slightly different shoulder profile. Engineering asks for the model to be retrained to cover it.

Steps 2 through 4. The input sample space has moved: this is case B, major, with no argument available. The intended use description is revised to add the new presentation, and the subgroup structure is extended so that the new presentation is a subgroup within each defect type. The existing test set contains no images of the new vial, so it cannot demonstrate performance on it. New test images are captured after the training set is closed, using physical vials that have never been used in training, and are labeled by two independent inspectors with disagreements adjudicated by a third. The frozen benchmark is extended with a stratified sample covering both presentations so that the incumbent and candidate can be compared on the old presentation as well as the new one.

Steps 5 through 7. The protocol sets acceptance criteria per defect type per presentation. The candidate passes aggregate criteria and passes on the new presentation. On the frozen benchmark, it matches the incumbent on the old presentation for three defect types and loses one point of sensitivity on particulate for the old presentation. That is a subgroup regression on the safety-critical class.

What the board does with that. This is where the tree earns its existence. The regression is small, the aggregate numbers look good, and the pressure to release is real because the new presentation is on the production schedule. The board’s options are documented: reject the candidate and retrain with rebalanced class weighting for particulate on the old presentation, accept with a compensating control routing all old-presentation particulate borderline cases to human review, or accept the regression with a written risk rationale. Without the frozen benchmark and the per-subgroup criteria, none of these options would have been visible, and the model would have been released on its aggregate improvement.

Example two: a document classification model in regulatory operations

A model classifies incoming documents into a controlled taxonomy for a document management system: clinical study report, investigator brochure, site correspondence, regulatory authority correspondence, and so on. Misclassification does not directly affect product quality, but it affects retrievability, which affects inspection readiness and submission assembly. The model runs with a confidence threshold: above it, the classification is applied automatically; below it, the document is routed to a records specialist.

The trigger. The vendor supplying the classification component announces that the underlying pretrained language model is being upgraded to a new version, and that the old version will be retired in ninety days.

Step 1 and 2. This is case E crossed with case D: a vendor-pushed update that is also a change of underlying architecture. Both classify as major. The intended use has not changed and the document types have not changed, so the sample space is stable, but that provides no comfort here because the model’s internals have been replaced entirely.

The supplier conversation. The first action is not technical. It is to establish what the supplier will disclose: what changed, whether the previous version can be pinned for a defined period, whether the supplier ran any comparative evaluation, and what the quality agreement says about notification periods for model changes. If the answer is that the change is mandatory in ninety days with no comparative data, that is a supplier quality finding, and it should be recorded as one regardless of how the technical assessment turns out. A regulated user cannot accept a change to a GxP-relevant function on a timeline that does not permit assessment. The draft annex is clear that documentation for these activities should be available and reviewed by the regulated user whether the model was built in-house or supplied.¹

Steps 3 and 4. Test data independence takes a different form here. You cannot verify that your test documents were excluded from the supplier’s pretraining corpus, and for a general-purpose pretrained model you should assume public documents may have been included. The response is to build the acceptance test set from documents that are internal and were never public: internal correspondence, internal study documents, site communications. Those cannot have been in the vendor’s pretraining data. The frozen benchmark is a stratified sample across all document types, including the low-frequency types that carry the most retrieval risk.

Steps 5 through 8. The protocol specifies per-class acceptance criteria, with tighter criteria on regulatory authority correspondence than on general site correspondence because misfiling the former has a larger consequence. Testing shows the new version improves on most classes and degrades on one: it now confuses two adjacent document types that the previous version separated cleanly. The confidence distribution has also shifted upward across the board, meaning the existing threshold would send fewer documents to human review than before, including some of the newly confused ones. The threshold has to be reset, and reset on data, not by preference.

The release decision. The board accepts the new version with three conditions: the threshold is lowered for the two confused classes specifically, creating a class-conditional threshold rather than a single global one; the records specialists are briefed on the specific confusion so they know what to look for; and the post-implementation review at sixty days examines the misclassification rate on those two classes specifically rather than reporting an overall number. The user notification is not optional here. People who have learned to trust the model’s behavior are entitled to know that its behavior changed, which is what the joint FDA and EMA principle on clear, essential information is asking for.²

Rollback, Parallel Running, and Writing the Rules Down in Advance

Rollback is a control, not a contingency

A model rollback is easier than most software rollbacks and harder than teams assume. Easier, because the artifact is a file and reverting to the previous file is mechanically simple. Harder, because of everything around the file.

Four things have to be retained for a rollback to be real:

• The exact prior artifact, with its hash, held under configuration control for a defined retention period rather than on whatever storage the last deployment happened to use.
• The prior artifact’s full runtime dependency set. A model file is useless without the library versions, preprocessing code, and configuration it was tested with. Reverting the model and not the preprocessing produces a system that was never validated in that combination.
• The prior thresholds and configuration. If thresholds moved with the retrain, rolling back the model without rolling back the thresholds produces a third configuration nobody has tested.
• The records produced under the new model. Every output the new model produced between release and rollback needs to be identifiable, because a rollback implies that those outputs may be suspect. Which means every record has to carry the model version that produced it. If your records do not carry a model version, you cannot roll back cleanly, and you should fix that before you fix anything else in your retraining procedure.

The rollback trigger conditions belong in the change record, agreed before release. Useful triggers are concrete: performance on a defined metric falling below a stated value over a stated window, the human override rate rising above a stated level, or a confirmed misclassification on a safety-relevant subgroup. A trigger that says “if problems are observed” is not a trigger.

Parallel running: what it proves and what it does not

Running the candidate model alongside the incumbent in production, with only the incumbent’s output acted upon, is the strongest evidence available for a major change. It is also frequently misunderstood.

What a parallel run proves. It shows how the two models behave on genuinely current production inputs, which is the population your test set can only approximate. It surfaces disagreements at a volume no curated test set reaches. It exposes throughput, latency, and integration problems before they matter. And it gives you a real distribution of confidence scores under production conditions, which is the only sound basis for setting a threshold.

What a parallel run does not prove. It is not a substitute for the independent acceptance test, because production inputs are unlabeled at the moment they arrive. A disagreement between two models tells you they differ; it does not tell you which is right. That determination requires adjudication by a subject matter expert on a sample of the disagreements, and that adjudication is the actual evidence. A parallel run reported as a percentage agreement, with no adjudication, is a number without meaning: two models can agree ninety-eight percent of the time and differ precisely on the cases that matter.

How to size it. Long enough to cover the process’s natural cycles. For a manufacturing model that means multiple batches, multiple shifts, and ideally more than one raw material lot. For a document model it means a period long enough to include the low-frequency document types. A two-week parallel run on a process with a monthly cycle proves less than it appears to.

A caution specific to GxP. The candidate model running in production is running in a production environment, and its outputs are being recorded. Decide in advance whether those shadow outputs are GxP records. Our position is that they should be treated as such, because they are being used to support a validation decision, which means they need the same integrity controls as any other record supporting a quality decision. Treating them as informal test output and then citing them in a validation report is the kind of inconsistency that does not survive an audit.

Write the rules before you need them

The final point is the one that determines whether any of this is usable. Every framework discussed here, the PCCP structure in device regulation, the post-approval change management protocol in ICH Q12, the comparability protocol in FDA’s CMC guidance, does the same thing: it moves the argument to before the change.⁶¹¹¹²

Applied to model retraining inside a pharmaceutical quality system, that means writing a retraining plan at the time the model is first validated, as part of the original validation package. The plan states, for that specific model:

• The retraining triggers, both scheduled and threshold-based, with the thresholds stated numerically.
• The changes permitted without escalation, which is to say the definition of like-for-like for this model, written specifically enough that two different people would classify the same change the same way.
• The changes that automatically escalate, including any change to the input sample space.
• The acceptance criteria and subgroup criteria that any future model must meet, so they are not renegotiated under pressure.
• The benchmark set identity and its governance.
• The independence controls and how they will be evidenced each time.
• The approval matrix by classification.
• The rollback plan and its trigger conditions.

None of this requires a regulator to agree in advance, which is the difference from a formal PCCP or PACMP. It is an internal commitment, held in the quality system, that makes each subsequent retrain an execution of an approved plan rather than a fresh negotiation. That is what turns a decision tree from a diagram in an article into something a team can actually run on a Tuesday afternoon when the monitoring dashboard turns amber.

Conclusion

Retraining is the change that exposes whether an AI governance framework was written to be used or written to be shown. A framework that treats every retrain identically will either exhaust the organization or wave through changes nobody assessed. The alternative is not more procedure. It is a small number of decisions taken early: define the input sample space precisely enough that you can tell when it moves, set acceptance criteria per subgroup rather than in aggregate, hold a frozen benchmark that no one trains against, keep the test data genuinely independent and be able to show it, and write down what counts as like-for-like for each specific model before the first retrain arrives.

The regulatory picture is going to keep moving. Annex 22 is still a draft with no final text and no implementation date, the joint FDA and EMA principles are deliberately non-prescriptive, and the PCCP framework that offers the cleanest structural analogy belongs to a different product category. None of that is a reason to wait. Every element of the decision tree in this article is defensible today under ICH Q10 change management and a risk-based validation approach, and every element of it will still be defensible when the final texts land. Organizations that build this now will be adjusting a working system rather than starting one.

Sakara Digital works with pharma and biotech organizations putting AI models into GxP processes and keeping them there through the changes that follow. If you are working out how to classify retraining changes, or you have a validated model you have been reluctant to update because the change control path is unclear, we are happy to have that conversation.

For Further Reading