NIS2 in België: valt uw AI-leverancier in uw keten?

Waarschijnlijk wel, maar alleen als het uw directe leverancier is. De Belgische NIS2-wet plaatst de beveiliging van de toeleveringsketen binnen uw eigen zorgplicht, en die reikt tot de relatie tussen u en uw directe leveranciers en dienstverleners. De partij die de meeste antwoorden over een AI-systeem heeft, de modelaanbieder, zit meestal één schakel verderop. Uw vragenlijst komt bij de verkeerde balie terecht.

Dit is geschreven voor de IT-manager, informatiemanager of security officer bij een Belgische organisatie van ruwweg 250 tot 5.000 medewerkers die als essentiële of belangrijke entiteit geregistreerd staat, en die een AI-assistent, een zoeksysteem of een agent in productie heeft genomen naast een bestaande ICT-partner. U hebt al een raamwerkkeuze, een auditkalender en een leveranciersvragenlijst. Wat u waarschijnlijk niet hebt, is een versie van die vragenlijst die het contact met een AI-leverancier overleeft.

Eerst één ding, want Vlaamse lezers krijgen stelselmatig Nederlands materiaal voorgeschoteld dat niet op hen van toepassing is. Nederland heeft een eigen omzetting, de Cyberbeveiligingswet, die sinds 15 augustus 2026 van kracht is. België kent een ander regime met andere data en een ander raamwerk, en was er eerder bij: de wet van 26 april 2024 trad op 18 oktober 2024 in werking, waarmee België als eerste lidstaat de richtlijn omzette. Leest u een artikel waarin staat dat uw verplichtingen in augustus 2026 zijn begonnen, dan leest u over het buurland.

Valt uw AI-leverancier überhaupt onder de Belgische NIS2-wet?

Meestal niet rechtstreeks. De wet bindt entiteiten die een omvangsdrempel halen en een dienst leveren die in de bijlagen staat, volgens de definities uit aanbeveling 2003/361/EG van de Commissie. Een dienst uit bijlage I op het formaat van een grote onderneming maakt u essentieel; een dienst uit bijlage I op middelgroot formaat, of een dienst uit bijlage II, maakt u belangrijk. Een AI-studio van twintig mensen die een zoeksysteem op uw documentarchief bouwt, is geen van beide.

De wet bereikt hen via u. Essentiële en belangrijke entiteiten moeten hun toeleveringsketen beveiligen, en de Belgische formulering is precies: de plicht betreft de beveiligingsaspecten van de relatie tussen de entiteit en haar directe leveranciers of dienstverleners. Dat woord 'direct' is hier bepalend, en het is dezelfde grens die de Nederlandse wet trekt. Uw AI-leverancier valt binnen uw plicht omdat u een contract met hem hebt. Van wie hij zijn model afneemt, valt daarbuiten.

De handhaving loopt dus commercieel en niet bestuursrechtelijk. Niemand van het CCB gaat bij uw AI-leverancier inspecteren. Een inspecteur kijkt naar wat u hebt gevraagd, wat u te horen kreeg en wat u met de gaten hebt gedaan. Dat onderscheid telt zodra u beslist hoeveel eigen budget u besteedt aan het najagen van een antwoord dat niet bestaat.

Waarom verwijst het CCB uw leveranciers naar CyberFundamentals Basic?

Omdat België een ondergrens heeft gebouwd die het Nederlandse regime niet kent. Het CyberFundamentals-raamwerk, CyFun, is de getrapte maatregelenset van het CCB, en een gevalideerde implementatie levert een vermoeden van conformiteit op met de risicobeheersverplichtingen: tot het tegendeel blijkt, wordt u geacht eraan te hebben voldaan. Het CCB adviseert elke organisatie die in de keten van een NIS2-entiteit terecht kan komen om minstens aan CyFun Basic te voldoen, en merkt op dat een NIS2-entiteit in theorie een bepaald CyFun-niveau aan haar directe leveranciers kan opleggen.

Dat advies heeft inmiddels gewicht. Bij de eerste verjaardag meldde het CCB 1.500 essentiële en 2.500 belangrijke geregistreerde entiteiten, waarvan 75 procent al een raamwerk had gekozen en de meerderheid daarvan CyFun. Vierduizend organisaties met een raamwerk en een auditdatum leveren heel wat leveranciersvragenlijsten op, en de lijsten die dit jaar in de mailbox van AI-leveranciers belanden, zijn op CyFun geënt.

