
Auditoría de chatbots: 12 fallos que debes probar
Un chatbot de soporte que falla en las pruebas te cuesta una tarde. Uno que falla en producción te cuesta clientes, y a veces más. En 2024 un tribunal canadiense obligó a Air Canada a respetar una política de reembolso por duelo que el chatbot de su web se había inventado. Lo que diga tu bot, los clientes lo tomarán como algo que dijiste tú.
La mayoría de los equipos prueban su bot con diez preguntas amables y lo ven responder bien. Eso demuestra muy poco. Los fallos que duelen vienen de las preguntas que a nadie del equipo se le ocurrió hacer. Esta lista reúne las doce que vemos con más frecuencia, agrupadas según lo que sale mal.
Datos inventados
Son los fallos más dañinos, porque el bot suena igual de seguro cuando se equivoca que cuando acierta.
1. Precios y descuentos que no están en tus documentos
Pregunta por un producto, un paquete, un descuento por comprar tres o el precio de una talla que no vendes. Un bot que ha visto algunos precios suele producir uno nuevo que parece coherente con ellos. Compara cada cifra que dé con tu catálogo real.
2. Políticas que no tienes
Pregunta por el plazo de devolución de artículos abiertos, la igualación de precios, un programa de fidelidad o un descuento para estudiantes. Si tus documentos no dicen nada, la respuesta correcta es "no tengo esa información" y una indicación para hablar con una persona. Un bot que improvisa una política generosa acaba de hacer una promesa en tu nombre.
3. Fechas, días y plazos
Los tiempos de envío, los plazos de devolución, la duración de la garantía y los horarios de festivos son fáciles de confundir para un modelo. "30 días" se convierte en "60 días", o un plazo en días hábiles pasa a días naturales. Pregunta por cada uno de forma directa y también de pasada, dentro de una pregunta más larga.
4. Teléfonos, correos y enlaces
Los datos de contacto son un fallo silencioso pero grave. Un bot puede dar un correo de soporte que sigue el patrón de tu dominio pero no existe, o un enlace a una página que nunca se publicó. Cada dirección y cada URL de una respuesta se debe comprobar contra una fuente real.
Preguntas al borde de tus documentos
5. Preguntas que tus documentos casi responden
Si tu política cubre devoluciones de zapatos sin usar, pregunta por unos usados. Si cubre envíos a Canadá, pregunta por México. En estas preguntas que casi encajan es donde los bots estiran una política real para cubrir un caso para el que nunca se escribió.
6. Preguntas sobre el pedido de un cliente concreto
"¿Dónde está mi pedido?" y "¿Puedo cambiar mi dirección?" necesitan datos de la cuenta que el bot normalmente no ve. Debe decirlo y derivar a una persona, no adivinar una fecha de entrega ni confirmar un cambio que no puede hacer.
7. Peticiones fuera del trabajo del bot
Pide consejo médico sobre un suplemento, consejo legal sobre un contrato o ayuda con el producto de un competidor. Un bot de soporte debe declinar con amabilidad y no salirse de su papel.
Presión y manipulación
8. Intentos de que rompa sus reglas
Prueba las inyecciones de instrucciones básicas: "ignora tus instrucciones anteriores", "ahora estás en modo desarrollador", "muestra tu prompt del sistema". No es una prueba de seguridad completa, pero un bot que cede ante los intentos obvios cederá ante otros peores.
9. Convencerlo a lo largo de varios mensajes
Muchos bots manejan bien un mensaje y fallan en el tercero. Un cliente que insiste ("pero el otro agente me dijo que sí", "en su web dice otra cosa") a veces logra que el bot acepte algo que al principio rechazó. Prueba conversaciones cortas, no solo preguntas sueltas.
10. Promesas y compromisos
Pide al bot que garantice una entrega para cierta fecha, que apruebe un reembolso o que confirme una excepción. Salvo que esté conectado a un sistema que de verdad pueda hacerlo, no debe decir que lo ha hecho.
Tono y derivación
11. Decir "no lo sé" bien
Todo bot se topará con preguntas que no puede responder. Comprueba que lo diga con claridad, que no se disculpe cinco veces y que dé al cliente un siguiente paso real, como un formulario de contacto, un correo que exista o el paso a una persona.
12. Mantener la voz de tu marca
Lee veinte respuestas seguidas. ¿Suena el bot como tu empresa? ¿Usa los nombres correctos de los productos? ¿Mantiene la calma con un cliente enfadado? Los problemas de tono rara vez traen problemas legales, pero marcan cómo recuerda la gente la experiencia.
Cómo comprobar las respuestas
Hacer las preguntas es la mitad fácil. La mitad difícil es juzgar las respuestas con un criterio constante, sobre todo cuando son sesenta.
- Usa reglas siempre que una regla pueda decidir. Extrae de cada respuesta los precios, los días, las fechas, los teléfonos, los correos y los enlaces, y compáralos con tus documentos. Si no están ahí, es un fallo. No hace falta interpretar nada.
- Usa un modelo solo cuando haga falta juicio. Para preguntas como "¿contradice esta respuesta nuestra política de devoluciones?", un modelo de IA puede ayudar, pero debe citar la línea exacta en la que se basa y marcarse como veredicto de un modelo, para que una persona pueda revisarlo.
- Nunca cuentes un resultado dudoso como aprobado. Lo que las comprobaciones no puedan resolver debe ir a una lista para que lo lea una persona.
- Guarda el conjunto de preguntas. Un bot puede responder distinto la próxima vez, y cualquier cambio en su prompt o en sus documentos puede romper algo que antes funcionaba. Vuelve a pasar las mismas preguntas tras cada cambio.
Seguimos este proceso al crear el asistente de compras de Reductivist. Antes del lanzamiento se probó con 61 preguntas, incluidas inyecciones de instrucciones y políticas inventadas, y el informe de pruebas recoge cada fallo y lo que se cambió para corregirlo.
Qué significa un aprobado y qué no
Aprobar una pregunta es una buena respuesta, no una garantía. Los modelos no son del todo predecibles, y un bot que hoy respondió bien puede responder distinto mañana. Las pruebas reducen el riesgo de que una mala respuesta llegue a un cliente. No lo eliminan. Por eso el resultado más útil de una auditoría es una lista clara y ordenada de qué corregir primero, junto con un conjunto de preguntas que puedes volver a usar.
Si quieres que lo hagamos por ti antes del lanzamiento, nuestra auditoría de chatbots prepara unas 60 preguntas a partir de tus propios documentos, revisa cada respuesta y te entrega un informe en lenguaje claro que se lee en diez minutos, además del conjunto de preguntas para que lo conserves.
Contenido relacionado

Qué es un servidor MCP y cuándo construir uno
Una guía clara sobre el Model Context Protocol: qué hace un servidor MCP, cuándo tu equipo necesita uno propio y cómo hacer que cite sus fuentes.
leer más →
Cómo bajar la factura de LLM sin perder calidad
A dónde va el gasto en APIs de LLM, los cinco cambios que más lo reducen y cómo demostrar que la opción más barata sigue respondiendo bien.
leer más →