Der überlesene Absatz – ODER: Wann der AI Act das Fahrzeug erreicht

… und warum das bestehende Cybersecurity-Management-System die geforderte AI-Security (noch) nicht trägt.

Eine Deadline, die in einigen Roadmaps falsch Verortet wurde

In zahlreichen Compliance-Roadmaps der Automobilindustrie ist der 2. August 2026 als harte Frist vermerkt: ab diesem Tag, so die verbreitete Lesart, greife der EU AI Act mit vollem Pflichtenkatalog auf Fahrzeuge mit KI-gestützten Fahrfunktionen. Diese zeitliche Verortung ist im Kern falsch. Und sie ist zudem teuer, weil sie Ressourcen auf eine Frist lenkt, die für das Fahrzeug so nicht existiert, während die regulatorische Entwicklung an einer ganz anderen Stelle stattfindet.

Der Grund liegt in einem Absatz, der in der Diskussion regelmäßig übergangen wird: Artikel 2 Absatz 2 in Verbindung mit der Zweiteilung von Anhang I des AI Act. In der Homologations-Planung ist der AI Act danach keine Direktnorm mit Stichtag 2026. Er ist für das Fahrzeug ein Rahmen, dessen materielle Anforderungen erst über das sektorale Typgenehmigungsrecht greifen, zeitversetzt und in dessen Logik.

Aus diesem ersten Befund folgt ein zweiter, der in den Roadmaps noch seltener auftaucht: Selbst wenn die Anforderungen des AI Act über das Typgenehmigungsrecht ankommen, ist damit nicht gesagt, dass der vorhandene Cybersecurity-Nachweisapparat des Fahrzeugs sie inhaltlich trägt. Die erste Frage ist eine des Wann und über welches Regime; die zweite eine des Womit. Beide werden hier getrennt beantwortet; denn gerade ihre Vermengung erzeugt eben jene teuren Planungsfehler, auf die die OEMs gerade in den jetzigen Zeiten gern verzichten würden.

Der Mythos und seine Quelle

Die Argumentationskette des Missverständnisses ist auf den ersten Blick schlüssig: KI-Systeme für das automatisierte und autonome Fahren sind Hochrisiko-Systeme; Hochrisiko-Systeme unterliegen dem vollen Anforderungskatalog des AI Act (Art. 8 bis 15); also gilt dieser Katalog ab Anwendbarkeit des AI Act für das Fahrzeug.

Der Fehler steckt im mittleren Glied: Der AI Act kennt zwei Wege in die Hochrisiko-Klassifizierung, und sie führen zu unterschiedlichen Rechtsfolgen:

• Anhang III erfasst eigenständige Hochrisiko-Anwendungen (etwa biometrische Identifizierung oder KI im Beschäftigungskontext). Für diese gilt der materielle Pflichtenkatalog unmittelbar.
• Anhang I erfasst KI als Sicherheitskomponente oder Produkt innerhalb bestehender Produktsicherheits- und Typgenehmigungsregime. Hier ist die Rechtsfolge differenzierter, und in diese Kategorie fällt das Fahrzeug.

Die Vermengung beider Anhänge unter dem pauschalen Etikett „Hochrisiko” erzeugt den Mythos der harten 2026-Fahrzeug-Deadline.

Die Korrektur: der Abschnitt-B-Mechanismus

Die Hochrisiko-Einordnung von KI-Fahrfunktionen ergibt sich aus Art. 6 Abs. 1 AI Act in Verbindung mit Anhang I. Art. 6 Abs. 1 verlangt zwei kumulative Bedingungen: Das KI-System ist Sicherheitskomponente eines Produkts (oder selbst ein Produkt), das unter eine in Anhang I gelistete Harmonisierungsvorschrift fällt (lit. a), und dieses Produkt unterliegt vor dem Inverkehrbringen einer Drittkonformitätsbewertung nach jener Vorschrift (lit. b). Für ein typgenehmigungspflichtiges Fahrzeug ist beides erfüllt.

Die innere Struktur von Anhang I ist zweigeteilt:

