Как вы обрабатываете PII в данных для RAG (GDPR, 152-ФЗ)?

Краткий тезис

Обработка PII (Personally Identifiable Information) в RAG — это обязательный этап для соблюдения GDPR (Европа) и 152-ФЗ (Россия). Основные шаги: детекция PII с помощью NER-моделей (spaCy, DeBERTa-NER, Microsoft Presidio), маскировка или удаление найденных сущностей, шифрованное хранение mapping (если нужна обратимость), аудит всех операций и использование синтетических данных для fine-tuning. Без такой обработки система нарушает законодательство и несёт риски утечки персональных данных.

1. Термин: PII и регуляторные требования

PII (Personally Identifiable Information) — любая информация, которая может прямо или косвенно идентифицировать физическое лицо: имя, номер телефона, email, адрес, паспортные данные, IP-адрес, геолокация, биометрия и т.д.

GDPR (General Data Protection Regulation) — европейский регламент, требующий:

• Минимизации сбора данных (data minimization)
• Явного согласия на обработку
• Права на забвение (удаление данных)
• Обязательного уведомления об утечках в течение 72 часов
• Штрафы до 4% от годового оборота

152-ФЗ «О персональных данных» — российский закон, аналогичные требования:

• Обработка только с согласия субъекта
• Локализация данных на территории РФ
• Уведомление Роскомнадзора
• Категории ПД: общедоступные, специальные, биометрические

В RAG-системе PII может содержаться как в индексируемых документах, так и в запросах пользователей. Обработка должна быть на обоих этапах.

2. Почему PII критична в RAG-системах

RAG-система индексирует документы и отвечает на запросы, используя их содержимое. Если в документах есть PII, то:

• Утечка через ответы: LLM может выдать PII из контекста (например, «Позвоните Ивану Петрову по номеру +7...»)
• Нарушение регуляций: хранение PII без согласия или без шифрования
• Юридические риски: штрафы, судебные иски, репутационный ущерб
• Проблемы с fine-tuning: модель может запомнить PII и воспроизводить их в будущем

Поэтому обработка PII — не опция, а обязательное требование для production RAG.

3. Этап 1: Детекция PII

Первый шаг — найти все PII-сущности в документах перед индексацией. Используются:

3.1 NER-модели (Named Entity Recognition)

• spaCy (en_core_web_trf, ru_core_news_lg) — быстрая, предобученная на стандартных сущностях (PERSON, ORG, GPE, PHONE, EMAIL)
• DeBERTa-NER (например, dslim/bert-base-NER) — более точная, но медленнее
• Microsoft Presidio — специализированная библиотека для PII: анализатор (NER + регулярные выражения) и анонимайзер

3.2 Регулярные выражения

Для номеров паспортов, СНИЛС, ИНН, банковских карт — паттерны, например:

import re
passport_pattern = r'\b\d{2}\s?\d{2}\s?\d{6}\b'  # российский паспорт (серия+номер)
phone_pattern = r'\+7[\s\-]?\(?\d{3}\)?[\s\-]?\d{3}[\s\-]?\d{2}[\s\-]?\d{2}'

3.3 Комбинированный подход

Лучший результат даёт комбинация: NER + regex + проверка контекста]]. Presidio уже включает это.

Пример детекции с Presidio

from presidio_analyzer import AnalyzerEngine
analyzer = AnalyzerEngine()
results = analyzer.analyze(text="Меня зовут Иван Петров, мой email ivan@example.com", language='ru')
for r in results:
    print(f"Тип: {r.entity_type}, текст: {text[r.start:r.end]}, уверенность: {r.score}")
# Вывод: PERSON, Иван Петров, 0.85; EMAIL, ivan@example.com, 1.0

4. Этап 2: Маскировка vs удаление

После детекции нужно решить, что делать с PII. Два основных подхода:

Маскировка — более гибкий вариант: сохраняется структура текста, но PII заменяется на метку. Mapping (соответствие метки → реальное значение) хранится отдельно, зашифрованным.

Удаление — безопаснее, но может нарушить смысл предложения. Например, «Позвоните Ивану» после удаления станет «Позвоните».

Пример маскировки с Presidio

from presidio_anonymizer import AnonymizerEngine
anonymizer = AnonymizerEngine()
result = anonymizer.anonymize(text="Иван Петров, +7-123-456-78-90", analyzer_results=results)
print(result.text)  # <PERSON>, <PHONE_NUMBER>

Можно настроить кастомные операторы: замена на [PERSON], [PHONE] или на случайный синоним (например, «Иван Петров» → «Алексей Смирнов»).

5. Этап 3: Хранение mapping (шифрование и аудит)

