획일적 거버넌스는 엔터프라이즈 AI 에이전트를 실패로 이끈다

Google News는 기업을 향한 날카로운 경고를 포착했다. 획일적인 거버넌스는 AI 에이전트의 안전성과 유용성을 모두 떨어뜨릴 수 있다. Techzine Global이 조명한 JFrog의 기반 분석은 심각한 운영상 결과를 예고한 Gartner의 전망을 토대로 한다.

Gartner는 2027년까지 기업의 40%가 자율형 AI 에이전트의 권한을 낮추거나 운영을 중단할 것으로 예측한다. 이 회사는 거버넌스 공백이 프로덕션 환경에서 사고가 발생한 뒤에야 드러날 것으로 본다. 이 전망은 거버넌스를 단순한 컴플라이언스 활동이 아니라 배포 리스크로 바꿔 놓는다.

갈등의 본질은 거버넌스 대 혁신이 아니다. 획일적 통제 대 비례적 통제의 문제다. 조사 지원 에이전트와 자율 결제 에이전트가 동일한 위험 노출을 만들지는 않는다. 그러나 많은 조직은 여전히 두 시스템에 똑같은 검토 절차, 권한, 모니터링 규칙을 적용한다.

이 접근 방식은 서로 반대되는 두 가지 실패를 낳는다. 과도한 통제는 저위험 도구의 배포를 지나치게 늦춘다. 반면 취약한 일반 통제는 고영향 에이전트에 조직이 안전하게 감독할 수 있는 수준을 넘어선 권한을 부여한다.

새롭게 부상하는 대안은 자율성, 접근 권한, 잠재적 결과에 따라 통제를 배정하는 방식이다. 또한 모든 모델, 도구, 플러그인, 스킬, 연결을 거버넌스 대상인 소프트웨어 구성 요소로 다룬다.

Google News 보도가 실제로 바꾼 것

중요한 변화는 Gartner가 획일적 거버넌스와 AI 에이전트 배포 실패의 연관성을 명시적으로 제기했다는 점이다.

Gartner는 2026년 5월 26일 경고를 발표했다. 모든 에이전트에 동일한 거버넌스 모델을 적용하면, 에이전트마다 권한과 범위가 다르기 때문에 실패를 초래한다고 주장했다.

이 구분은 당연하게 들리지만, 기업 정책은 흔히 이를 무시한다. 많은 프로그램은 하나의 허용 사용 정책, 하나의 검토 위원회, 하나의 보안 체크리스트에서 출발한다. 이러한 통제는 대개 생성형 AI를 광범위한 범주로 다룬다.

에이전트는 이 구조를 복잡하게 만든다. AI 에이전트는 목표를 향해 단계를 계획하고, 도구를 선택하며, 행동을 수행할 수 있는 시스템이다. 따라서 그 행동은 기반 모델만으로 결정되지 않는다.

기본적인 요약 에이전트는 문서를 읽고 텍스트를 생성할 수 있다. 하지만 원본 파일을 변경하거나, 메시지를 보내거나, 코드를 실행할 수는 없다. 가장 가능성 높은 최악의 실패는 부정확하거나 오해를 불러일으키는 답변이다.

고객 서비스 에이전트는 계정 데이터를 읽고, 기록을 업데이트하며, 크레딧을 발행하고, 사용자에게 연락할 수 있다. 그 오류는 금전, 개인정보, 계약상 의무, 고객 신뢰에 영향을 줄 수 있다.

인프라 에이전트는 더 큰 위험 노출을 제시한다. 클라우드 리소스를 수정하고, 접근 정책을 변경하며, 코드를 배포하거나, 보안 경고에 대응할 수 있다. 한 번의 잘못된 조치는 연결된 시스템 전반으로 확산될 수 있다.

‘AI 에이전트’라는 단일한 명칭은 이러한 차이를 숨긴다. 단일한 통제 패키지는 이를 다시 숨긴다.

Gartner의 거버넌스 경고는 에이전트의 자율성과 접근 범위를 구분한다. 두 차원 모두 중요하다.

자율성은 에이전트가 단계를 얼마나 독립적으로 선택하고 실행할 수 있는지를 설명한다. 범위는 에이전트가 도달할 수 있는 시스템, 데이터, 비즈니스 프로세스를 뜻한다. 에이전트는 한 차원에서는 높고 다른 차원에서는 낮을 수 있다.

