Otari AI 거버넌스: Mozilla AI, 하나의 게이트웨이에 모델 선택과 에이전트 제한 통합

Mozilla AI는 11월 4일 Otari AI 거버넌스 접근 방식을 공개하며 모델 선택을 에이전트 도구 및 지출 제한과 함께 제시했다. 회사는 Otari를 거버넌스를 위한 운영 체제라고 설명하지만, 제품 자체는 오픈 소스 게이트웨이다. 게이트웨이는 애플리케이션과 AI 서비스 사이에 위치하며, 요청을 라우팅하고 규칙을 적용할 공통 지점을 제공한다.

이 제안은 현실적인 충돌을 다룬다. 팀은 모델을 바꾸는 자유를 원하지만, 그 주변의 통제를 다시 구축하고 싶어 하지는 않는다. Mozilla AI는 Otari가 워크스페이스 권한, 예산 확인 및 사용량 가시성을 결합한다고 말한다. 이는 각 애플리케이션이 자체 공급업체 연결과 안전장치를 유지하는 방식에 부담을 준다.

Otari는 LiteLLM처럼 중앙 집중식 접근 및 지출 통제를 이미 제공하는 대안이 있는 기존 범주에 진입한다. 관련된 질문은 에이전트가 다음 행동과 다음 유료 요청을 모두 선택할 수 있을 때 권한이 어디에 있어야 하는가다.

Otari AI 거버넌스, 모델 선택과 권한을 함께 관리하다

Mozilla AI는 모델 접근과 에이전트 권한을 동일한 인프라 결정의 일부로 제시하고 있다.

Mozilla AI는 AI 거버넌스 발표에서 허용 모델, 웹 검색, 코드 실행 및 필수 확인 절차를 포괄하는 워크스페이스 규칙을 설명한다. 회사는 플래그가 지정된 요청을 공급업체에 도달하기 전에 차단할 수 있다고 말한다. 예산은 사용자와 애플리케이션 키에 연결되며, 애플리케이션 키는 애플리케이션이 게이트웨이에 접근할 때 사용하는 자격 증명이다.

이러한 기능은 제품이 의도한 경계를 설정한다. 개발자는 공통 접근 지점을 중심으로 애플리케이션을 구축할 수 있고, 관리자는 해당 애플리케이션이 사용할 수 있는 서비스를 결정한다. 모델 변경과 에이전트에 다른 기능을 부여하는 일은 서로 연관된 결정이 된다.

모델의 답변과 에이전트의 권한은 서로 다른 책임을 만들기 때문에 이 구분은 중요하다. 부정확한 초안은 편집이 필요할 수 있다. 부정확한 행동은 기록을 변경하거나, 정보를 노출하거나, 누군가 결과를 검토하기 전에 추가 작업을 시작할 수 있다.

공유 게이트웨이는 조직이 모델과의 대화 밖에서 제한을 표현할 장소를 제공한다. 이는 최종 접근 결정을 내리는 주체를 바꾼다. 애플리케이션은 기능을 요청할 수 있지만, 인프라는 그 요청을 거부할 수 있다.

승인된 문서를 사용해 답변 초안을 작성하는 가상의 고객 지원 어시스턴트를 생각해 보자. 배정된 작업이 제한 없는 브라우저나 실행 환경에 대한 접근을 자동으로 정당화하지는 않는다. 그러한 기능은 관련 없는 작업의 성능을 높이더라도 별도의 근거가 필요하다.

이 사례는 자율성 논의에서 흔히 나타나는 모호함도 드러낸다. 에이전트에 더 유용한 정보를 제공하는 일은 더 많은 행동을 허용하는 일과 다르다. 제품은 고객 기록을 수정할 권한을 얻지 않고도 더 나은 문서를 통해 더 유용해질 수 있다.

Otari가 무엇인지 묻는 독자에게 유용한 답은 따라서 아키텍처에 관한 것이다. 이는 AI 애플리케이션 전반의 접근 결정을 조율하는 장소이며, Mozilla AI는 거버넌스와 공급업체 선택을 함께 배치하고 있다.

