1장. 감사 계획·범위와 AI 목록

학습 목표

• AI 사용 현황 목록(인벤토리)에 담을 항목을 감사 목적에 맞게 고른다.
• 자기 보고로 만든 목록의 빈틈을 사용 경로에 맞는 독립 기록으로 찾아낸다.
• 섀도 AI를 찾았을 때 감사가 할 일과 경영진이 할 일을 구분한다.
• 영향과 가능성으로 AI 시스템의 위험 순위를 매기고 감사 대상과 깊이를 정한다.
• 인공지능기본법, 개인정보 보호법, NIST AI RMF, ISO/IEC 42001을 감사 기준으로 매핑한다.
• 보증과 자문, 객관성, 전문가 활용처럼 계획 단계에서 내려야 하는 결정을 설명한다.

들어가며

중견 제조사의 감사실장이 이사회에서 이런 질문을 받았다고 해 봅시다. "요즘 다들 AI를 쓴다던데, 우리 회사의 AI 위험은 괜찮습니까?" 감사실장은 IT팀이 관리하는 목록에 승인된 도구가 네 개뿐이라는 것을 압니다. 그런데 지난주 구내식당에서 영업팀 직원들이 각자 쓰는 글쓰기 AI를 비교하는 이야기를 들었고, 구매팀은 업체가 보내 준 견적 분석 기능이 "알아서 켜졌다"고 했습니다.

"괜찮은가"라는 질문에 답하려면 먼저 "무엇이 있는가"를 알아야 합니다. 목록에 없는 것은 위험 평가에서도, 통제 점검에서도, 보고서에서도 빠집니다. 그리고 감사 자원은 늘 모자라므로, 무엇이 있는지 안 다음에는 어디에 얼마나 깊이 들어갈지 정해야 합니다. 마지막으로, 무엇을 기준으로 "괜찮다"고 말할지도 정해야 합니다. 법령인지, 국제 표준인지, 회사 스스로 정한 지침인지에 따라 같은 사실이 발견 사항이 되기도 하고 되지 않기도 합니다.

이 장은 이 세 가지, 즉 목록, 범위, 기준을 차례로 다룹니다. 먼저 AI 감사가 답하는 질문과 감사 대상인 "AI"의 경계를 정하고, 목록에 담을 항목과 목록의 빈틈을 찾는 방법을 익힙니다. 이어서 위험에 따라 감사 대상과 깊이를 정하는 방법, 감사 기준으로 쓸 법령과 프레임워크를 매핑하는 방법을 다룹니다. 끝으로 보증과 자문의 구분, 객관성, 전문가 활용처럼 계획 단계에서 놓치기 쉬운 결정을 정리합니다.

핵심 개념

AI 감사가 답하는 질문

내부감사는 조직의 거버넌스, 위험 관리, 통제 과정이 효과적인지 독립적으로 평가하고 개선을 돕는 일입니다. AI 감사도 다르지 않습니다. 다만 평가 대상에 AI 시스템과 그것을 둘러싼 사람·절차·계약이 들어갈 뿐입니다. AI 감사가 답하는 질문은 대개 다음 다섯 가지입니다.

1. 조직은 자신이 쓰는 AI를 알고 있는가? (목록과 범위, 이 장)
2. AI의 위험을 줄이는 통제가 제대로 만들어졌고, 실제로 작동하는가? (2장)
3. 그 판단을 뒷받침할 증거는 충분하고 믿을 만한가? (3장)
4. 모델과 데이터는 주장하는 만큼 정확하고 공정하며, 변해도 관리되는가? (4장)
5. 문제를 찾았을 때 고칠 수 있게 알렸고, 실제로 고쳐졌는가? (5장)

감사인이 하지 않는 일도 분명히 해 둡시다. 감사인은 AI 도구를 승인하거나 금지하지 않고, 통제를 직접 설계하거나 운영하지 않으며, 직원을 징계하지 않습니다. 미국 GAO의 정부감사기준(Yellow Book)은 내부통제의 설계·구현·유지에 책임을 지는 일, 감사인의 권고 가운데 무엇을 실행할지 정하는 일 등을 경영진의 책임으로 들고, 감사인이 이런 책임을 맡으면 독립성이 손상된다고 봅니다(GAO 3.78, 3.81). 비유하자면 감사인은 건물의 안전 점검자이지 시공사가 아닙니다. 점검자가 벽을 직접 고치기 시작하면 다음 점검에서 자기 공사를 평가하게 됩니다.

무엇을 AI로 볼 것인가

목록을 만들기 전에 경계를 정해야 합니다. 인공지능기본법은 "인공지능"을 학습, 추론, 지각, 판단, 언어의 이해 등 인간이 가진 지적 능력을 전자적 방법으로 구현한 것으로, "인공지능시스템"을 다양한 수준의 자율성과 적응성을 가지고 주어진 목표를 위해 실제 및 가상환경에 영향을 미치는 예측, 추천, 결정 등의 결과물을 추론하는 인공지능 기반 시스템으로 정의합니다(제2조제1호·제2호). 글, 소리, 그림, 영상 등을 생성하는 시스템은 "생성형 인공지능"으로 따로 정의합니다(제2조제5호).

감사 실무에서는 법적 정의를 출발점으로 삼되, 조직의 정책이 목록 범위를 명시적으로 정하게 하는 편이 좋습니다. 경계에서 자주 논쟁이 되는 사례는 다음과 같습니다.

NIST의 생성형 AI 프로파일(NIST AI 600-1)은 조직의 생성형 AI 시스템을 목록에 넣고, 응용 소프트웨어에 내장된 생성형 AI에 대한 목록 예외가 있다면 조직 정책에서 정하라고 제안합니다(GV-1.6-001, GV-1.6-002). 예외는 있어도 되지만, 정책에 적혀 있어야 합니다.

AI 목록의 역할과 항목

NIST AI RMF는 AI 시스템을 목록화하는 체계를 두고, 그 체계에 조직의 위험 우선순위에 맞게 자원을 배정하라고 합니다(GOVERN 1.6). 목록은 감사의 출발점이자 경영진의 위험 관리 도구입니다. 그런데 이름, 부서, 비용만 적힌 목록으로는 위험을 판단할 수 없습니다. 목록의 항목은 "이 목록으로 어떤 질문에 답할 것인가"에서 거꾸로 정해야 합니다.

NIST AI 600-1은 생성형 AI 목록 항목의 예로 데이터 출처 정보(출처, 서명, 버전, 워터마크), 내부 오류 추적과 외부 사고 정보에서 알려진 문제, 사람의 감독 역할과 책임, 지식재산·개인정보·민감 데이터에 대한 고려 사항, 기반 모델과 그 버전, 이용 방식을 듭니다(GV-1.6-003). 감사인은 목록이 이런 항목을 담고 있는지를 목록 자체의 "설계"로 평가할 수 있습니다.

목록의 완전성을 시험하는 방법

목록의 가장 흔한 약점은 완전성입니다. 부서 설문이나 부서장 확인서처럼 스스로 적어 낸 목록은 모르는 것, 잊은 것, 숨긴 것이 빠집니다. Yellow Book은 설문이 대개 자기 보고 정보를 제공하므로 설문의 설계와 운영을 평가해 그 신뢰성을 판단하라고 하고(GAO 8.106), 감사인이 직접 검사하거나 계산해 얻은 증거가 간접적으로 얻은 증거보다 대체로 더 신뢰할 만하다고 설명합니다(GAO 8.104).

그래서 감사인은 자기 보고 목록을 사용 흔적이 남는 독립된 기록과 대조합니다. 어떤 기록이 쓸모 있는지는 사용 경로에 달려 있습니다.

한 가지 출처로 모든 경로를 덮을 수는 없습니다. 감사인은 조직의 실제 일하는 방식(재택 비율, 결제 정책, 접속 차단 정책)을 먼저 파악하고, 빠질 가능성이 큰 경로에 맞는 출처를 고릅니다. 예를 들어 외부 AI 사이트를 차단하고 AI 결제를 경비로 인정하지 않는 회사라면 새 도구가 들어올 길은 좁지만, 이미 쓰는 서비스 안에 AI가 켜지는 길은 열려 있습니다.

섀도 AI

섀도 AI는 조직의 승인이나 관리 밖에서 쓰이는 AI를 말합니다. 대부분 악의에서가 아니라 필요에서 생깁니다. 승인 절차가 몇 주씩 걸리거나, 승인된 도구가 업무에 맞지 않거나, 무료 서비스가 너무 쉽게 손에 닿기 때문입니다.

섀도 AI를 찾았을 때 감사인이 할 일은 세 가지입니다.

