P2 노출 가드 — 표준답변·안내글의 고객 챗봇 노출 개인정보·비공개 가드 정본

최초 작성 — 2026-06-18 · 개인정보보호관리자(privacy-officer) · Phase 2 고객 챗봇이 표준답변(hp_standard_answer)·안내글(hp_announce)을 인용·노출하기 전 적용해야 할 PII 마스킹·비공개 출처 차단·직원 내부표현 필터·승인 게이트의 정본

갱신 — 2026-06-19 · privacy-officer · 재큐레이션 복원 스크린샷(이미지) PII 검수 기준 확정(§4-A)·승인 게이트 이미지 필수 체크(§4-2)·PII 게이트 상태 컬럼(§4-B)·텍스트 정규식 보강(§2-1). 배경: created_by='llm-curator-v3' approved 580건 중 이미지 보존 345건(51.3%) — 본문 텍스트는 마스킹됐으나 스크린샷 속 PII는 자동 제외되지 않음(사람 검수 필수)

이 문서가 해소하는 미정 항목(다른 정본이 본 문서에 위임):

• REQUIREMENTS.md FR-10.3 · NFR-6.3 · §7 Q3 (비공개 자료 마스킹·노출 세부 규칙)
• PMS-INQUIRY-HARVEST.md §7-2 H8 · §9-E (안내글 P2 노출 가드)
• STANDARD-ANSWER-CURATION.md §7-2 T8 · §8-D · §9-E (비공개 출처 표준답변 P2 노출 가드)

포지셔닝: 수집·분류·승인 워크플로 자체는 위 두 정본이 정본이다. 본 문서는 그 워크플로에 개인정보·비공개 노출 관점의 가드(검사 규칙·승인 체크리스트·차단 조건·적법성) 만을 얹는다. 실제 마스킹 파이프라인·승인 UI·자동 스캔 구현은 §8 핸드오프로 api/admin/dba에 넘긴다(본 문서는 코드를 만들지 않는다).

1. 위협 모델 — 무엇이 어디서 새는가

표준답변·안내글은 PMS 문의/직원 안내글에서 수집된다(출처 source_post_id). 본문(answer/body)·이미지·출처 메타에 다음이 섞여 들어올 수 있다.

핵심 원칙: 승인(approval_status='approved')은 챗봇 사용의 필요조건이지 PII 안전의 충분조건이 아니다. 승인 단계에 PII·비공개 가드를 명시적으로 끼워 넣지 않으면 "승인됨 = 그대로 노출"이 되어 L1·L3·L5·L6이 그대로 흐른다.

2. 노출 가드 규칙 (챗봇 인용·노출 전 검사)

표준답변/안내글이 P2 고객 챗봇 응답에 인용·노출되기 전 아래 4중 가드를 통과해야 한다. 1차는 승인 시점(저장 게이트), 2차는 노출 시점(런타임 가드) — 이중화한다(승인 후 본문 수정·정규식 갱신을 흡수).

2-1. G1 — PII 마스킹 (본문·캡션, hp_setting safety 재사용)

• 재사용 자산: hp_setting safety 그룹의 pii_masking(on/off) + pii_patterns. 현 시드는 3종뿐(주민번호 \d{6}-[1-4]\d{6} · 전화 \d{3}-\d{3,4}-\d{4} · 이메일 정규식). 별도 정규식 세트를 새로 만들지 않고 이 시드를 정본으로 공유한다(REQUIREMENTS NFR-1 AC-1.3·§9 safety 시드와 정합).
• 보강 필요 패턴(현 시드 미포함 → 3종에서 6종으로 — §8 dba/api 핸드오프, §7-2 P5):
  • 사업자등록번호 \d{3}-\d{2}-\d{5} — 마스킹 대상 추가([사업자번호]). 고유식별정보는 아니나 법인·개인사업자 식별이 가능하므로 마스킹한다.
  • 계좌번호 — 은행별 자릿수가 제각각이라 단일 정규식 오탐이 크다. 보수적 패턴 + "계좌/입금/예금주" 키워드 근접으로만 후보화하고, 최종 판정은 C2 사람 검수가 보완한다.
  • 카드번호 \d{4}-\d{4}-\d{4}-\d{4} — 16자리 하이픈 구분 형태. 일반 숫자열 오탐을 줄이기 위해 키워드 근접(카드/승인번호)으로 보강하고 C2 사람 검수가 보완한다.
  • (기존) 이름+연락처 근접 결합.
