If our AI vendor goes bankrupt, can our data be sold?

Data held by the company is generally property of the estate and can be sold, subject to limits. The most important limit in practice comes from the promises the company itself made — privacy policies and contracts that restrict transfer can constrain what a buyer may do with the data, and regulators have historically paid close attention to data sales that contradict the representations under which the data was collected.

Who owns a model fine-tuned on our proprietary data?

Whoever the contract says, which is usually the vendor unless you negotiated otherwise. This is the term most customers never check. You may own your input data and still have no rights at all in the resulting weights, meaning the artifact your data created can be sold to a stranger while you retain only the raw material you supplied.

Does a data export feature protect us?

Only if you use it on a schedule. An export button is worthless during an abrupt shutdown, because service access frequently ends before or alongside the announcement. The protection is a routine export you already have, in a format you have confirmed you can actually load somewhere else.

Is source code escrow useful for AI products?

Less than people expect. Application code without the weights, training data, infrastructure configuration and the third-party model access it depends on may not be runnable at all. If you pursue escrow for an AI system, the deposit needs to specify the artifacts that actually make it work, and someone should verify the deposit rather than trusting the certificate.

Can a buyer in bankruptcy ignore the old privacy policy?

Not freely. Where the collecting company promised not to transfer data, that promise is a well-recognized constraint on the sale, and courts have appointed independent examiners to evaluate consumer privacy issues in data sales. Buyers who intend to use acquired data differently typically need to obtain fresh consent rather than simply inheriting the old relationship.

What contract terms actually help before a vendor fails?

A defined deletion and return obligation on termination, an explicit statement of who owns derived artifacts including embeddings and fine-tuned weights, a transfer restriction that survives assignment, a commitment to a wind-down window with continued export access, and contractual clarity that your data is not an asset the vendor may sell. Each is far easier to obtain at renewal than at the filing.

When Your AI Vendor Goes Bankrupt: Who Owns Your Data and the Model Trained On It (2026)

A Failure Mode Nobody Underwrote

Vendor risk reviews are built around breach and downtime. They ask how a supplier protects data and how quickly it recovers from an outage. Almost none of them ask the question that matters most for an unprofitable AI startup burning capital: what happens to everything you gave it if the company simply stops.

This is not an exotic scenario. A wave of AI companies raised on the expectation of rapid growth, and a meaningful share of them will wind down, sell for parts, or be acquired by someone with different intentions for the customer base. In every one of those outcomes, the same underlying question arises: what did the company have, and who gets it?

Four Distinct Things You Think of as "Our Data"

The word "data" hides several separate assets with separate ownership answers, and conflating them is where customers get surprised.

Your raw input: documents, records, transcripts. Contracts usually confirm you own this, and it is the piece customers assume the whole question is about.
Derived artifacts: embeddings, indexes, extracted entities, enriched records. These are generated by the vendor from your content, and ownership is frequently unaddressed or assigned to the vendor by default.
Fine-tuned weights: a model shaped by your proprietary corpus. Almost always vendor property under standard terms, which means the most valuable thing your data produced is not yours.
Usage and behavioral records: prompts, interactions, corrections and feedback. Often the most commercially interesting dataset in the company and the one least discussed in the contract.

Read the ownership clause in your AI vendor agreements and check whether it says anything at all about embeddings, indexes or fine-tuned models. In most contracts the clause covers "Customer Data" and stops. Silence there is not neutral — it leaves the artifacts your data created outside anything you own.

What Actually Constrains a Sale

The most effective brake on the transfer of personal information in an insolvency has historically been the failing company's own promises. Where a business collected data under a policy saying it would never sell or transfer that information, that representation limits what the estate can do with it, and consumer protection regulators have intervened when proposed sales contradicted the terms under which data was gathered. Some proceedings have appointed an independent privacy examiner precisely to evaluate this.

Modern privacy statutes add another layer. Where a transfer to a new controller falls outside the purposes disclosed at collection, notice and sometimes fresh consent are required, and individual deletion rights persist against whoever holds the data. That creates the practical result that a buyer acquiring a dataset may acquire a set of obligations along with it — which is one reason sophisticated buyers sometimes prefer not to take the data at all.

A separate wrinkle applies to models. If a fine-tuned model was trained on personal data and an individual exercises a deletion right, removing the record from a database does not remove its influence on weights. Regulators have shown willingness to order deletion of models built from improperly obtained data. A prospective buyer of a failed AI company's model assets inherits that question, and it is a genuine reason a distressed model asset may be worth much less than its builders assumed.

