Los casos de alucinaciones de IA jurídica superan los 2000: qué construir

Más de 2000 resoluciones judiciales sobre contenido alucinado por IA: por qué no bastó con el RAG y patrones de diseño de mi trabajo en IA para contratos.

A fecha de 14 de septiembre de 2026, la base de datos AI Hallucination Cases de Damien Charlotin recoge 2041 resoluciones de juzgados y tribunales sobre contenido alucinado por IA. En la mayoría, un tribunal constató o dio a entender que una de las partes se había apoyado en ese contenido; de forma excepcional, la base de datos incluye también algunas en las que se alegó el uso de IA sin que llegara a confirmarse. La recuperación de documentos, por sí sola, no es la solución: tres de las principales herramientas de investigación jurídica, evaluadas en 2024 en un estudio dirigido por Stanford, alucinaron cada una entre el 17 y el 33 % de las veces. Lo que hay que construir es una estructura que haga verificable la salida, una persona que decida y un conjunto de evaluación creado antes que nada.

Fui ingeniero de IA en Kartez Contract; esto es lo que conservaría de aquel trabajo y lo que haría primero.

Qué enseña a los desarrolladores la base de datos de casos de alucinaciones de IA, y qué no

La cifra de Charlotin ya supera las 2000. Antes de citarla en una presentación comercial o en un informe de riesgos, conviene tener claras tres cosas.

Cuenta resoluciones, no errores. La base de datos «no recoge el universo (necesariamente más amplio) de todas las citas falsas ni del uso de IA en escritos procesales». Es un registro de errores que llegaron a un juez, no una tasa de alucinación.

No culpa a las herramientas. Su propia nota advierte que la mención de una herramienta «no significa necesariamente que esa herramienta fuera responsable de las alucinaciones en cuestión», así que nada de lo que se dice aquí vincula una resolución de la base de datos con una herramienta. Las herramientas que se nombran más abajo proceden del estudio de Stanford, no de la base de datos.

Las categorías importan más que el total. En la base de datos de Charlotin, 1690 resoluciones llevan la etiqueta Fabricated (inventado), 854 la de Misrepresented (tergiversado) y 548 la de False Quotes (citas falsas), y una misma resolución puede llevar varias etiquetas. Comprobar que la fuente citada existe puede detectar la mayor parte del primer tipo, las referencias jurídicas inventadas. Esa comprobación deja pasar los otros dos siempre que la fuente sea real pero la cita sea inventada o su interpretación, errónea. Una herramienta de contratos puede cometer ambos errores mientras señala una cláusula que existe.

Charlotin recoge además 1174 resoluciones en las que quien usó la IA era una parte que litigaba sin abogado, representándose a sí misma (pro se), y 811 en las que era un abogado, así que una herramienta de IA jurídica no puede dar por hecho ni que haya un abogado de por medio ni que este vaya a detectar sus errores. El derecho contractual (Contract), con 449 resoluciones, es el área jurídica más representada en su base de datos. Se trata de litigios sobre contratos en los que estaba en cuestión contenido alucinado por IA, no de contratos redactados por IA.

¿Evita el RAG las alucinaciones de la IA jurídica?

No. El estudio dirigido por Stanford que se analiza más abajo concluye que la generación aumentada por recuperación (RAG) aplicada al ámbito jurídico «puede reducir las alucinaciones en comparación con los sistemas de IA de propósito general (en este caso, GPT-4), pero las alucinaciones siguen siendo considerables, de amplio alcance y potencialmente insidiosas». «Insidiosas» es la palabra justa: una respuesta mal fundamentada llega con una fuente real adjunta. Para el diseño general de guardrails, véase guardrails contra las alucinaciones en RAG.

El estudio dirigido por Stanford: entre el 17 y el 33 %

En un artículo publicado en arXiv el 30 de mayo de 2024, investigadores de Stanford y Yale presentaron «la primera evaluación empírica prerregistrada de herramientas de investigación jurídica basadas en IA». Prerregistrada significa que el estudio y su conjunto de datos de más de 200 consultas jurídicas se registraron antes de realizar la evaluación, como salvaguarda frente a la elección de consultas a la medida de los resultados. Algunos proveedores habían promocionado la recuperación como una forma de «eliminar» o «evitar» las alucinaciones. El estudio halló que Lexis+ AI, Westlaw AI-Assisted Research y Ask Practical Law AI alucinaron cada una entre el 17 y el 33 % de las veces, y que «las afirmaciones de los proveedores son exageradas».

