기업 AI 보안의 기본

AI 보안의 출발점은 "금지"가 아니라 "경계선"이다

기업이 생성형 AI를 도입할 때 가장 먼저 나오는 반응은 대개 둘 중 하나다. 하나는 "일단 다 써보자"이고, 다른 하나는 "위험하니 전부 막자"이다. 두 선택 모두 오래가지 못한다. 전자는 어느 순간 고객정보, 계약서, 소스코드, 내부 전략 문서가 외부 AI 도구로 흘러 들어가고 있음을 뒤늦게 발견한다. 후자는 직원들이 개인 계정, 브라우저 확장 프로그램, 무료 AI 사이트를 몰래 쓰는 '섀도 AI'를 키운다.

AI 보안의 목적은 AI 사용을 멈추게 하는 것이 아니다. 직원이 안전하게 쓸 수 있는 길을 넓히고, 위험한 사용은 초기에 차단하는 것이다. 보안 정책이 너무 추상적이면 현장에서는 지켜지지 않는다. "민감한 정보는 넣지 마세요"라는 문장은 듣기에는 그럴듯하지만, 실제 업무에서는 거의 도움이 되지 않는다. 영업 담당자가 고객사 미팅 메모를 요약하려 할 때, 인사 담당자가 지원자 이력서를 정리하려 할 때, 개발자가 오류 로그를 AI에게 보여주려 할 때 무엇이 허용되고 무엇이 금지되는지 바로 판단할 수 있어야 한다.

AI는 일반 소프트웨어보다 경계가 흐리다. 사용자의 프롬프트가 입력 데이터가 되고, 응답이 업무 결과물이 되며, 플러그인이나 커넥터가 사내 시스템을 호출할 수도 있다. 그래서 AI 보안은 모델 하나를 보호하는 문제가 아니라 데이터, 계정, 도구, 로그, 승인 절차를 함께 다루는 운영 체계가 되어야 한다. Cloud Security Alliance도 기업 AI 보안을 모델, 데이터, 에이전트, 공급망, 운영 모니터링을 아우르는 생애주기 문제로 설명한다¹.

이 장에서는 복잡한 보안 이론보다 기업이 당장 정해야 할 기준을 중심으로 다룬다. 핵심 질문은 단순하다. "어떤 데이터를 어떤 AI 도구에 넣어도 되는가?", "누가 어떤 AI 기능을 사용할 수 있는가?", "문제가 생겼을 때 어떻게 발견하고 멈출 것인가?" 이 세 질문에 답하지 못하면 AI 도입은 생산성 프로젝트가 아니라 데이터 유출 프로젝트가 될 수 있다.

회사 데이터는 먼저 등급으로 나누어야 한다

AI 보안 정책의 첫 번째 단추는 데이터 분류다. 많은 회사가 AI 도구 목록부터 정하려 하지만, 실제로 먼저 해야 할 일은 데이터의 민감도를 나누는 것이다. 같은 생성형 AI라도 공개 보도자료 초안을 다듬는 일과 미공개 인수합병 자료를 요약하는 일은 전혀 다른 위험을 가진다.

기업에서는 최소한 다음과 같은 기준을 마련하는 것이 좋다.

이 표의 목적은 직원을 겁주기 위한 것이 아니다. 오히려 반대다. 공개 가능한 데이터는 자유롭게 활용하게 하고, 내부용 데이터는 승인된 도구 안에서 쓰게 하며, 기밀·개인정보·영업비밀은 별도의 검토와 보호 장치 아래에서만 쓰게 하는 것이다. 데이터 등급이 없으면 모든 판단이 개인의 감에 맡겨진다. 어떤 직원은 고객명을 그대로 넣고, 어떤 직원은 아무것도 못 넣어 생산성을 잃는다.

특히 개인정보와 영업비밀은 가장 보수적으로 다루어야 한다. 유럽의 GDPR 관점에서 ChatGPT 같은 범용 AI를 업무에 사용할 때는 입력 데이터에 개인정보가 포함될 수 있고, 처리 목적과 보관, 이전, 삭제 권리 등의 문제가 발생할 수 있다². 법무팀이 "개인정보를 넣지 말라"고 말하는 것만으로는 충분하지 않다. 시스템 차원에서 마스킹, 익명화, 입력 차단, 승인 절차를 붙여야 한다.

예를 들어 고객지원팀이 상담 이력을 요약하고 싶다면 고객 이름, 전화번호, 주소, 주문번호를 먼저 제거한 뒤 "30대 여성 고객"처럼 업무 판단에 필요한 범위로만 바꾸어 입력해야 한다. 개발팀이 오류 로그를 분석하려 한다면 API 키, 토큰, 내부 서버 주소, 고객 식별자가 로그에 섞여 있는지 자동으로 검사해야 한다. 보안은 사용자의 선의에만 기대면 실패한다. 좋은 정책은 사용자가 실수하기 전에 멈춰 세운다.

AI 도구는 금지 목록보다 승인 목록으로 관리한다

AI 도구는 매주 새로 등장한다. 문서 작성 AI, 회의록 AI, 코딩 AI, 디자인 AI, CRM AI, 브라우저 확장 AI까지 종류가 끝이 없다. 이 상황에서 "위험한 도구 목록"을 계속 업데이트하는 방식은 오래 버티기 어렵다. 더 현실적인 방식은 승인 목록 중심의 관리다. 회사가 검토한 도구를 명확히 알려주고, 업무 데이터는 그 도구 안에서만 쓰도록 하는 것이다.

승인 목록을 만들 때는 기능보다 먼저 보안 조건을 확인해야 한다. "답변을 잘하느냐"보다 "우리 데이터를 어떻게 다루느냐"가 먼저다. SaaS AI 도구를 도입하기 전에는 최소한 다음 항목을 확인해야 한다.

• 데이터가 어느 국가와 리전에 저장되는가

• 입력한 프롬프트와 업로드 파일이 모델 학습에 사용되는가

• 저장 데이터와 전송 데이터가 암호화되는가

• 관리자 콘솔에서 사용자, 권한, 로그를 관리할 수 있는가

• SSO와 MFA를 지원하는가

• 감사 로그, 사용량 로그, 파일 업로드 이력을 제공하는가

• 데이터 삭제 요청과 보관 기간 설정이 가능한가

• 외부 플러그인, 커넥터, API 연동을 통제할 수 있는가

• 계약서에 데이터 처리, 기밀 유지, 사고 통지 조항이 포함되는가

Palo Alto Networks는 생성형 AI 보안 정책에서 승인된 도구와 비승인 도구를 구분하고, 섀도 AI를 탐지하며, 데이터 처리와 모니터링 기준을 실제 통제 절차로 연결해야 한다고 강조한다³. 이 말은 AI 정책이 문서 한 장으로 끝나면 안 된다는 뜻이다. 승인 목록은 보안팀의 엑셀 파일이 아니라 직원이 매일 확인할 수 있는 업무 포털, 브라우저 정책, SSO 앱 목록, 교육 자료에 반영되어야 한다.

또 하나 중요한 점은 무료 개인 계정과 기업용 계정을 구분하는 것이다. 같은 AI 서비스라도 개인용과 기업용은 데이터 사용 정책, 관리자 기능, 로그, 보안 인증, 학습 사용 여부가 다를 수 있다. OpenAI는 기업용 서비스에서 고객의 비즈니스 데이터를 기본적으로 모델 학습에 사용하지 않는다고 설명하지만⁴, 기업은 특정 벤더의 홍보 문구만 믿어서는 안 된다. 계약 조건, 데이터 처리 부속계약, 관리자 설정, 로그 보존 정책을 직접 확인해야 한다.

승인 목록 방식이 직원에게 답답하게 느껴질 수 있다. 그래서 예외 승인 절차도 함께 있어야 한다. 새로운 AI 도구가 필요하면 사용 목적, 입력 데이터 등급, 예상 사용자, 외부 연동 여부, 비용, 대체 도구를 간단히 적어 신청하게 한다. 보안팀은 무조건 "안 됩니다"라고 답하는 부서가 아니라, 안전하게 쓸 방법을 찾아주는 파트너가 되어야 한다.

개인 계정 사용을 줄이고 접근 권한을 설계한다

AI 도구의 가장 흔한 보안 구멍은 의외로 단순하다. 직원이 개인 이메일로 가입해 회사 자료를 넣는 것이다. 이 경우 회사는 누가 어떤 데이터를 넣었는지 알기 어렵고, 퇴사 후에도 계정에 대화 기록이 남을 수 있으며, 관리자 권한으로 접근을 회수하기도 어렵다.

