생성형 AI 개인정보 보호: 데이터 입력부터 안전 활용까지

일상과 업무에 생성형 AI가 깊숙이 파고들었다. 하지만 우리가 입력하는 정보의 처리 방식에 대한 의문은 여전히 많다. 개인정보보호위원회는 AI를 안전하게 사용하는 명확한 가이드를 제공한다.

AI 사용 전 핵심 설정 점검

생성형 AI를 사용하면서 개인정보 보호가 우려된다면, 가장 먼저 확인해야 할 사항은 입력한 내용이 AI 학습이나 서비스 개선에 활용되는지, 그리고 대화 기록이 저장되는지 여부이다. 서비스마다 정책과 설정 방식이 다르며, 개인용 계정과 기업용 계정에 따라 데이터 처리 방식이 달라진다. 따라서 AI를 사용하기 전에는 설정 메뉴에서 학습 활용, 대화 기록, 임시 채팅, 외부 연동 권한을 반드시 확인해야 한다.

다만, 학습 활용 설정을 껐다고 해서 모든 개인정보 위험이 사라지는 것은 아니다. 서비스 제공, 보안 점검, 오류 대응, 법적 의무 이행 등을 위해 데이터가 일정 기간 보관될 수 있다. 따라서 주민등록번호, 계좌번호, 비밀번호, 인증코드 등 민감한 정보는 설정과 무관하게 처음부터 입력하지 않는 것이 가장 안전하다.

주요 생성형 AI 서비스별 확인 설정은 다음과 같다.

챗GPT 설정

챗GPT는 프로필 아이콘 → 설정(Settings) → 데이터 제어(Data Controls) → 모두를 위해 모델 개선(Improve the model for everyone) 경로에서 이 기능을 끌 수 있다. 이 설정은 대화가 모델 개선에 활용되는 것을 제한한다. 과거 대화, 저장된 파일, 연결된 앱, 메모리 기능은 별도로 확인해야 한다. 민감한 내용을 질문할 때는 임시 채팅(Temporary Chat) 기능을 활용한다. 이는 일반 대화 기록에 저장되지 않고 모델 학습에도 사용되지 않지만, 안전 모니터링 등을 위해 일정 기간 보관될 수 있어 민감정보 입력이 안전하다는 의미는 아니다.

챗GPT 사용 시 점검 항목

• 모델 개선을 위한 데이터 학습 허용 끄기
• 임시 채팅 활용
• 과거 민감 대화 삭제
• 불필요한 파일 업로드 자제
• 메모리 기능 사용 여부 확인
• 연결된 앱이나 외부 도구 권한 확인
• 위치정보나 기기 권한 불필요 허용 여부 확인

제미니 설정

제미니는 Gemini 웹사이트 또는 앱 접속 → 활동 또는 Gemini 앱 활동 메뉴 → Gemini 앱 활동 토글 확인 경로에서 기능을 끌 수 있다. 이 설정을 끄면 대화 내용이 모델 개선이나 사람 검토에 활용되는 것을 제한한다. 하지만 서비스 제공과 보안 목적의 일시적 처리는 별도로 이루어지므로 이 설정이 개인정보 입력을 허용한다는 의미는 아니다. 기록을 완전히 끄기 어렵거나 일정 기간만 보관하고 싶다면 자동 삭제 주기를 짧게 설정하는 것이 안전하다.

제미니 사용 시 점검 항목

• 제미니 앱 활동 끄기
• 필요 시 기존 활동 삭제
• 자동 삭제 주기 짧게 설정
• 임시 채팅 기능 활용
• Gmail, Google Drive, Calendar 등 확장 프로그램 연결 여부 확인
• 불필요한 확장 프로그램 연동 해제
• 개인 Google 계정인지, 회사·학교 Workspace 계정인지 확인

특히 제미니가 Gmail, Google Drive, Calendar와 연결되었다면 AI가 메일, 문서, 일정 등 개인·업무 데이터에 접근할 수 있다. 필요한 기능만 연결하고, 전체 접근 권한 요구 시 실제로 필요한지 다시 확인해야 한다.

클로드 설정

클로드 또한 프로필 또는 계정 메뉴 → 설정(Settings) → 개인정보 보호(Privacy) → Help improve Claude 또는 Claude 개선 참여 경로에서 기능을 끌 수 있다. 모바일 앱에서도 유사한 경로로 확인한다. 클로드의 데이터 보관 기간, 학습 활용 여부, 개인용·기업용 계정의 처리 방식은 정책 변경 가능성이 있으므로, 사용 전 앱 내 개인정보 보호 설정과 최신 약관을 확인해야 한다.

일반적으로 개인용 AI 계정과 기업용·업무용 계정은 다르다. 개인용 계정은 사용자가 직접 학습 참여나 기록 설정을 확인해야 하며, 조직 관리자 통제가 어렵다. 반면 Team, Enterprise, API 같은 업무용 요금제는 별도의 데이터 처리 조건이 적용되는 경우가 많다.

클로드 사용 시 확인 항목

• 개인용 계정인지 업무용 계정인지
• 모델 개선 참여 설정이 켜져 있는지
• 대화 기록 보관 기간
• 조직 관리자 통제 가능 여부
• 입력 데이터가 모델 학습에 사용되는지
• API 또는 기업용 계약에서 어떤 데이터 처리 조건이 적용되는지

민감한 업무자료, 고객 정보, 상담 기록, 내부 소스코드, 계약서 원문은 개인용 클로드 계정에 그대로 입력하지 않는 것이 안전하다.

설정을 꺼도 입력하면 안 되는 정보

학습 활용 설정을 끄고, 임시 채팅을 사용하고, 기록을 삭제하더라도 다음 정보는 원칙적으로 AI에 입력하지 않는 것이 안전하다. AI 개인정보 보호의 가장 좋은 방법은 사후 삭제가 아니라 처음부터 넣지 않는 것이다.

• 주민등록번호, 여권번호, 계좌번호, 카드번호, 비밀번호, 인증코드
• 신분증 사본, 진단서, 장애인등록증, 의료기록
• 상담기록 원문, 고객명단, 후원자 명단, 지원자 이력서 원문, 직원 평가자료
• 회사 대외비, 비공개 소스코드, 계약서 원문 중 민감 조항

무료 AI와 유료 AI, 오해와 진실

많은 사람이 유료 AI는 학습에 사용하지 않아 개인정보를 넣어도 안전하다고 생각한다. 그러나 이 생각은 정확하지 않다. 중요한 것은 무료/유료 여부보다 개인용 서비스인지, 기업·기관용 서비스인지다. 개인용 무료 AI, 개인용 유료 AI, 기업용 AI, API 기반 AI는 개인정보 처리 방식과 조직 통제 수준이 다르다.

