Kies open-weight versus gesloten AI-modellen op aantoonbare controle, niet op het label

Kies niet op het label open of gesloten, maar op de vraag welke controle u zelf kunt bewijzen. Het Australian Cyber Security Centre waarschuwt dat open-weight modellen lokale controle geven, maar provenance, safeguards, monitoring en incidentrespons bij uw organisatie leggen; gesloten modellen centraliseren die controles bij de leverancier, ten koste van onafhankelijke inspectie.

Op 5 november 2026 publiceerde het Australian Cyber Security Centre de guidance Open-weight AI models: Opportunities and cyber security risks. De kern van de vergelijking tussen open-weight versus gesloten: wie een open-weight model zelf host, krijgt zeggenschap over versiebeheer, hostinglocatie en inspectie, maar neemt daarmee ook de verantwoordelijkheid over voor herkomst, supply-chainbeveiliging, beschermende maatregelen, monitoring, onderhoud en incidentrespons. Bij een gesloten model blijven die controles bij de leverancier, wat het beheer vereenvoudigt maar onafhankelijke verificatie beperkt.

Voor bestuurders, juristen en CISO's die met vertrouwelijke informatie werken, verschuift daarmee de kernvraag. Niet: welk model scoort het hoogst? Maar: voor welke architectuur kan ik de volledige vertrouwelijkheids-, beveiligings- en auditketen aantoonbaar beheersen? Naar onze analyse kunnen toepasselijke verplichtingen onder de EU AI Act een aanvullende reden zijn om verantwoordelijkheden, controles en bewijs per inzet vast te leggen; de precieze verplichtingen hangen af van de rol, het systeem en de risicocategorie. Naar onze inschatting is aantoonbare controle het bruikbaarste selectiecriterium dat uit deze publicaties volgt.

Wat is het verschil tussen gesloten, open-weight en echt open-source modellen?

Het Australian Cyber Security Centre maakt expliciet onderscheid tussen drie vormen. Bij gesloten modellen blijven gewichten en centrale safeguards bij de leverancier. Bij open-weight modellen zijn de modelgewichten beschikbaar om zelf te hosten en te inspecteren. Echt open-source betekent dat ook trainingsdata, code en documentatie beschikbaar zijn. De guidance benadrukt dat publicatie van gewichten níét betekent dat trainingsdata, recepten of volledige auditinformatie beschikbaar zijn.

• Gesloten: leverancier beheert gewichten en safeguards; u leunt op zijn verklaringen.
• Open-weight: u kunt gewichten hosten en inspecteren, maar documentatie en herkomst zijn vaak onvolledig.
• Open-source: gewichten plus data, code en documentatie, wat de hoogste reproduceerbaarheid mogelijk maakt.

Dit onderscheid is geen semantiek. Een open-weight model geeft u inzicht in gedrag en configuratie, maar laat de herkomstvraag open. Onze lezing: de term "open" verleidt tot de aanname dat alles controleerbaar is, terwijl de controleerbaarheid per laag sterk verschilt.

Welke controle verschuift naar mijn organisatie bij een open-weight model?

Zelf hosten verplaatst beveiliging, privacy, safeguards, monitoring en onderhoud naar uw organisatie. NVIDIA Research beschrijft in Evaluating Risk in Open-Weight Models dat een deployment als volledig systeem beoordeeld moet worden: model, harness, retrieval, tools, sandboxing en runtime-handhaving. Een benchmarkresultaat zegt alleen iets over de geteste omstandigheden.

Concreet moet u bij een zelf gehost open-weight model zelf vastleggen en bewaken:

• modelidentiteit, versie en hashes van de modelbestanden;
• fine-tuning, configuratie en de servingversie die productie draait;
• prompts, datasets en de gebruikte evaluatiemethode;
• supply-chaincontrole op herkomst en modelartefacten;
• bescherming tegen promptinjectie en datalekken;
• logs, updates en een incidentresponsproces.

Onze analyse van het gevolg dat de bronnen niet benoemen: wie open-weight overweegt, moet interne capaciteit opbouwen voor versiebeheer, monitoring en auditketens, omdat die taken niet langer bij een leverancier liggen. Dat waarom lokaal draaien geen vrijbrief is, lichtten wij eerder toe in onze analyse over waarom lokaal draaien gevoelige prompts niet vanzelf beschermt. Ontbreekt die capaciteit, dan ruilt u leveranciersafhankelijkheid in voor een onbeheerde keten.

