RAG pentru obligații contractuale: scadențe, nu pasaje

Nimeni nu a pus nicio întrebare. Asta e problema.

Contractul cu furnizorul de licențe s-a reînnoit automat pe 1 martie, pentru încă douăsprezece luni, la un preț indexat. Fereastra de denunțare se închisese cu șaizeci de zile înainte. Nimeni nu a ratat un răspuns: nimeni nu a formulat întrebarea, fiindcă nimeni nu știa că trebuie formulată în februarie.

Restul clusterului a tratat sisteme care răspund. Cineva întreabă, retrieval-ul aduce pasajele, modelul sintetizează, citarea trimite înapoi la sursă. Articolul de față tratează primul caz în care unitatea utilă nu mai e pasajul, ci obligația contractuală extrasă din el — un obiect cu titular, scadență, condiție de declanșare și consecință. Valoarea nu vine din a răspunde bine, ci din a declanșa o alertă înainte ca cineva să întrebe.

Diferența nu e de nuanță. Un sistem de regăsire e reactiv prin construcție: fără interogare, nu produce nimic. Un registru de obligații e proactiv prin construcție: produce output pe bază de calendar, nu de întrebare. Retrieval-ul rămâne — dar coboară un nivel, ca strat de dovadă sub registru, nu ca interfață principală. Dacă ai nevoie întâi de mecanica generală, ce este RAG acoperă fundamentele.

Obligația contractuală nu e un pasaj, e o înregistrare

Un pasaj e text. O obligație e un rând într-un tabel, cu câmpuri obligatorii și o stare care se schimbă în timp. Confuzia dintre cele două e motivul pentru care multe proiecte de „AI pe contracte” livrează un chatbot bun și zero alerte.

Patru câmpuri, niciunul semantic

Orice obligație monitorizabilă are minimum patru câmpuri:

• Titular — cine execută. Nu compania, ci o funcție internă concretă: responsabilul de contract, financiarul, șeful de depozit.
• Scadență — o dată calendaristică, nu o formulare.
• Condiție de declanșare — ce eveniment pornește ceasul: semnarea, recepția, prima factură, o notificare primită.
• Consecință — ce se întâmplă dacă nu se execută: penalitate, decădere dintr-un drept, reînnoire automată, reziliere.

Niciunul dintre cele patru nu se regăsește semantic. Textul „Beneficiarul va comunica obiecțiunile în termen de 30 de zile de la recepția livrării” conține o regulă de calcul, nu o dată. Data apare abia când regula se aplică peste un eveniment care trăiește în alt sistem — recepția, care e în ERP, nu în contract.

De ce top-k nu produce registrul

Căutarea semantică întoarce cele mai similare k fragmente pentru o interogare dată. Trei lucruri lipsesc din răspunsul ăsta, structural:

Ultimul rând e cel esențial. Un registru de obligații nu are utilizator care întreabă; are un job care rulează zilnic și compară scadențele cu data de azi.

Unde rămâne retrieval-ul util

Coborât un nivel, e în continuare necesar. Fiecare rând din registru poartă citarea clauzei-sursă, cu documentul, versiunea și pagina — altfel alerta e o afirmație fără probă, iar responsabilul de contract nu are pe ce să acționeze. Mecanica citării la nivel de clauză e tratată în RAG pe contracte și documente juridice; aici e stratul de sub registru, nu produsul.

A doua utilizare e verificarea punctuală: când cineva contestă un rând din registru, deschizi clauza și compari. A treia e reconstruirea registrului după un act adițional. Regăsirea e infrastructură, nu interfață.

Extracția: o dată, exhaustiv, pe fiecare contract

Registrul se populează printr-o operațiune de extracție rulată o dată pe fiecare document, la ingestie și la fiecare versiune nouă. Nu la interogare.

Metrica e recall exhaustiv per contract

Aici se schimbă criteriul de acceptanță față de restul clusterului. Un sistem de întrebări și răspunsuri se măsoară pe întrebări: din o sută de interogări, la câte a regăsit pasajul corect. Un registru se măsoară pe documente: din obligațiile reale ale contractului X, câte au ajuns în registru.

Diferența practică e că o omisiune nu produce niciun semnal. Dacă retrieval-ul ratează un pasaj, utilizatorul vede un răspuns slab și reformulează. Dacă extracția ratează o obligație, nu se întâmplă nimic — până în ziua în care consecința se produce. Un registru cu 92% recall pe un portofoliu de 400 de contracte înseamnă câteva sute de obligații pe care nimeni nu le monitorizează și pe care nimeni nu le va reclama.

Măsoară deci fals-negativele, nu precizia medie. Și măsoară-le pe tipuri de obligație separat: termenele de plată ies aproape întotdeauna bine, obligațiile de notificare și cele de a nu face ies prost, fiindcă sunt formulate indirect.

