AI System End-of-Life and Decommissioning

The EU AI Act addresses system end-of-life through several provisions, each creating specific obligations that persist beyond the system's operational lifetime. Article 3(16) defines recall as any measure aiming to achieve the return to the provider, taking out of service, or disabling the use of an AI system made available to deployers. Article 3(17) defines withdrawal as any measure aiming to prevent an AI system in the supply chain from being made available on the market. These are distinct actions: withdrawal prevents new deployments, while recall retrieves or disables systems already in deployers' hands.

Article 16 requires providers to maintain compliance throughout the system's time on the market. When compliance can no longer be maintained, Article 20 requires the provider to immediately take corrective action to bring the system into conformity, withdraw it, disable it, or recall it. Distributors, deployers, authorised representatives, and importers must be informed. Where the system presents a risk within the meaning of Article 79(1), the provider must investigate the causes, collaborate with the reporting deployer, and inform the competent market surveillance authority and any notified body that issued a certificate.

Article 18 imposes a ten-year documentation retention obligation running from the date the system was placed on the market. This obligation persists after withdrawal or recall. The aisdp, evidence pack, conformity assessment records, and Declaration of Conformity must all remain retrievable. Article 79 empowers a competent authority to order withdrawal or recall of a non-conforming system, with the provider required to comply within 15 working days. Failure to comply is an aggravating factor in penalty determination under Article 99. PMM obligations under Article 72 do not cease at decommissioning, and serious incidents discovered after withdrawal must still be reported under Article 73.

ISO/IEC 42001 Annex A Control A.6.2.6 requires that the AI management system address decommissioning as a defined lifecycle stage, defining and documenting processes for safely phasing out the AI system while addressing residual impacts. ISO/IEC 23894 Annex C reinforces this by mapping risk management activities to every lifecycle stage including retirement, requiring assessment and treatment of risks arising from the system's withdrawal from service.

A system reaches end-of-life through one of three pathways, and the AI Governance Lead should monitor for all three. Planned retirement occurs when the system has reached the end of its intended operational life, driven by commercial factors such as product line discontinuation or replacement by a successor, technical factors such as an unmaintainable technology stack, or strategic factors such as exit from the market segment. Planned retirement allows the longest lead time for structured decommission.

Voluntary withdrawal for compliance reasons occurs when the organisation determines the system cannot achieve or maintain conformity with the AI Act. This may arise from an internal conformity assessment finding irremediable non-conformities, or from a risk reassessment that elevates residual risk above the acceptability threshold with no viable mitigation. It may also follow a substantial modification assessment revealing that the system has drifted beyond its documented intended purpose and cannot be brought back into scope. A post-market monitoring finding that reveals a systemic fairness or safety issue beyond remediation within acceptable cost or time constraints can also trigger decommissioning.

Mandated withdrawal or recall occurs when a market surveillance authority orders the system's withdrawal under Article 79. This pathway allows the least time and imposes the most stringent obligations. The authority may prescribe a specific timeframe, and Article 79(2) sets a backstop of 15 working days. Where the non-compliance is not restricted to one member state, the authority will inform the Commission and other member states, which may trigger parallel enforcement actions. The compressed timeline means that the end-of-life planning, deployer notification, technical shutdown, and data lifecycle closure workstreams must execute in parallel rather than sequentially, placing extreme pressure on the organisation's operational capability and governance coordination.

The AI Governance Lead initiates end-of-life planning as soon as a trigger is identified. For planned retirements, this process should begin at least six months before the target decommission date. For voluntary compliance withdrawals, the timeline depends on the severity of the compliance gap. For mandated withdrawals, the planning must be compressed into the timeframe set by the authority.

