Какво изисква Законът за изкуствения интелект на ЕС и как Docker подпомага съвместимостта

Публикувано от Svetni.me Editorial на 27 юни 2026 г.

В официално изявление на корпоративния си блог, технологичният гигант Docker представи обстоен анализ на новите регулаторни изисквания, наложени от Закона за изкуствения интелект на ЕС (EU AI Act), и очерта практически стъпки, с които софтуерните инженери и организациите могат да гарантират техническо съответствие на своите системи [1]. Законът за изкуствения интелект на ЕС (Регламент (ЕС) 2024/1689) влезе в сила през август 2024 г., като неговите изисквания се въвеждат поетапно до 2027 г. Регламентът има екстратериториално действие – той засяга всеки доставчик или потребител, чиито AI системи се предлагат, внедряват или техните резултати се използват на пазара в ЕС, независимо от местоположението на централата на компанията [1].

Четирите нива на риск и техните изисквания

Правната рамка на ЕС прилага подход, базиран на риска, като разделя изкуствения интелект на четири нива, всяко от които носи различни правни задължения:

  1. Неприемлив риск (Забранени практики): Тези системи са напълно забранени съгласно Член 5 от февруари 2025 г. [1]. Списъкът включва технологии за подсъзнателна манипулация, експлоатация на уязвимости (възраст, увреждания), социално оценяване (social scoring), предсказваща полицейска дейност въз основа на профилиране, нерегламентирано извличане на биометрични данни от интернет или камери за видеонаблюдение, разпознаване на емоции на работното място и в училищата, както и биометрична идентификация в реално време на обществени места (с изключение на тесни случаи, свързани с националната сигурност и разследване на тежки престъпления).
  2. Висок риск (Регулирани системи): Това ниво обхваща критични сектори като здравеопазване, критична инфраструктура, образование, заетост, правоприлагане, контрол на границите и правосъдие. Тези системи подлежат на най-строги изисквания за тестване, верификация и прозрачност. Важно техническо изискване е автоматизираното генериране на одитни логове и подробна документация. Член 25 от регламента указва, че всеки оператор по веригата за доставка, който постави името си върху високорискова система или я модифицира съществено, бива прекласифициран като „доставител“ (provider) и поема пълната отговорност за нейното съответствие [1].
  3. Ограничен риск (Изисквания за прозрачност): Системите в тази категория (като чатботове, генеративни модели и дълбоки фалшификати) трябва ясно да информират потребителите, че взаимодействат с AI. Всички генерирани синтетични материали трябва да бъдат маркирани в машинночетим формат.
  4. Минимален риск (Нерегулирани системи): Огромната част от използваните приложения (като спам филтри или игри) попадат тук. За тях не се налагат законови задължения, но се насърчава доброволното спазване на етични кодекси за поведение [1].

Актуална хронология на съвместимостта

Въвеждането на регулациите се осъществява на етапи, които наскоро бяха прецизирани с одобрението на пакета „Дигитален Омнибус“ от Европейския парламент на 16 юни 2026 г. [1]. Актуалният график на изискванията включва:

  • 1 август 2024 г.: Влизане в сила на регламента.
  • 2 февруари 2025 г.: Забрана на системите с неприемлив риск и начало на задълженията за AI грамотност (Член 4).
  • 2 август 2025 г.: Приложимост на правилата за моделите с общо предназначение (GPAI), установяване на органите за управление и стартиране на наказателните разпоредби.
  • 2 август 2026 г.: Основна дата на приложение. Влизат в сила задълженията за прозрачност по Член 50 (маркиране на синтетично съдържание и deepfakes), а държавите членки трябва да осигурят поне една работеща регулаторна пясъчница (sandbox) [1].
  • 2 декември 2026 г. (Омнибус корекция): Край на гратисния период за машинночетимо маркиране на системи, пуснати на пазара преди август 2026 г.
  • 2 август 2027 г.: Изискванията стават задължителни за високорискови системи, вградени в продукти, които подлежат на съществуващо продуктово законодателство (съгласно Анекс I).
  • 2 декември 2027 г. (Омнибус корекция): Отложеното влизане в сила за самостоятелните високорискови системи по Анекс III (първоначално планирано за август 2026 г., но удължено, за да се даде време на пазара за адаптиране) [1].
  • 2 август 2028 г. (Омнибус корекция): Изисквания за компоненти от продукти, попадащи под продуктовата безопасност на Анекс I.

