AI 사고(AI Incident)란? 실제 피해를 기록하고 대응하는 기준

TL;DR

AI 사고(AI Incident)는 AI 시스템의 개발, 사용 또는 오작동이 사람의 건강, 권리, 재산, 공동체, 중요 기반 시설이나 환경에 실제 피해를 일으킨 사건입니다. 아직 피해가 생기지 않았지만 충분히 생길 수 있는 상황은 AI 위험 사건(AI Hazard)에 가깝습니다. 대응할 때는 기능을 멈추는 데서 끝내지 말고 어떤 모델과 데이터가 어떤 결과를 냈는지, 누가 영향을 받았는지, 어떤 조치를 했는지까지 보존해야 합니다.

핵심 3줄 요약

• 핵심 1
  AI 사고의 기준은 실제 피해가 발생했는지입니다. 단순히 답변이 마음에 들지 않았다는 이유만으로 모든 사례를 사고로 분류하지는 않습니다.
• 핵심 2
  AI 위험 사건은 피해 가능성, AI 사고는 현실화된 피해를 가리킵니다. 오류나 오작동은 원인일 수 있지만 피해로 이어졌는지 따로 확인해야 합니다.
• 핵심 3
  좋은 사고 대응은 중단, 보호, 증거 보존, 영향 평가, 보고, 재발 방지로 이어집니다. 모델 버전과 프롬프트, 입력·출력, 로그, 사람의 개입도 함께 기록해야 합니다.

이 글에서 다룰 내용

AI 사고를 한 문장으로 정의하면 무엇인가요?

AI 사고는 하나 이상의 AI 시스템을 개발하거나 사용하거나 운영하는 과정에서 그 시스템의 작동 또는 오작동이 직접·간접으로 실제 피해를 일으킨 사건이나 일련의 사건입니다.

OECD는 AI 사고를 AI 시스템의 개발, 사용 또는 오작동이 사람의 건강, 중요 기반 시설, 법으로 보호되는 권리, 재산, 공동체나 환경에 실제 피해를 일으킨 경우로 정의합니다. 핵심은 AI가 관련됐다는 사실만이 아니라 실제 피해와의 연결입니다.

AI가 잘못된 답을 한 번 냈더라도 사람이 즉시 발견해 아무 결정에도 쓰지 않았고 피해도 생기지 않았다면 곧바로 AI 사고라고 단정하기 어렵습니다. 반대로 AI 추천을 믿고 대출을 부당하게 거절하거나, 상담 AI가 개인정보를 다른 사용자에게 노출해 권리 침해가 발생했다면 사고로 다뤄야 할 가능성이 큽니다.

한 줄 정리: AI 사고는 단순한 모델 오류가 아니라 AI의 개발·사용·오작동이 현실의 피해로 이어진 사건입니다.

쉬운 예시로 이해해 볼까요?

감자나라ai님이 고객 상담 AI를 운영한다고 가정해 보겠습니다. 어느 날 상담 AI가 고객 A의 주문 내역과 전화번호를 고객 B에게 보여 줬습니다. 운영팀이 실제 노출 사실을 확인했다면 AI 기능이 관련된 개인정보 피해가 발생한 상황입니다. 일반적인 품질 문제로만 넘기지 말고 AI 사고와 개인정보 침해 사고 절차를 함께 검토해야 합니다.

비슷해 보이지만 다른 상황도 있습니다. 테스트 환경에서 같은 문제가 발견됐지만 외부 고객에게는 아무 정보도 노출되지 않았고 운영 전에 수정했다면 실제 피해가 발생한 사고보다는 AI 위험 사건이나 근접 사고로 기록하는 편이 맞을 수 있습니다. 이런 사례도 버리지 말고 재발 방지 자료로 남겨야 합니다.

서버가 잠시 느려졌다는 사실만으로 AI 사고가 되는 것도 아닙니다. 일반 인프라 장애인지, AI 시스템의 오작동이 중요 업무를 중단시키거나 사람과 조직에 피해를 줬는지 확인해야 합니다.

쉬운 예시: 연기 감지기가 이상 신호를 냈지만 불이 나지 않았다면 위험 신호에 가깝고, 실제 화재로 사람이 다치거나 재산이 손상됐다면 사고입니다. AI에서도 잠재적 피해와 현실화된 피해를 나눠 봅니다.

AI 위험·오류·보안 사고와 무엇이 다른가요?

AI 사고와 AI 위험 사건

OECD가 말하는 AI 위험 사건(AI Hazard)은 AI 시스템의 개발, 사용 또는 오작동이 실제 피해로 이어질 가능성이 있는 상황입니다. AI 사고는 그 피해가 이미 현실화된 경우입니다. 피해가 없었다고 기록을 버리는 것이 아니라 사고로 발전할 가능성을 점검하고 통제를 보완합니다.

