When Amadeus IT Group repurposed booking data for a traveller profiling pilot, they triggered an €18 million fine from Spain's supervisory authority. The breaches weren't unusual; they were fundamental errors in how organizations approach data reuse. These mistakes are surprisingly common across industries.
Why These Mistakes Keep Happening
Data reuse projects often sit at a risky intersection. Your commercial teams see valuable data already in-house and want to extract new insights. Your legal team knows GDPR applies but treats the project as an incremental change rather than new processing. Your engineering team builds the pilot quickly because "it's just internal." Nobody stops to map the compliance obligations from first principles.
The result: organizations process data they already hold under a new purpose without recognizing they've crossed into controller territory, triggered new transparency obligations, and invalidated their original lawful basis. The Amadeus enforcement demonstrates what happens when these assumptions go unchecked.
Mistake 1: Treating Pilots as Compliance-Light
Why it happens: Teams rationalize that pilots are temporary, small-scale, or "just testing," so full compliance processes feel disproportionate. You want to move fast and validate the concept before investing in legal review.
The consequence: The AEPD rejected Amadeus's pilot framing entirely. The processing involved real personal data at scale, across millions of travelers, for a materially different purpose. A "pilot" label doesn't reduce your Article 6 or Article 14 obligations. If you're processing real data, you're subject to real compliance requirements.
The fix: Apply full compliance processes before any pilot that uses real personal data. If you need speed, use synthetic or anonymized data for proof-of-concept work. Once you're confident in the technical approach, pause and complete your compatibility assessment, legitimate interests assessment, and data protection impact assessment before switching to real data. Document the decision: if you're choosing to proceed with a compliance gap for a genuine pilot (e.g., processing 100 records for 48 hours), record the risk acceptance and mitigations explicitly.
Mistake 2: Relying on Vague Privacy Notice Language
Why it happens: Your existing privacy notice includes broad phrases like "analytics," "product improvement," or "business purposes." Legal teams assume this language covers future processing activities that fall within those categories.
The consequence: The AEPD found Amadeus's broad privacy policy language insufficient for the specific, complex further processing involved in the pilot. Generic references to analytics don't inform data subjects about profiling for hyper-personalized marketing. Without specific notice, travelers couldn't exercise their rights or form reasonable expectations about how their booking data would be used.
The fix: Draft purpose-specific transparency language for each new processing activity. Your notice should answer: What new thing are you doing with the data? Why? Who will receive it? How does this differ from the original purpose? If the new processing is materially different (profiling vs. booking administration), update your privacy notice before processing begins and communicate the change to affected data subjects where feasible.
Mistake 3: Skipping the Compatibility Assessment
Why it happens: Teams conflate "we already have the data" with "we can use it however we want." If you collected data under one lawful basis for one purpose, the assumption is you don't need a new basis for a related use.
The consequence: Article 6(4) requires a compatibility assessment when you process personal data for a purpose other than the one for which it was collected. Amadeus collected Passenger Name Record data for travel bookings but repurposed it for profiling and targeted marketing. The AEPD found no evidence of a compatibility assessment, which meant Amadeus couldn't demonstrate the new purpose was compatible with the original one.
The fix: Conduct a formal compatibility assessment using the Article 6(4) factors: the link between the original and new purposes, the context in which you collected the data, the nature of the personal data, the possible consequences for data subjects, and your safeguards. Document your reasoning. If the new purpose isn't compatible, you need a fresh lawful basis (consent or legitimate interests) and must meet full transparency obligations as if you were collecting the data for the first time.
Mistake 4: Misidentifying Your Controller Status
Why it happens: If you originally received the data as a processor (processing on behalf of clients), it's easy to assume you remain a processor when you reuse that data. Your contracts say "processor," your systems label you as processor, so the new project must also be processor activity.
The consequence: When you reuse customer data for your own purposes (developing your own product, generating insights for your business), you're acting as a controller for that processing, even if you're still a processor for the original purpose. Amadeus received traveler data through airlines and travel agencies but repurposed it for its own pilot. That made Amadeus a controller for the pilot, with full controller obligations, regardless of its processor role in the booking flow.
The fix: Map your role for each distinct processing purpose. If you're using data to deliver a service your client requested, you're likely a processor. If you're using the same data to build your own product, train your models, or generate commercial insights, you're a controller for that activity. Update your contracts to reflect dual roles where necessary, and ensure you have contractual permission to use client data for your own purposes. Implement the appropriate governance: processor activities need client instructions and data processing agreements; controller activities need your own lawful basis, transparency obligations, and risk assessments.
Mistake 5: Ignoring the Communication Challenge
Why it happens: You have no direct relationship with the data subjects. You received their data through intermediaries (in Amadeus's case, airlines and travel agencies). Communicating directly with millions of travelers feels impractical or impossible, so teams assume the transparency obligation doesn't apply or can be met through the intermediary's notice.
The consequence: Article 14 requires you to provide information to data subjects even when you didn't collect the data directly from them. The AEPD found that Amadeus failed to provide the required information about the pilot's processing. Relying on intermediaries to communicate on your behalf only works if you've contractually obligated them to do so and verified they've complied.
The fix: Plan your communication strategy before processing begins. Options include: direct communication (email, in-app messaging) if you can identify data subjects; contractual obligations on your data sources (airlines, agencies) to include your processing in their privacy notices; prominent website notices if data subjects can reasonably be expected to visit your site; or, in limited cases, demonstrating that providing the information would involve disproportionate effort (Article 14(5)(b)) and implementing alternative safeguards. Document which approach you're using and why. If you're relying on intermediaries, get written confirmation they've updated their notices and shown them to data subjects.
Prevention Checklist
Before launching any data reuse project:
- Identify your role (controller, processor, or joint controller) for the new processing activity
- Complete a compatibility assessment if reusing data for a new purpose
- Conduct a legitimate interests assessment if relying on Article 6(1)(f)
- Draft specific, purpose-focused transparency language (don't rely on existing broad terms)
- Determine how you'll communicate the new processing to data subjects, especially if you have no direct relationship
- Update contracts to reflect your controller status and secure permission to reuse data
- Complete a data protection impact assessment for innovative uses or large-scale profiling
- Verify you're not exceeding retention periods set by sector-specific regulations
- Document all assessments and decisions before processing begins
- If running a pilot, confirm you're using synthetic data or apply full compliance as if it were production
The Amadeus case isn't about exotic technology or novel legal theories. It's about organizations failing to apply established GDPR principles to data they already hold. Your next product feature, analytics project, or AI training run could trigger the same violations if you treat data reuse as a technical decision rather than a compliance reset.
