AI 데이터 보안 솔루션 점검: 민감정보·프롬프트·DLP 통제 포인트

서론

기업의 생성형 AI 활용은 실험 단계를 넘어 업무 도구 안으로 들어가고 있다. 문서 작성, 회의 요약, 코드 보조, 고객 응대, 리서치, 데이터 분석까지 AI가 연결되면서 보안팀이 봐야 할 대상도 달라졌다. 이제 핵심 질문은 “AI를 쓸 것인가 말 것인가”가 아니라 “어떤 데이터가 어떤 AI에 들어가고, 어떤 결과가 다시 업무 시스템으로 나오는가”다.

보안뉴스의 ISEC 2026 미리보기 기사에 따르면 프루프포인트는 AI를 위한 데이터 보안 솔루션을 소개하며 승인 AI와 Shadow AI 사용 가시성, AI 애플리케이션 보안 상태, Copilot 등 승인 AI 내부의 데이터 활동 모니터링, 정책 위반 탐지와 조치, 비인가 AI 앱으로 공유되는 데이터 식별을 강조했다. 같은 기사에는 국내 기업 약 40%, 대기업 65.1%가 AI를 도입했다는 맥락도 함께 제시됐다. AI 사용이 빠르게 늘어나는 만큼 보안팀은 금지 중심 정책만으로는 충분하지 않다.

AI 데이터 보안은 기존 DLP의 확장판이지만, 단순히 “민감정보 업로드 차단”만 뜻하지 않는다. 프롬프트 입력, 첨부파일, 내부 문서 검색, RAG, Copilot형 협업 도구, 브라우저 기반 AI 서비스, AI 에이전트의 외부 액션, 응답 복사와 공유까지 데이터 흐름 전체를 봐야 한다. 특히 로그와 감사 체계를 만들 때도 원문 프롬프트를 과도하게 저장하면 보안팀이 또 다른 민감정보 저장소를 만드는 역효과가 생긴다.

본론

AI 보안의 통제 대상은 데이터 흐름이다

생성형 AI 보안에서 가장 먼저 정리할 것은 승인 AI와 비인가 AI의 경계다. Microsoft 365 Copilot, Google Workspace AI, 사내 RAG 서비스, 개발용 코드 보조 도구처럼 조직이 승인한 AI가 있는 반면, 개인 계정으로 접속하는 공개 AI 서비스나 브라우저 확장형 AI, 파일 변환형 AI, 마케팅 자동화 AI처럼 보안팀이 모르는 도구도 존재한다. Shadow AI는 사용자가 악의적이라서만 생기는 문제가 아니다. 업무 속도를 높이려는 자연스러운 선택이 통제 밖 데이터 이동으로 이어지는 경우가 많다.

따라서 AI 보안 정책은 금지 목록만으로 설계하면 우회 사용을 늘릴 수 있다. 허용 AI, 조건부 허용 AI, 금지 AI를 나누고, 사용자 그룹과 데이터 등급별로 다른 정책을 적용해야 한다. 예를 들어 공개 정보 요약은 허용하되 고객정보, 소스코드, 계약서, 미공개 재무자료, 보안 로그, 인증 정보는 입력을 차단하거나 마스킹해야 한다. 고위험 업무에서는 관리자 승인이나 격리된 사내 AI 환경을 요구할 수 있다.

기존 DLP는 메일, 파일 업로드, 웹 전송, 엔드포인트 복사 같은 전통적 채널에 강하다. 그러나 AI 환경에서는 프롬프트 본문, 채팅형 응답, 플러그인 호출, 에이전트 액션, SaaS 내부 문서 참조까지 함께 봐야 한다. DLP, CASB/SSE, SSPM, 브라우저 보안, 엔드포인트 제어, ID 권한관리, SIEM 로그를 분리해 운영하면 AI 사용 맥락을 놓치기 쉽다.

민감정보는 입력·검색·출력 단계별로 봐야 한다

AI 데이터 유출은 입력 단계에서만 발생하지 않는다. 프롬프트에 고객정보나 계약서 내용을 붙여 넣는 것도 문제지만, AI가 내부 문서를 검색해 답변하는 과정에서 사용자가 볼 수 없는 문서 내용이 응답으로 노출되는 것도 문제다. 이를 권한 증폭 위험으로 봐야 한다. 사용자가 원본 문서에 접근할 수 없다면 AI 응답으로도 그 내용을 볼 수 없어야 한다.