기업 AI 보안의 기본은 계정 통제다. 가능한 한 개인 계정 사용을 줄이고 회사 계정 기반으로 통합해야 한다. SSO, 즉 단일 로그인은 직원이 회사 계정으로 여러 업무 도구에 접속하게 해주는 방식이다. 여기에 MFA, 즉 다중 인증을 붙이면 비밀번호가 유출되어도 추가 인증 없이는 접근하기 어렵다. 역할 기반 접근 제어, 즉 RBAC는 직무나 부서에 따라 사용할 수 있는 기능과 데이터 범위를 나누는 방식이다.

AI 시대의 접근 통제는 사람에게만 적용되지 않는다. 에이전트, API 키, 커넥터, 자동화 봇도 모두 하나의 "행위자"처럼 다루어야 한다. Red Hat은 에이전트형 AI에서 모델이 도구를 호출하는 순간 위험이 단순한 나쁜 답변에서 실제 업무 실행으로 이동한다고 설명한다. 따라서 모델이 권한의 최종 판단자가 되어서는 안 되며, 독립적인 인증과 권한 검사가 필요하다⁵.

실무적으로는 다음 원칙을 적용한다.

• 모든 AI 도구는 회사 SSO와 MFA를 기본으로 연결한다.

• 부서별, 직무별로 사용할 수 있는 AI 기능을 나눈다.

• 기밀 데이터 접근 권한은 최소 인원에게만 부여한다.

• 에이전트와 자동화 봇에는 사람 계정을 공유하지 않고 별도 서비스 계정을 사용한다.

• API 키는 개인 PC나 프롬프트 안에 저장하지 않고 비밀 관리 도구에 보관한다.

• 퇴사자, 전보자, 프로젝트 종료자의 권한을 정기적으로 회수한다.

• 관리자 권한은 보안, IT, 현업 관리자에게 역할별로 분리한다.

최소 권한 원칙은 AI에서 특히 중요하다. 예를 들어 영업 이메일 초안을 작성하는 AI가 CRM 전체 고객 데이터와 계약서 저장소, 청구 시스템까지 접근할 필요는 없다. 회의록 요약 AI가 인사 평가 폴더를 읽을 필요도 없다. AI 에이전트는 성실한 인턴처럼 보일 수 있지만, 권한을 과하게 주면 실수도 초고속으로 한다.

Microsoft의 Zero Trust for AI 접근법도 명시적 검증, 최소 권한, 침해 가정이라는 기존 제로 트러스트 원칙을 AI의 데이터 수집, 모델 실행, 에이전트 행동 전반에 적용해야 한다고 설명한다⁶. 쉽게 말해 "우리 회사 안에서 돌아가니까 믿는다"가 아니라 "매번 누가, 무엇을, 왜 하려는지 확인한다"가 AI 접근 통제의 핵심이다.

프롬프트 유출은 작은 복사 붙여넣기에서 시작된다

AI 보안 사고는 영화처럼 거대한 해킹 장면으로만 발생하지 않는다. 대부분은 바쁜 직원의 복사 붙여넣기에서 시작된다. 영업 담당자가 고객사 제안서를 더 멋지게 만들려고 전체 계약 조건을 AI에 넣는다. 인사 담당자가 지원자를 비교하려고 이력서 여러 개를 업로드한다. 개발자가 버그를 해결하려고 소스코드와 환경변수를 통째로 붙여 넣는다. 법무 담당자가 계약서 리스크를 검토하려고 상대방과의 협상 메모까지 함께 올린다.

이런 행동은 악의가 아니라 업무 효율에서 나온다. 그래서 더 위험하다. 직원 입장에서는 "AI가 일을 잘하려면 자료를 많이 줘야 한다"고 생각하기 쉽다. 하지만 AI에 넣는 순간 데이터는 회사의 통제 경계 밖으로 나갈 수 있다. 도구에 따라 프롬프트가 저장될 수 있고, 계정이 탈취되면 대화 기록이 노출될 수 있으며, 외부 플러그인이나 커넥터가 예상보다 넓은 범위의 데이터에 접근할 수도 있다.

