Cómo medimos las alucinaciones de una IA en producción

Cuando un proveedor de inteligencia artificial afirma que su sistema «no alucina», está describiendo una sensación, no un resultado. La única versión exigible de esa frase es una tasa de alucinación medida: sobre qué conjunto de preguntas, con qué definición de error, contra qué versión del sistema, en qué fecha y con qué intervalo de confianza. En Innova y Cree medimos así los sistemas que operamos sobre normativa chilena, publicamos las cifras congeladas con su fecha y —desde hoy— publicamos también el arnés con el que se obtienen, bajo licencia MIT, para que cualquier comprador pueda reproducir la medición contra el sistema de cualquier proveedor. Este artículo explica el estado del arte para directivos, el protocolo paso a paso, los resultados públicos, lo que el benchmark no mide, cómo exigirlo en un contrato y cómo correrlo.

Por qué «no alucina» no es una afirmación sino una medición

Un modelo de lenguaje produce texto plausible; su capacidad de sonar seguro es independiente de su exactitud. Por eso «no alucina» solo tiene sentido como el resultado de una prueba: alguien preguntó n veces, comparó cada respuesta contra una referencia y contó. Sin ese conteo, la frase describe la experiencia de quien probó tres consultas un martes, no el comportamiento del sistema.

Los marcos de gestión de riesgo lo formulan igual. El NIST AI Risk Management Framework dedica una de sus cuatro funciones, Measure, a medir con métodos documentados los riesgos identificados¹; su perfil para IA generativa nombra la confabulación —contenido falso o engañoso producido con seguridad— como uno de los doce riesgos propios de esta tecnología y pide medirla, no negarla². OWASP la recoge como Misinformation en su lista de riesgos para aplicaciones con LLM³. Un comité que compra IA para una función regulada tiene, entonces, un derecho simple: pedir el número, el método y la fecha. Lo demás es marketing.

El estado del arte, explicado para directivos

Dos trabajos definen hoy cómo se mide esto con seriedad. Conviene entenderlos porque cualquier proveedor serio debería poder decir en qué se parece y en qué se aparta de ellos.

Stanford RegLab: la tasa de las herramientas legales comerciales

En 2024-2025, investigadores de Stanford y Yale evaluaron las principales plataformas de investigación jurídica con IA del mercado estadounidense, comercializadas como «hallucination-free», con más de doscientas consultas preregistradas y evaluación por expertos⁴¹⁶. Los resultados, publicados en el Journal of Empirical Legal Studies, fijaron el estándar de la conversación: las herramientas alucinaron en una de cada seis consultas o más, y en un caso en una de cada tres.

Tres aportes del estudio son los que nosotros adoptamos. Primero, una definición operativa de alucinación en dos partes: la respuesta incorrecta (describe mal el derecho) y la mal fundada (la afirmación puede ser cierta, pero la cita no la respalda). Segundo, la distinción entre alucinar y abstenerse: un sistema que declara «no encuentro fundamento» no alucina; comete, si acaso, un error de omisión, que se cuenta aparte. Tercero, un conjunto de preguntas con trampas deliberadas: premisas falsas, casos inexistentes, preguntas cuya respuesta correcta es «eso no existe». El estudio anterior del mismo grupo había mostrado que los modelos generalistas alucinan en más de la mitad de las consultas jurídicas directas⁵; el de 2025 mostró que la recuperación con citas reduce el problema pero no lo elimina.

FACTS Grounding: qué mide y cómo

FACTS Grounding, publicado por Google DeepMind en diciembre de 2024, mide otra cosa, complementaria: si la respuesta de un modelo está completamente fundamentada en el documento que se le entregó y además responde a lo que se preguntó⁶. Cada ejemplo trae un documento largo, una instrucción y la respuesta se juzga en dos etapas: primero se descartan las respuestas que eluden la pregunta (para que abstenerse de todo no sea una forma de ganar) y luego se verifica, frase por frase, que nada afirme lo que el documento no dice⁷. El detalle metodológico que más nos importa: los jueces son varios modelos de distintos proveedores, y el resultado se promedia, porque un modelo tiende a preferir sus propias respuestas.

Lo que ambos enseñan

