Doprava a kritická infrastruktura — soulad s EU AI Act

Povinnosti vyplývající z EU AI Act pro AI v autonomních vozidlech, řízení dopravy, letectví, železnici a kritické infrastruktuře. Zahrnuje přílohu I (NLF) a kategorii 2 přílohy III.

Proč je doprava prioritním sektorem EU AI Act

EU AI Act (nařízení (EU) 2024/1689) ukládá nejnáročnější povinnosti oblastem, kde selhání AI má přímé důsledky pro fyzickou bezpečnost, kontinuitu kritických služeb a veřejnou bezpečnost. Doprava a kritická infrastruktura zaujímají v této architektuře ústřední postavení ze dvou nezávislých právních důvodů: rozsáhlé nasazení AI jako bezpečnostních komponent v regulovaných dopravních produktech (aktivující čl. 6 odst. 1 prostřednictvím přílohy I) a výslovné zařazení AI pro správu kritické infrastruktury jako vysoce rizikové v příloze III bodě 2.

Dopravní sektor se rovněž vyznačuje hustotou a vyspělostí stávajících regulačních rámců. Schválení typu vozidla podle nařízení o obecné bezpečnosti (EU) 2019/2144, certifikace v letectví podle základního nařízení EASA (EU) 2018/1139, interoperabilita a bezpečnost železnic podle nařízení ERA (EU) 2016/796 a bezpečnostní směrnice 2016/798 a kybernetická bezpečnost kritické infrastruktury podle směrnice NIS2 (EU) 2022/2555 vytvářejí preexistující právní povinnosti, které se vrství na EU AI Act — a v některých případech s ním strukturálně interagují.

Pro dopravní organizace je praktickým důsledkem skutečnost, že soulad s předpisy o AI nelze řídit jako izolovaný regulační tok. Musí být integrován do stávajících programů schválení typu, certifikace, řízení bezpečnosti a kybernetické bezpečnosti. Neschopnost dosáhnout této integrace riskuje nejen nesoulad s AI Act, ale také nesoulad se sektorovými předpisy, které mají vlastní orgány prosazování práva a důsledky pro přístup na trh.

AI jako bezpečnostní komponenta (příloha I) vs. AI pro kritickou infrastrukturu (příloha III, bod 2)

EU AI Act vytváří dvě odlišné cesty k vysokému riziku relevantní pro dopravu. Pochopení, která cesta se uplatní — a zda obě platí současně — je prvním analytickým krokem v každém programu souladu s předpisy o AI v dopravě.

Příloha I — Bezpečnostní komponenty produktů regulovaných NLF

Čl. 6 odst. 1 EU AI Act klasifikuje jako vysoce rizikový každý AI systém, který je bezpečnostní komponentou produktu regulovaného podle právních předpisů New Legislative Framework (NLF) uvedených v příloze I. Pro dopravu jsou klíčovými nástroji NLF:

• Nařízení o obecné bezpečnosti (EU) 2019/2144 — silniční vozidla (osobní automobily, nákladní vozidla, motocykly, autobusy)
• Základní nařízení EASA (EU) 2018/1139 — letadla, motory a související vybavení
• Železniční legislativa ERA — včetně nařízení (EU) 2016/796 (ERA Agency), směrnice 2016/797 (interoperabilita) a směrnice 2016/798 (bezpečnost železnic)
• Nařízení o strojních zařízeních (EU) 2023/1230 — relevantní pro AI v automatizovaném přístavním vybavení, průmyslových vozidlech a stavební technice provozované v kontextu dopravní infrastruktury

AI systém je bezpečnostní komponentou dopravního produktu, pokud by jeho selhání nebo porucha mohly ohrozit zdraví nebo bezpečnost osob. U silničních vozidel to zahrnuje systémy autonomního nouzového brzdění, AI pro udržování jízdního pruhu, adaptivní tempomat SAE úrovně L2 a vyšší a všechny systémy automatizovaného řízení L3–L5. V letectví to zahrnuje AI v systémech řízení letu, komponenty autopilota a systémy varování před blízkostí země. V oblasti železnic to zahrnuje AI v automatické ochraně vlaku, AI pro signalizaci a autonomní systémy posunu.

Klasifikace podle čl. 6 odst. 1 je kategorická. Nevyžaduje, aby AI systém samostatně prokázal významnou pravděpodobnost škody — označení jako bezpečnostní komponenta je dostatečné. To znamená, že poskytovatelé takových systémů musí dodržovat požadavky kapitoly III oddílu 2 (čl. 9–15) zahrnující řízení rizik, správu dat, technickou dokumentaci, automatické protokolování, transparentnost, lidský dohled a přesnost a robustnost.

Příloha III, bod 2 — Správa kritické infrastruktury

