AI beveiligen in kritieke infrastructuur: waar AI Act, Cyber Resilience Act en NIS2 samenkomen

Kort antwoord: Zodra je AI inzet in een haven, een terminal of een vervoersketen, raak je vaak drie regelgevingskaders tegelijk. De AI Act eist dat het AI-systeem zélf bestand is tegen fouten en aanvallen (artikel 15). De Cyber Resilience Act stelt cybersecurity-eisen aan het product met digitale elementen waarin die AI zit. En NIS2 verplicht de exploitant — als essentiële entiteit in de vervoerssector — tot organisatiebrede risicomaatregelen en incidentmelding. Drie lagen rond één systeem — product, AI-functie en organisatie (en bij fysieke machines een vierde: de machine zelf). Wie de lagen door elkaar haalt, dekt gaten af die er niet zijn en mist gaten die er wél zijn.

Drie kaders, drie verschillende vragen

De kaders overlappen, maar ze stellen niet dezelfde vraag. Het helpt om ze te zien als drie lagen rond hetzelfde systeem:

• De Cyber Resilience Act — de productlaag. Vraag: is dit product met digitale elementen veilig ontworpen, geleverd en onderhouden? Het richt zich op de fabrikant en geldt horizontaal voor vrijwel alle hard- en software met een digitaal element.
• De AI Act, artikel 15 — de AI-laag. Vraag: is de AI-functie zelf nauwkeurig, robuust en bestand tegen AI-specifieke aanvallen? Het richt zich op de aanbieder van het hoogrisico-AI-systeem.
• NIS2 — de organisatielaag. Vraag: beheert de exploitant van de essentiële dienst zijn cyberrisico's en meldt hij incidenten? Het richt zich op de gebruiksverantwoordelijke organisatie — de haven, de terminaloperator, de vervoerder.

De kunst is niet om te kiezen, maar om te zien welke laag welke verplichting bij welke partij legt.

De AI-laag: artikel 15 van de AI Act

Artikel 15 verplicht aanbieders om hoogrisico-AI zo te bouwen dat het een passend niveau van nauwkeurigheid, robuustheid en cyberbeveiliging haalt over de hele levensduur. Naast klassieke beveiliging noemt het kader expliciet AI-specifieke dreigingen: data poisoning (manipulatie van trainingsdata), model poisoning (sabotage van vooraf getrainde componenten), adversarial examples (invoer die het model bewust misleidt) en vertrouwelijkheidsaanvallen (het onttrekken van model of data).

Dat onderscheid is wezenlijk: een AI-cameramodel dat containers classificeert kan technisch "veilig" zijn als product en tóch te misleiden zijn met geprepareerde stickers of belichting. Dat is geen klassiek IT-lek — het is een aanval op de logica van het model. Alleen artikel 15 dekt dit expliciet af.

Let op de timing: de hoogrisico-verplichtingen (waaronder artikel 15) zijn onder het Digital Omnibus-akkoord verschoven van 2 augustus 2026 naar 2 december 2027; tot de publicatie in het Publicatieblad geldt formeel nog de oude datum. Zie de tijdlijn van verplichtingen voor de actuele stand.

De productlaag: de Cyber Resilience Act

De Cyber Resilience Act (CRA, Verordening (EU) 2024/2847) stelt horizontale beveiligingseisen aan producten met digitale elementen: secure-by-design, geen bekende uitbuitbare kwetsbaarheden bij levering, beveiligingsupdates gedurende de ondersteuningsperiode, en het melden van actief misbruikte kwetsbaarheden. De meldplichten gaan eerder in (vanaf 11 september 2026) dan de bredere fabrikantsverplichtingen (vanaf 11 december 2027).

Cruciaal voor AI: de AI Act verklaart dat hoogrisico-AI die óók onder de CRA valt en aan de CRA-eisen voldoet, geacht wordt te voldoen aan de cybersecurity-eis van artikel 15 — voor zover die eisen elkaar dekken. Dubbel werk hoeft dus niet, maar de leverancierseisen en de AI-specifieke dreigingsanalyse moeten beide aantoonbaar zijn afgedekt; de CRA vervangt de AI-laag niet volledig.

De organisatielaag: NIS2

