데이터 삭제 처리(data redaction)는 가장 오래된 데이터 보호 방식입니다. 값을 빼내고 남은 부분을 공개합니다. 법무팀은 증거 개시 전에 문서에서 이름과 계좌번호를 지웁니다. 공공기관은 기록을 공개하기 전에 삭제 처리를 합니다. 데이터베이스 엔진은 권한이 없는 사용자에게 비우거나 일부만 보이는 값을 돌려주는 삭제 처리 정책을 제공하고, 애플리케이션 팀은 누군가 로그를 읽기 전에 식별자를 지웁니다.
이런 방식의 PII 삭제 처리는 설명하기 쉽고 감사하기도 쉽습니다. 지운 값이 해당 사본에서 사라지기 때문입니다. 이 점이 가까운 두 방식과의 차이이기도 합니다. 데이터 마스킹은 값을 그럴듯한 대체값으로 바꿔 테스트에 쓸 수 있도록 형식을 유지합니다. 가명처리는 값을 대체값으로 바꾸고, 따로 보관한 키로 되돌릴 수 있게 합니다. 삭제 처리는 되돌릴 대상을 아무것도 남기지 않습니다.
AI 업무에서는 바로 이 점이 한계가 됩니다. 삭제된 값은 원래 지니던 관계를 더는 담지 못합니다. 불만 접수가 어느 고객의 것인지, 날짜가 어느 계약을 가리키는지, 어느 두 레코드가 같은 사람을 설명하는지 알 수 없게 됩니다. 삭제 처리된 사본을 받은 모델은 그 맥락이 빠진 채로 답하고, 그 답은 누군가 실제로 조치해야 할 레코드와 연결되지 않습니다.
업무에 그 값이 전혀 필요 없다면 삭제 처리가 적절한 기본 선택입니다. 업무가 값의 의미에 기대고 있다면 의미를 유지하는 대체가 대안입니다. 맥락 인식 비식별화는 텍스트 안에서 값이 하는 역할을 보고 무엇을 지울지 정합니다. 컨텍스트 보존 데이터 레이어는 민감한 값을 모델이 볼 관계를 유지하는 대체값으로 바꾸고, 매핑을 환경 안에 두며, 응답에서 원래 값을 복원합니다. CUBIG의 LLM Capsule이 이 방식으로 작동하며, LLM Capsule vs AI DLP에서 삭제 처리에서 멈추는 도구와 비교합니다.
데이터 삭제 처리는 가명처리와 어떻게 다른가요?
삭제 처리는 값을 지우고 아무것도 남기지 않습니다. 가명처리는 값을 대체값으로 바꾸고, 대체값을 원래 값으로 되돌릴 수 있는 키를 따로 보관합니다. 이 차이에 따라 나머지 데이터로 할 수 있는 일이 정해집니다.
- 삭제 처리: 되돌릴 방법 없이 사본을 공개할 수 있습니다. 지운 값을 거쳐 이어지던 관계도 함께 사라집니다.
- 가명처리: 같은 값을 공유하던 레코드는 같은 대체값을 공유하므로 조인하고 집계할 수 있습니다. 권한 있는 프로세스는 원래 값을 복원할 수 있습니다.
- 맥락 보존 대체(context-preserving substitution): 대체값이 모델에게 값의 의미까지 유지합니다. 예를 들어 날짜는 그럴듯한 날짜로 남습니다. 매핑은 고객 환경 안에 남습니다.
AI 업무에서 데이터 삭제 처리는 어디서 한계를 드러내나요?
고객 지원팀이 답변 초안을 작성하는 모델에 티켓 텍스트를 보내기 전에 고객 식별자를 지웁니다. 초안은 자연스럽게 읽힙니다. 하지만 모델은 티켓 세 건이 같은 계정에서 왔다는 사실을 알 수 없어 각 티켓에 환불을 제안합니다. 상담원도 초안을 업데이트해야 할 고객 레코드와 연결할 방법이 없습니다.
삭제 처리 과정에서 레코드를 묶고, 조인하고, 조치하는 데 필요한 값이 정확히 지워졌습니다. 삭제 처리 전에는 업무가 맥락으로만 쓰는 값과 레코드를 연결하는 데 쓰는 값을 나눠 정리해야 합니다. 앞의 값은 지웁니다. 뒤의 값은 관계를 유지하고 응답에서 복원할 수 있는 대체값으로 바꿉니다. CUBIG의 LLM Capsule은 외부 모델로 가는 데이터를 이 방식으로 처리합니다.