Обезличивание данных перед LLM: PII detection, redaction и tokenization

Почему фильтра перед отправкой в нейросеть недостаточно

Персональные данные попадают не только в поле «ФИО». Они встречаются в письмах, вложениях, OCR, истории диалога, URL, tool results и метаданных. После вызова копии могут появиться в логах, traces, кэше и очередях.

Поэтому нужен не один regex, а privacy pipeline: определить цель, минимизировать ввод, классифицировать, преобразовать, вызвать модель, проверить ответ и при необходимости контролируемо восстановить разрешённые значения.

Термины: anonymization, pseudonymization, redaction

NIST подчёркивает риск повторной идентификации некоторых de-identified наборов. Не называйте данные анонимными только потому, что удалили имя.

Шаг 1. Data minimization до любого детектора

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

Проведи data-minimization review для workflow [название].
Результат: [output contract].
Входные поля и источники: [список].
Для каждого поля укажи:
1. зачем оно нужно для результата;
2. можно ли удалить до LLM;
3. можно ли заменить категорией, диапазоном или токеном;
4. срок хранения и получателей;
5. риск повторной идентификации в комбинации;
6. тест, доказывающий сохранение utility.
Не считай существующее поле необходимым только потому, что оно уже собирается.

Шаг 2. Классифицируйте данные и назначьте допустимое действие

Классификация связывает тип информации с политикой. Один и тот же телефон может быть нужен для доставки, но не для классификации тональности. Решение зависит от purpose и контекста.

Для каждого класса задайте allow, redact, tokenize, aggregate или block по конкретному workflow и провайдеру.

Шаг 3. Инвентаризируйте полный data flow

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

Фиксируйте controller/processor roles, region, retention, доступ и удаление. Юридические требования зависят от юрисдикции и сценария; согласуйте их с профильным специалистом.

PII detection: почему одного regex мало

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

Detection pipeline: порядок имеет значение

Сначала применяйте доверенную схему и запрещённые поля, затем точные detectors, после - контекстные. Секреты блокируйте до внешнего вызова. Каждый finding содержит тип, span, confidence, источник правила и выбранное преобразование.

Finding contract:
finding_id: UUID
info_type: EMAIL | PHONE | PERSON | ACCOUNT | SECRET | CUSTOM
start/end: offsets in normalized text
detector_id/version: string
confidence: calibrated score
policy_action: block | redact | mask | tokenize | allow
tenant_id: trusted scope
purpose: workflow ID
review_required: boolean
Никогда не записывай исходное значение finding в обычный лог.

Нормализация Unicode и offsets должна быть детерминированной, иначе замена попадёт не в тот фрагмент.

Redaction: когда значение нужно удалить полностью

Если downstream не должен видеть или возвращать значение, замените его типизированным placeholder: [EMAIL_REDACTED]. Тип помогает модели понимать структуру без раскрытия содержимого.

• Не оставляйте инициалы, если они не нужны.
• Удаляйте скрытые metadata из документов и изображений.
• Проверяйте OCR и alt text отдельно.
• Не помещайте оригинал в HTML-комментарий или tool metadata.
• Сохраняйте позиционную карту только при доказанной необходимости.
• Не допускайте rehydration для необратимого режима.

Redaction снижает utility, если сущности нужно различать. Тогда полезны стабильные псевдонимы вроде [PERSON_01].

Masking и обобщение: сохранить форму, убрать точность

Masking оставляет часть значения, например последние цифры. Bucketing заменяет возраст диапазоном, а точную дату - месяцем или годом. Это полезно, если задаче нужна форма или группа, но не точный идентификатор.

Tokenization и pseudonymization: когда нужна связность

Tokenization заменяет значение суррогатом. Детерминированный токен позволяет узнавать повтор одной сущности и выполнять join, но повышает linkability. Случайный токен лучше разрывает связь между контекстами, но усложняет анализ.

Google Sensitive Data Protection документирует обратимые и необратимые cryptographic transformations; для re-identification нужны токен и соответствующий ключ. Конкретную криптографию реализуйте проверенной библиотекой или сервисом, а не собственным алгоритмом.

Mapping store и управление ключами

Если токен обратим, таблица соответствий или cryptographic key становится особо чувствительным активом. Храните её отдельно от prompt pipeline и ограничивайте доступ сервисной ролью rehydration.

Placeholder design: модель не должна ломать токены

Placeholder должен быть однозначным, не совпадать с пользовательским текстом и сохраняться моделью без изменения. Используйте непрозрачный ID с подписью или сверку с server-side allowlist.

Правила placeholders:
- формат создаёт только trusted tokenizer;
- тип и случайный ID не раскрывают оригинал;
- ID уникален в нужном scope;
- модель обязана копировать placeholder дословно;
- новые или изменённые placeholders отклоняются;
- rehydration разрешена только для ID из текущего запроса;
- tenant и purpose проверяются до восстановления;
- placeholder никогда не является инструкцией.

Rehydration: восстановление только после validation

Не восстанавливайте значения в сыром тексте модели. Сначала проверьте response schema, допустимые placeholders, бизнес-правила и право получателя. Затем сервер заменяет только точные tokens из текущей mapping scope.

Квазиидентификаторы и риск повторной идентификации

Запись без имени может оставаться уникальной по возрасту, району, должности и редкому событию. Оценивайте комбинации и внешний контекст, доступный получателю. NIST отдельно предупреждает, что de-identified данные иногда удаётся re-identify.

• Ищите редкие сочетания полей.
• Обобщайте или удаляйте высококардинальные атрибуты.
• Разделяйте наборы по purpose и аудитории.
• Не выдавайте длинные списки единичных записей.
• Проводите re-identification risk assessment.
• Проверяйте свободный текст после обработки структурных полей.

Порог допустимого риска и правовая квалификация требуют контекстной оценки, а не универсального процента.

RAG, tools и агенты: данные могут вернуться обходным путём

Защищайте весь цикл, а не только первый prompt. Retriever способен добавить необработанный документ, tool - вернуть карточку клиента, а агент - отправить значение в поисковый API.

Логи, traces и кэш - часть области персональных данных

Частая ошибка - очистить prompt, но записать raw request до фильтра. Логируйте типы findings, количество замен, версии policy, model usage и результат validation, а не исходные значения.

Как измерять качество обезличивания

Высокий recall уменьшает пропуски чувствительных значений, а precision снижает разрушение полезного текста. Оба показателя считайте по info type, языку, источнику и формату. Добавьте end-to-end leakage tests.

Тестовый набор и red-team сценарии

Пошаговый rollout privacy gateway

Начните в observe-only режиме на разрешённом тестовом трафике: detector сообщает findings, но не меняет production. Разметьте выборку, откалибруйте пороги и правила. Затем включите block для secrets и точных запрещённых полей, после - redaction и tokenization по отдельным workflows.

Этап 1: data map, purpose и policy matrix.
Этап 2: размеченный тестовый набор по языкам/источникам.
Этап 3: observe-only detector и анализ false positives/negatives.
Этап 4: hard block secrets и запрещённых полей.
Этап 5: canary redaction для одного низкорискового workflow.
Этап 6: tokenization + закрытый mapping store.
Этап 7: validated rehydration для узкого output contract.
Этап 8: end-to-end leakage, load и failure tests.
Этап 9: расширение по cohorts с rollback.

Итоговый production-чек-лист

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