Transport & Kritische Infrastruktur — EU AI Act Compliance

EU AI Act-Pflichten für KI in autonomen Fahrzeugen, Verkehrsmanagement, Luftfahrt, Schienenverkehr und kritischer Infrastruktur. Behandelt Annex I (NLF) und Annex III Kategorie 2.

Warum der Transportsektor ein vorrangiger Sektor des EU AI Act ist

Der EU AI Act (Verordnung (EU) 2024/1689) weist die anspruchsvollsten Pflichten den Bereichen zu, in denen KI-Fehler unmittelbare Folgen für die physische Sicherheit, die Kontinuität kritischer Dienste und die öffentliche Sicherheit haben. Transport und kritische Infrastruktur nehmen in dieser Architektur aus zwei unabhängigen rechtlichen Gründen eine zentrale Stellung ein: die weitverbreitete Nutzung von KI als Sicherheitskomponenten in regulierten Transportprodukten (was Art. 6(1) über Annex I auslöst) sowie die ausdrückliche Auflistung von KI für das Management kritischer Infrastrukturen als hochriskant in Annex III, Punkt 2.

Der Transportsektor zeichnet sich zudem durch die Dichte und Reife seiner bestehenden regulatorischen Rahmenwerke aus. Die Fahrzeugtypgenehmigung nach der Allgemeinen Sicherheitsverordnung (EU) 2019/2144, die Luftfahrtzertifizierung nach der EASA-Basisverordnung (EU) 2018/1139, die Eisenbahn-Interoperabilität und -Sicherheit nach der ERA-Verordnung (EU) 2016/796 und der Sicherheitsrichtlinie 2016/798 sowie die Cybersicherheit kritischer Infrastrukturen nach der NIS2-Richtlinie (EU) 2022/2555 begründen bestehende rechtliche Verpflichtungen, die sich mit dem EU AI Act kumulieren — und in einigen Fällen strukturell mit ihm interagieren.

Für Transportunternehmen hat dies die praktische Konsequenz, dass KI-Compliance nicht als isolierter regulatorischer Workstream verwaltet werden kann. Sie muss in bestehende Typgenehmiegungs-, Zertifizierungs-, Sicherheitsmanagement- und Cybersicherheitsprogramme integriert werden. Das Versäumnis dieser Integration birgt nicht nur das Risiko einer Nichteinhaltung des AI Act, sondern auch der Nichtkonformität mit Sektorvorschriften, die eigene Vollzugsbehörden und Marktzugangskonsequenzen haben.

Sicherheitskomponenten-KI (Annex I) vs. KI für kritische Infrastrukturen (Annex III, Punkt 2)

Der EU AI Act schafft zwei verschiedene Hochrisiko-Pfade, die für den Transport relevant sind. Das Verständnis, welcher Pfad anwendbar ist — und ob beide gleichzeitig greifen — ist der erste analytische Schritt in jedem Transport-KI-Compliance-Programm.

Annex I — Sicherheitskomponenten von NLF-regulierten Produkten

Art. 6(1) des EU AI Act stuft als hochriskant jedes KI-System ein, das eine Sicherheitskomponente eines Produkts ist, das unter die in Annex I aufgeführten Rechtsvorschriften des Neuen Rechtsrahmens (NLF) fällt. Für den Transport sind die zentralen NLF-Instrumente:

• Allgemeine Sicherheitsverordnung (EU) 2019/2144 — Straßenfahrzeuge (PKW, LKW, Motorräder, Busse)
• EASA-Basisverordnung (EU) 2018/1139 — Luftfahrzeuge, Triebwerke und zugehörige Ausrüstung
• ERA-Eisenbahnrecht — einschließlich Verordnung (EU) 2016/796 (ERA-Agentur), Richtlinie 2016/797 (Interoperabilität) und Richtlinie 2016/798 (Eisenbahnsicherheit)
• Maschinenverordnung (EU) 2023/1230 — relevant für KI in automatisierten Hafengeräten, Industriefahrzeugen und Baumaschinen, die in Transportinfrastrukturkontexten eingesetzt werden

Ein KI-System ist eine Sicherheitskomponente eines Transportprodukts, wenn sein Ausfall oder seine Fehlfunktion die Gesundheit oder Sicherheit von Personen gefährden könnte. Bei Straßenfahrzeugen umfasst dies autonome Notbremssysteme, Spurhalte-KI, adaptive Geschwindigkeitsregelung ab SAE L2 und alle automatisierten Fahrsysteme der Level L3 bis L5. In der Luftfahrt umfasst dies KI in Flugmanagementsystemen, Autopilot-Komponenten und Bodennäherungswarnsystemen. Bei Eisenbahnen umfasst dies KI in der automatischen Zugsteuerung, KI-gestützter Signalgebung und autonomem Rangieren.

