Транспорт и критична инфраструктура — съответствие с EU AI Act

Задължения по EU AI Act за AI в автономни превозни средства, управление на трафика, авиация, железопътен транспорт и критична инфраструктура. Обхваща Annex I (NLF) и категория 2 от Annex III.

Защо транспортът е приоритетен сектор по EU AI Act

EU AI Act (Регламент (EU) 2024/1689) налага най-взискателните задължения в области, където неизправностите на AI носят преки последици за физическата безопасност, непрекъснатостта на критичните услуги и обществената сигурност. Транспортът и критичната инфраструктура заемат централно място в тази архитектура по две самостоятелни правни причини: повсеместното внедряване на AI като компоненти за безопасност в регулирани транспортни продукти (задействащо Art. 6(1) чрез Annex I) и изричното изброяване на AI за управление на критична инфраструктура като високорискова в Annex III, точка 2.

Транспортният сектор се отличава и с гъстотата и зрелостта на съществуващите си регулаторни рамки. Одобряването на типа превозно средство съгласно Общия регламент за безопасност (EU) 2019/2144, авиационната сертификация съгласно Базовия регламент на EASA (EU) 2018/1139, оперативната съвместимост и безопасността на железопътния транспорт съгласно Регламент (EU) 2016/796 на ERA и Директива за безопасност 2016/798, и киберсигурността на критичната инфраструктура съгласно Директива NIS2 (EU) 2022/2555 — всички те създават предварително съществуващи правни задължения, които се наслагват върху EU AI Act и в някои случаи структурно взаимодействат с него.

За транспортните организации практическото следствие е, че съответствието с изискванията за AI не може да се управлява като изолиран регулаторен процес. То трябва да бъде интегрирано в съществуващите програми за одобряване на типа, сертификация, управление на безопасността и киберсигурност. Неспазването на това изискване за интеграция носи риск не само от несъответствие с AI Act, но и от неконформност с секторните регулации, разполагащи с техни собствени изпълнителни органи и последици за достъпа до пазара.

AI за компоненти за безопасност (Annex I) срещу AI за критична инфраструктура (Annex III, точка 2)

EU AI Act създава два отделни пътя за класификация като високорискова, приложими в транспорта. Разбирането кой от тях е приложим — и дали двата се прилагат едновременно — е първата аналитична стъпка при всяка програма за съответствие на транспортен AI.

Annex I — Компоненти за безопасност на продукти, регулирани по NLF

Art. 6(1) от EU AI Act класифицира като високорискова всяка AI система, която е компонент за безопасност на продукт, регулиран от законодателството на Новата законодателна рамка (NLF), изброено в Annex I. За транспорта ключовите инструменти на NLF са:

• Общ регламент за безопасност (EU) 2019/2144 — пътни превозни средства (автомобили, камиони, мотоциклети, автобуси)
• Базов регламент на EASA (EU) 2018/1139 — въздухоплавателни средства, двигатели и свързано оборудване
• Железопътно законодателство на ERA — включващо Регламент (EU) 2016/796 (Агенция ERA), Директива 2016/797 (оперативна съвместимост) и Директива 2016/798 (железопътна безопасност)
• Регламент за машините (EU) 2023/1230 — приложим за AI в автоматизирано пристанищно оборудване, промишлени превозни средства и строителна техника, функционираща в контекста на транспортна инфраструктура

AI система е компонент за безопасност на транспортен продукт, ако нейната неизправност или повреда би могла да застраши здравето или безопасността на хора. При пътните превозни средства това обхваща системите за автономно аварийно спиране, AI за поддържане на лента, адаптивен круиз контрол от ниво SAE L2 и по-горе и всички системи за автоматизирано шофиране от нива L3–L5. При авиацията — AI в системите за управление на полета, компонентите на автопилота и системите за предупреждение за приближаване на земята. При железопътния транспорт — AI в автоматичната защита на влака, AI-подпомаганото сигнализиране и автономното маневриране.

Класификацията по Art. 6(1) е категорична. Тя не изисква AI системата самостоятелно да демонстрира значителна вероятност от вреди — достатъчно е определянето й като компонент за безопасност. Това означава, че доставчиците на такива системи трябва да спазват изискванията на Глава III, Раздел 2 (Arts. 9–15), обхващащи управление на риска, управление на данните, техническа документация, автоматично регистриране, прозрачност, човешки надзор, точност и устойчивост.

Annex III, точка 2 — Управление на критична инфраструктура