• Abschnitt A listet die Rechtsakte des „New Legislative Framework” (Maschinen, Spielzeug, Medizinprodukte und weitere).
• Abschnitt B listet acht sektorale Sonderregime mit eigenem, etabliertem Typgenehmigungs- bzw. Zertifizierungssystem, darunter die Luftfahrt, die Bahn, die Schifffahrt und das Kraftfahrzeugrecht.

Die für das Fahrzeug maßgeblichen Rechtsakte stehen in Abschnitt B: die Typgenehmigungs-Rahmenverordnung VO (EU) 2018/858 (Anhang I, Eintrag 18) und die „General Safety Regulation” VO (EU) 2019/2144 (Anhang I, Eintrag 19).

Diese Verortung in Abschnitt B bestimmt die Rechtsfolge. Art. 2 Abs. 2 AI Act ordnet für Hochrisiko-KI, die zu Produkten unter den Abschnitt-B-Rechtsakten gehört, ausdrücklich an:

„… only Article 6(1), Articles 102 to 109 and Article 112 apply.”

Für das Fahrzeug gilt damit nicht der materielle Hochrisiko-Katalog aus Kapitel III Abschnitt 2 (Art. 8 bis 15) unmittelbar. Es gibt keinen direkten Durchgriff einer „AI-Act-Konformitätsbewertung” über eine notifizierte Stelle auf das typgenehmigte Fahrzeug, und die Anforderungen an Risikomanagement, Daten-Governance, Transparenz, menschliche Aufsicht oder Robustheit greifen nicht als unmittelbar anwendbares Recht. Anwendbar sind allein die Klassifizierungsregel (Art. 6 Abs. 1), die Änderungsbefehle an das Sektorrecht (Art. 102 bis 109) und eine Schlussbestimmung (Art. 112). Alle übrigen Regelungen des AI Act, einschließlich des materiellen Pflichtenkatalogs und der horizontalen Verfahrensregeln, sind durch die abschließende Aufzählung des Art. 2 Abs. 2 für das Fahrzeug ausgenommen.

„Aber nicht nichts”: Integration über das Typgenehmigungsrecht

Daraus zu schließen, der AI Act sei für das Fahrzeug irrelevant, ginge allerdings ebenso fehl. Der Verweis auf die Art. 102 bis 109 ist nicht nur deklaratorisch, sondern der Wirkmechanismus selbst: Diese Artikel ändern die Abschnitt-B-Rechtsakte und verankern die AI-Act-Anforderungen dort, wo sie das Fahrzeug erreichen, im Typgenehmigungsrecht.

Konkret:

• Art. 107 AI Act fügt dem Art. 5 der VO (EU) 2018/858 einen Absatz hinzu, wonach bei künftigen delegierten Rechtsakten zu KI-Sicherheitskomponenten die Anforderungen des Kapitels III Abschnitt 2 des AI Act zu berücksichtigen sind.
• Art. 109 AI Act fügt dem Art. 11 der VO (EU) 2019/2144 eine parallele Bestimmung für Durchführungsrechtsakte hinzu.

Die materiellen Hochrisiko-Anforderungen gelangen also nicht per Stichtag in das Fahrzeug, sondern dann und in dem Maße, wie die Kommission sie über delegierte bzw. Durchführungsrechtsakte in die typgenehmigungsrechtliche Systematik überführt. Selbst dort gelten sie zunächst als „zu berücksichtigender” Maßstab, nicht als unverändert durchgereichter Katalog. Diese Lesart deckt sich mit der Anwendungsregel des Art. 113: Während der AI Act allgemein ab dem 2. August 2026 anwendbar ist, gelten Art. 6 Abs. 1 und die zugehörigen Pflichten erst ab dem 2. August 2027.

Der für die Homologation relevante Stichtag ist damit nicht 2026 und genaugenommen auch nicht 2027, sondern der jeweils noch offene Zeitpunkt der sektoralen Rechtsetzung.

Vorausschau I: die offene Novellierung

Damit verschiebt sich die regulatorische Beobachtungsaufgabe: Die Variable ist nicht länger der AI Act-Text; es ist die Frage, wann und wie die Kommission die delegierten und Durchführungsrechtsakte unter VO 2018/858 und VO 2019/2144 ausgestaltet, die die Kapitel-III-Anforderungen in das Fahrzeugrecht tragen.

