데모 성공률과 운영 성공률은 다른 숫자입니다
AI가 샘플 20개를 잘 처리했다고 바로 업무에 연결하면 위험합니다. 정확도가 95%라고 가정해도 하루 1,000건을 자동 처리하면 기대값상 50건이 틀릴 수 있습니다. 그 50건이 광고 문구인지, 고객 환불인지, 송금 정보인지에 따라 위험은 완전히 다릅니다.
NIST의 Generative AI Profile도 생성형 AI를 도입할 때 위험을 수명주기 전체에서 식별하고 관리하는 접근을 권고합니다.
실패 이유 1 — 입력이 현실에서는 깨끗하지 않습니다
메일 제목이 비어 있고, PDF가 스캔본이고, 엑셀 열 이름이 바뀌고, 사용자가 예상하지 못한 표현을 씁니다. 데모 데이터보다 실제 데이터의 꼬리가 훨씬 깁니다.
실패 이유 2 — AI의 자신감과 정확도는 다릅니다
생성형 AI는 틀린 답도 자연스럽게 표현할 수 있습니다. 그래서 금액·계좌·계약조건처럼 검증 가능한 항목은 원천 데이터와 deterministic rule로 다시 확인해야 합니다.
실패 이유 3 — 권한이 너무 큽니다
읽기만 하면 되는 AI에게 삭제·송금·발송 권한까지 주면 작은 판단 오류가 실제 사고가 됩니다. 처음에는 read → draft → human approve → execute 순서가 안전합니다.
실패 이유 4 — 실패했는데 아무도 모릅니다
운영 자동화에는 성공 로그보다 실패 로그가 더 중요합니다. 어떤 입력이 실패했는지, 재시도했는지, 사람이 처리해야 하는지 알림이 와야 합니다.
실패 이유 5 — 모델이 바뀌는데 테스트가 없습니다
프롬프트, 모델, 외부 API, 원본 양식 중 하나만 바뀌어도 결과가 달라질 수 있습니다. 중요한 workflow에는 대표 입력 세트와 기대 결과를 저장해 회귀 테스트하는 편이 좋습니다.
실무 배포 전 최소 체크
- AI가 틀려도 되돌릴 수 있는가
- 고위험 행동 전에 사람이 승인하는가
- 개인정보와 credential 접근 범위가 최소화됐는가
- 실패와 예외가 기록되는가
- 비용과 호출량을 모니터링하는가
- 모델·프롬프트 변경 후 테스트하는가
자동화 수준을 높이는 것보다 실패했을 때 피해 반경을 작게 만드는 것이 먼저입니다.
근거: NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (2024, updated 2026).