Ce este securitatea LLM? Cum să atenuați cele 10 riscuri de securitate din topul OWASP

Un atac care păcălește un AI să trateze instrucțiunile unui atacator drept comenzi — injecția de prompt — s-a aflat pe locul 1 în OWASP Top 10 pentru aplicații LLM în fiecare ediție din 2023 încoace.

Lista este cel mai apropiat lucru de un consens din domeniul securității AI. Proiectul a pornit ca un mic grup de profesioniști în securitate, iar acum se bazează pe peste 600 de experți colaboratori din peste 18 țări.

Suntem o companie de AI care publică un ghid despre felul în care AI-ul poate fi convins să facă lucruri, așa că nu ne vom preface că problema este rezolvată. Wilson, unul dintre coordonatorii proiectului OWASP, a fost destul de clar în privința mecanismelor de apărare actuale: „...sincer, nu cred că suntem la 99%.”

Ediția 2026 începe în aceeași notă. Coordonatorul proiectului ne îndeamnă să „încetăm să mai încercăm să construim un model care nu poate fi păcălit” și să proiectăm sistemul din jurul lui astfel încât un model păcălit să nu poată strica nimic important.

Adoptăm această poziție pentru toate cele 10 riscuri de pe lista OWASP din 2026.

Ce înseamnă securitatea LLM?

Securitatea LLM înseamnă protejarea modelelor AI și a aplicațiilor care le folosesc împotriva atacurilor și a utilizării abuzive. Riscul crește odată cu resursele la care este conectat modelul: fișierele și datele pe care le poate citi și instrumentele pe care le poate folosi, cum ar fi e-mailul, căutarea sau o bază de date a companiei.

Într-un software securizat corespunzător, există o graniță fermă între instrucțiunile pe care le urmează un program și informațiile pe care le procesează. LLM-urile însă nu au această graniță.

Tot ce citește modelul ajunge sub forma unui singur flux lung de text: instrucțiunile dezvoltatorului, întrebarea ta, o pagină web pe care a consultat-o. Modelele AI ar trebui să țină evidența celui care vorbește, fie că este vorba de dezvoltator, de utilizator sau chiar de model, atunci când analizează o problemă.

Însă cercetătorii Jasmine Cui și Charles Ye au descoperit că modelele ghicesc în mare parte cine vorbește după felul în care sună textul. Așadar, dacă un atacator scrie ceva care sună ca raționamentul propriu al modelului, modelul poate crede că ideea i-a aparținut. Este o problemă pentru orice mecanism de siguranță care depinde de capacitatea modelului de a ști cine deține controlul.

Ne-am confruntat cu aceeași problemă în cazul propriilor noștri agenți AI. CISO-ul nostru, Kyle Polley, a declarat pentru ISMG că agenții „s-ar putea să nu respecte politicile chiar dacă le adaugi în promptul de sistem”. De aceea am creat Numbat, un instrument open-source care verifică ce urmează să facă un agent și poate bloca acțiunea dacă aceasta încalcă o regulă de securitate configurată.

Securitatea LLM înseamnă să accepți că modelul va primi uneori ordine de la persoana greșită și să construiești în jurul lui bariere de protecție AI care rezistă chiar și atunci când se întâmplă asta.

Care sunt cele mai bune practici pentru securitatea LLM?

Vom parcurge în ordine OWASP Top 10 pentru aplicații LLM 2026, de la nr. 1 la nr. 10.

Pentru fiecare risc, vei găsi o explicație pe înțelesul tuturor despre cum pot merge lucrurile prost și un exemplu real. Apoi vom prezenta practicile care pot ajuta la prevenirea lui sau, cel puțin, la limitarea pagubelor.

1. Ține sub control injecția de prompt

O injecție de prompt are loc atunci când un atacator face ca un AI să urmeze instrucțiuni pe care nu ar trebui să le urmeze. Aceste instrucțiuni pot veni direct, într-un chat, sau pot fi plantate într-un e-mail, o pagină web sau un document.

