What Should Be Included in an AI Escrow Agreement?

Your organisation has already taken a sensible precaution. It holds the source code in escrow. However, the platform also relies on a trained model, your organisation’s knowledge base and cloud infrastructure. It will also need integrations, access credentials and third-party services.

Recovering the source code is only the first step.

Why an AI Escrow Agreement Needs to Go Beyond Source Code

Business-critical AI creates a wider continuity challenge than source code alone can address. After supplier failure, your organisation needs a practical way to keep the service running or recover it.

As we explored in our article on third-party risks for an AI system, organisations need to understand their dependency on external AI suppliers. Only then can they build an effective continuity strategy.

Traditional Source Code Escrow addresses part of this risk. It protects source code and other agreed materials for release under specific conditions. However, AI systems typically have much wider dependencies.

An AI solution can depend on models, data, infrastructure, prompts and agent workflows. It can also use retrieval-augmented generation (RAG) knowledge bases. These knowledge bases provide trusted information that the system uses when producing answers.

This means buyers need to consider more than what goes into the escrow deposit. They must first decide what AI system recovery should look like for their organisation.

Start With Your AI Recovery Strategy

The deposit and testing should follow the recovery strategy, not the other way around.

Before deciding what belongs in escrow, buyers should define what their organisation needs and expects to happen following supplier failure. The intended outcome will determine the assets, access and support that the AI escrow agreement needs to protect.

Interim Use or Long-Term Development?

First, consider how your organisation intends to use the solution after a supplier failure event. It could need interim operation while moving to another supplier. Alternatively, your organisation could want and need to maintain and develop the system over the longer term.

These outcomes create different requirements. Long-term operation can require additional data access or control, development materials and retraining capabilities. Interim use could focus more heavily on maintaining service while your organisation prepares an alternative.

Defining this outcome early helps buyers avoid protecting materials that do not support their organisation’s actual recovery needs.

Who Will Recover the AI System?

Buyers should also decide who will carry out the recovery process. Some organisations have the technical skills and capabilities to redeploy an AI system internally. Others will need specialist support to recover and operate it.

Buyers should also consider the required recovery time. A technically possible recovery route offers limited protection if rebuilding takes longer than the organisation can tolerate.

These decisions can significantly change the escrow requirements. An internal team could need detailed documentation, build instructions and infrastructure configurations. Other organisations could need technical assistance as part of their recovery plan or a secondary system to fall back onto.

For organisations without the internal resources to redeploy services in a reasonable amount of time following a release, SaaS Recovery Escrow provides a secondary cloud environment that can be recovered by the escrow agent following a release event on behalf of the beneficiary.

Can the Existing Environment Continue?

Rebuilding from scratch is not always the most practical approach.

Buyers should establish whether the system operates within an environment dedicated to their organisation. If it does, SaaS Access Continuity can provide credentials to the existing production environment following a supplier default event.

This approach can avoid rebuilding the entire system from source code, configuration materials and databases. However, it requires the right credentials, permissions and operational controls to continue the service or subscriptions.

Where continued access is not possible, your organisation will need another recovery route. This could involve rebuilding from the escrow deposit or using a prepared recovery environment.

The right approach therefore depends on what your organisation needs after supplier failure: rebuild, continue the existing environment or recover into a prepared environment.

What Should Go into an AI Escrow Agreement?

Once the AI recovery strategy is clear, buyers can identify what the escrow deposit needs to contain.

The exact materials will depend on the system and the intended recovery route. However, the following areas provide a useful starting point.

1. Source Code

Source code remains an important part of most software escrow arrangements. This also applies to AI escrow deposits, especially for proprietary supplier applications. However, buyers should avoid assuming that source code alone provides enough protection.

The important question is: if the supplier disappeared tomorrow, could the deposited materials support rebuilding, operating and maintaining the solution? Some AI systems will also require future retraining or fine-tuning. Answering this question means looking beyond the code itself.

2. Model Weights and Checkpoints

Model weights contain the parameters an AI model learns during training. These weights can form one of the most important parts of an AI solution. Without them, source code can recreate the application but not the trained model.

As we explain in our article on protecting AI models, effective protection needs to consider the assets that make the AI system operational.

Buyers should consider whether model weights, checkpoints and other parameters belong in the escrow deposit. They should also consider how often the supplier needs to update these assets. This helps ensure the deposit reflects the model currently in use.

3. Training Data and Data Preparation

AI systems often depend heavily on large datasets. The supplier will use this data to create, refine or operate the model. Where appropriate, an escrow arrangement can include deposits of training data. It could also include access instructions, preparation scripts and related processes.

However, data rights require particular care. Privacy requirements, licensing restrictions and third-party rights can affect how organisations store and use data. This does not mean placing every dataset into escrow. Instead, buyers should identify essential data and ensure their organisation can access it if needed.

4. Training and Retraining Workflows

For some AI systems, running today’s model will not provide long-term continuity. The model will need retraining or fine-tuning to remain effective. This becomes particularly important when the recovery strategy involves long-term operation.

The deposit can include the workflows needed to train and maintain the model. These can cover data loading, model training, performance validation and checkpoint creation. Buyers should ensure these materials support their organisation’s intended use after release.

5. Deployment Materials and Infrastructure

Receiving an AI model does not necessarily mean an organisation can run it. AI solutions often depend on a specific technical environment. This can include containers, GPU settings, API endpoints, load balancers and monitoring tools.

The solution can also depend on integrations or services controlled by third parties. Buyers should identify everything their organisation needs to reproduce the environment. They should then ensure the escrow arrangement supports realistic redeployment.