Die Einstufung nach Art. 6(1) ist kategorisch. Sie erfordert nicht, dass das KI-System unabhängig davon eine signifikante Schadenswahrscheinlichkeit nachweist — die Sicherheitskomponentenbezeichnung ist ausreichend. Das bedeutet, dass Anbieter solcher Systeme die Anforderungen von Kapitel III, Abschnitt 2 (Art. 9–15) erfüllen müssen, die Risikomanagement, Datenverwaltung, technische Dokumentation, automatische Protokollierung, Transparenz, menschliche Aufsicht sowie Genauigkeit und Robustheit abdecken.

Annex III, Punkt 2 — Management kritischer Infrastrukturen

Getrennt vom Sicherheitskomponenten-Pfad führt Annex III, Punkt 2 ausdrücklich als hochriskant auf: KI-Systeme, die als Sicherheitskomponenten im Management und Betrieb kritischer Infrastrukturen eingesetzt werden sollen, insbesondere:

• Kritische Straßenverkehrsinfrastruktur
• Kritische Wasserverkehrsinfrastruktur
• Kritische Stromversorgungsnetz-Komponenten (als kritische Infrastruktur mit transportäquivalenten Risikoprofilen)

KI-Systeme, die in diese Kategorie fallen, umfassen: Autobahn-Verkehrsmanagementsysteme mit KI für dynamische Geschwindigkeitssteuerung und Vorfallserkennung, KI-basierte Systeme zur Stabilisierung und Lastverteilung intelligenter Stromnetze, bei denen ein Netzausfall den Transportbetrieb beeinträchtigen würde, sowie KI-Systeme, die Hafeninfrastruktur auf der Ebene wesentlicher Dienste betreiben.

Der Unterschied zwischen Punkt 2 und dem Annex-I-Pfad besteht darin, dass Annex III, Punkt 2 für Betreiber von Infrastrukturen gilt und nicht nur für Produkthersteller. Eine Behörde oder ein privater Konzessionsnehmer, der ein KI-gestütztes Verkehrsmanagementzentrum betreibt, unterliegt den Pflichten nach Punkt 2 als Betreiber oder — sofern das KI-System selbst entwickelt wurde — als Anbieter.

Doppelte Einstufung

Wenn ein KI-System sowohl eine Sicherheitskomponente eines NLF-regulierten Produkts ist als auch im Management kritischer Infrastrukturen eingesetzt wird (z. B. ein KI-System, das in eine intelligente Autobahnplattform integriert ist und zugleich Schnittstellen zu Fahrzeugsystemen hat), greifen beide Pfade. Die strengeren Pflichten sind maßgeblich.

Anbieter vs. Betreiber im Transportkontext — OEM vs. Infrastrukturbetreiber

Die Zuordnung von Pflichten zwischen Anbietern (Art. 16) und Betreibern (Art. 26) ist im Transport besonders komplex, wo die Lieferkette zwischen KI-Entwickler, Systemintegrator, OEM, Infrastrukturbetreiber und Endnutzer-Flotte mehrere Rechtssubjekte umfassen kann, die jeweils eigenständige AI Act-Pflichten tragen.

Fahrzeug-OEMs als Anbieter

Ein OEM, der ein KI-Fahrsystem — ob intern entwickelt oder von einem Tier-1- oder Tier-2-Lieferanten bezogen — integriert und das Fahrzeug unter seinem eigenen Markennamen auf dem EU-Markt bereitstellt, ist der Anbieter des KI-Systems nach Art. 16. Dies gilt auch dann, wenn die KI-Technologie ursprünglich von einem Dritten entwickelt wurde, sofern der OEM nicht lediglich ein unverändertes System unter der Marke des Drittanbieters weiterverkauft hat. Anbieterpflichten umfassen:

• Einrichtung eines Qualitätsmanagementsystems nach Art. 17
• Erstellung und Pflege der technischen Dokumentation nach Art. 11 und Annex IV, die den bestimmungsgemäßen Verwendungszweck, das Design, die Trainingsdaten, die Validierungsergebnisse und den Plan zur Überwachung nach dem Inverkehrbringen des KI-Systems abdeckt
• Durchführung oder Beauftragung der Konformitätsbewertung — die für Sicherheitskomponenten von Fahrzeugen mit dem Typgenehmigungsverfahren nach GSR 2019/2144 koordiniert werden muss
• Registrierung des KI-Systems in der EU-Datenbank für hochriskante KI-Systeme nach Art. 49 vor der Marktplatzierung
• Bereitstellung von Gebrauchsanweisungen für nachgelagerte Betreiber (Flottenbetreiber, Mietwagenunternehmen), die eine konforme Nutzung ermöglichen

