직원이 묻습니다. “고객 명단을 ChatGPT에 넣어도 돼요?” 대표는 확신이 없어 “일단 넣지 마세요”라고 합니다. 그러면 AI는 공개 정보 검색과 문장 다듬기에만 쓰이고, 실제 생산성 효과가 큰 업무에는 적용되지 못합니다.
반대로 “요즘 다 쓰니까 괜찮겠지”라고 열어두는 것도 위험합니다. 필요한 것은 전면 금지나 전면 허용이 아니라 데이터 종류와 용도에 따라 허용 범위를 정하는 것입니다.
개인정보보호위원회는 2025년 「생성형 인공지능(AI) 개발·활용을 위한 개인정보 처리 안내서」에서 생성형 AI 수명주기의 단계별 개인정보 처리 이슈와 법적 기준, 안전조치를 제시하고 있습니다. NIST의 AI Risk Management Framework도 AI 위험을 조직 차원에서 식별·측정·관리하는 체계를 강조합니다.
이 글은 법률 자문이 아니라 중소기업이 내부 AI 사용 기준을 만들 때 쓸 수 있는 실무 프레임입니다.
1. 먼저 데이터를 4등급으로 나눈다
Level 0 — 공개 정보
홈페이지, 공개 보도자료, 공개 가격표, 공개 채용공고처럼 누구나 볼 수 있는 자료입니다.
대체로 AI 활용 위험이 낮습니다.
Level 1 — 사내 일반 정보
내부 회의록, 업무 가이드, 공개 전 콘텐츠 초안처럼 외부 공개는 하지 않았지만 노출 시 큰 피해가 제한적인 정보입니다.
회사 승인된 AI 도구에서 사용할 수 있도록 정책을 정할 수 있습니다.
Level 2 — 민감 업무 정보
고객 계약 내용, 원가, 비공개 영업자료, 내부 전략, 고객 문의 내역처럼 외부 유출 시 사업상 영향이 큰 정보입니다.
원문 전체를 그대로 입력하기보다 필요한 항목만 추출하거나 익명화하고, 사용 목적과 도구를 제한해야 합니다.
Level 3 — 고위험 정보
주민등록번호, 금융정보, 인증정보, 비밀번호, Secret Key, 의료정보 등 법적·보안적 위험이 큰 정보입니다.
일반적인 외부 생성형 AI 입력에 사용하지 않는 것을 기본 원칙으로 두는 편이 안전합니다. 필요한 경우 별도의 법률·보안 검토와 통제된 환경이 필요합니다.
2. ‘AI에 넣는다’를 더 세분화해야 한다
같은 데이터라도 사용 형태가 다릅니다.
- 원문 전체 업로드
- 일부 문장 복사
- 이름/회사명을 제거한 요약 입력
- 통계값만 입력
- 사내 API를 통해 전송
- 사내 검색 시스템(RAG)에 저장
따라서 정책은 “고객 데이터 금지”보다 구체적이어야 합니다.
예:
고객 이메일 원문을 외부 AI에 붙여 넣지 않는다. 단, 이름·이메일·계약금액 등 식별·민감 항목을 제거한 후 문의 유형 분류에 사용할 수 있다.
이렇게 써야 직원이 실제로 판단할 수 있습니다.
3. 최소수집·최소전송 원칙
AI가 일을 잘하려면 모든 정보를 줘야 한다는 생각이 위험합니다. 작업에 필요한 최소 정보만 전달합니다.
예: “고객 불만 유형 10개 분류” 작업에 고객 실명, 전화번호, 계약번호까지 필요하지 않습니다.
입력 전 질문:
- 이 정보가 없으면 AI가 작업을 못 하는가?
- 식별자를 제거해도 되는가?
- 원문 대신 요약·통계로 대체 가능한가?
- 결과를 만들고 나면 원문을 계속 보관할 이유가 있는가?
4. 계정 정책을 만든다
개인 무료 계정과 회사 관리 계정은 통제 수준이 다를 수 있습니다. 중요한 업무라면 회사가 승인한 계정과 도구를 사용하도록 정합니다.
확인 항목:
- 회사 이메일 기반 계정인가
- 퇴사자 접근을 회수할 수 있는가
- 관리자 설정이 가능한가
- 데이터 처리/보관 옵션을 확인했는가
- 조직 내 공유 기능의 권한이 적절한가
각 AI 서비스의 데이터 사용·보관 정책은 수시로 바뀔 수 있으므로 도입 시점의 공식 문서를 확인해야 합니다.
5. Secret과 인증정보는 절대 프롬프트에 넣지 않는다
개발팀에서 특히 중요합니다.
금지 예:
- AWS Access Key
- DB Password
- PG Secret Key
- OAuth Client Secret
- 개인키 파일
- 서비스 계정 JSON
AI에게 오류를 설명해야 한다면 Secret 값을 ***로 마스킹하고 구조만 공유합니다.
6. 개인정보를 다룰 때는 목적을 먼저 기록
“AI를 쓰고 싶어서”가 아니라 왜 처리가 필요한지 정의해야 합니다.
예:
- 고객문의 분류
- 상담 요약
- FAQ 추천
- 이탈 사유 분석
목적이 정해지면 필요한 데이터와 불필요한 데이터가 분리됩니다.
7. Human Review가 필요한 영역
AI 결과가 바로 외부로 나가면 위험한 업무가 있습니다.
- 고객에게 보내는 중요한 답변
- 계약/법률 문서
- 채용·인사 판단
- 가격·견적
- 의료/안전 관련 조언
- 회사 공식 발표
이 업무에는 “AI 생성 → 담당자 검토 → 승인 → 외부 발송” 단계를 정책에 명시합니다.
8. 팀용 1페이지 AI 사용 정책 예시
허용
- 공개 정보 리서치
- 비민감 문서 초안
- 내부 문서의 문장 교정
- 익명화된 데이터 요약
- 승인된 회사 계정에서의 업무 보조
조건부 허용
- 고객 문의: 개인정보 제거 후
- 영업자료: 비공개 가격/계약 조건 제거 후
- 회의록: 참석자/민감 안건 확인 후
- 소스코드: Secret 제거, 고객 고유 로직 검토 후
금지
- 비밀번호/API Secret
- 주민등록번호 등 고유식별정보
- 미공개 인수합병/투자 정보
- 외부 반출이 계약상 금지된 고객 데이터
반드시 사람 승인
- 계약 문구
- 대외 발표
- 가격/견적
- 인사 결정
9. RAG라고 자동으로 안전한 것은 아니다
사내 문서를 벡터DB에 넣어 검색형 AI를 만들면 “데이터가 회사 안에 있으니 안전하다”고 생각하기 쉽습니다. 그러나 권한 통제가 없으면 다른 직원의 민감 문서가 검색 결과로 노출될 수 있습니다.
확인해야 할 것:
- 원본 문서 권한이 검색에도 반영되는가
- 퇴사자 문서/계정 접근이 제거되는가
- 문서 삭제 시 인덱스에서도 제거되는가
- 질문/응답 로그에 민감정보가 남는가
10. 사고가 났을 때를 미리 정한다
AI 관련 사고도 일반 보안 사고처럼 대응 절차가 있어야 합니다.
예:
- 잘못 입력한 데이터와 계정 확인
- 공유 링크/대화 접근 차단
- 관리자에게 보고
- 해당 서비스의 삭제·보관 정책 확인
- 영향 범위 분석
- 필요 시 법무/보안/개인정보 담당 검토
- 재발 방지 규칙 업데이트
도입 전 10문항 체크
| 질문 | Yes/No |
|---|---|
| 회사가 승인한 AI 도구 목록이 있는가 | |
| 데이터 등급을 구분했는가 | |
| 금지 데이터 예시가 구체적인가 | |
| 개인 계정 사용 기준이 있는가 | |
| Secret 입력 금지 규칙이 있는가 | |
| 고객 데이터 익명화 기준이 있는가 | |
| 외부 발송 전 사람 검토가 필요한 업무를 정했는가 | |
| 퇴사자 계정 회수 절차가 있는가 | |
| AI 사용 중 사고 보고 채널이 있는가 | |
| 정책을 정기적으로 업데이트할 담당자가 있는가 |
정리
중소기업의 AI 보안은 거대한 보안 솔루션에서 시작하지 않습니다. 무슨 데이터를 어느 도구에 어떤 목적으로 넣을 수 있는지 직원이 30초 안에 판단할 수 있는 기준에서 시작합니다.
완주 관점의 핵심: 보안 때문에 AI를 못 쓰게 하는 것이 아니라, 안전하게 쓸 수 있는 범위를 만들어 사용을 정착시킵니다.
참고자료
- 개인정보보호위원회, 「생성형 인공지능(AI) 개발·활용을 위한 개인정보 처리 안내서」(2025.8): https://www.privacy.go.kr/front/bbs/bbsView.do?bbsNo=BBSMSTR\_000000000049&bbscttNo=20836
- NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
- NIST Generative AI Profile: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence