Decommissioning a GxP AI System: Records, Weights, and Retention

What Counts as the Record for an AI-Supported Decision

Start with the question that decides everything else: when an inspector asks how a decision was made, what do you have to be able to show?

For a conventional computerized system the answer is well settled. You show the record, the audit trail, and the procedure. 21 CFR 11.10 requires the ability to generate accurate and complete copies of records in both human readable and electronic form, protection of records to enable their accurate and ready retrieval throughout the retention period, and audit trail documentation retained for a period at least as long as that required for the subject electronic records.³ The record is the thing in the database. The audit trail explains who changed it and when. Those two artifacts, plus the controlling procedure and the training record, close the loop.

An AI-supported decision does not close the same way. The output of the model is a number, a rank, a flag, or a piece of text. It is not self-explaining. If someone asks in 2033 why the model flagged batch 4471 for investigation in 2026, the flag itself answers nothing. The explanation lives in the relationship between an input, a model, and a configuration, none of which are visible in the record that the flag produced.

The seven components

In practice, the reconstructable record for one AI-supported decision has up to seven components. Not every system needs all seven, and part of the work of a decommissioning plan is deciding which ones this system needs. But the list is the starting point, and it is longer than most retirement procedures assume.

Read that table again with the decommissioning question in mind. Three of the seven components are held by the vendor by default. One of them, the input data as it existed at the moment of inference, is usually the responsibility of a system that is not the AI system at all, and that has its own retirement schedule. Only the last row is reliably inside your quality management system.

Human review changes what you have to keep

There is one distinction that changes the size of the retention problem more than any other, and it is worth settling early in the plan. Was the model output a formal input into a GxP decision, or was it a supporting signal that a qualified person independently evaluated before acting?

If a human being reviewed the underlying evidence, formed an independent judgment, and documented the reasoning, then the GxP record is that human’s assessment. The model output is context. It should be retained as part of the record, because it informed the decision and pretending otherwise would be inaccurate, but the burden of proof does not require replaying the model. You have to show what the reviewer saw and what they concluded.

If the model output was accepted without independent evaluation, or if the volume of decisions makes meaningful independent evaluation implausible, then the model is part of the decision-making apparatus and the reconstruction burden is much heavier. This is not a legal loophole to be exploited by writing “reviewed by” on a form. Inspectors look at whether review was real, and a review step that clears three hundred model outputs an hour is not review. But when human evaluation is genuine and documented, it legitimately reduces what you need to keep in order to defend the decision later.

Settle this per use case, not per system. One platform can host a model whose outputs are always independently evaluated and another whose outputs feed straight into a disposition, and the two need different retention treatments even though they retire on the same day.

Where Retention Periods Actually Come From

A decommissioning plan that says “retain per SOP” has not answered the question. The retention period for the artifacts of a retired AI system is derived, not declared. It comes from the records the system touched, and those records get their periods from regulation and from the commercial life of the product.

The FDA anchors

For drug products, 21 CFR 211.180(a) requires that any production, control, or distribution record specifically associated with a batch be retained for at least one year after the expiration date of the batch, or three years after distribution for certain OTC products that lack expiration dating.¹ Paragraph (c) adds the availability requirement: records must be readily available for authorized inspection during the retention period at the establishment where the activities occurred, and records that can be immediately retrieved from another location by computer or other electronic means are considered to satisfy that requirement.¹ Paragraph (d) permits retention as original records or as true copies.¹

That last clause is doing quiet work in every archiving decision, and it is the clause most often stretched too far. A true copy preserves content and meaning. Whether an extracted CSV of model outputs, stripped of the application that gave those outputs context, still preserves meaning is a judgment you have to make and document rather than assume.

Clinical and nonclinical work have their own anchors. 21 CFR 312.62(c) requires an investigator to retain records for two years following the date a marketing application is approved for the indication being investigated, or, if no application is filed or the application is not approved for that indication, until two years after the investigation is discontinued and FDA is notified.⁴ Good laboratory practice retention under 21 CFR 58.195(b) is set as the shortest of three periods: at least two years after approval of an application the study supported, at least five years after the study results were submitted in support of an application, or at least two years after the study is completed, terminated, or discontinued where no application follows.⁵

