Fallos de agentes de IA: ¿alucinación o falta de política?

Analizar los fallos de un agente de IA significa clasificar cada conversación fallida según su causa antes de que nadie la corrija. La mayoría de los fallos que se llaman “alucinaciones” son otra cosa: un artículo que falta, una política desactualizada o ambigua, un fallo de recuperación, una herramienta rota o una mala derivación. Cada causa tiene un responsable y una solución distintos, así que la etiqueta decide si la solución funciona.

En resumen

• “Alucinación” describe un síntoma (una respuesta errónea dada con seguridad), no una causa. Trátela como la última explicación, no como la primera.
• Diez causas cubren casi todas las conversaciones fallidas de un agente de IA en soporte, desde las lagunas de conocimiento hasta la confusión del lado del cliente.
• Una pregunta resuelve la mayoría de los casos: ¿había una fuente aprobada que respondiera a esto, y la usó el agente?
• Las causas de contenido van al responsable del conocimiento o de la política, las de herramientas a ingeniería, y solo los errores de razonamiento al equipo que ajusta el agente de IA.
• Siga cada semana la composición por causa por cada 1.000 conversaciones. Los porcentajes solos engañan, porque una causa puede crecer como porcentaje mientras baja en número.

¿Por qué los equipos llaman alucinación a cualquier fallo de un agente de IA?

Los equipos llaman alucinación a cualquier fallo porque la transcripción solo muestra el resultado: una respuesta errónea dada con seguridad. La causa está antes, en el contenido, la política, el paso de recuperación, una herramienta o las reglas de derivación. Sin un paso que clasifique la causa, gana la palabra más conocida y la corrección acaba en el prompt.

La palabra tiene un significado preciso. El perfil de riesgos de la IA generativa del NIST define la confabulación, “coloquialmente también llamada alucinación”, como la de sistemas que “generan y presentan con seguridad contenido erróneo o falso” (NIST AI 600-1, sección 2.2, en inglés). Eso cubre al modelo inventando algo. No cubre a un agente que repitió fielmente un artículo de reembolsos desactualizado, ni a uno que siguió una política que nadie puso por escrito.

La diferencia importa porque la etiqueta equivocada envía el trabajo al equipo equivocado. Un cambio de prompt no puede arreglar un artículo que no existe. Cuando la empresa de herramientas de soporte Pylon clasificó unos 200 tickets que su agente de IA escaló durante una semana de su propia cola, las lagunas de conocimiento “supusieron más de la mitad de los escalamientos” y las peticiones de funcionalidades, el 15% (Pylon, septiembre de 2026, en inglés). Son datos de una sola empresa, no una referencia del sector, pero ninguna de las dos causas es un problema del modelo.

Esta guía forma parte de nuestra guía central sobre la gestión de políticas de agentes de IA, que explica cómo se redactan, se asignan y se versionan las políticas. Aquí el foco es el paso anterior a la corrección: nombrar bien la causa.

¿Cuáles son las diez razones por las que fallan las conversaciones con IA?

Las conversaciones con IA en soporte fallan por diez razones principales: una laguna de conocimiento, conocimiento desactualizado o contradictorio, una política que falta o es ambigua, un fallo de recuperación, un error de razonamiento o alucinación, un fallo de acción o de herramienta, un fallo de derivación, un fallo de alcance, un error del producto o una petición de funcionalidad, y un problema del lado del cliente. Cada una deja una huella distinta en la transcripción.

La tabla siguiente es la taxonomía para copiar. Úsela como lista de selección en su formulario de revisión, una causa por criterio no superado.

Etiquete el criterio no superado, no la conversación entera, porque una conversación puede fallar por dos causas. Las causas 6 y 7 suelen esconderse en las cifras de contención; nuestra guía sobre los fallos silenciosos de los agentes de IA explica cómo sacarlas a la luz. Para los agentes humanos, la distinción equivalente está en nuestra guía sobre error del agente o error del proceso (en inglés).

¿Cómo se distingue una alucinación de una política que falta?

Una alucinación se distingue de una política que falta comprobando la fuente. Si una fuente aprobada y vigente respondía a la pregunta y el agente se apartó de ella, es una alucinación o un error de razonamiento. Si ninguna fuente cubría el caso, o la regla solo existe en la cabeza de los agentes veteranos, falta una política, y ningún cambio en el modelo lo arreglará.

Los cuatro pares que más se confunden:

