Для многих небольших компаний самый срочный вопрос AI Act связан не с тем, относится ли система к категории высокого риска. Сначала нужно понять, может ли клиент определить, что взаимодействует с ИИ или видит созданный им материал.
2 августа 2026 года начали применяться требования прозрачности статьи 50 AI Act. Руководство Европейской комиссии охватывает определённые интерактивные и генеративные ИИ-системы: прямое взаимодействие человека с ИИ, машиночитаемую маркировку синтетического контента, дипфейки и созданные ИИ тексты по вопросам общественного интереса.
Одновременно AI Omnibus перенёс часть сроков для систем высокого риска. Отсюда возникло опасное упрощение: некоторые сроки изменились, но дата применения статьи 50 не исчезла.
Ниже — операционный чек-лист, а не юридическая консультация. Конкретное требование зависит от системы, роли компании, аудитории и контекста использования результата.
Начинайте со сценария, а не с марки модели
Подписка на ИИ-сервис сама по себе не говорит, что именно нужно раскрывать пользователю. Сначала перечислите ситуации, в которых ИИ выходит к человеку или в публичное пространство:
- посетитель сайта общается с автоматическим помощником;
- голосовая система принимает или совершает звонок;
- маркетинг публикует изображение или видео, созданное ИИ;
- реальная запись изменяется так, что человек выглядит говорящим или делающим то, чего не было;
- компания публикует созданный ИИ текст по вопросу общественного интереса;
- система распознаёт эмоции или применяет биометрическую категоризацию.
Затем определите роль компании. Упрощённо, provider разрабатывает систему или заказывает разработку и выводит её на рынок под своим именем. Deployer использует систему под своей ответственностью в профессиональной деятельности. Небольшая компания может быть deployer в одном процессе и получить более широкие обязанности в другом — например, после существенной модификации или ребрендинга решения.
Не определяйте роль по рекламной странице поставщика. Зафиксируйте её для каждого сценария, сопоставьте с договором и официальным руководством.
Четыре ситуации, которые стоит найти первыми
1. Человек напрямую взаимодействует с ИИ
Если клиент обоснованно может решить, что общается с человеком, интерфейс должен ясно сообщить об участии ИИ. Уведомление должно появляться в нужный момент, а не прятаться в политике, которую пользователь, вероятнее всего, не откроет.
Практический вариант в начале контакта:
Вы общаетесь с ИИ-помощником. При необходимости разговор может проверить или продолжить сотрудник нашей команды.
Это операционный пример, а не установленная законом формула. Он полезен тем, что называет характер взаимодействия и показывает путь к человеку.
2. Система создаёт или изменяет контент
Для providers определённых генеративных систем предусмотрены обязанности, связанные с обнаруживаемостью искусственно созданного или изменённого результата, включая машиночитаемую маркировку там, где она требуется. Поэтому deployer должен знать, какие средства provenance предоставляет поставщик и сохраняет ли их реальный процесс публикации.
Экспорт, изменение размера или пересборка файла могут удалить метаданные. Фразы «поставщик добавляет маркировку» недостаточно: проверьте именно тот файл, который увидит публика.
3. Компания публикует дипфейк или текст общественного значения
Для deployers существуют отдельные обязанности по раскрытию дипфейков. Правила также относятся к некоторым созданным или изменённым ИИ текстам, публикуемым для информирования общества. При этом важна разница между автоматическим выпуском и настоящим человеческим или редакционным контролем, за который отвечает конкретное лицо или организация.
Поэтому «человек посмотрел» должно означать реальное редакционное решение, а не галочку, которую поставил сам workflow.
4. Применяется распознавание эмоций или биометрическая категоризация
Такие функции вызывают отдельные вопросы прозрачности и защиты данных. Если они используются в найме, образовании, контроле доступа, мониторинге или клиентской аналитике, передайте сценарий на профильную проверку. Не рассматривайте его как обычную настройку чат-бота.
60-минутный аудит прозрачности
Используйте отдельную строку для каждого клиентского или публичного ИИ-процесса.
| Проверка | Вопрос | Какие свидетельства сохранить |
|---|---|---|
| Инвентаризация | Где ИИ общается с людьми или создаёт видимый им материал? | Название процесса, владелец, аудитория и канал |
| Роль | Мы provider, deployer, distributor или совмещаем роли? | Договор, конфигурация и письменная оценка роли |
| Раскрытие | Что и в какой момент видит человек? | Утверждённый текст, скриншоты или тестовые записи |
| Маркировка | Сохраняется ли требуемая машиночитаемая информация? | Документация поставщика и тест финального файла |
| Проверка человеком | Какие результаты требуют настоящего решения? | Проверяющий, критерии, журнал решения и эскалация |
| Запись | Можем ли мы восстановить, что работало и что было опубликовано? | Версия системы, класс входа, результат, утверждение и время |
Не пытайтесь за час описать каждое внутреннее автодополнение. Сначала проверьте внешнее воздействие и действия с существенными последствиями.
Минимальный набор контролей для небольшой команды
Сделайте раскрытие частью интерфейса
Храните утверждённый текст уведомления как управляемый контент, а не как случайную фразу внутри prompt. Тогда его можно переводить, согласовывать и тестировать.
Проверьте как минимум первое взаимодействие, повторно открытый диалог, начало голосового звонка, мобильную версию, встроенные виджеты, передачу человеку и сообщения, которые workflow может отправить автоматически.
Отделите черновик от внешнего действия
ИИ-черновик в приватном рабочем пространстве и отправленное клиенту сообщение — разные состояния. Проведите явную границу:
- создать черновик;
- проверить обязательные поля и запрещённые утверждения;
- показать проверяющему доказательства;
- запросить утверждение соразмерно последствиям;
- выполнить действие детерминированным сервисом;
- записать событие.
Модель не должна сама решать, заслуживает ли её результат проверки.
Ведите соразмерный журнал
После жалобы компания должна суметь ответить: какая система и версия работала, какое уведомление увидел клиент, требовалось ли утверждение, кто последним изменил процесс и можно ли исправить или отозвать результат.
Не храните персональные данные «на всякий случай». Определите цель и срок хранения каждого типа записи.
Проверяйте поставщика глубже рекламного обещания
Запросите описание уведомлений для пользователей, маркировки синтетического контента, локаций данных и subprocessors, правил сообщения об инцидентах и изменениях, экспорта и удаления, а также распределения ответственности за конечный интерфейс.
Фраза «мы соответствуем AI Act» слишком общая. Нужна связь между конкретной функцией, обязанностью и вашим workflow.
Не смешивайте прозрачность, согласие и точность
Маркировка «создано ИИ» не делает материал точным, справедливым или законным. Она не заменяет правовое основание обработки данных, privacy notice, маркетинговое согласие, требования трудового или потребительского права.
Рассматривайте прозрачность как один слой системы:
- идентичность: человек понимает, что участвует ИИ;
- данные: у обработки есть цель, основание и защита;
- контент: существенные утверждения проверены;
- действие: система имеет только необходимый объём полномочий;
- доказательства: компания способна восстановить ход события.
Великобритания и компании, работающие с ЕС
Великобритания входит в европейский рынок, но не является государством — членом ЕС. Нельзя автоматически утверждать, что чисто британский сценарий регулируется AI Act. При работе британской компании на рынке ЕС может потребоваться отдельная оценка территориального действия.
Для европейского запуска добавьте в чек-лист страну и применимую правовую область, а не используйте «Европу» как одну юрисдикцию.
Что сделать на этой неделе
Выберите три процесса с наибольшей публичной экспозицией. Для каждого:
- сохраните фактический пользовательский путь;
- назначьте владельца и определите роль;
- утвердите текст и место уведомления;
- проверьте маркировку после финального экспорта;
- опишите правило проверки и эскалации;
- сохраните свидетельства теста;
- назначьте пересмотр после смены модели, поставщика или сценария.
Цель — не длинная политика, а наблюдаемая система, в которой клиент распознаёт участие ИИ, а бизнес объясняет путь результата до публикации.
Источники
- European Commission. “Guidelines on transparency obligations for providers and deployers of AI systems.” 20 July 2026. Официальное руководство (откроется в новой вкладке).
- European Commission. “AI Omnibus enters into force.” 27 July 2026. Официальное обновление (откроется в новой вкладке).
Применить чек-лист в Methodfield
Используйте FMEA, чтобы найти возможные отказы раскрытия и маркировки, защиту от ошибок, чтобы поставить контроль у границы публикации, и PDCA/PDSA, чтобы повторно проверять реальный интерфейс после каждого существенного изменения системы.
Материал содержит общую операционную информацию и не является юридической консультацией. Последняя сверка с руководством Европейской комиссии и обновлением AI Act выполнена 11 августа 2026 года.