A door that opens back into the same supplier
Imagine a public office using an artificial-intelligence system to rank applications for a benefit. The contract allows the service to be terminated, and the dashboard has a switch that stops it. On paper, the institution retains two powers: it can turn the system off and end the contract. Yet its officials have adapted the process to the supplier’s categories; case files are stored in formats that this system handles better than any alternative; operational experience has accumulated around the platform, and the office has reduced the staff capable of doing the work manually. The day it decides to leave, the service it must protect for applicants may be interrupted as well.
The example is hypothetical. Its mechanism appears in a documented problem in public procurement of AI: vendor lock-in. The OECD warns that public authorities can become heavily dependent on contractors’ proprietary technologies and data formats. It also describes systems already embedded within public administration that may lack in-house capacity for maintenance or independent monitoring. What matters is whether the institution can stop the system without abandoning the public function it had delegated along with it.[1]
Three capacities that contractual language often compresses into one should be distinguished. Stopping means interrupting an operation. Leaving means ending the relationship with a supplier and recovering the means needed to avoid dependence on it. Continuing means maintaining the function—with another supplier, another system or a different procedure—during and after that departure. An authority may possess the first capacity while lacking the other two. It may have the legal right to terminate a contract and discover that doing so amounts, in practice, to ceasing the service.
The distinction matters because formal permission and effective capacity are not the same. In the analysis of authority within organisations, a person may hold the written power to decide yet lack control over the conditions that make the decision feasible. In AI procurement, a termination clause belongs to the first plane. Recoverable data, available documentation, knowledge retained by the public body and a workable transition path belong to the second.[4] Without those elements, freedom of contract risks resembling an emergency exit that opens into the same room.
How the cost of leaving is built
Dependence rarely appears fully formed on the day a contract is signed. It develops as the system becomes part of the organisation. Teams connect databases, move tasks into an interface, train officials in a particular workflow and adjust working criteria to the options the product offers. Each adaptation may be reasonable on its own. Together, they make departure require the recovery of information, the reconstruction of procedures, the transfer of knowledge and the handling of open cases. What began as a purchase becomes working infrastructure.
Dependence can be organisational as well as technical. An exportable file is of little use if no one retains the documentation that explains its fields. A manual cannot migrate a service if the teams who understand its integrations have left. Training officials does not solve the problem either if their expertise extends only to operating one platform, not to detecting relevant changes, reviewing outputs or activating a different procedure. The supplier may know details absent from the record; the institution may retain public obligations without retaining the capabilities needed to meet them.
That is why the cost of exit cannot be measured only by a termination fee, charges for downloading data or the hours needed to install different software. It also includes lost internal investment and the risk that the function will deteriorate during the transfer. If users of a public system cannot wait for a migration to finish, an authority may stay with a supplier even after finding faults that would justify a change. The threat of exit then ceases to discipline the relationship: the contractor knows, or can anticipate, that the written option is too costly to exercise.
A clause retains value when it changes the real options available to both parties. If the authority can transfer data, rebuild the process and sustain service during a transition, the supplier has reason to compete for the contract’s continuation. The institution need not actually change companies. The disciplinary value of an alternative lies in its being usable if the relationship ceases to serve the public interest. Once it becomes impracticable, it can still be invoked in negotiation, but it no longer works as a credible alternative.
Dependence varies with the task, architecture, data, contract length and the authority’s capability. Institutional design must identify the knowledge and public resources needed to keep a future decision to stop, replace or redesign the system practicable. Interoperability helps when it enables that transition; its reach depends on whether data, processes and services can be transferred usefully.
Changing suppliers is also a public capability
The OECD places vendor lock-in among the challenges of implementing AI through public procurement.[1] That dependence indicates when an authority must act: before awarding a contract, it can still compare formats, require documentation, discuss transition support and assess how much expertise it must retain. Once the service has entered everyday procedures, the cost of correcting an omission rises, and negotiations take place from a different position.
European law offers a bounded comparison. Chapter VI of the European Union’s Data Act sets requirements to facilitate switching between providers of data-processing services, including cloud and edge services. The European Commission explains that these requirements include exporting data in commonly used, machine-readable formats, open interfaces for certain services and measures to reduce barriers to switching. The regulation has applied since 12 September 2025; switching charges are due to be eliminated in full from 12 January 2027.[2][3] These rules cover data-processing services within their scope. They should not be presented as a general right to transfer any AI model, configuration, system or public-sector contract.
The comparison shows something more modest and more useful than a universal promise: the ability to switch providers can become a contractual and technical design obligation. It also shows what a portability rule does not decide automatically. Exporting data does not guarantee that a new system will preserve the required performance; an open interface does not transfer institutional knowledge; functional equivalence in a cloud service does not determine who will review the substantive decisions of an AI system. Exit must be designed around the function that needs to continue, not a box labelled ‘download available’.
For a public authority, this starts with an inventory of what is being delegated. It may be a recommendation that an official still checks, a classification that sets priorities or a step that triggers a decision affecting a person. The more a service depends on a platform, the more important it becomes to retain usable records, understandable descriptions of data and versions, documentation of integrations, and the ability to reconstruct the workflow. Not every contract requires the same solution. Design must respond to the function, the seriousness of interruption and the time the institution would need to replace the system.
A sound contract can specify export formats, access to records, migration assistance, notice of relevant changes, transition periods and continuity tests. It can also require the parties to rehearse an exit before a crisis forces them to improvise. The test should not stop at whether a file can be downloaded: it should establish that the authority can use it, knows what information is missing, has staff able to rebuild the process and can keep serving people during the transfer. Where the function cannot easily be interrupted, an alternative procedure may need to be backed by identified resources and responsible officials.
The public authority retains the capabilities it needs to meet the obligations that justified contracting the system. Adequate documentation, staff prepared to review and migrate, lawful access to relevant records and contractual transition terms may provide more control than a copy of code no one can run. The level of requirement should correspond to the service’s criticality and the cost of having no alternative; in some cases a tested transition will suffice, while others will require an alternative procedure with assigned resources.
Reversibility before a crisis
Dependence also changes over time. A system may receive a new version, new data, an added function or responsibility for more decisions than anticipated when it was contracted. Staff who understood the configuration may leave; a supplier may change an interface, a service condition or its pricing policy. The exit capability that seemed adequate at the beginning may no longer be so. An initial clause therefore cannot replace contract supervision: the authority must check whether the conditions that make exit executable still exist.
A periodic test can reveal a dependence that the contract does not: who holds the credentials, which system contains the usable version of case files, what procedure allows the service to continue if the tool stops, and how long a realistic transfer takes. This exercise does not predict the next failure. It shows what decision would be possible when the moment arrives and what investment must be made beforehand to avoid being too late. In an institution processing applications, a delay of several weeks may affect people; other tasks will produce different harms. A continuity plan should explain them through the public function at stake.
The question connects to a broader concern about delegated authority. Superior technical capability may make it reasonable to entrust a task to a system; it does not automatically make the organisation using it the master of the conditions for leaving it. Authority over a function includes retaining the practical ability to review the arrangement, change it and answer for its consequences. If only the supplier can interpret the operation, restore the service or make transition feasible, the institution retains its public duty but has ceded some of the means needed to exercise it.
A tool may improve a function and reduce costs; an authority has reason to adopt it when the benefit serves its public purpose. In contracting for it, the authority must decide which capabilities it will retain to examine performance, replace the system and maintain the service. That provision allows it to benefit from automation while continuing to learn from its use. Continuity is then organised by the institution rather than left to the goodwill of the party supplying the tool.
The off switch remains useful. It prevents an operation from continuing when it must stop. But the power to stop does not complete the power to govern if, after pressing it, the institution has no idea how it will serve people who depended on that service tomorrow. The State shows that it retains authority when it can stop a system and also sustain the task, change suppliers or rebuild the procedure. An exit does not begin with a signed clause; it begins much earlier, when the institution decides which capabilities it will not delegate along with the work.