Un model arhitectural pentru reducerea riscului ca datele recuperate în fluxurile RAG să influențeze modelul ca instrucțiuni, prin politici aplicate înainte de context și validare după generare.
Acest blueprint descrie o disciplină de separare pentru aplicații RAG în care datele recuperate pot influența răspunsul, dar nu trebuie să controleze instrucțiunile, accesul sau acțiunile permise.
Perimetrul nu promite securitate perfectă. Definește controale verificabile pentru reducerea riscului ca fragmentele recuperate să fie tratate ca autoritate operațională.
Într-un flux RAG, aplicația combină trei straturi care ar trebui să rămână separate: instrucțiunile sistemului, întrebarea utilizatorului și fragmentele recuperate din surse externe. Dacă aceste straturi ajung în același context fără delimitare, clasificare și politici clare, modelul poate interpreta conținutul recuperat ca parte din instrucțiunile de lucru.
Aici apare riscul arhitectural. Documentele, paginile, PDF-urile, emailurile sau fragmentele indexate pot conține formulări imperative, payload-uri ascunse, instrucțiuni conflictuale sau conținut contaminat. Fără o graniță explicită de încredere, ele pot influența răspunsul dincolo de rolul lor legitim: acela de context.
Problema nu este doar că un utilizator poate formula un prompt adversarial. Problema este că un sistem RAG poate introduce singur în contextul transmis modelului date neîncrezătoare, recuperate din index, înainte ca modelul să genereze răspunsul. De aceea, controlul trebuie aplicat înainte de retrieval, în momentul construirii contextului și după generare, nu doar în promptul de sistem.
Un sistem RAG nu trebuie analizat doar ca o conversație între utilizator și model. El trebuie analizat ca un traseu de date: cererea utilizatorului este transformată în interogare, interogarea recuperează fragmente, iar fragmentele sunt introduse în context, iar răspunsul generat poate fi afișat, citat sau transmis mai departe către acțiuni.
Riscul apare atunci când un strat al acestui traseu primește mai multă autoritate decât ar trebui.
Inputul utilizatorului. O cerere poate conține instrucțiuni adversariale care încearcă să schimbe prioritățile aplicației, să ignore regulile inițiale sau să împingă sistemul în afara perimetrului permis.
Corpusul indexat. Documentele externe, paginile web, PDF-urile, emailurile sau fragmentele importate pot conține instrucțiuni ascunse, conținut contaminat sau formulări concepute să influențeze modelul după retrieval. În acest caz, atacul nu intră direct prin utilizator, ci prin datele pe care sistemul le recuperează singur.
Retrieval-ul. Dacă drepturile nu sunt aplicate la nivel de document sau chunk, sistemul poate recupera fragmente relevante semantic, dar nepotrivite pentru utilizatorul curent. Relevanța nu trebuie confundată cu autorizarea.
Construirea contextului. Chiar și datele recuperate corect pot deveni riscante dacă sunt introduse lângă instrucțiunile sistemului fără delimitare, etichetare și ierarhie clară. Contextul trebuie să indice ce este regulă, ce este întrebare și ce este material recuperat.
Ieșirea modelului. Răspunsul generat poate combina informații valide cu concluzii nesusținute, poate omite incertitudinea sau poate produce instrucțiuni care par autorizate. De aceea, răspunsul generat trebuie verificat înainte să fie afișat, citat sau folosit într-un flux operațional.
Acțiunile conectate. Când sistemul RAG este conectat la tool calling, notificări, modificări de date sau escaladări, răspunsul nu mai este doar text. Devine o posibilă acțiune, iar acțiunea trebuie validată separat de model.
Modelul de amenințare nu urmărește să trateze orice fragment ca atac. Scopul lui este să marcheze unde datele pot primi autoritate greșită și unde trebuie aplicate controale verificabile.
Un RAG controlat nu se bazează pe o singură barieră. Promptul de sistem, delimitatorii, filtrarea sau validarea nu sunt suficiente separat. Ele devin utile doar atunci când sunt așezate într-un traseu în care fiecare strat are o responsabilitate clară și verificabilă.
Modelul tratează LLM-ul ca pe un motor de interpretare și sinteză, nu ca pe autoritatea care decide singură accesul, ierarhia surselor, acțiunile permise sau nivelul de încredere al contextului recuperat.
Controlul începe înainte ca datele să ajungă în context. Cererea utilizatorului este evaluată, politicile de acces sunt aplicate înainte de retrieval, iar fragmentele recuperate sunt filtrate, etichetate și delimitate. După generare, răspunsul este verificat înainte să fie afișat, citat sau transmis mai departe către acțiuni.
În acest model, defense-in-depth nu înseamnă acumularea de filtre, ci separarea responsabilităților: inputul este evaluat, retrieval-ul este autorizat, contextul este delimitat, modelul generează, iar ieșirea este validată și trasabilă.
Intrarea este normalizată fără privilegii suplimentare.
Sistemul detectează ambiguități, cereri adversariale sau risc operațional ridicat.
Perimetrul utilizatorului este stabilit înainte ca retrieval-ul să ruleze.
Sunt recuperate doar documente sau chunk-uri permise pentru utilizatorul curent.
Fragmentele sunt verificate pentru instrucțiuni ascunse, contaminare sau semnale de risc.
Instrucțiunile, întrebarea și datele externe sunt separate și etichetate.
Modelul sintetizează răspunsul, dar nu decide singur accesul sau acțiunile permise.
Răspunsul generat este verificat înainte de afișare, citare sau execuție.
Răspunsul păstrează legătura cu sursele, regulile aplicate și deciziile relevante.
Schema marchează trei granițe de încredere în fluxul RAG: înainte de retrieval se stabilește ce are voie utilizatorul să acceseze; în timpul construirii contextului se separă materialul recuperat de instrucțiunile sistemului; după generare se verifică dacă răspunsul poate fi afișat, citat sau transmis mai departe către acțiuni.
Astfel, fragmentele recuperate pot contribui la răspuns fără să rescrie regulile aplicației. Când o cerere, un document sau un răspuns depășește perimetrul stabilit, fluxul nu continuă automat, ci intră în clarificare, respingere sau escaladare.
Implementarea unui RAG controlat nu începe cu promptul, ci cu deciziile aplicate înainte ca datele să ajungă la model. Fiecare strat al fluxului trebuie să aibă o responsabilitate verificabilă: sursele care intră în corpus, fragmentele care pot fi recuperate, modul în care datele externe sunt delimitate, validarea răspunsului și tratamentul cazurilor care depășesc perimetrul acceptat.
Registru de surse și niveluri de încredere. Corpusul folosit de RAG trebuie tratat ca infrastructură de decizie, nu ca depozit pasiv de documente. Sursele pot fi clasificate după origine, sensibilitate, actualitate, proprietar, permisiuni și nivel de încredere. Un document necunoscut sau neverificat nu trebuie să primească aceeași greutate operațională ca o sursă internă validată.
Autorizare înainte de retrieval. Accesul trebuie decis înainte ca căutarea vectorială sau căutarea semantică să returneze fragmente. Politicile ACL/RBAC trebuie aplicate la nivel de document sau chunk, astfel încât utilizatorul să primească doar materialul pe care are voie să îl consulte. Relevanța semantică nu înlocuiește autorizarea.
Filtrarea fragmentelor recuperate. Fragmentele recuperate trebuie evaluate înainte de introducerea în context. Sistemul poate marca instrucțiuni ascunse, formulări imperative, conținut contaminat, surse neclare sau nepotriviri între cererea utilizatorului și drepturile disponibile. Scopul nu este eliminarea tuturor riscurilor, ci reducerea influenței necontrolate a datelor externe.
Constructor de context delimitat. Contextul transmis modelului trebuie să separe explicit instrucțiunile sistemului, întrebarea utilizatorului și datele recuperate. Fragmentele externe trebuie etichetate ca material de referință, nu ca reguli de execuție. Delimitarea reduce ambiguitatea, dar nu înlocuiește autorizarea și validarea aplicate în afara modelului.
Validarea răspunsului generat. Răspunsul modelului trebuie verificat înainte să fie afișat, citat sau folosit într-un flux operațional. Validarea poate urmări dacă răspunsul este susținut de sursele recuperate, dacă respectă perimetrul utilizatorului, dacă introduce afirmații nesusținute sau dacă încearcă să transforme contextul în instrucțiuni operaționale.
Controlul acțiunilor conectate. Dacă sistemul RAG este conectat la tool calling, notificări, CRM, email, modificări de date sau escaladări, răspunsul nu trebuie să declanșeze automat acțiuni cu impact. Parametrii, permisiunile și efectul operațional trebuie validate separat de model.
Audit și trasabilitate. Un RAG controlat trebuie să poată reconstrui ce surse au fost recuperate, ce politici au fost aplicate, ce fragmente au fost introduse în context și de ce un răspuns a fost permis, blocat sau escaladat. Trasabilitatea nu înseamnă absența erorilor, dar face deciziile verificabile și reduce dependența de comportamentul opac al modelului.
Validarea unui sistem RAG nu confirmă doar că modelul răspunde corect la câteva întrebări. Ea verifică traseul complet: surse, retrieval, context, generare, acțiuni și audit. Scopul este să rămână clară separarea dintre date, instrucțiuni și decizii operaționale.
Checklistul nu promite un RAG imposibil de manipulat. Rolul lui este să verifice dacă deciziile critice sunt scoase din zona de interpretare a modelului: accesul se stabilește înainte de retrieval, contextul este delimitat înainte de generare, iar răspunsul este validat înainte să fie afișat sau să producă efecte operaționale.
Validarea rămâne un proces recurent, nu un test bifat la lansare. Pe măsură ce se schimbă sursele, permisiunile, modelele, prompturile, politicile de acces sau comportamentul utilizatorilor, controalele trebuie revizuite pentru a păstra separarea dintre date, instrucțiuni și decizii operaționale.
Promptul de sistem poate ordona contextul, dar nu trebuie tratat ca graniță principală de securitate. Într-un sistem RAG, rolul lui este să clarifice cum sunt separate instrucțiunile, întrebarea utilizatorului și datele recuperate. Deciziile critice, precum accesul, nivelul de încredere, acțiunile permise sau tratamentul riscului, trebuie aplicate în afara modelului.
Contextul transmis modelului nu ar trebui construit ca o simplă concatenare de fragmente. El trebuie tratat ca un artefact controlat: fiecare bloc are un rol explicit, o sursă identificabilă, un nivel de încredere și o limită clară de utilizare. Astfel, modelul poate folosi informația recuperată pentru răspuns, fără ca acea informație să devină instrucțiune operațională.
Această structurare reduce ambiguitatea, dar nu elimină riscul de prompt injection, retrieval injection sau context poisoning. Ea funcționează doar împreună cu autorizarea înainte de retrieval, filtrarea fragmentelor recuperate, validarea răspunsului și auditul deciziilor relevante.
Contextul controlat este zona în care informația recuperată devine utilizabilă, fără să primească autoritate operațională.
Un RAG controlat reduce riscul prin separarea responsabilităților, dar nu transformă sistemul într-un mediu imposibil de manipulat. Limitările trebuie asumate explicit, pentru ca arhitectura să nu fie confundată cu o promisiune de securitate perfectă sau cu un filtru universal peste prompt injection.
Un sistem RAG matur nu ascunde aceste limite. Le face vizibile în arhitectură, le verifică prin audit și proiectează trasee de degradare pentru situațiile în care contextul, autorizarea sau efectul operațional nu sunt suficient de clare.
