2026 Article 50 AI Act: тестировать модель заново?

Тестовый отчёт всё ещё привязан к старому дайджесту модели, а в продакшене уже работает новая версия с изменённым шлюзом вывода.

Самое быстрое решение: повторно тестировать нужно, но не всегда полностью. На этой неделе зафиксируйте состав изменений, разделите их на полную проверку, локальную регрессию и обновление документации, а до выпуска новой версии сохраните старую модель и связанную с ней цепочку маркировки.

Эта статья предназначена для команд, которые уже используют самохостинговую модель с машиночитаемой маркировкой и готовят замену базовой модели, новую LoRA, квантование или обновление инференс-цепочки. Она также пригодится техническим руководителям и ответственным за соответствие, которым нужно решить, можно ли сослаться на старый отчёт при выпуске новой версии.

Последнее обновление: 10 августа 2026 года. Данные сверены с официальными разъяснениями Европейской комиссии, текстом Article 50 и финальным Code of Practice, опубликованным до этой даты.

Календарь обязательств и первая проверка

Article 50 начал применяться 2 августа 2026 года. Ограниченный переходный период до 2 декабря 2026 года относится не ко всем обновлениям и не ко всем обязанностям: Европейская комиссия описывает его только для систем, размещённых на рынке до 2 августа, и только в отношении маркировки и обнаружения искусственно созданного контента по Article 50(2). Это не подтверждает автоматическое сохранение переходного периода после существенного изменения системы. (официальный FAQ Европейской комиссии)

Поэтому рабочее правило для MLOps выглядит так:

• до 2 декабря 2026 года нужно отдельно подтвердить, что система действительно была размещена на рынке до 2 августа;
• нужно определить, изменилась ли именно система, а не только внутренний файл модели;
• нельзя считать, что новая модель автоматически наследует статус старой;
• окончательное решение о роли поставщика, статусе системы и применимости переходного периода должен подтвердить юрист или ответственное за соответствие лицо.

Европейская комиссия связывает статус поставщика с разработкой системы либо заказом её разработки и выводом на рынок или вводом в эксплуатацию под собственным именем или товарным знаком. Для самохостинговой инфраструктуры это означает, что факт использования открытой модели сам по себе не снимает вопрос об ответственности: важны способ вывода системы на рынок, собственное наименование, назначение и то, кто контролирует её эксплуатацию. (пояснения Европейской комиссии о прозрачности Article 50)

В инженерном плане стоит вести три независимые линии контроля:

1. Article 50(1) — человек должен быть проинформирован о взаимодействии с AI-системой, если это не очевидно из контекста.
2. Article 50(2) — синтетический текст, звук, изображение или видео должны иметь эффективную, надёжную, устойчивую и совместимую машиночитаемую маркировку, позволяющую обнаружить искусственное происхождение.
3. Article 50(4) — deployer должен обеспечить видимое раскрытие для deepfake-контента и определённых публикаций, созданных или изменённых AI, если они относятся к общественно значимым вопросам и не прошли полноценный человеческий редакторский контроль.

Смешивать эти линии нельзя. Наличие видимой подписи в интерфейсе не доказывает наличие машиночитаемого признака, а успешная запись метаданных не заменяет уведомление пользователя о взаимодействии с AI.

Карта изменений перед выпуском

Перед запуском новой версии мы рекомендуем составить не список номеров релизов, а карту потенциального воздействия. В неё должны попасть:

• дайджест базовой модели;
• LoRA, адаптеры и другие компоненты адаптации;
• способ квантования и формат весов;
• токенизатор;
• стратегия декодирования;
• инференс-фреймворк и его версия;
• системный промпт и шаблон диалога;
• компонент маркировки;
• детектор;
• API-шлюз;
• потоковый вывод;
• пакетная обработка;
• конвертация файлов;
• постобработка текста, аудио, изображений или видео;
• кэш, очередь и резервный маршрут;
• клиентские каналы, через которые результат доходит до пользователя.

Ключевой вопрос — не «изменился ли номер версии», а могло ли изменение повлиять на форму результата, место записи маркировки, обнаруживаемость признака или путь, по которому результат обходит компонент маркировки.

Именно здесь старый отчёт часто перестаёт быть достаточным. Например, обновление базовой модели может не менять код маркировщика, но изменить длину, структуру или формат вывода. Новая LoRA может заставить систему использовать другой шаблон ответа. Квантование может потребовать иной backend. Обновление шлюза может сохранить запись признака в логах, но удалить его при сериализации ответа.

