AI 거버넌스 정책 작성 방법 (+ 포함할 내용)

조직의 단 11%만이 AI 보안에 완전히 준비되어 있다고 The Netwrix 2026 Data and Identity Security Report에 따르면 나타났습니다.

대부분 조직에서의 AI 도입은 보안 검토가 따라잡기 전에 개별 도구 선택을 통해 이루어졌습니다: 직원들은 Microsoft Copilot, ChatGPT 및 수십 가지 내장 AI 기능을 일상 업무에 연결했으며, 누군가가 해당 도구들이 접근할 수 있는 내용을 규정하는 접근 규칙을 작성하기 전이었습니다.

이 위험은 AI 접근이 일반 사용자 요청과 다른 검토 패턴을 따르기 때문에 계속 존재합니다. 이러한 도구와 그 뒤에 있는 에이전트 ID는 권한을 상속하고, 민감한 콘텐츠를 조회하며, 수동 검토가 이를 분류하는 것보다 더 빠르게 새로운 감사 질문을 생성할 수 있습니다.

보안 팀은 어떤 도구가 존재하는지, 어떤 데이터에 접근할 수 있는지, 누가 승인했는지, 팀이 어떻게 예외를 처리하는지에 대한 가시성이 필요합니다. 서면 정책은 사고가 문제를 제기하기 전에 AI가 무엇을 다룰 수 있는지 정의하여 사이버 복원력을 강화하고 AI 도입에 책임을 부여합니다.

AI 거버넌스 정책이란 무엇인가요?

AI 거버넌스 정책은 조직의 직원, 계약자 및 공급업체가 AI 도구를 어떻게 사용할 수 있는지에 대한 규칙을 정의하는 문서입니다. 이 도구들이 접근할 수 있는 데이터, 조직이 승인하는 도구, 그리고 팀이 위반 사항을 어떻게 보고하는지 등이 포함됩니다.

팀들은 종종 "AI 거버넌스"와 "AI 정책"을 혼용하지만, 이는 같은 문제의 다른 층을 설명하며 구분은 누가 무엇을 책임지는지를 결정합니다.

AI 거버넌스 프레임워크는 정책이 작동하는 더 넓고 지속적인 프로그램으로, 정책을 최신 상태로 유지하는 역할, 검토 주기 및 도구를 포함합니다. 외부 참조 프레임워크로는 NIST AI Risk Management Framework (AI RMF) 및 ISO/IEC 42001, 가 프레임워크의 구조를 제공하며, 정책은 해당 구조를 팀이 따를 수 있는 규칙으로 변환합니다.

AI 거버넌스 정책의 예는 무엇인가요?

추상적인 원칙은 동의하기는 쉽지만 구현하기는 어렵습니다. 엔터프라이즈 소프트웨어, 의료, 금융 서비스 및 방위 계약의 참조 정책은 데이터 유형과 규제에 따라 요구 사항이 어떻게 달라지는지 보여줍니다.

Enterprise Copilot 및 대형 언어 모델(LLM) 데이터 액세스 정책

이것들은 대부분의 중견 시장 보안 팀이 작성해야 하는 것과 가장 유사한 예시이며, 특정 산업 규정을 따르는 경우를 제외합니다. 이들은 Microsoft 365 Copilot 또는 ChatGPT와 같이 이미 사용 중인 특정 도구 범주에 연결된 데이터 접근 규칙에 초점을 맞추어 실제 작업 흐름에 기반한 시행을 유지합니다. 이러한 정책은 종종 민감도 라벨과 운영 모델을 결합하여 분류 체계 소유권과 기술적 시행을 분리합니다.

의료 AI 거버넌스 정책

의료 기관은 Health Insurance Portability and Accountability Act(HIPAA)를 중심으로 이러한 정책을 수립하며, 임상 AI 사용(진단 또는 환자 대상 도구, 가장 엄격한 접근 및 감사 규칙 적용)과 행정 AI 사용(일정 관리, 청구, 내부 문서화)을 구분합니다. 두 가지는 동일한 규정 하에서 서로 다른 위험 수준을 가지기 때문입니다. 모델 정책: 조직은 공급업체가 Business Associate Agreement를 체결한 경우에만 AI 도구에 보호 건강 정보(PHI)를 입력할 수 있습니다.

