RAG pe registrul de riscuri: ipoteză, proprietar, scadență
Registrul de riscuri e primul corpus în care înregistrarea descrie ceva ce nu s-a întâmplat. Ce se schimbă la retrieval: stare, proprietar, scadență.

Un rând dintr-un registru de riscuri arată așa. R-014: „Furnizorul unic de convertoare nu livrează la termen.” Probabilitate 3, impact 4, expunere 12. Stare: în atenuare. Proprietar: șeful de aprovizionare. Revizuire: 30 septembrie.
Rândul acesta nu consemnează nimic din ce s-a petrecut. Consemnează ce crede cineva că se poate petrece, evaluat pe o scară pe care organizația și-a definit-o singură, cu o dată la care cineva ar trebui să se uite din nou și cu un nume care răspunde dacă nu o face.
Fiecare corpus de până acum din cluster a avut un punct de sprijin în trecut. Un buletin de laborator poartă o măsurătoare. O neconformitate poartă o abatere deja produsă. Un atestat poartă un drept valabil până la o dată. Registrul de riscuri e primul în care înregistrarea nu are corespondent în realitatea petrecută: e o presupunere despre viitor, iar întrebările puse peste ea se lovesc de asta din prima secundă.
Diferența are trei consecințe tehnice imediate. Sistemul nu poate produce o dovadă pentru afirmația centrală a documentului. Scorul care ordonează registrul nu e comparabil în afara organizației care l-a produs. Iar o fișă își pierde valabilitatea în tăcere, fără ca textul să se schimbe, când trece de revizuire și nimeni nu o atinge. Mecanica de bază e în ce este RAG; mai jos e ce se schimbă când documentul indexat vorbește despre ce nu s-a întâmplat încă.
Înregistrarea care descrie ceva ce nu s-a întâmplat
Ipoteza nu are dovadă, are argument
Un buletin de încercări trimite la un raport de laborator, cu metodă și probă. O neconformitate trimite la o constatare, cu dată și operator. O fișă de risc nu trimite nicăieri: nu există document care să ateste că evenimentul se va produce, fiindcă evenimentul nu s-a produs.
Ce există, în cel mai bun caz, e un argument: o cauză identificată, un precedent, o dependență vizibilă în plan. Asta schimbă forma răspunsului. Nu poți construi o propoziție de tipul „conform documentului, valoarea este”, ci doar „în registru există ipoteza X, formulată la data D, cu argumentul Y, evaluată de Z”.
Comparația utilă e cu perimetrul unui rezultat de laborator: acolo, buletinul vorbește strict despre proba lui. Aici perimetrul e și mai strâmt — o presupunere a unui om, la un moment dat, într-un context care s-ar putea să nu mai fie valabil.
Modalitatea se pierde prima
Modelul pierde modalitatea. Textul sursă spune „există riscul ca livrarea să întârzie”, iar răspunsul generat spune „livrarea va întârzia”. E cea mai frecventă eroare pe corpusuri de acest tip și nu se vede la citire rapidă: propoziția e fluentă și trimite la un document real.
Corecția nu e la nivel de model, ci de format impus. Fiecare afirmație scoasă dintr-o fișă poartă trei etichete: că e ipoteză, cine a formulat-o, la ce dată. Regulile de sinteză și citare sunt în cum arată un răspuns bun de RAG; aici se adaugă una singură: fără eticheta de ipoteză, răspunsul e greșit chiar dacă e fidel textului.
Enunțul de risc nu e titlul lui
„Întârziere livrare” nu e un risc. E un titlu de rând. Un enunț utilizabil are trei componente separate: cauza care favorizează apariția, evenimentul incert în sine și efectul asupra unui obiectiv anume.
Standardul internațional merge mai departe: ISO 31000 definește riscul ca efectul incertitudinii asupra obiectivelor. Fără un obiectiv atins de eveniment, nu ai un risc, ai o îngrijorare. De aici iese structura de extragere: cauză, eveniment, efect, obiectiv afectat — patru câmpuri, nu un paragraf. Registrele reale le amestecă într-o singură celulă, iar separarea lor la ingestie e cea mai ieftină îmbunătățire pe care o poți face înainte să atingi retrievalul.
Scorul nu e o măsurătoare, e o convenție locală
Aceleași cifre, două înțelesuri
Două filiale ale aceluiași grup evaluează câte un risc de indisponibilitate a unui furnizor. Prima folosește o scară de la 1 la 5 în care impactul 4 înseamnă întârziere de peste o lună. A doua folosește tot 1-5, dar impactul 4 înseamnă pierdere financiară peste un prag exprimat în procent din cifra de afaceri. Ambele scriu 4. Cifrele arată identic și nu spun același lucru.
Nu e o problemă de disciplină, ci consecința faptului că scalele se definesc local, iar cadrele care recomandă exercițiul nu impun o scară anume.
Ce arată literatura despre matricea probabilitate × impact
Articolul lui Louis Anthony Cox din 2008, apărut în Risk Analysis, e cel mai citat text critic pe subiect și enumeră probleme matematice, nu stilistice. Rezoluție slabă: o matrice tipică poate compara corect și fără ambiguitate doar o mică parte dintre perechile de pericole alese aleatoriu, sub 10%. Compresie de interval: riscuri cantitativ foarte diferite primesc același calificativ. Erori de ordine: matricea poate atribui un calificativ mai mare unui risc cantitativ mai mic, iar acolo unde frecvența și severitatea sunt negativ corelate rezultatul poate fi mai slab decât o ordonare aleatorie. Și ambiguitate: doi utilizatori pot da evaluări opuse acelorași riscuri cuantificate.
Concluzia practică nu e că scorul trebuie aruncat. E că scorul e un obiect de guvernanță internă, util ca să prioritizezi într-un singur registru, nu o mărime care traversează granițele organizației.
Nu agrega fără o cheie de traducere
Regula care iese de aici e dură. Sistemul nu construiește niciodată un top al riscurilor peste registre diferite, ordonat după expunere. Poate ordona în interiorul unui registru, cu scara declarată în răspuns, și poate compara între registre doar printr-o cheie de traducere documentată, aprobată și versionată.
E aceeași lecție ca la metodele de încercare din articolul despre buletine, mutată de pe măsurători pe evaluări subiective. Diferența e că acolo procedura stă într-un standard publicat, iar aici într-un document intern pe care nimeni nu-l indexează.
Proprietar, scadență, stare: ce ține o fișă în viață
Un nume, nu un compartiment
O fișă fără proprietar nu produce nicio acțiune. Practica de management de proiect e explicită: PRINCE2 cere un singur proprietar pentru fiecare risc și separă rolul acesta de executantul răspunsului, cel care implementează efectiv acțiunile. Sunt două câmpuri, nu unul, iar un sistem care le confundă trimite întrebarea la omul greșit.
În sectorul public românesc numele diferă, intenția e aceeași: codul controlului intern managerial definește responsabilul cu riscurile ca persoana desemnată de conducătorul unui compartiment, care colectează informațiile privind riscurile și actualizează registrul la nivelul acestuia.
Legătura cu registrul de competențe și autorizări e directă, cu o singură deosebire care contează: acolo, titularul deține un drept care expiră la o dată fixă. Aici, proprietarul deține o obligație de a se uita din nou.
Scadența e a unei revizuiri, nu a unui drept
Un atestat expirat nu mai e valabil, iar consecința se calculează automat. O fișă de risc trecută de revizuire rămâne, formal, la fel de validă. Nimic din text nu se schimbă. Se schimbă doar probabilitatea ca ea să mai descrie realitatea.
Vechimea nu se poate deduce din conținut, deci se calculează și se afișează. Fiecare fișă returnată poartă distanța până la data de revizuire, iar una depășită apare marcată, nu ascunsă — cineva trebuie să afle că registrul e în urmă.
Scadența devine astfel un declanșator, nu doar metadată de afișare. Tiparul e cel din monitorizarea obligațiilor contractuale, cu alt obiect: acolo termenul aparține unei obligații asumate, aici unei promisiuni de a reevalua o presupunere.
Starea contează mai mult decât textul
Textul unei fișe se schimbă rar. Starea ei se schimbă des, iar starea decide ce are voie sistemul să spună despre ea.
| Stare | Ce spune despre ipoteză | Ce poate răspunde sistemul |
|---|---|---|
| Deschis | Formulată, fără măsuri implementate | O poate cita ca risc activ, cu proprietar și scadență |
| În atenuare | Măsuri în curs, expunere nerecalculată încă | O citează împreună cu măsurile și stadiul lor |
| Acceptat | Expunerea a fost asumată deliberat, sub limita de toleranță | Trebuie să spună cine a acceptat și pe ce argument |
| Materializat | Nu mai e ipoteză, s-a produs | Nu o mai citează ca risc deschis; trimite la înregistrarea de incident |
| Închis | Cauza a dispărut sau obiectivul nu mai există | O returnează doar la întrebări despre istoric |
Distincția cea mai des ratată e între acceptat și închis. Un risc acceptat rămâne activ, doar că organizația a decis să nu cheltuiască pe el — codul de control intern numește asta limită de toleranță și o leagă de decizia de a nu implementa măsuri. Un sistem care le tratează la fel produce răspunsuri liniștitoare și false. Iar când răspunsul la risc a fost transferul, fișa are un corespondent în afara registrului: o poliță de asigurare, cu propriile ei excluderi și straturi de contract — un risc marcat ca transferat, dar prins de o excludere, rămâne în fapt netransferat.
Riscul materializat pleacă din registru
Când presupunerea se produce, obiectul își schimbă natura. Materializarea riscului e definită ca translatarea lui din domeniul incertitudinii în cel al certitudinii, moment în care amenințarea posibilă devine problemă.
Pentru sistem, momentul acela e o migrare, nu o actualizare de câmp. Înregistrarea trece în registrul de incidente și neconformități, unde întrebarea nu mai e „se poate întâmpla?”, ci „s-a mai întâmplat?”. Cele două corpusuri rămân separate, legate printr-un identificator, iar regula de retrieval e că un risc materializat nu mai apare niciodată în răspunsurile despre riscuri deschise. Dacă apare, ai o contradicție pe care un auditor o găsește în cinci minute.
Ce cer cadrele de management al riscului și ce lasă la tine
ISO 31000: ghid, nu cerință
Standardul oferă linii directoare, nu cerințe, și nu e destinat certificării — lucru afirmat explicit de organizația care îl publică, ca să lase flexibilitate de aplicare. Nu prescrie o metodologie anume; e cadrul peste care se construiesc standarde sectoriale.
Tradus în constrângeri de sistem: nu există structură de registru garantată, nici scară, nici vocabular comun de la o organizație la alta. Vocabularul standardizat există separat, în ISO 31073, publicat în 2022 — dar un vocabular publicat nu înseamnă unul folosit.
ISO 9001: gândire bazată pe risc, fără registru obligatoriu
Aici e capcana cea mai frecventă. Clauza 6.1 cere organizației să determine riscurile și oportunitățile și să planifice acțiuni, însă anexa A.4 e explicită: nu există cerința unor metode formale de management al riscului sau a unui proces documentat, iar organizația decide singură dacă păstrează informații documentate ca dovadă. Materialul de îndrumare al comitetului tehnic ISO/TC 176 merge în aceeași direcție: ISO 31000 rămâne o referință utilă pentru cine vrea o abordare mai formală, fără ca folosirea lui să fie obligatorie, iar gândirea bazată pe risc nu se auditează ca activitate separată, ci pe tot parcursul auditului sistemului.
Consecința e că într-o companie certificată registrul poate să nu existe ca document unic. Poate fi o secțiune dintr-un plan de calitate, un tabel dintr-un proces-verbal de analiză de management, câteva rânduri într-un fișier de proiect. Neomogenitatea e starea normală, iar un sistem construit pe presupunerea unui registru unic ratează jumătate din corpus.
OSGG 600/2018: în sectorul public, registrul e obligatoriu și are două niveluri
Regimul din administrația publică românească e mult mai prescriptiv, ceea ce îl face un bun exemplu de model de date. Codul controlului intern managerial definește riscul ca o situație sau un eveniment care nu a apărut încă, dar care poate apărea în viitor — definiția normativă spune, cuvânt cu cuvânt, punctul de plecare al articolului. Registrul de riscuri e documentul în care se consemnează informațiile privind riscurile identificate.
Riscurile se identifică și se evaluează la nivelul fiecărui compartiment, potrivit elementelor minimale din registru, iar cele semnificative se centralizează la Comisia de monitorizare, în registrul entității publice. Comisia le prioritizează prin profilul de risc și limita de toleranță, aprobate anual de conducere. Vocabularul separă riscul inerent — cel din absența oricărei acțiuni a conducerii — de riscul rezidual, cel rămas după implementarea măsurilor.
Două niveluri înseamnă două corpusuri cu granularitate diferită și suprapunere parțială. Un răspuns care nu spune din care registru vine informația e inutilizabil: în cel de compartiment riscul poate fi deschis, iar în cel al entității poate să nu fi ajuns deloc.
Cum se schimbă retrievalul peste un registru de riscuri
Ce se întreabă de fapt
Cererile reale nu seamănă cu o interogare de documentație:
- Riscul pe care vreau să-l înregistrez există deja, sub altă formulare?
- Cine e proprietarul acestui risc și când l-a revizuit ultima dată?
- Ce s-a decis data trecută pe riscul ăsta și cu ce argument?
- Ce fișe au depășit data de revizuire în compartimentul meu?
- Ce riscuri s-au materializat anul acesta și ce aveau consemnat ca măsuri?
Prima e cea mai valoroasă și cea mai rar implementată. Căutarea de duplicat, rulată chiar când cineva scrie un risc nou, valorează mai mult decât celelalte patru la un loc: previne fragmentarea corpusului la sursă.
Duplicatul e regula, nu excepția
Într-o organizație cu zece compartimente, aceeași dependență de un furnizor unic apare în șase registre, cu șase formulări. Niciuna nu e greșită.
Deduplicarea se face la ingestie, printr-un identificator canonic, nu la afișare. Contorul rezultat e el însuși un semnal: un risc care apare în șase registre nu e de compartiment, e sistemic și ar trebui să urce la nivelul entității. Fără pasul acesta, orice răspuns despre expunerea totală numără de mai multe ori aceeași cauză.
Identificatorii de tip R-014 sau referințele către obiective numerotate sunt exact tokenii pe care căutarea semantică îi tratează prost, deci partea lexicală nu e opțională — mecanica e în hybrid search și reranking.
Filtrul pe stare și dată vine înaintea similarității
Ordinea contează. Întâi restrângi la stările permise de întrebare și la fereastra de revizuire relevantă, abia apoi ordonezi după apropiere. Invers, primele rezultate vor fi fișe închise acum doi ani, formulate mai frumos decât cele deschise.
Un risc închis rămas în index se comportă ca orice fragment învechit și cere tratamentul de ștergere și reindexare din prospețime, ștergeri și reindexare. Diferența e că aici starea se schimbă des, deci reindexarea nu e un eveniment rar, ci un flux.
Mai apare și o problemă de acces. Registrele de risc conțin formulări incomode: dependența de o singură persoană, fragilitatea unui contract, suspiciuni de fraudă. Nu e un corpus care se deschide tuturor, iar filtrarea se face înainte ca modelul să vadă ceva — regimul e cel din controlul accesului în RAG.
Ce răspunde sistemul, ce decide omul, cum verifici
Unde chiar câștigă timp
Aduce duplicatul înainte de înregistrare, cu formularea și proprietarul lui, ca omul să decidă dacă adaugă un rând nou sau completează unul existent.
Reconstituie istoricul unei decizii: cine a acceptat riscul, la ce dată, cu ce argument, sub ce limită de toleranță. E aceeași legătură între afirmație și artefactul care o susține ca la conformitate și audit intern, doar că aici artefactul e adesea un proces-verbal, nu un document de politică.
Și livrează lista de fișe scadente, grupate pe proprietar. E răspunsul cel mai puțin spectaculos și cel mai des cerut.
Ce nu propune niciodată
Nu propune un scor. Nici probabilitate, nici impact, nici expunere recalculată. Un model care sugerează „probabil 4” produce o cifră care intră într-un tabel aprobat de conducere, fără ca cineva să fi făcut evaluarea — și care nu poate fi susținută în fața nimănui.
Nu decide acceptarea și nu închide o fișă. Ambele sunt decizii cu proprietar, iar proprietarul e o persoană cu nume.
Există însă și riscuri a căror expunere nu e o convenție internă, ci un procent stabilit prin lege și aplicat pe un contract întreg: corecțiile financiare de pe dosarele de fonduri europene. Acolo, cifra din registru nu se negociază cu scara proprie.
Nu inventează riscuri. Poate semnala că un risc dintr-un registru vecin nu are corespondent în al tău — o comparație între documente existente, nu o generare.
Ce poți măsura când nu ai un adevăr de referință clasic
Nu ai perechi întrebare-document adnotate, dar ai patru cifre care se calculează direct din registru și din log: Duplicate prinse înainte de înregistrare. Din rândurile adăugate într-o perioadă, câte au fost semnalate ca similare și câte s-au dovedit, la verificare, chiar duplicate. E metrica principală: atacă fragmentarea la sursă.
Acoperirea câmpurilor care fac o fișă utilizabilă. Ce procent din registru are, simultan, proprietar cu nume, dată de revizuire și stare explicită. Sub un prag rezonabil, restul măsurătorilor nu au sens.
Corectitudinea stării în răspunsuri. Pe un eșantion de răspunsuri, în câte starea citată coincide cu starea din registru la momentul întrebării.
Riscuri materializate încă citate ca deschise. Ținta e zero. Orice valoare peste zero arată o problemă de migrare, nu de retrieval, iar cadrul general de evaluare din cum evaluezi un sistem RAG nu o prinde, fiindcă nu e o eroare de relevanță.
Un semn că nu ai nevoie de model deloc: dacă lista de întrebări se reduce la numărători — câte riscuri deschise pe compartiment, câte scadente luna asta — ai nevoie de o interogare peste câmpuri în sistemul intern, nu de retrieval. Cazurile astea sunt trasate în când nu folosești RAG.
Întrebări frecvente
Cum tratez riscurile scrise ca titluri, fără cauză și fără efect?
Le indexezi ca atare, marcate ca incomplete, și nu le rescrii. Un pas de extragere poate propune separarea în cauză, eveniment și efect, dar propunerea merge la proprietarul fișei. Rescrierea automată a unui enunț schimbă sensul unei evaluări aprobate, iar scorul rămâne atașat vechii formulări.
Poate sistemul să propună riscuri noi pornind de la proiecte similare?
Poate propune candidați din registre existente, cu sursa vizibilă: acest tip de proiect a avut consemnate riscurile A, B și C. Nu poate genera riscuri din nimic și nu poate estima probabilități. Căutarea declanșată de contextul de lucru, nu de o întrebare scrisă, e tratată în RAG pentru lecțiile învățate — mecanismul se aplică și aici, cu diferența că registrul de riscuri are un proces care obligă la consultare.
Ce fac cu registre din compartimente care evaluează pe scale diferite?
Le păstrezi separate și afișezi scara în răspuns. Dacă organizația chiar are nevoie de o vedere consolidată, cheia de traducere se construiește o dată, se aprobă și se versionează, iar sistemul o aplică explicit, cu mențiunea că cifra afișată e convertită. Fără asta, un top consolidat e o ficțiune ordonată frumos.
Cine ar trebui să vadă registrul într-un sistem de întrebări?
Mai puțină lume decât are acces la fișierul original, ca regulă de pornire. Un registru căutabil e mult mai ușor de explorat decât unul deschis ca fișier, iar formulările despre dependențe de persoane sau fragilități contractuale nu sunt destinate întregii organizații. Permisiunile se aplică la nivel de fișă, filtrat înainte de retrieval.
Cum evit ca un risc închis sau materializat să fie citat ca deschis?
Prin trei lucruri în ordine: starea ca filtru obligatoriu în interogare, reindexarea la fiecare schimbare de stare și o verificare periodică de contradicție între registrul de riscuri și cel de incidente. Ultimul pas prinde exact cazurile în care migrarea s-a făcut într-un sistem și nu în celălalt.
Deschide registrul curent și numără câte rânduri au, simultan, un proprietar cu nume, o dată de revizuire care nu a trecut și o stare actualizată în ultimele șase luni. Raportul dintre cifra aia și numărul total de rânduri e plafonul oricărui sistem construit peste registru. Se calculează într-o oră și îți spune dacă proiectul următor e unul de retrieval sau unul de disciplină a registrului.
Dacă vrei să discuți cum ar arăta modelul de stări și cheia de traducere pe registrele tale, trimite un mesaj. Alte corpusuri de companie, cu problemele lor specifice, sunt în hubul Cazuri de utilizare enterprise, iar serviciul întreg în AI & RAG.
Surse
- The new ISO 31000 keeps risk management simple — ISO, 2018
- What's Wrong with Risk Matrices? (Risk Analysis, 28(2), 497-512) — Risk Analysis / Wiley, 2008
- Ordinul SGG nr. 600/2018 privind aprobarea Codului controlului intern managerial al entităților publice — Portal Legislativ, 2018
- ISO 9001 Auditing Practices Group Guidance on: Risk Based Thinking — ISO/TC 176, 2023
- ISO 31073:2022 Risk management — Vocabulary — ISO, 2022
Andrei Badulescu
Fondator & Software ArchitectConstruiește sisteme B2B la BaseTech — ERP la comandă, platforme SaaS, agenți AI și arhitecturi programmatic SEO. Scrie despre deciziile tehnice din spatele lor: stack, trade-off-uri și ce ține la scară.
Vezi profilul autorului →Articole conexe

RAG pe procedurile de urgență: documentul se execută
Planul de intervenție se aplică în minute, prin fum și fără curent. Ce cere asta de la un sistem de retrieval: mod degradat, rol pe tură, cronometru.

RAG pe nomenclatorul arhivistic: ștergerea ca obligație
Pe o arhivă, răspunsul corect poate fi că documentul nu mai trebuie să existe. Cum distinge sistemul o absență legitimă de o pierdere reală.

RAG pe documentația SSM: absența dovezii e chiar fapta
„Nu găsesc fișa" acoperă trei fapte diferite, cu consecințe diferite. Pe documentația SSM, absența unei înregistrări e ea însăși contravenția.
Insights pentru companii
care construiesc
Articole noi despre ERP, AI, agenți și pSEO, direct pe email. Fără spam.