AI의 외부 조작을 멈추고, 확인하고, 되돌릴 수 있도록 만들었다

본고는 Responsibility Pathway Runtime (RPR)을 소개하는 2부 구성의 전편이다. 전편에서는 왜 RPR을 만들었는지, 책임 경로(Responsibility Pathway)라는 개념으로부터 현재의 제품 구성이 어떻게 탄생했는지를 설명한다.

AI 에이전트에게 파일 업데이트나 API 조작을 맡긴다.

인간이 내용을 확인하고 AI가 쓰기를 시작했다. 그 직후 통신이 끊겼다.

성공했는지, 실패했는지 알 수 없다.

다시 보내면 중복 등록이 될지도 모른다. 실패로 처리하고 닫으면 이미 반영된 변경 사항을 놓치게 된다. 성공으로 처리하고 닫으면 증거 없는 완료 기록이 남는다.

"중요한 조작은 인간이 확인한다", "조작 이력을 남긴다"는 것만으로는 이 상황을 안전하게 다룰 수 없다.

필요한 것은 조작 전에 멈출 수 있는 것, 실행한 사실과 외부에서 일어난 결과를 분리하여 남기는 것, 결과를 모르는 상태로 유지하는 것, 외부 상태를 다시 읽어 확인하는 것, 복구와 재개의 담당자를 잃지 않는 것이다.

Responsibility Pathway Runtime (RPR)은 AI 에이전트나 자동화 시스템의 외부 조작을 권한, 승인, 실행 이력, 증거, 결과 불명, 대조, 복구, 재개, 남은 영향의 인수 대상까지 포함하는 「책임 경로 (Responsibility Pathway)」로 통과시키는 AI 거버넌스/어슈어런스 (Assurance)용 Python Runtime이다.

RPR은 MIT 라이선스의 오픈 소스로 공개되어 있다. 상태 전이는 JSON으로 공개하며, 선택한 불변 조건(Invariant)을 Lean 4로 검사할 수 있는 형식 자산(Formal Asset)도 동봉했다.

제품 페이지, 브라우저에서 실제 RPR을 구동하는 데모, 공개 소스는 여기서 확인할 수 있다.

어떤 고민을 다루는가

RPR은 개별 기능을 나열하는 것에 그치지 않고, 다음의 질문들을 하나의 경로로 연결한다.

누구의 권한으로 실행하는가. 어디서 멈출 것인가. 무엇을 증거로 완료할 것인가. 알 수 없는 결과를 어떻게 남길 것인가. 누가 복구하고 어떤 조건에서 재개하며, 마지막에 누구에게 판단을 돌려줄 것인가.

이 일련의 과정을 나는 「책임 경로 (Responsibility Pathway)」라고 부른다.

왜 이런 구성이 되었는가

RPR은 처음에 Human Gate나 감사 로그를 나열하여 설계한 제품이 아니다.

내가 기점으로 삼은 것은 이전에 발표했던 다음의 정의였다.

책임이란, 행위로 인해 상실된 가역성 (Reversibility)의 잔량이다.

이 정의를 수치나 단일 스코어로 구현한 것은 아니다.

책임을 가역성으로 생각했을 때, 외부 조작을 수행하는 시스템에 무엇이 필요할지를 분해했다.

이 분해를 구현한 결과, RPR은 정지, 확인, 대조, 복구, 재개, 남은 영향의 인수 대상을 가진 상태 머신 (State Machine)이 되었다.

RPR은 「가역성의 잔량」을 계량하는 제품이 아니다. 책임을 가역성으로 생각한 결과, 필요해진 실행 시점의 구조를 제품화한 Runtime이다.

책임 경로에서 RPR까지

나(오노 아키히사)가 제창하고 정의한 「책임 경로 (Responsibility Pathway)」는 AI, 인간, 조직, 업무 시스템 사이에서 책임이 끊기지 않고 이어지도록 하기 위한 설계 개념이다.

나는 이 개념을 다음의 계열로 전개하고 있다.

책임 경로 (Responsibility Pathway)
↓
책임 경로 모델 (Responsibility Pathway Model)
...