• Alucinación frente a política que falta. La prueba es: “¿podría un agente humano nuevo, leyendo solo sus fuentes escritas, haber respondido bien?”. Si no, el agente de IA no tenía nada a lo que ser fiel.
• Alucinación frente a conocimiento desactualizado. Si el dato erróneo aparece palabra por palabra en un artículo, el agente hizo su trabajo. El fallo es el artículo.
• Alucinación frente a fallo de recuperación. Si el artículo correcto existe pero la respuesta encaja con un tema vecino, el agente respondió fielmente a partir de la página equivocada. La generación aumentada por recuperación (RAG), el método que usan muchos agentes de IA de soporte, combina un modelo con una búsqueda en su contenido (Lewis et al., 2020, en inglés), así que el paso de búsqueda puede fallar por sí solo.
• Acción alucinada frente a fallo de herramienta. “Su reembolso está en camino” sin reembolso en el sistema es o bien el agente atribuyéndose una acción que nunca hizo, o bien una llamada a una herramienta que falló sin avisar. El log de la herramienta le dice cuál de las dos. Nuestra guía sobre la auditoría de la tasa de resolución de agentes de IA explica cómo contrastar las acciones declaradas con los registros del sistema.

Nuestra guía para detectar alucinaciones de agentes de IA explica la rutina para las alucinaciones reales una vez aisladas. Esta página es el filtro que decide cuáles lo son.

El árbol de decisión: diez preguntas en orden

La forma más rápida de clasificar una conversación fallida con IA es responder una lista fija de preguntas en un orden fijo y detenerse en el primer “sí” o “no” que nombre una causa. El orden importa: descarta las causas del cliente, del producto y de los sistemas antes de culpar al contenido, y culpa al contenido antes que al modelo.

Copie esto en su formulario de revisión. Responda para un criterio no superado cada vez.

1. ¿Podría una persona haber entendido lo que quería el cliente a partir de lo que escribió? No: lado del cliente (causa 10). Sí: siga.
2. ¿Era una solicitud que el agente de IA debía atender? No, y la atendió de todos modos: fallo de alcance (causa 8). Sí: siga.
3. ¿Era el problema de fondo un defecto, o algo que el producto no hace? Sí: error del producto o petición de funcionalidad (causa 9). No: siga.
4. ¿Necesitaba el agente ejecutar o comprobar una acción (consulta, reembolso, cancelación, actualización), y esa llamada falló, agotó el tiempo de espera o fue rechazada? Sí: fallo de acción o de herramienta (causa 6). No: siga.
5. ¿Debería la conversación haber pasado a una persona, en otro momento o con mejor contexto? Sí: fallo de derivación (causa 7). No: siga.
6. ¿Hay una fuente aprobada que responda a esta pregunta? No, y la regla está clara para todos: laguna de conocimiento (causa 1). No, y la regla depende de a quién se pregunte: política que falta o es ambigua (causa 3). Sí: siga.
7. ¿Está vigente esa fuente, y es la única sobre el tema? No: conocimiento desactualizado o contradictorio (causa 2). Sí: siga.
8. ¿Usó el agente esa fuente para esta respuesta? No: fallo de recuperación (causa 4). Sí: siga.
9. ¿Coincide la respuesta con la fuente? No: error de razonamiento o alucinación (causa 5). Sí: siga.
10. ¿Es correcto el propio criterio? Si el agente siguió fielmente una fuente vigente y aprobada y aun así falló, el criterio de la scorecard puede estar mal. Envíelo al responsable de QA para calibrarlo en lugar de forzar una causa.

La pregunta 10 es la válvula de seguridad: una taxonomía que no puede decir “nuestro criterio estaba mal” culpa a quien quede. Cuente cuántas veces llega a la pregunta 9. Es el único camino que termina en “alucinación”.

¿Quién corrige cada causa y cómo se deriva?

Cada causa tiene un responsable, y lo decide el lugar donde debe hacerse la corrección: el contenido va al responsable del conocimiento o de la política, los sistemas a ingeniería, el producto al equipo de producto, y solo las instrucciones y el razonamiento al responsable de la IA. Derive la conversación con las evidencias adjuntas, nunca solo con una cifra.

Nombre a cada responsable como persona, no como equipo. Una nota de derivación necesita cuatro cosas: la causa, dos o tres conversaciones de ejemplo con las líneas que fallan marcadas, la intención afectada con su volumen semanal y la fecha en que volverá a evaluar. Sin los ejemplos, el equipo que la recibe discute la clasificación en lugar de corregir.

Corregir un agente de IA no es hacer coaching a una persona: la corrección debe cambiar el contenido o la configuración que lee el agente. Nuestro artículo sobre coaching de personas frente a corregir agentes de IA trata esa diferencia. Para las causas 6 y 8, la solución adecuada a veces es un límite, no una respuesta mejor. OWASP señala la “funcionalidad excesiva”, los “permisos excesivos” y la “autonomía excesiva” como causas de fondo de las acciones dañinas de los agentes (OWASP LLM06), y ahí es donde continúan nuestras guías sobre los guardrails de agentes de IA y los niveles de autonomía de agentes de IA.

