EU AI Act: раскрытие информации об агенте становится решением рантайма, а не ярлыком интерфейса

2 августа 2026 года начали применяться обязательства по прозрачности из статьи 50 EU AI Act. Для организаций, использующих интерактивный или генеративный ИИ, это уже не будущий комплаенс-проект, а действующее операционное требование. Однако из этого не следует, что каждому агенту нужен новый дисклеймер. Раскрытие информации нельзя больше считать неизменным элементом чат-интерфейса или общей настройкой модели.

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

Что изменилось 2 августа

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

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

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

Что не изменилось

Статья 50 не сделала весь EU AI Act применимым одновременно. В графике Комиссии предусмотрены более поздние сроки для систем высокого риска, включая 2 декабря 2027 года и 2 августа 2028 года для ИИ, встроенного в регулируемые продукты. Статья 50 также не ввела единый универсальный баннер для любого ИИ-взаимодействия. Ее требования различают прямое взаимодействие, маркировку сгенерированного контента, дипфейки, текст по вопросам общественного интереса, распознавание эмоций и биометрическую категоризацию; кроме того, существуют исключения.

Не превратила статья 50 и наблюдаемость рантайма в юридическое соответствие требованиям. Журналы, policy engine и хранилища доказательств могут сделать контроль исполнимым и проверяемым. Но сами по себе они не определят, является ли организация провайдером или деплоером в конкретном случае, действует ли исключение и как окончательный правовой текст применяется к данному развёртыванию. Это по-прежнему вопросы роли, назначения, контекста и юридической интерпретации.

Почему ярлык в интерфейсе — неверная граница контроля

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

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

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

Какое решение должен принимать рантайм агентной системы

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

• Роль: выступает ли организация провайдером, деплоером или одновременно в обеих ролях на соответствующей границе сервиса?
• Взаимодействие: общается ли физическое лицо непосредственно с ИИ-системой и применимо ли предусмотренное исключение?
• Контент: создает или изменяет ли система текст, изображение, аудио, видео либо иной тип результата?
• Назначение: останется ли результат внутри организации, будет отправлен отдельному человеку или опубликован для информирования общественности по вопросу общественного интереса?
• Условие: включает ли процесс распознавание эмоций, биометрическую категоризацию или дипфейк и важна ли для решения проверка человеком?
• Действие: должен ли рантайм показать уведомление, добавить машиночитаемую маркировку, потребовать раскрытия перед выпуском, направить задачу на проверку или заблокировать публикацию до принятия решения?

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

Доказательство должно описывать контроль, а не только результат

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

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

Операционное следствие

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

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