생성형 AI에 개인정보를 넣어도 될까? 초보자용 입력 전 점검표

AI를 활용하여 생성한 이미지입니다.

생성형 AI 입력창은 비밀을 보관하는 금고가 아닙니다. 주민등록번호, 비밀번호, 인증번호처럼 명백한 정보만 위험한 것도 아닙니다. 회사명, 지역, 날짜, 직책, 사건 내용이 함께 남으면 이름을 지워도 특정인을 알아볼 수 있습니다. 입력 버튼을 누르기 전에 “이 문장이 공개되어도 괜찮은가?”라고 물어보고, 아니오라면 원문을 넣지 않는 것이 첫 원칙입니다.

NIST의 AI 위험관리 프레임워크도 AI를 사용할 때 위험을 파악하고 목적에 맞는 대응을 마련하는 접근을 제시합니다.[1] 개인정보 보호는 서비스 설정 하나로 끝나는 일이 아니라 입력 범위를 줄이고, 필요한 권한만 주고, 결과를 다시 확인하는 과정입니다.

30초 안에 자료를 세 종류로 나누기

두 번째 범주의 자료는 이름만 바꾸는 것으로 충분하지 않을 수 있습니다. “A회사 마케팅팀 팀장, 9월 3일, 특정 지역에서 발생한 희귀한 사건”처럼 단서가 겹치면 조직 안에서 한 사람을 바로 떠올릴 수 있습니다. 회사·지역·날짜·직책을 더 넓은 범주로 바꾸고, 작업에 필요하지 않은 금액과 고유 조건은 삭제하세요. 실제 값과 비슷하게 만든 가짜 숫자도 원문을 추측하게 한다면 줄여야 합니다.

원문을 안전한 입력으로 줄이는 방법

• 고객 명단은 고객 A·B와 가상 연락처로 바꾸고 실제 전화번호와 이메일은 제거합니다.
• 계약서는 회사 X·Y로 바꾼 뒤 검토에 필요한 조항만 남기고 금액·날짜·고유 조건을 범주화합니다.
• 진료 상담 기록은 환자 A의 가상 사례로 바꾸고 병원, 날짜, 희귀한 사건 조합을 제외합니다.
• 오류 코드만 필요한 경우에는 재현 가능한 최소 코드로 줄이고 API 키, 토큰, 내부 주소를 삭제합니다.
• 받은 이메일은 서명과 머리글을 지운 뒤 핵심 문장만 가공해 넣습니다.

가공본을 만든 뒤에도 한 번 더 읽어 보세요. 원문에서 작업에 꼭 필요한 문장만 남겼는지, 출력만 보고도 실제 사람이나 거래를 역추적할 수 없는지 확인해야 합니다. “완전히 익명화했다”는 표현은 데이터 특성과 접근 권한을 모르면 단정하기 어렵습니다.

서비스 설정은 두 번째 방어선

서비스마다 채팅 기록, 자동 삭제, 제품 개선 사용, 사람의 검토 가능성, 연결 앱 권한이 다릅니다. 계정의 설정 화면과 공식 정책을 확인하되, 설정을 바꿨다고 기밀 입력의 위험이 사라진다고 생각하지 마세요. 입력을 줄이는 조치가 먼저입니다.

• 채팅 기록이 저장되는지와 수동 삭제 방법을 확인합니다.
• 자동 삭제 기간과 삭제 후 처리 범위를 읽습니다.
• 대화가 제품 개선이나 모델 학습에 사용될 수 있는지 확인합니다.
• Gmail, Drive, 사진 같은 연결 서비스에 어떤 권한을 주는지 점검합니다.
• 조직 자료라면 회사 규정과 승인된 환경을 서비스 설정에 우선합니다.

서비스 안내에 따라 데이터 처리 방식이 달라질 수 있으므로 계정 유형과 지역도 함께 확인하세요. 공개 뉴스와 내부 메모를 한 대화에 섞는 것도 조심해야 합니다. 공개 자료 자체보다 그 자료에 개인의 계정 정보, 내부 일정, 비공개 판단을 덧붙이는 순간 위험이 달라집니다.

출력에도 개인정보가 남을 수 있습니다

