1. Introduction
The rapid adoption of artificial intelligence across commercial operations has heightened a familiar category of business risk: technology continuity risk. As organisations embed AI-driven systems into core operations, the consequences of supplier failure or loss of access to critical platforms have grown more serious.
By some accounts, global AI spending reached approximately US$340 billion in 2025, with most organisations now using AI in at least one business function. Yet this rapid adoption carries real risk: many AI projects fail to deliver their intended outcomes, and the dependency chains created by these systems are rarely well understood. When an AI vendor fails, customers may find themselves unable to access their platforms, data, or the trained models that underpin critical operations, often with little warning and no clear path to recovery.
Legal, commercial and procurement teams must therefore understand both the nature of AI continuity risk and what can be done to mitigate it.
2. Why contractual protections are not enough
Procurement teams commonly rely on contractual mechanisms, warranties, indemnities, SLAs and service credits, as their primary means of managing supplier risk. But these do not address continuity risks when a vendor becomes insolvent or ceases to trade. An indemnity from a company in administration is unlikely to result in any meaningful recovery.
Modern technology ecosystems are deeply interconnected. The CrowdStrike outage of July 2024 affected approximately 8.5 million devices worldwide and caused estimated losses of US$5.4 billion to Fortune 500 companies alone, whilst the Cloudflare outages of November 2025 triggered cascading failures across ChatGPT, LinkedIn, Zoom, and numerous fintech platforms. A single configuration error can propagate through shared infrastructure at a speed no contractual SLA could anticipate or remedy in real time.
3. The regulatory backdrop
Regulators across Europe and the UK now treat operational resilience, not merely cybersecurity, as the right framework for managing technology risk.
NIS2 Directive
The NIS2 Directive raises the EU's cybersecurity ambition, mandating supply chain security policies, risk assessment, and incident management plans. Member States were required to transpose NIS2 into national law by 17 October 2024. NIS2 applies to a broad range of “essential” and “important” entities across critical sectors, with penalties of up to €10 million or 2% of global annual turnover for non-compliance. In-scope organisations must ensure the security of their immediate supply chains, including incorporating cybersecurity requirements into contracts with direct suppliers and service providers.
DORA
The Digital Operational Resilience Act (DORA) has been applicable since 17 January 2025. It applies to financial entities and imposes requirements for ICT risk management, incident reporting, resilience testing, and third-party risk management. For financial services organisations procuring AI systems, DORA has significant practical implications: contracts with AI vendors must include specific provisions covering service levels, data access and recovery rights, audit rights, and termination rights; financial entities must maintain documented exit strategies for critical AI services; and where AI platforms depend on designated critical ICT third-party service providers, such as AWS, Microsoft, or Google Cloud, among the 19 providers currently designated by the ESAs, additional governance and concentration risk obligations apply. DORA imposes penalties of up to 2% of annual worldwide turnover.
EU AI Act
The EU AI Act entered into force on 1 August 2024. Under the Digital Omnibus package agreed in May 2026, the original 2 August 2026 deadline for high-risk AI systems has been extended: standalone high-risk systems under Annex III must comply by 2 December 2027, and high-risk systems embedded in regulated products by 2 August 2028. The Act introduces transparency, governance, and risk management obligations that intersect with continuity planning.
UK: CTP regime and Cyber Security Bill
The UK, no longer an EU member state, has developed its own parallel frameworks for operational resilience. For the financial services sector, the Critical Third Parties (CTP) regime, introduced under the Financial Services and Markets Act 2023, came into force on 1 January 2025 and allows the Bank of England, the PRA, and the FCA to exercise direct oversight of third-party providers designated by HM Treasury as critical to the UK financial system. Initial CTP designations are expected later in 2026, with cloud infrastructure providers, data vendors, and AI/ML model providers likely candidates. The FCA’s October 2024 lessons-learned report on the CrowdStrike outage made clear that UK regulators expect firms to manage critical technology dependencies with the same rigour as their EU counterparts.
Beyond financial services, the Cyber Security and Resilience Bill, introduced to Parliament in November 2025 and expected to receive Royal Assent in 2026, will extend cybersecurity obligations to operators of essential services, digital service providers, data centres, managed service providers, and designated critical suppliers across all sectors. The Bill builds upon the Network and Information Systems Regulations 2018, which transposed the original EU NIS Directive while the UK was still an EU member state and remains in force as retained law.
Taken together, NIS2, DORA, and the EU AI Act in Europe, and the UK CTP regime and Cyber Security and Resilience Bill domestically, mark a regulatory shift from pure cyber risk to operational resilience, including the management of supplier risk and critical third-party dependencies.
4. What is AI escrow?
Traditional software escrow involves a tri-party agreement between the developer, the customer, and an independent escrow agent. The developer deposits source code, build environments, and deployment scripts, and the customer gains access upon defined release events (typically insolvency, breach of maintenance obligations, or ceasing operations). Modern escrow deposits now routinely include cloud infrastructure configurations, SaaS credentials, and deployment pipelines. Yet even this expanded scope is insufficient for AI systems.
AI amplifies continuity risk. Unlike traditional software, where source code can be deposited in escrow and recompiled if the vendor fails, AI systems present different challenges:
- First, AI models evolve rapidly: OpenAI has deprecated entire model generations (including the GPT-3 family and GPT-4.5) with notice periods as short as three months, forcing customers to migrate or lose access.
- Second, even developers may not fully understand how a trained model produces its outputs, making independent replication difficult.
- Third, foundation models are typically delivered as cloud-hosted APIs owned by a small number of private companies; the customer never possesses the underlying weights or training data.
The consequences of vendor failure are not hypothetical: in 2024 and 2025, high-profile AI startups including Humane, Builder.ai, and Forward Health shut down abruptly, while others such as Inflection AI and Adept AI were effectively acquired for their talent, leaving customers stranded. Meanwhile, research suggests that over 40% of AI startups launched between 2022 and 2024 have already failed or been wound down. For any organisation reliant on third-party AI, the core question is whether continuity can be ensured if the vendor fails, pivots, or is acquired, and whether the organisation can continue operating if the model it depends upon is deprecated, degraded, or withdrawn.
In principle, an effective AI escrow arrangement must cover all material necessary to reconstruct the AI platform: model weights and parameters, prompt frameworks and configurations, fine-tuning artefacts, retrieval systems and vector databases (searchable stores of data used to augment model responses), supporting codebases, deployment environments (including infrastructure-as-code configurations), and documentation. Where legally and practically feasible, this may also include training data or representative subsets, though data protection requirements and third-party licensing restrictions often limit what can be deposited.
In practice, however, obtaining such commitments from major foundation model providers is extremely difficult, as discussed below. A range of third party escrow agents now offer AI-specific escrow services with technical verification, but the challenge is vendor willingness rather than agent capability. Emerging approaches include SaaS continuity / hot failover, pre-configured dormant instances that can be activated immediately upon a release event, and automated escrow, which involves continuous, automated depositing of updated materials as the AI system evolves.
5. Practical challenges
AI escrow addresses a real need, but implementation is hard. For example:
Multi-tenant environments
Modern AI platforms typically operate as multi-tenant SaaS environments, where multiple customers share underlying infrastructure, compute resources, and model instances. This architecture makes it hard to isolate customer-specific assets, such as fine-tuned model weights, prompt configurations, and retrieval databases, from shared components. For escrow purposes, vendors must be able to extract and deposit materials that would enable a specific customer to reconstruct their implementation independently of the shared infrastructure. This often requires careful architectural planning from the outset and may require the deposit of infrastructure-as-code configurations and containerised deployment environments.
Third-party foundation models: the limits of escrow
Many enterprise AI applications are built upon proprietary foundation models, such as OpenAI’s GPT series, Anthropic’s Claude, or Google’s Gemini, which are delivered via API and remain entirely under the control of the model provider. Model weights are treated as core trade secrets; even Microsoft, despite investing over US$13 billion in OpenAI, does not have rights to OpenAI’s model weights under its revised partnership agreement. Customers have no contractual right to demand that these foundation models be placed into escrow, and the model providers will not agree to such arrangements.
The practical reality is that escrow negotiations with major AI providers will focus on what they are willing to deposit, typically limited to customer-specific configurations, API documentation, and integration specifications, rather than the underlying model. The correct approach is therefore to escrow the customer’s own fine-tuning artefacts, prompt frameworks, retrieval-augmented generation (RAG) configurations (systems that retrieve external data to augment model responses), and integration logic, the components that sit atop the foundation model.
Customers should also document their foundation model dependencies and consider whether alternative models could be substituted in a continuity scenario, recognising that this may require significant re-engineering. Where AI is procured from smaller or bespoke vendors building custom solutions, full escrow arrangements covering model weights may be more achievable, particularly where the customer has significant bargaining power or operates in a regulated sector with documented continuity requirements.
Verification of escrowed assets
Deposited materials are of limited value if they cannot be deployed successfully when needed. Unlike traditional source code escrow, where verification typically involves confirming that code compiles and executes, AI escrow verification must confirm that models produce expected outputs, that prompt frameworks function correctly, that retrieval systems return appropriate results, and that the entire pipeline can be reconstructed in a new environment. This requires technical expertise and may involve the use of test datasets and benchmark evaluations. Customers should require periodic verification exercises, ideally conducted by the escrow agent or an independent technical expert, to confirm that escrowed assets remain complete and deployable.
Automated and continuous deposit
AI systems evolve rapidly. Models may be retrained on new data, prompts refined based on user feedback, and retrieval databases updated as new information becomes available. Traditional escrow arrangements, where deposits are made manually at periodic intervals, are ill-suited to this pace of change. A deposit made six months ago may bear little resemblance to the current production system. Customers should therefore require automated, continuous deposit solutions that integrate with the vendor’s development and deployment pipelines, ensuring that escrowed materials remain synchronised with the live system. Where this is not feasible, deposit schedules should be aligned with the vendor’s release cadence, and customers should understand the potential gap between the escrowed version and the production version at any given time.
6. Key release triggers
The value of any escrow arrangement depends on the precision of the release triggers. Customers should negotiate triggers covering: insolvency or ceasing to trade; breach of maintenance obligations; transfer of IP or change of control; and sustained outages or service level failures beyond defined thresholds. Each release condition should balance the vendor’s legitimate commercial interests with the customer’s right to operational continuity.
7. What customers should do now
Customers should prioritise the following:
- Conduct a dependency audit: map all AI-dependent applications and assess their criticality.
- Review existing contracts: examine whether current escrow provisions are fit for purpose for AI systems. In most cases, they will not be.
- Negotiate AI-specific escrow provisions: ensure the deposit scope extends beyond source code to encompass model weights, fine-tuning artefacts, prompt frameworks, deployment environments, and, where legally permissible, training data or representative subsets.
- Define clear release triggers: ensure release events are drafted with precision, covering insolvency, breach, change of control, and sustained service failure.
- Address third-party dependencies: understand and document the chain of dependency where the vendor relies on foundation models or cloud providers.
- Require verification: require periodic verification of escrowed assets to confirm they can be deployed successfully.
- Develop exit strategies: define recovery time and recovery point objectives for critical AI applications.
- Align with regulatory requirements: ensure continuity planning supports compliance with NIS2, DORA, and the EU AI Act where applicable.
AI is transforming how businesses operate, but that transformation brings new dependencies and new risks. Organisations that treat AI continuity as an afterthought may find themselves exposed when a critical vendor fails. Those that plan ahead, mapping dependencies, negotiating sound escrow arrangements, and keeping pace with regulatory expectations, will be better placed to maintain operational resilience.