• 계좌·카드는 정규식 단독으로 오탐/미탐이 큰 영역이라 자동 마스킹의 신뢰도가 낮다 → 키워드 근접으로 후보를 좁히되 최종 안전판은 §4-2 C2 사람 검수로 둔다.
• 적용 면: answer/body 본문 + 인용 이미지의 description 캡션 + 출처 표기 문자열. 임베딩 생성 입력에도 동일 적용(마스킹 후 임베딩 — 그래야 벡터·국외전송에 PII가 남지 않는다, L7).
• 마스킹 표기: 값 자체를 제거하고 [연락처]·[이메일]·[사업자번호] 류 플레이스홀더로 치환(부분 노출 010-****-1234는 재식별 위험 — 전체 치환 권장).
• 고유식별정보 특칙: 주민등록번호가 발견되면 마스킹이 아니라 해당 표준답변/안내글을 차단(노출 불가) 후 운영자 알림. 주민번호는 원칙적 처리 금지 대상이라 "마스킹해서 노출"이 아니라 "원천 제거 후 재검토"가 맞다(개인정보보호법 §24의2).

2-2. G2 — 비공개 출처 파생 차단 (L3·L4)

• 차단 조건: 표준답변/안내글의 source_post_id가 가리키는 원 게시물의 답변이 비공개 댓글(private_yn='Y')에서 파생됐으면 → P2 노출 후보에서 제외. 비공개 댓글 본문은 이미 api에서 LLM 입력·외부 반환이 차단돼 있으나(src/index.ts private_yn != 'Y' 필터·content: isPrivate ? null), 수집 단계에서 비공개 내용이 사람 손으로 본문에 옮겨졌을 가능성을 승인 게이트에서 사람이 확인해야 한다(자동 탐지 불가 영역).
• 비공개 출처 플래그(C1 자동): source_post_id가 비공개 댓글에서 파생된 자산이면 C1 자동 스캔이 private_source_flag를 세운다. 이 플래그는 자동 차단이 아니라 승인 화면에 경고를 띄워 사람 확인을 강제하는 신호다(일반화 녹임 여부는 자동 판정 불가이므로 C2 승인자가 §4-2 체크리스트에서 직접 판단). 컬럼은 §4-B에 정의.
• 출처 표기 마스킹(L4): P2 응답에 출처를 노출할 때 원 게시물 ID·프로젝트명·고객사명을 그대로 인용하지 않는다. 출처는 "검증된 표준답변" 수준의 일반화된 라벨만 노출(예: 토픽·서비스 라벨). source_post_id는 admin 내부 역추적 전용이며 P2 응답 페이로드에 포함 금지.
• 봇 가시성 연계: FR-10 AC-10.1 — P2 고객 노출 봇은 visibility=public 고정(ADMIN-PLAN §4-13). 비공개 파생 표준답변은 internal 봇(상담사 보조)에서만 허용.

2-3. G3 — 직원 내부표현 필터 (안내글 특유, L5)

안내글은 staff가 작성한 글이라 고객 직접 노출이 부적절한 표현이 섞인다. §3에서 상술.

2-4. G4 — 교차 고객/일반화 검증 (L6)

• 본문이 특정 1개 고객·계약·1회성 사례에 묶여 있으면 P2 노출 부적합 → 일반화(고객 식별정보 제거·범용 안내문 재작성)된 버전만 승인. CURATION §5-1 "재사용성" 판단과 동일 게이트에서 PII 관점을 함께 본다.
• 한 표준답변에 원 문의자 외 제3 고객이 언급되면(L6) 무조건 차단·재작성.

