Маркировка ИИ-контента в корпоративном приложении

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

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

В России пока нет общей обязанности маркировать каждый результат

Федеральный закон от 26.07.2026 № 243-ФЗ «О поддержке развития технологий искусственного интеллекта в Российской Федерации» не требует от каждого корпоративного приложения автоматически помечать весь сгенерированный контент. Закон регулирует большие фундаментальные модели ИИ и вводит более узкое требование к определенным крупным информационным ресурсам.

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

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

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

AI Act разделяет машинную метку и раскрытие для человека

Статья 50 Регламента ЕС 2024/1689, известного как AI Act, устанавливает две разные обязанности, которые команды часто смешивают. Поставщик генерирующей системы отвечает за машиночитаемую маркировку ее синтетических выходов. Внедряющая организация, то есть лицо, использующее систему под своей ответственностью, в отдельных случаях раскрывает искусственное происхождение материала людям.

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

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

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

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

Российская компания может попасть в сферу AI Act

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

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

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

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

Тип контента меняет и правило, и способ метки

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

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

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

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

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

Решение должно приниматься в момент публикации

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

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

Вот минимальный конверт, который полезнее голого флага:

{
  "content_id": "cnt_01J...",
  "content": "Текст или ссылка на медиаобъект",
  "provenance": {
    "ai_used": true,
    "provider_role": "system_provider",
    "model_route": "hosted-model-family",
    "generated_at": "2026-07-27T10:15:00Z",
    "modifications": ["generation", "human_edit"]
  },
  "publication": {
    "media_type": "text",
    "territories": ["RU", "EU"],
    "public_interest": true,
    "human_review": "substantive",
    "editor_responsible": "legal-entity-id",
    "disclosure": "not_required_text_review_exception",
    "policy_version": "2026-08-02"
  }
}

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

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

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

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

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

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

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

Автоматическая маркировка должна быть политикой, а не тумблером

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

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

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

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

Исключение для проверенного текста требует настоящей редакции

Исключение AI Act для текста после человеческой проверки нельзя сводить к полю reviewed=true. Регламент связывает его с процессом проверки или редакционного контроля и с ответственностью физического либо юридического лица за публикацию. Команде нужен воспроизводимый процесс, который показывает, что человек оценил содержание, а не просто подтвердил успешное выполнение задания.

Глубина проверки зависит от назначения материала. Для карточки товара редактор сверяет свойства, цену, ограничения и формулировки, которые могут ввести покупателя в заблуждение. Для сообщения о работе городской инфраструктуры он проверяет даты, места, цифры и источники каждого утверждения. Для внутренней инструкции сотрудник сопоставляет текст с действующим регламентом. Универсальное требование «прочитать ответ» слишком расплывчато: два сотрудника выполнят его по-разному, а журнал не объяснит, что именно они подтвердили.

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

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

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

Исправляет этот сбой конечный автомат редакционного процесса. Сгенерированный материал получает статус generated, после назначения редактора переходит в under_review, а статус approved появляется только после заполнения подходящей формы проверки. Модель, сервисный аккаунт и автор исходного запроса не должны автоматически подтверждать собственный материал в чувствительных сценариях. Если компания допускает самопроверку автора для низкого риска, это исключение надо назвать прямо и не переносить на публикации об общественно значимых вопросах.

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

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

Неопределенность лучше обрабатывать явным раскрытием или остановкой выпуска. Поле human_review=unknown не должно тихо превращаться в «проверено». Команда может разрешить публикацию с понятной меткой, отправить материал другому редактору или заблокировать канал для этого типа контента. Какой вариант выбрать, зависит от риска и политики, но молчаливое значение по умолчанию почти всегда создает худший доказательственный след.

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

Владелец приложения отвечает за последнюю милю

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

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

Особенно опасен разрыв между API и выгрузкой. Я видел системы, где внутренний объект хранил generated=true, а функция «Скачать» отдавала чистый JPEG или DOCX без метаданных. После загрузки в корпоративную CMS никто уже не мог связать файл с генерацией. Тестировать надо не ответ модели, а полный путь до страницы, письма, файла или публикации клиента.

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

Шлюз выбирают по качеству доказательств, а не по наличию галочки

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

Проверка шлюза должна ответить на несколько практических вопросов:

• Возвращает ли он стабильный идентификатор запроса и сведения о фактическом маршруте модели?
• Можно ли отличить генерацию от перевода, исправления и иной вспомогательной обработки?
• Передаются ли признаки в потоковых ответах, пакетных заданиях и при повторной попытке?
• Сохраняются ли версии политики, решения и преобразования без записи полного чувствительного промпта?
• Что делает система, если метку нельзя встроить или проверить: блокирует выпуск, просит ручное решение или молча продолжает?

Проверьте еще одну неприятную границу: смена модели не должна менять контракт происхождения приложения. Если один провайдер возвращает собственный заголовок, второй добавляет поле в JSON, а третий не сообщает ничего, бизнес-логика быстро заполнится исключениями. Шлюз должен нормализовать эти сигналы и честно помечать неизвестное происхождение как неизвестное, а не как человеческое.

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

Релиз готов, когда метка переживает реальный маршрут

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

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

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