EU AI Act после Omnibus: что разработать до декабря 2026

Сдвинулись сроки для высокорисковых систем. Остальные даты 2026 года остались на месте. Регламент (ЕС) 2026/1744, Digital Omnibus on AI, датирован 8 июля 2026 года. В Official Journal его опубликовали 24 июля, а в силу он вступил 27 июля, за шесть дней до прежнего срока 2 августа 2026 года. Обязанности для высокорисковых сценариев из Приложения III (найм, кредитный скоринг и подобные) теперь действуют с 2 декабря 2027 года. ИИ, встроенный в регулируемые продукты по Приложению I, подчиняется требованиям с 2 августа 2028 года. Прозрачность по статье 50, то есть чат-боты, агенты и генераторы контента, действует с 2 августа 2026 года. У генеративных систем, выведенных на рынок до этой даты, есть время до 2 декабря 2026 года, чтобы добавить машиночитаемую маркировку; в тот же день начинают действовать два новых запрета.

Требования к высокорисковым системам легче не стали. Они получили фиксированную более позднюю дату вместо условного триггера, который сначала предлагала Еврокомиссия (Gibson Dunn, 27 мая 2026 года). Малые и средние компании и новая категория «small mid-cap» (до 750 сотрудников) могут подавать техническую документацию в упрощённой форме (Orrick).

Многие материалы, написанные в 2025 и начале 2026 года, до сих пор ставят все обязанности на 2 августа 2026 года; для высокорисковых систем это теперь просто неверно.

Дальше — инженерное прочтение текста. Это не юридическая консультация.

Все даты, которые мы отслеживаем, и работа, которую каждая из них запускает. Две строки 2026 года — это код, который выходит в этом году. Строки 2027 и 2028 годов — архитектурные решения: встраивать логирование и человеческий контроль в уже работающую систему дороже, чем закладывать их с самого начала.

Если результат работы ИИ используется в ЕС, Act применяется. Статья 2(1)(a) охватывает провайдеров, выводящих ИИ-системы на рынок ЕС, «независимо от того, учреждены ли эти провайдеры или находятся в Союзе или в третьей стране». Статья 2(1)(c) распространяется на провайдеров и deployer из третьих стран, «если результат, созданный ИИ-системой, используется в Союзе». Американская SaaS-компания с клиентами в ЕС подпадает под статью 50 с первого же разговора с европейским пользователем, как и швейцарский страховщик, чей чат-бот отвечает немецким клиентам.

Бесплатная система или платная, значения не имеет, говорится в руководстве Еврокомиссии по статье 50. Непредвиденное последующее использование само по себе не должно затрагивать провайдера из третьей страны, который не выводил систему на рынок ЕС. Это исключение узкое: если вы продаёте покупателям в ЕС, вы внутри.

Когда мы оцениваем ИИ-функцию, классификация проходит на этапе discovery, до того как кто-то напишет смету. От ответа зависит содержимое бэклога: от одного компонента с уведомлением до полного досье на соответствие. Пять вопросов, всегда в этом порядке, ответы записываются в карточку функции в реестре.

1. Провайдер или deployer? Провайдер тот, кто выпускает систему под своим именем, в том числе компания, которая запускает внутреннего чат-бота для собственных нужд. Когда мы делаем систему для клиента, провайдером обычно становится клиент.
2. Запрещена ли она? Смотрим статью 5. С 2 декабря 2026 года в этот список входят и системы, создающие интимные изображения узнаваемого человека без его согласия, а также CSAM. Функции работы с изображениями и видео проходят эту проверку каждый раз.
3. Приложение III? Сверяем назначение системы с восемью областями. Чаще всего в наших разговорах на discovery всплывают отбор откликов и оценка кандидатов (пункт 4(a)), кредитоспособность и кредитные рейтинги (пункт 5(b), кроме выявления мошенничества), приём и оценка знаний в образовании (пункт 3).
4. Работает ли исключение из статьи 6(3)? Кандидаты на исключение: узкая процедурная задача, улучшение уже выполненной человеком работы, выявление отклонений от прежних решений, подготовительная задача. Профилирование физических лиц всегда считается высоким риском. Если провайдер опирается на исключение, он документирует оценку до запуска (статья 6(4)). Обязанность регистрировать такие самооцениваемые системы пережила Omnibus «с меньшей административной нагрузкой» (Freshfields).
5. Общается ли она с людьми или генерирует контент? Тогда применяется статья 50. Если все пять ответов отрицательные, функция относится к минимальному риску и не добавляет в работу ничего по AI Act.

