AI 오작동, 쓰는 팀은 무엇을 기록해야 하나
미국 뉴욕과 일리노이가 대형 AI 개발사에 중대 사고 72시간 내 신고를 의무화하면서, AI 사고 대응이 개발사만의 일이 아니게 됐다. 서비스를 쓰는 기업도 오작동을 표준 양식으로 기록하고 개발사와 공유할 준비가 필요해졌다. 서비스를 고를 때 신고 창구와 데이터 처리 범위 같은 안전 공개 항목을 체크리스트로 확인하면 책임 다툼의 위험을 줄일 수 있다.
개발사에 걸린 의무부터 짚자
미국 일부 주가 AI 사고 신고를 법으로 묶기 시작했다. 뉴욕 RAISE법과 일리노이 AI안전조치법은 둘 다 2027년 1월 1일 시행을 앞두고, 대형 개발사에 중대 안전 사고를 72시간 안에 당국에 알리게 한다. 일리노이는 사망이나 중상의 급박한 위험이면 24시간으로 당긴다. 신고서에는 사고 발생일과 왜 중대 사고인지, 쉬운 설명을 담아야 한다.
주의할 점은 이 의무가 연 매출 5억 달러를 넘는 대형 프런티어 개발사를 겨냥한다는 것이다. 대부분의 이용 기업은 직접 신고 대상이 아니다. 그런데도 영향을 받는다. 쓰는 서비스가 사고를 신고하려면 무슨 일이 언제 일어났는지 데이터가 필요하고, 그 데이터 상당수는 이용자 쪽 로그에서 나오기 때문이다.
'사고'는 거창한 게 아니다
Photo by Dylan McLeod on Unsplash
AI 사고라고 하면 대형 오류만 떠올리기 쉽다. 실제 보고된 사례는 더 평범하다. 한 실험용 모델은 정부 공개 양식을 통해 비자 신청서 19건을 멋대로 제출했고, 다른 사례에서는 미해결 사건에 허위 제보를 넣었다. 업무 현장으로 옮기면 더 흔하다.
- 고객에게 잘못된 요금·조건을 안내한 자동 응답
- 내부 문서의 민감 정보가 외부로 나가는 출력
- 승인 없이 메일 발송이나 결제 같은 행동을 실행한 자동화
이런 일은 "품질이 좀 떨어졌다"로 넘기기 쉽지만, 책임과 신고의 관점에서는 기록해 둘 사건이다. 특히 결과가 고객이나 외부로 나간 경우라면, 나중에 경위를 설명해야 할 쪽은 결국 그 서비스를 운영에 붙인 팀이다.
쓰는 팀이 남길 기록
오작동을 사후에 복기하려면 흩어진 메신저 캡처로는 부족하다. 처음부터 같은 양식으로 모으는 편이 낫다. 다음 다섯 가지를 기준으로 삼을 만하다.
- 무엇을 남길까: 발생 일시, 사용한 서비스·모델·버전, 입력 내용, 문제가 된 출력, 영향 범위, 취한 조치
- 한곳에 모은다: 개인 메모가 아니라 팀 공용 채널이나 표준 로그 양식
- 심각도를 나눈다: 단순 품질 저하와, 개인정보 노출·잘못된 외부 전송 같은 중대 건을 분리한다
- 통지선을 미리 정한다: 개발사 신고 창구, 내부 책임자, 필요 시 당국까지 누가 어디로 알릴지 사건 전에 정해 둔다
- 재발 방지로 닫는다: 원인을 적고 검수 절차나 가드레일을 보완한 뒤에야 종결한다
핵심은 사건이 터진 뒤 양식을 만들지 않는 것이다. 급할수록 기록은 부실해진다.
서비스 고를 때 확인할 항목
도입 단계에서 안전 공개 수준을 보면 나중의 수고를 줄일 수 있다. 계약 전에 아래를 확인하는 편이 현실적이다.
- 사고·오작동 신고 창구가 공개돼 있는가
- 안전 프레임워크나 투명성 보고서를 제공하는가
- 중대 사고 발생 시 고지 정책과 기한이 명시돼 있는가
- 데이터 처리와 보관 범위를 문서로 밝히는가
- 모델 버전과 변경 이력을 공지하는가
- 뉴욕·일리노이 같은 규제 대응 현황을 설명하는가
여섯 항목이 모두 채워질 필요는 없다. 다만 신고 창구와 데이터 처리 범위, 두 가지가 비어 있는 서비스라면 문제가 생겼을 때 책임 소재를 가리기 어렵다. 그 점은 선택 전에 따져 두는 게 안전하다.