Transport i infrastruktura krytyczna — zgodność z EU AI Act

Obowiązki wynikające z EU AI Act dla systemów AI w pojazdach autonomicznych, zarządzaniu ruchem, lotnictwie, kolei i infrastrukturze krytycznej. Obejmuje Annex I (NLF) oraz kategorię 2 Annex III.

Dlaczego transport jest sektorem priorytetowym EU AI Act

EU AI Act (Rozporządzenie (UE) 2024/1689) nakłada najbardziej wymagające obowiązki na dziedziny, w których awarie AI niosą bezpośrednie konsekwencje dla bezpieczeństwa fizycznego, ciągłości usług o znaczeniu krytycznym oraz bezpieczeństwa publicznego. Transport i infrastruktura krytyczna zajmują centralne miejsce w tej architekturze z dwóch niezależnych powodów prawnych: powszechnego stosowania AI jako komponentów bezpieczeństwa w regulowanych produktach transportowych (uruchamiającego Art. 6(1) poprzez Annex I) oraz wyraźnego wymienienia AI zarządzającego infrastrukturą krytyczną jako wysokiego ryzyka w Annex III, punkt 2.

Sektor transportu wyróżnia się również gęstością i dojrzałością istniejących ram regulacyjnych. Homologacja pojazdów na podstawie Rozporządzenia o bezpieczeństwie ogólnym (UE) 2019/2144, certyfikacja lotnicza na podstawie Rozporządzenia podstawowego EASA (UE) 2018/1139, interoperacyjność i bezpieczeństwo kolei na podstawie Rozporządzenia ERA (UE) 2016/796 i Dyrektywy bezpieczeństwa 2016/798 oraz cyberbezpieczeństwo infrastruktury krytycznej na podstawie Dyrektywy NIS2 (UE) 2022/2555 — wszystkie te instrumenty tworzą istniejące wcześniej obowiązki prawne, które nakładają się na EU AI Act, a w niektórych przypadkach strukturalnie z nim oddziałują.

Dla organizacji transportowych praktyczna konsekwencja jest taka, że zgodność z przepisami AI nie może być zarządzana jako izolowany strumień regulacyjny. Musi zostać włączona do istniejących programów homologacji, certyfikacji, zarządzania bezpieczeństwem i cyberbezpieczeństwa. Brak tej integracji grozi nie tylko niezgodnością z AI Act, ale również niespełnieniem wymogów przepisów sektorowych, które dysponują własnymi organami egzekwowania i wywołują własne skutki w zakresie dostępu do rynku.

AI jako komponent bezpieczeństwa (Annex I) a AI zarządzający infrastrukturą krytyczną (Annex III, punkt 2)

EU AI Act tworzy dwie odrębne ścieżki wysokiego ryzyka istotne dla transportu. Ustalenie, która ścieżka ma zastosowanie — i czy obie stosują się jednocześnie — jest pierwszym krokiem analitycznym w każdym programie zgodności AI w transporcie.

Annex I — komponenty bezpieczeństwa produktów regulowanych w ramach NLF

Art. 6(1) EU AI Act klasyfikuje jako wysokiego ryzyka każdy system AI będący komponentem bezpieczeństwa produktu regulowanego na podstawie przepisów Nowych Ram Prawnych (NLF) wymienionych w Annex I. Dla transportu kluczowymi instrumentami NLF są:

• Rozporządzenie o bezpieczeństwie ogólnym (UE) 2019/2144 — pojazdy drogowe (samochody osobowe, ciężarówki, motocykle, autobusy)
• Rozporządzenie podstawowe EASA (UE) 2018/1139 — statki powietrzne, silniki i powiązane wyposażenie
• Prawodawstwo kolejowe ERA — w tym Rozporządzenie (UE) 2016/796 (Agencja ERA), Dyrektywa 2016/797 (interoperacyjność) i Dyrektywa 2016/798 (bezpieczeństwo kolei)
• Rozporządzenie maszynowe (UE) 2023/1230 — istotne dla AI w zautomatyzowanym sprzęcie portowym, pojazdach przemysłowych i maszynach budowlanych eksploatowanych w kontekście infrastruktury transportowej

System AI jest komponentem bezpieczeństwa produktu transportowego, jeżeli jego awaria lub nieprawidłowe działanie mogłoby zagrozić zdrowiu lub bezpieczeństwu osób. W odniesieniu do pojazdów drogowych obejmuje to autonomiczne systemy awaryjnego hamowania, AI utrzymywania pasa ruchu, adaptacyjny tempomat na poziomie SAE L2 i powyżej oraz wszystkie zautomatyzowane systemy jazdy L3–L5. W lotnictwie obejmuje AI w systemach zarządzania lotem, komponenty autopilota i systemy ostrzegania o zbliżaniu się do ziemi (GPWS). W kolejnictwie obejmuje AI w automatycznej ochronie pociągu, AI wspomagający sygnalizację i autonomiczne systemy manewrowania.

Klasyfikacja na podstawie Art. 6(1) ma charakter kategoryczny. Nie wymaga samodzielnego wykazania przez system AI znaczącego prawdopodobieństwa wyrządzenia szkody — wystarczające jest zakwalifikowanie go jako komponentu bezpieczeństwa. Oznacza to, że dostawcy takich systemów muszą spełniać wymogi Rozdziału III, Sekcja 2 (Art. 9–15) obejmujące zarządzanie ryzykiem, zarządzanie danymi, dokumentację techniczną, automatyczne rejestrowanie, przejrzystość, nadzór ludzki oraz dokładność i odporność.

Annex III, punkt 2 — zarządzanie infrastrukturą krytyczną

Niezależnie od ścieżki opartej na komponentach bezpieczeństwa, Annex III, punkt 2 wyraźnie wymienia jako wysokiego ryzyka systemy AI przeznaczone do stosowania jako komponenty bezpieczeństwa w zarządzaniu i eksploatacji infrastruktury krytycznej, w szczególności:

• Krytyczna infrastruktura drogowego ruchu drogowego
• Krytyczna infrastruktura transportu wodnego
• Krytyczne elementy sieci elektroenergetycznej (jako infrastruktura krytyczna o profilu ryzyka równoważnym z transportem)

Do tej kategorii zaliczają się: platformy zarządzania ruchem na autostradach z wykorzystaniem AI do dynamicznej kontroli prędkości i wykrywania incydentów, systemy AI do stabilizacji sieci elektroenergetycznej i bilansowania obciążenia w przypadkach, gdy awaria sieci miałaby wpływ na operacje transportowe, oraz systemy AI zarządzające infrastrukturą portową na poziomie świadczenia usług o znaczeniu podstawowym.

Różnica między punktem 2 a ścieżką z Annex I polega na tym, że Annex III, punkt 2 stosuje się do operatorów infrastruktury, a nie wyłącznie do producentów produktów. Organ publiczny lub prywatny koncesjonariusz eksploatujący centrum zarządzania ruchem oparte na AI podlega obowiązkom wynikającym z punktu 2 jako podmiot stosujący lub — jeżeli sam opracował system AI — jako dostawca.

Podwójna klasyfikacja

W przypadku gdy system AI jest jednocześnie komponentem bezpieczeństwa produktu regulowanego w ramach NLF i jest wdrożony w zarządzaniu infrastrukturą krytyczną (np. system AI zintegrowany z inteligentną platformą autostradową, który jednocześnie współdziała z systemami pojazdu), obie ścieżki mają zastosowanie. Bardziej wymagające obowiązki mają pierwszeństwo.

Dostawca a podmiot stosujący w kontekście transportu — OEM a operator

Podział obowiązków między dostawców (Art. 16) a podmioty stosujące (Art. 26) jest szczególnie złożony w transporcie, gdzie łańcuch dostaw między deweloperem AI, integratorem systemów, OEM, operatorem infrastruktury i flotą użytkownika końcowego może obejmować wiele podmiotów prawnych, z których każdy ponosi odrębne obowiązki wynikające z AI Act.

OEM jako dostawca

OEM, który integruje system AI do jazdy — opracowany we własnym zakresie lub pozyskany od dostawcy poziomu 1 lub 2 (Tier 1/Tier 2) — i wprowadza pojazd na rynek UE pod własną marką, jest dostawcą systemu AI w rozumieniu Art. 16. Ma to zastosowanie nawet jeżeli technologia AI została pierwotnie opracowana przez podmiot trzeci, pod warunkiem że OEM nie jedynie odsprzedał niezmieniony system pod marką podmiotu trzeciego. Do obowiązków dostawcy należą:

• Ustanowienie systemu zarządzania jakością na podstawie Art. 17
• Sporządzenie i utrzymywanie dokumentacji technicznej na podstawie Art. 11 i Annex IV, obejmującej przeznaczenie systemu AI, projekt, dane szkoleniowe, wyniki walidacji i plan monitorowania po wprowadzeniu do obrotu
• Przeprowadzenie lub zlecenie oceny zgodności — która w przypadku komponentów bezpieczeństwa pojazdów musi być skoordynowana z procedurą homologacji na podstawie GSR 2019/2144
• Rejestracja systemu AI w unijnej bazie danych systemów AI wysokiego ryzyka na podstawie Art. 49 przed wprowadzeniem na rynek
• Dostarczenie instrukcji użytkowania do podmiotów stosujących niższego szczebla (operatorów flot, firm wynajmu) w zakresie wystarczającym do zapewnienia zgodnego z prawem stosowania

Operatorzy flot i koncesjonariusze jako podmioty stosujące

Spółka eksploatująca flotę pojazdów autonomicznych, jednostka samorządu terytorialnego wdrażająca system zarządzania ruchem oparty na AI lub zarządca infrastruktury kolejowej używający narzędzi konserwacyjnych wspomaganych AI jest podmiotem stosującym w rozumieniu Art. 26. Do obowiązków podmiotu stosującego należą:

• Stosowanie systemu AI w zakresie instrukcji użytkowania dostawcy — jakiekolwiek użycie operacyjne wykraczające poza ten zakres może spowodować przeklasyfikowanie podmiotu stosującego na dostawcę, uruchamiając pełen zestaw obowiązków dostawcy
• Wdrożenie środków nadzoru ludzkiego określonych przez dostawcę i odpowiednich do kontekstu operacyjnego
• Przechowywanie dzienników operacyjnych generowanych przez system AI przez co najmniej sześć miesięcy lub dłużej, jeżeli mające zastosowanie przepisy sektorowe (NIS2, krajowe przepisy bezpieczeństwa transportu) wymagają dłuższego okresu przechowywania
• Niezwłoczne zgłaszanie awarii lub poważnych incydentów dostawcy oraz właściwym organom krajowym na podstawie Art. 73, gdy w grę wchodzi bezpieczeństwo lub prawa podstawowe
• Przeprowadzanie ocen wpływu na prawa podstawowe (FRIA) na podstawie Art. 27, gdy system AI jest wdrażany przez organ publiczny lub w kontekście oddziałującym na osoby na dużą skalę

Wzajemne oddziaływanie z regulacjami sektorowymi — EASA, ERA i homologacja

Pojazdy drogowe — GSR 2019/2144 i homologacja

Rozporządzenie o bezpieczeństwie ogólnym (UE) 2019/2144 nakłada obowiązek włączenia określonych funkcji ADAS i jazdy autonomicznej do nowych typów pojazdów i ustanawia wymagania techniczne dotyczące ich działania. Homologacja — przeprowadzana przez krajowe organy homologacji (np. KBA w Niemczech, DREAL we Francji, Rijksdienst voor het Wegverkeer w Holandii) — jest podstawowym mechanizmem dostępu do rynku dla pojazdów drogowych.

EU AI Act nie zastępuje homologacji. Art. 8(1) AI Act stanowi, że tam, gdzie przepisy sektorowe nakładają wymogi równoważnej lub wyższej rygorystyczności, możliwe jest uzgodnienie proceduralne, jednak obowiązki AI Act pozostają w mocy. W praktyce ocena zgodności systemu AI do jazdy musi uwzględniać zarówno wymagania techniczne GSR (oceniane w ramach homologacji), jak i wymagania AI Act (dokumentacja techniczna, zarządzanie danymi, rejestrowanie, nadzór ludzki, monitorowanie po wprowadzeniu do obrotu). OEM powinni planować zintegrowaną ocenę obejmującą oba reżimy prawne, aby uniknąć powielania wysiłków i potencjalnych luk.

Lotnictwo — EASA i mapa drogowa dotycząca AI

EASA sprawuje uprawnienia certyfikacyjne nad statkami powietrznymi, silnikami i częściami na podstawie Rozporządzenia (UE) 2018/1139. Mapa drogowa EASA dotycząca AI (publikowana w kolejnych wydaniach od 2020 r.) dotyczy wiarygodności AI w pokładowych systemach AI i stanowi podstawowe odniesienie certyfikacyjne dla AI w zastosowaniach krytycznych dla lotu.

