2장. 통제 설계와 운영 효과성

학습 목표

• 통제의 설계 효과성과 운영 효과성을 구분해 평가 절차를 고른다.
• 발견한 문제를 설계 미비와 운영 미비 가운데 어디에 해당하는지 판정한다.
• 사람의 검토 통제가 실질적인지, 형식적인 승인에 그치는지 가리는 테스트를 고른다.
• AI 시스템에서 접근 관리와 변경 관리의 대상을 모델, 판정 기준, 지시문, 지식 문서까지 넓혀 점검한다.
• 벤더 계약과 서비스 조직 보고서를 읽고 회사가 따로 확인할 것을 찾아낸다.

들어가며

어느 보험사의 보상팀장이 감사팀에 자신 있게 말합니다. "AI가 산정한 금액은 전부 담당자가 확인하고 확정합니다. 사람이 최종 결정하니 문제없습니다." 절차서에도 그렇게 적혀 있고, 확정 버튼은 담당자만 누를 수 있습니다. 감사팀이 시스템 기록을 열어 보니 지난 분기 담당자가 AI 금액을 고친 건은 1,000건 중 3건이었고, 건당 처리 시간은 평균 20초였습니다.

이 통제는 효과적일까요? 답은 "아직 모른다"입니다. 절차서와 확정 버튼은 통제가 그렇게 설계되어 있다는 증거일 뿐, 기간 동안 실제로 작동했다는 증거가 아닙니다. 그리고 낮은 수정 비율도 그 자체로는 아무것도 증명하지 못합니다. AI가 거의 틀리지 않았다면 수정할 일이 없었을 테고, AI가 자주 틀렸다면 담당자가 오류를 흘려보낸 것입니다. 둘을 가르려면 증거가 더 필요합니다. 통제를 평가하는 일은 이처럼 "통제가 있다"와 "통제가 작동한다"를 나눠 묻는 데서 시작합니다.

이 장은 통제 평가의 두 축인 설계와 운영을 먼저 구분하고, 문제가 어디에서 생겼는지 판정하는 방법을 익힙니다. 이어서 AI 감사에서 가장 자주 쟁점이 되는 사람의 검토 통제와 형식적 승인을 깊이 다루고, 접근 관리와 변경 관리, 벤더 관리 통제를 AI 시스템의 특성에 맞게 점검하는 방법을 정리합니다.

핵심 개념

통제의 종류

통제는 위험이 결과로 이어지지 않게 하는 장치입니다. PCAOB AS 2201은 통제를 오류나 부정이 생기지 않게 막는 예방 통제와, 생긴 오류를 제때 찾아내는 적발 통제로 나누고, 효과적인 내부통제는 흔히 두 가지를 함께 쓴다고 설명합니다(AS 2201 .A8). 수행 주체로는 사람이 하는 수작업 통제와 시스템이 하는 자동 통제가 있습니다.

이 구분은 테스트 방법을 정합니다. 사람이 반복 수행하는 통제는 기간 전체에서 표본을 뽑아 봐야 하고, 완전히 자동화된 통제는 설정과 그 변경 관리를 보는 방식으로 효율적으로 확인할 수 있습니다.

설계 효과성과 운영 효과성

설계 효과성은 통제가 권한과 역량을 갖춘 사람에 의해 정해진 대로 수행된다면 통제 목적을 이루고 오류나 부정을 막거나 찾아낼 수 있는지를 봅니다(AS 2201 .42). 운영 효과성은 그 통제가 실제로 설계대로 운영되는지, 그리고 수행하는 사람이 필요한 권한과 역량을 갖췄는지를 봅니다(AS 2201 .44).

비유하자면 설계 평가는 소화기가 올바른 자리에 올바른 종류로 놓여 있는지 보는 일이고, 운영 평가는 지난 1년 동안 점검표대로 압력을 확인하고 교체했는지 보는 일입니다. 소화기가 엉뚱한 곳에 있다면 점검 기록이 아무리 성실해도 화재를 막지 못합니다. 그래서 설계 평가가 먼저입니다. IIA 기준도 통제가 적절히 설계되지 않았다면 그 효과성을 전부 평가하는 데 드는 비용만큼의 효익을 얻기 어렵다고 설명합니다(IIA 4.2).

