Comprehend PII와 Medical PHI의 언어·탐지·마스킹 경계

1. 한국어 문서와 한국어 입력 지원은 다르다

Amazon Comprehend의 기능별 표에서 일반 개체·감성 등이 한국어를 포함한 여러 언어를 지원하더라도 개인 식별 정보(personally identifiable information, PII) 개체 감지와 PII 레이블은 영어·스페인어다. Medical의 작동 방식은영어(US-EN) 텍스트만 분석한다고 명시한다. 따라서 ‘한글 문서에 안내가 있고 예문도 한국어이므로 한국어 보호 대상 건강 정보(protected health information, PHI)도 지원’이라는 추론은 잘못이다. 기능 이름, 요청 언어, 실제 원문 언어를 각각 대조해야 한다. 근거: 위 지원 언어·PII·Medical 작동 방식 페이지.

한국어 보험 상담 문서를 LanguageCode=en으로 보내 빈 배열을 받았다고 해서 개인정보가 없다고 판단해서는 안 된다. 영어 번역본을 만드는 경우에도 번역(translation) 과정에서 개인정보가 다른 처리기로 전달되고, 이름과 주소, 숫자, 원문 위치인 오프셋(offset)이 달라질 수 있다. 번역은 미지원 언어에 대한 공식 지원이나 안전성을 보장하는 방법이 아니다. 지원하지 않는 언어는 조직이 승인한 별도 분석, 제한된 기능 또는 사람의 검토(human review)로 처리한다. 여기의 한국어 사례는 설계 예시이며 API 성공을 보여 주는 실습 결과가 아니다.

2. 위치 탐지·문서 레이블·마스킹 결과는 다른 산출물

목적	입력·출력의 의미	주의점
일반 개인 식별 정보(PII)의 위치 탐지	`DetectPiiEntities`는 텍스트에서 개체 유형(entity type), 점수(score), 시작·끝 위치(offset)를 반환한다.	가릴 위치의 후보를 찾는 것이며 원문을 자동으로 삭제하지는 않는다.
PII 유형의 존재 여부 표시	`ContainsPiiEntities`는 텍스트에 포함된 정보 유형의 레이블(label)과 점수(score)를 반환한다.	위치가 없으므로 이 결과만으로 정확한 구간을 마스킹(masking)할 수 없다.
일반 PII의 비동기 마스킹(asynchronous redaction)	S3 입력 문서에서 지정한 PII를 가린 복사본을 S3 출력에 생성한다.	원본, 이전 버전과 백업은 남을 수 있다. 수정본 생성 성공과 데이터 전체 삭제는 다르다.
보호 대상 건강 정보(PHI)의 위치 탐지	`DetectPHI`는 임상 텍스트에서 PHI 유형, `Category`, `Text`, 위치(offset)와 점수(score)를 반환한다.	임상 문서의 모든 개체와 약물 관계를 추출하는 작업과 다르다.
의료 개체(entity)의 전체 분석	`DetectEntitiesV2`는 임상 텍스트에서 의료·PHI 개체, 속성(attribute), 특성(trait)과 관계(relationship)를 반환한다.	더 많은 민감 정보를 생성·보관할 수 있으므로 필요한 최소 수집 범위에 맞는지 확인한다.

일반 PII의 실시간 입력 한도 100KB는 해당 KO 위치 탐지·실시간 API 설명의 UTF-8 텍스트 한도다. 100,000개의 글자, Medical의 한도 또는 모든 배치 파일의 한도로 확대하지 않는다. 실제 경계 바이트 수·SDK 계약은 제품별 검증 잔여다. 임의 청크로 자르면 청크 사이 이름·번호가 분리되어 탐지가 약해질 수 있고 중첩을 주면 비용·중복 탐지가 늘어난다. 원문 좌표로 합치는 로직까지 검증해야 한다.

비동기 마스킹 페이지에는 입력·출력 버킷이 호출 API와 같은 리전이어야 하고, 서비스 역할이 입력 읽기·출력 쓰기 권한을 가져야 한다고 명시돼 있다. ONLY_REDACTION은 수정본을 쓰는 방식이며 유형 이름 치환과 허용한 한 문자 마스킹이 별도로 설명된다. 실시간 위치 탐지 후 앱이 치환하는 설계는 가능하나 그 치환기는 앱의 구현 책임이지 DetectPiiEntities가 수정본을 반환한다고 주장하는 것이 아니다. 위 표의 API 이름은 한국어 안내에서 확인한 이름이며 실행·전체 스키마 검증은 하지 않았다.

3. 점수가 낮은 후보를 버리면 개인정보 누출이 늘 수 있다

Score는 탐지된 후보가 해당 유형이라는 추정 신뢰 수준이다. ‘점수 0.9이면 문서 개인정보 90% 제거’, ‘최대 점수 후보만 지우면 익명화’라는 뜻이 아니다. 위치를 찾지 못한 개인정보는 결과에 나타나지 않으므로 높은 점수 목록만 보아도 미탐률은 알 수 없다. 사람이 표기한 별도 검증 세트에서 종류·언어·문서 양식별 정밀도(Precision)·재현율(Recall)을 평가한다.

Medical의 보호 대상 건강 정보(PHI) 문서는 더 많은 후보를 찾으려면 임계값(threshold)을 낮추는 방법을 고려하고, 규정 준수 용도에는 사람 검토(human review) 등 추가 확인을 권한다. 반면 의료 관계 추출(relation extraction)은 잘못된 값을 업무 사실로 채택하지 않는 것이 중요하므로 더 높은 신뢰 기준을 고려할 수 있다.