La definición importa más que la horquilla. Una respuesta se considera alucinada «si es incorrecta o está mal fundamentada» (misgrounded), y mal fundamentada significa que las proposiciones clave «se citan, pero malinterpretan la fuente o remiten a una fuente no aplicable». Las herramientas se evaluaron en 2024, en investigación jurídica y no en contratos, así que la horquilla no es una cifra válida para la IA jurídica actual. La categoría, en cambio, sí se traslada: en un contrato, una respuesta mal fundamentada suena bien y señala la cláusula equivocada.

El hallazgo de Google sobre el contexto suficiente: más contexto, menos abstenciones

El artículo «Sufficient Context» distingue los errores en los que el modelo usa mal un contexto adecuado de aquellos en los que el contexto nunca bastó para responder. Los modelos más grandes que evaluó, de Google, OpenAI y Anthropic, «a menudo dan respuestas incorrectas en lugar de abstenerse cuando el contexto no es» suficiente.

La entrada de blog que Google Research publicó sobre ese trabajo (14 de mayo de 2025) señala que, aunque el RAG «en general mejora el rendimiento global, paradójicamente reduce la capacidad del modelo de abstenerse de responder cuando corresponde». En el ejemplo de Google, Gemma dio respuestas incorrectas en el 10,2 % de las preguntas sin contexto y en el 66,1 % con contexto insuficiente.

La recuperación cambia lo que ve el modelo, no su capacidad de saber si tiene suficiente. Una pregunta sobre la extinción del contrato puede depender de una definición o de una cláusula de preaviso que nunca se recuperó. El diseño tiene que convertir «necesito otra sección» en una salida normal, y la evaluación tiene que ponerlo a prueba.

Revisión de contratos con IA: los fallos que importan

Una cláusula inventada genera responsabilidad para quien firma, así que un modelo que se inventa una es peor que no tener ningún modelo. Estos son los fallos contra los que diseñaría en primer lugar. Ninguno de los patrones siguientes demuestra que una respuesta sea correcta; la mayoría hace que una respuesta errónea se pueda detectar.

Patrones de diseño de IA para contratos en Kartez Contract

De noviembre de 2025 a julio de 2026 trabajé como ingeniero de IA en Kartez Contract, un espacio de trabajo trilingüe para contratos, con interfaz de derecha a izquierda, un asistente de redacción, un recorrido de revisión y un estudio de contratos. Reconstruí y amplié el motor de IA que hay detrás de esos flujos, partiendo de las primeras cadenas básicas de IA del cliente, y construí el copiloto que clasifica cada petición, encuentra las cláusulas pertinentes y planifica ediciones en todo el contrato.

Los problemas más difíciles fueron la recuperación y el anclaje, y el anclaje se resolvió con estructura, no con confianza. Ninguno de los seis patrones siguientes es una garantía medida; los cuatro primeros son las propias restricciones de anclaje.

Respuestas basadas solo en las cláusulas que seleccionó el copiloto

El contrato del usuario se dividía siguiendo su propia estructura, incluidos los artículos, cláusulas y notas (ماده، بند، تبصره) que los contratos persas numeran a su manera. Para responder a una pregunta solo se usaban las secciones pertinentes, y el copiloto tenía instrucciones de avisar cuando necesitaba secciones que no se le habían mostrado.

La cláusula es una unidad con la que un abogado ya trabaja, así que un conjunto recuperado formado por cláusulas es algo que un evaluador puede etiquetar y comprobar. La instrucción ofrece una alternativa a adivinar, pero no es una compuerta de obligado cumplimiento, de modo que el conjunto de evaluación necesita preguntas que las cláusulas seleccionadas no puedan responder. La recuperación en persa tiene sus propias trampas, analizadas para otro sistema en búsqueda híbrida para RAG en persa.

Correcciones que citan el contrato literalmente

Cada corrección sugerida tenía que citar palabra por palabra la redacción actual, para poder localizarla y sustituirla, e incluía un texto de sustitución listo para usar. Esa exigencia es lo que hace posible la validación de cita exacta: un programa puede confirmar que el texto citado existe antes de aplicar la corrección.

