Данный документ является машинным переводом оригинальной английской версии. В случае любых расхождений между переводом и оригиналом на английском языке, приоритет имеет английская версия. Читать оригинал на английском языке
Локальный псевдонимизатор: разработка и тестирование производительности
2026-05-22 · Caiioo Team
Мы хотели решить проблему конфиденциальности в системах ИИ, которые обучаются на реальных персональных данных и сохраняют их. Политики «Zero Data Retention» снижают риски, но они полны исключений. По сути, они гласят: «Мы не будем хранить ваши промпты или результаты, за исключением: (далее следует огромный список исключений: цели безопасности, правительственный надзор, судебные разбирательства, разработка продуктов, журналы ошибок, улучшение сервисов...)»
Чтобы решить эту проблему, мы создали фильтр персональных данных, который работает на собственной машине пользователя, видит сообщение до того, как оно покинет устройство, и возвращает тот же ответ, который пользователь получил бы, если бы сообщение было набрано без фильтра вовсе.
И мы его создали. Следующая версия Caiioo будет включать Псевдонимизатор. Он доступен через иконку щита в чате агента, а также в настройках.
В этом техническом документе изложены обоснование, архитектура, процесс оценки и принципы проектирования нашей системы фильтрации конфиденциальности.
К чему мы стремимся
Общая защита конфиденциальности путем минимизации данных. Когда пользователь общается с удаленной моделью, ей не нужны настоящее имя, домашний адрес, реальный адрес электронной почты или номер телефона клиента, чтобы ответить на вопрос. Ей нужна лишь суть вопроса, и он должен выглядеть как настоящий запрос, чтобы LLM не отклонила его как тестовый. Поэтому фильтр удаляет реальные идентификаторы из данных, отправляемых ИИ, и подставляет реальные значения обратно при получении ответа. Модель видит синтетические имена и идентификаторы; пользователь видит реальный диалог.
Помощь в соблюдении требований HIPAA. Второй режим ориентирован на 18 идентификаторов, указанных в правиле HIPAA Safe Harbor (§164.514), и на более гибкий вариант Limited Data Set. Клиницист, администратор здравоохранения или любой сотрудник, работающий с защищенными рабочими процессами, может обсуждать реальные случаи с моделью общего назначения, не отправляя защищенную медицинскую информацию (PHI) в ИИ. Мы не являемся сотрудниками по комплаенсу для подконтрольной организации, но мы можем стать тем слоем, который предотвращает утечку 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 % |
Один только regex пропускает три четверти идентификаторов, потому что большинство идентификаторов в реальной прозе не структурированы. Один только ML пропускает 16 процентных пунктов, которые уловил бы уровень regex — вещи, которые определяются исключительно своей формой (кредитная карта выглядит как кредитная карта; у модели нет дополнительного сигнала, который можно было бы добавить). Вместе они охватывают то, что ни один из них не может охватить в одиночку.
Если взглянуть глубже на то, где каждый уровень является решающим: в том же наборе данных 16 тестовых значений были пойманы только с помощью regex (электронные письма, IP-адреса, финансовые счета, структурированные ID) и 327 были пойманы только с помощью ML (имена, контекстуальные идентификаторы, мультиязычные фразы).
Маленький, умный, быстрый — и работает везде
Нам нужно было заставить фильтр работать на устройстве, что стало серьезным инженерным вызовом.
Он должен быть маленьким, потому что наше приложение работает локально на многих системах: внутри расширения браузера, в приложениях для macOS, iOS, Android, а также Windows и Linux. Пакет весит около 113 МБ на модель. Моделей две — одна для общих персональных данных, другая для защищенной медицинской информации — и режим Safe Harbor запускает обе параллельно. Среди них бюджетное Android-устройство является наименее производительным, но наша система работает отлично.
Он должен быть умным, потому что пропуски (false negatives) приводят к утечке реальных данных в удаленную LLM, а ложные срабатывания (false positives) портят диалог. Имена должны быть скрыты, а местоимения — нет. Электронная почта врача в пересланном треде должна быть скрыта, а футер [email protected], вероятно, нет.
Он должен быть быстрым, потому что он стоит на пути каждого сообщения, которое пользователь отправляет или получает. Мы измерили накладные расходы на цикл обработки — менее 200 мс на одном потоке процессора, в основном это токенизация. На WebGPU и на Apple Neural Engine это время ничтожно по сравнению с сетевой задержкой самого вызова LLM.
Он должен работать в нескольких средах, потому что Caiioo мультиплатформенная. Одна и та же система работает в расширениях Chrome, macOS и iOS, Android, а также на Windows и Linux. Одна модель обнаружения, одна библиотека регулярных выражений, один модуль слияния, одна политика — идентичное поведение на каждой поверхности, где работает 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:
Сводка по всем трем режимам фильтрации
| Режим | Комбинированная полнота (recall) | Точность (precision) | F2 | Образцы |
|---|---|---|---|---|
| Personal Data filter | 97.3 % | 97.8 % | 97.4 | 200 |
| HIPAA filter — Limited Data Set | 92.3 % | 92.3 % | 92.3 | 200 |
| HIPAA filter — Safe Harbor | 91.9 % | 91.5 % | 91.8 | 200 |
Эти цифры исключают URL, которые мы намеренно оставляем нетронутыми — удаление URL нарушило бы последующие действия, такие как «открыть эту ссылку» или «получить содержимое страницы». Подробнее об этом в разделе о рабочем процессе ниже.
Общая картина перед таблицами по категориям: в каждом режиме идентификаторы, которые действительно позволяют установить личность человека, улавливаются в 100% случаев или близко к этому. Имена, электронная почта, номера телефонов, почтовые адреса, государственные удостоверения личности, биометрические данные, точная геолокация, номера медицинских карт, даты рождения, номера социального страхования — обнаруживаются в каждом образце, в каждом тесте. Категории, где мы опускаемся ниже 100%, предсказуемы: идентификаторы устройств (огромное разнообразие форматов в реальном тексте), прочие институциональные ID (номера карт лояльности, ID сотрудников — та же проблема) и фотографии (текстовый фильтр не видит, что внутри изображения). Ни один из них не является критически важным идентификатором вроде «имени в карте» или «email в черновике», которые действительно важны при утечке. Категории с высокими ставками — самые надежные.
Personal Data filter
Отсортировано по комбинированной полноте (сначала лучшие), затем по уровню риска (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, государственные ID, биометрические ID и точная геолокация показывают 100% только при использовании regex — это поверхностные форматы, которые ML-модель получает «бесплатно». Ники (online handles), ID транспортных средств и секреты аутентификации дают смешанный результат: regex ловит стандартные формы, ML — всё остальное. Комбинированная полнота соответствует или превосходит показатели любого из слоев в каждой категории.
Идентификаторы устройств и прочие институциональные ID — это категории с результатом ниже 100%, и мы знаем почему: у них самое широкое разнообразие форматов в реальном тексте. Мы предпочитаем быть честными в отношении категорий, где полнота снижается, чем притворяться, что фильтр идеален во всем.
HIPAA filter — субрежим 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 filter — субрежим 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 family — семейство небольших классификаторов сущностей общего назначения. 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 ГБ.
- Её можно обмануть. Генеративную модель можно в середине сообщения убедить не выполнять редактирование (атака типа «инъекция промпта»). Маленький классификатор, такой как наш, обмануть нельзя.
- Один и тот же вход, разный выход. Генеративные модели не всегда дают один и тот же ответ дважды. Это нарушает цикл обработки — маскировка на выходе и демаскировка на обратном пути опираются на то, что одно и то же реальное значение всегда сопоставляется с одним и тем же поддельным.
Caiioo создан для другой стороны этого компромисса: крошечный, предсказуемый, субсекундный фильтр, который запускается в редакторе до того, как пользователь нажмет «отправить», и который всегда создает одно и то же поддельное значение для одного и того же реального значения в рамках диалога, чтобы цикл обработки оставался согласованным. Таблица сравнения с аналогами выше — это сравнение «яблок с яблоками» именно для такого сценария использования.
The proof is in the pudding
Бенчмарки — это лишь отправная точка, а не финишная черта. Фильтр встроен в новую функцию Caiioo: псевдонимизатор — компонент, который фактически находится между редактором и моделью.
Вот что происходит, когда пользователь нажимает кнопку отправки.
- Detect. Сначала запускается слой регулярных выражений (regex) — он детерминирован и работает со скоростью микросекунд. Затем на оставшемся тексте запускается модель ML. Если два слоя пересекаются на одном и том же фрагменте текста, мы используем простое правило: regex имеет приоритет для поверхностных форматов, ML — для контекста.
- Tag self vs. other. Caiioo разделяет идентификаторы, относящиеся к пользователю, и идентификаторы, относящиеся к другим людям. Пользователь может выбрать: скрыть только один тип или оба. Имена, которые пользователь добавил в личный словарь, всегда считаются «своими» (self).
- Substitute. Каждое реальное значение получает стабильный, соответствующий стилю псевдоним. «Sarah Goldberg» превращается в «Maya Hartwell» — и остается «Maya Hartwell» на протяжении всего диалога, чтобы логика модели в отношении этого человека не фрагментировалась между репликами. Таблица соответствия реальных данных поддельным хранится на устройстве пользователя, зашифрованная ключом из системной связки ключей (keychain).
- Send. Модель получает полностью поддельное сообщение. Ни один реальный идентификатор никогда не передается по сети, а наш журнал аудита фиксирует только количество замен — и никогда сами значения.
- Restore. Потоковый ответ сопоставляется обратно по мере поступления. «Maya Hartwell» в ответе модели превращается в «Sarah Goldberg» до того, как попадет на экран, и отображается с небольшой подсвеченной меткой, чтобы пользователь мог сразу увидеть, что именно было защищено.
- Restore tool arguments too. Если модель вызывает инструмент — отправить email, создать тикет, записать в документ — и аргументы содержат поддельные данные, мы подставляем реальные значения перед запуском инструмента. Модель рассуждает, используя подделки; действие выполняется с реальным значением.
Фильтру неважно, какой сервис AI используется. Он запускается до того, как сообщение достигнет модели, поэтому OpenRouter, Anthropic, Google, OpenAI и локальный Ollama получают один и тот же замаскированный контент. Добавление нового провайдера не создает новых уязвимостей в приватности.
Кого это защищает
Пользователя. Имя пользователя, электронная почта, адрес, телефон, IP и биометрические идентификаторы — вещи, которые в совокупности позволяют агрегатору идентифицировать личность, — никогда не покидают устройство, когда фильтр включен.
Людей, о которых говорит пользователь. Большинство инструментов конфиденциальности фокусируются на том, кто печатает, но игнорируют «общественный договор» — тот факт, что мы несем ответственность перед другими так же, как и перед собой. Отправка запроса «Пожалуйста, проанализируйте поведение мистера Сондерса на предмет некомпетентности» в LLM, где это может быть записано в системных логах на неопределенный срок, безответственна (и потенциально клеветнична). Просьба к LLM помочь с таблицей Google Sheet, содержащей 1000 деловых контактов, помещает их все в «липкую ленту» хранения данных. Фильтр Caiioo также распространяется на третьих лиц: клиента, для которого составляется контракт, пациента, чья карта анализируется, коллегу, чье письмо было вставлено в контекст. Они не давали согласия на то, чтобы удаленная LLM видела их идентификаторы. Фильтр уважает это по умолчанию; пользователь может переключиться на режимы «только я» или «только другие», если того требует рабочий процесс.
Организации — предприятия, больницы, фирмы. Номера счетов, номера лицензий, номера медицинских карт, финансовые реквизиты, внутренние идентификаторы, API-ключи, списки клиентов. У бизнеса такой же интерес к минимизации данных, как и у человека. Клиницист, использующий Caiioo для составления выписного эпикриза, не отправляет номер медицинской карты пациента в OpenAI. Юрист не отправляет номер счета клиента в Anthropic. Инженер службы поддержки не отправляет API-ключ из лога клиента в Google. Фильтр не спрашивает, принадлежит ли идентификатор человеку или организации — он просто оставляет его на устройстве.
Максимальная полезность, минимальное воздействие
Весь смысл в том, что пользователь не должен чувствовать работу фильтра.
Большинство инструментов конфиденциальности заставляют выбирать: агрессивно скрывать данные и наблюдать, как ответы модели становятся хуже, или сохранять полезность промпта и видеть, как рушатся обещания конфиденциальности. Мы отвергли этот компромисс. Модель по-прежнему получает полноценный промпт — она видит имя, место, дату, номер медицинской карты, и все это в правильных грамматических позициях. Просто она видит вымышленные данные. Её логика остается прежней; очищаются только строки.
Стабильная подстановка — вот что заставляет это работать. Поскольку одно и то же реальное значение всегда сопоставляется с одним и тем же вымышленным в рамках разговора — в сообщении пользователя, в результате работы инструмента, ссылающемся на это имя, в более раннем ответе модели — у модели есть целостный персонаж, место или объект для рассуждений. Многоэтапные диалоги не путаются. Вызовы инструментов не ломаются. Субагенты наследуют карту родительского диалога и остаются последовательными на протяжении всей задачи.
Результат, который видит пользователь, — это реальный разговор. Данные, которые видит провайдер, — это связный вымысел. Работа происходит в разрыве между этими двумя представлениями, и цель — единственная цель — сделать этот разрыв невидимым.
Фильтр конфиденциальности, который мешает работе, будет отключен. Фильтр конфиденциальности, который незаметно встраивается в рабочий процесс, — единственный, который стоит выпускать.
Это та планка, которую мы себе установили.