Belastbare Termine hierfür liegen derzeit nicht vor; jede Datierung wäre Spekulation. Festhalten lässt sich jedoch die Mechanik: Die Integration erfolgt im etablierten Verfahren der Fahrzeug-Rechtsetzung, mit dessen Konsultations-, Beteiligungs- und Übergangslogik, nicht im Tempo des horizontalen AI-Act-Zeitplans. Für die Planung folgt daraus, die Anforderungen aus Art. 8 bis 15 (Risikomanagement, Daten und Daten-Governance, technische Dokumentation, Protokollierung, Transparenz, menschliche Aufsicht, Genauigkeit/Robustheit/Cybersecurity) bereits jetzt als kommende Typgenehmigungsmaßstäbe zu behandeln, ohne sich an eine vermeintliche 2026-Frist zu binden.

Zwei Fragen, nicht eine

Die bisherige Korrektur betrifft die institutionelle Ebene: über welches Regime und ab wann die Anforderungen des AI Act das Fahrzeug erreichen. Mit ihr ist die zweite, schwierigere Frage erst gestellt, jedoch noch nicht beantwortet: Trägt der Inhalt des heutigen Cybersecurity-Nachweisapparats die Schutzziele, die der AI Act für die KI-Sicherheitskomponente verlangt, sobald sie über die Novellierung ankommen?

Diese Trennung ist mehr als akademisch. Die in der Praxis gängige Leitfrage, ob sich die AI-Security über die Automotive Cybersecurity (UN R155 und die VO 2018/858) abdecken lässt oder ob es eine stärker IT-bezogene Betrachtung braucht, suggeriert eine Wahl zwischen zwei Polen. Tatsächlich laufen hier zwei Ebenen auseinander, die getrennt zu beantworten sind:

1. Institutionell: durch welches Regime wird die AI-Security des Fahrzeugs verwaltet? Die Antwort ist sektoral, nicht horizontal.
2. Substanziell: trägt der heutige Inhalt dieses Regimes die KI-spezifischen Schutzziele? Die Antwort ist nein … zumindest nicht ohne Ergänzung.

Die Vermengung beider Ebenen führt zu zwei Fehlern: zur falschen Beruhigung („es gibt ja die UN R155”) oder zum falschen Reflex („dann braucht es einen zweiten, IT-getriebenen Nachweisstrang”). Beides verfehlt den Kernpunkt der Diskussion. Die folgenden Abschnitte beantworten die institutionelle Ebene knapp, da sie bereits entschieden ist, und widmen sich dann der substanziellen, die die eigentliche Vorbereitungsaufgabe enthält.

Die institutionelle Antwort: der Gesetzgeber normiert sektoral

Dass die AI-Security des Fahrzeugs im Typgenehmigungsregime und nicht in einem parallelen horizontalen IT-Regime verwaltet wird, ist eine gesetzgeberische Entscheidung und keine offene Auslegungsfrage mehr; sie wird an zwei Stellen deutlich sichtbar:

Erstens der Cyber Resilience Act (VO (EU) 2024/2847): Er nimmt in Art. 2 Abs. 2 Produkte, für die die VO (EU) 2019/2144 gilt, ausdrücklich aus seinem Anwendungsbereich aus. Die Begründung (EG 27/28) ist die eines lex specialis: Das Kfz-Typgenehmigungsrecht leistet über R155 bereits eine lebenszyklusweite, zertifizierte CSMS-Cybersecurity; das horizontale IT-Produkt-Regime tritt dort zurück, wo das Sektorrecht mindestens dasselbe Schutzniveau erreicht. Ein paralleler, horizontaler IT-Sicherheitsnachweis neben der Typgenehmigung ist damit gerade nicht der vorgesehene Weg.

Zweitens der AI Act selbst: Er greift, wie gezeigt, nicht horizontal auf das Fahrzeug durch, sondern ändert über Art. 102 bis 109 die sektoralen Rechtsakte. Die begleitenden Erwägungsgründe bestätigen die Stoßrichtung: Die technischen und regulatorischen Sektor-Spezifika und die bestehende Konformitätsbewertung sind zu respektieren (EG 49), eine Doppelbewertung ist zu vermeiden (EG 124), und KI-Tests sollen in die bestehenden Verfahren integriert werden (EG 64).

