RAG pentru conformitate și audit intern: nu doar răspunsul

Un auditor nu te întreabă ce spune politica. Te întreabă să dovedești că ai respectat-o, în perioada pe care o verifică el, cu artefacte pe care le poate deschide și data. Asta separă un sistem de RAG pentru conformitate și audit intern de orice altă căutare în documentația companiei.

Diferența pare mică. Nu e. Toate celelalte cazuri de utilizare pe documentație internă se termină când răspunsul e corect: utilizatorul citește, înțelege, își vede de treabă. Aici răspunsul corect e doar începutul. Trebuie să fie și defensabil în fața cuiva care nu te crede pe cuvânt și care are mandat să ceară dovada.

Articolul de față tratează cazul ca pe unul distinct, nu ca pe o variantă de căutare în documente. Ce se schimbă: legătura dintre politică și artefactul-dovadă, versionarea cu interval de valabilitate, provenanța ca parte din răspuns și granița față de un GRC clasic. Dacă ai nevoie întâi de mecanica generală, ce este RAG acoperă fundamentele.

Întrebarea auditorului nu e întrebarea utilizatorului

Într-un helpdesk intern sau într-o bază de cunoștințe, întrebările converg spre „cum fac X”. Într-un audit, converg spre „arată-mi”. Sunt trei forme distincte, cu trei cerințe tehnice diferite.

Trei forme de întrebare care par una singură

Forma 1 — conținutul regulii. „Care e frecvența obligatorie de revizuire a conturilor privilegiate?” E o întrebare de regăsire clasică. Un sistem de retrieval peste politici răspunde bine, cu citare la nivel de secțiune.

Forma 2 — dovada execuției. „Arată-mi că revizuirea conturilor privilegiate a avut loc în trimestrul I 2025.” Aici răspunsul nu e în politică. E într-un export de log, un tichet aprobat, un proces-verbal, o captură de configurare. Politica spune ce trebuia făcut; dovada spune că s-a făcut, când și de către cine.

Forma 3 — starea la o dată din trecut. „Care era politica de retenție în martie 2025?” Un index care conține doar versiunea curentă nu poate răspunde onest la asta. Poate răspunde plauzibil, ceea ce e mai rău.

Doar prima formă e rezolvată de un retrieval standard peste text. A doua cere o legătură între documente de tipuri diferite. A treia cere o dimensiune temporală explicită.

Un răspuns greșit devine o afirmație de conformitate

Aici e asimetria de cost care justifică tratamentul separat. Într-un helpdesk, un răspuns greșit produce un tichet reluat. Într-un audit, un răspuns greșit intră într-un dosar, e transmis unui auditor sau unui client și devine o declarație pe care organizația o susține.

Consecința nu e o corectură ulterioară, ci o constatare — și, în cazurile proaste, o problemă de credibilitate care contaminează restul dosarului. Un auditor care prinde o afirmație nesusținută nu corectează afirmația aceea; extinde eșantionul.

De aici regula de proiectare care structurează tot restul: sistemul răspunde cu dovada atașată sau spune explicit că nu are dovada. Nu există a treia variantă. O sinteză convingătoare fără artefact nu e un răspuns parțial, e un pasiv.

Legătura politică → control → dovadă

Un sistem de conformitate nu operează pe un singur tip de document. Operează pe trei, iar valoarea lui stă în legătura dintre ele — legătură pe care retrievalul peste text nu o produce singur.

Modelul minim de date

Trei entități, legate explicit:

• Politica — documentul normativ intern, cu versiune și interval de valabilitate. Textul lui e ceea ce indexezi integral.
• Controlul — obligația operațională care decurge din politică, cu un identificator stabil, un responsabil și o frecvență. Un control nu e un paragraf de text; e o înregistrare.
• Artefactul-dovadă — exportul, tichetul, aprobarea, captura de configurare, lista de participanți la instruire. Are o perioadă acoperită, un sistem-sursă și un identificator în acel sistem.