Que una reescritura sea acertada es una cuestión de criterio jurídico. Que exista la frase que sustituye es una comparación de cadenas. La guía de OWASP sobre desinformación en los LLM plantea el argumento general: «validar automáticamente las salidas clave, especialmente las procedentes de entornos de alto riesgo». Si volviera a construirlo, descartaría cualquier corrección cuya cita no se encontrara, nunca la aplicaría de forma aproximada y contaría los descartes como señal de alerta temprana.

Estas correcciones forman parte del recorrido de revisión, que no se había probado por completo cuando se detuvo el trabajo, así que el patrón se sostiene por su lógica, no por una medición.

Esquemas de salida fijos, nunca mostrados en bruto

Cada análisis devolvía una estructura fija, de modo que cronologías, registros de riesgos y correcciones se presentaban siempre de la misma manera. Una respuesta mal formada pasaba por un proceso de análisis sintáctico y reparación en varias etapas, que incluía reparar respuestas cortadas, y se reintentaba con más margen cuando hacía falta. Nunca se mostraba en bruto al usuario.

Así se ataca un fallo silencioso: una lista de riesgos truncada parece completa a quien la lee. La reparación por sí sola no lo resuelve, porque una lista cortada a la que se le cierra la estructura sigue siendo sintácticamente válida; por eso yo reintentaría o marcaría un truncamiento reparado, en lugar de mostrarlo como si estuviera completo. Un esquema también da a las demás comprobaciones un lugar conocido donde buscar.

Baja aleatoriedad al redactar

Al redactar, el modelo funcionaba con baja aleatoriedad. Eso aporta repetibilidad, no exactitud: la misma entrada tiende a producir el mismo borrador, así que se pueden reproducir los fallos y comparar las ejecuciones de evaluación.

Flujos guiados, no un único chat para todo

Redactar, revisar y editar son trabajos distintos, y cada uno necesita su propio flujo guiado, no una única ventana de chat. La revisión, por ejemplo, se redacta desde la posición del usuario, así que su primer paso pregunta qué papel desempeña en la operación.

El artículo «Building effective agents» de Anthropic usa «workflow» (flujo de trabajo) en el sentido de orquestación: «sistemas en los que los LLM y las herramientas se orquestan mediante rutas de código predefinidas». Según el artículo, estos flujos «ofrecen previsibilidad y coherencia en tareas bien definidas». Cada paso fijo tiene una forma de entrada y de salida conocida que se puede comprobar. Un chat en blanco acepta cualquier cosa y devuelve cualquier cosa.

Ediciones resaltadas que el usuario acepta o rechaza

La regla en los tres flujos era que la IA propone y el usuario decide. Las ediciones del copiloto se resaltaban en el editor para que el usuario las aceptara o rechazara. Una instrucción que afectaba a todo el contrato, como cambiar el nombre de una de las partes, se planificaba primero, se aplicaba en cada sección afectada y se resaltaba.

El usuario evalúa cambios marcados en lugar de releer el documento, y un cambio de nombre queda resaltado en cada lugar donde se aplicó, en vez de descubrirse más tarde como una incoherencia.

Otro sistema: las compuertas del asistente de este sitio

Nada de lo que se describe en esta sección formó parte de Kartez Contract. El asistente de este sitio, que he construido y mantengo, responde solo a partir del contenido del propio sitio, y lo hace tras una serie de compuertas deterministas.

Algunas preguntas se rechazan mediante patrones antes de recuperar nada: tarifas y disponibilidad, datos privados, especulación, intentos contra el prompt del sistema y peticiones de tareas, como escribir código o traducir un texto. Si una pregunta no trata sobre mí y ningún resultado recuperado supera un umbral mínimo de puntuación de recuperación, el asistente se niega a responder y nunca se llega a llamar al modelo. Las preguntas sobre mí también se reconocen mediante patrones, por indicios como mi nombre o un pronombre de tercera persona, y no se rechazan solo porque ningún pasaje supere el umbral. En su lugar, el modelo recibe los registros del propio sitio, entradas de su CV, sus casos de estudio, sus artículos y sus servicios, con la instrucción de responder con un token fijo si no cubren la pregunta; el lector ve entonces la misma negativa. Mientras la respuesta se emite en streaming, una compuerta por frases comprueba cada frase completa antes de mostrarla:

• Rango de citas. Cada marcador de cita apunta a una fuente que se le dio al modelo.

• Cita obligatoria. Cada frase sustantiva lleva un marcador.

• Respaldo de valores. Cada número, URL y dirección de correo electrónico aparece en una fuente que la frase cita.

