RAG pe contracte și documente juridice: ce poate și ce nu

Un director juridic îți spune că are „vreo cinci mii de contracte” și vrea să le poată întreba în limbaj natural. Sună ca un caz de manual pentru RAG pe contracte și documente juridice: corpus mare, întrebări repetitive, oameni scumpi care caută manual prin dosare.

În practică, jumătate din proiectele de acest tip eșuează înainte de retrieval. Nu din cauza modelului, ci pentru că cele cinci mii de fișiere sunt scanuri strâmbe, versiuni multiple ale aceluiași contract și anexe care trimit una la alta. Iar o parte din întrebările pe care le pun juriștii nu au răspuns tehnic — au nevoie de o opinie juridică, ceea ce niciun sistem de regăsire nu livrează.

Articolul de față separă cele două categorii: ce poate face un sistem RAG pe un corpus de contracte, cu ce condiții tehnice, și ce nu poate livra indiferent de buget. Dacă ai nevoie întâi de mecanica generală, ce este RAG acoperă fundamentele; aici tratăm strict specificul juridic.

Corpusul real: ce ai de fapt când zici „contractele noastre”

Înainte de orice decizie de arhitectură, deschide zece fișiere la întâmplare din folderul juridic. Ce găsești acolo decide 70% din efortul proiectului.

Trei populații de fișiere, cu costuri diferite

Un corpus de contracte nu e omogen. Se împarte, aproape întotdeauna, în trei populații:

• PDF nativ, exportat din Word — are strat de text, se citește curat, e cazul ideal.
• Scan de document semnat — imagine pură, fără strat de text, adesea strâmbă, cu ștampile peste text și cu ultima pagină ocupată de semnături olografe.
• Fișiere Office — .docx cu track changes încă active, comentarii nerezolvate și versiuni de negociere care nu au fost niciodată semnate.

Problema e că versiunea care contează juridic — cea semnată — e de obicei cea mai proastă calitativ. Draftul curat în Word nu e documentul obligatoriu; scanul mototolit e.

Un contract nu e un fișier

În arhivele reale, un singur raport contractual înseamnă mai multe documente: contractul-cadru, două acte adiționale, patru anexe cu grile de preț, un proces-verbal de recepție. Douăsprezece fișiere pentru o singură relație comercială.

Dacă le indexezi ca douăsprezece documente independente, sistemul va răspunde din anexa 2 la o întrebare la care răspunsul corect a fost modificat prin actul adițional 1. Legătura dintre fișiere e o problemă de modelare a datelor, nu de embeddings.

Zgomotul de nomenclatură

Adaugă la asta denumiri de fișier de tipul contract_final_v3_FINAL_semnat.pdf, aceeași parte scrisă în cinci feluri (SC Alfa SRL, S.C. ALFA S.R.L., Alfa), contracte bilingve în care versiunea română și cea engleză stau în același PDF, pe coloane. Fiecare dintre aceste lucruri sparge un filtru sau un chunk. Toate se rezolvă la ingestie, nu la interogare.

Ce întreabă juriștii, de fapt

A doua sursă de eșec e presupunerea că toate întrebările sunt întrebări de regăsire. Nu sunt. Iată tipologia care apare în orice atelier cu un departament juridic, cu ce cere fiecare tip de la sistem.

Doar primele două rânduri sunt cazuri de retrieval. Al treilea e o problemă de extracție: dacă vrei să numeri clauze pe tot portofoliul, ai nevoie de un câmp structurat pe fiecare contract, populat o dată la ingestie, nu de un top-k care întoarce cinci fragmente similare. Al patrulea e o interogare pe metadate. Al cincilea nu are soluție tehnică.

Merită să faci exercițiul ăsta explicit, cu lista reală de întrebări scrisă pe hârtie, înainte de a scrie o linie de cod. Dacă din cincizeci de întrebări doar zece sunt de regăsire, întrebarea corectă e dacă îți trebuie un sistem RAG sau altceva.

OCR și pregătirea documentelor: aici se pierde sau se câștigă totul