Legătura control → artefact e cea care lipsește în majoritatea implementărilor eșuate. Ea nu se deduce din text: nicăieri în exportul de log nu scrie „acesta e dovada pentru controlul 8.2”. Ori o creezi la ingestie, ca relație, ori nu o ai niciodată.

De ce top-k nu construiește singur legătura

Retrievalul întoarce fragmente care seamănă semantic cu întrebarea. Întrebarea „arată-mi revizuirea conturilor privilegiate din T1” seamănă cel mai bine cu... textul politicii de conturi privilegiate. Care e exact documentul greșit.

Artefactul-dovadă e, lexical, un tabel de identificatori și date. Nu conține vocabularul întrebării. Un sistem construit doar pe similaritate va prefera sistematic norma în locul dovezii, cu încredere mare. Compensezi printr-un filtru pe metadate înainte de căutarea semantică: identificator de control plus interval de timp reduc spațiul la câteva zeci de artefacte, iar abia acolo contează relevanța.

Ce indexezi și ce doar referențiezi

Nu copia artefactele în index. Trei motive practice:

1. Integritate. Un export copiat într-un vector store e o copie, nu dovada. Dovada e obiectul din sistemul-sursă, cu lanțul lui de custodie. Un auditor va cere sursa, nu reprezentarea ta a sursei.
2. Permisiuni. Artefactele au, aproape întotdeauna, un cerc de acces mai strâmt decât politicile. Copiate în același index, moștenesc regimul lui.
3. Volum. Un export lunar de log e inutil ca text pentru un model și scump ca embedding.

Indexează în schimb fișa artefactului: ce demonstrează, pentru ce control, ce perioadă acoperă, cine l-a produs, unde se află. Câteva sute de caractere care se regăsesc bine și care trimit la obiectul real. Principiile generale de pregătire a corpusului sunt în pregătirea documentelor pentru o bază de cunoștințe; ce se adaugă aici e stratul de relații.

Dimensiunea temporală e primară, nu decorativă

În majoritatea sistemelor de retrieval, timpul înseamnă prospețime: vrei versiunea curentă și vrei ca cea veche să dispară. Într-un sistem de audit, pragul e inversat. Versiunea veche nu se șterge — se marchează.

Prospețime versus valabilitate

Mecanica de actualizare, ștergere și reindexare e aceeași și e tratată separat în prospețime, ștergeri și reindexare. Ce diferă e obiectivul. Acolo, o versiune depășită care apare într-un răspuns e un defect. Aici, o versiune depășită care nu mai poate fi regăsită e un defect: dacă auditul acoperă exercițiul precedent, versiunea aplicabilă e cea de atunci.

Regula practică: ștergi din index doar ce a ieșit din termenul de păstrare, nu ce a fost înlocuit.

Trei date care nu sunt aceeași dată

Fiecare versiune de politică poartă cel puțin trei momente distincte, iar confundarea lor produce răspunsuri false cu aparență de precizie:

Data de intrare în vigoare e cea care contează pentru selecție. E și cea care lipsește cel mai des din metadate, pentru că nu apare în numele fișierului și nu e mereu scrisă în document.

Interogarea „as of” ca default explicit

Modelul de retrieval capătă un parametru suplimentar: data de referință. Default-ul e ziua curentă. Când întrebarea conține o perioadă — un trimestru, un an fiscal, o dată calendaristică — parametrul se mută acolo, iar filtrul selectează versiunile valabile atunci.

O structură minimă de metadate pe fiecare chunk de politică:

1{
2  "document_id": "POL-SEC-004",
3  "versiune": "3.1",
4  "valabil_de_la": "2025-01-15",
5  "valabil_pana_la": "2026-03-31",
6  "inlocuieste": "3.0",
7  "aprobat_de": "Comitet de risc",
8  "aprobat_la": "2024-12-18",
9  "controale": ["AC-08", "AC-09"]
10}

