De un pipeline de dos agentes a una arquitectura de seis capas: lo que hubo que imponerle a la IA para que la persona sintética se convirtiera en un artefacto confiable.
En este artículo, detallo cómo construí un pipeline de personas sintéticas con agentes de IA para probar prototipos. Tras situar el primer ejercicio, con dos agentes, voy a detallar la evolución hacia una arquitectura en capas, con las reglas, los checkpoints y los límites que la hacen confiable.
El primer ejercicio contaba con un Investigador que consumía transcripciones de entrevistas, métricas y recorridos de negocio y generaba personas. Cuando la información no estaba en el material, reportaba la brecha. El otro agente era un UX Senior que recibía esas personas y simulaba entrevistas, en modo roleplay, crítica o mixto. Probé el pipeline en un prototipo de e-commerce B2B de bienes de consumo, en el que el usuario principal es el representante que atiende a otros negocios, con un recorrido de compra denso y lleno de escenarios logísticos.
Funcionó. Ayudó a refinar el prototipo antes de pasar a la validación con el equipo y a la prueba con usuarios reales, y me enseñó más sobre el negocio del cliente, porque muchas dudas las aclaraba preguntándole a la persona y confirmando después con el equipo. También dejó dos aprendizajes que siguen vigentes: la persona es un reflejo de los datos, una cápsula del tiempo que envejece si el material envejece; y la precisión depende del prompt, porque una pregunta suelta genera una respuesta confusa, y una pregunta condicionada a un dolor y a una fuente genera una respuesta rica.
El ejercicio siguiente fue llevar el método a otros escenarios, en una estructura multiagente, dividiendo los objetivos de la prueba en más de un agente. La evolución no fue agregar agentes. Hubo que repensar la arquitectura entera.
1. Por qué dos agentes empezaron a no bastar
El pipeline de dos agentes resolvía un problema específico: generar una persona a partir de datos y simular una conversación con ella. Para un primer experimento, era suficiente.
El problema apareció cuando intenté usar el mismo método en escenarios diferentes.
¿Y cuando no tenía entrevistas? Solo tenía hipótesis del equipo, datos secundarios, unos benchmarks sueltos. La persona "salía", pero salía con la misma confianza visual que una persona con datos reales. Peligroso.
¿Y cuando quería probar un concepto todavía no diseñado? El agente UX Senior seguía simulando "uso de pantallas", porque era lo que sabía hacer. La respuesta no siempre tenía sentido. ¿Y cómo saber si una respuesta venía de los datos o era inferida? No siempre se podía. A veces el agente mezclaba las dos cosas en una sola frase, y yo tenía que volver a los datos para verificar manualmente.
El primer ejercicio ya lo había mostrado: sin una estructura rigurosa, la IA tiende a llenar los vacíos con suposiciones genéricas. Vi a la IA llenar un vacío con una suposición como si fuera evidencia, más de una vez, y me di cuenta de que prompts más sofisticados no lo iban a resolver.
Lo que tenía que cambiar no era el prompt, sino la arquitectura. Si ya pasaste por eso, conoces la sensación: la pregunta deja de ser "¿cómo hago mejores prompts?" y pasa a ser "¿cómo organizo todo el sistema?".
2. El giro: pensar en capas, no en agentes
Lo primero que tuve que internalizar es que "multiagente" no es "muchos agentes conversando entre sí". Al contrario.
La intuición inicial es poner a los agentes a ayudarse: el Crítico de UI ve lo que escribió el Empático, el Modelador conversa con todos, y así sucesivamente. Parece colaborativo. En la práctica, lo contamina todo.
Cuando dos agentes de IA pueden leerse, las inferencias de uno se vuelven "hecho" para el otro. El patrón es siempre el mismo: el primero arriesga una hipótesis ("el usuario parece ansioso"); el segundo la lee y la trata como observación ("el usuario está ansioso"); el tercero propone acciones basadas en la ansiedad. Cuando llegas al final del ciclo, la alucinación está cosida a la persona como si fuera evidencia.
La solución fue invertir la lógica. En lugar de agentes que conversan, capas que aíslan. Cada capa tiene un rol único, recibe input de una capa específica, y nadie retroalimenta a nadie. El flujo es unidireccional.
Salió una arquitectura de seis capas:
- Preprocesador: estructura los datos brutos.
- Skills analíticas: analizan en paralelo, orquestadas por un Supervisor.
- Modelador: consolida en persona.
- UX Senior: simula la entrevista.
- Síntesis: integra y evalúa.
- Investigador: audita la trazabilidad.
El Investigador cambió de función entre las dos versiones. Antes creaba las personas; ahora audita lo que fue creado. Fue una de las mejores decisiones del proyecto: separar a quien hace de quien verifica.
3. Las tres reglas que sostienen la arquitectura
Tener seis capas no significa nada por sí solo. Lo que hace que la cosa funcione son las tres reglas que gobiernan el flujo entre ellas.
3.1 Solo una capa toca los datos brutos
El Preprocesador es el único agente con acceso directo a las carpetas de entrada (entrevistas, analytics, videos, pantallas, hipótesis). Todas las capas siguientes operan exclusivamente sobre su output estructurado.
¿Por qué importa? Porque los datos brutos son demasiado interpretables. Cuando varios agentes entran en contacto con la transcripción original, cada uno lee la misma frase de una manera. Cuando solo un agente lee y estructura, todos los demás parten de la misma base, y cualquier divergencia posterior se vuelve señal de algo real, no de una lectura diferente.
3.2 Las skills de la capa analítica no se leen entre sí
La capa 2 tiene varias skills corriendo en paralelo: Cronometrista (mide tiempo y fricción), Empatía (mapea emociones expresadas de forma observable), Cuantitativo (analytics), Crítico de UI, Hipótesis, Benchmarks, y así sucesivamente. Cuáles entran depende del modo de operación. En una prueba de usabilidad con video, por ejemplo, entran Cronometrista y Crítico de UI; en una proto-persona sin datos reales, entran Hipótesis y Benchmarks.
Todas reciben el mismo input: el output del Preprocesador. Ninguna lee lo que las otras escribieron. Un Supervisor coordina las skills sin leer lo que cada una escribió y entrega el conjunto al Modelador, en la capa siguiente.
Ese aislamiento es lo que más me costó aceptar al principio. Parecía un desperdicio. Hoy lo veo como lo opuesto: es lo que permite que la capa de Síntesis detecte convergencia genuina entre análisis independientes. Si tres skills aisladas llegaron a la misma conclusión por caminos diferentes, eso vale mucho más que si se hubieran influido entre sí.
3.3 Toda afirmación necesita fuente
Esta es la regla más molesta de implementar y la que más protege contra la alucinación. Es un principio básico de IA responsable. Cada ítem producido por cualquier skill tiene que llevar una clasificación:
- Dato explícito: observado directamente.
- Inferido: conexión lógica no observada directamente.
- Dato secundario: investigación externa, informe.
- Benchmark: producto similar, caso publicado.
- Hipótesis del equipo: suposición del equipo sin dato externo.
- Ausencia: ningún dato encontrado; no completar.
¿Parece demasiado formal? Pero, cuando el Investigador audita al final, logra separar con precisión lo que tiene respaldo de lo que es inferencia. Y cuando yo, como diseñadora, voy a presentar la persona al equipo, sé exactamente dónde puedo golpear la mesa y dónde necesito decir "esto es hipótesis, hay que validarlo".
4. Los checkpoints: dónde el sistema puede detenerse
Algo que aprendí: confiar en que la IA "va a entregar bien" es la forma más cara de descubrir que no entregó. Por eso, la arquitectura tiene dos checkpoints críticos a mitad de camino, puntos donde el ciclo se detiene si algún criterio no se cumple.
Checkpoint 1, después del Preprocesador. Antes de disparar los análisis paralelos, el sistema verifica: ¿se procesaron todas las carpetas? ¿Cada ítem tiene clasificación de fuente? ¿Cada ítem tiene referencia de origen (carpeta, archivo, fragmento)? ¿Se declararon las transformaciones? Si es un modo con datos reales, ¿hay ausencia de información personal identificable? Si alguno de esos puntos falla, el ciclo se detiene, no pasa a la capa 2 y notifica lo que faltó.
Checkpoint 2, después del Modelador. Antes de ir a la simulación, verifica si la persona tiene todas las secciones obligatorias, si cada característica tiene sustento clasificado, si hay un patrón de decisión mapeado. Si es proto-persona, verifica si el lenguaje es condicional, si la confianza está declarada como baja, si está identificada como proto-persona en el encabezado.
Y al final, después de la Síntesis, viene la auditoría del Investigador, que puede aprobar, aprobar con reservas o rechazar. ¿Rechazó? Vuelve a revisión.
Estos checkpoints hacen que el ciclo tarde más. A cambio, llego al final con un artefacto en el que confío. Y, cuando no confío, el propio sistema me dice dónde mirar.
5. Persona o proto-persona: cuando los datos no existen
Quizás la parte que más reorganizó mi forma de pensar fue separar persona de proto-persona como artefactos distintos, no como "lo mismo en etapas diferentes".
La persona sintética nace cuando hay datos reales: entrevistas, analytics, videos. Confianza media a alta. Lenguaje descriptivo. La proto-persona nace cuando no los hay: solo hipótesis, datos secundarios, benchmarks. Confianza baja. Lenguaje condicional obligatorio.
En la práctica, la persona con datos reales dice "el usuario hizo una pausa de 8 segundos antes de hacer clic", "3 de 5 usuarios abandonaron el flujo en este punto", "hay una pausa larga seguida de una reformulación". La proto-persona dice "el público posiblemente enfrentaría dificultad", "si la hipótesis se confirma, este perfil probablemente...", "los datos secundarios sugieren que...".
Parece un detalle lingüístico, pero es un detalle estructural. Cuando el Modelador escribe "el usuario siente X" sin dato real, transforma una hipótesis en afirmación. Cuando escribe "el público posiblemente sentiría X", preserva la incertidumbre, y quien lo lea tomará una decisión diferente.
Y una regla que costó aceptar, pero tiene sentido: las proto-personas no evolucionan a personas. Cuando aparecen datos reales, no "actualizas"; empiezas de cero. Porque una proto-persona es por naturaleza hipotética; mezclarla con dato real crea un híbrido en el que ya nadie logra distinguir qué es evidencia de qué era suposición.
6. Los límites de la IA
La arquitectura reduce el riesgo de alucinación y deja la confianza declarada, pero no cambia lo que la simulación es. Cuatro límites que mapeé desde el primer ejercicio siguen definiendo el papel de la IA como herramienta de refinamiento, y no de reemplazo.
La dependencia de datos. Una persona sintética es tan profunda como los datos que la alimentan. En el primer ejercicio, el usuario sintético insistía en un problema del recorrido que ya estaba resuelto, porque las pruebas con usuarios reales eran anteriores a la mejora. La persona refleja el pasado para intentar anticipar el futuro; por eso importa el reciclaje constante de datos reales.
El factor sorpresa y emocional. La IA es buena en lógica y detección de patrones, pero todavía falla en replicar la imprevisibilidad humana. Emociones complejas, como la vacilación al ver un botón nuevo, la simulación no las capturó. Como señala el NN Group, el comportamiento humano es complejo y depende del contexto, y los usuarios sintéticos no captan esa complejidad.
Cualitativo, no cuantitativo. El análisis se inclina hacia lo cualitativo. La IA es excelente para señalar por qué un flujo es confuso, pero la métrica de tiempo de tarea en un entorno sintético todavía no pasa de una sugerencia. La simulación responde "qué" y "por qué"; el "cuánto" todavía pertenece a las pruebas de usabilidad reales.
El riesgo de alucinación. Sin una estructura rigurosa, la IA divaga y llena los vacíos con suposiciones genéricas. Las tres reglas y los checkpoints existen por eso, y aun con ellos la salvedad sigue siendo obligatoria.
Reconocer estas limitaciones no disminuye el valor del método. Al contrario: le da al diseñador la visión necesaria para saber cuándo confiar en la simulación, cuándo iterar el método y cuándo es hora de ir a campo a escuchar al usuario real.
7. Lo que cambia en el papel del diseñador (y lo que no)
La pregunta que abrió el primer ejercicio, ¿la IA va a reemplazar al diseñador de investigación?, sigue con la misma respuesta: no. Pero la respuesta se volvió más matizada.
Lo que cambió con la arquitectura multiagente. Me detengo menos a "verificar si la IA inventó algo". El sistema ya separa evidencia de inferencia por defecto. Logro manejar escenarios en los que no tengo datos reales; antes evitaba personas en esos casos, ahora genero proto-personas conscientes de su propia limitación. El artefacto que le entrego al equipo viene con auditoría incorporada. La confianza no es una sensación mía, es un campo declarado.
Lo que no cambió. La persona sintética sigue siendo una estructura probabilística, no una persona real. La simulación no reemplaza la validación empírica. La salvedad sigue siendo obligatoria. La investigación de campo continua es lo que mantiene los datos frescos; sin ella, cualquier persona, sintética o no, se vuelve una cápsula del tiempo.
Y quizás el cambio más importante: la arquitectura me obligó a pensar antes de simular. ¿Qué tipo de prueba quiero correr? ¿Tengo datos reales? ¿Qué confianza necesita tener el resultado para sostener una decisión? Son preguntas que antes me saltaba, directo al prompt. Ahora son el primer paso del ciclo.
Liderar con método
Si el primer ejercicio fue descubrir que las personas sintéticas funcionan, la evolución fue descubrir que funcionan mejor cuando le impones límites estructurales a la IA, no cuando le das libertad.
La intuición es lo opuesto. Queremos agentes "inteligentes", "creativos", "que conectan puntos". En la práctica, son el aislamiento, la clasificación obligatoria de fuentes y la auditoría los que producen un artefacto confiable. La creatividad de la IA generativa, sin gobernanza, es exactamente lo que socava la confianza en el resultado.
Aquí en Taqtile, ese aprendizaje se convirtió en plugin: una arquitectura reutilizable que cualquier diseñador del equipo puede correr en cualquier proyecto, con los mismos filtros de evidencia corriendo por debajo. La idea no es encerrar el método en una persona; queremos transformar el método en algo que el equipo construye e itera junto.
Si quieres seguir cómo evoluciona este método, suscríbete al newsletter de Taqtile. Es por donde contamos nuestros últimos experimentos, casos y proyectos.