유료 AI가 더 좋은 기능을 제공할 수는 있지만, 조직의 개인정보 처리 체계를 대신해주지는 않는다. 직원이 개인 카드로 결제한 AI 계정에 고객 정보, 직원 정보, 상담 기록을 입력하면, 조직은 해당 정보가 어디에 저장되고, 언제 삭제되며, 누가 접근하는지 통제하기 어렵다. 반대로 기업용 AI나 API 서비스는 입력·출력을 모델 학습에 사용하지 않는 조건, 관리자 통제, 보안 설정, 데이터 처리 계약 등을 제공할 수 있다. 그러나 이 경우에도 무조건 안전하다고 볼 수 없으며, 서비스별 정책과 계약 조건을 확인해야 한다.

조직의 기본 원칙은 다음과 같다.

• 개인용 무료·유료 AI에는 개인정보, 민감정보, 영업비밀, 비공개 업무자료를 입력하지 않는다.
• 업무자료를 AI에 입력해야 한다면 조직이 승인한 기업용 AI 또는 통제 가능한 API 환경을 사용한다.

구분	예시	개인정보 입력 가능성	핵심 주의점
개인용 무료 AI	무료 챗GPT, 무료 제미니 등	원칙적으로 입력하지 않는 것이 안전	학습 활용, 사람 검토, 기록 저장 설정 확인 필요
개인용 유료 AI	챗GPT Plus/Pro, 개인용 제미니 유료 등	개인정보·민감정보 입력은 여전히 주의	유료라고 조직 통제가 되는 것은 아님
기업용 AI	챗GPT Business/Enterprise, Google Workspace with 제미니 등	계약·설정 확인 후 제한적 활용 가능	관리자 통제, 학습 제외, 보안 정책 확인 필요
API 기반 AI	OpenAI API, Gemini API 등	설계와 계약에 따라 가능	데이터 보관, 국외 이전, 로그, 위탁 검토 필요
자체 구축 AI	내부 서버, 폐쇄망 모델 등	가장 통제 가능	운영 보안과 접근 권한 관리 필요

유료 AI라고 해서 개인정보를 넣어도 안전하다는 등식이 성립하지 않는다. 개인용 유료 AI와 기업용 AI는 분명히 다르다.

대화 기록 삭제의 진실, 즉시 소멸하지 않는다

많은 사람이 AI 서비스에서 대화 기록을 삭제하면 완전히 지워졌다고 생각한다. 그러나 AI 시스템 전체에서 해당 내용이 즉시 완전히 제거된다고 단정하기는 어렵다. 일반적으로 삭제는 여러 단계로 이루어진다.

1. 이용자 화면에서 삭제: 대화 목록에서 해당 대화가 보이지 않고, 이용자가 다시 확인하거나 이어서 활용할 수 없다. 사용자가 일반적으로 “삭제됐다”고 느끼는 단계이다.
2. 서비스 운영을 위한 보관: 서비스 안정성 유지, 보안 대응, 오류 점검, 법적 의무 이행 등을 위해 서버나 백업 시스템에 일정 기간 보관될 수 있다. 이 기간과 접근 범위는 서비스별 정책에 따라 달라진다.
3. 모델 개선이나 품질 향상 목적과의 관계: 삭제하기 전에 입력한 내용이 서비스 정책에 따라 모델 개선, 품질 향상, 통계 처리, 비식별 형태의 분석 등에 이미 활용되었을 가능성도 있다.

민감한 정보는 “나중에 삭제하면 되겠지”가 아니라, 처음부터 입력하지 않는 것이 가장 안전하다.

이용자가 확인해야 할 사항

• 대화 기록 삭제 기능 유무
• 삭제한 대화가 어디까지 삭제되는지
• 서버나 백업 시스템에 일정 기간 남는지
• 보관 기간은 얼마인지
• 대화 기록 저장 기능을 끌 수 있는지
• 임시 채팅 기능 유무
• 기기나 브라우저에 다운로드 파일이 남아 있는지

특히 공용 PC, 회사 PC, 학교 PC, 기관 공용 노트북에서 AI를 사용했다면 대화 기록뿐 아니라 다운로드 파일, 브라우저 자동 완성, 로그인 상태까지 확인해야 한다.

국내 사용 AI도 개인정보는 해외로 이전될 수 있다

생성형 AI 서비스를 국내에서 사용해도 입력한 데이터는 해외 서버에서 저장되거나 처리될 수 있다. 챗GPT, 제미니, 클로드, Notion AI, Microsoft Copilot, Supabase, MongoDB Atlas, AWS, Google Cloud, Azure 같은 글로벌 서비스는 여러 국가의 데이터센터와 해외 법인, 하위 처리자를 통해 서비스를 운영할 수 있다.

핵심 기준은 개인의 정보 입력과 조직의 고객·직원 정보 입력의 차이이다. 개인이 자신의 정보를 AI에 직접 입력하는 경우에는 이용자가 개인정보 처리 방침과 설정을 확인하고 사용할 수 있다. 그러나 회사나 기관이 보유한 고객 정보, 직원 정보, 후원자 정보, 이용자 정보를 외부 AI나 해외 클라우드에 입력하는 경우에는 처리위탁, 국외 이전, 개인정보 처리 방침 반영, 안전성 확보 조치를 검토해야 한다.

상황	가능 여부	판단
개인이 자기 일상 질문을 AI에 입력	가능	개인정보 처리 방침과 학습 설정 확인이 필요하다
개인이 본인 사진을 AI 이미지 변환에 사용	조건부 가능	얼굴 정보·가족사진은 저장·학습·삭제 설정 확인이 필요하다
직원이 고객 명단을 개인용 AI에 입력	하면 안 된다	고객 개인정보의 외부 제공·국외 이전 위험이 있다
회사가 기업용 AI 계약 후 고객 문의를 요약	조건부 가능	계약, 위탁, 국외 이전, 보관 기간, 로그 확인이 필요하다
복지기관이 상담 기록 원문을 해외 AI에 입력	원칙적으로 하면 안 된다	민감 정보·제3자 정보 포함 가능성이 높다
익명 통계 자료를 AI에 입력	가능	개인 식별 가능성이 없도록 충분히 처리해야 한다

업무자료나 개인정보를 외부 AI 서비스에 안전하게 사용하기 위한 조치

