What is a software escrow agreement?

It is a three-party arrangement between a vendor, a customer and a neutral escrow agent. The vendor deposits materials — historically source code and build instructions — with the agent. The customer gets no access while the vendor performs. On a defined release condition, typically bankruptcy, discontinuation of the product or an uncured failure to support, the agent releases the deposit to the customer along with a license to use it for continuity purposes.

Why does traditional escrow fail for AI systems?

Because the source code is frequently the least important part of the system. An AI product is application code plus model weights, a tokenizer or preprocessing pipeline, fine-tuning datasets or their provenance, prompt and configuration assets, retrieval indexes and embeddings, an evaluation harness that defines correct behavior, and a serving stack with specific hardware and dependency requirements. A deposit containing only a repository of application code releases something that cannot produce an inference.

What should an AI escrow deposit schedule list?

At minimum: application and infrastructure-as-code repositories, model artifacts including weights and tokenizer or feature-transformation code, model cards documenting training data sources and license terms, fine-tuning and evaluation datasets or a precise description where the data itself cannot be deposited, prompt templates and configuration, the evaluation harness with expected results, container or environment definitions pinning dependency versions, and current build and deployment runbooks. The schedule should also state update frequency, because a deposit refreshed once at signing is stale within a quarter.

Does escrow help if the vendor is only reselling a third-party foundation model?

Only partially, and this is the most common gap. If the product calls a third-party model API, the vendor cannot deposit weights it does not own and cannot grant rights it does not have. What escrow can preserve is the vendor's own layer — orchestration, prompts, retrieval logic, fine-tuning adapters where separately licensed, evaluation. Continuity then depends on your ability to obtain the underlying model independently, which is a separate commercial question worth answering before signing rather than after release.

What is escrow verification and is it worth paying for?

Verification is an agent-performed check on the deposit, sold in tiers ranging from confirming media is readable and inventoried, through compiling the code in a clean environment, to a full build-and-run test against expected outputs. For conventional software, the mid tier catches most problems. For AI systems the meaningful test is whether the deposit reproduces evaluation results within a stated tolerance, because a build that starts and a model that behaves are different claims.

Do escrow release conditions actually work in a bankruptcy?

Release conditions are contractual and their operation in an insolvency depends on the applicable insolvency law and on how the license was structured. In the United States, the intellectual-property provisions of the Bankruptcy Code are the reason escrow license grants are usually drafted as present grants of a license with the escrow release as a condition of exercise, rather than as a promise to grant a license later. This is a drafting question with real consequences, and it is one of the few places where a standard form is worth reviewing with counsel rather than accepting.

Source Code and Model Escrow for AI Vendors: What Actually Gets Released in 2026

What Escrow Was Built To Solve

The original problem was narrow and mechanical. A company licensed enterprise software that ran on its own servers, the vendor was small enough to fail, and if the vendor disappeared the binary would keep running until an operating-system upgrade or a security patch made it stop. The customer could not maintain the software because it had no source. Escrow closed that gap: deposit the source with a neutral agent, define the events that mean the vendor is no longer performing, and grant a license that activates on release.

That structure survived the move to SaaS awkwardly. With the software running on the vendor's infrastructure, source code alone no longer reconstitutes the service, so escrow deposits grew to include deployment scripts, infrastructure definitions and runbooks. Many procurement templates still in use today stop there. They were last meaningfully revised when the hardest missing piece was a Terraform module.

What An AI Product Actually Consists Of

Take a typical vertical AI product — document classification, claims triage, code review, whatever the vertical. The parts a continuity plan has to account for are not exotic, but they are unevenly distributed across the deposit schedule of a standard agreement.

Model artifacts. Weights for any model the vendor trained or fine-tuned, plus the tokenizer or feature-transformation code. Weights without the exact preprocessing that produced them are close to unusable, and preprocessing is often application code that nobody thought of as part of the model.
Training and evaluation data, or its provenance. Frequently the vendor cannot deposit the data itself — third-party licenses, personal data, customer data under other contracts. What it can deposit is the description: sources, license terms, filtering rules, and the eval sets that define what correct looks like.
Prompts and configuration. In retrieval-augmented and agentic products, a large share of the behavior lives in prompt templates, tool definitions, routing rules and thresholds, none of which are obviously "source code" to someone drafting a schedule.
Retrieval indexes and embeddings. These can usually be rebuilt if you have the corpus and the embedding model. If either is third-party and unavailable to you, they cannot.
The evaluation harness. This is the piece most often missing and the one that determines whether a released deposit is usable. Without a way to check that your rebuilt system behaves like the one you were paying for, you have inherited a system you cannot validate.
The serving stack. Container definitions, pinned dependency versions, accelerator requirements, quantization settings. AI dependency trees rot fast, and an unpinned environment reproduced eighteen months later frequently will not build at all.

The Third-Party Model Problem

A great many products described as AI vendors are orchestration layers over a foundation model they license by API. Escrow cannot fix this, and pretending otherwise is the most common form of continuity theater. The vendor cannot deposit weights it does not possess and cannot sublicense rights it was never granted.

What escrow can do is preserve the layer the vendor did build, which is often substantial: the orchestration graph, prompts, retrieval logic, guardrails, evaluation, and any adapters or fine-tunes the vendor owns under its own agreement with the model provider. Your continuity question then becomes whether you can independently obtain access to the underlying model on commercially reasonable terms. That is answerable during diligence — ask which model, under what account structure, whether the vendor's fine-tunes are portable, and whether the provider offers direct enterprise access in your jurisdiction. It is much harder to answer during a wind-down.

Release Conditions and the Bankruptcy Drafting Point