설계 미비와 운영 미비

AS 2201은 두 가지 미비를 이렇게 정의합니다(AS 2201 .A3).

• 설계 미비: 통제 목적을 이루는 데 필요한 통제가 없거나, 있는 통제가 설계대로 운영돼도 목적을 이루지 못하게 설계된 경우.
• 운영 미비: 적절히 설계된 통제가 설계대로 운영되지 않거나, 통제를 수행하는 사람이 효과적으로 수행하는 데 필요한 권한이나 역량을 갖추지 못한 경우.

AI 시스템에서 이 구분은 생각보다 자주 헷갈립니다. 다음 예를 보세요.

판정이 중요한 이유는 권고가 달라지기 때문입니다. 설계 미비는 정책이나 시스템을 고쳐야 하고, 운영 미비는 수행을 바로잡거나 수행자를 바꿔야 합니다.

테스트 기법과 증거의 강도

통제를 테스트하는 기법은 네 가지입니다. 담당자에게 묻는 질문, 수행 과정을 지켜보는 관찰, 수행 기록을 살피는 문서 검사, 감사인이 통제를 독립적으로 다시 해 보는 재수행입니다. AS 2201은 이 네 가지를 통상 얻는 증거가 약한 것부터 강한 순서로 들고, 질문만으로는 통제가 효과적이라는 결론을 뒷받침할 수 없다고 못 박습니다(AS 2201 .50). 실제 증거의 강도는 통제의 성격과 수행한 절차의 조합에 따라 달라집니다(.49, .51).

설계 평가에는 질문, 관찰, 문서 검사를 묶은 워크스루가 대개 충분합니다(AS 2201 .43). 워크스루는 위험과 수행한 절차에 따라 운영 효과성의 충분한 증거가 될 수도 있지만(.49), 위험이 크거나 기간 중 수행을 넓게 봐야 하면 표본 테스트가 필요합니다. 워크스루는 거래 하나를 시작부터 끝까지 따라가며 담당자에게 묻고, 실제 화면과 기록을 함께 보는 방법입니다. 운영 평가에는 기간 전체에서 표본을 뽑아 문서 검사나 재수행을 합니다. 더 긴 기간을 테스트할수록 통제 효과에 대한 증거도 강해집니다(AS 2201 .52).

이탈을 만났을 때

표본에서 통제가 수행되지 않은 건, 즉 이탈이 나왔다고 해서 곧바로 통제가 효과적이지 않다고 결론 내리지는 않습니다. AS 2201은 효과적인 통제도 절대적 확신을 주지는 못하므로 개별 통제가 이탈 없이 운영돼야만 효과적인 것은 아니라고 설명합니다(AS 2201 .48). 감사인은 이탈의 빈도를 허용 이탈률과 견주고(3장), 이탈의 원인과 성격도 평가합니다. 실수에서 생긴 이탈과 의도적인 우회는 무게가 다릅니다.

반대로 실제 피해가 없었다고 미비를 가볍게 봐서도 안 됩니다. AS 2201은 미비의 심각성이 오류가 실제로 생겼는지가 아니라 통제가 오류를 막거나 찾아내지 못할 합리적 가능성과 그 크기에 달려 있다고 설명합니다(AS 2201 .63–.64). 퇴사자 계정이 2주 동안 비활성화되지 않았지만 로그인 기록이 없었다는 사실은 영향 평가에는 쓰이지만, 이탈 자체를 지우지는 못합니다.

사람의 검토 통제가 갖춰야 할 것

AI 시스템에서 가장 흔한 통제는 "사람이 확인한 뒤 확정한다"입니다. 인공지능기본법은 고영향 인공지능을 제공하는 사업자의 책무로 사람의 관리·감독을 들고(제34조제1항제4호), NIST AI RMF는 사람의 감독 절차를 정의하고 평가해 문서화하며(MAP 3.5), 의도와 다른 결과를 내는 AI 시스템을 대체하거나 멈추게 할 장치와 책임을 두라고 합니다(MANAGE 2.4). GAO 프레임워크도 책임성을 위해 사람의 감독 절차를 정하라고 합니다(실무 3.9).

