Detectar alucinaciones de IA: 3 barreras para equipos B2B

¿Cómo se ven las alucinaciones IA en flujos B2B reales?

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 salida parece confiada — aun siendo incorrecta. "La IA se equivoca" no es accionable; hay que detectar dónde y por qué. Las tres barreras siguientes hacen eso.

Tres barreras: evidencia, validación y decisión humana

1) Evidencia verificable: pida al sistema que vincule cada afirmación importante con el documento, registro o fragmento autorizado del que procede. Si no existe evidencia suficiente, la salida debe abstenerse o pasar a revisión; una cita generada por el propio modelo no es prueba.

2) Validación determinista: antes de usar la salida, compruebe con reglas independientes los campos que sí tienen una forma conocida: identificadores, fechas, importes, categorías permitidas y relaciones entre registros. Registre qué regla falló y no convierta una respuesta inválida en una acción.

3) Decisión humana proporcional al riesgo: la IA puede preparar una propuesta, pero reembolsos, compromisos contractuales, decisiones médicas, financieras o jurídicas y cambios irreversibles necesitan una persona con autoridad y contexto. Defina por escrito qué casos pueden continuar, cuáles se escalan y cuál es el modo seguro cuando el sistema o la fuente no están disponibles.

Ninguna barrera promete un porcentaje universal de reducción. Su eficacia debe medirse con un conjunto de evaluación representativo, una línea base y pruebas adversariales propias; publique el resultado solo con su alcance, fecha y método.

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. Ejecute el modelo contra él antes de cada cambio de prompt o de modelo, no solo en el lanzamiento.

Controle dos cifras por separado: la precisión (si acertó la respuesta) y la tasa de abstención (si dijo correctamente "no lo sé" cuando debía hacerlo). Un modelo que nunca se abstiene parece seguro, pero es más arriesgado; uno que se abstiene demasiado resulta molesto pero más seguro. El umbral correcto depende de cuán costosa sea una respuesta incorrecta en comparación con una que se pospone.

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 fallar con elegancia en una prueba controlada, tampoco lo hará en producción.

Trate esto como un proceso vivo, no como una validación puntual. Cada vez que cambie el prompt, sustituya modelos o añada una nueva fuente de documentos, vuelva a ejecutar el conjunto de evaluación y compare las nuevas cifras de precisión y abstención con su línea base 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

No todas las tareas de IA conllevan el mismo riesgo, así que su presupuesto de salvaguardas tampoco debería repartirse de manera uniforme. La generación abierta —redactar un correo para un cliente, resumir una reunión, escribir textos de marketing— deja espacio para la creatividad, pero ese mismo espacio es exactamente donde se esconde la alucinación: estadísticas inventadas, citas ficticias, promesas que la empresa nunca hizo. Esta es la categoría de mayor riesgo, porque no existe una salida "correcta" fija con la que contrastar, solo un rango de resultados aceptables.

La extracción numérica y financiera queda muy cerca. Extraer un total de una factura, calcular un descuento, obtener un número de identificación fiscal: los errores aquí son silenciosos (la cifra parece plausible) y costosos (alimenta directamente el movimiento de dinero). Las afirmaciones legales y relacionadas con la medicina —obligaciones contractuales, declaraciones de cumplimiento normativo, indicaciones de dosis o de seguridad— pertenecen al mismo nivel de alto riesgo: equivocarse una sola vez y el daño resultante no es vergüenza, es responsabilidad legal.

En el otro extremo, la extracción estructurada contra un esquema fijo —analizar este currículum para obtener nombre/correo/habilidades, clasificar este ticket en una de 12 categorías, etiquetar esta transacción con un código de comercio— es comparativamente de bajo riesgo. El modelo tiene menos margen para inventar porque el espacio de salida está acotado y es fácil de validar mecánicamente: puede comprobar que la categoría existe, que el correo tiene una arroba, que el valor es una de 12 opciones. La clasificación en un conjunto cerrado pequeño se comporta de la misma manera: incluso cuando el modelo se equivoca, falla dentro de los límites que usted definió, lo cual es un modo de fallo fundamentalmente más barato.

Use este gradiente para decidir dónde invertir el esfuerzo de salvaguarda. Las tareas de bajo riesgo con esquema cerrado a menudo pueden funcionar con validación ligera y controles puntuales. Las tareas de alto riesgo, abiertas o de tipo numérico/legal, merecen el conjunto completo de la sección anterior —cita de fuentes, comprobaciones de reglas y una persona en el bucle— antes de dejar que la automatización toque a un cliente o un libro contable.