Чому самостійно розгорнуті інструменти PII не витримують аудит відповідності
GDPR вимагає доказів. Ви маєте продемонструвати, що видалення PII виконувалось однаково щоразу. Аудитори DPA це перевіряють. Вони хочуть бачити чіткий послідовний метод, застосований до всіх даних.
Самостійно розгорнутий Presidio має тут реальну проблему. Це не питання конфігурації. Це фундаментальне обмеження самостійно розгорнутих NLP-інструментів.
Що таке дрейф середовища?
Самостійно розгорнутий Presidio працює в середовищах розробки, staging і виробничому. Кожне з них може поводитись по-різному. Тому однаковий вхідний документ може дати різні результати в кожному з них.
Це називається дрейфом середовища. Він має чотири основні причини.
Дрейф версії моделі
Моделі spaCy мають версіонування. Моделі en_core_web_lg 3.4.4 та en_core_web_lg 3.5.1 навчались на різних даних і мають різну архітектуру. Тому один і той самий документ може дати різні результати NER з кожною версією.
Типове налаштування виглядає так:
- Dev:
en_core_web_lg 3.4.4— встановлена на початку проєкту - Staging:
en_core_web_lg 3.5.0— оновлена під час планового обслуговування - Production:
en_core_web_lg 3.5.1— оновлена під час виправлення безпеки
Це три конфігурації. Три версії моделі. Три різних результати виявлення. Тести проходять у staging. Але виробниче середовище використовує іншу модель. Тому розрив залишається непоміченим.
Дрейф версій залежностей
spaCy 3.4.x та 3.5.x відрізняються за способом розбиття речень. Ця зміна впливає на те, як знаходяться імена поблизу кордонів речень. Ці зміни відображені в примітках до релізів spaCy. Але більшість команд не перевіряє їх на вплив щодо PII.
Дрейф конфігурації
Порогові значення оцінки, встановлені в розробці, можуть не перенестись до виробничого середовища. Власні словники також можуть відрізнятись між конфігураціями. Такі розбіжності поширені. Вони рідко відстежуються. Дивіться наш посібник з відповідності GDPR, щоб дізнатись, що перевіряють аудитори.
Відмінності апаратного забезпечення
Математика в NLP-моделях не є ідентичною на всіх CPU та GPU. Споживчий ноутбук і сервер можуть давати злегка різні результати оцінки. Тому деякі імена можуть бути знайдені на одній машині, але не на іншій.
Реальна знахідка аудиту
Банк протестував своє самостійне розгортання Presidio.
Тестове середовище: Presidio зі spaCy 3.4.4 на staging-кластері. Виробниче середовище: Presidio зі spaCy 3.5.1 на виробничому кластері.
Вони запустили однаковий набір документів через обидва середовища, а потім порівняли результати. Знахідка: 3% документів мали різні результати видалення PII. Деякі імена виявлялись у staging, але не у виробничому середовищі. Деякі мали різні межі виявленого тексту.
Висновок аудиту був прямим: «Компанія не може продемонструвати послідовне застосування технічних заходів видалення PII через середовищеспецифічні відмінності у результатах виявлення».
Стаття 32 GDPR вимагає відповідних технічних заходів. Правила EDPB щодо видалення PII вимагають послідовності та відтворюваності. Рівень 3% при обробці 100 000 документів на місяць означає 3 000 документів з непослідовними результатами щомісяця. Деякі — це хибні негативи. PII, яку staging виявив би, залишається у виробничих вихідних даних. Це порушення відповідності.
Після цього банк перейшов на managed SaaS. Знахідку аудиту було закрито. Дивіться нашу сторінку безпеки та відповідності, щоб дізнатись, як managed-конфігурації вирішують цю проблему.
Чому managed-сервіси відрізняються
Managed-сервіс запускає одну версію рушія. Всі користувачі одночасно використовують одну і ту саму версію. Оновлення моделей застосовуються з одного місця. Конфігурація також управляється з одного місця з повним журналом змін. Апаратне забезпечення користувача не впливає на результати.
Тому один і той самий документ, оброблений сьогодні, дає той самий результат наступного місяця. Якщо версія рушія змінилась, ця зміна зафіксована та версіонована.
Ключова відмінність — у журналі аудиту.
Журнал аудиту самостійного розгортання:
- «Використано Presidio 2.2.35 зі spaCy
en_core_web_lg 3.5.1на Ubuntu 22.04.» - Чи була це та сама версія, що в staging? Невідомо.
- Чи змінювалась модель з моменту обробки цього документа? Невідомо, якщо не відстежувалось.
- Чи таке саме порогове значення, як при тестуванні? Залежить від управління конфігурацією.
Журнал аудиту managed-сервісу:
- «Використано API anonym.legal, версія рушія 4.22.1, о 2025-03-15T14:22:31Z.»
- Та сама версія для всіх користувачів? Так.
- Чи змінювалась? Версії рушія закріплені. Версія 4.22.1 завжди означає той самий рушій.
- Чи можна відтворити конфігурацію? Так. Ідентифікатор пресету зафіксований. Конфігурацію цієї версії можна отримати.
Журнал managed-сервісу зрозумілий. Журнал самостійного розгортання потребує ретельного відстеження, яке більшість команд ігнорує.
Як покращити послідовність при самостійному розгортанні
Якщо самостійне розгортання є обов'язковим, ви можете зменшити дрейф чотирма кроками.
По-перше, закріпіть версії моделей. Зафіксуйте точні версії моделей у всіх файлах розгортання. Заблокуйте автоматичні оновлення. Відстежуйте версії в системі контролю версій.
Далі, заморозьте образи контейнерів. Будуйте Docker-образи з точними версіями моделей, вбудованими в них. Позначайте кожен образ версією моделі, версією Presidio та датою. Не оновлюйте базові образи без попереднього тестування.
Також зберігайте конфігурацію в коді. Зберігайте всі налаштування Presidio у файлах, що відстежуються системою контролю версій. Це включає детектори, порогові значення оцінки та активні мови. Розгортайте конфігурацію разом із додатком.
Нарешті, тестуйте в різних середовищах. Після будь-якого оновлення запускайте фіксований набір тестових документів через нове середовище. Порівнюйте результати зі збереженим еталоном. Автоматизуйте цю перевірку. Дивіться FAQ для відповідей на поширені запитання про автоматизоване регресійне тестування PII.
Ці кроки допомагають. Але вони також додають роботи. Managed-сервіс забезпечує ту саму послідовність без додаткових зусиль.
Підсумок
Послідовне видалення PII не фігурує в рекламних матеріалах. Але воно стає критичним, коли аудитори вимагають доказів.
Без активної уваги самостійно розгорнуті інструменти PII дрейфують. Зміни версій вносять непомітні прогалини. Ці прогалини з'являються як знахідки аудиту.
Managed-сервіси забезпечують послідовність за замовчуванням. Рушій запускається з одного місця. Конфігурації користувачів не впливають на результати. Для команд, орієнтованих на відповідність, це пряма перевага.