데이터 익명화를 준비하고 재식별 위험을 검토하는 방법.
눈에 띄는 식별자를 없앤다고 익명성이 보장되지는 않습니다. 여전히 개인을 식별할 수 있는 필드 조합과 드문 값을 검토하세요.
작업에 맞게 절차를 조정하세요.
직접 식별자, 드문 조합, 신원을 드러낼 수 있는 자유 텍스트를 찾으세요. 공개 목적을 합의한 뒤 그에 맞게 필드를 삭제, 일반화 또는 대체하세요. 재식별 키가 있다면 별도로 보관하고, 결과를 자동으로 익명 데이터라고 부르지 말고 남아 있는 위험을 설명하세요.
- 제공할 내용
- 제공된 소규모 데이터셋과 선택한 가림 처리 정책.
- 받을 결과
- 가림 처리된 값 또는 합성 대체 값과 잔여 위험 메모.
입력과 결과를 확인하세요.
설명용 입력과 출력 · 실제 WebAct 실행이 아닌 학습용 예시
입력 항목 예시개
Fictional internal table: name Alex Example; email alex@example.com; role "sole night-shift laboratory coordinator". Prepare a public summary requiring only a broad job family.
완성된 예시
Public-summary draft: job_family: operations Removed: name, email and unique role wording. No stable person ID is needed for this purpose. A single-record summary could still be identifying through context; this transformation is not an anonymity certification.
이 입력을 프롬프트에 넣고 WebAct에 복사해 작업을 실행해 보세요. 결과는 설명용 예시와 다를 수 있습니다.
판단 기준과 문제 해결.
이름을 무작위 IDs로 바꾸면 데이터셋이 익명화되나요?
레코드가 가명 처리되는 데 그칠 수 있습니다. 다른 필드나 보관된 대응표를 통해 여전히 사람과 연결될 수 있습니다.
이메일 주소를 제거한 뒤에도 사람을 알아볼 수 있는 이유는 무엇인가요?
특이한 직무, 날짜, 위치, 서술 세부 정보가 결합되면 개인을 식별할 수 있습니다. 레코드 전체와 예상 독자를 검토하세요.
직접 준비한 자료로 시도하세요.
작업 프롬프트의 예시를 내 자료로 바꾸세요. 필요한 요구 사항은 유지하고 작업을 WebAct에 복사하세요.
작업 맞춤 설정 및 복사 ↑