Varonis는 생성형 AI 시대의 DLP, 즉 데이터 유출 방지 전략이 기존 이메일·파일 전송 감시를 넘어 AI 플랫폼에 입력되는 텍스트와 파일을 실시간으로 분석하고 차단해야 한다고 설명한다⁷. 이는 현장에서 매우 중요한 변화다. 과거에는 문서가 외부 메일로 나가는지 보면 됐다. 이제는 직원이 브라우저 창에 붙여 넣은 문장, 업로드한 PDF, 회의록 AI가 가져간 녹취 파일까지 봐야 한다.

특히 다음 사례는 기업에서 자주 발생한다.

첫째, 고객정보가 섞인 프롬프트다. "아래 고객 불만 내용을 공손하게 답변해줘"라고 입력했는데, 그 안에 고객명, 전화번호, 주소, 주문번호, 결제 정보가 포함되어 있다. 이 경우 AI는 훌륭한 답변을 줄 수 있지만, 회사는 개인정보 처리 리스크를 떠안는다.

둘째, 계약정보와 협상 전략 유출이다. "이 계약서에서 불리한 조항을 찾아줘"라고 요청하면서 미공개 가격표, 위약금 조항, 상대방과의 협상 메모까지 업로드한다. 계약 검토는 AI가 잘 도와줄 수 있는 영역이지만, 반드시 승인된 법무용 AI 환경이나 비식별 처리 절차가 필요하다.

셋째, 소스코드와 비밀값 노출이다. 개발자가 오류 해결을 위해 코드 저장소 일부를 붙여 넣었는데, 그 안에 API 키, 데이터베이스 접속 문자열, 내부 경로, 고객 데이터 샘플이 들어 있다. 코딩 AI는 생산성을 크게 높일 수 있지만, 개발 환경에서는 비밀값 탐지와 코드 업로드 정책이 필수다.

넷째, 외부 커넥터의 과도한 접근이다. 문서 검색 AI에 구글 드라이브나 노션을 연결했는데, 모든 폴더 읽기 권한을 부여해버리는 경우다. 직원은 자신의 업무 폴더만 연결했다고 생각하지만, 실제로는 인사, 재무, 전략 문서까지 검색 가능한 상태가 될 수 있다. RAG 기반 사내 지식 검색을 만들 때도 문서별 접근 권한이 검색 결과에 그대로 반영되어야 한다.

다섯째, 에이전트의 잘못된 실행이다. AI 에이전트가 이메일을 작성하는 데서 그치지 않고 실제 발송, CRM 업데이트, 결제 요청, 티켓 종료까지 수행한다면 보안 위험은 한 단계 올라간다. Microsoft는 에이전트형 AI가 자율성 때문에 잘못된 출력, 과신, 새로운 공격 벡터, 책임 소재 문제를 만들 수 있으므로 고위험 결정에는 인간 검토와 모니터링이 필요하다고 설명한다⁸.

로그와 모니터링은 감시가 아니라 안전벨트다

AI 사용 로그를 남긴다고 하면 직원들은 감시받는 느낌을 받을 수 있다. 그래서 회사는 로그 수집의 목적을 명확히 설명해야 한다. 목표는 개인의 사소한 사용을 들여다보는 것이 아니라, 회사 데이터가 비정상적으로 빠져나가는지, 승인되지 않은 도구가 쓰이는지, 에이전트가 권한을 남용하는지 확인하는 것이다.

AI 보안에서 남겨야 할 로그는 기존 업무 시스템보다 조금 다르다. 단순히 로그인 성공·실패만 보면 부족하다. 프롬프트, 응답, 파일 업로드, 외부 앱 연결, 커넥터 권한 변경, 에이전트 실행 이력까지 추적해야 한다. 물론 프롬프트 전체를 무조건 저장하면 그 자체가 또 다른 민감정보 저장소가 될 수 있으므로, 마스킹과 접근 제한이 필요하다.

실무적으로는 다음 로그를 우선 관리한다.

• 누가 어떤 AI 도구에 접속했는지

• 어떤 데이터 등급의 문서가 업로드되었는지

• 프롬프트에 개인정보나 기밀 패턴이 포함되었는지

• AI 응답에 민감정보가 포함되어 외부로 공유되었는지

• 어떤 외부 앱, 플러그인, 커넥터가 연결되었는지

• 에이전트가 어떤 도구를 호출했고 어떤 결과를 만들었는지

