Багаторівневий конвеєр очищення персональних даних для 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 додають розуміння контексту, а рушій політик перетворює знахідки на правильну захисну дію. Разом вони захищають те, що важливо, і зберігають користь решти даних, а це і є справжня мета, бо маскувати все підряд метою ніколи не було.