One provision in the GLP regulation deserves attention from anyone writing vendor exit terms. 21 CFR 58.195(h) states that if a facility conducting nonclinical testing goes out of business, all raw data, documentation, and other material must be transferred to the archives of the sponsor of the study, and FDA must be notified in writing of the transfer.⁵ That is a regulatory expectation that evidence follows the sponsor rather than dying with the supplier. It applies to testing facilities, not to software vendors. But the principle it encodes is exactly the principle your AI vendor contract should encode by agreement.

The EU anchors

EudraLex Volume 4, Chapter 4 sets the European GMP documentation expectations.⁶ Section 4.10 requires that it be clearly defined which record relates to each manufacturing activity and where that record is located, with secure controls to maintain the integrity of the record throughout the retention period, validated where appropriate. Section 4.11 requires batch documentation to be kept for one year after expiry of the batch to which it relates or at least five years after certification of the batch by the Qualified Person, whichever is longer, and for investigational medicinal products, at least five years after completion or formal discontinuation of the last clinical trial in which the batch was used.

Section 4.12 is the one that turns a five-year problem into a twenty-year problem. It states that critical documentation, including raw data relating to validation or stability, which supports information in the marketing authorization should be retained for as long as that authorization remains in force.⁶ If an AI system contributed to validation data or to a stability program that supports a filed dossier, its output is tied to the commercial life of the product rather than to the life of a batch.

Note the range in that row of numbers. Six months and twenty-five years are both real requirements that can apply to different artifacts of the same platform. A decommissioning plan that picks one number and applies it to everything will either destroy something it needed or pay to keep everything forever.

The AI-specific layer, and its actual timing

The EU AI Act adds record-keeping obligations for high-risk systems. Article 12 requires that high-risk AI systems technically allow for the automatic recording of events over their lifetime.¹² Article 19 requires providers to keep those automatically generated logs, where the logs are under their control, for a period appropriate to the intended purpose of the system and of at least six months, unless a different period is provided in applicable law.¹³

Be careful with the timing, because it changed in 2026 and a lot of material still circulates with the old dates. Under the AI Omnibus, which entered into force on 27 July 2026, the high-risk obligations apply from 2 December 2027 for stand-alone Annex III systems and from 2 August 2028 for high-risk AI embedded in products regulated under Annex I.¹⁴ Anyone planning a decommissioning schedule that assumes those duties are already binding is planning against the wrong calendar. Anyone assuming they can be ignored is planning against a calendar that runs out during the retention period of systems being built now.

Predicate rules decide, not Part 11

There is a point of nuance here that saves a great deal of argument. FDA’s guidance on the scope and application of Part 11 states that the Agency intends to exercise enforcement discretion with regard to the Part 11 requirement for protection of records to enable accurate and ready retrieval throughout the retention period, and that persons must still comply with all applicable predicate rule requirements for record retention and availability.² The same guidance suggests basing the decision on how to maintain records on predicate rule requirements, and on a justified and documented risk assessment together with a determination of the value of the records over time.²

That is a direct instruction on how to build the retention section of a decommissioning plan. Do not start from Part 11. Start from the predicate rule that governs the record, decide what the record is worth over time, write down the reasoning, and let that drive what you keep and in what form. The 2024 final FDA guidance on electronic systems, records, and signatures in clinical investigations reinforces the same posture for the clinical side.¹⁸

The Weights Question: Keep, Summarize, or Let Go

This is the question every team asks first, and the honest answer is that it depends on whether reproducibility of a specific past decision is something you will actually be required to demonstrate.

No regulation in force today says “retain model weights.” Searching for one is a waste of a week. What the regulations say is that you must be able to reconstruct the record and defend the decision. Whether that requires the weights is a function of how the model was used and what claim you will need to support later.

Four levels of reconstruction, and what each one needs

It helps to be explicit about what “reproduce the decision” means, because people use the phrase for four quite different things.

Most GxP use cases need Level 1 or Level 2, and a well-designed inference record delivers both without preserving a single parameter. If every inference writes a durable record containing the input values, the model identifier and version, the configuration in force, the output, any confidence or explanation artifact produced at the time, and the reviewing user with their disposition, then the reconstruction obligation is met by a normal database record that can be archived like any other GxP data.

Level 3 becomes the requirement in a narrower set of situations: where the model output was the effective decision without meaningful human evaluation, where a specific past decision is likely to be challenged individually, where the model contributed to a regulatory submission whose underlying evidence may be re-examined, or where a contractual or legal commitment to re-execution exists. Those situations are real, and when you are in one, plan for the weights and everything around them.

