Miguel Martín (Winking Owl): «El objetivo de las pruebas adversariales es descubrir vulnerabilidades de la IA, antes de que lo haga un cliente»

Para comenzar abordar este tema definamos primero por qué los métodos tradicionales de testing ya no son válidos por si solos. Como recuerda Miguel Martín, los métodos tradicionales de testing se diseñaron para sistemas deterministas: ante una entrada concreta, esperamos una salida concreta. Ese supuesto deja de cumplirse con la IA generativa. Un cliente puede formular la misma petición de cientos de maneras, y el agente puede responder de forma distinta a la misma pregunta. Un conjunto finito de guiones cerrados apenas cubre una fracción del espacio real de conversaciones.

"Por eso proponemos un cambio de enfoque: dejar de probar respuestas y empezar a probar comportamientos. Los clientes sintéticos son agentes de IA que reproducen perfiles reales de clientes, con sus objetivos, su vocabulario, sus dudas, sus errores y su estado de ánimo. Cada ejecución genera conversaciones nuevas, de modo que exploramos el espacio de interacciones de forma sistemática y no solo los caminos previstos", comenta Miguel Martín.

Y añade: "El testing tradicional sigue siendo útil para validar integraciones y reglas fijas. Pero, por sí solo, no basta para garantizar la fiabilidad de una IA conversacional en entornos reales".

Relación Cliente: Uno de los grandes desafíos de la IA conversacional es responder adecuadamente ante situaciones imprevistas, clientes con distintos perfiles o interacciones que se salen de los escenarios habituales. ¿Cómo ayudan los clientes sintéticos a identificar errores, alucinaciones, incumplimientos de políticas corporativas o comportamientos inesperados? ¿Qué papel desempeñan las pruebas adversariales en este proceso?

Miguel Martín: Los fallos más críticos de la IA conversacional rara vez aparecen en los escenarios habituales. Surgen en los márgenes: el cliente que mezcla dos peticiones, el que corrige un dato a mitad de conversación, el que no sabe expresar lo que necesita o el que se enfada. Los clientes sintéticos nos permiten generar de forma deliberada estos edge cases, variando perfiles, intenciones y contextos, y repetirlos tantas veces como sea necesario.

En cada conversación evaluamos si el agente ha entendido la intención, si ha ejecutado el flujo correcto, si la información que ofrece es veraz o inventada y si respeta las políticas de la compañía: qué puede prometer, qué datos puede facilitar y cuándo debe transferir a un agente humano.

Las pruebas adversariales completan este análisis. En ellas el cliente sintético adopta el papel de atacante: intenta manipular al asistente mediante prompt injection, obtener información a la que no debería acceder o forzarle a saltarse las reglas. El objetivo es sencillo: descubrir estas vulnerabilidades nosotros, antes de que lo haga un cliente real.

Relación Cliente: A medida que los agentes de IA adquieren mayor autonomía en la relación con los clientes, también aumenta la necesidad de supervisar su comportamiento. ¿Por qué es importante contar con una capa independiente de verificación y gobierno de la IA conversacional? ¿Cómo puede contribuir esta supervisión continua a mejorar la calidad del servicio y generar confianza en las empresas?

Miguel Martín: Cuando un agente de IA pasa de responder preguntas a ejecutar acciones, como modificar una tarifa, abrir una incidencia o actualizar un CRM, el riesgo deja de ser solo reputacional y pasa a ser operativo. Además, estos sistemas no son estáticos: cambian con cada nueva versión del modelo, cada ajuste del prompt o cada integración, a veces sin que nadie lo perciba.

Consideramos imprescindible que esa supervisión sea independiente, por el mismo principio por el que una empresa no audita sus propias cuentas. Quien desarrolla el agente tiende a probar lo que espera que funcione. Una capa externa verifica de forma continua que el agente se comporta como debe, con criterios definidos por el negocio y no solo por la tecnología.

Esta supervisión aporta dos cosas: calidad, porque detecta degradaciones silenciosas antes de que afecten al cliente y confianza, porque ofrece a la Dirección, a cumplimiento y a los reguladores evidencias objetivas del comportamiento de la IA. En Winking Owl lo resumimos así: IA que audita a la IA.

Relación Cliente: Muchas organizaciones siguen evaluando el funcionamiento de sus canales de atención a partir de métricas técnicas, registros internos o pruebas directas sobre la IA. Sin embargo, estos indicadores no siempre reflejan la experiencia real del usuario. ¿Qué limitaciones presentan estos métodos y por qué es necesario adoptar un enfoque de validación end-to-end que reproduzca exactamente el recorrido del cliente?

Miguel Martín: Los registros y las métricas técnicas responden a una pregunta: ¿están funcionando los sistemas? Pero el cliente se pregunta otra cosa: ¿he podido completar mi gestión? Entre ambas preguntas hay una distancia considerable. Un servidor puede estar disponible y la API del bot responder correctamente y, aun así, el cliente quedarse atascado en el menú del IVR, no recibir el SMS de verificación o abandonar por un tiempo de espera excesivo.