Ce arată cercetarea, și ce nu

Detectarea obligațiilor și a interdicțiilor e o sarcină de procesare a limbajului studiată cu mult înainte de valul actual. Chalkidis, Androutsopoulos și Michos au publicat în 2018, la ACL, o abordare cu rețele recurente ierarhice pentru clasificarea frazelor care exprimă obligații și interdicții, motivată explicit de nevoia firmelor și a departamentelor juridice de a monitoriza conformitatea fiecărei părți și de a popula baze de date cu informație extrasă din contracte. Formularea aceea de acum câțiva ani descrie exact arhitectura din articolul de față: extracție în bază de date, nu regăsire la cerere.

Pe partea de modele generative, un rezultat util pentru calibrare vine din ContractEval, un benchmark prezentat la workshopul NLLP 2025, care evaluează 4 modele proprietare și 15 open-source pe identificarea riscurilor la nivel de clauză folosind setul CUAD. Două observații ale autorilor contează direct aici: modelele open-source răspund mai frecvent că nu există o clauză relevantă chiar și atunci când ea este prezentă, iar modul de raționare extins îmbunătățește forma răspunsului, dar reduce corectitudinea la sarcini simple. Ambele efecte sunt fals-negative — exact modul de eșec pe care un registru nu-l semnalează singur.

Ce nu poți folosi ca reper: cifrele de acuratețe publicate de furnizorii de platforme de contract lifecycle management. Circulă procente de 95% și peste, fără eșantion declarat, fără definiție a unității măsurate și fără set de referință public. Înainte să pui o cifră într-un business case, cere forma originală, anul și compoziția eșantionului; dacă lipsește unul, omite cifra și măsoară pe corpusul tău.

Setul de referință se construiește manual, o singură dată

Ia 30-50 de contracte reprezentative pentru portofoliu — nu cele mai curate. Pune un jurist și un responsabil de contract să enumere toate obligațiile din fiecare, cu cele patru câmpuri completate. Durează câteva zile și e singura investiție care îți spune cât recall ai efectiv.

Setul ăsta se refolosește la fiecare schimbare de model, de prompt sau de furnizor. Metodologia generală de construire și de prag e în cum evaluezi un sistem RAG, iar disciplina extracției exhaustive pe corpus cu termen, în RAG pentru due diligence.

Scadența se calculează, nu se citește

O parte din scadențe sunt scrise ca atare în contract. Majoritatea nu sunt.

Trei tipuri de termen, trei surse de date

Doar primul tip trăiește complet în document. Celelalte două cer o îmbinare între clauză și un sistem operațional, iar calitatea rezultatului e limitată de calitatea evenimentelor din sistemul acela, nu de model.

Consecința de arhitectură: registrul de obligații nu stă în indexul vectorial. Stă într-o bază relațională, alături de identificatorii contractelor și ai evenimentelor, cu indexul ca sursă de citare.

Detaliile care produc alerte greșite

Zile calendaristice sau zile lucrătoare? Termenul curge de la comunicare sau de la primire? Ce sărbători legale se aplică, dacă părțile sunt în jurisdicții diferite? Fiecare dintre întrebările astea schimbă data cu câteva zile — suficient cât să ratezi o fereastră de preaviz.

Nu le rezolva cu o presupunere implicită în cod. Fă din regula de calcul un câmp explicit al obligației, extras din text și verificabil de om, astfel încât o alertă greșită să poată fi urmărită până la regula care a produs-o.

Recalcularea și „as of”

Registrul nu e o fotografie. Când apare un act adițional care mută un termen, obligațiile derivate din versiunea veche nu se corectează prin suprascriere: se închid, cu motivul și data, iar din versiunea nouă se derivă rânduri noi. Altfel pierzi exact răspunsul la întrebarea auditorului — care era termenul aplicabil în martie anul trecut.

Ține deci fiecare rând legat de versiunea de contract din care provine, cu intervalul în care a fost în vigoare. Mecanica versionării și a reindexării e în prospețime, ștergeri și reindexare, iar tiparul de răspuns raportat la un moment în trecut, în RAG pentru conformitate și audit intern.

Reînnoirea tacită: tăcerea sistemului e o decizie

Cazul care justifică singur proiectul e cel în care absența unei acțiuni produce efect juridic. Nu greșești făcând ceva; greșești nefăcând nimic.

Ce spune Codul civil