Odděleně od cesty přes bezpečnostní komponentu příloha III bod 2 výslovně uvádí jako vysoce rizikové AI systémy určené k použití jako bezpečnostní komponenty při správě a provozu kritické infrastruktury, konkrétně:

• Kritická infrastruktura silniční dopravy
• Kritická infrastruktura vodní dopravy
• Kritické součásti elektroenergetické sítě (jako kritická infrastruktura s rizikovými profily rovnocennými dopravě)

AI systémy spadající do této kategorie zahrnují: platformy pro řízení dálniční dopravy využívající AI pro dynamické řízení rychlosti a detekci nehod, AI systémy pro stabilitu a vyrovnávání zátěže inteligentní sítě, kde by výpadek sítě ovlivnil dopravní provoz, a AI systémy řídící přístavní infrastrukturu na úrovni provozu základních služeb.

Rozdíl mezi bodem 2 a cestou přes přílohu I spočívá v tom, že příloha III bod 2 se vztahuje na provozovatele infrastruktury, nikoli pouze na výrobce produktů. Veřejný orgán nebo soukromý koncesionář provozující centrum AI pro řízení dopravy podléhá povinnostem bodu 2 jako provozovatel, nebo — pokud sám AI systém vyvinul — jako poskytovatel.

Dvojí klasifikace

Pokud je AI systém zároveň bezpečnostní komponentou produktu regulovaného NLF a je nasazen ve správě kritické infrastruktury (např. AI systém integrovaný do platformy chytré dálnice, který rovněž rozhraní s vozidlovými systémy), platí obě cesty. Uplatní se náročnější povinnosti.

Poskytovatel vs. provozovatel v kontextu dopravy — OEM vs. operátor

Přidělení povinností mezi poskytovatele (čl. 16) a provozovatele (čl. 26) je v dopravě obzvláště složité, kde dodavatelský řetězec mezi vývojářem AI, systémovým integrátorem, výrobcem OEM, provozovatelem infrastruktury a flotilou koncových uživatelů může zahrnovat více právních subjektů, z nichž každý nese odlišné odpovědnosti podle AI Act.

Výrobci OEM jako poskytovatelé

Výrobce OEM, který integruje AI systém řízení — ať již vyvinutý interně nebo získaný od dodavatele Tier 1 nebo Tier 2 — a uvede vozidlo na trh EU pod vlastní značkou, je poskytovatelem AI systému podle čl. 16. To platí i v případě, že technologie AI byla původně vyvinuta třetí stranou, pokud výrobce OEM nezprostředkoval pouhý prodej nezměněného systému pod značkou třetí strany. Povinnosti poskytovatele zahrnují:

• Zavedení systému řízení kvality podle čl. 17
• Přípravu a vedení technické dokumentace podle čl. 11 a přílohy IV, zahrnující zamýšlený účel AI systému, návrh, trénovací data, výsledky validace a plán monitorování po uvedení na trh
• Provedení nebo zadání posouzení shody — které musí být u bezpečnostních komponent vozidel koordinováno s postupem schválení typu podle GSR 2019/2144
• Registraci AI systému v databázi EU pro vysoce rizikové AI systémy podle čl. 49 před uvedením na trh
• Poskytnutí návodu k použití provozovatelům (flotily, půjčovny) v dostatečném rozsahu pro zajištění souladu s předpisy při nasazení

Flotily a koncesionáři jako provozovatelé

Společnost provozující flotilu autonomních vozidel, místní orgán nasazující AI systém pro řízení dopravy nebo správce železniční infrastruktury používající nástroje pro údržbu s podporou AI je provozovatelem podle čl. 26. Povinnosti provozovatele zahrnují:

• Používání AI systému v rámci návodu k použití poskytovatele — jakékoli provozní použití mimo tento rámec může provozovatele přeřadit do kategorie poskytovatele, čímž se aktivuje plný soubor povinností poskytovatele
• Zavádění opatření pro lidský dohled specifikovaných poskytovatelem a přiměřených provoznímu kontextu
• Vedení provozních protokolů generovaných AI systémem po dobu nejméně šesti měsíců, nebo déle, pokud to vyžaduje příslušná sektorová legislativa (NIS2, národní právní předpisy v oblasti bezpečnosti dopravy)
• Bezodkladné hlášení poruch nebo závažných incidentů poskytovateli a národním příslušným orgánům podle čl. 73, pokud jsou dotčeny bezpečnost nebo základní práva
• Provádění posouzení dopadů na základní práva (FRIA) podle čl. 27, pokud AI systém nasazuje veřejný orgán nebo je využíván v kontextech ovlivňujících jednotlivce ve velkém měřítku

Interakce se sektorovými předpisy — EASA, ERA a schválení typu

