"AI 거버넌스"라는 말이 요즘 많이 나오는데, 막상 뭘 하라는 건지 모호하죠. 저희도 그랬어요. 그래서 거창한 프레임워크 대신, 저희가 제품을 운영하면서 실제로 지키고 있는 기준 일곱 개를 적어 볼게요. 이 블로그에서 그동안 쓴 글들이 사실 다 이 기준의 구현이에요.
1. 모든 결과에 근거가 붙어요
추출한 값이든 판정이든, 원본의 어디에서 왔는지 좌표나 위치가 있어요. 근거 없는 결과는 내보내지 않아요. 도면 파서의 rects, 한글 파서의 src, 뉴스 요약의 원문 문단 참조가 다 이거예요.
왜냐면, 근거가 없으면 사용자가 결과를 확인할 방법이 없고, 확인 못 하면 믿을 수 없고, 못 믿으면 안 써요.
2. 모르면 모른다고 해요
신뢰도가 낮거나 대조 상대가 없으면 "판단 보류"예요. 억지로 답하지 않아요. 보류율을 지표로 보고, 0이면 오히려 의심해요. 3월 10일 글이에요.
3. 사람이 되돌릴 수 없는 일은 사람이 승인해요
메일 발송, 데이터 수정, 결재 상신처럼 되돌릴 수 없는 작업은 AI가 혼자 못 해요. 계획을 보여 주고 승인받아요. 승인 없이 실행되는 경로는 구조상 없어요. 4월 28일 글이에요.
4. 바뀌는 건 전부 버전이 있어요
모델, 프롬프트, 판정 규칙, 보정 표, 계정 사전. 전부 버전이 있고 어떤 결과가 어떤 버전으로 만들어졌는지 기록돼요. "지난달엔 됐는데 왜 지금은 안 돼요?"에 답하려면 이게 있어야 해요.
5. 바꾸기 전에 평가해요
프롬프트든 모델이든 바꾸면 평가셋을 돌리고, 어느 영역이든 나빠지면 배포를 막아요. 4월 14일 글이에요. "전체적으로 좋아졌어요"는 배포 근거가 아니에요.
6. 기록은 남기되 내용은 안 남겨요
호출, 도구 실행, 승인, 비용은 전부 트레이스와 감사 로그로 남아요. 하지만 문서 내용 자체는 로그에 안 들어가요. 해시와 위치만요. 로그를 외부로 보낼 수 있으려면 이래야 해요. 특히 폐쇄망 고객에게는 필수예요.
7. 성능은 계속 재요
배포 시점의 정확도는 그 시점의 정확도예요. 입력이 바뀌면 조용히 떨어져요. 사람이 확인한 결과를 모아서 주기적으로 정확도와 보정 상태를 다시 재고, 떨어지면 알려요. 이건 하반기 ML Ops 글에서 자세히 쓸게요.
이 일곱 개가 "거버넌스"인 이유
규정이나 위원회 얘기가 아니라서 거버넌스 같지 않게 느껴지실 수도 있어요. 그런데 저희 생각에 거버넌스는 결국 "이 AI가 뭘 했는지 설명할 수 있고, 잘못됐을 때 찾아서 고칠 수 있는가" 예요. 위 일곱 개가 있으면 그게 돼요. 없으면 아무리 좋은 정책 문서가 있어도 안 돼요.
도입하실 때
전부 한 번에 하실 필요는 없어요. 저희가 권하는 순서는 1번(근거) → 2번(보류) → 4번(버전) 순이에요. 이 셋이 있으면 나머지는 자연스럽게 필요해져요. 반대로 7번(모니터링)부터 하면 뭘 봐야 할지 몰라서 대시보드만 생겨요.
다음 주는 금융·공공 환경에서 문서 자동화를 설계할 때의 단계를 정리할게요.