Назад в блог

EU AI Act для AI-агентов: что требует закон в 2026–2028

Применяется ли EU AI Act к вашим агентам: 4 уровня риска, provider vs deployer, 6 блоков governance и сдвинутые дедлайны Omnibus до 2027–2028.

Иллюстрация к материалу: EU AI Act для AI-агентов: что требует закон в 2026–2028

EU AI Act вступил в силу в 2024 и применяется экстерриториально: если вывод агента используется в ЕС — вы в scope, где бы ни был хостинг. С 2 августа 2026 уже действует Article 50, а high-risk требования сдвинуты Omnibus-пакетом на 2027–2028. Для агентов это не новый закон, а применение существующей лестницы риска.

Применяется ли к вам

Два вопроса. Первый — reach: провайдер или деплоер с пользователями/выводом в ЕС — в scope (Article 2). Self-hosted агент в компании из ЕС — тоже. Второй — tier риска. Act не имеет главы про агентов, он классифицирует AI-системы по риску применения, и агент попадает туда же.

4 уровня риска (и куда попадают агенты)

TierПримеры агентовЧто требуется
ProhibitedСоциальный скоринг, манипуляцииЗапрещено
High-riskHR-скрининг, кредит, критическая инфраструктура, safety-компоненты (Annex I/III)Полный набор: логи, риск-менеджмент, human oversight, документация, CE, регистрация
Limited-riskЧат-боты, бизнес-ассистенты, суммаризация тикетовПрозрачность (сообщить что это AI, маркировка synthetic)
Minimal-riskВнутренние утилиты без влияния на людейБез специфичных обязательств

Большинство внутренних агентов (поиск по своим данным, черновики) — limited/minimal. Агент становится high-risk из-за задачи: оценивает кандидатов, готовит кредитное решение, триажит заявки на essential services — тогда дорога к 2 декабря 2027.

Provider vs deployer — кто отвечает

  • Provider — разрабатывает агента (или заказывает) и выводит на рынок/в эксплуатацию под своим именем.
  • Deployer — использует чужого агента под своей ответственностью.
  • Article 25 — ребрендинг, существенная модификация или смена назначения на high-risk делает вас provider’ом.
  • Третья сторона (Article 25(4)) — поставщик инструментов/компонентов для high-risk системы обязан по договору дать информацию и доступ для комплаенса.

На практике: лаборатория дает модель, платформа — framework, вы — промпты/инструменты/данные. Зафиксируйте в контракте кто provider/deployer по каждому агенту до инцидента — потом спор дороже.

High-risk: 6 блоков governance

Если агент high-risk, требуется:

  1. Scoped permissions — least privilege per agent.
  2. Human oversight (Article 14) — человек понимает, может вмешаться и остановить. Выбор: human-in-the-loop (одобряет каждое действие) vs human-on-the-loop (мониторит и перехватывает).
  3. Logging (Article 12) — автоматические логи за весь жизненный цикл, хранение минимум 6 месяцев, достаточные для реконструкции. Это audit trail.
  4. Kill switch + инцидент-процесс — протестированная остановка и план реагирования.
  5. Periodic review — поведение и классификация пересматриваются, задача дрейфует.
  6. AI register — каждый агент с целью, моделью, инструментами, владельцем, oversight-моделью и ролями.

Сюда же: Article 11 — техдокументация до вывода на рынок, Article 9 — risk management system, FRIA (Article 27) для публичного сектора/кредита/страхования и DPIA по GDPR где есть персоналка.

Даты: что уже, что сдвинуто

  • 2.02.2025 — Chapters I–II (запрещенные практики).
  • 2.08.2025 — Chapter III Section 4, Chapter V, VII, XII (часть).
  • 2.08.2026 — применяется Act в целом, включая Article 50 (прозрачность для прямого взаимодействия и маркировка synthetic). Это уже сейчас.
  • Omnibus 06.2026 сдвиг: Annex III high-risk (use-based) — с 2.08.2026 на 2.12.2027, Annex I (product safety) — на 2.08.2028. GPAI-модели — отдельный график. Даты уже двигали раз, стройте на требования, а не на дедлайн.

Где Codenik маппится на Act

Codenik как managed access layer закрывает 4 из 6 блоков из коробки: scoped permissions через gateway, human-in-the-loop/on-the-loop для необратимых действий, логи по Article 12 (кто/что/когда/чем вызвано, 6+ месяцев, tamper-evident), kill switch через мгновенный отзыв NHI и сессий. Реестр агентов с владельцами и oversight-моделью — тот же fleet control plane. Это не сертификат соответствия, но архитектурный фундамент чтобы high-risk агенты прошли conformity assessment без ретрофита.

Короткий вывод

Классифицируйте каждый агент по задаче, а не по модели. Для high-risk — включите 6 блоков сейчас: права, человек, логи, kill switch, ревью, реестр. Тогда сдвиг дедлайна даст время на глубину, а не на панику.

Источники и дальнейшее чтение