UK SMEs and charities are racing to add AI to products and back‑office processes. The risk that sneaks in at the contract stage is lock‑in — not just to a cloud, but to a model, a proprietary prompt format, a vector store, or a vendor‑owned dataset. The UK Competition and Markets Authority’s provisional findings in January 2025 flagged how cloud egress fees and technical barriers make switching harder and costlier, especially for AI workloads that move a lot of data. Read the CMA’s summary. Ofcom raised the same trio of concerns earlier: egress fees, switching barriers, and discount structures. See the scope.
This guide shows non‑technical leaders how to buy AI capability that stays portable. It gives you the exact questions to ask, proofs to demand, a simple cost‑risk view, KPIs for portability, and a 30‑60‑90 day plan to de‑risk implementation.
What “portable AI” actually means (in plain English)
- Portable data: You can export training data, prompt libraries, outputs, feedback labels, and embeddings in reusable formats whenever you need.
- Portable interfaces: Your app calls a simple API contract you control, so swapping model or provider doesn’t break everything.
- Portable evaluation: You keep an offline test set and a repeatable process to compare vendors and models on your real tasks, not their marketing benchmarks.
- Portable observability: Your logs and traces are yours, in open formats, so you can monitor, cost‑control and debug across providers. OpenTelemetry is the current de‑facto standard for traces and metrics. See the spec.
- Portable operations: You can run “shadow” traffic, A/B tests, and failover without renegotiating contracts.
If you’re buying via public‑sector routes (many charities do), Crown Commercial Service provides AI buying routes (DPS/dynamic markets) that can reduce friction and improve comparability across suppliers. Explore CCS AI routes.
The 12 procurement requirements that prevent lock‑in
Insert these as requirements in your RFP and contract schedules. They’re proportionate for most OFFICIAL‑level data and align with UK government guidance for choosing and securing SaaS and AI systems.
- Data export on demand: The vendor must provide self‑service export of all your inputs, outputs, system and user prompts, evaluation datasets, and feedback labels in CSV/JSON/Parquet. Government guidance explicitly recommends choosing tools that let you retrieve or remove data safely. Source.
- Embeddings and vector portability: The vendor must allow bulk export of embeddings with their model identifier and dimensionality, plus the underlying text chunks and metadata.
- Transparent telemetry: Request logs of prompts, model IDs, temperatures, and token counts, with trace IDs. Prefer OpenTelemetry‑compatible exports so you can move your observability stack later. Spec.
- Model‑swap demo as a proof: In the pilot, the supplier must demonstrate swapping the primary model for an alternative and replaying the same evaluation set with minimal code changes.
- Shadow mode and dual‑run: Non‑disruptive A/B or shadow traffic must be possible to compare vendors before cut‑over.
- Bring‑your‑own‑identity (SSO) and role separation: Use your identity provider; keep admin, developer and auditor roles separate. See UK guidance on using cloud tools securely. GOV.UK.
- Key control: Encryption keys should be managed under your control where feasible (“customer‑managed keys”). This aligns with UK cloud security principles around protecting data in transit and at rest. Cloud Security Principles.
- Exit support and capped fees: Include a defined exit plan with time‑boxed vendor assistance and capped rates for data extraction and cut‑over.
- Egress cost transparency: Vendors must itemise all egress‑related fees and constraints that apply during normal use and at exit. This is a known switching barrier per CMA/Ofcom. CMA.
- Security baseline for AI: Ask suppliers to attest to the UK AI Cyber Security Code of Practice, or equivalent, and show how they mitigate AI‑specific risks (e.g., data poisoning, prompt injection). Code of Practice (DSIT).
- Supplier incident playbook and reporting times: Include clear incident notification SLAs and evidence that their supply‑chain risks are governed at board level. See NPSA supply chain guidance for leaders. NPSA.
- Data residency clarity: Confirm locations for storage, inference and backups, with the right to move to UK/EEA if risk changes. UK guidance recommends offshoring agreements and retrieval routes. GOV.UK.
How to test vendor claims in one week
Set up a simple, fair evaluation
- Pick 30–50 real cases from your own data with agreed “good” answers.
- Define 3–5 quality criteria staff can score consistently (e.g., accuracy, tone, citation presence, safety adherence).
- Measure cost per resolved case and latency as well as quality.
- Run each case through two vendors and one open‑model route.
- Log prompts, settings, model IDs and token counts for replay.
If you don’t have an internal security baseline, borrow from the Five‑Eyes joint guidance on deploying AI systems securely and the UK’s own code of practice; they’re practical and vendor‑neutral. CISA/Five Eyes and DSIT Code.
Decision helper: Buy off‑the‑shelf, buy a platform, or build?
Choose off‑the‑shelf SaaS if…
- Your need is common (FAQ search, email triage, meeting notes) and you can live with best‑practice workflow.
- You can export data on demand in open formats, and you verified a model‑swap demo during the pilot.
- The vendor provides SSO, audit logs, and clear egress costs at exit.
Choose a cloud AI platform if…
- You need to combine your data with multiple models and channels.
- Your team will own the API contract and observability, using open tracing standards.
- You’re ready to run shadow traffic and A/B across models/vendors.
Build bespoke if…
- You require unusual controls, heavy custom workflows, or on‑prem data controls that SaaS won’t meet.
- You can staff the support burden and still meet the UK AI security baseline and supply‑chain governance. NPSA for practitioners.
Public‑sector buyers or VCSEs selling into the public sector should also check CCS routes and events to understand upcoming frameworks and supplier expectations. CCS AI & SME events.
Costs and risks to quantify up front
| Risk or cost | What it looks like | How to mitigate when buying |
|---|---|---|
| Egress and switching fees | Bill shock when exporting data or moving workloads | Demand itemised egress schedules and free or capped exit support. CMA highlights egress as a switching barrier. Source |
| Proprietary prompt formats | Templates that won’t run elsewhere | Insist on plain‑text prompts and parameter docs; require a model‑swap demo using your prompts. |
| Unclear data residency | Backups or inference outside expected regions | Specify storage, inference and backup regions; require notice and right to move. Gov guidance |
| Weak auditability | No logs for who changed what, when | Require audit logs and export; prefer OpenTelemetry compatibility to avoid tool lock‑in. Otel spec |
| Security drift | Basic hygiene slips over time | Ask for alignment to the UK AI Cyber Security Code of Practice and periodic attestations. DSIT |
15 procurement questions to surface portability risk
- Show the export screen for prompts, outputs, feedback labels and embeddings. What formats are supported?
- Which model families can your product use today? How do you add new ones?
- Demonstrate swapping the default model for an alternative on my test set within the pilot.
- How do you version prompts and configurations? Can we export them?
- What observability do we get by default? Can we export raw traces and logs with IDs?
- Do you support SSO with conditional access and granular roles?
- Where are data stored, processed and backed up? How can we change this later?
- What is your exit plan? What’s the maximum we would pay for a full export?
- How do you cap spend (rate limits, budgets, alerts)? What happens if you exceed them?
- How do you protect against common AI risks (prompt injection, data poisoning) in line with UK guidance? Reference
- What’s your incident response playbook and notification SLA? Who owns root‑cause actions?
- Do you subcontract inference, storage or annotation to third parties? Where?
- How do you test and report quality across updates? Can we pin versions?
- If we pause, how do you retain or delete our data? How quickly?
- What will we be unable to do without paying to upgrade or extend licence scope?
If you need a deeper template, see our AI vendor due‑diligence pack and the 2025 AI copilot buyer’s guide.
Portability KPIs your board will understand
- Time‑to‑swap (TTS): Hours to switch the primary model/provider and re‑run your test set end‑to‑end.
- Replay coverage: Percentage of production use‑cases that can be replayed from logs into a new model.
- Abstraction coverage: Share of AI calls routed through your own API contract, not vendor‑specific SDKs.
- Dual‑run cost delta: Extra cost of running two vendors in parallel for a week during evaluation or incident response.
- Exit readiness score: Traffic‑light view across data export, logs export, embeddings export, and identity controls.
30‑60‑90 day plan to make your AI stack portable
Days 1–30: set the rules
- Nominate an executive owner for AI supply‑chain risk and put it on the risk register. NPSA advises top‑down governance. Source
- Adopt a one‑page “AI Portability Standard” covering exports, observability, model‑swap demos, SSO and key control.
- Prepare a 50‑case offline test set from real tasks and agree your scoring rubric with frontline staff.
Days 31–60: prove portability in pilot
- Run dual‑vendor pilots with shadow traffic; measure quality, latency and cost per resolved case.
- Capture traces and logs with unique IDs so you can replay elsewhere; prefer OpenTelemetry formats.
- Test incident processes and confirm notification SLAs and security contacts.
Days 61–90: lock in the right to switch
- Negotiate exit assistance with capped rates; fix egress line items in the order form.
- Pin data residency; put change‑control around any move.
- Schedule quarterly portability tests: re‑run the test set on an alternate model and review KPIs.
Moving to production? Use our one‑page Go‑Live Gate for AI to sanity‑check readiness and rollback.
Common pitfalls (and how to avoid them)
- Assuming SaaS = secure by default. Government guidance stresses you must still assess supplier security, manage identities, and plan for retrieval and deletion. GOV.UK
- Under‑specifying observability. Without portable logs/traces you can’t compare quality or costs across vendors.
- Accepting vague exit clauses. Define data formats, timelines and cost caps; require a named exit manager.
- Ignoring supplier’s own supply chain. Ask who runs inference, storage and annotation — and where. NPSA urges visibility of subcontractors. NPSA
- Leaving AI risk to IT only. The UK’s AI cyber guidance expects organisational controls, not just technical ones. DSIT Code
Mini checklist: before you sign
- We witnessed a model‑swap demo on our own test set.
- We verified export of prompts, outputs, feedback labels and embeddings.
- We have SSO, audit logs and OpenTelemetry‑compatible traces.
- Regions for storage, inference and backups are contractually pinned.
- Exit plan and egress costs are clear and capped.
- Supplier aligns to the UK AI Cyber Security Code of Practice and has a documented incident playbook.
For public bodies and charities partnering with them, Crown Commercial Service’s AI purchasing routes can simplify comparisons and add supplier discipline. CCS AI.