Отговорности по роли: Доставчици и внедряващи лица

Регламентът ясно разграничава задълженията според ролята на организацията. Доставчиците (providers) носят най-голяма тежест, включително поддържане на система за управление на риска през целия жизнен цикъл на продукта, строго управление на данните за обучение (съвместимо с GDPR), изготвяне на техническа документация (Анекс IV), съхраняване на записи в продължение на 10 години, осигуряване на киберсигурност и извършване на оценка на съответствието (conformity assessment) с поставяне на CE маркировка [1].

Внедряващите лица (deployers) – организациите, които интегрират и използват тези системи за професионални нужди – трябва да спазват инструкциите на доставчика, да осигурят компетентен човешки надзор, да контролират входните данни, да съхраняват автоматично генерираните логове поне 6 месеца и да информират засегнатите служители и потребители [1]. Член 27 налага и извършването на Оценка на въздействието върху основните права (Fundamental Rights Impact Assessment - FRIA) от страна на държавни органи или финансови институции, използващи високорискови модели [1].

Технически мерки за инженерните екипи

Преводът на сложния юридически език в практически ИТ контроли изисква промени в жизнения цикъл на разработката (CI/CD) и киберсигурността на organisations [1]:

  1. Инвентаризация и класификация: Първата стъпка е описването на всяка AI система и свързването ѝ с регистрите по GDPR, за да се проследи обработката на лични данни.
  2. Одитни логове (Audit Trails): Изисква се структуриран запис на действията на автономните агенти: времеви клейма, контекст на сесията, извикани инструменти и идентичност на услугата [1]. Тези данни трябва да се експортират към SIEM системи.
  3. Софтуерен опис на материалите (SBOM): За да се осигури съответствие, екипите трябва да внедрят софтуерен опис на материалите (SBOM), който да документира пълния състав от библиотеки, зависимости и модели, намалявайки риска от атаки по веригата за доставки [1].
  4. Изолирана среда за изпълнение (Runtime Isolation): Човешкият надзор и ограничаването на щетите при неочаквано поведение на автономни агенти се постигат чрез пускането им в изолирани среди (sandboxes). Това ограничава мрежовия достъп и файловите нива на права [1].
  5. Инструменти за съвместимост: Европейската комисия предостави инструменти като официалния Compliance Checker на своя Service Desk за тестване на съответствието на системите.

[Схема за съвместимост с Docker]
Авторско изображение

Внедряване на съответствието с Docker AI Governance

Docker предлага практическо решение чрез своята инициатива за управление на изкуствения интелект (Docker AI Governance), подпомагаща операционализирането на тези изисквания [1]. Инструментът не изземва юридическата отговорност от компаниите, но предоставя инфраструктурни контроли: sandbox изолация на ниво контейнери за ограничаване на потенциални щети от неоторизиран достъп, дефиниране на политики за мрежа, файлови системи и достъп до MCP инструменти, както и подробни структурирани одитни логове за бърз анализ [1]. Важно е да се отбележи, че клиентските конфигурации и телеметрия не се използват за обучение на външни или вътрешни модели на Docker.

Изграждането на регулаторно съответствие не е еднократна задача, а непрекъснат процес на управление (governance), който трябва да бъде заложен в самата архитектура на внедряваните AI решения [1].

Източници

[1]: What Does EU AI Act Compliance Require? - Docker Blog