Cenário ilustrativo. A equipa que constrói o teu agente de apoio ao cliente pede, com toda a lógica, «uma amostra de tickets reais para o afinar». Exportam duas mil conversas do CRM, deixam-nas numa pasta partilhada e o agente começa a melhorar. Ninguém decidiu nada: aconteceu. E essa pasta tem agora nomes, moradas e ocorrências de pessoas que nunca souberam que as suas mensagens iam servir para testar software.
A tese numa linha: testar um agente com dados reais não é um atalho técnico, é um tratamento de dados pessoais com o seu risco e o seu responsável, e quase sempre pode evitar-se ou limitar-se, a troco de uma perda de qualidade que convém medir em vez de ignorar.
Dados de teste para agentes de IA: porque «testar com o real» já é tratar dados
A autoridade espanhola de proteção de dados (AEPD) di-lo sem rodeios no seu blogue sobre ambientes de desenvolvimento e pré-produção (abril de 2022): os testes de software com dados pessoais «são, ou fazem parte de, tratamentos de dados pessoais», com todas as obrigações do RGPD, e deve evitar-se, sempre que possível, usar dados pessoais em desenvolvimento, pré-produção ou qualquer outro ambiente de teste. Acrescenta algo incómodo: o risco nesses ambientes pode ser igual ou superior ao da produção, porque há mais fornecedores, mais cópias e menos controlos.
Com um agente, a exposição é mais difícil de ver do que numa aplicação clássica. Os dados de teste não ficam numa base de dados: viajam em prompts para um modelo de terceiros, ficam em registos de observabilidade e acabam em conjuntos de avaliação que se versionam e partilham. Cada cópia é mais um sítio onde os dados dos teus clientes existem sem que ninguém os tenha contado; é o mesmo problema de o que sai do teu perímetro em cada chamada. A regra de fundo é europeia; a aplicação concreta pode variar de autoridade nacional para autoridade nacional.
Que alternativas há aos dados reais e o que se perde com cada uma?
Nenhuma opção é grátis. Cada alternativa protege algo e custa algo; escolher bem é saber que teste se perde com cada uma.
| Alternativa | O que faz | O que se perde | Quando serve |
|---|---|---|---|
| Anonimizar a sério | Retira ou transforma os dados até ninguém conseguir identificar a pessoa, nem com informação adicional | Os detalhes que tornavam o caso real: o histórico, o fio que liga uma mensagem à seguinte. Fazê-lo bem é difícil, e se for reversível não é anonimização | Dados curtos e estruturados; quase nunca texto livre longo |
| Pseudonimizar | Substitui identificadores por códigos e guarda a chave à parte | Quase nenhum realismo. Mas continuam a ser dados pessoais: as diretrizes 01/2025 do Comité Europeu para a Proteção de Dados lembram que os dados pseudonimizados continuam pessoais se houver informação adicional que permita reidentificar | Quando precisas de continuidade entre casos e controlas quem tem a chave |
| Dados sintéticos | Geram-se dados com a forma dos reais, que não correspondem a ninguém | As esquisitices que ninguém pensou em simular: a gralha, o cliente que mistura dois idiomas, o campo vazio exceto às terças | Testar fluxo, formato, permissões e integrações |
| Casos construídos à mão | Escritos por quem conhece o processo, a partir de padrões reais | Volume e surpresa: só encontras o que já sabias procurar | Casos-limite e testes que têm de ser repetíveis |
| Dados reais delimitados | Um subconjunto mínimo, com decisão documentada, acesso restrito e data de eliminação | Nenhum realismo perdido, mas todo o risco, reduzido | Só quando o resto não chega e há uma razão concreta |
A AEPD recolhe esta hierarquia: os dados sintéticos evitam em muitos casos tratar dados pessoais nos testes, e os dados de teste derivados de dados reais devem manter a estrutura sem conter dados pessoais reais. Se isso não chegar, pede uma decisão documentada que limite ao máximo os dados reais usados.
O que não se pode testar com dados falsos?
O que se parte em produção raramente é o que imaginaste. Um agente testado só com dados limpos passa em exames que a produção não faz: mensagens de três linhas sem contexto, anexos digitalizados tortos, o cliente que responde a outra coisa. É o mecanismo de a demo que usava os teus melhores casos, aplicado aos testes.
Por isso a resposta não é «nunca dados reais», mas separar o que se testa onde. A lógica, os formatos, as integrações e as permissões testam-se com dados sintéticos e casos à mão. A qualidade perante a variedade real mede-se depois, numa execução em sombra em que o agente lê entradas reais mas escreve em destinos falsos, como explica o guia para testar alterações sem estragar a automatização. Atenção: essa cópia lê dados reais, por isso continua a ser um tratamento e precisa da sua própria justificação e dos seus próprios limites.
Que regra prática evita o problema desde o início?
- Começa sintético e sobe só se for preciso. Cada degrau em direção ao real exige uma razão escrita: que teste concreto não consegues fazer sem isso.
- Dá ao ambiente de teste as permissões de um ambiente de teste. Credenciais próprias, sem acesso à produção nem a envios reais, como se desenvolve em que permissões dar a um agente de IA.
- Segue o percurso dos dados. Prompts, registos, conjuntos de avaliação e cópias do fornecedor contam. Se o teu fornecedor guarda as tuas entradas de teste, o ambiente de teste já não é só teu.
- Põe uma data de eliminação no conjunto de teste. Um conjunto de avaliação com dados reais que ninguém revê é um arquivo de dados pessoais sem responsável.
- Que decida uma pessoa com nome. Quem aprova usar dados reais e quem verifica, de tempos a tempos, que ainda são necessários.
O que fazer quando é o fornecedor a pedir uma amostra real?
Acontece mais do que parece: o fornecedor precisa de «ver os vossos casos» para configurar o agente. Antes de enviar o que quer que seja, quatro perguntas, por escrito:
- Para quê, exatamente? Uma amostra para perceber o formato não é uma amostra para treinar nem para avaliar.
- O que faz o fornecedor com ela? Se a usa para melhorar os seus próprios modelos ou para algo além do teu projeto, a conversa é outra.
- Onde fica guardada e quem tem acesso? País, subcontratantes, tempo de conservação. É a pergunta de fundo de o que o teu fornecedor não conta sobre IA e RGPD.
- Resolve-se com dados sintéticos? Quase sempre, dez casos escritos à mão e um esquema de campos chegam para configurar; a amostra real vem mais tarde, delimitada, e só se for preciso.
Quando faz sentido usar dados reais?
Quando medir a qualidade real é o objetivo e o sintético não a representa. Uma avaliação contínua sobre uma amostra pequena, delimitada e com acesso restrito é defensável, e é o tipo de medição que desenvolvemos em avaliar a qualidade dos teus agentes de IA e em evals: sem medir, não sabes se funciona. O que não é defensável é fazê-lo por inércia.
Nesse caso, a AEPD pede uma análise de necessidade e proporcionalidade e medidas de segurança conformes com o artigo 32.º do RGPD. Na prática cabe numa página: porquê, quantos dados, quem acede e até quando. E se for preciso depurar uma falha com dados reais sem alternativa, a mesma AEPD indica o que se aplica: autorização do responsável, registo e auditoria dessa autorização e do que se faz, dados mínimos e acesso só a quem precisa.
A frase para levar: não perguntes se o teu agente passou nos testes, pergunta com os dados de quem passou. Se a resposta for «com os reais» e ninguém o decidiu, não testaste um agente: abriste um arquivo.
Fontes (consultadas a 20 de outubro de 2026): AEPD, «Brechas de datos personales: entornos de desarrollo y preproducción» (18 de abril de 2022, em espanhol); Regulamento (UE) 2016/679, arts. 4.º(5) e 32.º; e um resumo das diretrizes 01/2025 do CEPD sobre pseudonimização (adotadas a 16 de janeiro de 2025). Informação geral, não é aconselhamento jurídico.