운영 체제라는 표현은 여전히 비유다. 구매자는 이를 Otari가 조직의 AI 활동 모든 부분을 관리한다는 증거가 아니라 조율에 관한 주장으로 해석해야 한다. 데이터 접근, 애플리케이션 동작 및 비즈니스 승인은 여전히 명확한 책임자가 필요하다.

11월 발표는 제품 방향에 대한 설명으로 이해하는 것이 가장 적절하다. 이는 Mozilla AI가 팀이 무엇을 통제하고 그러한 통제가 어디에 위치하기를 원하는지 설명한다. 안전성, 신뢰성 또는 운영 비용의 독립적으로 측정된 개선을 입증하지는 않는다.

실질적인 변화는 애플리케이션 팀과 플랫폼 소유자 사이의 더 명시적인 계약이다. 개발자는 인터페이스를 통해 접근을 요청하고, 관리자는 허용 범위를 정의한다. 이 계약이 유지되는지는 애플리케이션이 실제로 사용하는 경로에 달려 있다.

플랫폼 팀은 에이전트가 소유할 수 없는 결정을 떠안는다

접근을 중앙화하면 책임이 더 분명해지지만, 각 워크플로가 무엇을 받을 자격이 있는지는 여전히 누군가가 정의해야 한다.

즉각적인 부담은 플랫폼 엔지니어, 보안 팀 및 애플리케이션 소유자에게 돌아간다. 이들은 “AI를 책임감 있게 사용하라”는 폭넓은 지침을 자격 증명, 허용 서비스, 지출 및 검토에 관한 결정으로 옮겨야 한다.

Mozilla AI의 이전 에이전트 인프라 논지는 지침과 제약의 차이를 구분한다. 작성된 규칙은 에이전트가 어떻게 행동해야 하는지 알려준다. 강제되는 제한은 에이전트가 실제로 무엇을 할 수 있는지 결정한다.

이 구분은 워크플로가 외부인이 제공한 자료를 다룰 때 중요한 결과를 낳는다. 프롬프트 인젝션은 콘텐츠가 단순히 정보를 제공하는 대신 모델의 행동을 바꾸려 시도하는 것을 뜻한다. 따라서 지원 티켓, 검색된 문서 또는 웹페이지는 원치 않는 지시의 원천이 될 수 있다.

인프라 제한은 모델이 모든 악의적 구절을 인식할 것을 요구하지 않는다. 워크플로에 특정 기능을 사용할 권한이 없다면, 모델의 판단이 실패하더라도 그 경계는 여전히 유효할 수 있다.

OWASP의 과도한 에이전시 지침은 과도한 기능, 권한 및 자율성을 피해를 유발하는 행동의 별도 원인으로 지목한다. 권고 사항에는 도구 제한, 하위 시스템 권한 축소 및 중요한 작업에 대한 승인 요구가 포함된다.

이는 Otari에 대한 보증이 아니라 독립적인 보안 지침이다. 모델의 판단 밖에 제한을 배치해야 하는 근본적 이유를 뒷받침한다. 또한 게이트웨이가 더 폭넓은 권한 시스템에 어떻게 맞아야 하는지도 보여준다.

공개 자료를 검색하고 결과를 요약할 수 있는 리서치 어시스턴트를 상상해 보자. 소유자는 웹 접근을 합리적으로 승인하면서도 결론을 외부에 게시할 권한은 보류할 수 있다. 정보를 찾는 일과 조직을 대표하는 일은 서로 다른 책임이다.

중앙 통제 지점은 이 차이를 드러내는 데 도움이 된다. 그러나 조직의 정책을 결정하지는 않는다. 어시스턴트가 어떤 정보에 접근할 수 있는지, 어떤 출력물에 검토가 필요한지, 예외를 누가 처리하는지는 여전히 누군가가 정해야 한다.