3. 안내글(hp_announce) 특유 위험과 가드

안내글은 직원(staff) 작성 공지·안내문이라 Q&A와 위험 프로파일이 다르다. HARVEST §5-3에서 안내글을 별도 테이블·별도 승인 메뉴로 분리했으므로, 안내글 승인 게이트에 아래 3종 추가 검사를 둔다.

• 안내글 출처·말투 가드(H8): 안내글이 P2에 노출될 때는 "검증된 안내"로 일반화된 말투로만 인용하고, 원 작성 직원·내부 게시물을 출처로 노출하지 않는다. 안내글의 valid_from/valid_to(유효기간) 경과분은 P2 노출 후보에서 자동 제외(노후 정책의 고객 오안내 방지).
• 분류 근거 가드: 안내글/표준답변의 staff·customer 분류는 classify.ts의 명시 규칙(@malgnsoft.com / company='맑은소프트')만 사용한다. 이름·말투·도메인 패턴으로 개인을 추정해 분류하지 않는다(추정 금지 — HARVEST §5-5 프롬프트 규약과 정합).

4. 승인 워크플로 연계 — 어디에 게이트를 두는가

approval_status 전이(draft → reviewing → approved, CURATION §3-3) 중 reviewing → approved 전이에 PII/노출 체크를 강제한다. 3계층으로 둔다(자동 스캔 + 사람 체크리스트 + 런타임 가드).

4-1. 계층별 책임

C2(사람)는 책임 소재를 명확히 한다 — 승인자가 체크리스트에 체크하면 그 표준답변/안내글의 P2 노출 적합성에 대한 승인자 책임이 감사 로그(hp_audit_log)에 기록된다(누가·언제 승인). agent는 승인 권한이 없으므로(CURATION §1-3) PII 게이트의 최종 책임은 admin/developer.

4-2. 승인 체크리스트 (admin UI 필수 체크박스)

reviewing → approved 전이 시 승인자가 확인:

• 본문·이미지 캡션에 이름·연락처·이메일·주소·사업자번호 등 PII가 없다(또는 마스킹됨). 자동 스캔 하이라이트 0건 또는 검토 완료.
• 주민등록번호 등 고유식별정보가 없다(있으면 승인 불가 — 원천 제거 후 재상신).
• (이미지 보유 시) 인용 이미지/스크린샷 PII 검수(§4-A)가 완료되어 모든 인용 이미지의 image_pii_status ∈ clear/removed/masked 다(롤업 기준 동일). pending·suspect·blocked가 하나라도 포함되면 승인 불가. 이 항목 미체크 시 승인 버튼 비활성.
• 비공개 댓글(private_yn='Y')에서 파생된 내용이 본문에 없다(출처 게시물 확인). private_source_flag 경고 시 본문 일반화 녹임 여부 직접 확인.
• 원 문의자 외 제3 고객 정보가 인용되지 않았다(교차 노출 L6).
• (안내글) 특정 고객사·계약·내부 가격/정책·"비공개" 표현이 없다(또는 일반화됨).
• 출처로 원 게시물 ID·프로젝트·고객사명이 노출되지 않는다(일반화 라벨만).
• (안내글) 유효기간이 유효하다(만료 공지를 P2에 승인하지 않음).

체크리스트 전 항목 통과 시에만 approved. 하나라도 불확실하면 반려(rejected, 사유 필수) 또는 internal 한정 승인(상담사 보조 전용, P2 비노출).

이미지 게이트는 하드 게이트다 — 이미지 보유 자산은 image_pii_status 롤업(인용 이미지 최악값, §4-B)이 clear/removed/masked가 아니면 admin UI에서 승인 버튼이 비활성화되며 강제 우회 불가. 승인자·판정 결과는 감사 로그(hp_audit_log)에 누가·언제 기록.