Нужно ли заново тестировать машиночитаемую маркировку после LoRA-настройки?
Да, если адаптер способен изменить тип, структуру или маршрут вывода. Минимумом будет локальная регрессия всех затронутых форматов и каналов, но при изменении шаблона ответа, декодирования, постобработки или места внедрения маркировки безопаснее переходить к полной проверке.

Решение по уровню повторной проверки

Используйте этот список как выпускной инструмент. Отмечайте пункты до публикации новой версии.

Полная проверка

Выбирайте этот уровень, если выполнено хотя бы одно условие:

• [ ] изменились базовая модель или её дайджест;
• [ ] добавлена, удалена или существенно изменена LoRA либо другой адаптер;
• [ ] изменились токенизатор, шаблон диалога или стратегия декодирования;
• [ ] изменился формат текста, аудио, изображения или видео;
• [ ] обновлены маркировщик, детектор или место внедрения признака;
• [ ] изменился инференс-фреймворк, формат событий или аппаратный backend;
• [ ] появился новый шлюз, конвертер, канал публикации или резервный маршрут;
• [ ] система получила новую функцию генерации или новый пользовательский путь;
• [ ] невозможно доказать, что старый отчёт связан с фактическим производственным образом.

При любом отмеченном пункте новую версию следует выпускать только с новым базисом тестов и новой привязкой доказательств.

Локальная регрессия

Этот уровень допустим, если одновременно выполнены все условия:

• [ ] изменение не затрагивает маркировщик и детектор;
• [ ] формат конечного результата остаётся прежним;
• [ ] путь от генерации до клиента не изменился;
• [ ] анализ воздействия показывает, какие именно форматы и режимы затронуты;
• [ ] тесты выполняются на конечном опубликованном объекте, а не только на внутреннем логе;
• [ ] старая версия доступна для немедленного отката.

В этом случае проверяйте только затронутые режимы, но сохраняйте перечень исключённых сценариев и объяснение, почему они не вошли в прогон.

Обновление документации

Ограничиться документами можно только тогда, когда изменение не влияет на выполнение, вывод, маркировку, обнаружение, сериализацию, публикацию и пользовательский путь. Примерами могут быть изменение внутреннего описания процесса, переименование неисполняемого документа или обновление контактного лица.

Если инженер не может доказать отсутствие влияния на выходную цепочку, выбирайте локальную регрессию, а не самый дешёвый вариант.

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

Тестовая база перед публикацией

Отчёт о соответствии должен быть связан с тем же набором компонентов, который отправляется в производство. Зафиксируйте в одном идентифицируемом базисе:

1. дайджест модели и адаптеров;
2. образ инференс-сервиса;
3. конфигурацию квантования;
4. системный промпт;
5. компонент маркировки;
6. версию детектора;
7. формат API-ответа;
8. конфигурацию шлюза и постобработки;
9. набор тестовых случаев;
10. ожидаемые результаты и правила остановки выпуска.

Если в отчёте указан старый дайджест модели, а в образе производства появился новый, отчёт должен считаться относящимся к предыдущей версии. Это не обязательно означает нарушение, но означает, что выпускная цепочка потеряла доказательную связь.

Тесты должны отдельно проверять:

• уведомление пользователя при прямом взаимодействии с AI;
• наличие машиночитаемого признака;
• обнаружение признака независимым инструментом;
• сохранение признака после сериализации;
• сохранение признака после потоковой выдачи;
• сохранение признака после пакетной обработки;
• видимое раскрытие в тех сценариях, где оно требуется deployer;
• поведение при ошибке маркировщика;
• поведение резервного маршрута;
• соответствие фактического результата версии, указанной в отчёте.

Article 50 требует учитывать техническую реализуемость, особенности разных типов контента, стоимость внедрения и существующее состояние технологий. Финальный Code of Practice Европейской комиссии описывает требования к маркировке текста, аудио, изображений и видео, а также подчёркивает, что сам код является добровольным инструментом, тогда как обязанности Article 50 имеют обязательную силу. (материалы Европейской комиссии о Code of Practice)

