Com construir un motor d'IA legal conforme: enrutament multimodel, RAG jurídic i el Reglament europeu d'IA a la pràctica
La majoria de productes d'IA es construeixen igual: tries un model, escrius quatre prompts i ho treus a producció. Per a un chatbot, funciona. Deixa de funcionar quan el resultat té pes legal, quan les dades estan regulades i quan una resposta errònia no és només inútil — és potencialment perjudicial.
Quan vam construir el motor d'IA de Bonus Iuri — una plataforma d'anàlisi de contractes que revisa documents legals espanyols contra la legislació real — cada decisió d'arquitectura havia d'equilibrar tres exigències contraposades: qualitat de raonament, compliment normatiu i sostenibilitat de costos a escala.
Aquest article repassa el raonament que hi ha darrere de les decisions clau. No és cap plànol per copiar — són els principis que ens van guiar en un domini on equivocar-se té conseqüències reals.
El problema central: una IA legal que no al·lucini
El repte de fons de la IA legal no és generar text que soni jurídic. Qualsevol gran model de llenguatge pot produir una anàlisi legal amb aplom. El repte és que l'anàlisi sigui correcta: que citi articles reals de lleis reals, que identifiqui riscos genuïns a partir de doctrina jurídica consolidada i que distingeixi amb claredat entre el que diu el contracte i el que exigeix la llei.
Les referències legals al·lucinades no són una molèstia menor. Un usuari que es refia d'una citació inventada de l'article 47 d'una llei que només en té 35, el producte l'ha perjudicat activament. No és un cas extrem que calgui mitigar: és el problema central que cal resoldre.
El nostre plantejament descansava sobre tres pilars arquitectònics: generació augmentada per recuperació dissenyada expressament per a text jurídic, una política estricta de verificació de cites i un enrutament intel·ligent de models que ajusta la profunditat de raonament a cada tasca.
Pilar 1: el RAG estàndard falla amb la legislació
Les implementacions estàndard de RAG trossegen els documents en blocs de mida fixa — 512 tokens, 1.000 caràcters, el valor per defecte que toqui — i recuperen els fragments més semblants a la consulta. Per a bases de coneixement generals, funciona. Amb la legislació, falla.
Els documents legals tenen una estructura interna rígida: articles, seccions, subseccions, disposicions transitòries, considerants. Un fragment de mida fixa que parteix en dos un article sobre fiances de lloguer perd la coherència semàntica que dona sentit a l'article. Pitjor encara: pot produir recuperacions que combinen el final d'un article amb l'inici del següent i crear una referència quimèrica que sembla vàlida però no ho és.
El principi: fragmentar als límits legals, no a recomptes arbitraris de tokens.
Vam construir un pipeline de fragmentació que analitza l'estructura legislativa abans de tallar. El sistema detecta els límits d'article, secció, capítol i disposició, i cada fragment es correspon amb una unitat legal completa — normalment un article amb les seves subseccions, o una secció coherent d'un capítol.
El sistema cobreix set legislacions espanyoles consolidades, obtingudes del BOE (Boletín Oficial del Estado): el Código Civil, l'Estatuto de los Trabajadores, la Ley de Arrendamientos Urbanos, dret de societats, dret mercantil, dret concursal i procediment administratiu. Cadascuna es fragmenta als límits estructurals, es vectoritza i es deduplica perquè no s'hi acumulin entrades obsoletes.
Per què importa que estigui al dia: la legislació espanyola no és estàtica. Hi apareixen esmenes i correccions contínuament. Un sistema que cita la versió antiga d'un article — esmenat fa mesos — produeix una anàlisi tècnicament incorrecta. Mantenir l'índex legislatiu al dia és un cost operatiu que la majoria de prototips ignoren. En producció, és la diferència entre una eina fiable i una font de problemes.
Pilar 2: verificació de cites — «sense font, no hi ha afirmació»
Fins i tot amb un RAG que entén la legislació, un LLM encara pot generar una anàlisi legal plausible que no es correspongui amb cap font recuperada. El model pot interpolar entre dos articles reals, o tirar de patrons de les dades d'entrenament que no s'apliquen al dret espanyol.
Vam imposar una regla estricta: tota afirmació legal del resultat ha de poder-se resseguir fins a un passatge concret recuperat. Si el sistema no pot fonamentar una afirmació en un text legislatiu real, l'afirmació no es fa.
El pipeline d'anàlisi valida les cites en temps de generació. Cada afirmació legal es contrasta amb el context recuperat: el passatge citat existeix de debò? El document font hi coincideix? La rellevància té prou pes per sostenir l'afirmació? Les afirmacions que no superen la validació es marquen; no s'inclouen d'amagat.
El resultat és una cadena de transparència: l'usuari pot resseguir qualsevol afirmació legal fins a un article concret d'una llei concreta. Aquesta traçabilitat és el que separa la IA legal útil de la IA legal perillosa — i el que dona a Bonus Iuri la credibilitat per servir professionals del dret, no només curiosos.
Pilar 3: l'enrutament de models és una decisió de producte, no només una palanca de costos
No totes les tasques d'una anàlisi legal demanen la mateixa profunditat de raonament. Enrutar-ho tot cap al model més potent (i més car) és malbaratar. Enrutar-ho tot cap al més barat dona una qualitat inacceptable en els raonaments complexos.
Vam construir una capa d'enrutament que tria el model adequat per a cada tipus de tasca, equilibrant qualitat de raonament, latència i cost:
- Detecció ràpida de riscos — la puntuació inicial tipus semàfor que diu a l'usuari si el contracte té problemes que valgui la pena investigar — fa servir un model ràpid i lleuger. Resposta en menys d'un segon, cost marginal gairebé nul.
- Anàlisi legal completa — la llista de comprovació detallada amb raonament, cites i matriu de riscos — s'enruta cap a un model amb més capacitat de raonament en diversos passos.
- Escenaris complexos que toquen més d'una llei — contractes que abasten diversos dominis jurídics — fan servir models optimitzats per encreuar referències amb cadena de pensament.
Per què això importa econòmicament: una plataforma freemium d'IA legal viu o mor dels costos unitaris. Si cada anàlisi gratuïta surt cara, escalar el pla gratuït esdevé insostenible. L'enrutament intel·ligent manté viable el pla gratuït i reserva el raonament profund per als usuaris de pagament. No és només optimització de costos: és una decisió de disseny de producte que defineix l'experiència de l'usuari a cada pla.
El compliment com a arquitectura, no com a llista de verificació
En productes d'IA regulats, el compliment normatiu sovint es tracta com un pas final de revisió: primer es construeix el producte i després es repassa la llista. Aquest plantejament falla perquè produeix arquitectures que surten molt cares de reformar a posteriori i documentació de compliment que no reflecteix com es comporta el sistema en realitat.
A Bonus Iuri, els requisits de compliment van donar forma a l'arquitectura des del primer dia:
La minimització de dades del RGPD va condicionar el model d'emmagatzematge. Els documents dels usuaris es processen amb una persistència mínima. Quan cal emmagatzemar, les dades de cada usuari queden aïllades estructuralment — no només amb controls d'accés, sinó per l'arquitectura d'emmagatzematge mateixa. A nivell d'infraestructura, l'accés creuat entre usuaris és impossible.
El dret de supressió va condicionar el cicle de vida de les dades. Eliminar el compte desencadena una cascada completa: documents, embeddings derivats i registres d'anàlisi s'esborren permanentment. No és un esborrat lògic amb neteja pendent: és immediat i irreversible.
La transparència del Reglament europeu d'IA va condicionar el format de sortida. Cada anàlisi declara amb claredat quins sistemes d'IA hi han intervingut, quines limitacions tenen i quines garanties hi ha sobre el tractament de les dades. No és un enllaç al peu cap a una política general: és una informació en context, enganxada al resultat que l'usuari té davant.
L'ètica del CCBE va condicionar el posicionament del producte. La plataforma és explícitament una eina d'anàlisi legal, no un substitut de l'assessorament jurídic. Els avisos formen part del flux de l'usuari, no estan enterrats als termes del servei.
La inversió: aproximadament una setmana d'un projecte de sis. No és poc, amb un calendari tan ajustat. Però encabir el compliment a posteriori en una arquitectura que no l'havia previst hauria costat el doble o el triple i hauria donat un resultat més feble.
Pipelines de domini, no prompts genèrics
El plantejament més simple per analitzar contractes és un sol prompt: «Analitza aquest contracte i identifica'n els riscos». El resultat és una anàlisi genèrica i superficial — l'equivalent en IA de la primera lectura d'un estudiant de dret.
Vam construir pipelines d'anàlisi especialitzats per a cada tipus de contracte. Cadascun inclou:
- Mapatge de legislació per tipus. L'anàlisi d'un contracte de treball remet al dret laboral; la d'un lloguer, a la llei d'arrendaments. El sistema recupera del marc legal pertinent, no de tot el corpus.
- Criteris d'avaluació propis del domini. Cada tipus de contracte té punts d'avaluació estructurats, derivats del que comprovaria un advocat espanyol en exercici — requisits legals concrets amb els articles concrets que els sustenten, no instruccions genèriques de «busca riscos».
- Puntuació de risc calibrada. Què és «risc alt» depèn del tipus de contracte. Que falti la clàusula de compensació en un contracte de treball és una infracció legal; que falti un SLA en un contracte de serveis és una qüestió a negociar. La puntuació recull aquestes distincions.
La diferència de qualitat és la distància entre «aquest contracte té alguns problemes potencials» i «la clàusula 7.3 fixa un període de prova de 9 mesos, que supera el màxim legal per a treballadors qualificats segons l'article corresponent de l'Estatuto de los Trabajadores».
Aquest nivell de concreció es pot veure en acció a bonusiuri.pro.
Què implica això per a altres dominis regulats
Els principis del motor d'IA de Bonus Iuri no són exclusius del legaltech. Valen per a qualsevol producte d'IA en un domini regulat:
- Recuperació que respecta l'estructura — no trossegis els documents del domini de qualsevol manera. Entén-ne l'estructura interna i conserva-la.
- Verificació de cites — si la IA no pot fonamentar una afirmació, no l'ha de fer. En dominis on hi ha molt en joc, la traçabilitat no és opcional.
- Enrutament intel·ligent — ajusta la capacitat del model a la tasca. No totes les consultes necessiten el teu model més car.
- Arquitectura conforme des del primer dia — incorpora els requisits regulatoris al model de dades i a la infraestructura, no a una llista de revisió final.
- Especialització de domini — els prompts genèrics donen resultats genèrics. Inverteix en pipelines propis del domini.
No són recomanacions teòriques. Són els principis que vam aplicar per posar en producció una plataforma d'IA legal en sis setmanes — i són directament transferibles a sanitat, finances, assegurances i qualsevol altre domini on el que diu la IA té conseqüències reals.
Estàs construint un producte d'IA en un domini regulat? Parla amb un CTO sobre com una arquitectura conforme des del primer dia pot comprimir el calendari sense abaixar el llistó.
