Право на забвение против права на вечность: как GDPR и неизменяемый реестр столкнулись в одной точке — и что с этим делать

Два закона, которые не могут оба быть правы

Письмо, на которое нечем ответить

Представьте обычное утро в компании, которая построила сервис на блокчейне. В почте — письмо от пользователя. Текст короткий и вежливый: «Прошу удалить мои персональные данные. Основание — статья 17 GDPR».

Дальше начинается то, чего человек с той стороны не видит.

Юрист смотрит на календарь: по статье 12(3) на ответ есть один месяц, при сложности запроса срок можно продлить ещё на два. Итого максимум три. Инженер смотрит на архитектуру и говорит фразу, после которой в переписке обычно наступает пауза: удалить нельзя. Не «сложно», не «дорого», не «нужен спринт». Нельзя — потому что запись уже разошлась по узлам сети, которые компании не принадлежат, и вся ценность этой сети ровно в том, что запись оттуда не убирается. Неизменяемость — не побочный эффект, это то, за что заплатили.

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

Это не спор о том, «как правильно»

Обычно такие ситуации описывают как конфликт технологии и регулирования: мол, право отстало от инженерии, подождём — догонит. Это удобная, но неверная рамка.

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

Первая — статья 17 GDPR, официально она называется «Right to erasure ('right to be forgotten')». Обратите внимание на кавычки: «право быть забытым» — это не самостоятельное право, а неофициальный синоним. Юридический термин — право на стирание. Регламент действует с 25 мая 2018 года и применяется напрямую во всех государствах ЕС. В статье 17(1) шесть оснований для удаления, и перечень закрытый: данные больше не нужны для целей сбора; отозвано согласие и нет другого основания; заявлено возражение против обработки, и у контролёра нет перевешивающих законных оснований; обработка была незаконной; удаления требует закон; данные собраны у ребёнка при оказании онлайн-услуг.

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

Формально закон, конечно, побеждает физику: правовая норма не отменяется тем, что её трудно исполнить. Но именно поэтому конфликт и не решается сам собой — исполнить норму нужно, а способа нет.

Два регулятора, два разных ответа

Показательно, что даже надзорные органы ЕС отвечают на этот вопрос по-разному — и со временем отвечают всё жёстче.

Французская CNIL ещё в 2018 году выпустила отчёт о блокчейне и GDPR и признала прямо: удовлетворить запрос на стирание технически невозможно, когда данные записаны в цепь. Дальше CNIL предложила обходной путь — класть в блокчейн не сами данные, а криптографическое доказательство их существования, а исходники и ключи хранить снаружи и уничтожать по запросу. Так можно, по формулировке CNIL, приблизиться к эффекту удаления. Но там же честная оговорка: за вычетом отдельных криптографических схем эти решения, строго говоря, стиранием не являются — данные в блокчейне остаются. И вывод, который редко цитируют: CNIL признаёт ценность этих решений, но сомневается в их способности обеспечить полное соответствие GDPR.

Общеевропейский орган — EDPB — в руководстве по обработке персональных данных через блокчейн (финальная версия принята 7 июля 2026 года) формулирует позицию заметно резче. Ключевая фраза: техническая невозможность не может служить оправданием несоблюдения требований GDPR. Логика простая и неудобная: защита данных должна закладываться на этапе проектирования, а значит выбор архитектуры, из которой ничего не удаляется, — это ваше решение, принятое заранее, а не обстоятельство непреодолимой силы.

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

Разница между позициями 2018 и 2026 года — это разница между «понимаем, что вы не можете» и «то, что вы не можете, — следствие вашего выбора».

Почему это касается не только блокчейна

Легко решить, что проблема узкая: не строй на блокчейне — не будет и конфликта. Но линия разлома проходит шире.

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

И ещё одно: сам GDPR нигде не определяет, что такое «erasure». Ни в статье 17, ни в преамбулах определения нет. Исследование, подготовленное для Европарламента его исследовательской службой EPRS (PE 634.445, июль 2019), отмечает это прямо и добавляет: есть основания считать, что физического уничтожения не требуется — в деле Google Spain достаточным сочли удаление ссылки из поисковой выдачи, а не самой публикации. Газета осталась. Ссылка исчезла.

То есть спор идёт не о том, чья технология лучше. Спор идёт о том, что вообще значит слово «удалить», — и от ответа зависит, законна ли ваша архитектура.

Что дальше в этой статье

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

Что на самом деле требует статья 17 — все шесть оснований, все пять исключений, реальные сроки. Что постановил Суд ЕС в деле Google Spain 2014 года и почему его логика устаревания информации бьёт по вечным хранилищам сильнее, чем кажется. Где проходят территориальные границы права на забвение после решения по делу Google против CNIL 2019 года — и почему расхожее «Суд ЕС запретил глобальное удаление» неточно.

Затем — техническая сторона: что такое криптографическое стирание по стандарту NIST, почему стандарт относит его к уровню «purge», а не «destroy», и при каких условиях оно не срабатывает. Отдельно — почему EDPB считает персональными данными и шифротекст, и хеш, и какая единственная конструкция, по мнению и CNIL, и EDPB, выводит запись из-под GDPR.

И наконец — цена вопроса. Нарушение статьи 17 попадает в верхний уровень штрафов по статье 83(5): до 20 миллионов евро, а если нарушитель — предприятие, то до 4% его мирового годового оборота за предыдущий финансовый год, причём берётся бо́льшая из двух величин.

Готового ответа в конце не будет — его нет ни у CNIL, ни у EDPB, ни у Суда ЕС. Будет карта: где твёрдая почва, где спор, а где обрыв.

Право на забвение: откуда оно взялось

История одного объявления о торгах

В марте 2010 года испанец Марио Костеха Гонсалес подал жалобу в национальный орган по защите данных. Повод был прозаический до неловкости: если набрать его имя в Google, поиск выдавал ссылки на две страницы газеты La Vanguardia. Публикации от 19 января и 9 марта 1998 года — объявление о продаже недвижимости с торгов в счёт погашения долгов по социальному страхованию.

Производство по взысканию было урегулировано целиком и много лет назад. Но имя человека продолжало склеиваться с этими двумя страницами при каждом запросе — от потенциального работодателя, партнёра, соседа. Заявитель написал в жалобе, что упоминание стало полностью нерелевантным.

Испанский регулятор AEPD 30 июля 2010 года принял решение, которое многое объясняет в устройстве этого права. Жалобу против газеты он отклонил: публикация была законной, она делалась по распоряжению Министерства труда, чтобы обеспечить торгам максимальную огласку. А жалобу против Google — удовлетворил.

Разница здесь не техническая, а смысловая. Газета сделала ровно то, что должна была сделать в 1998 году. Поисковик делает нечто другое: он собирает разрозненные следы человека в один список и держит его наготове двенадцать лет спустя.

Что сказал Суд ЕС

13 мая 2014 года Большая палата Суда Европейского союза вынесла решение по делу C-131/12 — Google Spain SL and Google Inc. v AEPD and Mario Costeja González. Тогда GDPR ещё не существовал: суд применял Директиву 95/46/EC и статьи 7 и 8 Хартии основных прав ЕС.

Суд постановил четыре вещи, и каждая была неочевидной.

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

Второе: юрисдикция ЕС достаётся Google через испанскую дочернюю компанию, которая продаёт рекламу. Продажа рекламных мест оказалась достаточной привязкой.

Третье — самое важное. Оператор обязан удалить ссылку из результатов поиска по имени человека даже тогда, когда сама страница остаётся нетронутой и даже, смотря по обстоятельствам, когда публикация на ней сама по себе законна. Ответственность поисковика автономна от ответственности издателя. Газета остаётся, ссылка исчезает.

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

Почему именно поисковик

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

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

