Legora elevó la precisión de las citas jurídicas del 70% al 99% sin acceder a los datos

El equipo de Legora afronta un problema incómodo, pero cada vez más habitual: su agente jurídico trabaja con documentos confidenciales, mientras que los desarrolladores no pueden limitarse a abrir una traza y comprobar dónde se desvió el modelo. Los datos pertenecen a los clientes de los bufetes. Por tanto, el ciclo habitual de «encontrar una mala respuesta, leer la consulta y corregir el prompt» no funciona aquí.

Legora plantea la evaluación de otra manera. Ingenieros y abogados crean entornos de prueba similares al trabajo real: salas con miles de archivos y tareas para localizar cláusulas en contratos, preparar borradores y verificar citas. No son copias perfectas de los asuntos de los clientes, pero constituyen un banco de pruebas suficientemente cercano como para detectar errores recurrentes antes del lanzamiento.

Cómo evaluar lo que no se puede ver

Imaginemos un agente al que se encarga revisar 10.000 contratos y elaborar una tabla con el plazo de vigencia, el derecho de rescisión, las penalizaciones y un enlace al fragmento original. En un proyecto real, el desarrollador no tiene derecho a leer ni los contratos ni las respuestas del agente. Sin embargo, puede crear un conjunto artificial con la misma estructura: documentos largos, anexos contradictorios, campos ausentes y varias formulaciones de una misma cláusula.

Después, el equipo define de antemano las respuestas correctas y mide cada etapa por separado: si se encontró el documento adecuado, si se extrajo la cláusula, si la conclusión coincide con la fuente y si la cita conduce al lugar correcto. En una entrevista, el CTO de Legora, Jacob Lauritzen, describe un equipo específico de ingenieros y abogados que construye estos entornos. Se parecen a los «mundos» de videojuegos utilizados para entrenar agentes: el sistema recibe una tarea realista, pero no entra en contacto con el expediente privado del cliente.

Cuando aparece un fallo en datos reales, Legora procura no trasladar el texto original fuera del entorno protegido. El equipo utiliza ejemplos anonimizados o parafraseados y reduce los problemas a 10–20 tipos. Por ejemplo, el agente puede seleccionar una versión incorrecta del contrato, perder una excepción a una regla o aportar una cita que parece convincente, pero no respalda la conclusión. Esa categoría de fallo ya puede reproducirse en un conjunto seguro.

Las métricas importan más que una demostración impecable

El ejemplo de las citas resulta especialmente revelador. Según Lauritzen, en una de las pruebas el modelo indicaba correctamente las fuentes en cerca del 70% de los casos. Tras otra actualización del modelo subyacente, la cifra aumentó hasta el 99%, aunque Legora no había modificado su propio sistema. Es una buena noticia para el producto, pero también una advertencia: la calidad del agente no depende únicamente de su código. El proveedor del modelo puede corregir de repente un punto débil o romper algo que funcionaba ayer.

Por eso, una única puntuación global no basta. Se necesitan evaluaciones separadas de la búsqueda, la extracción de datos, las citas, el trabajo con documentos largos y la cumplimentación de tablas. No se debe lanzar un modelo nuevo solo porque responda mejor a unas cuantas preguntas manuales. Hay que ejecutarlo sobre un conjunto fijo de tareas y compararlo con la versión anterior en cada escenario crítico.

Qué puede adoptar un producto convencional

El enfoque de Legora no solo resulta útil para los abogados. Un asistente bancario, un agente médico o un buscador corporativo se enfrentan al mismo límite: el producto debe mejorar, pero los datos sin procesar no pueden entregarse a los desarrolladores. La fórmula práctica consta de cuatro partes: describir los flujos de trabajo reales, construir equivalentes seguros, etiquetar los resultados esperados y mantener un catálogo de fallos recurrentes.

La limitación es evidente: una simulación siempre es más pobre que la realidad. No mostrará una formulación poco común, una estructura de archivo extraña ni un error que solo surge con una combinación concreta de documentos. Por eso, las pruebas sintéticas no sustituyen los comentarios protegidos de los usuarios ni las métricas agregadas del producto. Aportan algo distinto: un entorno reproducible en el que se pueden cambiar el modelo, la búsqueda y la interfaz sin acceder a secretos ajenos.

La principal conclusión para el desarrollador es sencilla: si las trazas son privadas, la observabilidad no desaparece; hay que diseñarla. No empiece registrándolo todo, sino elaborando una lista de las decisiones de las que responde el agente y de los indicadores medibles de un resultado correcto. Así, la privacidad deja de ser una excusa para la ausencia de evaluaciones y se convierte en una restricción alrededor de la cual se construye el sistema de ingeniería.