예를 들어, 폐기 가능한 테스트 환경에서 매우 자율적으로 작동하는 에이전트는 제한적인 비즈니스 위험만 만들 수 있다. 반면 프로덕션 결제 접근 권한을 가진 자율성이 낮은 에이전트도 엄격한 통제가 필요할 수 있다.

Google News 검색 결과가 중요한 이유는 실제 위험 노출에 기반한 거버넌스 모델을 가리키기 때문이다. 이제 핵심 질문은 조직이 ‘에이전트를 허용하는지’ 여부가 아니다.

리더는 각 에이전트가 무엇을 관찰하고, 결정하고, 변경할 수 있는지 물어야 한다. 또한 이러한 행동을 되돌릴 수 있는지도 판단해야 한다.

이 질문들은 거버넌스를 엔지니어링에 더 가깝게 만든다. 정책 팀은 여전히 허용 가능한 위험을 정의하지만, 기술 시스템은 개발과 프로덕션 과정에서 그 한계를 강제해야 한다.

따라서 변화는 구조적이다. 엔터프라이즈 AI 거버넌스는 승인 단계에서 적용되는 문서에 머물 수 없다. 정체성, 권한, 의존성, 행동, 결과와 연결된 지속적인 통제 시스템이 되어야 한다.

하나의 정책이 두 가지 다른 실패를 만드는 이유

획일적 거버넌스가 실패하는 이유는 동일한 제한이 한 에이전트에는 과도하고 다른 에이전트에는 위험할 정도로 취약할 수 있기 때문이다.

첫 번째 실패는 운영 마비다. 저위험 내부 지원 에이전트가 재무 기록을 변경할 권한을 가진 에이전트와 동일한 승인 절차를 거칠 수 있다.

이 검토에는 법무, 개인정보 보호, 사이버보안, 모델 리스크, 조달, 아키텍처 팀이 참여할 수 있다. 각 그룹은 조직의 가장 민감한 시스템을 위해 설계된 증거를 요구할 수 있다.

이 과정은 중대한 영향을 미치는 배포에는 타당하다. 하지만 에이전트가 공개 문서를 요약하거나 사람이 검토할 초안을 작성하는 데 그친다면 과도하다.

긴 승인 주기가 항상 도입을 막는 것은 아니다. 도입을 승인된 채널 밖으로 밀어낼 수 있다. 직원들은 여전히 마감 기한, 반복 업무, 사용 가능한 도구를 활용해야 한다는 압박에 직면한다.

그 결과는 중앙 가시성 없이 사용되는 미승인 시스템, 즉 섀도우 AI다. 따라서 엄격하고 획일적인 정책은 공식 배포를 줄이는 동시에 알려지지 않은 배포를 늘릴 수 있다.

두 번째 실패는 시스템적 위험 노출이다. 일반적인 체크리스트는 고영향 에이전트의 정확한 도구, 자격 증명, 실패 경로, 에스컬레이션 행동을 검증하지 않은 채 승인할 수 있다.

송장을 읽을 수 있는 에이전트와 결제를 승인할 수 있는 에이전트는 다르다. 클라우드 변경안을 작성하는 에이전트와 이를 자동 배포하는 에이전트도 다르다.

광범위한 정책 언어는 이런 경계를 좀처럼 포착하지 못한다. ‘인간 감독’과 같은 표현도 승인이 어디서 이루어지고 검토자가 어떤 증거를 받는지 설명하지 않으면 의미가 거의 없다.

모든 행동을 승인하는 사람은 형식적 승인자가 될 수 있다. 예외적인 행동만 검토하는 사람에게는 예외를 식별할 신뢰할 수 있는 기준이 필요하다.

시점도 중요하다. 되돌릴 수 없는 행동 이후의 승인은 의미 있는 감독이 아니다. 사고 후 감사는 피해를 설명할 수는 있지만, 그 피해를 막을 수는 없다.

JFrog의 에이전트 거버넌스 분석은 이 문제를 일괄적 제한과 비례적 통제 사이의 선택으로 제시한다. 이 주장은 소프트웨어 공급망 관점을 반영한다.