1{
2  "document_id": "POL-SEC-004",
3  "versiune": "3.1",
4  "valabil_de_la": "2025-01-15",
5  "valabil_pana_la": "2026-03-31",
6  "inlocuieste": "3.0",
7  "aprobat_de": "Comitet de risc",
8  "aprobat_la": "2024-12-18",
9  "controale": ["AC-08", "AC-09"]
10}

Când perioada cerută traversează două versiuni, răspunsul corect nu e una dintre ele. E amândouă, cu intervalul fiecăreia menționat explicit. Un sistem care alege tăcut una dintre versiuni pentru o întrebare care acoperă schimbarea produce exact tipul de eroare pe care un auditor o caută.

Provenanța face parte din răspuns

În alte cazuri de utilizare, citarea e un element de încredere: utilizatorul o folosește dacă vrea să verifice. Într-un context de audit, citarea e conținutul. Un răspuns fără provenanță nu e un răspuns mai puțin util, e unul inutilizabil.

Ce conține un răspuns defensabil

Șase elemente, toate obligatorii:

1. Afirmația, formulată strict, fără extrapolare.
2. Documentul-sursă și versiunea lui.
3. Intervalul de valabilitate al versiunii citate.
4. Cine a aprobat și la ce dată.
5. Artefactele-dovadă, cu identificator și sistem-sursă, nu ca text copiat.
6. Perioada acoperită de fiecare artefact.

Punctul 6 e cel omis cel mai des și cel mai periculos. Un artefact care demonstrează revizuirea din trimestrul II nu demonstrează nimic despre trimestrul I, dar arată la fel de convingător într-un răspuns care nu spune perioada.

Mecanica prin care citarea reduce riscul de afirmație nefondată e tratată în reducerea halucinațiilor prin grounding și citare. Reținerea utilă aici: pe conformitate, citarea nu e ornament de încredere, e obiectul livrat.

„Nu am dovada” e un rezultat, nu o eroare

Un sistem care răspunde „nu există un artefact indexat pentru controlul AC-08 în intervalul cerut” a livrat exact ce trebuia. Într-o pregătire de audit, harta golurilor e mai valoroasă decât răspunsurile complete: e lista de lucruri pe care le poți repara înainte să le găsească altcineva.

Tratează refuzul ca funcționalitate de prim rang: prag de relevanță explicit, mesaj care distinge între „nu am găsit” și „nu există”, și un raport agregat al controalelor fără dovadă pentru perioada curentă.

Permisiunile sunt mai stricte pe dovezi decât pe politici

O politică internă de securitate e, de regulă, citibilă de toți angajații — asta e și ideea. Artefactele care demonstrează aplicarea ei nu sunt.

Ce conțin, de fapt, dovezile

Un export de revizuire a accesului conține nume și drepturi efective. Un dosar de incident conține detalii de exploatare care nu circulă. O evaluare de furnizor conține prețuri și clauze. Un registru de instruire conține cine nu a participat.

Regimul de acces al dovezii e, aproape întotdeauna, mai strâmt decât cel al normei pe care o demonstrează. Un index care le pune la un loc, cu aceleași drepturi, transformă un sistem de conformitate într-o problemă de conformitate. Modelul de segmentare e detaliat în controlul accesului în RAG; ce se adaugă aici e că cele două straturi au politici de acces diferite prin construcție, nu accidental.

Filtrează la retrieval, nu la afișare

Un sistem care regăsește tot și apoi ascunde ce nu are voie utilizatorul să vadă a expus deja informația: în context, în sinteză, în numărul de rezultate. Filtrul de drepturi se aplică înainte de căutare, pe metadate, nu după.

Corolarul incomod: doi utilizatori cu drepturi diferite trebuie să primească răspunsuri diferite la aceeași întrebare, iar cel cu drepturi mai puține trebuie să afle că există ceva ce nu poate vedea, nu să primească un răspuns care sugerează că nu există nimic.