Это редкая для права мысль: истина о человеке не портится, но её уместность — портится. Объявление 1998 года не стало ложью. Оно перестало что-либо говорить о том, кто такой Костеха в 2014-м. В пункте 98 суд прямо сослался на то, что первичная публикация состоялась шестнадцатью годами ранее.

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

Как это стало статьёй закона

Почти через два года, 27 апреля 2016 года, был принят GDPR — Регламент (ЕС) 2016/679, применяющийся с 25 мая 2018 года. Логика Google Spain получила в нём отдельную статью.

Статья 17 называется «Right to erasure ('right to be forgotten')» — «Право на стирание („право быть забытым")». Обратите внимание на кавычки внутри самого названия: «право на забвение» — неофициальный синоним, красивое имя для газетных заголовков. Юридический термин — право на стирание.

Оснований ровно шесть, перечень закрытый:

• (a) данные больше не нужны для целей, ради которых собирались;
• (b) человек отозвал согласие — и другого правового основания нет;
• (c) человек возразил против обработки, и нет перевешивающих законных оснований (а против прямого маркетинга возражение действует безусловно);
• (d) обработка была незаконной;
• (e) стирание требуется по закону ЕС или государства-члена;
• (f) данные собраны у ребёнка при оказании онлайн-услуг.

Пункт 2 статьи 17 — прямое наследство дела Костехи. Если контролёр обнародовал данные, он обязан разумными мерами уведомить других контролёров, что человек требует удалить ссылки, копии и репликации. С честной оговоркой: «с учётом доступных технологий и стоимости реализации». Это не обязательство результата.

Срок задан не в статье 17, а в статье 12(3): без неоправданной задержки и в любом случае в течение месяца, с возможностью продления ещё на два — итого до трёх.

Пять дверей, которые остаются открытыми

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

Стирать не обязаны, когда обработка необходима:

• (a) для осуществления свободы выражения и информации — сюда попадает журналистика;
• (b) для исполнения юридической обязанности, выполнения задачи в публичном интересе или осуществления официальных полномочий;
• (c) по причинам публичного интереса в сфере общественного здравоохранения;
• (d) для архивирования в публичном интересе, научных или исторических исследований, статистики — но только если стирание сделает достижение этих целей невозможным или серьёзно затруднит;
• (e) для установления, осуществления или защиты правовых требований.

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

Зачем это людям

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

Поиск отменил несовершенство. Теперь по умолчанию — вечное припоминание, причём выборочное: не биография, а её худшие пять минут, поднятые на первую строку выдачи. Долг, погашенный в девяностых. Обвинение, снятое судом. Ошибка, сделанная в девятнадцать.

Статья 17 — это попытка вернуть то, что раньше давала природа, юридическими средствами. И она честно признаёт, что права здесь сталкиваются: право одного человека на будущее — против права всех остальных знать прошлое. GDPR не разрешает этот конфликт раз и навсегда. Он лишь предписывает взвешивать — каждый раз заново, с оглядкой на то, сколько прошло времени и кто перед нами: частное лицо или тот, чью роль в публичной жизни общество вправе помнить.

Неизменяемость: почему блокчейн не умеет забывать

Обычная база данных устроена так, что запись можно поправить. Есть строка — есть команда «обновить», есть кнопка «удалить». Блокчейн строили люди, которые считали ровно это уязвимостью: если запись можно тихо изменить, значит, кто-то однажды изменит её в свою пользу.

Хеш: отпечаток, который нельзя подделать

В основе всего — хеш-функция. Это математическая мясорубка: на вход подаётся что угодно (строка, файл, целая книга), на выходе всегда получается короткая строка фиксированной длины. У неё три важных свойства:

• одинаковый вход всегда даёт одинаковый выход;
• изменение одного символа во входе меняет выход целиком — не «немного», а до неузнаваемости;
• по выходу нельзя восстановить вход.

Хеш — это отпечаток данных. Сами данные он не хранит, но удостоверяет их однозначно: имея файл и его хеш, вы за долю секунды проверите, что файл не подменили.

Цепь: почему правка одной записи ломает всё

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

Представьте амбарную книгу, где вверху каждой страницы записан отпечаток предыдущей. Подчистили сумму на странице 40 — её отпечаток изменился — и он больше не совпадает с тем, что написан на странице 41. Чтобы скрыть подлог, придётся переписать 41-ю. Но тогда «поедет» 42-я. И так до последней страницы.

Поэтому отдельную запись в блокчейне отредактировать не получится. Можно только переписать всё, что идёт после неё, — и добиться, чтобы с новой версией согласились те, кто держит копии цепи. В исследовании, выпущенном исследовательской службой Европарламента в 2019 году, само слово «неизменяемость» названо вводящим в заблуждение: при сговоре участников данные изменить можно — это крайне обременительно и дорого, но не невозможно. Разница принципиальная: неизменяемость — не закон физики, а очень дорогой замок.

«Удалить у себя» — это ничего не значит

Вторая половина ответа спрятана в слове «распределённое». Цепочка блоков лежит не на одном сервере, а на множестве независимых машин по всему миру, и у многих из них — копия цепи целиком.

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

Французский регулятор CNIL зафиксировал это ещё в 2018 году: удовлетворить запрос на стирание, когда данные записаны в блокчейн, технически невозможно. Европейский совет по защите данных (EDPB) в руководстве 02/2025 — финальная версия принята 7 июля 2026 года — идёт дальше: как правило, хранить персональные данные в блокчейне не рекомендуется, и уж точно их не следует помещать в содержимое транзакций. И отдельно, чтобы не оставалось лазейки: технической невозможностью нельзя оправдывать несоблюдение GDPR.

Обходные пути описывают оба регулятора, и контур у них общий: в цепь кладут не сами данные, а доказательство их существования — указатель, криптографическое обязательство (commitment) или хеш с ключом, — а всё, что нужно для проверки этого доказательства, держат снаружи. CNIL выстраивает порядок предпочтения: сначала commitment, затем хеш с ключом, затем шифротекст. EDPB строже: открытый текст, шифротекст и хеш он ставит в один ряд и писать персональные данные в цепь в любой из этих форм не рекомендует — им место вне её. Зашифрованные персональные данные остаются персональными данными; и даже безупречно реализованное современное шифрование будет побеждено временем, если цепочка хранится бессрочно.

Единственный случай, когда оба регулятора соглашаются, что данные перестали быть персональными, — perfectly hiding commitment: если удалить и исходное значение, и вспомогательный секрет, оставшееся в цепи обязательство бесполезно, по нему нельзя ни восстановить, ни опознать исходные данные. Про всё остальное CNIL говорит ровно то, что обычно опускают при цитировании: такие решения, строго говоря, не приводят к стиранию, поскольку данные по-прежнему существуют в блокчейне, — и добавляет, что ставит под вопрос их способность обеспечить полное соответствие GDPR.

Arweave: вечность не как побочный эффект

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

Экономика такая. Платёж делится надвое: одна часть уходит майнеру сразу, основная — в общий фонд, из которого хранителям платят годами вперёд. Расчёт строится на том, что хранение дешевеет: по данным жёлтой книги Arweave, за полвека стоимость гигабайто-часа падала в среднем чуть больше чем на 30 % в год, а документация проекта утверждает, что для бессрочной поддержки фонда достаточно и полупроцента в год. Комиссию при загрузке считают по текущим ценам как плату за двести лет хранения в двадцати копиях.

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

Нужна и вторая оговорка. Ни один из документов европейских регуляторов, которые я читала, не разбирает Arweave отдельно — ни его, ни IPFS, ни другие постоянные хранилища. Всё, что о них можно сказать по регуляторной линии, — это перенос рассуждений о блокчейне по аналогии. Аналогия выглядит крепкой: та же неизменяемость, та же распределённость, то же отсутствие единой кнопки «удалить». Но это по-прежнему аналогия, а не позиция регулятора.

И третья, которую нечестно было бы опустить: наш собственный проект пишет память именно в Arweave. Это не делает описанное выше неверным, но вы вправе знать, что автор текста тут не сторонний наблюдатель.

Итог простой. Спор о праве на забвение и вечной памяти — не спор о том, кто ленится нажать кнопку. Кнопки нет. Она не предусмотрена архитектурой, причём намеренно.

Где именно они сталкиваются

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

Точка первая: данные попали — и остались навсегда

Статья 17 GDPR устроена просто. Есть шесть закрытых оснований, при которых субъект вправе требовать стирания: данные больше не нужны для цели сбора; отозвано согласие и нет другого основания; заявлено возражение против обработки — и у контролёра нет перевешивающих законных оснований (против прямого маркетинга возражение действует безусловно); обработка была незаконной; стирание требует закон; данные собраны у ребёнка при предложении услуг информационного общества. Сработало любое из шести — контролёр обязан стереть «without undue delay». Статья 12(3) переводит это в календарь: один месяц, с возможностью продлить ещё на два.

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

CNIL — французский регулятор, разобравший эту тему в отчёте сентября 2018 года, — сформулировала прямо: технически невозможно удовлетворить запрос на стирание, когда данные записаны в блокчейн. Дальше CNIL описала обходной путь: если в цепи лежит не сам текст, а криптографическое обязательство, хеш с ключом или шифротекст, то, уничтожив вне цепи исходные данные и элементы верификации, можно «приблизиться к эффекту стирания». И тут же оговорилась — за исключением отдельных схем commitment, эти решения строго говоря стиранием не являются, поскольку данные в цепи продолжают существовать. Собственная оценка CNIL своей же рекомендации: признаём ценность этих решений, но сомневаемся в их способности обеспечить полное соответствие GDPR.

Почти восемь лет спустя EDPB — общеевропейский совет по защите данных — высказался жёстче. В финальной версии Guidelines 02/2025 (принята 7 июля 2026) есть фраза, которая закрывает главную линию защиты индустрии: техническая невозможность не может служить оправданием несоблюдения требований GDPR. Логика такая: статья 25 требует защиты данных «by design», то есть на этапе выбора средств обработки. Вы выбрали неизменяемое хранилище — это ваш выбор, а не обстоятельство непреодолимой силы.

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

Последнее удивляет инженеров сильнее всего. «Я же зашифровал» — не аргумент: EDPB напоминает, что зашифрованные персональные данные остаются персональными данными. И добавляет то, о чём редко думают при проектировании: даже безупречно реализованное современное шифрование будет побеждено временем, если цепь хранится бессрочно.

Точка вторая: кто здесь контролёр

GDPR построен на допущении, что у каждой единицы персональных данных есть хотя бы один контролёр — субъект знает, кому предъявлять требование. Исследование, подготовленное для Панели по будущему науки и технологий Европарламента (EPRS, PE 634.445, июль 2019; автор — Мишель Финк), называет это первым из двух корневых конфликтов: блокчейн заменяет единого актора множеством игроков, а отсутствие консенсуса о том, как определять контролёрство, мешает распределить ответственность.

CNIL попыталась распределить. Контролёром признаются участники с правом записи, решившие отправить данные на валидацию: физлицо — если обработка связана с профессиональной или коммерческой деятельностью, юрлицо — если оно регистрирует персональные данные в цепи. Майнеры контролёрами не признаны: они лишь валидируют транзакции, не определяя цели и средства. Человек, купивший биткоин для себя, — тоже не контролёр, тут работает исключение личной деятельности.

Но конструкция ломается на следующем шаге. Майнеры, по CNIL, могут оказаться процессорами. А процессор по статье 28 GDPR работает на основании договора с контролёром. Как заключить договор с анонимным майнером в публичной сети, который сам не знает, чью транзакцию включает в блок? CNIL признала практическую сложность и честно ответила, что ведёт по этому вопросу «углублённое размышление». Готовой конструкции в отчёте нет.

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

Стоит помнить: по делу Google Spain (C-131/12, Большая палата, 13 мая 2014) Суд ЕС признал контролёром оператора поисковика — того, кто просто индексирует чужие страницы и не имеет отношения к первичной публикации. Причём ответственность поисковика оказалась автономной: удалять ссылку он обязан даже в тех случаях, когда публикация на исходной странице сама по себе законна. Суд не искал, кому удобнее отвечать, — он искал, кто определяет цели и средства. Эта же логика, применённая к распределённому реестру, не даёт хорошего ответа. Она даёт много плохих.

Точка третья: цена ошибки

Нарушение права на стирание попадает в верхний из двух уровней штрафов. Статья 83(5)(b) охватывает права субъектов данных по статьям 12–22 — статья 17 входит сюда целиком. Потолок: 20 000 000 евро или 4% совокупного мирового годового оборота за предыдущий финансовый год.

Три детали, которые обычно искажают. Формула — «whichever is higher»: берётся бо́льшая из двух величин, а не меньшая. Процент считается от оборота, а не от прибыли, и от мирового, а не европейского. Процентный порог применяется к предприятию; к не-предприятиям — только абсолютная сумма.

Есть и смягчающая механика. Статья 83(3): при нескольких нарушениях в рамках связанных операций общая сумма не превышает размер, установленный для самого тяжкого нарушения, — штрафы не складываются. Статья 83(2) даёт закрытый перечень из одиннадцати обязательных факторов; среди них — характер и длительность нарушения, умысел или неосторожность, принятые меры по смягчению вреда, степень ответственности с учётом статей 25 и 32, прошлые нарушения, сотрудничество с надзорным органом, категории данных, полученная выгода. Потолок здесь — верхняя граница взвешивания, а не тариф.

Порядок сумм на практике даёт дело Google v CNIL (C-507/17): CNIL оштрафовала Google на 100 000 евро — за отказ выполнить предписание об удалении ссылок на всех доменных расширениях. Суд ЕС 24 сентября 2019 года постановил, что удалять по всему миру Google не обязан — достаточно версий, соответствующих всем государствам-членам, с мерами, которые эффективно предотвращают или как минимум серьёзно затрудняют доступ при поиске из ЕС. Но там же, в пункте 72, есть оговорка, которую часто теряют: право ЕС глобального удаления и не запрещает — национальный надзорный или судебный орган вправе его предписать по национальным стандартам защиты основных прав.

Точка четвёртая: как данные туда попадают

Здесь придётся быть аккуратной. Изученные документы регуляторов не приводят каталог инцидентов с конкретными сетями и датами — они описывают механизмы, а не хронику. Поэтому назову механизмы.

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

Второй: хеш как персональные данные. Инженерная интуиция говорит «хеш необратим, значит анонимен». WP29 в Opinion 05/2014 — так её цитирует исследование EPRS — ответила: простое применение хеш-функции не превращает персональные данные в анонимные автоматически; хеширование чаще даёт псевдонимные, а не анонимные данные — это полезная мера безопасности, но не метод анонимизации. Причина арифметическая: если множество возможных входов известно и конечно — скажем, все существующие адреса электронной почты, — перебор, по замечанию Эдварда Фелтена, которое приводит то же исследование, занимает у машины меньше времени, чем заваривание чашки кофе. Солёные хеши положения не спасают; ключевые дают более сильные гарантии. EDPB подтверждает: хеш будет считаться персональными данными, как и любые другие имеющиеся идентификаторы, — с одной оговоркой: если алгоритм не взломан, а секретный ключ или соль удалены и не утекли, связать хеш с исходными данными уже не должно получиться.

Третий: право на исправление, обернувшееся против субъекта. По CNIL исправление реализуется записью обновлённых данных новым блоком — но первая, ошибочная транзакция остаётся в цепи. Формально право исполнено. Фактически неверные данные о человеке хранятся вечно, рядом с верными.

Единственная архитектура, которую оба регулятора признают выходом, — криптографическое обязательство по perfectly hiding схеме. CNIL в сноске отмечает: после удаления witness и самого закоммиченного значения commitment становится анонимным настолько, что больше не может считаться персональными данными. EDPB в пункте 53 согласен: оставшийся в цепи commitment бесполезен — исходные данные ни восстановить, ни опознать. Это узкая дверь, но она есть.

Что говорят регуляторы

Спор о том, можно ли записывать людей в вечное хранилище, ведут не только инженеры. В Европе есть три документа, к которым в этом споре принято обращаться: отчёт французского регулятора CNIL, исследование, подготовленное для Европарламента его аналитической службой, и руководство Европейского совета по защите данных (EDPB). Статус у них разный — два надзорных органа и одна экспертная работа, — но читать их подряд полезно: видно, как почти за восемь лет позиция ужесточилась, а не смягчилась.

CNIL, 2018: «технически невозможно» — и что с этим делать

Начать стоит с французского регулятора. В сентябре 2018 года CNIL выпустил отчёт «Blockchain and the GDPR: Solutions for a responsible use of the blockchain in the context of personal data» — подробный разбор того, как GDPR ложится на неизменяемый реестр, сделанный надзорным органом.

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

Но у CNIL дальше идёт то, что цитируют реже. Регулятор описывает обходной путь: если в цепь положен не сам текст, а криптографическое обязательство, хеш с секретным ключом или шифротекст, то, уничтожив вне цепи исходные данные и элементы проверки, контролёр может «приблизиться к эффекту стирания». И тут же оговаривается: за исключением отдельных схем обязательства, эти решения строго говоря стиранием не являются, поскольку данные в блокчейне продолжают существовать. И итоговая оценка: CNIL признаёт ценность таких решений, но сомневается в их способности обеспечить полное соответствие GDPR.

То есть уже в 2018 году регулятор сказал не «можно», а «мы видим ваш обходной манёвр и не уверены, что он засчитывается».

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

Исследование для Европарламента, 2019: закон не трогать, нужны разъяснения

Через год вышло исследование «Blockchain and the General Data Protection Regulation» (PE 634.445, июль 2019, автор — Michèle Finck), подготовленное исследовательской службой Европарламента для панели по научно-технологическому прогнозированию. Это работа приглашённого эксперта, а не позиция парламента как института, — но именно она свела конфликт к двум допущениям, зашитым в GDPR.

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

Второе: данные можно изменить или стереть. Блокчейн намеренно сделан так, чтобы одностороннее изменение было максимально трудным, — в этом весь смысл технологии.

Вывод исследования при этом мягкий: менять GDPR не нужно. Регламент писался технологически нейтральным и построен на принципах, а не на описании конкретных систем. Нужны не поправки в закон, а разъяснения регулятора — специальное руководство EDPB, кодексы поведения, механизмы сертификации.

Ещё одно наблюдение оттуда стоит запомнить: статья 17 GDPR вообще не определяет, что значит «стирание». Ни в тексте статьи, ни в преамбулах определения нет. А в деле Google Spain удаление ссылок из результатов поиска было признано достаточным — при том, что сама страница газеты осталась на месте (правда, большего заявитель и не требовал). Это довод в пользу того, что уничтожение как физический акт не является обязательным содержанием права. Практика, впрочем, непоследовательна: в деле Nowak Суд ЕС говорил о стирании именно как об уничтожении.

EDPB, 2026: «технически невозможно» перестало быть аргументом

Разъяснения, о которых просило исследование 2019 года, появились почти шесть лет спустя. Guidelines 02/2025 по обработке персональных данных через блокчейн-технологии: версия 1.1 принята 8 апреля 2025 года, финальная версия 2.0 — 7 июля 2026 года, после публичных консультаций.

Тон изменился радикально. Ключевая фраза (п. 50):

«The EDPB emphasises that technical impossibility cannot be invoked to justify non-compliance with GDPR requirements»

Техническая невозможность не оправдывает несоблюдение. Логика простая и трудноопровержимая: защита данных by design (ст. 25(1)) применяется на этапе выбора средств обработки. Если вы выбрали архитектуру, в которой удаление невозможно, — невозможность создали вы сами, и она ваша проблема, а не смягчающее обстоятельство.

Общая установка ещё жёстче (п. 48): персональные данные в блокчейне хранить в целом не рекомендуется, и в содержимом транзакций их быть не должно. Пункт 104 ставит в один ряд открытый текст, шифротекст и хеш: регистрировать персональные данные в любой из этих форм в цепи не рекомендуется — их место off-chain. Рекомендация 11 доводит мысль до конца: если нет технического решения, гарантирующего удаление или обезличивание по истечении срока хранения, то персональные данные в цепь класть не следует вовсе.

Между CNIL 2018 и EDPB 2026 разница принципиальная. CNIL описывал, как жить с блокчейном. EDPB отвечает: чаще всего — никак; если свойство строгой целостности цепи вам не нужно, берите другой инструмент.

Считается ли хеш персональными данными

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

Позиция EDPB (п. 52) прямая: хеш будет считаться персональными данными, как и любые другие присутствующие идентификаторы. Оговорка там тоже есть: после удаления секретного ключа или соли хеш не должен связываться с исходными данными — но лишь до тех пор, пока алгоритм не взломан, а ключ и соль не скомпрометированы. Про шифрование сказано столь же недвусмысленно (п. 51): зашифрованные персональные данные остаются персональными данными, и шифрование не отменяет обязанностей по GDPR. Добавлена отдельная мысль про время: даже идеально реализованное современное шифрование будет преодолено, если блокчейн хранится бессрочно.

Это не новая позиция. Ещё в 2014 году Рабочая группа ст. 29 в Opinion 05/2014 отнесла хеширование к псевдонимизации, а не к анонимизации: полезная мера безопасности — но не метод обезличивания. Солёные хеши анонимности тоже не дают. Эти формулировки известны прежде всего по цитатам в исследовании EPRS, которое на мнение Рабочей группы и опирается; само исследование говорит то же самое: применение хеш-функции само по себе не превращает персональные данные в анонимные.

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

Единственная конструкция, про которую оба регулятора говорят одинаково и положительно, — криптографическое обязательство (commitment). CNIL в сноске к отчёту: при perfectly hiding схеме удаление witness и самого закоммиченного значения делает обязательство анонимным настолько, что оно больше не может считаться персональными данными. EDPB (п. 53) вторит: после удаления исходных данных и witness обязательство, остающееся в блокчейне, бесполезно — исходные данные ни восстановить, ни узнать.

Где у регуляторов нет ответа

Стоит назвать вещи своими именами.

Нет определения «стирания». Статья 17 его не даёт. Это признаёт и исследование, подготовленное для Европарламента. Вся конструкция «уничтожили ключ — считайте, стёрли» держится не на норме, а на её отсутствии.

Нет ни одного акта, который признал бы криптографическое стирание исполнением ст. 17. Есть инженерный стандарт (NIST SP 800-88r2 относит cryptographic erase к техникам уровня purge, а не destroy). Есть осторожное «приближение к эффекту» у CNIL. Есть решение Суда ЕС по делу SRB, в котором, судя по юридическим разборам, наметился контекстуальный поворот. Но обязывающего документа, где сказано «уничтожение ключа = удаление», нет. Более того, общеевропейский обзор правоприменения по ст. 17 — отчёт EDPB CEF 2025, опрошено 764 контролёра — не упоминает криптостирание ни разу. При этом надзорные органы там прямо критикуют подмену удаления обезличиванием: распространённая практика, когда контролёры применяют базовую псевдонимизацию или частичное маскирование и выдают это за удаление, требованиям GDPR не отвечает.

Нет ответа про перманентные хранилища. Ни один из этих документов не рассматривает Arweave, IPFS и подобные системы отдельно от блокчейнов. Любые выводы о них — экстраполяция, а не позиция регулятора.

Нет решения проблемы майнеров. CNIL признал, что договор обработчика с валидаторами публичной сети оформить практически трудно, и сообщил, что размышляет над этим; готового ответа в отчёте нет.

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

Решения, которые не работают

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

«Мы кладём в цепь только хеш»

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

Регуляторы говорят иначе. EDPB в Guidelines 02/2025 формулирует прямо: хеш тоже будет считаться персональными данными — как и любые другие идентификаторы, которые могут существовать рядом. Рабочая группа ст. 29 ещё в 2014 году (Opinion 05/2014 on Anonymisation Techniques, WP 216) назвала хеш-функции полезной мерой безопасности, но не методом обезличивания — привожу по исследованию, подготовленному для Европарламента, которое цитирует это мнение; сам первоисточник я не открывала. Само исследование (PE 634.445, Michèle Finck, июль 2019) добавляет ту же мысль от себя: хеширование чаще даёт псевдонимные, а не анонимные данные, и применение хеш-функции не превращает персональные данные в анонимные автоматически.

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

Практический вывод CNIL 2018 года: если уж что-то писать в цепь, то в порядке предпочтения — криптографическое обязательство (commitment), затем хеш с ключом, затем шифротекст. Руководство EDPB оставляет от этого списка только верхнюю часть: в цепи допустимы указатель, commitment или хеш с ключом, а шифротекст в п. 104 попадает в один ряд с открытым текстом — записывать персональные данные в таком виде не рекомендуется. Голый бесключевой хеш в публичном блокчейне EDPB считает в общем случае недостаточным.

«Мы шифруем — а потом уничтожим ключ»

Это техника с именем и стандартом: криптографическое стирание, cryptographic erase. NIST SP 800-88r2 (сентябрь 2025) определяет её как санитизацию ключей, делающую восстановление расшифрованных данных нецелесообразным. Инженерно всё честно.

Но обратите внимание на классификацию: NIST относит криптостирание к уровню purge, а не destroy. Это не физическое уничтожение, и стандарт этого не скрывает — шифротекст остаётся на носителе.

Юридически EDPB отвечает ещё прямее: зашифрованные персональные данные остаются персональными данными, и шифрование не отменяет необходимость соблюдать GDPR. И добавляет то, что для вечного хранилища смертельно: даже безупречно реализованное современное шифрование будет преодолено временем, если цепь хранится бессрочно.

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

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

Есть и обратный аргумент, честно его приведу. Решение Суда ЕС по делу C-413/23 P (EDPS против SRB, 4 сентября 2025) закрепило относительный подход: одни и те же псевдонимизированные данные могут быть персональными для того, у кого есть ключ, и не быть персональными для получателя, который реидентифицировать их не может. Это сильнейший на сегодня довод в пользу криптостирания. Но он про квалификацию данных у получателя без ключа, а не про то, что контролёр, уничтоживший ключ, исполнил ст. 17 в отношении оставшегося у него шифротекста. И оговорюсь: текст этого решения я по первоисточнику не сверяла.

«У нас приватная сеть, туда посторонние не попадают»

Приватный или консорциумный блокчейн действительно снимает часть проблемы: круг участников известен, договориться о процедурах проще, публичного доступа нет. EDPB прямо пишет, что публичные блокчейны стоит применять, только если публичный доступ необходим хотя бы для одной из целей обработки, — со ссылкой на ст. 25(2) GDPR о недоступности данных неопределённому кругу лиц по умолчанию.

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

Второе: приватная сеть не отменяет вопрос «кто контролёр». По логике CNIL контролёрами становятся участники с правом записи — юрлицо, регистрирующее персональные данные в цепи, контролёр без вариантов. Если несколько участников ведут обработку с общей целью и заранее не определили, кто отвечает, все рискуют оказаться совместными контролёрами по ст. 26 GDPR. В консорциуме это не смягчающее обстоятельство, а описание типичной ситуации.

«Форкнем цепочку и вычистим запись»

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

Технически это возможно — но именно поэтому и не работает как правовой механизм. Форк требует согласия сети. Значит, исполнение права конкретного человека зависит от доброй воли множества независимых участников, у которых нет перед ним никаких обязанностей. GDPR же даёт субъекту право обратиться к контролёру и получить результат «без неоправданной задержки» — по ст. 12(3) в течение месяца, максимум с продлением ещё на два. Механизм, требующий координации всей сети под каждый индивидуальный запрос, в эти сроки не укладывается и в принципе не масштабируется: он рассчитан на редкое чрезвычайное событие, а запросы на стирание — рутина.

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

«Данные обезличены» и «просто не будем удалять»

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

Отчёт EDPB о правоприменении по праву на стирание (опрошено 764 контролёра) фиксирует это как распространённую практику: контролёры полагаются на обезличивание как на замену окончательному удалению. И констатирует, что в ряде случаев применяется лишь базовая псевдонимизация или частичное маскирование — а такой процесс требованиям GDPR к удалению не отвечает. Там же отмечено, что многие по умолчанию исключают резервные копии из удаления, не обосновывая почему.

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

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

EDPB эту опору убрал. В Guidelines 02/2025 (финальная версия 2.0 принята 7 июля 2026) сказано прямо: техническая невозможность не может служить оправданием несоблюдения требований GDPR. Со ссылкой на ст. 25(1) — защита данных by design применяется уже на этапе, когда вы определяете средства обработки. То есть архитектурное решение, сделавшее исполнение закона невозможным, — это ваш выбор, а не форс-мажор.

Цена вопроса не абстрактная. Нарушение прав субъектов по ст. 12–22 попадает в верхний уровень ст. 83(5): до 20 000 000 евро, а если нарушитель — предприятие, то до 4% его мирового годового оборота за предыдущий финансовый год, whichever is higher, то есть берётся бо́льшая из двух величин.

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

Криптографическое стирание

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

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

Что говорит стандарт

У метода есть каноническое определение — NIST SP 800-88r2 «Guidelines for Media Sanitization» (сентябрь 2025). Дословно:

«cryptographic erase (CE): A purge sanitization technique in which key sanitization is applied to one or more keys providing confidentiality protections for the encrypted target data, making recovery of the decrypted target data infeasible.»

Обратите внимание на слово purge. В классификации NIST есть уровень Destroy — физическое уничтожение носителя, когда от диска остаётся стружка. Криптостирание туда не попадает. Это уровень «очистка», и NIST честно оговаривает: «The encryption itself acts to sanitize the data» — шифрование само выполняет роль стирания, но при соблюдении условий, перечисленных в документе. Шифротекст физически остаётся на носителе.

Отдельно стоит знать, что предыдущая редакция стандарта — SP 800-88r1 от 2014 года, на которую до сих пор ссылается девять из десяти статей и блогов о crypto-shredding, — отозвана 26 сентября 2025 года и полностью заменена на r2. Если вам показывают ссылку на r1 как на действующий стандарт, документ читали давно.

Условия, при которых это работает

NIST не говорит «уничтожьте ключ и спите спокойно». В §3.2 стандарта перечислены жёсткие предусловия, и каждое из них — потенциальная точка отказа.

Стойкость криптографии. Со ссылкой на ISO/IEC 27040: алгоритм и режим — не менее 128 бит стойкости, энтропия генератора случайных чисел — не меньше длины ключа. Режим ECB прямо запрещён.

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

Уничтожены все копии ключа. Не одна, а все — включая ключи, стоящие ниже в иерархии. Рекомендованная техника — зануление по ISO/IEC 19790.

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

Слабые места — честно

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

Шифр может не устоять. Это не паранойя, а прямая оговорка NIST: если в будущем будут найдены криптографические слабости алгоритма или вычислительные возможности (например, квантовые вычисления) сделают восстановление ключей реальным, данные снова станут доступны — и в таких случаях «CE may not be an acceptable sanitization technique».

Отсюда следует неприятное: атака «harvest now, decrypt later». Копия шифротекста, снятая до уничтожения ключа, живёт вечно и ждёт своего часа. Против физического уничтожения носителя такая атака бессмысленна. Против криптостирания — вполне рабочая стратегия.

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

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

Переведём на человеческий. Ключ живёт в KMS. KMS реплицируется в три региона. Есть ночной бэкап KMS. Есть эскроу-копия у второго администратора на случай, если первый уволится. Есть снапшот виртуальной машины, снятый в момент, когда ключ был развёрнут в памяти. Вы нажали «уничтожить ключ» — а он ещё в пяти местах. Эффект стирания равен нулю, при этом отчёт о выполнении запроса пользователя уже отправлен.

Результат невозможно перепроверить. Это, пожалуй, самая недооценённая проблема. Отозванная редакция r1 описывала её без экивоков: после криптостирания на носителе лежит шифротекст, содержимое которого неизвестно, и сравнивать его не с чем; а если организация не может проверить, что CE сработал, следует применять другой, проверяемый метод.

Актуальная r2 требует документировать процедуру по десяти обязательным пунктам, но тут же добавляет отрезвляющее: «CE's effectiveness as a purge sanitization technique does not depend on documentation». Эффективность не зависит от бумаг. Бумаги — это про прослеживаемость, не про факт.

И отдельно про внешний менеджер ключей: носитель попросту не видит, что происходит с ключом внутри KMS. Он отправил команду. Что было дальше — вопрос доверия к чужой системе.

Необратимость как риск. Уничтожение ключа нельзя откатить. Ошибка оператора, сбой скрипта, злонамеренное действие — и данные потеряны безвозвратно, без всякой возможности восстановления. А если архитектура предполагает отдельный ключ на каждого пользователя, при миллионе пользователей вы управляете миллионом ключей, каждый из которых надо где-то надёжно хранить и вовремя уничтожать.

Почему это признают стиранием — и признают ли

Здесь надо разделить две вещи: инженерное признание и юридическое.

С инженерной стороны всё в порядке. Криптостирание описано в NIST SP 800-88r2, опирается на ISO/IEC 27040, ISO/IEC 19790 и ISO/IEC 24759, смежные техники вынесены в IEEE 2883-2022. Это признанный метод санитизации с ясными условиями применения.

С юридической — гораздо мутнее, и об этом стоит говорить прямо. Начать с того, что сам термин «erasure» в статье 17 GDPR не определён — ни в тексте статьи, ни в преамбулах Регламента. Отсюда и разнобой в практике: Рабочая группа ст. 29 в мнении об облачных вычислениях допускала уничтожение оборудования; австрийский надзорный орган решением от 5 декабря 2018 года признал обезличивание способом исполнить право на стирание; британский регулятор давно применяет концепцию «putting beyond use» — данные не удалены физически, но выведены из обращения. Общего для всех государств-членов понимания так и не сложилось.

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

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

Разрыв между «технически надёжно» и «юридически засчитано» здесь настоящий, и закрывать его пока нечем.

Как это сделано у нас

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

Базовое правило: в вечное хранилище не попадает открытый текст

Диалог пользователя с ассистентом живёт в трёх слоях. Оперативный — контекст текущей сессии. Семантический — эмбеддинги в базе с векторным поиском. Вечный — Arweave.

Ключевая развилка проходит на границе третьего слоя. Всё, что уходит в постоянное хранилище, шифруется до отправки: AES-256-GCM, шифрование на стороне клиента, в сеть уходит только шифротекст. Ключ хранится в двух местах: у пользователя и в управляемом хранилище ключей (KMS). В самой цепи не лежит ни имени, ни текста, ни ничего, что читается без ключа.

Почему так, а не «просто не класть персональные данные в блокчейн»? Потому что тогда не остаётся продукта. Смысл вечной памяти в том, что архив переживает и сервис, и компанию, и меня. Хранить его только на своих серверах — значит сделать вечность зависимой от того, платим ли мы за хостинг в 2040 году.

Удаление = уничтожение ключа

Запрос на удаление у нас не пытается стереть данные из Arweave. Это физически невозможно, и делать вид, что возможно, — обман.

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

Техника называется криптографическое стирание. У неё есть стандарт — NIST SP 800-88 (актуальная редакция r2, сентябрь 2025; предыдущая r1 официально отозвана 26 сентября 2025, и на неё до сих пор ссылаются девять из десяти статей и блогов о криптостирании). Определение оттуда: санитизация ключей, защищающих зашифрованные целевые данные, делающая восстановление расшифрованных данных неосуществимым.

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

Что было альтернативой

Три варианта, которые мы рассматривали и отвергли.

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

Хранить хеш вместо шифротекста. Кажется чище, но не решает проблему. EDPB формулирует прямо: хеш тоже будет считаться персональными данными — как и любые другие идентификаторы рядом с ним. Оговорка у него есть: после уничтожения секретного ключа или соли связать хеш с исходными данными уже не должно получаться — при условии, что алгоритм не взломан, а ключ и соль не скомпрометированы, не утекли и выбраны корректно. Условия сильные. Рабочая группа по защите данных ещё в 2014 году называла хеширование полезной мерой безопасности, но не методом обезличивания — так её позицию передаёт исследование Европарламента. Причина арифметическая: перебор по известному множеству входов (все адреса электронной почты мира — порядка 5 миллиардов) занимает у машины меньше времени, чем заваривание чашки кофе. Формулировка принадлежит Эдварду Фелтену.

Криптографическое обязательство (commitment). Вот это — единственная схема, которую регуляторы прямо называют дающей выход из статуса персональных данных. CNIL в сноске своего доклада и EDPB в пункте 53 говорят одно и то же: при perfectly hiding схеме удаление witness и исходного значения оставляет в цепи бесполезный след, по которому исходные данные ни восстановить, ни узнать. Технически это лучший вариант, и в порядке предпочтения CNIL он стоит выше и хеша с ключом, и шифротекста.

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

Где остаются компромиссы

Их четыре, и ни один я не считаю закрытым.

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

Копии ключей — слепая зона. Стандарт требует уничтожить все копии целевого ключа и всех ключей ниже по иерархии, включая развёрнутые копии в оперативной памяти и регистрах. И отдельно предупреждает: там, где ключи резервировались или сдавались в эскроу, полагаться на криптостирание не следует — если только организация не знает с высокой достоверностью, как и где эти ключи хранились и как ими управляли. Для своего контура мы это гарантировать можем. За пользователя, который сохранил ключ себе, — нет.

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

Юридический статус не подтверждён. Это самое честное, что я могу сказать. Зашифрованные персональные данные остаются персональными данными — прямая формулировка EDPB. Обзор правоприменения по праву на стирание, опубликованный в феврале 2026 (764 опрошенных контролёра), не упоминает криптостирание ни разу — ни как одобренную практику, ни как запрещённую. Зато надзорные органы там же критикуют подмену удаления обезличиванием. И отдельно EDPB настаивает: техническая невозможность не может служить оправданием несоблюдения требований.

То есть наша архитектура не защищена ничьим разъяснением. Она защищена только тем, что делает максимум технически возможного и не врёт о том, чего не делает.

Что из этого следует практически

Мы проектируем так, чтобы не оказаться в положении «данные есть, а сделать с ними нечего». Пользователю говорится ровно то, что происходит: удаление уничтожает ключ, шифротекст остаётся, прочитать его нельзя, гарантии на горизонте десятилетий никто дать не может — ни мы, ни NIST, ни EDPB.

Инженерное решение здесь ровно одно и оно скучное: закладывать возможность обезличивания на этапе проектирования, а не искать её после первого запроса на удаление. Именно это EDPB и требует. Всё остальное — про то, где проходит граница между «сделали всё, что можно» и «пообещали больше, чем умеем». Первое — инженерия. Второе — маркетинг, и его в этом тексте не будет.

Одно право, разные страны

Право на удаление данных существует не в одном экземпляре. В разных юрисдикциях это разные права — с разными основаниями, разными исключениями и разной ценой ошибки. Сервис, у которого пользователи из Берлина, Лос-Анджелеса, Шэньчжэня и Сан-Паулу, сталкивается не с одним требованием, а с четырьмя, и они не совпадают.

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

Что известно точно: Европейский союз

В GDPR это Article 17 — «Right to erasure ('right to be forgotten')». Обратите внимание на кавычки внутри самого названия: «право на забвение» — неофициальный синоним. Юридический термин — право на стирание.

Оснований ровно шесть, перечень закрытый: данные больше не нужны для цели сбора; отозвано согласие и нет другого основания; заявлено возражение по ст. 21(1) — и у контролёра нет перевешивающих законных оснований (возражение против прямого маркетинга по ст. 21(2) действует безусловно); обработка была незаконной; стирание требует закон; данные собраны у ребёнка при оказании онлайн-сервиса.

Срок отвечать задан не в самой ст. 17, а в ст. 12(3): «without undue delay and in any event within one month of receipt of the request», с возможным продлением ещё на два месяца при сложности запроса. То есть месяц, максимум три.

Исключений тоже пять, и формула у них хирургическая: «shall not apply to the extent that processing is necessary». Не «запрос отклоняется», а «в той мере, в какой». Свобода выражения и информации. Исполнение юридической обязанности и публичные полномочия. Общественное здравоохранение. Архивирование в публичном интересе, научные и исторические исследования, статистика — но только если стирание сделает достижение целей невозможным или серьёзно затруднит. И защита правовых требований.

Штраф за нарушение прав субъекта данных идёт по верхнему уровню ст. 83(5): до 20 000 000 евро или — если нарушитель предприятие — до 4 % мирового годового оборота за предыдущий финансовый год, whichever is higher, то есть берётся бо́льшая величина. Не от прибыли, от оборота.

Границы права: что показал Люксембург

Два решения Суда ЕС очертили контур этого права точнее, чем текст регламента. Первое вынесено ещё по Директиве 95/46 — предшественнице GDPR, — но именно оно задало рамку, в которой позже писалась ст. 17.

Google Spain (C-131/12, 13 мая 2014). Испанец Марио Костеха Гонсалес обнаружил, что поиск по его имени выдаёт ссылки на две страницы газеты La Vanguardia от января и марта 1998 года — объявление о продаже его недвижимости с торгов за долги по социальному страхованию. Взыскание было полностью урегулировано много лет назад. Испанский регулятор отклонил жалобу на газету (публикация была законной, по распоряжению министерства) и удовлетворил жалобу на Google.

Суд постановил вещь, которая до сих пор многих удивляет: удалить ссылку нужно «even, as the case may be, when its publication in itself on those pages is lawful». Газета остаётся, ссылка исчезает. Ответственность поисковика автономна от ответственности издателя. И доказывать причинённый вред заявителю не требуется. В п. 93 Суд сформулировал доктрину устаревания: даже изначально законная обработка точных данных «in the course of time» может стать «incompatible with the directive» — несовместимой с тогдашней Директивой, — когда данные становятся «inadequate, irrelevant or no longer relevant, or excessive».

Из этого же решения — ограничитель, названный прямо: права субъекта перевешивают «as a rule», но баланс зависит от характера информации, её чувствительности и от «the role played by the data subject in public life». Публичная фигура защищена слабее.

Google v CNIL (C-507/17, 24 сентября 2019). Французский регулятор потребовал удалять ссылки на всех доменах поисковика по всему миру и оштрафовал Google на 100 000 евро. Суд решил: обязанности удалять глобально нет, но удалять надо на версиях, соответствующих всем государствам-членам ЕС, плюс применять меры, которые «effectively prevent or, at the very least, seriously discourage» доступ из ЕС.

И вот деталь, которую в пересказах регулярно теряют. Пункт 72: право ЕС глобального удаления не требует, но «it also does not prohibit such a practice» — национальный надзорный или судебный орган вправе его предписать по национальным стандартам. Фраза «Суд ЕС запретил глобальное удаление» неверна.

Сравнение юрисдикций

Здесь я обязана быть точной в том, что именно проверено. По Калифорнии, Китаю и Бразилии у меня сверены сами нормы: номер статьи, название, конструкция права, перечень исключений. Сроки ответа, территориальный охват и санкции — нет, и в таблице эти клетки остаются пустыми.

Две строчки из этих законов стоят того, чтобы вынести их отдельно, — потому что они прямо про наш сюжет. Второй абзац ст. 47 PIPL: если срок хранения по закону не истёк или удаление технически трудно осуществимо, обработчик прекращает всякую обработку, кроме хранения и мер безопасности. А в бразильском LGPD техническая ограниченность встроена в саму обязанность: ст. 16 требует удалять данные по окончании обработки «no âmbito e nos limites técnicos das atividades» — в рамках и технических пределах деятельности. Прямого аналога ни у той, ни у другой оговорки в ст. 17 GDPR нет. Европейский текст просто не предусматривает ответа «мы не можем».

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

Что делать сервису, работающему везде сразу

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

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

Не полагаться на «технически невозможно». EDPB в Guidelines 02/2025 (финальная версия 2.0 от 7 июля 2026) формулирует это без обиняков: «technical impossibility cannot be invoked to justify non-compliance with GDPR requirements». Со ссылкой на ст. 25(1) — защита данных by design применяется на этапе, когда вы выбираете средства обработки, а не после.

Считать зашифрованное персональными данными. Ещё одна прямая цитата EDPB: «encrypted personal data is still personal data and encryption does not remove the need for GDPR compliance». И там же — предупреждение, которое стоит повесить над архитектурной доской: даже безупречно реализованное современное шифрование «will be overtaken by time if the blockchain is retained indefinitely». Хеш EDPB тоже относит к персональным данным — «the hash will also be considered personal data», — с оговоркой: связь с исходными данными рвётся, только если секретный ключ или соль удалены, алгоритм не взломан, а ключ и соль не утекли. В исследовании Европарламента 2019 года, которое цитирует Opinion 05/2014 Рабочей группы ст. 29, хеширование названо «a useful security measure but not a method of anonymisation»: данные получаются псевдонимные, не анонимные.

Различать «недоступно» и «удалено». CNIL описала это ещё в 2018-м. Уничтожив ключ и внецепочечные данные, можно «move closer to the effects of data erasure» — приблизиться к эффекту удаления. Но тут же: «Excluding the specific case of some commitment schemes, these solutions do not, strictly speaking, result in an erasure of the data, insofar as the data would still exist in the blockchain». Исключение важно и его часто теряют: при perfectly hiding commitment, когда уничтожены и witness, и само закоммиченное значение, CNIL признаёт запись переставшей быть персональными данными. Во всех остальных случаях приблизиться — не значит исполнить, и сама CNIL «questions their ability to ensure a full compliance with the GDPR».

Единый режим вместо матрицы режимов. Соблазн понятен: у европейцев удалять по-настоящему, у остальных — помягче. На практике это означает поддерживать несколько путей удаления, каждый со своими багами, и постоянно определять, чей пользователь перед вами, — по стране регистрации? по IP? по гражданству? Дешевле и надёжнее один строгий путь для всех. Заодно снимается вопрос из C-507/17: если вы удаляете везде, спор о территориальном охвате для вас не существует.

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

Что делать, если вы это строите

Главное решение принимается один раз — на бумаге, до первой строки кода. Статья 25(1) GDPR требует защиты данных «by design» уже на этапе определения средств обработки, и EDPB в руководстве 02/2025 (версия 2.0, 7 июля 2026) закрывает единственную лазейку прямо: «technical impossibility cannot be invoked to justify non-compliance with GDPR requirements» (п. 50). Сказать регулятору «мы не можем удалить, у нас блокчейн» — не аргумент, а признание, что архитектура спроектирована неправильно.

Что никогда не кладут в неизменяемое хранилище

Позиция EDPB (п. 48): «in general, it is not advisable to store personal data on the blockchain, and it should not be stored in the content of transactions». Пункт 104 уточняет и ставит в один ряд три формата: открытый текст, зашифрованные и хешированные данные — все три не рекомендуется писать в цепь, все три следует держать off-chain.

Это тот пункт, где инженерная интуиция чаще всего ошибается. Шифрование не выводит данные из-под регулирования: «encrypted personal data is still personal data» (п. 51). Хеш EDPB тоже относит к персональным данным (п. 52) — с оговоркой, что после удаления секретного ключа или соли связь с исходными данными теряется, пока алгоритм не взломан, а ключ и соль не утекли. Мысль не новая: ещё в 2014 году Рабочая группа ст. 29 в Opinion 05/2014 — по цитированию в исследовании EPRS — назвала хеш-функции «a useful security measure but not a method of anonymisation»; солёные хеши анонимности не дают, хеш с секретным ключом даёт более сильные гарантии, но анонимными данные не делает.

Публичную цепь EDPB (п. 49) допускает только если публичный доступ необходим хотя бы для одной из целей обработки — со ссылкой на ст. 25(2) о недоступности данных неопределённому кругу лиц по умолчанию.

Что класть можно

Целевая архитектура из п. 54: в цепи — только форма, служащая доказательством существования (указатель, криптографическое обязательство, хеш с ключом); данные для проверки этого доказательства — вне цепи, с высоким уровнем конфиденциальности. CNIL ещё в 2018 году дала порядок предпочтения: commitment → хеш с ключом → шифротекст.

Единственная точка, где оба регулятора говорят, что данные перестают быть персональными, — perfectly hiding commitment. После удаления witness и самого закоммиченного значения обязательство в цепи, по формулировке EDPB (п. 53), «neither possible to recover nor to recognise the original personal data». Всё остальное — приближение к эффекту удаления, а не удаление.

Ключи

Криптостирание — признанная инженерная техника (NIST SP 800-88r2), но классифицирована она как purge, не как destroy. Стандарт задаёт условия, которые легко провалить:

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

И отдельная неприятность, подробно описанная ещё в отозванной первой редакции стандарта (r1, §4.7.2): результат криптостирания нечем проверить — после него содержимое носителя неизвестно, сравнивать не с чем.

Отсюда практика: ключ на субъекта, реестр ключей с идентификаторами, отдельная процедура зануления с подтверждением, и ни одной копии ключа в хранилище, которое вы не контролируете. Рекомендация 11 EDPB замыкает логику: если механизма, гарантирующего удаление или обезличивание по истечении срока хранения, нет — «then no personal data should be stored on the chain».

Политика конфиденциальности

Три вещи, которые в ней должны быть названы прямо.

Первое — контролёр. CNIL советует определить его заранее: создать юрлицо или назначить участника. Иначе все участники рискуют оказаться совместными контролёрами по ст. 26.

Второе — честное описание того, что попадает в неизменяемое хранилище и почему это необратимо. Не «мы удалим ваши данные по запросу», а что именно удаляется, что остаётся и в каком виде.

Третье — основание. Рекомендация 9 EDPB: согласие не должно использоваться как основание, если архитектура не даёт способа удалить данные.

Ответ на запрос об удалении

Срок задан не ст. 17, а ст. 12(3): один месяц с получения, с продлением ещё на два при сложности или количестве запросов.

Порядок: проверить основание (перечень в ст. 17(1) закрытый, ровно шесть); удалить off-chain-часть по-настоящему, включая бэкапы — в обзоре правоприменения EDPB 2025 года надзорные органы отдельно отметили, что многие контролёры исключают бэкапы из удаления по умолчанию, без обоснования; занулить ключ или witness; проверить исключения ст. 17(3) — формула «to the extent that» означает, что исключение действует лишь в той мере, в какой обработка необходима, и не блокирует запрос целиком. Если данные обнародованы, ст. 17(2) требует разумными мерами уведомить других контролёров об удалении ссылок, копий и репликаций.

И написать заявителю правду о том, что осталось. Тот же обзор EDPB прямо критикует подмену удаления обезличиванием: «in some cases, they only apply basic pseudonymisation or partial masking».

Журналы

Стандарт требует документировать каждое криптостирание: в §3.2.5 перечислено десять пунктов — и там же честно оговорено, что эффективность самой техники от документации не зависит. От неё зависит ваша защита. Поверх перечня NIST держите рабочий минимум под запрос об удалении: дату получения и ответа, основание, что и где удалено, идентификатор ключа и факт зануления, кто санкционировал, результаты DPIA. Ст. 83(2) прямо относит к учитываемым факторам меры по снижению вреда и сотрудничество с надзорным органом — а нарушение прав по ст. 12–22 попадает в верхний уровень санкций: до 20 млн евро, а для предприятия — до 4% мирового годового оборота за предыдущий финансовый год, и берётся бо́льшая из двух величин.

Право быть забытым и право быть сохранённым

Мы разбирали два права по отдельности — как будто это две стороны спора, где одна должна победить. Но у них общий корень, и это стоит проговорить прямо.

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

Один человек в разные годы

История Марио Костехи Гонсалеса — про человека, чью недвижимость продавали с торгов в счёт долгов по социальному страхованию. Объявления вышли в La Vanguardia 19 января и 9 марта 1998 года. Взыскание, как он потом указывал в жалобе, урегулировали много лет назад. Но поиск по имени в Google продолжал показывать эти страницы, и Суд ЕС в решении от 13 мая 2014 года отметил: с момента публикации прошло шестнадцать лет.

Шестнадцать лет — это ключевая цифра, а не декорация. Суд сформулировал мысль, которая держит всю конструкцию: даже изначально законная обработка достоверных данных может со временем стать несовместимой с директивой — а действовала тогда Директива 95/46, GDPR ещё не написали, — если данные больше не нужны: становятся неадекватными, нерелевантными или избыточными «в свете истёкшего времени».

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

Изменился человек. Точнее — изменилось расстояние между человеком и его прошлым.

У того, кто просит убрать одну ссылку из выдачи, почти всегда есть и вторая половина запроса — чтобы что-то осталось. Фотографии. Письма. То, что говорил детям. Просьба удалить одну страницу — не просьба стереть себя целиком. Это просьба, чтобы одна страница перестала быть первым, что о тебе узнают.

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

Почему система не должна решать за человека

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

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

Эта конструкция — презумпция в пользу человека, а не в пользу системы — важнее, чем любая техническая деталь. Она означает: по умолчанию решает он.

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

Но тут начинается неудобное.

Выбор нельзя дать наполовину

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

EDPB в руководстве по блокчейну (версия 2.0, принята 7 июля 2026 года) формулирует жёстко: техническая невозможность не может служить оправданием несоблюдения требований GDPR. И дальше — прямая рекомендация: в общем случае не рекомендуется хранить персональные данные в блокчейне, а если техническое решение, гарантирующее удаление или обезличивание по истечении срока хранения, отсутствует — тогда персональные данные не должны храниться в цепи вовсе.

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

Что из этого следует практически? Система, которая обещает вечность и не может ничего забыть, — не даёт выбора. Она даёт один вариант и называет его свободой. Система, которая всё удаляет по расписанию, тоже не даёт выбора — она просто выбрала за вас другое.

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

Что унести с собой

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

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

Ответа, работающего для всех, нет. Регуляторы искали его не в тексте закона: исследование, подготовленное для Европарламента ещё в 2019 году, заключило, что менять GDPR не нужно — регламент писался технологически нейтральным, — а нужны разъяснения. Разъяснения пришли: EDPB выпустил руководство по блокчейну в апреле 2025-го, финальную версию — в июле 2026-го. И оказались они не компромиссом, а требованием: если архитектура не позволяет ни удалить данные, ни обезличить их, то персональным данным в ней не место.

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