Silniční vozidla — GSR 2019/2144 a schválení typu

Nařízení o obecné bezpečnosti (EU) 2019/2144 ukládá povinnost zahrnout do nových typů vozidel specifické funkce ADAS a autonomního řízení a stanovuje technické požadavky na jejich výkon. Schválení typu vozidla — prováděné národními orgány pro schválení typu (např. KBA v Německu, DREAL ve Francii, Rijksdienst voor het Wegverkeer v Nizozemsku) — je primárním mechanismem přístupu na trh pro silniční vozidla.

EU AI Act nenahrazuje schválení typu. Čl. 8 odst. 1 AI Act stanoví, že pokud sektorové právní předpisy ukládají požadavky stejné nebo vyšší přísnosti, je možné procesní sladění, ale povinnosti AI Act zůstávají. V praxi musí posouzení shody AI systému řízení řešit jak technické požadavky GSR (posuzované v rámci schválení typu), tak požadavky AI Act (technická dokumentace, správa dat, protokolování, lidský dohled, monitorování po uvedení na trh). Výrobci OEM by měli plánovat integrované posouzení pokrývající oba rámce, aby se vyhnuli duplicitnímu úsilí a potenciálním mezerám.

Letectví — EASA a plán pro AI

EASA vykonává certifikační pravomoc nad letadly, motory a součástkami podle nařízení (EU) 2018/1139. Plán EASA pro AI (zveřejněný v postupných vydáních od roku 2020) se zabývá důvěryhodností AI pro palubní AI systémy a je primárním certifikačním referenčním dokumentem pro AI v letově kritických aplikacích.

EU AI Act se vztahuje na pozemní letecký AI (řízení letového provozu, diagnostika údržby, systémy řízení kabiny), který nespadá do perimetru letové způsobilosti EASA. U palubních AI systémů certifikovaných EASA je dostupné sladění podle čl. 8 odst. 1, ale překrytí mezi požadavky EASA na letovou způsobilost a povinnostmi AI Act (zejména pokud jde o protokolování a lidský dohled) musí být analyzováno pro každý systém zvlášť. Koncept EASA „úrovně zajištění AI" se přímo nepromítá do klasifikace vysokého rizika EU AI Act ani do požadavků na posouzení shody.

Železnice — ERA a systémy řízení bezpečnosti

ERA (Agentura Evropské unie pro železnice) dohlíží na interoperabilitu železnic a společný bezpečnostní rámec podle směrnic 2016/797 a 2016/798. Železniční podniky a správci infrastruktury jsou povinni vést Systém řízení bezpečnosti (SMS), který zahrnuje posuzování rizik, vyšetřování nehod a neustálé zlepšování.

Požadavky EU AI Act na řízení rizik podle čl. 9 úzce paralelují požadavky ERA na SMS. Organizace s vyspělým SMS jsou dobře připraveny integrovat dokumentaci řízení rizik podle AI Act do stávajícího rámce. ERA a Evropská komise deklarovaly preferenci integrovaných přístupů k dodržování předpisů, které zabraňují duplicitě mezi SMS a povinnostmi AI Act. AI systémy používané v automatickém provozu vlaku, AI komponenty ETCS (European Train Control System) nebo prediktivní údržbě, která vstupuje do bezpečnostně kritických rozhodnutí, jsou vysoce rizikové podle přílohy I (bezpečnostní komponenta železničních vozidel nebo infrastruktury).

Orgány prosazování práva a certifikace

Soulad s předpisy AI v dopravě zahrnuje více orgánů prosazování práva s částečně překrývající se jurisdikcí v závislosti na funkci AI systému a produktu, do kterého je zabudován.

EASA je certifikačním orgánem pro AI v letadlech a leteckých výrobcích. Může provádět šetření selhání AI systémů s dopadem na letovou způsobilost a její rozhodnutí ovlivňují přístup na trh v celé EU i v jurisdikcích bilaterálních partnerů.

ERA dohlíží na společný bezpečnostní rámec pro železnice. Bezpečnostní certifikáty železnic a povolení k provozu jsou podmíněny shodou s SMS, která stále více protíná soulad s AI Act pro AI systémy v železniční dopravě.

Národní orgány pro schválení typu vozidel — včetně KBA (Německo), orgánů pověřených ANFIA (Itálie) a Rijksdienst voor het Wegverkeer (Nizozemsko) — vydávají a mohou odvolávat schválení typu pro silniční vozidla. Nesoulad s požadavky AI Act na AI bezpečnostní komponenty může být důvodem k pozastavení schválení typu nebo odvolání vozidla z trhu.