사람의 검토가 실질적이려면 네 가지가 갖춰져야 합니다.

1. 권한: 검토자가 AI 결과를 뒤집을 수 있어야 합니다. 의견만 남기고 AI 결과가 자동으로 우선 적용된다면 감독은 형식입니다.
2. 정보: 판단에 필요한 원자료와 AI가 그렇게 판단한 근거를 볼 수 있어야 합니다.
3. 시간: 건당 처리 목표나 대기열 압박이 실제 판단을 불가능하게 하지 않아야 합니다.
4. 역량: 검토자가 그 판단을 할 지식과 교육을 갖춰야 합니다.

검토 절차가 애초에 뒤집을 권한, 원자료, 시간을 주지 않게 만들어졌다면 설계 미비입니다. 절차는 제대로 만들어졌는데 실제로 검토를 맡은 사람에게 필요한 권한이나 역량이 없었다면 AS 2201의 정의대로 운영 미비입니다.

형식적 승인과 자동화 편향

형식적 승인(흔히 "고무도장")은 검토가 절차상으로는 있지만 실제로는 AI 결과를 그대로 통과시키는 상태를 말합니다. 그 바탕에는 자동화 편향이 있습니다. NIST AI 600-1은 생성형 AI의 신뢰성이 높아질수록 사람이 시스템에 지나치게 기대거나 그 결과를 다른 출처보다 높게 평가할 수 있으며, 이런 자동화된 시스템에 대한 과도한 의존이 그럴듯한 오답(confabulation)이나 편향 같은 다른 위험을 키울 수 있다고 설명합니다.

형식적 승인의 신호는 대개 다음과 같습니다.

• 수정·번복 비율이 AI의 알려진 오류율보다 훨씬 낮다.
• 건당 처리 시간이 원자료를 읽기에는 너무 짧다.
• 일괄 승인 기능이 있고 실제로 쓰인다.
• 번복할 때 사유를 남기라는 요구는 있지만 그대로 따를 때는 아무 기록도 남지 않는다.

이 신호들은 "의심"이지 "결론"이 아닙니다. 경력이 긴 검토자도 예외가 아니므로, 숙련도를 이유로 테스트에서 빼서는 안 됩니다.

형식적 검토를 찾는 테스트 고르기

어떤 테스트가 알맞은지는 어떤 증거가 남아 있고, 무엇이 허용되며, 감사팀이 무엇을 판단할 수 있는가에 따라 정해집니다.

시험 건 투입은 강력하지만 운영 시스템에 영향을 줄 수 있어 사내 규정과 경영진 합의가 먼저입니다. 재수행은 감사팀이 같은 판단을 할 수 있을 때만 의미가 있으며, 그렇지 않다면 자격 있는 전문가를 참여시킵니다. 면담만으로 끝내는 테스트는 어느 상황에서도 충분하지 않습니다.

접근 통제

AI 시스템의 접근 통제는 "누가 결과를 바꿀 수 있는가"를 다룹니다. 모델 파일과 배포 설정만이 아니라, 생성형 AI의 지시문(프롬프트), 판정 기준 점수, 검색에 쓰이는 지식 문서, 외부 도구 연결 설정이 모두 결과를 바꿉니다. 감사인은 다음을 확인합니다.

1. 수정 권한이 꼭 필요한 사람에게만 주어졌는가(최소 권한).
2. 권한 목록을 정기적으로 검토하는가. 검토는 권한 목록을 인사 기록의 재직자 명단과 대조하는 식으로 독립된 자료와 맞춰 봅니다.
3. 퇴사·전보 때 정책이 정한 기한 안에 권한을 회수하는가.
4. 수정 이력이 남고, 누군가 그 이력을 검토하는가.

수정 이력은 사후에 찾아내는 적발 통제입니다. 이력이 남는다는 사실이 최소 권한 같은 예방 통제를 대신하지는 못합니다.

변경 관리 통제

전통적인 IT 감사의 변경 관리는 프로그램 코드 변경을 봅니다. AI 시스템에서는 변경의 단위가 넓습니다. 모델 재학습이나 교체, 판정 기준 점수 조정, 지시문 수정, 지식 문서 갱신, 외부 벤더의 기반 모델 교체가 모두 결과를 바꿉니다. 변경 관리 정책이 이 가운데 일부만 승인 대상으로 정했다면, 나머지는 통제 밖에 남는 설계 미비입니다.

변경 관리 통제를 테스트하는 순서는 대개 이렇습니다. 정책에서 승인 대상 변경과 승인권자를 확인하고, 운영 시스템에서 실제 배포 이력을 감사인이 직접 뽑아 승인 기록과 하나씩 대조하고, 맞지 않는 건의 원인을 조사합니다. 요청자와 승인자가 같은 사람인지, 승인된 내용과 배포된 내용이 같은지도 함께 봅니다.

자동 통제와 기준선 전략

"근거를 입력해야 확정 버튼이 켜진다" 같은 완전 자동 통제는 일반적으로 사람의 실수로 무너질 위험에 노출되지 않습니다(AS 2201 .B28). AS 2201은 프로그램 변경, 접근, 운영에 대한 일반 통제가 효과적이고 계속 테스트되며, 자동 통제가 기준선을 세운(지난번 테스트한) 이후 바뀌지 않았음을 확인하면, 자동 통제가 계속 효과적이라고 결론 낼 수 있다고 설명합니다(.B29). 이를 기준선(벤치마킹) 전략이라 합니다.

다만 자동 통제의 작동은 관련 파일, 표, 데이터, 매개변수에 기댈 수 있고(AS 2201 .B30), 시간이 지나면 기준선을 다시 세워야 합니다(.B33). AI 시스템이라면 판정 기준 점수나 참조 단가표가 그런 매개변수입니다. "버튼 설정은 그대로인데 참조 표가 바뀌었다"면 통제는 바뀐 것입니다.

벤더 관리 통제

많은 AI 시스템은 외부 벤더의 모델이나 서비스 위에서 돌아갑니다. 맡겨도 위험은 회사에 남습니다. NIST AI RMF는 제3자와 관련된 AI 위험을 다루는 정책과 절차를 두고(GOVERN 6.1), 고위험으로 본 제3자 데이터나 AI 시스템의 실패에 대비한 비상 절차를 마련하며(GOVERN 6.2), 제3자 자원의 위험을 정기적으로 모니터링하고(MANAGE 3.1), 개발에 쓰인 사전학습 모델을 정기 모니터링에 포함하라고 합니다(MANAGE 3.2). 개인정보 처리를 맡겼다면 개인정보 보호법 제26조의 위탁 문서와 수탁자 감독도 함께 봅니다.

AI 벤더 계약에서 감사인이 특히 찾는 조항은 다음과 같습니다.

보안 인증, 장애 보상, 비밀유지 조항도 중요하지만, 예고 없는 모델 교체와 성능 저하 같은 AI 고유의 위험은 직접 다루지 못한다는 점을 구분해야 합니다.

서비스 조직 보고서 읽기

벤더는 흔히 독립 감사인이 작성한 서비스 조직 보고서를 줍니다. PCAOB AS 2601은 재무제표 감사에서 이런 보고서를 다루는 기준이지만, 보고서를 읽는 원리는 AI 업체가 주는 다른 보증 보고서에도 그대로 빌려 쓸 수 있습니다. AS 2601이 정리한 기억할 점은 다음과 같습니다.