금융 서비스 및 국방 계약 AI 거버넌스 정책

이들은 각각 특정 프레임워크를 기반으로 합니다. 금융 서비스는 Service Organization Control 2 (SOC 2), 일반 데이터 보호 규정(GDPR), Digital Operational Resilience Act (DORA)를 포함하며, 방위 계약은 Cybersecurity Maturity Model Certification (CMMC). 두 경우 모두 AI 도구가 고객 금융 데이터 또는 통제된 비분류 정보(CUI)에 접근하는지 여부에 따라 위험 등급이 직접 연결됩니다.

방위 정책은 더 나아가서, Information Security Oversight Office (ISOO) 지침에 따라 계약자는 공개 또는 소비자용 AI 도구에 CUI를 전혀 입력할 수 없으며, CUI를 처리하는 모든 AI 도구는 계약자의 시스템 보안 계획에 포함되어야 합니다.

이 예제를 사용하여 조직이 실제로 보유한 도구, 데이터 유형 및 준수 의무에 정책을 기반하세요.

AI 거버넌스 정책이 중요한 이유

서면 정책은 보안 팀이 측정, 시행 및 개선할 수 있는 AI 도입 거버넌스 모델을 제공합니다. 또한 도구 승인, 데이터 접근, 모니터링 및 에스컬레이션을 검토 가능한 증거로 전환합니다.

AI 도입은 보안이 평가할 수 있는 속도보다 더 빠르게 공격 표면을 확장합니다

새로운 Copilot, ChatGPT 또는 내장 AI 기능은 조직 데이터를 액세스해야 하며, 각각은 관리해야 할 새로운 액세스 경로를 만듭니다. Netwrix 2026 Data and Identity Security Report에 따르면 76%가 환경 내 비인간 아이덴티티를 완전히 관리하거나 모니터링하지 않아 대부분의 AI 도구 도입이 지속적인 가시성 없이 이루어집니다.

규제 프레임워크가 자발적 지침에서 강제 집행으로 전환되고 있습니다

EU AI Act의 적합성 평가 의무는 고위험 시스템에 대해 일반적으로 2026년 8월 2일부터 적용됩니다, 부록 I 제품 법률에 따른 고위험 시스템은 2027년 8월 2일부터 적용됩니다. 문서화된 정책은 조직이 의무화되기 전에 요구사항을 추적했음을 보여주는 데 도움이 됩니다. 규제가 발효되기 전까지 아무것도 기록하지 않으면 선의의 노력을 입증할 증거가 없습니다.

감사자와 이사회는 이제 문서화된 정책을 기대합니다

경영진이 "AI에 대해 안전한가요?"라고 물을 때, 서면 정책은 그 답변이 단순한 의견 이상임을 증명합니다. 구두 보장은 감사나 사고 검토 시 무너집니다. 정책은 보안 태세를 감사자가 읽을 수 있고 이사회가 지적할 수 있는 형태로 번역하여 ISO/IEC 42001에 공식화된.

최소 권한 원칙은 정책이 액세스를 정의할 때만 AI 도구에 적용됩니다

보안 팀은 수년간 역할별로 인간 접근을 제한해 왔습니다. 팀은 종종 AI 도구를 기본적으로 동일한 규율에서 제외하며, 이를 배포한 인간의 확장 또는 일반 서비스 계정으로 취급합니다. Identity guidance 는 두 접근 방식을 모두 권장하지 않습니다. 왜냐하면 least privilege 는 범위가 지정되고 책임 있는 접근을 요구하기 때문입니다. 정책은 AI 도구를 자체 계정 유형으로 지정하여 실제 접근 제한을 적용합니다.

하나 없는 조직은 이미 비용을 지불하고 있습니다

Netwrix 2026 Data and Identity Security Report에 따르면 72%의 조직이 AI 및 자동화로 인해 지난 2년간 민감한 데이터에 대한 identity 관련 위험이 증가했다고 말합니다. 정책 격차는 이미 위험 데이터에 나타나며, 이를 보고하는 조직은 AI를 가장 빠르게 도입하는 곳입니다.

AI 거버넌스 정책에 포함할 내용

