# 필터 설정 가이드 (관리자용)
코어핀 필터를 처음 설정하는 관리자와 임직원 안내 자료를 만드는 분을 위한 문서입니다. **무엇을 어떤 기준으로 판단하는지**, **어떻게 설정하는지**, **차단됐을 때 사유를 어디서 보는지**를 다룹니다.
## 1. 한눈에 보기
| 필터 | 하는 일 | 결과 | 차단 여부는 누가 정하나 |
|---|---|---|---|
| 개인정보 | 이름·주민번호·전화번호 등 19종 개인정보 찾기·마스킹 | 카테고리별 위치·건수, 마스킹 본문 | 마스킹 대상 카테고리를 정책으로 지정 |
| 문서보안 | 문서 **등급**(6단계)과 **유형**(11종) 분류 | 등급·유형·신뢰도 | 차단할 등급·유형을 정책으로 지정 |
| 유해발화 | 욕설·혐오·위협·프롬프트 인젝션 등 11개 라벨 | 라벨·차단 여부 | 차단할 라벨을 정책으로 지정 |
| 정신건강 | 자살·자해 등 10개 축 위험 신호 | 위험 수준·권고 조치 | **차단이 아니라 알림·안내** |
핵심은 이것입니다. **코어핀 필터는 「판정」을 내고, 「차단」은 설정한 정책(또는 파트너 콘솔의 관리자 설정)이 결정합니다.** 판정이 왜 그렇게 나왔는지는 응답의 `explanation` 에 들어 있습니다 → 「판정 사유 API」 문서.
## 2. 설정은 어디서 하나요
1. **코어핀 대시보드 → 설정 → 필터 정책**: 조직·앱(프로젝트) 단위 기본 정책입니다. 변경은 다음 호출부터 바로 적용됩니다.
2. **API 호출 파라미터**: 파트너 서비스(예: 웍스AI 관리자 콘솔)가 관리자가 고른 값을 호출마다 넘깁니다.
| 파라미터 | 의미 |
|---|---|
| `pii_mask` · `pii_categories` | 개인정보 마스킹 켜기 · 마스킹할 카테고리 |
| `dlp_grade` · `dlp_grades` · `dlp_types` | 문서보안 분류 켜기 · 보고할 등급 · 보고할 유형 |
| `moderation_check` · `moderation_labels` | 유해발화 검사 켜기 · 보고할 라벨 |
| `mental_health_check` · `mental_health_axes` | 정신건강 검사 켜기 · 알림 대상 축 |
목록을 주면 **그 대상만 보고**합니다. 예를 들어 `dlp_grades=CONFIDENTIAL,RESTRICTED` 면 문서가 ‘내부’ 로 분류됐을 때 `grade=null` 로 응답하고, `explanation.dismissed` 에 「모델 등급은 내부이지만 대상 등급이 아니라 미해당 처리」 라고 남습니다.
## 3. 문서보안 필터 — 등급·유형 기준
### 어떻게 판단하나요
- 분류 모델이 문서 **앞부분(약 512토큰, 한글 기준 천 자 안팎)** 의 내용·형식을 읽고 6등급과 11유형을 판단합니다. 키워드 목록과 대조하는 방식이 아니라 문서 전체의 맥락을 보는 모델입니다.
- 신뢰도가 낮으면 심층 검증 모델이 한 번 더 판단합니다.
- 단, **보안 표식**(‘대외비’·‘영업비밀’ 등)이 문서 어디에든 있으면 해당 등급 이상으로 올립니다. 이것만 고정 규칙입니다.
- 개인정보를 마스킹해도 등급·유형은 바뀌지 않습니다. 개인정보 필터와 문서보안 필터는 서로 다른 것을 봅니다.
### 6등급
| 등급 | 기준 | 예시 | 일반적 처리 |
|---|---|---|---|
| 공개 `PUBLIC` | 이미 공개됐거나 공개해도 되는 문서 | 보도자료, 공시·IR 자료, 채용 공고 | 제한 없음 |
| 내부 `INTERNAL` | 사내 일반 업무 문서. 외부 공유는 부적절 | 회의록, 업무 보고, 사내 공지, 교육 자료 | 사내 공유 가능 |
| 기밀 `CONFIDENTIAL` | 특정 부서·직급만 봐야 함. 유출 시 거래·평판 불이익 | ‘대외비’ 문서, 미공개 사업 계획·단가 협상 자료 | 접근 권한자만, 외부 전달은 승인·NDA |
| 제한 `RESTRICTED` | 임원·법무·감사 등 제한된 인가자만. 법적·재무적 영향 큼 | 소송·감사·징계 문서, 이사회 보고, 미공시 중요 정보 | 인가자만, 사본 최소화 |
| 영업비밀 `TRADE_SECRET` | 기술·노하우·고객 목록 등 영업비밀 | 핵심 기술 명세, 공정 노하우, 전체 고객 목록 | 반출·전송 금지가 일반적 |
| 특급 `CLASSIFIED` | 법령·규제로 보호되는 최상위 비밀 | ‘극비’·‘Top Secret’ 표식 문서 | 특별 승인, 외부 AI 전달 제외 |
### 11유형
| 유형 | 기준 | 예시 |
|---|---|---|
| 계약·합의 `CONTRACT` | 계약·합의 조건이 적힌 문서 | 계약서, MOU, NDA |
| 재무·실적 `FINANCIAL` | 재무 상태·실적·결산 수치 | 재무제표, 예산·결산 |
| 인수·합병 `M_AND_A` | M&A·지분 거래 등 미공시 영향 정보 | 인수 검토 보고, 지분 양수도 협상 |
| 인사·평가 `HR` | 개인의 인사 기록·평가·처우·징계 | 인사평가서, 징계 자료 |
| 법무·소송 `LEGAL` | 소송·규제 대응·컴플라이언스 | 소송 서면, 법률 자문 |
| R&D·지식재산 `RND_IP` | 연구개발·특허·기술 명세 | 연구 노트, 특허 명세 |
| 전략·기획 `STRATEGY` | 사업 전략·로드맵·시장 진출 계획 | 중장기 전략, 신사업 기획안 |
| 고객 정보 `CUSTOMER` | 거래·계좌·문의 이력 등 고객 정보 | 고객 거래 내역, 문의·클레임 이력 |
| 보안·인증 `SECURITY` | 보안 정책·키·인증서·사고 보고 | 보안 점검 결과, 접근 통제 정책 |
| 구매·조달 `PROCUREMENT` | 납품 단가·협력사 거래 조건 | 견적·단가표, 입찰 평가 |
| 공시 분류물 `PUBLIC_CLASSIFIED` | 공시·뉴스·홍보 (보안 유형 아님) | 공시, 보도자료 |
### 보안 표식 규칙 (고정 규칙)
| 표식 | 최소 등급 |
|---|---|
| 극비 · 1급 비밀 · 특급 비밀 · Top Secret | 특급 |
| 영업비밀 · Trade Secret | 영업비밀 |
| 대외비 · Confidential · Strictly Private · [기밀] · 기밀문서/자료/등급/취급/구분 | 기밀 |
| 사내한정 · 사내전용 · 내부용 · 내부자료 · 대내용 · Internal Use/Only | 내부 |
글자 사이 공백(OCR 결과)은 허용합니다. 「기밀 유지가 중요합니다」 같은 일반 문장은 표식으로 보지 않습니다. 표식은 등급을 **올리기만** 하고 내리지 않습니다.
### 「과하게 차단된다」 싶을 때
차단되는 문서가 관리자 생각보다 많다면 대개 아래 세 가지입니다.
1. **차단 유형을 너무 많이 골랐다.** 유형을 많이 고를수록 일상 업무 문서가 걸릴 가능성이 커집니다. 정말 막아야 하는 유형만 남기세요.
2. **경계선 점수에서 차단한다.** 유형마다 반응 기준이 다릅니다(현행 모델: 인수·합병 0.33 · 계약·합의 0.35 · 인사·평가 0.39 · 전략·기획 0.48 · 구매·조달 0.49 · 재무·실적 0.51 · 고객 정보 0.58 · 보안·인증 0.59 · 법무·소송 0.70 · R&D·지식재산 0.72). 기준이 낮은 유형은 경계선 문서가 걸리기 쉽습니다. 응답 `reasons[].score` 가 `threshold` 를 막 넘은 값(0.10 이내)이면 경계선입니다. 이런 판정이나 `inputs.confidence_band` 가 `low` 인 판정은 자동 차단 대신 **검토 대기**로 돌리는 것을 권장합니다.
3. **낮은 등급까지 차단한다.** ‘내부’ 까지 막으면 사내 일반 문서가 대부분 걸립니다.
권장 시작점:
| 성향 | 차단 등급 | 차단 유형 |
|---|---|---|
| 보수적(오차단 최소) | 영업비밀 · 특급 | 인수·합병 |
| 균형 | 기밀 · 제한 · 영업비밀 · 특급 | 인수·합병 · R&D·지식재산 |
| 엄격 | 기밀 이상 + 유형 전부 | 기준을 0.10 넘게 초과한 점수만 차단, 나머지 검토 |
운영하면서 차단 기록(`explanation`)을 보고 조정하세요.
## 4. 유해발화 필터
| 라벨 | 의미 | 기본 차단 |
|---|---|:-:|
| M01 여성·젠더 | 여성·젠더 관련 혐오·차별 | |
| M02 인종·국적·지역 | 인종·국적·지역 차별 | |
| M03 정치·이념 | 정치인·이념 진영 모욕·혐오 | |
| M04 종교 | 종교 모욕·혐오 | |
| M05 연령·세대 | 세대 비하·연령 차별 | |
| M06 장애·질병 | 장애·질병 비하 | |
| M07 욕설·비속어 | 욕설·비속어·모욕 | ✓ |
| M08 성희롱·성적 | 성희롱·성적 표현·미성년 관련 위험 표현 | ✓ |
| M09 위협·자해 | 위협·자해·자살 관련 발화 | ✓ |
| M10 프롬프트 인젝션 | 시스템 우회·jailbreak·위해 방법 요청 | ✓ |
| M11 모델 정체 누설 | 응답이 모델 이름·제작사를 직접 노출 | |
- 판단은 ① 표현 규칙(걸린 문구와 위치를 사유로 제공) → ② 빠른 분류기 → ③ 심층 검증 모델 순입니다. 사유의 `basis` 가 `rule` 이면 규칙, `model` 이면 모델 판단입니다.
- **문서 검사는 채팅 입력 검사와 다릅니다.** 문서에서는 AI 에게 시키는 요청 표현이 없는 문장의 「주제 언급」(예: ‘악성코드 감염 예방 수칙’, ‘해킹 사고 대응 매뉴얼’, ‘보이스피싱 예방 교육’)은 위험 방법 요청으로 보지 않고 제외합니다. 제외된 항목은 `explanation.dismissed` 에 근거 문구와 함께 남습니다. 문서에 심어진 지시 무시·시스템 프롬프트 노출 같은 인젝션 서명은 그대로 잡습니다.
- 차단 라벨은 정책(`block_labels`)이나 호출 파라미터(`moderation_labels`)로 바꿀 수 있습니다.
## 5. 정신건강 필터
- 10개 축(자살 사고, 비자살 자해, AI 의존, AI 망상 강화, 정신증 신호, 조증 신호, 섭식장애, 약물·알코올, 현실감 상실, 급성 위기)을 5단계(없음·약함·중간·심각·급성)로 판단하고 권고 조치(모니터링 · 자원 안내 · 운영자 큐 · 임상 검토 · 응급 1393)를 정합니다.
- **차단용이 아닙니다.** 상담 앱·챗봇에서 위험 신호를 운영자에게 알리고 안내 카드를 띄우는 용도입니다. 문서 업로드를 막는 데 쓰려면 `risk_level` 이 `severe` 이상이거나 `recommended_action` 이 `human_review`·`emergency_1393` 일 때만 반응하도록 하세요.
- 문서에서는 표·서식·도면이 아니라 **사람이 1인칭·구어체로 서술한 문장**만 추려 검사합니다. 그런 문장이 없으면 검사를 건너뛰고(`decision: skipped`) 과금도 하지 않습니다.
## 6. 개인정보 필터
- 이름·주소·이메일·전화번호·URL·날짜·계좌·카드번호·비밀정보, 주민등록번호·외국인등록번호·여권·운전면허·사업자등록번호·법인등록번호·건강보험증·차량번호·IP, 회사명·기관명, 금액 — 19종.
- 마스킹할 카테고리는 정책이나 `pii_categories` 로 고릅니다. 고르지 않으면 정책의 차단 카테고리를 따릅니다.
## 7. 임직원 안내용 요약 (그대로 가져다 쓰세요)
> **Q. 문서가 왜 차단됐나요?**
> 문서의 성격(계약·재무·전략·고객 정보 등)이나 ‘대외비’ 같은 보안 표식 때문에 회사 정책에서 막기로 한 등급·유형으로 분류됐기 때문입니다. 차단 기록에서 사유를 확인할 수 있습니다.
>
> **Q. 개인정보를 가렸는데도 막히나요?**
> 네. 개인정보 가리기와 문서 보안 등급 분류는 별개입니다. 문서의 성격이 같으면 개인정보를 가려도 같은 등급으로 분류됩니다.
>
> **Q. 잘못 막힌 것 같아요.**
> 차단 기록의 요청 번호(request_id)와 함께 관리자에게 알려 주세요. 관리자가 사유를 확인하고 필요하면 코어핀에 오탐으로 접수합니다.
>
> **Q. 어떤 문서가 막히나요?**
> 회사가 정한 등급(예: 기밀 이상)과 유형(예: 인수·합병)에 해당하는 문서입니다. 공개·일반 업무 문서는 대체로 통과합니다.
## 8. 오탐 문의 방법
문의할 때 아래를 알려 주시면 가장 빠르게 확인됩니다.
1. 응답의 `meta.request_id`
2. 저장해 둔 `explanation` JSON (또는 `GET /v1/decisions/{request_id}` 결과)
3. 기대한 결과(예: 「공개로 나와야 함」)
`explanation.reasons[].basis` 와 `score`, `dismissed` 를 보면 규칙 때문인지 모델 때문인지 바로 구분되어, 규칙 수정이 필요한지 모델 개선이 필요한지 판단할 수 있습니다.