Release conditions are the contractual triggers: insolvency or bankruptcy filing, cessation of business, discontinuation of the specific product, assignment for the benefit of creditors, or an uncured material failure to provide maintenance and support after notice. Vendors negotiate these narrowly and add a dispute procedure so a customer cannot unilaterally assert a support failure and walk off with the deposit. That is reasonable; what matters is that the procedure has a defined clock rather than an open-ended arbitration that outlives the vendor.

The drafting point that experienced counsel focus on is the shape of the license. Under the intellectual-property provisions of the United States Bankruptcy Code, a licensee of intellectual property has protections when a debtor rejects the license, which is why escrow agreements typically grant the continuity license at signing — present, contingent, and exercisable only upon release — rather than promising to grant one in the future. A future promise looks much more like an executory obligation that can be rejected. Insolvency law is jurisdiction-specific and this is one of the few standard clauses where accepting the vendor's form without review is a genuine risk rather than a formality.

Verification: The Difference Between Continuity and a Receipt

Escrow agents sell verification in tiers. The cheapest confirms the media is readable and the file inventory matches the schedule. The middle tier compiles the deposit in a clean room. The most expensive builds and runs it against expected results. For conventional software the middle tier catches most of what goes wrong, because the common failure is a missing dependency or an undocumented build step.

For AI systems the only verification that answers the real question is behavioral. The test is not "does the service start" but "does the deposited system reproduce the evaluation results within a stated tolerance." That test requires the eval harness and expected results to be in the deposit, which is a good reason to require them regardless of whether you buy verification. A deposit you can inventory but not validate is a receipt.

A Realistic Deposit Schedule

If you are revising a template, the changes are mostly additive and mostly uncontroversial for a vendor acting in good faith:

Enumerate model artifacts explicitly — weights, adapters, tokenizer, preprocessing — rather than relying on a general reference to "software."
Require a model card or equivalent documenting training data sources and their license terms, so a released deposit does not create a licensing problem you cannot assess.
Require the evaluation harness and a current results baseline, and tie verification to reproducing it.
Pin the environment: container images or lockfiles with exact versions, plus stated hardware requirements including accelerator type and memory.
Set an update cadence tied to releases rather than to the calendar, with a lightweight confirmation from the agent that a deposit was actually received.
Address third-party model dependencies directly — name them, and record whether the vendor's rights are sublicensable or whether you need your own agreement.
Include operational data export separately. Escrow protects the system; a data export right protects your records, and the two are routinely confused.

When Escrow Is The Wrong Tool

Escrow costs real money annually and consumes negotiation capital. It is worth it when the AI system is embedded in a process you cannot pause, when switching costs are high because of integration or model-specific tuning, and when the vendor is small enough that failure is plausible. It is a poor fit when the vendor is a large platform whose failure would be a systemic event, when the function is genuinely commoditized and a competitor could be swapped in within the tolerable outage window, or when the real exposure is your data rather than the software.

In that last case the better instruments are a continuous data export in a documented format, a defined transition-assistance period at agreed rates, and a commitment to maintain the export path through wind-down. Many companies buy escrow and skip these, which is the wrong way round: the export right helps in every failure scenario, including the common one where the vendor survives and you simply want to leave.

Frequently Asked Questions

Who pays for AI escrow?

Practice varies. Vendors often maintain a single multi-beneficiary deposit and charge each customer a beneficiary fee, which is cheaper than bespoke arrangements and is usually the right structure to ask for. Where a customer requires a custom deposit schedule with model artifacts and verification, expect the vendor to push the incremental cost across. The negotiation is more productive when framed around the deposit contents than around the fee.

Can we require escrow from a vendor that has never done it?

You can, and small vendors frequently agree, but budget for the fact that assembling a genuinely runnable deposit is work they have not done before. The useful move is to make the first deposit a milestone with verification attached rather than a checkbox at signature, because the first attempt commonly reveals that undocumented build steps live in one engineer's head.

Does escrow give us the right to keep using the system commercially?

That depends entirely on the license grant, and it is the clause to read closely. Continuity licenses are usually limited to internal use for the purpose of maintaining and supporting the licensed product for your own operations, without rights to sublicense, distribute or build a competing offering. If your actual need is broader, negotiate it explicitly; it will not be read in.

What about open-weight models — is escrow still needed?

If the vendor builds on openly licensed weights you can obtain yourself, one large failure mode is already mitigated, but the vendor's own contribution still is not. Fine-tunes, prompts, retrieval design and evaluation remain proprietary, and those often carry most of the product's value. Escrow scoped to that layer is cheaper and easier to verify, which makes it a more realistic ask.

How often do release conditions actually trigger?

Rarely, which is precisely why deposits go stale and nobody notices. The discipline that matters is not the release event but the routine: confirming deposits are current, that verification has been performed at least once, and that someone on your side knows what receiving the deposit would require operationally. An escrow nobody has tested is an assumption, not a control.

We tell customers our platform has continuity protections. Is that a risk?

It can be. Statements on a website or in a trust center about escrow, continuity or data portability are representations, and they are read literally after an incident by customers and sometimes by regulators. If the deposit covers application code only, saying the platform is escrowed overstates what exists. Describe the scope accurately, or describe it less specifically.

Does Your Site Promise Continuity You Have Not Built?

Trust pages, security overviews and enterprise landing pages accumulate claims about escrow, portability and business continuity. The strongest-sounding version is usually the oldest one, written before anyone checked the deposit schedule.

See every continuity, security and compliance claim on your site in one pass. Run a free scan and check each against what your agreements actually cover.

This article is general information and not legal advice. Escrow enforceability and the treatment of licenses in insolvency are jurisdiction-specific and fact-dependent. Confirm requirements with qualified counsel before relying on any escrow arrangement.