데모는 끝났는데, 아무도 배포를 승인하지 못합니다
AI가 고객 문의를 꽤 잘 분류합니다. 발표 화면에서도 결과가 좋았고 현업 반응도 괜찮아요. 그런데 프로덕션 배포를 논의하면 질문이 쏟아집니다. 어느 정도 틀려도 되는지, 고객 데이터에 접근해도 되는지, 사고가 나면 누가 끄는지 정해진 답이 없습니다.
이 단계에서 모델을 더 튜닝한다고 문제가 풀리지는 않아요. 프로덕션으로 가기 위한 기준을 파일럿 전에 쓰지 않았기 때문입니다. Vellum의 AI 전환 플레이북이 제시하는 실용적인 변화도 여기에 있습니다. 전략, 팀, 도구, 파일럿, 조직 확산의 순서로 진행하되, KPI·책임·데이터 접근·승인 조건은 첫 단계부터 함께 설계하라는 것입니다.
NIST AI RMF 역시 GOVERN을 마지막 점검 단계가 아니라 MAP·MEASURE·MANAGE를 가로지르는 교차 기능으로 둡니다. 거버넌스는 배포 직전 받는 도장이 아니라, 무엇을 만들고 누가 어떤 조건에서 멈출지를 계속 결정하는 운영 방식에 가깝습니다.
먼저 ‘95%가 죽는다’는 숫자부터 내려놓아야 합니다
Vellum 원문은 MIT NANDA를 인용해 기업 생성형 AI 파일럿의 95%가 측정 가능한 ROI를 내지 못한다고 소개합니다. 하지만 이 문장을 “95%가 프로덕션 배포에 실패했다”거나 “나머지 5%는 초기 거버넌스 덕분에 살아남았다”고 바꿀 근거는 확인되지 않았습니다.
현재 확인 가능한 MIT NANDA 공식 페이지는 연구 그룹과 연구 방향을 소개하며, 해당 보고서는 별도 접근 경로로 안내합니다. 공개된 공식 원문에서 표본 구성, ROI의 정의, 95% 산출 방식을 직접 확인하지 못한 상태이므로 이 수치를 보편적인 실패율로 쓰면 안 됩니다.
가져갈 것은 95%라는 공포가 아니라 배포 판단의 순서입니다. Vellum의 5단계는 공급사가 제안한 플레이북이지, 성공 기업과 실패 기업을 통제 비교한 연구가 아닙니다. 따라서 특정 성공 확률을 약속하기보다 우리 파일럿의 승격 조건을 만드는 용도로 써야 합니다.
파일럿 전에 한 장으로 정할 일은 일곱 가지입니다
도구 비교표보다 먼저 필요한 문서는 ‘무엇이 얼마나 좋아져야 하며, 어떤 위험이 생기면 멈출지’를 연결한 1페이지 운영 계약입니다. 최소한 다음 일곱 항목이 한곳에 있어야 합니다.
| 항목 | 적어야 할 내용 | 비어 있을 때 생기는 문제 |
|---|---|---|
| KPI 기준선 | 현재 처리시간·비용·오류율 | 개선 여부를 비교할 수 없음 |
| 목표와 기간 | 언제까지 어느 수준을 만들지 | 파일럿이 끝없이 이어짐 |
| KPI 소유자 | 업무 결과를 최종 판단할 사람 | 좋은 데모가 곧 성공으로 간주됨 |
| 데이터 계약 | 출처·소유자·접근·보존 조건 | 실데이터 연결 단계에서 중단됨 |
| 권한 분리 | 구축자·승인자·배포자 | 만든 사람이 스스로 위험을 승인함 |
| 오류 예산 | 허용 오류와 즉시 중단할 사고 | 문제가 생겨도 계속할지 판단 못 함 |
| 롤백 경로 | 기존 업무로 돌아가는 방법과 권한자 | 배포 후 안전하게 끌 수 없음 |
이 문서는 긴 정책집일 필요가 없습니다. NIST AI RMF도 특정 조직도나 제품을 의무화하지 않는 자발적·결과 중심 프레임워크입니다. 조직의 사용 맥락과 위험 허용도에 맞춰 GOVERN·MAP·MEASURE·MANAGE의 행동을 선택하도록 설계돼 있습니다. 생성형 AI를 다룬다면 고유하거나 증폭된 위험에 맞춘 NIST의 생성형 AI 프로필을 보조 자료로 사용할 수 있습니다.
첫 파일럿은 실제 행동을 끈 상태에서 시작하세요
처음부터 AI가 환불 승인이나 고객 발송을 실행하게 할 필요는 없습니다. Vellum은 제안 결과를 검토 대기열로 보내는 섀도 실행부터 시작해 SOP와 골든셋을 비교하고, 이후 작은 사용자 집단의 보조 모드와 제한적 자동 행동으로 범위를 넓히는 방식을 제안합니다.
AI RMF 1.0의 현재·목표 프로필 개념으로 상태를 정리하고, NIST AI RMF Playbook에서 필요한 행동을 고른 뒤 아래 순서로 업무 하나를 준비해 보세요.
- 이미 기준선을 아는 업무 하나를 고릅니다. 처리시간·비용·오류율 중 적어도 하나를 현재 기록하고 있어야 합니다. 기준선이 없다면 AI를 연결하기 전에 이번 주부터 같은 기준으로 기록하세요.
- 가치 가설과 중단 조건을 한 문장에 넣습니다. 예를 들어 “90일 동안 상담원 승인형 환불 분류로 중앙 처리시간을 12분에서 9분 이하로 낮추되, 전체 오분류율은 현재 4%를 넘지 않는다”처럼 대상·기간·목표·안전 조건을 함께 씁니다. 90일과 수치는 예시이며 조직의 업무 주기에 맞춰 정해야 합니다.
- 사람과 데이터의 권한을 분리합니다. 데이터 출처와 소유자, 허용된 접근 방법을 적고 구축자·업무 승인자·개인정보 검토자·배포자를 지정하세요. 한 사람이 여러 역할을 맡더라도 어떤 권한으로 결정했는지는 구분해야 합니다.
- 행동을 끈 섀도 실행을 돌립니다. 정상 사례와 대표 실패 사례로 골든셋을 만들고, AI 결과는 고객에게 보내지 말고 검토 대기열에 쌓습니다. SOP 대비 통과율과 오류 유형을 기록하세요.
- 게이트를 모두 통과할 때만 보조 모드로 엽니다. 평가 임계값, 오류 예산, 데이터 통제와 소유자 승인을 모두 충족하면 작은 사용자 집단에 제안 기능만 제공합니다. 범위를 넓힐 때도 같은 게이트를 다시 확인합니다.
대상 업무: ______
기준선 / 목표 / 기간: ______
KPI 소유자: ______
데이터 출처·소유자·접근 조건: ______
구축자 / 승인자 / 배포자: ______
통과 임계값과 오류 예산: ______
즉시 중단 조건: ______
롤백 방법과 권한자: ______
첫 성공은 자동화율이 아닙니다. 이 문서와 섀도 실행 결과를 보고 책임자가 “이 조건이라면 소규모 보조 모드로 열어도 된다”고 승인할 수 있는 상태가 첫 번째 운영 성과입니다. 기준선, 데이터 권한, 실패 사례, 로그나 롤백 기능 중 하나라도 확인되지 않았다면 모델 개선보다 그 빈칸을 먼저 해결해야 합니다.