1. 규모를 독립 증거로 확인한다. 이용 횟수, 이용 부서, 기간을 접속·결제 기록으로 확인합니다.
2. 위험의 크기를 평가한다. 같은 이용 횟수라도 어떤 데이터가 나갔는지에 따라 위험이 전혀 다릅니다. 업로드된 파일 종류나 입력 내용에 고객 정보가 있는지 표본으로 확인합니다.
3. 원인을 찾는다. 승인 절차가 업무 수요를 따라가지 못하는지, 승인된 대안이 없는지, 정책을 모르는지 확인합니다. 원인을 알아야 권고가 우회를 줄입니다.

반대로 이용자 명단을 징계용으로 넘기거나, 감사팀이 도구를 대신 승인해 주거나, "승인되지 않았으니 감사 범위 밖"이라고 빼는 것은 모두 잘못입니다. 앞의 두 가지는 경영진의 일이고, 마지막은 가장 큰 위험을 범위에서 지우는 일입니다.

위험 기반 범위 설정

감사 자원은 위험에 비례해 배분합니다. NIST AI RMF는 조직의 위험 허용 수준에 따라 필요한 위험 관리 활동의 수준을 정하는 절차를 두라고 하고(GOVERN 1.3), 식별된 영향마다 가능성과 크기를 파악해 문서화하라고 합니다(MAP 5.1). IIA 기준도 감사 대상 활동의 목표와 위험, 조직의 위험 허용 수준, 적용할 수 있는 기준을 이해한 뒤 중요한 위험을 식별하고 우선순위를 정하라고 요구합니다(IIA 13.2).

AI 시스템의 위험 순위를 매길 때 쓸 수 있는 신호는 다음과 같습니다.

같은 시스템이라도 어떤 신호가 두드러지느냐에 따라 감사의 중심이 달라집니다. 모델이 2년째 그대로인데 계약서가 비어 있다면 변경 관리보다 제3자 관리가 중심이고, 새로 사들인 데이터가 들어왔다면 데이터 출처가 중심입니다.

감사 깊이 정하기

모든 시스템을 같은 깊이로 볼 필요는 없습니다. 오히려 같은 깊이로 보면 가장 위험한 시스템이 충분히 다뤄지지 않습니다. 실무에서는 깊이를 몇 단계로 나눠 계획합니다.

깊이를 낮춘다고 목록에서 지우는 것은 아닙니다. 목록 유지와 감사 깊이는 별개의 결정입니다.

감사 기준의 뜻과 출처

감사 기준(criteria)은 "있어야 할 상태"입니다. Yellow Book은 기준에 법령, 규정, 계약, 표준, 측정치, 기대 성과, 정해진 업무 관행, 벤치마크가 들어갈 수 있다고 설명합니다(GAO 8.124). IIA 기준은 감사 대상 활동을 평가할 가장 관련 있는 기준을 찾고, 이사회와 경영진이 정한 기준이 적절하면 그것을 쓰되 부적절하면 협의해 적절한 기준을 찾으라고 요구합니다(IIA 13.4).

따라서 "자율 프레임워크라서 기준이 될 수 없다"는 말은 틀립니다. NIST AI RMF처럼 법적 의무가 아닌 프레임워크도 조직이 채택했거나 업계에서 널리 쓰인다면 기준이 될 수 있습니다. 다만 왜 그 기준이 적합한지를 계획서와 보고서에 밝혀야 합니다.

규제 매핑 ①: 인공지능기본법

인공지능기본법은 감사 기준으로 자주 쓰일 조항을 담고 있습니다. 여기서는 감사 계획에 필요한 만큼만 정리합니다. 어떤 시스템이 의무 대상인지에 대한 결론은 법무 판단이 필요합니다.

