La IA que inventó un caso judicial (y la arquitectura que construimos para hacerlo imposible)

Recuerdo el momento exacto en que dejé de confiar en la forma en que la mayoría de la gente construye IA legal.

Era tarde, un martes, y estaba leyendo la transcripción judicial de Mata contra Avianca. No un resumen. No un hilo de tuits. El escrito real. Un abogado había presentado un alegato citando Varghese contra China Southern Airlines, Shaboon contra Egyptair y Petersen contra Iran Air — completo con números de expediente, fechas y fallos citados textualmente. Lo bastante convincente como para que la parte contraria tuviera que ponerse a buscarlos. Los casos no existían. ChatGPT los había inventado. Y cuando el abogado volvió a ChatGPT para comprobarlo, el modelo confirmó alegremente sus propias invenciones: «Sí, esos casos efectivamente existen y pueden encontrarse en bases de datos jurídicas de prestigio».

Dejé la transcripción sobre la mesa y pensé: esto no es un problema de prompting. Es un problema de arquitectura. Y la mayor parte de la industria de la IA legal finge lo contrario.

Aquel incidente —que resultó en una multa de 5.000 dólares, una amonestación judicial y un cráter reputacional— se convirtió en el caso de estudio fundacional de lo que mi equipo en Veriprajna construye ahora: sistemas GraphRAG con citas obligatorias para IA legal. Sistemas en los que la IA físicamente no puede emitir una cita de un caso que no corresponda a una entrada verificada en un grafo de conocimiento. No «probablemente no lo hará». No puede.

Quiero explicar por qué importa esa distinción, qué hizo falta para construirlo y por qué creo que ha terminado la era de ponerle una interfaz de chatbot a un modelo fundacional y llamarlo «IA legal».

¿Por qué ChatGPT inventó un caso judicial?

Esta es la pregunta que todo el mundo hace y que casi nadie responde correctamente.

La explicación habitual es «alucinación» —una palabra tan sobreutilizada que ha perdido su valor diagnóstico—. Lo que realmente ocurrió en Mata contra Avianca es más específico y más grave. Se le pidió al modelo que encontrara precedentes sobre la responsabilidad de las aerolíneas por lesiones a pasajeros. No buscó en una base de datos. No tiene ninguna. Predijo la siguiente secuencia de palabras estadísticamente probable.

«Varghese» es un nombre plausible para un demandante. «China Southern Airlines» es un demandado plausible. Un número de expediente como «2017 WL 3245891» sigue el patrón sintáctico de las citas reales. El modelo ensambló estos fragmentos de la misma forma en que ensambla un poema o un correo de marketing: minimizando algo llamado perplejidad, que es esencialmente una medida de cuán «sorprendido» está el modelo por su propia salida. Poca sorpresa equivale a texto fluido. El texto fluido no es lo mismo que el texto verdadero.

El modelo está entrenado para minimizar la perplejidad: cuán sorprendido está por la siguiente palabra. No está entrenado para optimizar la procedencia: si esa palabra se remonta a algo real.

Esta es la tensión central. Los LLM optimizan la coherencia. El derecho exige procedencia. Son objetivos fundamentalmente distintos, y ninguna cantidad de ingeniería de prompts salva esa brecha. Puedes decirle a GPT-4 «Eres un abogado cuidadoso, cita solo casos reales». Asentirá y obedecerá —hasta el momento en que sus datos de entrenamiento no contengan el caso que necesitas, punto en el cual inventará uno que suene bien, porque sonar bien es literalmente para lo que está optimizado.

Investigadores de Stanford lo probaron con rigor. Los chatbots de propósito general, incluso los que tienen acceso a internet o capacidades básicas de recuperación, alucinaron entre el 58 % y el 82 % de las veces en consultas legales complejas. No casos límite. Preguntas rutinarias de investigación jurídica.

La trampa del wrapper

Después de Mata, empecé a catalogar las herramientas de IA legal del mercado. La mayoría eran lo que la industria llama educadamente «wrappers» —interfaces de usuario superficiales superpuestas a la API de OpenAI o de Anthropic—. Un prompt de sistema que dice «Eres un asistente legal útil». Quizá una función para subir PDF. Quizá una tipografía más bonita.