Jurnalul de interogări devine el însuși dovadă

Un sistem care răspunde la întrebări de audit produce, la rândul lui, o urmă: cine a întrebat ce, când, ce a primit. Urma aceea are trei consecințe pe care merită să le decizi înainte, nu după:

• Devine dovadă — poți demonstra cu ea că verificarea a avut loc.
• Devine obiect de audit — cineva o va cere, iar ea trebuie să aibă propria politică de retenție și de acces.
• Devine material sensibil — tiparul întrebărilor unui investigator intern spune ce se investighează.

Partea de protecție a datelor personale, inclusiv registrul de prelucrări și termenele de retenție, e tratată în RAG și GDPR.

Granița față de un GRC: ce nu se mută

Întrebarea vine devreme în orice discuție serioasă: dacă sistemul răspunde la întrebări de conformitate, nu înlocuiește el uneltele de guvernanță, risc și conformitate? Nu. Iar claritatea acestei granițe decide dacă proiectul e util sau redundant.

Registrul rămâne registru

Evidența structurată — lista de controale, responsabilii, scadențele, statusul dovezilor, planurile de remediere — trăiește într-un sistem tranzacțional, cu stări și fluxuri de aprobare. Un model de limbaj nu produce și nu întreține așa ceva.

Cazul limită e instructiv: sub DORA, entitățile financiare țin un registru de informații privind toate contractele de servicii ICT cu terți și îl raportează cel puțin anual autorității competente, în formatul standardizat prin regulament de punere în aplicare. Un registru raportat într-un format tehnic fix, cu reguli de validare, nu e o problemă de retrieval. E o problemă de date structurate, iar încercarea de a-l genera dintr-un corpus de documente e o eroare de arhitectură.

Unde câștigă stratul de retrieval

Trei zone, toate cu întrebări deschise pe text nestructurat:

• Întrebări care traversează documente. „Ce spun politicile noastre despre păstrarea logurilor de acces?” — răspunsul e împrăștiat în patru documente scrise de trei echipe.
• Chestionarele de securitate ale clienților. Sute de întrebări repetitive, formulate diferit de fiecare client, la care răspunsurile există deja în documentația internă. Aici câștigul e real: primul draft, cu citare, urmat de validare umană.
• Identificarea golurilor. „Ce controale nu au niciun artefact asociat pentru trimestrul curent?” — dacă relațiile din secțiunea a doua există, întrebarea are răspuns.

Ce nu e retrieval

„Câte incidente de securitate am avut în trimestrul II?” nu e o întrebare de regăsire. E o agregare, iar un top-k care întoarce cinci fragmente similare va produce un număr plauzibil și greșit. Aceeași graniță, pe alt tip de corpus, e tratată în sinteza feedbackului de la clienți: agregarea cere o interogare peste date structurate, nu o sinteză peste fragmente.

Iar dacă inventarul tău arată că majoritatea întrebărilor sunt de tip registru și status, concluzia corectă e că ai nevoie de un GRC, nu de un strat de model. Pragurile de decizie sunt în când nu folosești RAG.

Peisajul de reglementare se schimbă sub tine

Un sistem de conformitate indexează documente care se raportează la reguli externe, iar regulile acelea au calendare proprii. Câteva repere verificate la iulie 2026, plus disciplina de a le trata corect.

NIS2: aceeași directivă, calendare naționale diferite

Directiva (UE) 2022/2555 avea termen de transpunere 17 octombrie 2024. Termenul acela nu e termenul tău: obligațiile concrete vin din actul național. În România, transpunerea s-a făcut prin OUG nr. 155/2024, consolidată prin Legea nr. 124/2025, cu DNSC drept autoritate competentă. Operaționalizarea a venit prin ordinele DNSC nr. 1/2025 și nr. 2/2025, intrate în vigoare la 20 august 2025, care reglementează notificarea în vederea înregistrării și metodologia de evaluare a nivelului de risc.