Больше всего мы следим за дрейфом. Чат-бот HR-платформы отвечает кандидатам на вопросы об открытых вакансиях: статья 50, одна строка уведомления. Позже владелец продукта просит кнопку «отранжировать эти резюме по описанию вакансии». Эта кнопка попадает ровно в Приложение III, пункт 4(a), где названы системы, используемые «для анализа и фильтрации откликов на вакансии и оценки кандидатов». Ранжирование людей по резюме — это профилирование, поэтому исключение 6(3) не спасёт. Статья 25(1)(c) делает того, кто изменил назначение системы, провайдером высокорисковой системы. Когда приходит такая задача, мы останавливаемся и классифицируем её заново как отдельную систему со своей записью в реестре и своим планом логирования. Deployer такой системы обязан хранить логи не менее шести месяцев (статья 26(6)).

В четырёх местах: на первом экране диалога, в каждом сообщении, которое агент отправляет человеку, в сгенерированных файлах и в конвейере вывода текста. Руководство Еврокомиссии от 20 июля 2026 года требует уведомлять «не позднее момента первого взаимодействия или контакта», ясно и различимо. Строка в пользовательском соглашении не считается, а исключение «очевидно из контекста» нужно толковать узко (Q&A Еврокомиссии).

Самый конкретный текст — про агентов. Пункт 31 руководства говорит, что агенты должны раскрывать «и свою искусственную природу, и лицо, от имени которого они действуют». Если провайдер не может знать, встретит ли агент человека, ему следует раскрывать себя везде, где это разумно вероятно, а также сообщать тому, кто поручил задачу, на ключевых шагах вроде авторизации. Для агента, который отправляет почту или записывает на приём, это значит метку в каждом исходящем сообщении и поле принципала в конфигурации агента (архитектура разобрана в статье «Как работают ИИ-агенты»). Машинные вызовы между бэкендами не входят в область действия. Как и веб-запросы, действия в браузере и цепочки рассуждений (пункт 63).

Те же факты мы кладём в ответ API, чтобы все клиенты отображали их одинаково, а по логам можно было доказать, что увидел пользователь:

{
  "reply": "Your refund for order 48213 was approved.",
  "ai": {
    "generated": true,
    "acting_for": "Example Retail GmbH",
    "disclosure_rendered_at": "2026-10-16T09:12:04Z",
    "model": "vendor-model@2026-09-snapshot",
    "prompt_version": "support-v14",
    "marking": ["signed-metadata"]
  }
}

Для сгенерированных медиа ориентир — Code of Practice on AI-generated content, утверждённый 10 июня 2026 года. К концу июля его подписали около 190 организаций, а Еврокомиссия и AI Board признали его адекватным. Он требует минимум двух машиночитаемых слоёв: подписанных метаданных с отметкой времени и незаметного водяного знака. Простому тексту, который не может нести метаданные, нужен один слой (DLA Piper, 16 июля 2026 года). Водяной знак не требуется для текста короче 200 токенов, а совместимость средств обнаружения водяных знаков должна быть обеспечена к 2 февраля 2027 года (Paul, Weiss, 4 августа 2026 года).

Какой текст подпадает? Руководство относит ИИ-переводы к обычному редактированию, так что маркировка не нужна. Краткие пересказы и переписывание, меняющее смысл, маркировать нужно. Исходный код и короткие строки исключены. Контент, сгенерированный до 2 августа 2026 года, задним числом размечать не надо.

