섀도 AI를 금지 문구로 막을 수 없는 이유와 현실적 정책

직원이 외부 생성형 AI를 쓰는 이유는 대개 악의가 아니라 속도다. 번역, 회의 요약, 코드 설명, 고객 답변 초안처럼 반복 업무를 줄이고 싶어 한다. 조직이 모든 사용을 막으면서 대안을 제공하지 않으면 개인 계정, 브라우저 확장, 비공식 API 키로 사용이 이동해 오히려 가시성이 낮아진다.

현실적인 정책은 도구 이름의 허용·금지 목록만 만들지 않는다. 어떤 데이터가 들어가고, 결과가 어디에 쓰이며, 도구가 어떤 권한을 실행하는지 기준으로 위험을 나눈다.

이 글은 보안 운영 관점의 예시다. 개인정보, 영업비밀, 근로자 모니터링, 산업별 기록 보존 규정은 관할 법률과 계약에 따라 달라지므로 적용 전 개인정보·법무·노무 담당자의 검토가 필요하다.

프롬프트·검색·도구 호출의 기록 경계는 AI 도구 데이터 유출을 막는 로그 설계 기준과 함께 정하고, 사내 LLM이 외부 도구를 실행한다면 사내 LLM 프롬프트 인젝션 방어 전략의 권한 분리도 적용한다.

데이터 등급과 사용 행위로 정책을 나눈다

데이터 등급	예시	외부 공개형 AI	기업 계약형 AI	추가 조건
공개	이미 게시된 문서, 공개 코드	허용 가능	허용	사실 검증·저작권 확인
내부	일반 회의 메모, 내부 절차	원칙적 제한	승인 도구에서 허용	식별자 제거, 보존 설정 확인
기밀	고객 계약, 미공개 재무, 소스 코드	금지	업무별 승인	최소 입력, 접근 통제, 감사 로그
고위험	인증정보, 건강·법률 기록, 원본 개인정보	금지	별도 위험 평가	전용 환경, 법률 검토, 사람 승인

“기업용 요금제”라는 이름만으로 안전하다고 판단하지 않는다. 입력 학습 사용 여부, 보존 기간, 관리자 로그, 데이터 처리 위치, 하위 처리자, 삭제 기능, 키 관리, 사고 통지 조건을 계약과 실제 설정에서 확인해야 한다.

허용 도구 카탈로그에 필요한 정보

직원이 찾기 쉬운 내부 페이지에 다음 항목을 공개한다.

• 승인 도구와 승인된 사용 사례
• 로그인 방식과 개인 계정 사용 금지 여부
• 입력 가능한 데이터 등급과 금지 예시
• 모델 학습·보존·삭제 설정
• 파일 업로드, 웹 검색, 플러그인, 에이전트 기능의 허용 범위
• 결과물의 사람 검토 요구 수준
• 비용 센터와 지원 연락처
• 정책 버전, 마지막 검토일, 대체 도구

금지 사례만 나열하지 말고 “고객 이름을 제거한 뒤 요약”, “승인된 사내 검색 도구로 문서 질의”처럼 안전한 대안을 같이 제시한다.

모델 사용과 자동 실행을 분리한다

텍스트 초안을 생성하는 도구와 실제로 이메일을 보내거나 데이터베이스를 수정하는 에이전트는 위험이 다르다. 다음 단계로 권한을 높인다.

1. 읽기 전용 질의와 초안 생성
2. 승인된 내부 문서 검색
3. 외부 API 읽기
4. 파일 생성·티켓 작성 등 제한된 쓰기
5. 고객 연락, 결제, 계정·권한 변경

4단계부터는 최소 권한 서비스 계정, 작업별 승인, 명확한 대상 제한, 실행 전 미리보기, 실패 시 롤백이 필요하다. 5단계는 사람의 최종 승인을 기본값으로 두고, 자동화 범위를 매우 좁게 시작한다.

짧고 실행 가능한 정책 예시

