Open-source lab test de veiligheid van 60+ AI-modellen

Open-source lab test de veiligheid van 60+ AI-modellen

TL;DR

  • Wat: G0DM0D3 is een open-source tool waarmee onderzoekers en bedrijven 60+ AI-modellen kunnen stresstesten op kwetsbaarheden en jailbreaks.
  • Waarom relevant: Als je AI inzet in je bedrijf, wil je weten hoe robuust die modellen zijn — en de EU AI Act vraagt daar straks ook om.
  • Wat je ermee kunt: Laat je AI-leverancier uitleggen welke veiligheidstests zij uitvoeren, en vergelijk dat met wat tools als G0DM0D3 blootleggen.

Ik kwam via een tweet van @RoundtableSpace een project tegen dat me direct nieuwsgierig maakte: G0DM0D3, een volledig open-source "red-teaming lab" waarmee je tientallen AI-modellen tegelijk kunt aanvallen om te kijken waar ze breken. Dat klinkt misschien als iets voor hackers, maar ik denk dat het juist voor ondernemers relevant is.

Wat is G0DM0D3 precies?

G0DM0D3 — de naam is een gestileerde schrijfwijze van "God Mode" — is een browsergebaseerde tool gemaakt door een onderzoeker die online bekendstaat als "Pliny the Prompter" (op GitHub: elder-plinius). Het project draait om één centrale vraag: hoe veilig zijn de AI-modellen die we dagelijks gebruiken?

De tool verbindt met meer dan 60 modellen via OpenRouter, tot 44 modellen via Venice, en je kunt er ook lokale modellen aan koppelen via tools als Ollama of LM Studio. Wat mij opvalt: het hele ding is gebouwd als één enkel HTML-bestand. Geen ingewikkelde installatie, geen frameworks — gewoon openen in je browser en je kunt beginnen.

Technisch gezien doet G0DM0D3 drie dingen:

  • GODMODE CLASSIC: Vijf verschillende prompt-model-combinaties worden tegelijk losgelaten op een opdracht, als een soort wedstrijd. Welk model geeft het meest bruikbare (of meest kwetsbare) antwoord?
  • ULTRAPLILIAN: Een evaluatie-engine die 12 tot 60 modellen door meerdere beoordelingslagen haalt en een samengestelde score geeft.
  • Parseltongue: Een module met 33 red-teaming-technieken op drie intensiteitsniveaus. Denk aan het herformuleren van prompts zodat ze beveiligingen omzeilen.

Het project staat op GitHub, heeft ruim 11.500 sterren en 2.700 forks, en valt onder de AGPL-3.0-licentie. Dat betekent: vrij te gebruiken, ook commercieel, maar als je het aanpast en online aanbiedt, moet je je broncode delen.

Waarom "red teaming" ertoe doet

Red teaming is een term uit de beveiligingswereld. Het idee: je huurt iemand in om je eigen systeem aan te vallen, zodat je de zwakke plekken vindt vóórdat een kwaadwillende dat doet. Bij AI-modellen betekent dat: proberen om het model dingen te laten zeggen of doen die het niet zou moeten doen. Jailbreaking, noemen ze dat.

Ik vind het eerlijk gezegd veelzeggend dat bij een recente NIST-competitie in maart 2026 meer dan 400 deelnemers ruim 250.000 aanvalspogingen deden op 13 vooraanstaande AI-modellen — en dat bij élk model minstens één aanval slaagde. Geen enkel model was waterdicht.

Dat is geen reden voor paniek, maar het is wel een feit dat je als ondernemer in je achterhoofd moet houden. Als je AI inzet voor klantenservice, voor het verwerken van documenten, of voor het genereren van content, dan is de vraag "hoe bestand is dit model tegen misbruik?" niet alleen theoretisch.

Wat betekent dit voor Nederlandse ondernemers?

Hier wordt het voor mij pas echt interessant. Uit recent onderzoek van ABN AMRO en MWM2 onder 777 Nederlandse organisaties blijkt dat 78 procent van het MKB AI in enige mate inzet op de werkvloer. Maar slechts 9 procent heeft formeel beleid voor het gebruik van externe AI-oplossingen.

Laat dat even inzinken. Bijna acht op de tien bedrijven gebruiken AI, maar minder dan één op de tien heeft opgeschreven hoe dat veilig en verantwoord moet.

Ik denk dat tools als G0DM0D3 daar indirect bij kunnen helpen — niet doordat elke ondernemer zelf gaat red-teamen, maar doordat dit soort projecten zichtbaar maakt hoe kwetsbaar AI-modellen kunnen zijn. Dat geeft je als ondernemer betere vragen om te stellen aan je leverancier.

Stel dat je als ondernemer een AI-chatbot laat bouwen voor je webshop. Kun je je voorstellen dat iemand via een slim geformuleerde vraag die chatbot dingen laat beloven die je bedrijf niet kan waarmaken? Of dat gevoelige klantinformatie via een jailbreak-techniek uit het model wordt gehaald? Dat zijn geen hypothetische risico's — het zijn precies de scenario's die G0DM0D3 test.

De EU AI Act als extra motivatie

Daar komt bij: de EU AI Act, die gefaseerd van kracht wordt, stelt in Artikel 15 dat aanbieders van hoogrisico-AI-systemen hun "adversarial robustness" moeten documenteren. Vrij vertaald: je moet kunnen aantonen dat je hebt getest hoe je AI-systeem reageert op kwaadwillige input. Voor veel MKB-bedrijven zal dat indirect gelden — via de leveranciers en platforms die zij gebruiken — maar het is goed om te weten dat dit eraan komt.

Kanttekeningen bij het project

Ik wil ook eerlijk zijn over de andere kant. Een tool die het makkelijker maakt om AI-modellen te jailbreaken, is per definitie een tweesnijdend zwaard. Onderzoekers gebruiken het om kwetsbaarheden te vinden en te melden. Maar dezelfde technieken kunnen ook worden ingezet door mensen met minder goede bedoelingen.

De maker positioneert G0DM0D3 als een onderzoekstool, en de open-source-licentie past bij die filosofie van transparantie. Maar het blijft een afweging die in de AI-veiligheidsgemeenschap continu wordt gevoerd: publiceer je aanvalstechnieken open, zodat verdedigers zich kunnen wapenen? Of hou je ze binnenskamers, zodat aanvallers er niet mee aan de haal gaan?

Ik heb daar zelf geen definitief antwoord op, maar ik merk wel dat de trend in de richting gaat van openheid. Het idee daarachter: security through obscurity — veiligheid door geheimhouding — werkt op de lange termijn zelden.

Wat neem ik hieruit mee?

Wat mij het meest bijblijft, is dat getal van 9 procent. Bijna iedereen in het MKB experimenteert met AI, maar bijna niemand heeft beleid. Tools als G0DM0D3 maken zichtbaar waarom dat beleid nodig is: niet omdat AI gevaarlijk is, maar omdat je wilt weten wat je inzet, hoe het zich gedraagt onder druk, en waar de grenzen liggen.

Voor mij is dit vooral een signaal dat AI-veiligheid niet iets is wat je aan de techneuten kunt overlaten. Het is een ondernemersvraag: welk risico accepteer je, en hoe controleer je dat?

80% van de AI-projecten haalt productie nooit.

Ik bouw de 20% — van prototype naar draaiend systeem, binnen weken.