PII Scanner & Microsoft SEAL Demo

핵심 흐름 (5단계):

1. 결정 누적 — 파일 분석 탭에서 [C][S][O] 버튼으로 사용자 최종 분류 기록.
2. 학습 조건 검사 — labeled ≥ 10 (총 결정), per-class ≥ 3 (각 등급별), gap ≥ 3 (AI와 다른 결정). 조건 통과해야 학습 가능.
3. "학습 라운드 실행" 클릭 → 1-step SGD on linear score → gradient 계산.
4. 결과 확인 — 가중치 변화 (Δw 차트) + 학습 전후 정확도/SSE 비교.
5. "핫스왑" 채택 — 새 가중치로 즉시 분류기 갱신 (서버 재시작 X).

학습 vs Rule Mining (운영 탭) 의 차이:

• 학습 (이 탭) = 자동 — gradient 계산해서 모든 entity 가중치 일괄 갱신.
• Rule Mining (운영) = 제안만 — 후보를 표시, 사용자가 각각 검토 후 채택.

하이퍼파라미터 (위 입력창):

• η (learning rate) — 가중치 변화 속도. 크면 빠르지만 진동, 작으면 학습 더딤. 기본 0.05.
• max|Δw| — 단일 라운드의 가중치 변화 한계 (안전망). 기본 0.5.

모델 버전 이력: 모든 학습 라운드 결과가 model_versions 테이블에 영속 보존. 잘못된 학습은 이전 버전으로 롤백 가능.

강제 실행 (force): 학습 조건 미달이어도 실험 목적으로 실행. 데이터 적어서 결과는 노이즈가 클 수 있음.

SPEC 출처: §1 기능 5/6/7/8/10 + §10 학습 파이프라인.

핵심 흐름 (3단계):

1. 입력 — 파일 분석 결과 가져오기 또는 텍스트 직접 붙여넣기.
2. "1회 익명화" — 현재 정책 1번 적용 → entity 별 치환된 텍스트 출력.
3. "target 등급까지 반복" — 정책을 반복 적용해 목표 등급에 도달 (최대 N번).

익명화 (이 탭) vs 가명화 framework (별도 탭) 의 차이:

6가지 처리 방법 (method):

• mask — 별표(*)로 가림. 예: 800101-1234567 → ******-*******
• remove — 통째로 삭제 (AWS key 같은 자격증명)
• replace — placeholder. 예: hong@example.com → [EMAIL_1]. consistent: true 면 같은 원본은 같은 번호 (문서 내 cross-reference 보존)
• generalize — 상위 개념으로. 주소 구→시, 날짜 일→월
• shift — 날짜를 ±N일 무작위 시프트 (시간 순서는 유지)
• round — 숫자를 N단위로 반올림 (금액 통계용)

target 등급 의미:

• O 공개 — PII 다 가려짐. 외부 공유 가능 수준.
• S 민감 (default) — 이메일 등 약식별자 남기되 주민번호 같은 강식별자는 가림.
• C 위험 유지 — 강등 안 함. 분석 후 비교만 할 때.

정책 수정 어디서? 운영 → 정책 편집기 탭에서 entity 별 method/옵션 변경. 변경 즉시 영속 (anonymization_policy.json).

SPEC 출처: §15 익명화.

점수 기반 분류 (rule-v1) 의 직관:

1. 문서에서 PII 항목을 찾는다 (PII 분석 단계).
2. 각 항목의 가중치 만큼 점수를 더한다 (주민번호 5점, 이메일 1점 등).
3. 등급 키워드 (예: "비밀번호") 가 있으면 점수 추가.
4. 비한국어이면 보수적으로 등급 ↑ (정보 부족 보완).
5. 최종 점수와 임계값을 비교 → C / S / O 결정.

채점 공식 (단순화):

score = Σ (ENTITY_WEIGHTS[type] × count) + LANGUAGE_PENALTY + KEYWORDS_BOOST