Estado del arte quiere decir, en la práctica, tres reglas. Una: preguntas diseñadas para inducir el error, no solo preguntas amables. Dos: juez distinto del evaluado, porque la literatura sobre «LLM como juez» documenta sesgos de posición, verbosidad y autopreferencia⁸. Tres: definición de fallo que separa lo incorrecto de lo mal fundado y ambos de la abstención. Ningún benchmark que no cumpla las tres merece ser leído como medición.

Qué entendemos por alucinación (definición operativa)

Adoptamos la rúbrica de Stanford RegLab tal cual, con cuatro veredictos para toda respuesta factual y uno adicional que se detecta por código:

La razón de contar la abstención aparte es de diseño, no de conveniencia: un asistente que responde siempre es más peligroso que uno que sabe decir «no está en el corpus». Si se penalizara la abstención como si fuera un error, el incentivo sería responder con seguridad sobre lo que no existe. Sí medimos, en cambio, la abstención innecesaria —callar cuando la respuesta estaba en el corpus— porque es el costo real de la prudencia y hay que vigilarlo en cada versión.

El protocolo, paso a paso

Paso 1 — Un conjunto de evaluación con referencia, fuente y cinco categorías

Cada ítem tiene una pregunta, la norma y el artículo cuya cita se espera, el texto oficial de ese artículo y la fuente primaria de la que se tomó, con fecha de consulta. Sin texto de referencia no hay juez posible; sin fuente no hay auditoría posible. Las preguntas factuales se redactan a partir del texto del artículo por un modelo distinto del evaluado —o por un profesional—, con una restricción que el validador del arnés impone: la pregunta no nombra el número del artículo. Si lo nombrara, mediríamos la capacidad del sistema de repetir un identificador, no de recuperar la norma correcta a partir de una necesidad real. El conjunto queda identificado por su hash: dos corridas solo son comparables si lo comparten.

El conjunto se organiza en cinco categorías, tres de ellas hostiles:

Las tres categorías hostiles existen para responder a la pregunta que un comité técnico hace primero: ¿qué pasa cuando le pido algo que no existe? Un sistema que responde con seguridad a un artículo inventado hará lo mismo con un plazo, un órgano competente o una multa. Por eso las trampas se construyen con números de artículo verificados como inexistentes contra el catálogo del corpus, y las adversariales embeben la falsedad dentro de una pregunta razonable, que es como llega en la práctica.

Paso 2 — Ejecución contra el motor por HTTP, con versión fijada

El arnés no ve el motor por dentro. Envía cada pregunta por HTTP —la misma ruta que usa un usuario— y recibe tres cosas: la respuesta, la lista de citas con su marca de verificación y la confianza declarada. Esto tiene dos consecuencias que valen para cualquier proveedor. La primera: publicar el arnés no publica el motor; se puede auditar el resultado sin entregar los componentes propietarios. La segunda: la corrida queda ligada a una versión del motor fijada y registrada. Un alias flotante («el último modelo disponible») no es una versión: si el proveedor sustituye el modelo por debajo, la cifra medida deja de describir el sistema que opera. Nuestra regla es versión fijada, aviso previo y comparación pareada antes de cualquier cambio.

Paso 3 — Evaluación determinista de todo lo que puede evaluarse por código

Las categorías trampa, fuera de corpus y adversarial no las juzga ningún modelo. Se califican por contraste directo: ¿el sistema entregó una cita marcada «verificada» que apunta al artículo inexistente? ¿Se abstuvo? ¿Qué confianza declaró? También por código se comprueba la recuperación de la cita esperada en las factuales y, con un catálogo de los artículos existentes, se recalcula cada cita que el motor marcó como verificada: si alguna apunta a un artículo que no está en el catálogo, es una cita fantasma. La lógica es la de FACTS Grounding llevada al límite: cuanto más se pueda decidir con una regla, menos depende el resultado de la opinión de un juez.

Paso 4 — Un juez independiente, calibrado contra revisión humana

