Регламент Европейского союза об искусственном интеллекте достигает общей даты применения 2 августа 2026 года. Для разработчика это не означает, что нужно добавить одинаковый значок «создано ИИ» на каждый экран. Нужно описать каждую AI-систему, определить provider и deployer, показать уведомление Article 50 в пользовательском потоке, сохранить сигналы для прослеживаемости и дать уполномоченному человеку реальный способ вмешаться. В этой статье такая инженерная работа сопоставлена с консолидированным текстом Регламента (EU) 2024/1689 на EUR-Lex и рекомендациями Комиссии по Article 50, проверенными 28 августа 2026 года.
Это техническое руководство, а не юридическая консультация. AI Act содержит правила, зависящие от роли, назначения системы, способа использования и отрасли. Команде всё равно нужно проверить факты, применимое национальное право, обязанности по защите данных и компетентный орган. Приведённые ниже решения являются инженерными шаблонами, а не юридической классификацией вашего продукта.
Даты, которые меняют план разработки
Обязанности по прозрачности Article 50 применяются с 2 августа 2026 года. Для provider генеративной AI-системы, размещённой на рынке до этой даты, предусмотрен ограниченный переходный период по обязанности Article 50(2) маркировать и обеспечивать обнаружение контента, до 2 декабря 2026 года. Комиссия указывает, что контент, созданный и уже доступный до 2 августа, не нужно маркировать задним числом. Этот переходный период не отменяет остальные обязанности Article 50, действующие для подпадающей под статью системы с 2 августа. Зафиксируйте две даты как разные контрольные точки релиза.
Другие даты легко перепутать. Запреты, определения и положения об AI-грамотности начали применяться 2 февраля 2025 года. Правила управления и обязанности для моделей общего назначения начали применяться 2 августа 2025 года. Согласно изменённой Article 113, требования к системам высокого риска из Chapter III, Sections 1–3 применяются к системам Annex III по Article 6(2) с 2 декабря 2027 года, а к связанным с продуктами системам по Article 6(1) и Annex I с 2 августа 2028 года. Provider и deployer высокорисковых систем, предназначенных для государственных органов, должны принять необходимые меры до 2 августа 2030 года. Эти даты не оправдывают откладывание защитных мер, но Article 12 не является общей обязанностью вести логи для каждого чатбота в августе 2026 года.
Для проверки календаря используйте актуальный обзор AI Act Комиссии. Перед релизом снова сверяйте консолидированный текст EUR-Lex, поскольку последующие акты или национальные меры могут изменить работу для конкретной системы.
Сначала определите роль и юрисдикцию
Article 2 охватывает provider, который размещает AI-систему или модель общего назначения на рынке Союза либо вводит её в эксплуатацию в Союзе, независимо от места регистрации в Союзе или третьей стране. В сферу входят deployer, находящийся в Союзе, а также provider или deployer из третьей страны, если результат системы используется в Союзе. В статье также перечислены импортёры, дистрибьюторы, изготовители продуктов и уполномоченные представители. Article 2 исключает области вне права Союза и системы, используемые исключительно в военных, оборонных целях или для национальной безопасности.
По Article 3 provider — это организация, которая разрабатывает или заказывает разработку AI-системы и размещает её на рынке либо вводит в эксплуатацию под собственным названием или товарным знаком. Deployer использует AI-систему под своим контролем, кроме личного непрофессионального использования. Облачный поставщик может быть provider модели, а ваша компания — deployer агента, вызывающего эту модель. Если компания ставит своё имя, существенно изменяет высокорисковую систему или меняет назначение так, что система, ранее не считавшаяся высокорисковой, становится такой, Article 25 может сделать компанию provider этой системы. Зафиксируйте решение по цепочке создания, а не предполагайте, что все обязанности принадлежат поставщику API.
Создайте строку реестра для каждой пользовательской системы и каждой повторно используемой модели или службы. Укажите provider, deployer, назначение, рынки, модальности, прямое взаимодействие с человеком, оценку риска, версии, интеграции и утвердившего сотрудника. Короткая схема потока данных полезнее продуктового ярлыка:
человек -> интерфейс -> уведомление о системе -> адаптер модели -> политика вывода
-> метка происхождения -> ярлык или проверка -> публикация
-> хранилище событий -> мониторинг и реагирование
У Article 50 четыре разные инженерные поверхности
FAQ Комиссии по Article 50 разъясняет сферу применения и примеры. Реализуйте обязанности раздельно.
| Поверхность AI Act | Ответственная роль | Минимальное последствие для продукта |
|---|---|---|
| Прямое взаимодействие | Provider | Сообщить человеку, что он взаимодействует с AI, если это не очевидно из контекста. |
| Синтетический звук, изображение, видео или текст | Provider | Добавить машиночитаемую метку, позволяющую обнаружить искусственное создание или изменение. |
| Воздействие распознавания эмоций или биометрической категоризации | Deployer | Уведомить людей, подвергшихся операции, и обрабатывать персональные данные по применимым правилам Союза. |
| Deepfake или сгенерированный текст о вопросе общественного интереса | Deployer | Дать ясное различимое раскрытие при первом воздействии с учётом исключений Article 50(4). |
Уведомление в чатботе и агенте
Рекомендации Комиссии описывают четыре совокупных условия обязанности Article 50(1): система является AI-системой, предназначена для настоящего двустороннего обмена, AI общается напрямую, а не через человека-посредника, и другой стороной является физическое лицо. Фоновая служба, общающаяся только с другой службой, отличается от агента поддержки, который передаёт клиенту поток текста. Исключение «это очевидно» следует трактовать узко, поскольку оно лишает человека информации.
Показывайте уведомление до первого токена модели. Оно должно быть видно в расшифровке, доступно вспомогательным технологиям и сохраняться при вызове инструмента или передаче диалога человеку. Формулировка «Вы взаимодействуете с AI-ассистентом» яснее названия бренда или похожего на человека аватара. Сохраняйте версию уведомления и результат отображения в аудиторском событии. В голосовом интерфейсе сообщайте об AI до начала обмена. Последующая проверка человеком не отменяет первоначальную обязанность уведомить.
Синтетический контент и происхождение
Article 50(2) возлагает обязанность маркировки на provider, включая provider системы общего назначения, создающей синтетический звук, изображение, видео или текст. Метка должна быть машиночитаемой и позволять обнаружить искусственное создание или изменение. Техническое решение должно быть эффективным, совместимым, устойчивым и надёжным настолько, насколько это технически возможно, с учётом типа контента, стоимости и современного уровня техники. Один видимый значок не является машиночитаемой меткой, а одна машиночитаемая метка не заменяет видимое раскрытие deployer для deepfake.
Исключения охватывают вспомогательную функцию стандартного редактирования, результат без существенного изменения входа deployer или его смысла, а также системы, разрешённые законом для обнаружения, предотвращения, расследования или преследования преступлений. Рекомендации Комиссии обсуждают более узкие примеры машинного обмена и замкнутого производственного процесса. Не превращайте их в общее исключение для внутренних инструментов. Сохраните решение о сфере применения и его владельца.
Deepfake и текст об общественном интересе
Deployer должен раскрывать AI-сгенерированное или изменённое изображение, аудио или видео, являющееся deepfake. Комиссия описывает deepfake через сходство с существующим или правдоподобно существующим человеком, объектом, местом, сущностью или событием и ложное впечатление подлинности или истинности. Раскрытие должно восприниматься без специального инструмента или дополнительного действия. Разместите слова «создано или изменено AI» рядом с медиа, в его доступном имени или в звуковом сообщении при первом воздействии. Для явно художественного, сатирического или вымышленного произведения можно сообщить только о наличии созданного контента, не мешая просмотру.
Отдельное правило для текста действует, когда созданный или изменённый текст публикуется для информирования общества о вопросе общественного интереса. Примеры включают политику, государственное управление, правосудие, основные права, общественную безопасность, здоровье, окружающую среду, безопасность потребителей, а также экономические, финансовые, научные и культурные события. Исключение Article 50(4) требует проверки человеком или редакционного контроля и наличия физического или юридического лица, несущего редакционную ответственность. Проверка орфографии не считается такой проверкой. Если команда не может показать содержательную проверку и ответственность, оставьте ясную метку.
Логи без сбора всего подряд
Article 12 применяется к высокорисковым AI-системам тогда, когда начинают действовать соответствующие требования Chapter III. Система должна технически поддерживать автоматическую запись событий на протяжении жизненного цикла. Логи должны обеспечивать прослеживаемость, соответствующую назначению, включая поиск ситуаций, создающих риск или существенное изменение, пострыночный мониторинг по Article 72 и мониторинг работы по Article 26(5). Для высокорисковой удалённой биометрической идентификации из Annex III, point 1(a), Article 12 добавляет минимальные поля: период использования, справочную базу, вход, давший совпадение, и лиц, проверивших результат.
Article 19 требует от provider хранить автоматически созданные логи, находящиеся под его контролем, в течение срока, соответствующего назначению системы, но не менее шести месяцев, если право Союза или национальное право, особенно законодательство о данных, не устанавливает иное. Article 26(6) устанавливает тот же минимум для логов под контролем deployer. Это не разрешение хранить исходные диалоги бессрочно. Определите класс хранения, ограничьте доступ, шифруйте хранилище событий и отделите телеметрию от содержания. Хешируйте или редактируйте входы и выходы, когда исходные данные не нужны. Поля, позволяющие идентифицировать человека, должен утвердить ответственный за защиту данных.
Полезная оболочка события может выглядеть так:
{
"trace_id": "tr_7f3c",
"system_version": "agent-2026.08.28",
"model_id": "model-release",
"actor_role": "deployer",
"content_class": "text",
"mark_applied": true,
"label_shown": true,
"human_review": "not_required",
"override": false,
"created_at": "2026-08-28T12:00:00Z"
}
Это пример идентификаторов, а не предписанная ЕС-схема. Свяжите уведомление, версию модели, обработку вывода, решение человека и публикацию, не помещая секреты или полную расшифровку в каждый лог. Для высокорискового использования дайте provider и deployer возможность получать, интерпретировать и связывать события. В руководстве по наблюдаемости AI-агента описаны трассировки, метрики и редактирование данных.
Human oversight должен работать на практике
Article 14 относится к высокорисковым системам. Provider должен проектировать их, включая подходящие инструменты взаимодействия человека и машины, так, чтобы физические лица могли эффективно контролировать систему во время использования. Меры должны соответствовать риску, автономности и контексту. Article 14 требует, чтобы человек мог понимать ограничения, находить аномалии и неожиданное поведение, замечать автоматическое доверие к результату, интерпретировать его, игнорировать или отменять и остановить систему кнопкой или аналогичной процедурой, переводящей её в безопасное состояние.
Article 26 требует от deployer назначить для контроля людей с нужными компетенциями, обучением, полномочиями и поддержкой. Фраза «кто-то посмотрел» не является контролем, если сотрудник не видит доказательства, не может отклонить рекомендацию или остановить действие. Поместите границу одобрения до необратимого побочного эффекта. Показывайте результат модели, важные входы, ограничения системы, проверки политики и точное последующее действие. Разделите отклонение, редактирование, эскалацию и остановку. Фиксируйте исполнителя и причину, не превращая проверяющего в формальную печать.
Для высокорисковых систем из Annex III, point 1(a), Article 14(5) требует отдельной проверки и подтверждения результата как минимум двумя компетентными, обученными и уполномоченными физическими лицами до действия deployer на основе идентификации, с отдельным исключением соразмерности для правоохранительной деятельности, миграции, пограничного контроля и убежища в праве Союза или национальном праве. Это специальное правило, а не универсальная обязанность двух проверяющих для каждого вывода AI.
Реализуемый поток данных
Оставьте контроль в детерминированных службах вокруг модели. Шлюз взаимодействия отвечает за уведомление при первом использовании и локаль. Адаптер модели записывает версию и нормализует метаданные provider. Сервис вывода определяет модальность и назначение, применяет или проверяет машиночитаемую метку и решает, нужен ли видимый ярлык или содержательная проверка человеком. Политический шлюз блокирует публикацию без нужного сигнала. Сервис согласования хранит проверяющего, решение, срок действия и путь остановки. Хранилище событий получает минимальную связанную запись. Сервис мониторинга ищет пропавшие уведомления, ошибки меток, непроверенный текст об общественном интересе, неожиданные вызовы инструментов и сбои остановки.
Не прячьте эти проверки в промпте. Только интерфейс гарантирует уведомление до потока ответа, а только конвейер вывода сохранит метку при экспорте. Для разрешений агента и недоверенного результата инструмента используйте руководство по prompt injection и безопасности MCP. Для раздельных границ оркестрации, политики и побочных эффектов смотрите руководство по production-архитектуре AI-агента.
Мониторинг и ритм обновлений
Считайте Article 50 инвариантом релиза. Каждый build, меняющий модель, системный промпт, интерфейс, отображение вывода, экспорт или локализацию, должен проверять уведомление при первом взаимодействии, сохранность машиночитаемой метки после скачивания и преобразования, видимое раскрытие deepfake и невозможность опубликовать текст об общественном интересе без настроенной проверки или метки. Проверяйте клавиатуру, скринридер, мобильный, голосовой и API-клиент: Article 50(5) требует ясной различимой информации с учётом применимых требований доступности.
В работе поднимайте тревоги по отсутствующему уведомлению, ошибке происхождения, удалённой преобразованием метке, публикации без human_review, проверяющему без полномочий или остановке, не приводящей систему в безопасное состояние. Еженедельно просматривайте выборку трасс. Ежемесячно проверяйте хранение, доступ, обучение и изменения модели или provider. Ежеквартально проводите документированный обзор риска и потока данных. Немедленно пересматривайте систему после серьёзного инцидента, выпуска provider, новой модальности, изменения назначения, существенной модификации или новой рекомендации Комиссии.
Такой ритм является инженерной практикой, а не установленным законом интервалом. Для высокорисковых систем согласуйте управление рисками и пострыночный процесс с Articles 9 и 72. Article 112 предусматривает оценку возможных изменений списка Article 50 к 2 августа 2028 года и затем каждые четыре года. Ведите реестр источников с консолидированным текстом EUR-Lex, рекомендациями Комиссии, статусом code of practice и ответственным национальным органом.
Чеклист перед релизом
- Запишите provider, deployer, назначение, связь с Союзом, модальности, пользователей и направления вывода.
- Определите применимый пункт Article 50 и сохраните доказательства исключений.
- Покажите уведомление о прямом взаимодействии до первого токена и проверьте доступность.
- Примените машиночитаемую метку на границе provider и проверьте её после экспорта.
- Добавьте раскрытие deepfake и путь для текста об общественном интересе при первом воздействии.
- Определите содержательную проверку, редакционную ответственность, полномочия, отмену и безопасную остановку.
- При высокорисковом статусе реализуйте запись событий, владение, доступ, хранение и эскалацию.
- Свяжите каждый релиз с записями модели, политики, метки, проверяющего и мониторинга.
- Сверяйте официальные источники Комиссии и EUR-Lex перед существенным релизом и после изменений.
Официальные источники этого руководства: консолидированный Regulation (EU) 2024/1689, рекомендации Комиссии по Article 50, FAQ по Article 50, календарь AI Act и краткие факты о прозрачности. Определяющими являются текст закона и рекомендации Комиссии. Эта статья не заменяет юридическую, privacy или отраслевую консультацию.