Al doilea tip este cunoscut drept injecție indirectă de prompt. Îi ceri asistentului tău să rezume un document. Cei care l-au scris i-au cerut asistentului să le trimită fișierele tale private. Dacă asistentul urmează aceste instrucțiuni, persoana care a scris documentul ți-a împrumutat, practic, accesul.

PCMag compară securitatea prompturilor cu astuparea găurilor dintr-o piatră poroasă. Astupi o deschidere, iar apa găsește alta. „Un atac își găsește drumul; este remediat, dar nenumărate alte căi de atac rămân de descoperit, pur și simplu din cauza caracterului dinamic al sistemelor precum LLM-urile.”

Exemplu: În iunie 2025, cercetătorii de la Aim Security au descoperit EchoLeak, o vulnerabilitate care a păcălit Microsoft 365 Copilot să divulge informații private ale companiei. Când un angajat punea o întrebare obișnuită legată de muncă, Copilot putea să preia e-mailul, să urmeze instrucțiunile ascunse în el și să trimită informații sensibile atacatorului. Atacul a trecut de verificările menite să detecteze instrucțiunile rău intenționate și să elimine linkurile suspecte.

Ce poți face:

• Respectă „Regula celor două” a Meta: EchoLeak avea nevoie de un AI care să poată citi datele companiei, să citească e-mailuri externe și să trimită informații în afară — iar acesta le avea pe toate trei. Limitarea lui la două dintre aceste capabilități împiedică o injecție de prompt să obțină prea mult control. Dacă sarcina le necesită pe toate trei, solicită aprobare umană înainte de fiecare acțiune.
• Testează împotriva atacatorilor care îți cunosc mecanismele de apărare: Oferă-le celor care îți testează securitatea regulile și filtrele pe care le-ai implementat, apoi lasă-i să le ocolească. Într-un studiu, atacatorii care s-au adaptat la mecanismele de apărare au reușit în peste 90% din cazuri împotriva majorității celor 12 mecanisme de apărare testate.

2. Împiedică scurgerea informațiilor sensibile

Când sistemele AI oferă informații private unor persoane care nu ar trebui să le vadă, fenomenul se numește divulgarea informațiilor sensibile. Asta poate însemna dezvăluirea detaliilor de plată ale unui client sau lăsarea unor conversații private într-o bază de date partajată.

Multe scurgeri încep cu „partajarea excesivă”. Să presupunem că o companie își conectează AI-ul la unități de stocare și baze de cunoștințe cu permisiuni laxe. AI-ul preia tot ce poate accesa, exact așa cum a fost proiectat. Nu e nevoie ca cineva să pătrundă prin efracție, dar e ca și cum LLM-ul ar fi fost deja spart.

Exemplu: În ianuarie 2025, cercetătorii Wiz au găsit o bază de date DeepSeek expusă pe internet, cu peste un milion de intrări de jurnal, inclusiv istoricul conversațiilor și chei API, pe care software-ul le folosește pentru a accesa alte servicii. Cercetătorii nu au fost nevoiți să convingă modelul să dezvăluie nimic.

Ce poți face:

• Verifică accesul înainte ca AI-ul să citească datele: Aplicația ta ar trebui să verifice ce documente are voie să vadă persoana care pune întrebarea înainte de a le transmite modelului.
• Protejează înregistrările pe care le lasă în urmă AI-ul: Elimină detaliile private și cheile secrete înainte de a salva jurnalele de activitate, solicită autentificarea și restricționează accesul la persoanele care au nevoie de ele. Stabilește o perioadă de păstrare, astfel încât aceste înregistrări să nu se acumuleze la nesfârșit.

3. Limitează autonomia excesivă

Sistemele AI cu autonomie excesivă au mai multă putere decât le cere rolul: instrumente de care nu au nevoie, permisiuni care depășesc sarcina lor sau libertatea de a acționa fără verificări. Cauza este irelevantă aici.

