Introduction:
Most systems of governance are built around a simple moment: approval. A product is tested, a policy is signed, a system is released. Once that moment has passed, attention often moves to the next project. This approach works reasonably well when the object being approved remains stable. A bridge does not learn from the traffic crossing it. A statutory form does not change its own criteria when a new applicant arrives. Artificial intelligence is different.
An AI system may be technically unchanged while the world around it changes completely. The people it serves may change. The data it receives may change. The policy, market or clinical environment in which it operates may change. Staff may begin to rely on it in ways that were never anticipated at the point of deployment. A model that was appropriate for a narrow task can quietly become a component in a much broader decision-making process.
This creates a problem of time. The question is not only whether a system was safe, accurate and legitimate when it was introduced. It is whether it remains safe, accurate and legitimate as the conditions that gave rise to the original approval begin to move. The answer cannot be assumed from the system’s past performance.
The idea of an algorithmic sunset clause follows from this basic observation. It does not mean that every AI system should be switched off after a fixed period. It means that continued deployment should become a deliberate decision. A system should be reviewed, re-authorised, changed or retired in the light of current evidence rather than allowed to persist simply because it is already in use.
The Assumption of Permanence
Software has often been treated as a completed object. A development team builds it, tests it, releases it and fixes problems when they are identified. Machine learning systems complicate this model because their behaviour depends not only on code, but on data, operational processes, user decisions and the environment in which the system is used. Sculley and colleagues described this wider problem as technical debt: apparently small machine learning choices can produce long-term maintenance burdens through data dependencies, feedback loops and changes in the external world. 1
The system that operates in practice is therefore larger than the model. It includes the data pipeline, the interface, the thresholds, the escalation rules, the people who interpret the output and the organisation that acts upon it. It also includes all the informal workarounds that develop after deployment. A risk score may begin as a recommendation for trained staff, then become a shortcut for a busy team, then become an unchallenged proxy for judgment. The code has not changed, but the significance of the system has.
Change can also be gradual. A model trained on last year’s transactions may confront new patterns of fraud. A demand-forecasting system may meet a sudden supply disruption. A health tool may be introduced into a population whose data was underrepresented during development. In each case, the relationship between input and outcome can shift over time. Research on concept drift has long recognised that learning systems may need to detect and respond when the statistical patterns on which they depend no longer hold. 2
This is not an argument against deployment. It is an argument against treating deployment as the end of governance.
From Approval to Living Authorisation
A sunset clause turns a one-off approval into a living authorisation. It gives an AI system permission to operate for a defined purpose, under defined conditions, for a defined period. Before that authorisation can be renewed, the organisation must ask whether the original case for use still stands.
The European Union’s AI Act does not impose a universal expiry date for algorithms. It does, however, place post-market monitoring at the centre of the obligations for high-risk systems. Providers must collect and review experience gained from use and identify whether corrective or preventive action is needed. 3 That is an important shift in emphasis: a system’s life after deployment is part of the governance problem, not an afterthought.
The same direction appears in voluntary standards. The NIST AI Risk Management Framework treats governance as a cross-cutting activity alongside mapping, measuring and managing risks. 4 ISO/IEC 42001 similarly frames AI management as something organisations establish, maintain and continually improve, rather than a document completed at the start of a project. 5 These frameworks do not prescribe a single review cycle, and they should not. A system used to prioritise maintenance requests does not carry the same consequences as one that informs access to work, credit, benefits, healthcare or essential services.
The principle is proportionality. The more consequential, autonomous, difficult to reverse or widely deployed a system becomes, the stronger the case for formal re-authorisation. In low-impact settings, this may be an annual documentation and performance review. In high-impact settings, it may involve continuous monitoring, independent assessment, a formal decision-maker and a clear route for pausing the system when the evidence changes.
What Should Trigger a Review
A calendar date is useful, but it is not enough. If review only happens once every twelve months, a material problem may be allowed to persist for eleven. A stronger clause combines a scheduled renewal date with events that trigger review sooner.
The first trigger is a meaningful change in data. A new source, a fall in data quality, a different population, or a new method of collection can alter the basis on which a model was evaluated. Data documentation is therefore not an administrative exercise. The datasheet approach proposed by Gebru and colleagues asks organisations to record a dataset’s motivation, composition, collection process, recommended uses and limitations. 6 When those facts change, an organisation has a concrete reason to revisit the system that depends upon them.
The second trigger is a change in purpose or setting. A model that is suitable for identifying patterns for a specialist may not be suitable for making an automated recommendation to a generalist. A tool introduced in one region may not transfer safely to another. A pilot can become a production system long before anyone formally acknowledges that the risk profile has changed. The intended use matters because performance is always measured against a context. Model cards were proposed precisely to make intended uses, evaluation methods, limitations and group-specific performance visible to the people deploying a model. 7
The third trigger is a change in rules or expectations. New legislation, guidance, contractual duties or sector standards can change what responsible deployment requires. The Information Commissioner’s Office emphasises that the data-protection implications of AI depend on the use case, population, overlapping regulatory requirements and wider social and political context. 8 A governance process that cannot notice these changes is likely to be compliant only by accident.
The fourth trigger is evidence of harm or unexpected behaviour. Complaints, appeals, near misses, unexplained performance shifts, security incidents and divergent outcomes between groups should not be treated as isolated operational noise. They are signals that the original assumptions may need to be tested again. This does not mean that every error requires retirement. It means that every serious signal should have a defined route to investigation and, where necessary, a decision about continued use.
Designing an Algorithmic Sunset Clause
The most useful clauses are not long. They are specific. They make clear what has been approved, who is responsible for it, what evidence must be reviewed and what happens if the evidence no longer supports continuation.
Define the object of approval. The authorisation should identify the model version, training and operational data sources, intended users, decision context, known limitations and prohibited uses. This prevents a common failure of governance: treating a materially changed system as though it were the same system that was originally assessed. A version update, a new third-party component or a change in workflow may be enough to require review.
Set a review horizon. The clause should state when renewal is required and why that interval is appropriate. A system operating in a rapidly changing context may need a shorter horizon than a stable analytical tool. The purpose is not to introduce a ritual. It is to establish an expectation that continued use must be justified by current evidence.
Name the decision-maker. Someone must have authority to renew, narrow, pause or retire the system. This cannot be left to a generic steering group or an unread policy document. The accountable person or body should have access to technical evidence, operational feedback and the perspective of people affected by the system. Without decision rights, monitoring becomes observation without consequence.
Specify the evidence. The review should not ask only whether headline accuracy is unchanged. It should consider safety, security, reliability, fairness, data quality, human oversight, user feedback, incidents, appeals and whether the system’s purpose remains legitimate. In a high-impact context, the organisation may also need to examine whether affected people can understand, challenge or seek redress for decisions made with the system’s assistance.
Create action pathways. A renewal decision should have more than two outcomes. Continued use may be authorised without change, authorised with conditions, narrowed to a smaller use case, paused while evidence is gathered, or ended. A good clause makes these options visible in advance. It reduces the pressure to choose between pretending that nothing has changed and abandoning a system that could be improved safely.
Preserve the record. Every renewal or retirement decision should leave an auditable record of what was reviewed, what changed, who decided and what follow-up action is required. This is where model documentation, dataset documentation and incident records become more than compliance artefacts. They become the institutional memory needed to explain why a system was allowed to continue.
Performance Is Not the Whole Question
A system can remain statistically accurate while becoming socially or operationally unsuitable. A demand model may produce useful forecasts while encouraging a team to neglect local knowledge. A fraud model may detect suspicious activity while generating a burden of false positives that shifts unfairly onto particular groups. A health tool may be technically robust but become difficult to use safely when clinicians are given less time to challenge its recommendations.
For this reason, re-authorisation needs to ask questions that a dashboard cannot answer alone. Who is using the system now? How does it shape decisions? Has the level of human scrutiny changed? Are people being asked to act on an output they cannot reasonably interpret? Has a model designed to support judgment started to replace it?
These questions matter especially in systems that affect rights, opportunities or safety. The World Health Organization’s guidance on AI for health argues that ethics and human rights must be placed at the centre of design, deployment and use, and that stakeholders should remain accountable to health workers, communities and individuals affected by these technologies. 9 The same principle extends beyond healthcare. Where an AI system influences a consequential decision, the continued suitability of the wider human process is as important as the continued performance of the model.
Learning from High Consequence Sectors
Some sectors already offer a practical example of how ongoing change can be governed without freezing innovation. In 2025, the US Food and Drug Administration issued final guidance on predetermined change control plans for AI-enabled medical device software. These plans identify proposed modifications, the protocol for implementing and controlling them, and the assessment of their effects. The guidance emphasises monitoring, evidence, risk management and the ability to detect, revert or stop a change that fails to meet defined criteria. 10
A medical-device framework cannot simply be copied into every field. But the underlying logic is widely relevant. The question is not whether a system is allowed to change. It is whether changes are bounded, understood, tested and governed before they alter a consequential decision.
This is also where sunset clauses can support innovation. Teams are more likely to improve a system responsibly when they know what evidence will be needed to renew it. Instead of treating governance as a late-stage obstacle, they can design monitoring, documentation, rollback mechanisms and user feedback into the system from the start. The review date then becomes a moment to learn from real-world use, not merely to defend an earlier decision.
Retirement Is Part of Responsible Design
Retiring an AI system is not the same as deleting a model file. A system may be connected to data feeds, user interfaces, operational policies, downstream databases and decisions that continue to have effects after the tool itself is switched off. If it is removed without a transition plan, staff may lose a useful control, recreate an ungoverned workaround or continue to rely on stale outputs.
A responsible retirement plan should therefore include a rollback or replacement pathway, a record of final performance and incidents, clear communication to users, treatment of stored outputs and a decision about how long relevant documentation must be retained. It should also identify any decisions that need to be revisited because they were materially shaped by the system.
The OECD AI Principles are explicit that AI systems should be robust, secure and safe throughout their life cycle, and should be overridden, repaired or decommissioned safely when they risk causing harm or exhibit undesired behaviour. 11 The principle is not that every system must end. It is that ending should be possible, planned and accountable.
The Limits of the Sunset Clause
A sunset clause is not a substitute for continuous monitoring, good technical practice, meaningful human oversight or legal compliance. A system should not be allowed to operate unsafely simply because its review date has not arrived. Nor should a clause create a performative annual exercise in which the same evidence is copied into a new form and approval is assumed.
There is also a risk in making renewal too rigid. Organisations could become reluctant to deploy beneficial systems because every change appears to require a costly reassessment. The answer is not to abandon review. It is to make it proportional, evidence-led and designed around the actual impact of the system. The review process for an internal writing assistant should not resemble the process for a tool that helps determine who receives medical treatment, a loan or public support.
The strongest approach combines routine review with event-based triggers and gives organisations a range of actions between full continuation and total shutdown. In this sense, expiration is not a blunt instrument. It is a discipline of attention.
Concluding Observations
Artificial intelligence is often discussed as though its most important moment is the moment of creation: the model is trained, the product is launched, the decision is made to deploy. In reality, the most consequential questions frequently emerge later. They emerge when the data changes, when users adapt their behaviour, when a system moves into a new setting or when a small operational shortcut becomes a new source of authority.
The central question is therefore not how long an algorithm should live. It is what evidence should allow it to continue. A sunset clause gives organisations a practical way to ask that question before a failure forces the issue. It turns continued deployment into something that must be earned through current evidence, accountable judgment and a genuine ability to change course. The future of responsible AI will depend not only on how systems are built, but on how carefully they are watched, renewed and, when necessary, allowed to end.
Footnotes
1. D. Sculley et al, Hidden Technical Debt in Machine Learning Systems (NeurIPS 2015).
2. J. Gama et al, A Survey on Concept Drift Adaptation (2014) ACM Computing Surveys 46(4).
3. European Union, Regulation EU 2024 1689 on artificial intelligence, including post market monitoring obligations for high risk AI systems.
4. National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework AI RMF 1.0 (2023).
5. International Organization for Standardization, ISO IEC 42001 2023 Artificial intelligence management systems.
6. T. Gebru et al, Datasheets for Datasets (2021) Communications of the ACM 64(12).
7. M. Mitchell et al, Model Cards for Model Reporting (2019) FAT Conference.
8. Information Commissioner’s Office, Guidance on AI and data protection.
9. World Health Organization, Ethics and governance of artificial intelligence for health (2021).
10. US Food and Drug Administration, Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence Enabled Device Software Functions (2025).
11. Organisation for Economic Co operation and Development, Recommendation of the Council on Artificial Intelligence, revised 2024.
