2026 C2PA и EU AI Act Article 50: проверка

Файл получает C2PA-манифест, но после перекодирования или загрузки на платформу проверка подписи перестаёт работать.

Быстрое решение: рассматривайте C2PA только как технический слой происхождения и истории обработки. Для Article 50 сначала проверьте обнаруживаемость, совместимость, устойчивость и надёжность маркировки, а для текста, потокового API и нестабильных форматов заранее добавьте другие методы и журналы.

Эта статья предназначена для трёх групп:

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

Последнее обновление — 6 августа 2026 года. Даты и требования проверены по материалам Европейской комиссии, EUR-Lex и текущей спецификации C2PA.

C2PA против автоматического соответствия: это разные утверждения

Вопрос «может ли C2PA выполнить Article 50» слишком широкий. Технически правильная формулировка другая:

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

Article 50(2) касается генеративных систем, создающих синтетический звук, изображения, видео или текст. Для таких результатов требуется маркировка в машиночитаемом формате и возможность обнаружить, что содержимое создано или изменено искусственным интеллектом. В норме нет требования использовать именно C2PA. Подробные разъяснения по области применения опубликованы в официальном FAQ Европейской комиссии по Article 50.

C2PA подходит для слоя происхождения:

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

Но наличие манифеста не отвечает автоматически на другие вопросы:

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

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

Первый этап: отделите техническую схему от юридической роли

Самостоятельное размещение модели не означает автоматически, что вы являетесь только deployer или только provider. Статус зависит от того, кто разрабатывает систему, выводит её на рынок, вводит в эксплуатацию и предоставляет пользователям под собственным именем или торговой маркой.

Поэтому процесс начинайте не с установки библиотеки C2PA, а с таблицы ответственности:

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

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

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

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

Второй этап: определите, где C2PA вообще может работать

Перед proof of concept составьте карту всех типов результата. Для каждого типа зафиксируйте не только расширение файла, но и весь путь от генерации до пользователя.

Минимальный перечень:

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

Затем запишите, где происходят:

• изменение размера;
• сжатие;
• смена кодека;
• перекодирование;
• переименование;
• загрузка в объектное хранилище;
• выдача через CDN;
• преобразование в превью;
• скачивание пользователем;
• повторное редактирование.

Только изображения можно маркировать C2PA и считать задачу закрытой?

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

Особенно опасны два случая:

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

В первом случае C2PA можно тестировать как основной слой. Во втором понадобится отдельная архитектура маркировки.

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

Третий этап: сравните варианты маркировки до внедрения

На этом этапе вам нужен не выбор «C2PA или ничего», а комбинация по типу результата.

C2PA описывает hard binding и soft binding как разные механизмы. Soft binding может использовать отпечаток содержимого или невидимый водяной знак для поиска манифеста после изменения исходных битов. Однако такой механизм нельзя путать с криптографической связью и нельзя без проверки считать точным доказательством для любого преобразованного файла. Подробности приведены в спецификации Content Credentials.

Что делать с текстом, если файл C2PA создать нельзя?

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

Не называйте внутренний журнал заменой маркировке результата. Журнал отвечает на вопрос «что произошло в системе», а машиночитаемый маркер — на вопрос «можно ли обнаружить искусственное происхождение самого результата».

Четвёртый этап: проведите проверку прохождения по настоящему конвейеру

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

Шаг 1. Зафиксируйте исходный образец

Для каждого типа результата сохраните:

• исходный файл;
• размер;
• формат и кодек;
• идентификатор модели;
• версию компонента подписи;
• время генерации;
• идентификатор запроса;
• ожидаемые поля манифеста.

Не подменяйте независимую проверку ответом API «операция завершена успешно».

Шаг 2. Пропустите файл через все преобразования

Минимальный сценарий должен включать:

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

Если у вас есть несколько кодеков или поставщиков хранения, каждый вариант становится отдельной веткой теста.

Шаг 3. Проверьте не только наличие, но и смысл

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

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

Полезный результат теста — не «C2PA найден», а карта состояний:

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

Шаг 4. Отдельно проверьте восстановление

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

Шаг 5. Проверьте отказоустойчивость

Намеренно создайте ошибки:

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

После этого система должна иметь заранее определённое поведение:

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

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

Пятый этап: добавьте второй слой для слабых мест

C2PA, водяной знак и журнал лучше использовать отдельно или вместе?

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

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

Для чистого текста возможная схема выглядит так:

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

Для файлового результата схема может быть другой:

1. C2PA-манифест подписывается на последнем этапе генерации;
2. после каждого преобразования выполняется независимая проверка;
3. для нестабильного канала включается soft binding;
4. журнал связывает идентификатор запроса с хэшем и результатом валидации;
5. при потере манифеста публикация блокируется или переводится в режим дополнительной проверки.

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

Шестой этап: соберите пакет доказательств для запуска

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

В него включите:

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

Разложите тесты по официальным критериям:

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

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

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

Сценарий отказа: файл подписан, но пользователь получает уже другой актив

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

На первом сервере всё выглядит правильно. В журнале есть подпись. Однако финальный файл может:

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

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

Если вы не контролируете платформу назначения, заранее определите предел гарантии. Например: «маркировка подтверждается до передачи во внешний сервис» — это честнее, чем заявлять, что конечный пользователь всегда сможет проверить происхождение.

Что проверить после запуска

После первой успешной проверки процесс не заканчивается. Повторяйте тесты при следующих изменениях:

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

Для временной изоляции такой конвейер можно воспроизвести на консоли MacHTML, а требования к подключению и окружению сверить в справочном разделе MacHTML. Это особенно удобно, если производственная среда занята, а вам нужно отдельно проверить подпись, перекодирование, скачивание и откат версии.

При сложном AI Agent сначала изолируйте цепочку: генерация — обработка — маркировка — публикация. Затем добавляйте внешние интеграции по одной. Иначе вы не сможете определить, на каком этапе исчез манифест или структурированное поле.

Где C2PA недостаточно

Решение «оставить только C2PA» рискованно, если у вас есть хотя бы один из признаков:

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

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

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

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

Окончательное решение по применимости Article 50, статусу вашей организации, переходному сроку и достаточности выбранных мер должен принять профильный специалист по праву ЕС. Техническая задача команды — передать ему проверяемую архитектуру, реальные границы метода и пакет доказательств, а не обещание «мы поставили стандарт, значит всё выполнено».

Читайте также: Новые правила регулирования ИИ для разработчиков в 2026 году Аудит безопасности AI-систем: проверки, риски и подготовка доказательств соответствия