Tuve una llamada con una posible clienta —asesora jurídica general de un bufete de tamaño medio— que me contó que habían estado evaluando una de estas herramientas. «Es rápida», dijo. «Pero la semana pasada citó un voto disidente como si fuera el fallo mayoritario. Mi asociado casi lo presenta». Hizo una pausa. «Lo aterrador es que el caso era real. El fallo simplemente estaba... mal».

Eso es lo que tienen las alucinaciones legales que me quita el sueño. Mata fue espectacular porque los casos estaban enteramente inventados. Pero los errores más sutiles —caso real, fallo equivocado; ley válida, pero derogada desde entonces; precedente vinculante de la jurisdicción equivocada— son más difíciles de detectar y, podría decirse, más peligrosos. Un caso falso se detecta en el primer paso de verificación. ¿Un caso real citado para una proposición que no sostiene? Eso puede sobrevivir a varias rondas de revisión.

El enfoque wrapper no puede resolver esto porque no es dueño de la capa de datos. No sabe qué casos existen. No sabe cuáles han sido revocados. No entiende que una decisión del Segundo Circuito no vincula a un tribunal del Noveno Circuito. Es un elegante cuadro de texto conectado a un motor de probabilidad.

Y la economía es brutal. El análisis del mercado de wrappers muestra que, aunque algunos alcanzan ingresos rápidamente, la inmensa mayoría fracasa porque carece de cualquier tecnología defendible. A medida que los modelos fundacionales mejoran, cada función que hacía útil al wrapper —resumir, redactar, preguntas y respuestas— queda absorbida por el modelo base. Estás construyendo en terreno alquilado, y el casero es OpenAI.

¿Qué ocurre cuando le das a la IA un mapa del derecho?

Aquí es donde empieza la obsesión de mi equipo.

La solución estándar para la alucinación es la generación aumentada por recuperación —RAG—. En lugar de depender de la memoria del modelo, recuperas documentos relevantes de una base de datos y los introduces como contexto. Es una mejora real. Pero para el derecho no basta, y quiero explicar por qué con un ejemplo concreto que nos volvió locos durante semanas.

Estábamos probando un pipeline estándar de RAG vectorial con una pregunta sobre si una determinada regulación ambiental de 1990 seguía siendo exigible tras una decisión de la Corte Suprema de 2023. El RAG vectorial hizo lo que hace: encontró fragmentos de texto semánticamente similares a la consulta. Devolvió la regulación. Devolvió la opinión de la Corte Suprema. Devolvió un artículo de revista jurídica que discutía ambas cosas.

El LLM los cosió en una respuesta segura y bien escrita que estaba completamente equivocada. Trató el artículo de revista jurídica —un comentario académico persuasivo pero no vinculante— como si tuviera el mismo peso que el fallo de la Corte Suprema. Peor aún, pasó por alto que la regulación había sido invalidada de hecho, porque la cadena de autoridad que conectaba la regulación con la decisión invalidante pasaba por un caso de apelación intermedio que la búsqueda vectorial no había recuperado. La conexión no era semántica. Era estructural.

Recuerdo a mi ingeniera principal, a mitad de la depuración de esto, girándose hacia mí y diciendo: «El problema no es la recuperación. El problema es que los vectores no entienden las relaciones».

Tenía razón. Y esa es la clave detrás de GraphRAG —generación aumentada por recuperación basada en grafos—.

En lugar de almacenar los documentos legales como puntos aislados en un espacio vectorial, los mapeamos en un grafo de conocimiento: una red donde cada ley, caso, regulación y doctrina jurídica es un nodo, y las relaciones entre ellos —cita, revoca, distingue, interpreta, confirma— son aristas explícitas y etiquetadas. Escribí sobre la arquitectura completa en la versión interactiva de nuestra investigación.

