Agentes de IA atendiendo clientes: lo que nadie audita
El debate público es si la IA reemplaza gente. La pregunta operativa es otra: qué datos ve el modelo sin necesidad, y qué inventa cuando le falta uno.
De dónde salen los datos
Auditorías propias sobre agentes en producción, agosto de 2026. En una revisión de calidad de dos bots de clientes aparecieron datos personales de pacientes viajando dentro del prompt del modelo sin necesidad, y un guardarraíl faltante que dejaba al bot afirmar cosas del negocio que nadie había verificado. En otro sistema, un detector automático de tareas montado sobre las conversaciones capturó, a los veinte segundos de encendido, una clave de restablecimiento que iba camino de un gestor de tareas externo y del propio modelo. Y en un tercer bot, la negación silenciosa: un servicio ausente de la base de datos se respondía como inexistente, tres veces en tres semanas, sin generar un solo log. Ninguno de los tres fallos se manifiesta como error: se manifiestan como conversaciones que salieron mal y que nadie leyó.
Por Wilmar Rocha
El debate público sobre agentes de inteligencia artificial atendiendo clientes casi siempre gira en torno a una pregunta: ¿va a reemplazar esto a un humano? Es la pregunta equivocada para quien ya tiene uno en producción. La pregunta que de verdad importa es más incómoda: ¿qué datos está viendo el modelo que no debería ver, y qué está inventando cuando le falta un dato real? Ninguna de las dos se responde con una opinión. Se responden auditando conversaciones reales, línea por línea.
El primer hallazgo: datos que no debían estar ahí
En una revisión de calidad sobre dos bots de clientes en producción, encontramos datos personales de pacientes viajando dentro del prompt que se le manda al modelo en cada turno de conversación, sin ninguna necesidad de que estuvieran ahí. No era un error de seguridad dramático — nadie los estaba robando — era algo más silencioso y más común: información sensible circulando por un sistema que no tenía por qué verla, simplemente porque nadie se detuvo a preguntar qué campos hacían falta de verdad. Junto a eso, faltaba un guardarraíl básico: el bot podía afirmar cosas sobre el negocio que jamás habían sido verificadas por una persona.
El segundo hallazgo: una clave viajando hacia afuera
En otro sistema montamos un detector automático que revisa las conversaciones en busca de tareas pendientes — una forma de que nada se pierda entre lo que el cliente pide y lo que el equipo hace. A los veinte segundos de encenderlo, capturó una clave de restablecimiento de contraseña que iba camino de un gestor de tareas externo y, de paso, del propio modelo que procesaba la conversación. Veinte segundos. No hizo falta esperar a que pasara algo grave para encontrar el problema — el problema ya estaba pasando, solo que nadie lo había medido todavía.
El tercer hallazgo: la negación que no deja rastro
El más difícil de detectar de los tres fue también el más simple de explicar. Un servicio que el negocio ofrecía no estaba cargado en la base de datos que alimentaba al bot. Cuando un cliente preguntaba por él, el bot respondía con total seguridad que no lo manejaban. Pasó tres veces en tres semanas. Ninguna de esas tres veces generó un error, un log o una alerta — porque desde el punto de vista técnico, el sistema funcionó exactamente como estaba programado: si el dato no existe, se responde que no existe. El problema no era el código. Era que a nadie se le había ocurrido preguntar cuántas veces el bot estaba diciendo "no" sobre cosas que sí existían.
Lo que tienen en común los tres casos
Ninguno de los tres fallos se manifestó como un error visible. No hubo una pantalla roja, no hubo un ticket de soporte, no hubo nada que le dijera a alguien "revisa esto". Se manifestaron como conversaciones que salieron mal y que nadie leyó — porque leer conversación por conversación no escala, y porque la suposición cómoda es que si el bot no se cayó, está funcionando bien. Un bot puede estar arriba, respondiendo instantáneamente y con buena redacción, mientras filtra datos que no debería tener, inventa hechos sobre el negocio, o le dice que no a un cliente que debería recibir un sí.
Qué auditar si ya tienes un agente en producción
- Qué datos viajan en cada prompt. No lo que el modelo necesita para responder bien — lo que efectivamente se le está mandando. Suelen ser cosas distintas.
- Qué pasa cuando falta un dato. Un bot bien diseñado dice "no tengo esa información, te conecto con alguien" — no inventa una respuesta con el mismo tono de seguridad que usa para lo que sí sabe.
- Si hay algo capturando información sensible que no debería salir del sistema, y a dónde va exactamente esa información una vez capturada.
- Una muestra real de conversaciones, leída por una persona, no solo las métricas de volumen y tiempo de respuesta. Los tres hallazgos de este artículo salieron de leer texto, no de un dashboard.
Auditar un agente de IA no es una tarea de una sola vez al lanzarlo. Es una revisión que hay que repetir, porque el bot no cambia solo — pero el negocio sí, y cada servicio nuevo, cada dato nuevo y cada integración nueva es una oportunidad para que aparezca un cuarto hallazgo que todavía nadie ha visto. Si vas a montar o auditar un chatbot de WhatsApp, esta es exactamente la lista con la que empezar antes de darlo por listo.
- chatbot
- automatizacion
- datos