EU AI Act stosuje się do naziemnych systemów AI w lotnictwie (zarządzanie ruchem lotniczym, diagnostyka konserwacyjna, systemy zarządzania kabiny pasażerskiej) wykraczających poza zakres zdatności do lotu EASA. W przypadku pokładowych systemów AI certyfikowanych przez EASA dostępne jest uzgodnienie na podstawie Art. 8(1), jednak nakładanie się wymogów zdatności do lotu EASA i obowiązków AI Act (w szczególności dotyczących rejestrowania i nadzoru ludzkiego) musi być analizowane system po systemie. Koncepcja „poziomu zapewnienia AI" stosowana przez EASA nie przekłada się bezpośrednio na klasyfikację wysokiego ryzyka ani wymogi oceny zgodności EU AI Act.

Kolej — ERA i Systemy Zarządzania Bezpieczeństwem

ERA (Agencja Kolejowa Unii Europejskiej) nadzoruje interoperacyjność kolei i wspólne ramy bezpieczeństwa na podstawie Dyrektyw 2016/797 i 2016/798. Przedsiębiorstwa kolejowe i zarządcy infrastruktury są zobowiązani do utrzymywania Systemu Zarządzania Bezpieczeństwem (SMS) obejmującego ocenę ryzyka, badanie wypadków i ciągłe doskonalenie.

Wymogi zarządzania ryzykiem AI Act wynikające z Art. 9 są ściśle zbieżne z wymogami SMS ERA. Organizacje posiadające dojrzały SMS są dobrze przygotowane do włączenia dokumentacji zarządzania ryzykiem zgodnej z AI Act do istniejących ram. ERA i Komisja Europejska wyraziły preferencję dla zintegrowanych podejść do zgodności, które unikają powielania obowiązków między SMS a wymogami AI Act. Systemy AI stosowane w automatycznym prowadzeniu pociągu, komponenty AI ETCS (Europejski System Sterowania Pociągiem) lub predykcyjna konserwacja zasilająca decyzje o krytycznym znaczeniu dla bezpieczeństwa są wysokiego ryzyka na podstawie Annex I (komponent bezpieczeństwa pojazdów kolejowych lub infrastruktury).

Organy egzekwowania i certyfikacji

Zgodność AI w transporcie obejmuje wiele organów egzekwowania o częściowo nakładającej się właściwości, w zależności od funkcji systemu AI i produktu, w którym jest wbudowany.

EASA jest organem certyfikacji AI w statkach powietrznych i produktach lotniczych. Może prowadzić postępowania wyjaśniające dotyczące awarii systemów AI mających wpływ na zdatność do lotu, a jej decyzje wpływają na dostęp do rynku w całej UE i jurysdykcjach partnerskich na podstawie umów dwustronnych.

ERA nadzoruje wspólne ramy bezpieczeństwa dla kolei. Certyfikaty bezpieczeństwa i autoryzacje do prowadzenia działalności kolejowej są uzależnione od zgodności z SMS, która coraz częściej krzyżuje się ze zgodnością z AI Act w przypadku systemów kolejowych wspieranych przez AI.

Krajowe organy homologacji pojazdów — w tym KBA (Niemcy), organy upoważnione przez ANFIA (Włochy) i Rijksdienst voor het Wegverkeer (Holandia) — wydają i mogą cofać homologacje pojazdów drogowych. Niezgodność z wymogami AI Act dotyczącymi komponentów bezpieczeństwa AI może stanowić podstawę do zawieszenia homologacji lub wycofania pojazdu z rynku.

Krajowe organy właściwe ds. NIS2 — wyznaczane przez każde państwo członkowskie, często krajowa agencja cyberbezpieczeństwa, taka jak BSI (Niemcy), ANSSI (Francja) lub NCSC-NL (Holandia) — egzekwują obowiązki NIS2 wobec operatorów usług kluczowych w transporcie. Egzekwowanie NIS2 może skutkować wydaniem wiążących nakazów, nałożeniem kar finansowych, a w poważnych przypadkach — zawieszeniem działalności.

Krajowe organy nadzoru AI wyznaczone na podstawie Art. 70 EU AI Act będą dysponować ogólnymi uprawnieniami w zakresie nadzoru rynku, z mechanizmami koordynacji z organami sektorowymi mającymi na celu uniknięcie konfliktów jurysdykcyjnych.

Priorytety zgodności dla operatorów i dostawców w transporcie

Krok 1: Inwentaryzacja i klasyfikacja systemów AI

Przeprowadź ustrukturyzowaną inwentaryzację wszystkich systemów AI będących w fazie opracowania lub wdrożenia w ramach portfela produktów transportowych lub działalności operacyjnej. Dla każdego systemu ustal, czy jest on komponentem bezpieczeństwa produktu regulowanego w ramach NLF (ścieżka Art. 6(1)), systemem AI zarządzania infrastrukturą krytyczną (Annex III, punkt 2) lub oboma jednocześnie. Udokumentuj uzasadnienie klasyfikacji na piśmie. Systemy, które nie mogą zostać definitywnie wyłączone z klasyfikacji wysokiego ryzyka, należy traktować jako wysokiego ryzyka do czasu przeprowadzenia definitywnej analizy prawnej.