El RAG vectorial pregunta: «Encuentra texto que se parezca a esta consulta». GraphRAG pregunta: «Encuentra la ley, recorre la arista 'interpreta' para hallar la jurisprudencia y luego recorre la arista 'revoca' para asegurarte de que sigue siendo válida».

Esa no es una diferencia sutil. Es la diferencia entre buscar en una biblioteca por intuición y buscar en ella por el catálogo de fichas, el índice de citas y el informe de Shepard's al mismo tiempo.

¿Cómo impides que una IA invente una cita?

Esta es la parte que más nos costó acertar, y es la parte de la que más orgulloso estoy.

Tener un grafo de conocimiento es necesario pero no suficiente. El grafo te da estructura. Pero el LLM sigue generando texto token a token, y en cualquier punto podría desviarse del grafo y empezar a inventar. Necesitábamos un mecanismo que no solo anime al modelo a citar casos reales, sino que le impida físicamente citar los falsos.

A esto lo llamamos decodificación restringida por grafos, y el mecanismo central es algo llamado KG-Trie.

Así funciona, en palabras sencillas. Tomamos cada entidad válida de nuestro grafo de conocimiento —cada nombre de caso, cada cita de repertorio, cada número de expediente— y construimos un árbol de prefijos (un Trie) a partir de esos identificadores. Cuando el LLM está generando texto y llega a un punto en el que está a punto de emitir una cita, se activa el mecanismo de restricción. Comprueba: ¿cuáles son los siguientes tokens válidos según el Trie?

Si el modelo ha generado «Mata v. A» —el Trie permite tokens que completen nombres de casos válidos que empiecen por esa cadena—. «Avianca» es válido. A todo lo demás se le fija la probabilidad en menos infinito. Bloqueado.

Si el modelo intenta generar «Varghese v. Chi» —el Trie no encuentra ninguna continuación válida—. La generación se detiene. El modelo se ve obligado a retroceder y o bien encontrar una cita real o bien emitir algo como «No se encontró precedente».

La IA no puede imaginar un caso porque físicamente no puede emitir la secuencia de tokens de un caso que no está en la base de datos verificada.

Esto es una garantía estructural, no una probabilística. No decimos «el modelo tiene un 95 % menos de probabilidad de alucinar». Decimos que la vía de la fabricación está cerrada. La secuencia de tokens de una cita falsa literalmente no puede producirse.

Ahora bien, quiero ser preciso sobre qué hace y qué no hace esto. Impide la fabricación —inventar un caso que no existe—. No impide la malinterpretación —citar un caso real pero extraer de él la conclusión equivocada—. Ese es un error de razonamiento, y sigue requiriendo revisión humana. Pero eliminar la fabricación es enorme. Saca de la mesa por completo el modo de fallo más catastrófico: el escenario Mata.

Hubo una noche, al principio del desarrollo, en que ejecutamos nuestra primera prueba de extremo a extremo. Alimentamos al sistema con la consulta exacta que había producido las citas falsas en Mata. El sistema restringido intentó generar «Varghese», chocó con el muro del Trie, retrocedió y devolvió un caso real con una cadena de citas válida. Mi ingeniero envió una captura de pantalla a nuestro chat grupal a la 1:47 de la madrugada. Nadie respondió con palabras. Solo una fila de emojis de fuego.

¿Por qué los wrappers no pueden hacer esto?

La gente me lo pregunta constantemente, y la respuesta es arquitectónica, no comercial.

La decodificación restringida por grafos requiere manipular las probabilidades de tokens del modelo —sus logits— en tiempo real durante la generación. Necesitas acceso al motor de inferencia a nivel de decodificación. Las API comerciales estándar como GPT-4 no exponen esto. Puedes enviar un prompt y obtener una respuesta. No puedes interceptar el proceso de generación a mitad de un token e inyectar restricciones.

Por eso construimos sobre modelos de pesos abiertos —Llama, Mistral— o desplegamos a través de endpoints empresariales que permiten bucles de decodificación personalizados. Nosotros alojamos el modelo. Controlamos el pipeline de inferencia. Inyectamos las restricciones del KG-Trie directamente en la distribución de probabilidad de cada token a medida que se genera.