입력 단계에서는 개인정보, 고객정보, 계정정보, 소스코드, 계약서, 재무자료, 미공개 사업정보, 보안 로그, API 키와 토큰을 탐지해야 한다. 단순 키워드 탐지만으로는 부족하다. 정규식, 데이터 분류 라벨, 문맥 기반 분류, 파일 지문, 저장소 위치, 사용자 그룹, 업무 목적을 함께 봐야 오탐과 미탐을 줄일 수 있다.

검색과 RAG 단계에서는 원본 권한과 응답 권한이 일치해야 한다. SharePoint, Google Drive, Slack, Teams, CRM, Confluence 같은 협업 저장소에 과도한 공유 권한이 남아 있으면 Copilot형 AI가 그 권한 혼선을 빠르게 드러낼 수 있다. “전체 조직 공개”, “링크가 있는 모든 사용자”, 퇴사자와 협력사 계정, 오래된 그룹 권한은 AI 도입 전 정리해야 한다.

출력 단계에서도 통제가 필요하다. AI가 민감정보를 요약하거나 재구성해 내보내면 원문을 그대로 붙여 넣지 않았더라도 유출이 될 수 있다. 응답 DLP, 출력 마스킹, 다운로드·복사·공유 제한, 외부 전송 전 승인 절차를 적용해야 한다. 특히 AI 에이전트가 메일 발송, 티켓 변경, 파일 공유, 코드 커밋, 외부 API 호출을 수행한다면 사람 승인, 범위 제한, 롤백 로그가 필요하다.

프롬프트와 응답 로그는 최소 수집이 원칙이다

AI 보안에서 로그는 필수지만, 과도한 원문 저장은 위험하다. 프롬프트와 응답에는 개인정보, 영업비밀, 소스코드, 보안 로그, 고객 데이터가 섞일 수 있다. 모든 원문을 장기간 저장하면 사고 대응을 위한 로그가 2차 유출 대상이 된다.

로그 설계의 원칙은 목적 제한과 최소 보존이다. 보안 감사와 사고 대응에 필요한 항목을 우선 남기되, 원문 전체 저장은 고위험 이벤트나 제한된 조사 절차에 한정하는 것이 바람직하다. 기본 로그에는 사용자, 부서, 앱, 모델, 테넌트, 시간, 데이터 분류 등급, 정책 위반 유형, 차단·허용·경고 조치, 첨부파일 해시, 외부 공유 대상, 에이전트 액션 이력을 남긴다. 원문은 마스킹이나 토큰화를 적용하고, 열람 권한과 열람 감사 로그를 별도로 둬야 한다.

탐지 관점에서는 반복적인 정책 우회 표현, 대량 복사와 붙여넣기, 비인가 모델 전송, 민감 문서 요약 요청, 프롬프트 인젝션, 데이터 추출 시도, 에이전트의 외부 API 호출을 함께 봐야 한다. 단일 이벤트보다 사용자·부서·업무 시간·데이터 등급·AI 앱 평판을 결합한 위험 점수가 운영에 더 적합하다.

DLP·CASB·SSPM은 같은 분류 체계를 써야 한다

AI 데이터 보안은 한 제품으로 끝나지 않는다. DLP는 민감정보 식별과 차단을 담당하고, CASB나 SSE는 클라우드 앱 사용과 데이터 이동을 본다. SSPM은 SaaS 설정, 공유 권한, OAuth 앱, 외부 협업 상태를 점검한다. 엔드포인트와 브라우저 통제는 사용자가 실제로 입력하고 복사하고 업로드하는 행위를 본다. ID 시스템은 누가 어떤 권한으로 접근하는지 결정한다.

이 도구들이 서로 다른 데이터 분류 체계를 쓰면 정책이 어긋난다. 문서 라벨, DLP 정책, AI 사용 정책, SaaS 공유 정책이 같은 기준으로 연결돼야 한다. “기밀”, “내부용”, “고객정보”, “소스코드”, “규제 대상 데이터” 같은 분류가 AI 입력·검색·출력 정책에 그대로 반영돼야 한다.

운영 측면에서는 예외 관리가 중요하다. 개발, 법무, 재무, 마케팅, 고객지원처럼 AI 활용이 많은 부서는 무조건 차단보다 안전한 사용 경로를 제공해야 한다. 경고 후 사유 입력, 관리자 승인, 제한된 사내 AI 샌드박스, 자동 마스킹, 읽기 전용 허용 같은 단계형 조치가 필요하다. 예외에는 만료일과 재검토 절차를 둬야 한다.