¿Cómo se organiza un triaje semanal de fallos de la IA?

Organice el triaje de fallos de la IA como una sesión semanal de 45 a 60 minutos: reúna las conversaciones fallidas, agrúpelas por intención, clasifique los grupos principales con el árbol de decisión, derive cada causa a su responsable con ejemplos y compruebe si las correcciones de la semana pasada se mantuvieron. Clasifique grupos, no conversaciones sueltas, para que la sesión escale con el volumen.

Una rutina que funciona:

1. Lunes: reúna los fallos. Tome cada conversación con IA que no superó un criterio crítico la semana pasada (exactitud, política, acción, escalamiento). Si solo evalúa una muestra, añada cada conversación con una reapertura, una reclamación o un contacto repetido en 7 días.
2. Agrupe por intención. Reembolsos, cambios de dirección, problemas de acceso. Empiece por las cinco intenciones con más fallos.
3. Clasifique de tres a cinco conversaciones por grupo. Aplique las diez preguntas. Si coinciden, etiquete el grupo. Si se dividen, el grupo son dos problemas: sepárelo.
4. Derive. Un ticket por causa e intención, a un responsable con nombre, con los ejemplos y una fecha para volver a evaluar.
5. Revise la semana pasada. Para cada corrección publicada, compare el número de fallos de esa intención antes y después. Una corrección que no movió la cifra era la corrección equivocada o la causa equivocada.
6. Regístrelo. Una fila por grupo: semana, intención, causa, número, responsable, corrección, resultado. Este registro es su composición de fallos a lo largo del tiempo.

La dirige el responsable de QA con el responsable de la IA, el responsable del conocimiento y un responsable de operaciones de soporte. Políticas, ingeniería y producto se unen solo cuando hay un punto suyo en la lista. Los fallos de derivación a menudo solo se ven entre varias conversaciones, y ahí ayuda el QA del recorrido del cliente.

¿Cómo se mide la composición de los fallos de la IA a lo largo del tiempo?

Mida la composición de los fallos como fallos por cada 1.000 conversaciones con IA, separados por causa, cada semana, junto al porcentaje de cada causa. Las cifras por 1.000 muestran si una causa disminuye. Los porcentajes muestran dónde está el trabajo pendiente. Lea ambos, porque corregir una causa hace que las demás parezcan mayores como porcentaje aunque no haya cambiado nada.

Pylon lo vio en sus propios datos: a medida que bajaban sus lagunas de conocimiento, los informes de errores pasaron “del 8,5% de los escalamientos al 19%” (Pylon, en inglés). Un porcentaje creciente no significa por sí solo más errores: las otras partes se hicieron más pequeñas.

Un ejemplo práctico (ilustración, cifras inventadas para mostrar el cálculo)

Tome un agente de IA que atiende 12.000 conversaciones a la semana. En la semana 1, 480 no superan un criterio crítico: 40 por cada 1.000. El equipo corrige los principales grupos de conocimiento y de políticas a lo largo de cuatro semanas. En la semana 5, con el mismo volumen, fallan 290: 24,2 por cada 1.000.

Hay tres cosas que leer. Las tres causas de contenido bajaron de 260 a 95 fallos, del 54,2% al 32,8% del total. Las alucinaciones pasaron del 7,3% al 11,4% de los fallos mientras su número bajaba de 35 a 33: un responsable que solo leyera porcentajes concluiría que el modelo empeoró. Y los fallos de herramientas apenas se movieron (de 40 a 38), lo que indica que ingeniería todavía no ha publicado su corrección.

Las métricas que conviene mantener en el dashboard:

• Fallos por cada 1.000 conversaciones con IA, en total y por causa.
• Porcentaje por causa, para decidir dónde va el esfuerzo de la semana siguiente.
• Recurrencia: fallos en una intención y causa marcadas como corregidas. Por encima de cero tras dos semanas significa que la corrección no se mantuvo.
• Tiempo de corrección por responsable, desde el ticket derivado hasta la nueva evaluación.
• Tasa sin clasificar: fallos que nadie pudo ubicar. Si supera un porcentaje pequeño, la taxonomía o los criterios necesitan trabajo.

¿Cuándo no es para usted esta taxonomía?

