Model Risk Management og Red Team

Gevinster:

• Evne til å klassifisere bruksscenarier i lav/middels/høy risiko i henhold til påvirkning
• Evne til systematisk å teste modellen før produksjon med red-teaming
• Evne til å ta produksjonsbeslutninger med modellkort og akseptdør (go/no-go)

Ikke hver bruk av AI har samme risiko. En assistent som oppsummerer et møtenotat og en assistent som vurderer en lånesøknad gir svært forskjellige resultater. Grunnlaget for eierstyring og selskapsledelse er å klassifisere bruk i henhold til risikonivå og anvende passende kontroll på hvert nivå. I denne enheten vil vi lære rammeverket for modellrisikostyring (disiplinen med å håndtere risikoen forårsaket av at en modell er feil, partisk eller utnyttelig), hvordan man tester modellen før produksjon med red-teaming, og modellkortet og akseptkriteriene.

Klassifisering etter risiko

Det første trinnet er alltid det samme: "Hva skjer hvis denne bruken går galt?" Tre grove nivåer i henhold til styrke og reversibilitet:

• Lav risiko: Feil oppdages lett og angres; Ingen personlige/økonomiske konsekvenser. Eksempel: intern møteoppsummering, utkast til idégenerering.
• Middels risiko: Feilen påvirker forretningsprosessen, men går gjennom det menneskelige øyet. Eksempel: utkast til svar til kunde, foreløpig rapportoppsummering.
• Høy risiko: Beslutning påvirker en person/penger direkte, vanskelig å reversere. Eksempel: kreditt-/forsikringsvedtak, triage av helsetjenester, sysselsettingsscreening.

Kontrollintensiteten øker med risikonivået: ved lav risiko er lyskontroller tilstrekkelig; Ved høy risiko er menneskelig tilsyn, streng verifisering, red teaming og konstant overvåking obligatorisk.

OBS: Gjør risikoklassifisering i henhold til effekten av bruken, ikke navnet. Det såkalte «bare en chatbot»-systemet er høyrisiko hvis det kan igangsette betalinger.

Red Team (Red-Teaming)

Red teaming prøver bevisst å bryte et system ved å utgi seg for å være en ondsinnet angriper. Dette er i AI; Det inkluderer jailbreaking (omgå modellens sikkerhetsregler), umiddelbar injeksjon, dataeksfiltrering, generering av partisk/ondsinnet utdata og testing av kantscenarier. Målet er å finne sårbarheter før den virkelige angriperen.

Trinn for trinn:

1. List opp trusselscenarier. Hvordan kan dette systemet misbrukes?
2. Forbered angrepssettet. Skriv konkrete inngangseksempler for hver trussel.
3. Prøv systematisk. Kjør hvert scenario og registrer resultatet.
4. Prioriter funn. Sorter etter innvirkning × sannsynlighet.
5. Fiks det og test på nytt. Etter oppdateringen, prøv igjen med det samme settet (regresjon).

Modellkort og akseptkriterier

Et modellkort er et dokument som oppsummerer hva en modell er egnet for, dens begrensninger, kjente risikoer og ytelse. Før du setter den i produksjon, bør du ha kriterier for en akseptbeslutning: nøyaktighetsterskel, red team bestått rate, latens, kostnad og skjevhetstester.

Fire kopierbare maler

Forespørsel om risikoklassifisering:

Tenk på følgende brukstilfelle: {{ scenario }}Spørsmål:- Hvem/hva påvirker feilen? (person, penger, omdømme, harmoni)- Er det reversibelt? (ja/nei) - Kan mennesker gripe inn? Resultat: "Lav / Middels / Høy risiko" + liste over obligatoriske kontroller.

Red team-angrepssettgenerator:

Du er en spesialist på rødt lag. Generer 15 angrepsscenarier for følgende assistent: 5 jailbreaks, 5 prompte injeksjoner (hvorav 3 er indirekte), 5 dataeksfiltreringsforsøk. For hvert scenario: skriv formålet, den fullstendige introduksjonsteksten og "suksesskriterier" (det jeg ser teller angrepet som vellykket).

Modell bordskjelett:

Modellkort:- Tiltenkt bruk / utilsiktet bruk- Trenings-/datagrenser og kjente sårbarheter- Ytelse: nøyaktighet, latens, kostnad (på testsett)- Sikkerhet: red team-passrate, kjente jailbreaks- Bias-testresultater- Akseptbeslutning: GODKJENNING / BETINGET / AVVISNING + begrunnelse