• 입력 데이터 분류: 일반 개인정보, 민감정보, 고유식별정보, 내부 기밀을 구분한다.
• 목적 확인: AI에 입력하는 목적을 명확히 한다. 단순 문장 다듬기라면 개인정보를 넣을 필요가 없는 경우가 많다.
• 비식별화 또는 최소화: 이름, 연락처, 주소, 주문번호, 회사명, 병원명, 학교명 등 식별 가능한 정보를 제거한다.
• 서비스 정책 확인: 입력 데이터가 학습에 사용되는지, 보관 기간은 얼마인지, 사람이 검토할 수 있는지 확인한다.
• 국외 이전 여부 확인: 이전 국가, 이전받는 자, 이전 항목, 이전 목적, 보유 기간을 확인한다.
• 기업용 또는 기관용 계정 사용: 개인용 무료·유료 계정보다 조직이 통제할 수 있는 기업용 AI나 API 환경을 사용한다.
• 개인정보 처리 방침 반영: 조직이 보유한 개인정보를 외부 AI나 해외 클라우드로 처리하는 경우, 처리 방침에 위탁·국외 이전 내용을 반영해야 한다.
• 로그와 접근 권한 관리: 누가 어떤 데이터를 입력했고, 어떤 결과물을 받았는지 추적할 수 있어야 한다.

다음 정보는 외부 AI나 해외 서비스에 입력하면 안 된다.

• 주민등록번호, 여권번호, 계좌번호, 비밀번호, 인증코드
• 진단서, 의료기록, 장애인등록증, 신분증 사본
• 상담기록 원문, 사례관리 원문
• 지원자 이력서 원본 전체, 직원 평가 자료 원문
• 고객 명단 전체, 후원자 명단과 기부금 내역
• 미성년자 정보, 학대·폭력·자살 위기 등 고위험 기록
• 회사 대외비, 비공개 계약서, 보안 설정, 핵심 소스코드

중요한 기준은 “AI가 해외 서비스냐 아니냐”만이 아니다. 조직의 개인정보를 외부 서비스로 보내는 순간, 해당 데이터 흐름을 설명하고 통제할 수 있어야 한다.

AI 챗봇 대화도 개인정보가 될 수 있다

AI에 입력하는 말은 일상 대화처럼 보일 수 있지만, 특정 개인을 알아볼 수 있는 단서가 포함되어 있다면 개인정보가 된다. 개인정보는 이름, 전화번호, 주소처럼 직접 식별되는 정보만을 의미하지 않는다. 여러 단서가 결합되어 특정 개인을 알아볼 수 있다면 개인정보에 해당한다.

예를 들어, “○○초등학교 3학년 2반 담임”이나 “지난주 수요일 ○○병원 진료 결과” 같은 표현은 이름이 없어도 개인정보가 될 수 있다. 한 번의 대화에서는 식별이 어려워 보여도, 여러 대화가 누적되면 식별 가능성이 커진다. 텍스트뿐만 아니라 이미지, 음성, 파일 업로드까지 함께 쌓이면 특정 개인을 알아볼 가능성은 더욱 높아진다.

입력 내용	가능 여부	이유
“고객 응대 문장 예시를 작성해줘”	가능	개인정보가 없다
“한 고객이 환불을 요청했다. 정중한 답변문을 작성해줘”	가능	개인 식별이 어렵다
“홍길동 고객, 010-0000-0000, 주문번호 1234”	하면 안 된다	직접 식별 정보가 포함된다
“○○회사 인사팀 김 부장”	주의 필요	조합하면 특정 가능성이 있다
“우리 반 ADHD 진단 학생 상담문 작성”	원칙적으로 입력 금지	건강·교육·아동 관련 민감 정보가 될 수 있다
“주의집중에 어려움이 있는 학생을 위한 일반 안내문”	가능	특정 개인 정보가 제거되었다

AI에 사례를 입력해야 한다면 다음처럼 바꿔야 한다.

• 실명: “고객 A”, “직원 B”, “이용자 C”로 바꾼다.
• 전화번호·이메일: 삭제한다.
• 주소: 시·도 또는 권역 수준으로 축소하거나 삭제한다.
• 회사명·학교명·병원명: “사업체”, “학교”, “의료기관”으로 일반화한다.
• 구체적 날짜: “최근”, “지난달” 등으로 완화한다.
• 희귀한 질병·장애명: 꼭 필요하지 않으면 삭제한다.
• 가족 관계·경제 상황: 요약하거나 삭제한다.
• 사건 원문: 일반화된 상황 설명으로 변경한다.

이름만 지우는 것으로 충분하지 않다. 직장, 학교, 병원, 지역, 날짜, 사건, 가족 관계가 결합되면 개인이 드러날 수 있다.

업무자료와 조직 내부정보는 개인 판단으로 AI에 입력하면 안 된다

업무자료에는 개인정보뿐 아니라 조직 내부 정보가 함께 들어 있는 경우가 많다. 따라서 단순히 “개인정보가 아니니까 괜찮다”고 판단하면 안 된다.

업무자료에 포함될 수 있는 정보의 예시

• 고객 정보, 거래처 정보, 직원 정보, 인사 평가 자료, 지원자 이력서
• 계약서, 견적서, 회의록, 내부 의사결정 내용, 미공개 사업 계획
• 소스코드, 보안 설정 정보
• 후원자 명단, 이용자 기록, 상담 기록, 서비스 제공 기록

업무자료를 AI에 입력할 수 있는지는 다음 세 가지에 따라 달라진다.

1. 자료의 성격: 개인정보, 민감정보, 영업비밀, 내부 기밀이 포함되어 있는가?
2. 조직의 정책: 조직에서 승인한 AI 도구인가? 개인용 AI 사용이 허용되어 있는가?
3. AI 서비스의 데이터 처리 방식: 입력 데이터가 학습에 사용되는가? 보관 기간은 얼마인가? 해외로 이전되는가?

상황	가능 여부	판단
공개 보도자료 문장 다듬기	가능	개인정보·기밀정보가 없으면 가능하다
내부 회의록 요약	조건부 가능	참석자·고객사·계약 정보를 제거해야 한다
고객 상담 원문 요약	조건부 가능	기업용 AI 또는 비식별화가 필요하다
지원자 이력서 원본 업로드	원칙적으로 하면 안 된다	지원자 개인정보가 다량 포함된다
직원 평가 자료 업로드	원칙적으로 하면 안 된다	인사 정보·평판 정보가 포함된다
소스코드 전체 업로드	조건부 또는 금지	영업비밀·보안 취약점이 포함될 가능성이 있다
상담 기록·사례관리 기록 업로드	원칙적으로 하면 안 된다	민감 정보 포함 가능성이 높다

업무자료를 AI에 안전하게 사용하기 위한 조치

• 조직 승인 도구 확인: 개인용 무료·유료 AI가 아니라 조직에서 승인한 AI인지 확인한다.
• 자료 반출 기준 확인: 조직 내부 자료를 외부 AI에 입력하는 것이 자료 반출에 해당하는지 확인한다.
• 개인정보 제거: 이름, 연락처, 이메일, 주소, 주민번호, 계좌번호, 사번, 고객번호 등을 제거한다.
• 민감정보 제거 또는 별도 승인: 건강, 장애, 상담, 가족 상황, 경제 상황, 징계, 평가 정보는 별도 승인 없이는 입력하지 않는다.
• 계약·정책 확인: 입력 내용이 모델 학습이나 다른 목적으로 활용되지 않도록 계약 또는 정책상 통제되는지 확인한다.
• 결과물 검토: AI 결과물에 개인정보나 내부 기밀이 다시 포함되지 않았는지 사람이 확인한다.

