SecurityTechInsider AI-veiligheid & governance
EN/ NL
Governance

Open-weight AI-modellen kwetsbaar voor jailbreaks: waarom de keuze open of gesloten een governancevraag is

Een studie van University of Waterloo en FAR.AI vond ernstige jailbreak-zwaktes in open-weight LLMs. Wat dit betekent voor de keuze tussen open en gesloten AI.

2 september 2026 3 min
Illustratie bij dit artikel: Open-weight AI-modellen kwetsbaar voor jailbreaks.
Organisaties moeten per workflow aantonen welk model zij gebruiken en welke beveiligingslagen eromheen staan. Beeld: SecurityTechInsider — originele redactionele illustratie

U moet per workflow kunnen aantonen welk model u gebruikt, welke data daarheen gaat, en welke verificatielagen eromheen staan. De keuze tussen open en gesloten AI is geen veiligheidsvraag meer, maar een governancevraag.

Een analyse van 4 september 2026 van jailbreak-kwetsbaarheden in open-weight taalmodellen stelt dat ingebouwde veiligheidsmechanismen in populaire open-weight LLMs relatief eenvoudig uit te schakelen zijn, waardoor het aanvalsoppervlak groter wordt zonder aanvullende runtime-controles. De studie testte 21 open-weight modellen en vond ernstige jailbreak-zwaktes. In onze beoordeling betekent dit niet dat open modellen ongeschikt zijn, maar dat de verantwoordelijkheid voor extra beveiligingslagen volledig bij uw organisatie ligt — wat het een governancevraag maakt in plaats van een merkkeuze.

Waarom openheid niet automatisch veiliger is

Bij open-weight modellen kan iedereen de gewichten downloaden, aanpassen en zonder centrale controles opnieuw inzetten. Een aanbieder van een gesloten model kan veiligheidsmechanismen centraal bijstellen; zodra gewichten publiek zijn, verdwijnt die controlelaag. Dat betekent dat het risico niet in het model zelf ligt, maar in wat u eraan toevoegt of niet toevoegt.

Echter: een benchmark van TELUS Digital toont aan dat het open-source model GLM 4.7 in een grote securitytest beter presteerde dan meerdere gesloten modellen. De gemeten kwetsbaarheidsrange liep uiteen van 1,3 tot 93 procent, vooral afhankelijk van modelontwerp, grootte en reasoning-capaciteiten — niet van het open- of gesloten-label.

Welke risico's moet u per workflow beheersen?

  • Jailbreak-kwetsbaarheid — veiligheidsmechanismen kunnen worden omzeild zonder aanvullende runtime-controles.
  • Datalekkage via gewichten — open modellen kunnen gevoelige trainingsdata reproduceren of afleiden.
  • Ongecontroleerde fine-tuning — derden kunnen modellen aanpassen en opnieuw uitrollen zonder uw toestemming.
  • Gebrek aan centrale mitigatie — u kunt niet centraal bijsturen zoals bij gesloten modellen.
  • Audittrail-blindheid — zonder eigen logging ziet u niet welke data waar doorheen gaat.

Hoe kiest u per workflow: open, gesloten of hybride?

Praktijkonderzoek van meer dan tweehonderd enterprise-casestudy's laat zien dat het combineren van gevoelige interne data met open-source modellen op eigen infrastructuur vaak veiliger kan zijn dan generieke SaaS-oplossingen. De reden: datapaden, logs en retentie blijven intern controleerbaar. Een academische vergelijking van on-premise open-source modellen met commerciële LLMs in security-context vond dat gesloten modellen hogere nauwkeurigheid haalden voor incidentclassificatie, terwijl lokaal gedeployde open-source modellen voordelen boden in privacy, kosten en datasoevereiniteit — omdat incidentdata uw infrastructuur niet verlaat.

De afweging per workflow ziet er als volgt uit:

  1. Documenteer welk model welke taak uitvoert — leg vast welk modeltype (open, gesloten, hybride) voor welke workflow actief is en wat de lawful basis is voor de data die het aanraakt.
  2. Maak het datapad zichtbaar — zorg dat u kunt aantonen waar gevoelige data heen gaat, of het uw infrastructuur verlaat, en hoe lang het wordt bewaard.
  3. Voeg verificatielagen toe waar nodig — routeer kritieke taken door meerdere onafhankelijke modellen zodat u onenigheid en correcties kunt inspecteren.
  4. Implementeer fail-closed controles — zorg dat gevoelige data alleen wordt verwerkt als privacy- of securitychecks slagen; bij mislukking gaat niets door.
  5. Onderhoud audit-logs per workflow — registreer welke model welke input kreeg, welke output gaf, en wie dat heeft goedgekeurd.
  6. Toets regelmatig op jailbreaks — test open-weight modellen die u zelf host op bekende aanvalsvectoren, vooral als u ze fine-tuned hebt.

Wat zegt de EU AI Act hierover?

De EU AI Act artikel 53 bevat een carve-out voor open-source modellen, maar dat betekent niet dat modelopenheid u vrijstelt van governanceplichten. Compliance is geen eigenschap van gewichten, maar van de combinatie van model, hosting, contracten en controlelaag. U bent verantwoordelijk voor wat u ermee doet, niet voor wat anderen ermee kunnen doen.

Wat kunnen tools doen, wat niet?

Verificatielagen kunnen helpen om zichtbaar te maken welke keuze in welke workflow actief is. Ze kunnen onenigheid tussen modellen blootleggen, bronnen traceerbaar maken en gevoelige data vervangen door synthetische equivalenten voordat verwerking plaatsvindt. Maar geen tool garandeert juistheid, elimineert hallucinaties of neemt uw eindoordeel over. Voor professionals in recht, zorg, finance en overheid geldt: de verificatielaag ondersteunt controle, maar het professionele oordeel blijft altijd bij u.

Bronnen: Dit artikel is gebaseerd op berichtgeving en richtlijnen van TechXplore (University of Waterloo & FAR.AI security study), Open Source For You (TELUS Digital GenAI Safety Model Benchmark), Areebi, MarketScale (Futuriom enterprise case study summary) en arXiv.

Marit Halversen

Geschreven door

Marit Halversen

Schrijft over AI-governance en regelgeving, met de nadruk op hoe verplichtingen neerslaan in architectuur in plaats van in papierwerk.