사용 가능한 정책은 보안, 법무, IT 및 데이터 소유자가 승인 및 접근에 대한 결정으로 해석할 수 있는 조항이 필요합니다. 각 조항은 정책 문구를 소유자, 도구, 데이터 범주 또는 이를 집행 가능하게 하는 통제와 연결해야 합니다.

• 범위 및 적용 대상: 정책이 적용되는 대상과 범위를 정의하며, 직원, 계약자, 공급업체 및 이미 사용 중인 shadow AI 도구를 포함합니다. 명확한 범위가 없으면 정책은 사람들이 이미 알고 있는 도구에만 적용되며 나머지는 관리되지 않습니다.
• 거버넌스 역할 및 운영 위원회: 정책 소유자 이름과 정책을 벗어나는 사항이 있을 때 보고할 대상. 지정된 소유자가 없으면 "정책 집행"은 문제를 가장 먼저 발견한 사람이 담당합니다.
• 위험 분류: 데이터나 결정에 따라 AI 사용 사례를 낮음, 중간, 높음 위험으로 분류합니다. 등급이 없으면 모든 AI 사용 사례가 동일한 수준의 검토를 받아 고위험 사용 사례는 과소평가되고 저위험 사용 사례는 불필요한 마찰을 일으킵니다.
• 데이터 접근 및 사용 규칙: AI 도구의 각 위험 등급이 접근할 수 있는 데이터와 접근할 수 없는 데이터를 명시합니다. 이는 가치 진술을 집행 가능한 통제로 전환하는 조항입니다. 이것 없이는 "책임 있는 AI 사용"에 기술적 의미가 없습니다.
• 승인된 도구 및 공급업체 검토 프로세스: 보안, 법무 및 데이터 담당자가 회사 데이터에 연결하기 전에 새로운 AI 도구를 검토하고 승인하는 방법을 설정합니다. 이 절차가 없으면 도구 채택이 보안 검토가 아닌 먼저 발견한 사람을 통해 이루어집니다.
• 모니터링 및 감사 요구사항: 조직이 팀이 정책을 실제로 준수하는지 확인하는 방법을 정의합니다. 아무도 현실과 대조하지 않는 정책은 문서상에만 존재합니다.
• 사고 대응 및 에스컬레이션: AI 도구가 보안 또는 규정 준수 문제를 일으키거나 드러낼 때 발생하는 일을 명시합니다. 이것이 없으면 팀은 AI 관련 사고를 임시방편으로, 잘못된 절차에 따라 또는 너무 늦게 처리합니다.
• 규제 정렬: 정책을 NIST AI RMF, ISO/IEC 42001 및 EU AI Act를 포함한 적용 가능한 프레임워크에 매핑합니다. 이를 통해 하나의 정책으로 여러 준수 의무를 충족할 수 있으며, 규제별로 별도의 문서를 요구하지 않습니다.
• 검토 및 업데이트 주기: 새로운 도구 카테고리, 규제 변경 또는 사고와 같은 주요 계기 후에 정해진 일정에 따라 정책을 재검토하는 데 전념하세요. AI 도구는 대부분의 정책 검토 주기보다 빠르게 변하므로 주기가 없는 정책은 몇 달 내에 구식이 됩니다.

채택과 책임의 균형을 맞춘 AI 거버넌스 정책 작성 방법

경영진은 AI 도입이 빠르게 진행되길 원하며, 보안은 부주의할 경우 그 결과를 책임집니다. 보안팀이 증거를 필요로 하는 순서대로 정책을 작성하세요: 먼저 소유자, 그 다음 도구와 데이터 흐름, 그 다음 위험 등급, 접근 규칙, 규제 매핑, 검토 주기 순입니다. 인벤토리 작성 전에 작성된 접근 규칙은 이미 노출을 일으키는 도구를 놓치는 경우가 많습니다.

1. 한 마디도 쓰기 전에 교차 기능 거버넌스 팀을 구성하세요

실제 역할을 지정하는 것부터 시작하세요: 집행, 법률 및 규제 언어 준수를 담당하는 정보 보안 또는 Identity and Access Management (IAM) 책임자, 민감한 데이터 위치를 아는 IT 또는 데이터 소유자, 일상적으로 AI 도구를 사용하는 사업 부서 대표, 예외를 승인할 수 있는 임원 후원자.