이 관점은 에이전트가 여러 개의 변화하는 구성 요소로 이루어져 있기 때문에 유용하다. 팀은 오늘 에이전트를 승인한 뒤, 내일 모델, 프롬프트, 플러그인 또는 도구를 업데이트할 수 있다.

각 변경은 행동을 바꿀 수 있다. 새 도구는 접근 범위를 확장할 수 있다. 수정된 프롬프트는 의사결정 우선순위를 바꿀 수 있다. 의존성 업데이트는 취약한 코드를 도입할 수 있다.

획일적 거버넌스는 승인된 에이전트를 안정적인 객체로 취급한다. 실제로 배포된 시스템은 변화하는 소프트웨어 스택에 더 가깝게 작동한다.

따라서 승인 모델은 변화를 고려해야 한다. 무해한 업데이트가 새로운 결제 기능과 같은 절차를 유발해서는 안 된다. 그러나 의미 있는 변경이 눈에 띄지 않은 채 통과해서도 안 된다.

이를 위해서는 정의된 임계값이 필요하다. 팀은 어떤 변경이 자동화된 테스트, 보안 검토, 비즈니스 승인 또는 새로운 위험 평가를 요구하는지 알아야 한다.

핵심 문제는 서류 작업의 부족이 아니다. 통제 해상도가 낮다는 데 있다.

거버넌스는 모든 에이전트를 동등하게 볼 때 해상도가 낮다. 권한, 데이터 민감도, 되돌릴 수 있는지 여부, 운영 범위를 구분할 때 유용한 해상도를 얻는다.

진정한 경계는 읽기 접근 권한과 행동 권한 사이에 있다

에이전트가 대화 창 밖의 세계를 바꿀 수 있게 되면 거버넌스는 실질적으로 더 어려워진다.

전통적인 챗봇은 주로 콘텐츠를 생성한다. 사용자는 그 콘텐츠를 신뢰할지, 행동으로 옮길지를 결정한다. 이 분리는 자연스러운 승인 경계를 만든다.

에이전트는 이 경계를 없앨 수 있다. 도구를 선택하고, API를 호출하며, 애플리케이션을 업데이트하고, 사람이 모든 단계를 승인하지 않아도 계속 작업할 수 있다.

이 역량은 수작업 인계를 줄이기 때문에 가치를 만든다. 동시에 실패 지점을 화면 속 답변에서 비즈니스 프로세스 내부의 행동으로 옮긴다.

세 가지 엔터프라이즈 시나리오를 생각해 보자.

조사 에이전트는 승인된 문서를 읽고 시장 요약을 작성한다. 외부 커뮤니케이션 도구는 없다. 배포 전에 사람이 결과를 확인한다.

영업 에이전트는 고객 기록을 읽고, 후속 작업을 생성하며, 메시지 초안을 작성한다. 고객 관계 플랫폼에 기록을 쓸 수는 있지만 외부 커뮤니케이션을 전송할 수는 없다.

수익 관리 에이전트는 구독 상태를 변경하고, 크레딧을 적용하며, 고객 알림을 발송한다. 직접적인 금전적·평판상 결과를 초래할 수 있다.

이 시스템들은 동일한 기반 모델을 사용할 수 있다. 그럼에도 거버넌스 요구사항은 크게 달라져야 한다.

첫 번째 에이전트에는 소스 접근, 데이터 유출, 사실 정확성을 위한 통제가 필요하다. 두 번째 에이전트에는 쓰기 제한, 레코드 수준 권한, 변경 로그도 필요하다.

세 번째 에이전트에는 거래 한도, 승인 게이트, 롤백 절차, 직무 분리, 신속한 중단 기능이 필요하다. 특정 관할권과 연계된 컴플라이언스 검토도 필요할 수 있다.

이것이 비례적 거버넌스다. 에이전트가 더 중대한 신뢰 경계를 넘을수록 통제도 강화된다.

이 원칙은 이미 확립된 프레임워크에 등장한다. NIST AI RMF는 거버넌스, 매핑, 측정, 관리 기능을 통해 위험 업무를 구성한다.

