I would not sign an AI contract without a tested way to leave. Owning your data is not enough if you cannot rebuild the service elsewhere.
I would put these five protections in writing:
- Data export rights: Specify what you receive, file formats, deadlines and capped costs.
- Rights to custom AI work: Secure ownership or lasting reuse rights for code, prompts, workflows and configurations.
- API and admin access: Keep the access and documentation needed to run, check and move the service.
- Termination and change rights: Protect your exit if the supplier suspends service, changes terms or shuts down.
- Migration assistance: Agree named staff, support hours, handover tests and fees before signing.
My check before committing? Test a sample export in a separate environment. Set a target of 100% reconciliation of critical records and relationships, and confirm that key workflows run there.
A download is not a working exit. I would make acceptance depend on usable files, clear reuse rights and a tested handover - not delivery alone.
::: @figure 
{5 AI Contract Clauses That Limit Vendor Lock-In}
:::
The vendor lock-in question comes up in nearly every enterprise AI strategy conversation.
Specify Exit Deliverables, Deadlines and Costs
Attach an Exit Deliverables Schedule that lists raw and processed data, prompts, outputs, configurations, logs, documentation, and buyer-owned custom code or integrations. For each item, record its owner, export method, format, dependencies and acceptance test.
Require open, structured and machine-readable formats wherever practical. Include schemas, mappings, manifests and checksums so the buyer can check that nothing is missing. Identify upstream dependencies and components that cannot be exported, such as restricted model weights. Agree which assets the buyer will need to rebuild those functions.
Give every deliverable a deadline and an acceptance test. Set timings according to the risk to service delivery: initial export within five working days, verified export within 15 working days, and defect fixes within two working days. Critical services may also need frequent incremental exports, priority support and read-only access during the transition. Record maximum downtime, named escalation contacts and remedies for missed commitments.
Include routine exports, documentation and secure deletion in recurring fees. Permit extra engineering charges only with prior written approval, an agreed rate card and a fixed cap. State who pays third-party platform, data-egress, storage and encryption costs. Make acceptance depend on reconciled record counts, matching checksums, intact metadata and successful import into the replacement system.
Commercial exit rights must also account for UK data-protection rules. Keep contractual export rights separate from UK GDPR portability: the statutory right usually covers only personal data supplied by the individual, not all business records, derived data or system settings.[1][4] Processor contracts should require personal data to be returned or deleted, at the controller’s choice, when processing ends unless the law requires retention.[2][3]
Ask a UK legal adviser to check the schedule against IP, confidentiality, security, international transfer and DPA terms. Require encrypted transfers, authenticated access and least-privilege permissions.[6] Specify how backups and subcontractor copies will be handled, including evidence of deletion and documented exceptions where data must be retained.[2][3]
1. Data Export and Portability Rights
Protected assets and permitted uses
Define customer-controlled assets to cover source records, prompts, prompt templates, workflow and agent configurations, system instructions, embeddings and indexes where technically exportable, retention labels and integration mappings. State whether this includes archived, quarantined or deleted records where legally and technically available.
Subject to confidentiality, UK data-protection law and third-party rights, give the buyer rights to access, copy, retain, analyse, transfer and import exports for continuity, audit, regulatory response, testing and migration.
Put these rights in the export schedule. Then require the supplier to show how it will deliver them through specified file formats and testable delivery rules.
Delivery formats and acceptance tests
Use the schedule to translate these rights into named file types, validation checks and evidence that the service can be rebuilt. This helps limit switching costs and service loss.
| Asset | Documented format | Validation and supplier obligation |
|---|---|---|
| Source data, prompts and outputs | CSV, JSON or Parquet for records; plain text, Markdown or JSON for prompts | Reconcile record counts and confirm that a sample import succeeds |
| Metadata, permissions and timestamps | JSON or CSV with role definitions and UTC time-zone conventions | Preserve relationships, access history and retention labels |
| Workflows, agent configurations and integration mappings | JSON/YAML or equivalent, with tool definitions, routing logic and field mappings | Supply the materials needed to reconstruct workflows |
| Embeddings and indexes | Native export where supported; otherwise reconstruction materials and rebuild instructions | Include source records, chunking rules, model/version and dimensions |
| Logs, evaluation sets and audit records | JSON/CSV with event identifiers, labels, scores and model versions | Preserve event order and enough context to reproduce evaluations |
Test a sample export before go-live and annually thereafter. Check permission mappings and relationships, not just file integrity. For rebuilt indexes, compare identifiers and retrieval results: a readable file does not prove that the service can be rebuilt.
The supplier should also provide a manifest listing files, versions, record counts, checksums, exclusions and known limitations.
Deadlines and continuity commitments
Once the asset list is agreed, set out how long the supplier must keep access and export tools available during notice and exit. Require read-only access and export functions throughout the notice and transition periods, subject to security and legal limits.
Charges, responsibilities and remedies
Make the supplier responsible for packaging exports, providing secure transfer and documentation, and obtaining equivalent confirmations from subprocessors. This should leave the buyer with usable assets and proof of deletion. The buyer should provide authorised contacts, sample validation and the destination environment.
Require a signed deletion certificate identifying the systems searched, asset categories deleted, deletion dates, any retained categories and responsible personnel. Require equivalent confirmations from subprocessors.
Define any backup exception narrowly. Data held under that exception must remain inaccessible for ordinary processing and be deleted at the next scheduled destruction cycle.[3]
2. Ownership and Use Rights for Custom AI Work
Protected assets and permitted uses
A blanket ownership clause is not enough. To protect your use of the work after termination, create an ownership matrix showing each asset, its owner, permitted users, delivery format and post-termination rights. Keep supplier background IP separate from work created specifically for your business.[10]
| Asset category | Position to negotiate |
|---|---|
| Buyer materials: customer-supplied data and prompts | The buyer retains ownership. The supplier may use these materials only to perform the contract. Training, product improvement and reuse for other customers require written permission. |
| Supplier background IP: existing frameworks, libraries and tools | The supplier retains ownership. The buyer receives lasting rights to use, copy, modify, maintain, host and migrate any elements needed to operate the deliverables after termination. |
| Bespoke deliverables: custom code, configurations, prompts, agent instructions, workflows, documentation and reports | Assign rights in genuinely bespoke deliverables to the buyer. If assignment is not possible, grant a perpetual, irrevocable, worldwide, royalty-free, transferable and sublicensable licence. It must cover use, copying, modification, maintenance, hosting, testing, audit and migration. Specify ownership or equivalent lasting rights for deliverable fine-tuned weights. Clarify whether the supplier may retain general know-how or reusable methods. |
| Third-party components: models, datasets, software and hosted services | Record licences, versions, commercial-use limits, attribution requirements, source-disclosure obligations and restrictions on modification, weight delivery or migration after termination. Identify unacceptable dependencies before signing. |
Allow affiliates, contractors and replacement suppliers to use and maintain the work. Explicitly permit reuse and commercial use of outputs and derivatives without extra royalties unless agreed, subject to disclosed third-party restrictions. If ownership is uncertain, combine assignments and licences with confidentiality duties and limits on supplier reuse.[8]
Delivery formats and acceptance tests
Require editable source code, version-controlled repositories or exports, configuration files, dependency manifests, infrastructure-as-code, build files, deployment scripts and technical documentation. Include fine-tuned weights where relevant.
Acceptance should test whether the work can run without the supplier. Require the buyer or an independent replacement supplier to install, configure, run, inspect, modify and redeploy it in a specified environment. The test should include changing an agent instruction and reproducing an agreed evaluation result without supplier intervention. A hosted demo does not prove the work can run independently.
Deadlines and continuity commitments
Tie rights to the creation of, or payment for, each deliverable - not to contract expiry. Require the initial repository and build documentation at acceptance, updates with every release, and a complete continuity pack on exit or material supplier failure.
Preserve version history, and ensure licences and continuity duties survive termination. If immediate source delivery is unavailable, agree escrow release triggers for insolvency, material breach or discontinued support.
Charges, responsibilities and remedies
Prohibit extra charges simply for exercising existing rights. Make the supplier responsible for accurate licence records and permissions. Include warranties, indemnities for third-party IP claims, and rights to recover reasonable replacement and migration costs.
Treat withheld source code, reuse without permission or unusable documentation as material breaches. Set correction deadlines and allow payment withholding or termination after a defined cure period. Ask legal counsel to confirm these terms are enforceable.[7][9]
The next clause should address access to the systems that run the work, including interfaces, APIs and admin access.
3. Interface, API and Admin Access
Protected assets and permitted uses
Ownership rights alone do not give the buyer control of the live service. Export rights cannot prevent lock-in without live access. Access must let you operate, audit and migrate the service.
Define protected interfaces broadly so the supplier cannot retain practical control. Cover current interfaces and materially equivalent replacements introduced during the contract term. Allow authorised buyer staff, group companies, advisers and replacement suppliers to use them to run the service, monitor performance, investigate incidents, extract information, test integrations and move to another provider. Apply confidentiality and security controls to these uses. The NCSC identifies APIs, web consoles and command-line interfaces as external interfaces requiring protection.[15]
| Protected access | Contract requirement |
|---|---|
| Documented APIs and schemas | Current OpenAPI or equivalent specifications, endpoint descriptions, field definitions, pagination, permitted values and error codes; versioned schemas with stable identifiers. |
| Export tools | Self-service access to bulk and incremental exports. |
| Admin access and authentication | Buyer-controlled roles, permissions, configurations and audit settings; minimum necessary access, MFA for administrators, separate service accounts, key rotation and auditable access. |
| Rate limits and event delivery | Agreed throughput and concurrency; documented event schemas, signed payloads, retries and replay capability. |
| Test environments | A representative sandbox with test credentials and enough quota for integration and migration tests. |
| Logs and configurations | Access to audit, usage, model, prompt, workflow and configuration records; encryption and controls that keep secrets out of exports. |
Delivery formats and acceptance tests
Require machine-readable interface documentation and a data dictionary. Test interoperability, not just endpoint access. Use dummy and production-like data to authenticate, retrieve records and invoke permitted functions. Check identifiers, relationships, timestamps, permissions and audit trails. If tests fail, the supplier must correct the faults and pay for retesting.[5][12]
Deadlines and continuity commitments
Set contractual deadlines for credentials and access. Specify supported API versions, a minimum notice period for breaking changes, advance access and an overlap period.[11][13]
Example deadlines: administrator access within one business day and export access within five business days.
Ban material breaking changes without written approval. Allow exceptions for urgent security or legal fixes, with prompt notice and remediation.
Charges, responsibilities and remedies
Include APIs, documentation, logs and admin controls in the agreed fees. Disclose and cap permitted usage charges, and prohibit migration-only price increases or throttling.
Make the supplier responsible for credentials, schemas and defect fixes. Make the buyer responsible for authorised users and secure receiving systems. Set restoration deadlines, service credits and rights to recover reasonable migration and re-integration costs. Repeated access failures should trigger material-breach and transition-support rights.
The next clause should ensure these access rights survive notice, suspension and contract changes.
4. Termination, Suspension and Contract Changes
Protected assets and permitted uses
Use these backstop terms to protect exit rights if the supplier changes, suspends or ends the service.
Specify that customer data, export rights and migration access survive termination until handover is complete. Supplier-owned platform software and pre-existing models remain the supplier’s property.
Delivery formats and acceptance tests
Apply the agreed export schedule to the final handover. Require delivery before termination, allow at least 10 business days for buyer validation, and require the supplier to correct failed deliverables. Keep read-only access available until acceptance or an agreed long-stop date.
Deadlines and continuity commitments
Link each contract trigger to a required exit action. The periods below are proposed contract terms, not statutory deadlines.
| Trigger | Notice or cure period | Required protection |
|---|---|---|
| Convenience | 60–90 days’ written notice | Maintain service and start export. |
| Material breach | 10 business days for remediable security, confidentiality or data-protection breaches; 30 days for other remediable breaches | Preserve exit assets and evidence of cure. |
| Insolvency, administration or shutdown | Immediate or accelerated exit, where lawful | Activate continuity arrangements and urgent export. |
| Serious security incident | Prompt notification; immediate action for an incident that cannot be contained | Isolate affected functions; preserve evidence and safe export where feasible. |
| Regulatory change or unlawful processing | Advance notice where possible; immediate action where legally necessary | Support lawful migration without an exit penalty. |
| Material pricing, functionality, data-use or upstream-terms change | 30–90 days’ advance notice and a rejection right | Allow penalty-free exit; maintain existing terms during notice where lawful and safe. |
| Final cutover | Agreed migration and acceptance milestones | Complete migration before revoking credentials and issuing deletion evidence. |
Make repeated SLA failures a termination trigger. Limit emergency suspension to what is necessary, and require the supplier to explain its reasons, expected duration and restoration steps. Preserve safe read-only export where technically and legally feasible. Ban suspension for disputed invoices.
Define material changes using objective criteria. These should cover removal of core features, reduced service levels, new training uses of buyer data and restrictions on output use.
Charges, responsibilities and remedies
Assign a supplier exit manager and a buyer validation owner. Require the supplier to cover costs caused by its breach or defective exports.
Require deletion evidence after acceptance, subject to lawful retention exceptions. Backups awaiting deletion must remain inaccessible.[3] Keep transition-support duties in force until the agreed handover milestones are met.[16]
Use the checklist below to test each trigger, deadline and handover step.
5. Migration Assistance and Transition Support
Exit rights need more than a place in the contract. The supplier must help carry out the move.
Exit plan and handover scope
Attach a binding exit plan at award. Update it annually and after material service changes, setting out the migration sequence, dependencies and named contacts.
The aim goes beyond exporting files: the replacement provider must be able to run the service without supplier intervention.
Define the handover materials using the scope agreed in earlier clauses. Cover data, outputs, prompts, configurations, code, logs and documentation, including model cards, evaluation results, policies, retrieval settings and customisation notes.
Limit the supplier’s use of these materials to transition assistance and require secure transfer. Where an excluded component is needed to run the service, require an equivalent replacement, a licence or a documented workaround.
Delivery formats and acceptance tests
Require source-to-target mapping, migration tools and two knowledge-transfer workshops. Also specify issue triage and escalation steps, access to named staff, scheduled walkthroughs and prompt answers to migration queries.
Apply the export schedule’s validation requirements. Test duplicate handling, reconstruction of sample workflows and successful import into the replacement environment.
Deadlines and continuity commitments
Assign a named individual to each role below, with a deputy and an escalation contact.
| Handover step | Responsible parties | Deadline and dependency | Acceptance evidence |
|---|---|---|---|
| Final incremental exports | Supplier delivers; incoming provider imports | Every 24 hours until cut-over; final delta before cut-over | Reconciled records; no missing final transactions |
| Integrity checks | Incoming provider tests; buyer signs off | Within five calendar days of delivery | All mandatory records imported; no unresolved referential-integrity errors |
| Cut-over and deletion | Buyer authorises; supplier acts; incoming provider checks | Disable old integrations only after written cut-over approval; provide deletion evidence within 30 calendar days of accepted handover, subject to agreed retention rules | Old keys, webhooks and jobs disabled; critical workflows pass; signed deletion record covering replicas, backup deletion dates and lawful retention |
| Emergency transition | Supplier mobilises; buyer sets priorities; incoming provider tests recovery | Critical response within four hours; recovery against agreed targets | Priority workflows restored and outstanding gaps logged |
Charges, responsibilities and remedies
Set a 60-day support window and state the included hours. Allow charges for extra work only at capped rates in £, with a fee ceiling, pre-approved expenses and itemised invoices.
Escalate missed milestones to a named senior contact. Require remediation at no charge, support extensions and recovery of agreed re-performance costs, subject to the liability cap.
Use the checklist below to check that the contract includes the support window, owners and handover tests.
Contract Review Checklist: Test the Exit Plan
Use this checklist before signing or renewal to check whether the exit plan works in practice.
Review each clause against the same fields: protected asset, responsible party, delivery format, deadline, service level, cost and remedy. Name the buyer’s owner, supplier contact and required evidence. Separate customer data from prompts, custom code, configurations, outputs, audit records and third-party components. The phrase “all data” may leave important assets out.
Before go-live or renewal, export a representative sample and import it into an isolated environment. Check linked records, permissions, versions, timestamps, metadata, archived items, access rules and core workflows. Require 100% reconciliation of critical records and relationships, with no unexplained permission changes[4]. Keep the manifest, checksums, import results, defects and sign-off. If the sample fails, fix the contract terms before production use.
Link this evidence to the exit strategy, dependency register, continuity plan and migration budget. Check each dependency’s owner, licence constraints, export method and estimated migration effort. Confirm who is accountable across technical, procurement, security, data-governance and legal teams.
Run a tabletop exit exercise to check who authorises the move, how users keep working and whether the budget covers parallel running, testing and retraining. A missing owner, licence restriction or budget gap means the exit plan is incomplete.
Read the exit schedule alongside the master agreement, order forms, data-processing agreement and licence terms. Flag suspension rights that could block retrieval, API limits that could delay extraction, supplier ownership claims over outputs and fees hidden outside the exit schedule. Ask solicitors whether liability caps and loss exclusions leave meaningful remedies if migration fails. Also confirm that retrieval rights survive termination.
Hokstad Consulting can assess technical dependencies and migration readiness for custom agent implementations. Use legal advice for ownership, licensing, data protection, liability and enforceable wording.
Conclusion: Agree a Testable Exit Before Signing
The five clauses work together to make an exit possible. Export rights let you recover data; custom-work rights preserve prompts and workflows; interface access restores connectivity; termination rights give you time to move; migration support covers the handover. A download alone won’t restore a working service.
Before signing, turn each clause into measurable commitments: export deadlines, interface documentation, named specialists, support hours and fee caps. Tie payment to acceptance, not just file delivery.[16][14]
Re-test after major platform, API or model changes, before affected interfaces are withdrawn. Require updated documentation and compatibility details, plus enough time to export affected assets.[14]
Set a timeframe and budget within which the organisation can carry out the transition.
FAQs
Which exit safeguards should I prioritise if my supplier resists?
Prioritise these exit safeguards:
- Data ownership and return rights: State who owns the data and require its return in a standard, usable format such as CSV, JSON or XML - not a proprietary format.
- Transition support: Set a clear support period, ideally 30 to 90 days, covering migration assistance, documentation delivery and system handovers.
- For-cause termination rights: Allow exit without penalties if the supplier fails to meet critical performance standards or undergoes a material adverse change.
How can I protect custom AI work built on proprietary models?
Your contract should give you full ownership of all customisations and configurations. It should also require complete system documentation and access to every configuration file when the contract ends. This helps you avoid costly reverse-engineering.
Set out clear terms for transition support, including technical help with migration and knowledge transfer sessions.
Keep proprietary AI services at the edges of your architecture. That way, your core logic stays portable and doesn’t depend on a single vendor’s ecosystem.
How can I budget for migration if my supplier shuts down?
Budget for data transfer fees, the cost of running both systems during the transition, professional services such as consultancy or extra staff, and any downtime costs. Set aside a contingency fund for unexpected expenses.
Make sure your contract sets prices in pounds sterling (£) to avoid costs changing with exchange rates. Carry out regular audits and keep detailed, itemised bills to spot hidden charges early.