AI red teaming: samme ord om en anden disciplin

Når en produktchef beder sikkerhedsfunktionen om at red teame den nye AI-assistent, er det ikke sikkert, at begge parter mener det samme. Forskellen hviler på, hvad der afprøves: AI red teaming undersøger, om et AI-system kan bringes til at opføre sig skadeligt eller forkert, mens red teaming i sikkerhedsforstand undersøger, om organisationen opdager og stopper en målrettet modstander. Ordet er fælles, men formål, deltagere og resultater er forskellige.

For CISO’en er det første skridt derfor at oversætte bestillingen. Hvad er det, organisationen er bekymret for: at modellen giver forkerte eller krænkende svar, at den kan lokkes til at udlevere data, eller at en angriber kan bruge AI-løsningen som vej ind i resten af miljøet?

Hvad AI red teaming dækker

Det amerikanske standardiseringsinstitut beskriver i sin profil for generativ AI, AI 600-1, AI red teaming som en praksis i udvikling. Øvelserne foregår ofte i et kontrolleret miljø og i samarbejde med dem, der udvikler modellen, og formålet er at finde mulig skadelig adfærd, forstå hvordan den kan opstå, og presse de indbyggede sikkerhedsforanstaltninger.

Det, der vurderes, er først og fremmest modellens svar og handlinger. Er de unøjagtige, diskriminerende eller skadelige? Kan sikkerhedsforanstaltningerne omgås? Opfører systemet sig anderledes i en bestemt sammenhæng end forventet?

Profilen nævner også, at kvaliteten af resultatet afhænger af, hvem der deltager. Fagfolk fra det område, systemet skal bruges i, almindelige brugere og blandede hold kan hver finde noget forskelligt. Det er en anden sammensætning end et klassisk red team, hvor deltagerne er specialister i at efterligne angribere. → Ordbog for red teaming

Det, en klassisk øvelse afprøver

En red team-øvelse i sikkerhedsforstand har organisationen som genstand. Holdet efterligner en modstander, der vil nå et aftalt mål, og øvelsen viser, om overvågning, eskalering og beredskab reagerer i tide. Resultatet er en fortælling om forsvaret, ikke en vurdering af, om en model svarer fornuftigt.

To spørgsmål kan hjælpe med at skelne:

Hvad er målet? · modellens adfærd eller organisationens evne til at opdage og reagere.
Hvem skal lære noget? · udviklerne af AI-løsningen eller sikkerhedsfunktionen og blue team.

Hvis begge svar peger på modellen, er der tale om AI red teaming. Peger de på forsvaret, er det en almindelig øvelse, hvor AI-løsningen måske indgår som en del af landskabet. → Hvad er red teaming?

Hvor de to discipliner mødes

Grænsen er ikke skarp, når AI-løsningen er koblet til forretningens data og systemer. En assistent, der kan slå op i kundedata, oprette sager eller sende mails, er ikke kun en model. Den er en del af den samlede angrebsflade, og den har rettigheder, som en modstander kan have interesse i.

I sådan et tilfælde kan AI-løsningen indgå i et scenarie i en klassisk øvelse. Spørgsmålet er da ikke, om modellen siger noget upassende, men om forsvaret ville opdage, at løsningen blev misbrugt som led i et angreb, og om de rettigheder, den har fået, står mål med formålet. Det skal i givet fald afgrænses i scope på samme måde som andre systemer, og leverandørens vilkår for test skal afklares. → Scope i red teaming

Selve afprøvningen af, om en chatbot på hjemmesiden kan misbruges, hører snarere hjemme i en sikkerhedstest af applikationen. Den del er beskrevet på penetrationtest.dk.

Hvem ejer opgaven?

AI red teaming i profilens forstand kan ejes af dem, der udvikler eller indfører AI-løsningen: produktansvarlige, dataspecialister og de fagområder, der kender konsekvenserne af forkerte svar. Sikkerhedsfunktionen er en vigtig part, men ikke nødvendigvis den eneste.

Den klassiske øvelse ejes af sikkerhedsfunktionen med et white team, der styrer forløbet. Her er det CISO’en, der sætter rammerne, godkender scenarierne og tager imod rapporten. Når begge typer foregår i samme organisation, er det en fordel at aftale, hvem der bestiller hvad, så resultaterne ikke blandes sammen, og så ingen tror, at den ene dækker den anden.

Et praktisk greb er at føre begge typer i samme oversigt over planlagte afprøvninger, men med hver sin ejer, sit eget formål og sin egen modtager af resultatet. Så kan ledelsen se, at AI-løsningen er afprøvet på to forskellige måder, og at ingen af dem står alene. Det gør det også lettere at opdage, hvis en AI-løsning med adgang til følsomme data hverken er med i den ene eller den anden afprøvning.

Regler, der kan spille ind

EU’s AI-forordning, forordning (EU) 2024/1689, stiller i artikel 55 krav om blandt andet adversarial test for udbydere af AI-modeller til almen brug med systemisk risiko. Kravet retter sig mod udbyderne af sådanne modeller, ikke mod enhver organisation, der tager en AI-løsning i brug. Hvilke krav der gælder for jeres egen brug, afhænger af rollen og af løsningen, og det bør afklares med de juridiske kompetencer, I har adgang til. Teksten er ikke juridisk rådgivning.

Persondata er et selvstændigt hensyn. Hvis en øvelse af nogen art involverer rigtige samtaler eller kundedata, gælder de samme overvejelser om dataminimering som i andre øvelser. → Persondata i øvelsen

Det skal I lade være med

At bestille på et ord · aftal, om det er modellen eller forsvaret, der skal afprøves.
At regne en AI-afprøvning for dækning af sikkerheden · den siger ikke noget om opdagelse og reaktion.
At glemme AI-løsningen i den klassiske øvelse · hvis den har adgang til vigtige data, kan den høre til scenariet.
At lade leverandørens vilkår være uafklarede · test af en hostet AI-tjeneste kan være reguleret af aftalen.
At sætte samme hold på begge opgaver uden at spørge · kompetencerne overlapper kun delvist. → Valg af leverandør til red teaming
At love compliance ud fra en enkelt øvelse · reglerne om AI er nye og afhænger af rollen.

Hvad kan og ikke kan konkluderes

AI red teaming kan vise, om et AI-system under bestemte forhold kan bringes til at opføre sig skadeligt eller forkert. Det kan ikke vise, om organisationen ville opdage en modstander, der bruger systemet som led i et angreb. En klassisk red team-øvelse kan omvendt sige noget om forsvaret omkring AI-løsningen, men ikke om modellens svar er pålidelige. Ingen af dem dokumenterer i sig selv, at regler om AI er overholdt.

Tjekliste før I siger ja til opgaven

☐ Er det aftalt, om målet er modellens adfærd eller forsvarets reaktion?
☐ Ved I, hvilke data og systemer AI-løsningen har adgang til?
☐ Er udviklere, produktansvarlige og jurister inddraget, hvor det er relevant?
☐ Er leverandørens vilkår for test af tjenesten afklaret?
☐ Er det besluttet, om AI-løsningen skal indgå i et scenarie i den næste øvelse? → Målet for øvelsen
☐ Er det klart, hvem der ejer resultatet og opfølgningen?

Kilder

AI 600-1, Generative Artificial Intelligence Profile: beskrivelsen af AI red teaming som en praksis i udvikling, formålet og betydningen af deltagernes baggrund.
Forordning (EU) 2024/1689 (AI-forordningen): artikel 55 om forpligtelser for udbydere af AI-modeller til almen brug med systemisk risiko, herunder adversarial test.

Senest gennemgået: oktober 2026.