Synthetic Data for Testing AI Agents Without Exposing Customers

Synthetic Data for Testing AI Agents Without Exposing Customers

To test a chatbot without exposing customers, create fictional records and conversations that mimic the structure, the mess and the hard cases of real support, but contain no actual person. The path is to list the situations the agent faces, generate invented data under clear rules, and label every record as synthetic. That lets your team evaluate and approve the agent in a repeatable way while real data stays out of the test environment.

Key takeaways

• Good synthetic data copies the format and difficulty of real support, not anyone's identity.
• Start with a map of the situations in your process (orders, questions, complaints, exceptions) and only then generate records.
• Fictional customer records need consistency rules: dates, statuses, values and history that make sense together.
• Every test record should be identifiable as fictional, so it is never mistaken for a real customer or sent a real message.
• Before approving the agent, check that the set carries no hidden real data, such as snippets copied from old conversations.

Why not use real customer conversations in testing?

The fastest way to build an evaluation set is to export your WhatsApp history and use it as is. It is also the riskiest. A real conversation contains a name, phone number, address, ID document, a photo of a payment receipt and, often, sensitive details the customer mentioned without thinking, such as a health problem that explains a delay.

Under LGPD (Brazil's data protection law), that data was collected for a purpose, usually customer support. Reusing it to train, evaluate or demonstrate a system is a different use, and it needs a legal basis and transparency toward the data subject. Even when the company believes it has that basis, testing usually involves more people and more tools than the original support did: developers, vendors, evaluation platforms and, often, a language model provider outside Brazil. It is worth reading how international data transfer works with AI providers and what LGPD requires before sending any real conversation to an external service.

There is also a practical reason: real data is poor test material. It is unbalanced (many easy questions, few rare cases), hard to reproduce, and it changes every time someone updates the database. Synthetic data lets you manufacture exactly the cases that rarely show up but do the most damage when the agent gets them wrong.

What does a synthetic dataset for a chatbot need?

A good set has three layers, and each answers a different question.

• Records: who the fictional customer is, what they bought, and the status of the order, contract or support case.
• Conversations: how that customer writes, with abbreviations, transcribed voice notes, typos and messages split into fragments.
• Answer keys: what the agent should do in each case (answer, ask a question, refuse or hand off to a person) and which information must never appear.

The third layer is the one most often forgotten. Without an answer key, you have a pile of nicely written text and no way to say whether the agent passed or failed. The evaluation guides published by AI vendors such as OpenAI and Anthropic are built on exactly this idea: test cases with success criteria defined in advance, run repeatedly.

How do you create realistic fictional customer records, step by step?

The plan below works for any support agent, whether it handles orders, scheduling, after-sales or technical support. The order matters.

• Step one: map the process. List the types of requests that arrive, the systems the agent consults (ERP, CRM, calendar, spreadsheet) and the fields it reads or changes.
• Step two: define the record schema. Use the same fields and formats as the real system, including the badly filled fields that exist in real life, such as an empty address line or a phone number without an area code.
• Step three: create customer profiles, not people. For example: a repeat customer with a long history, a new customer with no history, a customer with two duplicate records, a customer with an overdue payment, a customer writing on behalf of someone else.
• Step four: generate identifiers with safe rules. Use email addresses on domains reserved for examples, such as example.com, and phone numbers from a range your team controls or from a provider's sandbox number, never randomly drawn numbers that could belong to someone.
• Step five: handle tax IDs (CPF and CNPJ) with care. Documents with valid check digits can coincide with those of real people. When the test does not depend on validation, use a clearly fictional pattern. When it does, use a test document generator and record that the list is synthetic.
• Step six: ensure internal consistency. Purchase date before complaint date, order value consistent with the items, status compatible with the history. Pointless inconsistency makes the agent fail for reasons that do not exist in the real world.
• Step seven: label everything as fictional. A source field, a name prefix or a tag on the record is enough, as long as any person or system can tell test from production.
• Step eight: separate the environments. The synthetic records live in a staging environment with its own credentials, no access to the real database and no outbound channel to real customers.

One note on names: avoid combining a common first and last name with a city and profession that are too specific, because the result may by chance describe an existing person. Mix the parts deliberately and prefer generic profiles.

How do you write fictional conversations that look like real WhatsApp?

The most common mistake is generating polite, complete dialogues in which the customer explains everything in the first message. Nobody writes like that. The test set needs to reflect how the channel is actually used.

• Short messages broken into several parts, with the key information in the third message.
• Typos, abbreviations and missing accents.
• Transcribed voice notes, with hesitations and sentences that never end.
• Photos and documents described in text when the test does not need the image.
• Topic changes mid-conversation and questions from customers who have already changed their mind.
• Out-of-scope requests, attempts to obtain another customer's data and aggressive messages.

An efficient way to produce this volume is to ask a language model to generate variations from scenarios you wrote, never giving it real conversations as examples. Review a sample by hand: models tend to produce text that is too clean and to repeat the same names. If you need to keep the whole process inside the company, a local model, as in the Ollama case, can generate the variations without sending anything outside.

Include edge cases in a deliberate proportion: the customer who asks for a discount nobody authorized, the one who tries to make the agent ignore its rules, the one who asks for third-party data. The OWASP list of prompt injection attacks is a good source of ideas for these scenarios.

Illustrative scenario: approving an after-sales agent

Imagine, as an invented example, a store that sells home appliances and wants a WhatsApp agent to report delivery status and open exchange requests. The agent queries an order system and may only open an exchange when the order is within the policy window.

The team defines five fictional profiles: a buyer with a delivery in progress, a buyer with a late delivery, a buyer past the exchange window, a buyer writing on behalf of their mother, and a buyer with two orders mixed up. For each profile, they create the record and the order in the staging environment, with an email on an example domain and a sandbox phone number.

Then they write three or four conversations per profile, with fragmented messages and one pressure case (the customer insists on an exchange after the deadline). The answer key says: in the past-the-window case, the agent does not open the exchange and hands off to a person with a summary. In the case of the buyer writing for their mother, the agent does not reveal order data without confirming identity.

The test result is not a single score. It is a list of failures by type: answered wrongly, acted without permission, failed to hand off, leaked a field. That list guides adjustments to the prompt, the rules and the agent's input and output controls.

How do you make sure the synthetic set contains no real data?

Synthetic data can fail in two ways: it can be too unrealistic to teach anything, or too real and carry an actual person. The second is the one that creates legal problems. LGPD treats data as anonymized, and therefore outside its scope, only when anonymization is truly irreversible with reasonable means. Swapping a name for a nickname and keeping the rest is not anonymization, it is pseudonymization, and the data remains personal. For official guidance, consult the ANPD, Brazil's data protection authority.

Use this checklist before releasing the set to your team and vendors:

• No record was copied from a customer conversation, email or spreadsheet, even with partial editing.
• The examples used to generate variations were also invented.
• Phone numbers and emails do not belong to real people and cannot send messages outside.
• Documents and addresses are fictional or come from identified test lists.
• Test photos, receipts and PDFs were created from scratch, without metadata from real files.
• A responsible person reviewed a sample and recorded the date and the criteria of the review.
• The staging environment has no credential with access to the production database.

If some case can only be reproduced with real data, treat it as an exception: the smallest possible excerpt, restricted access, a recorded purpose and deletion after the test. Whoever monitors the use of AI tools on the team should also make sure this does not turn into surveillance of people, as we discuss in measuring AI productivity without surveillance.

How does the map, limit, pilot and hand over method apply?

Synthetic data fits into each stage of the method without requiring anything special.

Map: the current process becomes the list of situations and the record schema. Without that map, the test set reflects what the team imagines, not what actually happens.

Limit: the staging agent receives only fictional data and minimal permissions. What it can read and do in the test is what you intend to allow in operation.

Pilot: the synthetic set serves as the basis for repeated evaluations before and during the pilot. When the pilot starts with a real flow, records and agreed metrics are tracked with logs. To structure this, see how to measure an AI automation pilot.

Hand over: at delivery, the set of cases, the answer keys and the rule for creating new records stay with the client's team, so they can re-evaluate the agent after each change of rule, product or model. The final decision is to expand, adjust or stop, based on the failures the tests revealed.

Frequently asked questions

Is synthetic data as good as real data for testing a chatbot? For most behavior tests, yes, as long as it reproduces the format, the mess and the hard cases of real support. It is even better for rare cases, because you can create them on demand. What synthetic data does not show is the real distribution of questions, so it is worth complementing it with observation during the pilot, using data handled in line with LGPD.

Can I use a language model to generate the fictional conversations? Yes, and it is a common way to gain volume. Give it scenarios and rules that you wrote, not real conversations, and review a sample to avoid text that is too clean and repeated names. If company policy restricts sending data outside, use a local model.

Is a randomly generated tax ID or phone number safe to use? Not always. A number with a valid format can belong to a real person, and a randomly drawn phone number can receive a real message. Prefer email domains reserved for examples, sandbox numbers and clearly fictional identifiers, and only use valid documents when the test depends on validation.

When should I update the test set? Whenever a business rule, a product, a handoff flow or the model used by the agent changes. It is also worth adding a new case for each failure found in operation, turning the real error into an equivalent fictional scenario without copying the original conversation.

Sources

• OpenAI: guia de evals
• Anthropic: Demystifying evals for AI agents
• OWASP Top 10 for LLM Applications
• ANPD: Autoridade Nacional de Proteção de Dados