보안 내부뿐만 아니라 외부의 비즈니스 유닛을 묶을 권한이 이미 있는 역할을 기준으로 의장을 선택하세요. 보안 주도 조직에서는 CISO입니다. 위험 우선 조직에서는 고위 위험 임원이 그 역할을 맡는데, 비즈니스 유닛이 이미 기업 위험에 대해 그 역할에 보고하기 때문이며 AI 거버넌스도 동일한 권한이 필요하지 않으면 해당 유닛들이 선택 사항으로 간주할 것입니다.

역할당 한 사람으로 제한하고, 업무량이 많을 때만 보조를 둡니다. 보안 부서가 정책을 단독으로 작성하면 보안 문서처럼 읽히며 위험을 발생시키는 사업부를 관리할 권한이 부족할 수 있습니다.

2. 이미 보유한 AI 도구와 데이터 흐름을 포함하여 섀도우 AI를 인벤토리하세요

SaaS 지출, 조달 기록, 브라우저 확장, Open Authorization (OAuth) 권한 감사, 그리고 사업 부서 직접 조사를 한 번에 네 가지 출처에서 인벤토리를 구축하세요.

직원들이 ‘단순한 글쓰기 도우미’라고 생각해 자주 누락하는 도구가 있으므로 네 가지 모두를 교차 확인하세요. 구매 기록에는 개별 비용 처리된 항목이 빠질 수 있습니다. 개별 구독은 승인 기준을 넘지 않을 수 있으며, 지출 검토 시 기존 SaaS 계약 내에 포함된 AI 계층을 놓칠 수 있습니다.

Microsoft 365의 경우 Entra ID에서 엔터프라이즈 애플리케이션과 서비스 주체를 나열하고, 위임된 권한 또는 애플리케이션 Microsoft Graph 권한을 가진 항목을 표시하세요. 각 권한 부여는 AI 도구가 사용할 수 있는 액세스 경로입니다.

OAuth 동의 부여 감사 및 Microsoft의 불법 동의 부여에 대한 수정 조치는 위험한 권한을 노출하고 정리하는 데 도움이 됩니다. 각 도구의 목적, 비즈니스 소유자 및 관련 데이터를 AI 시스템 인벤토리에 기록하세요.

3. 위험 등급별로 AI 사용 사례 분류

각 사용 사례를 두 가지 기준으로 함께:

1. 도구가 다루는 데이터(공개, 내부, 규제 대상 또는 개인 식별 정보(PII)).
2. 해당 데이터를 어떻게 처리하는지(요약 및 표시, 비즈니스 의사 결정에 정보 제공 또는 자율적 조치 수행).

공개 마케팅 문구만 다시 작성하는 도구는 얼마나 정교하든 위험이 낮습니다. 고객 기록을 불러와 지원 티켓에 답하는 도구는 출력물이 평범해 보여도 위험이 높습니다.

거래를 실행하거나 생산을 변경하는 자율 도구는 최상위 계층에 위치하며 필수적인 인간 승인이 필요합니다. EU에서 운영하는 경우, 이러한 내부 계층을 EU AI Act categories 위에 겹쳐서 두 체계가 모두 보이도록 하십시오.

4. 각 위험 등급이 접근할 수 있는 데이터와 접근할 수 없는 데이터를 정의하세요

각 액세스 규칙을 위험 등급에서 데이터 범주로 직접 매핑하여 작성하세요. 저위험 도구는 민감하지 않고 이미 공개된 콘텐츠에 액세스할 수 있습니다. 중위험 도구는 특정 이미 분류된 데이터 세트에 액세스하도록 범위가 제한됩니다. 고위험 도구는 배포 전에 명시적인 서면 승인, 액세스 기록 및 지정된 인간 검토자가 필요합니다.

규제 대상 데이터의 경우 조건을 명확히 명시하세요: PHI는 서명된 Business Associate Agreement가 필요하며, CUI는 인증된 환경 외의 도구에 입력할 수 없습니다.

5. 게시하기 전에 에스컬레이션 및 사고 대응을 정의하세요