• Voz. Ninguna frase usa pronombres de primera persona como yo, mí o nosotros.

Basta una frase que no supere la compuerta para detener la respuesta, y esa frase nunca se muestra. Los marcadores de cita se comprueban y después se eliminan, así que los lectores nunca los ven.

El mecanismo se explica en guardrails para LLM en streaming. La demo «RAG frente a sin RAG» emite en streaming una respuesta fundamentada real junto a una columna sin recuperación que, por diseño, permanece vacía; pregunte algo que no trate sobre mí y que el sitio no cubra, y la ejecución se detendrá antes de llegar a ningún modelo. Si estuviera construyendo una herramienta de contratos, añadiría el mismo tipo de comprobación para importes, fechas y nombres de las partes, con la exigencia de que cada valor coincida palabra por palabra con la fuente.

Cómo evaluar la IA jurídica: construir primero el conjunto de evaluación

El orden habitual es construir y después medir. En IA jurídica, yo lo invertiría.

1. Una restricción de diseño es una hipótesis. «Las correcciones deben citar el contrato literalmente» es una regla. Con qué frecuencia la incumple el modelo es un número, y solo un conjunto de evaluación lo produce.

2. Cada cambio necesita una prueba de regresión. Sin un conjunto fijo, cada cambio de modelo, de prompt o de recuperación se juzga a ojo.

3. El conjunto sobrevive al proyecto. Un conjunto etiquetado y su última ejecución son evidencia que otra persona puede aprovechar. Una lista de principios de diseño, no.

Qué pasó en Kartez Contract

El cliente detuvo el encargo un mes antes de su finalización, cuando las dificultades financieras derivadas de la guerra cortaron la financiación. Fue un fallo de financiación del cliente, no un fallo en la entrega. Para entonces, el asistente de redacción, el estudio de contratos con su copiloto y la interfaz trilingüe estaban construidos y conectados de extremo a extremo. El recorrido de revisión estaba construido en sus cinco pasos, pero no se había probado por completo y seguía perfeccionándose cuando se detuvo el trabajo.

No existe ninguna cifra de precisión, porque el encargo se detuvo antes de construir un conjunto de evaluación formal. Las restricciones de diseño eran reales; el número que las habría convertido en una afirmación nunca llegó a obtenerse.

Un conjunto de evaluación de IA para contratos desde la primera semana

Esto es una recomendación, no la descripción de algo que tuviera Kartez Contract. Cada elemento se evalúa de forma binaria: se supera o no se supera.

• Preguntas con respuesta, etiquetadas con su cláusula. La respuesta debe ser correcta y basarse en esa cláusula.

• Preguntas que el contrato no puede responder. Se espera «necesito la sección X» o «el contrato no lo dice», no una respuesta.

• Peticiones de edición. Cada fragmento citado en una corrección propuesta debe coincidir como cadena con el documento de origen.

• Ediciones de todo el contrato. Renombrar una parte debe cambiar todas sus apariciones y nada más.

• Valores que no deben moverse. Importes, fechas, plazos de preaviso y nombres de las partes, comparados literalmente antes y después de cada reescritura.

• Salidas defectuosas. Las respuestas truncadas o mal formadas nunca deben llegar en bruto a la pantalla, y un truncamiento reparado nunca debe mostrarse como completo.

• Estructura persa. Numeración por ماده, بند y تبصره, líneas con dirección mixta y dígitos persas.

• Los dos lados de la operación. El mismo contrato revisado desde la posición de cada parte.

Plazos del Reglamento de IA de la UE tras el Digital Omnibus: una visión de ingeniería

• El Parlamento adoptó el texto final el 16 de junio de 2026, y el Consejo, el 29 de junio de 2026.

• El marcado del contenido generado por IA debe aplicarse a más tardar el 2 de diciembre de 2026 en los sistemas introducidos en el mercado antes del 2 de agosto de 2026.

• Las demás obligaciones de transparencia del artículo 50, como informar a los usuarios de que están interactuando con un sistema de IA, se aplican desde el 2 de agosto de 2026.

• Las obligaciones para los sistemas de alto riesgo autónomos del anexo III se aplazan al 2 de diciembre de 2027. Para la IA integrada en productos cubiertos por la legislación de seguridad del anexo I, la fecha es el 2 de agosto de 2028.

Determinar el ámbito de aplicación corresponde a un asesor jurídico. Ninguno de los patrones anteriores es una medida de cumplimiento normativo.