if score ≥ T_C  → C (위험)
if T_S ≤ score < T_C  → S (민감)
else  → O (공개)

주요 가중치 (default — 학습으로 변경 가능):

• KR_RRN (주민번호) — 5.0 (가장 위험)
• CREDIT_CARD — 4.5
• KR_PASSPORT — 4.0
• EMAIL_ADDRESS — 1.0 (약식별자)
• ... 더 많은 항목은 아래 표 참조

왜 룰 기반인가? — 신경망 (KoELECTRA + mDeBERTa) 와의 차이:

HE-TEST 는 둘을 weighted ensemble (α default 0.5) 로 결합합니다.

룰 추가/수정 — 동적 편집:

• custom_patterns.yaml — 정규식·키워드 인식기 자유롭게 추가
• "Reload Patterns" 버튼 → 즉시 반영 (서버 재시작 X)
• API: /api/rules/pattern, /api/rules/grade-keyword 등으로 프로그래밍 방식 편집

신뢰도 (confidence): 점수가 등급 경계에서 얼마나 떨어졌는가. 경계에 가까우면 낮은 신뢰도 (사용자 검토 권장), 멀면 높은 신뢰도. 운영 → 신뢰도 보정 (Platt) 탭에서 보정 가능.

SPEC 출처: §3.4 룰엔진 + §3.5 분류기.

상황: 단순 익명화 (PII 가리기) 만으로는 외부 공유·해외 송신 시 법규를 만족하지 못합니다. 한국 PIPA, 유럽 GDPR, 일본 APPI, 미국 CCPA 가 각자 다른 기준을 요구.

표준의 의미:

• ISO/IEC 20889 — 가명화/익명화의 기법 표준 (masking, tokenization, generalization, suppression 등 7가지).
• ISO/IEC 27559 — 익명화 후의 재식별 위험 평가 표준 (k-anonymity 등).
• W3C DPV 2.0 — 데이터 카테고리 온톨로지 (검출된 PII 를 표준 클래스에 매핑).
• 4개 관할 법령 — 각 국가의 PII 정의·처리 요구사항·보존 기간 등.

처리 흐름 (아래 SVG 다이어그램 참조):

1. 입력 — 파일/텍스트 + 관할 선택 (KR/JP/US/EU 다중 선택) + 처리 수준 (가명화/익명화)
2. PII 검출 — Presidio + 한국어 NER (분류 파이프라인 재사용)
3. DPV 매핑 — 검출된 PII 를 W3C DPV 카테고리에 매핑 (예: KR_RRN → dpv:NationalIdentificationNumber)
4. 관할 분류 — 각 PII 를 identifier (직접식별) / quasi (준식별) / sensitive (민감) 로 분류 (관할마다 다름)
5. ISO 20889 기법 적용 — masking, tokenization, generalization, suppression 등 (entity 종류에 따라 자동 선택)
6. 변환문 + 관할별 준수 판정 — 결과 텍스트 + 각 관할 (KR/JP/US/EU) 의 요구사항 만족 여부 별도 평가

처리 수준 (treatment_level):

• pseudonymization (가명화) — 원본 복원 가능. 매핑 키만 별도 보관하면 추적/재식별 가능. 내부 분석/통계 목적.
• anonymization (익명화) — 비가역. 매핑 자체를 폐기. 외부 공개·연구 목적.

익명화 / 등급강등 탭과의 차이:

관할별 핵심 차이 (요약):

• KR (PIPA) — 주민번호·여권번호 등 고유식별번호 엄격. 가명정보 결합 시 동의 또는 통계 목적 제한.
• JP (APPI) — 가명가공정보 / 익명가공정보 구분. 매핑 폐기 의무.
• US (CCPA) — Personal Information 광범위. opt-out 권리. 14세 미만 추가 보호.
• EU (GDPR) — Personal Data + Special Category (인종·종교·건강 등) 구분. 가명화는 추가 보호조치 (recital 28).