• 고영향 인공지능(제2조제4호). 사람의 생명, 신체의 안전 및 기본권에 중대한 영향을 미치거나 위험을 초래할 우려가 있는 인공지능시스템으로, 에너지 공급, 먹는물 생산 공정, 보건의료 제공, 의료기기, 원자력 시설, 범죄 수사의 생체인식정보 분석, 채용·대출 심사 등 개인의 권리·의무 관계에 중대한 영향을 미치는 판단 또는 평가, 교통, 공공서비스의 자격 확인·결정 등 국가기관등의 의사결정, 유아·초등·중등교육의 학생 평가, 그 밖에 대통령령으로 정하는 영역에서 활용되는 것을 말합니다.
• 투명성 확보 의무(제31조). 고영향 인공지능이나 생성형 인공지능을 이용한 제품·서비스를 제공하려면 그 사실을 이용자에게 사전에 고지하고, 생성형 결과물에는 생성 사실을 표시하며, 실제와 구분하기 어려운 가상의 음향·이미지·영상은 이용자가 명확하게 인식할 수 있게 고지 또는 표시해야 합니다.
• 고영향 인공지능의 확인(제33조). 사업자는 고영향 해당 여부를 사전에 검토해야 하며, 필요하면 과학기술정보통신부장관에게 확인을 요청할 수 있습니다. 감사인에게는 "사전 검토 기록이 있는가"가 첫 확인 사항입니다.
• 사업자의 책무(제34조). 고영향 인공지능을 제공하는 사업자는 제1항 각 호의 조치, 즉 제1호 위험관리방안의 수립·운영, 제2호 설명 방안의 수립·시행, 제3호 이용자 보호 방안의 수립·운영, 제4호 사람의 관리·감독, 제5호 조치 내용을 확인할 수 있는 문서의 작성과 보관 등을 이행해야 합니다. 여기서 사업자는 AI를 개발해 제공하는 "인공지능개발사업자"와, 개발사업자가 제공한 AI를 이용해 제품이나 서비스를 제공하는 "인공지능이용사업자"를 모두 포함합니다(제2조제7호).
• 시행령 제27조. 위험관리방안과 설명 방안의 주요 내용, 이용자 보호 방안, 관리·감독자의 성명·연락처를 게시하고(영업비밀은 제외 가능), 조치의 근거를 문서로 5년간 보관해야 합니다. 제34조제1항제1호부터 제3호까지의 조치를 모두 또는 일부 이행한 인공지능사업자로부터 시스템을 받은 이용사업자가 본래 목적이나 용도를 현저하게 바꾸는 등 중대한 기능 변경을 하지 않았다면, 그 조치를 모두 또는 일부 이행한 것으로 봅니다. 간주는 제1호부터 제3호까지에 한하므로 사람의 관리·감독(제4호)과 문서의 작성·보관(제5호)은 간주 대상이 아닙니다. 이용사업자는 개발사업자에게 필요한 자료를 요청할 수 있습니다.
• 영향평가(제35조). 고영향 인공지능을 이용한 제품·서비스를 제공할 때 사전에 기본권 영향을 평가하도록 노력해야 하며, 평가할 때는 제품·서비스의 성격을 고려해 인공지능취약계층의 특성이 반영될 수 있도록 해야 합니다. 평가 실시는 "노력하여야 한다", 취약계층 특성의 반영은 "하여야 한다"로 강도가 다르므로 기준표에 나눠 적고, 평가를 했다면 그 반영 기록을 증거 요청 목록에 넣습니다.

감사 계획에서 이 조항들은 "어떤 증거를 요청할 것인가"로 바뀝니다. 사전 검토 기록, 위험관리방안, 게시 화면, 관리·감독자 지정 문서, 5년 보관 체계, 이용사업자라면 개발사업자에게서 받은 자료와 기능 변경 여부가 요청 목록에 들어갑니다.

규제 매핑 ②: 개인정보 보호법

AI 시스템 대부분은 개인정보를 다루므로 개인정보 보호법도 자주 기준이 됩니다. 감사 계획에 자주 쓰이는 조항은 두 가지입니다.

• 업무위탁(제26조). 개인정보 처리 업무를 위탁할 때는 위탁 목적 외 처리 금지, 기술적·관리적 보호조치 등을 담은 문서로 해야 하고, 위탁 업무와 수탁자를 정보주체가 쉽게 확인할 수 있게 공개해야 하며, 수탁자를 교육하고 처리 현황 점검 등으로 감독해야 합니다. 수탁자는 위탁받은 범위를 넘어 개인정보를 이용할 수 없습니다. AI 서비스를 외부에 맡겼다면 위탁 문서, 공개, 감독 기록이 요청 목록에 들어갑니다.
• 자동화된 결정(제37조의2). 완전히 자동화된 시스템으로 개인정보를 처리해 이루어지는 결정(「행정기본법」 제20조에 따른 행정청의 자동적 처분은 제외)이 정보주체의 권리 또는 의무에 중대한 영향을 미치면, 정보주체는 그 결정을 거부할 수 있습니다(법이 정한 예외가 있습니다). 이와 별도로 정보주체는 개인정보처리자가 자동화된 결정을 한 경우 그 결정에 대해 설명 등을 요구할 수 있습니다. 개인정보처리자는 자동화된 결정의 기준과 절차, 개인정보가 처리되는 방식을 쉽게 확인할 수 있게 공개해야 합니다. 이 조항은 "완전히 자동화된" 결정에 걸리므로, 사람이 실질적으로 개입하는지가 조항이 적용되는지를 가르는 사실이 됩니다. 감사인은 사람의 개입이 형식에 그치지 않는지, 그리고 조항이 적용되는 결정이라면 거부·설명 요구를 처리하는 절차가 있는지를 확인합니다.