NIST는 이러한 기능을 보편적인 체크리스트로 제시하지 않는다. 이 지침은 조직에 위험 관리를 맥락, 목표, 법적 요구사항, 위험 허용 수준에 맞추도록 요구한다.

이 프레임워크의 매핑 기능은 특히 관련성이 높다. 팀은 에이전트의 의도된 작업, 영향을 받는 당사자, 운영 조건, 예상되는 실패 모드를 이해하기 전에는 적절한 통제를 선택할 수 없다.

유럽연합도 유사한 논리를 따른다. AI Act는 위험 범주와 사용 사례에 따라 서로 다른 의무를 설정한다.

AI Act 지침은 허용 불가, 고위험, 투명성, 최소 위험 시스템을 구분한다. 모든 AI 애플리케이션을 동일하게 규제하지는 않는다.

엔터프라이즈 거버넌스도 더 세부적인 수준에서 유사한 차별화가 필요하다. 규제 분류는 하나의 경계를 제공하지만, 내부 운영 위험에는 추가 계층이 필요하다.

두 에이전트가 모두 고위험 법적 범주에 속하지 않더라도, 매우 다른 사이버보안 위험 노출을 만들 수 있다. 한 에이전트는 공개 정보에 접근하는 반면, 다른 에이전트는 내부 시스템용 자격 증명을 보유할 수 있다.

정체성은 핵심 통제가 된다. 각 에이전트는 개발자 계정을 빌리거나 광범위한 서비스 자격 증명을 공유하는 대신, 고유한 비인간 정체성을 가져야 한다.

권한은 최소 권한 원칙을 따라야 한다. 이는 정의된 작업에 필요한 접근 권한만 부여하고, 더 이상 필요하지 않을 때 제거하는 것을 의미한다.

조직에는 행동 수준의 정책도 필요하다. 애플리케이션에 대한 접근 권한이 그 안의 모든 작업을 자동으로 허용해서는 안 된다.

에이전트는 티켓을 읽고, 내부 메모를 추가하며, 상태 변경을 제안할 권한이 필요할 수 있다. 하지만 티켓을 종료하거나 이력을 삭제할 권한까지 필요하지는 않을 수 있다.

이 구분은 통제 가능한 행동 표면을 만든다. 또한 로그가 각 작업을 요청한 정체성을 보여주므로 감사의 유용성도 높인다.

모든 에이전트는 소프트웨어 공급망이기도 하다

모델은 에이전트 실행 경로의 한 구성 요소일 뿐이므로, 거버넌스는 모델 승인에서 멈출 수 없다.

현대의 에이전트는 모델에 프롬프트, 메모리, 검색 시스템, 도구, 플러그인, API, 오케스트레이션 코드를 결합한다. 각 구성 요소는 에이전트가 무엇을 알고 무엇을 수행하는지 바꿀 수 있다.

모델은 합리적인 계획을 생성할 수 있다. 그러나 침해된 도구는 여전히 해로운 작업을 실행할 수 있다. 안전한 도구 역시 과도한 권한으로 구성되면 위험해질 수 있다.

일반적으로 MCP라고 불리는 Model Context Protocol은 이러한 과제를 잘 보여준다. MCP는 AI 애플리케이션이 데이터 소스 및 실행 가능한 도구와 연결할 수 있도록 표준 방식을 제공한다.

이 표준화는 맞춤형 통합 작업을 줄일 수 있다. 동시에 외부에서 확보한 패키지나 서버를 통해 새로운 기능을 쉽게 추가하게 만들 수도 있다.

연결이 쉬워지면 거버넌스 문제도 달라진다. 보안팀이 에이전트의 모델은 승인했지만, 소스 코드나 자격 증명에 접근할 수 있는 새 MCP 서버가 추가된 사실은 놓칠 수 있다.

플러그인과 스킬도 유사한 우려를 낳는다. 여기에는 스키마, 지침, 스크립트, 인증 범위, 의존성 체인이 포함될 수 있다. 각각이 시스템의 동작 범위를 확장한다.

전통적인 소프트웨어 프로그램은 명시적인 코드 경로를 따르지만, 복잡한 시스템은 여전히 예기치 않게 동작할 수 있다. 에이전트는 런타임에 그 경로들 중 하나를 선택하는 모델 기반 의사결정을 더한다.

