Construir un motor de IA legal que cumple la normativa: enrutamiento multimodelo, RAG jurídico y el Reglamento Europeo de IA en la práctica
La mayoría de los productos de IA se construyen igual: eliges un modelo, escribes unos cuantos prompts y lanzas. Para un chatbot, vale. Pero no vale cuando la salida tiene peso jurídico, cuando los datos están regulados y cuando una respuesta errónea no es solo inútil, sino potencialmente dañina.
Cuando construimos el motor de IA detrás de Bonus Iuri — una plataforma de análisis de contratos que revisa documentos legales españoles contra legislación real — cada decisión de arquitectura tuvo que equilibrar tres exigencias en tensión: calidad de razonamiento, cumplimiento normativo y sostenibilidad de costes a escala.
Este artículo recorre el razonamiento detrás de las decisiones clave. No es un plano que puedas copiar, sino los principios que nos guiaron en un dominio donde equivocarse tiene consecuencias reales.
El problema central: una IA legal que no alucina
El reto fundamental de la IA legal no es generar texto que suene jurídico. Cualquier modelo de lenguaje grande puede producir un análisis legal con tono convincente. El reto es producir análisis correctos: que citen artículos reales de leyes reales, que identifiquen riesgos genuinos basados en doctrina jurídica consolidada y que distingan con claridad entre lo que dice el contrato y lo que exige la ley.
Las referencias legales alucinadas no son una molestia menor. Un usuario que se apoya en una cita inventada del artículo 47 de una ley que solo tiene 35 artículos ha sido perjudicado activamente por el producto. No es un caso límite que mitigar — es el problema central que resolver.
Nuestro enfoque se apoyó en tres pilares de arquitectura: generación aumentada por recuperación diseñada específicamente para texto legal, una política estricta de verificación de citas y un enrutamiento inteligente de modelos que ajusta la profundidad de razonamiento a lo que pide cada tarea.
Pilar 1: el RAG estándar falla con la legislación
Las implementaciones estándar de RAG trocean los documentos en bloques de texto de tamaño fijo — 512 tokens, 1.000 caracteres, el valor por defecto que toque — y recuperan los bloques más parecidos a la consulta. Funciona para bases de conocimiento generales. Con la legislación, falla.
Los documentos legales tienen una estructura interna rígida: artículos, secciones, subsecciones, disposiciones transitorias, considerandos. Un bloque de tamaño fijo que parte en dos un artículo sobre fianzas de alquiler pierde la coherencia semántica que da sentido al artículo. Peor aún: puede producir recuperaciones que combinan el final de un artículo con el principio de otro, creando una referencia quimérica que parece válida pero no lo es.
El principio: trocear en los límites legales, no en recuentos arbitrarios de tokens.
Construimos un pipeline de fragmentación consciente de las secciones que analiza la estructura legislativa antes de dividir. El sistema detecta los límites de artículos, secciones, capítulos y disposiciones. Cada fragmento corresponde a una unidad legal completa — normalmente un artículo con sus subsecciones, o una sección coherente de un capítulo.
El sistema cubre siete legislaciones españolas consolidadas obtenidas del BOE (Boletín Oficial del Estado): el Código Civil, el Estatuto de los Trabajadores, la Ley de Arrendamientos Urbanos, derecho de sociedades, derecho mercantil, derecho concursal y procedimiento administrativo. Cada una se fragmenta en sus límites estructurales, se vectoriza y se deduplica para que no se acumulen entradas obsoletas.
Por qué importa la frescura: la legislación española no es estática. Las modificaciones y correcciones aparecen con regularidad. Un sistema que cita la versión obsoleta de un artículo — uno que se modificó hace meses — produce análisis técnicamente incorrectos. Mantener al día el índice legislativo es un coste operativo que la mayoría de los prototipos ignora. En producción, es la diferencia entre una herramienta fiable y un riesgo legal.
Pilar 2: verificación de citas — «sin fuente, no hay afirmación»
Incluso con un RAG consciente de la legislación, un LLM puede generar análisis legales que suenan plausibles pero no corresponden a ninguna fuente recuperada. El modelo puede interpolar entre dos artículos reales, o recordar patrones de sus datos de entrenamiento que no aplican al derecho español.
Impusimos una regla estricta: toda afirmación legal en la salida debe poder rastrearse hasta un pasaje recuperado concreto. Si el sistema no puede fundamentar una afirmación en un texto legislativo real, esa afirmación no se hace.
El pipeline de análisis valida las citas en el momento de la generación. Cada afirmación legal se contrasta con el contexto recuperado: ¿existe realmente el pasaje citado? ¿Coincide el documento de origen? ¿Es la relevancia lo bastante fuerte para sostener la afirmación? Las afirmaciones que no superan la validación se marcan, en lugar de colarse en silencio.
El resultado es una cadena de transparencia: el usuario puede rastrear cualquier afirmación legal hasta un artículo concreto de una ley concreta. Esa trazabilidad es lo que separa la IA legal útil de la IA legal peligrosa — y es lo que da a Bonus Iuri la credibilidad para servir a profesionales del derecho, no solo a consumidores curiosos.
Pilar 3: el enrutamiento de modelos es una decisión de producto, no solo una palanca de costes
No todas las tareas de un análisis legal requieren la misma profundidad de razonamiento. Enrutarlo todo por el modelo más potente (y caro) es un despilfarro. Enrutarlo todo por el modelo más barato produce una calidad inaceptable en las tareas de razonamiento complejo.
Construimos una capa de enrutamiento que selecciona el modelo adecuado según el tipo de tarea, equilibrando calidad de razonamiento, latencia y coste:
- Detección rápida de riesgos — la puntuación inicial tipo semáforo que le dice al usuario si su contrato tiene problemas que merece la pena investigar — usa un modelo rápido y ligero. Respuesta en menos de un segundo, coste marginal casi nulo.
- Análisis legal completo — la lista de comprobación detallada con razonamiento, citas y matriz de riesgos — se enruta a un modelo con capacidades de razonamiento multipaso más sólidas.
- Escenarios complejos con varias leyes — contratos que abarcan varios dominios jurídicos — usan modelos optimizados para el cruce de referencias con cadena de razonamiento.
Por qué importa económicamente: una plataforma de IA legal freemium vive o muere por su economía unitaria. Si cada análisis gratuito sale caro, escalar el nivel gratuito se vuelve insostenible. El enrutamiento inteligente mantiene viable el nivel gratuito y reserva el razonamiento más profundo para los usuarios de pago. No es solo optimización de costes — es una decisión de diseño de producto que da forma a la experiencia de usuario en cada nivel.
El cumplimiento como arquitectura, no como lista de comprobación
En los productos de IA regulados, el cumplimiento normativo suele tratarse como un paso final de revisión: construye el producto y luego marca las casillas. Este enfoque falla porque produce arquitecturas carísimas de adaptar a posteriori y documentación de cumplimiento que no refleja el comportamiento real del sistema.
En Bonus Iuri, los requisitos de cumplimiento dieron forma a la arquitectura desde el primer día:
La minimización de datos del RGPD definió el modelo de almacenamiento. Los documentos de los usuarios se procesan con persistencia mínima. Cuando hace falta almacenar, los datos de cada usuario quedan aislados estructuralmente — no solo mediante controles de acceso, sino por la propia arquitectura de almacenamiento. El acceso cruzado a datos entre usuarios es imposible a nivel de infraestructura.
El derecho de supresión definió el ciclo de vida de los datos. Eliminar la cuenta desencadena una cascada completa: documentos, embeddings derivados y registros de análisis se borran de forma permanente. No es un borrado lógico con limpieza eventual — es inmediato e irreversible.
La transparencia del Reglamento Europeo de IA definió el formato de salida. Cada análisis incluye una declaración clara de los sistemas de IA implicados, sus limitaciones y las garantías sobre el tratamiento de los datos. No es un enlace al pie hacia una política genérica — es una declaración en contexto, adjunta al resultado que el usuario está leyendo.
La ética del CCBE definió el posicionamiento del producto. La plataforma es, de forma explícita, una herramienta de análisis legal, no un sustituto del asesoramiento jurídico. Los avisos están integrados en el flujo del usuario, no enterrados en los términos de servicio.
La inversión: aproximadamente una semana de un proyecto de seis. En un plazo ajustado, eso pesa. Pero adaptar el cumplimiento a posteriori sobre una arquitectura no conforme habría costado dos o tres veces más y habría producido un resultado más débil.
Pipelines de dominio en lugar de prompts genéricos
El enfoque más simple para el análisis de contratos es un único prompt: "Analiza este contrato e identifica riesgos." Ese enfoque produce análisis genéricos y superficiales — el equivalente en IA de la primera lectura de un estudiante de Derecho.
Construimos pipelines de análisis especializados para cada tipo de contrato. Cada uno incluye:
- Mapeo de legislación específico por tipo. Un análisis de contrato laboral remite al derecho laboral. Un análisis de alquiler remite a la ley de arrendamientos. El sistema recupera del marco legal relevante, no de todo el corpus.
- Criterios de evaluación específicos del dominio. Cada tipo de contrato tiene puntos de evaluación estructurados, derivados de lo que comprobaría un abogado español en ejercicio: requisitos legales concretos con referencias normativas concretas, no instrucciones genéricas de "buscar riesgos".
- Puntuación de riesgo calibrada. Lo que constituye «alto riesgo» varía según el tipo de contrato. Que falte una cláusula de indemnización en un contrato laboral es una infracción legal. Que falte un SLA en un contrato de servicios es un punto de negociación. La puntuación refleja estas distinciones.
La diferencia de calidad es la que va de "este contrato tiene algunos problemas potenciales" a "la cláusula 7.3 fija un período de prueba de 9 meses, que supera el máximo legal para trabajadores cualificados según el artículo correspondiente del Estatuto de los Trabajadores."
Puedes ver este nivel de concreción en acción en bonusiuri.pro.
Qué implica esto para otros dominios regulados
Los principios detrás del motor de IA de Bonus Iuri no son exclusivos del legaltech. Se aplican a cualquier producto de IA en un dominio regulado:
- Recuperación consciente de la estructura — no trocees los documentos del dominio de forma arbitraria. Entiende su estructura interna y presérvala.
- Verificación de citas — si la IA no puede fundamentar una afirmación, no debe hacerla. La trazabilidad no es opcional en dominios de alto riesgo.
- Enrutamiento inteligente — ajusta la capacidad del modelo a los requisitos de la tarea. No toda consulta necesita tu modelo más caro.
- Arquitectura con el cumplimiento por delante — incorpora los requisitos regulatorios al modelo de datos y a la infraestructura, no a una lista de revisión final.
- Especialización de dominio — los prompts genéricos producen resultados genéricos. Invierte en pipelines específicos del dominio.
No son recomendaciones teóricas. Son los principios que aplicamos para poner en producción una plataforma de IA legal en seis semanas — y son directamente transferibles a sanidad, finanzas, seguros y otros dominios donde la salida de la IA tiene consecuencias reales.
¿Estás construyendo un producto de IA en un dominio regulado? Habla con un CTO sobre cómo una arquitectura que pone el cumplimiento por delante puede comprimir tus plazos sin recortar en calidad.