AI 사고와 모델 오류

모델 오류는 잘못된 분류, 부정확한 답변, 예상하지 못한 출력 같은 기술적 결과입니다. 오류가 사람의 권리나 재산에 실제 피해를 주면 AI 사고의 원인이 될 수 있습니다. 그러나 내부 테스트에서 발견해 영향 없이 수정한 오류까지 모두 같은 심각도의 사고로 볼 필요는 없습니다.

AI 사고와 오작동

오작동은 시스템이 의도하거나 문서화한 방식과 다르게 움직인 상태를 가리킵니다. 오작동 자체와 피해는 구분해야 합니다. 정상 동작한 AI를 사람이 부적절한 목적으로 사용해 피해를 만들 수도 있으므로 AI 사고는 기술 고장보다 넓은 개념입니다.

AI 사고와 사이버보안 사고

사이버보안 사고는 계정 탈취, 악성 접근, 데이터 유출처럼 정보 시스템의 기밀성·무결성·가용성을 침해한 사건을 중심으로 봅니다. AI 사고는 차별적 결정, 잘못된 의료 권고, 안전 문제, 재산 피해처럼 보안 침해가 아닌 피해도 포함할 수 있습니다. 한 사건이 AI 사고이면서 보안 사고일 수도 있습니다.

AI 사고와 근접 사고

근접 사고(Near Miss)는 실제 피해 직전까지 갔지만 우연이나 사람의 개입으로 피해가 발생하지 않은 상황입니다. 조직마다 분류 기준은 다를 수 있지만, 이런 사례를 따로 모으면 큰 사고가 일어나기 전에 취약한 절차를 찾는 데 도움이 됩니다.

비교 정리: AI 위험은 피해 가능성, 모델 오류·오작동은 기술적 원인이나 상태, AI 사고는 현실화된 피해, 보안 사고는 정보보호 침해를 중심으로 봅니다.

AI를 사용할 때 왜 알아야 하나요?

AI는 답변만 만드는 도구를 넘어 채용, 고객 응대, 의료, 금융, 교육, 보안, 콘텐츠 검수와 업무 자동화에 들어갑니다. 결과가 사람의 기회와 권리, 돈, 안전에 연결될수록 작은 오류도 실제 피해로 커질 수 있습니다.

AI 사고라는 공통 용어가 있으면 고객 불만, 모델 오류, 데이터 유출, 차별적 결과를 서로 다른 부서가 제각각 처리하는 문제를 줄일 수 있습니다. 제품팀은 모델과 프롬프트 버전을 찾고, 보안팀은 접근 기록을 확인하며, 법무·개인정보 담당자는 신고 의무를 검토하고, 운영팀은 피해 확산을 막는 식으로 역할을 나눌 수 있습니다.

OECD의 공통 보고 프레임워크는 AI 사고를 비교하고 배우기 위한 29개 기준을 제시합니다. NIST의 생성형 AI 프로필도 제3자 생성형 AI 기술을 포함한 사고 대응 계획의 책임자를 정하고, 훈련하고, 사후 학습으로 개선하라고 권고합니다.

EU AI Act는 모든 AI 문제를 같은 방식으로 부르지 않고, 법이 정한 범위의 중대한 사고(Serious Incident)와 보고 의무를 별도로 다룹니다. 따라서 내부의 AI 사고 분류와 법적 보고 대상은 같다고 가정하지 말고 적용 지역, 시스템 위험 등급과 구체적 피해를 확인해야 합니다.

핵심 인사이트: 사고 이름을 붙이는 목적은 책임을 피하거나 과장하는 데 있지 않습니다. 피해를 멈추고 같은 문제가 반복되지 않도록 사실과 조치를 연결하는 데 있습니다.

어떤 상황을 AI 사고로 점검해야 하나요?

사람의 건강이나 안전에 피해가 생겼을 때

의료 보조 AI의 잘못된 권고, 산업 현장의 위험한 자동 제어, 이동 수단의 오판처럼 사람이 다치거나 건강이 악화된 경우입니다. AI의 출력이 최종 원인이 아니더라도 의사결정에 어떤 영향을 줬는지 조사합니다.

개인정보와 기본권이 침해됐을 때

개인정보 노출, 차별적 채용·대출 결정, 부당한 감시, 설명이나 이의 제기 기회가 없는 자동 결정처럼 사람의 권리에 영향을 준 경우입니다. 모델 성능 수치가 높아도 특정 집단에 반복해서 피해가 생기면 사고 대응이 필요할 수 있습니다.

중요 업무와 기반 시설이 중단됐을 때

