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

Да, существование приватного набора данных можно подтвердить, не публикуя сам набор.
Схема короткая: вы строите манифест набора данных, хешируете его записи, сворачиваете эти хеши в единый корень Merkle и публикуете одну запись Proof of Existence Label 309 в Cardano. Сам набор данных при этом никогда не покидает ваш контроль. Позже вы можете раскрыть ровно один файл, строку, запись манифеста или доказательство включения, чтобы показать, что элемент входил в зафиксированный снимок, — и ничего сверх этого.
Это подтверждает факт прежнего владения на определённый момент времени. Само по себе оно не доказывает право собственности, авторские права, наличие согласия или законность использования. Это отдельные вопросы, для которых нужны отдельные записи.
Зачем это команде, работающей с ИИ?
Обучающие данные превратились в вопрос уровня совета директоров. Поставщику модели может потребоваться показать, какими данными он располагал, когда они у него появились, откуда они пришли, как обрабатывались и какие наборы данных легли в основу конкретной версии модели, — для инвесторов, партнёров, клиентов, регуляторов, аудиторов, лицензиаров или судебного разбирательства.
При этом компания зачастую не может опубликовать набор данных. В нём может быть лицензированный контент, данные клиентов, персональные данные, проприетарные источники, внутренняя разметка, коммерческие тайны, оценки безопасности, корпуса для поиска, синтетические данные или чувствительные правила фильтрации.
Proof of Existence снимает это противоречие. Подтверждение существования позволяет зафиксировать состояние и хронологию набора данных, не раскрывая его публично. Вы публикуете отпечаток — а байты остаются у вас.
Что фиксировать: сырые данные или манифест?
Фиксируйте манифест, а не одни лишь сырые байты.
Манифест набора данных описывает снимок в структурированном машиночитаемом виде. В нём можно зафиксировать:
- название набора данных и идентификатор снимка;
- период сбора;
- категории источников и метаданные о правах;
- хеши по каждому файлу и по каждой строке;
- версии дедупликации и фильтрации;
- версии конвейеров разметки и предобработки;
- модель или цикл обучения, в котором он использовался;
- политику хранения и внутреннюю принадлежность.
Манифест не обязан раскрывать публично ни одной чувствительной детали. Он может полностью оставаться внутри компании. Публичное подтверждение фиксирует только его хеш или корень Merkle над множеством записей манифеста. Цель узкая и долговечная: заморозить свидетельство состояния набора данных на известный момент времени.
Зачем корень Merkle вместо отдельной записи на каждый файл?
Наборы данных велики, и публикация отдельной записи на каждый файл или строку не масштабируется. Эту проблему решает корень Merkle: он фиксирует упорядоченный список из множества хешей под единым 32-байтовым значением, закреплённым в одной транзакции.
Позже, чтобы подтвердить включение одного элемента, вы раскрываете только:
- сам элемент или его хеш;
- соответствующую запись манифеста;
- доказательство включения Merkle;
- ссылку на транзакцию Label 309.
Верификатор пересчитывает путь от этого листа до корня и подтверждает, что корень был опубликован в конкретное блочное время Cardano. Размер доказательства растёт как логарифм размера пакета, поэтому остаётся компактным даже при миллионах листьев. Что важно, построение дерева и проверка доказательств — это чисто офлайновые вычисления: на этапе проверки не нужен ни сервер, ни учётная запись, ни какое-либо содействие с вашей стороны.
Именно это делает возможным выборочное раскрытие. Вам никогда не приходится раскрывать весь набор данных, чтобы подтвердить, что один элемент входил в зафиксированный снимок.
Что на самом деле видит публика?
Только запись-подтверждение в блокчейне. В зависимости от того, как именно вы публикуете, она может включать хеш манифеста, корень Merkle, число листьев, время транзакции, необязательную подпись вашей компании или системы и необязательные контентно-адресуемые URI (ar://, ipfs://) для публичных или зашифрованных вспомогательных материалов.
Публика не видит файлы набора данных, полный список листьев, метаданные источников, данные клиентов, детали лицензирования, разметку или внутренние заметки. Всё это остаётся внутри вашей системы хранения свидетельств до тех пор, пока конкретный вопрос не потребует раскрытия.
Что и когда вы раскрываете потом?
Раскрывайте только то, что требует вопрос.
- Был ли файл в наборе данных? Раскройте файл или его хеш, запись манифеста и доказательство включения.
- Включена ли была категория источников? Раскройте соответствующий раздел манифеста и доказательство того, что он входит в зафиксированный снимок.
- Использовала ли версия модели конкретный снимок? Раскройте манифест цикла обучения, связывающий версию модели с корнем набора данных.
- Это полный аудит? Раскройте весь манифест и список листьев в рамках подходящей процедуры конфиденциальности.
Корень в блокчейне подтверждает хронологию. А ваш внутренний архив определяет, сколько деталей вы можете показать и кому. Для случаев, когда сам вспомогательный материал должен попасть к третьей стороне, но остаться приватным, вы можете передать его конфиденциально, а не делать публичным.
Как это связано с регулированием ИИ?
Регулирование ИИ движется в сторону более строгих требований к документированию и прозрачности. Например, EU AI Act устанавливает правила прозрачности и нормы, связанные с авторским правом, для моделей ИИ общего назначения, а Европейская комиссия опубликовала шаблон публичного резюме об обучающем контенте, описанный, по собственным словам комиссии, как минимальная базовая планка для информации, которая должна быть доступна публично.
Подтверждение приватного набора данных — это не то же самое, что такое публичное резюме. Оно не заменяет регуляторную отчётность, юридическую экспертизу, управление согласиями или записи о лицензировании, и поможет ли что-либо из этого в конкретной ситуации, зависит от вашей юрисдикции и ваших юристов.
Зато оно может укрепить слой свидетельств, стоящий за этими процессами. Если компании позже понадобится показать, чем она располагала, что знала или на каком снимке основано опубликованное резюме, фиксация манифеста с меткой времени даёт конкретное, закреплённое третьей стороной свидетельство хронологии и целостности.
Что на самом деле подтверждает подтверждение набора данных?
Оно подтверждает, что конкретная фиксация набора данных существовала к публичному блочному времени. В зависимости от того, какие свидетельства вы сохраняете, это помогает показать, что:
- файл входил в снимок набора данных;
- манифест существовал до возникновения спора;
- версия набора данных существовала до выпуска модели;
- цикл обучения ссылался на конкретный снимок;
- категория источников была задокументирована в тот момент;
- конвейер предобработки или фильтрации был зафиксирован.
Если запись подписана — а Label 309 поддерживает необязательные подписи уровня записи, — она также может показать, что ключ компании или системы поручился за эту фиксацию. Подпись никогда не требуется, поэтому неподписанная фиксация так же действительна; подпись лишь добавляет атрибутируемое авторство.
Что оно не подтверждает?
Об этом стоит говорить честно, потому что пробелы здесь важны.
Подтверждение набора данных не доказывает, что данные можно было использовать законно. Оно не доказывает, что данные принадлежали вам, что они собраны с согласия или каков их статус с точки зрения авторского права. Оно не доказывает, что данные действительно применялись для обучения, — если только ваш конвейер обучения и записи о модели сами не привязаны к снимку набора данных. И оно не доказывает, что манифест полон; убедительной полноту делают только ваши процессы и средства контроля.
Proof of Existence — это свидетельство хронологии и целостности. Оно устанавливает, что определённые байты существовали к публичному моменту времени. Оно ничего не говорит об истинности, праве собственности, правах или соответствии требованиям — для этого нужны дополнительные записи и юридический анализ. Если вам нужна полная картина того, где проходит эта граница, см. что подтверждение доказывает, а что — нет.
Как выстроить рабочий процесс?
Проектируйте под вопрос, на который вы ожидаете ответить позже, а не просто под сегодняшнее хеширование.
Рабочая схема:
- Определите канонический формат манифеста набора данных.
- Хешируйте каждый элемент набора данных или запись манифеста.
- Постройте корень Merkle для снимка.
- Опубликуйте запись Label 309 — с подписью, если вам нужно атрибутируемое авторство.
- Сохраните манифест, список листьев и материал для доказательств включения.
- Свяжите циклы обучения моделей с корнями наборов данных.
- Запечатайте чувствительные пакеты свидетельств для получателей из юридического отдела или комплаенса.
- Фиксируйте замещающие снимки, когда набор данных меняется.
Сложность редко в криптографии. Сложность в том, чтобы решить, какие свидетельства окажутся значимыми, когда о них спросят через месяцы или годы.
Как часто фиксировать снимок?
Фиксируйте всякий раз, когда набор данных существенно меняется, — обычно после новой загрузки данных, перед циклом обучения, после дедупликации или фильтрации, после разметки, перед выпуском модели, на контрольной точке управления или перед передачей набора данных партнёру.
Частота должна соответствовать вопросам, на которые вы рассчитываете отвечать. Фиксируйте раз в год — и вы, возможно, не сможете подтвердить, какой промежуточный снимок существовал. Фиксируйте при каждом мелком изменении — и вы породите операционный шум. Поскольку пакетирование Merkle позволяет одному корню заменить целый снимок — одна транзакция, сколько бы файлов она ни охватывала, — стоимость остаётся примерно постоянной на каждую фиксацию, и вы можете выбрать частоту под нужные вам свидетельства, а не под диктат цены.
При чём здесь запечатанное хранилище?
Иногда хеширования недостаточно — вы хотите сохранить само свидетельство, а не только его отпечаток.
Это позволяет сделать запечатанное PoE. Публичная запись по-прежнему фиксирует хеш открытого текста — ровно так же, как и обычное подтверждение. Чувствительные данные шифруются и хранятся по контентно-адресуемому URI, а ключ шифрования содержимого упаковывается под один или несколько ключей получателей. Уполномоченные получатели смогут позже расшифровать их и подтвердить, что восстановленный открытый текст соответствует фиксации в блокчейне, пересчитав хеш.
Блокчейн никогда не несёт открытый текст и никогда не раскрывает, кто получатели; он показывает лишь то, что запечатанная фиксация была сделана в момент времени T. Это важно, когда потеря исходного манифеста ослабила бы ваше подтверждение. Запись только с хешем подтверждает существование, пока у вас всё ещё есть файл. Запечатанная запись может сохранить сам зашифрованный файл, так что свидетельство и фиксация остаются вместе.
Стоит честно назвать одно ограничение: запечатывание сохраняет содержимое приватным от всех, кроме выбранных держателей ключей, но не делает никого анонимным, и получатель всегда может слить открытый текст после расшифровки. Запечатывание управляет тем, кто может читать, а не тем, что человек делает дальше.
Кому владеть этим процессом?
Процесс подтверждения наборов данных не должен быть бесхозным инженерным скриптом. Он затрагивает юристов, безопасность, управление данными, комплаенс и разработку моделей, и хороший процесс делает границы явными: кто может создавать снимки, кто может подписывать фиксации, где хранятся манифесты, кто может расшифровывать запечатанные пакеты, как формируются доказательства включения, как циклы обучения связываются с корнями, как обрабатываются замещённые снимки и как свидетельства предоставляются во время аудита или спора.
Подтверждение криптографично. Управление организационно. Нужно и то, и другое.
Коротко
Чтобы подтвердить обучающие данные, не раскрывая их, фиксируйте снимок, а не набор данных. Постройте манифест, захешируйте его записи, опубликуйте корень Merkle в записи Label 309 и сохраните список листьев и доказательства включения. Запечатывайте чувствительные вспомогательные файлы, когда их потеря ослабила бы подтверждение. А затем раскрывайте только те свидетельства, которые действительно требует каждый вопрос.
Это даёт вам долговечное, закреплённое третьей стороной подтверждение факта прежнего владения и хронологии. Само по себе оно не доказывает право собственности, законность использования или соответствие требованиям — и оно наиболее полезно, когда вы чётко понимаете, что именно из этого оно делает, а что нет.
Что почитать дальше
- Открытый стандарт, лежащий в основе этих подтверждений: label309.org. Он подаётся в процесс Cardano CIP и находится на рассмотрении редакторов CIP; следить за предложением можно в открытом pull request.
- Открытые SDK и CLI
cardanowall, которые строят манифесты, деревья Merkle и доказательства включения офлайн: github.com/cardanowall. - Одна запись для тысяч файлов — как устроено пакетирование Merkle в деталях.
- Манифесты наборов данных для ИИ — как структурировать манифест, который вы фиксируете.
- Конфиденциальное раскрытие без публичных файлов — как передать свидетельство контрагенту, не публикуя его.