자체 호스팅 PII 도구가 컴플라이언스 감사에서 실패하는 이유
GDPR은 증거를 요구합니다. PII 제거가 항상 동일한 방식으로 이루어졌다는 것을 증명해야 합니다. DPA 감사관들은 이를 확인합니다. 모든 데이터에 걸쳐 명확하고 일관된 방법이 사용되었다는 증거를 원합니다.
자체 호스팅 Presidio는 이 부분에서 실질적인 문제를 안고 있습니다. 설정 문제가 아닙니다. 자체 호스팅 NLP 도구의 근본적인 한계입니다.
환경 드리프트란 무엇인가?
자체 호스팅 Presidio는 개발(dev), 스테이징(staging), 프로덕션(production) 환경에서 실행됩니다. 각 환경은 서로 다르게 동작할 수 있습니다. 따라서 동일한 입력이 각 환경에서 다른 결과를 낼 수 있습니다.
이를 환경 드리프트라고 합니다. 네 가지 주된 원인이 있습니다.
모델 버전 드리프트
spaCy 모델은 버전이 있습니다. en_core_web_lg 3.4.4와 en_core_web_lg 3.5.1은 서로 다른 데이터로 학습되었습니다. 설계도 다릅니다. 따라서 동일한 문서가 각 버전에서 서로 다른 NER 결과를 낼 수 있습니다.
일반적인 설정은 다음과 같습니다.
- 개발:
en_core_web_lg 3.4.4— 프로젝트 시작 시 설치 - 스테이징:
en_core_web_lg 3.5.0— 정기 작업 중 업데이트 - 프로덕션:
en_core_web_lg 3.5.1— 보안 패치 중 업데이트
세 가지 설정, 세 가지 모델 버전, 세 가지 다른 탐지 결과입니다. 스테이징에서는 테스트가 통과합니다. 하지만 프로덕션은 다른 모델을 실행합니다. 그래서 격차가 숨겨진 채 남아 있습니다.
의존성 버전 드리프트
spaCy 3.4.x와 3.5.x는 문장 분리 방식이 다릅니다. 그 변화는 문장 경계 근처에서 이름이 찾히는 방식에 영향을 줍니다. 이러한 변경 사항은 spaCy 릴리스 노트에 있습니다. 하지만 대부분의 팀은 PII 영향에 대해 확인하지 않습니다.
설정 드리프트
개발 환경에서 설정된 점수 임계값이 프로덕션에 반영되지 않을 수 있습니다. 커스텀 단어 목록도 환경별로 다를 수 있습니다. 이러한 격차는 흔합니다. 추적되는 경우는 드뭅니다. 감사관이 무엇을 확인하는지는 GDPR 준법 가이드를 참조하세요.
하드웨어 차이
NLP 모델의 수학 연산은 모든 CPU와 GPU에서 동일하지 않습니다. 개인 노트북과 서버는 약간 다른 점수 결과를 낼 수 있습니다. 그래서 특정 이름이 한 기기에서는 탐지되지만 다른 기기에서는 그렇지 않을 수 있습니다.
실제 감사 발견 사례
한 은행이 자체 호스팅 Presidio 설정을 테스트했습니다.
테스트 환경: 스테이징 클러스터에서 spaCy 3.4.4로 Presidio 실행. 실제 환경: 프로덕션 클러스터에서 spaCy 3.5.1로 Presidio 실행.
동일한 문서 세트를 두 환경 모두에 실행하고 결과를 비교했습니다. 발견: 문서의 3%에서 PII 제거 결과가 달랐습니다. 일부 이름은 스테이징에서 잡혔지만 프로덕션에서는 그렇지 않았습니다. 일부는 탐지된 텍스트 범위가 달랐습니다.
감사 결과는 직접적이었습니다. "해당 회사는 환경별 탐지 결과 차이로 인해 기술적 PII 제거 조치의 일관된 사용을 증명할 수 없습니다."
GDPR 제32조는 적절한 기술적 조치를 요구합니다. EDPB의 PII 제거 관련 규정은 일관성과 반복 가능성을 요구합니다. 월 100,000건의 문서 중 3%는 매월 3,000건의 일관성 없는 처리를 의미합니다. 일부는 미탐입니다. 스테이징에서 잡혔을 PII가 실제 출력에 그대로 남는 것입니다. 이는 컴플라이언스 위반입니다.
이 은행은 이후 관리형 SaaS로 전환했습니다. 감사 결과가 해소되었습니다. 관리형 설정이 이 문제를 어떻게 처리하는지는 보안 및 컴플라이언스 페이지를 참조하세요.
관리형 서비스가 다른 이유
관리형 서비스는 하나의 엔진 버전으로 실행됩니다. 모든 사용자가 동시에 동일한 버전을 사용합니다. 모델 업데이트는 한 곳에서 적용됩니다. 설정도 전체 변경 이력과 함께 한 곳에서 관리됩니다. 사용자 하드웨어는 결과에 영향을 주지 않습니다.
따라서 오늘 처리된 동일한 문서는 다음 달에도 동일한 결과를 냅니다. 엔진 버전이 변경되었다면 해당 변경 사항은 기록되고 버전화됩니다.
감사 추적의 차이가 핵심입니다.
자체 호스팅 감사 추적:
- "Ubuntu 22.04에서 spaCy
en_core_web_lg 3.5.1과 함께 Presidio 2.2.35를 사용했습니다." - 스테이징과 동일한 버전이었습니까? 불분명합니다.
- 이 문서가 처리된 이후 모델이 변경되었습니까? 추적하지 않으면 알 수 없습니다.
- 점수 임계값이 테스트와 동일합니까? 설정 관리에 달려 있습니다.
관리형 서비스 감사 추적:
- "anonym.legal API, 엔진 버전 4.22.1, 2025-03-15T14:22:31Z."
- 모든 사용자에게 동일한 버전? 예.
- 변경되었습니까? 엔진 버전은 고정됩니다. 버전 4.22.1은 항상 동일한 엔진을 의미합니다.
- 설정이 반복 가능합니까? 예. 프리셋 ID가 기록됩니다. 해당 버전의 설정은 언제든 조회 가능합니다.
관리형 추적은 명확합니다. 자체 호스팅 추적은 대부분의 팀이 생략하는 꼼꼼한 관리를 필요로 합니다.
자체 호스팅의 일관성을 높이는 방법
자체 호스팅이 필요하다면 네 가지 방법으로 드리프트를 줄일 수 있습니다.
첫 번째, 모델 버전을 고정합니다. 모든 배포 파일에 정확한 모델 버전을 잠급니다. 자동 업데이트를 차단합니다. 버전을 소스 컨트롤에서 추적합니다.
다음으로, 컨테이너 이미지를 고정합니다. 정확한 모델 버전이 내장된 Docker 이미지를 빌드합니다. 각 이미지에 모델 버전, Presidio 버전, 날짜를 태그로 붙입니다. 먼저 테스트 없이 기본 이미지를 업데이트하지 않습니다.
또한, 설정을 코드로 관리합니다. 모든 Presidio 설정을 버전 컨트롤로 추적하는 파일에 저장합니다. 탐지기, 점수 임계값, 활성 언어가 포함됩니다. 설정을 앱과 함께 배포합니다.
마지막으로, 환경 간 테스트를 수행합니다. 업데이트 후 고정된 테스트 문서 세트를 새 환경에 실행합니다. 결과를 저장된 기준과 비교합니다. 이 확인을 자동화합니다. 자동화된 PII 회귀 테스트에 관한 일반적인 질문은 FAQ를 참조하세요.
이러한 조치는 도움이 됩니다. 하지만 추가 작업도 따릅니다. 관리형 서비스는 추가 노력 없이 동일한 일관성을 제공합니다.
결론
일관된 PII 제거는 제품 시트에 나오지 않습니다. 하지만 감사관이 증거를 요구할 때 매우 중요해집니다.
적극적인 관리가 없으면 자체 호스팅 PII 도구는 드리프트됩니다. 버전 변경이 눈에 띄지 않는 격차를 만듭니다. 그 격차가 감사 결과로 나타납니다.
관리형 서비스는 기본적으로 일관성을 제공합니다. 엔진이 한 곳에서 실행됩니다. 사용자 설정은 결과에 영향을 주지 않습니다. 컴플라이언스 중심 팀에게 이는 직접적인 장점입니다.