Waarom zegt één prestatie- of veiligheidsscore te weinig over de modelkeuze?

Omdat capability, cyberrisico, robuustheid en vertrouwelijkheid losse beoordelingsdimensies zijn. Het National Institute of Standards and Technology rapporteerde in zijn CAISI-assessment van GLM-5.3 dat dit op het moment van beoordeling het meest cybercapabele publiek vrijgegeven open-weight model was, maar dat het onder actuele Amerikaanse frontiermodellen presteerde op vier cyberbenchmarks. Die test meet cybercapaciteit, niet algemene veiligheid of vertrouwelijkheid.

Een peer-reviewed benchmark van open-source en commerciële modellen in financiële scenario's, uitgevoerd door Marko Pribisalić en Sanda Martinčić-Ipšić, versterkt dit beeld. Geen enkel model domineerde op alle dimensies, en de gemeten financiële capability hing in de steekproef niet betrouwbaar samen met security-robuustheid (Spearman rho 0,095; p=0,823). De auteurs benadrukken dat de resultaten afhangen van deployment en benchmark en geen volledige productiesecurity meten.

Ons verband: een hogere inspecteerbaarheid kan samengaan met relevante dual-use-capaciteit. Open beschikbaarheid is dus geen synoniem voor veilig. Beoordeel een model altijd gescheiden op taakprestatie, security en vertrouwelijkheid, zoals wij ook bepleiten bij het vergelijken van welke subverwerkers en modelroutes uw AI-systeem feitelijk gebruikt.

Wat betekent deze afweging voor bestuurders, juristen en CISO's?

Onze analyse: omdat open-weight modellen provenance, safeguards en incidentrespons bij uw organisatie leggen, krijgen CISO's er een permanente beheertaak bij; daarom bepaalt u vóór selectie of u versiebeheer, monitoring en een auditketen voor modelbestanden daadwerkelijk kunt bemensen, en legt u vast wanneer een model niet wordt toegelaten omdat dat bewijs ontbreekt. Omdat gesloten modellen onafhankelijke inspectie beperken en afhankelijkheid van leveranciersclaims vergroten, moet de jurist in het contract concreet inspectiebewijs afdwingen; daarom neemt u clausules op over retentie, trainingsgebruik, subverwerkers, modelversies, regio en incidentmelding, zoals wij uitwerkten over een afdwingbaar auditrecht met concreet inspectiebewijs vastleggen. Omdat de NIST- en financiële benchmarks laten zien dat capability en security niet samenvallen, mag de bestuurder geen besluit baseren op één ranglijst; daarom eist u per voorgenomen inzet een aparte taak-, security- en privacytoets voordat u akkoord geeft. En omdat de Australische guidance de hele keten als systeem beschouwt, beoordeelt u bij self-hosting of lokale uitvoering werkelijk alle runtime-, opslag-, beheer- en telemetriecomponenten binnen uw grens houdt; daarom legt u externe autorisatie en filtering voor toolgebruik vast voordat het model in productie gaat.

Samengevat volgt hieruit een eenvoudige selectieprocedure:

1. Classificeer de data en bepaal de vereiste vertrouwelijkheidsgrens.
2. Bepaal voor open-weight of u de volledige beheer- en auditketen kunt bemensen.
3. Controleer bij gesloten diensten retentie, training, subverwerkers, versie, regio en auditmogelijkheden.
4. Toets modellen apart op taakprestatie, security en privacy.
5. Leg vast wanneer een model wordt afgewezen omdat bewijs ontbreekt.

Meer verdieping over modelbeheersing en de hele keten vindt u in onze themahub over AI-security en modelbeheersing. De guidance van het Australian Cyber Security Centre is officieel maar niet universeel bindend; het NVIDIA-stuk is primaire leveranciersresearch, en de financiële benchmark onderzocht specifieke modellen, datasets en configuraties.

Bronnen: Het artikel steunt op guidance van het Australian Cyber Security Centre, een CAISI-assessment van NIST, onderzoek van NVIDIA Research en een peer-reviewed financiële benchmark in FinTech (MDPI).