Er lag een hard ijkpunt op 18 april 2026. Essentiële entiteiten moesten de inspectiedienst van het CCB een van drie dingen tonen: een verificatie CyFun Basic of Important die behaald is of actief loopt, dan wel een getekende overeenkomst met een geaccrediteerde beoordelingsinstelling; of een ISO/IEC 27001-scope, verklaring van toepasselijkheid en het recentste interne auditrapport, met volledige certificering tegen april 2027; of een zelfevaluatie plus een formeel verzoek om inspectie, een route waarvan het CCB aangeeft dat die rechtstreeks tot toezichtsmaatregelen kan leiden. Die datum is gepasseerd. Valt u onder de wet, dan zijn de vragenlijsten geen hypothese meer.

De inspectiedienst kwam op 11 augustus 2026 op het onderwerp terug, met een mededeling aan essentiële entiteiten op grond van artikel 48 van de NIS2-wet. Het thema was het cyberrisico dat met frontier-AI-systemen meekomt, en de dienst noemde ketenbeveiliging als een van de processen die geavanceerde AI verandert, naast governance, risicobeoordeling, monitoring en incidentrespons. De brief ging rechtstreeks naar de entiteiten en is niet integraal gepubliceerd, dus geldt de samenvatting op de nieuwspagina van het CCB als het publieke spoor ervan. Waar het hier om gaat: de toezichthouder heeft AI en ketenbeveiliging al in één zin gezet.

Welke CyFun-vragen kan een AI-leverancier wél beantwoorden?

Meer dan men denkt. Breng de vragenlijst terug tot wat een leverancier in de eerste schakel zelf beheert, en een bekwame AI-leverancier hoort dit zonder aarzelen te beantwoorden:

• Hoe hij zich aanmeldt in uw omgeving, met welk soort account, en of die credential met een andere klant wordt gedeeld.
• Wie van zijn medewerkers de prompts en documenten van uw gebruikers kan lezen, met welke logging, en hoe lang.
• Zijn eigen basishygiëne: meervoudige authenticatie, patchritme, back-up en herstel, en in-, door- en uitstroom voor de mensen op uw account.
• Zijn lijst van onderaannemers, en of daarin iets is veranderd sinds de ondertekening.

• De route en de klok waarmee hij u over een incident aan zijn kant inlicht; die moet binnen uw eigen meldplicht passen.

Dat laatste punt is waar de meeste AI-contracten zwijgen en waar zwijgen het duurst is. Onder het Belgische regime vraagt een significant incident een vroegtijdige waarschuwing aan het CCB binnen 24 uur nadat u er kennis van krijgt, een incidentmelding binnen 72 uur, een tussentijds verslag op verzoek en een eindverslag binnen een maand. Een leverancier die u op dinsdag vertelt over iets wat hij vrijdag zag, heeft uw venster van 24 uur opgebruikt voordat u wist dat het openstond. Die clausule is meer waard dan het certificaat.

Welke vragen kan alleen de modelaanbieder beantwoorden, en doet hij niet?

Hier zit het structurele probleem, en het ligt niet aan een ontwijkende leverancier. Een vragenlijst die voor een hosting- of softwareleverancier is gemaakt, veronderstelt dat de partij met wie u contracteert zelf beheert waarnaar u vraagt. Bij een AI-systeem gaan vier van de zwaarstwegende vragen over infrastructuur die uw leverancier huurt:

• Wat er met een prompt gebeurt nadat die de applicatie van uw leverancier verlaat: hoe lang hij wordt bewaard, of hij in misbruikmonitoring terechtkomt, en of een mens hem kan lezen.
• In welke regio een concrete inferentie-aanroep werkelijk heeft gedraaid, en niet voor welke regio het account staat ingesteld.
• Hoeveel aankondiging er is, als die er al is, voordat een modelversie onder een ongewijzigde API verandert.
• Of een modelupdate telt als een wijziging waarover uw leverancier u contractueel moet inlichten.

Een modelaanbieder publiceert voorwaarden voor alle klanten en onderhandelt met zeer weinige afzonderlijk. Uw leverancier krijgt die voorwaarden niet anders geformuleerd, en een kleine AI-leverancier heeft bij een frontier lab niet meer invloed dan u. Harder duwen op de eerste schakel levert een langer antwoord op, geen beter.

Het eerlijke oordeel luidt dus dat een ketenplicht die bij de directe leverancier ophoudt, blijft steken bij de schakel vóór de partij die de antwoorden heeft. Dat is geen redactiefout waar u omheen kunt argumenteren. Het is de vorm van de verplichting, en de bruikbare reactie is om de eerste schakel niet langer feiten te laten garanderen die hij niet beheert.

Wat zet u in het contract in plaats van een certificaat?