AI 도구가 보안 또는 규정 준수 문제를 일으키거나 발견했을 때 발생하는 일을 명확히 하세요: 누가 통보받는지, 얼마나 빠른지, 그리고 어떤 기존 사고 대응 프로세스가 이를 처리하는지. 1단계에서 명명된 거버넌스 역할과 에스컬레이션 경로를 연결하여, 문제가 처음 발견한 사람에게 자동으로 맡겨지는 대신 명확한 소유자가 지정되도록 하세요.

이 단계를 문서화하지 않으면 팀은 AI 관련 사건을 임시방편으로, 잘못된 매뉴얼에 따라 또는 너무 늦게 처리하게 되며, 이는 정책이 사건 발생 전에 해결해야 하는 바로 그 공백입니다.

6. 정책을 적용되는 규제 프레임워크에 매핑하세요

하나의 제어 매트릭스가 사용 중인 모든 프레임워크에 적용될 수 있습니다. 네 가지 AI RMF 기능 (Govern, Map, Measure, and Manage)를 ISO/IEC 42001 관리 시스템 조항 및 AI Act 위험 등급과 정렬한 후, 해당 결합 매트릭스에 대해 정책 언어를 한 번 작성하세요.

두 표준은 상호 보완적입니다: NIST AI RMF는 운영 위험 관리 조치를 제공하고, ISO/IEC 42001은 거버넌스 아키텍처와 감사 추적을 제공합니다. 이러한 프레임워크 전반에 걸쳐 동일한 제어 언어를 사용하면 모든 의무에 대한 중복 문서 작성을 줄일 수 있습니다.

7. 게시하기 전에 검토 주기를 설정하세요

최소 연간 단위로 특정 간격을 약속하고, 새로운 AI 도구 범주 도입, 규제 변경, 사고, 인수 또는 재조직(주요 비즈니스 프로세스 및 관련 데이터 요구 사항의 주요 변경 포함)과 같은 지정된 트리거가 비주기적 검토를 강제하도록 하십시오.

위험에 따라 주기를 조정하세요. 위험도가 높은 시스템은 팀이 더 자주 검토하고, 거버넌스 위원회는 정기적으로 회의를 진행합니다. 주기, 트리거, 담당자는 문서에 직접 작성하세요. 누군가의 머릿속에만 있는 검토 일정은 그 사람이 역할을 바꾸면 무효가 됩니다.

AI 거버넌스 정책을 실제로 시행하는 방법

정책 조항에는 보안이 검증할 수 있는 기술적 통제가 필요합니다. “정책에서 금지한다”는 답변은 가시성, 접근 검토, 경고 및 취소가 그 답변을 진실로 만들 때만 중요합니다.

AI 도구가 실제로 액세스할 수 있는 내용을 완전히 파악하세요

집행은 AI 도구와 데이터 연결의 실시간 맵에서 시작됩니다: OAuth 권한, Microsoft 365 및 Microsoft Entra ID 권한, 브라우저 확장 프로그램, 그리고 기존 SaaS 플랫폼 내에 내장된 AI 기능들.

동시에 정문을 닫으세요: 미확인 애플리케이션에 대한 사용자 동의를 비활성화하고 새 요청을 관리자 동의 워크플로우로 라우팅하여 새로운 AI 통합이 기본적으로 검토 프로세스에 들어가도록 합니다.

보안 팀은 일반적으로 인간 계정에 대해 "누가 무엇에 접근할 수 있는지"를 답할 수 있습니다. 이 단계에서는 중첩 그룹과 상속된 접근에서 비롯된 실제 권한을 포함하여 AI 도구 및 에이전트에 대한 동등한 답변을 만듭니다.

여기에는 Microsoft의 기본 도구가 도움이 되지만 Purview DSPM for AI는 상위 100개 SharePoint 사이트에 대해서만 자동 위험 평가를 실행하므로 더 넓은 data security posture 뷰가 기본 상태를 검증하고 격차를 식별하는 데 도움이 됩니다.

특히 Copilot의 경우, 민감도 레이블을 SharePoint 사이트 액세스 제한 및 Restricted Content Discovery와 결합하여 과도한 공유가 Copilot이 참조하는 기본 데이터에 도달하지 않도록 하십시오.