Pentru un corpus de scanuri, calitatea OCR-ului e variabila care determină rezultatul final. Un chunk cu text corupt intră în index la fel de liniștit ca unul curat — și iese la fel de ușor într-un răspuns.

Două moduri de eșec, unul tăcut

Primul mod e vizibil: PDF-ul nu are strat de text deloc, extragerea întoarce zero caractere, documentul intră în index gol. Se prinde ușor cu o verificare de lungime.

Al doilea e tăcut și mult mai periculos: stratul de text există, dar e greșit. Diacriticele lipsesc sau sunt înlocuite (rezilierea devine rezi1ierea), cifrele dintr-o grilă de preț se amestecă între coloane, iar textul pe două coloane se citește în zigzag. Chunk-ul arată plauzibil, se indexează, se regăsește și ajunge într-un răspuns cu o cifră greșită.

Tabelele sunt cazul cel mai fragil

Grilele de preț, matricele de SLA și scadențarele sunt tabele. Majoritatea fluxurilor de OCR le liniarizează, adică pierd relația rând–coloană. Rezultatul: un chunk în care apar toate valorile, dar nu se mai știe care aparține cărui serviciu.

Pentru documentele în care tabelele contează, tratează-le separat: detectează zonele tabelare, extrage-le ca structură (rânduri și coloane), apoi serializează-le într-un format explicit în chunk — de exemplu Markdown sau perechi cheie-valoare — în loc să lași textul brut.

Un gate de acceptanță înainte de indexare

Nu trimite tot ce iese din OCR direct în index. Pune între ele un prag automat, cu câteva verificări ieftine per pagină:

1. Densitate de caractere — sub un prag minim, pagina e probabil o imagine neprocesată.
2. Proporție de cuvinte recunoscute — verifică textul contra unui dicționar românesc; sub un prag, e semn de OCR corupt.
3. Prezența diacriticelor — un document în română fără niciun ș sau ț pe zece pagini e un OCR care le-a mâncat.
4. Consistență numerică — dacă un tabel are sume care nu se adună, semnalează pagina.

Paginile care pică testul nu se aruncă: intră într-o coadă de reprocesare — alt motor de OCR, rescanare, sau verificare manuală pentru documentele cu miză mare. Pentru principiile generale de curățare a unui corpus, pregătirea documentelor pentru o bază de cunoștințe acoperă partea comună; secțiunea de față e ce se adaugă peste, pentru scanuri juridice.

Chunking pe clauze: unitatea corectă de retrieval

Împărțirea la 800 de tokeni cu suprapunere funcționează acceptabil pe documentație tehnică. Pe contracte, taie exact unde nu trebuie: în mijlocul clauzei de limitare a răspunderii.

Clauza e unitatea semantică

Un contract e deja structurat de autorii lui: capitole, articole, alineate, litere. Numerotarea aceea e o hartă gratuită. Folosește-o: detectează tiparele de numerotare (Art. 5, 5.1, 5.1.a, Capitolul V) și segmentează pe ele, cu o limită superioară de lungime pentru clauzele foarte lungi.

Un chunk devine astfel „clauza 5.2 din contractul cu Alfa SRL, versiunea semnată la 12.03.2024”, nu „fragmentul 47”. Diferența se vede direct în răspuns: poți cita ce ai regăsit.

Metadatele fac jumătate din muncă

Fiecare chunk pleacă în index cu un set fix de câmpuri: părțile, tipul de contract, data semnării, intervalul de valabilitate, versiunea, limba, fișierul-sursă și pagina. Ele permit filtrarea înainte de căutarea semantică — pe un corpus de mii de contracte, „doar contractele active de prestări servicii” reduce spațiul de căutare cu un ordin de mărime înainte ca embeddings-urile să conteze.

Trimiterile interne și clauzele scurte

Două capcane specifice contractelor:

• Trimiteri interne. „Penalitățile se calculează conform art. 8.3.” Chunk-ul regăsit e inutil singur. Ori rezolvi trimiterea la ingestie și atașezi clauza referită ca context vecin, ori răspunsul va fi incomplet într-un mod pe care utilizatorul nu-l observă.
• Clauze scurte și generice. „Prezentul contract intră în vigoare la data semnării de către ambele părți.” Aceeași frază apare, cuvânt cu cuvânt, în opt sute de contracte. Semantic sunt indistinctibile; doar metadatele și căutarea lexicală le separă. De aceea pe corpusuri juridice căutarea hibridă și reranking-ul nu sunt opționale.

Pentru alegerea concretă a strategiei și a dimensiunilor, strategiile de chunking tratează compromisurile în detaliu.

Citarea la nivel de clauză, nu de document

Aici se rupe cel mai des încrederea. Un sistem care răspunde „conform contractului cu Alfa SRL, preavizul e de 30 de zile” și atașează un PDF de 40 de pagini nu a economisit nimic: juristul tot trebuie să deschidă documentul și să caute.

Unitatea de citare = unitatea de verificare

Regula practică: citezi la granularitatea la care omul verifică. Un jurist verifică o clauză. Deci citarea trebuie să conțină documentul, versiunea, calea clauzei (Cap. IV > Art. 8.3), pagina și textul exact regăsit — nu o parafrază.

Asta cere ceva de la ingestie: păstrează, pentru fiecare chunk, poziția în documentul original (numărul paginii și, ideal, coordonatele blocului de text). Fără ancora aceea, nu poți construi butonul care duce utilizatorul direct la locul potrivit din PDF, iar verificarea rămâne manuală.

Refuzul e o funcționalitate

Când retrieval-ul nu întoarce nimic peste pragul de relevanță, răspunsul corect e „nu am găsit o clauză care să acopere asta în documentele indexate”, nu o sinteză plauzibilă din contracte vecine. Pe un corpus juridic, un răspuns inventat costă mai mult decât zece răspunsuri lipsă.

Mecanica de grounding și modul în care citarea reduce riscul de răspuns nefondat sunt tratate pe larg în reducerea halucinațiilor prin grounding și citare.

Ce nu poate livra un RAG juridic

Trei limite sunt structurale. Nu se rezolvă cu un model mai bun, cu mai multe date sau cu un prompt mai lung.

Nu dă opinii juridice

„Putem rezilia fără penalizări?” nu e o întrebare de regăsire. Răspunsul depinde de fapte care nu sunt în contract (ce s-a executat, ce corespondență există), de calificarea juridică a situației și de o judecată care angajează răspunderea profesională a cuiva. Un sistem de regăsire poate scoate clauza de reziliere și clauza de penalități. Concluzia rămâne a juristului.

Nu interpretează

Aceeași clauză poate fi validă într-un context și inaplicabilă în altul, în funcție de norme imperative, de practica părților sau de jurisprudență. Corpusul intern de contracte nu conține niciunul dintre aceste elemente. Un sistem antrenat să pară că interpretează va produce cu încredere afirmații pe care nimeni nu le-a verificat.

Nu garantează exhaustivitatea

E limita cea mai prost înțeleasă și cea mai periculoasă. Retrieval-ul întoarce ce seamănă cu întrebarea, nu ce lipsește din corpus. „Nu apare nicio clauză de neconcurență” înseamnă, tehnic, „nu am regăsit una”, nu „nu există”. Absența nu se poate demonstra dintr-o căutare top-k.

Pentru întrebările de tip due diligence — unde tocmai absența unei clauze e informația căutată — ai nevoie de extracție structurată exhaustivă pe fiecare document, cu verificare, nu de retrieval.

Cât de departe sunt uneltele specializate

Merită calibrat așteptările cu date publice. Un studiu al Stanford RegLab și HAI, publicat ulterior în Journal of Empirical Legal Studies, a evaluat unelte comerciale de cercetare juridică construite pe RAG și a constatat rate de halucinație între 17% și 33%, în condițiile în care furnizorii promovau arhitecturile respective drept lipsite de halucinații. Nu poți extrapola cifrele acelea direct la corpusul tău — sunt alt tip de întrebări, pe alt corp de documente — dar concluzia calitativă rămâne: „RAG deci zero halucinații” e o afirmație de marketing, nu una tehnică.

Consecința practică se vede în instanțe. Baza publică AI Hallucination Cases, întreținută de cercetătorul Damien Charlotin, urmărește deciziile în care instanțe din toată lumea au constatat că o parte s-a bazat pe conținut halucinat; la consultarea din iulie 2026 depășise 1.700 de cazuri identificate, față de ordinul sutelor cu un an înainte. Răspunderea nu s-a mutat niciodată pe unealtă.

Cum îți măsori propriile limite

Nu porni în producție pe baza a cinci întrebări demonstrative. Construiește un set de referință: 60–100 de întrebări reale, cu răspunsul verificat de un jurist, distribuite pe categorii de clauze. Un punct de plecare util pentru taxonomia categoriilor e CUAD, un set de date public cu 510 contracte comerciale adnotate de experți pe 41 de tipuri de clauze.

Măsoară două lucruri separat: dacă sistemul a regăsit clauza corectă (recall pe clauza-țintă) și dacă răspunsul citează exact ce a regăsit. Stabilește pragul de acceptanță înainte de a vedea rezultatele. Metricile și metodologia sunt detaliate în cum evaluezi un sistem RAG.

Versiuni, prospețime și retenție

Un contract nu e un document static. Se modifică prin acte adiționale, se prelungește tacit, expiră, iar la un moment dat iese din termenul de păstrare și trebuie să dispară.

Modelul minim de versionare

Trei niveluri, nu unul: raportul contractual (părțile și obiectul), versiunile (contract inițial, act adițional 1, act adițional 2) și clauzele din fiecare versiune. Fiecare chunk poartă intervalul în care clauza a fost în vigoare.

Default-ul de retrieval devine atunci simplu: caută doar în versiunile active la data de azi. Istoricul rămâne accesibil, dar numai când utilizatorul cere explicit o dată anterioară. Fără regula asta, sistemul va cita cu aceeași convingere o clauză modificată acum doi ani.

Ștergerea trebuie să ajungă în index

Când un document iese din retenție și e distrus fizic, vectorii lui rămân în index dacă nu ștergi explicit. Rezultatul e o clauză care apare într-un răspuns după ce dosarul a fost eliminat din arhivă — exact situația pe care politica de retenție voia să o prevină. Mecanica de ștergere și reindexare e tratată în prospețime, ștergeri și reindexare.

Termenele nu le stabilești tu

În România, păstrarea documentelor e reglementată de Legea Arhivelor Naționale nr. 16/1996 și, pentru zona financiar-contabilă, de Legea contabilității; Legea nr. 36/2023 a redus la 5 ani termenul de păstrare pentru registrele obligatorii și documentele justificative care stau la baza înregistrărilor contabile, calculați de la 1 iulie a anului următor exercițiului financiar. Termenele diferă pe categorii de documente și sunt operaționalizate prin nomenclatorul arhivistic al fiecărei companii.

Concluzia de arhitectură: indexul oglindește nomenclatorul, nu invers. Politica de retenție există deja și e stabilită de juridic — sistemul o execută, nu o rescrie. Iar când întrebarea nu mai e ce spune regula, ci „dovedește-mi că ai respectat-o în perioada X”, discuția se mută pe RAG pentru conformitate și audit intern.

Reglementare și răspundere la 2026

Întrebarea vine invariabil de la comitetul de risc: „un sistem AI pe documente juridice nu e cumva reglementat strict?” Răspunsul, la nivelul lui iulie 2026, are două straturi.

Ce înseamnă „risc ridicat” în AI Act

Regulamentul (UE) 2024/1689 listează în Anexa III, la administrarea justiției, sistemele destinate a fi folosite de o autoritate judiciară sau în numele acesteia pentru cercetarea și interpretarea faptelor și a legii. Un sistem intern care caută în contractele propriei companii nu intră acolo doar pentru că documentele indexate sunt de natură juridică. Clasificarea se face pe destinația sistemului, nu pe tipul fișierelor.