프레임워크 매핑 ③: NIST AI RMF, GAO 프레임워크, ISO/IEC 42001

법령 외에도 세 가지 프레임워크가 AI 감사의 기준으로 널리 쓰입니다.

ISO/IEC 42001을 다룰 때 한 가지를 꼭 기억하세요. ISO는 표준을 만들 뿐 인증을 하지 않으며, 인증은 외부 인증기관이 합니다. 내부감사의 결론은 감사한 범위와 기준 안에서만 의미가 있고, 인증을 대신하지 못합니다.

보증과 자문, 그리고 객관성

내부감사의 업무는 크게 두 가지입니다. 보증(assurance)은 통제가 효과적인지에 대한 독립적인 결론을 주고, 자문(advisory)은 경영진이 통제를 설계하거나 개선하도록 조언합니다. 구분은 시점이 아니라 목적입니다. 경영진이 통제를 설계하도록 돕는 의견 요청은 자문으로, 기준에 비추어 통제가 적정하거나 작동했는지에 대한 독립적 결론을 구하는 요청은 보증으로 수행합니다. 출시 전 설계 단계의 의견 요청은 대개 자문이고, 일정 기간 운영된 통제가 작동했는지에 대한 의견 요청은 보증입니다.

IIA 기준은 객관성을 지키기 위해 몇 가지를 요구합니다(IIA 2.2). 내부감사인은 이전에 자신이 책임을 졌던 활동을 평가하지 않아야 하며, 지난 12개월 안에 책임을 졌던 활동에 보증 업무를 하면 객관성이 손상된 것으로 추정됩니다. 이전에 자문을 했던 영역에 보증 업무를 하려면 감사 책임자가 자문의 성격이 객관성을 해치지 않는지 확인하고 인력을 배정해야 합니다. 감사 책임자 자신이 책임을 맡은 기능에 대한 보증 업무는 내부감사 조직 밖의 독립된 쪽이 감독해야 합니다. 감사 책임자가 감사 외의 책임을 한시적으로 맡았다면, 그 영역의 보증은 맡은 기간과 이후 12개월 동안 독립된 제3자가 제공해야 하고 감사 책임자는 그 책임을 경영진에 넘길 계획을 세워야 합니다(IIA 7.1).

전문가와 이전 결과 활용

AI 감사는 감사팀에 없는 전문성을 자주 요구합니다. 의료 영상 판독의 정확성이나 신용평가 모델의 통계적 타당성을 감사인이 혼자 판단하기는 어렵습니다. Yellow Book은 필요하면 전문가를 참여시키되, 그 역량과 자격, 그리고 편향·이해충돌·외부 영향이 판단에 미칠 영향을 평가하라고 하고(GAO 4.12–4.14), 전문가 작업의 목적과 범위, 사용 목적, 절차와 결과, 가정과 방법을 문서화하라고 합니다(GAO 8.32). NIST AI RMF도 시스템의 일선 개발자가 아니었던 내부 전문가나 독립 평가자가 정기 평가에 참여하라고 합니다(MEASURE 1.3). 도입을 직접 추진한 사람은 아무리 뛰어난 전문가라도 독립적인 평가자가 될 수 없습니다.

이전 결과도 계획의 재료입니다. Yellow Book은 감사 목적과 관련된 이전 감사나 연구, 그 권고의 이행 여부를 경영진에게 확인하고, 이를 위험 평가와 절차의 범위를 정하는 데 쓰라고 요구합니다(GAO 8.30). "이행했다"는 답변은 출발점일 뿐이고, 이행 여부는 테스트로 확인합니다.

깊이 읽기

내장 AI를 목록에 넣을 것인가