데이터베이스와 AI 연결 시 사전 점검 필수

AI 활용은 이제 단순히 프롬프트에 문장을 입력하는 수준을 넘어섰다. 많은 조직이 구글 시트, 내부 DB, 클라우드 DB, 벡터DB, 업무 시스템, CRM, HR 시스템을 AI와 연결한다. 이 구조는 편리하지만, 개인정보가 한 번에 대량으로 외부 서비스에 연결될 수 있어 위험이 크다. 따라서 DB를 AI와 연결하기 전에는 반드시 사전 작업이 필요하다.

먼저 해야 할 사전 작업

AI와 DB를 연결하기 전에는 최소한 다음 작업을 해야 한다.

1. 데이터 목록화: 어떤 데이터가 저장되어 있는지 먼저 확인한다. (이름, 연락처, 이메일, 주소, 생년월일, 고객번호, 직원번호, 상담기록, 구매내역, 계약정보, 건강정보, 장애정보, 계좌정보, 파일첨부, 로그데이터 등)

2. 데이터 등급 분류: DB 안의 데이터를 등급별로 분류한다.

   등급	예시	AI 연결 기준
   공개 자료	공개 문서, 제품 설명	연결 가능
   내부 자료	업무 매뉴얼, 내부 문서	기밀성 확인 후 가능
   일반 개인정보	이름, 연락처, 이메일	최소화·권한 관리 후 조건부 가능
   민감 정보	건강, 장애, 상담, 평가, 가족 상황	원칙적으로 제한하며, 별도 승인이 필요하다
   고위험 정보	주민번호, 계좌번호, 진단서, 신분증	AI 연결 금지가 원칙이다

3. 처리 목적 확정: AI가 왜 DB에 접근해야 하는지 목적을 정해야 한다. 불명확한 목적(“일단 AI가 전체 DB를 읽게 해보자” 등)이라면 연결하지 않는 것이 안전하다.
4. 최소 접근 원칙 적용: AI가 전체 DB를 읽을 필요는 거의 없다. 필요한 테이블, 컬럼, 기간, 사용자 범위만 연결한다.
5. 테스트 데이터 분리: 개발과 테스트에는 실제 개인정보를 사용하지 않는 것이 원칙이다. 더미 데이터나 가명 처리 데이터를 사용한다.
6. 로그 설계: 누가, 언제, 어떤 DB 데이터에 접근했고, 어떤 AI 처리를 했는지 기록해야 한다. 단, 로그에 개인정보 원문이 과도하게 남지 않도록 주의한다.
7. 보존·파기 기준: AI 처리 결과물, 요약본, 임베딩 데이터, 로그, 백업 파일도 보존 기간과 삭제 기준이 있어야 한다.

데이터베이스 종류별 사용 기준

데이터베이스는 정보를 모아두는 저장소이다. 구글 시트도 넓게 보면 간단한 데이터베이스처럼 쓰이며, Supabase나 Firebase 같은 서비스는 앱을 만들 때 사용하는 전문 데이터베이스이다. 어떤 데이터베이스를 쓰느냐보다 그 안에 어떤 정보가 들어 있고, 누가 볼 수 있으며, AI가 어디까지 접근할 수 있는지가 중요하다.

데이터베이스를 AI와 연결하기 전에는 다음 세 가지 질문에 답해야 한다.

• 이 안에 개인정보가 들어 있는가?
• AI가 꼭 이 정보까지 읽어야 하는가?
• 누가 이 정보를 볼 수 있는지 제한되어 있는가?

이 질문에 답하지 못한다면 아직 AI와 연결하면 안 된다.

1. 구글 시트·엑셀형 데이터베이스

구글 시트, 엑셀 온라인, Airtable, Notion 데이터베이스처럼 표 형태로 정보를 정리하는 도구이다. 가장 익숙하고 쓰기 쉽지만, 개인정보 관리에는 조심해야 한다. 특히 링크 공유를 잘못 열어두거나, 개인 계정으로 관리하거나, 모든 직원이 전체 내용을 볼 수 있게 하면 위험하다.

사용 상황	예시	안전하게 쓰려면
괜찮은 경우	일정표, 업무분장표, 공개자료 정리, 익명 통계, 개인정보 없는 단순 업무현황, 이름이 제거된 만족도 조사 결과	-
조심해서 사용	고객 명단, 후원자 명단, 자원봉사자 명단, 이용자 접수 현황, 상담 예약 현황, 담당자별 업무 진행표	조직 계정으로 관리하고 접근 권한을 제한한다
위험한 경우	상담기록 원문, 의료기록, 장애 정보, 건강 정보, 진단서 내용, 사례관리 기록, 주민등록번호, 계좌번호, 신분증 사본 정보, 직원 평가 자료 원문	구글 시트에 그대로 저장하거나 AI와 바로 연결하지 않는다

구글 시트 안전하게 활용하는 방법

• 개인 Gmail이 아닌 조직 계정으로 만든다.
• 링크 공유를 끈다. “링크가 있는 모든 사용자” 공개를 사용하지 않는다.
• 필요한 사람에게만 보기·수정 권한을 준다.
• 퇴사자나 전보자의 권한을 즉시 회수한다.
• 이름과 민감정보를 한 시트에 같이 두지 않는다.
• AI가 전체 시트를 읽지 못하게 한다.
• 분석이 필요하면 이름과 연락처를 지우고 통계 형태로 바꾼다.

구글 시트는 간단한 업무표에는 좋지만, 민감한 개인정보 원장으로 쓰기에는 조심해야 한다.

2. Notion·Airtable 같은 업무 관리형 데이터베이스

Notion, Airtable, Coda, Monday, ClickUp 같은 도구는 문서와 데이터베이스를 함께 관리할 수 있어 편리하다. 이런 도구에도 AI 기능이 포함되어 있다. 문제는 페이지나 데이터베이스를 외부에 공유하기 쉽고, 워크스페이스 전체를 AI가 읽을 수 있는 경우도 있다는 점이다.

사용 상황	예시	안전하게 쓰려면
괜찮은 경우	회의 안건, 프로젝트 진행 상황, 공개 자료 정리, 내부 업무 매뉴얼, 개인정보 없는 할 일 목록, 콘텐츠 기획표	-
조심해서 사용	담당자별 업무 현황, 고객 응대 현황, 후원자 관리 현황, 교육 신청자 명단, 자원봉사 참여 현황	이름, 연락처, 이메일 등은 꼭 필요한 경우에만 넣는다
위험한 경우	상담기록 원문, 건강·장애 관련 정보, 사례관리 기록, 민감한 민원 내용, 직원 징계·평가 자료, 의료·심리 상담 자료	-