Drie dingen, en geen daarvan vraagt om een CyFun-label dat uw leverancier toch nooit ging kopen. Ten eerste een doorlegverplichting: de leverancier noemt de modelaanbieders en subverwerkers achter de dienst, houdt die lijst actueel en licht u in vóór er iets wijzigt. U maakt hem niet verantwoordelijk voor de beveiliging van de bovenliggende partij. U maakt hem verantwoordelijk voor de transparantie die u zelf niet kunt afdwingen.

Ten tweede symmetrie in melden. De leverancier meldt een incident, een wezenlijke wijziging van voorwaarden of een modelversiewissel binnen een venster dat uw eigen vroegtijdige waarschuwing van 24 uur intact laat. Schrijf die uren op. Een clausule die "zonder onnodige vertraging" zegt, overleeft een vrijdagmiddag niet.

Ten derde, en dit wordt het vaakst overgeslagen, een benoemde wijzigingscategorie voor modelgedrag. Een model dat zonder uitrol anders begint te antwoorden, is geen beschikbaarheidsgebeurtenis en verschijnt op niemands monitoring. Wij hebben elders betoogd dat niemand een melding krijgt wanneer een AI-systeem draait en ernaast zit; de contractuele versie van dat betoog is dat niemand u hoeft te melden dat modelgedrag is veranderd zolang dat geen wijziging heet.

Wat u hier opbouwt is een dossier waaruit blijkt dat u hebt gevraagd, antwoord hebt gekregen en hebt gehandeld. Onder het voorafgaande toezicht op essentiële entiteiten is dat dossier wat een inspecteur kan zien. Een certificaat dat uw leverancier niet heeft, is dat niet.

Geldt CyFun 2023 of CyFun 2025 op het moment dat u de vragenlijst stuurt?

Voorlopig allebei, en het loont om dit vóór verzending recht te zetten, want u wilt de oefening niet twee keer doen. Het CCB bracht CyFun 2025 uit in oktober 2025, nauwer afgestemd op het NIST Cybersecurity Framework 2.0 en op NIS2. De belangrijkste wijzigingen raken precies dit onderwerp: meer aandacht voor de beveiliging van de toeleveringsketen, meer aandacht voor operationele technologie, en governancemaatregelen vanaf het zekerheidsniveau Important.

Het CCB heeft gezegd dat beide versies tijdens een overgangsperiode beschikbaar blijven. Geaccrediteerde beoordelingsinstellingen die hun eigen overgangsuitleg publiceren, leggen het einde van die keuze op 18 april 2027, met verklaringen op basis van 2023 die uiterlijk tot 18 april 2028 geldig blijven. Behandel die twee data als de lezing van de certificerende instellingen en niet als wettekst die u een inspecteur kunt voorhouden, en bevestig ze bij uw eigen beoordelaar. Het planningsgevolg staat hoe dan ook overeind: koerst uw eigen conformiteitswerk op CyFun 2025, stel uw leveranciers de ketenvragen van 2025 nu, in plaats van ze volgend jaar opnieuw te stellen.

Merk ook op dat u een CyFun-zekerheidsniveau onder uw NIS2-classificatie mag verantwoorden op grond van een risicoanalyse, en dat de inspectiedienst u kan sanctioneren als u zich aan een lager niveau conformeert dan uw risico rechtvaardigt. Dezelfde logica hoort te gelden voor wat u van een AI-leverancier eist. Een verwachting op Basic-niveau bij een leverancier wiens systeem aan uw klantgegevens raakt, is een beslissing die u zult moeten verdedigen en geen besparing.

Wat dit betekent voor een IT-organisatie die al partners heeft

U hebt hiervoor geen nieuwe ICT-partner nodig, en wij bieden ons daar ook niet voor aan. Crux Digits bouwt en integreert AI-systemen naast de ICT-partner of het interne IT-team dat u al hebt; wij draaien geen servicedesks, infrastructuur of beheer van uw IT-landschap, en wij zijn geen conformiteitsbeoordelingsinstelling, dus wij kunnen niemand tegen CyFun verifiëren. Wat een AI-leverancier u hier verschuldigd is, is toetsbaar bewijs over zijn eigen helft van het systeem en eerlijkheid over de helft die hij huurt.

De praktische volgorde is weinig spannend. Neem uw bestaande leveranciersvragenlijst, splits die in wat de eerste schakel beheert en wat hij huurt, haal harde antwoorden op de eerste helft, leg doorleg- en meldclausules vast voor de tweede, en bewaar de correspondentie. Valt het AI-systeem ook onder de AI Act, dan lopen de verplichtingen naast elkaar in plaats van elkaar te vervangen, en de meldklokken zijn niet even lang.

Wilt u bij het uitwerken van een implementatie de leveranciersvragen geregeld hebben vóór livegang in plaats van na de eerste auditbrief, dan is dat het gesprek om te voeren zolang de architectuur nog beweegt.

Veelgestelde vragen