추출 결과를 사실로 채택하는 목표와 누출을 막기 위해 잠재적 PII까지 가리는 목표는 손실함수가 다르다. 낮은 후보를 단순 삭제하는 공통 코드를 두 목적에 재사용하지 않는다.

자체 산술 예: 실제 민감 구간 100개 중 92개를 가리고 정상 구간 8개를 추가로 가렸다면 민감구간 재현율 92%, 치환 정밀도 92/100=92%다. 그러나 남은 8개가 서로 다른 문서에 흩어졌는지 한 문서에 모였는지에 따라 문서 단위 누출률은 달라진다. 이 수치는 설명용이지 AWS·강좌 측정치·권장 임계값이 아니다. 사람 검토 비용과 의학적 의미 훼손도 함께 측정한다.

4. 빈 목록과 탐지 실패를 분리하는 처리 계약

애플리케이션은 검사 결과의 상태(status)와 개체 목록(entity list)을 분리해서 다룬다. 성공, 미지원 언어, 잘못된 입력, 권한 거부(access denied), 시간 초과(timeout), 서비스 오류를 구분하고 성공했을 때만 개체 목록을 해석한다. 예외를 잡아 무조건 []를 반환하면 후속 코드는 검사 실패를 ‘PII 없음’으로 오해해 원문을 모델이나 사용자에게 보낼 수 있다. 지원 언어가 맞고 전체 본문을 검사했으며 검사가 성공했는지 확인하기 전에는 보호가 필요한 정보를 표시하거나 전달하지 않는다. 정상적으로 빈 결과를 받아도 ‘탐지된 PII가 없음’이라는 뜻이지 개인정보가 전혀 없다는 수학적 증명은 아니다.

오프셋(offset)으로 민감 정보를 치환할 때는 변경하지 않은 원문을 기준으로 범위를 검증한다. 겹친 범위(overlapping spans)를 처리하고 뒤쪽 위치부터 바꾸면 앞선 치환 때문에 다음 위치가 밀리는 문제를 줄일 수 있다. 일반 PII의 위치는 문자 오프셋(character offset)이므로 UTF-8 바이트 위치(byte offset)와 섞지 않는다. 시작과 끝 위치의 포함 규칙, 런타임의 Unicode 단위, 번역과 정규화(normalization) 후의 좌표 변환은 실제 API 명세와 테스트로 확인한다. 한국어로 번역된 예문과 영어 원문의 JSON Text·오프셋이 함께 제시된 경우에는 같은 문자열의 위치 정보인지부터 확인해야 한다.

실제 PDF 파일을 단순 텍스트 파일처럼 여는 예제 구현의 가정도 별개다. 지원 파서/광학 문자 인식(optical character recognition, OCR) → 원문 페이지·구간 매핑 → 지원 언어 확인 → PII 검사 → 치환 → 누락·의미 검사로 다룬다. 일반 Comprehend의 사용자 지정 분류·개체 일부가 PDF를 받는다고 PII API 전체가 PDF 바이트를 직접 받는 것은 아니다. 원본·변환본·탐지 응답의 Text 필드도 모두 민감 자료가 될 수 있다.

5. PHI 탐지는 익명화·HIPAA 충족 판정이 아니다

Medical PHI의 공식 제목은 ‘PII 탐지’로 표시되지만 본문은 DetectPHI와 보호 대상 건강 정보다. 문서는 HIPAA의 18개 식별자 목록과 탐지 엔터티가 1:1 매핑되지 않는다고 설명하며 추가 확인을 권한다. 따라서 API의 유형 목록을 체크했다고 법적 비식별화 요건 전체가 충족된다고 할 수 없다. 탐지는 후보 식별이며, 마스킹·보존·접근 통제·재식별 위험·해당 조직의 법적 검토는 별도다. PHI 탐지 사례를 규정 준수 인증이나 법률 자문으로 해석하지 않는다.

예를 들어 이름과 의무기록번호를 지워도 희귀 질환, 작은 지역과 정확한 치료 날짜를 결합하면 환자를 추정할 수 있다. 이처럼 다른 정보와 결합해 식별에 쓰일 수 있는 준식별자(quasi-identifier)의 일반화(generalization)와 재식별(re-identification) 위험을 검토한다. 사용 목적에 필요한 임상 정보는 유지해야 하므로, 마스킹(masking) 중 ‘복용하지 않음’의 부정 표현이나 단위를 지워 의료 의미를 바꾸지 않도록 확인한다. 이는 실제 환자 기록을 사용한 사례가 아니라 설명을 위한 예다.

적용 범위: 위 제약과 예외를 적용 대상의 현재 공식 문서와 대조한다. 이 해설은 API 실행 성공이나 법적 준수를 보증하지 않는다.

구현 전에 검증할 세부 사항

Medical 콘솔의 표시 결과와 기능별 언어표, API Reference의 요청·응답·할당량·리전을 확인한다.
실시간 치환 코드에서 SDK의 문자열 단위와 오프셋을 실제 원문으로 시험한다. 탐지 성능과 법적 비식별화 판단도 각각 검증한다.
한국어 예시의 JSON 쉼표 누락, 다른 작업의 조회 이름 혼입, 번역된 유형명과 범주 개수의 불일치는 실행용 사양으로 채택하지 않는다. 실제 API 식별자와 현재 스키마를 기준으로 확인한다.