Die regulatorische Philosophie ist damit eindeutig: Das Fahrzeug ist kein generisches IT-Produkt, sondern ein sicherheitskritisches System; seine AI-Security wird innerhalb der Typgenehmigung verwaltet, nicht daneben. Ein eigenständiger „IT-Zulassungsstrang” neben der Homologation ist nicht bloß unpraktisch; er ist rechtlich versperrt. So weit die beruhigende Hälfte des Befunds. Die andere Hälfte betrifft den Inhalt.

Die Lücke: was UN R155 und ISO/SAE 21434 nicht erfassen

KI-Systeme werden über eine eigene Klasse von Angriffen verwundbar, die nicht an Code-Fehlern oder Netzwerk-Fehlkonfigurationen hängen, sondern an der statistischen, datengetriebenen Natur des Modells. Die einschlägige Taxonomie (NIST AI 100-2; ENISA „Securing Machine Learning Algorithms”) benennt im Kern drei Familien:

• Täuschende Eingaben (adversarial examples / model evasion): minimal, oft unmerklich gestörte Eingaben, etwa ein präparierter Aufkleber auf einem Stoppschild, die die Entscheidungsgrenze des Modells verschieben. Netz und Code bleiben dabei unversehrt.
• Verfälschung (data poisoning / model poisoning, Backdoors): Manipulation der Trainingsdaten oder vortrainierter Komponenten, lange vor Kompilierung oder OTA-Update.
• Vertraulichkeitsangriffe (model extraction, membership inference): das statistische „Stehlen” eines trainierten Modells oder das Rückschließen auf Trainingsdaten über bloßen Abfragezugriff.

Das Bedrohungsmodell der UN R155 adressiert davon nichts explizit. R155 definiert Cybersecurity als Schutz der „elektrischen oder elektronischen Komponenten”; seine Bedrohungsliste (Anhang 5) ist auf E/E-Architektur, Kommunikationswege und Software ausgerichtet. Wo R155 verwandte Begriffe führt, meint es Klassisches:

Auch die Engineering-Systematik der ISO/SAE 21434 (samt der ihr eigenen TARA) setzt methodisch an der E/E-Architektur über den Lebenszyklus an, nicht am trainierten Modell, seiner Datenversorgung oder seiner statistischen Robustheit. Die Trennlinie verläuft damit präzise zwischen der Infrastruktur um das Modell und der statistischen Integrität des Modells selbst. Das Cybersecurity-Management-System sichert die erste; die zweite adressiert es nicht.

Ein naheliegender Einwand lautet, die Kombination aus ISO 26262 (funktionale Sicherheit) und ISO 21448 (SOTIF) decke das KI-Verhalten doch bereits ab. Er trägt nicht, und die Stelle, an der er bricht, ist aufschlussreich. SOTIF adressiert primär nicht-böswillige Funktions- und Leistungsgrenzen: das verblasste Schild, die Blendung, den Regen, also die Umwelt-Verwundbarkeit des Sensors. Den adversarialen Aufkleber, die mathematisch konstruierte Täuschung, deckt es nicht ab; sie fällt in die Security-Domäne. Die Lücke sitzt damit exakt zwischen der „natürlichen Grenze” einer Funktion (SOTIF) und der „böswilligen Ausnutzung genau dieser Grenze” (bislang ungedeckt).

Was Art. 15 verlangt: die Lücke ist die Anforderung

Diese Lücke ist nicht hypothetisch, sie ist bereits kodifiziert. Art. 15 AI Act verlangt für Hochrisiko-Systeme ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit. Art. 15 Abs. 5 wird konkret und übernimmt die Adversarial-ML-Taxonomie nahezu wörtlich ins Recht: Die technischen Lösungen müssen, „where appropriate”, gegen die Manipulation der Trainingsdaten (data poisoning), die Manipulation vortrainierter Komponenten (model poisoning), täuschende Eingaben (adversarial examples / model evasion), Vertraulichkeitsangriffe und Modellfehler wirken.