Además, los logs son por naturaleza reactivos: muestran lo que ya ha fallado, y solo aquello que el sistema es capaz de registrar. Las pruebas directas sobre la IA, por su parte, evalúan el modelo de forma aislada, sin el canal que lo rodea. Y el canal condiciona la conversación. Aunque WhatsApp y el chat de la web compartan la misma IA, el cliente no se comporta igual en ambos.

En WhatsApp divide su petición en varios mensajes cortos, envía audios, deja la conversación y la retoma horas después, y acepta esperas y tiempos de respuesta más largos. En el chat de la web escribe mensajes más completos, espera delante de la pantalla una respuesta inmediata y la sesión puede caducar si se demora. Por no hablar del canal telefónico, donde entran en juego la voz, las pausas, las interrupciones y los silencios, y donde unos segundos de retardo bastan para romper la conversación. Una prueba por API no reproduce nada de esto, de modo que la IA puede superarla y fallar después ante el cliente real.

La validación end-to-end invierte la perspectiva. En lugar de observar desde dentro, reproducimos el recorrido completo desde fuera, exactamente como lo haría un cliente: marcar el número, escribir por WhatsApp o navegar por la web. Solo así medimos la disponibilidad real del servicio, que es la que percibe el cliente.

Relación Cliente: Al hilo de lo que comentas, y teniendo en cuenta las diferencias a tener en cuenta al validar y evaluar distintos canales,  ¿cómo pueden detectarse en cada uno de ellos problemas relacionados con los tiempos de espera, las latencias, el enrutamiento, los IVR o los procesos de autenticación antes de que afecten al usuario?

Miguel Martín: Un mismo asistente no se comporta igual en todos los canales, porque cada uno impone sus propias condiciones. En el teléfono influyen la calidad del audio, el reconocimiento de voz, las pausas y los silencios: un retardo de dos segundos que en un chat pasa desapercibido, en una llamada provoca interrupciones y respuestas solapadas. En WhatsApp el cliente escribe en varios mensajes cortos o envía audios. En la web y en la app intervienen la navegación, los formularios y la autenticación.

Muchos fallos, además, se producen antes de llegar a la IA: un IVR que enruta mal, una autenticación que no valida o una integración que tarda en responder. Para el cliente el resultado es el mismo: no puede resolver su gestión.

Por eso nuestros clientes sintéticos interactúan con cada canal según sus propias reglas: hablan, esperan, escriben y se equivocan. Ejecutamos estos recorridos de forma continua, medimos tiempos, latencias y rutas, y generamos una alerta en cuanto detectamos una desviación, indicando el paso exacto en el que se ha producido.

Relación Cliente: Teniendo en cuenta esta multicanalidad y que una misma interacción puede implicar una llamada, el envío de un SMS o un correo electrónico y el acceso posterior a un enlace o una aplicación, ¿cómo se puede comprobar que todo este recorrido funciona de manera coordinada y sin interrupciones? ¿Qué ventajas aporta realizar pruebas proactivas de extremo a extremo frente a detectar los fallos cuando ya han afectado al cliente?

Miguel Martín: La atención al cliente ya no es una conversación en un único canal, sino un recorrido que encadena varios. El cliente llama, el asistente le envía un SMS con un enlace, ese enlace abre una página o la app y, al final, recibe un correo de confirmación. Cada eslabón puede funcionar por separado y, sin embargo, el recorrido fallar: el SMS no llega, el enlace caduca o muestra un contenido incorrecto, o el correo no refleja la gestión realizada.

Las IAs más avanzadas van incluso un paso más allá: gestionan varios canales a la vez. Un voicebot puede enviar un correo o un SMS mientras mantiene la conversación, o pedir al cliente que lo revise sin colgar: "le acabo de enviar un enlace, ¿lo ha recibido?". En estos casos ya no basta con validar cada canal por separado. Hay que comprobar que la acción se produce durante la conversación, que llega a tiempo y que la IA conserva el contexto mientras tanto.

Para comprobarlo, el cliente sintético recorre toda la cadena, también en paralelo a la conversación: recibe el SMS, abre el enlace, verifica el contenido, lee el correo y comprueba que todo es coherente con lo solicitado durante la conversación.

La ventaja de hacerlo de forma proactiva es clara. Cuando un fallo se detecta a través de las reclamaciones, ya ha afectado a muchos clientes, ha generado nuevos contactos y ha erosionado su confianza. Detectarlo antes cambia la ecuación: menos tiempo de detección, menos tiempo de resolución y menos clientes afectados. En definitiva, pasamos de reaccionar ante los fallos a anticiparnos a ellos.