4-3. 단정 불가 영역 (법무/DPO 확인 필요)

• 비공개 댓글 내용이 일반화돼 본문에 녹은 경우 자동 탐지 불가 — 사람 판단 의존. 운영 중 누락 사례가 발견되면 법무/DPO와 일반화 허용 경계를 재합의.
• 사업자번호·법인명의 "개인정보" 해당 여부는 개인사업자 여부에 따라 갈린다 — 법무/DPO 확인 필요. 본 정책은 보수적으로 마스킹 대상에 포함.

4-A. 이미지/스크린샷 PII 검수 기준 (L2 — 사람 검수 기본)

표준답변/안내글이 인용하는 이미지(hp_image_asset)에는 관리화면 스크린샷·고객 명단 표·캡처 등이 섞이며, 본문 텍스트와 달리 정규식 마스킹이 닿지 않는다. 재큐레이션 복원 자산 580건 중 345건(51.3%)이 이미지를 보존하고 있고, 본문 텍스트는 마스킹됐어도 스크린샷 속 PII는 자동 제외되지 않았다. 따라서 이미지 PII 검수의 기본은 사람 검수다(사용자 방침).

• Vision 자동은 검수 보조(트리아지)일 뿐 자동 통과 금지. Vision 1차는 사람 검수 우선순위를 매기는 트리아지로만 쓴다. Vision이 "PII 없음"으로 본 것을 근거로 자동 통과시키지 않는다 — Vision 미탐(false negative) = PII 노출이므로, 자동 통과는 미탐 리스크를 그대로 떠안는다.

처리 순서 (I1→I2→I3)

검수 체크리스트 (값 전사 금지 — 유형·위치만 기록)

검수자는 화면에 보이는 PII 값을 절대 텍스트로 옮겨 적지 않는다(전사 자체가 2차 노출). 발견 시 유형 라벨과 위치(이미지 ID·대략 영역)만 기록한다.

• 인명·연락처·이메일·주소가 화면에 보인다
• 고객 명단·표(여러 고객 행이 한 번에 노출되는 관리화면 리스트)가 보인다
• 계좌·카드·사업자번호가 보인다
• 주민등록번호 등 고유식별정보가 보인다 → 있으면 즉시 blocked·제외(마스킹 아님, §2-1·5-3 고유식별정보 특칙 동일)
• 내부 관리화면(고객 비노출 전용 화면)이 그대로 캡처돼 있다
• 제3자 정보가 교차 노출된다(원 문의자 외 고객, L6)
• 일반 조작안내(메뉴·버튼 위치 등)로서 적합한가 — 적합하면 clear 후보

판정 규칙

• clear — PII 없음·일반 조작안내로 적합. (단, 사용자 방침상 Vision 단독 clear는 금지, 사람 판정 필요)
• masked — 일부 PII 영역을 가린 처리본으로 교체하면 노출 가능
• removed — 가림으로 해결 불가하거나 이미지가 본질적으로 명단/내부화면 → 인용 이미지 자체를 답변에서 제거
• blocked — 고유식별정보 포함 등 노출 절대 불가 → 자산 차단·운영자 알림

국외 이전 유의(Vision 1차): I1은 이미지를 AI Gateway→OpenAI(국외) 로 보낸다 = 개인정보 국외 이전(§5-2 L7과 동일 쟁점). Vision 프롬프트에 값을 전사하도록 요구하지 않으며(유형·위치만 반환), Gateway 프롬프트/응답 로그에 PII가 잔존하지 않는지 api-developer가 점검(§7-2 P7).

표본 검수 운영(cs-operator): (1) 이미지 보유 345건은 100% I1 1차 큐에 적재해 사람 검수 대상으로 올린다. (2) clear 판정분은 무작위 재검수(주 10~20% 표본)로 미탐을 사후 회수. (3) 신규 인용 승인 전 동일 게이트(I1→I3)를 통과시켜 백필 이후 유입분도 동일 기준 적용.