Два вопроса остаются открытыми. Документ от 20 июля, C(2026) 5054, — это решение Еврокомиссии, утверждающее содержание проекта Communication, а руководства никого не обязывают; Акт толкует только Суд ЕС. И Omnibus убрал у Еврокомиссии право вводить общие правила маркировки через имплементационный акт (пункт 41 преамбулы), поэтому пока добровольный кодекс — единственный общеевропейский ориентир.

Автоматическое логирование по статье 12 — обязанность для высокого риска, и начинается она с даты Приложения III. Мы всё равно логируем каждую ИИ-функцию: когда спрашивают про статью 50 или оценку по 6(3), нужны одни и те же свидетельства. Какая версия модели работала и кто изменил классификацию, в какой день.

• Запись о классификации. Письменная оценка в репозитории с версиями, с датой и тем, кто её утвердил.
• Фиксация модели и промпта. ID модели вместе со снапшотом и версия промпта. Тихое обновление у вендора меняет поведение, и без этих данных инцидент не воспроизвести.
• События уведомления, по одной отметке времени на сессию.
• Происхождение данных для всего, что попадает в evals или дообучение.
• Evals, которые перезапускаются при каждой смене модели или промпта, результаты сохраняются.

Цена — хранилище и персональные данные. Логи диалогов — это персональные данные, поэтому идентификаторы пользователей мы хэшируем, а исходный текст храним только столько, сколько позволяет политика хранения. Для агентов нам нужен журнал, в котором подмена видна. Мы используем SealedRun, независимый open-source рекордер: запись нельзя изменить так, чтобы правка не проявилась. Более широкий набор мер описан в статье «Безопасность ИИ-агентов в продакшене», а сторону атаки мы разбираем в заметках про OWASP Top 10 для LLM-приложений.

Облачная модель оставляет ваши обязанности по статье 50 там, где они были. Пункт 27 руководства Еврокомиссии говорит, что статья 50 «прямо не применяется к моделям GPAI». Обязанности лежат на провайдере системы, построенной поверх модели; провайдерам моделей лишь «рекомендуется» добавлять маркировку на уровне модели, полезную дальше по цепочке. У провайдеров универсальных моделей свои обязанности, которые действуют с 2 августа 2025 года, среди них техническая документация и политика в отношении авторских прав. Уведомление в вашем чат-боте они не покрывают.

Надзор тоже делится: AI Office берёт системы, построенные на собственной GPAI-модели провайдера (Orrick), а ваш продукт на чужом API остаётся за национальными органами.

Реестр вендоров мы ведём в каждом проекте и пересматриваем, когда модель выводят из поддержки или меняются условия договора:

- feature: support-assistant
  role: provider            # client ships it under its own brand
  risk_class: art50-only    # 6(3) not needed, no Annex III purpose
  model: vendor-model@2026-09-snapshot
  region: eu-west
  data_terms: no-training, 30-day retention (contract clause 7.2)
  vendor_marking: none for text; signed metadata on images
  owner: product lead
  recheck: 2026-12-02

Строку vendor_marking пропускают чаще всего. Если текст никто не маркирует, запишите это и то, что вы делаете вместо.

Составьте перечень всех ИИ-функций, включая те, что вендор включил за вас. Классифицируйте каждую по пяти вопросам выше. Добавьте компонент уведомления и метаданные в ответ. Включите фиксацию версий и логирование уведомлений. Назначьте одного ответственного на функцию. Поставьте в реестр 2 декабря 2026 года как первую дату пересмотра. Если функция попала в Приложение III, откройте для неё отдельный трек уже сейчас: декабрь 2027 года близко для системы, в которую нужно заложить человеческий контроль.

Мы делаем это в рамках работ по безопасной разработке и соответствию требованиям или первым шагом разработки ИИ-решения. Пришлите список функций, и мы скажем, какие строки таблицы вас касаются.