Отделно от пътя на компонентите за безопасност, Annex III, точка 2 изрично изброява като високорискови AI системи, предназначени за използване като компоненти за безопасност в управлението и експлоатацията на критична инфраструктура, по-специално:

• Критична инфраструктура за пътен трафик
• Критична инфраструктура за воден транспорт
• Критични компоненти на електроенергийната мрежа (като критична инфраструктура с рискови профили, равностойни на транспортните)

AI системите, попадащи в тази категория, включват: платформи за управление на магистралния трафик, използващи AI за динамичен контрол на скоростта и засичане на инциденти; AI системи за стабилизиране и балансиране на товара на интелигентни мрежи, при които авария би засегнала транспортните операции; и AI системи за управление на пристанищна инфраструктура на ниво операция на основна услуга.

Разликата между точка 2 и пътя по Annex I е, че Annex III, точка 2 се прилага за оператори на инфраструктура, а не само за производители на продукти. Публичен орган или частен концесионер, управляващ AI-базиран център за управление на трафика, подлежи на задълженията по точка 2 като ползвател, или — ако е разработил AI системата самостоятелно — като доставчик.

Двойна класификация

Когато AI система е едновременно компонент за безопасност на продукт, регулиран по NLF, и се използва за управление на критична инфраструктура (напр. AI система, интегрирана в платформа за интелигентна магистрала, която си взаимодейства и с превозните средства), се прилагат и двата пътя. Управляват по-взискателните задължения.

Доставчик срещу ползвател в транспортен контекст — OEM срещу оператор

Разпределението на задълженията между доставчиците (Art. 16) и ползвателите (Art. 26) е особено сложно в транспорта, където веригата на доставки между разработчик на AI, системен интегратор, OEM, инфраструктурен оператор и флот на крайния потребител може да включва множество правни субекти, всеки от които носи самостоятелни отговорности по AI Act.

OEM производители на превозни средства като доставчици

OEM, интегриращ AI система за шофиране — независимо дали е разработена вътрешно или е набавена от доставчик от Tier 1 или Tier 2 — и пускащ превозното средство на пазара на ЕС под собственото си търговско наименование, е доставчик на AI системата по смисъла на Art. 16. Това важи дори когато AI технологията е разработена първоначално от трета страна, при условие че OEM не е просто препродал непроменена система под търговска марка на третата страна. Задълженията на доставчика включват:

• Установяване на система за управление на качеството по Art. 17
• Изготвяне и поддържане на техническа документация по Art. 11 и Annex IV, обхващаща предназначението, проектирането, данните за обучение, резултатите от валидирането и плана за мониторинг след пускането на пазара на AI системата
• Провеждане или възлагане на оценка на съответствието — която при компоненти за безопасност на превозни средства трябва да бъде координирана с процедурата за одобряване на типа по GSR 2019/2144
• Регистриране на AI системата в базата данни на ЕС за високорискови AI системи по Art. 49 преди пускането й на пазара
• Предоставяне на инструкции за употреба на ползвателите по надолу по веригата (флот оператори, компании за наем), достатъчни за осигуряване на съответстващо използване

Флот оператори и концесионери като ползватели

Дружество, управляващо флот от автономни превозни средства, местен орган, внедряващ AI система за управление на трафика, или управител на железопътна инфраструктура, използващ AI-подпомагани инструменти за поддръжка, е ползвател по смисъла на Art. 26. Задълженията на ползвателя включват:

• Използване на AI системата в рамките на инструкциите за употреба на доставчика — всяко оперативно използване извън тези рамки може да прекласифицира ползвателя като доставчик, пораждайки пълния набор от задължения на доставчика
• Прилагане на мерки за човешки надзор, посочени от доставчика и съобразени с оперативния контекст
• Съхраняване на оперативни регистрационни файлове, генерирани от AI системата, за срок от най-малко шест месеца или по-дълго, когато приложимото секторно законодателство (NIS2, национално законодателство за транспортна безопасност) изисква по-дълъг срок на съхранение
• Незабавно докладване на неизправности или сериозни инциденти на доставчика и на националните компетентни органи по Art. 73, когато са засегнати безопасността или основните права
• Провеждане на оценки на въздействието върху основните права (FRIA) по Art. 27, когато AI системата се използва от публичен орган или в контексти, засягащи лица в значителен мащаб

Взаимодействие със секторните регулации — EASA, ERA и одобряване на типа

Пътни превозни средства — GSR 2019/2144 и одобряване на типа

