본 문서는 영어 원본을 기계 번역한 것입니다. 번역본과 영어 원본 사이에 내용이 상충할 경우 영어 원본이 우선합니다. 영어 원본 보기
온디바이스 가명화 도구: 개발 및 벤치마크 완료
2026-05-22 · Caiioo Team
우리는 AI 시스템이 실제 개인 식별 정보를 학습하고 보유하는 개인정보 문제를 해결하고자 했습니다. "데이터 제로 보유(Zero Data Retention)" 정책과 계약은 위험을 줄여주지만, 수많은 예외 조항이 존재합니다. 이는 본질적으로 다음과 같이 말하는 것과 같습니다. "보안 목적, 정부 감시, 소송 보존, 제품 개발, 오류 로그, 서비스 개선 등 대규모 예외 목록을 제외하고는 귀하의 프롬프트나 출력을 저장하지 않습니다."
이를 해결하기 위해 사용자의 기기에서 실행되며, 메시지가 기기를 떠나기 _전_에 이를 확인하고, 필터 없이 입력했을 때와 동일한 답변을 반환하는 개인 데이터 필터를 구축했습니다.
그 결과물이 탄생했습니다. Caiioo의 다음 버전에는 가명화 도구가 포함될 예정입니다. 에이전트 채팅의 방패 아이콘과 설정을 통해 접근할 수 있습니다.
이 백서는 당사 개인정보 필터링 시스템의 근거, 아키텍처, 평가 프로세스 및 설계 원칙을 설명합니다.
우리의 목표
데이터 최소화를 통한 일반적인 개인정보 보호. 사용자가 원격 모델과 대화할 때, 모델은 사용자의 질문에 답하기 위해 실명, 집 주소, 실제 이메일 또는 고객의 전화번호를 필요로 하지 않습니다. 모델에 필요한 것은 질문의 _형태_이며, LLM이 해당 쿼리를 테스트로 간주하여 무시하지 않도록 실제 질문처럼 보여야 합니다. 따라서 필터는 AI로 전송되는 데이터에서 실제 식별자를 제거하고, 돌아오는 길에 실제 값을 다시 결합합니다. 모델은 합성된 이름과 식별자를 보게 되며, 사용자는 실제 대화 내용을 보게 됩니다.
HIPAA 준수 지원. 두 번째 모드는 HIPAA Safe Harbor 규칙(§164.514)의 18가지 식별자와 더 완화된 Limited Data Set 변형을 대상으로 합니다. 임상의, 의료 행정가 또는 대상 워크플로에서 작업하는 모든 사람은 보호 대상 건강 정보(PHI)를 AI에 전송하지 않고도 실제 사례에 대해 범용 모델과 대화할 수 있습니다. 당사는 대상 기관의 준수 책임자(compliance officer)는 아니지만, PHI가 노트북 밖으로 나가지 않도록 차단하는 계층이 될 수 있습니다. 당사의 평가는 조직이 자신의 준수 및 개인정보 보호 표준에 대한 필터의 적합성을 평가하는 데 사용할 수 있는 측정 가능한 벤치마크를 제공합니다. 모든 개인정보 보호 및 보안 조치는 사용자 또는 사용자 엔티티의 책임하에 이루어지는 판단 사항입니다.
우리는 두 가지 방식을 모두 선택했습니다. 그 이유는 엔지니어링 측면에서 동일하며, PHI 사용 사례가 기술적으로는 실제로 더 쉽기 때문입니다. PHI는 고유한 명명된 엔티티를 사용하므로 Personal Data 카테고리의 일반적인 데이터보다 수정(redact)하기가 더 쉽습니다. 또한 HIPAA 필터링은 일반적으로 영어 또는 스페인어로 이루어진다는 점도 도움이 됩니다. 당사는 식별자를 탐지하고, 동일한 형식의 안정적인 가명 및 대체 식별자로 교체하며, 돌아오는 길에 이를 복원하고, 실제 값은 절대 기록하지 않습니다. 합성 정보와 실제 정보 사이의 매핑은 사용자의 기기에만 유지되므로, 사용자는 에이전트의 응답에서 실제 정보를 읽을 수 있습니다. 모드에 따라 변경되는 것은 카테고리 목록과 정책 게이트뿐입니다.
왜 정규표현식(regex)과 머신러닝을 함께 사용하며, 하나만 사용하지 않는가
저희의 가명화 도구에는 두 가지 주요 필터 기술이 있습니다. 바로 정규표현식(regex)이라 불리는 결정론적 패턴 인식 언어와 훈련된 머신러닝 모델입니다.
정규표현식은 **표면적인 형식(surface formats)**을 파악하는 데 있어 타의 추종을 불허합니다. 이메일 주소는 특정 형태([email protected])를 가집니다. IP, 신용카드, IBAN, VIN, SSN(XXX-XX-XXXX), API 키도 마찬가지입니다. 형식이 신뢰할 수 있다면, 정규표현식은 모델 로드나 추론 비용 없이 매번 결정론적으로 이를 포착합니다.
하지만 정규표현식은 문맥(context) 파악에는 속수무책입니다. "Sarah's chart from last Tuesday(지난 화요일 Sarah의 차트)"에는 인물과 날짜가 포함되어 있지만, 어느 것도 형식만으로는 구분할 수 없습니다. "The patient at 14 Elm(14 Elm에 거주하는 환자)"에는 수천 개의 주소가 아닌 것들과 겹치는 주소가 포함되어 있습니다. "Their MRN is 7741032(그들의 MRN은 7741032입니다)"라는 문장은 숫자 주변의 단어들이 있어야만 의미를 가집니다.
미세 조정된 소형 언어 모델은 문맥을 처리합니다. 저희 모델은 다국어 소형 언어 모델에서 증류(distilled)하여 특별히 훈련된 1억 1천만 개의 파라미터를 가진 인코더입니다. 이 모델은 하위 문자열이 아닌 문장 전체를 읽으며, 모바일 기기에서도 매우 빠르게 실행될 수 있을 만큼 작습니다.
벤치마크는 두 레이어의 상호 보완적인 강점을 잘 보여줍니다. 저희는 각 레이어가 실제로 제 역할을 하고 있는지 확인하기 위해 두 레이어를 개별적으로 벤치마킹했습니다. 모델 훈련에 명시적으로 사용되지 않은 질문과 답변으로 구성된 150개 문항의 PrivacyBench-PD 데이터 세트 결과는 다음과 같습니다.
| 레이어 | 포착된 PII 수 | 포착률 |
|---|---|---|
| 정규표현식 전용 | 205 / 670 | 30.6 % |
| ML 전용 | 516 / 670 | 77.0 % |
| 모두 사용 (운영) | 625 / 670 | 93.3 % |
정규표현식만 사용하면 식별자의 4분의 3을 놓치게 되는데, 이는 실제 산문 속 대부분의 식별자가 구조화되어 있지 않기 때문입니다. ML만 사용하면 정규표현식 레이어가 잡았을 식별자들을 16%포인트만큼 놓치게 됩니다. 이는 순수하게 형태만으로 판단되는 것들(신용카드는 신용카드처럼 보이며, 모델이 추가할 별도의 신호가 없음)입니다. 두 기술이 결합함으로써 어느 하나가 단독으로 해결하지 못하는 영역을 보완합니다.
각 레이어가 결정적인 역할을 하는 부분을 더 자세히 살펴보면, 동일한 데이터 세트에서 16개의 테스트 값은 정규표현식에 의해서만 포착되었고(이메일, IP, 금융 계좌, 구조화된 ID), 327개는 ML에 의해서만 포착되었습니다(이름, 문맥적 식별자, 다국어 표현).
작고, 똑똑하고, 빠르며 — 어디서나 실행됩니다
필터를 온디바이스에서 실행되게 만드는 것은 엔지니어링 측면의 도전이었습니다.
브라우저 확장 프로그램, macOS 앱, iOS 앱, Android 앱, Windows 및 Linux 등 다양한 시스템의 기기에서 실행되어야 하므로 작아야 합니다. 번들 크기는 모델당 약 113 MB입니다. 일반 개인 데이터용과 보호 대상 건강 정보용의 두 가지 모델이 있으며, 세이프 하버 모드는 두 모델을 병렬로 실행합니다. 이 중 저사양 Android 기기의 성능이 가장 낮지만, 우리 시스템은 문제없이 작동합니다.
탐지 실패(False Negative)는 실제 데이터를 원격 LLM으로 유출하고, 과잉 탐지(False Positive)는 대화를 망치기 때문에 똑똑해야 합니다. 이름은 가려져야 하지만 대명사는 가려지면 안 됩니다. 전달된 스레드에 포함된 의사의 이메일은 가려져야 하지만, [email protected]와 같은 푸터 정보는 가릴 필요가 없을 것입니다.
사용자가 보내거나 받는 모든 메시지의 경로에 직접 위치하므로 빨라야 합니다. 단일 CPU 스레드에서 왕복 오버헤드를 200ms 미만으로 측정했으며, 대부분은 토큰화 과정입니다. WebGPU나 Apple의 Neural Engine에서는 LLM 호출 자체의 네트워크 지연 시간에 비해 매우 미미한 수준입니다.
Caiioo는 멀티 플랫폼이므로 다양한 런타임에서 실행되어야 합니다. Chrome 확장 프로그램, macOS, iOS, Android, Windows, Linux에서 동일한 시스템이 작동합니다. 하나의 탐지 모델, 하나의 정규표현식 라이브러리, 하나의 병합기, 하나의 정책을 통해 Caiioo가 실행되는 모든 환경에서 동일한 동작을 보장합니다.
점수 결과
수차례의 테스트와 학습을 거쳐, 당사는 모델의 16번째 버전을 최종 확정했습니다. 아래는 각각 서로 다른 측면을 측정하는 세 가지 벤치마크 결과입니다.
자체 테스트 세트: 모델이 접한 적 없는 150개의 질문
공개 벤치마크로 테스트하기 전, 당사는 학습 데이터에서 의도적으로 제외하여 탐지기가 이전에 한 번도 본 적 없는 내부 테스트 세트를 대상으로 Personal Data 필터를 실행했습니다. 150개의 질문은 네 개의 그룹(코드 스니펫, 문서 산문, 의도적으로 생소하게 표현된 문구, 10개 국어의 비영어권 언어)으로 나뉘어 있으며, 여기에 개인 데이터가 전혀 포함되지 않은 "네거티브(negative)" 그룹을 추가하여 과도한 비식별화가 발생하지 않는지 확인하는 무결성 검사(sanity check)를 진행했습니다. 결합된 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개의 의료 관련 질문
각 질문에는 비식별화되어야 하는 보호 대상 건강 정보(PHI, 이름, 의료 기록 번호 등)와 유지되어야 하는 신호(날짜, 지리 정보, 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 필터 | 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을 그대로 둡니다. URL을 훼손하면 "이 링크 열기" 또는 "해당 페이지 가져오기"와 같은 후속 작업이 불가능해지기 때문입니다. 이에 대한 자세한 내용은 아래의 워크플로우 섹션에서 다룹니다.
카테고리별 상세 표 이전의 전체적인 개요: 모든 모드에서 실제로 개인을 식별하는 식별자들은 100%에 가깝게 포착됩니다. 이름, 이메일, 전화번호, 우편 주소, 정부 발행 ID, 생체 인식 ID, 정밀 지리 위치, 의료 기록 번호, 생년월일, 사회보장번호 등은 모든 샘플과 테스트에서 포착되었습니다. 100% 미만으로 떨어지는 카테고리들은 예측 가능한 범위 내에 있습니다. 기기 ID(실제 텍스트에서 형식이 매우 다양함), 기타 기관 ID(멤버십 번호, 사번 등 — 동일한 문제), 그리고 사진(텍스트 전용 필터는 이미지 내부를 볼 수 없음) 등입니다. 이 중 어느 것도 실제 유출 시 문제가 되는 "차트상의 이름"이나 "초안의 이메일"과 같은 핵심 식별자는 아닙니다. 위험도가 높은 카테고리들은 신뢰할 수 있는 수준으로 관리되고 있습니다.
Personal Data 필터
결합 재현율(높은 순) 및 위험 등급(T1 = 가장 민감함) 순으로 정렬되었습니다.
| 카테고리 | 등급 | Regex 재현율 | ML 재현율 (원시) | 결합 재현율 | 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 |
표를 살펴보면 2계층 설계의 효과가 입증되고 있습니다. 우편 주소, 생년월일, 인명은 regex 단독으로는 0~13%의 점수를 기록했습니다. 일치시킬 정형화된 패턴이 없기 때문에 오직 ML 모델만이 이를 포착할 수 있습니다. 반면 이메일, 전화번호, IP, 정부 ID, 생체 ID, 정밀 지리 위치는 regex 단독으로 100%를 기록했습니다. 이는 ML 모델이 별도의 노력 없이도 얻을 수 있는 표면적 형식들입니다. 온라인 핸들, 차량 ID, 인증 비밀번호는 혼합된 양상을 보입니다. regex는 표준 형식을 잡고, ML은 나머지를 잡습니다. 모든 카테고리에서 결합 재현율은 단일 계층 중 더 강력한 쪽의 성능과 일치하거나 이를 능가합니다.
기기 ID와 기타 기관 ID는 100% 미만인 카테고리이며, 그 이유는 명확합니다. 실제 텍스트에서 형식이 가장 다양하기 때문입니다. 당사는 필터가 모든 곳에서 완벽한 척하기보다는 재현율이 떨어지는 카테고리에 대해 솔직하게 밝히고자 합니다.
HIPAA 필터 — Limited Data Set 하위 모드
Limited Data Set 하위 모드는 설계상 날짜, 지리 정보, 89세 이하의 연령을 보존합니다. 이는 HIPAA가 정당한 임상 연구 및 운영을 위해 조직이 보유할 수 있도록 허용하는 신호들입니다.
| 카테고리 | 등급 | Regex 재현율 | ML 재현율 (원시) | 결합 재현율 | 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 재현율 (원시) | 결합 재현율 | 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%)입니다. 당사는 Safe Harbor에서 이 두 항목을 의도적으로 regex가 처리하도록 했습니다. 날짜는 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의 오픈 소스 전용 프라이버시 필터. 약 5,000만 개의 파라미터로, 현대적인 브라우저 어디에서나 실행될 수 있을 만큼 작습니다.
- piiranha-v1 — iiiorg의 2억 7,800만 파라미터 탐지기. 라이선스상 연구 및 평가용으로만 제한됩니다(측정은 가능하나 상업적 출시는 불가).
- Microsoft Presidio — 가장 널리 배포된 오픈 소스 비식별화 도구로, 전통적인 패턴 매칭과 문맥 파악을 위한 소형 언어 모델을 결합합니다.
- GLiNER PII 제품군 — 소형 범용 엔티티 분류기 제품군. Knowledgator는 small(~44M), base(~86M), large(~304M) 변체를 제공하며, NVIDIA는 2025년 10월에 570M 변체를 출시했습니다.
- Caiioo (Personal Data, HIPAA Limited Data Set, HIPAA Safe Harbor의 세 가지 모드 모두).
5개 테스트 세트 전체의 재현율(Caiioo 우선 정렬):
| 시스템 | PrivacyBench PD-25 | Caiioo 합성 PD-200 | PrivacyBenchHIPAA-40 | Caiioo 합성 PHI-200 | 다국어 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)에서 전용 필터 클래스를 선도하고 있으며, 공개 벤치마크에서도 동등하거나 앞선 성적을 거두었고, 다국어 부문에서는 2위를 기록했습니다. 가장 작은 테스트(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 모드 모두 모든 HIPAA 테스트에서 100% 재현율을 달성했습니다. 모든 환자 이름, 모든 의료 기록 번호, 모든 생년월일, 모든 계좌 번호를 포착했습니다. 두 번째로 우수한 시스템은 PrivacyBenchHIPAA에서 93.7%를 기록한 openai/privacy-filter로, 6.3포인트의 격차가 발생했습니다. 모든 누락이 실제 데이터 노출로 이어지는 벤치마크에서 이는 큰 차이입니다.
주목할 만한 두 번째 수치는 과잉 비식별화(over-redaction), 즉 실제 개인 데이터가 아닌 항목을 마스킹하는 경우입니다. 과잉 비식별화는 프라이버시 침해는 아니지만 사용성 저하를 초래합니다. 너무 많은 항목을 마스킹하면 LLM의 추론 능력이 떨어지고 답변의 질이 저하됩니다. Caiioo는 테스트 세트 전체에서 불필요한 마스킹을 124회 수행했습니다. Presidio는 1051회, NVIDIA의 GLiNER는 HIPAA 테스트에서만 31~64회를 기록했습니다. 노출을 최소화하면서 최선의 답변을 얻는 것이 목표일 때, 정밀도는 재현율만큼이나 중요합니다.
최신 LLM을 필터로 사용하는 것은 어떨까요?
가능합니다. 그리고 순수 재현율 면에서는 그들이 승리합니다. 클라우드나 로컬에서 실행되는 대형 범용 LLM(Llama 3.1 8B, Gemma 4, Qwen 3.5 9B 등)은 다국어를 포함한 모든 테스트에서 95~100%의 점수를 기록할 수 있습니다. 이는 최대의 재현율이 필요하고 그에 따른 비용을 지불할 의사가 있는 사용자에게는 실제적인 선택지입니다.
하지만 다음과 같은 실질적인 단점이 있습니다.
- 느립니다. 메시지당 밀리초 단위가 아닌 수 초가 걸립니다. 필터는 사용자가 보내는 모든 메시지의 맨 앞에 위치합니다.
- 메시지가 사용자의 기기를 떠나거나, 모델이 기기로 들어와야 합니다. 클라우드에서 필터링하려면 메시지가 외부로 전송되어야 하므로 본래의 목적에 어긋납니다. 온디바이스에서 필터링하려면 1~17GB에 달하는 모델을 다운로드해야 합니다.
- 속임수에 취약합니다. 생성형 모델은 메시지 중간에 비식별화를 하지 않도록 설득당할 수 있습니다("프롬프트 인젝션" 공격). 당사와 같은 소형 분류기는 그렇지 않습니다.
- 동일 입력, 다른 출력. 생성형 모델은 항상 같은 답변을 내놓지 않습니다. 이는 왕복 과정을 방해합니다. 나갈 때 마스킹하고 돌아올 때 마스킹을 해제하는 과정은 동일한 실제 값이 항상 동일한 가짜 값으로 매핑되는 것에 의존하기 때문입니다.
Caiioo는 이러한 트레이드오프의 반대편을 위해 구축되었습니다. 사용자가 전송 버튼을 누르기 전 작성기 내에서 실행되는 아주 작고 예측 가능하며 1초 미만으로 작동하는 필터입니다. 또한 대화 내에서 동일한 실제 값에 대해 항상 동일한 가짜 값을 생성하므로 왕복 과정의 일관성이 유지됩니다. 위의 동급 클래스 비교 표는 이러한 사용 사례에 대한 적절한 비교 자료입니다.
백문이 불여일견 (The proof is in the pudding)
벤치마크는 시작점일 뿐, 결승선이 아닙니다. 이 필터는 Caiioo의 새로운 기능인 pseudonymizer에 내장되어 있습니다. 이 컴포넌트는 작성기(composer)와 모델 사이에서 실제로 작동합니다.
사용자가 전송 버튼을 눌렀을 때 일어나는 과정은 다음과 같습니다.
- 탐지 (Detect). 정규식(regex) 레이어가 먼저 실행됩니다. 이는 결정론적이며 마이크로초 단위로 빠릅니다. 그다음 남은 텍스트에 대해 ML 모델이 실행됩니다. 두 레이어가 동일한 텍스트 조각에서 겹치는 경우, 단순한 규칙을 적용합니다. 표면적인 형식은 정규식이 우선하며, 문맥은 ML이 우선합니다.
- 본인 vs 타인 태그 지정 (Tag self vs. other). Caiioo는 _사용자_를 지칭하는 식별자와 타인을 지칭하는 식별자를 구분합니다. 사용자는 하나만 익명화할지, 둘 다 할지 선택할 수 있습니다. 사용자가 개인 사전에 추가한 이름은 항상 "본인"으로 간주됩니다.
- 대체 (Substitute). 각 실제 값은 안정적이고 스타일이 일치하는 가명(pseudonym)으로 대체됩니다. "Sarah Goldberg"는 "Maya Hartwell"이 되며, 전체 대화 동안 "Maya Hartwell"로 유지됩니다. 따라서 해당 인물에 대한 모델의 추론이 대화 차례마다 파편화되지 않습니다. 실제 값과 가짜 값의 조회 테이블(lookup table)은 사용자의 기기에 보관되며, 플랫폼 키체인의 키로 암호화됩니다.
- 전송 (Send). 모델은 완전히 가짜인 메시지를 수신합니다. 실제 식별자는 결코 네트워크를 통과하지 않으며, 당사의 감사 로그(audit log)에는 횟수만 기록될 뿐 값 자체는 절대 기록되지 않습니다.
- 복원 (Restore). 스트리밍 응답은 도착하는 즉시 다시 매핑됩니다. 모델 답변의 "Maya Hartwell"은 화면에 도달하기 전 "Sarah Goldberg"로 바뀌며, 사용자가 무엇이 보호되었는지 한눈에 볼 수 있도록 작은 글로우 필(glow pill)과 함께 렌더링됩니다.
- 도구 인자도 복원 (Restore tool arguments too). 모델이 도구를 호출할 때(이메일 발송, 티켓 생성, 문서 작성 등) 인자에 가짜 값이 포함되어 있다면, 도구가 실행되기 _직전_에 실제 값으로 다시 대체합니다. 모델은 가짜 값을 바탕으로 추론하고, 실제 동작은 실제 값을 사용합니다.
이 필터는 어떤 AI 서비스를 사용하는지 상관하지 않습니다. 메시지가 모델에 도달하기 전에 실행되므로 OpenRouter, Anthropic, Google, OpenAI 및 로컬 Ollama 모두 동일하게 마스킹된 페이로드를 받게 됩니다. 새로운 제공업체를 추가하더라도 프라이버시 허점이 다시 생기지 않습니다.
누구를 보호하는가
사용자. 사용자의 이름, 이메일, 주소, 전화번호, IP 및 생체 식별자 등 수집기가 개인을 식별할 수 있게 하는 정보들은 필터가 켜져 있는 동안 기기를 절대 떠나지 않습니다.
사용자가 언급하는 사람들. 대부분의 개인정보 도구는 입력하는 사람에게만 집중하지만, 우리가 간과하는 것은 '사회적 계약'입니다. 즉, 우리 모두는 자신뿐만 아니라 타인에 대해서도 책임을 져야 한다는 사실입니다. "샌더스 씨의 무능함에 대한 행실을 분석해 줘"라는 내용을 LLM에 제출하면 시스템 로그에 무기한 기록될 수 있으며, 이는 무책임하고 잠재적으로 명예훼손의 소지가 있습니다. 1,000명의 비즈니스 연락처가 포함된 Google Workspace 시트에 대해 LLM에 도움을 요청하면, 적용 중인 '데이터 제로 보유' 수준에 따라 그 정보들이 데이터 보유망에 들어가게 됩니다. Caiioo의 필터는 제삼자도 보호합니다. 계약서 작성 대상인 고객, 기록 분석 대상인 환자, 이메일 내용이 컨텍스트에 복사된 동료 등이 포함됩니다. 그들은 원격 LLM이 자신의 식별자를 보는 것에 동의하지 않았습니다. 필터는 기본적으로 이를 존중하며, 워크플로우에 따라 사용자가 "본인만" 또는 "타인만"으로 전환할 수 있습니다.
엔티티 — 기업, 병원, 법률 사무소. 계좌 번호, 면허 번호, 의료 기록 번호, 금융 라우팅 세부 정보, 내부 ID, API 키, 고객 명단 등이 해당됩니다. 기업도 개인과 마찬가지로 데이터 최소화에 대한 이해관계를 가집니다. Caiioo를 사용하여 퇴원 요약지를 작성하는 임상의는 환자의 의료 기록 번호를 OpenAI로 보내지 않습니다. 변호사는 고객의 계좌 번호를 Anthropic으로 보내지 않습니다. 지원 엔지니어는 고객 로그의 API 키를 Google로 보내지 않습니다. 필터는 식별자가 개인의 것인지 법인의 것인지 묻지 않고 그저 기기에 머물게 합니다.
최대의 유용성, 최소의 노출
핵심은 사용자가 필터의 존재를 느끼지 못해야 한다는 점입니다.
대부분의 개인정보 도구는 선택을 강요합니다. 공격적으로 가려서 모델의 답변 품질이 떨어지는 것을 감수하거나, 프롬프트의 가독성을 유지하면서 개인정보 보호 약속을 약화시키는 것입니다. 우리는 이러한 타협을 거부했습니다. 모델은 여전히 완벽한 형태의 프롬프트를 받습니다. 이름, 장소, 날짜, 의료 기록 번호가 모두 올바른 문법적 위치에 배치된 상태로 보입니다. 다만 가짜 정보를 볼 뿐입니다. 모델의 추론 과정은 동일하며 문자열만 세척됩니다.
'안정적인 대체(Stable substitution)'가 이를 가능하게 합니다. 대화 내에서 동일한 실제 값은 항상 동일한 가짜 값으로 매핑되기 때문입니다. 사용자의 메시지, 해당 이름을 참조하여 돌아오는 도구 결과, 이를 언급했던 모델의 이전 답변에 걸쳐 모델은 일관된 인물, 장소 또는 사물에 대해 추론할 수 있습니다. 여러 차례 이어지는 대화가 뒤섞이지 않고, 도구 호출도 깨지지 않습니다. 하위 에이전트는 상위 대화의 매핑을 상속받아 전체 작업에서 일관성을 유지합니다.
사용자가 보는 출력은 실제 대화입니다. 제공업체가 보는 데이터는 일관된 허구입니다. 작업은 이 두 시각 사이의 간극에서 이루어지며, 우리의 유일한 목표는 그 간극을 보이지 않게 만드는 것입니다.
방해가 되는 개인정보 필터는 결국 꺼지게 됩니다. 워크플로우 속으로 사라지는 개인정보 필터만이 출시할 가치가 있는 유일한 필터입니다.
그것이 우리가 구축한 기준입니다.