EU AI Act Article 50: комплаенс самохостинга

2 августа 2026 года начали применяться обязанности прозрачности Article 50, а ограниченный срок перехода для части старых систем заканчивается 2 декабря 2026 года. Это следует из официального FAQ Европейской комиссии по Article 50. Выигрывает не «самая открытая» модель, а самохостинговая система с правильно определёнными ролями provider и deployer, проверенной машинно-читаемой маркировкой и сохранённой цепочкой доказательств. Открытая лицензия и собственный сервер сами по себе не дают освобождения.

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

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

Сначала роль, затем модель и лицензия

Главная ошибка самохостинговых команд — начинать с названия модели: «модель открытая, значит обязательства лежат на ком-то другом». Article 50 оценивает не только происхождение весов и лицензию, но и сам AI-сервис.

Европейская комиссия определяет provider как лицо или организацию, которые разработали AI-систему либо заказали её разработку и размещают её на рынке ЕС или вводят в эксплуатацию под собственным именем или товарным знаком. Это правило применяется независимо от того, находится ли provider в ЕС или за его пределами, если результат системы используется в ЕС. Deployer — лицо или организация, использующие систему под своим руководством, кроме личного непрофессионального использования. (официальный FAQ Европейской комиссии)

Для самохостинга полезно разделить анализ на четыре вопроса:

1. Кто разработал именно систему, а не только базовую модель?
2. Кто заказал интеграцию, настройку, интерфейс, фильтры и публикационный контур?
3. Под чьим именем или товарным знаком сервис доступен клиенту?
4. Кто устанавливает правила использования, контролирует доступ и принимает решения о выводе системы в эксплуатацию?

Факт в продуктовой цепочке	Что это может означать	Какое доказательство сохранить
Команда только запускает модель для внутренних задач	Вероятен статус deployer при профессиональном использовании	Внутреннее назначение системы, политика доступа, приказ о владельце
Компания собрала интерфейс, API и публикационный контур под своим брендом	Возможен статус provider системы	Архитектура, договор разработки, карточка продукта, публичное описание
Интегратор действует по инструкции и под контролем заказчика	Заказчик может сохранять роль deployer или provider в зависимости от вывода на рынок	Договор, зона ответственности, журнал релизов
Сервис доступен клиентам ЕС под именем компании	Риск применения обязанностей provider возрастает	Страница продукта, условия обслуживания, данные о вводе в эксплуатацию
Открытая модель скачана и изменена без внешнего бренда	Само по себе это не определяет роль	История изменений, решение о назначении системы, схема распространения

Открытая модель и открытая лицензия не являются общей льготой для Article 50. Это также отмечено в юридическом обзоре Stibbe, который следует считать правовым комментарием, а не обязательным толкованием суда. (правовой обзор области применения Article 50)

Практический вывод: в реестре комплаенса нужно описывать не только «модель Qwen» или «внутренний inference-сервер», а всю систему — от запроса пользователя до конечного файла или публикации.

2 августа и 2 декабря — разные контрольные точки

Дата 2 августа 2026 года означает начало применения Article 50. Это не дата, после которой нужно ждать отдельного национального закона. Европейская комиссия указывает, что с этого дня provider и deployer должны выполнять применимые требования прозрачности.

Дата 2 декабря 2026 года относится только к узкой переходной ситуации:

• система уже была размещена на рынке до 2 августа 2026 года;
• речь идёт именно об обязанностях Article 50(2);
• требование связано с машинно-читаемой маркировкой и возможностью обнаружения AI-контента;
• команда всё равно должна проверить остальные обязанности, которые уже применяются.

Нельзя превращать этот срок в универсальную отсрочку. Он не переносит уведомление пользователя о прямом взаимодействии с AI по Article 50(1). Он также не отменяет обязанность deployer рассматривать видимую маркировку deepfake или текста общественного интереса по Article 50(4). Контент, который был создан и опубликован до 2 августа 2026 года, не нужно маркировать задним числом, но результат, созданный до этой даты и опубликованный после неё, требует отдельного анализа.