1. 보고서의 종류. 특정 기준일 현재 통제가 설계돼 적용되고 있는지만 다룬 보고서는 감사 계획에는 도움이 되지만 운영 효과성의 증거가 되지 못합니다(AS 2601 .12, .37). 기간 중 운영 효과성을 테스트한 보고서여야 그 증거가 됩니다.
2. 범위. 보고서는 적힌 통제 목적에 대해서만 의견을 내며, 테스트하지 않은 통제 목적에는 의견이 없습니다(.44). 접근 관리와 가용성만 다룬 보고서는 모델 학습 이용 여부에 대해 아무것도 말하지 않습니다.
3. 기간. 테스트 기간이 짧거나 테스트 뒤 시간이 오래 지났을수록 보고서가 주는 확신은 줄어듭니다(.16).
4. 이용자 측 보완 통제(complementary user organization controls). 서비스 조직의 통제가 이용자 쪽 통제를 전제로 설계됐다면 보고서는 그 통제를 밝힙니다(.31, .46). 회사가 그 통제를 운영하지 않으면 보고서의 결론은 전제를 잃습니다.

깊이 읽기

의미 있는 사람 검토의 비용

"모든 건을 사람이 꼼꼼히 본다"는 설계는 듣기에는 안전하지만, 실제로는 형식적 승인을 낳기 쉽습니다. 하루 수백 건을 처리해야 하는 검토자에게 건당 몇 초만 허용된다면, 절차서가 무엇을 요구하든 검토는 AI 결과를 따르는 쪽으로 흐릅니다. 감사인이 이런 상황에서 "검토를 강화하라"고만 권고하면 같은 문제가 반복됩니다.

더 나은 설계는 검토를 위험에 따라 나누는 것입니다. 금액이 크거나 고객에게 불리한 결정, AI의 확신도가 낮은 건은 사람이 깊이 보고, 그 밖의 건은 표본 재검토 같은 적발 통제로 대신하는 식입니다. 이때 감사인이 확인할 것은 세 가지입니다. 나누는 기준이 위험과 맞닿아 있는가, 깊이 보는 건에 충분한 시간과 정보가 주어지는가, 표본 재검토의 결과가 실제로 기준이나 모델 개선으로 이어지는가. 사람 검토를 줄이는 결정 자체는 경영진의 위험 판단이며, 감사인은 그 결정이 위험 허용 수준 안에 있는지와 그 결정을 누가 승인했는지를 봅니다.

에이전트의 도구 권한과 사람 승인

AI 에이전트는 메일을 보내고, 주문을 넣고, 기록을 고치는 도구를 직접 호출합니다. 접근 통제의 대상이 사람의 계정에서 에이전트의 권한으로 넓어지는 셈입니다. OWASP는 프롬프트 인젝션(사용자 입력이나 외부 문서에 숨은 지시가 모델의 행동을 의도와 다르게 바꾸는 공격) 대응책으로 모델의 접근 권한을 의도된 작업에 필요한 최소한으로 제한하고, 권한이 큰 작업에는 사람의 승인을 두며, 모델을 신뢰할 수 없는 사용자처럼 취급하는 침투 테스트를 정기적으로 하라고 권합니다. 지시문에 "개인정보를 노출하지 말 것"이라고 적는 것은 그 대책 가운데 하나일 뿐, 그것만으로 안전하다고 볼 수는 없습니다.

감사인의 질문은 사람 계정과 같은 틀로 바뀝니다. 에이전트가 가진 도구 권한 목록이 있는가, 그 권한은 업무에 필요한 최소한인가, 되돌리기 어려운 작업(송금, 삭제, 외부 발송)에 사람 승인이 걸려 있는가, 에이전트의 행동 기록은 에이전트 스스로 고칠 수 없는 곳에 남는가. 마지막 질문은 3장의 로그 무결성으로 이어집니다.

실무 장면

한올보험: 수정 비율 0.6%의 의미

손해보험사 '한올보험'은 AI가 여행자보험 청구를 '지급'과 '심사'로 나누면 담당자 9명이 '지급' 건을 확인해 확정한다. 감사팀이 받은 운영 자료에서 담당자가 AI 판단을 '심사'로 돌린 비율은 0.6%, 건당 확인 시간 중앙값은 11초였다. 보상부서장은 "AI가 정확하니 고칠 일이 적은 것"이라고 설명했다.