AI가 교통, 에너지, 의료, 통신이나 조직의 핵심 업무를 잘못 제어하거나 중단시킨 경우입니다. 단순한 짧은 지연과 광범위한 운영 중단은 심각도가 다르므로 영향 범위와 복구 시간을 기록합니다.

재산·공동체·환경에 실제 손해가 생겼을 때

AI 자동화가 잘못된 거래나 주문을 반복해 금전 손실을 만들거나, 합성 콘텐츠가 공동체에 실질적 피해를 주거나, 자동 제어가 환경 피해에 기여한 경우입니다. 피해 금액만 보지 말고 영향을 받은 사람과 기간도 봅니다.

외부 AI 공급자의 변경이 피해로 이어졌을 때

API 모델 업데이트, 안전 정책 변경, 데이터 처리 방식 변경이나 서비스 장애가 우리 제품의 잘못된 결과로 연결될 수 있습니다. 외부 공급자 문제라도 사용자에게 제공한 서비스의 대응 책임과 계약상 통보 절차를 따로 확인합니다.

실전 의미: AI 사고 여부는 모델 정확도 하나가 아니라 실제 피해, 영향받은 대상, 지속 시간, 확산 범위와 AI의 기여도를 함께 보고 판단합니다.

사고가 발생하면 무엇을 기록해야 하나요?

1. 발견 시각과 영향 범위를 적습니다

누가 언제 문제를 발견했는지, 언제부터 언제까지 이어졌는지, 어떤 사용자·업무·지역이 영향을 받았는지 기록합니다. 피해가 계속되는지부터 확인합니다.

2. 사용한 AI 구성과 입력·출력을 보존합니다

모델 이름과 버전, 시스템 프롬프트, 사용자 입력, 검색 문서, 도구 호출, 안전 필터, 출력, 사람의 승인 여부를 남깁니다. 개인정보와 비밀 정보는 권한을 제한한 안전한 저장소에 보관합니다.

3. 실제 피해와 잠재 피해를 나눕니다

확인된 피해, 아직 확인 중인 영향, 최악의 가능성을 섞지 않습니다. 영향을 받은 사람 수, 권리 침해, 금전 손실, 업무 중단과 건강·안전 영향을 근거와 함께 기록합니다.

4. 즉시 조치와 의사결정을 시간순으로 남깁니다

기능 중단, 이전 버전으로 복구, 사람 검토 전환, 접근 키 폐기, 고객 안내, 공급자 연락 같은 조치를 누가 승인하고 언제 실행했는지 적습니다.

5. 관련 법·계약의 보고 요건을 확인합니다

개인정보 침해, 산업별 안전 규정, 계약상 통보, AI 관련 규정은 보고 대상과 기한이 서로 다를 수 있습니다. EU AI Act의 중대한 사고처럼 특정 범위에만 적용되는 의무도 있으므로 담당자와 법률 전문가가 확인해야 합니다.

6. 원인과 재발 방지 조치를 연결합니다

사람 한 명의 실수로 끝내지 말고 데이터, 모델, 프롬프트, 권한, 테스트, 승인 절차와 모니터링 가운데 무엇이 실패했는지 봅니다. 수정 후에는 같은 입력과 유사한 경계 사례로 재시험합니다.

기록 체크리스트: 시간, 영향 대상, 실제 피해, 모델·프롬프트·데이터 버전, 입력·출력, 사람의 개입, 즉시 조치, 보고 여부, 원인, 재시험 결과를 한 사건 번호에 연결하세요.

AI 사고에는 어떻게 대응하나요?

먼저 피해 확산을 막습니다. 위험한 자동 실행을 중단하고 필요한 경우 사람 승인 방식이나 안전한 이전 버전으로 전환합니다. 건강과 안전에 직접 영향을 주는 상황이라면 일반적인 서비스 복구보다 사람 보호를 우선합니다.

그다음에는 증거를 보존합니다. 로그를 보기 좋게 고쳐 쓰거나 실패한 입력을 삭제하지 않습니다. 현재 상태의 스냅샷과 원본 기록을 남기고, 조사 사본에서 분석합니다.

영향받은 사람과 담당 기관에 무엇을 언제 알릴지도 정합니다. 확인되지 않은 내용을 확정적으로 말하지 않되, 피해를 줄이기 위해 필요한 행동과 연락 경로는 분명히 안내합니다.

복구 뒤에는 원인 분석과 재발 방지를 진행합니다. 평가 데이터 추가, 위험 입력 차단, 권한 축소, 사람 승인, 공급자 변경 감지, 경보 기준, 비상 전환 절차를 보완하고 실제 훈련으로 작동 여부를 확인합니다.

실전 팁: AI 사고 대응표에 제품, 데이터, 보안, 개인정보·법무, 고객 지원 책임자를 미리 지정하세요. 사고가 난 뒤 담당자를 찾기 시작하면 피해 확인과 보고가 늦어집니다.

