· 8 min read

Google Paid $10 Million for a Dead Airline's Internal Data. Your Own Privacy Policy Already Says This Can Happen to Your Users.

Google won a bankruptcy auction for the data assets of Spirit Aviation Holdings with a $10 million bid, beating AI recruiting firm Mercor.io, which bid $7.5 million. The haul includes roughly 100 million emails, about 500 million Microsoft Teams chats and collaboration records, pricing from 7.2 billion competitor flights, and an estimated 7.5 billion passenger transaction records going back to 2008. Google says it will use the material to improve its AI.

This is worth twenty minutes of your attention, and not for the reason most of the coverage suggests. The lesson is not about Google. It is that insolvency is a mechanism by which data changes hands, it is fully legal, and the clause enabling it is almost certainly in the privacy policy you shipped.

What was and wasn't in the sale

Credit where it is due on the privacy side, because this matters for how alarmed to be.

The purchase excludes personal data and privileged materials, specifically Spirit's 97.5 million passenger profiles and an estimated 50.2 million Free Spirit loyalty program records. Reporting also states that everything transferred to Google will be scrubbed of personally identifiable information by a third party before Google receives it.

So this is not a case of a bankrupt company selling its customer list to the highest bidder. It is a case of operational exhaust, internal email, chat, pricing history, audit and fraud records, revenue and aircraft operations data, being valued as AI training material and sold as an asset.

That is a genuinely new category of thing to think about. Your Slack history is not something most founders have ever priced. Somebody just did.

The clause you already agreed to

Open your own privacy policy. Search for "merger." You will find a sentence close to this one:

In the event of a merger, acquisition, reorganization, bankruptcy, or sale of all or a portion of our assets, your information may be transferred as part of that transaction.

That clause is in nearly every privacy policy template in circulation, including the generators most solo operators use. I have it in mine. It exists because without it an acquisition of a software business would be legally impossible, since the customer relationships are most of what is being bought.

It is also the clause that turns "we will never sell your data" into a statement with a large asterisk. You will not sell it. A trustee acting on behalf of your creditors might, and they have a fiduciary duty to get a good price.

I am not arguing you should remove the clause. Remove it and you have made your own business unsellable, which is a worse outcome for you and arguably for your users, since the alternative to acquisition is usually shutdown. I am arguing you should know it is there and be able to say what it covers.

The version of this that will actually bite you

Flip the direction. You are not Spirit in this story, you are a Spirit customer.

Count the vendors currently holding data you would struggle to reconstruct. For me that is analytics, email delivery, a payment processor, a form backend, an error tracker, and object storage. Six companies. Two of them are venture-funded startups with no visible path to profitability, which is not a criticism, it is just what the category looks like right now.

If one of those dies, what happens is not a polite export window. In an actual insolvency the service usually stops answering before the wind-down email goes out, because keeping servers running costs money the estate does not want to spend. The data becomes an asset, and assets get sold or sit frozen in a proceeding for months.

Terms of service almost never protect you here. A promise to provide export tooling is an unsecured contractual obligation, which is close to the bottom of the creditor stack.

What I'd actually do

Three things, in descending order of how much they matter.

First, run an export of anything you cannot rebuild, on a schedule, to storage you control. Not a manual export you did once during onboarding. A cron job or a scheduled task, output to a bucket you own, with a retention policy. For most of my vendors this is a single API call and a script that takes under an hour to write. If a vendor has no export API at all, that is the finding, and it should change how much you put in there.

Second, read your own assets clause and decide whether you can defend it. Not remove it, defend it. If a user emailed and asked "what happens to my data if you go bankrupt," could you answer in three honest sentences? If not, write those three sentences into your policy now, while it costs nothing.

Third, sort your vendor list by how bad the loss would be, not by how much you pay. The $9-a-month form backend holding four years of customer submissions ranks above the $200-a-month service you could swap in a day. Price and criticality are close to uncorrelated, and the cheap tools are usually the ones with the shakiest business models.

Where I might be wrong

The strongest counter-argument is that this is a rare event dressed up as a systemic risk. Most SaaS vendors do not die abruptly. They get acquired, deprecate slowly, or limp along for years, and in nearly all of those paths you get plenty of warning and a working export button. Spending real time on bankruptcy contingencies for a six-vendor stack could easily be time better spent on the product.

I think that is broadly right, which is why my recommendation tops out at "write an export script" rather than anything more elaborate. The scheduled export is worth doing regardless because it also covers the boring failure modes: an account lockout, a billing dispute, a mistaken deletion, a vendor pivoting away from your use case. Bankruptcy is just the version of that story with a headline attached.

The part I am confident about is narrower: the assets clause is real, you agreed to it on both sides, and a $10 million cheque for a dead company's Teams history is a reasonable prompt to go read it.

Author

Sources

Stay in the Loop

Get new posts delivered to your inbox. No spam, unsubscribe anytime.

Newsletter coming soon. Set PUBLIC_CONVERTKIT_FORM_ID in .env to activate.

Related Posts