Calendarul s-a schimbat însă în 2026: prin pachetul Digital Omnibus, agreat politic în mai 2026, obligațiile pentru sistemele cu risc ridicat din Anexa III au fost amânate la 2 decembrie 2027, iar cele pentru AI încorporat în produsele reglementate din Anexa I la 2 august 2028. Data de 2 august 2026 rămâne activă pentru obligațiile de transparență din articolul 50 și pentru competențele de sancționare. Verifică textul final publicat înainte de a-ți construi calendarul intern pe aceste date.

Cine supraveghează în România

Guvernul a adoptat pe 12 martie 2026 un memorandum care desemnează autoritățile naționale competente pentru aplicarea regulamentului: ANCOM ca autoritate de supraveghere a pieței și punct unic de contact, ASF și BNR pentru sistemele cu risc ridicat din serviciile financiare, ANSPDCP pentru domeniile sensibile — între care administrarea justiției — și ADR ca autoritate de notificare.

Riscul real e altundeva

Pentru un RAG intern pe contracte, expunerea imediată nu vine din clasificarea AI Act, ci din două direcții mai banale:

• Permisiuni. Contractele conțin prețuri, comisioane, clauze de exclusivitate și, uneori, date salariale. Un index fără segmentare pe drepturi le face vizibile oricui pune întrebarea potrivită. Modelul de acces e tratat separat în controlul accesului în RAG.
• Date personale și confidențialitate. Semnatari, persoane de contact, uneori date de identificare în anexe. Plus clauzele de confidențialitate din contractele înseși, care pot restricționa transmiterea documentului către terți — inclusiv către un furnizor de model extern. Verifică restricțiile contractuale cu juridicul înainte de a alege unde rulează inferența; partea de protecție a datelor e detaliată în RAG și GDPR.

Întrebări frecvente

Poate un sistem RAG să-mi spună dacă un contract e valabil?

Nu. Poate regăsi și cita clauzele relevante, cu versiunea și pagina. Calificarea validității e o operațiune juridică, nu una de regăsire, iar un răspuns automat la o astfel de întrebare e un semnal de sistem prost proiectat.

De la câte contracte merită efortul?

Nu numărul decide, ci frecvența întrebărilor și costul căutării manuale. Sub câteva sute de documente bine denumite, o căutare full-text peste metadate curate rezolvă majoritatea cazurilor la o fracțiune din cost. Pragurile de decizie sunt detaliate în când nu folosești RAG.

Ce fac cu scanurile vechi, de calitate proastă?

Nu le rescana pe toate. Rulează gate-ul de calitate pe tot corpusul, apoi ordonează documentele care pică testul după importanță — contracte active, valoare mare, litigii în curs — și reprocesează doar vârful listei. Restul rămân indexate cu un marcaj de calitate scăzută, vizibil în răspuns.

Pot folosi un model prin API pe contracte confidențiale?

Depinde de ce ai semnat. O parte din contracte conțin clauze care restricționează transmiterea către terți, iar politica internă de clasificare a datelor poate impune procesare locală pentru anumite categorii. E o verificare juridică, nu una tehnică, și se face înainte de alegerea stack-ului.

Cum arată un răspuns bun într-un sistem juridic?

Scurt, cu citare la nivel de clauză, cu versiunea documentului menționată explicit, cu link direct în pagina PDF-ului și cu refuz clar când nu există suport în corpus. Un tipar similar, aplicat pe alt tip de corpus, apare în RAG pentru customer support.

Un proiect de RAG pe contracte se decide la inventar, nu la demo. Numără documentele, calculează ce procent sunt scanuri, scrie cele zece întrebări care trebuie să primească răspuns și marchează care dintre ele sunt de regăsire și care de opinie. Cu inventarul acela, discuția de fezabilitate durează o oră; fără el, durează un proiect.

Restul cazurilor de utilizare pe corpusuri de companie sunt adunate în hub-ul Cazuri de utilizare enterprise, iar imaginea completă a serviciului — de la arhitectură la costuri — în AI & RAG.