Shadow AI는 모두 차단해야 할까?｜Risk Tiering으로 승인·제한·금지 기준을 정하는 방법

Shadow AI Risk Tiering AI 위험도 승인 제한 금지 기준

AI Risk Management와 Enterprise AI Governance의 핵심은 회사에서 발견한 AI를 전부 막는 것이 아니라, 데이터 접근 범위·실행 권한·자율성·영향도를 기준으로 위험을 구분하고 그에 맞는 통제를 설계하는 데 있습니다.

Shadow AI를 발견한 뒤 필요한 다음 질문은 “누가 몰래 썼나?”보다 **“이 AI가 무엇을 보고, 무엇을 바꾸며, 잘못됐을 때 어디까지 영향을 줄 수 있나?”**에 가깝습니다.

오늘은 AI Inventory → Shadow AI Discovery 다음 단계인 AI Risk Tiering을 중심으로, 기업이 AI를 승인·조건부 승인·제한·금지하는 기준을 어떻게 만들 수 있는지 핵심 개념부터 실무 적용까지 차근차근 정리해보겠습니다.

오후 2시 40분, 보안팀 화면에 처음 보는 AI 서비스가 나타났습니다.

※ 아래 내용은 특정 기업의 실제 사고가 아니라, 기업에서 발생할 수 있는 상황을 바탕으로 재구성한 가상의 시뮬레이션입니다.

목요일 오후 2시 40분.

중견 유통기업 보안팀의 모니터에 SaaS 사용 현황 보고서가 올라왔습니다. 승인 목록에는 없던 생성형 AI 서비스가 여러 개 잡혔습니다.

마케팅팀 직원은 공개된 상품 설명을 자연스럽게 다듬는 데 AI를 사용하고 있었습니다.

영업팀에서는 거래처 계약서 초안을 업로드해 핵심 내용을 요약하고 있었습니다.

고객지원팀에서는 상황이 조금 달랐습니다. AI Agent가 공동 메일함을 읽고 고객 문의를 분류한 뒤 답변 초안까지 만들고 있었습니다.

셋 다 회사가 공식 승인하지 않은 Shadow AI입니다.

그렇다면 답은 간단할까요?

“전부 접속 차단하면 되는 것 아닌가?”

그런데 여기서 문제가 뒤집힙니다.

공개 상품 문구를 다듬는 AI와 계약서를 읽는 AI, 고객 메일에 접근하는 Agent의 위험이 정말 같을까요?

같은 ‘미승인 AI’라는 이름 아래 전혀 다른 위험이 숨어 있습니다.

Shadow AI 관리에서 놓치기 쉬운 부분도 바로 여기에 있습니다.

Shadow AI 발견 다음 단계｜차단보다 AI Risk Tiering이 필요한 이유

Risk Tiering은 말 그대로 위험을 여러 층(Tier)으로 나누는 방식입니다.

아파트를 떠올리면 이해하기 쉽습니다.

공동 현관, 각 세대 현관, 개인 금고에 똑같은 잠금장치를 사용하지 않습니다. 보관하는 물건의 중요성과 접근했을 때 생길 수 있는 피해가 다르기 때문입니다.

AI도 마찬가지입니다.

공개 자료를 요약하는 AI, 회사 내부 문서를 검색하는 AI, 고객 개인정보를 읽는 AI, 결제까지 수행하는 Agent에 똑같은 통제를 적용할 이유는 없습니다.

NIST AI Risk Management Framework 공식 페이지

미국 NIST의 AI RMF는 AI 위험을 개인·조직·사회에 미치는 맥락 속에서 관리하도록 설계된 자발적 프레임워크입니다. 현재 NIST는 AI RMF 1.0 개정 작업도 진행하고 있습니다. NIST

특히 NIST AI RMF의 MANAGE 기능에서는 평가 결과에 따라 AI 위험의 우선순위를 정하고, 영향도(impact)와 발생 가능성(likelihood), 사용 가능한 자원·대응수단 등을 고려하도록 설명합니다. NIST는 동시에 모든 조직에 동일한 risk tolerance를 정해주지 않으며, 허용 가능한 위험 수준은 조직과 사용 맥락에 따라 달라질 수 있다고 밝힙니다. NIST AI Resource Center

