Bounded Autonomy for Enterprise AI: Typed Action Contracts and Consumer-Side Execution

1. 문제 제기 (Problem)

LLM 은 사용자의 의도를 해석하고 작업 컨텍스트를 종합하는 데 탁월하지만, 직접적인 시스템 운영자 (System Operator) 로서 사용할 경우 심각한 위험을 초래합니다.

• 주요 위험: 모델의 오류 (할루시네이션, 잘못된 엔티티 식별, 권한 오해석 등) 가 그대로 실행되어 권한 없는 작업 수행, 잘못된 데이터 생성, 워크스페이스 간 데이터 유출, 되돌릴 수 없는 비즈니스 변경 등으로 이어질 수 있습니다.
• 기존 접근법의 한계: 현재 많은 도구 기반 AI 설계는 프롬프트 엔지니어링, 사후 모니터링, 또는 더 강력한 모델에 의존하는 방식을 취합니다. 그러나 이는 모델이 백엔드 실행에 너무 직접적으로 접근하게 만들어, 가장 중요한 '실행 제어' 문제를 해결하지 못합니다.

2. 방법론 및 아키텍처 (Methodology & Architecture)

저자들은 제한적 자율성 (Bounded Autonomy) 아키텍처를 제안하며, 이는 **BAL (Bounded Autonomy Layer)**이라는 이식 가능한 AI 중재 계층을 통해 구현됩니다.

핵심 설계 원칙

1. 타입화된 액션 계약 (Typed Action Contracts): 모든 실행 가능한 기능은 기업 애플리케이션이 정의한 타입화된 계약 (입력 스키마, 권한 조건, 유효성 검사 로직, 실행 콜백 등) 으로 표현됩니다. 모델은 이 계약만 볼 수 있습니다.
2. 권한 인식 기능 노출 (Permission-Aware Capability Exposure): BAL 은 현재 사용자의 권한에 따라 허용된 액션의 하위 집합 (Granted Actions) 만 모델에게 노출합니다.
3. 소비자 측 실행 권한 (Consumer-Side Execution Authority): 모델은 계획을 수립할 수 있지만, 실제 실행 (Side Effects) 은 기업 애플리케이션의 코드 경로 (백엔드 서비스, API 레이어) 를 통해 이루어집니다. BAL 은 백엔드에 직접 접근하지 않습니다.
4. 사이드 효과 전 유효성 검사 (Validation Before Side Effects): 실제 데이터 변경 전에 스키마 및 도메인 유효성 검사를 수행합니다.
5. 명확한 모호성 처리 (Explicit Ambiguity Handling): 엔티티 식별이 불확실할 경우 (예: 이름이 같은 여러 고객), 모델을 대신 추측하게 하지 않고 사용자에게 명확화 (Clarification) 를 요청합니다.
6. 확인 게이트 (Confirmation Gates): 고위험 워크플로우의 경우 실행 전 사용자의 명시적 승인을 받습니다.
7. 명시적 매니페스트 (Manifest Governance): 모델이 접근할 수 있는 기능 목록은 명시적으로 발행된 매니페스트에 기반하며, 숨겨진 기능은 접근할 수 없습니다.

실행 흐름

사용자 요청 $\rightarrow$ BAL (의도 해석, 권한 필터링, 유효성 검사, 모호성 해결, 승인 요청) $\rightarrow$ 승인된 액션 $\rightarrow$ 기업 애플리케이션 (기존 비즈니스 로직 및 권한 시스템 통과) $\rightarrow$ 실행.

3. 주요 기여 (Key Contributions)

1. 설계 원칙 정의: 기업용 AI 시스템에서 LLM 을 '신뢰할 수 있는 직접 운영자'가 아닌 '계획가 및 해석자'로 제한하는 제한적 자율성 개념을 정의했습니다.
2. BAL 프레임워크 개발: 어떤 기업 애플리케이션에도 통합 가능한 이식 가능한 AI 중재 계층 (BAL) 을 구현했습니다. 이는 권한 필터링, 타입별 유효성 검사, 확인 게이트 등을强制执行합니다.
3. 실제 배포 및 평가: 다중 테넌트 기업용 CRM 애플리케이션에 이 아키텍처를 배포하고, 3 가지 조건 (수동 운영, 안전 계층 비활성화된 AI, 전체 제한적 자율성 시스템) 하에서 실험을 수행했습니다.
4. 실증적 결과 제시: 안전 계층을 제거했을 때 오히려 작업 완료율이 떨어지고 안전 사고가 발생했음을 입증하여, 안전 메커니즘이 단순한 제약이 아니라 유용성 (Utility) 을 향상시키는 요소임을 보였습니다.

