Я попытался создать детектор AI-изображений. Вместо этого я разобрался, как на самом деле работает C2PA

Я начал этот проект с простого предположения: если взять произвольное изображение — например, созданное онлайн-сервисом на основе AI, — валидатор сможет определить, откуда оно появилось.

Было ли оно снято камерой? Создано AI? Какое приложение его подготовило? Изменял ли его кто-то впоследствии?

Это предположение оказалось ошибочным.

Когда я начал изучать C2PA Content Credentials и экспериментировать с библиотекой Credentio с открытым исходным кодом от Google, различие стало очевидным. C2PA — не детектор AI. Он не анализирует пиксели и не пытается угадать, как было создано изображение. Он проверяет криптографически подписанные сведения о происхождении, когда такие сведения доступны.

Чтобы увидеть, как это работает на практике, я создал Credentio Local Checker — небольшой веб-интерфейс с открытым исходным кодом, который выполняет проверку локально.

Вопрос, на который я изначально хотел получить ответ

Я представлял себе инструмент, который возьмёт изображение из неизвестного источника и даст простой ответ:

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

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

Камера, приложение или AI-сервис с поддержкой стандарта могут создать C2PA-манифест с утверждениями о том, как материал был создан или изменён. Эти утверждения подписываются криптографически и встраиваются в файл либо связываются с ним. После этого валидатор может изучить запись и проверить, остаётся ли она действительной.

Ключевое различие заключается в следующем:

C2PA не определяет, что произошло. Он проверяет подписанные утверждения о том, что произошло.

Что могут рассказать Content Credentials

В зависимости от того, какие сведения записали автор или приложение, Content Credentials могут описывать:

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

Валидатор может проверить:

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

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

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

Три результата, которые нельзя смешивать

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

1. Действительные Content Credentials

Манифест найден, проверки его целостности пройдены, а подписи удалось подтвердить.

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

2. Обнаружена проблема целостности

Файл содержит Content Credentials, но одна или несколько проверок завершились неудачно.

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

3. Content Credentials не найдены

Это нейтральный результат, а не ошибка проверки.

Файл может быть:

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

Отсутствие Content Credentials не доказывает ни один из этих вариантов. Называть такой файл «настоящим» или «поддельным» означало бы выйти за пределы имеющихся данных.

Почему я использовал Google Credentio

13 августа 2026 года Google представила Credentio — C++-библиотеку с открытым исходным кодом для проверки C2PA Content Credentials.

Исходный код опубликован в репозитории Google Media Provenance по лицензии Apache License 2.0.

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

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

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

Как работает локальный валидатор

Архитектура намеренно сделана простой:

Браузер
   ↓
Локальный Node.js-сервер на 127.0.0.1
   ↓
Временный файл с ограниченными правами доступа
   ↓
Локально собранный C++-валидатор Credentio
   ↓
Результат crJSON
   ↓
Понятный человеку отчёт в браузере

Пользователь выбирает материал в браузере. Браузер передаёт его процессу Node.js, работающему на том же компьютере. Сервер передаёт временный файл локально собранной программе Credentio, разбирает результат, возвращает сводку в браузер, а затем удаляет временный файл.

Интерфейс показывает:

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

Это не облачный сервис проверки. Приложение привязывается только к loopback-интерфейсу и предназначено для запуска на компьютере пользователя.

Проверка четырёх разных сценариев

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

Действительный подписанный JPEG

Первый образец содержит действительные Content Credentials. Credentio сообщает:

• 4 манифеста;
• 40 успешных проверок;
• 0 ошибок;
• 4 доверенные подписи из 4;
• подписант — Google LLC.

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

Изменённый JPEG

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

• 4 манифеста;
• 39 успешных проверок;
• 1 ошибку;
• код проверки assertion.dataHash.mismatch.

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

JPEG без Content Credentials

Третий образец не содержит C2PA-манифеста. Интерфейс намеренно считает это отдельным нейтральным состоянием, а не ошибкой проверки.

Назвать файл «поддельным» означало бы выйти за пределы имеющихся данных. Валидатор может сообщить лишь о том, что Content Credentials не найдены.

Действительный подписанный MP4

Четвёртый образец показывает, что тот же подход применим и к видео. Credentio сообщает:

• 2 манифеста;
• 19 успешных проверок;
• 0 ошибок;
• 2 доверенные подписи из 2.

Файл остаётся локальным

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

Поэтому в проекте действуют несколько ограничений, обеспечивающих локальную работу:

• сервер слушает только 127.0.0.1;
• выбранные материалы не загружаются в Google или другой облачный сервис;
• временные каталоги доступны только владельцу;
• временные материалы удаляются после проверки;
• межсайтовые запросы на загрузку отклоняются;
• интерфейс отдаётся со строгой политикой безопасности контента (Content Security Policy);
• исходный crJSON остаётся в локальном браузере.

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

Воспроизводимая настройка

Credentio — C++-проект, который собирается с помощью Bazel.

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

• Credentio;
• Android LibCppBor;
• списки доверия C2PA;
• общедоступные тестовые материалы.

Сценарий настройки проверяет контрольные суммы SHA-256 для загруженных списков доверия и образцов. Созданные зависимости и исполняемые файлы хранятся в игнорируемом каталоге .runtime, а не добавляются в репозиторий.

Текущая процедура настройки рассчитана на macOS и протестирована на Apple Silicon.

npm install
npm run setup
npm start

После этого интерфейс становится доступен по адресу:

http://127.0.0.1:3210

Первая нативная сборка может занять несколько минут. Последующие сборки используют локальный кеш Bazel.

Чего проект не делает

Credentio Local Checker не умеет:

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

Это экспериментальный интерфейс проверки, а не промышленный сервис фактчекинга.

Что я узнал

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

Чтобы C2PA давал значимый сигнал:

1. устройство или приложение должно создать Content Credentials;
2. инструменты редактирования должны сохранить или дополнить их;
3. платформы распространения не должны удалять их;
4. получатель должен проверить подписи;
5. получатель должен решить, заслуживает ли подписант доверия.

Если какая-либо часть этой цепочки отсутствует, вывод становится слабее.

Это не делает C2PA бесполезным. Стандарт решает более точную задачу, чем «обнаружить поддельный контент». Лучше описать её так:

C2PA предоставляет инфраструктуру для создания проверяемых утверждений о происхождении цифровых медиаматериалов.

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

Ссылки проекта

• Страница проекта
• Исходный код на GitHub
• Анонс Google Credentio
• Спецификация и материалы C2PA

Credentio Local Checker — независимый экспериментальный проект. Он не является официальным продуктом Google или C2PA и не одобрен ни одной из этих организаций.