즉, 중요한 것은 “AI니까 위험하다”가 아닙니다.

어떤 AI가, 어떤 상황에서, 어떤 위험을 만들 수 있는지를 구분하는 것입니다.

WSF 필자의 한 줄
“보이지 않는 AI를 찾는 일이 지도를 그리는 일이라면, Risk Tiering은 그 지도에 제한속도와 위험구간을 표시하는 일입니다.”

AI Inventory → Shadow AI → Risk Tiering은 무엇이 다를까?

세 개념은 비슷해 보여도 질문이 다릅니다.

AI Inventory는 “우리 조직에 어떤 AI가 존재하는가?”를 묻습니다.

Shadow AI Discovery는 “그 목록 밖에서 관리되지 않고 사용되는 AI는 무엇인가?”를 찾습니다.

그리고 AI Risk Tiering은 한 단계 더 나아갑니다.

“찾아낸 AI를 어느 수준으로 관리해야 하는가?”

즉,

Discovery → Inventory → Ownership → Risk Assessment → Risk Tier → Approval → Monitoring

이라는 흐름으로 이어집니다.

Inventory까지만 만들고 끝내면 ‘AI 목록’은 생기지만 실제 통제는 생기지 않습니다.

Risk Tiering이 필요한 이유입니다.

AI Risk Assessment 비교 분석｜제품명이 아니라 6가지 위험 축을 보세요.

AI 위험도를 “ChatGPT는 몇 등급”, “Agent는 몇 등급”처럼 제품 이름만으로 고정하면 금방 예외가 발생합니다.

같은 생성형 AI도 공개 보도자료를 다듬는 것과 고객 개인정보가 담긴 파일을 분석하는 것은 다릅니다.

같은 Agent라도 캘린더를 읽는 것과 계좌이체·파일 삭제·계정 권한 변경까지 가능한 것은 전혀 다른 문제입니다.

평가 항목	낮은 위험 예시	중간 위험 예시	높은 위험 예시	핵심 확인 질문
데이터 민감도	공개 자료	사내 일반 문서	개인정보·기밀·인증정보	무엇을 읽는가?
실행 권한	생성·요약	내부 시스템 Write	삭제·결제·권한 변경	무엇을 바꿀 수 있는가?
자율성	사람이 직접 실행	조건부 자동화	연속 자율 실행	사람 없이 어디까지 가는가?
외부 영향	개인 초안	팀·고객 응대	금융·법률·안전 영향	실패하면 누구에게 영향이 가는가?
복구 가능성	폐기 가능	수정·Rollback 가능	되돌리기 어려움	실수를 취소할 수 있는가?
추적 가능성	Owner·로그 명확	일부 기록	소유자·로그 불명확	누가 무엇을 실행했는가?

※ 모바일 화면에서는 표를 좌우로 밀어서(스크롤) 전체 내용을 확인하실 수 있습니다.

이 표의 목적은 ‘정답 점수’를 만드는 것이 아닙니다.

조직 구성원들이 왜 어떤 AI는 허용되고 다른 AI는 추가 검토가 필요한지를 같은 언어로 설명할 수 있게 만드는 것입니다.

데이터 접근 위험 가이드｜AI가 무엇을 ‘아는지’부터 확인하세요.

가장 먼저 볼 것은 데이터입니다.

공개 홈페이지를 요약하는 AI와 미공개 실적, 인사자료, 고객정보, 소스코드, 인증정보를 처리하는 AI를 같은 수준으로 관리하기는 어렵습니다.

냉장고를 떠올려보세요.

AI에게 데이터를 제공하는 것은 누군가에게 냉장고 문을 열어주는 것과 비슷합니다.

물 한 병만 꺼내도록 허용했는지, 냉장고 안을 전부 볼 수 있게 했는지, 아니면 현관 열쇠까지 함께 건넸는지는 전혀 다른 문제입니다.

그래서 기업 AI 정책에서는 단순히

“생성형 AI를 사용하는가?”

보다

“어떤 데이터가 입력되고, 어디로 전송되며, 얼마나 저장되고, 다시 어떤 목적으로 사용될 수 있는가?”

를 확인하는 것이 중요합니다.