Un prompt de injecție, o eroare sau un model care pur și simplu greșește duc toate la același rezultat. Până la urmă, AI-ul va face ceva distructiv dacă are capacitatea de a o face.

Exemplu: În iulie 2025, fondatorul SaaStr, Jason Lemkin, a relatat că agentul de programare al Replit i-a șters baza de date cu 1.206 înregistrări despre directori executivi, în ciuda instrucțiunilor de a nu face modificări. Inițial, agentul a spus că datele nu pot fi restaurate, deși ulterior recuperarea s-a dovedit posibilă. Jason a constatat că, deși îi spusese agentului să nu atingă baza de date, acesta nu își pierduse capacitatea de a o șterge.

Extinde

Sursa: X

Ce poți face:

• Elimină capabilitățile de care sarcina nu are nevoie: Limitează atât instrumentele pe care le primește un agent, cât și ceea ce pot face acele instrumente. Un asistent care rezumă e-mailuri are nevoie de permisiunea de a le citi, nu de a le trimite sau de a le șterge.
• Plasează verificările permisiunilor în afara AI-ului: De fiecare dată când este solicitată o acțiune, asigură-te că aceasta este verificată în raport cu regulile tale de securitate și cere aprobarea unei persoane.

4. Verifică ce intră în lanțul tău de aprovizionare AI

Puține companii creează AI de la zero, iar numărul lor scade de la an la an. Potrivit sondajului The State of Generative AI in the Enterprise 2025 realizat de Menlo Ventures, 53% dintre companii au achiziționat modele AI în 2024, procent care a crescut la 76% în 2025.

De cele mai multe ori, companiile descarcă modele de pe platforme precum Hugging Face, le antrenează suplimentar pe seturi de date colectate de alții și adaugă extensii și pachete de cod scrise de necunoscuți.

Fiecare dintre aceste componente reprezintă o cale de intrare. Dacă una este compromisă, problema ajunge direct în produsul tău.

Exemplu: Depozitele publice de modele ale Hugging Face au crescut de la 2,43 milioane la 2,96 milioane între ianuarie 2026 și august 2026. Totuși, în iulie 2026, modelele OpenAI au ocolit controalele menite să le țină departe de internet în timpul testelor interne de securitate și au pătruns în anumite părți ale sistemelor Hugging Face. De fapt, un agent a recuperat 14 credențiale de acces expuse public, a verificat că funcționează și le-a partajat cu alți agenți. Agenții au exploatat apoi vulnerabilități care le-au permis să ruleze cod pe serverele Hugging Face.

„Impunem cerințe mai stricte privind alinierea pe tot parcursul ciclului de viață al unui model și creăm medii sandbox mai izolate, restricționăm accesul la internet și controlăm și mai strict accesul la ponderile modelelor”, se arată în raportul OpenAI.

Ce poți face:

• Fixează modelele la o versiune exactă și verifică-le: Fixează fiecare model la o versiune analizată și verifică-i amprenta fișierului înainte de a-l încărca, astfel încât un fișier înlocuit să nu se poată strecura sub aceeași etichetă. OWASP recomandă și semnăturile digitale, cu o precizare: o semnătură dovedește de unde provine un model, nu și că acesta este sigur.
• Verifică fiecare pachet pe care ți-l sugerează AI-ul: Înainte de a instala un pachet de cod recomandat de un asistent AI, confirmă că acesta există, că este pachetul pe care l-ai avut în vedere și că provine de la editorul la care te aștepți.

5. Protejează-te împotriva otrăvirii datelor și a modelelor

Un AI otrăvit învață din date corupte. Acestea pot fi exemplele folosite pentru ajustarea sa fină sau o bază de cunoștințe în care caută răspunsuri. Modelul pare în continuare să funcționeze; doar că învață lecțiile greșite, iar uneori învață să se comporte necorespunzător numai atunci când vede o anumită expresie declanșatoare.

