회사에서 보이지 않는 AI 사용이 생기는 순간
회의록을 요약하려고 개인 AI 계정에 파일을 올리거나, 보고서를 빨리 찾으려고 외부 AI에 회사 드라이브를 연결하는 일이 있다. 직원에게는 작은 업무 편의이지만, 회사에는 승인하지 않은 데이터 처리 경로와 접근 권한이 생긴다. Shadow AI를 점검할 때는 접속한 사이트 목록과 함께 입력한 정보, 사용 계정, 연결한 기능을 확인해야 한다.
이 글은 임직원의 생성형 AI 사용을 검토하는 보안·IT 담당자와 부서 책임자를 위한 글이다. 승인 여부와 실제 노출 위험을 구분하고, 어떤 사용을 허용·보완·중단할지 판단하는 기준을 정리한다.
Shadow AI는 회사의 승인·관리 범위 밖에서 사용하는 AI
영국 NCSC는 Shadow AI를 조직의 승인된 시스템과 절차에 포함되지 않은 AI 기술 사용으로 설명한다. Shadow IT의 한 형태이며, 특정 무료 서비스나 악성 도구만을 뜻하지 않는다. [1]
개인이 유료로 구독한 AI도 회사가 사용 조건을 검토하지 않았다면 관리 범위 밖에 있을 수 있다. 반대로 회사가 도입한 서비스라도 승인받지 않은 외부 앱 연결이나 데이터 활용은 별도 검토 대상이다. 따라서 승인 단위는 서비스 이름과 함께 업무 목적, 계정·워크스페이스, 데이터 등급, 허용 기능까지 정하는 편이 실무적이다.
승인 여부와 위험도는 서로 다른 축이다. 공개 자료로 표현을 다듬는 미승인 사용과 고객 명단을 전송하는 미승인 사용은 조치 우선순위가 다르다. 회사의 승인도 모든 데이터를 모든 기능에 넣어도 된다는 뜻은 아니다.
입력 데이터·보관 조건·연결 권한을 나눠 확인
입력한 순간 외부 처리 경로가 생긴다
외부 서비스에 업무 파일을 올리면 그 정보를 서비스가 처리하게 된다. 해당 내용이 다른 사람에게 공개되거나 모델에 학습됐는지는 별도의 사실 확인 사항이다. 확인 전부터 ‘전 세계에 유출됐다’고 단정해서도, 학습 제외라는 이유만으로 안전하다고 판단해서도 안 된다.
OWASP는 개인정보와 기밀 업무 정보의 노출을 LLM 애플리케이션의 위험으로 다루며 최소 권한, 접근 가능한 데이터 소스 제한, 민감정보 입력에 관한 교육 등을 제시한다. 실무에서는 이름만 지우기보다 문서 본문·첨부파일에 남은 식별정보와 업무 비밀까지 검토해야 한다. [2]
학습 제외와 저장·삭제 조건은 다르다
‘모델 학습에 사용하지 않는다’는 설명은 데이터 보관 여부 전체를 답하지 않는다. 예를 들어 OpenAI는 기업용 데이터의 기본 학습 제외를 설명하면서, 일부 기업용 서비스의 보관 설정과 삭제 조건을 따로 안내한다. 이는 해당 제품·계약 범위의 설명이며 개인 계정이나 다른 서비스에 그대로 적용할 수 없다. [4]
OpenAI API 문서도 학습 사용 여부, 악용 모니터링 로그 보관, 기능별 상태 보관을 구분한다. 따라서 보관 기간은 서비스명 하나로 확정하기보다 사용하는 기능·설정·계약과 예외 조건을 함께 확인해야 한다. 중간에 다른 업체의 AI 앱을 이용한다면 그 앱 사업자의 데이터 처리 조건도 별도로 검토한다. [5]
파일 하나 업로드와 폴더 연결은 노출 범위가 다르다
파일 업로드는 선택한 자료를 넘기는 행위다. 드라이브나 메일 연결은 설정된 범위의 자료에 접근할 수 있는 권한을 부여하는 행위다. 어떤 자료를 실제로 읽거나 보관하는지는 제품과 설정에 따라 달라지므로 ‘연결했으니 모두 복제됐다’고 가정하지 않는다.
읽기 전용도 기밀정보의 조회 위험을 남긴다. 여기에 수정·삭제·전송 권한이 더해지면 업무 시스템에 영향을 줄 수 있다. OWASP는 과도한 기능·권한·자율성을 Excessive Agency의 원인으로 설명한다. 요약 업무라면 읽기 범위를 좁히고, 외부 전송이나 수정에는 별도 승인 단계를 두는 방식이 적합하다. [3]
업무별 판단표로 허용 범위를 구체화
아래 표는 조직 정책을 설계하기 위한 예시다. 실제 허용 여부는 회사의 정보 분류와 계약 조건에 따라 결정한다. ‘보완 후 검토’는 직원이 임의로 사용을 재개해도 된다는 의미가 아니다.
| 사용 상황 | 먼저 확인할 사항 | 권장 판단 |
|---|---|---|
| 공개된 제품 소개문 표현 다듬기 | 공개 자료인지, 회사 허용 계정인지 | 승인 절차와 출력물 검토 조건을 충족하면 허용 검토 |
| 내부 회의록을 개인 계정에 업로드 | 참석자 정보, 미공개 계획, 보관 조건 | 입력 중단 후 승인 환경·최소 자료로 대체 검토 |
| 고객 문의 원문을 외부 AI로 분류 | 연락처·주문정보, 처리 목적, 서비스 조건 | 그대로 입력하지 않고 개인정보 담당자와 처리 방식 검토 |
| 회사 드라이브를 AI에 연결 | 접근 폴더, 계정, 권한, 해제 방법 | 필요 폴더·읽기 권한으로 제한하고 사전 승인 |
| AI가 초안 메일을 외부로 자동 발송 | 수신자·첨부 검증, 전송 권한, 승인 기록 | 검토 가능한 초안과 발송 승인을 분리 |
| 소스코드 오류 분석 | 비밀키, 내부 주소, 비공개 로직 | 비밀정보 제거와 코드 반출 기준 확인 후 승인 환경 사용 |
도구 목록만 배포하면 경계 상황이 남는다. ‘어느 계정에서 어떤 자료로 무엇까지 할 수 있는지’를 업무 예시로 제시해야 직원이 자신의 행동을 판단할 수 있다.
가상 예시: 고객 문의 분류가 드라이브 연결로 확대된 경우
다음은 실제 사고가 아닌 가상 예시다. 마케팅 담당자가 문의 유형을 정리하려고 고객 연락처가 포함된 파일을 개인 AI 계정에 올렸다. 이후 자료를 매번 올리는 번거로움을 줄이려고 관련 폴더 연결도 허용했다.
이때 최초 파일의 내용과 폴더 연결 권한은 나눠 조사해야 한다. 업로드 파일의 정보 항목, 연결된 폴더 범위, 읽기·쓰기 권한, 실제 접근 기록, 결과 공유 여부를 확인한다. 폴더에 접근할 수 있었다는 사실만으로 모든 문서가 읽혔다고 결론 내리지는 않는다.
후속 업무는 승인된 환경에서 연락처를 제외한 최소 문의 내용으로 수행하도록 설계할 수 있다. 다만 이름·연락처를 지워도 본문에 개인을 알아볼 수 있는 단서가 남을 수 있다. 불필요한 문장과 첨부파일까지 검토하고, 외부 처리 자체가 허용되는지 먼저 판단한다.
발견 후에는 추가 노출 억제와 사실 확인을 함께 진행
다음 순서는 조직의 사고 대응 절차에 맞춰 적용할 운영 권고다. 미승인 사용을 발견했다는 사실만으로 법적 유출 여부나 신고 의무가 확정되는 것은 아니다.
- 추가 입력과 자동 실행을 멈춘다. 사용자가 보고한 서비스·계정·시간·파일 종류·공유 범위를 기록하고 담당 부서에 알린다.
- 진행 중인 접근을 억제한다. 외부 연결 권한과 공유 링크를 회수하고, 노출된 비밀키가 있다면 해당 키를 폐기·교체한다. 진행 중인 노출 억제를 조사 완료까지 미루지 않는다.
- 기록을 보존하며 범위를 확인한다. 필요한 대화·접근·승인 기록을 안전하게 확보하고, 누가 어떤 자료를 처리했는지와 추가 수신자가 있었는지 확인한다. 조사 목적으로 원문을 개인 메일 등에 다시 복제하지 않는다.
- 자료 성격에 따라 보안·개인정보·법무 담당자가 영향을 평가한다. 개인정보, 계약상 비밀정보, 접근 자격 증명을 구분해 후속 의무와 조치를 판단한다.
- 서비스의 대화·파일 삭제와 잔여 데이터 조건을 확인한다. 권한 해제는 기존 사본의 삭제와 다르고, 화면에서 삭제해도 즉시 모든 저장본이 사라지는지는 별도로 확인해야 한다.
- 업무를 재개할 경로를 정한다. 승인 도구, 최소 데이터, 좁은 권한, 결과 검토 책임자를 지정하고 예외 승인에는 유효기간을 둔다.
실무자 관점: 차단 실적보다 업무 경로의 변화를 확인
실무적 판단으로는 차단한 AI 사이트 수만으로 관리 효과를 평가하기 어렵다. 승인된 대안이 업무를 수행할 수 있는지, 예외 신청이 어디서 지연되는지, 개인 계정과 과도한 외부 연결이 줄어드는지를 함께 봐야 한다. 사용 실태를 파악할 때도 회사의 정당한 관리 범위에서 필요한 기록만 확인한다.
NCSC 역시 직원이 Shadow AI를 선택하는 이유를 이해하고 안전한 대안을 제공하며 위험을 줄이는 접근을 권고한다. 현업은 업무 목적과 필요한 자료를 설명하고, IT는 계정·권한을 관리하며, 보안·개인정보 담당자는 데이터 처리 조건을 검토하는 식으로 책임을 나누는 편이 실행하기 쉽다. [1]
허용 기준은 도구 이름보다 데이터와 권한으로 설정
Shadow AI 관리의 출발점은 ‘AI를 썼는가’에서 한 걸음 더 들어가는 것이다. 승인된 계정인지, 외부로 보내도 되는 자료인지, 업무에 필요한 만큼만 접근하는지, 결과를 누가 검토하는지까지 확인해야 한다.
처음부터 모든 사용 사례를 완벽하게 분류하기 어렵다면 고객 원문 입력, 비밀키가 포함된 코드 전송, 광범위한 폴더 연결, 외부 자동 발송부터 우선 검토할 수 있다. 확인되지 않은 사용을 계속 두기보다 해당 기능을 제한하고 업무를 이어갈 승인 경로를 마련하는 것이 실행 가능한 기준이다.