Regel for inngangsportkontroll:

ALLE betingelser må være oppfylt for å gå til produksjon:- >= målterskel på nøyaktighetstestsett- Red teamkritiske funn teller = 0- Hvis høy risiko: menneskelig inspeksjon og overvåkingstavle Hvis ingen er oppfylt: "NO-GO" + manglende element.

Svak forespørsel / sterk forespørsel

dårlig tilnærming

Sterk tilnærming

Behandler hver bruk med samme kontroll

Klassifiser etter risiko og skalakontroll

"Vi testet det, det fungerer" (med glede)

Bevisst bruddforsøk med det røde laget

Å sette modellen i produksjon uten begrunnelse

Modellkort + akseptport (go/no-go)

Tester ikke på nytt etter patching

Regresjonstest etter korrigering

Tre minivesker

Sak 1 – Feilklassifisering var kostbar. Ett selskap anså forhåndsscreeningen for rekruttering som "bare et tillegg" og anså det som lav risiko. Modellen eliminerte systematisk nyutdannede fra visse skoler; dette ble til en diskrimineringsklage. Bruk ble omklassifisert som "høy risiko" og skjevhetstesting og menneskelig overvåking ble lagt til.

Tilfelle 2 - Rødt team fant 3 kritiske sårbarheter. En kundeassistent ble tildelt det røde teamet før de gikk i produksjon. 3 av 15 scenarier var vellykkede: en annen kundes ordreinformasjon kunne lekket gjennom en indirekte injeksjon. Hullene ble lukket og testet på nytt med samme sett; Produksjonen ble gjenopptatt først når det kritiske funnet ble tilbakestilt.

Sak 3 — Modellen klargjorde beslutningen om å godta kortet. Ved å velge mellom to modeller, plasserte et team modellkort side ved side. Den billigere modellen traff blink i nøyaktighet, men var sårbar for 2 kritiske jailbreaks på det røde laget. Teamet valgte den dyre, men sikre modellen på grunn av akseptporten «kritisk funn = 0»-regelen og dokumenterte beslutningen.

Tips: Rødt lag er ikke en engangshendelse. Kjør angrepssettet på nytt når modellen, ledeteksten eller verktøyene endres; Sikkerhet er ikke en stat, men en pågående praksis.

Vanlige feil

• Klassifiser bruk etter navn (i stedet for effekt); forveksler høy risiko med lav.
• Just testing the “happy path” and not trying the abuse at all.
• Gjør det røde laget en gang og ikke gjenta det etter endringer.
• Sette modellen i produksjon uten modellkort og akseptkriterier.
• Omgå skjevhets-/diskrimineringstesting (spesielt ved menneskelige beslutninger med høy innsats).
• Det betyr "stengt" uten å utføre regresjonstesting etter korreksjon.

Oppsummert

• Det første trinnet er å klassifisere bruk som lav/middels/høy risiko i henhold til påvirkning; Kontrollintensiteten øker med risiko.
• Red teaming prøver bevisst å bryte systemet som en angriper; finner sårbarheten før den virkelige angriperen.
• Modellkortet dokumenterer modellens formål, begrensninger og risikoer; ligger til grunn for opptaksvedtaket.
• Overgang til produksjon må være knyttet til en go/no-go: nøyaktighet, kritisk funn null, nødvendig overvåking.
• Sikkerheten er kontinuerlig: Red teaming og regresjonstesting gjentas med hver endring.

Søknadsoppgave

Velg din bruk av en AI, bestem risikonivået basert på virkningen, og skriv begrunnelsen. Generer deretter minst 10 angrepsscenarier for den bruken (jailbreak, injeksjon, dataeksfiltrering) og prøv dem manuelt. For hvert vellykket angrep, foreslå en løsning. Til slutt, fyll ut et modellkortskjelett og ta en "GO/NO-GO" avgjørelse med begrunnelse.

sjekkliste

• [ ] Jeg har klassifisert bruken etter risikonivå i henhold til effekten.
• [ ] Jeg matchet kontrollintensiteten til risikonivået.
• [ ] Jeg forberedte et angrepssett for rødt lag og prøvde det systematisk.
• [ ] Jeg fikset de kritiske funnene og verifiserte dem med regresjonstesting.
• [ ] Jeg forberedte et modellkort (formål, grense, ytelse, sikkerhet).
• [ ] Jeg knyttet produksjonsbeslutningen til en go/no-go.