- 1Удаление документа из интерфейса не подтверждает уничтожение его фрагментов, метаданных, журналов и иных копий.
- 2Основание и срок прекращения обработки определяют по конкретной ситуации. Универсального правила «удалить всё за 30 дней» нет.
- 3При автоматизированной обработке уничтожение подтверждают актом и выгрузкой из журнала событий. Технические проверки должны показывать, что фактически уничтожено.
Правовые выводы проверены и актуализированы 9 октября 2026 года. Примеры условные; рекомендации по организации работы отделены от обязательных требований.
Куда попадают данные из одного файла
Представим корпоративного ассистента, который отвечает по внутренним документам. Сотрудник загрузил PDF с обращением клиента. Система извлекла текст, разделила его на фрагменты, рассчитала числовые представления для поиска и сохранила связи с исходным документом. Позднее клиент потребовал прекратить обработку своих данных. Администратор удалил PDF и получил сообщение об успехе.
Такое сообщение описывает конкретную операцию. Оно ещё не отвечает на вопрос, остались ли извлечённый текст, фрагменты, записи поискового индекса, история запросов и ответы с цитатами. В зависимости от архитектуры дополнительные копии могут находиться в очереди обработки, временном каталоге, кэше, системе наблюдения за запросами или тестовой среде.
RAG — подход, при котором модель получает найденные в базе знаний материалы вместе с вопросом пользователя. Поэтому аудит удаления начинается с движения документа через систему: от загрузки до поиска, ответа и последующего хранения. Состав этого пути надо установить для конкретного продукта.
Когда фрагменты и векторы остаются персональными данными
По статье 3 закона № 152-ФЗ значение имеет связь информации с определённым или определяемым человеком. Замена фамилии идентификатором не устраняет такую связь, если система сохраняет таблицу соответствия или позволяет установить человека по другим сведениям.
Фрагмент договора может содержать имя, телефон, обстоятельства обращения или сочетание признаков, позволяющее определить клиента. Метаданные могут связывать фрагмент с карточкой человека, номером его дела или исходным файлом. Поэтому проверять нужно и содержимое, и доступные системе связи между объектами.
Само числовое представление текста — embedding — нельзя автоматически считать ни персональными данными, ни безопасно обезличенной информацией. Вывод зависит от того, какие сведения оно отражает, с чем связано и какие возможности определения человека существуют в конкретной системе. Обоснование этой оценки желательно сохранить вместе с описанием архитектуры.
Сначала определить основание, затем срок
Статья 5 закона № 152-ФЗ связывает объём и продолжительность обработки с её целями. Статья 21 устанавливает разные обязанности для неправомерной обработки, достижения цели, отзыва согласия и требования прекратить обработку. Эти ситуации нельзя объединять одной настройкой срока хранения.
Например, при выявлении неправомерной обработки закон предусматривает её прекращение в пределах трёх рабочих дней, а если обеспечить правомерность невозможно — уничтожение в пределах десяти рабочих дней. При достижении цели и отзыве согласия применяются другие условия и сроки. Требование прекратить обработку также имеет отдельный порядок и предусмотренные законом исключения.
Отзыв согласия не всегда означает уничтожение всех сведений: необходимо проверить, сохраняется ли самостоятельное законное основание по статье 6. Но основание хранить отдельный документ для исполнения обязанности само по себе не оправдывает его использование в ответах RAG. Для каждого оставленного массива нужны конкретная цель, состав данных и срок.
Составить карту удаления
Практический рабочий документ — карта объектов, которые возникают из загрузки. Для каждого места хранения полезно указать владельца процесса, идентификатор объекта, связь с исходным файлом и человеком, операцию удаления и способ проверки. Это организационная рекомендация; закон не устанавливает обязательную схему базы RAG.
Начать можно с цепочки: исходный файл → извлечённый текст → фрагменты → векторный индекс и метаданные → кэш поиска → запросы и ответы → журналы и резервные копии. Затем проверить, какие из этих объектов действительно создаёт продукт. Если один файл относится к нескольким людям, удаление по имени или одному идентификатору документа может оказаться неточным.
Устойчивая связь между идентификатором документа, его фрагментами, записями индекса и пространством конкретного заказчика помогает найти зависимые объекты. Отдельно стоит проверить дубликаты и повторную загрузку из внешнего источника. Удалённые сведения могут вернуться после очередной синхронизации, если источник продолжает передавать их.
Проверить журналы, кэш и восстановление из копии
После выполнения операции полезно повторить поиск по контрольным запросам, проверить записи в хранилищах и убедиться, что сведения не появляются в новой выдаче. Отсутствие ответа по одному запросу показывает лишь результат этого запроса. Оно не доказывает отсутствие всех копий.
Журналы требуют самостоятельного решения. В них могут оказаться полный запрос, найденный фрагмент и ответ модели. Если для расследования ошибок достаточно технических идентификаторов и кода события, сохранение полного текста нужно отдельно обосновать. Минимизация записываемых сведений уменьшает и объём будущего удаления.
Резервная копия также требует проверки. Неизменяемость хранилища не создаёт автоматического исключения из закона. Часть 6 статьи 21 предусматривает блокирование и последующее уничтожение при отсутствии возможности уничтожить данные в установленный срок, при соблюдении её условий. Это не универсальное разрешение хранить любую копию шесть месяцев.
Для конкретной резервной копии надо установить срок, режим доступа и порядок восстановления. Практически важно проверить сценарий, при котором старая копия возвращается в рабочую среду: сведения, подлежащие уничтожению, не должны снова начать использоваться. Факт сохранения копии и основание её временного сохранения нельзя скрывать за отметкой «всё удалено».
Чем подтвердить уничтожение
Приказ Роскомнадзора от 28 октября 2022 года № 179 действует с 1 марта 2023 года до 1 марта 2029 года. При автоматизированной обработке он предусматривает два документа: акт об уничтожении персональных данных и выгрузку из журнала регистрации событий информационной системы. Для смешанной обработки также нужны оба документа.
В акте отражают предусмотренные приказом сведения об операторе и исполнителе поручения, субъектах, категориях данных, лицах, выполнивших уничтожение, информационных системах, способе, причине и дате уничтожения. Для выгрузки установлены сведения о субъектах, категориях данных, системе, причине и дате. Если выгрузка не позволяет указать отдельные сведения из установленного перечня, их вносят в акт.
Акт и выгрузку хранят в течение трёх лет с момента уничтожения. Приказ не требует отдельного акта на каждую запись векторного индекса. При этом технические материалы должны позволять соотнести проведённую операцию с данными и системами, указанными в подтверждении. Нельзя оформлять уничтожение всего массива, если проверка охватывала только исходный файл.
Согласовать действия заказчика и поставщиков
В одном сервисе могут участвовать заказчик, разработчик RAG, провайдер модели, облачное хранилище и сервис журналирования. Роль каждого определяют по операциям: кто задаёт цели, какие данные получает и что делает с ними. Название «технический подрядчик» само по себе этот вопрос не решает.
Если действует поручение обработки, его нужно согласовать с требованиями статьи 6 закона № 152-ФЗ. В договоре и рабочем порядке полезно определить, как передаётся требование, какие производные объекты охватываются, кто собирает подтверждения, как учитываются привлечённые исполнители и что происходит с копиями после прекращения договора.
До запуска процесса стоит провести сквозную проверку на специально подготовленных тестовых данных: загрузить документ, проследить созданные объекты, выполнить удаление и проверить восстановление из копии. Результат такой проверки помогает увидеть разрыв между обещанием в политике, договором и фактической работой продукта.