Detectar alucinaciones de IA: 3 medidas de control para equipos B2B

¿Cómo se manifiestan las alucinaciones de la IA en los flujos de trabajo B2B?

Una alucinación es cuando el modelo genera una respuesta que suena segura pero es incorrecta. En B2B aparece en tres formas clásicas: (1) inventar un número de pedido que no existe para una consulta de soporte, (2) "citar" una fecha que no está realmente en el contrato al resumirlo, (3) inventar una categoría nueva al clasificar facturas fuera del conjunto definido.

Las tres comparten el mismo patrón: cuando el modelo no encuentra un anclaje real, rellena el hueco. El problema es que la respuesta se expresa con seguridad — aun siendo incorrecta. Decir "la IA se equivoca" no basta para actuar; hay que detectar dónde y por qué. Las tres medidas de control siguientes hacen eso.

Tres controles: evidencia, validación y aprobación humana

Comprobación de fuentes: muestre el documento y el pasaje que respaldan la respuesta; verifique que sustentan la afirmación, no solo que existe una cita. La evidencia ausente o contradictoria debe pasar a revisión.

Comprobación de reglas: valide en la aplicación la existencia del pedido, los permisos, el importe y la categoría. Un formato válido no garantiza información correcta.

Aprobación humana: antes de un pago, reembolso o mensaje vinculante, una persona autorizada debe revisar la salida exacta. Si cambia, requiere otra aprobación. No existe un porcentaje universal de éxito. Pruebe casos correctos, erróneos y sin fuente: las salidas inválidas deben detenerse y la cola de revisión debe llegar a su responsable.

Construir un proceso de evaluación antes de lanzar

No se puede detectar una tasa de alucinaciones simplemente observando resultados a ojo; se necesita un conjunto de pruebas. Cree un conjunto de referencia de 50 a 200 ejemplos reales con respuestas correctas conocidas, y asegúrese de que cubra casos límite: datos faltantes, consultas ambiguas, solicitudes fuera de alcance. Pruebe el modelo con este conjunto después de cada cambio de instrucciones (prompt) o de modelo y antes de publicar el cambio, no solo en el lanzamiento.

Controle dos cifras por separado: la exactitud (si dio la respuesta correcta) y la tasa de abstención (con qué frecuencia decidió no responder). Un modelo que nunca se abstiene puede responder a preguntas para las que no tiene una respuesta fiable; uno que se abstiene demasiado puede resultar menos útil. La seguridad no puede evaluarse solo con esta tasa. El umbral adecuado depende del coste de dar una respuesta incorrecta frente al coste de no responder.

Las pruebas adversariales importan tanto como las pruebas de casos normales: alimente deliberadamente al modelo con consultas diseñadas para provocar alucinaciones —preguntas sobre entidades que no existen, solicitudes que mezclan dos registros, indicaciones que le piden extrapolar más allá del documento fuente—. Si no puede gestionar un fallo de forma segura en una prueba controlada, tampoco cabe esperar que lo haga en producción.

Trate esto como un proceso vivo, no como una validación puntual. Cada vez que cambie las instrucciones, sustituya modelos o añada una nueva fuente de documentos, vuelva a ejecutar el conjunto de evaluación y compare las nuevas cifras de exactitud y abstención con su referencia inicial antes de desplegar. Es la misma disciplina que las pruebas de regresión en el software tradicional; solo que aquí se evalúa el criterio en lugar de la lógica.

Qué tareas conllevan mayor riesgo de alucinación

El riesgo no depende solo de que el texto sea libre o estructurado. Un asiento contable incorrecto en una categoría válida también puede causar daños. Evalúe impacto, reversibilidad, sensibilidad de los datos y destinatarios. Preparar borradores no debe otorgar los mismos permisos que contactar con clientes o mover dinero.