Lo que sí requiere criterio —¿la respuesta es exacta, incompleta, mal fundada o incorrecta?— lo decide un juez que es un modelo distinto del evaluado, con temperatura cero, que ve la pregunta, la respuesta y el texto oficial del artículo. Antes de llamarlo, el arnés detecta por código las abstenciones y las registra como tales. Y como el juez es un modelo, no un abogado, el protocolo incluye su calibración: el arnés exporta las respuestas juzgadas a un archivo que un profesional del dominio completa a ciegas, y calcula el acuerdo juez–humano con el kappa de Cohen y una matriz de confusión, leída con la escala orientativa de Landis y Koch⁹. Un juez sin kappa publicado es una limitación declarada, no un detalle omitido.

Paso 5 — Métricas con intervalo: Wilson, «cero» acotado, abstenciones y fabricaciones

Toda tasa se reporta con su intervalo de confianza de Wilson al 95 %¹⁰, que se comporta bien con muestras moderadas y con proporciones cercanas a cero —justo donde el intervalo «normal» de los cursos introductorios falla, como muestran Brown, Cai y DasGupta¹¹. Las métricas son: exactitud (veredicto «exacta» sobre las juzgadas), tasa de alucinación (incorrecta más mal fundada), incompletas, abstenciones —distinguiendo las necesarias de las innecesarias—, fabricaciones en pruebas hostiles y citas fantasma. Y una regla de lectura: «cero» nunca se afirma, se acota. Cero fabricaciones en n pruebas hostiles no significa tasa cero: por la regla de tres, acota la tasa real a aproximadamente 3/n con 95 % de confianza. Un comité técnico refuta un «cero» en un minuto; un intervalo se sostiene.

Paso 6 — Comparación pareada McNemar antes de cambiar de modelo

Cuando cambia el modelo base, la estrategia de recuperación o el prompt del sistema, la pregunta correcta no es «¿subió el promedio?», sino «¿mejoró de verdad o cambió el ruido?». La prueba de McNemar¹² responde a eso: sobre las mismas preguntas, cuenta cuántas pasaron de fallar a acertar y cuántas de acertar a fallar, y entrega un valor p exacto sobre esos pares discordantes. Con motores no deterministas, es la única forma honesta de atribuir una mejora a un cambio. Nuestra política operativa es que ningún cambio de modelo entra en producción sin esta comparación contra la línea base; si degrada, se revierte.

Paso 7 — Congelado con fecha

Cada medición se publica con su fecha, la versión del motor, el tamaño del corpus al momento de medir y el hash del conjunto. Nunca se retoca: cuando el corpus crece o el motor cambia, una re-medición agrega una entrada nueva al historial y la anterior queda tal como se publicó. Es la única forma de que un comité que leyó una cifra en julio pueda volver en octubre y encontrarla idéntica, junto a la nueva.

Resultados públicos (medición de julio de 2026)

Las cifras siguientes corresponden a la medición del 2026-07-10 sobre un sistema en producción con corpus normativo chileno, y están congeladas con esa fecha¹³. Se reproducen aquí desde la tabla maestra de cifras del sitio; la tabla completa de veredictos con sus intervalos, la desagregación de las pruebas hostiles y la comparación pareada con la versión anterior están en la página del benchmark y en el paper técnico¹⁴.

Dos precisiones de lectura. La primera: la mejora entre versiones que reporta el valor p provino de correcciones estructurales de recuperación —no de un cambio de modelo— y la abstención innecesaria bajó a la vez sin que subiera la alucinación; ese es exactamente el patrón que la comparación pareada permite verificar. La segunda: los casos de alucinación de la corrida comparten un patrón —el sistema respondió desde un artículo vecino o una norma hermana y describió mal un detalle—, y en ningún caso inventó una norma o un artículo inexistente. Eso es lo que separa un error de matiz, detectable en segundos porque cada respuesta trae sus citas con enlace a la fuente oficial, de una fabricación.

La referencia internacional no es un ranking

Junto a nuestras cifras publicamos las del estudio de Stanford como orden de magnitud, no como comparación directa: aquellos sistemas operan sobre jurisprudencia estadounidense en lenguaje natural abierto; el nuestro, sobre normativa regulatoria chilena acotada. Lo comparable no es el número sino el método: misma definición de alucinación, mismo tratamiento de la abstención, misma exigencia de juez distinto del evaluado. El corpus, además, sigue creciendo —16 normas y 1.173 artículos al 2026-08-13— y por eso la próxima re-medición trimestral publicará su propio corte, sin tocar el de julio.