Общият регламент за безопасност (EU) 2019/2144 задължава включването на конкретни функции за ADAS и автономно шофиране в новите типове превозни средства и установява технически изисквания към тяхната ефективност. Одобряването на типа превозно средство — провеждано от национални органи за одобряване на типа (напр. KBA в Германия, DREAL във Франция, Rijksdienst voor het Wegverkeer в Нидерландия) — е основният механизъм за достъп до пазара за пътни превозни средства.

EU AI Act не отменя одобряването на типа. Art. 8(1) от AI Act уточнява, че когато секторното законодателство налага изисквания с равностойна или по-голяма взискателност, е възможно процесуално сближаване, но задълженията по AI Act остават в сила. На практика оценката на съответствието за AI система за шофиране трябва да обхваща както техническите изисквания на GSR (преценявани в рамките на одобряването на типа), така и изискванията на AI Act (техническа документация, управление на данните, регистриране, човешки надзор, мониторинг след пускането на пазара). OEM производителите следва да планират интегрирана оценка, обхващаща двете рамки, за да избегнат дублиращи усилия и потенциални пропуски.

Авиация — EASA и пътната карта за AI

EASA упражнява сертификационни правомощия по отношение на въздухоплавателни средства, двигатели и части съгласно Регламент (EU) 2018/1139. Пътната карта на EASA за AI (публикувана в поредица от издания от 2020 г.) разглежда надеждността на AI за бордови AI системи и е основният сертификационен ориентир за AI в критични за полета приложения.

EU AI Act се прилага за наземни авиационни AI системи (управление на трафика, диагностика на поддръжката, системи за управление на кабината), попадащи извън периметъра на летателна годност на EASA. За бордови AI системи, сертифицирани от EASA, е налично сближаване по Art. 8(1), но застъпването между изискванията на EASA за летателна годност и задълженията по AI Act (особено относно регистрирането и човешкия надзор) трябва да бъде анализирано система по система. Концепцията на EASA за „ниво на увереност в AI" не се съответства пряко на класификацията на EU AI Act като високорискова или изискванията за оценка на съответствието.

Железопътен транспорт — ERA и системи за управление на безопасността

ERA (Агенция на Европейския съюз за железопътен транспорт) осъществява надзор върху оперативната съвместимост на железопътния транспорт и общата рамка за безопасност съгласно Директиви 2016/797 и 2016/798. Железопътните предприятия и управителите на инфраструктура са задължени да поддържат Система за управление на безопасността (SMS), обхващаща оценка на риска, разследване на произшествия и непрекъснато усъвършенстване.

Изискванията за управление на риска по Art. 9 от AI Act са в тясна паралел с изискванията на ERA за SMS. Организациите с утвърдена SMS са добре позиционирани да интегрират документацията за управление на риска по AI Act в съществуващата рамка. ERA и Европейската комисия са изразили предпочитание към интегрирани подходи за съответствие, избягващи дублирането между SMS и задълженията по AI Act. AI системите, използвани при автоматична влакова операция, AI компоненти на ETCS (Европейска система за управление на влаковото движение) или прогностична поддръжка, захранваща решения, критични за безопасността, са високорискови по Annex I (компонент за безопасност на железопътни превозни средства или инфраструктура).

Изпълнителни органи и органи по сертификация

Съответствието на транспортния AI включва множество изпълнителни органи с частично застъпващи се правомощия, в зависимост от функцията на AI системата и продукта, в който е вградена.

EASA е сертификационен орган за AI в въздухоплавателни средства и аеронавтически продукти. Тя може да провежда разследвания на повреди на AI системи, засягащи летателната годност, а нейните решения влияят на достъпа до пазара в целия ЕС и в юрисдикции на двустранни партньори.

ERA осъществява надзор върху общата рамка за безопасност на железопътния транспорт. Сертификатите за безопасност и разрешенията за работа са обвързани с конформността с SMS, която все повече се пресича със съответствието с AI Act за AI-базирани железопътни системи.

Национални органи за одобряване на типа — включително KBA (Германия), органите, делегирани от ANFIA (Италия), и Rijksdienst voor het Wegverkeer (Нидерландия) — издават и могат да отнемат одобрения на типа за пътни превозни средства. Несъответствието с изискванията на AI Act за AI компоненти за безопасност може да представлява основание за спиране на одобрението на типа или за отзоваване.