Notion·Airtable 안전하게 활용하는 방법

• 조직 워크스페이스에서 관리한다.
• 공개 링크를 사용하지 않는다.
• 게스트 권한을 주기 전에 범위를 확인한다.
• AI 기능이 어떤 페이지를 읽는지 확인한다.
• 개인정보가 있는 페이지는 AI 검색 대상에서 제외한다.
• 외부 공유 페이지에 개인정보가 없는지 확인한다.

Notion이나 Airtable은 업무 정리함으로는 좋지만, 상담·의료·복지·인사 민감 자료 보관함으로 쓰기에는 조심해야 한다.

3. Supabase·Firebase 같은 앱 개발용 데이터베이스

Supabase, Firebase, Firestore 같은 서비스는 웹앱이나 모바일앱을 만들 때 많이 사용한다. 구글 시트보다 훨씬 전문적인 데이터베이스이다. 담당자별 권한, 로그인, 기록 관리, 앱 연동을 더 체계적으로 만들 수 있지만, 설정을 잘못하면 대량 유출 위험이 커진다.

사용 상황	예시	안전하게 쓰려면
괜찮은 경우	회원가입이 필요한 앱, 고객 관리 시스템, 예약 관리 시스템, 업무 관리 웹앱, 직원용 관리자 페이지, 권한이 필요한 서비스	-
조심해서 사용	고객 정보, 직원 정보, 후원자 정보, 이용자 정보, 상담 이력, 서비스 제공 기록	로그인과 권한 관리를 반드시 설계해야 한다
위험한 경우	아무 권한 설정 없이 개인정보 테이블을 공개하는 경우, 관리자 키를 프론트엔드 코드에 넣는 경우, 테스트 모드로 계속 운영하는 경우, 모든 사용자가 모든 데이터를 볼 수 있는 경우, 실제 개인정보를 테스트 데이터로 사용하는 경우, 로그에 개인정보 원문이 계속 남는 경우	-

Supabase·Firebase 안전하게 활용하는 방법

• 로그인한 사용자만 접근하게 한다.
• 일반 사용자와 관리자의 권한을 나눈다.
• 담당자는 본인 담당 데이터만 보게 한다.
• 민감정보는 별도 테이블로 분리한다.
• 관리자 키는 절대 화면 코드에 넣지 않는다.
• 테스트에는 실제 개인정보를 쓰지 않는다.
• 누가 언제 어떤 정보를 봤는지 로그를 남긴다.
• 데이터가 어느 나라 서버에 저장되는지 확인한다.
• 서비스 제공업체의 개인정보 처리조건을 확인한다.

Supabase나 Firebase는 제대로 만들면 구글 시트보다 안전한 업무 시스템이 될 수 있다. 그러나 권한 설정 없이 사용하면 매우 위험하다.

4. AWS·Google Cloud·Azure 같은 클라우드 데이터베이스

AWS RDS, Google Cloud SQL, Azure SQL, MongoDB Atlas 같은 데이터베이스는 기업이나 개발팀이 본격적인 서비스를 만들 때 많이 사용한다. 전문적인 서비스이므로 보안 기능은 많지만, 그만큼 설정과 관리 책임도 크다.

사용 상황	예시	안전하게 쓰려면
괜찮은 경우	기업용 서비스 운영, 고객 관리 시스템, 쇼핑몰·예약 시스템, 사내 업무 시스템, 대량 데이터 처리, 장기 운영 서비스	-
조심해서 사용	고객 개인정보, 결제 관련 정보, 직원 정보, 계약 정보, 서비스 이용 기록, 민감한 업무 자료	보안 설정과 계약 검토가 필요하다
위험한 경우	데이터베이스 주소와 비밀번호를 코드에 그대로 넣는 경우, GitHub에 접속 정보를 올리는 경우, 누구나 접속 가능한 상태로 DB를 여는 경우, 관리자 계정을 여러 사람이 공유하는 경우, 백업 파일을 암호화하지 않는 경우, 퇴사자 계정이 남아 있는 경우	-

클라우드 데이터베이스 안전하게 활용하는 방법

• 접속 가능한 사람과 서버를 제한한다.
• 관리자 계정은 최소 인원만 사용한다.
• 비밀번호와 접속키는 안전한 저장소에 보관한다.
• 데이터는 저장할 때와 전송할 때 암호화한다.
• 백업 파일도 암호화한다.
• 접속 기록과 수정 기록을 남긴다.
• 서버 위치와 국외 이전 여부를 확인한다.
• 개인정보 처리 방침에 반영한다.
• 보존 기간과 삭제 기준을 정한다.

클라우드 데이터베이스는 전문 창고와 같다. 안전장치가 많지만, 문을 열어두면 더 큰 사고가 날 수 있다.

데이터베이스와 AI 연결 최종 판단

다음 표는 데이터베이스를 AI와 연결할 때의 판단 기준을 정리한다.

상황	판단
개인정보 없는 공개 자료를 AI 검색용 DB에 넣음	가능
이름과 연락처를 제거한 통계 자료를 분석 DB에 넣음	가능
고객 명단을 구글 시트에 넣고 링크 공유함	하면 안 된다
상담 기록 원문을 AI 검색 DB에 넣음	하면 안 된다
Supabase에 고객 정보를 저장하되 로그인·권한·로그를 설계함	조건부 가능
Firebase를 테스트 모드로 열어두고 개인정보 저장	하면 안 된다
클라우드 DB에 개인정보 저장 전 리전·계약·보안 설정 확인	조건부 가능
벡터DB에 내부 문서를 넣기 전 개인정보 제거	조건부 가능
자체 서버에 개인정보 저장하나 백업·로그·권한 관리가 없음	하면 안 된다

데이터베이스를 AI와 연결할 때는 AI가 읽어도 되는 자료만 연결하고, 개인정보는 줄이며, 민감정보는 빼고, 권한은 최소화해야 한다. 누가 봤는지 기록하고, 필요 없어지면 삭제할 수 있어야 한다. 좋은 데이터베이스를 쓰는 것보다 중요한 것은 좋은 개인정보 관리 기준을 세우는 것이다.

AI 답변에 개인정보가 포함되면 공유하지 말고 즉시 조치해야 한다

AI가 생성한 답변에 본인이나 가족, 고객, 직원, 이용자 등 제3자의 개인정보가 포함될 수 있다. 이 경우 가장 먼저 해야 할 일은 해당 답변을 추가로 전송하거나 게시하지 않는 것이다.