그렇다고 에이전트를 보호할 수 없다는 뜻은 아니다. 구성 요소 목록화와 런타임 관찰이 필수라는 의미다.

조직은 배포된 모든 에이전트에 대한 자재 명세서가 필요하다. 이 기록에는 모델, 프롬프트, 도구, 플러그인, 패키지, 컨테이너, 데이터 소스, 외부 서비스가 식별되어야 한다.

각 구성 요소에는 소유자와 버전이 있어야 한다. 팀은 누가 이를 승인했는지, 어떤 테스트를 통과했는지, 어떤 시스템에 접근할 수 있는지 알아야 한다.

업데이트가 에이전트의 공개 이름을 바꾸지 않고도 동작을 변경할 수 있으므로 의존성 통제가 중요하다. 플러그인 버전은 새 권한을 요청하거나 취약한 라이브러리를 도입할 수 있다.

아티팩트는 신뢰할 수 있는 저장소를 거쳐야 한다. 그러면 배포 전에 보안 검사가 패키지, 컨테이너, 구성 파일을 검사할 수 있다.

프롬프트와 정책에도 같은 규율이 적용되어야 한다. 전통적인 의미의 실행 코드가 아니더라도, 변경 사항은 에이전트의 동작을 실질적으로 바꿀 수 있다.

프롬프트 업데이트는 에이전트에게 검토보다 속도를 우선하라고 지시할 수 있다. 정책 업데이트는 특정 거래 한도 이하의 자동 실행을 허용할 수 있다.

두 변경 모두 버전 이력과 테스트가 필요하다. 필요한 검토 수준은 파일 형식이 아니라 영향에 맞춰야 한다.

OWASP의 에이전트 가이드는 목표, 도구, 메모리, 정체성, 멀티에이전트 상호작용에서 발생하는 위험을 설명한다. 이러한 위험은 부정확한 모델 출력의 범위를 넘어선다.

목표 조작은 공격자의 목적을 향하도록 에이전트를 전환할 수 있다. 도구 오용은 정당한 기능을 공격 경로로 바꿀 수 있다.

메모리 오염은 저장된 컨텍스트를 통해 이후 의사결정에 영향을 줄 수 있다. 과도한 자율성은 에이전트가 사용자의 의도를 넘어서는 행동을 하게 만들 수 있다.

이러한 위협에는 서로 다른 통제가 필요하다. 입력 필터링만으로는 침해된 의존성을 막을 수 없다. 모델 평가만으로는 과도한 권한을 가진 서비스 계정을 탐지할 수 없다.

따라서 비례적 거버넌스는 아티팩트 중심이어야 한다. 위험 분류가 필요한 통제를 결정하고, 아티팩트 관리는 그 통제를 집행 가능하게 만든다.

모델은 에이전트가 무엇을 추론할 수 있는지를 결정한다. 도구와 자격 증명은 그 추론이 무엇에 영향을 줄 수 있는지를 결정한다.

비례적 거버넌스에는 라벨이 아니라 증거가 필요하다

위험 등급은 팀이 실제 실행 중 통제가 작동한다는 사실을 입증할 수 없다면 거의 가치가 없다.

조직은 흔히 저위험, 중위험, 고위험 같은 범주를 만든다. 이러한 라벨에 측정 가능한 기준이 없다면, 그 작업은 또 하나의 획일적인 체크리스트가 될 수 있다.

유용한 등급 체계는 자율성에서 시작한다. 팀은 에이전트가 행동을 단지 권고하는지, 승인이 필요한지, 독립적으로 실행하는지를 문서화해야 한다.

다음 차원은 접근성이다. 여기에는 데이터 민감도, 허용된 시스템, 작업 유형, 지리적 경계, 영향을 받는 사용자가 포함된다.

세 번째 차원은 결과다. 팀은 잘못되거나 악의적이거나 사용할 수 없는 동작으로 인한 피해를 추정해야 한다.

복구 가능성도 중요한 차원을 이룬다. 초안은 폐기할 수 있다. 내부 기록은 대체로 복원할 수 있다. 반면 공개적인 공개나 금융 이체는 되돌리기 어려울 수 있다.

