Це машинний переклад оригінального документа англійською мовою. У разі будь-яких розбіжностей між цим перекладом та оригінальною англійською версією, пріоритет має версія англійською мовою. Читати оригінал англійською мовою
Локальний псевдонімізатор: розроблено та протестовано
2026-05-22 · Caiioo Team
Ми хотіли вирішити проблему конфіденційності в системах ШІ, які навчаються на реальній особистій інформації та зберігають її. Політики «Нульового зберігання даних» зменшують ризики, але вони сповнені винятків. Фактично вони кажуть: «Ми не зберігатимемо ваші запити чи відповіді, за винятком: (вставте величезний список винятків: цілі безпеки, урядовий нагляд, судове зберігання, розробка продукту, журнали помилок, покращення сервісів...)»
Щоб вирішити це, ми створили фільтр персональних даних, який працює на власному комп'ютері користувача, бачить повідомлення до того, як воно залишить пристрій, і повертає ту саму відповідь, яку користувач отримав би, якби текст було введено без фільтра взагалі.
Отже, ми його збудували. Наступна версія Caiioo включатиме Псевдонімізатор. Доступ до нього можна отримати через іконку щита в чаті з агентом, а також у налаштуваннях.
Цей документ описує обґрунтування, архітектуру, процес оцінки та принципи проектування нашої системи фільтрації конфіденційності.
Що ми прагнемо зробити
Загальний захист конфіденційності шляхом мінімізації даних. Коли користувач спілкується з віддаленою моделлю, моделі не потрібні справжнє ім'я, домашня адреса, реальна електронна пошта або номер телефону клієнта, щоб відповісти на запитання користувача. Їй потрібна форма запитання, і воно має виглядати як справжнє запитання, щоб LLM не відхилила запит як тестовий. Тому фільтр видаляє реальні ідентифікатори з даних, що надсилаються до AI, і вставляє реальні значення назад на зворотному шляху. Модель бачить синтетичні імена та ідентифікатори; користувач бачить реальну розмову.
Допомога у дотриманні вимог HIPAA. Другий режим орієнтований на 18 ідентифікаторів згідно з правилом HIPAA Safe Harbor (§164.514) та більш гнучкий варіант Limited Data Set. Клініцист, адміністратор охорони здоров'я або будь-хто, хто працює з відповідними робочими процесами, може спілкуватися з моделлю загального призначення про реальні випадки, не надсилаючи захищену медичну інформацію до AI. Ми не є спеціалістами з комплаєнсу для підзвітної організації — але ми можемо бути тим шаром, який запобігає виходу PHI за межі ноутбука. Наші оцінки надають вимірювані показники, які організації можуть використовувати для оцінки придатності фільтра до їхніх стандартів комплаєнсу та конфіденційності. Усі заходи щодо конфіденційності та безпеки є оціночними судженнями, відповідальність за які несе користувач або організація-користувач.
Ми обрали обидва варіанти, оскільки інженерна частина однакова, а сценарій використання PHI технічно навіть простіший через використання чітких іменованих сутностей, які легше редагувати, ніж більш загальні дані в категорії персональних даних. Фільтрації HIPAA також сприяє той факт, що вона зазвичай здійснюється англійською або іспанською мовами. Ми виявляємо ідентифікатори, замінюємо їх стабільними псевдонімами та підставними ідентифікаторами в тому самому форматі, відновлюємо їх на зворотному шляху і ніколи не реєструємо реальні значення. Зв'язок між синтетичною та реальною інформацією зберігається лише на пристрої користувача, щоб користувач міг бачити реальну інформацію у відповідях агента. Список категорій та політика доступу — це те, що змінюється залежно від режиму.
Чому регулярні вирази плюс машинне навчання, а не щось одне з них
У нашому псевдонімізаторі використовуються дві основні технології фільтрації: детермінована мова розпізнавання образів, що називається регулярними виразами (regex), та навчені моделі машинного навчання.
Regex не має рівних у розпізнаванні поверхневих форматів. Адреса електронної пошти має певну структуру ([email protected]). Те саме стосується IP-адреси, кредитної картки, IBAN, VIN, SSN (XXX-XX-XXXX) або API ключа. Якщо формат надійний, regex виявляє його детерміновано кожного разу, без навантаження на модель та витрат на інференс.
Однак regex безпорадний, коли йдеться про контекст. Фраза «Графік Сари з минулого вівторка» містить ім'я особи та дату, але жодне з них неможливо ідентифікувати лише за форматом. Фраза «Пацієнт на Елм, 14» містить адресу, яка перетинається з тисячами значень, що не є адресами. Щоб зрозуміти, що «Їхній MRN — 7741032», потрібні слова навколо номера.
Мала донавчена мовна модель справляється з контекстом — наша модель є спеціально навченим енкодером на 110 млн параметрів, дистильованим з багатомовної крихітної мовної моделі. Вона зчитує речення, а не підрядок, і є достатньо малою, щоб надзвичайно швидко працювати на пристрої, навіть на мобільному телефоні.
Бенчмарки ілюструють взаємодоповнювальні переваги цих двох рівнів. Ми протестували обидва рівні ізольовано, щоб переконатися, що кожен з них дійсно виконує свою роль. На наборі з 150 запитань PrivacyBench-PD, де запитання та відповіді явно НЕ використовувалися для навчання моделі:
| Рівень | Виявлено PII | Відсоток виявлення |
|---|---|---|
| Тільки Regex | 205 / 670 | 30.6 % |
| Тільки ML | 516 / 670 | 77.0 % |
| Обидва (production) | 625 / 670 | 93.3 % |
Самі лише регулярні вирази пропускають три чверті ідентифікаторів, оскільки більшість ідентифікаторів у реальному тексті не є структурованими. Сама лише ML пропускає 16 відсоткових пунктів, які б виявив рівень regex — речі, що визначаються виключно своєю формою (кредитна картка виглядає як кредитна картка; модель не має додаткового сигналу для аналізу). Разом вони охоплюють те, що жоден з методів не може охопити самостійно.
Якщо поглянути глибше на те, де кожен рівень є вирішальним: у тому самому наборі даних 16 тестових значень були виявлені лише за допомогою regex (електронні адреси, IP, фінансові рахунки, структуровані ID) і 327 були виявлені лише за допомогою ML (імена, контекстуальні ідентифікатори, багатомовні фрази).
Малий, розумний, швидкий — і працює всюди
Нам потрібно було змусити фільтр працювати локально на пристрої, що стало інженерним викликом.
Він має бути малим, оскільки наш додаток працює на багатьох системах: у розширенні браузера, додатках для macOS, iOS, Android, або Windows та Linux. Пакет займає близько 113 МБ на модель. Є дві моделі — одна для загальних персональних даних, інша для захищеної медичної інформації — і режим Safe Harbor запускає обидві паралельно. Серед них бюджетний Android-пристрій є найменш продуктивним, проте наша система працює справно.
Він має бути розумним, оскільки пропуски призводять до витоку реальних даних до віддаленої LLM, а хибнопозитивні спрацьовування псують розмову. Імена мають бути анонімізовані, а займенники — ні. Електронна пошта лікаря в пересланій гілці має бути прихована, а футер [email protected], ймовірно, ні.
Він має бути швидким, оскільки він стоїть безпосередньо на шляху кожного повідомлення, яке користувач надсилає або отримує. Ми виміряли затримку циклу — вона становить менше 200 мс на одному потоці процесора, переважно на токенізацію. На WebGPU та на Apple Neural Engine вона мізерна порівняно з мережевою затримкою самого виклику LLM.
Він має працювати в різних середовищах, оскільки Caiioo є мультиплатформним. Та сама система працює в розширеннях Chrome, macOS та iOS, Android, а також на Windows та Linux. Одна модель виявлення, одна бібліотека regex, один механізм злиття, одна політика — ідентична поведінка на кожній платформі, де працює Caiioo.
Показники
Після кількох раундів тестування та навчання ми зупинилися на 16-й версії наших моделей. Нижче наведено три бенчмарки, кожен з яких вимірює різні аспекти.
Наш власний набір тестів: 150 запитань, які модель ніколи не бачила
Перед тестуванням на публічних бенчмарках ми запустили наш фільтр Personal Data на внутрішньому наборі тестів, який навмисно тримали поза навчальними даними — тож детектор ніколи раніше не бачив жодного з цих запитань. 150 запитань розділені на чотири групи (фрагменти коду, проза документів, навмисно незвичні формулювання та 10 іноземних мов), плюс «негативна» група, яка взагалі не містить приватних даних (перевірка на адекватність, щоб ми не видаляли зайвого). Комбінований конвеєр regex + ML:
| Суб-бенчмарк | Виявлено | Показник |
|---|---|---|
| code_bench | 69 / 74 | 93.2 % |
| doc_bench | 233 / 247 | 94.3 % |
| generalization_bench | 123 / 133 | 92.5 % |
| multilingual_bench | 200 / 216 | 92.6 % |
| Усі 4 позитивні бенчі | 625 / 670 | 93.3 % |
(Негативна група не мала приватних даних для пошуку. Фільтр замаскував один елемент, який не мав би маскувати — що узгоджується з показниками точності (precision) нижче.)
Система оцінювання сувора: кожен очікуваний фрагмент приватних даних має повністю зникнути з замаскованого результату, щоб запитання отримало бал. Жодних часткових балів або «майже вгадав». Це жорсткіше, ніж бенчмарки, де суддею виступає інша LLM (судді-LLM зазвичай поблажливі). Для отримання цифр, які можна безпосередньо порівняти з іншими системами, дивіться розділ порівняння нижче.
PrivacyBenchHIPAA — 40 медичних запитань
Кожне запитання містить захищену медичну інформацію, яку необхідно видалити (імена, номери медичних карток тощо), ТА сигнали, які мають бути збережені (дати, географія, вік, якщо він менше 90 років — правило HIPAA Limited Data Set). Система оцінювання перевіряє обидва напрямки: чи видалили ми те, що мали видалити, і чи залишили ми те, що мали залишити?
| Режим | PHI видалено | Збережене залишено |
|---|---|---|
| Limited Data Set (зберегти дати / географію / вік ≤89) | 79 / 79 (100 %) | 34 / 34 |
| Safe Harbor (видалити все, включаючи дати) | 99 / 104 (95.2 %) | — |
Підрежим Limited Data Set показав ідеальний результат у цьому бенчмарку. Safe Harbor — де потрібно видаляти більше, а отже, більше можливостей для пропуску — охоплює 95.2%.
Результати за категоріями на наших власних даних, 200 зразків на режим
Публічні бенчмарки звалюють усе в одну купу. Наші внутрішні тестові дані розбивають результати за категоріями (імена, електронні адреси, адреси тощо) і запускають кожну трьома способами: лише regex, лише ML та обидва разом. Це точно показує нам, яка технологія виявляє певний тип ідентифікатора — і де кожна з них потребує допомоги іншої. Останній запуск, 2026-05-20:
Підсумок за всіма трьоми режимами фільтрації
| Режим | Комбінована повнота | Точність | F2 | Зразки |
|---|---|---|---|---|
| Фільтр Personal Data | 97.3 % | 97.8 % | 97.4 | 200 |
| Фільтр HIPAA — Limited Data Set | 92.3 % | 92.3 % | 92.3 | 200 |
| Фільтр HIPAA — Safe Harbor | 91.9 % | 91.5 % | 91.8 | 200 |
Ці цифри не включають URL, які ми навмисно залишаємо — видалення URL порушило б подальші дії, такі як «відкрити це посилання» або «отримати цю сторінку». Докладніше про це в розділі про робочий процес нижче.
Загальна картина перед таблицями за категоріями: у кожному режимі ідентифікатори, які дійсно ідентифікують особу, виявляються у 100% випадків або близько до цього. Імена, електронні адреси, номери телефонів, поштові адреси, державні ідентифікатори, біометричні дані, точна геолокація, номери медичних карток, дати народження, номери соціального страхування — виявлені в кожному зразку, у кожному тесті. Категорії, де ми опускаємося нижче 100%, є передбачуваними: ідентифікатори пристроїв (величезна різноманітність форматів у реальному тексті), різноманітні інституційні ідентифікатори (номери програм лояльності, ідентифікатори співробітників — та сама проблема) та фотографії (текстовий фільтр не може бачити, що всередині зображення). Жоден із них не є ідентифікатором типу «ім’я в картці» або «email у чернетці», які дійсно мають значення для витоку даних. Категорії з високими ставками є надійними.
Фільтр Personal Data
Відсортовано за комбінованою повнотою (найкращі спочатку), потім за рівнем ризику (T1 = найбільш чутливі).
| Категорія | Рівень | Повнота Regex | Повнота ML (raw) | Комбінована повнота | Gold n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| email_address | T1 | 100.0 % (20/20) | 100.0 % (20/20) | 100.0 % | 20 |
| government_id | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| person_name | T1 | 13.3 % (4/30) | 96.7 % (29/30) | 100.0 % | 30 |
| phone_or_fax | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| postal_address | T1 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| precise_geolocation | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| birth_date | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| ip_address | T2 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| online_handle | T2 | 40.0 % (4/10) | 100.0 % (10/10) | 100.0 % | 10 |
| vehicle_id | T2 | 50.0 % (5/10) | 100.0 % (10/10) | 100.0 % | 10 |
| authentication_secret | T4 | 40.0 % (4/10) | 100.0 % (10/10) | 100.0 % | 10 |
| financial_account | T1 | 90.0 % (18/20) | 100.0 % (20/20) | 90.0 % | 20 |
| institutional_id | T3 | 80.0 % (8/10) | 90.0 % (9/10) | 90.0 % | 10 |
| device_id | T3 | 40.0 % (4/10) | 50.0 % (5/10) | 80.0 % | 10 |
Як бачимо, дворівнева архітектура виправдовує себе. Поштові адреси, дати народження та імена людей мають показник 0–13% лише за regex — там немає шаблону для зіставлення, тому лише модель ML може їх виявити. Електронні адреси, номери телефонів, IP-адреси, державні та біометричні ідентифікатори, а також точна геолокація мають 100% лише за regex — це поверхневі формати, які модель ML отримує «безкоштовно». Нікнейми, ідентифікатори транспортних засобів та секрети автентифікації змішані: regex виявляє стандартні форми, ML — решту. Комбінована повнота відповідає або перевищує показник будь-якого окремого рівня в кожній категорії.
Ідентифікатори пристроїв та різноманітні інституційні ідентифікатори — це категорії з показником нижче 100%, і ми знаємо чому: вони мають найширший спектр форматів у реальному тексті. Ми воліємо бути чесними щодо категорій, де повнота знижується, ніж вдавати, що фільтр ідеальний усюди.
Фільтр HIPAA — підрежим Limited Data Set
Підрежим Limited Data Set за задумом зберігає дати, географію та вік 89 років або молодше — це сигнали, які HIPAA дозволяє організації зберігати для законних клінічних досліджень та операцій.
| Категорія | Рівень | Повнота Regex | Повнота ML (raw) | Комбінована повнота | Gold n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| email_address | T1 | 100.0 % (13/13) | 100.0 % (13/13) | 100.0 % | 13 |
| medical_record_number | T1 | 100.0 % (26/26) | 100.0 % (26/26) | 100.0 % | 26 |
| person_name | T1 | 15.4 % (4/26) | 100.0 % (26/26) | 100.0 % | 26 |
| phone_or_fax | T1 | 100.0 % (13/13) | 100.0 % (13/13) | 100.0 % | 13 |
| social_security_number | T1 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| account_number | T2 | 0.0 % (0/13) | 100.0 % (13/13) | 100.0 % | 13 |
| health_plan_id | T2 | 0.0 % (0/13) | 100.0 % (13/13) | 100.0 % | 13 |
| ip_address | T2 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| license_number | T2 | 0.0 % (0/12) | 100.0 % (12/12) | 100.0 % | 12 |
| vehicle_id | T2 | 25.0 % (3/12) | 100.0 % (12/12) | 100.0 % | 12 |
| device_id | T3 | 41.7 % (5/12) | 100.0 % (12/12) | 100.0 % | 12 |
| photo | T2 | 0.0 % (0/12) | 0.0 % (0/12) | 0.0 % | 12 |
Фотографії — це відомий пропуск; текстовий фільтр не може бачити вміст зображення. PHI у зображеннях — це окрема проблема, рішення для якої ми ще не випустили. Усі інші категорії в цьому режимі мають 100%.
Фільтр HIPAA — підрежим Safe Harbor
Safe Harbor видаляє все, що зберіг би підрежим Limited Data Set — дати, вік понад 89 років, географію. Для забезпечення найсуворішого охоплення він запускає обидві моделі фільтрації паралельно: спеціалізовану для HIPAA та загальну для персональних даних.
| Категорія | Рівень | Повнота Regex | Повнота ML (raw) | Комбінована повнота | Gold n |
|---|---|---|---|---|---|
| age_over_89 | T1 | 100.0 % (18/18) | 0.0 % (0/18) | 100.0 % | 18 |
| biometric_id | T1 | 100.0 % (9/9) | 100.0 % (9/9) | 100.0 % | 9 |
| email_address | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| medical_record_number | T1 | 100.0 % (20/20) | 100.0 % (20/20) | 100.0 % | 20 |
| person_name | T1 | 20.0 % (4/20) | 100.0 % (20/20) | 100.0 % | 20 |
| phone_or_fax | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| social_security_number | T1 | 90.0 % (9/10) | 100.0 % (10/10) | 100.0 % | 10 |
| account_number | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| general_date | T2 | 100.0 % (27/27) | 29.6 % (8/27) | 100.0 % | 27 |
| health_plan_id | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| ip_address | T2 | 100.0 % (9/9) | 100.0 % (9/9) | 100.0 % | 9 |
| license_number | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| vehicle_id | T2 | 10.0 % (1/10) | 100.0 % (10/10) | 100.0 % | 10 |
| device_id | T3 | 22.2 % (2/9) | 88.9 % (8/9) | 77.8 % | 9 |
| photo | T2 | 0.0 % (0/9) | 0.0 % (0/9) | 0.0 % | 9 |
Два цікаві рядки — це загальні дати (regex 100%, ML 30%) та вік понад 89 років (regex 100%, ML 0%). Ми навмисно дозволяємо regex обробляти обидва випадки в Safe Harbor: дати мають структуру, яку regex виявляє щоразу, і ми не хочемо, щоб імовірнісна модель ставила під сумнів числовий поріг, такий як «>89». Детерміноване правило надійніше, ніж спроба навчити модель ML тому самому правилу.
Загальні показники за всіма категоріями
Підсумовуючи: як повний конвеєр (regex + ML разом) виглядає у порівнянні з кожним рівнем окремо?
| Режим | Рівні | Повнота | Точність | F2 |
|---|---|---|---|---|
| Personal Data | лише regex | 65.8 % | 93.0 % | 69.9 % |
| Personal Data | лише ML | 95.4 % | 92.4 % | 94.8 % |
| Personal Data | обидва (повний) | 96.9 % | 98.0 % | 97.1 % |
| Limited Data Set | лише regex | 55.9 % | 95.0 % | 60.9 % |
| Limited Data Set | лише ML | 92.9 % | 84.5 % | 91.0 % |
| Limited Data Set | обидва (повний) | 92.9 % | 89.3 % | 92.1 % |
| Safe Harbor | лише regex | 58.9 % | 93.6 % | 63.6 % |
| Safe Harbor | лише ML | 82.4 % | 88.3 % | 83.5 % |
| Safe Harbor | обидва (повний) | 92.4 % | 88.9 % | 91.7 % |
Рядок «повний» фільтра Personal Data перевершує обидві однорівневі версії за всіма метриками — поєднання regex (для поверхневих форматів) з моделлю ML (для контексту) дійсно дає результат, який не під силу жодному рівню окремо. Показник 97.3%, згаданий раніше в цій публікації, відображає те, що отримує реальний користувач. Число в таблиці вище трохи нижче лише тому, що воно включає категорію URL, яку ми навмисно зберігаємо, щоб не ламати посилання та виклики інструментів.
Пряме порівняння з іншими спеціалізованими фільтрами приватності
Справедливим є порівняння нашого локального, майже миттєвого фільтра приватності з іншими локальними, майже миттєвими фільтрами — а не з гігантськими хмарними LLM, які витрачають секунди на повідомлення і потребують мережевого запиту. Ми протестували кожну систему цього класу на тих самих наборах тестів, використовуючи ті самі правила зіставлення. Однаковий стандарт для всіх.
Клас аналогів:
- openai/privacy-filter — спеціалізований фільтр приватності з відкритим кодом від OpenAI. Близько 50 мільйонів параметрів, достатньо малий для роботи в будь-якому сучасному браузері.
- piiranha-v1 — детектор на 278 млн параметрів від iiiorg. Його ліцензія обмежує використання лише дослідженнями та оцінкою (ми можемо його вимірювати, але він не може постачатися комерційно).
- Microsoft Presidio — найбільш розповсюджений інструмент редагування з відкритим кодом, що поєднує традиційне зіставлення шаблонів з невеликою мовною моделлю для контексту.
- Родина GLiNER PII — родина невеликих універсальних класифікаторів сутностей. Knowledgator постачає варіанти small (~44M), base (~86M) та large (~304M); NVIDIA випустила варіант на 570M у жовтні 2025 року.
- Caiioo у всіх трьох режимах (Personal Data, HIPAA Limited Data Set, HIPAA Safe Harbor).
Повнота (recall) у п'яти наборах тестів, відсортована з Caiioo на першому місці:
| Система | PrivacyBench PD-25 | Caiioo synthetic PD-200 | PrivacyBenchHIPAA-40 | Caiioo synthetic PHI-200 | Multilingual PD-40 (10 локалей) |
|---|---|---|---|---|---|
| Caiioo — Personal Data | 96.2 % (76/79) | 99.0 % (198/200) | — | — | 92.6 % (200/216) |
| Caiioo — HIPAA Limited Data Set | — | — | 100.0 % (79/79) | 100.0 % (200/200) | — |
| Caiioo — HIPAA Safe Harbor | — | — | 100.0 % (79/79) | 100.0 % (200/200) | — |
| openai/privacy-filter (50M) | 96.2 % (76/79) | 83.0 % (166/200) | 93.7 % (74/79) | 77.0 % (154/200) | 94.9 % (205/216) |
| gliner_pii_nvidia (570M) | 94.9 % (75/79) | 85.5 % (171/200) | 84.8 % (67/79) | 85.0 % (170/200) | 76.9 % (166/216) |
| gliner_pii_large (~304M) | 72.2 % (57/79) | 86.5 % (173/200) | 84.8 % (67/79) | 93.0 % (186/200) | 50.0 % (108/216) |
| gliner_pii_base (~86M) | 87.3 % (69/79) | 66.0 % (132/200) | 74.7 % (59/79) | 66.0 % (132/200) | 51.4 % (111/216) |
| gliner_pii_small (~44M) | 88.6 % (70/79) | 84.5 % (169/200) | 91.1 % (72/79) | 83.0 % (166/200) | 68.5 % (148/216) |
| Microsoft Presidio | 82.3 % (65/79) | 76.5 % (153/200) | 84.8 % (67/79) | 76.5 % (153/200) | 69.0 % (149/216) |
| piiranha-v1 (~278M) | 60.8 % (48/79) | 58.5 % (117/200) | 43.0 % (34/79) | 47.0 % (94/200) | 82.4 % (178/216) |
Caiioo лідирує в класі спеціалізованих фільтрів у двох найбільших тестах (PD-200 та PHI-200), ділить першість або лідирує в публічних бенчмарках і посідає друге місце в багатомовному тесті. У найменшому тесті (PrivacyBench PD-25, лише 25 запитань) Caiioo та openai/privacy-filter мають однаковий результат 96.2%. У багатомовному тесті openai/privacy-filter все ще лідирує з 94.9%, тоді як Caiioo має 92.6% — мова, де ми відстаємо найбільше, це китайська; в усіх інших ми на вершині або поруч із нею. Якщо багатомовне охоплення є критично важливим, openai/privacy-filter є розумною альтернативою. Для більшості інших робочих навантажень у цьому класі найкращим є Caiioo.
Результат HIPAA є головним досягненням. Обидва режими Caiioo HIPAA показали 100% повноту в кожному тесті HIPAA — кожне ім'я пацієнта, кожен номер медичної картки, кожна дата народження, кожен номер рахунку були виявлені. Другою найкращою системою є openai/privacy-filter з 93.7% на PrivacyBenchHIPAA — розрив у 6.3 пункти в бенчмарку, де кожен пропуск є реальним розголошенням даних.
Другий важливий показник: надмірне маскування — приховування даних, які насправді не були приватними. Надмірне маскування не шкодить приватності, але воно погіршує зручність використання. Якщо замаскувати занадто багато, логіка LLM погіршується, а якість відповіді знижується. Caiioo маскує зайве 1–24 рази в усіх наборах тестів. Presidio: 10–51. GLiNER від NVIDIA: 31–64 лише в тестах HIPAA. Точність (precision) має таке ж значення, як і повнота (recall), коли метою є отримання найкращої відповіді за мінімального розголошення.
А як щодо використання передової LLM як фільтра?
Вони можуть це робити — і за чистою повнотою вони виграють. Великі універсальні LLM (Llama 3.1 8B, Gemma 4, Qwen 3.5 9B тощо), що працюють у хмарі або локально, можуть набрати 95–100% у кожному тесті, включаючи багатомовні. Це реальний варіант для користувачів, яким потрібна максимальна повнота і які готові за це платити.
Проте існують суттєві недоліки:
- Це повільно. Секунди на повідомлення замість мілісекунд. Фільтр стоїть перед кожним повідомленням, яке надсилає користувач.
- Або повідомлення залишає пристрій користувача, або модель. Щоб фільтрувати в хмарі, повідомлення має потрапити туди — що суперечить самій меті. Для фільтрації на пристрої потрібно завантажити модель розміром 1–17 ГБ.
- Їх можна обдурити. Генеративну модель можна вмовити посеред повідомлення не виконувати маскування (атака «prompt injection»). Малий класифікатор, як наш, неможливо так обманути.
- Той самий вхід, різний вихід. Генеративні моделі не завжди дають однакову відповідь двічі. Це порушує цілісність процесу — маскування на виході та демаскування на вході покладається на те, що те саме реальне значення завжди відповідає тому самому фейковому.
Caiioo створений для іншої сторони цього компромісу: крихітний, передбачуваний, субсекундний фільтр, який працює в редакторі ще до того, як користувач натисне «надіслати», і який завжди створює те саме фейкове значення для того самого реального значення в межах розмови, щоб процес залишався узгодженим. Таблиця аналогів вище є порівнянням «яблук з яблуками» саме для такого сценарію використання.
Доказ у дії
Бенчмарки — це лише точка відліку, а не фінішна пряма. Фільтр інтегрований у нову функцію Caiioo: псевдонімізатор — компонент, який фактично знаходиться між редактором та моделлю.
Ось що відбувається, коли користувач натискає «надіслати».
- Виявлення. Спочатку запускається шар regex — він детермінований і працює зі швидкістю мікросекунд. Далі на залишках тексту працює модель ML. Якщо два шари перекриваються на одному фрагменті тексту, ми використовуємо просте правило: regex має пріоритет для поверхневих форматів, ML — для контексту.
- Тегування «себе» та «інших». Caiioo розділяє ідентифікатори, що стосуються користувача, та ідентифікатори, що стосуються інших людей. Користувач може вибрати анонімізацію лише одного типу або обох. Імена, які користувач додав до особистого словника, завжди вважаються «собою».
- Заміна. Кожне реальне значення отримує стабільний псевдонім, що відповідає стилю. «Sarah Goldberg» стає «Maya Hartwell» — і залишається «Maya Hartwell» протягом усієї розмови, щоб логічні висновки моделі щодо цієї особи не фрагментувалися між репліками. Таблиця відповідності реальних значень фейковим зберігається на пристрої користувача, зашифрована ключем із системної зв'язки ключів (keychain).
- Надсилання. Модель отримує повністю фейкове повідомлення. Жоден реальний ідентифікатор ніколи не передається через мережу, а наш журнал аудиту фіксує лише кількість — ніколи не самі значення.
- Відновлення. Потокова відповідь відображається назад у міру надходження. «Maya Hartwell» у відповіді моделі стає «Sarah Goldberg» ще до того, як потрапить на екран, і відображається з невеликим підсвічуванням, щоб користувач міг з першого погляду побачити, що саме було захищено.
- Відновлення аргументів інструментів. Якщо модель викликає інструмент — надіслати email, створити тікет, записати в документ — і аргументи містять фейкові дані, ми підставляємо реальні значення перед запуском інструмента. Модель оперує фейками; дія виконується з реальним значенням.
Фільтру байдуже, який сервіс AI використовується. Він працює до того, як повідомлення досягне моделі, тому OpenRouter, Anthropic, Google, OpenAI та локальна Ollama отримують однакове масковане корисне навантаження. Додавання нового провайдера не створює нових вразливостей для приватності.
Кого він захищає
Користувача. Ім'я користувача, електронна пошта, адреса, телефон, IP та біометричні ідентифікатори — речі, які разом ідентифікують особу для агрегатора — ніколи не залишають пристрій, коли фільтр увімкнено.
Людей, про яких говорить користувач. Більшість інструментів конфіденційності зосереджені на людині, яка друкує, але вони ігнорують «суспільний договір» — той факт, що ми несемо відповідальність як перед іншими, так і перед собою. Надсилання запиту «Будь ласка, проаналізуйте поведінку містера Сондерса на предмет некомпетентності» до LLM, де це може бути назавжди записано в системні журнали, є безвідповідальним (і потенційно наклепницьким). Запит до LLM про допомогу з Google Workspace таблицею, що містить 1000 бізнес-контактів, залишає їх усіх у «пастці» зберігання даних. Фільтр Caiioo також охоплює третіх осіб: клієнта, для якого складається контракт, пацієнта, чия медична карта аналізується, колегу, чий лист було вставлено в контекст. Вони не давали згоди на те, щоб віддалена LLM бачила їхні ідентифікатори. Фільтр поважає це за замовчуванням; користувач може переключитися на режими «тільки я» або «тільки інші», якщо цього вимагає робочий процес.
Організації — бізнес, лікарні, фірми. Номери рахунків, номери ліцензій, номери медичних карток, фінансові реквізити, внутрішні ідентифікатори, ключі API, списки клієнтів. Бізнес має такий самий інтерес у мінімізації даних, як і приватна особа. Клініцист, який використовує Caiioo для підготовки виписки, не відправляє номер медичної карти пацієнта в OpenAI. Юрист не відправляє номер рахунку клієнта в Anthropic. Інженер підтримки не відправляє API-ключ із логів клієнта в Google. Фільтр не запитує, кому належить ідентифікатор — людині чи організації — він просто залишає його на пристрої.
Максимальна корисність, мінімальний ризик
Головна ідея в тому, що користувач не повинен відчувати роботу фільтра.
Більшість інструментів конфіденційності змушують обирати: агресивно анонімізувати та спостерігати, як відповідь моделі погіршується, або зберегти корисність промпту та бачити, як обіцянка конфіденційності тане. Ми відмовилися від цього компромісу. Модель все одно отримує повноцінний промпт — вона бачить ім'я, місце, дату, номер медичної карти, і все це у правильних граматичних формах. Вона просто бачить вигадані дані. Її логіка залишається ідентичною; очищаються лише рядки.
Стабільна заміна — ось що робить це можливим. Оскільки одне й те саме реальне значення завжди відображається як одне й те саме вигадане в межах розмови — у повідомленні користувача, у результаті роботи інструменту, що посилається на це ім'я, у попередній відповіді моделі — модель має цілісну особу, місце чи об'єкт для аналізу. Багатокрокові діалоги не плутаються. Виклики інструментів не ламаються. Субагенти успадковують карту розмови батьківського процесу та залишаються послідовними протягом усього завдання.
Результат, який бачить користувач, — це реальна розмова. Дані, які бачить провайдер, — це цілісна вигадка. Робота відбувається в розриві між цими двома представленнями, і мета — єдина мета — зробити цей розрив непомітним.
Фільтр конфіденційності, який заважає, буде вимкнено. Фільтр конфіденційності, який непомітно вбудовується в робочий процес, — це єдиний вид, який варто випускати.
Це та планка, яку ми встановили.