1,368 AI Failures and What They Teach About Evals — Vishal Srivastava & Tanmay Sah, New York Life

한 줄 핵심

AI 실패는 기술 성능만으로 설명되지 않으며, 개발·배포·비즈니스 맥락을 함께 평가하는 위험 기반 시스템 수준 eval이 필요하다는 점을 보여준다.

시간별 요약

1. 0:00
   소개 공개 AI incident database를 바탕으로 AI 실패를 분석해, 개별 모델이 아니라 전체 AI 시스템을 어떻게 평가해야 하는지에 대한 교훈을 찾는다.
2. 0:41
   AI 실패가 빠르게 증가하고 있다 기초 모델 시대에 AI 실패 사례가 가파르게 늘고 있어, 기업이 모든 유스케이스를 일일이 검토하기보다 체계적인 분석 틀이 필요하다.
3. 1:35
   실패의 세 가지 차원 실패는 개발 단계, 배포 단계, 그리고 실제 비즈니스 사용 맥락에서 발생하며, 모델 성능만이 아니라 시스템 전체를 봐야 위험을 제대로 이해할 수 있다.
4. 3:34
   13개 세부 차원 기술적 강도 6개, 배포 통제 4개, 비즈니스 영향 3개로 나누면 실패를 구조적으로 분해할 수 있고, 각 차원은 데이터 품질, 인간 개입, 모니터링, 법적 영향, 규모 같은 요소를 포함한다.
5. 6:09
   실패의 98%를 포괄하는 틀 13개 세부 차원을 적용하면 거의 98%의 AI 실패를 설명할 수 있어, 실패는 우연한 사건이 아니라 반복적으로 나타나는 구조를 가진다는 점이 드러난다.
6. 7:12
   가장 큰 피해를 만드는 실패 모든 세부 차원이 같은 중요도를 갖는 것은 아니며, 인간 검토의 효과성과 모니터링 같은 배포 통제 요소가 실제 피해와 더 강하게 연결되므로 우선순위를 더 높게 둬야 한다.
7. 9:43
   유스케이스를 중요도로 순위 매기기 유스케이스별 위험 수준을 중요도 기준으로 나누면 더 위험한 AI 사용처에 평가 자원을 집중할 수 있고, 이는 곧 피해와 직접적으로 연결되는 업무를 먼저 다루는 방식이다.
8. 10:43
   위험을 네 부분으로 분해하기 위험은 실패 빈도, 실제 의사결정에 도달하는지, 실패가 탐지되지 않는지, 그리고 결과가 얼마나 심각한지의 네 요소로 나눌 수 있으며, 배포 방식에 따라 같은 모델도 전혀 다른 위험을 만든다.
9. 11:40
   에이전트 시스템에서 무엇을 테스트할 것인가 에이전트 시스템 평가는 검색 결과, 도구 실패, 인간 검토, 권한 경계, 복구 가능성까지 포함해야 하며, 전통적 ML보다 테스트 범위가 넓어졌지만 검증의 원리는 그대로다.
10. 13:14
    평가자를 신뢰할 수 있는가 평가자 자체가 틀릴 수 있으므로, 평가 결과를 맹신하지 말고 어떤 증거를 얼마나 커버하는지와 실제 배포 시스템에 적합한지를 함께 점검해야 한다.
11. 13:48
    확증 편향과 실패 중심 eval 평가는 무엇이 맞는지 확인하는 절차가 아니라 무엇이 틀리는지 반증하는 절차여야 하며, 실패를 드러내는 방향으로 설계해야 확증 편향을 줄일 수 있다.
12. 15:20
    구축, 파괴, 수정 시스템의 주장부터 세우고 적극적으로 깨본 뒤, 실패 구간을 파악해 보완 시스템이나 적용 범위 제한을 추가하는 반복 루프를 통해 신뢰 가능한 배포 영역을 점점 넓힌다.
13. 17:03
    실제 챗봇 실패 사례 항공사 챗봇이 잘못된 환불 조언을 해 고객이 이를 믿고 행동한 뒤 회사가 책임을 지게 된 사례를 통해, 정책 일치성 검증과 인간 에스컬레이션이 없으면 단순한 답변 오류도 큰 피해로 이어질 수 있음을 보여준다.
14. 18:30
    정리 평가는 빈도 중심이 아니라 위험 중심이어야 하며, 전체 시스템을 기술적 실패·배포 통제·비즈니스 맥락으로 나눠 중요한 유스케이스부터 스트레스 테스트한 뒤에야 배포 결정을 내릴 수 있다.

실무 인사이트

• 고위험 AI는 모델 정확도보다 배포 통제와 인간 검토의 설계가 실제 피해를 더 크게 좌우하므로, eval 대상에 운영 절차를 반드시 포함해야 한다.
• 평가를 설계할 때는 정상 사례 평균 성능보다 실패를 드러내는 반증형 테스트를 우선해야 하며, 특히 경계 조건과 권한 남용 시나리오를 집중적으로 검증해야 한다.
• 유스케이스별 중요도와 위험도를 먼저 분류한 뒤 평가 자원을 배분하면, 모든 시스템을 동일한 수준으로 보는 비효율을 줄이고 고위험 영역의 안전성을 빠르게 높일 수 있다.