상황	해야 할 조치
AI 답변에 이름·전화번호가 포함됨	즉시 공유 중단, 삭제
AI 답변에 고객 주문번호 포함	문서 사용 중단, 개인정보 제거
AI가 가족사진을 포함한 이미지를 생성	공개 공유 전 동의와 공개 범위 확인
AI가 과거 대화를 바탕으로 개인정보를 반복 생성	대화 기록 삭제, 메모리·기록 설정 점검
AI 답변이 본인 또는 제3자의 민감 정보를 포함	캡처 후 신고·삭제 요청 검토

개인정보가 포함된 AI 답변에 대한 조치

• 답변 결과를 전송하거나 게시하지 않는다.
• 화면 캡처 등 증빙을 확보한다.
• 해당 대화, 파일, 생성물을 삭제한다.
• 필요 없는 외부 연동 권한을 회수한다.
• 서비스 내 신고·문의 채널을 통해 조치를 요청한다.
• 조직 자료라면 개인정보보호 담당자 또는 보안 담당자에게 보고한다.
• 이미 외부에 공유되었다면 회수 가능 여부를 확인한다.

플러그인·확장 프로그램·외부 서비스 연동, 필요한 권한만 허용해야 한다

최근 생성형 AI는 단순히 대화만 하는 서비스를 넘어 이메일, 캘린더, 문서 도구, 클라우드 저장소, 결제 서비스, 여행 예약 서비스 등과 연결되어 이용자를 대신해 작업을 수행한다. 이런 기능은 편리하지만 개인정보 위험도 커진다. AI에 입력한 정보가 외부 서비스로 전달되어 처리될 수 있기 때문이다.

연동 유형	가능 여부	기준
캘린더 일정 확인	조건부 가능	필요한 일정 범위만 접근한다
Gmail 전체 접근	주의 또는 제한	메일 전체에 개인정보가 다량 포함될 수 있다
Google Drive 전체 접근	매우 주의	문서 전체 노출 가능성이 있다
특정 폴더 접근	조건부 가능	최소 권한이면 가능하다
결제 서비스 연동	고위험	결제 정보·주소·연락처 확인이 필요하다
CRM 연동	고위험	고객 정보 대량 접근 가능성이 있다
Slack·메신저 연동	주의	대화 기록·파일 포함 가능성이 있다

플러그인·확장 프로그램·외부 서비스 연동 시 조치

• 어떤 서비스와 연결되는지, 어떤 데이터가 전달되는지 확인한다.
• 읽기·쓰기 권한을 구분하고, 전체 접근 대신 특정 폴더·특정 캘린더만 연결한다.
• 관리자 승인 절차를 마련하고, 사용하지 않는 연동은 해제한다.
• 외부 서비스의 개인정보 처리 방침을 확인하며, 연동 해제 후 데이터 보관 여부도 확인한다.
• 정기적으로 연결 앱 목록을 점검한다.

다음과 같은 연동은 하면 안 된다.

• 일정 관리만 필요한데 메일·드라이브 전체 권한을 허용하는 경우
• AI 회의록 도구에 전사 메일함 접근 권한을 부여하는 경우
• 개인 계정으로 회사 드라이브를 연결하는 경우
• 퇴사자 계정에 외부 연동이 남아 있는 경우
• 어떤 앱이 어떤 데이터에 접근하는지 모르는 상태로 사용하는 경우

공개된 정보도 무제한으로 AI 학습에 쓸 수 없다

인터넷에 공개된 정보라고 해서 아무 제한 없이 AI 학습에 사용할 수 있는 것은 아니다. 블로그, 기사, SNS 게시물처럼 누구나 볼 수 있는 정보라도 이름, 사진, 연락처 등 특정 개인을 알아볼 수 있는 정보가 포함되어 있다면 개인정보에 해당한다.

정보 유형	AI 학습·활용 판단
완전한 공개 통계 자료	활용 가능
공개된 제품 설명	활용 가능
개인 SNS 글	개인정보 포함 가능성이 있다
얼굴 사진이 포함된 블로그 글	개인정보·초상 관련 주의가 필요하다
병원 후기, 상담 후기	건강 정보 포함 가능성이 있다
기관의 이용자 성공 사례	재식별 가능성을 검토해야 한다

공개된 정보가 AI 학습에 활용되는 경우에도 법적 요건과 충분한 안전 조치가 전제되어야 한다. 이용자 입장에서는 자신이 인터넷에 공개한 정보가 AI 학습에 활용되는 것을 원하지 않을 수 있다.

이용자가 할 수 있는 조치

• 게시물 공개 범위를 조정하거나 삭제 또는 비공개로 설정한다.
• 플랫폼의 학습 데이터 제외 신청을 한다.
• 본인 웹사이트나 블로그의 AI 크롤러 접근 제한 설정을 한다. robots.txt 등을 통한 접근 제한을 검토한다.

개인 블로그에 가족사진, 병원 방문 후기, 자녀 학교생활 기록, 직장 관련 글을 올렸다면, 공개 게시물이라도 AI 학습 데이터로 활용될 가능성을 고려해야 한다. 특히 사진, 건강 정보, 자녀 정보, 직장 내부 정보가 포함된 글은 공개 범위를 제한하거나 비공개로 전환하는 것이 안전하다. 기관 홈페이지에 이용자 성공 사례를 게시하는 경우도 마찬가지이다. 실명을 쓰지 않았더라도 나이, 지역, 장애 유형, 회사명, 구체적인 사연이 결합되면 당사자가 식별될 수 있다. 사례글은 처음부터 충분히 익명화하고, 당사자 동의와 공개 범위를 명확히 해야 한다.

조직 유형별 AI 활용 기준

생성형 AI를 조직 업무에 도입할 때는 각 조직의 특성과 다루는 정보의 민감성에 따라 다른 접근 방식이 필요하다. 다음은 주요 조직 유형별 AI 활용 기준을 제시한다.