The end-of-life plan is a document prepared by the AI Governance Lead, reviewed by the Legal and Regulatory Advisor, and approved by the appropriate governance authority. The plan covers seven workstreams: trigger identification, planning, deployer transition, technical shutdown, data lifecycle closure, documentation finalisation, and post-decommission obligations. A system decommissioned without a structured process risks leaving orphaned data, unnotified deployers, active credentials with no owner, and regulatory obligations that no one is tracking. The AISDP must document the end-of-life process as a process planned during the system's design phase and refined as the system matures, not a formality addressed when the moment arrives.

A stakeholder impact assessment precedes execution. Deployers need time to transition to alternative systems or manual processes. Affected persons whose decisions remain in effect need to know how those decisions will be reviewed or supported. Internal teams that depend on the system's outputs need replacement workflows.

The plan sets a target decommission date and works backward to define milestones. A planned retirement might follow a timeline of announcement to deployers at T-6 months, transition support beginning at T-5 months, new deployments blocked at T-3 months, inference endpoints deprecated at T-1 month, full shutdown at T-0, and post-decommission monitoring beginning immediately after shutdown. A mandated withdrawal compresses this into 15 working days or less, requiring several workstreams to execute in parallel.

Deployers are the stakeholders most directly affected by system end-of-life. Article 13 requires providers to supply deployers with sufficient information, and this obligation extends to the end-of-life context. The provider must notify all known deployers of the withdrawal decision, the reason for withdrawal at an appropriate level of detail, the timeline for decommission, and the recommended transition arrangements.

Transition arrangements vary by deployment model. For API-served systems, the provider should publish a deprecation notice on the API documentation, implement a sunset header on API responses indicating the shutdown date, maintain the API at full functionality through the deprecation period, and cut off access on the announced date. For embedded or on-premises systems, the provider should issue a software update that clearly communicates end-of-service status, provide data export capabilities for deployer continuity, and coordinate the disabling or uninstallation of the system.

For systems integrated into deployer workflows, the provider should offer migration guidance for alternative systems, provide parallel running periods where feasible, and support deployers in conducting their own impact assessments. The AI System Assessor documents all deployer notifications, including dates, recipients, content, and acknowledgements received, as end-of-life evidence in the aisdp.

The Technical SME coordinates the technical shutdown in collaboration with engineering and infrastructure teams, ensuring the process is controlled, logged, and reversible until the final cutoff. Production inference endpoints are taken offline in a controlled sequence, with staged shutdown for systems with multiple deployment targets to identify unexpected dependencies. API endpoints should return informative error responses using HTTP 410 Gone with a response body explaining the system's withdrawal, not silent failures.

Production model artefacts are moved from the production model registry stage to an archived stage. The artefacts are not deleted but retained in the archive tier for the ten-year retention period. Cryptographic signatures are verified one final time to confirm artefact integrity at archival. The Technical SME records the final model version, its hash, and the archival location in the decommissioning record.

All production credentials, API keys, service accounts, and access tokens associated with the system are revoked, including deployer-side credentials granting access to provider APIs. The Technical SME verifies revocation by attempting access with revoked credentials and confirming failure. Dedicated compute, storage, and networking resources are released, with the infrastructure decommission ensuring it does not affect archived model artefacts, PMM data, or AISDP documentation in separate long-term storage. Active monitoring dashboards, alerting rules, and data collection pipelines are shut down after exporting a final snapshot of all monitoring data.

For organisations with mature CI/CD practices, several automation mechanisms reduce risk and improve auditability. HashiCorp Vault's lease mechanism allows all system-specific credentials to be tied to a single parent lease; revoking the parent lease cascades revocation to all child credentials, with the event logged in Vault's audit trail providing evidence for the decommissioning record. Infrastructure teardown via Terraform, Pulumi, or CloudFormation can execute a destroy against the production workspace after verifying that all archival steps are complete, with the IaC state file archived alongside the AISDP as evidence of what infrastructure existed and when it was decommissioned.

Data lifecycle closure sits at the intersection of the AI Act's documentation retention requirements and the GDPR's storage limitation principle. Article 18 requires ten-year retention of technical documentation while GDPR Article 5(1)(e) requires personal data to be kept for no longer than necessary. These obligations must be reconciled for each data category.