감사팀은 먼저 이 설명이 맞는지 확인할 기준을 찾았다. 출시 전 검증 보고서에는 '지급' 판단의 약 4%가 약관상 지급 대상이 아니었다는 결과가 있었다. AI가 4% 틀리는데 사람이 0.6%만 바로잡았다면 차이가 크다. 다만 출시 뒤 모델이 개선됐을 수도 있었으므로, 이 차이를 결론이 아니라 테스트의 출발점으로 삼았다.

테스트 방법을 두고 세 가지 안이 나왔다. 담당자 면담은 질문만으로는 결론을 낼 수 없어 보조 절차로 돌렸다. 시험용 오류 건을 대기열에 섞는 안은 운영 시스템에 처리되지 않을 청구를 넣는 일이라 사내 규정상 정보보호위원회 승인이 필요했고, 감사 기간 안에 승인을 받기 어려웠다. 남은 것은 재수행이었다. 청구 서류 원본이 모두 보관돼 있었고, 여행자보험 약관 판단은 그 상품의 심사에 관여한 적이 없는 감사팀의 보험 경력자가 할 수 있었다.

감사팀은 지난 분기 확정된 '지급' 건 2만 1천 건에서 무작위로 60건을 뽑아 약관에 따라 다시 판단했다. 그중 2건이 지급 대상이 아니었는데 담당자 확인을 통과했다. 감사팀은 확인 화면도 함께 봤다. 화면에는 AI 판단과 금액만 크게 보였고, 첨부 서류는 별도 탭을 눌러야 열렸으며, 화면에 '전체 확인' 버튼이 있었다. 감사팀은 결과를 두 갈래로 정리했다. 2건은 운영상 이탈로 평가했고(허용 이탈률과 견준 평가는 3장의 방식대로 했다), 서류를 열지 않아도 확정할 수 있는 화면 구성과 일괄 확인 버튼은 검토자에게 필요한 정보를 주지 못하는 설계상의 원인으로 기록했다. 보고서에는 이 설계 문제를 발견 사항의 원인으로, 놓친 2건을 그 영향을 보여 주는 증거로 적었다.

버들식품: 업체 보고서 한 권으로 충분한가

식품 제조사 '버들식품'은 외부 업체의 생성형 AI 서비스로 협력업체 계약서를 요약하고 위험 조항을 표시한다. 감사팀이 업체 통제에 대한 증거를 요청하자, 구매팀은 업체가 보내 준 서비스 조직 보고서를 내밀며 "적정 의견이니 따로 볼 것이 없다"고 했다.

감사팀은 보고서를 세 가지로 나눠 읽었다. 첫째, 종류. 보고서는 12개월 동안 통제의 운영 효과성을 테스트한 보고서였다. 둘째, 범위. 통제 목적은 접근 관리, 변경 관리, 백업과 복구였다. 감사팀의 관심 가운데 하나인 "계약서 원문이 업체의 모델 학습에 쓰이는가"는 어떤 통제 목적에도 들어 있지 않았다. 셋째, 이용자 측 보완 통제. 보고서는 "고객사는 퇴사자 계정을 관리 콘솔에서 즉시 비활성화한다"를 전제로 했다.

감사팀은 보고서로 확인된 것과 확인되지 않은 것을 표로 나눴다. 변경 관리와 접근 관리는 보고서를 증거로 쓰되, 보완 통제를 확인하려고 버들식품의 콘솔 사용자 목록 34명을 인사 기록과 대조했다. 퇴사자 2명의 계정이 살아 있었고, 한 명은 퇴사 6주가 지난 상태였다. 학습 이용 여부는 보고서 밖이었으므로 계약서와 데이터 처리 조건, 관리자 설정 화면을 따로 확인했다. 계약서에는 학습 이용 금지 조항이 있었지만, 관리자 설정의 '서비스 개선을 위한 데이터 공유'가 켜져 있었다.

구매팀은 "적정 의견"이라는 말에 기댔지만, 그 의견이 무엇에 대한 것인지를 읽자 회사가 직접 해야 할 일 두 가지가 드러났다. 감사팀은 퇴사자 계정 회수를 운영 미비로, 데이터 공유 설정을 계약 조건과 맞지 않는 설정으로 각각 발견 사항에 올렸다. 두 번째 건의 원인으로는 계약에서 정한 데이터 조건을 관리자 설정에 반영하고 확인하는 절차가 없었다는 점을 적었다.

