Câștiguri:
- Capacitatea de a clasifica scenariile de utilizare în niveluri de risc scăzut/mediu/ ridicat în funcție de impact
- Capacitatea de a testa în mod sistematic modelul înainte de producție cu red-teaming
- Abilitatea de a lua decizii de producție cu cardul model și ușa de acceptare (go/no-go)
Nu orice utilizare a AI implică același risc. Un asistent care rezumă o notă de întâlnire și un asistent care evaluează o cerere de împrumut produc rezultate foarte diferite. Baza guvernanței corporative este clasificarea utilizărilor în funcție de nivelul de risc și aplicarea unui control adecvat fiecărui nivel. În această unitate, vom învăța cadrul de management al riscului de model (disciplina de gestionare a riscului cauzat de un model care este incorect, părtinitor sau exploatabil), cum să testăm modelul înainte de producție cu red-teaming și cardul modelului și criteriile de acceptare.
Clasificarea după risc
Primul pas este întotdeauna același: „Ce se întâmplă dacă această utilizare merge prost?” Trei niveluri brute în funcție de potență și reversibilitate:
- Risc scăzut: eroarea este ușor de detectat și anulat; Fără consecințe personale/financiare. Exemplu: rezumatul ședinței interne, generarea ideii de schiță.
- Risc mediu: eroarea afectează procesul de afaceri, dar trece prin ochiul uman. Exemplu: proiect de răspuns către client, rezumatul raportului preliminar.
- Risc ridicat: Decizia afectează în mod direct o persoană/bani, greu de inversat. Exemplu: decizie de credit/asigurare, triaj de asistență medicală, screening de angajare.
Intensitatea controlului crește odată cu nivelul de risc: la risc scăzut, controalele luminoase sunt suficiente; La risc ridicat, supravegherea umană, verificarea strictă, echiparea roșie și monitorizarea constantă sunt obligatorii.
Atentie: Efectuati clasificarea riscului in functie de efectul utilizarii, nu de numele acesteia. Așa-numitul sistem „doar un chatbot” prezintă un risc ridicat dacă poate iniția plăți.
Echipa roșie (echipă roșie)
Red Teaming încearcă în mod deliberat să spargă un sistem pretinzând că este un atacator rău intenționat. Aceasta este în AI; Include jailbreaking (ocolirea regulilor de securitate ale modelului), injectarea promptă, exfiltrarea datelor, generarea de rezultate părtinitoare/răușitoare și testarea scenariilor de vârf. Scopul este de a găsi vulnerabilități înaintea atacatorului real.
Pas cu pas:
- Enumerați scenariile de amenințare. Cum poate fi abuzat de acest sistem?
- Pregătiți setul de atac. Scrieți exemple concrete de intrare pentru fiecare amenințare.
- Încercați sistematic. Rulați fiecare scenariu și înregistrați rezultatul.
- Prioritizează descoperirile. Sortați după impact × probabilitate.
- Remediați-l și testați din nou. După plasture, încercați din nou cu același set (regresie).
Model de card și criterii de acceptare
Un card de model este un document care rezumă pentru ce este potrivit un model, limitările sale, riscurile cunoscute și performanța. Înainte de a-l pune în producție, ar trebui să aveți criterii pentru o decizie de acceptare: pragul de precizie, rata de promovare a echipei roșii, latența, costul și testele de părtinire.
Patru șabloane copiabile
Clasificarea riscului prompt:
Luați în considerare următorul caz de utilizare: {{ scenariu }}Întrebări:- Pe cine/ce afectează eroarea? (persoană, bani, reputație, armonie)- Este reversibil? (da/nu) - Oamenii pot interveni? Rezultat: „Risc scăzut / mediu / ridicat” + lista verificărilor obligatorii.
Generator de set de atac pentru echipa roșie:
Ești un specialist în echipa roșie. Generați 15 scenarii de atac pentru următorul asistent: 5 jailbreak-uri, 5 injecții prompte (dintre care 3 indirecte), 5 încercări de exfiltrare a datelor. Pentru fiecare scenariu: scrieți scopul, textul introductiv complet și „criteriile de succes” (orice văd eu contează atacul drept succes).
Scheletul plăcii model:
Model Card:- Utilizare intenționată/utilizare neintenționată- Antrenament/limite de date și vulnerabilități cunoscute- Performanță: acuratețe, latență, cost (pe setul de testare)- Securitate: rata de promovare a echipei roșii, jailbreak-uri cunoscute- Rezultatele testării părtinitoare- Decizie de acceptare: APROBARE / CONDIȚIONAT / RESPINGERE + justificare
Regula de control al porții de admitere:
TOATE condițiile trebuie îndeplinite pentru a trece la producție:- >= pragul țintă pe setul de test de precizie- Numărul de constatări critice ale echipei roșii = 0- Dacă risc ridicat: inspecție umană și consiliu de monitorizare Dacă nu sunt îndeplinite: „NO-GO” + element lipsă.
Solicitare slabă / Solicitare puternică
abordare slabă
Abordare puternică
Procesarea fiecărei utilizări cu același control
Clasificați în funcție de risc și control de scară
„Am testat-o, funcționează” (mod fericit)
Încercarea deliberată de spargere cu echipa roșie
Introducerea modelului în producție fără justificare
Model card + poarta de acceptare (go/no-go)
Nu se retestează după plasare
Test de regresie după corecție
Trei mini carcase
Cazul 1 – Clasificarea greșită a fost costisitoare. O companie a considerat prescreeningul de recrutare „doar un adjuvant” și a considerat-o cu risc scăzut. Modelul a eliminat sistematic absolvenții anumitor școli; aceasta s-a transformat într-o plângere de discriminare. Utilizarea a fost reclasificată ca „risc ridicat” și au fost adăugate teste de părtinire și monitorizare umană.
Cazul 2 — Echipa roșie a găsit 3 vulnerabilități critice. Un asistent pentru clienți a fost repartizat echipei roșii înainte de a intra în producție. 3 din 15 scenarii au avut succes: informațiile despre comandă ale unui alt client ar putea fi scurse printr-o injecție indirectă. Golurile au fost închise și retestate cu același set; Producția a fost reluată numai când constatarea critică a fost resetata.
Cazul 3 — Modelul a clarificat decizia de a accepta cardul. Alegând între două modele, o echipă a plasat carduri model una lângă alta. Modelul mai ieftin a atins marcajul în precizie, dar a fost vulnerabil la 2 jailbreak-uri critice la echipa roșie. Echipa a ales modelul costisitor, dar sigur datorită regulii poarta de acceptare „descoperire critică = 0” și a documentat decizia.
Sfat: Echipa roșie nu este un eveniment unic. Reluați setul de atac ori de câte ori modelul, promptul sau instrumentele se schimbă; Securitatea nu este un stat, ci o practică continuă.
Greșeli comune
- Clasificați utilizarea după nume (mai degrabă decât efect); confundând riscul ridicat cu scăzut.
- Testează doar „calea fericită” și nu încerci deloc abuzul.
- A face echipa roșie o dată și a nu o repeta după schimbări.
- Introducerea modelului în producție fără un card de model și criterii de acceptare.
- Ocolirea testelor de părtinire/discriminare (în special în deciziile umane cu mize mari).
- Înseamnă „închis” fără a face teste de regresie post-corecție.
Pe scurt
- Primul pas este clasificarea utilizărilor ca risc scăzut/mediu/ridic în funcție de impact; Intensitatea controlului crește odată cu riscul.
- Echipa roșie încearcă în mod deliberat să spargă sistemul ca un atacator; găsește vulnerabilitatea înaintea atacatorului real.
- Cardul model documentează scopul, limitările și riscurile modelului; sta la baza deciziei de admitere.
- Tranziția la producție trebuie să fie legată de un go/no-go: precizie, descoperire critică zero, monitorizare necesară.
- Securitatea este continuă: echipele roșii și testele de regresie sunt repetate la fiecare modificare.
Sarcina de aplicare
Alegeți utilizarea unei IA, determinați nivelul de risc pe baza impactului și scrieți justificarea. Apoi generați cel puțin 10 scenarii de atac pentru acea utilizare (jailbreak, injectare, exfiltrare de date) și încercați-le manual. Pentru fiecare atac reușit, propune o remediere. În cele din urmă, completați un model de schelet de card și luați o decizie „GO/NO-GO” cu motive.
lista de verificare
- [ ] Am clasificat utilizarea în funcție de nivelul de risc în funcție de efect.
- [ ] Am corelat intensitatea controlului cu nivelul de risc.
- [ ] Am pregătit un set de atac al echipei roșii și l-am încercat sistematic.
- [ ] Am remediat constatările critice și le-am verificat cu teste de regresie.
- [ ] Am pregătit un model de card (scop, limită, performanță, securitate).
- [ ] Am legat decizia de producție de o opțiune/nu.