Level 3 is harder than keeping a file

The most common planning error is treating weight preservation as a storage problem. It is a determinism problem. Research on deterministic machine learning has documented that major machine learning libraries default to non-deterministic algorithms, and that fixing all random seeds is not by itself sufficient to make training deterministic.¹⁶ Inference is generally more stable than training, but it is not automatically bit-identical across library versions, hardware, or numerical precision settings.

What that means for a decommissioning plan is that “we saved the weights” is not the same commitment as “we can re-execute and get the same answer.” If Level 3 is your requirement, the preserved package has to include the weights, the inference code, the preprocessing steps, a pinned dependency manifest, a container image or an equivalent environment definition, and a documented test that demonstrates the package still reproduces a known set of outputs. And that test has to be repeated periodically, because a container image that has not been started in six years is an assumption, not a capability.

Documentation that outlives the artifact

There is a middle path that is undervalued. Even where you decide not to preserve a re-executable model, you can preserve a full description of it. The practice of structured model and dataset documentation, established in the machine learning literature through model cards and dataset datasheets, produces exactly the kind of artifact that survives technology change: a human-readable account of what the model was trained on, what it was intended for, how it performed, on which populations, and what its known limitations were.¹⁷

A dataset datasheet records provenance, composition, collection process, preprocessing, and intended uses.¹⁷ A decade later, when the container will not build and the framework has been rewritten twice, that document is still readable and still answers most of the questions an inspector asks. It is cheap to produce at the time and impossible to reconstruct afterward. Produce it during operation, retain it with the archive, and treat it as a controlled document rather than as engineering notes.

Readable and Retrievable Twenty Years From Now

Retention is a promise about the future, and the future part is the hard part. A record retained on media nobody can read, in a format nobody can open, described by nobody who is still employed, has been kept in a bookkeeping sense and lost in every sense that matters.

The digital preservation field has thought about this for longer than the pharmaceutical industry has, and the reference model is worth borrowing. The Open Archival Information System reference model, published by CCSDS and adopted as an international standard, defines an archive as an organization of people and systems that has accepted responsibility to preserve information and make it available to a designated community.⁸ Three of its ideas transfer directly to GxP work.

The first is the designated community. An archive is preserved for someone specific, and what has to be preserved depends on what that community will independently understand. Your designated community for a retired AI system is a future inspector plus a future quality investigator, neither of whom will have worked on the project.

The second is representation information. A bit stream is not a record. What makes it a record is the additional information required to interpret it: the schema, the code lists, the units, the meaning of each field, and the description of the process that produced it. Preserving the data without the representation information preserves an artifact that cannot be read.

The third is preservation planning as an ongoing function rather than a one-time act. Formats become obsolete, media degrade, and the software needed to interpret content stops running. The model treats migration and periodic review as continuing responsibilities of the archive.⁹ Guidance from the digital preservation community stresses that an archive is an active undertaking with people accountable for it, not a storage location.⁹

European GMP expects the same behavior in a shorter sentence. Chapter 4 requires secure controls to maintain the integrity of the record throughout the retention period, validated where appropriate.⁶ “Throughout” is the operative word, and it means the control has to hold in year eighteen, not only on the day the archive was created.

What this looks like in practice

Three practical decisions carry most of the weight.

Choose a format that will still open. Preferring open, documented, text-based formats over proprietary binary ones is the single highest-value choice in long-term preservation. Parquet, CSV with a documented schema, JSON, XML, and PDF/A are readable by many tools and will remain so. A proprietary application export that only the retired application can interpret is not an archive.

Preserve the meaning alongside the data. Every archived extract should travel with a data dictionary, the code lists in effect, the definitions of any derived fields, and a description of what the system did. This is the representation information requirement, and it is usually the thing skipped under schedule pressure because the team writing the archive still remembers what the fields mean.

Test retrieval on a schedule and keep the evidence. An annual or biennial restore test on a sample of archived records, with a written result, converts an assumption into a controlled process. It also finds media and format problems while they are still fixable. The test record itself becomes part of the evidence that the archive was maintained.

Vendor and SaaS Decommissioning: Write the Exit Before Go-Live

Almost everything difficult about retiring an AI system that was delivered as a service was decided at contract signature, years before anyone thought about retirement. This is the section to read before your next vendor selection rather than before your next decommissioning.

