Сохраняйте не только финальный файл и prompt, а связанный паспорт: цель и владелец решения, сервис и точная версия модели, режим и параметры, полный ввод, reference assets и права на них, даты, выбранные и отклонённые версии, существенные правки, согласия людей, экспортные настройки, хэш каждой контрольной версии и статус Content Credentials. Provenance помогает восстановить историю, но сам по себе не доказывает истинность сведений и не создаёт лицензию.

Почему одного prompt недостаточно

Текст запроса описывает только часть процесса. Он не сообщает, какая версия модели его интерпретировала, был ли включён автоматический rewrite, какие изображения загружались как reference, кто имел право их использовать и какие изменения внесены после генерации. Одинаковый prompt в другой версии сервиса может дать другой результат. А финальный JPEG может быть обрезан, перекрашен, собран из нескольких вариантов и лишён исходных metadata.

Поэтому единицей учёта должен быть не «запрос», а визуальный актив как цепочка состояний. У цепочки есть намерение, входы, действия, ответственные люди, промежуточные сущности и выпуск. Такая логика совпадает с базовой моделью W3C PROV: Entity, Activity и Agent. Для редакции это можно перевести без сложной онтологии: файл или prompt — сущность, генерация и правка — действие, автор решения или сервис — участник.

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

Восемь разделов паспорта

1. Идентичность и назначение

Присвойте assetId, не зависящий от имени файла. Запишите materialId или projectId, назначение изображения, владельца финального решения, дату создания и допустимые каналы использования. Отдельно укажите статус: черновик, на проверке, разрешён к выпуску, отозван или архивирован. Имя вроде final-final-3.webp не является идентификатором и не объясняет, какой файл действительно опубликован.

2. Генеративная среда

Зафиксируйте поставщика, продукт, модель, доступную версию или model ID, интерфейс либо API, регион аккаунта при необходимости и дату генерации. Сохраните режим: text-to-image, edit, inpainting, variation, style reference или subject reference. Добавьте все параметры, которые реально влияли на вывод: aspect ratio, seed, strength, quality, prompt rewrite, watermark setting, число результатов. Не заполняйте поле, если сервис не раскрывает значение.

3. Ввод

Сохраните исходный prompt без «улучшения памяти», negative prompt, system preset, shot-list строку и локальные настройки. Если интерфейс показывает переписанную моделью версию запроса, сохраните и исходный, и преобразованный текст с понятными названиями. Секреты, персональные данные и закрытые документы не переносятся в паспорт открытым текстом: укажите безопасную ссылку на защищённое хранилище и уровень доступа.

4. Reference assets

Для каждого загруженного изображения запишите собственный ID, автора или правообладателя, источник, дату получения, лицензию или договор, разрешённую цель, ограничения, хэш и роль: style, subject, composition, mask, texture. Если право на загрузку не подтверждено, не обозначайте поле как «разрешено»; поставьте ручную проверку и не выпускайте актив. Открытая URL не равна разрешению на использование в генеративном сервисе.

5. Человеческие решения

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

6. Правки и производные версии

Создайте запись на каждую контрольную версию: generated source, selected source, edited master, crop for web, compressed delivery. Для версии укажите parentAssetId, программу и действие, исполнителя, время, размер, формат, цветовой профиль и хэш. Не нужно сохранять сотни автоматических previews навсегда; сохраните все входы, отобранные кандидаты и точки, после которых материал существенно изменился.

7. Права, согласия и ограничения

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

8. Выпуск и проверка

Запишите имя опубликованного файла, URL, alt, caption, размеры, хэш доставки, дату публикации, disclosure об использовании AI, статус Content Credentials и результат визуального дубль-check. После замены файла создайте новую версию и отметьте предыдущую как отозванную, а не переписывайте историю. Так редакция может сопоставить публичный объект с конкретным проверенным master.