Flottenbetreiber und Konzessionsinhaber als Betreiber

Ein Unternehmen, das eine Flotte autonomer Fahrzeuge betreibt, eine Kommunalbehörde, die ein KI-Verkehrsmanagementsystem einsetzt, oder ein Eisenbahninfrastrukturmanager, der KI-gestützte Wartungstools verwendet, ist ein Betreiber nach Art. 26. Betreiberpflichten umfassen:

• Nutzung des KI-Systems im Rahmen der Gebrauchsanweisungen des Anbieters — jede betriebliche Nutzung außerhalb dieses Rahmens kann den Betreiber zum Anbieter umstufen und den vollständigen Anbieterpflichtensatz auslösen
• Umsetzung von Maßnahmen zur menschlichen Aufsicht, wie vom Anbieter festgelegt und dem Betriebskontext angemessen
• Aufbewahrung der vom KI-System erzeugten Betriebsprotokolle für mindestens sechs Monate oder länger, wenn anwendbare Sektorrechtsvorschriften (NIS2, nationales Transportsicherheitsrecht) eine längere Aufbewahrung vorschreiben
• Unverzügliche Meldung von Fehlfunktionen oder schwerwiegenden Vorfällen an den Anbieter und an nationale Behörden nach Art. 73, sofern die Sicherheit oder Grundrechte betroffen sind
• Durchführung von Grundrechte-Folgenabschätzungen (FRIA) nach Art. 27, wenn das KI-System von einer Behörde oder in Kontexten eingesetzt wird, die Einzelpersonen in großem Maßstab betreffen

Wechselwirkung mit Sektorvorschriften — EASA, ERA und Typgenehmigung

Straßenfahrzeuge — GSR 2019/2144 und Typgenehmigung

Die Allgemeine Sicherheitsverordnung (EU) 2019/2144 schreibt die Einbeziehung spezifischer ADAS- und automatisierter Fahrfunktionen in neue Fahrzeugtypen vor und legt technische Anforderungen an deren Leistungsfähigkeit fest. Die Fahrzeugtypgenehmigung — die von nationalen Typgenehmigungsbehörden (z. B. KBA in Deutschland, DREAL in Frankreich, Rijksdienst voor het Wegverkeer in den Niederlanden) durchgeführt wird — ist der primäre Marktzugangsmechanismus für Straßenfahrzeuge.

Der EU AI Act verdrängt die Typgenehmigung nicht. Art. 8(1) des AI Act legt fest, dass eine verfahrensmäßige Angleichung möglich ist, wenn sektorspezifische Rechtsvorschriften gleichwertige oder strengere Anforderungen stellen, die AI Act-Pflichten jedoch bestehen bleiben. In der Praxis muss die Konformitätsbewertung eines KI-Fahrsystems sowohl die technischen Anforderungen der GSR (die im Rahmen der Typgenehmigung bewertet werden) als auch die Anforderungen des AI Act (technische Dokumentation, Datenverwaltung, Protokollierung, menschliche Aufsicht, Überwachung nach dem Inverkehrbringen) abdecken. OEMs sollten eine integrierte Bewertung planen, die beide Rahmenwerke abdeckt, um doppelten Aufwand und potenzielle Lücken zu vermeiden.

Luftfahrt — EASA und die KI-Roadmap

Die EASA übt die Zertifizierungsbefugnis über Luftfahrzeuge, Triebwerke und Teile nach Verordnung (EU) 2018/1139 aus. Die KI-Roadmap der EASA (in aufeinanderfolgenden Ausgaben ab 2020 veröffentlicht) behandelt die KI-Vertrauenswürdigkeit für bordseitige KI-Systeme und ist die primäre Zertifizierungsreferenz für KI in flugkritischen Anwendungen.