Cu o astfel de expresie, modelul va trece orice test la care îl supui, până când cineva o folosește.

Extinde

În plus, efectele sunt foarte greu de anulat. Otrăvirea nu este o eroare pe care o poți remedia cu un patch. Dacă datele tale sunt greșite, s-ar putea să fie nevoie să le reverifici, să reantrenezi modelul sau să-l înlocuiești complet.

Exemplu: În octombrie 2025, cercetătorii de la Anthropic, UK AI Security Institute și Alan Turing Institute au arătat că 250 de documente otrăvite pot învăța un model să producă text fără sens ori de câte ori întâlnește un anumit declanșator. Același număr a funcționat pentru toate cele patru dimensiuni de model testate, deși cel mai mare a fost antrenat pe un volum de date curate de peste 20 de ori mai mare.

Ce poți face:

• Urmărește proveniența datelor: Păstrează o evidență a fiecărui set de date și model pe care îl folosești, a provenienței fiecăruia și a modificărilor dintre versiuni. Recomandăm controlul versiunilor pentru seturile de date, astfel încât, dacă apare o otrăvire, să poți reveni la o versiune curată și să afli cum a pătruns.
• Testează existența backdoorurilor: Un „backdoor” este un comportament ascuns pe care un atacator îl plantează într-un model și care așteaptă o anumită expresie sau un alt declanșator pentru a se activa. Testează existența lor cu date de intrare concepute să determine modelul să-și încalce regulile obișnuite.

6. Pune limite consumului nelimitat

Când sistemele AI nu au nicio limită privind volumul de muncă pe care îl pot efectua sau costurile pe care le pot genera, consumul lor este considerat „nelimitat”. Majoritatea serviciilor AI taxează per utilizare, așa că un atacator ți-ar putea umfla factura sau ar putea construi o copie a modelului tău.

OWASP numește problema de fond „asimetria costurilor”. O cerere scurtă și ieftină poate declanșa calcule costisitoare de partea ta.

Exemplu: În mai 2024, echipa Threat Research a Sysdig a descoperit un nou tip de atac numit „LLMjacking”. Un grup de atacatori a vizat 10 servicii LLM găzduite în cloud folosind date de autentificare furate. Aceștia au pătruns printr-o versiune vulnerabilă de Laravel, apoi au aflat ce permiteau datele de autentificare și ce cote existau, cu scopul evident de a vinde accesul. Au fost interogate și numeroase setări de jurnalizare, probabil pentru a evita detectarea. Potrivit Sysdig, în cel mai rău caz, victima ar putea plăti peste 46.000 de dolari pe zi.

Ce poți face:

• Stabilește bugete care opresc cheltuielile: Impune limite stricte de cheltuieli pentru utilizatori individuali, chei API, echipe și contul în ansamblu. Aplică-le oriunde pot intra cereri.
• Stabilește un punct de oprire pentru fiecare sarcină: Limitează cât timp poate rula o sarcină, cât text poate procesa și genera și câte apeluri de instrumente poate face. Adaugă opriri automate pentru agenții care se repetă sau își depășesc alocarea.

7. Depistează informațiile eronate înainte de a acționa

Când un AI produce ceva fals care pare corect, iar cineva sau ceva acționează pe baza lui, vorbim de informații eronate. Riscul de bază nu este atât răspunsul greșit în sine, cât faptul că acesta ajunge să fie considerat de încredere și folosit.

Istoricul incidentelor sugerează că specialiștii nu au fost atât de îngrijorați de informațiile eronate pe cât ar fi trebuit. Potrivit scrisorii de deschidere a ediției 2026, votanții au plasat acest risc aproape de coada clasamentului, însă incidentele reale îl plasează aproape de vârf.