Regula generală la locațiune e că, la expirarea termenului, contractul încetează de drept, fără a fi necesară o înștiințare prealabilă (art. 1809 din Codul civil). Dar art. 1810 adaugă tacita relocațiune: dacă, după împlinirea termenului, locatarul continuă să dețină bunul și să își îndeplinească obligațiile fără vreo împotrivire din partea locatorului, se consideră încheiată o nouă locațiune, în condițiile celei vechi, inclusiv în privința garanțiilor. Noua locațiune operează pe durată nedeterminată, dacă legea sau convenția părților nu prevede altfel.

Reține construcția: nu e o prelungire a vechiului contract, ci un contract nou, născut din tăcere. Iar mecanismul se aplică prin analogie și în alte materii — la contractul de agenție, contractul pe durată determinată care continuă să fie executat de părți după expirarea termenului este asimilat celui pe durată nedeterminată (art. 2088).

Ce se schimbă după reînnoire

Trecerea pe durată nedeterminată nu e un detaliu administrativ. Schimbă regimul de ieșire pentru amândouă părțile.

Contractul încheiat pe durată nedeterminată poate fi denunțat unilateral de oricare dintre părți, cu respectarea unui termen rezonabil de preaviz, iar orice clauză contrară sau stipularea unei prestații în schimbul denunțării se consideră nescrisă (art. 1277). „Rezonabil” nu e o cifră: se apreciază după natura, obiectul și durata contractului, după investițiile făcute și după timpul necesar pentru a încheia o tranzacție de substituire.

La agenție, legiuitorul fixează totuși un minim: preavizul trebuie să fie de cel puțin o lună în primul an de contract și crește cu câte o lună pentru fiecare an suplimentar început, fără să depășească 6 luni; dacă părțile nu convin altfel, termenul expiră la sfârșitul unei luni calendaristice (art. 2089). Când un contract pe durată determinată s-a prelungit pe durată nedeterminată, la calculul preavizului se ia în considerare întreaga perioadă, nu doar cea de după prelungire.

Verifică forma consolidată în vigoare înainte de a hardcoda un termen — numerotarea și conținutul se pot schimba între republicări, iar pentru contractele cu consumatori și pentru sectoarele reglementate se adaugă reguli proprii, care nu se deduc din dreptul comun.

Obiectul monitorizat e fereastra, nu data de expirare

Consecința operațională e simplă și aproape întotdeauna implementată greșit. Registrul nu monitorizează 31.12.2026, ci data limită de transmitere a denunțării, calculată înapoi din expirare, minus preavizul, minus timpul intern necesar pentru decizie și pentru transmiterea prin canalul convenit.

Din trei termene se compune un singur rând: expirarea, preavizul contractual și fereastra internă de decizie. Alerta pleacă la începutul ferestrei, nu cu o săptămână înainte de expirare, când singura opțiune rămasă e să negociezi din poziție proastă.

Alerta e un artefact, nu o notificare

Un e-mail automat care spune „contractul X expiră în 45 de zile” nu e un livrabil. E un semnal care mută munca înapoi la om, fără să-i dea nimic din ce îi trebuie ca să acționeze.

Scadența singură nu produce efectul juridic

Un detaliu pe care sistemele îl ratează constant: în dreptul român, simpla ajungere la scadență nu îl pune, de regulă, pe debitor în întârziere. E nevoie de o notificare, în afară de cazul în care părțile au stipulat expres că simpla împlinire a termenului produce acest efect, sau de cazurile în care legea prevede întârzierea de drept (art. 1522-1523). Mai mult, cazurile de întârziere de drept trebuie dovedite de creditor.

Traducerea în cerințe de sistem: alerta nu e finalul fluxului, ci începutul lui. Ce contează juridic e actul trimis, canalul pe care a plecat și dovada că a ajuns. Un registru care semnalează impecabil și nu păstrează urma notificării a rezolvat jumătate din problemă — jumătatea ieftină.

Ce conține o alertă utilă

Șapte elemente, nu unul:

1. Obligația, formulată ca acțiune, nu ca citat.
2. Titularul — o persoană, nu un departament.
3. Data limită de acțiune, nu data scadenței finale.
4. Consecința neexecutării, formulată concret.
5. Citarea clauzei-sursă, cu documentul, versiunea și pagina.
6. Acțiunea propusă, cu documentul de ieșire pregătit dacă e standardizat.
7. Butonul care închide bucla: executat, amânat cu motiv, nu se aplică.

Ultimul punct transformă alerta în stare. Fără el, registrul nu știe niciodată ce s-a făcut, iar a doua lună nimeni nu mai citește notificările.

Închiderea buclei

Pasul de acțiune — deschiderea unui tichet, generarea unei notificări, programarea unei revizuiri — e chiar tiparul tratat în agentic RAG și multi-hop, aplicat aici pe un declanșator de calendar în loc de o interogare. Iar rezultatul, arhivat cu dovada lui, e artefactul pe care îl cere auditorul.