SPEC 출처: 본 framework 는 origin/main 의 pseudo_framework.py 모듈 + 아래 SVG 다이어그램으로 시각화.

• 고유식별정보 (§24) — 주민등록번호·여권번호·운전면허번호·외국인등록번호. 주민등록번호는 §24-2 별도 처리제한 (법령 근거 필수).
• 민감정보 (§23) — 사상·신념·노조·정치·건강·성생활·유전·전과. 별도 동의 또는 법령 근거 필요.
• 개인정보 (§2) — 식별 가능한 정보. 단독 또는 결합으로 특정 가능.
• 가명정보 (§28-2~7, 2020 신설) — 통계·연구·공익 목적 활용. 추가정보 별도 보관 필수.
• 익명정보 (§58-2) — 어떤 추가정보로도 복원 불가. PIPA 적용 제외.

유출신고: 72시간 내 PIPC + KISA. 트리거 — ① 1,000명 이상 / ② 민감정보 / ③ 자격증명. 위반 시: 행정처벌 + 손해배상 (법정·징벌적).

• HIPAA (1996) — Healthcare 분야. Safe Harbor 18 식별자 모두 제거 (§164.514(b)(2)(i)). PHI 보호.
• CCPA/CPRA (California, 2018 / 2023) — opt-out 권리. Sensitive Personal Information 별도 카테고리 (§1798.140(ae)).
• GLBA (1999) — Financial 분야. NPI (Nonpublic Personal Information).
• FCRA — Consumer reports (신용보고서).
• COPPA — 13세 미만 아동.
• FERPA — 학생 교육기록.

HIPAA Breach Notification: 60일 (Individuals + HHS) / 미디어 (≥500명). State laws: 모든 50개 주가 별도 통지법 보유 (California Civ. §1798.82 등).

Penalties: HIPAA Tier 4 최대 $1.5M/year; FTC enforcement; class action 가능.

1. 기본법 — 個人情報保護法 (APPI). 2003년 제정, 2015·2020·2022 개정. 한국 PIPA 와 거의 대응.
2. 특별법 — マイナンバー法. 12자리 마이넘버 전용. APPI 보다 엄격 (利用目的限定·暗号化義務).
3. 분야 가이드라인 — 金融 (FSA) · 医療 (MHLW) · 電気通信 (MIC).

유출신고 (APPI §26): 速報 3-5일 / 確報 30일. 마이넘버 위반 시 §51 不正取得罪 (최대 4년 징역).

📌 한국 PIPA 와 핵심 차이: 마이넘버 = 별도법 (한국은 PIPA 통합). 유출신고 트리거가 훨씬 광범위 ("권리침해 우려 시" 무조건).

• Personal Data (Art 4(1)) — 식별 가능한 자연인의 정보. IP 도 포함 (Breyer C-582/14).
• Special Categories (Art 9) — race·political·religious·trade union·genetic·biometric·health·sex life. 처리 금지 원칙, Art 9(2) 예외만 허용.
• Criminal data (Art 10) — 공식기관 또는 회원국 법령 근거 시에만.
• Pseudonymisation (Art 4(5)) — 추가정보 별도 보관. 가명화 자체로는 개인정보 지위 유지.
• Anonymisation (Recital 26) — 합리적 수단으로도 재식별 불가. GDPR 적용 제외.

7대 원칙 (Art 5): lawfulness · fairness · transparency · purpose limitation · data minimisation · accuracy · storage limitation · integrity & confidentiality · accountability.

유출신고: Art 33 (DPA, 72시간) / Art 34 (data subjects, "without undue delay" if high risk). Penalty: 최대 €20M 또는 글로벌 매출 4% (Art 83).

