Zero Data Retention и приватность: защита ПДн в LLM

Сотрудник банка вставляет в ИИ-ассистента выписку клиента, чтобы подготовить ответ на претензию. В выписке — ФИО, паспорт, IBAN, адрес, суммы операций. Ассистент вызывает облачную модель. С этого момента персональные данные клиента физически покинули периметр и лежат в инфраструктуре провайдера: минимум в оперативной обработке, а по умолчанию ещё и в логах abuse-мониторинга на 30 дней. Клиент об этом не знает и согласия на трансфер не давал.

Это не гипототический риск, а самый частый способ, которым компании нарушают GDPR через ИИ. Не злым умыслом — тем, что на пути запроса не стояло ничего, что вычищает данные до вызова модели. Задача инженера data plane — поставить барьер, который гарантирует: конфиденциальные данные не утекут, не осядут в логах провайдера и не попадут в обучение публичных моделей.

Цена утечки и обещание бизнесу

Для финансовой организации цена утечки — не абстрактный штраф. Это комбинация: GDPR-санкции, нарушение банковской тайны, отзыв доверия регулятором. Архитектурное обещание звучит так: модель никогда не видит реальных ПДн, а компания может это доказать.

Условия, без которых обещание невыполнимо:

ПДн и банковская тайна не покидают периметр в открытом виде.
Провайдер не хранит промпты и не обучается на них (Zero Data Retention).
Право клиента на удаление (GDPR ст. 17) не ломается тем, что данные ушли в чужое обучение и стали невозвратными.

Регуляторный драйвер

Отправка ПДн в LLM-провайдера без правового основания и без гарантий нехранения — нарушение ст. 5 (минимизация, ограничение хранения), ст. 25 (privacy by design) и ст. 32 (безопасность обработки) GDPR. Трансграничная передача добавляет главу V.

Хранение промптов для abuse-мониторинга — это экспорт ПДн третьей стороне, даже если «никто их не читает». Попадание ПДн в обучающий корпус делает право на удаление неисполнимым — юридический тупик. EU AI Act (Art. 10) пересекается с GDPR в части data governance для high-risk систем.

Архитектурный паттерн: In-Flight Anonymization Gateway + ZDR

Прослойка перед вызовом LLM обезличивает данные на входе и восстанавливает на выходе. Контрактный Zero Data Retention стоит вторым рубежом. Модель работает с плейсхолдерами; реальные значения живут только внутри периметра доли секунды.

              ┌────────── Anonymization Gateway ──────────┐
 «Иванов И.И.,│  detect (NER+regex) → mask → <PERSON_1>    │
  IBAN RS35…» │        │                                    │  masked prompt
 ────────────►│        ▼                                    │──────────────► LLM (ZDR)
              │  mapping → Redis (TTL = жизнь запроса)       │◄──────────────
              │        ▲                                    │  masked answer
 «Уважаемый   │  unmask ◄── mapping                         │
  Иванов И.И.»│                                             │
 ◄────────────└─────────────────────────────────────────────┘

Инженерный стек

Детекция PII/NER: Microsoft Presidio (open, MIT; актуальный релиз 2.2.362, март 2026; 50+ типов сущностей; сменные NLP-бэкенды — spaCy / ONNX / Stanza / HuggingFace). Альтернативы — Private AI, AWS Comprehend PII. Regex для структурного (IBAN, СНИЛС, паспорт, карта).
Gateway: LiteLLM Proxy (нативная интеграция с Presidio) или собственный FastAPI-слой.
Mapping store: Redis с коротким TTL.
ZDR: Enterprise-контракты (Azure OpenAI, Anthropic / OpenAI Enterprise, AWS Bedrock) с Zero Data Retention и отключённым логированием промптов, зафиксировано в DPA.

Реализация

Шаг 1. Gateway как единственная дверь к модели