Der EU AI Act gilt für bodengestützte Luftfahrt-KI (Verkehrsmanagement, Wartungsdiagnostik, Kabinenmanagement-Systeme), die außerhalb des EASA-Lufttüchtigkeitsbereichs liegt. Für bordseitige KI-Systeme, die von der EASA zertifiziert werden, ist eine Angleichung nach Art. 8(1) möglich, aber die Überschneidung zwischen EASA-Lufttüchtigkeitsanforderungen und AI Act-Pflichten (insbesondere zu Protokollierung und menschlicher Aufsicht) muss systemspezifisch analysiert werden. Das EASA-Konzept der „KI-Assurance-Level" lässt sich nicht direkt auf die Hochrisiko-Einstufung oder die Konformitätsbewertungsanforderungen des EU AI Act übertragen.

Eisenbahn — ERA und Sicherheitsmanagementsysteme

Die ERA (Europäische Eisenbahnagentur) überwacht die Eisenbahn-Interoperabilität und den gemeinsamen Sicherheitsrahmen nach den Richtlinien 2016/797 und 2016/798. Eisenbahnunternehmen und Infrastrukturmanager sind verpflichtet, ein Sicherheitsmanagementsystem (SMS) zu unterhalten, das Risikobewertung, Unfalluntersuchung und kontinuierliche Verbesserung abdeckt.

Die Risikomanagementanforderungen des EU AI Act nach Art. 9 entsprechen weitgehend den SMS-Anforderungen der ERA. Organisationen mit einem ausgereiften SMS sind gut positioniert, um die AI Act-Risikomanagementdokumentation in das bestehende Rahmenwerk zu integrieren. ERA und die Europäische Kommission haben eine Präferenz für integrierte Compliance-Ansätze signalisiert, die Doppelarbeit zwischen SMS und AI Act-Pflichten vermeiden. KI-Systeme, die im automatischen Zugbetrieb, in ETCS-Komponenten (Europäisches Zugsicherungssystem) mit KI-Anteil oder in der prädiktiven Wartung eingesetzt werden, die sicherheitskritische Entscheidungen beeinflusst, sind hochriskant nach Annex I (Sicherheitskomponente von Schienenfahrzeugen oder -infrastruktur).

Vollzug und Zertifizierungsbehörden

Die Transport-KI-Compliance umfasst mehrere Vollzugsbehörden mit teilweise überschneidender Zuständigkeit, je nach Funktion des KI-Systems und dem Produkt, in das es eingebettet ist.

Die EASA ist die Zertifizierungsbehörde für KI in Luftfahrzeugen und Luftfahrtprodukten. Sie kann Untersuchungen zu KI-Systemausfällen einleiten, die die Lufttüchtigkeit berühren, und ihre Entscheidungen wirken sich auf den Marktzugang in der gesamten EU und bilateralen Partnerrechtsgebieten aus.

Die ERA überwacht den gemeinsamen Sicherheitsrahmen für Eisenbahnen. Eisenbahnsicherheitsbescheinigungen und Betriebsgenehmigungen sind an die SMS-Konformität geknüpft, die zunehmend mit der AI Act-Compliance für KI-gestützte Eisenbahnsysteme zusammenwächst.

Nationale Typgenehmigungsbehörden — darunter KBA (Deutschland), von ANFIA delegierte Stellen (Italien) und Rijksdienst voor het Wegverkeer (Niederlande) — erteilen und können Typgenehmigungen für Straßenfahrzeuge entziehen. Nichtkonformität mit AI Act-Anforderungen für KI-Sicherheitskomponenten kann einen Grund für die Aussetzung der Typgenehmigung oder einen Rückruf darstellen.

Nationale NIS2-Behörden — von jedem Mitgliedstaat benannt, häufig eine nationale Cybersicherheitsbehörde wie BSI (Deutschland), ANSSI (Frankreich) oder NCSC-NL (Niederlande) — vollziehen NIS2-Pflichten für Transportbetreiber wesentlicher Dienste. NIS2-Vollzug kann zu verbindlichen Anordnungen, Bußgeldern und in schwerwiegenden Fällen zur Aussetzung des Betriebs führen.

Nationale KI-Marktüberwachungsbehörden, die nach Art. 70 des EU AI Act benannt werden, haben allgemeine Marktüberwachungsbefugnisse mit Koordinierungsmechanismen für sektorspezifische Behörden, um Zuständigkeitskonflikte zu vermeiden.

Compliance-Prioritäten für Transportbetreiber und Anbieter

Schritt 1: KI-Systeminventar und Einstufung

Führen Sie ein strukturiertes Inventar aller KI-Systeme durch, die im Transport-Produkt- oder Betriebsportfolio entwickelt oder eingesetzt werden. Bestimmen Sie für jedes System, ob es eine Sicherheitskomponente eines NLF-regulierten Produkts (Pfad nach Art. 6(1)), eine KI für das Management kritischer Infrastrukturen (Annex III, Punkt 2) oder beides ist. Dokumentieren Sie die Einstufungsbegründung schriftlich. Systeme, die nicht definitiv aus der Hochrisiko-Einstufung ausgeschlossen werden können, sollten bis zur abschließenden rechtlichen Analyse als hochriskant behandelt werden.