Запись в календаре	Что проверить	Типичная ошибка
Дата первой публикации системы	Была ли система уже на рынке до 2 августа 2026 года	Считать датой публикации дату загрузки весов
Дата ввода в эксплуатацию	Когда сервис стал доступен пользователям или клиентам	Игнорировать внутренний production-запуск
Дата генерации контента	Когда появился конкретный аудио-, видео-, графический или текстовый результат	Подменять её датой экспорта файла
Дата публикации	Когда результат стал доступен человеку	Считать публикацией сохранение в закрытом хранилище
Дата релиза маркировки	Какая версия генератора добавила техническую отметку	Не фиксировать версию backend и конвертера

Соберите минимум три независимых источника времени: журнал релиза, запись о согласовании production-запуска и журнал создания либо публикации контента. Если эти источники расходятся, система не должна автоматически пользоваться сроком до 2 декабря.

Article 50(1), 50(2) и 50(4) нельзя смешивать

Самохостинговый сервис может одновременно попадать в несколько категорий.

Article 50(1) относится к непосредственному взаимодействию человека с AI. Человек должен быть проинформирован с начала первого взаимодействия, если искусственная природа контакта не очевидна. Системы, которые работают только в фоне, обмениваются данными машина-машина или не контактируют напрямую с человеком, находятся вне этой конкретной обязанности.

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

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

Тип результата или взаимодействия	Основной вопрос	Предварительное действие
Чат, голосовой помощник, AI Agent	Понимает ли человек, что взаимодействует с AI?	Добавить заметное уведомление на старте диалога
Текст, изображение, звук или видео	Может ли результат быть обнаружен как созданный или изменённый AI?	Встроить машинно-читаемую отметку и проверить её сохранность
Deepfake	Может ли контент выглядеть подлинным для человека?	Подготовить понятное видимое или слышимое раскрытие
Текст о политике, здоровье, безопасности, финансах или другой общественно значимой теме	Была ли проведена содержательная проверка?	Зафиксировать редактора, основания решения и итоговую публикацию
Исходный код	Действительно ли результат является кодом, а не пояснительным текстом?	Разделить код, комментарии, документацию и пользовательский интерфейс

Где заканчивается исключение для исходного кода

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

Но инженерная команда не должна превращать эти исключения в универсальную метку «всё разрешено».

Например, coding agent может выдавать исходный код, но одновременно вести прямой диалог с разработчиком. Тогда обязанность по Article 50(1) оценивается отдельно. Текстовый отчёт о внесённых изменениях — уже не обязательно исходный код. Публичная документация, созданная тем же сервисом, может попасть в другой контур анализа. А закрытый промышленный pipeline перестаёт быть закрытым, если финальный результат выводится для клиентов или публики.

Для каждого типа вывода создайте карточку:

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

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

Машинная отметка против видимого раскрытия

Видимый текст «создано AI» не заменяет машинно-читаемую маркировку provider. И наоборот: встроенные метаданные не всегда заменяют видимое раскрытие deployer перед человеком.

Машинная отметка должна проходить проверку после реального жизненного цикла файла:

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

Водяной знак, метаданные происхождения или другой метод — это технический выбор. Ни один из них нельзя заранее объявлять автоматически соответствующим требованиям. Практические меры маркировки и обнаружения описываются в Code of Practice Европейской комиссии, однако окончательная пригодность метода зависит от типа контента и реального сценария распространения.

Если выполняется A, выбирается B

• Если сервис напрямую разговаривает с человеком — выбирается уведомление по Article 50(1), даже когда модель работает только на собственном сервере.
• Если компания выводит генеративную систему под своим именем — выбирается проверка provider-обязанностей, включая машинную маркировку.
• Если результат видит только другой сервис и человек его не видит — проверяется исключение машин-машин, но сохраняется доказательство отсутствия человеческого показа.
• Если результат публикуется как deepfake — выбирается видимое раскрытие для человека; одних метаданных недостаточно.
• Если публикуется текст о вопросе общественного интереса — выбирается содержательная проверка и ответственное лицо либо заметная маркировка.
• Если система была на рынке до 2 августа 2026 года и выполняются условия переходного режима — срок до 2 декабря применяется только к Article 50(2), а не ко всей прозрачности.
• Если после конвертации отметка исчезает — production-публикация блокируется до исправления или утверждённого альтернативного процесса.

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