Прямые вызовы LLM из сервисов запрещены сетевой политикой — всё идёт через gateway. Иначе любой разработчик, дернувший API напрямую, обходит всю плоскость защиты.

Шаг 2. Детекция и обратимое маскирование

NER и regex находят сущности; каждая заменяется на типизированный плейсхолдер, а обратное отображение кладётся в Redis под ключ trace_id (тот же id, что в аудите):

results = analyzer.analyze(text=prompt, language="ru")   # Presidio NER
masked, mapping = reversible_mask(prompt, results)        # <PERSON_1>, <IBAN_1>...
redis.setex(f"pii:{trace_id}", TTL_SECONDS, json.dumps(mapping))

resp = llm.call(masked, extra_headers={"x-zdr": "true"})
answer = unmask(resp, json.loads(redis.get(f"pii:{trace_id}")))

Шаг 3. Fail-closed

Если детектор недоступен или уверенность ниже порога — запрос блокируется, а не пробрасывается «как есть». Приватность — свойство, которое ломается тихо; дефолт — отказ, не пропуск.

Шаг 4. ZDR как второй рубеж

Маскирование неполно, поэтому ZDR обязателен независимо от него: даже если что-то просочилось, провайдер контрактно не хранит и не обучается. Два рубежа, не один.

Где ломается

Recall < 100%. NER пропускает неструктурированные и редкие имена, транслит, опечатки, нестандартные форматы. Маскирование снижает риск, не обнуляет — отсюда обязательность ZDR.
Квази-идентификаторы. «Клиент из посёлка N, 1974 г.р., единственный ИП» не является PII по отдельным полям, но реидентифицируется по совокупности. Маскирование сущностей это не ловит — это про k-анонимность, другой инструмент.
Псевдонимизация ≠ анонимизация. Обратимое маскирование с сохранением mapping — это по GDPR псевдонимизация (ст. 4(5)), а не анонимизация. Данные остаются ПДн, к mapping-хранилищу применяются все требования: шифрование, доступ, TTL. Выдавать псевдонимизацию за «данных больше нет» — значит копать яму для регулятора.
Утечка через структуру. Даже обезличенный текст несёт коммерческую тайну (суммы, условия сделки) — второй аргумент за ZDR.
Латентность. NER на каждом запросе и на длинных документах заметно тормозит; кэш детекции и батчинг помогают, но плата есть.
Деанонимизация галлюцинаций. Модель может «сочинить» плейсхолдер, которого нет в mapping — unmask должен это переживать: оставлять как есть и писать флаг в аудит.

Стандарты и маппинг

GDPR: ст. 5, 25, 32, глава V (трансфер); псевдонимизация — ст. 4(5).
EU AI Act: Art. 10 (data governance для high-risk).
ISO/IEC 42001: контроли управления данными ИИ-системы.
OWASP LLM: LLM02 (Sensitive Information Disclosure).
NIST AI RMF: Map/Manage — data privacy.

Лаба и артефакт

Развернуть LiteLLM + Presidio перед сервисом; собрать golden-датасет синтетических ПДн клиентов (разные форматы, транслит, квази-идентификаторы); замерить precision/recall детектора по типам, латентность; включить fail-closed; подписать и зафиксировать ZDR в DPA.

Артефакт: gateway-конфиг, отчёт по recall на golden-датасете, карта mapping-хранилища с режимом шифрования и TTL — доказательство для аудита.

Чеклист зрелости

L1: ZDR-контракт подписан, логирование промптов у провайдера отключено.
L2: gateway с NER-маскированием на пути всех вызовов, mapping с TTL и шифрованием, fail-closed.
L3: метрики recall в CI, покрытие квази-идентификаторов, регресс на golden-датасете при смене модели, честная классификация «псевдонимизация» в реестре обработки.

Источники

Если на пути пакета с ПДн клиента к облачной LLM не стоит маскирование и контрактный Zero Data Retention — данные уже у провайдера, и доказать обратное невозможно.