Open-weight versus gesloten AI-modellen

U moet aantoonbare controle over de volledige vertrouwelijkheids-, beveiligings- en auditketen kunnen bewijzen voordat u een model selecteert — ongeacht of het open-weight of gesloten is. Dit bepaalt uw architectuur, niet het label.

Een analyse van 10 november 2026 van de afweging tussen open-weight en gesloten AI-modellen op basis van controleerbaarheid stelt dat de keuze niet op modeltype berust, maar op welke controles u zelf kunt bewijzen. Het Australian Cyber Security Centre onderscheidt drie vormen: gesloten modellen met gewichten en safeguards bij de leverancier; open-weight modellen met beschikbare gewichten voor zelf hosten; en volledig open-source met trainingsdata en code. In onze inschatting is aantoonbare controle het bruikbaarste selectiecriterium. Wie open-weight zelf host, krijgt inzicht in gedrag en configuratie, maar neemt ook de volledige verantwoordelijkheid voor herkomst, supply-chainbeveiliging, beschermende maatregelen, monitoring, onderhoud en incidentrespons. Wie gesloten modellen gebruikt, vereenvoudigt het beheer maar beperkt onafhankelijke verificatie.

Welke controles verschuiven naar uw organisatie bij open-weight?

Zelf hosten verplaatst beveiliging, privacy, safeguards, monitoring en onderhoud van de leverancier naar uw organisatie. Een deployment moet als volledig systeem worden beoordeeld: model, harness, retrieval, tools, sandboxing en runtime-handhaving. Een benchmarkresultaat zegt alleen iets over de geteste omstandigheden.

Wie open-weight overweegt, moet interne capaciteit opbouwen voor versiebeheer, monitoring en auditketens. Ontbreekt die capaciteit, dan ruilt u leveranciersafhankelijkheid in voor een onbeheerde keten.

• Herkomst en supply-chainbeveiliging — vastleggen waar het model vandaan komt en hoe de trainingsdata is beveiligd.
• Versiebeheer en hostinglocatie — documenteren welke versie u gebruikt en waar deze draait.
• Beschermende maatregelen en runtime-handhaving — implementeren welke guardrails en filtering u toepast.
• Monitoring en telemetrie — vastleggen hoe u gedrag en anomalieën detecteert.
• Incidentrespons en onderhoud — bepalen wie reageert op veiligheidsproblemen en hoe u patches toepast.
• Onafhankelijke inspectie — bewijzen dat u de keten zelf kunt controleren zonder leveranciersclaims.

Waarom samenvallen capability en security niet?

Het National Institute of Standards and Technology rapporteerde dat een bepaald open-weight model op het moment van beoordeling het meest cybercapabele publiek vrijgegeven model was, maar 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 versterkt dit beeld. Geen enkel model domineerde op alle dimensies. De gemeten financiële capability hing niet betrouwbaar samen met security-robuustheid. De auteurs benadrukken dat de resultaten afhangen van deployment en benchmark en geen volledige productiesecurity meten.

Een hogere inspecteerbaarheid kan samengaan met relevante dual-use-capaciteit. Open beschikbaarheid is dus geen synoniem voor veilig.

Welke concrete controles moet u per inzet aantonen?

1. Documenteer welk model u gebruikt en de lawful basis — vastleggen welke versie, welke trainingsdata en welke verwerking van gevoelige informatie rechtmatig is.
2. Implementeer versiebeheer en hostinglocatie onder uw grens — bewijzen dat u weet welke versie waar draait en wie daarover beschikt.
3. Leg runtime-, opslag-, beheer- en telemetriecomponenten vast — aantonen dat alle onderdelen van het systeem binnen uw organisatie of onder uw contractuele controle blijven.
4. Definieer monitoring, filtering en incidentrespons vooraf — vastleggen wie reageert op afwijkingen en hoe u beveiligingsproblemen aanpakt.
5. Eis per gesloten model contractueel inspectiebewijs — clausules opnemen over retentie, trainingsgebruik, subverwerkers, modelversies, regio en incidentmelding.
6. Voer per voorgenomen inzet een aparte taak-, security- en privacytoets uit — niet baseren op één ranglijst, maar op gescheiden beoordeling van prestatie, veiligheid en vertrouwelijkheid.

Hoe kiest u tussen architecturen?

Omdat open-weight modellen provenance, safeguards en incidentrespons bij uw organisatie leggen, bepaalt u vóór selectie of u versiebeheer, monitoring en een auditketen daadwerkelijk kunt bemensen. Omdat gesloten modellen onafhankelijke inspectie beperken, moet u contractueel inspectiebewijs afdwingen. Omdat capability en security niet samenvallen, mag u geen besluit baseren op één ranglijst. En omdat de volledige keten als systeem werkt, beoordeelt u bij self-hosting of alle runtime-, opslag-, beheer- en telemetriecomponenten werkelijk binnen uw grens blijven.

Tooling kan u helpen versiebeheer, monitoring en audittrails vast te leggen. Wat tooling niet kan doen: bepalen of de controles die u hebt ingericht werkelijk afdoende zijn voor uw risicoprofiel, of u de capaciteit hebt om ze vol te houden, of de contractuele termen met leveranciers werkelijk afdwingbaar zijn. Die oordelen blijven uw eigen professionele verantwoordelijkheid.