대응방안

우선순위 1: 승인 AI와 Shadow AI를 목록화한다

조직에서 사용하는 AI 앱을 허용, 조건부 허용, 금지로 구분한다. 프록시, DNS, CASB, 브라우저 확장, 엔드포인트 이벤트를 통해 비인가 AI 접속과 업로드를 식별한다. 사용자에게는 금지 목록만 알리는 것이 아니라 안전하게 쓸 수 있는 승인 AI와 데이터 입력 기준을 함께 제공해야 한다.

우선순위 2: AI 입력 정책을 데이터 등급과 연결한다

개인정보, 고객정보, 인증 정보, 소스코드, 계약서, 미공개 재무자료, 보안 로그 등 금지 또는 승인 대상 데이터를 정의한다. 데이터 라벨과 DLP 정책을 AI 앱에도 적용하고, 단순 차단 외에 마스킹, 경고, 사유 입력, 관리자 승인 같은 단계형 조치를 둔다.

우선순위 3: Copilot형 AI 도입 전 SaaS 권한을 정리한다

AI가 내부 문서를 참조하는 환경에서는 기존 공유 권한이 그대로 위험이 된다. 전체 조직 공유, 공개 링크, 퇴사자와 협력사 접근, 오래된 그룹 권한, 외부 OAuth 앱 권한을 정리한다. 원본 문서를 볼 수 없는 사용자는 AI 응답으로도 해당 내용을 볼 수 없어야 한다.

우선순위 4: 프롬프트·응답 로그 보존 기준을 정한다

보안 감사에 필요한 메타데이터를 남기되 원문 프롬프트와 응답 전체 저장은 최소화한다. 고위험 이벤트에 한해 제한 보존하고, 마스킹·토큰화·암호화·접근 승인·열람 감사 로그를 적용한다. 로그 보존 기간과 삭제 절차도 개인정보와 영업비밀 기준에 맞춰야 한다.

우선순위 5: AI 에이전트 액션에 사람 승인과 롤백을 둔다

메일 발송, 파일 공유, 티켓 변경, 코드 커밋, 외부 API 호출처럼 실제 업무 결과를 바꾸는 AI 에이전트 액션은 별도 통제가 필요하다. 고위험 액션에는 사람 승인, 허용 대상 제한, 실행 전 미리보기, 사후 롤백, 액션별 감사 로그를 둔다.

운영 체크리스트

결론

생성형 AI 보안은 모델을 막는 문제가 아니라 데이터 흐름을 설명 가능하게 만드는 문제다. 승인 AI와 Shadow AI를 모두 볼 수 있어야 하고, 프롬프트 입력부터 내부 문서 검색, 응답 출력, 에이전트 액션까지 같은 정책 체계로 관리해야 한다. 기존 DLP만으로는 AI 앱의 맥락과 SaaS 권한 증폭, 프롬프트·응답 로그의 2차 유출 위험을 충분히 다루기 어렵다.

보안팀이 지금 확인해야 할 질문은 분명하다. 우리 조직은 어떤 AI를 쓰는지 알고 있는가. 민감정보가 AI에 들어갈 때 차단하거나 마스킹할 수 있는가. Copilot형 AI가 참조할 수 있는 문서 권한은 정리돼 있는가. 프롬프트와 응답 로그를 어디까지 저장하는가. AI 에이전트가 외부 전송이나 업무 변경을 수행할 때 사람 승인과 롤백이 남는가.

AI 활용을 무조건 막는 정책은 오래가기 어렵다. 대신 허용 가능한 AI 사용 경로를 만들고, 데이터 등급별 통제와 예외 관리, 로그 최소화, SaaS 권한 정리, 에이전트 액션 통제를 함께 운영해야 한다. 그 체계가 갖춰질 때 AI는 Shadow IT가 아니라 관리 가능한 업무 도구가 된다.

참고자료

• 보안뉴스, “[ISEC 2026 미리보기] 프루프포인트, AI를 위한 데이터 보안 솔루션 선보여”, 2026-07-12. https://www.boannews.com/media/view.asp?idx=144608&page=1&kind=3
• Proofpoint, Data Security and AI governance 관련 제품·솔루션 자료.
• Microsoft, Microsoft 365 Copilot 데이터 보호·권한 모델 관련 공식 문서.
• NIST, Artificial Intelligence Risk Management Framework.
• CISA, Generative AI and security risk management 관련 권고 자료.

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.