An AI escrow package is vendor-risk insurance, not paperwork. The artifacts are four; model weights or deployed checkpoint, prompt registry with versioned production prompts, eval test set with reference outputs and scoring rubric, and fine-tune scripts plus training data if a fine-tune is in production. The agent is a neutral third party with established release-event protocol, not buyer self-escrow. The release events are specific; bankruptcy, hostile acquisition, material SLA breach, end-of-life; not “material adverse change” boilerplate. Refresh quarterly minimum, monthly for high-velocity workloads, with annual drills that prove the escrow is real. The cost is $5K to $50K per year for the agent plus 0.1 to 0.3 of an engineer for buyer-side maintenance. This piece is the operating model: what to escrow, who holds it, what triggers release, what clauses make it enforceable, and how to test it before the vendor’s continuity event arrives.
This follows from the AI build-vs-buy-vs-hire decision matrix for 2026. The matrix’s third principle is that foundation models are buy permanently and that single-provider lock-in is a strategic vulnerability priced at a 20 to 40 percent risk premium; escrow is one of the procurement instruments that prices that vulnerability down.
Why escrow exists in the AI stack
A buy decision assumes the vendor will be there. Most of the time the assumption holds. Some of the time it doesn’t; bankruptcy, hostile acquisition, persistent SLA breach, end-of-life on six months’ notice. Each event is rare per vendor; in a portfolio of ten AI vendors over five years, at least one is likely.
Buyer exposure scales with the vendor’s depth in the workload. Inference-only API access has shallow exposure; switching is a PR. A fine-tuned model trained on proprietary data has deep exposure; the artifact encoding the workload sits on vendor infrastructure. An agent platform with an in-vendor prompt registry is deeper still; the operational substrate is gone if the vendor is gone.
Escrow converts deep exposures into shallow exposures. The buyer keeps operating against the vendor’s production system, but the artifacts that would otherwise be lost on vendor failure are held by a neutral third party and released on documented triggers. Buyer continuity is no longer contingent on vendor continuity.
The instrument is borrowed from legacy software-source-code escrow has been a procurement standard for decades. The AI version is similar in form and different in substance: different artifacts, faster refresh, AI-specific release-event criteria.
What goes in the package
Four artifacts.
Model weights or deployed checkpoint. Actual weights or a current snapshot. For fine-tuned models, the fine-tune output. For agent platforms with vendor-trained components, the trained artifact. For pure-buy workloads against frontier APIs this is typically not available; frontier providers won’t escrow weights and the buyer shouldn’t expect them to.
Prompt registry with versioned production prompts. Prompts encode the workload’s domain knowledge. Without them, a successor team rebuilds from a blank page. The escrow includes production versions, version history if forensic reconstruction may be needed, and metadata linking prompts to workloads.
Eval test set with reference outputs and scoring rubric. The artifact that lets a successor team know if the reconstituted workload works. Test items, reference outputs against the production model, scoring rubric, pass/fail thresholds.
Fine-tune scripts and training data. If a fine-tune is in production, the scripts that produced it and the data that fed it. Without these, the fine-tune is a black box; the successor team can run inference but cannot retrain or update.
Together the four artifacts let a competent successor team reconstitute the workload within a quarter; without them the rebuild is a multi-quarter project that may not converge on the original quality. That asymmetry is what makes the escrow worth carrying.
Who holds it
A neutral third party; Iron Mountain, NCC Group, EscrowTech, or equivalent; holds the package. The agent is selected on three criteria: established release-event protocol, verifiable infrastructure for storing model weights at scale (AI files are larger than legacy source-code escrows), and a litigation track record that demonstrates the clauses hold.
Self-escrow held by the buyer is not real escrow. It provides no protection against vendor disputes; the vendor can claim the buyer’s copy is unauthorized and seek injunctive relief. Legal protection comes from the third-party intermediary. Self-escrow held by the vendor is also not real escrow; the vendor controls the artifact and can withhold it on trigger.
What triggers release
Release-event clauses must be specific. Boilerplate “material adverse change” clauses are unenforceable; the threshold is contestable and the buyer requesting release will be tied up in litigation while the workload runs without artifacts.
Four release events:
- Vendor bankruptcy. Filing of Chapter 7 or equivalent. The clause should specify the filing event itself as the trigger, not later court approval; the gap between filing and approval is when the workload is most exposed.
- Hostile acquisition. Acquisition by a named competitor or by an entity that publicly redirects the project’s roadmap. The contract should include named competitors or a definition tied to product overlap; “competitor” alone is contestable.
- Material SLA breach. Documented persistent failure; typically breach in three of any twelve consecutive months, or in two consecutive months. Must be measurable; “service quality” without numbers fails in litigation.
- Product end-of-life. Vendor announcement of discontinuation, with a release window the buyer can use to reconstitute elsewhere.
Each event should produce automatic release on documented evidence, not contested release.
The clauses that make it enforceable
Five clauses convert escrow from paperwork to insurance.
Specific release-event list. Enumerated, with evidence requirements specified and the agent’s protocol binding.
No-injunction clause. The vendor agrees not to seek injunctive relief blocking release on documented triggers. Without this, the vendor can tie up release in court for months.
Refresh-cadence obligation with audit rights. The vendor is contractually obligated to deliver fresh artifacts on the agreed cadence, and the buyer can audit the agent’s holdings.
License-on-release clause. On release, the buyer receives a perpetual license to use the escrowed artifacts. Without this, the buyer holds artifacts but cannot legally deploy them; a particularly dangerous gap for fine-tunes trained on data subject to upstream licensing.
Export-control compliance. For cross-border deployments, the escrow must comply with applicable controls on the AI artifacts. The clause assigns responsibility and ensures release does not trigger violations.
Without these five, the escrow is decorative.
Refresh cadence
Quarterly minimum; monthly for high-velocity workloads. A six-month-old snapshot is worthless; the vendor’s production system has drifted past it. Match cadence to deployment cadence: slow-changing workloads quarterly, active workloads monthly, highly active workloads weekly or accept that escrow is a coarse safety net and invest more in multi-vendor redundancy. The agent verifies receipt and integrity each cycle. Without verification, the buyer learns at trigger that the last several refreshes were corrupted, incomplete, or rarely sent.
The annual release-event drill
Untested escrow is paperwork; tested escrow is insurance.
The drill: once a year, the agent delivers the package to a designated successor team; internal, outside contractor, or agency partner. The team attempts cold-start reconstitution against the eval set. Time-to-first-acceptable-output is measured. Gaps are documented and fed back into the contract.
The first drill almost usually finds gaps. Fine-tune scripts depend on a deprecated library. The prompt registry references a vendor-hosted variable resolver. The eval set’s reference outputs were generated against a model version no longer available. The drill surfaces these before they are operational risks. Cost is 2 to 4 engineer-weeks per drill; the value is the discovery of gaps.
Where escrow does and doesn’t apply
Escrow applies to vendors supplying fine-tuned models, agent platforms, RAG infrastructure, or other workloads where the buyer’s specific work is encoded in vendor-owned artifacts.
Escrow does not apply to frontier API providers (OpenAI, Anthropic, Google). They won’t escrow weights, the buyer shouldn’t expect them to, and the right vendor-risk management is multi-provider redundancy; two providers contracted at many times, secondary getting a small share of traffic continuously, ready to flip on a continuity event. Detail in build, buy, or fine-tune: a decision frame for foundation-model choices.
Escrow also doesn’t substitute for in-house artifacts. The eval set should already be in-house; the escrow ensures the vendor-side matches. Detail in the AI insourcing wave.
Frequently asked questions
What exactly should be in an AI escrow package?
Four artifacts: model weights or a current snapshot of the deployed checkpoint, the prompt registry with versioned production prompts, the eval test set with reference outputs and scoring rubric, and the fine-tune scripts plus training data if a fine-tune is in production. With those four, a competent successor team can reconstitute the workload within a quarter; without them, the rebuild is a multi-quarter project.
Who holds the escrow?
A neutral third party; Iron Mountain, NCC Group, or an equivalent escrow agent specializing in software and IP. Self-escrow held by the buyer is not real escrow; it provides no protection against vendor disputes. The escrow agent should have an established release-event protocol and verifiable infrastructure for storing model weights at scale.
What triggers a release event?
Vendor bankruptcy, vendor acquisition by a competitor with hostile redirect of roadmap, vendor breach of material service-level agreements, or vendor end-of-life of the product. The release-event clauses should be specific and machine-checkable wherever possible; not “material adverse change” boilerplate.
Does escrow apply to API-only frontier providers?
No. Frontier providers will not escrow weights and the buyer should not expect them to. The escrow strategy applies to AI vendors that supply fine-tuned models, agent platforms, or RAG infrastructure where the buyer’s workload is encoded in vendor-owned artifacts. For frontier API providers, vendor risk is managed through multi-provider redundancy, not escrow.
How often should the escrow be refreshed?
Quarterly at minimum; monthly is better for high-velocity workloads. A six-month-old escrow snapshot is worthless because the vendor’s production system has drifted past it. The refresh cadence should match the workload’s deployment cadence, with the escrow agent verifying receipt and integrity each cycle.
What does AI escrow cost?
Typically $5K to $50K per year for the escrow agent’s services, plus 0.1 to 0.3 of an engineer for the buyer-side maintenance; preparing snapshots, verifying integrity, running release-event drills. The cost is small relative to the workload value being protected; the failure mode is under-investment in the buyer-side maintenance, not the escrow fee.
Can we test the escrow without a release event?
Yes, and you should. An annual release-event drill; escrow agent delivers the package to a designated successor team, the team attempts a cold-start reconstitution against the eval set, time-to-first-acceptable-output is measured; is the only way to know the escrow is real. Untested escrow is paperwork; tested escrow is insurance.
What clauses make the escrow enforceable?
A specific release-event list, a no-injunction clause preventing the vendor from blocking release through litigation, a refresh-cadence obligation with audit rights, a license-on-release clause granting the buyer perpetual use of the escrowed artifacts, and an export-control compliance clause for cross-border deployments. Without these, the escrow is decorative.
How does escrow interact with the prompt registry?
The prompt registry is one of the escrowed artifacts and is also the most volatile; prompts change weekly in active development. The escrow refresh cadence should match the prompt-registry release cadence, and the registry’s versioning system should produce the snapshot the escrow agent receives. Without that, the escrow has stale prompts and the reconstitution fails.
What if the vendor refuses to escrow weights?
Treat the refusal as a procurement signal. Vendors confident in their continuity escrow weights; vendors that refuse are flagging that the artifact is not theirs to escrow (they license it from upstream) or that they prefer the buyer’s switching cost remain high. Either is a vendor-risk red flag worth pricing into the contract.
Key takeaways
AI escrow converts deep vendor exposure into shallow vendor exposure. The buyer continues to operate against the vendor’s production system, but the artifacts that would otherwise be lost on vendor failure are held by a neutral third party and released on documented triggers.
Four artifacts make the package: model weights, prompt registry, eval test set, fine-tune scripts plus training data. A neutral third-party agent holds them, with five enforceability clauses (specific releases, no-injunction, audited refresh, perpetual license, export compliance).
Refresh quarterly at minimum, monthly for high-velocity workloads. Verify integrity each cycle. Run an annual release-event drill; the only test that proves the escrow is real rather than decorative.
Escrow applies to AI vendors with deep workload exposure (fine-tuned models, agent platforms, RAG infrastructure). It does not apply to frontier API providers; for those, manage vendor risk through multi-provider redundancy. The cost is small relative to the workload value protected; the failure mode is under-investment in buyer-side maintenance, not the escrow fee.
Arthur Wandzel
