The €18m Amadeus fine wasn't a hack. It was a company reusing data it already held.

What happened

In May 2026 Spain's data protection authority, the AEPD, published its decision against Amadeus IT Group. That's the booking platform behind a large share of the world's airline and hotel reservations.

The fine was €18 million, split down the middle.

€9 million for processing without a lawful basis under Article 6, and €9 million for not telling the people concerned, under Article 14.

Amadeus paid a reduced amount under early-settlement rules and didn't admit liability.

Nobody broke in.

Between 2021 and 2022 Amadeus ran a pilot.

It took traveller booking records it already held (the Passenger Name Records) and reused them to build travel-history profiles.

Those profiles then went out to hotel-chain partners, who used them for personalisation and for spotting trends in who was travelling where, and when.

The travellers had never been told.

Amadeus couldn't point to a lawful basis for the new use. Its "legitimate interest" argument was rejected. Profiling people for hotel partners isn't something you'd reasonably expect when you book a flight.

Two further findings sharpen the point.

Amadeus hadn't run the compatibility assessment that Article 6(4) asks for before you use data for a new purpose. And it kept the data longer than its own retention rules allowed.

Why this case matters more than a breach would

Most data-protection stories that reach a boardroom are about attackers.

This one is about a business decision, and that's exactly why it deserves a DPO's attention.

Think of it like lending a friend your car keys so they can move it off the drive, then finding out they've been running a taxi service with it.

The keys were handed over legitimately. What happened next wasn't what anyone agreed to.

Amadeus held the data lawfully.

A commercial opportunity arrived. A partner insight here, a personalisation pilot there. The data was put to work for it.

That sequence is ordinary.

It's how analytics programmes, partner deals, AI pilots and data products start in most companies.

The regulator's objection wasn't that the data existed, or that Amadeus was careless with security.

It was that real, identifiable people were profiled and passed to third parties for a purpose they hadn't been told about and that no lawful basis supported.

So if your organisation shares data with partners, with vendors, with analytics providers or with any of the AI tools that have arrived in the last two years, this case asks you one simple question.

When the data leaves for a new purpose, what does the recipient actually hold?

What a safeguard can change

Replacing unnecessary identifying fields can reduce direct exposure in a shared copy. Whether that copy still identifies someone depends on the remaining detail and the recipient’s means.

Article 6(4) includes safeguards such as pseudonymisation among the factors in a compatibility assessment. It does not supply a lawful basis or a transparency notice.

What to take from it this week

First, list the feeds that leave for a purpose other than the one the data was collected for. Partner insights. Personalisation pilots. Analytics vendors, AI tools, test environments.

Most organisations find more than they expected!

Second, for each one, ask what the recipient holds. Which identifying details are necessary, and what could still be inferred after substitution?

Third, write the compatibility assessment down and name the safeguards you applied.

If pseudonymisation is one of them, say so, with a note in your own file that the data remains personal data in your hands.

And fourth, tell people.

No technical control replaces Article 13 and 14.

Synthaveil can help prepare selected identifying fields for step two. Review the output, and keep the purpose and permission decisions alongside it.