4. 실험 결과 (Results)

25 가지 시나리오 (7 가지 실패 유형군) 에 대한 평가 결과:

• 안전성 (Safety):

  • 제한적 자율성 (Condition C): 25 개 작업 중 23 개 성공, 0 건의 안전 사고 (Unsafe Execution). 실패한 2 건은 모호성 해결 중이거나 승인 대기 상태로 안전하게 차단되었습니다.
  • 제약 없는 AI (Condition B, 안전 계층 비활성화): 25 개 중 17 개 성공, 2 건의 안전 사고 발생 (잘못된 엔티티에 데이터 수정). 나머지 6 건은 일반적 오류로 인해 모델이 복구하지 못하고 실패했습니다.
  • 결론: BAL 계층 (D1-D3) 이 모든 안전 위반을 차단했습니다. 특히 백엔드 권한 시스템이 구조적으로 놓칠 수 있는 '권한은 있지만 잘못된 대상 (Wrong-Entity)' 수정 오류를 BAL 의 모호성 해결 및 확인 게이트만 차단할 수 있었습니다.

• 유용성 및 효율성 (Utility & Efficiency):

  • 작업 완료율: 제한적 자율성 (92%, 23/25) 이 제약 없는 AI (68%, 17/25) 보다 높았습니다. 안전 계층이 모델에게 구조화된 피드백을 제공하여 자가 수정을 유도했기 때문입니다.
  • 속도: 수동 작업 대비 두 AI 조건 모두 13~18 배 속도 향상을 보였습니다. 안전 계층이 있는 조건이 안전 계층이 없는 조건보다 작업당 약 1.5 초 더 느렸으나, 전체적인 성공률은 훨씬 높았습니다.
  • 상호작용: 안전 계층이 있는 경우 모델이 구조화된 오류 메시지를 받아 1~2 턴 내에 해결했으나, 없는 경우 일반적 오류로 인해 3 번 이상의 재시도 (할루시네이션 포함) 가 필요했습니다.

• 방어 심층 (Defense in Depth):

  • BAL 계층이 우회되었을 때, 기업 애플리케이션의 백엔드 계층이 일부 오류를 차단했으나, '잘못된 대상 수정'과 같은 특정 실패 유형은 모든 백엔드 계층을 통과하여 데이터 손상을 일으켰습니다. 이는 BAL 이 필수적임을 입증합니다.

5. 의의 및 결론 (Significance & Conclusion)

• 패러다임 전환: 기업용 AI 의 안전 문제는 모델의 지능 향상 (Model Quality) 이 아니라 **실행 아키텍처 (Execution Architecture)**의 문제임을 입증했습니다.
• 안전과 유용성의 상충 관계 해소: 기존의 통념과 달리, 안전을 위한 제약 (검증, 승인 등) 이 모델의 자가 수정 능력을 도와 전체적인 작업 성공률을 높이는 결과를 낳았습니다.
• 실용적 아키텍처: 이 아키텍처는 LLM 이 백엔드 데이터베이스에 직접 접근하지 않고, 기업 애플리케이션이 정의한 '계약'을 통해 실행되도록 함으로써, 불완전한 모델이라도 기업 시스템에서 안전하게 운영할 수 있는 실질적인 해결책을 제공합니다.
• 미래 방향: 콘텐츠 가드레일 (Content Guardrails) 이나 툴 접근 정책 (Tool Access Policies) 과는 별개로, 실행 계층의 거버넌스를 담당하는 필수적인 레이어로 자리 잡을 것으로 기대됩니다.

이 연구는 불완전한 AI 모델을 기업 환경에 안전하게 통합하기 위해, 모델의 자유를 무제한으로 두기보다는 구조적으로 통제된 자율성을 부여하는 것이 더 효과적이고 안전한 전략임을 실증적으로 증명했습니다.