Decision at stake: should the board/SRO approve the procurement and contract sign‑off that gives a supplier operational control of an AI model or AI service used in an essential public function? Accepting an AI model without explicit rights and tested reversibility converts a commercial buy into a long‑term operational dependency with material service, regulatory and financial risk.
Why model portability and reversibility are delivery risks, not legal curiosities
Procurement decisions that expose public services to opaque model ownership, API‑only access or undisclosed third‑party components create operational dependencies. When a supplier controls the live model, training data or the only operational runbook, a routine commercial dispute, price rise, acquisition or change of licensing terms can immediately threaten continuity, compliance and the ability to extract contracted benefits.
This problem arises because technology, contracts and delivery practices have not evolved together. Legal teams draft IP and licence clauses; commercial teams negotiate price and SLAs; technical teams accept API access for integration speed. Without explicit delivery artefacts and acceptance tests that prove egress, interchangeability and operational self‑sufficiency, the technical reality — one vendor owning the only viable path to run or retrain the model — defeats contractual intent.
How process, data, systems, people and suppliers interact to create vendor lock‑in
Model lock‑in is the product of six interacting domains: (1) procurement terms (IP, licence, export rights), (2) technical integration (proprietary APIs, data formats, cloud enclaves), (3) data governance (training data provenance, personal data constraints and transferability), (4) operational runbooks and skills (who runs inference and retraining pipelines), (5) supplier supply chain (subprocessors, third‑party model weights), and (6) assurance and controls (acceptance tests, audit logs, escrow). Weakness in any domain reduces recovery options and multiplies failure modes.
Example failure chain: a trust procures an API‑only clinical triage model (procurement), the supplier refuses to export weights (IP), clinical records used for fine‑tuning are classed as proprietary derivatives (data governance), integration uses vendor SDKs (technical), local teams lack MLOps skills to replicate the pipeline (people), and contract exit clauses are vague (assurance). When the supplier changes pricing or ceases support, the customer cannot reproduce the model, cannot legally train a replacement with the same performance, and cannot deliver the service.
The lifecycle gates you must use (sourcing → procurement → delivery → exit)
Treat portability and reversibility as lifecycle requirements with explicit gates and artefacts at each stage. Key lifecycle stages and the minimum artefacts to require:
1. Sourcing & option selection: documented model policy that classifies acceptable model types (open‑weight, open‑license, vendor‑hosted API) tied to service‑criticality and data sensitivity; supplier mapping showing third‑party components and cloud hosting locations; risk decision record signed by SRO.
2. Procurement & contract award: contract schedule defining IP ownership/licences, permitted uses of customer data, model export obligations (weights or retrainable artefacts if required), transition assistance and pricing protections, escrow arrangements, flow‑down clauses for subprocessors and termination for regulatory change.
3. Implementation & technical acceptance: deliverable list including model provenance report, training dataset snapshot (where lawful), reproducibility scripts, export in open, documented formats, egress test results and a documented runbook with handover sessions.
4. Operational readiness & exit validation: a contract exit simulation (technical dry‑run) that demonstrates full migration of data and functional parity on a substituted stack or a successor supplier, plus continuous monitoring and scheduled retraining checkpoints in agreed form.
Boards should require evidence at each gate before signing, and make approval conditional on successful execution of the next test/gate rather than on promises alone.
Concrete artefacts, acceptance tests and their pass/fail criteria
Require the following artefacts at technical acceptance and explain the pass criteria:
• Model provenance report: provenance lineage for the model, third‑party components, licences for foundation models and an inventory of training datasets. Pass: no undisclosed third‑party dependencies and all dataset licences documented.
• Reproducibility bundle: scripts, environment definition (container images or infrastructure‑as‑code), sample training data (or synthetic equivalence) and test harness. Pass: independent run of the bundle reproduces baseline outputs within pre‑agreed tolerances.
• Exportable model artefact or API‑ed egress: either model weights in a documented format or a documented, machine‑readable export of model behaviour (e.g., tests, transformation pipelines). Pass: export produces a working model on a neutral host using the reproducibility bundle.
• Egress and data migration test: export of customer data and model‑related metadata in non‑proprietary formats and successful import into a target environment. Pass: end‑to‑end functional test showing parity for a representative workload.
• Escrow deposit and retrieval test: code, critical models and documentation placed in escrow; retrieval process executed under controlled conditions. Pass: escrow agent can provide artefacts and a neutral party can deploy them.
• Operational runbook and knowledge transfer: runbook, incident playbooks and at least two knowledge transfer sessions with local teams. Pass: local operations team completes a maintenance and incident handling scenario unaided.
Failure modes and conditional mitigations boards must consider
Common failure modes and the conditional action leaders must require:
• Supplier refuses to export weights or reproducibility scripts: conditional mitigation — require API‑level portability guarantees, extended transition assistance, right to audit, and stronger escrow/indemnity terms. If supplier still refuses, reclassify the procurement as high‑risk and require executive approval with clear contingency funding.
• Legal or regulatory block on exporting training data: require schema and synthetic dataset generation, plus clear legal mapping in contract showing what can legally be exported as a migration artefact. If migration cannot meet legal tests, require hybrid deployment options (on‑premise enclave) with contractual price ceilings.
• Performance/behaviour drift after migration: require baseline performance metrics, test harness and an agreed retraining plan with access to labelled data snapshots. Include a performance‑linked SLA and remediation timetable.
• Supplier insolvency or acquisition: require escrow, step‑in rights, and an exit simulation executed before go‑live to prove recoverability.
• Subprocessor dependency unknowns: require supplier to publish an approved subprocessor registry and include flow‑down obligations; if significant subprocessors are non‑compliant, require a replacement supplier or additional contract assurances.
Commercial and contractual mechanisms that work in practice
Specific contract mechanisms to insist on (tailored, not boilerplate):
• Model portability clause: obligation to provide model weights, environment specification and reproducibility scripts within X days in documented format, or, if not possible, supplier‑funded migration assistance for an agreed period.
• Data and model egress SLA: defined egress test windows, export format, and acceptance criteria with financial penalties if migration fails within agreed tolerances.
• Escrow and trusted third‑party retrieval test: deposit of deterministic artefacts and an annual retrieval simulation to prove access.
• IP and licence schedule: clear carve‑outs for customer data, customer‑specific fine‑tuning, outputs and derivatives; restrictions on supplier re‑training commercial models using customer‑confidential data without explicit, auditable consent.
• Flow‑down and supply‑chain visibility: supplier must secure equivalent rights from subprocessors and provide an auditable registry of model component provenance.
• Price protection and performance‑linked transition fees: limit sudden commercial leverage at the point of exit by capping transition fees and tying them to objective egress completion milestones.
How to sequence these decisions at board and SRO level
Boards and SROs should treat contracting and acceptance as a sequence of conditional approvals rather than a single sign‑off. Recommended sequence:
1. Pre‑award policy decision: the board determines the acceptable model access class (weights vs API) for the service class and data sensitivity, backed by a documented risk appetite.
2. Contract award conditional: procurement may award subject to successful escrow deposit and a satisfactory reproducibility bundle demonstration within a defined period.
3. Technical acceptance gating: SRO with CTO signs acceptance only after the reproducibility bundle and exit simulation pass.
4. Live operation conditional: go‑live authorised with defined monitoring, retraining cadence and scheduled reassessment points (for example, after the first 90 days of live operation).
5. Regular contract health reviews: quarterly assurance on subprocessor changes, escrow state, export tests and pricing reviews.
Boards must stop treating AI model access as a legal question and start treating it as a delivery control: require exportable artefacts, a real migration dry‑run and escrow retrieval as preconditions to approval.
Antares recommended actions
These are Antares's recommended first actions for organisations turning the issues in this article into practical governance and delivery.
- Before market approach: classify the required model access type (open‑weight, open‑license, API‑only) based on service criticality and data sensitivity; document that decision and the risk appetite in the procurement strategy.
- Procurement stage: include explicit model portability, data egress, escrow and flow‑down clauses. Make award conditional on an escrow deposit and a reproducibility bundle demonstration within a defined window.
- Technical acceptance: require and witness a reproducibility run by an independent technical assessor that reproduces baseline outputs to pre‑agreed tolerances; require a live exit simulation (egress to a neutral environment) before go‑live.
- If the supplier refuses weights or reproducibility: escalate — require vendor‑funded migration support, stronger escrow terms and a stepped price cap; if the supplier still refuses, present a formal high‑risk exception to the board for decision.
- Operational assurance: mandate quarterly supplier health reviews covering subprocessor changes, export tests, pricing changes and a scheduled retrieval test from escrow; tie a portion of payment to completion of migration‑capable milestones.
Our insights are provided for general information only and reflect the position at the date of publication. They do not constitute legal, financial, regulatory, cybersecurity or other advice tailored to your circumstances and should not be relied upon as a substitute for appropriate professional advice.
While we take reasonable care over our content, we do not guarantee that it is complete, accurate or current. Reading our insights does not create a client relationship with Antares Consultancy. To the fullest extent permitted by law, we accept no liability for decisions made or losses arising from reliance on this content. External links are provided for convenience and do not imply endorsement.