Accesul se filtrează la nivel de rând din registru, nu la afișare: un contract conține prețuri, comisioane și uneori date personale, iar o alertă e la fel de sensibilă ca pasajul din care provine. Modelul e cel din controlul accesului în RAG.

Ce strică sistemul în lunile 2-6

Un registru care funcționează la lansare se degradează previzibil. Patru cauze acoperă majoritatea cazurilor.

Zgomotul

Dacă alertezi la 90, 60, 30 și 7 zile pentru fiecare obligație din 400 de contracte, produci câteva mii de notificări pe an. Oamenii filtrează, apoi ignoră, apoi ratează exact obligația care conta.

Prioritizează după consecință, nu după apropierea datei. O reînnoire tacită pe un contract de 200.000 de euro pe an și un raport trimestrial de rutină nu merită același tratament. Un prag de valoare și o clasificare a consecinței, aplicate la extracție, reduc volumul cu un ordin de mărime.

Actul adițional care mută termenul

Registrul derivat dintr-o versiune veche nu se corectează prin editare manuală. Se re-derivă din versiunea nouă, iar rândurile vechi se închid cu motiv. Orice flux care permite editarea directă a unei scadențe în registru, fără trasabilitate la clauza-sursă, produce în șase luni un registru pe care nimeni nu-l mai crede.

Obligațiile fără titular

Un rând cu titular gol nu e monitorizat, oricât de bine ar fi extras. Iar titularul e o funcție care se schimbă: oamenii pleacă, echipele se reorganizează. Leagă titularul de un rol din structura internă, nu de un nume, și tratează rândurile orfane ca defecte de sistem, nu ca date lipsă. Aceeași disciplină de proprietar și dată de revizuire se aplică și pe registrul de riscuri, cu diferența că acolo scadența nu e a unei obligații asumate, ci a unei reevaluări.

Efectul care nu se vede în calendar

Unele obligații produc efecte în afara operațiunilor: penalități probabile, garanții care se activează, angajamente care se traduc în provizioane. Registrul e sursa naturală pentru discuția aceea, dar tratamentul contabil se decide după alt referențial — subiect tratat separat în RAG pentru finanțe și raportare.

Iar dacă la inventar constați că ai 40 de contracte, toate cu termene fixe, într-un folder bine denumit — nu ai nevoie de extracție automată, ci de un tabel și de un calendar partajat. Pragurile de decizie sunt în când nu folosești RAG.

Întrebări frecvente

De la câte contracte merită construit un registru automat?

Nu numărul decide, ci câte obligații relative la evenimente ai și cât de dispersate sunt versiunile. Cu 40 de contracte cu termene fixe, un tabel întreținut manual e suficient. Cu 300 de contracte, acte adiționale frecvente și termene care depind de recepții sau de facturi, întreținerea manuală cedează în câteva luni — de obicei tăcut.

Pot lăsa sistemul să trimită singur notificarea de denunțare?

Nu fără confirmare umană. Denunțarea produce efecte juridice și e greu de retras, iar canalul și forma sunt de regulă stabilite prin contract. Modelul funcțional e sistemul care pregătește documentul, atașează dovada clauzei și cere o singură aprobare, apoi arhivează confirmarea de transmitere.

Cum arată răspunsul când cineva contestă un rând din registru?

Cu clauza-sursă citată la nivel de articol, versiunea documentului și regula de calcul care a produs data. Fără cele trei, discuția degenerează în opinii. Formatul general al unui răspuns care își arată sursele e în cum arată un răspuns bun de RAG.

Ce fac cu contractele care nu au strat de text?

Le tratezi ca pe orice corpus de scanuri, cu un prag de calitate înainte de extracție — altfel obligațiile ies cu date greșite, iar greșeala e invizibilă. Partea de pregătire a documentelor juridice e detaliată în RAG pe contracte și documente juridice.

Cine validează că extracția e corectă și cât durează?

Un jurist plus responsabilul de contract, pe eșantionul de referință, o singură dată la început și apoi la fiecare schimbare majoră de model sau de prompt. Pentru 30-50 de contracte adnotate complet, socotește câteva zile de muncă — mai puțin decât costă o singură reînnoire tacită ratată pe un contract mediu.

Începe cu un inventar de o oră, nu cu o platformă. Ia zece contracte active la întâmplare, scrie pentru fiecare toate obligațiile cu titular, scadență și consecință, apoi verifică în ce sistem intern se vede fiecare dintre ele. Numărul de rânduri care nu se văd nicăieri e dimensiunea reală a problemei — și e, de obicei, mai mare decât se așteaptă oricine din cameră.

Dacă ai un portofoliu de contracte care se reînnoiește singur și vrei o a doua opinie pe arhitectura registrului, trimite un mesaj. 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.