use_case: customer_reply_draft
data_classification: internal
approved_tools:
  - company-ai-workspace
allowed_inputs:
  - redacted_ticket_text
prohibited_inputs:
  - passwords
  - payment_card_data
  - raw_identity_documents
required_controls:
  - company_sso
  - training_disabled
  - retention_days_lte_30
  - human_review_before_send
owner: customer-support
review_date: 2026-09-30

정책을 문서에만 두지 말고 프록시, DLP, 브라우저 관리, OAuth 승인, API 게이트웨이, 비용 관리와 연결한다. 다만 직원의 모든 프롬프트를 무기한 수집하는 방식은 또 다른 개인정보 위험을 만든다. 목적에 필요한 최소 메타데이터와 집계 지표를 우선 사용한다.

탐지 신호

• 승인되지 않은 AI 도메인·브라우저 확장·OAuth 앱 사용 증가
• 개인 이메일로 가입한 AI 서비스의 업무 기기 접근
• DLP 정책에 걸린 대량 붙여넣기·파일 업로드
• 새 AI API 키 생성과 비정상적인 비용 증가
• 승인 도구에서 기밀 데이터 등급 입력 경고 증가
• 에이전트의 쓰기 작업 실패, 과도한 재시도, 예상 밖 대상 호출
• 퇴사자 또는 역할 변경자의 AI 워크스페이스 접근 잔존

탐지 지표는 처벌보다 정책의 사용성을 개선하는 데 먼저 사용한다. 특정 팀에서 무단 사용이 집중되면 그 팀의 업무에 승인 대안이 부족한지 확인해야 한다.

예외 절차

예외 요청에는 “AI가 필요하다”가 아니라 구체적인 업무, 입력 데이터, 결과 사용처, 도구 권한, 대안 검토, 보존 기간을 적는다. 승인에는 소유자와 만료일을 붙이고, 파일럿 종료 후 결과와 사고 여부를 검토한다. 같은 예외가 반복되면 정책을 제품화하거나 정식 도구로 전환할 시점이다.

사고 대응

민감한 정보가 외부 AI에 입력됐다고 의심되면 다음 순서로 처리한다.

1. 해당 세션·공유 링크·API 키를 중지한다.
2. 도구의 삭제 기능과 공급자 지원 절차를 실행하고 증거를 남긴다.
3. 입력된 데이터 종류, 대상 계정, 공유 범위, 보존 설정을 확인한다.
4. 고객·직원·계약 데이터가 포함됐는지 개인정보·법무 담당자와 평가한다.
5. 동일 경로의 반복 사용을 막고 승인 대안을 제공한다.

“삭제 요청을 보냈다”는 사실과 실제 삭제가 확인됐다는 사실을 구분한다. 공급자의 처리 완료 증거와 계약상 의무를 확인해야 한다.

운영 체크리스트

• 업무별 승인 도구와 금지 입력 예시가 쉽게 검색되는가.
• 개인 계정 대신 회사 SSO와 계정 회수가 가능한가.
• 학습 사용, 보존, 공유, 플러그인 설정이 중앙 관리되는가.
• 자동 실행 권한이 읽기와 쓰기로 분리돼 있는가.
• 결과물의 사실·보안·저작권 검토 책임자가 정해져 있는가.
• 예외에 소유자, 범위, 만료일, 종료 조건이 있는가.
• 감시 데이터 자체의 최소 수집·보존 정책이 있는가.

참고 기준

• NIST AI Risk Management Framework
• NIST AI 600-1: Generative AI Profile
• OWASP GenAI Security Project
• NIST Privacy Framework

결론

섀도 AI를 줄이는 가장 현실적인 방법은 금지 문구를 강화하는 것이 아니라 안전한 선택을 더 빠르게 제공하는 것이다. 데이터 등급, 도구 계약, 실행 권한, 사람 검토를 한 표로 연결하고 예외를 짧게 운영하면 AI 활용 속도와 데이터 보호를 동시에 관리할 수 있다.