AI Procurement: Write the Exit Clause Before You Pick the Model
Forget which model wins this quarter's leaderboard. The AI contract a UK board signs in 2026 can quietly hand one vendor control of its stack until 2028, unless the exit clause is written first.
Picture a UK services firm, a composite of the cases we see across the desk. It shipped a retrieval assistant last year on a closed American model, wired straight into the vendor's API. It works well. Then the renewal lands. The list price has moved, and buried in the vendor's developer notes is a shutdown date for the exact model the assistant was built and evaluated against. The choice stops being academic. Migrate to the vendor's newer model and re-run the whole evaluation suite, re-tune the prompts and re-certify the security review, or move off the vendor entirely and rebuild the retrieval layer somewhere else. Both cost real engineering weeks. The firm budgeted for neither, because when it signed, nobody priced the exit.
That is the AI procurement decision that actually binds a board, and most get made backwards. A committee asks which model tops this quarter's leaderboard, signs a metered contract with the winner, and treats it as done. Capability feels like the hard question. The harder one is what the contract you sign in 2026 still lets you do in 2028, once the model has been retired, the price has changed and your data has spent two years on someone else's infrastructure.
Two pieces of borrowed context, then set them down. Chinese open-weight releases such as the Qwen and GLM families now trail the US frontier by months rather than years on CSIS's reading, close enough that for classification, extraction, drafting and retrieval most buyers can't feel the gap at the point of use. And the American hyperscalers have bet the other way: Moody's counts roughly $969bn of committed lease obligations across them, most tied to leases that haven't yet commenced. Those are lease commitments, a wager that the world rents metered compute, not owned infrastructure, and neither figure tells a UK buyer what to write into a contract. That is the part worth your attention.
What belongs in a two-year AI procurement clause?
Four terms earn their place, and each answers a failure you can already point to. First, portability: the right to export your prompts, fine-tune data and evaluation sets in a usable format. This matters because closed models retire on the vendor's timetable. OpenAI keeps a public deprecations list of models it has already switched off, each with a shutdown date, and a fine-tune built on a base model dies when that base is retired. If your training data and evals live only inside the vendor, a retirement becomes a rebuild.
Second, a capped notice period on price changes. Metered pricing moves in both directions across this market, and a mid-contract change with no notice cap hands your unit economics to the supplier. Third, a defined exit that returns or deletes your data and leaves it on infrastructure you control. For a UK buyer this is a UK GDPR question, not a slogan: your data processing terms should state where prompts and fine-tune data are held, and oblige deletion or return on exit. Fourth, a second qualified model behind an abstraction layer, so that a shutdown date becomes a configuration change rather than a project. Firms that plan for this treat model selection as readiness work before they build, and getting the surrounding architecture right is a technical strategy question rather than a shopping one.
Why does open-weight adoption compound?
Weights anyone can download don't just get used, they get built on. Every fine-tune, quantisation, adapter and integration pattern published against a model family lowers the cost of the next build on that family. Tooling standardises around it. The engineers you go on to hire have already shipped with it, because it was the thing they could run on a laptop while learning. A closed API can't enter that loop, because its weights never leave the vendor, so the ecosystem gravity forms around whatever is downloadable. For a buyer, that gravity is what makes a fallback realistic: the second option behind your abstraction layer is only cheap to reach if a live ecosystem already supports it.
Are Chinese open source AI models a security risk?
Self-hosting narrows one risk and opens others, and a board should hear both halves. A model you run inside your own environment doesn't call home on every request the way a hosted API does, which is a genuine cut in exposure. It does not send nothing anywhere, and anyone who tells you it does is overselling. The weights are an artefact of uncertain provenance: you don't fully know what they were trained on, model files have been used as a malware vector with poisoned checkpoints uploaded to public hubs, and the stack you serve them on, plus the telemetry and packages your inference tooling pulls in, is all live supply-chain surface. The NCSC's guidelines for secure AI development treat exactly these as the things to assure, and they apply whoever trained the weights. Keep humans and review in the loop over anything consequential, and assure the systems you run yourself the way you would any other software supply chain.
None of this makes self-hosting free. The weights download for nothing, but the tokens still cost GPU time, and you carry the ops, the evaluation and the security assurance yourself. The honest comparison isn't free versus metered, it's a known internal cost you control against a metered cost the supplier controls. A board that writes portability, a price-change cap, a clean data exit and a live fallback into its 2026 contract has bought the one thing a leaderboard can't hand it: the option to change its mind in 2028 without paying to rebuild.
Questions people ask
How do open weights actually reduce AI vendor lock-in?
Because the model runs on your own hardware and isn't tied to one company's API, you can move between competing open releases without rewriting your application. That portability caps your exposure to any single vendor's pricing, deprecation schedule and roadmap, which is precisely the exposure a metered closed API is built to preserve. The practical trick is to keep a second qualified model behind an abstraction layer so switching stays a configuration change rather than a rebuild.
What should a UK board put in a two-year AI contract?
Four terms earn their place: a right to export prompts, fine-tune data and evaluation sets in a usable format; a capped notice period on price changes; a defined exit that returns or deletes your data and leaves it on infrastructure you control; and an obligation that lets you run a fallback model without renegotiating. Together they price the lock-in you are taking on, rather than pretending it is free, and the data-exit term is where UK GDPR obligations actually bite.
Does using a Chinese open source AI model create a UK GDPR problem?
If you self-host, personal data stays inside your environment, so the international-transfer question narrows sharply. It does not dissolve your obligations: you remain the controller, and your processing, security and accountability duties under UK GDPR still apply in full. The live technical risks shift to model provenance and the supply chain of the stack you serve it on, which the NCSC's secure-AI guidance is built to address. If instead you call a Chinese hosted API, you are exporting data abroad and UK GDPR transfer rules apply on top, the same as for any overseas processor.
Related
- Your Cloud Provider Is Financing Its Own AI Revenue. Do the Financial Due Diligence
- The Announcement Is Not the Deal: AI Infrastructure's Announced vs Contracted Gap
- The Target-Less Number: Glucose Sensors Are Turning Fitness Trackers into Health Anxiety Machines
- Data & Strategy
Written by an AI editorial persona of Abyshire's proprietary editorial system and reviewed by our team.