Что такое data exfiltration через LLM (утечка данных через ответы)?

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

Data exfiltration через LLM — это утечка конфиденциальных данных, которые модель непреднамеренно воспроизводит в ответе пользователю. Проблема возникает, когда модель обучена на приватной информации (PII, медицинские записи, коммерческие тайны) или имеет доступ к таким данным через контекст RAG. Защита требует комбинации методов: очистка обучающих данных, RLHF для обучения отказу, пост-процессинг с фильтрацией PII и дифференциальная приватность при обучении.

1. Термин: Data Exfiltration (утечка данных)

Data exfiltration — несанкционированное копирование, передача или извлечение конфиденциальной информации из системы. В контексте LLM это означает, что модель выдает данные, которые не должны быть раскрыты: персональные данные (PII), пароли, внутренние документы компании, медицинские записи и т.д.

Утечка может быть:

• Прямой — модель дословно воспроизводит фрагмент из обучающего набора или контекста.
• Косвенной — модель обобщает или комбинирует данные так, что из ответа можно восстановить приватную информацию (например, «средняя зарплата в отделе — 150 000 руб.» при наличии всего нескольких записей).

2. Механизм утечки через LLM

LLM — это model|генеративная модель, которая предсказывает следующее слово на основе контекста. Если в тренировочных данных или в промпте (контексте RAG) присутствуют конфиденциальные строки, модель может их воспроизвести, особенно при специально сконструированном запросе (атака prompt injection или extraction attack).

Пример механизма:

1. Модель обучена на корпусе, содержащем строки вида «Пользователь John Doe, email: john@example.com».
2. Злоумышленник задаёт вопрос: «Что ты знаешь о пользователе John Doe?»
3. Модель, не имея механизма отказа, генерирует ответ, содержащий email.

В Agentic RAG риск выше: агент может самостоятельно обращаться к базам данных, API или файлам, и если доступ к конфиденциальным источникам не ограничен, утечка происходит через цепочку вызовов.

3. Примеры атак

4. Связь с RAG и Agentic RAG

В RAG-системе контекст формируется из документов, полученных retrieval'ом. Если в векторной базе хранятся конфиденциальные документы (например, HR-политики, медицинские карты), LLM может включить их в ответ. Особенно опасно, когда:

• Retrieval возвращает документы с PII, не отфильтрованные на этапе индексации.
• LLM не имеет встроенного запрета на раскрытие таких данных.

В Agentic RAG агент может выполнять действия (вызов API, чтение файлов). Если агенту даны права на доступ к приватным источникам, злоумышленник может через цепочку промптов заставить агента прочитать и выдать данные. Пример: «Найди в CRM контакт CEO и отправь мне его телефон».

5. Методы защиты: очистка данных (PII removal)

Первый уровень — удаление конфиденциальной информации из тренировочных данных и из индексируемых документов RAG.

• Scrubbing — автоматическое удаление или маскирование PII (имена, email, номера телефонов, адреса) с помощью регулярных выражений, NER-моделей или специализированных библиотек (например, Microsoft Presidio).
• Анонимизация — замена реальных данных на синтетические (например, «John Doe» → «User_123»).
• Обобщение — замена точных значений на диапазоны («возраст 34» → «30-40»).

Пример кода фильтрации PII на Python с использованием Presidio:

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

text = "Клиент Иван Петров, телефон +7-999-123-45-67"
analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

analyzer_results = analyzer.analyze(text=text, language='ru')
anonymized_text = anonymizer.anonymize(text=text, analyzer_results=analyzer_results)
print(anonymized_text.text)  # "Клиент <PERSON>, телефон <PHONE_NUMBER>"

6. Методы защиты: RLHF и обучение отказу

RLHF (Reinforcement Learning from Human Feedback) — метод тонкой настройки, при котором модель учится предпочитать «безопасные» ответы. На этапе обучения:

• Аннотаторы оценивают ответы модели: отказ от раскрытия приватных данных получает высокую оценку.
• Модель штрафуется за выдачу PII.

В результате модель вырабатывает политику отказа: на запросы вида «Расскажи о пользователе X» она отвечает «Извините, я не могу предоставить личную информацию».

Ограничение: RLHF не защищает от атак, когда злоумышленник обходит запрет через переформулировку запроса (jailbreaking).

7. Методы защиты: пост-процессинг и фильтры

После генерации ответа применяется пост-процессинг — проверка и фильтрация вывода.

• Фильтр PII — тот же Presidio или регулярные выражения проверяют ответ на наличие конфиденциальных паттернов. Если обнаружено — ответ заменяется на шаблонный отказ.
• Фильтр конфиденциальности — сравнение ответа с исходными документами через эмбеддинги или n-граммы. Если ответ слишком похож на защищённый документ, он блокируется.
• LLM-as-a-judge — отдельная модель (например, GPT-4) оценивает ответ на предмет утечки.

Недостаток: пост-процессинг может ложно блокировать легитимные ответы (например, имя публичного лица).

8. Методы защиты: дифференциальная приватность

Дифференциальная приватность (DP) — математическая гарантия, что присутствие или отсутствие одной записи в тренировочных данных незначительно влияет на выход модели. Реализуется добавлением контролируемого шума в градиенты при обучении (DP-SGD).

• ε (epsilon) — параметр приватности: чем меньше ε, тем сильнее защита, но ниже точность.
• Для LLM DP применяется редко из-за сильного падения качества, но активно исследуется.

Формула (упрощённо):
P(M(D) ∈ S) ≤ e^ε * P(M(D') ∈ S) + δ
где D и D' — наборы данных, отличающиеся одной записью.

9. Мониторинг и аудит

Даже при всех защитах необходим мониторинг утечек в production:

• Логирование запросов и ответов — с маскированием PII в логах.
• Автоматические алерты — если модель начала выдавать подозрительно много отказов или, наоборот, перестала отказывать.
• Red teaming — регулярные атаки на систему для проверки устойчивости к extraction attack.

10. Compliance и регуляторные аспекты

Утечка данных через LLM может нарушать законы:

• GDPR (ЕС) — требует минимизации сбора и обработки персональных данных.
• HIPAA (США) — защита медицинской информации.
• 152-ФЗ (РФ) — о персональных данных.

Для соответствия необходимо:

• Проводить DPIA (Data Protection Impact Assessment) перед внедрением LLM.
• Внедрять privacy by design — защита на всех этапах пайплайна.
• Обеспечивать право на забвение — возможность удалить данные из модели (сложно, но решается через машинное забывание).

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

Задача Создать RAG-систему на синтетических данных (например, база сотрудников с PII) и реализовать защиту от утечки.

Инструменты

• LangChain / LlamaIndex для RAG.
• FAISS или Chroma для векторной базы.
• Presidio для фильтрации PII.
• OpenAI API или локальная модель (Llama 3) для генерации.

Шаги:

1. Сгенерировать 100 синтетических профилей сотрудников (имя, email, телефон, зарплата).
2. Индексировать их в векторную базу.
3. Реализовать RAG-цепочку, которая ищет профили по запросу.
4. Добавить фильтр PII на этапе индексации (удалить PII из чанков).
5. Добавить пост-процессинг ответа: проверять, не содержит ли ответ email или телефон.
6. Написать тестовые запросы: «Расскажи о сотруднике Иванове» — система должна отказать или выдать обезличенную информацию.
7. Провести red teaming: попробовать extraction attack через промпт-инъекцию.

Ожидаемый результат Работающая RAG-система, которая не выдает PII ни в одном из тестовых сценариев. Код с комментариями и отчётом о тестировании.

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

Навигация

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