입력을 가렸더라도 AI가 원문에 있던 연락처를 반복하거나, 문맥을 보고 존재하지 않는 이름·주소·사건을 추측해 넣을 수 있습니다. 결과를 메일이나 게시물로 보내기 전 이름, 연락처, 주소, 계정 정보가 남았는지 확인하세요. 중요한 사실은 원문과 대조하고, 원문에 없던 개인정보는 사실로 취급하지 않아야 합니다. 요약 결과를 그대로 복사하는 것보다 사람이 공개 범위와 정확성을 검토하는 단계가 필요합니다.

상황별 판단 기준

익명화와 가명화는 같은 말이 아닙니다

이름을 고객 A로 바꾼 것은 가명화에 가깝고, 다른 정보와 결합해도 개인을 알아볼 수 없도록 만든 상태와는 다릅니다. 가상 이름을 썼더라도 실제 사건 날짜, 희귀한 직업, 소수 지역, 특정 금액이 남으면 내부 자료와 대조할 수 있습니다. 따라서 “이름을 바꿨으니 익명화됐다”고 기록하기보다 어떤 식별 단서를 삭제하거나 범주화했는지 적어 두는 편이 정확합니다.

작업 목적에 따라 남겨야 할 정보도 달라집니다. 문장 톤을 다듬는 일에는 사람의 이름과 날짜가 필요하지 않습니다. 표의 열을 설계하는 일에는 열 이름과 몇 개의 가상 행이면 충분합니다. 코드 오류를 찾는 일에는 입력과 출력의 구조가 중요하지만, 실제 서버 주소나 고객 데이터는 필요하지 않은 경우가 많습니다. 필요한 정보와 단순히 복사하기 편한 정보는 다릅니다.

사내 자료를 다룰 때 추가로 정할 것

개인 판단으로 서비스 설정만 바꾸어 회사 자료를 입력해서는 안 됩니다. 조직이 승인한 도구인지, 누가 계정을 관리하는지, 대화 기록에 접근할 수 있는 사람이 누구인지, 결과를 어디에 저장할지 확인하세요. 팀이 공통으로 사용할 가공 규칙도 필요합니다. 예를 들어 모든 고객 이름을 고객 A로 바꾸더라도 부서마다 다른 치환표를 쓰면 원문과 연결되는 위험이 남을 수 있습니다.

가공한 문서와 원문을 같은 폴더에 두고 파일명만 비슷하게 만드는 것도 피하세요. 작업이 끝난 뒤 가공본, 결과물, 임시 클립보드나 다운로드 파일을 누가 보관할지 정해야 합니다. AI 서비스가 안전하다는 가정만으로는 이 흐름을 대신할 수 없습니다. 입력 전 단계부터 결과 공유 단계까지 정보의 이동 경로를 점검해야 합니다.

출력 검토를 두 번 나누기

첫 번째 검토는 개인정보를 찾는 단계입니다. 이름, 이메일, 전화번호, 주소, 계정 식별자와 추측성 표현을 검색하세요. 두 번째 검토는 사실과 업무 품질을 확인하는 단계입니다. AI가 원문에 없는 사람이나 사건을 만들어 넣지 않았는지, 요약하면서 조건을 빠뜨리지 않았는지 원문과 대조합니다. 두 검토를 한 번에 하려고 하면 개인정보가 없는지 확인하느라 내용 오류를 놓칠 수 있습니다.

자주 묻는 질문

이름만 지우면 안전한가요?

아닙니다. 회사, 날짜, 지역, 직책, 희귀한 사건이 조합되면 특정할 수 있습니다. 서로 결합되는 단서를 함께 줄이세요.

공개된 뉴스도 입력하면 안 되나요?

공개 자료 자체와 개인 메모나 계정 정보가 붙은 입력은 다릅니다. 공개 자료는 필요한 문장만 쓰고 내부 정보와 분리하세요.

채팅을 삭제하면 모든 복사본도 즉시 없어지나요?

서비스마다 보관과 삭제 방식이 다릅니다. 삭제 버튼만 보고 모든 복사본이나 검토 가능성이 즉시 사라진다고 단정하지 마세요.

가장 간단한 한 줄 규칙은 무엇인가요?

“이 내용이 검색 결과에 공개되어도 괜찮은가?”에 아니오라고 답했다면 원문을 넣지 마세요. 필요한 경우 조직이 승인한 환경에서 별도 절차를 따르세요.

관련 콘텐츠

• AI 에이전트와 챗봇의 차이
• AI 토큰과 컨텍스트 창 이해하기

Sources

1. [1] NIST AI Risk Management Framework