지식 근로자에게 이는 개인 지식 베이스와 공유 조직 리소스의 구분과 직접 연결된다. 유용한 검색이 더 광범위한 접근이나 행동 권한을 자동으로 정당화하지는 않는다.

따라서 애플리케이션 소유자에게 가해지는 요구는 구체적이다. 권한이 목적을 따를 수 있도록 워크플로를 충분히 정확하게 설명해야 한다. “리서치 에이전트” 같은 라벨은 승인된 입력과 허용된 출력을 명확히 설명하는 것보다 지침을 덜 제공한다.

보안 팀에도 그에 상응하는 의무가 있다. 제한은 개발자가 애플리케이션의 동작을 예측할 수 있을 만큼 이해하기 쉬워야 한다. 설명되지 않은 거부는 문제 해결을 어렵게 만들고 더 광범위한 접근 요청을 부추긴다.

에이전트의 선택이 반복적인 유료 활동을 발생시킬 수 있으므로 재무 및 운영 팀도 논의에 참여한다. 이들은 사용량을 책임 있는 워크플로와 연결하는 귀속 정보가 필요하다. 의미 있는 소유자 없는 공유 자격 증명은 그러한 책임성을 약화시킨다.

Otari AI 거버넌스는 이러한 결정을 더 가까이 모은다. 조직적 결과는 공동 책임이다. 애플리케이션 팀은 업무를 정의하고, 플랫폼 팀은 경계를 강제하며, 비즈니스 소유자는 어떤 결과가 지속적인 접근을 정당화하는지 결정한다.

Otari vs LiteLLM, 집행 세부 사항에 초점을 맞추다

의미 있는 비교는 제품이 예산과 모델 라우팅을 나열하는지 여부가 아니라, 통제가 배포 환경에서 어떻게 작동하는가다.

LiteLLM은 문서에서 이미 중앙 집중식 지출 통제를 설명하고 있으므로 유용한 기준점이 된다. 예산 집행 문서는 개인, 팀, 팀 구성원 및 에이전트 예산을 다룬다. 또한 예산 집행은 연결된 데이터베이스에 의존한다고 명시한다.

이 조건은 기능 이름만으로는 비교가 불완전한 이유를 보여준다. 대시보드는 예산을 표시할 수 있지만, 기본 배포 환경에는 이를 집행하는 데 필요한 상태 정보가 없을 수 있다. 운영자는 각 통제를 뒷받침하는 조건을 이해해야 한다.

따라서 Otari vs LiteLLM 평가는 애플리케이션의 실제 요청 경로에서 시작해야 한다. 어떤 자격 증명이 호출자를 식별하는가? 어떤 제한이 적용되는가? 회계 정보를 이용할 수 없을 때는 어떻게 되는가? 답은 긴 지원 통합 목록보다 더 중요하다.

이 지점에서 중앙 집중식 인프라는 애플리케이션에 개별적으로 내장된 안전장치와도 다르다. 개별 구현은 지역적 요구 사항을 반영할 수 있지만, 각각의 구현에는 유지보수가 필요하다. 공유 통제 지점은 이러한 애플리케이션 전반에서 일관된 동작을 만들 기회를 제공한다.

팀이 공급업체를 교체하거나 다른 워크플로를 도입할 때 이러한 일관성은 가치가 있다. 관리자는 변경이 기존 규칙을 유지하는지 이해할 수 있어야 한다. 그렇지 않으면 모든 통합이 정책이 흔들릴 또 다른 기회가 된다.

Mozilla AI는 Otari가 애플리케이션이 모델에 도달하는 공통 애플리케이션 프로그래밍 인터페이스, 즉 API를 제공한다고 말한다. 또한 공급업체를 이용할 수 없을 때 요청을 재라우팅하는 폴백 규칙을 설명한다.