Training data containing personal data is subject to the GDPR storage limitation principle. The organisation should delete or anonymise personal data at decommission unless a specific retention justification exists such as pending litigation or regulatory investigation. Records about the training data, including metadata, provenance records, quality metrics, and statistical summaries, are retained for the ten-year period. The training data itself need not be.

Inference logs containing personal data follow the retention period defined in the PMM data retention policy. At decommission, the AI Governance Lead reviews whether the retention period has elapsed and authorises deletion where it has. Logs generated close to the shutdown date transfer to archive storage and are deleted at their scheduled time. Aggregated monitoring data without personal data is retained for the full ten-year period. Monitoring data containing personal data is either anonymised or deleted in accordance with the retention policy.

Data subjects retain their GDPR rights after decommission. A data subject submitting an access request under GDPR Article 15 must receive a response even if the system no longer exists. The organisation must maintain the capability to respond to such requests for as long as it retains personal data related to the system. The DPO Liaison defines the post-decommission process for handling data subject requests and communicates it to the relevant team.

When an AI system is decommissioned, the decisions it made during its operational lifetime may still be in effect and continuing to affect individuals. A credit scoring system withdrawn three years ago may have produced assessments that still influence access to financial services. A recruitment screening system may have contributed to hiring decisions whose effects persist in career trajectories. A medical diagnostic aid may have influenced treatment plans still being followed.

The AI Governance Lead assesses, at the point of decommissioning, whether the system's historical outputs continue to affect individuals. Where they do, a post-decommission monitoring plan specifies the data sources available for tracking downstream effects, the metrics to be monitored, the duration of monitoring which may be shorter than the ten-year retention period depending on how long outputs remain consequential, the responsible person, and the escalation pathway if adverse outcomes are detected.

This monitoring need not replicate the full PMM programme. It should focus on the specific risk dimensions, particularly fairness and accuracy of consequential decisions, that remain relevant after the system is no longer operational. The monitoring outputs are added to the archived evidence pack.

The duration of downstream decision monitoring depends on how long the system's outputs remain consequential. Credit assessments may affect individuals for years. Recruitment decisions have career-long effects. Medical diagnostic outputs may influence treatment plans that remain in place indefinitely. The AI Governance Lead determines the monitoring duration based on the domain-specific consequences, and the plan documents the rationale for the chosen period. Where adverse outcomes are detected during the monitoring period, the escalation pathway may trigger corrective action even though the system itself is no longer operational, including notification to affected persons and, where required, reporting to the competent authority.

The AI System Assessor prepares the final AISDP version, which includes all content from the operational AISDP plus a comprehensive decommissioning record. The record captures seven categories of evidence.

The end-of-life trigger and rationale documents the reason for decommission, the date the trigger was identified, and the governance approval. The end-of-life plan and execution log records each milestone's completion date, deviations from the plan, and how those deviations were resolved. Deployer notification records include copies of all notifications with dates, content, delivery confirmation, and deployer responses. The technical shutdown record covers endpoint deactivation dates, credential revocation confirmations, infrastructure release records, and the final model artefact integrity verification. The data deletion and retention record schedules which data categories were deleted, which were retained, the justification for each decision, and the DPO Liaison's signed attestation. A post-decommission obligations register lists ten-year retention expiry dates, monitoring commitments, and pending data subject rights. The registration status update confirms the EU database has been updated to reflect the system is no longer on the market.

The archive must be immutable to prevent retrospective modification, accessible to service competent authority requests within a reasonable timeframe, and cost-efficient so active monitoring infrastructure can be decommissioned while data survives. Cloud-based cold storage tiers such as AWS Glacier, Azure Archive, and GCS Archive provide cost-effective long-term retention. The archive includes a manifest document describing the system, AISDP version history, evidence pack contents, and retrieval procedures, ensuring future employees or authorities can navigate the archive without relying on institutional knowledge.