Národní příslušné orgány NIS2 — jmenované každým členským státem, často národní agentura pro kybernetickou bezpečnost, jako BSI (Německo), ANSSI (Francie) nebo NCSC-NL (Nizozemsko) — prosazují povinnosti NIS2 pro provozovatele základních dopravních služeb. Prosazování NIS2 může mít za následek závazné pokyny, pokuty a v závažných případech pozastavení provozu.

Národní dozorové orgány pro AI jmenované podle čl. 70 EU AI Act budou mít obecné pravomoci dohledu nad trhem, s koordinačními mechanismy pro sektorově specifické orgány k zamezení jurisdikčních konfliktů.

Priority souladu pro provozovatele a poskytovatele v dopravě

Krok 1: Inventář AI systémů a klasifikace

Proveďte strukturovaný inventář všech AI systémů ve vývoji nebo nasazení v rámci dopravního produktu nebo provozního portfolia. U každého systému určete, zda jde o bezpečnostní komponentu produktu regulovaného NLF (cesta přes čl. 6 odst. 1), AI pro správu kritické infrastruktury (příloha III bod 2), nebo obojí. Zdokumentujte písemně zdůvodnění klasifikace. Systémy, které nelze jednoznačně vyloučit z klasifikace vysokého rizika, by měly být považovány za vysoce rizikové do doby, než bude provedena jednoznačná právní analýza.

Krok 2: Plánování cesty posouzení shody

U AI systémů, které jsou bezpečnostními komponentami vozidel, letadel nebo železničních produktů, identifikujte příslušný postup certifikace v sektoru a zmapujte jej vůči požadavkům na posouzení shody podle AI Act. Určete, zda je vyžadován notifikovaný subjekt (čl. 43 odst. 3), nebo zda postačuje vlastní posouzení s technickým auditem třetí strany. Koordinujte časový plán posouzení shody podle AI Act s programem schválení typu nebo certifikace, abyste předešli zpožděním v přístupu na trh.

Krok 3: Technická dokumentace a správa dat

Připravte technickou dokumentaci podle přílohy IV pro každý vysoce rizikový AI systém. V případě AI v dopravě musí zahrnovat: zamýšlený účel s přesností dostatečnou pro podporu klasifikace podle AI Act i sektorových předpisů; původ trénovacích dat včetně případných reálných jízdních, provozních nebo senzorových dat; popis simulačního prostředí pro AI systémy validované virtuálním testováním; a plány monitorování po uvedení na trh sladěné se sektorově specifickými povinnostmi hlášení.

Krok 4: Integrace NIS2 pro provozovatele kritické infrastruktury

Provozovatelé základních dopravních služeb musí integrovat požadavky AI Act na kybernetickou bezpečnost podle čl. 15 s povinnostmi NIS2 v oblasti řízení kybernetických rizik. Zavedení jediného procesu hodnocení bezpečnostních rizik pokrývajícího oba rámce. Zajistěte, aby dodavatelé AI softwaru — včetně vývojářů AI modelů a poskytovatelů dat — podléhali požadavkům na bezpečnost dodavatelského řetězce konzistentním s čl. 21 odst. 2 písm. d) NIS2 a čl. 25 AI Act (povinnosti ohledně nástrojů třetích stran).

Krok 5: Lidský dohled v provozních kontextech

Navrhněte mechanismy lidského dohledu podle čl. 14, které jsou provozně reálné v dopravním prostředí. U systémů autonomního řízení definujte podmínky, za nichž musí být řidič schopen převzít kontrolu (L3) nebo vzdálený operátor musí mít možnost zasáhnout (L4). U AI pro řízení letového provozu uveďte body v pracovním postupu, v nichž musí řídící letového provozu zkontrolovat a schválit pokyny generované AI. U AI pro údržbu železnic definujte eskalační protokoly, když systém označí bezpečnostně kritické anomálie. Mechanismy dohledu musí být zdokumentovány v technické dokumentaci a promítnuty do návodu k použití poskytnutého provozovatelům.

Krok 6: Monitorování po uvedení na trh a hlášení incidentů

Zaveďte systémy monitorování po uvedení na trh, které splňují jak požadavky čl. 72 AI Act, tak sektorově specifické povinnosti hlášení bezpečnostních událostí (hlášení nehod ERA, hlášení výskytů EASA podle nařízení (EU) 376/2014, oznámení incidentů NIS2). Závažné incidenty zahrnující vysoce rizikové AI systémy musí být hlášeny národnímu dozorovému orgánu pro AI podle čl. 73 do 15 pracovních dnů od zjištění. Tuto lhůtu je nutné sladit s požadavkem NIS2 na počáteční oznámení do 24 hodin u závažných kybernetických incidentů, který může pokrývat stejnou událost, pokud je porucha AI systému přičitatelná narušení kybernetické bezpečnosti.