What the standard contract gives you, and what it does not

A typical AI or analytics service agreement gives the customer a right to export their data on termination, usually within a defined window and in the provider’s standard format. That right is real and worth having. It is also narrower than most buyers realize.

“Your data” in a standard agreement generally means the data you supplied. It frequently does not include the model outputs as a separate retained record class, the configuration history, the application audit trail in a form usable outside the application, the model version history, or anything about the model itself. The provider considers the model to be their product rather than your data, and on the plain terms of most agreements they are correct.

The clauses that change the outcome

Six provisions do most of the work. All of them are far easier to obtain during a competitive selection than during a termination.

On the European side, the regulatory environment has moved in the customer’s favor. The EU Data Act introduced obligations on providers of data processing services around switching, including contractual terms that support a customer moving to another provider or to their own infrastructure.¹⁵ It is a general framework rather than a GxP one, and it does not deliver model weights. But it strengthens the negotiating position on export, transition assistance, and the removal of barriers to leaving, and it is worth citing in a contract discussion.

Handling the vendor who cannot deliver

Sometimes the answer from the vendor is genuinely no. The model is a shared multi-tenant asset, weights cannot be extracted for one customer, and no amount of negotiation changes that. This is a legitimate technical constraint and pretending otherwise wastes everyone’s time.

The response is not to abandon the requirement but to move it. If Level 3 cannot be obtained, then the use case must be designed so Level 3 is not needed: strengthen the inference record so that Levels 1 and 2 are complete and durable, ensure genuine human evaluation is documented for decisions that matter, and record in the risk assessment that re-execution is not available and why that is acceptable for this use. That is a defensible position, documented in advance. Discovering the same constraint during a decommissioning project, after the decisions have already been made, is not.

Privacy Deletion Duties Against GxP Retention

Decommissioning is often the moment the privacy team and the quality team discover they have been operating on incompatible assumptions. Quality assumes everything is retained until the retention period expires. Privacy assumes personal data is deleted when the purpose that justified holding it ends. Retiring the system forces the conflict into the open, because someone has to decide what happens to the data.

The conflict is more apparent than real, but only if it is worked through explicitly. The GDPR sets storage limitation as a principle in Article 5(1)(e) and gives data subjects a right to erasure in Article 17. That right is not absolute. Article 17(3)(b) provides that it does not apply to the extent processing is necessary for compliance with a legal obligation which requires processing under Union or Member State law to which the controller is subject.¹¹

The European Data Protection Board applied that reasoning directly to clinical research. In its opinion on the interplay between the Clinical Trials Regulation and the GDPR, the EDPB considered that obligations concerning the archiving of the clinical trial master file, twenty-five years under Article 58 of the Clinical Trials Regulation, and the medical files of subjects, fall within the legal obligation ground, and that retention of clinical trial data in accordance with those archiving obligations is necessary to comply with legal obligations to which the sponsor and investigator are subject.¹⁰ The same opinion treats disclosure of clinical trial data to national competent authorities during an inspection the same way.¹⁰

So an erasure request does not override a GMP or clinical archiving requirement. What it does do is set a boundary. The exemption covers what the legal obligation requires, and no more.

Where the boundary actually falls

The practical work at decommissioning is separating the data the retention obligation requires from the data the system happened to accumulate. AI systems accumulate a great deal of the second kind: training and evaluation copies, feature stores, embeddings and vector indexes derived from source records, caches, intermediate pipeline outputs, prompt and response logs, telemetry, and the copies that sat in the vendor’s environment for support purposes.

Very little of that is required by any predicate rule. Much of it contains personal data. Decommissioning is the natural and correct moment to dispose of it, and doing so deliberately is better practice than allowing it to persist in a decommissioned environment nobody monitors.

Write this table for your own system, get privacy and quality to sign the same version of it, and attach it to the decommissioning plan. A retention decision that both functions have signed is worth far more at inspection than two functions each holding a defensible position that contradicts the other.

The Decommissioning Plan and Report as Controlled Documents

System retirement is a recognized lifecycle phase, not an administrative loose end. GAMP 5 Second Edition treats retirement as part of the specification and verification lifecycle, addresses system replacement and retirement in its operation guidance, and dedicates Appendix M10 to system retirement.⁷ Treating retirement as a phase means it gets the same document pair as any other phase: a plan approved before the work starts and a report approved after it finishes, both under change control, both signed by quality.