업무용 소프트웨어마다 AI 기능이 붙으면서 "모든 AI를 목록에 넣는다"는 원칙은 금세 감당하기 어려워집니다. 문서 편집기의 맞춤법 제안, 메일의 답장 추천, 화상회의의 자동 자막까지 모두 넣으면 목록이 수백 줄로 늘고, 정작 중요한 시스템이 묻힙니다. 반대로 내장 기능을 통째로 빼면, 고객 상담 기록을 요약해 외부 서버로 보내는 CRM 기능 같은 의미 있는 위험이 빠집니다.

NIST AI 600-1이 내장 생성형 AI의 목록 예외를 "조직 정책에서 정하라"고 한 것은 이 긴장을 정책 결정으로 드러내라는 뜻입니다. 감사인은 예외 자체를 문제 삼기보다 예외의 기준을 봅니다. 좋은 예외 기준은 "어떤 데이터가 나가는가"와 "결과가 결정에 쓰이는가"로 선을 긋습니다. 예를 들어 "회사 밖으로 데이터를 보내지 않고, 결과가 사람의 판단에 직접 쓰이지 않는 내장 기능은 기능 단위가 아니라 제품 단위로 기록한다"처럼 정합니다. 감사인은 그 기준이 일관되게 적용됐는지, 기준이 정해진 뒤에 새로 켜진 기능이 검토됐는지를 확인합니다.

감사 기준과 법률 판단의 경계

인공지능기본법은 시행된 지 얼마 되지 않았고, 많은 세부 사항을 대통령령과 고시, 가이드라인에 맡깁니다. 그래서 "이 시스템이 고영향인가"는 사실관계와 해석에 따라 달라질 수 있습니다. 감사인이 이 질문에 대한 법적 결론을 내리면 두 가지 위험이 생깁니다. 결론이 틀릴 위험과, 경영진이 해야 할 판단을 감사인이 대신하는 위험입니다.

그래서 실무에서는 질문을 바꿉니다. "고영향인가?" 대신 "회사는 고영향 해당 여부를 사전에 검토했는가, 그 검토는 문서로 남아 있는가, 검토의 근거는 무엇이며 누가 승인했는가?"를 묻습니다. 사전 검토 자체가 법이 요구하는 절차이므로(제33조제1항), 이 질문에 대한 답은 감사인이 사실로 확인할 수 있습니다. 검토 결과가 의심스럽다면 그 의심과 근거를 보고하고, 법무 검토를 권고합니다.

자문 뒤의 보증: 같은 팀이 두 번 볼 때

AI 거버넌스는 많은 조직에서 처음 만들어지는 중이라, 경영진은 내부감사에 "설계를 같이 봐 달라"고 요청하곤 합니다. 이 요청을 거절할 필요는 없습니다. 자문 업무는 내부감사의 정당한 업무이고, 출시 전에 위험을 줄이는 데 큰 도움이 됩니다. 문제는 1년 뒤 같은 통제를 보증할 때 생깁니다.

자문을 할 때 지켜야 할 선은 "의견은 주되 결정과 운영은 경영진이 한다"입니다. 감사인이 절차서를 대신 쓰고, 승인 화면을 직접 설계하고, 운영 담당자 역할까지 맡으면 그것은 더 이상 자문이 아니라 경영진의 책임을 떠맡은 것이고, 나중의 보증은 자기 작업을 평가하는 일이 됩니다. 반대로 경영진이 결정하고 운영한 통제라면, 자문을 했던 팀이 보증을 해도 감사 책임자가 객관성을 확인하고 인력을 조정해 관리할 수 있습니다. 자문 단계에서 남긴 의견서와 경영진의 결정 기록이 나중에 객관성을 보여 주는 증거가 됩니다.

실무 장면

솔내건설: 현장마다 다른 AI 목록

종합건설사 '솔내건설'(임직원 3,400명, 공사 현장 46곳)의 내부감사팀은 연간 계획에 처음으로 "AI 사용 관리" 감사를 넣었다. IT팀이 준 목록에는 승인된 도구 다섯 개가 있었고, 모두 본사가 계약한 것이었다.

감사팀은 먼저 이 회사의 일하는 방식을 확인했다. 직원의 절반 이상이 현장 사무소에서 일했고, 현장 사무소는 통신사 회선을 따로 써서 본사 프록시를 거치지 않았다. 현장 운영비는 현장소장 전결로 법인카드를 쓸 수 있었다. 감사팀원 한 명이 본사 프록시 기록부터 뽑자고 했지만, 팀장은 그 기록이 현장 사용을 거의 보여 주지 못한다는 점을 지적했다. 본사 기록은 본사에 대해서만 쓰기로 했다.

