사내 AI 비서 개인정보 마스킹, 문서 넣기 전 지워야 할 기준
RAG나 사내 AI 비서에 문서를 연결하기 전, 원문·로그·첨부파일에서 어떤 개인정보를 가리고 남길지 정리하는 실무 체크리스트입니다.
사내 AI 비서나 RAG 검색을 붙일 때 가장 먼저 떠올리는 것은 “문서를 얼마나 많이 넣을 수 있나”입니다. 하지만 운영 단계에서 더 자주 문제가 되는 질문은 조금 다릅니다.
AI가 답을 잘하는 것보다 먼저, AI에게 보여도 되는 원문과 가려야 할 정보를 구분해야 합니다.
특히 고객 상담 기록, 계약서 초안, 견적 메모, 내부 회의록처럼 사람이 일상적으로 쓰는 문서에는 이름·연락처·계좌·주소·식별번호·민감한 메모가 섞여 있습니다. 이 글은 법률 자문이 아니라, HeyRatty 관점에서 사내 AI 비서 도입 전에 정리해야 할 개인정보 마스킹 운영 기준을 다룹니다.
핵심 요약
- 문서를 바로 RAG에 넣기 전에 “수집 원문, AI 입력용 사본, 보관 로그”를 분리합니다.
- 이름·전화번호 같은 직접 식별자만 보지 말고, 소속·직책·사건 일자처럼 조합하면 특정되는 정보도 점검합니다.
- 마스킹은 한 번의 정규식으로 끝내기보다, 업로드 전 검수·자동 탐지·사후 로그 점검을 나눠 운영합니다.
- AI 답변 품질이 떨어지는 항목은 원문 공개가 아니라 요약본·범주값·권한 필터로 보완합니다.
- 삭제·수정 요청이 들어왔을 때 벡터DB, 원본 저장소, 실행 로그에서 어디까지 지워야 하는지 미리 정해둡니다.
1. 먼저 “AI가 봐야 하는 정보”와 “사람만 봐야 하는 정보”를 나눕니다
개인정보 마스킹을 어렵게 만드는 이유는 정보가 완전히 필요 없어서가 아닙니다. 업무 맥락에는 필요하지만, AI가 원문 그대로 볼 필요는 없는 정보가 많기 때문입니다.
예를 들어 고객 문의 자동분류에는 “구매 후 3일 이내 환불 요청”이라는 맥락이 필요합니다. 하지만 고객의 실명, 휴대폰 번호, 상세 주소 전체가 항상 필요한 것은 아닙니다.
- AI 답변에 꼭 필요한 업무 맥락: 상품명, 요청 유형, 진행 상태, 담당 부서, 처리 기한
- 대체 가능한 정보: 실명 → 고객 A, 전화번호 → 연락처 보유, 주소 → 시/구 단위
- AI 입력에서 제외할 정보: 주민등록번호, 계좌번호, 카드번호, 인증번호, 민감한 개인 사유
처음부터 모든 문서를 “그대로 넣을 수 있는가”로 판단하면 기준이 흐려집니다. “답변에 필요한 최소 정보가 무엇인가”부터 정하면 마스킹 범위가 훨씬 선명해집니다.
2. 직접 식별자보다 “조합 식별자”를 더 조심합니다
운영팀이 흔히 놓치는 부분은 이름이나 연락처처럼 눈에 보이는 정보만 마스킹하는 것입니다. 실제 업무 문서에서는 여러 조각이 합쳐져 한 사람이나 특정 거래를 가리키는 경우가 많습니다.
- 소속 + 직책 + 근무지
- 계약일 + 금액 + 프로젝트명
- 상담 채널 + 문의 시간 + 상품명
- 작은 조직에서의 역할명, 별칭, 내부 코드
이런 정보는 모두 지울 필요는 없지만, AI가 전사 공용 비서로 쓰이는지, 부서 제한 비서로 쓰이는지에 따라 공개 범위를 달리해야 합니다. 같은 문서라도 전사 검색용 색인과 담당자 전용 색인은 다르게 설계할 수 있습니다.
3. 마스킹 룰은 “업로드 전·검색 전·로그 후처리”로 나눕니다
마스킹을 한 단계에 몰아넣으면 놓친 항목을 찾기 어렵습니다. 실무에서는 세 구간으로 나누면 운영이 쉬워집니다.
- 업로드 전: 원본 문서에서 명확한 개인정보 패턴을 탐지하고, AI 입력용 사본을 따로 만듭니다.
- 검색 전: 사용자의 권한·부서·목적에 따라 검색 가능한 문서 묶음을 제한합니다.
- 로그 후처리: 프롬프트, 검색 결과, 답변 로그에 민감정보가 남지 않았는지 주기적으로 샘플링합니다.
정규식 탐지는 시작점일 뿐입니다. 사람 이름, 조직 내 별칭, 프로젝트 코드처럼 패턴이 일정하지 않은 값은 담당 부서의 예시 데이터와 함께 룰을 보완해야 합니다.
4. 답변 품질이 떨어질 때 원문 공개로 해결하지 않습니다
마스킹을 강하게 걸면 AI 답변이 뭉뚱그려질 수 있습니다. 그렇다고 원문을 그대로 풀어버리면 운영 리스크가 커집니다. 이때는 아래 우회 설계를 먼저 검토합니다.
- 상세 원문 대신 승인된 요약본을 색인합니다.
- 금액·연령·지역은 정확한 값보다 구간값으로 바꿉니다.
- 민감한 필드는 답변에 직접 쓰지 않고 “담당자 확인 필요”로 넘깁니다.
- 부서별 권한이 다른 문서는 메타데이터 필터를 먼저 적용한 뒤 검색합니다.
- 답변 출처에는 원문 전체가 아니라 문서 제목, 섹션, 업데이트 일자만 노출합니다.
5. 삭제 요청과 문서 수정 흐름까지 같이 정합니다
AI 비서가 문서를 한 번 읽고 끝나는 구조라면 단순합니다. 하지만 RAG는 원본 저장소, 임베딩, 캐시, 대화 로그, 운영 대시보드가 함께 움직입니다. 그래서 삭제나 수정 요청을 받았을 때 어느 저장소를 다시 처리해야 하는지 정해두어야 합니다.
- 원본 문서 위치: Notion, Drive, Slack export, CRM, NAS 등
- AI 입력용 사본 위치: 전처리된 텍스트, 청크 파일, 임베딩 전 중간 파일
- 검색 인덱스 위치: 벡터DB, 검색DB, 캐시
- 실행 로그 위치: 프롬프트, 검색 결과, 답변, 오류 로그
이 경로가 없으면 “문서는 지웠는데 AI가 여전히 답하는” 상황이 생길 수 있습니다. 반대로 경로가 있으면 특정 문서의 재색인, 로그 보존기간, 삭제 확인까지 운영 절차로 만들 수 있습니다.
실무 체크리스트
- AI가 처리할 문서 유형별로 개인정보 포함 가능성을 표시했는가?
- 직접 식별자와 조합 식별자를 나눠 마스킹 기준을 적었는가?
- 원본 문서와 AI 입력용 사본을 같은 저장소에 섞어두지 않았는가?
- 사용자 권한에 따라 검색 가능한 문서 범위가 달라지는가?
- 프롬프트·검색 결과·답변 로그에 민감정보가 남는지 샘플링하는가?
- 삭제·수정 요청이 들어오면 원본, 인덱스, 캐시, 로그를 어디까지 처리할지 정했는가?
- 마스킹 때문에 답변 품질이 떨어지는 항목을 요약본·구간값·담당자 확인 흐름으로 보완했는가?
자주 묻는 질문
Q. 모든 개인정보를 지우면 AI 비서가 쓸모없어지지 않나요?
전부 지우는 것이 목표가 아닙니다. 업무 판단에 필요한 맥락은 남기고, 개인을 직접 식별하거나 불필요하게 노출되는 값을 줄이는 것이 목표입니다. “최소한의 업무 맥락”과 “원문 접근 권한”을 분리하면 품질과 안전을 함께 맞출 수 있습니다.
Q. 정규식으로 전화번호와 이메일만 지우면 충분한가요?
출발점으로는 좋지만 충분하지 않은 경우가 많습니다. 이름, 별칭, 소속, 사건 일자, 프로젝트 코드처럼 패턴이 일정하지 않은 정보도 조합되면 특정인을 가리킬 수 있습니다. 그래서 샘플 문서 기반 검수와 권한 필터가 함께 필요합니다.
Q. 이미 운영 중인 RAG에도 적용할 수 있나요?
가능합니다. 먼저 최근 답변 로그와 검색된 문서 샘플을 보고 민감정보 노출 가능성을 분류합니다. 이후 새 문서부터 전처리 룰을 적용하고, 기존 인덱스는 우선순위를 정해 재처리하는 방식이 현실적입니다.
HeyRatty가 도와드릴 수 있는 부분
HeyRatty는 사내 AI 비서나 RAG 자동화를 만들 때, 단순히 챗봇 화면만 붙이지 않습니다. 어떤 문서를 넣을지, 어떤 정보는 가릴지, 누가 어느 범위까지 검색할지, 실패했을 때 로그를 어떻게 볼지까지 함께 설계합니다.
우리 회사 문서를 AI에 연결해도 되는지 막막하다면, 먼저 문서 유형과 업무 흐름을 함께 점검해보는 것부터 시작할 수 있습니다.
참고 및 이미지 출처
- Wikimedia Commons: Privacy icon.svg · Author: GDJ · License: CC0 1.0
- NIST SP 800-122: Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)
- 개인정보 포털: 개인정보보호 관련 안내 자료