Можно ли удалить свои данные из уже обученной нейросети

Второй по частоте вопрос после «как выключить обучение» звучит так: «Хорошо, а то, что уже попало в модель, можно оттуда убрать?» Люди нажимают «удалить аккаунт», видят, что профиль исчез, и думают, что вопрос закрыт. На самом деле здесь начинается юридический и технический тупик, о котором честнее говорить прямо.

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

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

Модель - это не база данных

Вся путаница растёт из одной ложной аналогии. Мы привыкли к базам данных, где у каждого факта есть адрес: вот таблица, вот строка, вот клиент, DELETE WHERE id = ... - и записи больше нет. Кажется, что и с нейросетью так же: раз она «запомнила» мой текст, значит где-то он лежит и его можно стереть.

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

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

Что вы реально можете удалить, а что нет

Полезно развести две вещи, которые в голове сливаются в одну.

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

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

Удаление истории при этом всё равно имеет смысл. Оно останавливает будущее обучение на этих данных и закрывает сценарий, где ваши прошлые диалоги снова уходят в следующий цикл дообучения. Это ровно та логика opt-out, которую я разбирал в тексте про то, как запретить ИИ учиться на ваших промптах: отказ ценен для будущего, а не для прошлого.

Что предлагают технически, и где пределы

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

1. Machine unlearning (машинное разобучение). Семейство методов, которые пытаются приблизительно убрать влияние конкретных данных без полного переобучения с нуля. Идея красивая, но на сегодня это приближение: методы работают в ограниченных постановках, дают вероятностные, а не абсолютные гарантии, дорого стоят по вычислениям и плохо масштабируются на модели фронтира. Для маленькой модели в лаборатории - да; для большой продакшен-модели гарантированного «вычитания» одного человека пока нет.
2. Полное переобучение без этих данных. Технически чистый способ: убрать пример из датасета и обучить модель заново. На бумаге работает, на практике почти нереален для больших моделей - обучение стоит миллионы, и его не запускают ради одного запроса на удаление. Плюс нужно ещё точно знать, где во всём корпусе следы этого человека, а это отдельная тяжёлая задача.
3. Ограждения на выводе (guardrails, фильтрация). Модель оставляют как есть, но на выходе ставят фильтр, который не даёт ей выдавать определённые данные. Это лечит симптом, а не причину: данные по-прежнему в весах, вы просто закрыли один из выходов. Фильтр можно обойти, и он ничего не «удаляет».
4. Дообучение на подавление. Модель дополнительно обучают так, чтобы она реже воспроизводила нежелательное поведение или конкретные строки. Это снижает вероятность, но не даёт удаления: подавленное поведение при определённых условиях всплывает обратно.

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

Право на удаление упирается в веса

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

В GDPR есть статья 17, «право на забвение». Но что именно значит «удалить», когда данные вплавлены в параметры, регуляторы всё ещё разбирают. Позиции расходятся. Часть надзорных органов допускает, что сами по себе веса модели могут не считаться хранением исходных персональных данных - и тогда требование об удалении бьёт не по весам, а по обычным базам и по выводу модели. Другая часть занимает жёсткую линию к провайдерам моделей: например, итальянский регулятор Garante в разное время и приостанавливал работу сервиса, и штрафовал за обработку персональных данных. Единой устоявшейся практики именно по языковым моделям на сегодня нет, и это стоит держать в голове как зону неопределённости, а не как решённый вопрос.

В российском контексте 152-ФЗ даёт субъекту право отозвать согласие и потребовать удаления, а оператор при этом обязан прекратить обработку. Но как это ложится на обученные веса внешней модели - в практике пока не проговорено. Оператор может удалить ваши данные из своих баз, остановить их отправку в модель, закрыть трансграничную передачу. А вот заставить зарубежного вендора «вычесть» вас из уже обученной сети - механизма, которым это делается быстро и проверяемо, сегодня просто нет. Поэтому право формально есть, а техническая возможность его исполнить в части весов отстаёт.

Настоящий рычаг - до обучения

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

На месте компании я бы смотрел на это так.

1. Не пускать лишнее внутрь. Самая надёжная защита от «как теперь это удалить» - чтобы данные вообще не попали в модель. Минимизируйте, что уходит в промпты и в индексы, обезличивайте, где можно, держите чувствительное вне внешних сервисов.
2. Выключить обучение как можно раньше. Перевести чувствительную работу на бизнес-тариф или API, где контент по договору не идёт в обучение, и сделать это до того, как туда ушли месяцы переписки. Логику я разбирал в тексте про opt-out обучения.
3. Разделять управляемое и неуправляемое. То, что лежит в ваших базах и в истории сервиса, - управляемо, чистите это по регламенту. То, что уже в весах чужой модели, - считайте практически несмываемым и стройте решения из этого допущения.
4. Оценивать риск вывода отдельно. Если беспокоит, что модель потом выдаст запомненное, это смежная тема про запоминание и утечки; я разбирал её в тексте про то, может ли ИИ выдать чужие персональные данные.

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

Честные оговорки

• Область быстро меняется. Unlearning активно исследуют, и через пару лет часть ограничений может отступить. Но полагаться сегодня стоит на то, что есть сейчас, а не на обещания.
• «Удалили данные» - уточняйте, что именно. Когда сервис говорит об удалении, спрашивайте прямо: удалён профиль и история или убрано влияние на модель. Это разные гарантии, и вторую почти никто не даёт.
• Guardrails - это не удаление. Фильтр на выводе прячет симптом. Данные остаются в весах, и это надо называть своими словами.
• Право не равно исполнимости. Формальное право на удаление существует, но техническая возможность исполнить его в части весов пока отстаёт. Это зона неопределённости, а не лазейка и не повод её игнорировать.
• Я не юрист. Всё про 152-ФЗ и GDPR здесь - инженерная рамка того, как я вижу риск. Конкретную квалификацию и формулировки требований проверяйте с юристом.

Если коротко

• Обученная модель - это не база данных: ваши данные растворены в параметрах, и операции «найти и удалить» для них нет.
• Удалить можно профиль, историю и обычные базы рядом с моделью. Убрать влияние ваших данных на уже обученные веса - почти нельзя.
• Технические подходы (unlearning, переобучение, guardrails, дообучение) либо приближённые и дорогие, либо маскируют симптом. Гарантированного удаления из большой модели индустрия пока не даёт.
• Право на удаление есть и в GDPR, и в 152-ФЗ, но его применение к весам модели не устоялось.
• Настоящий рычаг - до обучения: не пускать лишнее внутрь и выключать обучение заранее, а не пытаться стереть прошлое.

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