Fleet AI 거버넌스, IT의 기존 워크플로에 직원 기기 감독 기능 통합
Fleet가 직원 컴퓨터를 위한 AI 거버넌스 기능을 발표하며, 관리되지 않는 업무용 AI에는 별도의 보안 제품이 필요하다는 인식에 도전장을 던졌다. Fleet AI 거버넌스는 관리자가 이미 설치된 소프트웨어와 기기 정책을 다루는 기기 관리 워크플로 안에 감독 기능을 배치한다. 그 대가는 결코 가볍지 않다. 더 깊은 가시성은 위험한 활동을 식별하는 데 도움이 될 수 있지만, 세션 검사는 직원과 회사 정보를 보호해야 하는 추가적인 책임을 수반한다.
회사는 2026년 10월 15일 이 기능을 발표했다. SecurityBrief UK는 10월 29일 직원 기기 감독 관련 보도를 게재했다. 이는 새로운 헤드라인이 새로운 출시일을 입증하거나 모든 기능의 제공 여부를 확인해 주지는 않는다는 점에서 중요하다.
Fleet는 Jamf가 이미 Mac에서 겨냥하고 있는 영역에도 진입하고 있다. 핵심 경쟁은 기존 기기 관리 체계 안에서 거버넌스를 통합하는 방식과, 특정 애플리케이션·브라우저·데이터 흐름을 중심으로 전문 통제를 구성하는 방식 사이에 있다. 구매자에게 중요한 질문은 또 하나의 민감 정보 집합을 만들지 않으면서 신뢰할 수 있는 증거를 제공하는 접근법이 무엇인지다.
Fleet AI 거버넌스는 관리형 컴퓨터에서 시작된다
Fleet의 AI 거버넌스 발표는 macOS, Windows, Linux 전반의 신규 및 출시 예정 기능을 설명한다. 제안된 범위에는 설치된 AI 소프트웨어, 사용량 측정, 세션 맥락, 거버넌스 워크플로가 포함된다. Fleet는 자사의 무료 제공 서비스에서 AI 인벤토리와 가시성을 이용할 수 있다고 말한다.
회사는 AI 애플리케이션을 외부 도구 및 정보와 연결하는 에이전트, 스킬, 플러그인, Model Context Protocol 서버를 포괄하는 인벤토리를 설명한다. 또한 모델이 처리하는 텍스트 단위를 측정하는 토큰 추적과 프롬프트 및 응답에 대한 가시성도 언급한다. 이는 모든 애플리케이션에 걸쳐 독립적으로 입증된 범위라기보다 제품 범위에 관한 회사의 주장이다.
이번 발표의 핵심 변화는 조직적이다. Fleet는 AI 감독을 일상적인 기기 관리의 일부로 만들고자 한다.
엔드포인트는 조직 시스템에 연결되는 직원 컴퓨터 또는 기타 기기다. 여기서 시작하면 관리자가 던질 수 있는 질문도 달라진다. 조달 기록은 승인된 구매를 식별하지만, 기기 증거는 실제로 어떤 항목이 기기에 존재하는지 확인하는 데 도움이 된다. 두 기록은 관련된 목적을 수행하지만 동일한 질문에 답하지는 않는다.
예시로 개발자 워크플로를 생각해 보자. 직원이 코딩 어시스턴트 사용 승인을 받고, 추가 플러그인을 설치한 뒤 문서 저장소와 연결한다. 원래 애플리케이션에 대한 승인은 추가 구성 요소에 관해 거의 알려주지 않는다. 유용한 거버넌스 시스템이라면 승인된 애플리케이션과 새 연결 및 그 권한을 구분할 수 있어야 한다.
이 예시는 Fleet가 모든 단계를 탐지한다는 사실을 입증하지는 않는다. 애플리케이션 이름만으로는 의사결정의 불완전한 근거가 되는 이유를 설명한다. 구매자는 익숙한 제품과 해당 제품의 특정 구성 간 차이를 이해할 만큼 충분한 세부 정보를 필요로 한다.
따라서 Fleet AI 인벤토리는 조치를 뒷받침할 때 가장 중요하다. 설치된 도구 목록은 관리자가 소유자를 식별하고, 구성을 평가하며, 예외 사항을 처리할 수 있을 때 운영상 유용해진다. 이러한 연결이 없다면 발견 기능은 수동 조사가 필요한 또 하나의 보고서가 될 위험이 있다.
이번 발표는 구성 정보를 파일에 저장하는 infrastructure as code와 버전 관리 검토를 통해 변경을 관리하는 GitOps를 사용해 검토 가능한 거버넌스 변경도 설명한다. 이 접근법은 관찰에서 승인된 변경으로 나아가는 제안된 경로를 관리자에게 제공한다. 다만 의도한 설정이 대상 컴퓨터 모두에 적용됐다는 사실을 독립적으로 입증하지는 않는다.
이 구분은 이번 출시를 평가하는 기준을 설정한다. 발견, 정책 배포, 시행 확인은 별개의 기능이다. 기존 플랫폼에서 이를 결합하는 것은 매력적인 제안이지만, 각 연결에는 여전히 증거가 필요하다.
IT 팀은 조달 부서가 해결할 수 없는 결정을 떠안는다
즉각적인 부담은 직원 기기를 담당하는 관리자와 보안 팀에 돌아간다. 승인된 애플리케이션 목록만으로는 설치된 구성 요소, 개인 계정 또는 업무 파일 접근에 관한 모든 문제를 해결할 수 없다. Fleet의 발표는 이 팀들이 소프트웨어 환경을 관리하는 데 더 직접적인 역할을 맡도록 요구한다.
기기 가시성은 의사결정을 일상 업무에 더 가깝게 가져오지만, 동시에 책임 소재를 피하기 어렵게 만든다.
인벤토리 항목만으로는 특정 업무에 도구가 적절한지 조직이 판단할 수 없다. 코딩 어시스턴트는 공개 문서에는 허용될 수 있지만 미출시 제품 코드에는 제한될 수 있다. 누군가는 이 구분을 직원이 이해하고 관리자가 시행할 수 있는 규칙으로 옮겨야 한다.
보안 팀은 낯선 소프트웨어와 유해한 행동도 구분해야 한다. 새로 발견된 모든 도구를 사고로 취급하면 피할 수 있는 혼란이 발생한다. 익숙한 모든 공급업체를 안전하다고 취급하면 계정, 확장 기능, 권한, 대상의 차이를 간과하게 된다.
따라서 실질적인 부담은 기술적일 뿐 아니라 해석의 문제이기도 하다. 마감이 임박한 프로젝트의 예외를 누가 승인하는가? 플러그인의 접근 권한이 적절한 수준인지 누가 결정하는가? 관리자가 도구를 제거하거나 권한을 제한할 때 무엇이 바뀌었는지 직원에게 누가 알리는가?
이 질문들은 통합의 한계를 드러낸다. 기존 관리 콘솔은 사람들이 확인해야 할 장소 수를 줄일 수 있다. 하지만 엔지니어링, 보안, 프라이버시, 사업 책임자 간의 이견을 자동으로 해결할 수는 없다. 이들 그룹은 여전히 공동의 의사결정 절차를 필요로 한다.
지식 근로자는 이 과정에 직접적인 이해관계를 가진다. 인터뷰 메모를 정리하기 위해 어시스턴트를 사용하는 연구자는 어떤 자료를 워크플로에 넣어도 되는지 이해해야 한다. 내부 논의를 요약하는 제품 관리자는 기밀 콘텐츠와 승인된 대상에 대해 똑같이 명확한 지침이 필요하다.
개인 지식 관리와 회사가 통제하는 정보 사이의 구분은 유용한 출발점을 제공한다. 개인적 편의가 조직의 접근 규칙을 결정하지는 않는다. 마찬가지로 회사의 정보 보호 필요성이 모든 직원 상호작용을 무제한으로 검사해야 한다는 뜻도 아니다.
Fleet 엔드포인트 보안은 조직이 이러한 구분을 일관되게 내리는 데 도움이 된다면 더 큰 가치를 제공한다. 예를 들어 관리자는 발견 사항을 지정된 책임자 및 문서화된 대응과 연결할 수 있는 것이 이상적이다. 발표만으로는 그러한 완전한 운영 절차가 입증되지 않는다.
배포 이후에는 책임성 문제도 있다. 팀이 구성을 승인했다면, 누군가는 그것이 여전히 애플리케이션의 동작과 일치하는지 검토해야 한다. 권한, 통합 또는 업무 관행이 바뀌면 과거의 승인은 오해를 낳을 수 있다.
그 결과 압력은 구체적이다. IT는 소프트웨어 식별을 넘어 그 사용에 대한 정당한 결정을 유지해야 한다. 이는 애플리케이션을 배포하는 것보다 더 광범위한 책임이다. Fleet의 접근법은 관련 증거를 익숙한 영역으로 가져오지만, 판단의 책임은 조직에 남긴다.
기존 기기 플랫폼은 적용 범위와 통제 깊이로 경쟁한다
Fleet의 통합 주장은 분명한 업계 비교 대상이 있다. Jamf는 2026년 6월 30일 Mac AI 거버넌스 기능의 정식 출시를 발표했다. 회사에 따르면 Mac 거버넌스 통제 기능은 처음에 Claude Code, Claude Desktop, OpenAI Codex를 지원했다.
Jamf는 모델 접근, 계정 테넌시, 네트워크 권한, 파일 접근, MCP 제한을 포괄하는 통제를 설명한다. 이 세부 사항은 유용한 비교 기준을 제시한다. 애플리케이션을 식별하는 것과 허용되는 동작을 구성하는 것은 서로 다른 수준의 적용 범위다.
의미 있는 경쟁은 AI 거버넌스를 소유한다는 상충된 주장보다 입증 가능한 통제 기능 사이에서 벌어진다.
Fleet가 밝힌 범위는 서로 다른 운영 체제를 실행하는 직원 컴퓨터에 걸쳐 있다. Jamf의 발표는 Mac에 집중한다. 혼합 환경에서는 더 넓은 운영 체제 범위가 감독을 단순화할 수 있다. 특화된 환경에서는 상세한 애플리케이션 통제가 플랫폼의 폭보다 더 큰 비중을 가질 수 있다.
어느 쪽의 장점도 그 자체로 구매 결정을 내리지는 못한다. 크로스 플랫폼 인벤토리가 모든 운영 체제에서 동등한 시행을 보장하지는 않는다. 선택된 애플리케이션에 대한 세부 설정도 낯선 도구까지 포괄한다는 사실을 입증하지 않는다. 구매자는 지원 기기, 지원 애플리케이션, 지원 조치가 만나는 지점을 검토해야 한다.
Microsoft는 또 다른 경계를 보여준다. 타사 AI 보호 기능에 관한 문서는 외부 AI 서비스와의 브라우저 상호작용을 위한 Purview 기능을 설명한다. 다수의 기능은 기기 온보딩과 브라우저 확장 프로그램을 요구하며, 다른 접근법은 브라우저 또는 네트워크 통합에 의존한다.
민감 정보 전송을 식별하거나 제한하는 데이터 손실 방지는 설치된 소프트웨어 인벤토리와는 다른 질문을 다룬다. 도구의 존재를 아는 것은 관리자의 조사에 도움이 된다. 특정 문서가 특정 대상으로 전송되는 것을 막으려면 해당 전송 경로 전반의 가시성과 통제가 필요하다.
이러한 접근법은 서로 보완할 수 있다. 기기 관리는 소프트웨어 및 구성 맥락을 제공할 수 있고, 브라우저 통제는 지원되는 웹 상호작용을 다룰 수 있다. 누가 또는 무엇이 리소스에 접근할 수 있는지를 결정하는 ID 통제는 또 다른 필수 관점을 더한다. 여기서 검토한 어떤 발표도 이러한 경계를 아우르는 보편적 적용 범위를 입증하지 않는다.
이 때문에 Fleet의 주장은 관리 조정에 관한 제안으로서 가장 강력하다. 이미 해당 플랫폼을 사용하는 조직은 AI 발견 사항이 기존 대응 절차에 맞는지 평가할 수 있다. 다만 추가 통제가 필요한 영역은 여전히 테스트해야 한다.
이 비교는 구매자가 “또 하나의 도구”를 해석하는 방식도 바꾼다. 추가 에이전트나 콘솔을 피하면 관리 부담을 줄일 수 있지만, 중복되는 제품이 때로는 서로 다른 위험을 다룬다. 중복 구매를 없애는 것은 어떤 보호 기능이 남는지 확인한 뒤에만 타당하다.
Fleet AI 거버넌스는 이러한 실질적 비교에 속한다. 그 가치는 관련 변경 사항을 발견하고, 책임을 할당하며, 정당한 제한을 적용하고, 결과를 확인하는 데 도움을 주는 작업에 달려 있다. 통합 인터페이스는 이러한 업무를 수행하고 평가하기 쉬워질 때 유용하다.
직원에게 해당하는 이점은 더 명확한 경계가 될 것이다. 승인된 워크플로는 직원이 사용하는 컴퓨터 전반에서 예측 가능하게 유지되어야 한다. 거버넌스가 설명 없는 일관성 부족한 제한을 만든다면, 관리자 측에서의 통합은 직원에게 거의 안도감을 주지 못할 것이다.
세션 가시성은 두 번째 정보 위험을 만든다
Fleet의 발표는 팀이 사용자가 AI 도구에 보내는 내용과 해당 도구가 반환하는 내용을 검토할 수 있게 하는 세션 컨텍스트를 설명한다. 이 목표는 어떤 애플리케이션이 존재하는지 파악하는 수준을 넘어선다. 감독 시스템이 보호하려는 바로 그 민감한 자료를 다루게 될 가능성을 제기한다.
데이터 노출의 증거를 수집하면 민감한 데이터를 보호해야 하는 또 다른 장소가 생길 수 있다.
프롬프트에는 고객 문서에서 복사한 정보가 포함될 수 있다. 응답은 내부 저장소에서 검색한 자료를 재현할 수 있다. 감독 시스템이 둘 중 하나라도 보존한다면, 조직은 그 추가 기록에 대한 접근, 저장, 삭제 및 조사 방식을 고려해야 한다.
이는 아키텍처상의 우려이지, 공개된 Fleet 취약점의 증거는 아니다. 검토한 발표는 수집 기본값이나 보존에 관한 모든 질문에 답하지 않는다. 따라서 무제한 수집이나 포괄적인 개인정보 보호를 어느 한쪽으로 가정하기보다, 세션 가시성이 어떻게 작동하는지 물어볼 근거가 된다.
가상의 고객 지원 워크플로는 이러한 긴장을 보여 준다. 한 직원이 계정 세부 정보가 포함된 서비스 분쟁을 요약해 달라고 어시스턴트에게 요청한다. 보안 담당자는 그 정보가 승인되지 않은 목적지에 도달했는지 판단해야 할 수 있다. 그렇다고 전체 대화에 무기한 접근할 필요가 반드시 있는 것은 아니다.
관련 증거는 판단 내용에 따라 달라진다. 애플리케이션 인벤토리만으로도 승인되지 않은 설치를 식별하기에 충분할 수 있다. 목적지 기록은 승인되지 않은 연결을 입증할 수 있다. 전체 대화 내용은 더 상세한 조사를 뒷받침할 수 있지만, 동시에 수집된 자료의 민감도도 높인다.
이러한 구분은 배포 전 평가에 반영되어야 한다. 구매자는 애플리케이션, 그룹 또는 조사 목적별로 수집을 제한할 수 있는지 이해해야 한다. 또한 어떤 관리자가 콘텐츠를 볼 수 있는지, 그리고 접근 행위 자체가 감사 가능한 기록을 남기는지도 알아야 한다.
소스 코드를 검토할 수 있는 오픈 소스 소프트웨어는 기술 검토자가 수집 동작을 이해하는 데 도움이 될 수 있다. 하지만 특정 조직이 배포를 어떻게 구성했는지를 자동으로 입증하지는 않는다. 또한 그 조직 내부에서 누가 접근 권한을 받아야 하는지도 결정하지 않는다.
Jamf의 현재 제품 페이지는 유용한 설계상 대비를 제공한다. 이 페이지는 프롬프트를 수집하지 않고 지출을 추정하는 계획된 AI usage insights를 설명하며, 해당 인사이트는 곧 제공될 예정이라고 표시한다. 이것이 더 우수한 제품을 입증하는 것은 아니다. 사용량 측정과 콘텐츠 수집이 별도의 설계 선택일 수 있음을 보여 준다.
지출 분석 자체도 절제가 필요하다. 높은 사용량이 유용한 업무를 증명하지 않으며, 낮은 사용량이 낭비를 증명하지도 않는다. 가끔이지만 중대한 의사결정을 지원하는 도구는 하루 종일 일상적인 텍스트를 생성하는 애플리케이션보다 더 중요할 수 있다.
Fleet 엔드포인트 보안에서는 까다로운 균형이 요구된다. 조사 담당자는 일상적인 활동과 의미 있는 노출을 구분할 만큼 충분한 맥락이 필요하다. 직원은 관찰의 이해 가능한 한계를 필요로 하며, 관리자는 불필요한 접근을 막을 안전장치가 필요하다.
따라서 책임 있는 평가는 세션 검사가 존재하는지만 묻는 것보다 폭넓어야 한다. 이 기능이 어떤 정보를 수집하는지, 해당 정보가 어떤 문제를 해결하는지, 더 제한적인 기록으로도 충분한지를 묻는다. 더 큰 가시성은 조직이 이를 정당화하고 보호할 수 있을 때만 가치가 있다.
이 발표는 보편적인 제공 여부를 입증하지 않는다
이번 릴리스의 표현은 주의 깊게 살펴볼 필요가 있다. Fleet는 이 서비스를 “new and upcoming” 기능 아래에 묶어 소개한다. 이 표현은 발표된 모든 기능이 일반적으로 제공되거나, 기본으로 활성화되거나, 언급된 운영 체제 전반에서 동일하게 지원된다는 사실을 입증하지 않는다.
Fleet의 October product roadmap 역시 AI 소프트웨어 인벤토리, 스킬 가시성, 호스트 수준 에이전트 세션을 향후 3개월 동안 계획된 작업으로 분류한다. AI 거버넌스 대시보드는 더 장기적인 기회로 나열한다. 이 로드맵은 기능별 배포 확인이 아니라 계획의 맥락을 제공한다.
구매자는 발표된 방향성과 자체 배포 환경에서 검증할 수 있는 기능을 구분해야 한다.
이것이 출시를 무시해야 할 이유는 아니다. 제품 발표는 종종 확장 중인 기능 집합을 설명한다. 다만 폭넓은 출시 헤드라인을 나열된 모든 기능이 이미 제공되었다는 주장으로 바꾸지 말아야 할 이유다.
여기서 검토한 공개 자료는 실무적인 질문을 해결하지 못한다. 어떤 애플리케이션이 세션 정보를 노출하는가? 어떤 운영 체제가 특정 거버넌스 조치를 지원하는가? 수집에는 어떤 권한이 필요한가? 이러한 질문에는 플랫폼의 전반적인 범위에서 추론하기보다 제품 문서나 직접적인 검증이 필요하다.
Fleet AI 인벤토리는 무엇을 측정하는지에 따라 평가되어야 한다. 설치된 소프트웨어, 최근 실행, 활성 사용은 서로 다른 상태를 나타낸다. 휴면 애플리케이션은 현재 업무에 영향을 주지 않더라도 인벤토리에 나타날 수 있다. 수명이 짧은 프로세스는 일반적인 설치처럼 보이지 않더라도 중요할 수 있다.
같은 구분은 감지된 문제를 바로잡기 위한 조치인 수정에도 적용된다. 애플리케이션을 제거하는 것, 설정을 변경하는 것, 리소스 접근을 제한하는 것은 서로 다른 결과를 낳는다. 구매자는 하나에 대한 지원이 다른 것들에 대한 지원까지 입증한다고 가정해서는 안 된다.
검토 가능한 구성도 또 다른 예다. 제안된 변경 사항은 내부 검토를 통과하고도 디바이스에 도달하지 못할 수 있다. 디바이스는 설정을 수신하더라도 의도한 대로 적용하지 않을 수 있다. 강력한 증거라면 승인된 결정과 그 이후 관찰된 상태를 연결해야 한다.
이는 평가 요건이지, Fleet가 현재 이를 충족하지 못한다는 주장은 아니다. 이용 가능한 출처는 발표된 범위 전반에서 탐지 완전성이나 시행 신뢰성을 입증하는 독립 평가를 제공하지 않는다. 기사의 결론은 그보다 더 좁게 유지되어야 한다.
따라서 유용한 시연에는 예상 결과가 명확히 알려진 지원 워크플로가 포함되어야 한다. 원래의 디바이스 상태, 거버넌스 결정, 조치 후 상태를 보여 주어야 한다. 지원되지 않는 단계는 요약 상태 뒤로 사라지지 않고 그대로 보여야 한다.
같은 원칙은 개인정보 보호 약속에도 적용된다. 구매자는 투명성에 관한 일반적인 진술에 의존하기보다 세션 수집에 관한 구성별 답변을 요청해야 한다. 문서는 어떤 데이터가 표시되는지, 어디로 가는지, 누가 검토할 수 있는지를 명확히 해야 한다.
Fleet의 방향은 분명하다. 기존 관리 환경을 AI 감독으로 확장하는 것이다. 해결되지 않은 문제는 그 경로를 따라가는 각 기능의 성숙도다. 조달 결정은 검증된 기능을 따라야 하며, 로드맵 항목은 계속 지켜봐야 할 약속으로 남아야 한다.
릴리스 증거, 개인정보 기본값 및 운영 결과를 지켜봐야 한다
다음 신호는 기대를 부풀리기보다 제품을 명확히 해야 한다. Fleet AI 거버넌스에는 정의된 가치 제안이 있지만, 실질적인 가치는 구체적인 릴리스와 관찰 가능한 결과에 달려 있다. 향후 몇 달 동안 구매자는 이 순서대로 제공 여부의 증거, 수집 기본값, 실제 배포 경험을 지켜봐야 한다.
가장 강력한 후속 증거는 지원되는 기능과 문서화된 결과를 연결할 것이다.
첫째, 릴리스 노트와 지원 문서는 발표가 남긴 제공 여부의 질문을 해소해야 한다. 구매자는 어떤 기능이 출시되었고 어떤 애플리케이션과 운영 체제를 지원하는지 확인해야 한다. 출시됨, 프리뷰, 계획됨 기능을 명확히 구분하면 이 서비스에 대한 신뢰가 높아질 것이다.
그러한 증거는 비교도 더 유용하게 만든다. 공개된 지원 경계를 통해 조직은 배포 전에 공백을 식별할 수 있다. 이에 상응하는 기술적 세부 정보가 없는 광범위한 설명은 인터페이스가 더 정교해지더라도 기존의 불확실성을 해소하지 못한다.
둘째, 문서는 세션 정보를 둘러싼 기본값과 제어 수단을 설명해야 한다. 중요한 신호는 조직이 기능을 활성화하기 전에 수집을 이해하고 제한할 수 있는지다. 접근과 삭제에 대한 명확한 설명은 더 방어 가능한 배포 결정을 뒷받침할 것이다.
사용량 측정이 대화 캡처와 독립적으로 작동할 수 있다는 증거는 구매자가 더 제한적인 선택지를 평가하는 데 도움이 될 것이다. 반대로 수집 동작이 불명확하면 거버넌스 결정은 더 어려워진다. 핵심은 수집된 정보가 명시된 목적과 일치하는지다.
셋째, 고객 사례는 한계를 포함해 완료된 운영 작업을 설명해야 한다. 유용한 사례라면 관리자가 승인되지 않은 구성 요소를 어떻게 처리했는지, 또는 지원되는 구성을 어떻게 변경했는지 설명할 것이다. 또한 정당한 업무에 어떤 일이 발생했는지와 조직이 결과를 어떻게 확인했는지도 설명해야 한다.
가시성에 대한 칭찬만으로는 문서화된 대응보다 증거 가치가 낮다. 발견은 업무를 해결하기 전에 업무를 만들어 내기 때문에 이 구분은 중요하다. 인벤토리는 팀이 조사를 마무리하거나 정당한 변경을 적용하는 데 도움이 될 때 더 가치가 있다.
이러한 신호는 통합 논리도 검증할 것이다. 기존 디바이스 플랫폼이 일상적인 AI 감독을 잘 처리한다면, 구매자는 관리 중복을 줄일 구체적인 이유를 얻게 된다. 중요한 작업에 여전히 단절된 조사가 필요하다면, 전문화된 제어 수단의 필요성은 여전히 유효하다.
직원도 다른 관점에서 같은 증거를 지켜봐야 한다. 명확한 안내, 이해 가능한 제한, 예측 가능한 예외 처리 절차는 거버넌스가 승인된 업무를 지원한다는 점을 보여 줄 것이다. 설명 없는 모니터링과 일관성 없는 차단은 운영 설계가 수집 역량을 따라잡지 못했음을 시사할 것이다.
기업 구매자에게 다음 단계는 지원되는 워크플로에 대한 범위가 제한된 평가다. 공급업체에 발견, 그에 따른 결정, 그리고 조치가 작동했음을 확인하는 과정을 보여 달라고 요청하라. 시스템이 어떤 세션 데이터를 수집했는지와 어떤 관리자가 접근할 수 있었는지도 별도로 물어야 한다. 릴리스 증거가 이를 뒷받침할 때까지 계획된 기능은 승인 기준에서 제외하라. 지식 근로자라면 조직이 허용하는 도구와 정보를 평이하게 설명해 달라고 요청하라. Fleet의 접근 방식은 증거가 발표된 범위와 일치한다면 그러한 결정을 체계화할 실용적인 기반을 제공한다. 감독을 확대하기 전에 필요한 결과와 그 결과를 얻는 데 필요한 정보를 정하라. 팀은 관리하는 디바이스의 사용자에게 이 둘을 모두 설명할 수 있는가?