Una taxonomía de diez causas no es para usted, o todavía no, si su agente de IA responde a unos cientos de preguntas al mes a partir de un centro de ayuda pequeño y no ejecuta acciones. Entonces bastan tres categorías: contenido (causas 1 a 3), agente de IA (4, 5, 8, 10) y todo lo demás. Pase a la lista completa cuando responsables de fuera de soporte empiecen a recibir el trabajo.

Señales de que tres categorías se le han quedado cortas: el agente ejecuta acciones en otros sistemas, tiene más de un agente de IA o más de una plataforma respondiendo a clientes, las políticas cambian más de una vez por trimestre, o dos equipos discuten cada semana de quién es un fallo. Si la misma intención sigue fallando tras las correcciones, haga un análisis de causa raíz más profundo de ese grupo concreto en lugar de añadir categorías.

Dónde encaja Kaizo

Kaizo es QA y supervisión de la gobernanza para equipos de soporte en los que personas y agentes de IA comparten el trabajo. Cubre la parte de evidencias del análisis de fallos: evaluar conversaciones, sacar a la luz las causas raíz y volver a evaluar tras una corrección. No redacta sus artículos ni sus políticas.

AutoPilot evalúa cada conversación resuelta con su propia scorecard, y en el lado del QA de agentes de IA usted añade los criterios en los que falla un agente de IA y conecta su base de conocimiento para que juzgue frente a su contenido. Cada nota enlaza con las evidencias de la transcripción. Insights convierte esas notas en causas raíz (el proceso roto, la fricción del producto, la carencia de habilidades), lo que da al triaje semanal sus grupos y ejemplos de partida.

Véalo con sus propias conversaciones. Reserve una demo y traiga una intención que su equipo considere un problema de alucinaciones.

Cómo empezar esta semana

Empiece por las peores conversaciones con IA de la semana pasada, no por una herramienta nueva. Añada las diez causas a su formulario de revisión, clasifique un lote pequeño con el árbol de decisión, nombre un responsable por causa y corrija primero el grupo de contenido más grande.

1. Pegue la tabla de las diez causas en su formulario de revisión como lista de selección obligatoria en cada criterio no superado.
2. Tome las 30 peores conversaciones con IA de la semana pasada y aplique las diez preguntas a cada una. Cuente cuántas llegan a la pregunta 9.
3. Nombre un responsable por causa, como personas, y acuerde el formato de la nota de derivación.
4. Reserve una franja recurrente de 45 minutos para el triaje y empiece el registro con los grupos de esta semana.
5. Elija el grupo de contenido más grande y corríjalo primero. Vuelva a evaluar la intención la semana siguiente. La parte de políticas del ciclo completo está en nuestra guía de gestión de políticas de agentes de IA.

Preguntas frecuentes

¿Toda respuesta errónea de un agente de IA es una alucinación?

No. Una alucinación es contenido que genera el modelo y que no está respaldado por sus fuentes ni por la conversación. Una respuesta errónea copiada de un artículo desactualizado, o una suposición ante un caso que ninguna política cubre, es un fallo de contenido. La prueba es si existía una fuente correcta y aprobada y el agente se apartó de ella.

¿Basar un agente de IA en su propio contenido evita las alucinaciones?

Basar el agente en su contenido reduce las respuestas inventadas, pero no las elimina, y añade nuevos puntos de fallo. El agente puede recuperar el artículo equivocado, citar uno desactualizado o apartarse incluso del correcto. Por eso la recuperación y el conocimiento desactualizado tienen sus propias causas en la taxonomía, separadas de la alucinación.

¿Quién debe encargarse del análisis de fallos de un agente de IA?

Normalmente el responsable de QA se encarga de la clasificación y del triaje semanal, porque la scorecard y las evidencias de revisión están en QA. Las correcciones corresponden a los responsables de cada causa: conocimiento, políticas, configuración de la IA, ingeniería, operaciones de soporte y producto. Que una sola persona sea responsable de la clasificación mantiene las etiquetas coherentes de una semana a otra.

¿Cuántas conversaciones fallidas con IA hay que clasificar cada semana?

Clasifique grupos, no cada conversación. De tres a cinco conversaciones por grupo, en las cinco intenciones con más fallos, son de 15 a 25 lecturas a la semana y suelen cubrir la mayoría de los fallos. Lea más dentro de un grupo cuando las conversaciones no coinciden en la causa.

¿Deben contar las peticiones de funcionalidades como fallos del agente de IA?

Cuéntelas, pero infórmelas aparte de los fallos propios del agente. Una petición de funcionalidad falla al cliente, no al agente, y ningún cambio de contenido o de prompt la corrige. Contarlas muestra a producto con qué frecuencia lo piden los clientes y evita que inflen la tasa de error del agente de IA.