1. 분류 추론 파이프라인 — 파일 한 개를 받아 등급(C/S/O) 으로 분류하는 메인 흐름. (탭: 파일 분석)
2. 신경망 분류 — KoELECTRA + mDeBERTa 두 백본의 임베딩을 조합한 보조 분류기. rule-v1 과 가중 평균.
3. 사용자 피드백 → 학습 루프 — 사용자가 [C][S][O] 버튼으로 정정한 결정을 SQLite 에 누적, 조건 도달 시 가중치 자동 갱신. (탭: 학습 / 이력)
4. 가명화 framework (KR·JP·US·EU) — ISO 20889 + DPV 매핑 + 4개 관할 법령 매트릭스. (탭: 가명화 framework)
5. 익명화 / 등급강등 — 정책에 따라 PII 를 placeholder 로 바꾸고 등급을 한 단계 내림. (탭: 익명화 / 등급강등, 정책 편집은 정책 편집기)
6. Rule Mining — 학습이 자동이라면 Rule Mining 은 "제안만" — 사용자 검토 후 채택. (탭: Rule Mining)
7. Platt Calibration — 분류기 신뢰도 숫자를 진짜 정답률에 맞춰 보정. (탭: 신뢰도 보정 (Platt))
8. Drift Detection — 분류 패턴 변화 (정확도/갭/entity 분포) 자동 감지·알림. (탭: Drift 탐지)
9. HE 학습 시연 — 다중 사용자의 gradient 를 BFV 동형암호로 평문 없이 합산. (탭: HE 학습 시연)
10. + 별도 파이프라인: 동형암호 (HE) — RRN/Keyword 검색용 BFV/CKKS 데모. (탭: SEAL Demo / RRN Search / Keyword Search)

색상 범례 — 노드 색상이 어디서 동작하는지 의미합니다:

문제: "민감 등급 (S)" 으로 분류된 문서를 외부에 공유해야 한다고 합시다. 그대로 보내면 안 되고, 개인정보를 가려야 합니다. 그런데 어디까지 가려야 안전한지, 어떻게 가려야 가독성이 살아있는지 는 항목별로 다릅니다.

예시:

• 주민번호 800101-1234567 → ******-******* (전부 가려야 함, mask)
• 이메일 hong@gmail.com → [EMAIL_1] (placeholder 로 일관성 보존, replace)
• 전화번호 010-1234-5678 → ***-****-5678 (마지막 4자만 남기기, preserve_last)
• 주소 서울특별시 강남구 역삼동 123-45 → 서울특별시 강남구 (하위 단위 제거, generalize)
• 날짜 2026-05-09 → 2026-04-21 (±30일 무작위 시프트, shift)

정책의 6가지 처리 방법 (method) — 각 PII 항목에 1개씩 지정:

• mask — 별표(*)로 가림. preserve_last: 4 로 끝 4자 보존 가능
• remove — 통째로 삭제 (자격증명 등)
• replace — placeholder (예: [EMAIL_%d]) 로 교체. consistent: true 면 같은 원본은 같은 번호
• generalize — 상위 개념으로 (주소 구→시, 날짜 일→월)
• shift — 날짜를 ±N일 무작위 시프트 (시간 순서는 보존)
• round — 숫자를 N단위로 반올림

등급 강등 (downgrade): 정책을 적용한 뒤 다시 분류했을 때도 등급이 안 내려가면 (예: C 등급 그대로) 더 강한 정책으로 자동 반복 적용. target_grade 까지 도달하거나 max_iterations 만큼 반복.

상황: AI 가 어떤 문서를 "S 민감" 등급이라 했지만, 사용자는 "C 위험" 으로 정정하는 일이 자주 발생. 왜? AI 의 룰이 그 패턴을 충분히 무겁게 안 봤기 때문.

해결: 결정 이력을 자동 분석해서:

• "KR_RRN 이 들어간 문서는 사용자가 항상 등급을 1단계 올림" → 이 entity 의 가중치를 ↑ 제안
• "EMAIL_ADDRESS 만 있는 문서는 사용자가 항상 등급을 내림" → 가중치 ↓ 제안
• "같은 파일명 패턴이 반복적으로 갭 발생" → 특별 룰 후보