• 관리자 권한이나 공유 권한이 언제 변경되었는지

SANS의 AI 보안 가이드라인은 접근 통제, 데이터 보호, 배포 전략, 추론 보안, 모니터링, 거버넌스·리스크·컴플라이언스를 핵심 통제 범주로 제시하며, 프롬프트와 출력 로그, 모델 행동 변화 감지, 감사 추적의 중요성을 강조한다⁹. 이 관점은 기업 보안팀에 익숙한 방식이다. AI라고 해서 완전히 새로운 우주가 열린 것은 아니다. 기존 보안 원칙을 AI의 입력, 출력, 연결, 실행 단계에 맞게 확장해야 한다.

DLP, CASB, 엔드포인트 보안과의 연계도 중요하다. DLP는 민감정보가 외부로 나가는 것을 탐지하거나 차단하는 도구다. CASB는 클라우드 서비스 사용을 가시화하고 통제하는 보안 중개 도구다. 엔드포인트 보안은 직원 PC와 노트북에서 발생하는 행위를 감시하고 악성 행위를 차단한다. 이 세 가지가 AI 도구 사용과 연결되면 "누가 어떤 SaaS AI에 어떤 데이터를 보내려 했는지"를 더 빨리 발견할 수 있다.

예를 들어 직원이 고객 주민등록번호가 포함된 엑셀 파일을 승인되지 않은 AI 사이트에 업로드하려 하면 DLP가 차단한다. 개발자가 개인 브라우저 확장 AI에 내부 저장소 코드를 붙여 넣으면 엔드포인트 보안이 경고한다. 부서 전체에서 갑자기 승인되지 않은 회의록 AI 사용량이 늘어나면 CASB가 섀도 AI 신호로 표시한다. 보안은 사고가 난 뒤 범인을 찾는 일이 아니라, 사고가 나기 전에 속도를 줄이는 일이다.

사내 AI 보안 가이드라인은 짧고 구체적이어야 한다

많은 회사의 보안 정책은 너무 길어서 아무도 읽지 않는다. AI 보안 가이드라인은 법무 문서처럼 쓰면 실패한다. 직원이 실제 업무 중 10초 안에 판단할 수 있어야 한다. 좋은 가이드라인은 "하지 말라"보다 "이렇게 하라"를 많이 담는다.

사내 AI 보안 가이드라인에는 최소한 다음 내용이 포함되어야 한다.

• 승인된 AI 도구 목록과 사용 가능한 업무 범위

• 데이터 등급별 입력, 업로드, 공유, 학습 사용 기준

• 개인정보·기밀·영업비밀의 비식별 처리 방법

• 부서별 예외 승인 절차

• 고위험 업무의 사전 보안 검토 기준

• 외부 AI 벤더 보안 평가 체크리스트

• 프롬프트, 응답, 파일 업로드 로그 관리 기준

• AI 사고 발생 시 신고, 차단, 조사, 고객 통지 절차

• 정기 교육과 위반 시 조치 기준

여기서 중요한 것은 부서별 예외다. 재무팀, 법무팀, 인사팀, 개발팀, 고객지원팀은 다루는 데이터가 다르다. 전사 공통 기준만으로는 충분하지 않다. 법무팀은 계약서 검토용 전용 환경이 필요할 수 있고, 고객지원팀은 상담 이력을 비식별 처리한 뒤 요약하는 워크플로우가 필요할 수 있다. 개발팀은 코딩 AI를 쓰되 저장소 범위와 비밀값 차단을 엄격히 해야 한다. 인사팀은 채용 과정에서 편향과 개인정보 보호를 함께 고려해야 한다.

고위험 업무에는 사전 보안 검토를 붙인다. 고객 개인정보 대량 처리, 외부 고객에게 직접 응답하는 챗봇, 결제·환불·계약 변경을 실행하는 에이전트, 법적 판단이나 인사 평가에 영향을 주는 AI, 핵심 소스코드나 영업비밀을 다루는 AI가 여기에 해당한다. 이런 업무는 현업이 단독으로 도입하지 않고 보안, 법무, 개인정보보호, IT, 해당 부서가 함께 검토해야 한다.