속도 역시 위험을 바꾼다. 하루에 한 번 검토된 작업을 수행하는 에이전트는 시간당 수천 건의 변경을 수행하는 에이전트와 다른 격리 문제를 제기한다.

이러한 차원은 구체적인 통제로 이어져야 한다.

저위험 읽기 전용 에이전트에는 승인된 소스, 데이터 유출 방지, 출력 검토, 기본 로깅이 필요할 수 있다. 배포 절차는 가볍게 유지할 수 있다.

쓰기 권한이 있는 중위험 에이전트에는 범위가 제한된 자격 증명, 작업 로그, 자동화된 테스트, 사용 제한, 민감한 작업에 대한 승인이 필요할 수 있다.

고위험 자율 에이전트에는 더 강력한 분리가 필요하다. 통제에는 거래 한도, 독립적 승인, 지속적 모니터링, 긴급 중지, 검증된 롤백 절차가 포함될 수 있다.

그다음 조직은 이러한 통제를 검증해야 한다. 에이전트가 최소 권한을 사용한다는 서면 진술은 그 자격 증명이 실제로 무엇을 할 수 있는지는 보여주지 않는다.

테스트는 금지된 작업을 시도해야 한다. 에이전트가 승인되지 않은 기록, 도구, 환경에 접근할 수 없음을 확인해야 한다.

팀은 간접 경로도 테스트해야 한다. 에이전트가 직접 결제를 변경할 권한은 없더라도, 해당 변경을 수행하는 워크플로를 실행할 수는 있다.

런타임 텔레메트리는 다음 증거 계층을 제공한다. 로그는 에이전트의 정체성, 선택한 도구, 매개변수, 결과, 승인 상태를 기록해야 한다.

민감한 데이터는 로그 내부에서도 신중하게 처리해야 한다. 모니터링이 기밀 정보나 자격 증명의 새로운 원천이 되어서는 안 된다.

행동 기준선은 비정상적인 활동을 탐지하는 데 도움이 될 수 있지만, 명시적인 정책을 대체해서는 안 된다. 새로운 에이전트 행동이 항상 악의적인 것은 아니며, 익숙한 행동이 항상 안전한 것도 아니다.

결정론적 통제는 명확히 금지된 행동을 차단해야 한다. 행동 기반 시스템은 조사가 필요한 예상치 못한 패턴을 식별해야 한다.

회의적인 질문은 기업이 수천 개의 에이전트 전반에 걸쳐 이러한 수준의 세부 사항을 유지할 수 있는지다. 비례적 모델은 일률적인 금지보다 더 풍부한 목록화, 소유권, 모니터링을 요구한다.

잘못된 구현은 등급 인플레이션을 초래할 수 있다. 팀은 지연을 피하려고 모든 것을 저위험으로 분류하거나, 개인적 책임을 피하려고 모든 것을 고위험으로 분류할 수 있다.

따라서 사업 책임자도 참여해야 한다. 보안팀은 위협을 이해하지만, 프로세스 책임자는 재무적, 고객 관련, 운영상 결과를 이해한다.

에이전트 소유자는 배포 후에도 책임을 유지해야 한다. 소유권에는 사고 검토, 중요한 변경 승인, 에이전트가 여전히 유효한 목적을 수행하는지 확인하는 일이 포함된다.

거버넌스에도 만료가 있어야 한다. 권한과 승인은 무기한 유효하게 유지되지 않고 검토 날짜를 가져야 한다.

가장 강력한 모델은 마찰 없는 통제가 아니다. 결과가 이를 정당화하는 곳에 마찰을 배치하는 모델이다.

Google News 독자가 다음으로 주목해야 할 점

다음 시험대는 기업이 위험 기반 원칙을 집행 가능한 운영 통제로 전환하는지 여부다.

첫 번째 신호는 에이전트 인벤토리의 품질이다. 조직은 식별할 수 없는 시스템을 거버넌스할 수 없다.

신뢰할 수 있는 인벤토리에는 승인된 에이전트, 내장된 공급업체 에이전트, 내부 프로토타입, 직원 계정을 통해 연결된 외부 서비스가 포함되어야 한다.

발견은 조달 기록을 넘어야 한다. 에이전트는 브라우저 확장 프로그램, SaaS 기능, 개발자 패키지, 워크플로 도구, 클라우드 마켓플레이스를 통해 유입될 수 있다.