현장에 대해서는 법인카드 결제 내역에서 AI 서비스 결제를 찾았다. 결제 대행사 이름으로 찍힌 건도 있어 가맹점명만으로는 부족했고, 금액 패턴과 영수증을 함께 봤다. 그 결과 현장 열한 곳에서 일곱 가지 유료 AI 서비스가 쓰이고 있었다. 이 가운데 두 개는 공정 사진을 올려 안전 위반을 찾아 주는 서비스였는데, 사진에는 협력업체 근로자의 얼굴이 담겨 있었다. 감사팀은 이 두 서비스를 위험 평가의 맨 위에 올렸다.

또 하나의 경로가 남아 있었다. 회사가 쓰는 공사 관리 SaaS가 지난 분기 업데이트로 "일일 작업일보 자동 요약"을 기본으로 켠 것이다. 결제도 새 접속도 없어서 카드와 프록시 어디에도 흔적이 없었다. 감사팀은 SaaS 관리자 화면과 벤더 공지를 확인해 이 기능을 찾았고, 회사 정책에 내장 기능에 관한 기준이 없다는 점을 따로 기록했다.

감사팀은 승인되지 않은 서비스의 이용자 명단을 만들지 않았다. 대신 현장소장 다섯 명을 면담해 왜 승인 절차를 거치지 않았는지 물었다. 답은 한결같았다. 승인 신청 양식이 본사 IT 기준으로 되어 있어 현장에서는 무엇을 적어야 할지 몰랐고, 처리에 두 달이 걸렸다. 발견 사항의 원인은 "현장 실정에 맞지 않는 승인 절차"로 정리됐다. 목록 보완 결과(5개에서 13개로)와 함께, 감사팀은 내장 기능에 관한 정책 기준과 현장용 간이 승인 절차를 권고했다.

해오름신협: 1,000시간을 어디에 쓸 것인가

신용협동조합 '해오름신협'의 감사실은 올해 AI 감사에 1,000시간을 쓸 수 있다. 보완을 마친 목록에는 AI 시스템 여섯 개가 있었다. 개인 신용대출 심사 보조 모델, 연체 회원 상담 우선순위 모델, 고객 문의 챗봇, 내부 규정 검색 도우미, 회의록 요약 도구, 그리고 올해 도입한 이상거래 탐지 서비스였다.

감사실은 시스템마다 영향과 가능성, 이전 확인 여부를 표로 정리했다. 대출 심사 보조 모델은 조합원의 대출 여부에 영향을 주고 지난해 정밀 감사를 받아 권고 세 건이 나왔다. 이상거래 탐지 서비스는 외부 업체가 운영하며 결제를 막을 수 있는데, 아직 감사한 적이 없었고 계약서 검토도 끝나지 않았다. 연체 상담 우선순위 모델은 상담 순서만 정하고 결정은 상담원이 했다.

감사실장은 처음에 여섯 시스템에 시간을 똑같이 나누는 안을 받았다. "공평하다"는 이유였지만, 그러면 이상거래 탐지 서비스에 겨우 170시간 남짓이 돌아가 계약, 운영, 오탐 피해까지 볼 수 없었다. 지난해 감사한 대출 모델에 다시 많은 시간을 쓰자는 의견도 있었다. 조서를 재활용할 수 있어 효율적이라는 이유였지만, 효율은 위험 기반 배분의 근거가 아니었다.

최종 계획은 이렇게 정해졌다. 이상거래 탐지 서비스에 450시간(3단계 정밀 감사: 계약과 수탁 관리, 오탐으로 결제가 막힌 회원의 구제 절차, 업체 보고서 검토), 대출 심사 모델에 250시간(2단계: 지난해 권고 세 건의 이행 테스트), 챗봇과 연체 상담 모델에 각 100시간(2단계: 핵심 통제 한 개씩), 규정 검색과 회의록 요약에 각 50시간(1단계: 관리 체계 확인)이다. 이상거래 탐지는 외부 데이터 과학 전문가를 참여시키기로 하고, 그 전문가가 업체와 이해관계가 없는지 확인한 뒤 작업 범위와 방법을 문서로 정했다. 계획서에는 버린 안(균등 배분, 익숙한 시스템 우선)과 그 이유도 남겼다.