폴백은 다른 작업 속성을 바꾸면서 가용성을 유지할 수 있다. 대체 모델은 지시를 다르게 따르거나, 다른 답변 형식을 생성하거나, 추가 검토를 요구할 수 있다. 따라서 서비스를 유지하는 일은 동등한 동작을 유지하는 일과 다르다.

이 때문에 공급업체 전환은 검증된 운영 결정으로 남아야 한다. 인터페이스는 출력 품질 평가의 필요성을 없애지 않고도 통합 작업을 줄일 수 있다. 애플리케이션은 여전히 모델이 지시를 해석하고 사용 가능한 도구를 활용하는 방식에 의존한다.

동일한 논리는 적용 조건에 따라 사용 가능한 모델 매개변수를 가진 오픈 웨이트 모델에도 적용된다. 이러한 매개변수에 접근할 수 있다고 해서 애플리케이션이 기대하는 주변 서비스가 자동으로 제공되는 것은 아니다.

Mozilla AI의 오픈 모델 인프라 논의는 검색과 코드 실행 같은 도구를 그 누락된 주변 계층의 일부로 규정한다. 그 주장은 애플리케이션이 그러한 기능에 계속 접근할 수 있을 때 모델 선택이 더 실용적이 된다는 것이다.

구매자에게 주는 시사점은 동등한 조건에서 완료된 작업을 비교하라는 것이다. 그럴듯한 답변을 빠르게 생성하는 모델도 광범위한 확인이 필요할 수 있다. 다른 모델은 더 적은 수정으로 같은 과제를 완료할 수 있다.

이러한 차이는 공급업체 이동성의 가치에 영향을 준다. 조직이 대안이 요구 사항을 충족하는지도 판단할 수 있을 때 쉬운 라우팅이 가장 중요하다. 그런 평가가 없다면 전환 능력은 대체로 이론에 머문다.

결과적으로 Otari vs LiteLLM은 선언된 승자가 아니라 배포 환경의 비교다. 허용된 워크플로와 그 실패 조건 모두가 평가를 결정해야 한다. 문서나 기능 체크리스트만으로는 특정 환경에서 어느 제품이 더 잘 작동할지 확정할 수 없다.

예산 통제는 요청이 거치는 경로에 달려 있다

지출 한도는 회계 규칙, 적용 범위, 그리고 동시 요청 상황에서의 동작만큼만 강력하다.

Otari의 예산 보안 참고 문서는 발표 내용과 함께 주목할 만한 제한 사항을 제시한다. 이 문서는 동시 토큰 과금 및 이미지 요청에 대한 비용 예약을 설명한다. 토큰은 모델이 텍스트를 입력받거나 생성할 때 처리하는 단위다.

예약은 작업을 전송하기 전에 예상 비용을 계산한다. 요청이 동시에 도착할 때 이는 중요하다. 각 요청이 동일한 잔여 한도를 사용할 수 있다고 가정해서는 안 된다.

보안 참고 문서는 이러한 예약을 사후 가져오기, 배치 작업, 그리고 현재 예약되지 않은 정액 요금 경로와도 구분한다. 이러한 경로는 엄격한 실시간 상한으로 설명되지 않는다. 따라서 이 약속이 적용되는 범위가 중요하다.

그렇다고 예산 제어가 도움이 되지 않는다는 뜻은 아니다. 이는 그 운영 경계가 구매 결정의 일부라는 의미다. 팀은 의도한 워크로드가 예약 경로를 따르는지, 아니면 나중에 이루어지는 회계 처리에 의존하는지 이해해야 한다.

예를 들어, 배치 단위로 작업을 제출하는 가상의 문서 처리 애플리케이션을 생각해 보자. 운영자는 두 서비스가 동일한 지출 대시보드에 표시된다는 이유만으로 그 동작이 대화형 어시스턴트와 같다고 가정해서는 안 된다.

핵심은 시스템이 언제 작업을 확정하는가다. 그 확정 이후에 회계 처리가 이루어진다면, 표시된 잔액은 요청 전 제한과 다른 목적을 가진다. 둘 다 재무 관리에 도움이 될 수 있지만, 답하는 질문은 서로 다르다.