What the plan has to contain

A decommissioning plan for an AI system is a conventional retirement plan plus five sections that a conventional plan does not need. Those five are where the effort goes.

A working checklist

The following is written to be adapted rather than adopted. It assumes a system with at least one GxP use case, a vendor relationship, and personal data somewhere in scope.

Two items on that list are more often missed than the rest. The first is the open items register: an investigation that is still open when the system retires needs its evidence preserved in a form the investigation team can use, and that is a different requirement from long-term archiving. The second is the named ongoing archive owner. Projects end and their teams disperse. An archive with no owner degrades on a predictable schedule.

Migrating to a Successor System Without Breaking Traceability

Most decommissioning happens because something is replacing the system. That makes the retirement easier in one way, because there is a live destination for the data, and harder in another, because the temptation is to treat migration as a substitute for archiving. It is not. Migration moves data forward for operational use. Archiving preserves the record of what happened. They serve different purposes and often need different content.

The traceability break

The break happens at the seam. A decision made in the old system, referenced by an investigation opened in the new one, has to remain followable across the boundary. It usually does not, for three reasons that are all avoidable.

Identifiers change. The new system assigns its own keys. Unless the old identifier is carried forward as a retained attribute, every reference in every historical document points at nothing. Carrying the legacy identifier is trivial to do during migration and effectively impossible to retrofit later.

Context is dropped. Migration typically moves current state, not history. The old system may have held configuration history, superseded values, and the sequence of changes that explain how a record reached its final state. If that history is not migrated, it must be archived, and the archive has to be findable from the new system.

Meaning shifts. The same field name means something slightly different in the new system. A status code is retired and mapped to the nearest equivalent. A threshold is expressed in different units. These transformations are individually reasonable and collectively make historical data misleading unless the mapping is documented and retained with the archive.

Model lineage across the replacement

When the successor system includes its own model, there is a further question that conventional migration planning does not raise: what is the relationship between the old model and the new one, and does the change need to be handled as a change rather than as a replacement?

If the new system’s model is genuinely a different model, trained differently, on different data, for a redefined purpose, then it is a new system and needs its own qualification. If it is presented as a continuation, a retrained or upgraded version of the same capability, the change control and comparability questions are the same ones that govern retraining a model in place. Those questions are worth answering with the same rigor whether the model changes inside a system or the system changes around the model.

Either way, the lineage record should be explicit in the decommissioning report: which model the retired system used, over which period, what replaced it, from which date, and where the evidence for each period is archived. That single paragraph saves a future investigator a week of work.

Retire the procedures too

The last step is the one that reveals whether the retirement was really finished. SOPs that reference the retired system, training curricula that teach it, work instructions that describe screens that no longer exist, risk assessments that credit controls the system provided, and validation inventories that still list it as active all need updating. A quality system that still describes a system nobody can log into is a finding waiting to be written, and it is the kind of finding that suggests the retirement was not controlled even when the archiving was done well.

Conclusion

The reason AI decommissioning is harder than conventional system decommissioning is not that the regulations are unclear. 21 CFR 211.180, EU GMP Chapter 4, the GLP and clinical retention provisions, and the Part 11 requirements are all readable and all applicable. The difficulty is that the record for an AI-supported decision is assembled from components that live in different places, several of them outside your organization, and the regulations were written for a world in which the record was a single thing you held. Nothing in the rules stops you from meeting them. What stops organizations from meeting them is that the decisions determining whether the evidence will exist are made at contract signature and at system design, and the consequences appear at retirement, years later, in front of a different team.

The practical conclusion is that decommissioning planning belongs at the start of the lifecycle rather than at the end. Decide what reconstruction level each use case requires before you build it, write the exportable-evidence and escrow clauses into the contract before you sign it, design the inference record so that Levels 1 and 2 are satisfied without vendor dependency, produce the model documentation while the people who built the model are still available, and derive retention from the predicate rule rather than from a default. Do those five things and retirement becomes an ordinary controlled project. Skip them and retirement becomes an exercise in finding out what you lost.

Sakara Digital works with pharma and biotech organizations on the governance and validation of AI systems across their full lifecycle, including the part at the end that most programs have not planned for yet. If you are retiring a validated AI system, negotiating an exit with an AI vendor, or trying to work out what your current contracts would actually deliver at termination, we are happy to have that conversation.

For Further Reading