Национални компетентни органи по NIS2 — определени от всяка държава членка, често национална агенция по киберсигурност като BSI (Германия), ANSSI (Франция) или NCSC-NL (Нидерландия) — прилагат задълженията по NIS2 спрямо транспортни оператори на основни услуги. Принудителното изпълнение по NIS2 може да доведе до задължителни указания, глоби и в тежки случаи до спиране на дейността.

Национални надзорни органи за AI, определени по Art. 70 от EU AI Act, ще разполагат с общи правомощия за пазарен надзор, с механизми за координация между секторно специфичните органи за избягване на юрисдикционни конфликти.

Приоритети за съответствие за транспортни оператори и доставчици

Стъпка 1: Инвентаризация и класификация на AI системите

Извършете структурирана инвентаризация на всички AI системи в разработка или внедряване в транспортния продукт или оперативното портфолио. За всяка система установете дали е компонент за безопасност на продукт, регулиран по NLF (пат по Art. 6(1)), AI за управление на критична инфраструктура (Annex III, точка 2) или и двете. Документирайте обосновката на класификацията в писмена форма. Системите, за които не може да се изключи категорично класификацията като високорискова, следва да се третират като такива до окончателен правен анализ.

Стъпка 2: Планиране на маршрута за оценка на съответствието

За AI системи, представляващи компоненти за безопасност на превозни средства, въздухоплавателни средства или железопътни продукти, идентифицирайте приложимата секторна процедура за сертификация и я съпоставете с изискванията за оценка на съответствието по AI Act. Определете дали се изисква нотифициран орган (Art. 43(3)) или е достатъчна самооценка с независим технически одит от трета страна. Координирайте графика за оценка на съответствието по AI Act с програмата за одобряване на типа или сертификация, за да избегнете забавяния при достъпа до пазара.

Стъпка 3: Техническа документация и управление на данните

Изгответе техническа документация по Annex IV за всяка високорискова AI система. За транспортен AI тя трябва да включва: предназначението с прецизност, достатъчна за класификацията по AI Act и секторната регулация; произхода на данните за обучение, включително използваните данни от реалното шофиране, оперативни или сензорни данни; описания на средите за симулация за AI системи, валидирани чрез виртуално тестване; и планове за мониторинг след пускането на пазара, съответстващи на секторно специфичните задължения за докладване.

Стъпка 4: Интегриране на NIS2 за оператори на критична инфраструктура

Транспортните оператори на основни услуги трябва да интегрират изискванията за киберсигурност по AI Act съгласно Art. 15 с задълженията за управление на риска в областта на киберсигурността по NIS2. Установете единен процес за оценка на риска за сигурността, обхващащ двете рамки. Осигурете доставчиците на AI софтуер — включително разработчиците на AI модели и доставчиците на данни — да подлежат на изисквания за сигурност на веригата на доставки, съответстващи на Art. 21(2)(d) от NIS2 и Art. 25 от AI Act (задължения относно инструменти на трети страни).

Стъпка 5: Човешки надзор в оперативни контексти

Проектирайте механизми за човешки надзор по Art. 14, оперативно приложими в транспортна среда. За системи за автономно шофиране определете условията, при които водачът трябва да може да поеме управлението (L3) или дистанционен оператор трябва да може да се намеси (L4). За AI в управлението на въздушния трафик посочете точките в работния процес, в които контрольорът трябва да преглежда и одобрява инструкции, генерирани от AI. За AI за поддръжка на железопътния транспорт определете протоколите за ескалация, когато системата сигнализира аномалии, критични за безопасността. Механизмите за надзор трябва да бъдат документирани в техническата документация и отразени в инструкциите за употреба, предоставяни на ползвателите.

Стъпка 6: Мониторинг след пускане на пазара и докладване на инциденти

Установете системи за мониторинг след пускане на пазара, удовлетворяващи едновременно изискванията на Art. 72 от AI Act и секторно специфичните задължения за докладване на безопасността (докладване на произшествия на ERA, докладване на събития на EASA по Регламент (EU) 376/2014, уведомяване за инциденти по NIS2). Сериозни инциденти, включващи високорискови AI системи, трябва да бъдат докладвани на националния надзорен орган за AI по Art. 73 в срок от 15 работни дни от узнаването. Този срок трябва да бъде съгласуван с изискването на NIS2 за първоначално уведомяване в рамките на 24 часа за значими инциденти в областта на киберсигурността, което може да обхваща същото събитие, ако неизправността на AI системата се дължи на нарушение на киберсигурността.