Чувствительные данные: как находить и маскировать

Одна из задач guardrails — контролировать, какие данные доступны LLM. В контексте могут оказаться персональные данные, информация о счетах или ключи доступа. Такие данные нужно защищать от утечек и маскировать там, где модель не должна их видеть.

Казалось бы, всё понятно: регулярки и NER-модели доступны давно. Находим данные, заменяем заглушками. Но есть 3 проблемы, которые мы всё ещё решаем у себя:

1️⃣ Скорость
Чтобы пропускать меньше чувствительных данных (растить recall), приходится усложнять правила, иногда подключать ML-модели. А это может увеличивать задержку.

2️⃣ Сломанные запросы
При маскировании можно повредить структуру JSON или типы значений. Данные спрятали, но запрос больше не работает.

3️⃣ Влияние на генерацию
Если фильтр часто маскирует лишнее, падает precision. Модель теряет полезный контекст — и вместе с данными можем искажать смысл запроса.

Поэтому я иногда смотрю, как эти задачи решают другие команды. Сегодня на вебинаре от Cloud.ru интересно разобрали guardrails-llm-filter — их решение на Go.

Внутри у них базовые регулярки и валидаторы контрольных сумм для некоторых сущностей. ML не используется вообще. Подход очень знакомый. Но что зацепило:

🟣Заявленный p95 маскирования < 1 мс. Звучит как магия. На слайде был указан 1 CPU, а в ответе на мой вопрос прозвучало, что тестировали с большим количеством CPU. Интересно, что будет на реальных запросах под нагрузкой.

🟣На трёх бенчмарках авторы получили precision 92,4–99,9% и recall 75,1–87,2%. Конечно, бенчмарки ≠ прод: форматы, опечатки и состав данных будут другими. Да и пропуски при таком recall остаются — важно понять, какие именно.

🟣Исходный код проекта опубликован на GitHub. Можно разобраться, как всё устроено, воспроизвести замеры и проверить подход на своих данных. Ссылка

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