Traditioneel red teaming is redelijk overzichtelijk: je huurt een team experts in dat probeert in te breken in je netwerk, en vervolgens vertellen ze je hoe slecht het ervoor staat. AI red teaming is hetzelfde concept, maar dan toegepast op systemen die zelf kunnen nadenken — of in ieder geval doen alsof ze dat kunnen. En dat maakt het een stuk ingewikkelder, want hoe test je iets dat je niet volledig begrijpt?
Waarom gewoon pentesten niet genoeg is
Bij een traditionele pentest zoek je naar bekende kwetsbaarheden: SQL-injectie, misconfiguraties, zwakke wachtwoorden. Het zijn technische problemen met technische oplossingen. AI-systemen hebben al die problemen ook, plus een hele categorie nieuwe problemen die we nog maar net beginnen te begrijpen.
Een AI-model kan technisch perfect beveiligd zijn — versleutelde verbindingen, sterke authenticatie, netjes gepatcht — en tóch gevaarlijke dingen doen. Het kan bevooroordeelde beslissingen nemen, vertrouwelijke trainingsdata lekken, of zich laten manipuleren om instructies te negeren. Dat zijn geen bugs in de traditionele zin. Het zijn emergente eigenschappen van systemen die te complex zijn om volledig te doorgronden.
De aanvalscategorieën
Prompt manipulation
De meest besproken categorie. Je probeert het model dingen te laten doen die het niet zou moeten doen door slim geformuleerde invoer. "Doe alsof je geen beperkingen hebt." "Negeer alle voorgaande instructies." Het is verbazingwekkend hoe vaak dit werkt, en nog verbazingwekkender hoe creatief mensen worden in het bedenken van nieuwe varianten.
Het is een kat-en-muisspel. Ontwikkelaars bouwen guardrails, aanvallers vinden manieren eromheen, ontwikkelaars bouwen betere guardrails, en aanvallers worden creatiever. Het verschil met traditionele beveiliging is dat de "exploit" hier geen code is, maar taal. En taal is oneindig flexibel.
Data poisoning en extraction
Twee kanten van dezelfde medaille. Bij data poisoning probeer je de trainingsdata te beïnvloeden zodat het model zich anders gedraagt. Bij data extraction probeer je het model te verleiden tot het onthullen van data waarop het getraind is — inclusief potentieel gevoelige informatie.
Stel je voor dat een chatbot die getraind is op klantgesprekken per ongeluk creditcardnummers begint op te lepelen. Dat is geen hypothetisch scenario — het is daadwerkelijk gebeurd.
Bias en fairness
Een AI-systeem dat consequent bepaalde groepen benadeelt is niet "gehackt" in de traditionele zin, maar het effect kan net zo schadelijk zijn. Een red team test of het model systematisch discrimineert op basis van geslacht, etniciteit, leeftijd of andere beschermde kenmerken. Dit is bijzonder lastig te testen omdat bias subtiel kan zijn en pas opvalt in statistische analyses over grote aantallen interacties.
Hoe doe je het in de praktijk?
Een AI red team exercise volgt grofweg deze stappen:
- Dreigingsmodellering — wat kan er mis gaan? Wie zou dit systeem willen misbruiken, en waarom? Dit is het moment waarop je je voorstellingsvermogen moet loslaten op alle manieren waarop je creatie kan worden misbruikt.
- Scenario-ontwikkeling — concrete aanvalsscenario's bedenken. Niet alleen de voor de hand liggende, maar ook de creatieve. Wat als iemand het model gebruikt om overtuigende desinformatie te genereren? Wat als iemand het als onderdeel van een grotere aanval inzet?
- Uitvoering — het daadwerkelijke testen. Handmatig en geautomatiseerd. Met domeinexperts en met mensen die geen idee hebben van AI maar wel creatief zijn in het breken van dingen.
- Rapportage en remediatie — bevindingen documenteren, risico's inschatten, en maatregelen implementeren. En dan opnieuw testen.
Wie zou dit moeten doen?
Het korte antwoord: iedereen die een AI-systeem in productie heeft dat impact heeft op mensen. Het lange antwoord: het hangt af van de risico's. Een interne chatbot voor het opzoeken van het kantine-menu heeft een ander risicoprofiel dan een AI-systeem dat beslissingen neemt over hypotheekaanvragen.
De grotere AI-bedrijven — OpenAI, Anthropic, Google — hebben interne red teams, maar dat ontslaat jou niet van de verantwoordelijkheid als je hun modellen integreert in je eigen applicaties. Het basismodel mag dan getest zijn, maar jouw implementatie, jouw data, en jouw gebruikscontext zijn uniek. En dus moet je die ook uniek testen.
Het is als het kopen van een auto die door de fabrikant is gecrashtested. Dat betekent niet dat jij geen gordel meer om hoeft te doen.