Если используется маскировка, mapping (словарь метка → реальное значение) необходимо:

• Шифровать (AES-256) при хранении
• Ограничить доступ (только для авторизованных сотрудников с ролью «Data Steward»)
• Логировать каждый запрос на расшифровку (кто, когда, зачем)
• Установить TTL (time-to-live) — автоматическое удаление mapping через N дней

Пример структуры mapping в зашифрованной БД:

{
  "PERSON_1": "Иван Петров",
  "PHONE_1": "+7-123-456-78-90",
  "EMAIL_1": "ivan@example.com"
}

Шифрование на уровне приложения: перед записью в БД сериализовать JSON и зашифровать ключом из Vault (HashiCorp Vault, AWS KMS).

6. Этап 4: Аудит и логирование

Каждая операция с PII должна логироваться:

• Детекция: какие сущности найдены, в каком документе
• Маскировка/удаление: что и как заменено
• Расшифровка mapping: кто и когда запросил оригинал
• Запросы пользователей: если в запросе есть PII, его тоже нужно обработать (маскировать перед отправкой в LLM)

Логи хранятся в SIEM-системе (Splunk, ELK) с retention policy. Для GDPR требуется возможность предоставить субъекту отчёт о том, какие его данные обрабатываются.

Пример лога

2025-03-[[15. Какие embedding-модели вы использовали и почему|15]] [[10. Что такое Self-RAG и когда его использовать|10]]:[[23. Как вы подбираете гиперпараметры для LoRA|23]]:[[45. Как вы тестируете агентов (сложно из-за стохастичности)|45]] | user_id=u123 | action=detect | doc_id=d456 | entities=[PERSON, PHONE] | confidence=0.92
2025-03-[[15. Какие embedding-модели вы использовали и почему|15]] [[10. Что такое Self-RAG и когда его использовать|10]]:[[23. Как вы подбираете гиперпараметры для LoRA|23]]:[[46. Какие инструменты (toolsfunctions) дать агенту для автоматизации бизнес-задач (ваш кейс!)|46]] | user_id=u123 | action=mask | doc_id=d456 | mapping_id=m789 | status=success

7. Fine-tuning на синтетических данных

Для fine-tuning LLM или эмбеддеров нельзя использовать реальные PII — модель может их запомнить. Вместо этого генерируют синтетические данные:

• Библиотека Faker (Python) — создаёт реалистичные, но вымышленные имена, адреса, телефоны
• GPT-4 / локальная LLM — может сгенерировать диалоги с синтетическими PII по шаблону
• Замена реальных PII на синтетические в существующих датасетах (с сохранением структуры)

Пример генерации с Faker

from faker import Faker
fake = Faker('ru_RU')
name = fake.name()          # 'Екатерина Смирнова'
phone = fake.phone_number() # '+7 (999) 123-45-67'
email = fake.email()        # 'smirnova@example.com'

Синтетические данные не несут риска утечки и могут свободно использоваться для обучения.

8. Инструменты и библиотеки

9. Compliance и проверки (DPIA)

DPIA (Data Protection Impact Assessment) — обязательная оценка влияния на защиту данных для систем, обрабатывающих PII в больших масштабах. Включает:

• Описание потоков данных (откуда берутся документы, как обрабатываются)
• Оценка рисков (утечка, несанкционированный доступ)
• Меры защиты (шифрование, маскировка, контроль доступа)
• План реагирования на инциденты

Для 152-ФЗ дополнительно требуется:

• Уведомление Роскомнадзора об обработке ПД
• Локализация баз данных на территории РФ
• Согласие субъекта (если PII собирается напрямую)

Пет-проект для закрепления

Задача Разработать конвейер обработки PII для RAG-системы на синтетических данных.

Инструменты Python, Presidio, spaCy, Faker, SQLite (для mapping), cryptography (AES).

Шаги:

1. Сгенерировать 100 синтетических документов с помощью Faker (тексты с именами, телефонами, email, адресами).
2. Написать скрипт детекции PII с Presidio (анализатор на русском и английском).
3. Реализовать маскировку: замена на [PERSON], [PHONE] и т.д. Сохранить mapping в зашифрованном SQLite.
4. Реализовать удаление (опционально) для сравнения.
5. Добавить логирование в файл (формат JSON).
6. Протестировать: взять запрос пользователя, пропустить через детекцию, убедиться, что PII не попадает в контекст LLM (можно использовать заглушку).

Ожидаемый результат Рабочий скрипт, который принимает на вход папку с документами и возвращает очищенную версию + лог. Вывод: таблица с количеством найденных PII до/после обработки.

Связь с другими вопросами

Навигация

• Предыдущий: 517
• Следующий: 519
• Индекс: 00. Индекс разборов