사용할 때 무엇을 주의해야 하나요?

첫째, 모든 낮은 품질의 답변을 같은 심각도의 사고로 올리지 않습니다. 품질 이슈, 위험 사건, 근접 사고, 실제 피해 사고를 나눠야 중요한 사건이 묻히지 않습니다.

둘째, AI가 단독 원인이어야만 사고라고 생각하지 않습니다. 사람의 승인, 잘못된 업무 규칙, 부족한 데이터와 외부 공급자 변경이 함께 작용할 수 있습니다. AI가 피해에 기여한 경로를 살핍니다.

셋째, 복구를 서두르다 증거를 지우지 않습니다. 모델·프롬프트를 바꾸기 전에 원본 설정, 로그와 출력 기록을 보존해야 원인을 재현할 수 있습니다.

넷째, 사고 보고서에 불필요한 개인정보를 더 모으지 않습니다. 조사에 필요한 최소 정보만 수집하고 열람 권한과 보관 기간을 정합니다.

다섯째, 공급자에게 알렸다는 이유로 내부 대응을 끝내지 않습니다. 외부 모델이나 API가 원인이어도 우리 사용자의 피해를 줄이고 진행 상황을 알리는 절차가 필요합니다.

여섯째, 사고 건수만 성과 지표로 삼지 않습니다. 보고를 장려하면 초기에는 건수가 늘 수 있습니다. 탐지 시간, 피해 확산 시간, 복구 시간, 재발률과 개선 조치 완료 여부를 함께 봅니다.

일곱째, 내부 분류를 법적 판단으로 대신하지 않습니다. OECD의 공통 정의, EU AI Act의 중대한 사고, 개인정보·보안 신고는 범위와 기준이 다릅니다. 실제 의무는 적용 법과 담당 기관의 최신 지침을 확인해야 합니다.

주의: AI 사고 대응의 목표는 문제를 숨기거나 숫자를 줄이는 것이 아니라 피해를 줄이고 사실을 보존하며 같은 실패가 반복되지 않게 만드는 것입니다.

자주 묻는 질문

Q1. AI가 틀린 답을 하면 모두 AI 사고인가요?

아닙니다. 틀린 답은 모델 오류나 품질 문제일 수 있습니다. 그 답이 실제 결정이나 행동에 쓰여 사람의 건강, 권리, 재산, 공동체, 기반 시설 또는 환경에 피해를 일으켰는지 확인해야 합니다.

Q2. 피해가 없었으면 아무 기록도 남기지 않아도 되나요?

그렇지 않습니다. 실제 피해가 없더라도 충분히 피해로 이어질 수 있었던 AI 위험 사건이나 근접 사고는 기록할 가치가 있습니다. 작은 신호를 모아 통제를 개선하면 큰 사고를 예방할 수 있습니다.

Q3. AI 사고와 개인정보 유출 사고는 별개인가요?

항상 별개는 아닙니다. AI 기능이 개인정보를 노출했다면 AI 사고이면서 개인정보 침해 사고일 수 있습니다. 각 절차의 담당자, 신고 기준과 기한을 함께 확인해야 합니다.

Q4. 외부 AI API가 원인이면 우리 책임은 없나요?

그렇게 단정할 수 없습니다. 공급자의 모델 변경이나 장애가 원인이어도 우리 제품의 사용 방식, 검증, 안전장치와 고객 대응을 살펴야 합니다. 계약상 통보와 지원 절차도 확인합니다.

Q5. 작은 조직도 AI 사고 대응 계획이 필요한가요?

필요합니다. 복잡한 문서부터 만들 필요는 없습니다. 신고 채널, 중단 권한이 있는 사람, 보존할 로그, 연락할 담당자, 고객 안내 방식과 안전한 대체 절차부터 한 장으로 정리하면 됩니다.

출처

마무리

AI 사고는 AI 시스템이 관련된 모든 이상 현상을 뜻하지 않습니다. AI의 개발, 사용 또는 오작동이 사람과 조직, 권리, 재산, 공동체, 중요 기반 시설이나 환경에 실제 피해를 일으킨 사건입니다. 아직 피해가 생기지 않은 위험 신호와 근접 사고도 따로 기록해야 더 큰 사고를 막을 수 있습니다.

감자나라ai님이 AI 기능이나 자동화를 운영한다면 사고 대응표에 네 가지부터 적어 두세요. 누가 기능을 멈출 수 있는지, 어떤 로그와 버전을 보존할지, 피해 여부를 누가 판단할지, 누구에게 언제 알릴지입니다. 이 네 가지가 정해져 있어야 문제가 생겼을 때 복구와 책임 확인을 동시에 진행할 수 있습니다.