생성형 AI를 업무에 도입하기 전 정해야 할 승인·검토·기록 기준
생성형 AI를 빠르게 쓰는 것보다 중요한 것은 어떤 업무를 누가 승인하고, 결과를 어떻게 검토하며, 문제가 생겼을 때 무엇을 기록할지 정하는 일입니다. 도입 전에 정리할 운영 기준을 체크리스트로 안내합니다.
생성형 AI를 업무에 도입하기 전에는 도구 선택보다 승인·검토·기록의 경계를 먼저 정해야 합니다. 사람이 최종 책임을 지는 업무, 입력하면 안 되는 정보, 결과를 배포하기 전 확인할 항목을 문서로 고정해야 속도와 안전을 함께 유지할 수 있습니다.
가장 실용적인 시작점은 업무를 위험도별로 나누고, 각 등급에 승인자와 검토 방법을 붙이는 것입니다. 초안 작성처럼 영향이 제한된 작업은 가벼운 확인으로 충분하지만, 고객 안내·채용·법무·보안 판단에 연결되는 결과는 별도 승인과 근거 기록을 요구해야 합니다.
먼저 정할 업무 경계와 책임
정책은 모델 이름이 아니라 업무 결과를 기준으로 써야 합니다. 예를 들어 내부 회의록 요약과 고객에게 발송할 계약 안내는 같은 모델을 사용하더라도 허용 범위와 책임이 다릅니다. 업무 소유자는 입력 데이터의 적법성, 결과의 정확성, 최종 게시 권한을 각각 누가 맡는지 지정합니다. 사용자는 AI가 작성한 문장을 그대로 전달하지 않고 검토를 완료했다는 표시를 남겨야 합니다.
승인 등급을 위험도에 연결하기
등급을 세 단계로 단순화하면 팀이 실제로 적용하기 쉽습니다. 낮은 등급은 개인 생산성 보조, 중간 등급은 내부 의사결정 자료, 높은 등급은 외부 이해관계자나 권리·안전에 영향을 주는 작업으로 구분합니다. 높은 등급일수록 승인자, 검토 근거, 되돌리기 절차를 모두 요구하고 자동 게시나 자동 실행은 기본값에서 제외합니다.

입력 데이터와 프롬프트 기록
기록은 감시를 위한 로그가 아니라 재현을 위한 업무 자료입니다. 프롬프트 전문을 저장할 수 없는 경우에도 사용 목적, 입력 데이터 분류, 사용한 모델·버전, 실행 시각, 담당자를 남겨야 합니다. 개인정보·비공개 계약서·인증정보처럼 외부 처리에 부적합한 값은 금지 목록으로 분리하고, 불가피한 테스트에는 비식별화된 샘플만 사용합니다.
업무 목적과 결과를 사용할 사람을 한 문장으로 적는다.
입력 데이터의 민감도와 외부 전송 허용 여부를 표시한다.
모델 이름·버전, 프롬프트 템플릿, 실행 시각을 기록한다.
원문, AI 결과, 사람이 수정한 최종본의 관계를 보존한다.
검토자가 확인할 결과 품질
검토는 문장이 자연스러운지 보는 교정과 다릅니다. 사실성, 누락, 편향, 권리 침해, 보안 노출을 업무별로 나눠 확인해야 합니다. 검토자는 원자료와 대조할 수 있어야 하며, 확인하지 못한 부분은 확정 표현 대신 보류 상태로 표시합니다. 결과를 사용하는 시스템에는 승인된 버전과 검토자를 함께 연결해 나중에 같은 결과를 다시 찾을 수 있게 합니다.
AI 결과의 핵심 주장마다 원자료 또는 담당자 확인 여부를 표시한다.
민감한 결정이나 외부 발송이면 독립된 사람이 재검토한다.
오류·거부·수정 사례를 기록하고 다음 프롬프트와 교육에 반영한다.
예외와 중단 조건을 운영하기
현장에서 정책이 멈추는 지점은 예외입니다. 결과가 원자료와 충돌하거나 개인정보가 섞였거나, 모델 변경 뒤 품질이 달라졌다면 누구나 사용을 중단하고 담당자에게 올릴 수 있어야 합니다. 중단 조건, 승인 회수, 이전 버전 복귀, 영향받은 사용자 통지의 순서를 미리 정하면 문제를 숨기려는 압박을 줄일 수 있습니다. 한 달에 한 번 기록을 샘플링해 승인 누락과 반복 오류를 점검하면 정책도 실제 업무에 맞게 조정됩니다.
도입 완료를 판단하는 체크리스트
도입 완료는 계정을 만들었다는 뜻이 아닙니다. 위험도별 업무 목록과 승인자가 있고, 금지 데이터가 정의되어 있으며, 검토자가 결과와 원자료를 연결할 수 있어야 합니다. 실제 사례로 승인·수정·중단 기록을 한 번씩 남겨 보고, 담당자가 바뀌어도 같은 절차를 재현할 수 있으면 첫 운영 기준이 마련된 것입니다. 이후에는 모델과 업무가 바뀔 때마다 이 조건을 다시 확인합니다.