Damit schließt sich der Kreis: Was Art. 15 Abs. 5 verlangt, ist genau das, was der heutige ACS-Bestand nicht abdeckt. Sobald die Cybersecurity-Dimension des Art. 15 über die sektorale Novellierung in das Typgenehmigungsrecht einfließt (über den eingangs beschriebenen Mechanismus: Art. 107 → Art. 5 VO 2018/858; Art. 109 → Art. 11 VO 2019/2144), entsteht ein inhaltlicher Anforderungsüberhang, den R155-CSMS und ISO/SAE 21434 in ihrer heutigen Form nicht bedienen. Der naheliegende Schluss, der vorhandene Nachweisapparat trage die Art.-15-Anforderungen „in weiten Teilen” bereits mit, ist deshalb zu optimistisch. Der Evidenz-Crosswalk zwischen CSMS-/21434-Artefakten und den Art.-15-Dimensionen ist kein Umetikettieren vorhandener Nachweise, sondern eine Gap-Analyse, die diese Deckungslücke offenlegt.

Zwei Denkmodelle, beide allein untauglich

Aus der Spannung zwischen institutioneller Zuständigkeit und substanzieller Lücke ergeben sich zwei naheliegende, aber je für sich unzureichende Denkmodelle.

Modell A: das ACS-Regime erweitern, also die AI-Security in CSMS und TARA integrieren. Dafür spricht der Gesetzgeberwille: sektorales Routing, CRA-Ausschluss, eine Governance-Klammer, eine Konformitätsbewertung, die etablierte Lebenszyklus-, Audit- und Feld-Monitoring-Mechanik, keine Doppeldokumentation. Dagegen spricht, dass die TARA-Methodik (ausgelegt auf logische Fehler, offene Ports, Netzangriffe) die KI-Schutzziele technisch nicht von selbst trägt: Klassische E/E-Cybersecurity-Kompetenz reicht für adversariales Training, Privacy-Auditing oder die Attestierung der Daten-Lieferkette nicht aus. Die Gefahr besteht darin, die Lücke unter dem vertrauten Label „CSMS” zu übersehen.

Modell B: eine separate IT-/AI-Security-Betrachtung als eigenständiger Strang. Dafür spricht, dass es die fehlende fachliche Tiefe (Adversarial Robustness, Dataset-Integrität, MLSecOps) sauber einbringt und die KI-Spezifika sichtbar macht. Dagegen spricht alles, was die institutionelle Ebene bereits geklärt hat: Als paralleler Nachweisstrang ist es rechtlich versperrt (CRA-Ausschluss, EG 124) und zerreißt die einheitliche sicherheitskritische Betrachtung des Fahrzeugs.

Die tragfähige Antwort liegt nicht zwischen den Modellen, sondern setzt sie übereinander: das sektorale Regime als Container, eine eigenständige AI-Security-Disziplin als Inhalt. Die Governance-Klammer bleibt sektoral: CSMS, TARA und ISO 21434 als integrierende Prozess- und Nachweisstruktur, der vom Gesetzgeber gewollte und einzig zulässige Weg in die Typgenehmigung. In diese Klammer wird die AI-Security-Substanz hineingezogen, nicht danebengestellt: Der TARA-Scope wird um KI-Assets und einen KI-Bedrohungskatalog erweitert, und die fehlenden Arbeitsstränge kommen hinzu: Daten-Governance und Dataset-Integrität, Robustheits- und Adversarial-Testing, das Prüfen der KI-Lieferkette einschließlich vortrainierter Komponenten, modellbezogenes Red-Teaming sowie ein Feld-Monitoring, das auch das Verhalten des Modells und Out-of-Distribution-Fälle erfasst.

Entscheidend ist dabei, dass die Lücke nicht primär eine Dokumentations-, sondern eine Fähigkeitslücke ist. Ein klassischer E/E-Penetrationstester deckt adversariale und Vertraulichkeitsangriffe nicht ab. Ohne spezialisierte AI-Security-Kompetenz (aufgebaut oder eingekauft) bleibt die KI-Komponente trotz formal grünem CSMS exponiert.