외부 AI SaaS라면 기업용 계정 제공 여부, 데이터 처리 조건, 보존 정책, 관리자 통제 기능도 별도로 확인해야 합니다.

실행 권한 비교 가이드｜Read·Write·Delete는 같은 권한이 아닙니다.

AI가 답을 생성하는 것과 실제 시스템에서 행동하는 것 사이에는 커다란 경계가 있습니다.

메일을 읽는 권한과 보내는 권한은 다릅니다.

파일을 검색하는 권한과 수정하는 권한도 다릅니다.

수정과 삭제 역시 다릅니다.

상품 가격을 추천하는 AI와 실제 쇼핑몰 가격을 변경할 수 있는 Agent 역시 같은 위험으로 보기 어렵습니다.

OWASP LLM06:2025 Excessive Agency 공식 가이드

OWASP는 LLM 기반 시스템의 Excessive Agency 위험의 주요 원인을 과도한 기능, 과도한 권한, 과도한 자율성과 연결합니다. 대응책으로 필요한 도구·기능·권한을 최소화하고, 영향이 큰 행동에는 사람의 승인을 두는 방식을 제시합니다. OWASP Gen AI Security Project

예를 들어 이메일을 요약하는 AI라면 메일을 읽을 필요는 있어도 삭제하거나 외부로 발송할 권한까지 반드시 필요한 것은 아닙니다.

이 때문에 Risk Tier를 판단할 때는

“이 모델이 얼마나 똑똑한가?”

보다

“이 모델이 틀렸을 때 실제로 무엇을 할 수 있는가?”

라는 질문이 훨씬 중요해질 수 있습니다.

WSF 필자의 한 줄
“AI의 위험은 답변의 길이보다, 그 답변 뒤에 연결된 버튼의 힘에서 커질 수 있습니다.”

Human Oversight 가이드｜같은 권한도 ‘사람 승인’ 위치에 따라 달라집니다.

메일 발송 권한을 가진 AI를 생각해보겠습니다.

A는 답변 초안만 작성합니다. 사람이 검토하고 ‘보내기’를 눌러야 합니다.

B는 사람이 정해놓은 조건에 맞으면 자동으로 답장을 보냅니다.

C는 받은 메일을 읽고 고객을 분류하고, 필요한 자료를 찾고, 답변을 작성하고, 첨부파일까지 선택한 뒤 스스로 발송합니다.

‘이메일 AI’라는 이름은 같지만 Autonomy, 즉 자율성은 완전히 다릅니다.

여기서 Human-in-the-Loop라는 개념이 등장합니다.

사람이 모든 작업을 다시 손으로 해야 한다는 의미는 아닙니다.

기차가 모든 구간에서 멈추는 것이 아니라 선로가 갈라지는 중요한 지점에 신호기를 설치하는 것과 비슷합니다.

고객 환불, 계약 확정, 계정 권한 변경, 외부 공개, 결제, 데이터 삭제처럼 결과가 큰 지점에 승인 단계를 배치하는 것입니다.

OWASP의 AI Agent Security 가이드 역시 Agent가 불필요하게 높은 권한을 갖지 않도록 최소권한을 적용하고, 민감한 작업에는 명시적 도구 승인을 적용하는 방식을 권고합니다. OWASP Cheat Sheet Series

AI Risk Tier 포트폴리오｜승인·조건부 승인·제한·금지를 나누는 방법

여기서 주의할 점이 있습니다.

아래 4단계는 NIST가 모든 기업에 의무적으로 지정한 공식 등급이 아닙니다.

NIST AI RMF의 위험 기반 접근을 참고해 기업 내부 운영정책으로 활용할 수 있도록 재구성한 예시 프레임입니다. NIST의 AI RMF Profile 자체도 조직의 요구사항·risk tolerance·자원과 사용 맥락에 맞춰 적용하도록 설계돼 있습니다. NIST AI Resource Center

Tier 1｜승인 — 공개·저영향 AI

공개 자료 요약, 아이디어 발산, 비민감 문구 교정처럼 데이터 민감도가 낮고 외부 시스템 실행 권한이 없는 경우입니다.

