---
title: "Как по-настоящему удалить пользователя из RAG-системы"
seoTitle: "GDPR-forget в RAG: удаление пользователя из векторной и графовой памяти"
description: "Запрос на удаление по GDPR значит, что данных больше нет — включая эмбеддинги, рёбра и производные артефакты. Разбираем, почему удаления строки мало и как выглядит настоящий forget."
date: "2026-06-20"
author: "INITE Brain Team"
category: "Приватность"
tags: ["GDPR", "приватность", "forget", "RAG", "PII"]
directAnswer: "Удалить пользователя из RAG-системы — это синхронное жёсткое удаление каждого факта, ребра, эмбеддинга и производного артефакта, привязанного к сущности, а не пометка «скрыто». Защитимый паттерн — каскад, который сносит данные и оставляет только HMAC-tombstone, чтобы можно было доказать удаление, не храня сами данные."
definitionSentence: "GDPR-forget (право на удаление) в RAG-системе — это операция, которая сносит все факты, эмбеддинги, рёбра графа и производный контент субъекта данных, оставляя только необратимую запись-доказательство удаления."
faqs:
  - question: "Разве удалить строку в базе недостаточно?"
    answer: "Нет. В RAG-системе данные пользователя живут ещё и в эмбеддингах, в рёбрах графа к другим сущностям, в кэшированных или суммаризованных артефактах, а иногда и в производных фактах. Удаление строки оставляет всё это, и пользователь всё ещё находится по похожести, хотя исходной строки нет. Удаление должно идти каскадом по всем представлениям."
  - question: "Что такое HMAC-tombstone и зачем он нужен?"
    answer: "Tombstone — это крошечная запись-доказательство, что удаление было: HMAC от идентификатора сущности плюс метка времени, без восстановимых персональных данных. Его держат, чтобы ответить аудитору «докажи, что стёр этого пользователя», не сохраняя сами данные. Ещё он не даёт повторному ingest тихо воскресить сущность."
  - question: "Forget должен быть синхронным или фоновой задачей?"
    answer: "Синхронным на пользовательском пути. Фоновая задача, которая «когда-нибудь доберётся», оставляет окно, где данные ещё запрашиваются, — а это ровно то, что регламент запрещает. Защитимая схема удаляет inline и возвращает ответ только после завершения каскада; фон годится для компакции, но не для удаления."
  - question: "Чем forget отличается от retract?"
    answer: "Retract исправляет запись: факт был неверным, ты помечаешь его отозванным, но оставляешь в аудит-следе. Forget уничтожает запись: у субъекта есть право быть удалённым, поэтому ничего восстановимого не остаётся. Retract сохраняет историю; forget её завершает. Перепутать их там, где нужно другое, — это баг комплаенса."
---

## Удаление строки — это не стирание

В обычной базе «удали пользователя» — это один оператор. В RAG-системе данные пользователя разбросаны по представлениям:

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

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

## Что сносит настоящий forget

Удаление должно идти каскадом по каждому представлению сущности:

1. **Факты** — каждое утверждение, где сущность субъект или объект.
2. **Рёбра** — каждая типизированная связь, входящая и исходящая.
3. **Эмбеддинги** — векторы, а не только текст.
4. **Производные артефакты** — всё, что собрано из перечисленного выше.

После каскада поиск по похожести на пользователя не возвращает ничего, а обход графа не находит узла. Вот планка.

## Храни доказательство, а не данные

Удаление всё равно надо *доказать* — не храня то, что удалил. Паттерн — **tombstone**: HMAC от id сущности плюс метка времени. В нём нет восстановимых персональных данных, но он позволяет ответить на аудит и блокирует повторный ingest, который иначе тихо пересоздал бы сущность под тем же id.

Инвариант после forget точный: **данных нет, доказательство есть.**

## Forget — это не retract

Их путают, и путаница — это баг комплаенса.

- **Retract** — факт был неверным. Помечаешь отозванным, оставляешь в аудит-следе, исключаешь из живых ответов. Историю сохраняешь намеренно.
- **Forget** — у человека есть право быть удалённым. Уничтожаешь каждое представление. История завершается.

Retract — для исправлений, forget — для стирания. Никогда не наоборот.

## Как это реализовано в Brain

В INITE Brain `POST /v1/entities/:id/forget` гоняет синхронный жёсткий каскад — факты, рёбра и эмбеддинги удаляются одной операцией — и пишет HMAC-tombstone. Eval-гейт memory-lifecycle проверяет инвариант и не пропускает значение ниже 1.0: после forget сущность недостижима ни одним путём, а tombstone — единственное, что остаётся.