Qué NO mide este benchmark (limitaciones que declaramos)

Un benchmark que oculta sus límites es un argumento de venta. Estos son los nuestros, en el mismo orden en que un comité técnico los encontraría.

• El juez es un modelo, no un abogado. El acuerdo juez–humano (kappa) sobre esta corrida es el siguiente hito comprometido; hasta publicarlo, la tasa de alucinación es la que reporta un juez independiente calibrado por diseño pero no aún por medición.
• Un dominio acotado. El corpus evaluado es regulatorio y de tamaño conocido; cada dominio nuevo se mide con el mismo arnés antes de entrar en producción, y sus cifras son suyas, no heredadas.
• Una corrida por versión. Los motores no son deterministas: repetir la corrida da cifras parecidas, no idénticas. Por eso las cifras se leen con su intervalo y los cambios se validan de forma pareada.
• No mide latencia, costo, seguridad ni fuga de datos. Mide fiabilidad de respuestas con citas. La inyección de instrucciones, el aislamiento entre clientes o el manejo de datos personales tienen sus propias pruebas y sus propios artículos.
• La detección de abstención es por frases. Un motor que se abstiene con una redacción inusual puede quedar mal clasificado; el arnés permite reemplazar el listado y revisar a mano los casos dudosos.
• El catálogo manda. Las citas fantasma se recalculan contra el catálogo de artículos que se le entrega al arnés; si el catálogo está incompleto, la cifra hereda ese error.

Cómo puede un comprador exigir esto en un contrato

Lo que un contrato de servicios de IA suele traer es una cláusula de «mejores esfuerzos» sobre la calidad de las respuestas. Lo que debería traer es un SLA de exactitud con método pactado. Sus elementos mínimos:

Un detalle práctico: el conjunto de evaluación con normativa real no se entrega al proveedor por adelantado, y no se publica junto al motor que se evalúa. Se publican el esquema, el arnés y ejemplos sintéticos; el conjunto real lo custodia quien audita. Es la única forma de que la cifra mida al sistema y no su capacidad de estudiar para el examen.

Cómo reproducirlo con el arnés publicado

El arnés está publicado en GitHub bajo licencia MIT, en la versión 1.0.0, con cita en formato CITATION.cff y metadatos listos para Zenodo; el DOI está en trámite y se añadirá aquí y en el repositorio cuando se emita¹⁵. Es un solo archivo de Python, sin dependencias, con cinco subcomandos: validar (comprueba el esquema del conjunto), correr (ejecuta contra el endpoint, evalúa por código y llama al juez), informe (métricas con Wilson, informe Markdown y planilla para revisión humana), comparar (McNemar pareado entre dos corridas) y kappa (calibración juez–humano). Incluye un motor simulado sobre una norma ficticia y una prueba de punta a punta que corre en un minuto:

git clone https://github.com/Davidpintoi/benchmark-ia-verificable.git
cd benchmark-ia-verificable
bash pruebas/prueba-extremo-a-extremo.sh

Para correrlo contra un motor real se le indica el endpoint, el token por variable de entorno, la etiqueta de versión y —recomendado— el catálogo de artículos del corpus para recalcular las citas fantasma; las rutas dentro de la respuesta JSON del motor son configurables, así que sirve para cualquier proveedor que exponga respuesta, citas y confianza. Las fórmulas se pueden comprobar sin correr nada: la función de Wilson del arnés reproduce los intervalos publicados en la página del benchmark y la de McNemar reproduce su valor p. Quien quiera verlo funcionar contra nuestro sistema con las preguntas de su propio comité, incluidas trampas sobre artículos que no existen, puede pedirlo: la demostración en vivo es parte de nuestro proceso comercial estándar.

La lección de esa base de datos no es que la IA no sirva para el trabajo jurídico y regulatorio: es que ningún proveedor serio puede declarar el problema resuelto. Solo puede medirlo, publicarlo con su método y su fecha, y mejorarlo de forma demostrable. Ese es el estándar que aplicamos y el que un comprador tiene derecho a exigir.