Krok 2: Planowanie ścieżki oceny zgodności

Dla systemów AI będących komponentami bezpieczeństwa pojazdów, statków powietrznych lub produktów kolejowych zidentyfikuj mającą zastosowanie procedurę certyfikacji sektorowej i porównaj ją z wymogami oceny zgodności AI Act. Ustal, czy wymagane jest zaangażowanie jednostki notyfikowanej (Art. 43(3)), czy wystarczy samoocena z zewnętrznym audytem technicznym. Skoordynuj harmonogram oceny zgodności z AI Act z programem homologacji lub certyfikacji, aby uniknąć opóźnień w dostępie do rynku.

Krok 3: Dokumentacja techniczna i zarządzanie danymi

Przygotuj dokumentację techniczną zgodną z Annex IV dla każdego systemu AI wysokiego ryzyka. W przypadku AI transportowego musi ona obejmować: przeznaczenie systemu ze stopniem precyzji wystarczającym do obsługi zarówno klasyfikacji AI Act, jak i regulacji sektorowych; pochodzenie danych szkoleniowych, w tym wszelkich rzeczywistych danych z jazdy, danych operacyjnych lub czujnikowych; opisy środowisk symulacyjnych dla systemów AI walidowanych poprzez testowanie wirtualne; oraz plany monitorowania po wprowadzeniu do obrotu dostosowane do sektorowych obowiązków sprawozdawczych.

Krok 4: Integracja NIS2 dla operatorów infrastruktury krytycznej

Operatorzy usług kluczowych w transporcie muszą zintegrować wymogi cyberbezpieczeństwa AI Act wynikające z Art. 15 z obowiązkami zarządzania ryzykiem cyberbezpieczeństwa NIS2. Należy ustanowić jeden proces oceny ryzyka bezpieczeństwa obejmujący oba reżimy prawne. Należy zapewnić, aby dostawcy oprogramowania AI — w tym deweloperzy modeli AI i dostawcy danych — podlegali wymogom bezpieczeństwa łańcucha dostaw zgodnym z Art. 21(2)(d) NIS2 i Art. 25 AI Act (obowiązki dotyczące narzędzi podmiotów trzecich).

Krok 5: Nadzór ludzki w kontekstach operacyjnych

Zaprojektuj mechanizmy nadzoru ludzkiego na podstawie Art. 14, które są operacyjnie wykonalne w środowiskach transportowych. W przypadku autonomicznych systemów jazdy należy określić warunki, w których kierowca musi być w stanie przejąć kontrolę (L3) lub operator zdalny musi być w stanie interweniować (L4). W przypadku AI do zarządzania ruchem lotniczym należy wskazać punkty w przepływie pracy, w których kontroler musi przeglądać i zatwierdzać instrukcje generowane przez AI. W przypadku AI do konserwacji kolei należy zdefiniować protokoły eskalacji, gdy system sygnalizuje anomalie o krytycznym znaczeniu dla bezpieczeństwa. Mechanizmy nadzoru muszą być udokumentowane w dokumentacji technicznej i odzwierciedlone w instrukcjach użytkowania dostarczanych podmiotom stosującym.

Krok 6: Monitorowanie po wprowadzeniu do obrotu i zgłaszanie incydentów

Ustanów systemy monitorowania po wprowadzeniu do obrotu spełniające zarówno wymogi Art. 72 AI Act, jak i sektorowe obowiązki sprawozdawczości w zakresie bezpieczeństwa (sprawozdawczość dotycząca wypadków ERA, zgłaszanie zdarzeń przez EASA na podstawie Rozporządzenia (UE) 376/2014, powiadamianie o incydentach NIS2). Poważne incydenty z udziałem systemów AI wysokiego ryzyka muszą być zgłaszane krajowemu organowi nadzoru AI na podstawie Art. 73 w ciągu 15 dni roboczych od powzięcia informacji. Termin ten musi być uzgodniony z wymogiem NIS2 dotyczącym wstępnego powiadomienia w ciągu 24 godzin o istotnych incydentach cyberbezpieczeństwa, który może obejmować to samo zdarzenie, jeżeli awaria AI jest przypisana naruszeniu cyberbezpieczeństwa.