Пошаговая приёмка для самохостинговой команды

Шаг 1. Зафиксировать границы системы

В реестре указываются модель, адаптеры, системные инструкции, фильтры, API, интерфейс, экспортёры и публикационные каналы. Отдельно отмечается, где заканчивается модель и начинается AI-система.

Шаг 2. Назначить provider и deployer

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

Шаг 3. Разнести выходы по четырём типам

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

Шаг 4. Выбрать технический метод

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

Шаг 5. Подготовить фиксированный набор образцов

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

Шаг 6. Провести негативные тесты

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

Шаг 7. Включить блокировку релиза

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

Шаг 8. Сохранить доказательства

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

Шаг 9. Провести повторную проверку после изменения модели

Замена базовой модели, адаптера, шаблона промпта, конвертера или внешнего канала считается поводом для регрессионной проверки. Даже если интерфейс не изменился, маркировочная цепочка могла измениться.

Для управления тестовыми версиями и доступами команда может использовать консоль ProxyMac, а организационные вопросы доступа и восстановления — сверять с разделом помощи ProxyMac. Это не заменяет юридическую документацию, но помогает отделить тестовый контур от production-доступа.

Доказательства важнее скриншота с меткой

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

Полноценная папка релиза должна содержать:

• схему ролей provider и deployer;
• таблицу выходов и применимых пунктов Article 50;
• дату размещения системы и дату каждого релиза;
• образцы до и после экспорта;
• отчёт проверки машинной обнаруживаемости;
• сведения о потерянных метаданных;
• правила аварийной остановки публикации;
• журнал ручного пересмотра общественно значимых текстов;
• имя или должность лица, принявшего решение;
• ссылку на использованный раздел руководства Европейской комиссии о прозрачности или Code of Practice.

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

Изолированная среда лучше экспериментов в production

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

Минимальная тестовая среда должна иметь:

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

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

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

Где текущая схема проигрывает Mac-среде

Самостоятельная проверка на единственном рабочем компьютере часто выглядит дешевле, но у неё есть реальные недостатки: нет отдельного контура для параллельных тестов, сложнее зафиксировать одинаковую версию инструментов, а возврат к предыдущей конфигурации может зависеть от ручных действий одного инженера. Локальная Linux- или Windows-среда тоже может быть технически пригодна, но не всегда повторяет macOS-инструменты, которыми пользуется команда разработки и выпуска.

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

Но для временной Article 50-приёмки, где нужно воспроизвести несколько версий модели, экспортировать образцы, проверить метаданные после перекодирования и затем удалить изолированный контур, аренда Mac через ProxyMac может быть удобнее постоянного расширения локального парка. Такой путь особенно оправдан, когда текущая схема не даёт стабильного отката, блокирует параллельные проверки или смешивает тестовые данные с production.

FAQ: что проверить до подписания акта приёмки

Открытая модель обслуживает клиентов — кто несёт основную роль?

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

Можно ли ждать 2 декабря для любого старого AI-сервиса?

Нет. Переходный срок относится к системам, уже размещённым на рынке до 2 августа 2026 года, и только к маркировке и обнаружению AI-контента по Article 50(2). Обязанность сообщать о прямом взаимодействии с AI и обязанности deployer по видимому раскрытию не переносятся автоматически. Даты запуска, генерации и публикации нужно хранить раздельно.

Требуется ли машинная отметка для кода?

Руководство Европейской комиссии относит исходный код к возможным исключениям из Article 50(2). Это исключение нужно применять узко. Coding agent может одновременно подпадать под Article 50(1), если напрямую взаимодействует с разработчиком. Комментарии, документация, отчёты и публичные объяснения следует классифицировать отдельно от самого кода.

Можно ли заменить метаданные заметной надписью?

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

Какой набор доказательств запросит проверяющий орган?

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

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