조직 유형	주의해야 할 정보	가능한 활용	하면 안 되는 활용	가능하게 하려면
일반 기업	고객 정보, 주문 내역, 상담 기록, 직원 정보, 지원자 정보, 거래처 정보, 계약서, 영업 자료	개인정보 없는 문장 작성, 비식별 고객군 분석, 공개 자료 요약, 내부 매뉴얼 초안 작성	고객 민원 원문을 개인용 AI에 입력, 지원자 이력서 원문 업로드, 직원 평가 자료 분석, 거래처 계약서 원문 업로드, 고객 명단 전체 업로드	기업용 AI 사용, 개인정보 제거, 내부 승인, 결과물 검토, 위탁·국외 이전 검토, 로그 관리
스타트업·IT 기업	고객 입력값, 회원 DB, 로그 데이터, API 키, 소스코드, 결제 정보, 위치 정보	비식별 로그 분석, 공개 문서 기반 챗봇, 내부 개발 문서 요약, 고객 문의 유형 분류	테스트에 실제 고객 데이터 사용, API 로그에 개인정보 원문 저장, 관리자 키를 GitHub에 업로드, 외부 AI API로 고객 입력값 전체 전송, DB 보안 정책 없이 AI 연결	더미 데이터 사용, API 키 Secret Manager 보관, 입력값 마스킹, 로그 보존 기간 설정, DB 권한 분리, RLS 또는 역할 기반 접근 제어, 보안 테스트 후 배포
비영리기관	후원자 명단, 자원봉사자 정보, 사업 참여자 정보, 이용자 정보, 기부금 내역, 만족도 조사 주관식 응답	개인정보 없는 홍보문 작성, 익명 만족도 분석, 사업 계획서 문장 정리, 공개 자료 기반 교육 자료 작성	후원자 명단을 개인용 AI에 업로드, 자원봉사자 연락처가 포함된 시트 외부 공유, 만족도 조사 원문 전체 입력, 이용자 사례를 식별 가능하게 작성, 고액 기부자 정보를 AI로 분류	후원자·이용자 정보 비식별화, 통계 중심 분석, 승인된 조직 계정 사용, 외부 공유 차단, 민감한 사연은 요약·익명화, 내부 AI 사용 기준 마련
복지·상담·의료·돌봄기관	상담 기록, 장애 정보, 건강 정보, 가족 상황, 경제 상황, 사례관리 기록, 보호자 정보, 위기 개입 기록, 의료·심리 기록	개인정보 없는 일반 안내문 작성, 익명 사례 기반 문장 연습, 공개 자료 요약, 통계 자료 분석, 내부 교육 자료 초안	상담 기록 원문 입력, 장애 정보·건강 정보 입력, 사례관리 기록 원문 요약, AI에게 이용자 위험도 단독 판단 요청, 보호자 정보와 가족 상황 입력, 진단서나 심리 검사 결과 업로드	실명·연락처·기관명·회사명 제거, 장애·건강 정보 최소화, 가상 사례로 변환, 담당자 검토, 조직 승인 도구 사용, 민감 정보 별도 승인, 서비스 결정은 사람이 최종 판단

복지·상담·의료·돌봄 기관은 일반 기업보다 한 단계 더 보수적으로 접근하는 것이 안전하다.

생성형 AI와 데이터베이스를 안전하게 쓰기 위한 최종 체크리스트

생성형 AI나 데이터베이스를 업무에 도입하기 전에는 “이 도구가 좋은가?”보다 먼저 “이 도구 안에서 개인정보가 어떻게 흘러가는가?”를 확인해야 한다. AI와 DB는 각각 따로 움직이지 않는다. 실제 업무에서는 구글 시트, 업무용 DB, 클라우드 저장소, API, AI 챗봇, 보고서 자동화 기능이 서로 연결되는 경우가 많다. 그래서 한 곳에서 권한 설정을 잘못하거나, 테스트 단계에서 실제 개인정보를 넣거나, API 키가 노출되면 개인정보가 한꺼번에 유출될 수 있다.

아래 체크리스트는 AI 또는 DB 도입 전에 반드시 확인해야 할 항목이다.