Fiecare pas din acea secvență produce un artefact cu dată — notificarea, evaluarea de risc, autoevaluarea de maturitate. Exact tipul de dovadă care trebuie legat de un control, nu lăsat într-un folder.

Cât despre stadiul european: la 8 iulie 2026, Comisia a decis sesizarea Curții de Justiție a UE împotriva Irlandei, Spaniei, Franței și Țărilor de Jos pentru nenotificarea măsurilor complete de transpunere. Trackerele comerciale de conformitate nu sunt de acord între ele cu privire la câte state au transpus integral — cifrele diferă în funcție de ce numesc „transpunere completă”. Dacă operezi în mai multe state, sursa e autoritatea națională, nu un tabel de vendor.

DORA: același regulament, alt calendar de raportare

Registrul de informații din articolul 28 alineatul (3) se raportează anual autorității naționale competente, dar data efectivă diferă de la stat la stat. Pentru ciclul 2026, autoritatea olandeză a stabilit termenul de raportare la 20 martie 2026, iar cea luxemburgheză a deschis portalul de transmitere la 11 februarie 2026, cu data de referință a registrului la 31 decembrie 2025.

Consecința pentru sistemul tău: nu codifica termenul în conținut. Ține-l ca dată în registru, legat de autoritatea competentă, și lasă documentația să explice mecanismul.

ISO 27001:2022: fereastra s-a închis, numerotarea a rămas

Perioada de tranziție stabilită pentru trecerea de la ISO/IEC 27001:2013 la ediția 2022 s-a încheiat la 31 octombrie 2025; certificatele emise pe ediția 2013 nu mai sunt valabile după acea dată. Anexa A a fost restructurată: 114 controale în 14 domenii au devenit 93 de controale grupate pe patru teme.

Detaliul care contează pentru index, și pe care îl ratează majoritatea proiectelor: dovezile din perioade anterioare sunt evaluate pe numerotarea de atunci. Dacă auditul acoperă un exercițiu în care sistemul tău de management funcționa pe ediția 2013, artefactele trimit la controale care nu mai există sub același identificator. Ai nevoie de ambele scheme în index, cu interval de valabilitate și cu maparea între ele — altfel o căutare după numărul de control întoarce gol pentru exact perioada care se auditează.

AI Act: sistemul devine el însuși obiect de documentat

Calendarul s-a modificat în 2026. Consiliul UE a dat aprobarea finală pachetului de simplificare pe 29 iunie 2026: obligațiile pentru sistemele cu risc ridicat de sine stătătoare din Anexa III se aplică de la 2 decembrie 2027, iar cele pentru AI încorporat în produsele din Anexa I de la 2 august 2028. Data de 2 august 2026 rămâne activă pentru obligațiile de transparență din articolul 50.

Clasificarea unui asistent intern e discutată pe cazul juridic în RAG pe contracte și documente juridice — nu o relua aici. Ce e specific conformității: un sistem care produce afirmații folosite în dosare de audit devine el însuși ceva ce va trebui descris, cu date de intrare, limite cunoscute și mod de verificare. Documentația aceea se scrie mai ieftin acum decât reconstituită retroactiv.

Ce am omis deliberat

Spațiul „costul conformității” e plin de procente fără numitor: cât la sută din timpul echipelor se duce pe colectare de dovezi, cu cât scade efortul după automatizare. Cifrele circulă între rapoarte de vendor fără metodologie publicată, iar definițiile diferă atât de mult încât comparația nu are sens.

Înainte să citezi o cifră de acest tip, cere trei lucruri: numitorul exact, mărimea și compoziția eșantionului, și cine a plătit studiul. Dacă lipsește unul, nu o pune într-un document care ajunge la un auditor.

Cum verifici că un RAG de conformitate e defensabil