NIS2 (Richtlijn (EU) 2022/2555, in Nederland omgezet via de Cyberbeveiligingswet) richt zich niet op het product maar op de organisatie. Exploitanten in de vervoerssector — lucht, spoor, water en weg, inclusief havenbeheerders en terminaloperators — gelden doorgaans als essentiële of belangrijke entiteit. Zij moeten passende risicobeheersmaatregelen nemen, hun toeleveringsketen beheersen, incidenten melden en bestuurlijke verantwoordelijkheid beleggen.

Voor een haven die een AI-systeem inzet, is de AI dus een onderdeel van het bredere risicobeeld dat NIS2 sowieso al eist. Een falend of gemanipuleerd AI-systeem dat de containerafhandeling of toegangscontrole verstoort, is in NIS2-termen een potentieel meldplichtig incident. De samenloop met DORA speelt mee voor wie ook financiële ketens raakt.

De fysieke laag: de Machineverordening

Zit de AI in fysieke apparatuur — een geautomatiseerde kraan, een AGV of een magazijnrobot — dan komt er een vierde kader bij: de Machineverordening (Verordening (EU) 2023/1230). Die stelt veiligheidseisen aan machines en behandelt AI-gestuurde veiligheidsfuncties expliciet. Voor zwaar materieel in een terminal is dat geen randgeval maar de kern: zie AI in een magazijnrobot onder de Machineverordening, waar productveiligheid en AI-conformiteit op één machine samenvallen. Let op: voor in zulke gereguleerde producten ingebedde hoogrisico-AI (bijlage I) geldt een nóg latere AI Act-datum — onder het Digital Omnibus-akkoord 2 augustus 2028, dus weer een andere klok dan de zelfstandige bijlage III-systemen.

Waar ze samenkomen: een AI-systeem in de haven

Stel: een terminal zet een AI-systeem in voor automatische kraan- of stack-planning, gevoed door camera's en sensoren. Dan gelden tegelijk:

1. CRA op het product (de software/hardware met digitale elementen) — de leverancier moet het veilig ontwerpen en onderhouden.
2. AI Act art. 15 op de AI-functie — de aanbieder moet aantonen dat het model robuust en bestand tegen poisoning/adversarial input is, mits het systeem hoog-risico is.
3. NIS2 op de terminaloperator — die moet het systeem opnemen in zijn risicobeheer, leveranciersafspraken en incidentrespons.

Drie partijen, drie soorten bewijs, één keten. De fout die organisaties maken, is aannemen dat "onze leverancier is ISO-gecertificeerd" alle drie de lagen afdekt. Dat doet het niet: certificering op productniveau zegt weinig over adversarial-robuustheid van het model, en niets over de NIS2-plichten van de exploitant zelf.

Wie is verantwoordelijk voor wat

• De fabrikant/leverancier draagt de CRA-productverplichtingen en, als aanbieder van het hoogrisico-AI-systeem, artikel 15.
• De gebruiksverantwoordelijke (de haven, vervoerder, terminal) draagt de NIS2-organisatieverplichtingen én de AI Act-plichten van de gebruiksverantwoordelijke (menselijk toezicht, gebruik volgens instructies, monitoring).
• Contractueel moet je dit beleggen: vraag leveranciers om bewijs van CRA-conformiteit én van AI-specifieke robuustheidstests, en regel toegang tot logging en kwetsbaarheidsmeldingen. Zie ook de rol van de CISO onder de AI Act.

Wat te doen

• Breng per AI-systeem in kaart welke lagen gelden — product (CRA), AI-functie (art. 15), organisatie (NIS2) — en wie de drager is.
• Eis AI-specifieke dreigingsanalyse bovenop standaard security: poisoning, adversarial input, model-evasion en onttrekking van model/data.
• Leun op de CRA-vermoedensregel waar die geldt, maar dek de AI-laag aanvullend af; ze overlappen, maar dekken elkaar niet volledig.
• Neem AI op in je NIS2-risicobeheer — een gemanipuleerd AI-systeem in een kritieke keten kan een meldplichtig incident worden.
• Beleg het contractueel: bewijs van conformiteit, toegang tot logging, updateafspraken en kwetsbaarheidsmelding in de toeleveringsketen.
• Volg de data's: CRA-meldplichten (sep 2026) en bredere CRA-eisen (dec 2027) lopen niet gelijk met de verschoven AI Act-hoogrisicodatum (dec 2027).

Voor de bredere context: zie AI-regulering in transport en logistiek, predictive maintenance in transport en het maritieme single window (EMSWE). Veilige AI in kritieke infrastructuur is geen kwestie van één keurmerk — het is drie lagen die je apart moet kunnen aantonen.