theCUBE AI 회복탄력성 연구, 자신감과 복구 사이의 격차 드러내
theCUBE Research는 기업의 자신감과 검증된 복구 사이에 불일치가 있다고 보고했다. 인터뷰한 25개 조직 가운데 AI 사고 시나리오를 실제로 훈련한 곳은 단 4곳이었다. 이 훈련에는 부분 테스트도 포함됐다. 2026년 11월 8일 공개된 theCUBE AI 회복탄력성 연구는 기업 구매자에게 구체적인 질문을 던진다. 권한을 부여받은 자동화가 잘못 작동할 때, 그들의 자신감은 무엇에 근거하는가?
AI 에이전트는 모델을 사용해 행동을 선택하고 연결된 도구를 호출하는 소프트웨어다. 이 소프트웨어에 업무 수행 권한을 부여하면 잘못된 답변의 결과도 달라진다. 잘못된 권고는 변경된 고객 기록, 외부로 발송된 메시지 또는 운영 의사결정으로 이어질 수 있다.
Microsoft와 Amazon Web Services는 이미 에이전트 ID와 실행 모니터링을 위한 통제 수단을 문서화하고 있다. 이들의 접근 방식은 유용한 맥락을 제공하지만, 권한 설정이나 추적 기록만으로 손상된 비즈니스 프로세스가 복구됐다는 사실이 입증되지는 않는다. 이 차이는 보안 책임자, 애플리케이션 소유자, 자율성을 평가하는 구매자에게 압박을 만든다.
theCUBE AI 회복탄력성 연구가 실제로 확인한 내용
이 결과는 소규모 인터뷰 표본 안에서의 준비 상태 문제를 보여줄 뿐, 산업 전반의 실패율을 확립하지는 않는다.
Dave Vellante와 Krista Case는 Qualitate와 함께 수행한 연구를 설명한다. AI 회복탄력성 결과는 두 조직에서 의도하지 않은 에이전트 행동을 폭넓게 탐지했고, 세 조직에서는 활동을 폭넓게 재구성했다고 보고한다. 이는 인터뷰 결과이며, 배포된 시스템에 대한 독립적 인증은 아니다.
이 수치가 주목할 만한 이유는 서로 다른 역량과 관련되기 때문이다. 예상치 못한 행동을 탐지하고, 그 순서를 재구성하며, 그 결과를 바로잡는 일은 각각 별개의 운영 성과다. 앞선 단계에서의 성공이 다음 단계에서의 성공을 입증하지는 않는다.
그러나 이 표본만으로 대부분의 기업이 AI 사고에서 복구할 수 없다는 제목을 뒷받침할 수는 없다. 또한 어느 플랫폼, 아키텍처 또는 산업이 가장 뛰어난지도 확정할 수 없다. 독자는 결과를 해석할 때 이 경계를 유지해야 한다.
유용한 변화는 구매자가 자신의 가정을 검토할 수 있는 실무자 증거가 공개됐다는 점이다. 이제 자신감에 관한 주장은 구체적인 후속 질문에 직면한다. 조직은 실제로 어떤 관련 사고를 훈련했는가?
이 질문은 에이전트의 임무가 좁은 경우에도 중요하다. 권한이 문서화돼 있고 정상적인 출력이 수용 가능해 보이기 때문에 배포가 통제된 것처럼 보일 수 있다. 그러나 어느 관찰도 잘못된 행동이 이러한 통제를 통과한 뒤 무슨 일이 일어나는지 답해주지는 않는다.
배송 주소를 업데이트하고 확인 메시지를 보내는 가상의 고객 서비스 워크플로를 생각해 보자. 에이전트는 잘못된 계정을 선택하지만 승인된 연결을 사용한다. 인증은 성공하고 애플리케이션은 업데이트를 받아들이며 메시지는 시스템을 떠난다.
모든 구성 요소가 각자의 설정대로 작동하더라도, 결합된 결과는 여전히 잘못될 수 있다. 이 사고는 유효한 작업과 유효하지 않은 비즈니스 결과 사이의 관계에 관한 문제다. 무단 접근에만 국한된 보안 조사는 이 차이를 놓치게 된다.
이 예시는 연구가 문서화한 사고가 아니라 가상의 사례다. 그 목적은 구매자가 준비됐다는 단일 주장으로 흔히 압축하는 질문들을 분리하는 데 있다. 접근 통제는 권한에 관한 것이고, 복구는 행사된 권한의 결과에 관한 것이다.
이 때문에 이 연구는 증거에 대한 도전으로 읽는 것이 가장 적절하다. 조직은 미해결 한계를 드러내는 시연을 포함해 관련 시연으로 답할 수 있다. 근거 없는 확신은 문서화되고 범위가 제한된 복구 역량보다 덜 유용한 정보를 제공한다.
이러한 틀은 모든 에이전트 배포를 똑같이 중대한 것으로 취급하는 것도 피한다. 내부 요약을 작성하는 일과 고객 계정을 변경하는 일은 서로 다른 의무를 만든다. 복구 증거의 강도는 실제로 부여된 권한을 반영해야 한다.
비즈니스 소유자는 권한 있는 실수의 결과를 떠안는다
압박은 에이전트를 운영하는 사람뿐 아니라, 수정된 비즈니스 결과를 받아들여야 하는 사람에게도 가해진다.
기술 팀은 기록이 상업적으로 정확한지 판단하지 않고도 애플리케이션이 사용 가능하다는 사실을 확인할 수 있다. 이 차이는 고객, 거래, 외부 커뮤니케이션을 연결하는 워크플로에서 뚜렷해진다.
가상의 배송 사례에서 주소 필드를 복원하는 것은 문제의 일부만 해결한다. 배송 물품은 이미 잘못된 위치로 이동하고 있을 수 있다. 고객 역시 이제 수정이 필요한 확인 메시지에 의존하고 있을 수 있다.
중요한 분석적 요점은 복구에 새로운 조치가 필요할 수 있다는 것이다. 일부 결과는 복원만으로 지울 수 없다. 비즈니스 소유자는 어떤 시정 조치가 적절한지, 어떤 잔여 예외에 주의가 필요한지 결정해야 한다.
이로 인해 제품 시연으로는 좀처럼 해결되지 않는 조직적 의존성이 생긴다. 에이전트 운영자는 구성을 이해할 수 있지만 고객 구제 조치에 대한 권한은 없을 수 있다. 애플리케이션 소유자는 기록을 이해할 수 있지만 외부 약속에 대한 가시성은 부족할 수 있다.
따라서 조달은 더 까다로운 평가 질문에 직면한다. 공급업체는 제품이 에이전트를 중지하는 방법을 설명할 수 있지만, 구매자는 영향을 받은 업무를 바로잡기 위한 체계도 필요하다. 책임은 소프트웨어 역량과 운영 관행의 경계를 넘는다.
그렇다고 모든 공급업체가 가능한 모든 비즈니스 결과를 보장해야 한다는 뜻은 아니다. 그러한 약속은 정의하기도 어렵고 입증하기는 더 어렵다. 이는 구매자가 제품 지원이 끝나는 지점과 조직의 책임이 시작되는 지점을 명확히 파악해야 한다는 뜻이다.
같은 차이는 사람의 승인에 관한 주장에도 적용된다. 승인은 제시된 정보를 바탕으로 행동을 허가할 수 있다. 그러나 기초가 되는 계정, 문서 또는 거래가 올바르게 선택됐음을 보장할 수는 없다.
검토자가 정확한 문구를 담았지만 잘못된 주문을 참조하는 고객 메시지를 승인하는 상황을 상상해 보자. 언어 검토는 성공하지만 계정 연결은 여전히 잘못돼 있다. 승인 기록은 의사결정을 입증하지만, 그에 따른 수정 업무는 미해결 상태로 남는다.
지식 근로자에게 이는 어시스턴트를 업무 시스템에 연결하는 일의 의미를 바꾼다. 문서를 읽고, 응답을 작성하고, 그 응답을 보내는 일은 서로 다른 결과를 수반한다. 제품이 이를 같은 인터페이스에서 제공하면 편의성이 그러한 경계를 가릴 수 있다.
지식 관리에서도 유사한 차이가 나타난다. 정보를 찾는 일과 그 정보에 따라 행동하는 일에는 서로 다른 판단이 필요하다. 유용하게 검색된 문구는 의사결정에 정보를 제공할 수 있지만, 그 결정을 실행할 권한을 확립하지는 않는다.
따라서 기업 구매자는 결과를 초래하는 행동 단위에서 자율성을 검토해야 한다. 에이전트의 전체 업무 설명은 그것이 만들 수 있는 모든 약속을 설명하기에는 지나치게 광범위하다. 책임의 관련 단위는 행동과 그 효과다.
바로 이 지점에서 AI 에이전트 복구는 비즈니스 문제가 된다. 질문은 엔지니어링이 서비스를 복원할 수 있는지 여부를 넘어선다. 조직이 영향을 받은 당사자를 식별하고, 약속을 바로잡고, 남은 상태를 수용할 수 있는지도 포함한다.
ID와 모니터링은 문제의 서로 다른 부분을 다룬다
ID 통제는 누가 행동할 수 있는지를 확립하고, 모니터링은 그 권한이 사용된 뒤 어떤 일이 일어났는지 설명하는 데 도움을 준다.
Microsoft가 공개한 에이전트 ID 통제는 전용 ID, 지정된 소유자, 좁게 설정된 권한, 통제된 도구 접근을 강조한다. 최소 권한은 정의된 작업에 필요한 접근 권한만 부여하는 것을 의미한다. Microsoft는 연결된 시스템 전반의 행동을 기록하고 권한 철회를 테스트할 것도 권고한다.
AWS는 실행 가시성을 통해 관련 문제에 접근한다. 에이전트 워크플로 추적 문서는 AgentCore Observability를 통해 실행 경로, 중간 출력, 운영 지표를 검사하는 방법을 설명한다. 관측 가능성은 기록된 시스템 활동을 활용해 행동을 이해하는 것을 의미한다. AWS는 표준화된 텔레메트리를 통해 기존 모니터링 시스템과 통합하는 방식을 문서화한다.
이러한 역량은 동일한 사고에서 서로 다른 위치를 차지한다. ID는 에이전트가 어떤 권한을 보유했는지 판단하는 데 도움을 준다. 실행 기록은 조사자가 에이전트가 그 권한을 어떻게 사용했는지 추적하는 데 도움을 준다.
이 비교가 Microsoft와 AWS 사이의 승자를 정하는 것은 아니다. 두 문서는 겹치지만 서로 다른 요구사항을 다루며, 제품 적합성은 배포 방식에 따라 달라진다. 어느 출처도 구매자의 전체 복구 프로세스를 독립적으로 검증하지는 않는다.
theCUBE AI 회복탄력성 연구에 이 차이는 중요한 시장 맥락을 제공한다. 구매자는 이미 검토할 수 있는 문서화된 구성 요소를 갖고 있다. 미해결 질문은 이들이 조합한 환경이 기대하는 결과를 지원하는지 여부다.
가상의 주문 관리 에이전트는 이러한 요소를 조합하는 일이 왜 중요한지 보여준다. 그 ID는 고객 조회와 배송 변경을 허용할 수 있다. 실행 기록에는 계정을 선택하고 업데이트를 성공적으로 제출했다는 내용이 남을 수 있다.
이 기록은 순서를 확립하는 데 도움이 되지만, 선택된 계정이 올바른지 판단하려면 추가 증거가 필요하다. 애플리케이션에는 과거 기록이나 거래 세부 정보가 필요할 수 있다. 고객 운영 부서는 커뮤니케이션과 이행 활동을 검토해야 할 수 있다.
따라서 성공적인 도구 호출은 중간 관찰 결과다. 이는 요청이 해당 요청을 받아들인 작업에 도달했다는 사실을 말해준다. 그 자체만으로는 요청이 올바른 비즈니스 목적을 수행했음을 입증하지 않는다.
이 차이는 제품 주장을 평가할 때도 중요하다. 에이전트의 순서를 보여주는 시연은 가시성에 관한 주장을 뒷받침할 수 있다. 무단 작업을 거부하는 시연은 접근 강제에 관한 주장을 뒷받침할 수 있다.
복구에 관한 주장은 다른 시연을 요구한다. 평가자는 영향을 받은 업무가 식별되고, 수정이 완료되며, 그 결과가 수용되는 모습을 확인해야 한다. 더 좁은 시연을 이처럼 광범위한 주장으로 확장하면 증거를 과장하게 된다.
구매자에게 이는 문제를 기능 체크리스트로 축소하지 않으면서 실용적인 비교 틀을 제공한다. 서로 다른 제품은 서로 다른 단계에서 유용한 증거를 제공할 수 있다. 이러한 단계들이 연결되는지 판단하는 책임은 조직에 남아 있다.
상업적 함의는 명확하다. 공급업체는 자신이 제공하는 보장의 범위를 정확히 설명해야 한다는 압박을 받는다. 분명한 한계는 구매자가 제품을 통합하는 데 도움을 준다. 신뢰에 관한 모호한 주장은 어떤 운영상 격차가 여전히 고객의 책임인지 판단하기 어렵게 만든다.
행동 권한은 프롬프트로 해결할 수 없는 상충 관계를 만든다
핵심 상충 관계는 위임된 권한과 조직이 탐지하고, 억제하고, 바로잡을 수 있는 결과 사이에 있다.
OWASP Gen AI Security Project는 과도한 자율성을 과도한 기능, 권한 또는 자율성으로 인해 가능해지는 피해 행위로 설명합니다. 이 프로젝트의 지침에는 도구 기능 제한, 권한 최소화, 중요한 결과를 초래하는 작업에 대한 승인 요구, 후속 시스템에서의 권한 부여 강제가 포함됩니다.
OWASP는 이메일 보조 도구의 시나리오도 제시합니다. 메시지를 요약하도록 설계된 소프트웨어에 불필요한 발송 기능이 부여되는 경우입니다. 그러면 악성 메시지 콘텐츠가 이 추가 기능을 통해 정보 공개를 유도할 수 있습니다. 이 사례에서 조작을 가능하게 하는 것은 신뢰할 수 없는 콘텐츠에 삽입된 지시문인 프롬프트 인젝션입니다.
이 시나리오는 연결된 모든 보조 도구를 동일하게 취급해야 한다는 근거가 아니라, 경계 설정의 문제를 보여 줍니다. 읽기와 전송은 서로 다른 노출 위험을 만듭니다. 이를 하나로 묶는 제품은 신뢰할 수 없는 콘텐츠를 잘못 해석했을 때의 결과를 바꿉니다.
더 넓은 분석적 함의는 지시와 권한이 서로 다른 계층에 존재한다는 점입니다. 프롬프트는 의도된 작업을 설명할 수 있습니다. 그러나 주변 시스템은 모델이 해당 작업을 잘못 해석하더라도 어떤 작업이 계속 가능할지를 결정합니다.
내부 정책의 개정안을 제안해야 하는 가상의 문서 보조 도구를 생각해 봅시다. 그 임무는 소박해 보이지만, 직접 게시 권한은 별도의 책임을 만듭니다. 잘못된 초안과 잘못 게시된 정책은 서로 다른 대응을 요구합니다.
게시 권한을 제거하면 초안 작성의 유용성은 유지하면서 즉각적인 결과를 줄일 수 있습니다. 신중하게 범위를 한정한 워크플로에서는 해당 권한을 유지하는 것이 정당화될 수도 있습니다. 결정은 실행의 가치와 조직이 예외 상황을 처리할 수 있는 능력에 달려 있습니다.
이는 최소 자율성을 위한 보편적 주장이 아니라 균형의 문제입니다. 지나친 제한은 배포가 제공하려 했던 운영 가치를 없앨 수 있습니다. 과도한 권한은 조직이 한 번도 평가하지 않은 책임을 만들 수 있습니다.
에이전트 보안 테스트는 잘못된 결정 상황에서 그 경계를 살필 때 유의미해집니다. 의도된 워크플로가 성공적으로 시연되면 유용성을 보여 줍니다. 통제된 실패 시연은 유용성이 무너질 때 배포 환경이 어떻게 작동하는지를 보여 줍니다.
이 차이는 구매자가 완성도 높은 시연을 해석하는 방식을 바꿉니다. 올바른 실행은 시연된 조건에서 시스템이 과업을 수행할 수 있음을 보여 줍니다. 하지만 잘못된 대상이나 작업이 그럴듯해 보일 때 어떤 일이 발생하는지는 여전히 답하지 못합니다.
반복적인 승인 절차가 이런 불확실성을 자동으로 해소하지는 않습니다. 검토자는 의미 있는 결정을 내릴 수 있도록 충분한 관련 정보를 받아야 합니다. 영향을 받는 기록을 숨기는 승인 인터페이스는 판단 근거를 감춘 채 통제의 외관만 유지할 수 있습니다.
이는 보안 아키텍처뿐 아니라 제품 설계에도 부담을 줍니다. 인터페이스는 중요한 선택이 의미를 갖는 지점에서 이를 드러내야 합니다. 그렇지 않으면 조직은 검토자가 충분히 평가할 수 없는 절차를 통해 권한을 위임하게 됩니다.
AI 에이전트 복구가 주는 교훈은 되돌릴 수 있는 능력이 자율성 결정에 포함돼야 한다는 점입니다. 조직은 실행을 초안 작성의 일반적인 확장으로 취급하기 전에 수정 부담을 이해해야 합니다. 이점과 책임은 함께 따라옵니다.
소규모 연구는 여전히 많은 질문을 남긴다
가장 강력한 결론은 복구 관련 주장은 더 나은 근거가 필요하며, 더 광범위한 문제의 발생 빈도와 심각성은 여전히 불확실하다는 점입니다.
인터뷰 연구는 광범위한 설문조사가 놓치는 차이를 드러낼 수 있습니다. 그러나 용어, 응답자의 지식, 해석의 차이도 반영할 수 있습니다. 부분적인 훈련을 설명하는 조직은 운영 준비 상태를 설명하는 다른 조직과 다른 기준을 사용할 수 있습니다.
이런 불확실성은 응답자 간 비교를 제한합니다. 또한 보고된 수치를 바탕으로 산업을 순위화하거나 예상 손실을 추정하려는 시도도 제한합니다. 그런 판단에는 해당 목적에 맞게 설계된 추가 근거가 필요합니다.
따라서 theCUBE AI 회복력 연구는 보편적 판정이 아니라 조사를 촉발해야 합니다. 구매자는 일반화에 신중하면서도 이 연구가 제기한 질문을 진지하게 받아들일 수 있습니다. 우려와 통계적 확실성은 서로 다른 문제입니다.
또 다른 해석상의 한계도 있습니다. 보고된 훈련이 없다고 해서 모든 관련 통제가 없다는 뜻은 아닙니다. 기존 거래 보호 장치는 특정 배포 환경을 제한할 수 있습니다. 그것이 충분한지는 워크플로에 달려 있습니다.
반대 방향의 추론도 마찬가지로 약합니다. 기존 애플리케이션 사고에 익숙하다고 해서 모든 에이전트 기반 시퀀스에 대비됐다는 의미는 아닙니다. 관련 경험은 출발점을 제공하지만, 확장되는 각각의 권한은 평가 대상 조건을 바꿉니다.
표준화 작업 역시 신중하게 해석해야 합니다. NIST의 National Cybersecurity Center of Excellence는 에이전트 식별과 접근 및 행동 관리를 위한 표준 기반 접근법을 포함해 에이전트 권한 부여를 탐색하는 작업을 설명합니다. 이 작업은 거버넌스 문제의 맥락을 제공하지만 특정 기업 배포 환경을 인증하지는 않습니다.
구매자에게 이 구분은 흔한 범주 오류를 막아 줍니다. 지침과의 정합성은 설계 선택을 설명할 수 있습니다. 인증, 독립적 검증, 성공적인 운영 훈련은 각각 고유한 근거가 필요한 별도의 주장입니다.
마찬가지로 통제된 테스트는 그 조건이 뒷받침하는 것만 입증할 수 있습니다. 선택된 애플리케이션을 포함하는 훈련은 연결된 모든 서비스에 관한 질문을 해결할 수 없습니다. 조직이 시연된 역량과 테스트되지 않은 경계를 모두 문서화할 때 그 가치는 커집니다.
가상의 실패 시나리오에도 표기가 필요합니다. 이는 특정 조직에서 실제로 발생했음을 증명하지 않고도 메커니즘을 명확히 할 수 있습니다. 예시 시나리오를 관찰된 사고와 혼동하면 이용 가능한 근거를 과장하게 됩니다.
따라서 신뢰할 수 있는 분석은 여러 관점을 보존합니다. 연구자는 더 강력한 시연을 합리적으로 요구할 수 있습니다. 공급업체는 자사 제품이 제공하는 기능을 합리적으로 설명할 수 있습니다. 실무자는 운영 제약과 기존 보호 장치를 합리적으로 지적할 수 있습니다.
해결되지 않은 문제는 이러한 관점이 특정 배포 환경에서 어떻게 연결되는가입니다. 구매자는 불가능한 보장을 요구하지 않으면서도 그 연결을 평가할 만큼 충분한 세부 정보를 필요로 합니다. 근거는 남은 불확실성을 감추기보다 드러내야 합니다.
이는 새로운 복구 제품을 바라보는 적절한 회의적 관점이기도 합니다. 설득력 있는 시연은 주목할 가치가 있지만, 그 범위는 주장과 일치해야 합니다. 좁은 성공이 더 넓은 질문의 답으로 제시될 때에만 오해를 낳습니다.
다음 근거는 통제뿐 아니라 수정도 보여야 한다
단기적으로 가장 유용한 신호는 입증된 복구, 연결된 근거, 자율성에 관한 명시적 결정입니다.
앞으로 몇 달 동안 주목해야 할 첫 번째 신호는 상세한 고객 훈련 사례의 공개입니다. 유용한 사례는 워크플로, 잘못된 조치, 영향을 받은 기록, 수용된 수정 방안을 설명할 것입니다. 또한 해당 훈련이 해결하지 못한 사항도 공개해야 합니다.
이러한 근거는 기업이 우려를 운영 역량으로 전환하고 있다는 주장을 강화할 것입니다. 자신감에 관한 진술에만 국한된 보고서는 핵심 불확실성을 그대로 남깁니다. 구매자는 설명된 의도와 관찰된 결과를 구분해야 합니다.
두 번째 신호는 제품 시연이 사고의 단계를 연결하는지에 관한 것입니다. 평가자는 동일한 시나리오를 통해 권한, 실행, 결과, 수정을 추적할 수 있어야 합니다. 각 기능을 따로 시연하면 통합에 관한 질문은 남습니다.
이것이 단일 공급업체가 모든 구성 요소를 보유해야 한다는 뜻은 아닙니다. 배포 환경은 제품과 조직 절차를 결합할 수 있습니다. 관련 근거는 그 결합이 주장하는 조건에서 작동하는지 여부입니다.
더 강력한 시연은 프로세스가 제품 경계를 넘을 때 책임 소재를 명확히 보여 줄 것입니다. 다음 결정을 제공하는 팀이 누구인지, 어떤 근거가 그 결정을 뒷받침하는지를 보여 줄 것입니다. 누락된 전환은 고객에게 남아 있는 업무를 드러낼 것입니다.
세 번째 신호는 조직이 추가 자율성을 실수 처리 능력의 입증과 연결하는지 여부입니다. 의미 있는 결정은 어떤 작업이 권한을 얻었고, 왜 이를 뒷받침하는 근거가 충분했는지를 설명할 것입니다. 조건 없는 확장은 신뢰를 덜 제공합니다.
이러한 신호는 서로 다른 방식으로 이 글의 핵심 판단을 강화하거나 약화할 것입니다. 문서화된 수정은 정의된 배포 환경에 대한 신뢰를 뒷받침할 것입니다. 그에 상응하는 근거 없는 추가 권한은 야심과 확립된 역량 사이의 격차를 유지할 것입니다.
개발자에게 이는 잘못된 조치 이후 애플리케이션이 무엇을 입증할 수 있는지에 관심을 돌리게 합니다. 비즈니스 구매자에게는 운영 의존성을 받아들이기 전에 요구할 근거를 바꿉니다. 지식 근로자에게는 초안 작성과 실행이 서로 다른 기대를 가져야 하는 이유를 명확히 합니다.
더 넓은 함의는 설득력 있는 엔터프라이즈 AI 시연의 기준이 바뀐다는 점입니다. 과업 완료는 유용성을 평가하는 데 여전히 필요합니다. 잘못된 과업의 결과를 처리하는 능력은 위임된 권한을 평가할 때 필요해집니다.
theCUBE AI 회복력 연구는 구매자에게 이 두 번째 요건을 살펴볼 구체적인 이유를 제공합니다. 작은 표본은 많은 문제를 남기지만, 이 연구가 제기하는 질문은 개별 배포 환경에서 조사할 수 있습니다. 따라서 이를 업계 전반의 결론으로 부풀리지 않으면서도 실행 가능한 문제로 만듭니다.
에이전트의 권한을 확대하기 전에, 위임하려는 업무와 유사한 워크플로의 근거를 요청하십시오. 시연이 어떤 결과를 수정했는지, 어떤 결과에 인간의 판단이 필요했는지 살펴보십시오. 비즈니스 책임자에게 어떤 조건이라면 결과 상태를 수용할 수 있는지 물어보십시오. 이러한 답변은 제품의 신원 및 모니터링 관련 주장과 함께 보관하십시오. 각각은 결정의 서로 다른 부분을 다루기 때문입니다. 유용한 결과는 배포 환경이 오늘 처리할 수 있는 일과 아직 테스트되지 않은 일을 명확히 설명하는 것입니다. 귀사라면 어떤 중요한 결과를 초래할 수 있는 워크플로를 먼저 검토할 의향이 있으며, 운영 상태로의 복귀를 신뢰할 만한 근거는 무엇일까요?