Un wrapper, por definición, no puede hacer esto. Está llamando a la API de otro. Es un pasajero, no el piloto.

La parte más difícil de la que nadie habla

Construir el mecanismo de restricción fue intelectualmente satisfactorio. Construir el grafo de conocimiento que lo sustenta fue una faena ardua.

El texto jurídico es caótico de formas que harían llorar a un ingeniero de datos. Un mismo caso puede referirse como «Mata v. Avianca», «Mata», «678 F. Supp. 3d 443», «el caso Avianca» o simplemente «Id.» —una abreviatura de dos letras que significa «el caso que acabo de mencionar»—. Todas ellas deben resolverse a un único nodo canónico en el grafo. Si te pierdes una, tienes un hueco en la red de citas.

Pasamos meses construyendo pipelines de resolución de entidades que gestionan la deduplicación («Smith v. Jones, 123 F.3d 456» y «Smith, 123 F.3d at 456» son el mismo caso), la desambiguación («Smith v. Jones (1995)» frente a «Smith v. Jones (2002)» —casos distintos, mismo nombre—), y el infierno particular de resolver las referencias «Id.» mediante análisis de contexto con ventana deslizante.

Y luego está el tratamiento negativo: el sistema de «bandera roja». Un grafo de conocimiento jurídico que trate los casos revocados como autoridad válida es peor que inútil. Ingerimos señales de citador —expresiones como «revocado», «abrogado», «reemplazado»— y las codificamos como aristas de bloqueo en el grafo. Cuando el sistema recorre una ruta y topa con una arista REVOCA, esa ruta queda invalidada como autoridad vinculante. Si alguien pregunta sobre Roe contra Wade en materia de derechos reproductivos, el grafo hace aflorar de inmediato la arista REVOCA de Dobbs contra Jackson. Una búsqueda vectorial podría aun así citar con entusiasmo Roe porque el gran volumen de texto histórico que lo respalda domina las puntuaciones de similitud.

Para el desglose técnico completo del esquema del grafo, el pipeline de resolución de entidades y la arquitectura de restricción, consulta nuestro documento de investigación.

¿Qué significa esto en realidad para un bufete de abogados?

Tuve una conversación con un socio director que lo planteó sin rodeos: «No me importan los grafos de conocimiento. Me importa si mis asociados van a dejarme en ridículo delante de un juez».

Justo. Así que déjame traducirlo.

El coste de Mata contra Avianca no fue de 5.000 dólares. Fue la humillación pública, la obligación de notificar al cliente, la exposición a negligencia profesional y la señal a todo cliente potencial de que este bufete no verifica su trabajo. Para un bufete grande, un solo escrito con alucinaciones es un evento reputacional existencial.

El GraphRAG con citas obligatorias funciona como una póliza de seguro contra la fabricación. El enfoque wrapper ofrece un bajo coste inicial y una responsabilidad ilimitada. Nuestro enfoque exige una inversión real en la capa de datos y la arquitectura de restricción, pero reduce a cero el riesgo de fabricación de citas.

También hay un argumento de eficiencia que es menos obvio. Ahora mismo, si un bufete usa IA para investigar, un asociado tiene que verificar cada una de las citas. Ese paso de verificación a menudo lleva más tiempo que la propia investigación, lo que anula el propósito. Los benchmarks de GraphRAG muestran una mejora del 30-35 % sobre el RAG estándar en tareas de razonamiento de múltiples saltos —el tipo de investigación compleja, de conectar los puntos, que realmente importa en litigios—. Y lo que es más importante, dado que las citas están estructuralmente garantizadas como válidas, el papel humano pasa de «verificador de hechos» a «revisor de estrategia». No pasas tres horas confirmando que los casos existen. Pasas ese tiempo en si el argumento es persuasivo.

Cuando cada cita está verificada estructuralmente, el trabajo del abogado pasa de comprobar los hechos de la IA a pensar en la estrategia. Ahí es donde está la verdadera palanca.