Lista de comprobación para construir o comprar IA jurídica

• ¿En qué se fundamenta cada respuesta? En una cláusula o una sección, no en «el documento».

• ¿Se puede localizar cada edición? Cada cambio cita el texto que sustituye, contrastado con el documento.

• ¿Puede decir que la respuesta no está? Pida una demostración.

• ¿Se valida la salida antes de mostrarla? Las respuestas defectuosas se reparan o se retienen.

• ¿Cambia algo sin que se acepte? No debería cambiar nada.

• ¿Hay un flujo para cada tarea? Redacción, revisión y edición no deberían compartir un mismo chat.

• ¿Se comprueban los valores literalmente? Importes, fechas y nombres de las partes, frente a la fuente.

• ¿Puedo ver el conjunto de evaluación? Qué contiene, qué elementos ponen a prueba la abstención y cuándo se ejecutó por última vez.

Si está definiendo el alcance de un sistema de IA para contratos o de IA jurídica, el Diagnóstico de proyecto convierte cinco preguntas en un primer esbozo de arquitectura.

Preguntas frecuentes

¿Cuántos casos de alucinaciones de IA han llegado a los tribunales?

A fecha de 14 de septiembre de 2026, la base de datos AI Hallucination Cases de Damien Charlotin recoge 2041 resoluciones de juzgados y tribunales sobre contenido alucinado por IA. En la mayoría, un tribunal constató o dio a entender que una de las partes se había apoyado en ese contenido; de forma excepcional, se incluyen algunas en las que se alegó el uso de IA sin que llegara a confirmarse. Registra resoluciones, no todas las citas falsas ni todos los usos de IA en escritos procesales.

¿Reduce el RAG las alucinaciones en la IA jurídica?

Las reduce, pero no acaba con ellas. En un estudio prerregistrado dirigido por Stanford, tres herramientas de investigación jurídica basadas en recuperación alucinaron menos que GPT-4, pero aun así cada una alucinó entre el 17 y el 33 % de las veces cuando se evaluaron en 2024. La investigación de Google sobre el contexto suficiente halló que los modelos más grandes a menudo responden de forma incorrecta en lugar de abstenerse cuando el contexto recuperado no basta.

¿Puede la IA revisar contratos de forma fiable?

No si se basa en la confianza. Lo que sí se puede construir es una revisión que haga verificables los errores: respuestas a partir de cláusulas seleccionadas, correcciones que citan el contrato literalmente, esquemas de salida fijos y una persona que acepta o rechaza cada cambio. Si una herramienta detecta de verdad los errores es algo que hay que medir, así que pida su conjunto de evaluación.

¿Qué es la validación de cita exacta?

Es una comprobación de que el texto que cita una corrección propuesta existe, palabra por palabra, en el documento actual antes de aplicar la corrección. Requiere una regla por la que cada corrección cite la redacción que sustituye, y convierte parte de una edición jurídica en una comparación de cadenas.

¿Por qué no hay una cifra de precisión para Kartez Contract?

El cliente detuvo el encargo un mes antes de su finalización por motivos de financiación relacionados con la guerra, antes de que se construyera un conjunto de evaluación formal. Este sitio no estima cifras que no ha medido. Esa carencia es la razón por la que este artículo defiende construir primero el conjunto de evaluación.

Fuentes

• Damien Charlotin, AI Hallucination Cases Database, última actualización el 14 de septiembre de 2026, consultada el 17 de septiembre de 2026 (CC BY 4.0).

• Varun Magesh, Faiz Surani, Matthew Dahl, Mirac Suzgun, Christopher D. Manning y Daniel E. Ho, «Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools» (2024).

• Hailey Joren, Jianyi Zhang, Chun-Sung Ferng, Da-Cheng Juan, Ankur Taly y Cyrus Rashtchian, «Sufficient Context: A New Lens on Retrieval Augmented Generation Systems» (2024).

• Google Research, «Deeper insights into retrieval augmented generation: The role of sufficient context» (14 de mayo de 2025).

• OWASP GenAI Security Project, «LLM09:2025 Misinformation».

• Anthropic, «Building effective agents» (19 de diciembre de 2024).

• Freshfields, «EU AI Act unpacked #34: The final Digital Omnibus on AI» (10 de julio de 2026).

• Caso de estudio de Kartez Contract, en este sitio.