AI 안전 약속을 검증 가능한 보증으로 바꾸는 방법

안전하다는 약속은 아직 안전성 근거가 아니다. 볼커 튀르크가 9월에 경고한 핵심 실무 교훈도 이것이다. 신뢰할 수 있는 보호장치 마련을 미루면 고도 AI가 실존적 위험이 될 수 있다는 것이다. 유엔 인권최고대표는 구속력 있는 규칙, 독립 통제, 분명한 한계를 요구했다. 이는 행동 촉구이지 현재 시스템이 이미 실존적 문턱을 넘었다는 증거는 아니다. 그러나 개발자가 모델을 안전하다고 말하면서도 다른 사람이 그 주장을 확인할 방법을 주지 않는 현재의 문제를 드러낸다.

모든 AI 실패를 문명적 위협으로 취급하거나 정책 문서를 통제의 증거로 받아들이는 것이 답은 아니다. 중요한 약속을 시험 가능한 주장으로 바꾸고, 누가 시험하며 실패 시 무엇을 할지 정해야 한다. 그러면 기술팀, 구매자, 규제기관이 안전을 검토할 수 있다.

반증 가능한 주장부터 시작하기

“시스템은 정렬되었다”는 말은 감사를 하기에는 너무 넓다. 반면 “별도로 인증된 사람의 승인 없이는 에이전트가 결제를 승인하거나, 운영 코드를 변경하거나, 고객 데이터를 내보낼 수 없다”는 말은 검증할 수 있다. 행위, 접근 경로, 이를 막아야 하는 통제가 정해져 있기 때문이다.

AI 위험은 능력과 환경에 모두 좌우된다. 통제된 평가에서 민감한 일을 수행한 모델도 이메일, 저장소, 브라우저 세션, 운영 데이터베이스에 연결되면 다른 위험을 만들 수 있다. 반대로 실험실의 우려스러운 응답만으로 엄격히 제한된 배포가 안전하지 않다고 증명되지는 않는다. 중요한 것은 모델이 무엇을 말하거나 계획하는지가 아니라 도구와 권한으로 실제 무엇을 일으킬 수 있는가다.

영향이 큰 사용처마다 금지 결과, 통제가 의존하는 가정, 필요한 증거를 적어야 한다. 금지 지시 거부 시험, 보호 시스템 접근 통제 시험, 자동화 작업의 롤백 훈련, 다른 통합 경로로 인간 승인을 우회할 수 없다는 기록이 예다. 다른 적격 검토자가 이의를 제기할 수 있을 만큼 증거는 반복 가능해야 한다.

모델 평가와 배포 보증을 구분하기

모델 평가는 정해진 조건에서의 행동을 묻는다. 안전하지 않은 지시를 따르는지, 평가자를 속이는지, 악성 코드를 만드는지, 종료 요청 후에도 지속하는지를 시험할 수 있다. 중요한 시험이지만 배포된 전체 시스템을 설명하지는 않는다.

배포 보증은 다른 질문을 한다. 에이전트가 어떤 자격증명에 도달하는가? 권한은 업무에 한정되는가? 되돌릴 수 없는 행동은 차단되는가? 운영자가 도구 사용을 보고, 빨리 격리하고, 유용한 기록을 보존할 수 있는가? 내부 문서 초안에는 적합한 시스템도 운영 인프라나 금융 흐름에 닿기 전에는 전혀 다른 통제 설계가 필요할 수 있다.

최소 권한은 일반적 체크박스가 아니다. 한 작업에 필요한 최소 도구·데이터·기간 제한 자격증명만 주고, 민감한 시스템은 ID와 네트워크로 분리하며, 되돌릴 수 없는 단계에는 명시적 인간 결정을 요구한다. 강력한 시스템을 무해하게 만들지는 못해도 잘못된 결정과 피해 사이의 간격을 줄인다.

독립성에 실질을 부여하기

독립 검토는 검토자가 관련 증거를 보고, 합의한 방법을 쓰고, 개발자가 선호하는 요약에 의존하지 않고 중요한 한계를 보고할 수 있을 때만 유용하다. 많은 배포 주장에서는 모델 가중치에 무제한 접근하는 것보다 감사 로그, 접근 정책, 시험 환경, 통제된 시연이 더 관련 있다.

범위도 밝혀야 한다. 특정 모델 버전·도구 설정·운영 환경에 대한 결과를 미래 버전이나 새 통합, 더 넓은 사용자 접근에 대한 영구 인증으로 확대해서는 안 된다. 중요한 변경에는 새 평가가 필요하다. 인권이사회는 표준과 정치적 압력의 장이지 연구소에 기술 공개를 강제하는 규제기관은 아니다. 실행 가능한 보증에는 조달 조건, 인가, 책임 또는 사고 보고 의무를 정할 수 있는 기관이 필요하다.

사고를 홍보가 아닌 시스템 시험으로 다루기

신뢰할 만한 안전 프로그램은 보호장치가 실패할 수 있다고 가정한다. 의심 행동 탐지, 시스템 중단 권한자, 접근 철회, 보존할 로그, 피해자 통지와 보호를 정한다. 열화 조건에서 시험해 보지 않은 킬 스위치는 통제가 아니라 주장이다.

사후 검토는 모델이 예기치 않게 행동했는지, 권한이 영향을 가능하게 했는지, 모니터링이 문제를 발견했는지, 사람이 신속하게 행동할 권한이 있었는지를 물어야 한다. 모델 제한, 도구 범위 축소, 승인 단계 추가, 배포 포기로 이어질 수 있다. 민감한 취약점을 공개하지 않고도 교훈을 공개할 수 있지만 모든 실패를 숨기면 외부 보증은 불가능하다.

튀르크의 실존적 위험 언어는 의도적으로 긴급하다. 운영상의 결론은 더 정확하다. 큰 결과를 낳는 AI는 신뢰만으로 나아가서는 안 된다. 배포 전에 한계를 정하고 실제 환경에서 시험하며 독립 검토자에게 충분한 증거를 주고 실패 대응을 출시 결정의 일부로 만들어야 한다. 그래야 안전 약속이 작성자 외의 사람도 검사할 수 있는 보증이 된다.