개요
Safety Evaluation은 AI 시스템이 어떤 조건에서 위험한 행동이나 능력을 보이는지 체계적으로 측정하는 평가 영역이다. 일반적인 정확도나 지식 평가와 달리, 악용 가능성·기만·사이버 능력·자율적 행동처럼 배포 위험과 연결되는 실패 모드를 별도로 정의하고 테스트할 수 있다.[1]
위험 능력 평가의 예
Google DeepMind 연구진은 고성능 모델에 대해 설득과 기만, 사이버 보안, 자기 증식, 자기 추론 등 위험과 관련된 능력을 측정하는 평가 프로그램을 제시하고 Gemini 계열 모델에 시험 적용했다.[1] 이런 평가는 모델이 실제 피해를 일으킬 것이라고 단정하는 도구가 아니라, 위험을 가능하게 하는 능력의 존재 여부와 경향을 조기에 점검하는 수단이다.
다른 평가와의 관계
MMLU나 HELM이 일반적인 능력과 여러 품질 차원을 비교하는 데 초점을 둔다면 Safety Evaluation은 위험 시나리오와 실패 조건을 명시하는 데 초점을 둔다. Red Teaming은 예상하지 못한 실패를 찾는 탐색적 수단으로 결합할 수 있고, 평가 범위·결과·남은 제한은 System Card에 기록해 배포 판단의 근거를 남길 수 있다.
모델의 능력과 시스템의 위험
모델이 과제를 수행할 수 있다는 관찰과, 특정 서비스에서 실제 피해가 발생할 위험은 구분해야 한다. 같은 모델이라도 연결된 도구, 접근 권한, 사용자와 사용 환경에 따라 평가할 시스템의 범위가 달라진다. NIST AI RMF는 사용 맥락과 시스템 구성 요소를 먼저 정의하고, 배포와 비슷한 조건에서 평가하며, 운영 중에도 위험을 측정하도록 제시한다.[2] AI Agent를 평가할 때도 답변뿐 아니라 도구를 통해 수행하는 행동과 사람의 감독 범위를 함께 살펴야 한다.
평가 결과에서 확인할 것
다음은 NIST의 맥락 정의·측정·운영 관리 원칙을 평가 보고서를 읽는 질문으로 정리한 것이다.[2]
- 대상과 조건: 어떤 모델·시스템 버전, 데이터, 도구와 사용 환경을 시험했는가?
- 판정 기준: 어떤 실패를 세었고, 어떤 시험 방법과 지표를 사용했는가?
- 불확실성과 범위: 결과가 어느 조건에 적용되며, 시험하지 못한 위험과 일반화의 한계는 무엇인가?
- 후속 조치: 발견한 문제를 어떻게 줄였고, 수정 후 재검증과 운영 중 감시는 어떻게 하는가?
문서에 평가 조건이 없거나 한 번의 점수만 제시되면 실제 배포 환경으로 해석을 넓히기 어렵다. 모델의 목적과 한계는 Model Card, 결합된 서비스의 평가·보호 조치는 System Card와 연결해서 읽을 수 있다.
안전성 주장과 근거를 연결하기
안전성 논증(safety case)은 특정 사용 환경에서 시스템의 위험이 관리된다는 주장을 근거와 연결해 설명하는 구조다. AISI는 실험 결과뿐 아니라 보호 조치가 작동하는 이유, 레드팀에서 얻은 관찰, 배포 환경과 조직에 관한 근거를 함께 고려한다.[3] 따라서 레드팀에서 실패를 찾지 못했다는 사실 하나가 모든 위험이 없다는 증명은 아니다.
예를 들어 도구를 사용하는 AI가 승인된 작업 범위를 지킨다는 주장을 평가한다면, 어떤 권한과 감독 조건에서 관찰했는지와 그 조건이 달라질 때의 한계를 함께 적어야 한다. 이는 위 원칙을 설명하는 예시이며, 특정 제품이 해당 평가를 통과했다는 뜻은 아니다.
2026년 9월의 외부 평가 논의
OpenAI는 2026년 9월 22일 제3자 평가 원칙을 발표했다. 안전성 논증, 핵심 보호 장치, 위험 역량·정렬 평가, 중대한 정렬 실패 사건을 평가 대상으로 제시하고, 평가 범위와 주장, 접근 권한, 방법과 불확실성, 이해충돌 및 보안 책임을 명확히 하도록 제안했다.[4]
외부 기관이 참여했다는 사실과 평가의 독립성·충분한 검증 범위는 각각 확인할 사항이다. 무엇을 검증했고 무엇을 제외했는지, 평가자와 개발사의 관계 및 공개 가능한 근거가 무엇인지 읽어야 한다. 위 발표는 회사가 제안한 원칙이며 특정 모델에 대한 포괄적 안전 인증을 의미하지 않는다.[4] 기업별 사례는 OpenAI와 Anthropic, 모델 발표의 평가 조건을 읽는 예시는 Claude 문서로 이어진다.
허용 작업과 실패 사건을 먼저 정의하기
가상의 문서 도우미가 비공개 초안을 저장할 수 있지만 승인 없이 공개 발행할 수는 없다고 하자. 허용 사용자·자료·도구와 기대 결과를 먼저 적고, 실제 발행 대신 모의 도구와 NOTE-TEST-1 같은 비밀이 아닌 시험 표식을 사용한다. 시도한 행동·차단된 행동·실제 완료된 행동을 구분해야 문장만 보고 권한 경계를 판단하는 오류를 줄일 수 있다.
위험 역량 평가 연구 ↗는 위험을 가능하게 하는 모델 능력을 조사했다.[1] 능력이 있다는 관찰과 특정 서비스에서 피해가 발생한다는 주장은 다르다. 권한·감독과 시스템 구성을 연결하고 허가된 격리 시험에서 실제 비밀이나 불필요한 사용자 자료를 사용하지 않는다.
계산 예제: 거절률과 정상 요청 오차단률
다음은 가상 이진 정책 시험이다. 금지 요청 20개 중 16개를 차단하고 4개를 놓쳤으며, 정상 요청 80개 중 8개를 잘못 차단하고 72개를 허용했다. 총 거절은 24 / 100 = 24%지만 금지 요청 차단 비율은 16 / 20 = 80%, 정상 요청 오차단률은 8 / 80 = 10%다. 정해 둔 판정과 일치한 것은 (16 + 72) / 100 = 88%다.
거절을 더 많이 했다는 사실만으로 더 안전하고 유용해졌다고 결론 내리지 않는다. NIST AI RMF ↗가 다루는 맥락·측정·관리와 연결해 실패의 정의, 분모, 영향도와 정상 작업의 완료를 기록한다.[2] 위 요청 구성과 기준은 설명용이며 실제 사용자 분포나 제품의 안전성 점수가 아니다.
실패 0회가 실패 확률 0을 뜻하지 않는 이유
독립적이고 동일한 실패 확률 p를 가진 가상 이항 시험 100회에서 실패를 한 번도 못 볼 확률은 (1 - p)^100이다. 이를 0.05로 놓고 풀면 p = 1 - 0.05^(1/100) = 약 2.95%다. 실패 0/100을 관찰했을 때 이런 가정 아래의 한쪽 95% 정확 이항 신뢰상한을 설명하는 계산이다. NIST 통계 안내 ↗는 비율의 신뢰구간과 실패가 적을 때의 이항 방법을 설명한다.[5]
이는 서비스가 2.95%까지 실패해도 된다는 기준이나 실제 사고 확률이 아니다. 빈도주의 신뢰구간을 p가 95% 확률로 그 안에 있다는 사후 확률로 해석하지 않는다. 적응적으로 고른 공격, 서로 연관된 시험과 바뀐 입력 분포는 위 가정을 충족하지 않을 수 있다. 표본·선정 방법·판정·불확실성을 함께 남긴다.
수정·배포 뒤에도 주장과 구성 버전을 연결하기
모델, 지시, 검색 자료, 접근 필터나 쓰기 도구가 달라지면 어떤 위험 주장과 근거가 영향을 받는지 표시한다. 저장해 둔 실패 사례의 회귀 시험과 별도로 준비한 새 입력을 구분하고, 정상 요청이 과도하게 막히지 않는지도 확인한다. 제외한 언어·권한·도구와 남은 실패를 보고서에서 숨기지 않는다.