Investigadores de Fudan y Ant Group lograron que un LLM siguiera un procedimiento juridico basado en grafos

Casi todos los abogados utilizan IA, pero muy pocos confian en ella. El problema no es que el modelo pueda confundir hechos. Es mucho mas peligroso que omita en silencio un paso del procedimiento y entregue un informe impecable al que le falta algo. Analizamos TG-RAG, un enfoque que intenta resolver precisamente este problema, y las lecciones que puede extraer cualquiera que desarrolle agentes para sectores regulados.

La brecha entre lo posible y lo real

Segun un estudio de Anthropic de marzo de 2026, en teoria los modelos pueden realizar casi el 90% de las tareas de las profesiones juridicas, mientras que en la practica la IA cubre alrededor del 20%. Una encuesta de ILTA muestra que el 94% de los bufetes utiliza o prueba IA generativa, frente al 80% un año antes. Sin embargo, la mayoria de las herramientas sigue en fase piloto. En Rusia se observa una situacion similar: cerca del 88% de los abogados ya trabaja con redes neuronales, pero el 84% teme recibir informacion poco fiable y el 80% se ve obligado a verificar cada resultado.

El autor del analisis, el linguista aplicado Sergei Slepukhin, situa la raiz del problema en la separacion del conocimiento. Ya sabemos almacenar conocimiento declarativo—lo que establecen las normas y la practica—en bases vectoriales y de grafos. El conocimiento procedimental—como actuar—suele permanecer en prompts y archivos como skills.md, es decir, en el mismo tipo de texto que los propios datos. Para un LLM no existe una frontera entre datos e instrucciones, por lo que, durante un dialogo largo, se aleja gradualmente de la instruccion original. Esto es instruction drift, un fenomeno que los autores de TG-RAG denominan deriva cognitiva.

Como funciona TG-RAG

La idea es sencilla. El razonamiento de un modelo de razonamiento es texto normal situado entre las etiquetas <think> y </think>. Si se dispone de un modelo abierto en un servidor propio—por ejemplo, Qwen o DeepSeek R1-Distill sobre vLLM—se controla la plantilla del chat y es posible añadir ese texto en nombre del modelo. Este lo continuara como si fuera un pensamiento propio y no lo distinguira del texto generado por el mismo.

El sistema se basa en esta propiedad. Un procedimiento experto, o SOP, se formaliza como un grafo: los vertices son pasos analiticos y las aristas definen el orden y las condiciones de transicion. El programa ejecuta el grafo por si mismo. Al llegar al limite de un paso, interrumpe la generacion, inserta en el razonamiento la instruccion del siguiente paso y aporta el conocimiento necesario justo en ese momento. El procedimiento marca el rumbo, mientras que la busqueda en la base de datos funciona de manera selectiva en lugar de volcarlo todo en un unico contexto.

Un ejemplo es el due diligence para adquirir una participacion en una LLC. Tras solicitar los documentos, el trabajo se divide en varias lineas: asuntos corporativos, activos, contratos, impuestos, litigios, deuda y quiebra, regulacion y sanciones. Todas confluyen en una matriz de riesgos. Aqui hacen falta tanto un proceso multi-hop—recopilar hechos de distintas fuentes—como uno multi-step—recorrer cada rama en orden—. El error puede no ser un hecho incorrecto, sino un paso omitido que resulte dificil de detectar durante la revision.

Limitaciones y como abordarlas

La primera limitacion es tecnica: se necesita acceso al prompt sin procesar y a la plantilla del chat. Las API cerradas no permiten insertar texto en el razonamiento, al menos no de esta forma. Por tanto, el enfoque queda vinculado a modelos abiertos desplegados en infraestructura propia, algo que no siempre supone una desventaja para abogados que manejan datos confidenciales.

La segunda limitacion es metodologica. Alguien debe crear el grafo del procedimiento, y esa es una tarea para un experto. Este debe describir el SOP y las condiciones de transicion, y el grafo debe mantenerse al dia cuando cambian las normas. El enfoque resulta adecuado para tareas con un procedimiento estandar o describible, pero no para analisis creativos abiertos. Ademas, no existen benchmarks reconocidos para el derecho en lengua rusa, por lo que es dificil medir la mejora de forma honesta. El autor lo senala expresamente y promete para la segunda parte un experimento con datos propios y un analisis de las limitaciones. En esta parte todavia no se presentan resultados de los autores del articulo.

La conclusion practica para desarrolladores y equipos de producto es la siguiente: si el agente trabaja en un ambito con un procedimiento estricto—derecho, compliance, medicina o finanzas—hay que dejar de guardar ese procedimiento en el prompt. Debe trasladarse a una estructura explicita, como un grafo, y ejecutarse mediante software. El conocimiento debe suministrarse paso a paso. Asi, el resultado es mas facil de auditar: en lugar de revisar toda la cadena de razonamiento, se comprueba si se recorrieron los nodos obligatorios del grafo.