모델 가격도 또 하나의 의존 요소다. Otari의 보안 정책은 기본적으로 가격 정보가 필요하며, 문서화된 규칙에 따라 가격이 책정되지 않은 모델 요청은 거부된다고 명시한다. 이는 알려지지 않은 비용을 비용이 없는 것으로 취급하지 않도록 하는 구체적인 안전장치다.

그러나 운영자는 구성을 변경할 수 있고, 같은 문서는 예외도 식별한다. 배포 평가는 기본값에 대한 가정이 아니라 실제 적용 설정과 엔드포인트를 확인해야 한다.

더 넓게 보면 비용 제어는 요청 처리에 속한다. 이는 신원, 가격 정보, 회계 상태, 그리고 작업이 승인되는 시점에 의존한다. 보고만으로는 이러한 조건을 모두 보장할 수 없다.

사람의 검토는 또 다른 경계를 만든다. 에이전트는 지출 한도 내에 머물면서도 사용할 수 없는 결과물을 생성할 수 있다. 예산은 노출을 제한할 뿐, 해당 작업이 비용을 들일 가치가 있는지를 판단하지는 않는다.

이 구분은 내부 보고 방식에도 반영되어야 한다. 애플리케이션 소유자는 사용량을 승인된 결과, 수정 사항, 포기된 시도와 연결해야 한다. 그렇지 않으면 워크플로가 단지 덜 유용한 작업을 완료하고 있음에도 낮은 사용량이 성공처럼 보일 수 있다.

팀이 모델을 비교할 때도 같은 검토가 적용된다. 저렴한 요청도 반복 재시도나 상당한 정리 작업을 유발하면 비싼 워크플로가 될 수 있다. 관련 있는 가치 단위는 완료된 작업이다.

Otari AI 거버넌스는 팀이 이러한 결정을 조율할 수 있는 제안된 공간을 제공하지만, 보안 문서는 “제어”에 대한 광범위한 해석을 제한한다. 구매자는 요구 사항을 작성할 때 이러한 제한 사항을 유지해야 한다.

책임 있는 평가는 승인된 환경에서 일반 요청과 경계 조건을 모두 테스트해야 한다. 결과는 무엇이 중단되는지, 언제 중단되는지, 그리고 어떤 활동이 엄격한 상한 밖에 남는지를 밝혀야 한다.

그러한 증거는 예산 기능이 존재한다는 주장보다 더 유용하다. 이는 제품의 문서화된 메커니즘을 조직의 실제 재무적 노출과 연결한다.

추적은 가시성과 보존되는 콘텐츠 사이의 선택을 만든다

팀은 발생한 일을 확인하는 것과 에이전트가 읽거나 생성한 모든 내용을 보존하는 것을 구분해야 한다.

세션 추적은 활동을 타임라인으로 연결하여 운영자가 워크플로가 어떻게 진행되었는지 조사할 수 있게 한다. Mozilla AI의 발표는 프롬프트, 응답 또는 도구 결과를 저장하지 않는 추적을 설명한다. 이는 가시성에 대한 해당 조직의 명시된 접근 방식에서 중요한 부분이다.

그러나 프로젝트의 릴리스 기록은 한 가지 제한 사항을 추가한다. 11월 4일자 버전 0.38.0에는 이를 요청하는 라우팅된 요청의 콘텐츠를 보존하는 기능 지원이 나열되어 있다.

이러한 설명을 저장에 관한 무조건적 약속으로 합쳐서는 안 된다. 발표는 콘텐츠를 최소화하는 접근 방식을 설명하는 반면, 릴리스 노트는 선택적 콘텐츠 보존 기능을 보여 준다. 따라서 배포 선택은 주의 깊게 검토할 가치가 있다.

운영자에게 이러한 모드는 서로 다른 조사를 지원한다. 타임라인은 실패한 요청이나 라우팅 변경을 찾는 데 도움이 될 수 있다. 특정 답변에 특정 오류가 포함된 이유를 재구성하려면 관련 자료에 대한 정보가 필요할 수 있다.