Минимальный шаблон

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

  • Identity: assetId, projectId, purpose, status, decisionOwner, createdAt.

  • Generator: provider, product, modelId, mode, parameters, generatedAt.

  • Input: promptOriginal, promptRewritten, negativePrompt, referenceAssetIds.

  • Decisions: selectedOutputId, selectionReason, materialEdits, reviewer.

  • Rights: inputRightsStatus, peopleConsentStatus, licenseRefs, attribution, legalReviewAt.

  • Lineage: parentAssetId, version, fileName, sha256, exportSettings.

  • Publication: deliverySha256, publicUrl, alt, disclosure, credentialsStatus.

Не превращайте отсутствие данных в красивый ноль. Значения UNKNOWN, NOT_APPLICABLE и MANUAL_REVIEW полезнее ложной точности. Если seed недоступен, так и укажите. Если модель отображается только маркетинговым названием без номера версии, сохраните название, скриншот интерфейса и дату. Паспорт должен различать факт, заявление сервиса и внутреннее предположение.

Хэш: что он делает и чего не делает

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

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

Для разных экспортов будут разные хэши. Не пытайтесь добиться одного значения для master, WebP и thumbnail. Свяжите их как производные версии. Если нужна устойчивость к визуально похожим файлам после перекодирования, это отдельная задача perceptual hashing или soft binding; обычный SHA-256 её не решает.

C2PA и Content Credentials

C2PA описывает Content Credential как криптографически связанную структуру с утверждениями об истории актива. Она может фиксировать создание, изменения, используемые инструменты и AI-составляющую. Подпись и trust list помогают проверить, что credential связан с файлом и не был незаметно изменён после подписания. Это сильнее простой строки metadata, но требует корректной реализации и защиты ключей.

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

Metadata могут удаляться платформами или при экспорте. Content Authenticity Initiative развивает сочетание metadata, watermarking и fingerprinting для более устойчивого восстановления credential, но поддержка не универсальна. На выпуске проверяйте фактический доставочный файл через совместимый verifier, а не наличие значка в исходной программе. Если credential отсутствует, не делайте вывод, что изображение «точно человеческое»; отсутствие данных — только отсутствие данных.

IPTC metadata как переносимый слой

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

Встроенные поля должны дублировать критический минимум паспорта, но не весь внутренний журнал. Не помещайте в публичный файл закрытые prompts, персональные данные, номера договоров или адреса хранилищ. Составьте mapping: какое поле паспорта идёт в IPTC/XMP, какое — в C2PA assertion, какое остаётся только в защищённой CMS. Проверьте экспорт, CDN-оптимизацию и социальные сети: каждый этап может менять файл и удалять metadata.

Практическая структура папки

Даже без DAM можно создать переносимый комплект. В каталоге актива храните passport.json, prompt.txt, source-assets.json, rights/, selected-source, edited-master и delivery/. В rights/ находятся не секретные копии разрешений или ссылки на защищённые документы. Файлы называются по assetId и версии, а не по эмоции автора. Автоматизация считает хэши, но не подставляет фиктивную лицензию.

Для серии добавьте общий manifest с style anchor и shot list, а каждый кадр получает собственный паспорт. Способ собрать постоянные и переменные части описан в материале про промпт для серии изображений. Общий prompt не отменяет индивидуальные reference assets, отбор, правки, хэши и выпускной файл каждого кадра.

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

Проверка перед публикацией

Сверьте master и delivery по цепочке версий. Убедитесь, что паспорт называет фактически использованную модель и prompt, все reference assets имеют основание, согласия людей охватывают канал и цель, итоговый файл прошёл визуальную проверку, disclosure соответствует редакционной политике, а public URL связан с delivery hash. Затем откройте файл в независимом metadata viewer и C2PA verifier, если credential заявлена.

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

Практический следующий шаг

Выберите один уже созданный файл и попробуйте заполнить минимальный паспорт без догадок. Каждое неизвестное значение отметьте UNKNOWN, каждое неподтверждённое право — MANUAL_REVIEW. Посчитайте хэш master и delivery, проверьте встроенные metadata и наличие credential. Список пробелов станет планом улучшения pipeline: добавить сохранение prompts, идентификаторы референсов, отдельный rights-check или проверку после CDN.

Что читать дальше