벤더 보안 평가도 일회성으로 끝나면 안 된다. AI 서비스는 빠르게 바뀐다. 오늘은 파일 업로드 기능이 없던 도구가 다음 달에는 구글 드라이브 연결을 지원할 수 있다. 오늘은 학습에 사용하지 않는다고 설정했지만, 관리자 정책이 바뀌거나 새로운 기능이 추가될 수 있다. 따라서 승인 도구는 정기적으로 재평가하고, 기능 변경 시 보안 검토를 다시 해야 한다.

사고 대응 절차도 미리 정해두어야 한다. 누군가 고객정보가 포함된 파일을 외부 AI에 업로드했다면 어떻게 할 것인가? 먼저 해당 계정과 연결 앱을 차단하고, 업로드 파일과 로그를 확인하며, 벤더에 삭제를 요청하고, 개인정보 유출 여부를 판단해야 한다. 필요하다면 고객 통지와 규제기관 신고도 검토해야 한다. 사고 대응은 침착함이 생명인데, 침착함은 사전에 작성된 절차에서 나온다.

직원이 지킬 수 없는 정책은 보안이 아니다

AI 보안에서 가장 큰 착각은 "정책을 만들었으니 안전하다"는 생각이다. 정책은 시작일 뿐이다. 직원이 이해하고, 업무 도구 안에서 자연스럽게 따를 수 있으며, 위반 시 즉시 피드백을 받을 수 있어야 한다.

현실적인 교육은 사례 중심이어야 한다. "개인정보 보호법을 준수하라"는 문장보다 "지원자 이력서를 AI에 넣기 전에 이름, 연락처, 학교, 주민번호, 사진 정보를 제거하라"는 예시가 훨씬 강하다. "영업비밀을 입력하지 말라"보다 "미공개 가격표, 고객별 할인율, 계약 협상 메모는 승인된 전용 AI 환경 외에는 넣지 말라"가 더 낫다.

교육은 모든 직원에게 같은 내용을 반복하는 방식보다 직무별로 나누는 편이 효과적이다. 마케팅팀은 고객 페르소나와 리뷰 분석에서 개인정보를 제거하는 법을 배워야 한다. 영업팀은 고객사 리서치와 제안서 작성 시 계약정보를 보호하는 법을 알아야 한다. 개발팀은 코딩 AI에 소스코드를 제공할 때 비밀값과 라이선스, 취약점 문제를 점검해야 한다. 임원은 AI 요약 보고서가 잘못된 정보를 포함할 수 있으며, 고위험 의사결정은 사람의 검토를 거쳐야 한다는 점을 이해해야 한다.

AI 보안은 회사의 속도를 늦추기 위한 브레이크가 아니다. 오히려 제대로 만든 보안 체계는 AI 도입 속도를 높인다. 어떤 데이터를 넣어도 되는지 모르면 직원은 매번 눈치를 본다. 어떤 도구가 승인되었는지 모르면 각자 다른 서비스를 쓴다. 접근 권한이 정리되지 않으면 에이전트와 자동화는 위험해서 확대할 수 없다. 반대로 데이터 등급, 승인 도구, 계정 통제, 로그 모니터링, 예외 승인 절차가 명확하면 조직은 훨씬 과감하게 AI를 업무 흐름에 넣을 수 있다.

AI 네이티브 기업은 AI를 많이 쓰는 회사가 아니다. AI를 안전하게 반복 사용할 수 있는 회사다. 보안이 약한 회사는 파일럿에서 멈춘다. 보안이 잘 설계된 회사는 AI를 부서와 프로세스 전체로 확장한다. 결국 AI 보안의 목표는 단 하나다. 직원이 겁먹지 않고, 회사가 무방비 상태가 되지 않으며, 고객이 신뢰를 잃지 않는 방식으로 AI와 함께 일하게 만드는 것이다.

참고

¹Cloud Security Alliance, How to Secure AI in the Enterprise: A Practical Framework for Models, Data, and Agents

²heyData, ChatGPT & Data Protection: A Guide for Businesses in the EU

³Palo Alto Networks, How to Build a Generative AI Security Policy

⁴OpenAI, Enterprise privacy at OpenAI

⁵Red Hat, AI security: Identity and access control

⁶Microsoft Security, New tools and guidance: Announcing Zero Trust for AI

⁷Varonis, ChatGPT DLP: What Enterprises Need to Know

⁸Microsoft, Guide for securing the AI-powered enterprise

⁹SANS Community, Critical AI Security Guidelines v1.1