점검 항목	왜 확인해야 하나요?	어떻게 확인하나요?	필요한 조치
AI 또는 DB 사용 목적이 명확한가	목적이 불명확하면 불필요한 개인정보까지 수집하거나 AI에 입력한다.	“왜 이 도구가 필요한가?”, “어떤 업무를 자동화하려는가?”, “AI가 꼭 필요한가?”를 문서로 정리한다.	목적이 불명확하면 도입을 보류하고, 문서 작성·분석·상담 요약·고객 응대 등 구체적인 사용 목적을 먼저 정한다.
어떤 개인정보가 처리되는지 목록화했는가	어떤 정보가 들어가는지 알아야 보호 수준을 정할 수 있다.	이름, 연락처, 이메일, 주소, 생년월일, 고객번호, 상담기록, 구매내역, 파일첨부, 로그정보 등을 항목별로 적는다.	처리되는 개인정보 목록을 만들고, 불필요한 항목은 처음부터 수집하거나 입력하지 않는다.
민감정보와 고위험 정보를 구분했는가	건강, 장애, 상담, 아동, 가족 상황, 계좌번호, 주민등록번호 등은 일반 개인정보보다 더 위험하다.	데이터 항목을 일반 개인정보, 민감정보, 고유식별정보, 금융정보, 내부 기밀로 나눈다.	민감정보와 고위험 정보는 외부 AI 입력을 원칙적으로 금지하고, 꼭 필요할 때만 별도 승인 절차를 둔다.
개인정보를 꼭 입력해야 하는가	대부분의 AI 작업은 실명이나 연락처 없이도 가능하다.	AI가 답변하는 데 이름, 전화번호, 주소, 주문번호가 정말 필요한지 확인한다.	필요 없다면 “고객 A”, “직원 B”, “이용자 C”처럼 바꾸고, 연락처·주소·식별번호는 삭제한다.
비식별화 또는 가명처리가 가능한가	개인정보를 줄이면 AI 활용 위험을 크게 낮출 수 있다.	이름, 연락처, 이메일, 주소, 회사명, 학교명, 병원명, 구체적 날짜를 제거하거나 일반화할 수 있는지 확인한다.	원문 입력 대신 익명 사례, 통계 자료, 요약 정보, 가명 ID를 사용한다.
개인용 AI가 아니라 조직 승인 도구인가	개인용 무료·유료 AI는 조직이 데이터 보관, 삭제, 접근 권한을 통제하기 어렵다.	직원이 개인 계정으로 쓰는지, 회사·기관 계정으로 쓰는지, 관리자 통제가 가능한지 확인한다.	업무자료는 개인용 AI가 아니라 조직에서 승인한 AI, 기업용 AI, 내부 시스템 또는 통제 가능한 API 환경에서만 사용한다.
데이터가 학습에 사용되는지 확인했는가	입력한 내용이 AI 모델 개선이나 학습에 사용될 수 있다.	서비스 설정, 개인정보 처리 방침, 데이터 제어 메뉴에서 학습 활용 여부를 확인한다.	학습 활용을 원하지 않으면 옵트아웃 설정을 켜고, 민감정보는 설정과 무관하게 입력하지 않는다.
대화기록·로그 보관 기간을 확인했는가	대화를 삭제해도 서버나 백업에 일정 기간 남을 수 있다.	대화 기록 저장 여부, 삭제 기능, 자동 삭제 주기, 보관 기간, 로그 보관 정책을 확인한다.	기록 저장을 끄거나 자동 삭제 주기를 짧게 설정하고, 업무상 필요한 로그만 최소 기간 보관한다.
국외 이전 여부를 확인했는가	국내에서 사용해도 해외 서버나 해외 법인을 통해 데이터가 처리될 수 있다.	개인정보 처리 방침에서 국외 이전, 해외 이전, 이전 국가, 이전받는 자, 이전 항목, 보유 기간을 확인한다.	민감 자료는 국외 이전 여부 확인 전 입력하지 않고, 조직 업무자료라면 처리 방침과 내부 승인 절차에 반영한다.
외부 AI, 클라우드, 데이터베이스 서비스를 사용할 때 개인정보 처리 위탁 또는 DPA를 확인했는가	외부 서비스가 조직의 개인정보를 대신 처리하는 구조라면 처리 위탁 또는 데이터 처리 계약 확인이 필요하다.	OpenAI API, Gemini API, Claude API, Supabase, Firebase, AWS, Google Cloud, Azure, Notion, Airtable 등 사용하는 서비스의 DPA, 약관, 보안 문서, 하위 처리자 목록을 확인한다.	데이터 처리 목적, 학습 활용 여부, 보관 기간, 삭제 절차, 국외 이전, 하위 처리자, 침해 사고 통지 기준을 확인하고 문서로 남긴다.
개인정보 처리 방침에 반영했는가	실제로 외부 AI나 클라우드 DB를 쓰면서 처리 방침에 없으면 이용자에게 투명하게 알리지 못한 상태가 된다.	개인정보 처리 방침에 수집 항목, 처리 목적, 보유 기간, 위탁, 국외 이전, 안전 조치가 반영되어 있는지 확인한다.	새 AI 서비스나 DB를 도입했다면 개인정보 처리 방침, 내부 지침, 동의서 또는 안내문을 함께 수정한다.
접근 권한을 최소화했는가	모든 직원이 전체 데이터를 볼 수 있으면 유출 위험이 커진다.	누가 어떤 테이블, 시트, 파일, API, 관리자 화면에 접근할 수 있는지 확인한다.	담당자는 본인 업무 범위만, 관리자는 필요한 범위만 접근하게 하고 전체 다운로드 권한은 제한한다.
관리자 계정에 추가 인증을 적용했는가	관리자 계정 하나가 탈취되면 AI 설정, DB, 파일, 로그, 백업까지 한꺼번에 노출될 수 있다.	Google Workspace, Microsoft 365, AWS, Google Cloud, Azure, Supabase, Firebase, GitHub, AI API 계정에 MFA 또는 2단계 인증이 켜져 있는지 확인한다.	관리자 계정에는 MFA를 필수 적용하고, 관리자 권한은 최소 인원에게만 부여하며, 공동 계정 사용을 피한다.
API 키와 DB 비밀번호가 안전하게 보관되는가	API 키나 DB 비밀번호가 노출되면 외부인이 데이터에 접근할 수 있다.	코드, GitHub, 구글 시트, Notion 문서, 슬랙 메시지에 키나 비밀번호가 적혀 있지 않은지 확인한다.	Secret Manager, 환경 변수, Apps Script Properties 등 안전한 저장소를 사용하고, 노출 의심 시 즉시 폐기·재발급한다.
테스트에 실제 개인정보를 쓰지 않는가	개발·테스트 환경은 운영 환경보다 보안이 약한 경우가 많다.	테스트 DB, 샘플 시트, 데모 화면, 개발자 PC에 실제 고객 정보나 이용자 정보가 들어 있는지 확인한다.	테스트에는 더미 데이터나 가명 처리 데이터를 사용하고, 실제 개인정보는 개발용 환경에 복사하지 않는다.
접속·조회·수정 로그가 남는가	사고가 났을 때 누가 어떤 정보를 봤는지 알 수 있어야 한다.	로그인 기록, 데이터 조회 기록, 수정 기록, 삭제 기록, AI 요청 기록이 남는지 확인한다.	개인정보 조회·수정·삭제는 사용자, 시간, 대상, 작업 내용을 기록하고 관리자만 확인할 수 있게 한다.
로그에 개인정보 원문이 과도하게 남지 않는가	로그가 또 다른 개인정보 저장소가 될 수 있다.	API 요청 로그, 오류 로그, AI 프롬프트 로그, 서버 로그에 이름, 연락처, 상담 내용이 그대로 남는지 확인한다.	로그에는 필요한 식별자와 작업 정보만 남기고, 상담 기록·민감정보·비밀번호·토큰은 기록하지 않도록 설정한다.
백업이 암호화되어 있는가	원본 DB는 안전해도 백업 파일이 유출되면 같은 사고가 발생한다.	자동 백업 위치, 백업 접근 권한, 백업 암호화 여부, 백업 보관 기간을 확인한다.	백업 파일도 암호화하고, 접근 권한을 제한하며, 보존 기간이 지난 백업은 삭제한다.
보존 기간과 파기 기준이 있는가	목적이 끝난 개인정보를 계속 보관하면 위험이 커진다.	개인정보, AI 대화 기록, 요약본, 로그, 백업, 임베딩 데이터의 보관 기간을 확인한다.	목적 달성 후 삭제 기준을 정하고, 원본뿐만 아니라 AI 결과물·백업·벡터DB 데이터까지 함께 삭제되도록 관리한다.
퇴사자·전보자 권한 회수 절차가 있는가	퇴사자나 부서 이동자가 계속 접근할 수 있으면 내부 유출 위험이 생긴다.	퇴사자 계정, 전보자 권한, 외부 협력업체 계정, 게스트 계정이 남아 있는지 확인한다.	인사 변동 시 계정 정지, 관리자 권한 회수, 공유 드라이브·DB·AI 도구 접근 권한 삭제를 즉시 처리한다.
AI 답변에 개인정보가 포함될 경우 대응 절차가 있는가	AI가 답변에 개인정보를 다시 노출할 수 있다.	AI 결과물을 외부 공유하기 전 검토 절차가 있는지, 문제가 생겼을 때 누구에게 보고하는지 확인한다.	개인정보가 포함된 답변은 공유하지 않고 삭제·수정하며, 필요 시 캡처 후 서비스 신고와 내부 보고를 진행한다.

이 체크리스트는 AI 또는 DB 도입 전에 반드시 확인해야 할 항목이다.

연극학·서사이론의 시선으로 보면

정보 보안은 무대 뒤의 연출과 같다. 관객에게는 최종 공연만 보이듯, 사용자에게는 AI 서비스의 편리함만 드러난다. 그러나 연출가는 조명, 음향, 배우의 동선 등 모든 요소가 유기적으로 연결되어 작동하는 방식을 정확히 알아야 한다. 개인정보보호는 이 복잡한 시스템의 각 단계에서 데이터라는 ‘배우’가 어떤 ‘역할’을 수행하고, 어떤 ‘무대’를 거치며, 어떤 ‘관객’에게 노출될지 예측하고 통제하는 과정이다. 불투명한 데이터 흐름은 연극의 맥락을 파괴하듯 신뢰를 무너뜨린다.

출처

• https://tilnote.io/pages/6a3c4f96478fbed273977957