기본적인 사용정책과 계정 관리, 허용 데이터 기준을 충족하면 비교적 간소화된 승인 절차를 적용할 수 있습니다.

Tier 2｜조건부 승인 — 내부 데이터 접근형 AI

사내 일반 문서 검색, 내부 회의록 정리, 코드 보조처럼 업무 효율은 높지만 회사 데이터에 접근하는 경우입니다.

기업 계정 사용 여부, 허용 데이터, 보존 정책, 연결 시스템, Owner, 접근권한 등을 확인한 뒤 조건부로 허용하는 방식을 고려할 수 있습니다.

Tier 3｜제한 — 민감 데이터 또는 실제 실행형 AI

개인정보·인사·재무자료를 처리하거나 고객 응대, 외부 메일 발송, DB Write처럼 실제 결과를 만드는 시스템입니다.

별도의 보안 검토, 최소권한, 승인 게이트, 로그, 모니터링, 정기 재평가 같은 추가 통제가 필요할 수 있습니다.

Tier 4｜금지 또는 별도 예외심사 — 통제하기 어려운 고위험 조합

소유자가 불명확하고 민감정보를 광범위하게 읽으면서 삭제·결제·계정 변경처럼 되돌리기 어려운 행동까지 사람 승인 없이 수행하며, 감사 로그와 중지 수단도 부족하다면 높은 수준의 제한이나 별도 예외심사를 검토할 수 있습니다.

여기에 중요한 반전이 있습니다.

‘금지’는 특정 AI 제품에 영원히 붙이는 딱지가 아니라 사용 맥락과 권한의 조합에 대한 판단이어야 더 정교해집니다.

동일한 서비스도 공개 데이터로 문구를 작성할 때와 고객정보·결제 API까지 연결했을 때의 위험은 달라질 수 있기 때문입니다.

AI Approval Workflow 실전 가이드｜7가지 질문으로 위험도를 좁혀보세요.

Risk Assessment 양식을 너무 복잡하게 만들면 또 다른 문제가 생깁니다.

직원들이 공식 승인 절차보다 개인 계정과 비공식 도구를 선택할 유인이 커질 수 있다는 점입니다.

그래서 초기 검토는 다음 7가지 질문으로 단순화해볼 수 있습니다.

1. 이 AI를 사용하는 업무 목적은 무엇인가?
2. 공개·내부·기밀·개인정보 중 어떤 데이터를 처리하는가?
3. 메일·파일·DB·API·SaaS 가운데 무엇과 연결되는가?
4. Read·Write·Delete·Send·Pay 가운데 어떤 행동이 가능한가?
5. 사람이 확인하지 않아도 자동으로 실행되는가?
6. 잘못 실행되면 취소·중지·Rollback이 가능한가?
7. Owner·로그·재평가 날짜가 정해져 있는가?

여기서 Owner는 문제가 발생했을 때 책임을 뒤집어쓸 사람이라는 뜻이 아닙니다.

사용 목적, 데이터 범위, 권한 변경, 공급자 변경, 재검토와 폐기 여부를 지속적으로 관리할 주체입니다.

주인이 없는 AI는 시간이 흐를수록 시스템은 남아 있는데 관리 책임은 사라지는 ‘고아 자산’이 되기 쉽습니다.

WSF 필자의 한 줄
“좋은 AI 정책은 직원에게 ‘쓰지 마세요’라고 끝나는 문서가 아니라, 안전하게 쓰려면 무엇을 준비해야 하는지 알려주는 사용설명서에 가깝습니다.”

AI Risk Score를 만들 때 숫자만 믿으면 안 되는 이유

Risk Tiering을 시작하면 자연스럽게 점수표를 만들고 싶어집니다.

데이터 민감도 3점, 실행권한 3점, 자율성 3점, 외부 영향 3점….

숫자로 바꾸면 객관적으로 보입니다.

하지만 숫자는 판단을 돕는 도구이지 판단 자체가 아닙니다.

예를 들어 민감정보를 거의 다루지 않더라도 실제 송금을 수행하는 Agent는 결과의 영향이 매우 클 수 있습니다.

반대로 많은 내부 문서를 검색하더라도 읽기 전용이고 외부 전송이 차단되어 있으며 강한 접근통제가 적용된다면 위험의 성격이 달라집니다.