Un demo cu cinci întrebări nu spune nimic. Un sistem de conformitate se validează pe un set construit din întrebări reale de audit, cu răspunsul verificat de cineva care a trecut printr-un audit.

Setul de evaluare

60–100 de întrebări, distribuite pe cele trei forme din prima secțiune și pe regimurile care te privesc efectiv. Pentru fiecare întrebare notează, înainte de a rula sistemul: răspunsul așteptat, documentul și versiunea care trebuie citate, artefactele care trebuie atașate și perioada acoperită.

Include deliberat întrebări fără răspuns — controale pentru care știi că dovada lipsește. Fără ele nu poți măsura lucrul care contează cel mai mult.

Trei metrici, măsurate separat

Ultima linie e metrica de acceptanță. Un sistem cu regăsire bună și refuz slab e mai periculos decât unul mediocru pe ambele, pentru că inspiră încredere exact acolo unde nu trebuie. Metodologia generală, pragurile și construcția setului sunt detaliate în cum evaluezi un sistem RAG.

Pilotul: un regim, o perioadă

Nu porni pe tot peisajul de conformitate deodată. Alege un singur regim, un singur exercițiu auditat și un singur set de controale — de preferat cel pe care tocmai l-ai trecut, fiindcă ai deja răspunsurile corecte de la auditor.

Compară ce produce sistemul cu ce a acceptat auditorul. Diferența e lista ta de lucru, iar mărimea ei îți spune, în două săptămâni, dacă abordarea merită extinsă.

Întrebări frecvente

Poate genera răspunsurile la chestionarele de securitate ale clienților?

Poate genera primul draft, cu citare la sursa internă pentru fiecare răspuns. Nu poate semna. Fluxul realist e: draft automat, validare de către responsabilul de control, aprobare înainte de trimitere. Câștigul vine din faptul că răspunsurile există deja în documentație și sunt reformulate diferit de fiecare client, nu din eliminarea validării.

Ce fac cu dovezile care sunt capturi de ecran?

Le tratezi ca artefacte referențiate, nu indexate ca text. Ce indexezi e fișa lor: ce configurare arată, pentru ce control, la ce dată a fost făcută captura și cine a făcut-o. O captură fără dată și fără context de sistem e o dovadă slabă oricum, independent de tehnologie.

Trebuie să indexez artefactele-dovadă sau doar să le referențiez?

Referențiază-le, cu o fișă indexată. Copierea lor în index rupe lanțul de custodie, moștenește regimul de acces al politicilor și umflă costul de embedding fără câștig de regăsire. Excepție rezonabilă: documentele-dovadă care sunt ele însele text narativ, cum sunt procesele-verbale.

Cum răspund la întrebări despre trecut dacă nu am versiunile vechi?

Onest: sistemul spune că nu are versiunea aplicabilă pentru perioada cerută. E singurul răspuns corect. Reconstituirea versiunilor vechi din arhive, cu data de intrare în vigoare atașată, e o sarcină de proiect separată — și e prima pe care o faci dacă auditurile tale privesc mai des în urmă decât în prezent.

Un asistent intern de conformitate e sistem cu risc ridicat?

Clasificarea depinde de destinația declarată a sistemului, nu de tipul documentelor pe care le indexează, iar analiza se face pe cazul concret cu juridicul. Independent de rezultat, un sistem ale cărui răspunsuri ajung în dosare de audit merită documentat ca și cum ar fi: date de intrare, limite, mod de verificare umană.

Începe cu inventarul, nu cu modelul. Ia ultimele treizeci de cereri primite de la un auditor sau dintr-un chestionar de client, împarte-le pe cele trei forme și marchează, pentru fiecare, unde stă acum dovada și dacă are dată. Dacă majoritatea artefactelor sunt fișiere fără perioadă atașată, primul proiect nu e unul de retrieval — e unul de metadate, și merită făcut oricum.

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.