Das fehlende PuzzleStück wird bereits normiert

Diese Disziplin muss nicht erst erfunden werden; sie entsteht bereits innerhalb des Automotive-Ökosystems, wie sich an der Normung ablesen lässt. Deren Richtung bestätigt den Befund: keine Ablösung der etablierten Systematik, sondern ihre Erweiterung.

Tragend ist hier zweierlei. ISO/PAS 8800 (2024) zur Sicherheit künstlicher Intelligenz in Straßenfahrzeugen adressiert KI-basierte Fahrfunktionen als dedizierter Automotive-Standard und erweitert die etablierten ISO 26262 und ISO 21448 (SOTIF); ihre Kerninnovation ist, die Trainingsdaten als primäres, eigenständig zu verifizierendes Engineering-Artefakt zu behandeln (ein „Dataset V-Model”). Die KI-spezifische Bedrohungsseite (Datenvergiftung, adversariale Eingaben, Modell-Extraktion) adressiert der in Entstehung befindliche ISO/IEC 27090. Beide docken an die vorhandene Systematik an, statt sie zu ersetzen.

Über diese beiden hinaus zeichnet sich ein breiterer Andockrahmen ab, der hier als Beobachtungslinie und nicht als gesicherter Befund genannt sei: horizontale ISO/IEC-AI-Normen, die über den Automotive-Stack gelegt werden (ISO/IEC 42001 für KI-Management und ISO/IEC 23894 für KI-Risiko), sowie für autonome Produkte der strukturierte Sicherheitsnachweis nach UL 4600. Ob und wie genau diese Normen im Typgenehmigungskontext verbindlich werden, ist offen und am jeweiligen Originaltext zu prüfen; festhalten lässt sich nur die Stoßrichtung.

Diese Entwicklung verschiebt den Vorbereitungshebel von einem Sollen zu einem Ist: Die AI-Security-Disziplin entsteht bereits sektorintern. Der falsche Weg wäre die Doppeldokumentation in einem zweiten, getrennten Nachweisstrang; der ebenso falsche die Annahme, das bestehende CSMS leiste das Geforderte schon. Tragfähig ist allein die frühe Adoption dieser entstehenden Systematik samt des dafür nötigen Kompetenzaufbaus, statt auf die delegierten Rechtsakte zu warten.

Fazit

Der AI Act trifft das Fahrzeug nicht mit dem horizontalen Stichtag, der vielerorts in regulatorischen Umsetzungs-Roadmaps steht. Seine materiellen Hochrisiko-Anforderungen erreichen die Typgenehmigung über einen Umweg, den Art. 2 Abs. 2 und die Anhang I, Abschnitt B-Verortung skizzieren und den die Art. 107 und 109 in das Sektorrecht einbringen. Das beantwortet das Wann und Wie.

Offen bleibt das Womit. Die institutionelle Zuständigkeit liegt zweifelsfrei beim Typgenehmigungsregime, doch dessen Inhalt deckt die KI-spezifischen Schutzziele des Art. 15 heute noch nicht ab: Das CSMS sichert die Infrastruktur um das KI-Modell, nicht dessen statistische Integrität. Wer beide Hälften in der Planung abbildet, vermeidet drei Fehler zugleich: die Fehlinvestition gegen eine Phantom-Deadline, das Versäumnis, die kommende Novellierung des Typgenehmigungsrechts rechtzeitig zu verfolgen, und die trügerische Beruhigung, ein grünes CSMS belege bereits die AI-Security. Das richtige Modell ist der sektorale Container mit einer eigenständigen AI-Security-Disziplin als Inhalt; sie beginnt, sich in ISO/PAS 8800 und ISO/IEC 27090 zu materialisieren. Damit verbindet sich eine letzte Beobachtung, die über den AI Act hinausweist: Dieselbe Hochrisiko-KI im selben Fahrzeug wird je nach Rechtsraum unterschiedlich erfasst. Die globale Fragmentierung der Fahrzeug-Cybersecurity-Regulierung soll jedoch nicht Gegenstand dieses Beitrags werden.