이는 현실적인 긴장을 만든다. 콘텐츠를 적게 보존하면 디버깅을 위해 수집되는 민감한 자료의 양을 줄일 수 있다. 더 많이 보존하면 특정 사고를 더 쉽게 이해할 수 있다. 어느 쪽 선호도 모든 운영 요구를 해결하지는 않는다.

내부 리서치를 처리하는 가상의 어시스턴트는 이러한 절충을 구체적으로 보여 준다. 활동 기록은 어떤 서비스가 요청을 처리했는지와 실패 여부를 식별할 수 있다. 오해를 불러일으키는 요약을 이해하려면 원문 구절도 검토해야 할 수 있다.

조직은 이러한 조사 자료가 어디에 속하는지 결정해야 한다. 이는 별도의 접근 제한이 적용되는 애플리케이션 자체의 기록에 이미 존재할 수 있다. 이를 다른 시스템에 복제하면 관리해야 할 장소가 하나 더 생긴다.

이 때문에 추적에 관한 주장은 조직 전체의 데이터 보존 정책을 대신할 수 없다. 애플리케이션, 모델 서비스, 검색 서비스 및 실행 도구는 워크플로에서 서로 다른 위치를 차지할 수 있다.

게이트웨이의 구성은 이 그림과 관련이 있지만, 다른 모든 구성 요소를 설명하지는 않는다. 팀은 정보가 어디로 이동하고 지속되는지에 관해 보장하기 전에 관련 서비스를 매핑해야 한다.

운영 가시성과 출력 책임성 사이에도 차이가 있다. 추적은 어떤 작업이 발생했음을 입증할 수 있다. 그 작업이 적절했는지를 판단하려면 여전히 워크플로의 목적과 이를 지배하는 규칙이 필요하다.

사고를 조사하는 검토자는 활동을 관련 애플리케이션 및 책임 소유자와 연결할 수 있어야 한다. 그렇지 않으면 상세한 타임라인도 해석하기 어려울 수 있다.

같은 원칙은 차단된 작업에도 적용된다. 승인된 운영자가 어떤 규칙이 이를 초래했는지 이해할 수 있을 때 거부는 더 유용하다. 이는 에이전트의 권한을 자동으로 넓히지 않으면서 수정을 지원한다.

오픈 소스 제공은 구현 선택을 검토할 기회를 제공한다. 그렇다고 모든 배포 인스턴스가 동일한 구성을 사용하거나 동일한 정보를 보존한다는 뜻은 아니다.

구매자에게 결론은 구체적이다. 어떤 추적 모드가 활성화되어 있는지, 누가 이를 변경할 수 있는지, 누가 생성된 기록을 검토할 수 있는지 물어야 한다. 이러한 답변은 일반적인 개인정보 보호 주장을 운영상의 약속으로 바꾼다.

이 선택은 워크플로의 민감도와 조사 필요성에 따라야 한다. 공개 리서치 어시스턴트와 기밀 문서를 처리하는 어시스턴트가 책임 있는 운영을 지원하기 위해 동일한 증거를 보존할 필요는 없다.

다음에 주목할 점: 집행 증거, 이식성, 그리고 도입

Otari의 진전은 사용자가 실제 워크플로에서 그 제어 기능을 관찰 가능한 동작과 연결할 수 있을 때 가장 분명해질 것이다.

향후 몇 달 동안 주목할 첫 번째 신호는 재현 가능한 집행 증거다. 유용한 보고서는 이름이 명시된 배포 환경이 거부된 도구, 소진된 예산 및 동시 요청을 어떻게 처리하는지 보여 줄 것이다. 버전과 관련 구성도 식별해야 한다.

이는 문서화된 제어 기능을 관찰된 결과와 연결함으로써 Mozilla AI의 제안을 강화할 것이다. 최종 결과가 고무적으로 들리더라도 요청 경로나 설정을 생략한 보고서는 신뢰를 덜 제공한다.