Contract Terms That Survive, and Terms That Do Not

Customers often comfort themselves with a service level agreement or an uptime commitment. Those are claims against an insolvent entity, which means they are close to worthless when it matters. The provisions that carry weight in a wind-down are the ones that define what the vendor may do with property, not the ones that promise performance.

Ownership of derived artifacts. Name embeddings, indexes, fine-tuned weights and evaluation datasets explicitly. If you cannot get ownership, get a perpetual license triggered by termination.
A transfer restriction that survives assignment. A term stating your data may not be sold or transferred except to a successor bound by identical obligations does real work in a sale process.
A defined wind-down window. A commitment to maintain export access for a stated period after any termination, including termination for insolvency, converts a scramble into a procedure.
Deletion and certification on termination. A concrete obligation to delete and certify — with derived artifacts named — gives you something to point at, and gives an estate a reason not to treat the data as salable.
Escrow specified for AI, if at all. If you use escrow, deposit the artifacts that make the system run, and verify the deposit once. Code alone typically will not reproduce an AI product.

The Operational Half Matters More Than the Legal Half

Everything above improves your position in a negotiation you may never get to have. What reliably protects you is the boring operational discipline of not depending on a single fragile supplier for something you cannot reconstruct.

Export on a schedule, not on an intention. Confirm at least once that the export actually loads into something else.
Keep the inputs, not just the outputs. If you retain the source corpus, a fine-tune can be rebuilt elsewhere. If you only have the vendor's processed version, you may have nothing.
Watch the signals — support degradation, a stalled roadmap, sudden pricing changes, departures on the engineering team, a pivot in public messaging. Distress is visible before it is announced.
Know your switching cost in advance. The worst time to discover that a migration is a six-month project is the week the shutdown email arrives.

If You Are the Vendor

The same analysis runs from the other side, and it has a live consequence: enterprise buyers increasingly ask these questions during procurement. A vendor who can answer them crisply — here is what you own, here is our wind-down commitment, here is how export works, here is what we do with derived artifacts — converts a category of objection into a differentiator.

There is also a consistency obligation. If your marketing says customer data is never used to train shared models and your terms permit it, that gap is a misrepresentation risk today and a constraint on your own optionality later. The promises you publish travel with the data.

Frequently Asked Questions

Our vendor was acquired, not liquidated. Does any of this apply?

Much of it does. An acquisition can change the purposes for which data is processed, the subprocessors involved, and the retention posture, and where the new use falls outside what was disclosed at collection, notice or consent obligations can attach. Acquisitions also frequently end products, which raises the same export and continuity problems as a failure with a friendlier press release.

We're on a free tier. Does that change anything?

It usually weakens your position considerably. Free-tier terms tend to include broad data usage rights, minimal commitments on availability or export, and no meaningful obligations on termination. If data you would miss lives in a free product, the exposure is greater than the price suggests.

Can we just demand deletion when we hear about the filing?

You can, and applicable privacy rights may support it for personal data, but expect friction. An estate in wind-down often has minimal staffing, and requests can go unanswered. Rights you exercise before there is a crisis are dramatically more likely to be honored.

How do we assess vendor financial stability without inside information?

Ask directly during procurement — funding stage, runway, profitability posture — and note how the answer is given. Beyond that, observable signals matter: hiring or shrinking, release cadence, support responsiveness, pricing behavior and whether the company still talks about the product you bought. None of it is conclusive; collectively it is informative.

Does a data processing agreement solve this?

A DPA governs processing on your instructions and typically includes deletion or return on termination, which is genuinely useful. It rarely settles ownership of derived artifacts, and it does not by itself keep a dataset out of an estate. Treat it as one necessary component rather than the answer.

Is any of this worth the effort for a small tool we pay a little for?

Scale the response to what you would lose. For a tool holding replaceable data, a periodic export is sufficient. For a system holding your customer records, your document corpus or the model your operations depend on, the contract terms deserve real attention at the next renewal — which is the only moment you have leverage.

What Does Your Site Promise About Customer Data?

If you sell AI software, the statements on your site about data ownership, training use and retention are the promises that will constrain what your company can ever do with that data — including in a sale. Most teams have never compared those pages against their actual terms.

Pull the full picture in one pass. Run a free scan and review every page that makes a data handling or ownership claim.

Your AI Vendor's Creditors Have a Claim on the Model You Trained