Многоуровневый конвейер очистки персональных данных для LLM-приложений

Современные ИИ-приложения перемалывают огромные объёмы неструктурированных и полуструктурированных данных, и немалая их часть чувствительна: персональные данные, учётные данные, финансовые записи, конфиденциальная деловая информация. Прежде чем что-то из этого попадёт в логи, хранилище, аналитику, на сторону или в последующую систему, нужен надёжный способ найти чувствительные фрагменты и защитить их, не испортив полезность данных.

Где обычного маскирования не хватает

Классическое маскирование опирается на регулярные выражения и заранее заданные шаблоны. Для структурированных значений вроде email, телефонов и номеров карт это работает хорошо. Хуже, когда чувствительность зависит от контекста. Возьмём такую фразу:

Ответ клиента на контрольный вопрос — BlueMountain.

Для сопоставителя шаблонов в строке BlueMountain нет ничего подозрительного. NLP-модели лучше распознают сущности, но тоже могут пропустить секреты, специфичные для предметной области. LLM понимают контекст, но если прогонять через них каждый вход, растут задержка, стоимость и непредсказуемость. Разумный выход — многоуровневое обнаружение.

Три уровня и движок политик

Схема объединяет три механизма обнаружения:

1. Правила — для предсказуемых шаблонов.
2. NLP — для сущностей и распознавания на уровне языка.
3. LLM — для классификации контекстной и предметно-специфичной чувствительной информации.

Всё найденное уходит в движок политик, который выбирает подходящее защитное действие. Цель не в том, чтобы сделать каждый уровень одинаково умным. Цель в том, чтобы для каждого вида данных использовать самый простой надёжный механизм.

Архитектура

Стройте это как переиспользуемый слой очистки, который стоит между приложениями, производящими данные, и системами, которые их потребляют.

Правила на Presidio

Microsoft Presidio — хорошая основа для поиска структурированных и заранее известных чувствительных значений. В нём есть распознаватели на шаблонах, распознаватели на NLP и возможность писать свои. Типичные цели — email, номера телефонов и карт, IP-адреса, государственные идентификаторы, API-ключи и любые внутренние бизнес-идентификаторы, которые вы зададите. Обнаружение по правилам быстрое, детерминированное и легко объяснимое, поэтому оно и должно быть первым уровнем.

Распознавание сущностей через NLP

Некоторые сущности надёжно не поймать регуляркой: имена людей, места, организации, даты и сущности предметной области. Например: "Рахул Шарма переехал из Мумбаи в Бенгалуру." NLP-модель выделит имена и места, хотя у них нет фиксированного формата.

Но найти сущность ещё не значит признать её чувствительной. Решать, нужна ли ей защита, всё равно должен уровень политик.

Классификация контекста через LLM

Некоторая информация раскрывается только через окружение. Во фразе "Ответ клиента на секретный вопрос — BlueMountain" традиционный распознаватель может слово не отметить, а LLM поймёт его роль по окружающему тексту. В идеале модель работает как классификатор, а не как свободный переписчик текста. Её вывод может выглядеть так:

{
  "text": "BlueMountain",
  "category": "SECURITY_ANSWER",
  "action": "MASK",
  "confidence": 0.96
}

Структурированные находки проще проверять, аудировать и передавать в детерминированную логику анонимизации.

Анонимизация по политикам

Обнаружение только выдаёт кандидатов. Что будет с каждым из них, решает движок политик, и действие зависит от категории:

• Email маскируются, номера телефонов — частично
• API-ключи удаляются полностью
• Идентификаторы клиентов заменяются токенами
• Ответы на контрольные вопросы вычёркиваются
• Название публичной компании может пройти без изменений

Если держать это сопоставление отдельно, правила приватности можно менять без переобучения или замены моделей обнаружения.

Последовательно или параллельно

Обычно уровни запускают одним из двух способов. При последовательной схеме LLM видит только текст, который предыдущие уровни уже очистили. Это ограничивает объём чувствительных данных, доходящих до модели, но может убрать контекст, нужный классификатору. При параллельной схеме все детекторы одновременно работают с сырым входом. Контекст сохраняется, но сырые данные могут попасть в LLM-классификатор.

Что подойдёт, зависит от границы доверия модели, среды развёртывания, требований к задержке и ограничений по приватности. Один из способов не раскрывать сырые данные — запускать модели у себя, on-premise.

Стоимость, безопасность и польза

Отправлять в LLM каждый вход и дорого, и не нужно. Многоуровневая схема эффективнее:

• Структурированные поля идут на обнаружение по правилам
• Известные сущности идут в Presidio или NLP
• Неоднозначный свободный текст идёт в LLM на классификацию
• Данные высокого риска попадают под строгие политики маскирования

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

Разбор на примере

Исходная запись:

{
  "email": "rahul@example.com",
  "customer_name": "Rahul Sharma",
  "recovery_answer": "BlueMountain",
  "transaction_id": "TXN-123456"
}

И очищенная версия:

{
  "email": "<EMAIL>",
  "customer_name": "<PERSON>",
  "recovery_answer": "<SECURITY_ANSWER>",
  "transaction_id": "<TRANSACTION_ID>"
}

Оценивайте систему по точности и полноте, долям ложноотрицательных и ложноположительных срабатываний, задержке очистки, частоте эскалации входов в LLM, стоимости обработки одной записи и тому, сколько ценности остаётся в данных после маскирования.

Почему уровни

Ни одна техника в одиночку не находит чувствительные данные надёжно. Правила дают скорость и детерминизм, NLP улучшает распознавание сущностей, LLM добавляют понимание контекста, а движок политик превращает находки в правильное защитное действие. Вместе они защищают то, что важно, и сохраняют пользу остальных данных, а это и есть настоящая цель, ведь маскировать всё подряд целью никогда не было.