가장 유익한 사례에는 정상적인 운영뿐 아니라 경계를 넘으려는 시도도 포함될 것이다. 성공적인 답변은 유용성을 보여 준다. 적절히 거부된 요청은 특정 제한이 테스트된 조건에서 유지되었음을 보여 준다.

두 번째 신호는 동등한 제약 조건에서의 제공업체 이식성이다. 팀은 모델을 변경하는 동안 애플리케이션의 작업, 허용된 도구 및 검토 기준을 유지하는 비교를 찾아야 한다.

이는 더 쉬운 라우팅이 실질적인 선택으로 이어지는지를 드러낼 것이다. 전환에 여전히 상당한 워크플로 복구가 필요하다면, 통합 이점은 실재하지만 운영 체제 비유가 시사하는 것보다 범위가 좁다.

출력 품질도 이 평가의 일부로 남아야 한다. 인터페이스는 유지하면서 수정량을 늘리는 제공업체 변경은 다른 곳에 작업을 만든다. 이식성은 조직이 그에 따른 동작을 수용할 수 있을 때 가치가 생긴다.

세 번째 신호는 명시적인 운영 책임을 갖춘 지속적인 도입이다. 관련 사례는 누가 게이트웨이를 유지하고, 정책 변경을 검토하며, 실패를 조사하고, 에이전트에 더 넓은 접근 권한을 부여할지 결정하는지를 설명할 것이다.

이러한 세부 사항은 중앙집중식 거버넌스가 반복 작업을 줄이는지, 아니면 단지 다른 곳으로 옮기는지를 보여 줄 것이다. 설득력 있는 배포 사례는 이점과 함께 유지 관리 및 예외도 인정해야 한다.

오픈 소스 접근 방식이 검증 가능해지는 지점도 여기다. 조직은 소프트웨어를 검토하고 직접 운영할 수 있지만, 누군가는 업데이트, 구성 및 사고 대응을 책임져야 한다.

안정적인 소유권의 증거는 게이트웨이를 공유 조직 인프라로 다루어야 한다는 근거를 강화할 것이다. 문서화되지 않은 개입을 통해서만 작동하는 배포는 기능 범위와 무관하게 그 근거를 약화할 것이다.

이러한 신호는 Mozilla AI가 설명한 사건에 대한 논의를 현실에 기반하게 한다. Otari는 모델 접근, 에이전트 권한 및 지출을 조율하기 위한 일관된 제안을 제시한다. 장기적 가치는 이러한 요소들이 함께 어떻게 작동하는지에 달려 있다.

회사의 거버넌스 프레이밍은 정확한 질문을 유도할 때 가장 유용하다. 어시스턴트는 어떤 작업을 요청할 수 있는가? 인프라는 어떤 작업을 거부할 수 있는가? 작업이 시작되기 전에 시스템은 어떤 비용을 제한할 수 있는가?

Otari AI 거버넌스를 평가하는 팀은 목적과 허용 가능한 출력을 이미 이해하고 있는 워크플로부터 시작해야 한다. 그러면 실패를 더 쉽게 인식하고 개선 사항을 더 쉽게 평가할 수 있다. 권한, 지출 동작 및 문제가 발생한 뒤 이용 가능한 증거를 검토하는 동안 작업을 안정적으로 유지하라.

접근 권한을 확대하기 전에 애플리케이션 소유자에게 추가 기능이 무엇을 가능하게 하며 누가 그 사용에 대한 책임을 수용하는지 설명해 달라고 요청하라. 플랫폼 소유자에게 그 권한이 어디에서 집행되는지 보여 달라고 요청하라. 그런 다음 다른 모델이 동일한 경계 내에서 같은 작업을 완료할 수 있는지 비교하라. 에이전트가 실수했을 때에도 어떤 결정이 집행 가능한 상태로 남는가?