학습 (train.py) 과의 차이: 학습은 가중치 자동 조정. Rule Mining 은 "이렇게 바꿔보세요" 제안만 — 사용자가 채택해야 적용. 더 안전 (자동화 X, 검토 후 적용).

SPEC 출처: §2.4 갭 활용 4가지 중 (3) Rule mining.

일반 학습의 문제: 100명의 직원이 각자 회사 문서를 분류·학습하면, 각자의 gradient (가중치 변화량) 가 그 사람의 분류 패턴을 그대로 드러냅니다. "이 사람은 어떤 문서를 위험으로 봤나" → 사실상 직원 행동 추적 가능.

HE 의 해결:

1. 클라이언트 (브라우저): 각자의 gradient 를 BFV 동형암호로 암호화 → 평문 사라짐
2. 서버: 암호문들을 받아 그대로 덧셈 (HE 의 동형성 — 평문 없이도 덧셈 가능). 서버는 누가 뭘 학습했는지 모름.
3. 관리자 (또는 일정 인원 합의): 합산 암호문을 복호화 → 전체 평균 gradient 만 노출. 개별 사용자 정보 X.
4. 모델은 이 평균 gradient 로 갱신.

왜 가능한가? BFV 같은 HE 스킴은 Enc(a) + Enc(b) = Enc(a+b) 가 수학적으로 성립. 서버는 두 암호문을 곱(덧셈)만 하면 됨. 평문 a, b 는 절대 보지 않음.

본 시연: 4개 entity 의 gradient (예: [KR_RRN: +0.3, EMAIL: -0.1, PHONE: +0.05, NAME: 0.0]) 를 두 클라이언트가 각각 암호화 → 서버가 합산 → 복호화. 시각적으로 평문이 어디서 사라지고 어디서 나타나는지 보여줍니다.

SPEC 출처: §2.6 동형암호와의 연결.

이 페이지의 목적: 사용자가 분류한 파일들의 정보가 어떤 경로로 모델 가중치 갱신까지 이어지는지, 그 과정에서 HE 가 어떻게 데이터를 보호하는지를 6단계로 가시화.

학습 대상 모델: classifier.ENTITY_WEIGHTS (rule-v1) — 약 20개 entity 별 가중치. 1-step linear regression SGD.

학습 데이터 정의:

• features = 결정의 findings_summary (entity → count, 예: {KR_RRN: 2, EMAIL: 1})
• target = 사용자 결정 등급 (O=0, S=1, C=2)
• pred = Σ weights[ent] × count[ent] (현재 모델 forward)
• grad[ent] = (pred − target) × count[ent] (∂MSE/∂w)

HE 의 역할: 각 클라이언트의 gradient 가 그 클라이언트의 분류 패턴을 그대로 노출 → BFV 동형암호로 암호화. 서버는 ciphertext 만 받아 합산 → 합산 결과를 복호화 → 평균. 평문 gradient 는 어느 한 머신에도 노출되지 않음 (관리자 복호화 시점에만 평균).

6단계 화면:

1. STEP 1 — 결정 이력 로드 (파일별 AI/User 등급)
2. STEP 2 — features + target 추출 (학습 데이터)
3. STEP 3 — 클라이언트별 gradient 계산 (forward + backward)
4. STEP 4 — BFV 암호화 → 서버 합산 → 복호화 (HE 학습 시연 탭의 흐름 자동 실행)
5. STEP 5 — 평균 gradient → 모델 적용 (ENTITY_WEIGHTS 갱신 + 새 model_version 영속)
6. STEP 6 — 학습 전후 비교 (Δw + 새 분류 결과)

SPEC 출처: §2.6 + docs/he_fl_plan.md Phase 1.

Phase 1 (위 6단계) — 실제 BFV 암호화·합산·복호화. 한 라운드 ~5초 (key gen 등 포함).