Y hay una dimensión de transparencia que importa para el cumplimiento normativo. Un wrapper no puede explicar por qué eligió un caso. Un sistema GraphRAG puede mostrar la ruta de recorrido exacta: «Seleccioné el Caso A porque interpreta la Ley B y fue confirmado por el Tribunal C, que es vinculante en tu jurisdicción». Ese rastro de auditoría no es solo algo agradable de tener: se está convirtiendo en una expectativa regulatoria.

¿Hacia dónde va esto a continuación?

La industria está pasando de los chatbots a los agentes: sistemas de IA que no solo responden preguntas, sino que planifican y ejecutan tareas de varios pasos. A un agente legal al que se le pide redactar una moción de desestimación necesita investigar el estándar aplicable, encontrar jurisprudencia que lo respalde, verificar que los casos son derecho vigente, comprobar los requisitos procesales y ensamblar el argumento.

Un agente que corre sobre búsqueda vectorial no tiene mapa. Tiene un montón de documentos y una buena suposición. Un agente que corre sobre un grafo de conocimiento tiene una estructura explícita que puede recorrer: ley → casos interpretativos → reglas procesales → requisitos específicos de la jurisdicción. El grafo es la capa de planificación del agente.

Por eso creo que la inversión en infraestructura de grafos ahora rinde retornos compuestos después. Los wrappers dejan tras de sí registros de chat. Los grafos de conocimiento dejan tras de sí un mapa estructurado, creciente y cada vez más valioso de la autoridad jurídica que se vuelve más útil con cada caso añadido, cada relación codificada, cada señal de tratamiento negativo ingerida.

La objeción honesta

La gente pone reparos por dos frentes, y quiero abordar ambos directamente.

Primero: «¿No es esto simplemente Westlaw con pasos adicionales?». No. Westlaw es un motor de búsqueda para humanos. Devuelve documentos que un abogado lee e interpreta. Lo que nosotros construimos es una arquitectura de restricción para IA —un sistema que gobierna lo que la IA puede y no puede decir—. Westlaw ayuda a los abogados a encontrar derecho. GraphRAG impide que la IA lo invente. Son complementarios, no competidores.

Segundo: «¿No puedes simplemente afinar el modelo para que deje de alucinar?». Lo intentamos. Al principio de nuestro trabajo, experimentamos con el afinamiento sobre conjuntos de datos jurídicos verificados. Redujo las tasas de alucinación. No las eliminó. Un modelo afinado sigue siendo un motor de probabilidad. Es un mejor motor de probabilidad, pero «mejor» en materia de citas legales significa «equivocarse menos a menudo», y «equivocarse menos a menudo» no es un estándar que ningún tribunal vaya a aceptar. La única manera de garantizar cero fabricación es hacer que la fabricación sea estructuralmente imposible, lo que significa restringir el espacio de salida, no solo mejorar los datos de entrada.

El fin del «suficientemente bueno»

Esto es a lo que sigo volviendo. La profesión jurídica se construye sobre una premisa sencilla: cuando citas una autoridad, esa autoridad debe ser real. No probablemente real. No normalmente real. Real.

Durante los dos años posteriores a Mata, los tribunales han ido endureciendo las sanciones, emitiendo órdenes permanentes sobre la divulgación del uso de IA y dejando claro que «lo hizo la IA» no es una defensa. La profesión está trazando una línea: si usas IA, su salida debe verificarse. Y si verificar la salida lleva más tiempo que hacer el trabajo manualmente, la IA no es una herramienta: es una responsabilidad.

La era del wrapper resolvió el problema equivocado. Hizo la investigación jurídica más rápida. Necesitaba hacer la investigación jurídica fiable. Velocidad sin confianza no es más que negligencia eficiente.

Lo que construimos en Veriprajna no es un chatbot que resulta saber algo de derecho. Es un sistema de razonamiento restringido en el que cada cita es un recorrido verificado a través de un grafo de conocimiento, cada relación es explícita y auditable, y al modelo generativo se le impide físicamente cruzar hacia la ficción.

La profesión que inventó el concepto de precedente vinculante merece una IA que realmente lo respete.