사회보장번호를 넘어: 조직의 내부 ID 익명화
귀하의 GDPR 도구는 이메일 주소를 제거합니다. 전화번호를 제거합니다. 이름을 제거합니다. 지원 내보내기를 통해 실행합니다. 그런 다음 분석 팀과 결과물을 공유합니다.
고객 계좌번호는 여전히 모든 티켓에 있습니다. 주문 ID도 여전히 있습니다. 내부 사용자 ID도 여전히 있습니다.
이 ID들은 단독으로는 무해해 보입니다. 조회 테이블 없이는 개인의 이름을 특정하지 않습니다. 하지만 귀하의 분석 팀에는 그 테이블이 있습니다. CRM에도 있습니다. 지원 데이터베이스에도 있습니다. 접근 권한이 있는 사람은 몇 초 만에 개인을 찾을 수 있습니다.
이것은 GDPR 실패입니다. 도구가 고장난 것이 아닙니다. 귀하의 ID를 찾으라는 지시를 받은 적이 없습니다.
표준 PII 도구가 탐지하는 것
표준 PII 도구는 범용 형식을 커버합니다. 모든 조직이 사용하는 것을 탐지합니다.
표준 도구가 탐지하는 것:
- 사회보장번호 (미국 SSN, 영국 NINO, EU 국가 ID 형식)
- 이메일 주소
- 전화번호
- 신용카드 번호
- 이름
- 여권 및 운전면허 번호
표준 도구가 탐지하지 않는 것:
- EMP-XXXXX 형식의 직원 ID
- ACC-XXXXXXXX-XX 형식의 고객 계좌번호
- ORD-XXXXXXX 형식의 주문 ID
- UUID 또는 커스텀 형식의 내부 사용자 ID
- 파트너별 참조 코드
표준 도구는 범용 패턴을 찾습니다. 귀하의 내부 ID는 범용이 아닙니다. 찾으려면 커스텀 설정이 필요합니다.
재식별 위험
한 기업이 품질 검토를 위해 지원 티켓을 내보냅니다. 표준 PII 제거로 이름, 이메일, 전화번호를 제거합니다. ACC-XXXXXXXX-XX 형식의 계좌번호는 그대로 남겨집니다.
내보내기가 분석 팀으로 전달됩니다. 분석가가 계좌번호로 티켓 테이블과 고객 데이터베이스를 즉시 조인합니다. 개인이 바로 특정됩니다. 특별한 기술이 필요하지 않습니다. 일상적인 SQL 조인입니다.
GDPR 제4조 제5항은 가명화를 "추가 정보 없이는 더 이상 특정 정보주체에게 귀속될 수 없는" 처리로 정의합니다. 계좌번호는 이 기준을 충족하지 않습니다. 추가 정보 — 귀하의 고객 데이터베이스 — 가 조직 내 바로 거기에 있습니다.
"익명화된" 내보내기는 익명이 아니었습니다.
커스텀 엔티티 패턴 구축
커스텀 엔티티 설정은 빠릅니다. 컴플라이언스 팀이 엔지니어링 도움 없이 할 수 있습니다.
1단계: ID 형식 목록 작성.
각각을 기록합니다. 예를 들어: 계좌 ACC-XXXXXXXX-XX, 주문 ID ORD-XXXXXXX, 직원 ID EMP-XXXXX.
2단계: 형식을 평이한 언어로 설명.
"계좌번호는 ACC로 시작하고, 대시, 8자리 숫자, 대시, 2개의 대문자로 구성됩니다."
AI 지원 패턴 생성 결과: ACC-\d{8}-[A-Z]{2}
3단계: 샘플 데이터에서 테스트.
20~30건의 문서를 업로드합니다. 모든 인스턴스가 탐지되는지 확인합니다. 오탐이 없는지 확인합니다.
4단계: 방법 선택.
분석에서 레코드를 연결해야 하는 조인 키로 사용되는 ID의 경우:
- 가명화. ACC-00123456-AB를 매번 ACC-99876543-XY로 대체합니다. 동일한 입력은 항상 동일한 출력을 생성합니다. 조인이 여전히 작동합니다. 원본 값은 키 없이 찾을 수 없습니다.
분석에 필요하지 않은 ID의 경우:
- 비식별화. **[REDACTED]**로 대체합니다. 단순합니다. 영구적입니다.
5단계: 공유 프리셋으로 저장.
커스텀 엔티티 — 또는 여러 개의 집합 — 를 공유 프리셋으로 저장합니다. 설정이 모든 사용에 적용됩니다: 배치 업로드, API 호출, 브라우저 인터페이스. 새 팀원도 즉시 전체 설정을 사용합니다.
사례 연구: 지원 티켓 18만 건
한 기업이 분석 웨어하우스에서 지원 티켓 18만 건을 발견했습니다. 이름과 이메일은 제거되어 있었습니다. 계좌번호는 그렇지 않았습니다. 각 티켓에 실제 ACC-XXXXXXXX-XX 값이 여전히 남아 있었습니다.
해결 일정:
- 컴플라이언스 담당자가 ACC 패턴 정의 — 15분
- 샘플 티켓 30건에서 테스트 — 20분
- 정확도 확인 — 10분
- 18만 건 티켓을 야간 배치로 처리
- 깨끗한 버전으로 웨어하우스 테이블 교체
컴플라이언스 담당자의 총 소요 시간: 45분. 커스텀 엔티티 지원 없이는 엔지니어링 티켓, 코드 리뷰, 배포가 필요했을 것입니다. 몇 시간이 아니라 몇 주가 걸렸을 것입니다.
AI 지원 도구에서 커스텀 ID가 어떻게 위험을 만드는지 자세히 보려면 GDPR과 지원 AI 가이드를 참조하세요.
커스텀 ID가 퍼지는 곳
내부 ID는 대부분의 팀이 예상하는 것보다 더 많은 곳에 나타납니다.
내부 문서:
- 계좌 또는 주문 ID 참조가 있는 회의 노트
- 고객 사례에 관한 이메일 스레드
- 사례 연구 데이터가 있는 프레젠테이션
제3자와 공유:
- 사례 참조번호가 있는 규제 기관 보고서
- 고객 참조가 있는 감사 파일
- 고객 ID가 포함된 벤더 파일
연구 및 분석:
- 고객 여정 데이터셋
- 지원 품질 검토 내보내기
- 내부 ML 모델의 학습 데이터
각 맥락에서 진정으로 익명화된 결과물을 만들려면 동일한 커스텀 엔티티 설정이 필요합니다.
가명화 vs. 익명화
GDPR은 명확한 선을 긋습니다.
가명화는 ID를 대리 값으로 대체합니다. 조회 테이블이 있는 사람은 원본 개인을 다시 찾을 수 있습니다. 이 데이터는 여전히 개인 데이터입니다. 위험을 줄입니다. GDPR 의무를 제거하지는 않습니다.
익명화는 재식별 능력을 제거합니다. 익명 데이터는 개인 데이터가 아닙니다. 여기에는 GDPR이 적용되지 않습니다.
계좌번호와 주문 ID는 조회 테이블이 존재하는 한 가명입니다. 고정된 대리 값으로 대체하면 위험이 낮아지지만 GDPR은 여전히 적용됩니다. 무작위 토큰으로 대체하고 키를 삭제하면 GDPR 의무가 제거되지만 조인 기반 분석이 불가능해집니다.
조회 테이블이 없는 제3자와 공유하는 경우: 가명화로 충분할 수 있습니다. 내부 분석의 경우, 완전한 익명화 또는 엄격한 접근 제어가 필요합니다. 각 접근 방식을 ROPA에 문서화하는 방법은 법적 컴플라이언스 가이드를 참조하세요.
결론
격차는 도구 실패가 아닙니다. 설정 격차입니다. 어떤 도구도 귀하에게 알려주지 않으면 귀하의 계좌번호 형식을 알 수 없습니다.
커스텀 엔티티 설정이 이 격차를 몇 시간 만에 해소합니다. 컴플라이언스 팀이 형식을 정의하고, 샘플 데이터에서 테스트하고, 모든 사용 모드에 적용합니다. 엔지니어링 도움이 필요하지 않습니다.
18만 건의 비식별화되지 않은 계좌번호가 그곳에 있었던 것은 도구가 실패했기 때문이 아닙니다. 도구가 찾으라는 지시를 받은 적이 없었기 때문입니다.