Phase 2 (이 섹션) — 같은 흐름의 평문 시뮬레이션. HE 의 효과는 Phase 1 이 보여줬으니, 이제 라운드 반복 수렴만 보는 단계. 한 라운드 ~10ms.

핵심 통찰: HE 의 동형성으로 평문 합산 결과 = HE 복호화 결과 (Phase 1 검증). 따라서 Phase 2 의 평문 시뮬도 production 의 HE 결과와 같음.

data 소스: reasons 기반 (train.py 와 동일). 결정 이력의 noise (NRP 등) 영향은 노이즈 fix commit 이후 가중치 0 으로 차단됨.

문제: 분류기가 100건의 문서에 "C 등급일 확률 0.95" 라고 했는데, 실제로는 70건만 C 였다면 → 모델이 과신 (overconfident). 사용자가 "신뢰도 95%" 보고 자동 채택하면 30% 가 틀림 → 사고.

핵심 수식:

P(정답 | 점수 f) = σ(A · f + B) = 1 / (1 + exp(−(A·f + B)))

두 파라미터 A, B 의 역할:

• A — 시그모이드의 가파름. 분류기 점수에 얼마나 민감한가.
• B — 시그모이드의 가로 이동. 어느 점수에서 0.5 가 되는가.

학습 데이터 정의:

• score = ai_confidence (분류기 출력 신뢰도)
• label = 1 if ai_grade == user_grade else 0 (사용자가 동의했는지)

알고리즘: 위 두 파라미터를 결정 이력에서 logistic regression (gradient descent 800 iter) 으로 학습. sklearn 의존성 X — numpy 도 안 쓰고 순수 Python.

왜 PoC 에 적합한가? 파라미터 단 2개 → 적은 데이터 (~30개부터) 로도 의미 있게 학습. SPEC §2.4 (2) 가 명시적으로 권장.

HE-TEST 에서 효과:

1. 학습 후 분류 결과 카드의 신뢰도가 실제 정답률에 맞춰 보정됨 (raw → calibrated 둘 다 표시).
2. 갭이 큰 영역에서 신뢰도가 가장 부정확 → 보정 효과 큼.
3. 외부 자동화 (예: 신뢰도 0.9+ 만 자동 처리) 의 안전성 ↑.

상황: 처음 1개월 — AI 가 "이메일 = S 민감" 으로 분류, 사용자도 동의 (정확도 90%). 그런데 3개월 후 — 회사 정책이 변해서 "이메일 = O 일반" 으로 정정해야 함. 사용자는 매번 정정. AI 는 모름. 학습이 자동 적용되기 전까지 정확도가 계속 떨어짐.

Drift 의 정의 (ML 용어):

• Concept drift — "정답의 의미가 변함" (위 시나리오)
• Data drift — "입력 데이터 분포가 변함" (새 문서 유형 등장)
• User drift — "사용자 판단 기준이 변함" (위 두 가지의 결합)

본 모듈이 보는 3 지표:

1. 정확도 drift — AI=User 비율의 변화 (최근 N건 vs 이전 N건)
2. 평균 갭 drift — |AI−User| 평균 변화 (커지면 분류기가 더 자주 어긋남)
3. Entity 분포 drift — 어떤 PII 가 자주 나오는지 비율 변화 (PSI 비슷한 점수)

알고리즘: 결정 이력을 시간순 정렬 → 최근 N건 (window A) vs 이전 N건 (window B) 통계 비교 → 임계값 초과 시 알림.

임계값 (기본): 정확도 −15%p 이상 하락 → alert, 평균 갭 +0.3 이상 증가 → warn, entity 분포 변화 PSI ≥ 0.1 → info

SPEC 출처: §2.4 갭 활용 4가지 중 (4) User profile drift detection — "특정 사용자의 갭이 커지면 → 정책 변경/조직 변경 신호로 알림".