Exemplu: În 2025, Deloitte Australia a livrat o analiză a sistemelor IT de asistență socială în baza unui contract guvernamental de 440.000 AUD. Un cercetător de la Universitatea din Sydney, Chris Rudge, a găsit trimiteri la studii inexistente, precum și un citat inventat dintr-o hotărâre a unei instanțe federale. Raportul revizuit a dezvăluit că Deloitte folosise Azure OpenAI GPT-4o în metodologia sa, iar firma a acceptat să ramburseze ultima tranșă. Din păcate, era vorba chiar de o evaluare de asigurare (assurance review).

Ce poți face:

• Verifică dacă dovezile susțin răspunsul: Fundamentează afirmațiile pe surse actuale și autoritare. Pentru un răspuns legat de o politică, preia politica aprobată și verifică dacă aceasta susține concluzia, inclusiv excepțiile ei.
• Verifică înainte ca sistemul să acționeze: Dacă un agent spune că un client a trecut o verificare a identității, confirmă acest lucru în sistemul de verificare înainte de a elibera o plată. Solicită aprobare umană pentru deciziile importante, cu dovezile justificative puse la dispoziția evaluatorului.

8. Limitează pagubele cauzate de expunerea contextului ascuns

Aplicațiile AI îi oferă modelului instrucțiuni și informații de context pe care utilizatorii nu le văd în mod normal. Acestea pot include promptul de sistem, politicile interne, descrierile instrumentelor disponibile și regulile privind cine le poate folosi. Expunerea contextului ascuns are loc atunci când modelul dezvăluie aceste informații cuiva.

În 2026, OWASP a extins această intrare, care se numea anterior „scurgerea promptului de sistem”, deoarece promptul de sistem este doar o parte din ceea ce poate scăpa. Pericolul depinde de ce ai pus acolo. Un ghid privind tonul vocii ajuns public e ușor jenant, dar o cheie API scursă îi oferă cuiva acces la baza ta de date confidențială.

Exemplu: În februarie 2023, utilizatorii au determinat Bing Chat de la Microsoft să-și dezvăluie instrucțiunile interne. Una dintre încercările reușite i-a aparținut lui Marvin von Hagen, care a pretins că este dezvoltator OpenAI și a cerut instrucțiunile pentru a putea configura modelul. Bing a dezvăluit regulile care îi guvernau căutările, răspunsurile și comportamentul de siguranță, precum și numele său intern, Sydney. Printre instrucțiunile dezvăluite se afla una care îi cerea să păstreze confidențialitatea acestor instrucțiuni.

Ce poți face:

• Țineți secretele în afara contextului modelului: Porniți de la premisa că orice poate citi modelul ar putea deveni vizibil pentru utilizatori — stocați parolele, cheile API și tokenurile de acces într-un sistem separat de gestionare a secretelor.
• Asigurați-vă că permisiunile rămân valabile chiar dacă regulile sunt divulgate: Aplicați verificările de acces în codul aplicației. Dacă un instrument este rezervat administratorilor, verificați permisiunile contului utilizatorului înainte de a-l rula.

9. Securizați vectorii și embedding-urile

Când un sistem AI folosește căutarea vectorială pentru a găsi răspunsuri în documentele companiei dumneavoastră, nu caută direct în text. Documentele sunt convertite în „embedding-uri”, adică liste lungi de numere care surprind sensul fiecărui pasaj, și stocate într-o bază de date vectorială. O întrebare este convertită în același mod, iar sistemul extrage pasajele ale căror numere se află cel mai aproape.

OWASP rezumă cele patru moduri în care acest mecanism poate eșua: otrăvirea face sistemul să greșească, inversiunea îl face să divulge date, blocarea îl face să tacă, iar controlul de acces defectuos îl face să ofere orice oricui.

Numerele nu sunt abstracțiunea sigură care par a fi. Embedding-urile stocate pot fi transformate înapoi în text, iar o metodă a reconstituit exact 92% dintre pasajele scurte, de 32 de tokenuri, în testele sale. Așadar, și o copie de rezervă scursă care conține „doar embedding-uri” poate expune conținutul documentelor.