For SaaS and cloud-hosted AI systems, SaaS and AI Escrow can extend protection beyond source code. The appropriate solution will depend on whether the organisation intends to rebuild, retain access or recover into another environment.

6. Documentation and Build Instructions

Technical assets have limited value if nobody understands how they fit together. Documentation and runbooks can therefore form an essential part of an AI escrow deposit.

A skilled third party should understand how to build, deploy and operate the solution. The required level of documentation will also depend on who will perform the recovery.

An internal technical team could need detailed build and deployment instructions. Where your organisation needs external assistance, the recovery plan and escrow verification processes should identify that support in advance.

7. Dependencies and External Services

AI solutions rarely operate independently. They can rely on software libraries, APIs, cloud infrastructure, external models or other third-party services.

Buyers should identify which dependencies support continued operation. They should then establish whether access will continue following an escrow release. If access cannot continue, your organisation will need an alternative continuity arrangement.

Insolvency is only one threat to continuity. A supplier can discontinue a product, stop support or change its product strategy after an acquisition. An essential third-party component can also lose support.

Identifying these dependencies early helps buyers understand what belongs in escrow. It also highlights areas that need a separate continuity strategy.

8. Clear Release Conditions

Knowing what goes into escrow is only half of the equation. The AI escrow agreement also needs to establish when those materials will be released.

Release events can include insolvency, business closure, service withdrawal or failure to support the product. Release conditions can also cover changes affecting essential intellectual property.

The right triggers will depend on the product, supplier relationship and recovery requirements. Clear conditions help buyers act before continued operation becomes impossible.

9. Rights to Use the Released Materials

Escrowed materials offer little value if the buyer cannot use them. The agreement should therefore address licensing, intellectual property and data rights.

The required rights will depend on the recovery strategy. Interim operation can require different rights from long-term maintenance and development. Buyers should define these requirements when planning their organisation’s recovery route.

The legal arrangements should support the intended technical recovery plan. These protections should form part of wider due diligence when reviewing a software licence or SaaS agreement.

10. Regular Updates and Escrow Verification

AI systems rarely remain static. Suppliers update models and code, while data and third-party dependencies also change over time. The escrow deposit should reflect the solution that your organisation currently uses.

Regular deposits help keep the materials current, but depositing assets is only the first step. Buyers also need confidence that those materials can support their organisation’s intended recovery route.

Escrow verifications test the deposited assets against that recovery scenario. It can identify missing components and other problems before your organisation needs to rely on them.

Verification should also reflect and work through the chosen approach. Testing a deposit for rebuilding will differ from testing access continuity or a prepared recovery environment and scaling process, especially where evidence-based reporting is required to support compliance or regulatory requirements.

Why an AI Escrow Agreement Shouldn’t Be One-Size-Fits-All

There is no universal list of files that makes every AI escrow agreement effective. The right protection depends on the system, its dependencies and the required recovery outcome.

A straightforward AI-enabled application can require a relatively limited deposit. A machine-learning platform can depend on models, data pipelines, specialist infrastructure and continued access to external services.

This is why the AI recovery strategy needs to come first. Once buyers understand their organisation’s required outcome, they can define the right deposit and wider continuity arrangements.

A Buyer’s AI Escrow Checklist

When considering an AI escrow agreement, buyers should start with the recovery approach:

• How critical is this AI system to our operations and what is the cost to us if it failed?
• What must happen if the supplier stops providing the service?
• Do we need interim use or long-term operation and development?
• Who will carry out the recovery?
• Do we have the necessary technical skills internally or will we need specialist recovery assistance?
• How quickly must the service return?
• Does the system operate within an environment dedicated to us?
• Could we continue using that existing environment?

Once the recovery approach is clear, buyers should consider the deposit and agreement:

• Is source code alone enough to recreate the solution?
• What infrastructure and deployment materials will we need?
• Do we need model weights or checkpoints?
• What data or access rights does the system require?
• Do we need training or retraining workflows?
• Which third-party services support the solution?
• Do we have enough technical documentation?
• How often will the supplier update the deposit?
• Will an independent party verify the chosen recovery route?
• What supplier default events will trigger a release?
• Will we have the required rights granted to use the materials after release?

If these questions are difficult to answer, there will be gaps in your organisation’s supplier dependency assessment. Identifying them early gives buyers time to build the right safeguards into the supplier relationship.

Building AI Business Continuity into Procurement

Organisations should consider AI escrow before they become dependent on a business-critical third-party system. An effective AI escrow agreement can form part of a wider supplier-risk and business-continuity strategy, mitigating service deterioration and concentration risks associated with utilising third-party software vendors.

Buyers should begin with their organisation’s required recovery outcome, not a standard list of deposit materials or legacy escrow terminology. They should decide how the service will continue, who will recover it and how quickly it must return. They can then build the escrow arrangement around those requirements.

Effective escrow services for AI systems should support a practical recovery strategy, not simply hold source code. That strategy should protect the assets, access, rights and operational capabilities your organisation needs for recovery.

Considering Escrow for a Third-Party AI Solution?

The The Escrow Company helps organisations define the recovery outcome they need from business-critical AI solutions. We identify whether rebuilding, continued access or a prepared recovery environment provides the most practical route.

We then identify the source code, models, data, infrastructure, documentation, credentials and operational support needed to achieve that outcome. Finally, we structure and verify the AI escrow agreement around the chosen recovery strategy.

This creates more than a deposit of technical assets. It provides a practical continuity plan designed around how your organisation will recover.

Speak to our team about SaaS and AI escrow and choosing the right recovery approach for your organisation.