Spirit data sale: an AI privacy lesson

Retrospective covering 18 August 2026, written on 9 September 2026. The transaction status below describes that date.

The Spirit data sale shows why an AI training proposal needs scrutiny at the level of actual records, relationships and permitted uses. My practical recommendation for UK businesses is to require an export approval pack before any large internal dataset is repurposed, even when somebody describes it as de-identified.

On 18 August, Reuters reported that a hearing on Google's proposed $10 million purchase of Spirit Airlines' internal business data had been postponed to 9 September after a union objection. This was a proposed transaction awaiting approval, not evidence that Google had already received the records. Reuters' report.

What made this proposal significant

The auction filing identifies Google as the successful bidder for the de-identified data. Its asset schedule covers operational material rather than a simple public-document collection. That is the important distinction for an IT leader: the proposed value sits inside the working records of a business. Original auction filing, filed 14 August.

The Association of Flight Attendants-CWA said its objection concerned employee information and links preserved across datasets. It challenged whether confidentiality and identification risks had been adequately addressed. Its statement also explicitly said that the data had not been handed over. These are the union's concerns, not a finding by this article that re-identification occurred. AFA-CWA's 18 August statement.

For a UK SME, the immediate question is not whether it might conduct a similar sale. It is whether the organisation can describe what sits in its own proposed AI inputs well enough to make an informed approval decision.

Keep anonymity and confidentiality separate

The ICO explains that pseudonymisation and anonymisation are different. Information that can still be attributed to someone using additional information remains personal data; removing obvious identifiers does not automatically settle the question. Its guidance should inform a UK assessment, while recognising that a US bankruptcy proceeding has its own legal context. ICO introduction to anonymisation.

Confidentiality is another question. In a hypothetical supplier negotiation archive, replacing names would not by itself remove a commercially sensitive pricing strategy. My recommendation is to review the proposed release against both concerns, rather than allowing a privacy label to stand in for the entire assessment.

Use your data governance strategy to identify who is responsible for making these decisions. IT should be able to describe the export precisely; it should not have to invent the commercial purpose or the permissions behind it.

Create a data release approval pack

I would require a short, reviewable pack with the following sections before an export is authorised:

The pack should refer to an actual sample and inventory, not just a slide describing a future cleaning exercise. If the intended dataset keeps changing, treat that as a change to the approval scope.

Ask reviewers to distinguish essential fields from material included merely because it is easy to export. For example, an evaluation of ticket classification might need issue categories and redacted descriptions. The proposer should explain why any additional attachments or conversation history are necessary. This is a suggested scoping discipline, not a claim that any specific extraction is lawful.

Examine relationships across systems

A record can look innocuous in isolation while becoming more revealing in context. The ICO's assessment guidance specifically addresses linkability and additional information. That makes a dataset-by-dataset review incomplete if the proposed recipient will be able to join the records together. ICO guidance on effective anonymisation.

For the approval workshop, ask the technical team to draw the intended joins: a ticket to a user, a user to a department, a document to a project, and a project to a customer. Then ask which of those relationships the training or analysis genuinely needs.

Use invented examples when exploring the review process with a wider group. Do not circulate real sensitive records simply to demonstrate that the proposed dataset may contain sensitive records. Keep the evidence required for the decision with people authorised to inspect it.

Review the recipient's continuing rights

A useful supplier conversation goes beyond asking whether the provider trains a model. Ask what happens to the original export, transformed copies, evaluation sets, logs and any derived artefacts. Request precise contractual answers about permitted purposes, onward access, retention, exit and what happens after a change of ownership.

These are questions for a joint commercial, technical and legal review. A vague assurance that the data will be "used responsibly" does not tell the service owner what they can enforce or how they will verify it. The ICT supplier risk guide explains how to retain evidence and allocate responsibility without creating an unmanageable questionnaire.

Keep the organisation's own obligations in view too. The approval pack should identify whether existing commitments to employees, customers or counterparties need specialist review. A supplier's willingness to accept data is not a substitute for the business deciding it can provide it.

Make the decision inspectable afterwards

Retain the approved scope, the decision-maker, the version of the export process, the release date and the evidence of what was transferred. Where release is declined, record the missing evidence or unacceptable condition rather than leaving an ambiguous verbal refusal.

For a business with limited internal privacy expertise, the outsourced DPO guide helps clarify how specialist support can fit into that decision. The immediate management task is to make sure somebody owns it.

The useful lesson from this story is that ordinary business records can become the subject of consequential AI proposals. IT leaders should be ready to describe those records, challenge the requested scope, and produce an approval trail that survives more than the enthusiasm of the original project meeting.