LLM red teaming: testworkflow en scoringsgids

U moet red teaming als herhaalde, gedocumenteerde controle uitvoeren, niet als eenmalige scorekaart. Elke bevinding wordt een regressietest en een systeemwijziging, zodat het werk later kan worden beoordeeld en verdedigd.

De aanleiding is een analyse van 12 november 2026 van gestructureerde LLM-red-teaming-workflows, die betoogt dat een verdedigbaar programma red teaming behandelt als gestructureerd bewijs van professionele betrouwbaarheid in plaats van een enkel kerncijfer. De analyse gebruikt een juridische intake-assistent als casus: een direct verzoek om verboden advies kan worden geweigerd, terwijl dezelfde assistent met een opgehaald bestand toch een stuk opstelt dat de advocaat niet heeft geautoriseerd. In onze beoordeling betekent dit dat u niet kunt vertrouwen op modelscores zonder inzicht in hoe het systeem zich gedraagt in de werkelijke werkstroom, met echte documenten, tools en gebruikersvragen.

Hoe begint u met scope in plaats van met prompts?

Een LLM-red-team begint met de use case, de sector, de gebruikers, de beoogde uitkomsten en de onaanvaardbare gevolgen. De eigenaar benoemt wie het systeem gaat gebruiken, hoe een correct resultaat eruitziet, en welke schade in die context onaanvaardbaar is. Testers krijgen vervolgens scenario-instructies die de schadelijke informatie benoemen die zij moeten proberen te ontlokken. Die instructies worden schadecategorieën met expliciete slaag- of faalcriteria, zodat een latere lezer kan zien wat is getest en wat als een fout gold.

Schrijf voor de eerste run een scope-register dat de eigenaar van elk beoordelingsgebied, de talen binnen de scope en de betrokken gebruikersgroepen benoemt. Beperk de eerste cyclus tot één use case en één vastgezet model. Een klantinstantie, account of document valt alleen binnen de testscope wanneer de tester er eigenaar van is of er expliciete schriftelijke toestemming voor heeft om het te testen.

Welke fouttypen moet u apart meten?

• Directe prompt-injectie — een poging van een gebruiker om instructies rechtstreeks te overschrijven.
• Indirecte prompt-injectie — instructies verborgen in een document, webpagina, e-mail of toolresultaat die het model ontvangt.
• Verzonnen onderbouwing — juridische, medische of feitelijke beweringen die goed geschreven zijn maar onwaar.
• Selectief citeren en weglating — relevante contra-indicaties of beperkingen die uit een antwoord worden gelaten.
• Laat-in-sessie-injectie — aanvallen die pas opduiken na meerdere beurten, niet in de eerste vraag.
• Zwak taalbegrip verward met veiligheid — een weigering die eigenlijk betekent dat het model de vraag niet heeft begrepen.

Rapporteer begrip, weigering, toxiciteit en behulpzaamheid afzonderlijk. De praktische vraag is niet alleen of het model een schadelijke prompt weigert. Het is of het model schade, dubbelzinnigheid, context van beschermde groepen en cultuurspecifiek risico herkent.

Waarom is een Engelse benchmark niet genoeg?

Do-Not-Answer, HarmBench, AdvBench en RedBench zijn alleen Engelstalig. Ze doorstaan betekent niet dat vergelijkbare veiligheid in andere talen of culturele contexten is vastgesteld. Onderzoek naar Yoruba en Nigeriaans Pidgin rapporteert dat meertalige training op zichzelf geen veilig gedrag oplevert. Sommige meertalige modellen produceren meer toxische uitvoer in talen met weinig bronnen, en veiligheidsnormen kunnen overwegend westerse aannames coderen.

Voor een wereldwijd professioneel systeem betekent dat taalspecifieke beoordelaars en een schadetaxonomie geworteld in de gemeenschappen die worden bediend. Workflows in de juridische sector, de gezondheidszorg, de journalistiek en de publieke sector zijn waar een Engelse pass het meest misleidend kan zijn. Een model kan er veilig uitzien in de benchmarktaal en toch onveilige of misleidende uitvoer produceren in een taal die wordt gebruikt door de getroffen mensen.

Welke controles moet u kunnen aantonen?

1. Vastleggen van de scope — documenteer welke use case, welke talen, welke gebruikersgroepen en welke schadecategorieën in deze cyclus worden getest.
2. Holdout-tests na elke wijziging — draai dezelfde vastgepinde configuratie opnieuw nadat u een fout hebt hersteld, zodat u kunt bewijzen dat de correctie dezelfde route niet opnieuw heeft geopend.
3. Koppeling van bevindingen aan aanvalstechnieken — verbind elke bevestigde fout aan MITRE ATLAS, zodat de eigenaar de aanvalstechniek ziet, niet alleen de prompt die faalde.
4. Gescheiden beoordelaars per stap — laat generatie, feitelijke audit, adversariële uitdaging en bronverificatie uitvoeren door onafhankelijke modellen of mensen, zodat geen enkel systeem het laatste woord heeft.
5. Drie beslissingen met benoemde onzekerheid — goedkeuren, goedkeuren met benoemde voorwaarden, of aanhouden, en noteer welke talen niet zijn getest, welke categorieën openstaan, en wie het restrisico schriftelijk accepteert.

Hoe draagt u het bewijs naar een goedkeuringsvergadering?

Breng drie cijfers mee: de severity-weighted rate voor de categorie met de hoogste schade, refusal quality, en de categorieën zonder tests. Laat zien welke configuratie faalde, welke wijziging werd doorgevoerd, en of de holdout nog steeds faalt. Een bevinding die wordt vastgelegd en niet opnieuw getest, is geen controle.

Vraag wie het restrisico schriftelijk accepteert. Die persoon zou de ongeteste talen en de openstaande fouten moeten kunnen zien, niet alleen de categorieën die zijn geslaagd. Klanten moeten uitvoer beoordelen voordat ze erop vertrouwen, ernaar handelen, deze archiveren of naar een derde partij sturen, zodat menselijke beoordeling onderdeel blijft van de goedkeuringsvoorwaarden.

Tooling kan u helpen bij het vastleggen van testresultaten, het bijhouden van regressies en het scheiden van beoordelaars. Het kan u niet helpen bij de beslissing wie het risico accepteert, welke schade in uw context onaanvaardbaar is, of of een goed geschreven antwoord waar is. Die oordelen blijven uw eigen professionele verantwoordelijkheid.