AI leverancier bewijs: vraag het, geen beloftes

Je besteedt je IT uit. Een van de tools die je leverancier inzet, is aangestuurd door kunstmatige intelligentie (AI). Dat klinkt modern en nuttig. Maar weet je of die AI getest werd op zwaktes voor ze in gebruik ging?

MIT Technology Review meldt dat OpenAI ‘GPT-Red’ ontwikkelde, een AI die automatisch probeert andere AI-systemen te hacken, zodat kwetsbaarheden gevonden en gedicht worden voor uitrol. De boodschap voor jou als zaakvoerder is eenvoudig: leveranciers die AI inzetten, moeten aantonen dat ze dit soort tests doen. Doen ze dat niet, dan draag jij stilletjes het risico.

Wat is geautomatiseerde red-teaming?

Red-teaming is een techniek waarbij een onafhankelijke partij, of een gespecialiseerd systeem, probeert een AI-toepassing te misleiden, te omzeilen of misbruik te maken van zwaktes. Denk aan iemand die bewust verkeerde of schadelijke vragen stelt om te zien of de AI foute antwoorden geeft, gevoelige data lekt of instructies negeert.

Tradiitioneel deden mensen dat handmatig: veiligheidsexperts die urenlang scenario’s uittesten. Geautomatiseerde red-teaming vervangt of ondersteunt dat met software, in dit geval een grote taalmodel (LLM), een AI die zelf vragen stelt en zwaktes opspoort op grote schaal en sneller dan een menselijk team.

GPT-Red is een voorbeeld van zo’n geautomatiseerd systeem. Het idee is dat je hiermee meer kwetsbaarheden vindt voor een AI-product de markt opgaat.

Belangrijk om te begrijpen: geautomatiseerde red-teaming is een nuttig hulpmiddel, maar geen volledig veiligheidsbewijs. Het vervangt geen onafhankelijke audit. Een leverancier die enkel zegt ‘wij doen red-teaming’ zonder documentatie of externe validatie, geeft je weinig houvast. Dat onderscheid is precies wat jij als afnemer moet kunnen maken.

Waarom dit jouw leverancierskeuze raakt

Dit is geen theoretisch verhaal. De EU AI Act, de Europese wet op artificiële intelligentie, verplicht leveranciers van zogenaamde high-risk AI en algemene AI-modellen om gedocumenteerde, herhaalbare veiligheidstests uit te voeren, inclusief adversarial testing, wat vergelijkbaar is met red-teaming. De volledige handhavingsdeadline valt op 2 augustus 2026.

Als je IT-leverancier AI-toepassingen aanbiedt die onder die categorie vallen, en ze kunnen geen bewijs leveren van degelijke tests, dan is dat een contractueel en juridisch risico voor jou.

Drie concrete vragen om te stellen bij je volgende leveranciersgesprek:

  1. Voeren jullie geautomatiseerde of onafhankelijke veiligheidstests uit op jullie AI-toepassingen?
  2. Kunnen jullie documentatie of een testrapport van een externe partij voorleggen?
  3. Wat is de procedure bij een incident of ontdekte kwetsbaarheid?

Als het antwoord vaag blijft of de leverancier verwijst naar interne evaluaties zonder externe validatie, is dat een signaal om verder door te vragen. Bij Clear IT bekijken we dit soort vragen soms samen met klanten wanneer zij een nieuwe AI-dienst overwegen.

Waarom dit jouw leverancierskeuze raakt

Welke bewijzen je wél moet vragen

Niet elk document dat een leverancier aanreikt, zegt even veel. Een intern testrapport dat volledig door henzelf is opgesteld, is moeilijk te controleren. Een onafhankelijke derde-partij audit of een SOC2-rapport, waarbij een erkende externe accountant of auditkantoor het systeem doorlichtte, geeft meer zekerheid.

Hier is een overzicht van de meest voorkomende bewijsstukken:

Type bewijsControleerbaarheid voor kmoBruikbaar als SLA-bewijs?
Intern red-team rapportLaagNee, te weinig onafhankelijkheid
Geautomatiseerde red-teamingMiddelAanvullend, niet op zichzelf
Onafhankelijke derde-partij auditHoogJa, vereist bij high-risk AI
SOC2-rapportHoogJa, breed erkend
Penetratietest door externe partijMiddel-HoogGedeeltelijk, als aanvulling

Vraag je leverancier ook naar incidentrapportage. Hoe snel verwittigen ze jou als er een probleem vastgesteld wordt? Staat dat ergens op papier? Dat hoort thuis in de serviceovereenkomst (Service Level Agreement, afgekort SLA). Zet het erin. Een leverancier die AI gebruikt zonder die waarborgen gedocumenteerd te hebben, vraagt je vertrouwen op basis van niets.

AI-veiligheid hoort in je contract, niet in een folder

Geautomatiseerde red-teaming is een positieve ontwikkeling in de AI-wereld. Maar voor jou als zaakvoerder telt vooral wat je zwart op wit kunt terugvinden. Vraag concrete documentatie. Zet testverplichtingen en incidentprocedures in je contract. Geef de voorkeur aan leveranciers die externe audits kunnen aantonen. Een leverancier die AI gebruikt zonder die transparantie biedt geen zekerheid, ongeacht hoe indrukwekkend de technologie klinkt.

Veelgestelde vragen

Moet mijn leverancier verplicht red-teaming uitvoeren?

Voor leveranciers van zogeheten high-risk AI en grote algemene AI-modellen verplicht de EU AI Act wel degelijk gedocumenteerde veiligheidstests, inclusief vormen van adversarial testing zoals red-teaming. De volledige handhaving geldt vanaf augustus 2026. Voor kleinere, lagere-risico-toepassingen gelden minder strikte vereisten, maar transparantie over tests blijft een goede inkoopregel.

Wat is het verschil tussen red-teaming en een gewone penetratietest?

Een penetratietest richt zich op technische kwetsbaarheden in een systeem, zoals softwarefouten of zwakke wachtwoorden. Red-teaming gaat verder en simuleert realistische aanvalsscenario’s, inclusief pogingen om een AI te misleiden of verkeerd gedrag uit te lokken. Voor AI-systemen is red-teaming dus specifieker en aanvullend op een gewone penetratietest.

Hoe zet ik AI-veiligheidsvereisten in een contract?

Vraag dat de SLA minimaal vermeldt welke type tests uitgevoerd worden, door wie, hoe vaak en wat er gebeurt bij een incident. Voeg toe dat de leverancier verplicht is externe auditresultaten of samenvattingen te delen op jouw verzoek. Een IT-partner met ervaring in leveranciersbeheer kan helpen om die clausules concreet te formuleren.

Wat als een leverancier zegt dat ze intern red-teaming doen, maar geen extern rapport hebben?

Interne tests zijn een begin, maar bieden je als klant weinig verificatiemogelijkheid. Voor AI-toepassingen die jouw bedrijfsdata of klantdata verwerken, is externe validatie een minimale drempel. Als de leverancier dat niet kan bieden, weeg dan zorgvuldig af of het risico aanvaardbaar is voor jouw situatie.