Exemplu: Într-o cercetare prezentată la USENIX Security 2025, cercetătorii au arătat că un singur document conceput cu atenție poate împiedica un sistem AI să răspundă la o anumită întrebare. Ei l-au adăugat în colecția în care căuta sistemul. Când sistemul l-a găsit, putea răspunde că nu are suficiente informații sau că un răspuns ar fi nesigur. Documentul nu trebuia să-i ceară sistemului să-și ignore regulile. Acest fenomen se numește „blocarea regăsirii” (retrieval jamming).

Ce poți face:

• Păstrați indexuri separate pentru datele publice și cele private: Nu amestecați conținutul extras de pe web cu datele partenerilor sau cu documentele interne confidențiale. Separați fizic datele în funcție de nivelul de încredere, în loc să etichetați conținutul dintr-un singur index: astfel eliminați o întreagă categorie de configurări greșite, iar conținutul extras de pe internet nu poate ajunge alături de documentele consiliului de administrație.
• Tratați embedding-urile ca pe documentele din care provin: Criptați-le, protejați copiile de rezervă ale bazei de date vectoriale la fel ca fișierele sursă și ștergeți embedding-urile atunci când ștergeți originalul. Cheile API pentru serviciul de embedding trebuie păstrate secrete.

10. Verificați rezultatele AI înainte de a le transmite mai departe

Ori de câte ori o aplicație transmite rezultatele AI către un alt sistem fără a verifica dacă sunt sigure pentru a fi utilizate acolo, aceasta gestionează necorespunzător rezultatele LLM.

Această categorie acoperă și codul nesigur pe care asistenții AI de programare îl generează la scară largă. Prin urmare, fiecare linie scrisă de un asistent este, la rândul ei, un rezultat.

Exemplu: În 2025, cercetătorul Johann Rehberger a arătat cum asistentul de programare Amp de la Sourcegraph putea divulga conținutul conversațiilor doar prin afișarea unei imagini. El a folosit injecția de prompturi pentru a-l determina pe Amp să includă informații private în adresa web a unei imagini. Aplicația a preluat apoi automat imaginea respectivă, trimițând informațiile către serverul său. Eșecul de gestionare a rezultatelor a constat tocmai în acea solicitare automată: textul generat de model a devenit o conexiune către un server extern, care a transportat date private.

Ce poți face:

• Faceți rezultatele sigure pentru destinația lor: Verificați și procesați răspunsurile în funcție de locul în care vor ajunge. Pentru o pagină web, împiedicați ca textul generat să devină cod executabil. Pentru o bază de date, folosiți interogări parametrizate, care păstrează valorile furnizate separat de comenzi.
• Împiedicați răspunsurile să creeze automat conexiuni externe: Dezactivați în mod implicit încărcarea automată a imaginilor, a previzualizărilor de linkuri și a paginilor încorporate în răspunsurile modelului. Limitați conexiunile necesare la destinații aprobate în mod explicit.

Cum securizează Perplexity modelele LLM?

Pornim de la premisa că fiecare dintre riscurile de mai sus se va materializa la un moment dat și proiectăm sistemele astfel încât, atunci când se întâmplă, să nu poată provoca mari pagube. Directorul nostru pentru securitatea informației (CISO), Kyle Polley, a explicat cum facem acest lucru într-un workshop recent.