그래서 단순 합산점수와 함께 **‘즉시 상향 조건’**을 만드는 방법을 고려할 수 있습니다.

결제, 삭제, 계정 권한 변경, 대규모 개인정보 처리, 안전 관련 의사결정, 되돌리기 어려운 외부 실행 같은 조건이 포함되면 총점과 별개로 추가 심사를 거치는 방식입니다.

경제적인 관점에서는 이를 Risk-Adjusted Resource Allocation, 즉 위험을 고려한 자원 배분이라고 이해할 수 있습니다.

모든 AI에 최고 수준의 심사를 적용하면 검토 인력과 시간, 도입 비용이 과도해집니다.

반대로 모든 AI를 빠르게 허용하면 사고 대응과 규제 대응 비용이 커질 수 있습니다.

따라서 위험이 큰 곳에 더 많은 검토 자원을 배치하고 낮은 위험은 상대적으로 빠르게 처리하는 것이 Risk Tiering의 중요한 운영 가치입니다.

Shadow AI를 모두 차단하면 오히려 더 안 보일 수도 있습니다.

여기가 이번 글에서 가장 중요한 지점입니다.

직원은 왜 승인받지 않은 AI를 사용할까요?

규칙을 무시하기 때문이라고만 볼 수는 없습니다.

공식 도구에 필요한 기능이 없거나, 승인까지 너무 오래 걸리거나, 회사에서 어떤 AI를 사용할 수 있는지 알기 어렵거나, 기존 시스템보다 개인용 AI가 업무를 훨씬 빠르게 해결해주는 상황도 있을 수 있습니다.

따라서 Shadow AI Discovery는 처벌 목록을 만드는 과정인 동시에 현업의 수요를 발견하는 과정이 될 수 있습니다.

여러 부서에서 같은 AI가 반복적으로 발견된다면 질문을 바꿔보세요.

“왜 규칙을 어겼을까?”

보다

“왜 직원들이 이 도구를 반복해서 필요로 할까?”

가 더 생산적인 질문일 수 있습니다.

공식 대체 도구가 부족한지, 기존 라이선스가 불편한지, 승인 과정에 병목이 있는지, 업무 프로세스에 자동화되지 않은 빈틈이 있는지 찾아낼 수 있습니다.

보안팀과 현업이 서로를 막는 관계에서 벗어나 업무 생산성과 안전성을 함께 설계하는 관계로 바뀌는 순간입니다.

Risk Tiering의 따뜻한 면도 여기에 있습니다.

통제의 목적은 사람을 의심하는 것이 아니라, 사람들이 일을 더 잘하기 위해 찾아낸 도구를 조직이 안전하게 받아들일 수 있는 통로를 만드는 데 있습니다.

AI Governance 운영 가이드｜Risk Tier는 한 번 정하면 끝일까?

아닙니다.

AI 서비스는 계속 변합니다.

처음에는 텍스트 생성만 제공하던 서비스가 파일 연결을 추가할 수 있습니다.

다음 업데이트에서는 이메일에 접근할 수 있습니다.

이후에는 Agent 기능을 통해 외부 시스템까지 실행할 수 있습니다.

기업 내부에서도 처음에는 공개 자료만 넣다가 어느 순간 고객 데이터가 연결될 수 있습니다.

따라서 Risk Tier에는 재평가 트리거를 붙이는 편이 좋습니다.

새 API 연결, 권한 확대, 개인정보 처리 시작, 자동 외부 실행 추가, 모델·공급자 변경, 사용 부서 확대, 중요한 보안사고가 발생하면 다시 평가하는 방식입니다.

NIST 역시 배포된 AI 시스템의 방법·맥락·위험·관련 이해관계자의 요구가 변화함에 따라 MANAGE 기능을 지속적으로 적용해야 한다고 설명합니다. NIST AI Resource Center

그래서 장기적으로는 이런 순환구조가 필요합니다.

Discovery → Inventory → Ownership → Risk Tier → Approval → Monitoring → Reassessment

AI Inventory가 살아 있는 자산대장이 되고, Shadow AI Discovery가 새 자산을 찾아내며, Risk Tiering이 관리 수준을 정하고, Monitoring이 변화를 다시 Inventory로 돌려보내는 구조입니다.

