AI Act в ЕС: что нужно знать разработчикам и компаниям
Проверенный разбор AI Act на 3 мая 2026 года: сроки вступления, high-risk и GPAI, роли provider/deployer и практическая ответственность за ошибки ИИ.
Проверено 3 мая 2026 года. AI Act уже действует по частям: запреты на отдельные практики и требования по AI literacy применяются с 2 февраля 2025 года, правила управления и обязанности для моделей общего назначения (GPAI) — с 2 августа 2025 года, а базовый дедлайн для основной массы high-risk требований пока остаётся 2 августа 2026 года.
Для команды, которая продаёт продукт в ЕС или обслуживает европейских пользователей, важны не общие разговоры про «этичный ИИ», а три практических вопроса: попадает ли система в high-risk, кто у вас считается provider и deployer, и кто будет отвечать, если модель ошибётся в продукте. Ниже — карта именно по этим вопросам.
Что уже действует, а что ещё впереди
Регламент вступил в силу 1 августа 2024 года, но применяется по этапам. При этом Еврокомиссия уже признала, что стандарты для high-risk слоя задерживаются: в FAQ и на официальной странице AI Act она прямо пишет про Digital Omnibus proposal, который может сдвинуть применение high-risk правил максимум на 16 месяцев. По состоянию на 3 мая 2026 года это именно proposal, а не вступившее в силу изменение.
- 1 августа 2024 года — AI Act формально вступил в силу.
- 2 февраля 2025 года — начали применяться запреты на отдельные практики и требования по AI literacy.
- 2 августа 2025 года — начали применяться правила управления и обязанности для GPAI-моделей.
- 2 августа 2026 года — базовый дедлайн общей применимости регламента.
- 2 августа 2027 года — отдельный продлённый переходный период для части high-risk систем, встроенных в регулируемые продукты из Annex II.
Какие системы AI Act считает рискованными
AI Act идёт не от отрасли, а от сценария использования. Один и тот же стек может быть почти нерегулируемым в корпоративном поиске и стать high-risk, если тем же движком оценивают кандидатов на работу, кредитоспособность, доступ к лечению или решения в сфере правосудия.
| Блок AI Act | Что сюда попадает | Что требует закон |
|---|---|---|
| Запрещённые практики | Вредоносная манипуляция поведением, social scoring, массовый сбор изображений лиц из интернета и CCTV, emotion recognition на работе и в образовании, часть real-time remote biometric identification для law enforcement. | Полный запрет, кроме узких исключений, прямо описанных в регламенте. |
| High-risk AI systems | Найм и фильтрация резюме, оценка в образовании, кредитный скоринг, pricing в life and health insurance, часть медицинского ПО, отдельные сценарии в law enforcement, justice, migration и critical infrastructure. | Оценка соответствия, требования к данным, документации, traceability, transparency, human oversight, accuracy, cybersecurity и post-market monitoring. |
| Transparency obligations | Чат-боты, deepfakes, часть generative AI и других систем, где пользователь должен понимать, что взаимодействует с ИИ или видит искусственно созданный контент. | Раскрытие искусственной природы взаимодействия или контента и связанные меры прозрачности. |
| Minimal risk | Большая часть обычной автоматизации, спам-фильтры, многие внутренние корпоративные инструменты и рекомендации контента. | Специальных требований AI Act нет, но действует общее право и отраслевые нормы. |
| GPAI models | Модели общего назначения, которые поставляются на рынок ЕС через API, скачивание, облако или встроенный сервис и потом используются как базовый слой в других системах. | Техдокументация, сведения для команд-интеграторов, copyright policy, сводка по обучающим данным; для systemic-risk моделей — дополнительные evaluations, incident reporting и меры кибербезопасности. |
Отдельно важно не переоценивать open-source exemption. Открытая лицензия помогает только частично и не спасает от дополнительных требований, если модель попадает в systemic risk. Этот слой особенно важен тем, кто строит стек на открытых весах или сравнивает открытые и проприетарные модели.
Штрафная рамка у регламента жёсткая: до 35 миллионов евро или 7% мирового оборота за запрещённые практики, до 15 миллионов евро или 3% за остальные нарушения и до 7.5 миллиона евро или 1.5% за ложную или неполную информацию регуляторам. Для SMEs пороги считаются мягче, но логика enforcement от этого не меняется.
Кто в цепочке отвечает за соблюдение требований
В терминах AI Act это не один «владелец ИИ», а цепочка ролей. От того, как вы называете себя в договоре и продуктовой схеме, зависит не только бумажная работа, но и то, кто первым получит вопросы от регулятора или корпоративного клиента.
Provider high-risk system. Это тот, кто выводит систему на рынок или вводит её в эксплуатацию под своим именем. Для high-risk систем на provider ложатся оценка соответствия (conformity assessment), система управления качеством, регистрация в базе ЕС, отчёты об инцидентах, корректирующие меры и поддержание соблюдения требований на всём жизненном цикле системы.
Provider GPAI-модели. Если вы выводите модель общего назначения на рынок ЕС через API, скачивание, облако или встроенный сервис, нужно вести техдокументацию, передавать командам-интеграторам сведения о возможностях и ограничениях модели, соблюдать copyright policy и публиковать достаточно подробную сводку по обучающим данным. Для моделей с systemic risk добавляются model evaluations, incident reporting и меры кибербезопасности.
Deployer. Это компания, которая использует систему у себя в процессе или сервисе. Deployer обязан работать по instructions for use, мониторить систему, реагировать на риски и серьёзные инциденты, назначить человека для human oversight, а при подаче собственных входных данных следить, чтобы они были релевантны и достаточно репрезентативны. Для части public-sector кейсов нужен ещё и fundamental rights impact assessment до первого запуска.
Если вы просто покупаете чужую модель по API, ответственность не исчезает. Провайдер модели отвечает за свой GPAI-слой, но интерфейс, промпт-обвязка, сценарий принятия решения, логи, уведомления пользователю и human oversight остаются на стороне deployer. Именно здесь чаще всего и происходит юридический сбой.
Где начинается ответственность за ошибку модели
AI Act не решает за суды все вопросы гражданской ответственности. Он делает другое: жёстко раскладывает обязанности по цепочке. В реальном инциденте дальше включаются ещё договоры, потребительское право, отраслевые нормы и правила о вреде. Поэтому вопрос звучит не «кто виноват вообще», а «кто контролировал конкретный этап и кто извлёк выгоду из запуска системы».
- Проблема в базовой модели. Если сбой связан с недокументированными ограничениями, системным риском или отсутствующей техдокументацией, первый вопрос идёт к provider.
- Проблема во внедрении. Если систему поставили вне предусмотренного сценария, без human oversight или на нерепрезентативных данных, линия риска быстро переходит к deployer.
- Проблема в пользовательском контуре. Если человеку не сказали, что он общается с ИИ, или продали «автономность», которой фактически нет, это обычно уже зона оператора сервиса, а не абстрактного поставщика модели.
Хороший ориентир даёт дело Moffatt v. Air Canada, 2024 BCCRT 149. Канадский tribunal обязал Air Canada компенсировать пассажиру разницу в тарифе после того, как чат-бот на сайте дал неверную информацию о bereavement fare. Логика для продуктовых команд неприятная, но полезная: компания не смогла спрятаться за аргументом «это сказал бот, а не мы». Для пользователя бот был частью сервиса Air Canada, значит и ответственность осталась у оператора сервиса.
Второй практический пример — документ NHTSA по расследованию EA22002. В нём агентство зафиксировало, что Tesla сама подала recall 23V838, потому что controls Autopilot в ряде случаев были недостаточны для driver assistance system, требующей постоянного человеческого надзора. Для AI Act это хороший маркер: human oversight нельзя написать в документации и забыть. Если система по факту провоцирует disengagement или создаёт ложное ощущение автономности, вопрос быстро переходит из продуктового интерфейса в regulatory risk.
Практический вывод здесь простой: пользователю, регулятору и суду обычно всё равно, сколько подрядчиков, open-source слоёв и API-обвязок стоит под капотом. Они смотрят, кто вывел систему на рынок, кто встроил её в решение и кто должен был обеспечить понятные ограничители.
Чеклист для команды до 2 августа 2026 года
- Зафиксируйте карту ролей: кто в вашей схеме provider, кто deployer, кто authorised representative в ЕС и где это отражено в договорах и продуктовой документации.
- Перепроверьте сценарии по Annex III и связанным отраслевым нормам. Самый частый баг здесь — считать продукт «обычной автоматизацией», хотя отдельный модуль уже решает high-risk задачу.
- Поставьте честное disclosure в user-facing точках: чат-бот, генеративный ответ, synthetic media, assisted decision workflow.
- Для high-risk сценариев назначьте ответственного за human oversight, логирование, incident response и проверку входных данных на релевантность и репрезентативность.
- Запросите у модельного поставщика техдокументацию, описание ограничений, copyright policy и сводку по обучающим данным. Если поставщик вне ЕС, отдельно проверьте authorised representative.
- Перепроверьте тексты на сайте, демо и скрипты продаж. Нельзя обещать «полную автономность» там, где закон и реальный риск требуют человеческого надзора.
- Если вы работаете в public-sector или решаете вопросы, затрагивающие права человека, заранее готовьте маршрут для explanation requests и, где нужно, fundamental rights impact assessment.
Что это значит для российских команд
Если продукт не работает на рынок ЕС и не обслуживает европейских пользователей, AI Act не создаёт для вас автоматической прямой обязанности. Но на практике корпоративные клиенты, интеграторы и международные партнёры всё равно начнут задавать те же вопросы: кто отвечает за модель, как устроен human oversight, какие ограничения известны заранее и как вы работаете с авторским правом. По этой линии регуляторная логика ЕС быстро становится коммерческим стандартом.
Если же вы продаёте SaaS в ЕС, подключаете европейских резидентов или используете зарубежную модель в чувствительном процессе, откладывать этот разговор уже поздно. Сначала нужна карта ролей и аудит продукта, потом — маркетинговые обещания. Отдельно полезно сверить связанный слой по авторскому праву и ИИ, потому что для GPAI copyright obligations теперь часть того же compliance-пакета.
Источники и дата проверки
Материал обновлён 3 мая 2026 года по официальным страницам Еврокомиссии и публичным документам регуляторов. Базовый календарь, роли provider/deployer, штрафы и требования для GPAI сверялись по официальной странице AI Act, FAQ Navigating the AI Act и guidelines on obligations for GPAI providers. Примеры практической ответственности дополнительно сверялись по Moffatt v. Air Canada и документу NHTSA по EA22002.
Читайте также:
