Planned Retirement (Commercial, Technical, Strategic) A system reaches planned retirement when it has completed its intended operational life. Commercial factors include product line discontinuation or replacement by a successor system. Technical factors include the underlying technology stack becoming unmaintainable or the model architecture being superseded. Strategic factors include the organisation exiting the market segment the system served. Planned retirement allows the longest lead time for a structured decommission. The AI Governance Lead should begin planning at least six months before the target date. The extended timeline permits deployer transition support, phased API deprecation, and thorough data lifecycle closure without the time pressure of compliance-driven or mandated withdrawals. The AI Governance Lead monitors for planned retirement triggers through the portfolio review process, where systems approaching the end of their useful life are identified and decommission planning is initiated. Key outputs
- Three planned retirement drivers (commercial, technical, strategic)
- Longest lead time for structured decommission
- Six-month minimum planning horizon
- Portfolio review as trigger identification mechanism
Voluntary Withdrawal (Non-Conformities, Risk, Drift, Fairness/Safety) The organisation determines that the system cannot achieve or maintain conformity with the AI Act. This may arise from an internal assessment finding irremediable non-conformities, a risk reassessment elevating residual risk above the acceptability threshold with no viable mitigation, a substantial modification assessment revealing the system has drifted beyond its documented intended purpose without a feasible path to realignment, or a PMM finding revealing systemic fairness or safety issues beyond remediation within acceptable cost or time constraints. Voluntary withdrawal is a compliance-preserving decision: the organisation recognises that continued operation presents greater regulatory risk than withdrawal. Under Article 20, the provider must immediately take corrective action to bring the system into conformity, or withdraw, disable, or recall it. Deployers, distributors, authorised representatives, and importers must be informed. The voluntary withdrawal timeline depends on the severity of the compliance gap. A critical safety issue may require immediate suspension (break-glass activation) followed by a structured withdrawal over weeks. A documentation gap may allow a more extended timeline. Key outputs
- Four voluntary withdrawal triggers (non-conformities, risk, drift, fairness/safety)
- Compliance-preserving decision framework
- Article 20 corrective action and notification obligations
- Timeline calibrated to compliance gap severity
Mandated Withdrawal/Recall (Art. 79, 15 Working Days) 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; Article 79(2) sets a backstop of 15 working days. Where the non-compliance is not restricted to one member state, the authority informs the Commission and other member states, potentially triggering parallel enforcement actions. Failure to comply with a withdrawal order is an aggravating factor in penalty determination under Article 99. The 15 working-day timeline means that the decommission workstreams must execute in parallel rather than sequentially. Pre-prepared end-of-life plans and templates are essential; an organisation that begins planning only after receiving the order will struggle to meet the deadline. Mandated withdrawal requires executive-level governance : the AI Governance Lead escalates immediately to the CEO/CTO with the Legal and Regulatory Advisor assessing enforcement consequences. Key outputs
- 15 working-day backstop under Article 79(2)
- Parallel workstream execution required
- Failure to comply as aggravating factor under Article 99
- Executive-level governance with immediate escalation