이때 AI Governance는 ‘금지 목록’이 아니라 운영 시스템이 됩니다.

기존 Shadow AI 글과 검색 의도를 겹치지 않게 만드는 방법

이번 글에서 Shadow AI를 제목에 사용하더라도 본문의 핵심 검색 의도는 Shadow AI Discovery가 아닙니다.

전편은

“회사 관리 밖에 있는 AI를 어떻게 발견할 것인가?”

를 담당합니다.

이번 글은

“발견한 AI를 어떤 위험 기준으로 평가하고, 어떤 통제를 연결할 것인가?”

를 담당합니다.

따라서 SEO 중심축도 분리합니다.

전편: Shadow AI → Shadow AI Discovery → Personal API Key → SaaS AI → Visibility

이번 글: AI Risk Tiering → AI Risk Assessment → AI Risk Classification → AI Governance → Approval Workflow

후속 확장: AI Vendor Risk Assessment → Third-Party AI Risk → AI Compliance → Continuous Monitoring

첨부 조사자료에서도 AI Risk Tiering을 메인으로, AI Risk Assessment와 AI Risk Management를 검색량 확장축, AI Governance와 AI Compliance를 상업 검색 확장축으로 가져가는 구성이 제안되어 있습니다. 붙여넣은 텍스트(1)

이렇게 분리하면 AI Inventory → Shadow AI Discovery → AI Risk Tiering이라는 콘텐츠 클러스터의 역할도 선명해집니다.

FAQ｜Shadow AI와 AI Risk Tiering에서 자주 묻는 질문

Q. 발견한 Shadow AI는 모두 즉시 차단해야 하나요?

그렇게 일반화하기는 어렵습니다. ‘미승인 여부’와 ‘위험 수준’은 구분할 필요가 있습니다. 데이터 민감도, 실행 권한, 자율성, 영향도, 복구 가능성 등을 평가해 조직의 정책과 risk tolerance에 맞는 대응을 정하는 방식이 현실적입니다. 다만 법률·계약·보안정책상 명백하게 금지된 데이터 처리나 심각한 보안 위반은 별도의 즉각적인 대응이 필요할 수 있습니다.

Q. AI Risk Tier는 몇 단계가 좋을까요?

모든 기업에 적용되는 하나의 정답은 없습니다. 3단계나 4단계처럼 직원들이 이해하기 쉬운 구조로 시작할 수 있습니다. 중요한 것은 단계의 개수보다 각 Tier에 승인 주체·필수 통제·사용조건·재평가 기준이 연결돼 있는지입니다.

Q. ChatGPT 같은 생성형 AI는 모두 같은 Risk Tier인가요?

제품명만으로 고정하기보다 계정 유형, 입력 데이터, 연결 시스템, 사용 목적, 실행 권한과 자동화 수준을 함께 평가하는 것이 더 적절합니다.

Q. AI Agent는 일반 챗봇보다 무조건 위험한가요?

Agent는 외부 도구를 호출하고 행동을 실행할 수 있어 추가적인 위험 요인이 생길 수 있습니다. 그러나 실제 위험은 권한·자율성·데이터·영향 범위에 따라 달라집니다. 읽기 전용 Agent와 결제·삭제 권한을 가진 Agent를 같은 위험으로 보는 것은 지나치게 단순합니다.

Q. AI Risk Tiering과 AI Inventory는 무엇이 다른가요?

Inventory는 어떤 AI가 존재하고 누구의 소유이며 무엇과 연결되어 있는지를 기록하는 장부에 가깝습니다. Risk Tiering은 그 자산을 평가해 어떤 수준으로 승인하고 통제할지를 결정하는 규칙입니다.

필자의 주관적인 마무리 의견

저는 Shadow AI 문제를 단순히 **“직원이 몰래 AI를 사용했다”**는 한 문장으로 정리하면 중요한 절반을 놓친다고 생각합니다. 조직이 정말 알아야 할 것은 그 AI가 왜 필요했는지, 어떤 데이터에 닿았는지, 어떤 권한을 받았고 어디까지 행동할 수 있었는지입니다.

