This is a ready-to-use decommissioning checklist for one AI or machine learning system leaving a GxP process. Retirement is the most neglected stage of the AI lifecycle: a model that stops being used but is never formally decommissioned can keep a live endpoint, an unmanaged training-data set, or an access grant nobody remembered to remove. Run this checklist once per system being retired, not once for the whole AI portfolio. Replace every <<FILL: ...>> placeholder, record a result of Pass, Fail, or N/A against each item, and route the completed checklist through change control. A worked filled specimen follows the template.
Document control header
| Field | Entry |
|---|---|
| Document title | AI System Decommissioning Checklist |
| Document number | <<FILL: CHK-ID, e.g. CHK-AI-DEC-009>> |
| System / model being retired, and version | <<FILL>> |
| AI register ID | <<FILL>> |
| Change control reference | <<FILL: CR-ID governing this retirement>> |
| Completed by | <<FILL: name / role>> |
| Date | <<FILL>> |
1. Decision and rationale
| Item | Result | Evidence / notes |
|---|---|---|
| The decommissioning decision and its rationale (replaced, no longer needed, performance no longer acceptable, vendor relationship ending) are recorded | Pass / Fail | <<FILL>> |
| The decision was approved by the system’s business owner and, for a medium- or high-tier system, the AI Governance Board | Pass / Fail / N/A | <<FILL>> |
| The decommissioning is executed as a change under change control, not as an informal switch-off | Pass / Fail | <<FILL>> |
2. Replacement and transition
| Item | Result | Evidence / notes |
|---|---|---|
| If a replacement system takes over the decision this model made, the replacement is identified and its own register entry exists | Pass / Fail / N/A | <<FILL>> |
| If no replacement exists, the process the model supported has a defined fallback (a manual process, an existing non-AI control) so retiring the model does not leave a gap | Pass / Fail / N/A | <<FILL>> |
| Downstream human-review workflows that depended on this model’s output are reassigned or stood down explicitly, not left pointing at a decommissioned system | Pass / Fail | <<FILL>> |
| Data migrating to a replacement system followed a controlled migration process | Pass / Fail / N/A | <<FILL>> |
3. Model version and training data retention
| Item | Result | Evidence / notes |
|---|---|---|
| The final production model version, and prior versions used in the retention period, are archived per the records retention schedule | Pass / Fail | <<FILL>> |
| The training and tuning datasets (or their reproducible reference, including version hash) used for the retired model are retained | Pass / Fail | <<FILL>> |
| The model’s validation file, monitoring history, and predetermined change control plan are retained alongside the model version | Pass / Fail | <<FILL>> |
| The retention period applied matches the records retention schedule for the GxP records this model produced, not a shorter IT-asset default | Pass / Fail | <<FILL>> |
| A named individual or role can retrieve and reconstruct a past decision this model made, within the retention period, if an investigation requires it | Pass / Fail | <<FILL>> |
4. Endpoint, access, and infrastructure
| Item | Result | Evidence / notes |
|---|---|---|
| The model’s live inference endpoint(s) are disabled, confirmed by a direct check rather than assumed from a configuration change | Pass / Fail | <<FILL>> |
| User and system access to the model and its underlying data is removed | Pass / Fail | <<FILL>> |
| Any scheduled job, integration, or automation that called the model is disabled or repointed | Pass / Fail | <<FILL>> |
| A verification check (a test call, a log review, or an access-log check) confirms no residual output is being produced | Pass / Fail | <<FILL>> |
5. Vendor-hosted or API-delivered systems only
| Item | Result | Evidence / notes |
|---|---|---|
| The vendor’s contractual data-return or deletion terms are identified and followed | Pass / Fail / N/A | <<FILL>> |
| Written confirmation was obtained from the vendor that the company’s data was returned, exported, or deleted per those terms | Pass / Fail / N/A | <<FILL>> |
| Vendor-side user accounts, API keys, and integrations tied to this system are revoked, confirmed with the vendor or through the vendor’s own access console | Pass / Fail / N/A | <<FILL>> |
| The AI vendor and trained-instance boundary statement for this system is closed out or superseded, not left referencing an active relationship | Pass / Fail / N/A | <<FILL>> |
6. Register and closure
| Item | Result | Evidence / notes |
|---|---|---|
| The AI register entry’s lifecycle state is updated to retired, with the decommission date | Pass / Fail | <<FILL>> |
| The register entry links to this checklist and the governing change-control record | Pass / Fail | <<FILL>> |
| The change control record is closed with this checklist attached as evidence | Pass / Fail | <<FILL>> |
| The AI Governance Board (for medium- or high-tier systems) or the business owner (for low-tier systems) has been informed of completion | Pass / Fail / N/A | <<FILL>> |
Overall disposition
- All applicable items Pass. Decommissioning is complete; the system is confirmed out of service and the register reflects it.
- One or more items Fail. Decommissioning is not complete; state the open items and the plan to close them below.
| Field | Entry |
|---|---|
| Open items and closure plan (if any Fail) | <<FILL>> |
| Completed by (name, signature, date) | <<FILL>> |
| QA review (name, signature, date) | <<FILL>> |
Acceptance criteria
- Every applicable item carries a Pass, Fail, or N/A result with supporting evidence, not a blank checkbox.
- No item is marked Pass on the basis of intent (the endpoint “should be” disabled); each Pass reflects a verified fact.
- For a vendor-hosted system, section 5 is either fully addressed or explicitly marked not applicable with the reason stated; it is never silently skipped.
- The register and the governing change-control record both reflect the retired state before the checklist is filed as closed.
References
ICH Q9(R1), Quality Risk Management, for sizing verification effort (for example, how the endpoint shutdown is confirmed) to the system’s risk tier. 21 CFR Part 11 and EU GMP Annex 11, for the retention and continued readability of electronic records the retired system produced. GAMP 5, Second Edition (ISPE, 2022), for the computerized system retirement stage of the lifecycle this checklist closes out. FDA and EMA, “Guiding Principles of Good AI Practice in Drug Development” (published jointly 14 January 2026), for the life cycle management principle this checklist operationalizes at the point a system leaves the portfolio.
Confirm the current version of each reference before issue.
Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
Approvals
| Role | Name | Signature | Date |
|---|---|---|---|
| Author | <<FILL>> | ||
| Reviewer (QA) | <<FILL>> |
Filled specimen
The following shows a completed checklist for an example vendor-hosted anomaly-flagging feature being retired when the company switches laboratory platforms, so you can see the level of detail expected. The company and system are illustrative; replace them with your own.
| Field | Entry |
|---|---|
| System / model | LIMS vendor “suggested root cause” feature, hosted, v2.3 |
| AI register ID | AI-011 |
| Change control reference | CR-2026-0877 |
| Completed by | QC Laboratory Systems Manager |
| Date | 14 November 2026 |
Decision and rationale: Pass. The company is migrating to a new LIMS platform; the incumbent vendor’s investigation-support feature has no continuing use case. Approved by the business owner; board review not required, Advisory tier.
Replacement and transition: Pass. The new LIMS platform’s equivalent feature (AI-018) has its own register entry and independent validation; investigators were notified of the cutover date and trained on the new feature ahead of go-live.
Model version and training data retention: Pass. The vendor confirmed in writing (attached) that no site-specific model version exists to archive, the feature ran on the vendor’s shared base model with no site-specific retraining. The site’s own confirmatory test records (VAL-2026-0288) and the boundary statement are retained per the 25-year records retention schedule applying to the investigations the feature supported.
Endpoint, access, and infrastructure: Pass. The feature toggle was disabled in the vendor platform’s admin console 01 November 2026; verified by attempting to trigger a suggestion on a test record, none appeared, screenshot attached.
Vendor-hosted systems only: Pass. Data-return terms per the quality agreement (deletion within 30 days of contract end) were confirmed with the vendor by email 10 November 2026; vendor’s written deletion confirmation is due 30 days after the LIMS contract’s formal end date and is tracked as an open item below. API credentials for this feature were revoked 01 November 2026, confirmed via the vendor’s access console screenshot. The boundary statement (BND-AI-011) is marked superseded, referencing this checklist.
Register and closure: Pass. AI-011 updated to retired, decommission date 14 November 2026, linked to CR-2026-0877.
Overall disposition: All applicable items Pass except the vendor’s final written deletion confirmation, which is a tracked open item with a defined due date rather than an unclosed gap. Completed by the QC Laboratory Systems Manager, signed 14 November 2026; QA review 17 November 2026.
Open items: Vendor’s written data-deletion confirmation, due 30 days after LIMS contract end (approximately 15 December 2026), owner QC Laboratory Systems Manager.
Common inspection findings this checklist prevents
- A “retired” model still reachable through a forgotten endpoint or an integration nobody repointed.
- Training data or model versions deleted at retirement, breaking the ability to investigate a past decision the model made while live.
- A vendor-hosted feature turned off in the company’s own console with no confirmation the vendor’s side was ever addressed, leaving company data on a vendor’s systems with no tracked closure.
- The register left showing a system as live months after it actually stopped being used.
- A decommissioning treated as an informal IT task with no change-control record and no QA review.
How to adapt this checklist
- Set the document number, register ID, and change-control reference in the header before starting; decommissioning without a governing change record is not controlled retirement.
- Skip section 5 entirely, and mark it N/A with a one-line reason, for a system that was built and hosted entirely in-house.
- Point the retention period in section 3 to your actual records retention schedule for the specific GxP records the system produced, not a generic IT default.
- For a high-tier or process-control system, add a verification step confirming any deterministic interlock or fallback control that depended on the model’s presence is still functioning correctly after the model is gone.
- File the completed checklist with the change-control record and the AI register entry so both point to the same evidence.