4-B. PII 게이트 상태 컬럼 (DB 영속화 — §8 dba 핸드오프)

승인 게이트(C1·C2)와 이미지 검수(§4-A) 결과를 영속화하는 컬럼. 컬럼 ENUM 값은 최종 통합본으로 고정한다.

• 롤업 규칙: 답변/안내글의 image_pii_status = 인용한 이미지들의 image_pii_status 중 최악값. 우선순위(나쁨→좋음): blocked > pending > suspect > removed/masked/clear. 이미지가 없으면 none. 승인은 롤업이 clear/removed/masked(또는 none)일 때만 가능(§4-2).
• MySQL 5.6 제약: 실서버 MySQL 5.6은 JSON 타입을 지원하지 않으므로 pii_finding_types는 LONGTEXT(콤마 구분 라벨 또는 JSON 문자열)로 저장한다.
• 백필: 재큐레이션 580건은 텍스트 pii_text_status='pending'으로, 이미지 보유 345건의 이미지 자산은 image_pii_status='pending'으로 백필 후 §4-A 게이트를 거쳐 확정한다.

5. 적법성 (한국 개인정보보호법·정보통신망법)

5-1. 수집·인용의 근거 (원 문의자 동의 범위)

• PMS 문의·답변은 상담·고객지원 목적으로 수집된 개인정보다. 이를 표준답변/안내글 자산으로 2차 가공해 챗봇에 노출하는 것은 원 수집 목적(해당 고객 상담)과 다른 목적일 수 있다 → 목적 외 이용 소지.
• 완화책: 표준답변/안내글은 개인 식별정보를 제거한 일반화 형태(가명/익명화) 로만 P2에 노출한다. 식별정보가 제거되면 더 이상 특정 개인의 개인정보가 아니므로 목적 외 이용 쟁점이 해소된다. → §2~4 가드의 적법성 근거 = "P2 노출본은 식별정보 없는 일반화본"이 전제.
• 식별정보를 제거할 수 없는(특정 고객사에만 유효한) 답변은 P2 노출 부적합 → internal 한정. 위험도 high, 정보주체 범위 = 원 문의 고객.

5-2. 국외 이전 (OpenAI / AI Gateway 경유) — L7

• 챗봇 매칭·생성·임베딩 시 본문이 AI Gateway → OpenAI(국외) 로 전송된다 = 개인정보 국외 이전(개인정보보호법 §28의8).
• 가드: P2 노출 후보 본문은 §2-1 마스킹을 임베딩·프롬프트 전송 전에 적용해 PII가 국외로 나가지 않게 한다. 마스킹된 일반화본만 전송되면 국외이전 대상 개인정보가 최소화된다.
• AI Gateway 로깅: Gateway가 프롬프트/응답을 캐싱·로깅하므로(malgn-helper 게이트) 로그에 PII가 남지 않도록 전송 전 마스킹이 선결이다. 로깅 보존기간·PII 잔존 여부는 api-developer와 별도 점검(현행 메모와 동일 포인트).
• 위탁·국외이전 고지/동의: Cloudflare(처리위탁)·OpenAI(국외이전)·AWS는 개인정보처리방침에 위탁·국외이전 항목(수탁자·이전국가·항목·목적·보유기간) 고지가 필요하다. P2 고객 대상 서비스 오픈 전 개인정보처리방침 정비 필요 — 위험도 high, 법무/DPO 확인 필요.

5-3. 보존기간·파기

• 민감정보·고유식별정보(주민번호 등)는 자료·로그에서 발견 시 즉시 제거·차단(보존 대상 아님). 위험도 critical.

6. 위험도·정보주체 범위 요약

7. 결정 사항 (이 문서로 확정) / 미정

7-1. 결정

7-2. 미정 (법무/DPO·후속 협의)

8. 핸드오프 — 후속 작업 (코드는 담당 에이전트가 구현)

9. 정합 — 다른 정본과의 관계