모든 AI를 막는 정책은 문서상으로는 단순합니다. 하지만 현실에서는 개인 계정이나 비공식 도구의 사용을 더 깊은 곳으로 밀어 넣을 가능성도 생각해야 합니다. 반대로 아무런 기준 없이 편의성만 따라가면 언젠가는 보안·규제·운영비용이라는 다른 형태의 청구서를 받을 수 있습니다.

그래서 좋은 AI Governance는 회색지대를 무조건 없애는 것이 아니라, 회색지대를 설명 가능한 단계로 나누는 일이라고 봅니다. 낮은 위험은 빠르게 승인하고, 중간 위험은 조건을 붙이며, 높은 위험은 사람의 승인과 강한 통제를 요구하고, 조직이 감당하기 어려운 조합은 멈추는 것입니다.

AI 도입의 성숙도는 회사가 몇 개의 최신 AI를 쓰고 있느냐만으로 판단하기 어렵습니다. 오히려 어떤 AI를 사용하는지 알고 있는가, 누가 책임지고 있는가, 무엇에 접근하는가, 위험을 설명할 수 있는가, 상황이 바뀌었을 때 다시 평가할 수 있는가가 더 중요한 기준이 될 수 있습니다.

결국 Risk Tiering은 보안팀만을 위한 위험표가 아닙니다. 생산성, AI 투자비용, 보안비용, 규제 대응, 업무 연속성을 함께 바라보는 기업의 디지털 자산 관리 포트폴리오에 가깝습니다. AI를 많이 쓰는 회사보다 AI를 어디까지 맡겨도 되는지 설명할 수 있는 회사가 더 안정적으로 AI를 확장할 가능성이 높다고 생각합니다.

함께 보면 좋은 추천 포스팅

첨부한 최신 게시 목록을 기준으로 이번 글과 가장 자연스럽게 연결되는 것은 AI Inventory → Shadow AI Discovery → AI Risk Tiering의 3단 구조입니다. 실제 목록에도 9월 25일 AI Inventory와 9월 26일 Shadow AI 글이 연속 배치돼 있어 이번 Risk Tiering 글의 선행 콘텐츠로 활용하기 좋습니다. 구글블로그포스팅_게시일과제목_URL

① 기업은 어떤 AI를 사용 중인지 알고 있을까?｜AI Inventory로 모델·데이터·API·Agent 자산을 추적하는 방법

Shadow AI를 평가하기 전에 먼저 조직 안에 어떤 모델·데이터·API·Agent가 존재하는지 알아야 합니다. Risk Tiering의 출발점인 AI Inventory와 AI Asset Registry 구조를 먼저 이해하고 싶다면 이 글부터 이어서 읽어보세요.

AI Inventory로 모델·데이터·API·Agent 자산 추적하기

② 회사가 모르는 AI는 어떻게 발견할까?｜Shadow AI·개인 API Key·SaaS AI가 만드는 보안 사각지대

Inventory에 등록되지 않은 AI는 평가조차 하기 어렵습니다. 직원 개인 계정, 개인 API Key, SaaS AI처럼 관리 밖에서 생기는 Shadow AI를 어떻게 발견할 것인지 먼저 살펴보면 이번 Risk Tiering 글의 흐름이 훨씬 선명해집니다.

Shadow AI와 개인 API Key·SaaS AI 보안 사각지대 알아보기

③ AI 에이전트 보안의 핵심은 ‘똑똑함’이 아니라 권한 통제입니다｜최소권한·승인·감사로그 가이드

Risk Tier가 높아지는 대표적인 순간은 AI가 단순 답변을 넘어 실제 시스템에 접근하고 행동하기 시작할 때입니다. Least Privilege·Human Approval·Audit Log가 왜 중요한지 권한 통제 관점에서 더 깊게 연결해볼 수 있습니다.

AI 에이전트 최소권한·승인·감사로그 가이드

공식 자료

본문의 사실 확인과 프레임워크 설명은 다음 공식 자료를 기준으로 교차 확인했습니다.

NIST AI Risk Management Framework 1.0

NIST Generative AI Profile — NIST AI 600-1

NIST AI RMF Playbook

OWASP LLM06:2025 Excessive Agency