Transport & Kritieke Infrastructuur — Naleving van de EU AI Act

Verplichtingen uit de EU AI Act voor AI in autonome voertuigen, verkeersmanagement, luchtvaart, spoorwegen en kritieke infrastructuur. Behandelt Annex I (NLF) en Annex III categorie 2.

Waarom Transport een Prioriteitssector is onder de EU AI Act

De EU AI Act (Verordening (EU) 2024/1689) legt de zwaarste verplichtingen op in domeinen waar AI-storingen directe gevolgen hebben voor de fysieke veiligheid, de continuïteit van kritieke diensten en de openbare veiligheid. Transport en kritieke infrastructuur nemen om twee onafhankelijke juridische redenen een centrale positie in binnen dit stelsel: de wijdverspreide inzet van AI als veiligheidscomponenten in gereguleerde transportproducten (wat Art. 6(1) activeert via Annex I), en de uitdrukkelijke vermelding van AI voor het beheer van kritieke infrastructuur als hoog-risico onder Annex III, punt 2.

De transportsector onderscheidt zich ook door de dichtheid en volwassenheid van zijn bestaande regelgevingskaders. De typegoedkeuring van voertuigen op grond van de Algemene Veiligheidsverordening (EU) 2019/2144, de luchtvaarteertificering op grond van de EASA Basisverordening (EU) 2018/1139, de spoorweginteroperabiliteit en -veiligheid op grond van de ERA-Verordening (EU) 2016/796 en Veiligheidsrichtlijn 2016/798, en de cybersecurity van kritieke infrastructuur op grond van de NIS2-Richtlijn (EU) 2022/2555 scheppen reeds bestaande wettelijke verplichtingen die worden gestapeld op — en in sommige gevallen structureel samenhangen met — de EU AI Act.

Voor transportorganisaties heeft dit als praktische consequentie dat AI-compliance niet kan worden beheerd als een afzonderlijk regelgevingstraject. Het moet worden geïntegreerd in bestaande programma's voor typegoedkeuring, certificering, veiligheidsmanagement en cybersecurity. Het uitblijven van deze integratie levert niet alleen een risico op van niet-naleving van de AI Act, maar ook van non-conformiteit met sectorale regelgeving die eigen handhavingsautoriteiten en consequenties voor markttoegang kent.

Veiligheidscomponent-AI (Annex I) versus Kritieke Infrastructuur-AI (Annex III, punt 2)

De EU AI Act creëert twee afzonderlijke hoog-risicopaden die relevant zijn voor transport. Begrijpen welk pad van toepassing is — en of beide paden tegelijkertijd van toepassing zijn — is de eerste analytische stap in elk nalevingsprogramma voor transport-AI.

Annex I — Veiligheidscomponenten van NLF-gereguleerde Producten

Art. 6(1) van de EU AI Act classificeert als hoog-risico elk AI-systeem dat een veiligheidscomponent is van een product dat is gereguleerd op grond van New Legislative Framework (NLF)-wetgeving die is opgenomen in Annex I. Voor transport zijn de belangrijkste NLF-instrumenten:

• Algemene Veiligheidsverordening (EU) 2019/2144 — wegvoertuigen (personenauto's, vrachtwagens, motorfietsen, bussen)
• EASA Basisverordening (EU) 2018/1139 — luchtvaartuigen, motoren en aanverwante uitrusting
• ERA Spoorwegwetgeving — waaronder Verordening (EU) 2016/796 (ERA-agentschap), Richtlijn 2016/797 (interoperabiliteit) en Richtlijn 2016/798 (spoorwegveiligheid)
• Machinerichtlijn (EU) 2023/1230 — relevant voor AI in geautomatiseerde havenuitrusting, industriële voertuigen en bouwmachines die actief zijn in transportinfrastructuurcontexten

Een AI-systeem is een veiligheidscomponent van een transportproduct als het uitvallen of de storing ervan de gezondheid of veiligheid van personen in gevaar kan brengen. Voor wegvoertuigen omvat dit autonome noodremssystemen, rijstrookbehouds-AI, adaptieve cruise control op SAE-niveau L2 en hoger, en alle L3–L5 geautomatiseerde rijsystemen. Voor de luchtvaart omvat dit AI in vluchtvluchtsystemen, autopilootcomponenten en grondnaderingswaarsystemen. Voor spoorwegen omvat dit AI in automatische treinbeveiliging, AI-ondersteunde seingeving en autonoom rangeren.

De classificatie op grond van Art. 6(1) is categorisch. Een AI-systeem hoeft niet zelfstandig aan te tonen dat er een significante kans op schade bestaat — de aanduiding als veiligheidscomponent is daartoe voldoende. Dit betekent dat aanbieders van dergelijke systemen moeten voldoen aan de vereisten van Hoofdstuk III, Afdeling 2 (Art. 9–15) betreffende risicobeheer, datagovernance, technische documentatie, automatische logging, transparantie, menselijk toezicht en nauwkeurigheid en robuustheid.

Annex III, Punt 2 — Beheer van Kritieke Infrastructuur

Los van het veiligheidscomponentenpad vermeldt Annex III, punt 2 uitdrukkelijk als hoog-risico de AI-systemen die bestemd zijn voor gebruik als veiligheidscomponenten bij het beheer en de exploitatie van kritieke infrastructuur, met name:

• Kritieke wegverkeersinfrastructuur
• Kritieke waterwegeninfrastructuur
• Kritieke elektriciteitsnetonderdelen (als kritieke infrastructuur met risicopatronen vergelijkbaar met die van transport)

AI-systemen die in deze categorie vallen, omvatten: platforms voor snelwegverkeersmanagement die AI gebruiken voor dynamische snelheidsregeling en incidentdetectie, AI-gebaseerde systemen voor stabiliteit en lastbalancering van slimme netten waar netuitval gevolgen zou hebben voor transportactiviteiten, en AI-systemen die haveninfrastructuur beheren op het niveau van exploitatie van een essentiële dienst.

Het onderscheid tussen punt 2 en het Annex I-pad is dat Annex III, punt 2 van toepassing is op exploitanten van infrastructuur en niet uitsluitend op producenten. Een overheidsinstantie of private concessiehouder die een AI-gestuurd verkeersmanagementcentrum exploiteert, is onderworpen aan de verplichtingen van punt 2 als gebruiksverantwoordelijke of, indien zij het AI-systeem zelf heeft ontwikkeld, als aanbieder.

Dubbele Classificatie

Wanneer een AI-systeem zowel een veiligheidscomponent is van een NLF-gereguleerd product als wordt ingezet voor het beheer van kritieke infrastructuur (bv. een AI-systeem dat geïntegreerd is in een slim snelwegplatform dat ook interfaces met voertuigsystemen heeft), zijn beide paden van toepassing. De zwaarste verplichtingen zijn bepalend.

Aanbieder versus Gebruiksverantwoordelijke in de Transportcontext — OEM versus Exploitant

De toewijzing van verplichtingen tussen aanbieders (Art. 16) en gebruiksverantwoordelijken (Art. 26) is bijzonder complex in de transportsector, waar de toeleveringsketen tussen AI-ontwikkelaar, systeemintegrator, OEM, infrastructuurexploitant en eindgebruikersvloot meerdere rechtspersonen kan omvatten die elk afzonderlijke verantwoordelijkheden dragen op grond van de AI Act.

Voertuig-OEM's als Aanbieders

Een OEM die een AI-rijsysteem integreert — ongeacht of dit intern is ontwikkeld of afkomstig is van een Tier 1- of Tier 2-leverancier — en het voertuig op de EU-markt brengt onder zijn eigen merknaam, is de aanbieder van het AI-systeem op grond van Art. 16. Dit geldt ook wanneer de AI-technologie oorspronkelijk door een derde partij is ontwikkeld, mits de OEM niet louter een ongewijzigd systeem heeft doorverkocht onder de merknaam van die derde partij. De verplichtingen van de aanbieder omvatten:

• Het opzetten van een kwaliteitsbeheersysteem op grond van Art. 17
• Het opstellen en bijhouden van technische documentatie op grond van Art. 11 en Annex IV, met betrekking tot het beoogde doel, het ontwerp, de trainingsdata, de validatieresultaten en het plan voor post-marktbewaking van het AI-systeem
• Het uitvoeren of opdragen van conformiteitsbeoordeling — die voor veiligheidscomponenten van voertuigen moet worden gecoördineerd met de typegoedkeuringsprocedure op grond van GSR 2019/2144
• Het registreren van het AI-systeem in de EU-database voor hoog-risico AI-systemen op grond van Art. 49 vóór het in de handel brengen
• Het verstrekken van gebruiksinstructies aan gebruiksverantwoordelijken (vlootexploitanten, verhuurbedrijven) die toereikend zijn om een conforme inzet mogelijk te maken

Vlootexploitanten en Concessiehouders als Gebruiksverantwoordelijken

Een bedrijf dat een vloot van autonome voertuigen exploiteert, een lokale overheid die een AI-verkeersbeheersysteem inzet, of een spoorweginfrastructuurbeheerder die AI-ondersteunde onderhoudsinstrumenten gebruikt, is een gebruiksverantwoordelijke op grond van Art. 26. De verplichtingen van de gebruiksverantwoordelijke omvatten:

• Het AI-systeem gebruiken binnen het toepassingsgebied van de gebruiksinstructies van de aanbieder — elk operationeel gebruik buiten dat toepassingsgebied kan ertoe leiden dat de gebruiksverantwoordelijke wordt geherkwalificeerd als aanbieder, waarmee de volledige reeks verplichtingen van de aanbieder van toepassing wordt
• Het implementeren van maatregelen voor menselijk toezicht zoals gespecificeerd door de aanbieder en passend bij de operationele context
• Het bewaren van operationele logs die door het AI-systeem worden gegenereerd gedurende ten minste zes maanden, of langer wanneer toepasselijke sectorale wetgeving (NIS2, nationale vervoersveiligheidswetgeving) een langere bewaartermijn vereist
• Het tijdig melden van storingen of ernstige incidenten aan de aanbieder, en aan nationale bevoegde autoriteiten op grond van Art. 73 wanneer de veiligheid of grondrechten in het geding zijn
• Het uitvoeren van grondrechtelijke effectbeoordelingen (FRIA's) op grond van Art. 27 wanneer het AI-systeem wordt ingezet door een overheidsinstantie of in contexten die op grote schaal gevolgen hebben voor personen

Wisselwerking met Sectorale Regelgeving — EASA, ERA en Typegoedkeuring

Wegvoertuigen — GSR 2019/2144 en Typegoedkeuring

De Algemene Veiligheidsverordening (EU) 2019/2144 verplicht de opname van specifieke ADAS- en autonoom-rijfuncties in nieuwe voertuigtypen en stelt technische vereisten voor hun prestaties. Typegoedkeuring van voertuigen — uitgevoerd door nationale typegoedkeuringsinstanties (bv. KBA in Duitsland, DREAL in Frankrijk, Rijksdienst voor het Wegverkeer in Nederland) — is het primaire mechanisme voor markttoegang voor wegvoertuigen.

De EU AI Act vervangt typegoedkeuring niet. Art. 8(1) van de AI Act bepaalt dat waar sectorspecifieke wetgeving vereisten oplegt van gelijkwaardige of grotere strengheid, procedurele afstemming mogelijk is, maar de verplichtingen van de AI Act blijven van kracht. In de praktijk moet de conformiteitsbeoordeling voor een AI-rijsysteem zowel de GSR-technische vereisten (beoordeeld als onderdeel van typegoedkeuring) als de vereisten van de AI Act (technische documentatie, datagovernance, logging, menselijk toezicht, post-marktbewaking) omvatten. OEM's dienen te plannen voor een geïntegreerde beoordeling die beide kaders omvat, om dubbele inspanningen en mogelijke lacunes te vermijden.

Luchtvaart — EASA en de AI-Routekaart

EASA oefent certificeringsautoriteit uit over luchtvaartuigen, motoren en onderdelen op grond van Verordening (EU) 2018/1139. De AI-routekaart van EASA (gepubliceerd in opeenvolgende edities vanaf 2020) heeft betrekking op AI-betrouwbaarheid voor luchtgebonden AI-systemen en is de primaire certificeringsreferentie voor AI in vluchtcritische toepassingen.

De EU AI Act is van toepassing op grondgebonden luchtvaart-AI (verkeersmanagement, onderhouddiagnostiek, cabinebeheersystemen) die buiten het luchtwaardigheidsgebied van EASA valt. Voor luchtgebonden AI-systemen die door EASA zijn gecertificeerd, is afstemming op grond van Art. 8(1) mogelijk, maar de overlap tussen de luchtwaardigheidsverordeningen van EASA en de verplichtingen van de AI Act (met name op het gebied van logging en menselijk toezicht) moet systeem voor systeem worden geanalyseerd. Het begrip "AI-assuranceniveau" van EASA correspondeert niet rechtstreeks met de hoog-risicoclassificatie of de conformiteitsbeoordelingsvereisten van de EU AI Act.

Spoorwegen — ERA en Veiligheidsbeheersystemen

ERA (Europees Spoorwegbureau) houdt toezicht op de spoorweginteroperabiliteit en het gemeenschappelijk veiligheidskader op grond van Richtlijnen 2016/797 en 2016/798. Spoorwegondernemingen en infrastructuurbeheerders zijn verplicht een Veiligheidsbeheersysteem (VBS) bij te houden dat risicobeoordelingen, onderzoek naar ongevallen en voortdurende verbetering omvat.

De vereisten voor risicobeheer van de AI Act op grond van Art. 9 vertonen sterke parallellen met de VBS-vereisten van ERA. Organisaties met een volwassen VBS zijn goed gepositioneerd om de documentatie van het AI Act-risicobeheer in het bestaande kader te integreren. ERA en de Europese Commissie hebben een voorkeur uitgesproken voor geïntegreerde nalevingsbenaderingen die duplicatie tussen VBS en AI Act-verplichtingen voorkomen. AI-systemen die worden gebruikt bij automatische treinexploitatie, ETCS-componenten (European Train Control System) met AI, of voorspellend onderhoud dat bijdraagt aan veiligheidskritieke beslissingen, zijn hoog-risico op grond van Annex I (veiligheidscomponent van spoorvoertuigen of -infrastructuur).

Handhaving en Certificeringsinstanties

Naleving van transport-AI-regelgeving omvat meerdere handhavingsinstanties met gedeeltelijk overlappende bevoegdheden, afhankelijk van de functie van het AI-systeem en het product waarin het is ingebed.

EASA is de certificeringsinstantie voor AI in luchtvaartuigen en luchtvaartproducten. Zij kan onderzoeken instellen naar storingen van AI-systemen die de luchtwaardigheid betreffen, en haar beslissingen hebben gevolgen voor de markttoegang in de EU en bij bilaterale partnerlanden.

ERA houdt toezicht op het gemeenschappelijk veiligheidskader voor spoorwegen. Veiligheidscertificaten voor spoorwegen en vergunningen om te exploiteren zijn afhankelijk van de conformiteit met het VBS, dat in toenemende mate raakvlakken heeft met de naleving van de AI Act voor AI-ondersteunde spoorsystemen.

Nationale typegoedkeuringsinstanties voor voertuigen — waaronder KBA (Duitsland), door ANFIA aangewezen instanties (Italië) en de Rijksdienst voor het Wegverkeer (Nederland) — verlenen typegoedkeuringen voor wegvoertuigen en kunnen deze intrekken. Non-conformiteit met de vereisten van de AI Act voor AI-veiligheidscomponenten kan grond vormen voor schorsing van de typegoedkeuring of terugroeping.

Nationale bevoegde NIS2-autoriteiten — aangewezen door elke lidstaat, vaak een nationaal cybersecurityagentschap zoals BSI (Duitsland), ANSSI (Frankrijk) of NCSC-NL (Nederland) — handhaven de NIS2-verplichtingen voor exploitanten van essentiële diensten in de transportsector. NIS2-handhaving kan leiden tot bindende instructies, boetes en in ernstige gevallen schorsing van de activiteiten.

Nationale AI-toezichthoudende autoriteiten aangewezen op grond van Art. 70 van de EU AI Act zullen algemene bevoegdheden voor markttoezicht hebben, met coördinatiemechanismen voor sectorspecifieke autoriteiten om jurisdictieconflicten te voorkomen.

Nalevingsprioriteiten voor Transportexploitanten en Aanbieders

Stap 1: Inventarisatie en Classificatie van AI-Systemen

Voer een gestructureerde inventarisatie uit van alle AI-systemen die worden ontwikkeld of ingezet binnen het transportproduct- of operationele portfolio. Bepaal voor elk systeem of het een veiligheidscomponent is van een NLF-gereguleerd product (pad via Art. 6(1)), een AI-systeem voor het beheer van kritieke infrastructuur (Annex III, punt 2), of beide. Documenteer de classificatieratio schriftelijk. Systemen die niet definitief kunnen worden uitgesloten van hoog-risicoclassificatie, dienen als hoog-risico te worden behandeld in afwachting van een definitieve juridische analyse.

Stap 2: Planning van de Route voor Conformiteitsbeoordeling

Identificeer voor AI-systemen die veiligheidscomponenten zijn van voertuigen, luchtvaartuigen of spoorwegproducten de toepasselijke sectorale certificeringsprocedure en breng deze in kaart ten opzichte van de vereisten voor conformiteitsbeoordeling van de AI Act. Bepaal of een aangemelde instantie vereist is (Art. 43(3)) dan wel of een zelfbeoordeling met technische audit door een derde partij volstaat. Coördineer de tijdplanning van de conformiteitsbeoordeling op grond van de AI Act met het typegoedkeurings- of certificeringsprogramma om vertragingen bij de markttoegang te voorkomen.

Stap 3: Technische Documentatie en Datagovernance

Stel technische documentatie op grond van Annex IV op voor elk hoog-risico AI-systeem. Voor transport-AI moet deze documentatie omvatten: het beoogde doel met voldoende precisie om zowel de classificatie op grond van de AI Act als op grond van de sectorale regelgeving te ondersteunen; de herkomst van trainingsdata, inclusief eventuele real-world rij-, operationele of sensordata die is gebruikt; beschrijvingen van simulatieomgevingen voor AI-systemen die zijn gevalideerd via virtueel testen; en plannen voor post-marktbewaking die zijn afgestemd op sectorspecifieke rapportageverplichtingen.

Stap 4: NIS2-Integratie voor Exploitanten van Kritieke Infrastructuur

Exploitanten van essentiële diensten in de transportsector moeten de cybersecurityvereisten van de AI Act op grond van Art. 15 integreren met de verplichtingen voor cybersecurityrisicobeheer op grond van NIS2. Stel één enkel beveiligingsrisicobeoordelingsproces in dat beide kaders omvat. Zorg ervoor dat AI-softwareleveranciers — waaronder AI-modelontwikkelaars en dataverstrekkers — zijn onderworpen aan vereisten voor de beveiliging van de toeleveringsketen die consistent zijn met NIS2 Art. 21(2)(d) en AI Act Art. 25 (verplichtingen voor instrumenten van derden).

Stap 5: Menselijk Toezicht in Operationele Contexten

Ontwerp mechanismen voor menselijk toezicht op grond van Art. 14 die operationeel haalbaar zijn in transportomgevingen. Definieer voor autonome rijsystemen de omstandigheden waaronder een bestuurder de controle moet kunnen overnemen (L3) of een externe operator moet kunnen ingrijpen (L4). Specificeer voor AI in luchtverkeersleiding de punten in de werkstroom waarop een luchtverkeersleider door AI gegenereerde instructies moet beoordelen en goedkeuren. Stel voor AI in spoorwegonderhoud escalatieprotocollen vast wanneer het systeem veiligheidskritieke afwijkingen signaleert. Toezichtsmechanismen moeten worden gedocumenteerd in de technische documentatie en weerspiegeld in de gebruiksinstructies die aan gebruiksverantwoordelijken worden verstrekt.

Stap 6: Post-Marktbewaking en Incidentrapportage

Stel systemen voor post-marktbewaking in die voldoen aan zowel de vereisten van Art. 72 van de AI Act als sectorspecifieke veiligheidsrapportageverplichtingen (ERA-incidentmelding, EASA-occurrencemelding op grond van Verordening (EU) 376/2014, NIS2-incidentmelding). Ernstige incidenten waarbij hoog-risico AI-systemen betrokken zijn, moeten worden gemeld aan de nationale AI-toezichthoudende autoriteit op grond van Art. 73 binnen 15 werkdagen nadat men hiervan kennis heeft genomen. Deze termijn moet worden afgestemd op de vereiste initiële melding van NIS2 binnen 24 uur voor significante cybersecurity-incidenten, die dezelfde gebeurtenis kunnen betreffen indien de storing van het AI-systeem toe te schrijven is aan een cybersecurityinbreuk.