AI 거버넌스는 사용 금지 목록만 만드는 일이 아닙니다. 업무에 AI를 쓸 때 어떤 정보에 접근하게 할지, 결과를 어디까지 보조로 쓸지, 누가 확인하고 어떤 기록을 남길지 정하는 운영 기준입니다. 기준이 업무 흐름에 붙어 있지 않으면 규정은 있어도 현장의 판단은 제각각이 됩니다.
AI 업무를 열기 전에 무엇을 정해야 할까요?
- 업무 범위: 조회·요약·초안·등록 보조 중 어디까지 허용할지 정합니다.
- 데이터 접근: 역할별로 볼 수 있는 문서와 데이터, 제외할 정보를 구분합니다.
- 검토 책임: 결과를 수정·승인·반려할 사람과 기한을 지정합니다.
- 실행 통제: 외부 발송이나 시스템 변경처럼 영향이 큰 행위는 별도 승인 조건을 둡니다.
- 이력: 요청, 참조 범위, 결과, 검토 의견, 후속 조치를 업무 항목에 연결합니다.
이 다섯 요소는 정책 문서에만 머물지 않아야 합니다. 예컨대 AI가 보완 요청 초안을 만들면, 시스템은 참조한 자료와 담당 검토자를 함께 보여주고 승인 전 발송을 막아야 합니다. 담당자는 원문 대조 뒤 수정하거나 반려하고, 결정 이유는 후속 검토에 남깁니다.
자료가 부족할 때 승인 흐름은 어디로 가야 할까요?
일반적인 요청은 정해진 기준으로 처리할 수 있지만, 자료가 부족하거나 접근 권한이 없는 경우에는 AI의 처리를 멈추고 책임자에게 넘겨야 합니다. 이때 ‘예외’ 상태와 추가 자료 요청, 재검토 경로가 없다면 담당자는 메일과 메신저로 돌아가게 됩니다. 예외를 흐름에 포함하는 것이 통제의 핵심입니다.
| 단계 | AI의 역할 | 사람의 결정 |
|---|---|---|
| 접수 | 승인된 정보 정리 | 처리 가능 여부 |
| 검토 | 초안·누락 후보 제시 | 기준 대조, 수정·반려 |
| 승인 | 결정용 요약 준비 | 최종 실행 판단 |
| 예외 | 추가 정보 요청 초안 | 책임자 지정과 조치 |
거버넌스는 한 번 정하고 끝나는 규칙이 아닙니다. 실제 사용에서 반복되는 오류, 반려 사유, 권한 요청을 살펴보고 보조 범위와 기준 자료를 조정해야 합니다. 그렇게 쌓인 결정 기록이 다음 AI 적용의 가장 실용적인 안전장치가 됩니다.
어떤 결과에 더 강한 승인이 필요할까요?
AI가 회의록을 요약하는 일과 협력사에 보완 요청을 발송하는 일은 통제 수준이 다릅니다. 전자는 승인된 회의 자료 안에서 결과를 만들고 담당자가 수정하는 방식으로 시작할 수 있습니다. 반면 외부 발송은 잘못된 수신자, 불완전한 근거, 의도하지 않은 약속으로 이어질 수 있으므로 초안을 넘어 자동 실행으로 연결하지 않는 편이 안전합니다.
이 차이를 역할별 권한으로 구현해야 합니다. 예를 들어 실무자는 자신의 업무 자료에서 요약을 요청할 수 있고, 검토자는 결과와 근거를 수정·반려할 수 있으며, 승인자만 확정된 내용을 발송 단계로 넘길 수 있게 둡니다. 권한이 없는 자료를 참조하려 할 때는 AI가 추측으로 답하지 않고 처리 불가 사유와 요청 경로를 보여줘야 합니다.
거버넌스가 실패하는 대표적인 경우는 예외를 ‘나중에 처리할 일’로 남기는 것입니다. 자료 누락이나 기준 충돌이 생긴 요청을 일반 승인 흐름에 태우면 승인 기록은 남아도 판단의 질을 설명할 수 없습니다. 예외 상태, 책임자, 보완 기한을 별도로 두면 통제는 사용을 막는 규칙이 아니라 업무를 안전하게 계속하게 하는 장치가 됩니다.
정책 변경도 이력으로 다뤄야 합니다. 예를 들어 참조 가능한 문서 범위가 바뀌거나 특정 유형의 자동 제안이 제한되면, 언제부터 어떤 요청에 새 기준을 적용하는지 남겨야 과거 결과와 혼동하지 않습니다. 운영 담당자는 정기적으로 반려·예외·권한 요청을 검토해 규칙을 조정하고, 사용자는 바뀐 경계를 업무 화면에서 확인할 수 있어야 합니다.
금지 목록을 실제 결정 흐름으로 바꾸는 법
AI 거버넌스를 정책 문서나 승인 체크박스로만 만들면 급한 업무는 시스템 밖에서 처리되고 정식 절차는 형식만 남습니다. 실무에서 필요한 거버넌스는 어떤 결과를 누구에게 보여줄지, 어느 조건에서 사람이 다시 확인할지, 문제가 생기면 어떻게 되돌릴지를 업무 흐름 안에 넣는 일입니다. 따라서 먼저 모델이 아니라 결과가 영향을 미칠 결정을 분류해야 합니다. 참고용 요약과 외부 요청·승인으로 이어지는 결과는 같은 승인 수준으로 다룰 수 없습니다.
가상의 변경 검토 업무를 보겠습니다. 요청자는 변경 사유와 대상을 등록하고, AI는 과거 기록에서 영향 가능성이 있는 문서와 시험 항목을 제안합니다. 검토자는 제안된 근거를 열어 보고 재시험 필요 여부를 판단합니다. 승인자는 AI 요약이 아니라 검토자의 판단과 연결된 증적을 보고 완료를 결정합니다. 이렇게 설계하면 AI는 판단 준비를 돕지만 책임 있는 상태 전환은 권한을 가진 사람이 수행합니다.
업무 담당자는 마감을 위해 불확실한 제안을 먼저 쓰고 싶어 할 수 있고, 보안 담당자는 자료 범위를 좁혀야 한다고 볼 수 있습니다. 해법은 한쪽의 요구를 일반 원칙으로 이기는 것이 아니라 업무 유형별 사용 경계를 정하는 것입니다. 승인된 내부 문서 요약은 제한적으로 허용하되 외부 발송 문구나 완료 판단은 원문 확인 전에는 실행할 수 없게 둘 수 있습니다. 대리 검토가 필요할 때도 계정을 공유하는 대신 역할·기간·대상 업무를 남겨야 이력이 끊기지 않습니다.
기준 문서가 대규모로 개정되거나 권한 오류가 발견되면, 먼저 해당 기간에 생성된 결과와 후속 상태 전환을 식별해 업무 책임자가 영향 여부를 확인합니다. 그다음 생성 범위를 제한하고 원문과 현재 기준을 대조해 재검토가 필요한 항목을 다시 엽니다. 원인을 자료 최신성, 접근 권한, 업무 규칙, 검토 화면으로 나눠 수정한 뒤 제한된 사례로 재개합니다. 월간 점검에서는 성능 수치뿐 아니라 수정 유형, 시스템 밖 예외, 권한 회수 지연을 함께 봐야 실제 위험이 큰 구간을 찾을 수 있습니다.
승인 단계를 늘리는 것만으로는 통제가 강해지지 않습니다
AI 결과가 불안하다는 이유로 모든 요청에 여러 승인자를 붙이면 책임이 선명해지기보다 검토가 형식화될 수 있습니다. 앞 단계에서 이미 본 내용을 다음 승인자도 반복해서 확인하고, 누구도 최종 판단의 근거를 소유하지 않는 상황이 생깁니다. 승인 설계는 사람 수가 아니라 결정의 성격을 나누는 일입니다. 내용의 정확성을 확인할 사람, 업무 영향과 예외를 판단할 사람, 외부 실행이나 상태 전환을 허용할 사람이 같은지 다른지부터 봐야 합니다.
예를 들어 내부 회의 요약은 참석자가 사실관계를 고치고 업무 책임자가 공유 범위를 결정하면 될 수 있습니다. 반면 계약 조건의 비교 결과는 원문 해석과 권한 있는 의사결정이 필요하므로 같은 흐름을 재사용하기 어렵습니다. 위험도가 낮은 결과는 표본 검토로 운영하더라도, 권리·의무나 외부 약속에 영향을 줄 수 있는 결과는 건별 원문 확인을 유지할 수 있습니다. 업무 영향에 따라 승인 강도를 다르게 두는 것이 일률적인 다단계 승인보다 현실적입니다.
검토 화면도 통제의 일부입니다. 결과만 크게 보이고 참조한 문서의 버전, 생성 시점, 제외된 자료가 숨겨져 있다면 담당자는 빠르게 승인할 수는 있어도 책임 있게 판단하기 어렵습니다. 근거를 같은 맥락에서 열어 보고, 불확실한 부분을 구분하며, 수정·반려 사유를 남길 수 있어야 합니다. 승인 버튼을 누르기 전에 어떤 항목이 사람의 확인을 거쳤는지 드러나는 구조가 필요합니다.
정책 위반이 적어도 우회 행동을 확인해야 합니다
정식 흐름이 너무 느리거나 예외 처리 방법이 없으면 사용자는 AI 결과를 개인 문서에 복사하거나 메신저로 승인받게 됩니다. 기록상 정책 위반이 적어 보여도 실제 통제는 약해질 수 있습니다. 운영 점검에서는 반려율만 보지 말고, 결과가 생성된 뒤 오랫동안 처리되지 않은 건, 시스템 밖에서 다시 작성된 흔적, 권한 요청이 반복되는 자료, 대리 승인 뒤 회수되지 않은 접근을 함께 살펴야 합니다.
고객 답변 초안에서 검토자가 근거 링크를 열 수 없는 상황도 가정해 봅시다. 담당자는 매번 원본 폴더를 따로 찾아야 합니다. 최종 문구를 잘 고쳤더라도 이 흐름은 안정적이지 않습니다. 먼저 외부 발송 연결을 제한하고, 참조 자료와 권한의 문제를 해결한 뒤, 이미 발송된 답변 중 영향을 받을 수 있는 범위를 업무 책임자가 확인합니다. 수정 후에는 같은 유형의 요청에서 근거 확인, 반려, 재검토가 실제로 이어지는지 점검합니다.
거버넌스 책임자는 이 결과를 금지 항목 추가로만 처리하지 않습니다. 왜 사용자가 우회했는지, 업무 화면과 승인 기한이 현실적인지, 기준 자료의 소유자가 응답할 수 있는지를 함께 고칩니다. 반복 오류가 특정 자료나 업무 유형에 모이면 해당 범위만 좁혀 운영하고 다른 저위험 업무는 유지할 수 있습니다. 전체 사용을 멈출지 일부만 제한할지 판단할 수 있어야 통제와 업무 연속성 사이의 균형을 잡을 수 있습니다.
다음 적용으로 넘어갈 기준은 승인 건수의 증가가 아닙니다. 요청자가 허용 범위를 이해하고, 검토자가 근거를 확인하며, 승인자가 남은 위험을 설명하고, 운영자가 문제가 생긴 결과를 찾아 되돌릴 수 있어야 합니다. 이 네 역할의 연결이 검증되면 거버넌스는 AI 사용을 막는 별도 절차가 아니라 조직의 결정 품질을 유지하는 일상 운영이 됩니다.
새 업무를 추가할 때는 기존 정책에 이름만 등록하지 말고 결과가 영향을 미칠 대상과 되돌림 가능성을 다시 분류합니다. 동일한 자료 요약이라도 내부 참고와 외부 제공은 다른 승인과 기록 기준이 필요할 수 있습니다. 운영 책임자는 예외가 실제 흐름에서 종료되는지 표본으로 확인한 뒤 범위를 승인해야 합니다. 이 확인이 어려운 업무는 금지로 단정하기보다 보조 범위를 더 좁혀 다시 설계할 수 있습니다.
참고한 공식 자료
- NIST AI RMF Playbook — AI 시스템의 설계·개발·배포·사용 전 과정에서 위험 관리 결과를 운영하는 선택지를 제시합니다. 조직별 의무 규정이 아닌 자발적 참고 자료입니다. (2026-08-26 확인)