사람에게 적용하는 것과 동일한 방식으로 AI에 최소 권한 원칙을 적용하세요

AI 도구 및 에이전트 ID를 자체 계정 유형으로 취급하고, 동일한 액세스 검토 및 증명 워크플로우를 인간 계정에 이미 사용 중인 것과 같이 적용합니다. 광범위하고 상시 권한 대신 범위가 제한되고 만료되는 액세스를 요구하며, 입사-이동-퇴사 프로세스를 실행하여 AI 도구 폐기와 인간 퇴사 절차를 함께 관리합니다.

Zero Standing Privilege는 작업 범위의 ephemeral accounts를 사용하여 이 원칙을 모델링하며, 지속적인 권한 상승 자격 증명 대신 사용합니다.

이스트 카버 카운티 학교는 정확히 이 원칙을 적용했습니다: 학생 데이터 주변에 관리자 계정을 방치하는 대신, 해당 교육구는 필요할 때만 Netwrix Privilege Secure를 사용해 권한 있는 접근을 제한했으며, 도입 기간은 분기 프로젝트가 아닌 며칠에 걸쳐 이루어졌습니다.

모든 에이전트 ID를 human sponsor에 연결하여 인간 소유자가 떠날 때마다 각 계정에 책임 있는 소유자가 있도록 합니다. 현재 ID 지침에서는 에이전트에 대해 더 짧은 검토 주기를 권장하며, 최소 분기별, 높은 권한 에이전트는 월별로 권장합니다. 에이전트 접근 권한은 연간 인증보다 더 빠르게 변경되기 때문입니다.

AI 기반 데이터 노출을 지속적으로 모니터링하세요

모니터링은 지속적으로 이루어져야 합니다. 일회성 접근 검토는 새로운 AI 도구나 통합이 나타나는 순간 무용지물이 되기 때문입니다. 기록된 권한을 넘어 AI 도구가 실제로 조회하고 검색하는 데이터를 추적하고, 승인된 사용 범위를 벗어나는 양 또는 민감도 패턴을 표시하세요.

Microsoft 365에서는 Copilot 상호작용이 통합 감사 로그에 기록되므로, 감사자가 작년 기록을 요청하기 전에 정책이 약속한 증거 보존 기간과 감사 보존 기간이 일치하는지 확인하세요. 이를 통해 보안 팀은 정책의 접근 규칙이 실제 AI 동작과 일치함을 입증할 수 있습니다.

Netwrix AI Governance, Netwrix 1Secure™를 통해 제공되며, 보안 팀이 감사 증거로 보존할 수 있는 Copilot 상호작용 추적 및 보고 기능을 추가합니다.

AI 도구가 접근 경계를 넘을 때 경고 및 에스컬레이션을 자동화하세요

탐지는 정책에서 이미 정의한 에스컬레이션 경로를 트리거할 때만 가치가 있습니다. 발견 사항을 정책의 거버넌스 섹션에 명시된 incident response process 로 자동으로 전달하고 모든 경고를 감사 증거로 기록하세요. 에스컬레이션 경로는 명확한 소유권과 일정이 있는 작동하는 철회 프로세스와 연결되어야 합니다.

AI 거버넌스 정책을 집행 가능한 통제로 전환하세요

각 조항이 기술적 통제에 대응할 때 서면 정책은 위험을 줄입니다: AI 도구가 접근할 수 있는 내용에 대한 가시성, AI 아이덴티티에 대한 최소 권한, 그리고 지속적인 모니터링.

많은 AI 관련 위험은 신원 사고와 동일한 접근 경로를 따릅니다: 공격자는 합법적인 자격 증명을 사용해 데이터에 접근하며, 과도한 상시 접근 권한을 가진 AI 도구는 환경 내 또 다른 과도 권한 부여된 신원이 됩니다.

데이터 보안과 아이덴티티 보안은 두 가지 관점에서 본 동일한 문제이며, 정책은 둘 다 함께 시행될 때만 위험을 줄입니다.

데모 요청하여 1Secure가 AI 도구 접근을 매핑하고, Copilot 상호작용을 추적하며, 정책의 접근 규칙을 감사 증거로 전환하는 방식을 확인하세요.