GDPR과 고객 지원 AI: 커스텀 식별자도 개인정보입니다
지원팀이 AI를 사용해 답변 초안을 작성하고 티켓을 검토합니다. 생산성이 올랐습니다. 그런데 DPO가 설정을 점검합니다.
일반적인 고객 메시지에는 이름, 이메일 주소, 주문 ID가 포함됩니다. 이름과 이메일은 개인정보입니다. 주문 ID도 마찬가지입니다. 주문 데이터베이스에서 Sarah Johnson을 특정할 수 있습니다. AI 벤더가 이를 교차 참조할 수 있습니다. 학습 데이터가 유출되면 해당 ID로 그녀를 재식별할 수 있습니다.
법적 근거 없이 이 중 하나라도 외부 AI 벤더에 전송하는 것은 GDPR 위반입니다.
주문 ID가 개인정보인 이유
GDPR 제4조는 개인정보를 폭넓게 정의합니다. 식별되거나 식별 가능한 사람에 관한 모든 정보를 포함합니다. 식별 가능성에는 식별자를 통한 간접 식별도 포함됩니다.
ORD-4521893 같은 주문 ID는 간접 식별자입니다. 그 자체로는 Sarah Johnson을 특정하지 않습니다. 하지만 주문 데이터베이스와 결합하면 특정됩니다.
GDPR 제4조 제5항은 가명 처리를 다룹니다. 주문 ID는 가명입니다. 해당 인물을 드러내려면 두 번째 출처가 필요합니다. 이것을 외부 AI 벤더에 전송할 때, 당신은 개인정보를 공유하는 것입니다. 법적 근거와 데이터 처리 계약이 필요합니다.
벤더가 당신의 데이터베이스를 보유하지 않을 수도 있습니다. 그렇다고 의무가 사라지지는 않습니다. 개인정보를 공유했습니다. GDPR은 여전히 적용됩니다.
표준 익명화의 공백
지원팀은 GDPR 준수를 위해 PII 탐지를 도입하는 경우가 많습니다. 표준 도구는 일반적인 엔티티 유형을 제거합니다.
표준 탐지는 고객 이름, 이메일 주소, 전화번호, 신용카드 번호를 잡아냅니다. 이들은 처리됩니다.
표준 탐지는 ORD-XXXXXXX 형식의 주문 ID를 잡아내지 못합니다. 계정 번호, 티켓 참조, 내부 사용자 ID, 구독 ID도 마찬가지입니다. 이것들은 통과됩니다.
결과는 이렇게 보입니다: "안녕하세요, 저는 **[PERSON_1]**이고 주문 ORD-4521893이 아직 도착하지 않았습니다. **[EMAIL_1]**으로 연락 부탁드립니다."
주문 ID가 여전히 남아 있습니다. CRM 접근 권한이 있는 누구나 Sarah Johnson을 즉시 찾을 수 있습니다. 익명화가 불완전합니다. 이것이 컴플라이언스 공백입니다.
Chrome 확장 프로그램: 브라우저 수준의 탐지
Claude, ChatGPT, Gemini를 사용하는 지원 상담사는 브라우저에서 작업합니다. Chrome 확장 프로그램은 커스텀 식별자가 외부로 나가는 것을 차단합니다.
작동 방식입니다. 상담사가 AI 도구에 고객 메시지를 붙여넣습니다. 확장 프로그램이 대상이 AI 플랫폼임을 인식합니다. 표준 PII를 제거한 다음 커스텀 형식을 적용합니다. 주문 ID 형식, 계정 번호 형식, 팀이 사용하는 기타 커스텀 식별자와 매칭됩니다. 상담사에게는 정리된 메시지만 보입니다. 원본 데이터는 AI에 도달하지 않습니다.
컴플라이언스 팀이 커스텀 형식을 한 번 설정합니다. 모든 상담사에게 공유 프리셋을 배포합니다. 상담사가 이를 관리할 필요가 없습니다. 메시지를 붙여넣으면 확장 프로그램이 나머지를 처리합니다.
MCP 서버: API 계층의 탐지
일부 플랫폼은 API를 통해 AI를 호출합니다. Intercom은 AI로 답변 초안을 만들고, Zendesk는 AI로 응답 제안을 제공합니다. MCP 서버는 이런 설정에서 API 계층에 익명화를 추가합니다.
흐름입니다. 고객 메시지가 지원 플랫폼에 도착합니다. AI에 도달하기 전에 MCP 엔드포인트를 통과합니다. 엔드포인트가 표준 및 커스텀 엔티티를 제거합니다. 정리된 메시지가 AI로 전달됩니다. AI가 응답을 반환합니다. 개인정보는 공유되지 않았습니다. 상담사는 지원 플랫폼에서 응답을 읽고 편집합니다.
상담사의 업무 방식에는 변화가 없습니다. 프로세스가 동일하게 보입니다. 커스텀 엔티티는 MCP 설정에서 한 번만 설정됩니다. 그 시점부터 모든 API 호출에 완전한 엔티티 탐지가 적용됩니다.
DPO 구현 체크리스트
1. AI로 향하는 모든 데이터 흐름을 파악하세요.
상담사가 AI를 사용하는 위치를 목록화하세요. 브라우저 도구, API 기반 도구, 파일 업로드를 포함하세요.
2. 고객 메시지의 모든 식별자 유형을 나열하세요.
표준 PII — 이름, 이메일, 전화번호 — 는 기본적으로 처리됩니다. 커스텀 식별자 — 주문 ID, 티켓 참조, 계정 번호 — 는 커스텀 형식이 필요합니다.
3. 커스텀 엔티티 형식을 추가하세요.
각 형식을 정의하세요. 샘플 메시지로 테스트하세요. 팀 프리셋에 저장하세요.
4. 올바른 계층에 배포하세요.
브라우저 기반 AI: 공유 프리셋과 함께 Chrome 확장 프로그램을 사용하세요. API 통합 AI: MCP 서버 또는 API 수준 전처리를 사용하세요.
5. ROPA를 업데이트하세요.
지원 AI가 자동 익명화를 사용한다고 기록하세요. 처리되는 커스텀 식별자 유형을 나열하세요. 이것이 기술적 보호 조치 문서입니다.
6. 설정을 테스트하세요.
모든 식별자 유형이 포함된 샘플 메시지를 실행하세요. AI에 도달하는 것이 없는지 확인하세요. 문서 템플릿은 법적 컴플라이언스 가이드를 참조하세요.
SaaS 지원팀 실제 사례
SaaS 지원팀이 내부 AI 플랫폼을 통해 Claude를 사용합니다. 고객 메시지에는 이름, 이메일, 주문 ID, 구독 ID가 포함됩니다. 일부 기능 플래그 이름에도 내부 식별자가 담겨 있습니다.
GDPR 검토 전: 모든 내용이 AI로 전달되었습니다. 주문 ID와 구독 ID가 포함된 상태였습니다.
커스텀 엔티티 탐지 적용 후:
ORD-XXXXXXX와 SUB-XXXXXXXX가 커스텀 엔티티로 추가되었습니다. Chrome 확장 프로그램이 공유 프리셋과 함께 배포되었습니다. DPO가 테스트를 실행하고 AI 처리 전에 모든 식별자가 제거됨을 확인했습니다.
상담사 업무 변화: 없음. 상담사는 동일하게 일합니다. 익명화가 백그라운드에서 실행됩니다. DPO는 기록된 보호 조치를 보유하게 됩니다.
결론
GDPR을 준수하는 지원 AI는 이름과 이메일만 제거하는 것 이상을 해야 합니다. 주문 ID, 계정 번호, 티켓 참조도 개인정보입니다. 표준 도구는 이를 놓칩니다. 커스텀 엔티티 설정이 공백을 메웁니다.
절차는 간단합니다. 식별자 형식을 정의하세요. 샘플 메시지로 테스트하세요. 팀에 배포하세요. DPO는 하루 오후 안에 이를 완료할 수 있습니다. 그 후부터는 모든 고객 데이터가 외부 AI 시스템에 도달하기 전에 제거됩니다. 컴플라이언스 효과는 그 시점부터 유지됩니다.