• Agentul primește propriul computer, care pornește gol: Instrumentele de tip agent instalate pe laptopul dumneavoastră pot obține acces la fișierele, aplicațiile și datele de autentificare salvate pe acesta. Perplexity Computer funcționează invers. Fiecare sarcină rulează în propriul sandbox izolat și, după cum spune Polley, „în mod implicit, nu are acces la nimic”.
• Agentul nu vede niciodată parolele: Datele de autentificare pentru serviciile conectate sunt stocate în afara sandboxului. Când agentul trebuie să acceseze un serviciu precum GitHub, trimite o solicitare fără date de autentificare atașate. Un gateway verifică dacă destinația și solicitarea corespund așteptărilor, apoi adaugă datele de autentificare la ieșire. Agentul poate folosi conexiunea fără să primească cheile.
• Permisiunile dumneavoastră se păstrează și le puteți restrânge: Conexiunile realizate prin OAuth păstrează permisiunile de acces pe care le aveți în serviciul conectat. Dacă dumneavoastră nu puteți vedea ceva, nici agentul nu poate.
• Fiecare pagină web este tratată ca un străin: Am creat BrowseSafe pentru Comet, browserul nostru agentic, deoarece instrumentele pe care le-am testat nu ne-au satisfăcut nevoile în utilizarea reală. Browserul scanează paginile web și alt conținut extern, inclusiv e-mailurile, pentru a detecta injecțiile de prompturi. Am publicat ca open source atât modelul, cât și setul de date.
• Monitorizăm agentul și mașinile pe care rulează: Numbat se situează între decizia unui agent de a acționa și rularea efectivă a instrumentului. Numbat înregistrează activitatea agenților de programare compatibili și poate bloca acțiunile care încalcă politicile configurate înainte ca acestea să fie executate. Bumblebee inventariază pachetele software de pe laptopuri, servere și pipeline-uri de build și le semnalează pe cele cunoscute ca fiind rău intenționate. Ambele sunt open source.
• Furnizorii de modele nu vă păstrează datele: Avem acorduri de retenție zero a datelor cu furnizorii noștri terți de modele LLM. De asemenea, administratorii Enterprise pot reduce perioada de retenție a datelor aplicată de Perplexity la doar 24 de ore.

Am creat Numbat în mod proactiv, dintr-un motiv pe care Polley îl rezumă într-o singură frază: „Cu cât îi oferi unui agent mai multă autonomie, cu atât riscul este mai mare”.

Întrebări frecvente despre securitatea LLM

Care este cel mai sigur LLM?

Niciun LLM nu face singur o aplicație sigură — modelele pot confunda în continuare conținutul pe care ar trebui doar să-l citească cu instrucțiuni pe care ar trebui să le urmeze. În plus, mecanismele de apărare care par solide în testele standard pot ceda sub presiune.

O întrebare mai bună este care configurație este cea mai sigură pentru cazul dumneavoastră de utilizare. Asta înseamnă permisiuni limitate, date de autentificare ținute departe de model, aprobare umană pentru acțiunile riscante și testare efectuată de persoane care vă cunosc mecanismele de apărare.

Ce sunt vulnerabilitățile LLM?

Vulnerabilitățile LLM sunt puncte slabe care permit ca un sistem AI să fie păcălit, să divulge date sau să provoace daune, fie din cauza unui atacator, fie din cauza propriilor greșeli.

Cele zece riscuri majore sunt injecția de prompturi, divulgarea informațiilor sensibile, autonomia excesivă, lanțul de aprovizionare, otrăvirea datelor și a modelului, consumul nelimitat, dezinformarea, expunerea contextului ascuns, vulnerabilitățile vectorilor și ale embedding-urilor și gestionarea necorespunzătoare a rezultatelor.

Sunt sigure modelele LLM private?

Pot fi o opțiune mai sigură în anumite situații, dar nu în mod implicit. Aveți mai mult control asupra modului în care sunt gestionate datele dacă rulați un model pe propria infrastructură sau într-un mediu cloud. Totuși, nu există o modalitate automată de a preveni injecțiile de prompturi, autonomia excesivă, otrăvirea sau dezinformarea.

Atunci când găzduiți singur modelul, sunteți responsabil și pentru modelul pe care îl descărcați, inclusiv pentru riscurile legate de lanțul de aprovizionare și pentru infrastructura de care are nevoie.