자주 틀리는 지점

1. "절차서가 있으니 통제는 효과적이다." 절차서는 설계의 증거일 뿐입니다. 기간 중 작동은 운영 테스트로 확인합니다.
2. "사람이 최종 결정하니 감독은 충분하다." 사람이 결과를 뒤집을 권한, 정보, 시간, 역량이 있어야 감독이 실질적입니다.
3. "수정 비율이 낮으니 AI가 정확하다." 수정 비율은 사람이 AI를 따른 정도일 뿐입니다. AI의 실제 오류율과 견줘야 의미가 생깁니다.
4. "검토 시간이 길면 실질적인 검토다." 화면을 열어 둔 시간은 판단의 질을 보여 주지 않습니다. 재수행 같은 직접 증거가 필요합니다.
5. "면담을 여러 명에게 하면 운영 효과성을 확인할 수 있다." 질문만으로는 결론을 낼 수 없고, 같은 종류의 증거를 늘려도 질은 보완되지 않습니다.
6. "이탈이 한 건이라도 나오면 통제는 실패다." 이탈의 빈도와 원인을 허용 기준과 함께 평가해 판단합니다.
7. "수정 이력이 남으니 권한이 넓어도 괜찮다." 이력은 적발 통제입니다. 최소 권한 같은 예방 통제를 대신하지 못합니다.
8. "업체 보고서가 적정이면 업체 관련 위험은 끝이다." 보고서의 종류, 범위, 기간, 이용자 측 보완 통제를 읽어야 무엇이 확인됐는지 압니다.

한눈에 정리

공식 문서로 확인하기

• PCAOB — AS 2201: 설계·운영 효과성(.42–.52), 미비의 정의(.A3), 심각성(.62–.64), 자동 통제의 기준선(.B28–.B33).
• PCAOB — AS 2601: 서비스 조직 보고서의 종류, 범위, 기간, 이용자 측 보완 통제.
• NIST AI RMF — Core: MAP 3.5(사람의 감독), MANAGE 2.4(대체·중지 장치), GOVERN 6.1·6.2, MANAGE 3.1·3.2(제3자).
• NIST AI 600-1: Human-AI Configuration과 자동화 편향 설명.
• GAO-21-519SP: 실무 3.9(사람의 감독)와 감사 절차 예시.
• OWASP GenAI — LLM01 Prompt Injection: 최소 권한, 사람 승인, 침투 테스트 같은 대응책.
• The IIA — Global Internal Audit Standards: 기준 4.2의 비용·효익 고려.

셀프 체크

2-1. 소화기 비유를 쓰지 않고, 설계 효과성과 운영 효과성의 차이를 AI 판정 기준 변경 승인을 예로 들어 두 문장으로 설명하라.

2-2. 검토 담당자가 교육을 받지 않은 신규 직원으로 바뀐 상황은 설계 미비와 운영 미비 가운데 어디에 해당하는가? AS 2201의 정의를 근거로 답하라.

2-3. 통제 테스트 기법 네 가지를 증거가 약한 것부터 나열하고, 질문만으로 끝낸 테스트가 왜 결론의 근거가 되지 못하는지 쓰라.

2-4. 사람 검토가 실질적이려면 갖춰야 할 네 가지를 쓰고, 그중 하나가 빠졌을 때 나타나는 형식적 승인의 신호를 하나씩 연결하라.

2-5. AI 시스템에서 변경 관리의 대상이 되어야 하는 변경 다섯 가지를 들고, 그중 전통적인 IT 변경 관리에서 놓치기 쉬운 두 가지를 고르라.

2-6. 서비스 조직 보고서를 받았을 때 확인할 네 가지를 쓰고, 그중 AI 고유의 위험과 가장 자주 부딪치는 항목을 이유와 함께 고르라.

2-7. (설계) 고객에게 메일을 보내고 환불을 실행할 수 있는 AI 에이전트에 대해, 감사인이 점검할 접근 통제 질문 네 개를 만들라.

실습 과제