Escenario ilustrativo. El equipo que construye tu agente de atención al cliente pide, con toda lógica, «una muestra de tickets reales para afinarlo». Exportan dos mil conversaciones del CRM, las dejan en una carpeta compartida y el agente empieza a mejorar. Nadie ha tomado ninguna decisión: ha pasado. Y esa carpeta ya contiene nombres, direcciones e incidencias de gente que jamás supo que sus mensajes iban a servir para probar software.
La tesis en una línea: probar un agente con datos reales no es un atajo técnico, es un tratamiento de datos personales con su riesgo y su responsable, y casi siempre se puede evitar o acotar a cambio de un coste de calidad que conviene medir en lugar de ignorar.
Datos de prueba para agentes de IA: por qué «probar con lo real» ya es tratar datos
La Agencia Española de Protección de Datos (AEPD) lo dice sin rodeos en su blog sobre entornos de desarrollo y preproducción (abril de 2022): las pruebas de software con datos personales «son, o forman parte de, tratamientos de datos personales», con todas las obligaciones del RGPD, y cuando sea posible debe evitarse usar datos personales en desarrollo, preproducción o cualquier otro entorno de pruebas. Añade algo incómodo: el riesgo en esos entornos puede ser igual o mayor que en producción, porque hay más proveedores, más copias y menos controles.
Con un agente la exposición es más difícil de ver que con una aplicación clásica. Los datos de prueba no se quedan en una base de datos: viajan en prompts hacia un modelo de terceros, se guardan en trazas de observabilidad y acaban en conjuntos de evaluación que se versionan y se comparten. Cada copia es un sitio más donde los datos de tus clientes existen sin que nadie los haya contado; es el mismo problema que explicamos en qué sale de tu perímetro en cada llamada. La norma de fondo es europea; los criterios concretos de cada autoridad nacional pueden variar.
¿Qué alternativas hay a los datos reales y qué se pierde con cada una?
No hay opción gratis. Cada alternativa protege algo y cuesta algo; elegir bien es saber qué prueba pierdes con cada una.
| Alternativa | Qué hace | Qué se pierde | Cuándo encaja |
|---|---|---|---|
| Anonimizar de verdad | Quita o transforma los datos hasta que nadie pueda identificar a la persona, ni con información adicional | Los detalles que hacían real el caso: el historial, el hilo que une un mensaje con el siguiente. Hacerlo bien es difícil, y si se puede revertir no es anonimización | Datos estructurados y cortos; casi nunca texto libre largo |
| Seudonimizar | Sustituye identificadores por códigos y guarda la clave aparte | Casi nada de realismo. Pero siguen siendo datos personales: las directrices 01/2025 del Comité Europeo de Protección de Datos recuerdan que lo seudonimizado sigue siéndolo si existe información adicional para reidentificar | Cuando necesitas continuidad entre casos y controlas quién tiene la clave |
| Datos sintéticos | Se generan datos con la forma de los reales, sin que correspondan a nadie | Las rarezas que nadie pensó en simular: la errata, el cliente que mezcla dos idiomas, el campo que viene vacío salvo los martes | Probar flujo, formato, permisos e integraciones |
| Casos construidos a mano | Los escribe alguien que conoce el proceso, a partir de patrones reales | Volumen y sorpresa: solo aparece lo que ya sabías buscar | Casos límite y pruebas que tienen que ser repetibles |
| Datos reales acotados | Un subconjunto mínimo, con decisión documentada, acceso restringido y fecha de borrado | Ningún realismo, pero todo el riesgo, aunque reducido | Solo cuando lo anterior no basta y hay una razón concreta |
La AEPD recoge esta jerarquía: los datos sintéticos evitan en muchos casos tratar datos personales en pruebas, y los datos de prueba derivados de datos reales deben conservar la estructura sin contener datos personales reales. Si eso no basta, pide una decisión documentada que limite al máximo qué datos reales se usan.
¿Qué no se puede probar con datos falsos?
Lo que se rompe en producción rara vez es lo que imaginaste. Un agente probado solo con datos limpios aprueba exámenes que producción no pone: mensajes de tres líneas sin contexto, adjuntos escaneados torcidos, el cliente que contesta a otra cosa. Es el mecanismo de la demo que usaba tus mejores casos, aplicado a las pruebas.
Por eso la respuesta no es «nunca datos reales», sino separar qué se prueba dónde. La lógica, los formatos, las integraciones y los permisos se prueban con datos sintéticos y casos a mano. La calidad ante la variedad real se mide después, en una ejecución en sombra donde el agente lee entradas reales pero escribe en destinos falsos, como explica la guía para probar cambios sin romper la automatización. Ojo: esa copia lee datos reales, así que sigue siendo un tratamiento y necesita su propia justificación y sus propios límites.
¿Qué regla práctica evita el problema desde el principio?
- Empieza sintético y sube solo si hace falta. Cada escalón hacia lo real exige una razón escrita: qué prueba concreta no puedes hacer sin ello.
- Dale al entorno de pruebas los permisos de un entorno de pruebas. Credenciales propias, sin acceso a producción ni a envíos reales, como se desarrolla en qué permisos dar a un agente de IA.
- Sigue el recorrido de los datos. Prompts, trazas, conjuntos de evaluación y copias del proveedor cuentan. Si tu proveedor guarda las entradas de prueba, el entorno de pruebas ya no es solo tuyo.
- Ponle fecha de borrado al conjunto de prueba. Un conjunto de evaluación con datos reales que nadie revisa es un archivo de datos personales sin responsable.
- Que decida una persona con nombre. Quién aprueba usar datos reales, y quién revisa cada cierto tiempo que sigue haciendo falta.
¿Qué hacer cuando es el proveedor quien pide una muestra real?
Pasa más de lo que parece: el proveedor necesita «ver vuestros casos» para configurar el agente. Antes de enviar nada, cuatro preguntas, por escrito:
- ¿Para qué exactamente? Una muestra para entender el formato no es una muestra para entrenar ni para evaluar.
- ¿Qué hace el proveedor con ella? Si se usa para mejorar sus propios modelos o para algo más que tu proyecto, la conversación es otra.
- ¿Dónde se guarda y quién accede? País, subencargados, tiempo de retención. Es la pregunta de fondo de lo que tu proveedor no cuenta sobre IA y RGPD.
- ¿Se puede resolver con datos sintéticos? La mayoría de las veces, con diez casos escritos a mano y un esquema de campos basta para configurar; la muestra real llega más tarde, acotada, y solo si hace falta.
¿Cuándo sí tiene sentido usar datos reales?
Cuando medir la calidad real es el objetivo y lo sintético no la representa. Una evaluación continua sobre una muestra pequeña, acotada y con acceso restringido es defendible, y es el tipo de medición que desarrollamos en evaluar la calidad de tus agentes de IA y en evals: sin medir, no sabes si funciona. Lo que no es defendible es hacerlo por inercia.
En ese caso la AEPD pide un análisis de necesidad y proporcionalidad y medidas de seguridad acordes al artículo 32 del RGPD. En la práctica cabe en una página: por qué, cuántos datos, quién accede y hasta cuándo. Y si hay que depurar un fallo con datos reales y no hay alternativa, la misma AEPD recoge lo que toca: autorización del responsable, registro y auditoría de esa autorización y de lo que se hace, datos mínimos y acceso solo a quien lo necesita.
La línea para llevarte: no preguntes si tu agente pasó las pruebas, pregunta con qué datos de quién las pasó. Si la respuesta es «con los reales» y nadie lo decidió, no has probado un agente: has abierto un archivo.
Fuentes (consultadas el 20 de octubre de 2026): AEPD, «Brechas de datos personales: entornos de desarrollo y preproducción» (18 de abril de 2022); Reglamento (UE) 2016/679, arts. 4(5) y 32; y resumen de las Directrices 01/2025 del CEPD sobre seudonimización (adoptadas el 16 de enero de 2025). Esto es información general, no asesoramiento jurídico.