Кнопка «Удалить аккаунт» ничего не удаляет из архитектуры данных П ользователь удалил аккаунт. Запись исчезла из основной базы, запрос закрыт. Но данные остались в резервной копии, журнале, аналитической витрине, поисковом индексе, тестовой среде и наборе для обучения модели.

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

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

В 2026 году EDPB сообщил о результатах проверки с участием 32 европейских надзорных органов. Среди повторяющихся проблем — слабые процедуры, неэффективная анонимизация, неясные сроки хранения и удаление данных из резервных копий.

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

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

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

Для аналитических моделей важно разделять пять объектов: исходную запись, обучающий набор, признаки, сохранённый прогноз и модель. Удаление источника не меняет остальные автоматически. I CO поясняет для ИИ: удалить запись из обучающего набора не всегда означает удалить модель. Но если модель содержит персональные данные или позволяет их вывести, может потребоваться переобучение или вывод из эксплуатации.

«Машинное разучивание» тоже нужно проверять, а не считать доказательством по названию.

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

Право на удаление не абсолютно, но «сохранить на всякий случай» — не основание. Любое исключение требует конкретной цели, срока, владельца и технического ограничения доступа.

Мой принцип: честное поэтапное удаление лучше обещания мгновенно уничтожить каждую копию — при условии, что компания действительно контролирует все стадии.

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