Можно ли использовать отчёт от исходной модели после квантования?
Только после документированного анализа воздействия и целевой регрессии. Если квантование не меняет формат вывода, не затрагивает размещение маркировки и не создаёт обходного пути, часть доказательств может быть использована повторно. Но обнаруживаемость нужно проверить на реальном производственном маршруте, а не только на этапе запуска модели.

Регрессия по типу изменения

При замене базовой модели проверяйте все поддерживаемые типы вывода. Даже если текущий продукт преимущественно генерирует текст, наличие функции создания файла, изображения, аудио или видео расширяет поверхность проверки. Команда должна сравнить старую и новую версии по одинаковым сценариям и отдельно зафиксировать случаи, когда модель формирует новый вид результата.

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

При обновлении инференс-фреймворка или аппаратного backend нужно проверить:

• потоковую выдачу;
• пакетные запросы;
• параллельные ответы;
• тайм-ауты;
• повторные попытки;
• генерацию файлов;
• ошибки сериализации;
• аварийное переключение на старую или упрощённую цепочку.

Может ли новый инференс-фреймворк сломать маркировку AI-контента?
Да, если он меняет формат событий, точки завершения генерации, сериализацию или порядок вызова компонента маркировки. Сам факт успешного запуска сервиса ничего не доказывает: нужна проверка результата после прохождения всей цепочки публикации.

При изменении API-шлюза и постобработки проверяйте не внутренний журнал, а конечный объект, который получает клиент. Шлюз может удалить поле, изменить MIME-тип, пересобрать медиафайл, преобразовать текст, обрезать поток или отправить ответ через внешний канал. В таких случаях лог «маркировка добавлена» не равен доказательству того, что пользовательский результат остался маркированным.

Для текстовых ответов отдельно фиксируйте изменение форматирования, шаблонов и удаления служебных полей. Для медиа — изменение контейнера, кодека, размера, превью и метаданных. Комиссия отдельно указывает, что технические решения должны быть эффективными, совместимыми, устойчивыми и надёжными настолько, насколько это технически возможно. (официальные рекомендации по маркировке AI-контента)

Условия выпуска и отката

На первый час после публикации новой версии не следует переводить весь пользовательский поток на изменённую цепочку. Используйте один из контролируемых вариантов:

• теневой трафик без выдачи нового результата пользователю;
• изолированный арендатор;
• серую группу запросов;
• отдельный endpoint;
• параллельную обработку одинаковых входных данных старой и новой версиями.

Новая версия может быть допущена к расширению трафика только при одновременном выполнении четырёх условий:

• маркировка обнаруживается на конечном результате;
• обходной маршрут контролируется и журналируется;
• отчёт связан с фактическими дайджестами и образами;
• старая версия восстанавливается без пересборки критических компонентов.

При ошибке маркировки сначала останавливайте комбинацию «модель плюс цепочка публикации». Нельзя просто отключить предупреждение детектора или добавить визуальную подпись в интерфейсе, если нарушена машиночитаемая маркировка. Видимая надпись и технический признак решают разные задачи.

Для команд, которым нужно заранее проверить изоляцию, параллельные версии и журналы, полезно использовать руководство по воспроизведению ошибок в Kimi K3 и vLLM. Оно помогает отделить ошибку модели от ошибки среды и публикационного маршрута.

Доказательства первой недели

После выпуска нужно собирать не только средний процент успешных проверок, а набор воспроизводимых случаев. Разделяйте результаты по:

• типу вывода;
• длине ответа;
• языку;
• клиентскому приложению;
• каналу публикации;
• потоковому и обычному режиму;
• версии модели;
• версии шлюза;
• результату независимого обнаружения.

Отдельно классифицируйте причины отказа:

• модель изменила структуру вывода;
• маркировщик не был вызван;
• шлюз удалил или преобразовал признак;
• кэш вернул старый объект;
• внешний сервис пересобрал файл;
• клиент не отобразил видимое раскрытие;
• детектор получил неподдерживаемый формат.

Каждый внешний отчёт об ошибке связывайте с версией, входными данными, конечным результатом, журналом маршрута, исправлением и повторным тестом. Среднее значение без отдельных неудачных случаев плохо подходит для аудита: оно не показывает, какой именно путь публикации оказался уязвимым.

Если после обновления появилась новая возможность — например, генерация другого типа медиа или публикация через новый канал, — запускайте повторную проверку не только маркировки, но и применимости Article 50, роли поставщика или deployer и статуса переходного периода.