Schritt 2: Planung des Konformitätsbewertungswegs

Identifizieren Sie für KI-Systeme, die Sicherheitskomponenten von Fahrzeugen, Luftfahrzeugen oder Schienenfahrzeugen sind, das anwendbare sektorale Zertifizierungsverfahren und ordnen Sie es den Konformitätsbewertungsanforderungen des AI Act zu. Stellen Sie fest, ob eine notifizierte Stelle erforderlich ist (Art. 43(3)) oder ob eine Selbstbewertung mit technischem Audit durch Dritte ausreicht. Koordinieren Sie den Zeitplan der AI Act-Konformitätsbewertung mit dem Typgenehmierungs- oder Zertifizierungsprogramm, um Verzögerungen beim Marktzugang zu vermeiden.

Schritt 3: Technische Dokumentation und Datenverwaltung

Erstellen Sie technische Dokumentation nach Annex IV für jedes hochriskante KI-System. Für Transport-KI muss diese umfassen: den bestimmungsgemäßen Verwendungszweck mit einer Präzision, die sowohl die AI Act- als auch die sektorale Regulierungsklassifikation unterstützt; die Herkunft der Trainingsdaten, einschließlich aller realen Fahr-, Betriebs- oder Sensordaten; Beschreibungen der Simulationsumgebung für KI-Systeme, die durch virtuelle Tests validiert wurden; sowie Pläne zur Überwachung nach dem Inverkehrbringen, die mit sektorspezifischen Berichtspflichten abgestimmt sind.

Schritt 4: NIS2-Integration für Betreiber kritischer Infrastrukturen

Transportbetreiber wesentlicher Dienste müssen die Cybersicherheitsanforderungen des AI Act nach Art. 15 mit den Cybersicherheits-Risikomanagementpflichten nach NIS2 integrieren. Etablieren Sie einen einheitlichen Sicherheitsrisikobewertungsprozess, der beide Rahmenwerke abdeckt. Stellen Sie sicher, dass KI-Softwarelieferanten — einschließlich KI-Modellentwickler und Datenanbieter — Lieferketten-Sicherheitsanforderungen unterliegen, die mit NIS2 Art. 21(2)(d) und AI Act Art. 25 (Pflichten für Drittanbieter-Tools) vereinbar sind.

Schritt 5: Menschliche Aufsicht in Betriebskontexten

Gestalten Sie Mechanismen zur menschlichen Aufsicht nach Art. 14, die in Transportumgebungen operativ praktikabel sind. Legen Sie für autonome Fahrsysteme die Bedingungen fest, unter denen ein Fahrer die Kontrolle übernehmen können muss (L3) oder ein Fernbediener eingreifen können muss (L4). Definieren Sie für KI in der Flugsicherung die Punkte im Arbeitsablauf, an denen ein Lotse KI-generierte Anweisungen prüfen und genehmigen muss. Legen Sie für Eisenbahn-Wartungs-KI Eskalationsprotokolle fest, wenn das System sicherheitskritische Anomalien meldet. Aufsichtsmechanismen müssen in der technischen Dokumentation dokumentiert und in den Betreibern bereitgestellten Gebrauchsanweisungen widergespiegelt werden.

Schritt 6: Überwachung nach dem Inverkehrbringen und Meldung von Vorfällen

Etablieren Sie Überwachungssysteme nach dem Inverkehrbringen, die sowohl die Anforderungen von AI Act Art. 72 als auch sektorspezifische Sicherheitsberichtspflichten erfüllen (ERA-Unfallmeldung, EASA-Vorkommnismeldung nach Verordnung (EU) 376/2014, NIS2-Vorfallsmeldung). Schwerwiegende Vorfälle mit hochriskanten KI-Systemen müssen der nationalen KI-Marktüberwachungsbehörde nach Art. 73 innerhalb von 15 Arbeitstagen nach Bekanntwerden gemeldet werden. Dieser Zeitraum muss mit der 24-Stunden-Erstmeldepflicht nach NIS2 für erhebliche Cybersicherheitsvorfälle abgestimmt werden, die dasselbe Ereignis abdecken kann, wenn die KI-Fehlfunktion auf einen Cybersicherheitsvorfall zurückzuführen ist.