Can We Run This as a Pilot? Data Reuse Edition

After the Amadeus decision hit the news, questions flooded my inbox. Legal teams alerted product managers, and compliance officers were suddenly in meetings about "that travel data thing." Everyone wanted to know: what does this mean for our pilot projects?

The questions below stem from real conversations with compliance teams, data officers, and legal counsel dealing with data reuse. If you're thinking about repurposing customer data for analytics, profiling, or new product features, you've probably asked some version of these yourself.

Understanding the Amadeus Case

The Agencia Española de Protección de Datos (AEPD) fined Amadeus IT Group €18 million for GDPR breaches related to a traveller profiling pilot. Amadeus used personal data from its Global Distribution System to create traveller profiles for hotels and travel companies. The AEPD found violations of Article 14 (information obligations) and Article 6 (lawful basis). Amadeus made a €14.4 million voluntary payment and plans to appeal.

This case is notable because it involved a pilot, not a production system, yet it affected millions of records.

Q1: Does GDPR apply to pilot projects using real data?

Yes, it does.

The AEPD didn't consider the "pilot" label as an exemption. If you're processing real personal data, GDPR applies. Article 4(2) GDPR defines processing broadly, including any operation on personal data. Running a profiling algorithm on customer records is processing. The regulation doesn't differentiate between production and pre-production when real data is involved.

If you're using synthetic data or fully anonymized datasets, your risk might be different. But with live customer records, your Article 14 obligations, lawful basis requirements, and Data Protection Impact Assessment duties apply before you start.

Q2: Our privacy notice mentions "analytics" and "product improvement." Is that enough?

Not if the new use is significantly different from what users expect.

Amadeus argued this point, but the AEPD found their privacy policy too vague for a "specific and complex further processing activity." If you're using booking data to build behavioral profiles for third-party hotels, that's a new purpose. Article 14 requires you to inform individuals about this new purpose in advance, with clear details.

Generic language doesn't meet the Article 13 or Article 14 transparency standard. Your notice must describe the actual processing, especially when there's no direct relationship with the data subjects.

Q3: We're a B2B service without direct user relationships. How do we notify them?

You need a plan before processing starts.

Article 14(1) requires you to inform data subjects even if you didn't collect the data directly. Options include:

• Contractual pass-through: Have your business customers include your processing purposes in their privacy notices.
• Direct communication: If possible, reach individuals directly through email, in-app notices, or account portals.
• Layered notice: Use your customer's touchpoints to direct users to your detailed privacy notice.

The AEPD noted that Amadeus's lack of a direct relationship with travelers worsened their transparency failure. You can't assume users will find your generic privacy policy. You need a proactive plan to inform them.

If providing Article 14 information is impossible or involves disproportionate effort, Article 14(5)(b) offers a limited exception. Document why and implement alternative safeguards, but don't rely on this as a first choice.

Q4: Can we rely on legitimate interest as a lawful basis?

It's possible, but not without careful consideration.

The AEPD rejected Amadeus's legitimate interest claim because:

• The processing wasn't within travelers' reasonable expectations.
• No direct relationship existed between Amadeus and the travelers.
• The processing lacked transparency.
• No documented balancing test showed Amadeus's interests outweighed travelers' rights.

Legitimate interest requires a three-part test: (1) a legitimate interest, (2) processing necessity, and (3) the interest doesn't override individual rights. The balancing test requires documentation. Consider the data's nature, context, individuals' expectations, and impact.

For unexpected secondary data uses, especially at scale, legitimate interest is challenging. If processing millions of records for an unanticipated purpose, your balancing test must be thorough and defensible. If you can't justify the intrusion, seek consent or another lawful basis.

Q5: Can we reuse data collected years ago for a new project?

Not without an Article 6(4) compatibility check.

If processing data for a new purpose, Article 6(4) requires a compatibility assessment. Evaluate if the new purpose aligns with the original one based on:

• The link between the original and new purposes.
• The collection context.
• The data's nature.
• Potential consequences for individuals.
• Existing safeguards.

The AEPD noted Amadeus didn't conduct this assessment. If the new purpose isn't compatible, you need a fresh lawful basis, requiring consent or another Article 6(1) ground.

Also, check retention limits. Amadeus kept Passenger Name Record data beyond Regulation (EC) No 80/2009 limits, which required offline storage within 72 hours and destruction within three years. If your original legal obligation or retention period has expired, you shouldn't still have the data.

Q6: What's the checklist before launching a data reuse pilot?

Here's what you need:

Before using the data:

1. Data Protection Impact Assessment: Required under Article 35 for high-risk processing. Document the processing's nature, scope, context, and purposes; assess necessity and proportionality; identify risks; describe mitigation measures.

2. Compatibility assessment (Article 6(4)): If processing for a new purpose, document compatibility with the original purpose or identify a new lawful basis.

3. Legitimate interests assessment: Document your interest, demonstrate necessity, and complete the balancing test. If the balance tips against you, find a different basis.

4. Updated privacy notice: Draft clear language describing the new processing purpose. Don't rely on boilerplate about "analytics."

5. Communication plan: Plan how to deliver Article 14 information to data subjects, especially without a direct relationship.

In your contracts:

6. Controller/processor clarity: Define where you act as processor (core service) and controller (developing your product/insight). Include Article 28 processor terms and controller-to-controller clauses.

7. Right to use data: Ensure your contract permits the intended reuse. If not, renegotiate or get consent.

8. Customer obligations: If your customer can notify end users, include a contractual obligation for them to do so and provide the required notice language.

During the pilot:

9. Retention limits: Don't keep data longer than necessary or beyond legal retention periods.

10. Access controls and safeguards: Implement measures proportionate to the risk.

Next Steps

For more details, see the full AEPD decision on their website. For English analysis, the linked blog post provides insights from the legal team that reviewed the decision.

For guidance on Data Protection Impact Assessments, see the Article 29 Working Party's Guidelines. For legitimate interests assessments, the ICO's guidance is a clear framework, even if you're not UK-based.

If you're unsure whether your pilot qualifies as high-risk processing, assume it does and run the DPIA. This documentation will highlight gaps before they lead to enforcement actions.