Матрица постоянного обслуживания

Чтобы не спорить заново при каждом релизе, создайте внутреннюю матрицу триггеров. В ней достаточно закрепить четыре решения:

• полная проверка — базовая модель, токенизатор, декодирование, маркировщик, детектор, формат вывода, шлюз или резервный маршрут;
• локальная регрессия — адаптер, квантование, изменение backend или постобработка, если анализ подтверждает ограниченное воздействие;
• переиспользование части доказательств — документация, неисполняемые настройки и изменения, не связанные с выходным маршрутом;
• обязательная правовая ревизия — изменение способа вывода на рынок, собственного имени, назначения системы, состава пользователей или условий переходного периода.

Матрицу следует пересмотреть после публикации новых технических стандартов, изменений Code of Practice, появления переходных правил или разъяснений органов надзора. В текущих официальных материалах нет основания утверждать, что любое обновление старой системы автоматически сохраняет право на переходный период до 2 декабря 2026 года. Поэтому существенные обновления должны проходить отдельную правовую проверку. (текст Regulation (EU) 2024/1689 в EUR-Lex)

Официальная санкция за нарушения отдельных требований AI Act может достигать 15 000 000 евро или 3% мирового оборота за предыдущий финансовый год; для малых и средних компаний учитывается принцип соразмерности. Надзор в основном осуществляют национальные органы рыночного контроля. (разъяснения Европейской комиссии о санкциях)

Переходный период и ответственность

Сохраняется ли срок до 2 декабря 2026 года после обновления старой самохостинговой системы?
Автоматически это утверждать нельзя. Нужно подтвердить дату размещения системы на рынке, характер обновления, фактическую идентичность системы, её назначение и применимую обязанность Article 50(2). Официальные материалы не дают инженерной команды, по которой любое обновление считается автоматически покрытым переходным периодом.

Финальное решение должно быть передано на правовую проверку, особенно если обновление меняет:

• коммерческое имя или описание продукта;
• круг пользователей;
• назначение системы;
• тип генерируемого контента;
• способ предоставления доступа;
• владельца или поставщика сервиса;
• внешний рынок или канал распространения.

Практический Code of Practice можно использовать как инструмент подготовки и документирования соответствия, но он не заменяет требования Regulation (EU) 2024/1689. Эта статья также не является юридическим заключением.

Выпускной порядок для команды

Перед подписанием релиза выполните последовательность:

1. Зафиксируйте старую и новую версии модели, адаптеров, инференс-образа и шлюза.
2. Опишите, какие изменения способны повлиять на форму результата, маркировку, обнаружение или путь публикации.
3. Выберите уровень проверки по условному списку: полная, локальная или документальная.
4. Создайте единый тестовый базис, связанный с фактическими дайджестами и конфигурацией выпуска.
5. Проверьте Article 50(1), Article 50(2) и Article 50(4) раздельно.
6. Прогоните реальные типы вывода и конечные каналы доставки.
7. Запустите теневой трафик или изолированную группу.
8. Убедитесь, что старая версия восстанавливается без ручной реконструкции окружения.
9. В течение первой недели собирайте отдельные случаи отказа, а не только средние показатели.
10. При существенном изменении системы передайте вопрос о переходном периоде и роли организации юристу.

Для хранения версий и подготовки двухконтурного процесса также можно использовать информацию о тарифах JexMac. Если существующая инфраструктура не позволяет параллельно держать старую и новую модель, воспроизводить цепочку macOS-клиента или выполнять изолированную регрессию без остановки основной среды, страница заказа JexMac может помочь организовать отдельный временный стенд. Это не гарантирует соответствие Article 50, но сокращает риск выпуска версии, которую невозможно сравнить, проверить и быстро откатить.

Для постоянной тяжёлой нагрузки собственное оборудование обычно рациональнее, если команда уже располагает резервированием, мониторингом и процессом восстановления. Для короткого окна миграции арендуемая среда удобнее, когда требуется быстро сохранить старую конфигурацию, поднять новую, проверить macOS-клиент и не смешивать эксперимент с основным контуром. Решение должно исходить не из обещания «облачная среда решит соответствие», а из конкретного вопроса: сможете ли вы до 2 декабря 2026 года доказуемо сопоставить версию модели, маркировку, конечный результат и процедуру отката.