두 번째 신호는 정체성 분리다. 성숙한 배포 환경에서는 각 프로덕션 에이전트에 좁고 검사 가능한 권한을 가진 고유한 정체성을 부여한다.

공유 계정은 계속 경고 신호로 남을 것이다. 책임 소재를 흐리고 다른 서비스를 방해하지 않으면서 하나의 에이전트를 중지하기 어렵게 만든다.

세 번째 신호는 작업 수준의 가시성이다. 기업은 에이전트가 어떤 작업을 시도하는지, 정책이 어떤 작업을 차단하는지, 사람이 어떤 작업을 승인하는지 알아야 한다.

모델 사용량을 보여주는 대시보드만으로는 충분하지 않다. 토큰 수는 에이전트가 데이터베이스 필드를 변경했는지, 사업 거래를 시작했는지를 알려주지 않는다.

MITRE의 ATLAS 지식 기반은 AI 지원 시스템에 대한 적대적 전술을 위한 유용한 참고 자료를 제공한다. 계속 발전하는 기법은 위협 모델이 실제 시스템 동작을 따라가야 하는 이유를 보여준다.

조직은 에이전트 등급별 프로덕션 사고도 추적해야 한다. 이러한 증거는 통제가 비례적인지, 아니면 단지 편의적인지 드러낼 수 있다.

저위험 에이전트가 의미 있는 안전상 이점 없이 긴 지연을 겪는다면, 거버넌스는 여전히 지나치게 제한적이다. 고위험 사고가 배포 후 발생한다면, 통제는 여전히 너무 약하다.

지표에는 승인 지연 시간, 차단된 작업, 롤백 빈도, 정책 예외, 승인되지 않은 도구, 미해결 소유권이 포함되어야 한다.

이 지표들은 거버넌스를 운영과 연결한다. 또한 리더가 통제가 위험을 줄이는지, 아니면 행정 업무만 늘리는지 판단하는 데 도움을 준다.

규제 동향도 또 다른 신호를 제공할 것이다. 유럽연합은 고위험 분류, 모니터링, 문서화, 인간 감독, 사이버보안, 사고 대응에 관한 지침을 계속 발표하고 있다.

그러나 법적 준수는 완전한 에이전트 보안 프로그램이 아니라 최소 기준에 해당한다. 많은 유해한 행동은 특별히 규제되는 사용 사례의 범위를 벗어난다.

공급업체의 행동도 면밀히 살펴볼 필요가 있다. 엔터프라이즈 플랫폼은 점점 기존 제품에 에이전트를 내장하고 있으며, 때로는 일상적인 기능 업데이트를 통해 새 기능을 활성화한다.

고객은 해당 에이전트에 별도의 정체성이 부여되는지 물어야 한다. 또한 어떤 작업을 제한할 수 있는지, 어떤 기록이 감사 목적으로 계속 제공되는지도 물어야 한다.

기업들이 자율 실행 모드의 에이전트를 권고 모드로 낮추기 시작한다면 Gartner의 전망은 신뢰를 얻을 것이다. 이는 조직이 프로덕션 환경에서 얻은 교훈에 따라 권한을 조정하고 있음을 보여줄 것이다.

기업들이 사고 증가나 광범위한 롤백 없이 자율 시스템을 확장한다면 그 전망은 약화될 것이다. 그러한 결과를 내려면 개발 및 런타임 환경 전반에서 작동하는 통제가 필요하다.

Google News는 유용한 경고를 증폭시켰지만, 이 헤드라인이 엔터프라이즈 에이전트를 금지하는 이유가 되어서는 안 된다. 이 주장은 덜 야심 찬 자동화가 아니라 더 정교한 거버넌스를 뒷받침한다.

경영진은 배포된 모든 에이전트에 대해 한 가지 직접적인 질문을 던져야 한다. 사람이 막지 않아도 이 시스템은 무엇을 변경할 수 있는가?

그 답은 정체성, 권한, 테스트, 모니터링, 승인 게이트, 종료 절차를 결정해야 한다. 이러한 통제가 모든 에이전트에서 동일하게 유지된다면, 거버넌스 모델은 여전히 위험을 놓치고 있다.