자주 틀리는 지점

1. "승인된 도구만 감사 범위다." 승인 밖의 사용이 가장 큰 위험일 수 있습니다. 목록 밖 사용을 찾아 범위에 넣는 것이 감사의 첫 일입니다.
2. "부서장 확인서를 받았으니 목록은 완전하다." 자기 보고는 모르는 것과 숨긴 것이 빠집니다. 완전성은 사용 흔적이 남는 독립 기록으로 확인합니다.
3. "프록시 기록 하나면 다 잡힌다." 회사망을 거치지 않는 사용, 기존 서비스에 내장된 기능은 프록시에 보이지 않습니다. 출처는 사용 경로에 맞춰 고릅니다.
4. "섀도 AI를 찾았으면 이용자를 징계하도록 넘긴다." 징계와 도구 승인은 경영진의 일입니다. 감사는 규모, 위험, 원인을 밝힙니다.
5. "공평하게 모든 시스템을 같은 깊이로 본다." 위험이 다른데 깊이가 같으면 가장 위험한 시스템이 충분히 다뤄지지 않습니다.
6. "자율 프레임워크는 감사 기준이 될 수 없다." 기준에는 표준, 업계 관행, 조직 지침도 들어갑니다. 다만 왜 적합한지 밝힙니다.
7. "내부감사에서 문제가 없었으니 ISO/IEC 42001 준수라고 써도 된다." 인증은 인증기관이 합니다. 내부감사의 결론은 감사한 범위와 기준 안에서만 말합니다.
8. "도입을 추진한 교수가 최고 전문가이니 검증을 맡긴다." 전문가는 역량과 함께 객관성을 평가해야 합니다. 이해관계가 있으면 독립된 전문가를 씁니다.

한눈에 정리

공식 문서로 확인하기

• NIST AI RMF — Core: GOVERN 1.3·1.6, MAP 5.1, MEASURE 1.3의 원문.
• NIST AI 600-1 — Generative AI Profile: GV-1.6-001~003의 목록 관련 제안.
• GAO-21-519SP — AI Accountability Framework: 네 원칙과 핵심 실무, 실무별 감사 질문.
• 국가법령정보센터 — 인공지능기본법: 제2조, 제31조, 제33조~제35조.
• 국가법령정보센터 — 인공지능기본법 시행령: 제27조의 게시·보관·간주 규정.
• 국가법령정보센터 — 개인정보 보호법: 제26조 업무위탁, 제37조의2 자동화된 결정.
• ISO — ISO/IEC 42001:2023과 ISO — Certification: 표준의 범위와 인증 주체.
• The IIA — Global Internal Audit Standards: 기준 2.2, 7.1, 9.4, 13.2, 13.4.

셀프 체크

1-1. AI 목록의 항목을 정할 때 "질문에서 거꾸로 정한다"는 말의 뜻을 설명하고, 개인정보 위험을 판단하는 데 필요한 항목 두 가지를 들라.

1-2. 재택근무 비율이 70%인 회사에서 웹 프록시 기록만으로 AI 목록의 완전성을 확인하려 한다. 이 방법의 한계와 보완할 출처 두 가지를 쓰라.

1-3. 섀도 AI 사용을 찾은 뒤 감사인이 밝혀야 할 세 가지를 쓰고, 감사인이 하지 말아야 할 일 하나를 그 이유와 함께 쓰라.

1-4. 위험 기반 범위 설정에서 "두드러진 신호가 감사의 중심을 정한다"는 원칙을, 외부 개발사가 운영하는 모델을 예로 들어 설명하라.

1-5. NIST AI RMF처럼 법적 의무가 아닌 프레임워크를 감사 기준으로 쓸 수 있는지 Yellow Book과 IIA 기준에 비추어 답하고, 쓸 때 보고서에 남길 것을 쓰라.

1-6. 인공지능기본법 시행령 제27조에서 감사인이 증거 요청 목록으로 바꿀 수 있는 내용 세 가지를 쓰라.

1-7. (설계) 감사 책임자가 1년 동안 AI 정책 위원회의 간사를 맡았던 조직에서, 이사회가 그 위원회 운영에 대한 보증을 요청했다. 업무를 어떻게 구성할지 IIA 기준에 맞춰 세 줄로 설계하라.

실습 과제