AI red teaming

AI red teaming låner begrebet fra militæret og sikkerhedsverdenen, men dækker et bredere fejlrum end en klassisk penetrationstest. Målene er modellen (skadeligt indhold, jailbreaks, bias, hallucinationer, memoriserede træningsdata, farlige kapabiliteter som hjælp til kemiske, biologiske eller cyberangreb), applikationen omkring den (læk af systemprompten, direkte og indirekte prompt injection, usikker håndtering af modellens output, overdreven handlefrihed i værktøjer og agenter) og infrastrukturen (model-endpoints, retrieval-lagre, forsyningskæde). OWASP GenAI Red Teaming Guide (2025) strukturerer arbejdet efter disse lag, og MITRE ATLAS giver en ATT&CK-lignende matrix over taktikker og teknikker mod maskinlæring, som kan bruges til at afgrænse og rapportere fund.

Et typisk forløb starter med en trusselsmodel og en skadestaksonomi: hvilke aktører, hvilke aktiver og hvilke indholdskategorier og handlinger der er uacceptable for netop denne løsning. Testerne kombinerer derefter manuel afprøvning - rollespil, personaer og hypotetiske rammer, eskalering over flere ture, kodningstricks, sprog med få træningsdata, forgiftede dokumenter placeret, hvor en RAG-pipeline vil hente dem - med automatisk generering og scoring. Open source-værktøjer som Microsoft PyRIT, NVIDIA garak og promptfoo sender store samlinger af angreb, muterer prompts med en angriber-LLM og bedømmer svarene med klassifikatorer eller en LLM-dommer. Fordi output er stokastisk, bør resultater rapporteres som attack success rate over mange kørsler med faste decoding-indstillinger, ikke som enkelte skærmbilleder.

For udbydere i EU af AI-modeller til almen brug med systemisk risiko kræver AI-forordningens art. 55, stk. 1, litra a, modelevaluering, "herunder gennemførelse og dokumentation af adversarial testing", med henblik på at identificere og afbøde systemiske risici, og adfærdskodeksen for AI-modeller til almen brug (juli 2025) beskriver i kapitlet om Safety and Security, hvordan tiltrædende udbydere dokumenterer det. For højrisikosystemer kræver art. 15 modstandsdygtighed over for forsøg på at ændre brug eller ydeevne ved at udnytte sårbarheder, herunder adversarielle eksempler og dataforgiftning, hvilket red teaming er med til at påvise. NIST AI 600-1 nævner red teaming blandt de foreslåede handlinger til at måle risici i generativ AI.

Typiske faldgruber: kun at teste basismodellen og ikke den konfiguration, der faktisk kører med systemprompt, værktøjer og retrieval; at behandle en bestået red team-øvelse som bevis på sikkerhed i stedet for en nedre grænse for, hvad en angriber finder; at køre én enkelt øvelse før lancering, mens modelversioner, prompts og connectors ændres hver uge; og ikke at føre fundene ind i regressionstest og guardrail-regler. Microsofts rapport fra 2025 om red teaming af over 100 generative AI-produkter understreger, at mange reelle fejl skyldes simple teknikker og systemintegration, ikke gradientbaserede angreb. Red teaming supplerer - men erstatter ikke - benchmark-evaluering, en klassisk pentest af den omgivende infrastruktur og overvågning i drift.