An illustrative scenario. The team building your customer-support agent asks, quite reasonably, for “a sample of real tickets to tune it”. They export two thousand conversations from the CRM, drop them in a shared folder, and the agent starts getting better. Nobody decided anything: it just happened. And that folder now holds names, addresses and incidents of people who never knew their messages would be used to test software.
The thesis in one line: testing an agent on real data isn’t a technical shortcut, it’s processing personal data with its own risk and its own owner, and you can almost always avoid it or narrow it, at a quality cost you should measure instead of ignore.
Test data for AI agents: why “just test on the real thing” already counts as processing data
Spain’s data protection authority (the AEPD) says it bluntly in its blog post on development and pre-production environments (April 2022): software tests using personal data “are, or are part of, processing of personal data”, with every GDPR obligation attached, and personal data should be avoided where possible in development, pre-production or any other test environment. It adds something uncomfortable: the risk in those environments can be as high as in production, or higher, because there are more vendors, more copies and fewer controls.
With an agent the exposure is harder to see than with a classic application. Test data doesn’t stay in a database: it travels in prompts to a third-party model, lands in observability traces, and ends up in evaluation sets that get versioned and shared. Every copy is one more place where your customers’ data exists and nobody counted it, the same problem we cover in what leaves your perimeter on every call. The underlying rule is European (the GDPR applies when you process data of people in the EU); how each national authority applies it can differ.
What are the alternatives to real data, and what does each one cost you?
There’s no free option. Each alternative protects something and costs something; choosing well means knowing which test you lose with each.
| Alternative | What it does | What you lose | When it fits |
|---|---|---|---|
| Real anonymization | Strips or transforms data until nobody can identify the person, even with extra information | The details that made the case real: the history, the thread linking one message to the next. Doing it properly is hard, and if it can be reversed it isn’t anonymization | Short, structured data; almost never long free text |
| Pseudonymization | Replaces identifiers with codes and keeps the key elsewhere | Almost no realism. But it’s still personal data: the European Data Protection Board’s Guidelines 01/2025 remind us pseudonymized data stays personal if additional information could re-identify it | When you need continuity across cases and control who holds the key |
| Synthetic data | Generates data shaped like the real thing that corresponds to no one | The oddities nobody thought to simulate: the typo, the customer who mixes two languages, the field that’s empty except on Tuesdays | Testing flow, format, permissions and integrations |
| Hand-built cases | Written by someone who knows the process, based on real patterns | Volume and surprise: you only find what you already knew to look for | Edge cases and tests that must be repeatable |
| Scoped real data | A minimal subset, with a documented decision, restricted access and a deletion date | No realism lost, but all the risk, reduced | Only when the above isn’t enough and there’s a concrete reason |
The AEPD sets out this hierarchy: synthetic data avoids processing personal data in tests in many cases, and test data derived from real data should keep the structure without containing real personal data. If that isn’t enough, it asks for a documented decision that limits the real data used as far as possible.
What can’t you test with fake data?
What breaks in production is rarely what you imagined. An agent tested only on clean data passes exams production never sets: three-line messages with no context, crooked scanned attachments, the customer who answers a different question. It’s the mechanism behind the demo that used your best cases, applied to testing.
So the answer isn’t “never real data”, it’s separating what gets tested where. Logic, formats, integrations and permissions get tested with synthetic data and hand-built cases. Quality against real-world variety gets measured later, in a shadow run where the agent reads real inputs but writes to fake destinations, as the guide on testing changes without breaking the automation explains. Careful: that copy reads real data, so it’s still processing and needs its own justification and limits.
Which practical rule prevents the problem from the start?
- Start synthetic and move up only if you must. Each step toward real data needs a written reason: which specific test you can’t run without it.
- Give the test environment test-environment permissions. Its own credentials, no access to production or real outbound sends, as covered in what permissions to give an AI agent.
- Follow the data’s route. Prompts, traces, evaluation sets and vendor copies all count. If your vendor stores your test inputs, the test environment is no longer only yours.
- Give the test set a deletion date. An evaluation set of real data that nobody reviews is an archive of personal data with no owner.
- Let a named person decide. Who approves using real data, and who checks periodically that it’s still needed.
What do you do when the vendor asks for a real sample?
It happens more than you’d think: the vendor needs to “see your cases” to configure the agent. Before sending anything, four questions, in writing:
- What exactly is it for? A sample to understand the format is not a sample to train on or to evaluate with.
- What does the vendor do with it? If it’s used to improve their own models or for anything beyond your project, it’s a different conversation.
- Where is it stored and who can access it? Country, sub-processors, retention time. It’s the core question in what your vendor won’t tell you about AI and GDPR.
- Can synthetic data solve it? Most of the time ten hand-written cases and a field schema are enough to configure; the real sample comes later, scoped, and only if needed.
When does using real data make sense?
When measuring real quality is the goal and synthetic data doesn’t represent it. Continuous evaluation on a small, scoped sample with restricted access is defensible, and it’s the kind of measurement we cover in evaluating the quality of your AI agents and in evals: without measuring, you don’t know if it works. What isn’t defensible is doing it out of habit.
In that case the AEPD asks for a necessity and proportionality analysis and security measures in line with Article 32 of the GDPR. In practice it fits on one page: why, how much data, who has access and until when. And if you must debug a failure on real data with no alternative, the same AEPD lists what applies: the controller’s authorization, a logged and audited record of that authorization and of what’s done, minimal data and access only for those who need it.
The line to take away: don’t ask whether your agent passed its tests, ask whose data it passed them with. If the answer is “the real data” and nobody decided that, you didn’t test an agent: you opened an archive.
Sources (accessed October 20, 2026): AEPD, “Brechas de datos personales: entornos de desarrollo y preproducción” (April 18, 2022, in Spanish); Regulation (EU) 2016/679, Arts. 4(5) and 32; and a summary of the EDPB Guidelines 01/2025 on pseudonymisation (adopted January 16, 2025). This is general information, not legal advice.