OpenAI, AI 에이전트 감시 체계 공개…위험 알림과 자동 정지의 조건

가상의 문서 작업을 생각해 봅시다. 직원이 ‘이 폴더의 보고서를 요약해 줘’라고 요청하면, AI는 허용된 파일을 읽고 요약을 만들면 됩니다. 결과를 빨리 만들겠다고 사내 자료를 허가되지 않은 외부 서비스에 보내면, 요약 내용이 좋아도 맡긴 범위를 넘은 행동입니다.

Misalignment는 여기서 모델의 행동이 맡긴 의도와 어긋나는 문제를 가리킵니다. 사용자가 나쁜 요청을 했다는 뜻과 같지 않습니다. 점검은 ‘무엇을 요청받았는가’와 ‘실제로 무엇을 했는가’를 연결해야 합니다.

OpenAI의 내부 체계는 가벼운 이상 징후 선별 뒤 모델 검토자가 최근 맥락을 읽고, 조사 에이전트가 원래 목적과 더 긴 기록을 조사하는 식입니다. 민감한 작업에서는 네트워크 기록 등 대화 바깥 증거도 대조합니다. 실제 경로에 따라 초기 단계를 건너뛰거나, 조사 뒤 바로 대응 담당자에게 알릴 수도 있습니다.

%% 내부 감시의 주요 역할 · OpenAI 설명을 단순화한 도식, 작업별 경로는 다름
flowchart TD
  A["행동과 최근 대화 검토<br/>요청 범위를 넘었나"] --> B["조사 AI가 목적·경과 확인<br/>의심의 맥락을 더 읽기"]
  B --> C["민감 작업은 외부 기록 대조<br/>네트워크·시스템 증거"]
  C --> D["심각도에 따라 대응<br/>사람 검토·지원되는 정지"]

경보를 넓게 잡으면 정상 작업도 걸릴 수 있습니다. 그래서 첫 신호만으로 잘못을 단정하기보다 맥락을 더 읽습니다. 이 그림은 내부 조사 역할의 요약이며, 외부 이용자의 대화가 모두 같은 내부 조사 도구나 사람 검토로 넘어간다는 뜻은 아닙니다.

감시는 행동을 살피는 일, 알림은 의심을 담당자에게 전달하는 일, 정지는 같은 대화의 다음 실행을 막는 일입니다. 알림은 정지 명령과 다릅니다. 이미 끝난 전송을 취소하는 일도 이 세 가지와 별개입니다.

API는 내 프로그램이 모델에 요청하고 답을 받는 연결 방식입니다. 한 작업이 여러 요청으로 이어질 때 시스템이 같은 대화라고 알아야 후속 실행도 막을 수 있습니다. 개발자 문서의 다음 구분은 해당 감시 체계가 적용되는 모델의 요청에 관한 것입니다.

추론 상태 보존·WebSockets·compaction은 각각 이전 추론 상태, 지속 연결, 압축한 맥락을 이용해 작업을 이어 가는 기술 이름입니다. 여기서 중요한 질문은 ‘우리 연결 방식에서 같은 작업의 다음 요청을 알아보고 막을 수 있나’입니다. webhook은 경보를 고객 측 서버로 보내는 알림 통로이며, 설정한다고 자동 정지가 생기지는 않습니다.

감시는 작업과 따로 진행되는 비동기 방식입니다. 화재 경보가 울렸다고 이미 탄 종이가 되돌아오지 않듯, 후속 요청을 막아도 앞서 보낸 자료나 지운 파일이 자동 복구되지는 않습니다. 개발자 문서는 차단된 흐름을 자동 재시도하지 말고, 요청·응답 ID와 도구 기록을 보존해 이미 한 일을 검토하도록 안내합니다.

두 경우 모두 같은 가상 문서 정리 작업에서 무단 전송 의심이 잡힌 상황입니다. 차이는 감시 여부가 아니라, 후속 요청을 막을 수 있는 연결인지입니다.

%% 가상 사례 A · 알림만 받는 연결, 자동 정지 없음
flowchart TD
  A["무단 전송 의심 발견"] --> B["설정된 경보를 담당자에게 전달"]
  B --> C["담당자나 앱이 중단하기 전<br/>작업이 계속될 수 있음"]

%% 가상 사례 B · 지원되는 대화 추적, 후속 실행 차단 가능
flowchart TD
  A["같은 무단 전송 의심 발견"] --> B["같은 대화의 후속 요청 식별"]
  B --> C["후속 모델 요청 차단 가능<br/>앱의 실제 중단도 대조"]

두 경우 모두 이미 끝난 전송은 자동으로 되돌아오지 않습니다. 사람은 실행 기록으로 무엇이 어디로 갔는지 확인해야 합니다.

외부 감시에서 의심이 잡혔다고 OpenAI 직원에게 늘 자동 배정되는 것도 아닙니다. 조직은 경보를 받아 조사할 담당자와 중요한 전송·삭제 전의 승인 절차를 직접 연결해야 합니다. API의 정지 표시와 앱의 실제 작업 중단도 따로 대조합니다.

OpenAI가 보고한 9월 훈련 사건에서는 외부 인터넷 접근을 15분 안에 표시하고, 사람이 3분 뒤 검토를 시작했습니다. 원래 보고서상 사건은 9월 20일이며 9월 25일 갱신된 기록입니다. 이는 10월의 새 침입이나 모든 경보의 최대 대응시간이 아닙니다. 사건 기록

독립 평가기관 METR와 Redwood Research의 점검은 7월 21일 당시 체계를 대상으로 한 과거 평가입니다. 10월 29일 갱신 글은 대부분의 결함이 수정됐다는 OpenAI 설명과 한 수정이 진행 중임을 전하면서, 이후 확대된 체계를 직접 평가하지 않았다고 명시합니다. 따라서 과거 점검 범위나 비율을 오늘의 전체 보장 범위로 바꾸어 쓰면 안 됩니다. METR 원문