다루는 것은 AI나 자동 처리가 외부로 작용할 때의 실행 경로이다.

AI / planner / agent framework
↓
실행 후보 조작
...

「처리가 끝났다」와 「변경할 수 있었다」는 다르다

함수가 정상적으로 종료되었다는 것과 외부 상태가 기대한 대로 변경되었다는 것은 같지 않다.

API가 200을 반환하더라도 대상 데이터가 저장되지 않았을 수도 있다. 송신 함수가 반환되더라도 외부 서비스에 기록이 남아있지 않을 수도 있다.

A callback is not proof of an external effect.

RPR은 외부 결과를 독립적으로 확인할 수 없는 경우, 추측만으로 completed로 진행하지 않는다.

확인할 수 없다면 결과 불명(unknown)으로 처리하고 멈춘다. 외부 상태를 다시 읽어 성립 여부를 확인한다. 필요하다면 인간에게 판단을 요청한다.

이 "모르는 채로 닫지 않는다"는 원칙이 RPR의 핵심에 있다.

Lean 4를 제품에 통합했다

책임 경로(responsibility path)를 상태와 전이(transition)로 구현했다면, 그 경로가 의도치 않게 생략되지 않는지도 검사하고 싶다.

RPR에는 Python Runtime, JSON으로 공개된 상태 머신(state machine), Lean 4 형식 모델(formal model)이 포함된다.

Lean 4로 검사하는 것은 공개된 상태 전이와, 그로부터 선택한 불변 조건(invariant)이다.

이것이 현실 세계의 안전, 법령 준수, 조직 판단의 타당성, 외부 서비스 전체의 올바름을 증명하는 것은 아니다.

중요한 것은, 무엇을 형식화(formalize)하고, 무엇을 검사하며, 무엇을 대상 외로 두었는지를 제삼자가 확인할 수 있다는 점이다.

브라우저에서 실물을 구동할 수 있다

공개 데모는 JavaScript로 상태 전이만 그린 모크(mock)가 아니다.

GitHub Actions가 공개된 소스로부터 RPR의 wheel을 만들고, 그 wheel을 브라우저 내의 Python 환경(Pyodide)으로 불러온다.

브라우저 내부에서는 실제 RPR, SQLite 저장, 실행 이력, 결과 불명, 재시작 후 읽기(read-back), 외부 상태와의 대조, 증거 체인(evidence chain) 검증이 작동한다.

안전을 위해 외부 결제 서비스만 테스트용 처리로 대체되어 있다.

데모에서는 외부 서비스에 대한 실행 횟수가 1회인 상태로 completed로 진행된다. 결과 불명 이후에 동일한 조작을 재전송하지 않고도 복구할 수 있음을 확인할 수 있다.

왜 오픈 소스로 만들었는가

책임을 다루는 기반이 검사할 수 없는 블랙박스여서는 안 된다.

RPR은 상태 전이, 증거의 경계, 실패 경로, Python 구현, Lean 4 형식 자산, 테스트, 도입 자료를 공개하고 있다.

현재는 MIT License의 Public Alpha 단계이며, 완성된 만능 기반이 아니다. 대규모 본산 운영, 안전성, 법령 준수, 조직 판단의 타당성을 보장하는 것도 아니다.

또한, 최종 tag, GitHub Release, package registry로의 배포는 소스 및 웹 공개와는 별개의 판단으로서 아직 실시되지 않았다.

그럼에도 불구하고, AI 거버넌스나 어슈어런스(assurance)를 문서로만 끝내지 않고, 실제로 멈추고, 확인하고, 수리하며, 인간에게 돌아가는 경로로서 작동할 수 있는 수준까지 만들었다.

거버넌스를 설명하는 문서가 아니라, 거버넌스를 실행 시점에 작동시키는 Runtime을 만들었다.

그것이 RPR이다.

후편에 대하여

후편에서는 RPR의 구체적인 기능, 상태, 도입 범위, 검증된 범위, 실제로 시도하는 방법을 설명한다. 후편 공개 후 이 위치에 링크를 추가할 예정이다.

Discussion