ChatGPT 데스크톱 GovCloud 배포, AWS 제어 기능을 중심에 두다
AWS는 모델 요청을 정부 클라우드 인프라로 라우팅하는 동시에 주변 데스크톱 워크플로를 제한하는 ChatGPT 데스크톱 GovCloud 배포 가이드를 공개했다. 10월 30일 발표에서는 AWS GovCloud US-West에서 AWS의 관리형 모델 서비스인 Amazon Bedrock을 사용하는 통제된 로컬 설정을 설명한다. 이 변화로 기관은 평가를 위한 배포 경로를 확보하게 되지만, 워크로드 승인 권한은 여전히 각 기관의 보안팀에 남는다.
핵심적인 절충점은 제어 권한이 어디에 있느냐에 있다. 익숙한 데스크톱 인터페이스가 익숙한 계정 관리 방식의 적용을 의미하지는 않는다. AWS는 ChatGPT 워크스페이스 역할이 아니라 워크스테이션 정책과 AWS ID 권한으로 관리되는 설정을 설명한다. 기존 보안 경계 안에서 코딩 지원을 평가하는 조직에는 이 차이가 중요하다.
관련 비교 대상은 연결된 어시스턴트와 의도적으로 제한된 로컬 배포다. OpenAI의 호스팅 서비스와 Bedrock 기반 추론은 서로 다른 운영 방식이다. 구매자에게는 제한된 방식이 유용한 작업을 지원하는지, 충분한 근거를 제공하는지, 파일럿 종료 후에도 관리 가능한지가 핵심 질문이 된다.
ChatGPT 데스크톱 GovCloud 배포가 바꾸는 점
AWS는 보안팀이 더 넓은 그룹으로 접근 권한을 확대하기 전에 검토할 수 있는 배포 경로를 문서화했다.
AWS GovCloud 배포 안내는 AWS의 Virgil Ennes와 Sean Phuphanich가 작성했다. 이 문서는 모델 응답을 생성하는 처리 과정인 추론을 us-gov-west-1의 Bedrock Mantle로 보내는 로컬 데스크톱 사용 방식을 설명한다.
AWS는 Work와 Codex를 데스크톱 경험의 구성 요소로 제시한다. Work는 더 폭넓은 작업을 처리하고, Codex는 소프트웨어 개발을 담당한다. 기술 안내는 Codex 구성과 요청 경로 검증에 집중한다.
인증 구성에는 API 모드 로그인, 관리자가 관리하는 기기 정책, 이름이 지정된 AWS 프로필, 네트워크 제한이 포함된다. AWS 프로필은 인증 설정을 선택하는 이름 지정 구성이다. 안내의 예시는 codex-il5를 사용한다.
이 문서는 검토할 수 있는 구체적 구성을 제시한다. 특정 모델, 저장소, 기기 또는 작업을 기관이 승인했다는 뜻은 아니다. AWS는 해당 승인 결정을 고객 조직에 명시적으로 맡긴다.
이 차이는 발표 내용을 조달 논의에 반영하는 방식을 바꾼다. 제품 가용성은 조직이 검토할 수 있는 대상이 있는지에 답한다. 승인은 조직이 정의된 조건 아래 특정 사용을 수용하는지에 답한다. 이 두 결정을 합치면 설치와 운영 도입 사이에 필요한 작업이 가려진다.
보안팀에 유용한 출발점은 제안된 워크플로의 설명이다. 작업을 제출하는 사람, 로컬에서 사용할 수 있는 파일, 모델 요청을 받는 목적지를 식별해야 한다. 이어서 응답을 받은 뒤 어시스턴트가 변경할 수 있는 대상을 파악해야 한다. 이 질문들은 광범위한 도입을 논의하기 전에 검토 가능한 제안을 만든다.
가상의 기관 유지보수 팀이 내부 애플리케이션을 검토한다고 가정해 보자. 첫 파일럿에서는 어시스턴트에게 샘플 모듈을 설명하고 패치를 제안하도록 요청할 수 있다. 팀은 변경을 허용하기 전에 제안을 검토한다. 이 사례는 범위가 제한된 평가를 보여 주는 것이며, AWS의 발표가 이러한 결과를 낸 기관 배포를 보고한 것은 아니다.
이 구분은 커뮤니케이션팀이 이번 출시를 정확하게 설명하는 데도 도움이 된다. “Bedrock을 통한 데스크톱 접근”은 배포 옵션을 뜻한다. 모든 ChatGPT 기능이 이제 GovCloud 내부에서 작동한다는 주장은 각 기능과 종속성에 대한 별도 근거를 필요로 한다.
따라서 이 발표의 실질적 의미는 구체적이다. 기술 검토자가 로컬 클라이언트, AWS 추론 목적지, 시행 가능한 제한 사항을 함께 검토할 수 있는 공통 출발점을 제공한다. 이 조합이 특정 조직의 요구를 충족하는지는 별도의 근거 기반 결정으로 남는다.
보안팀이 운영 결정을 맡게 된다
승인된 AWS 환경으로 추론을 옮기면 검토 절차는 달라지지만, 데스크톱에 대한 책임이 사라지는 것은 아니다.
직접적인 부담은 엔드포인트, ID, 소프트웨어 제공을 책임지는 담당자에게 돌아간다. 유용한 파일럿을 위해서는 이들의 결정이 일치해야 한다. 데스크톱 관리자는 애플리케이션을 제한할 수 있지만, ID 관리자는 과도한 접근 권한을 부여할 수 있다. 범위가 좁은 ID 권한도 지나치게 허용적인 워크스테이션과 공존할 수 있다.
어느 한 팀도 전체 배포를 단독으로 해결할 수 없다. 따라서 승인 제안서에는 클라이언트 구성, AWS 권한, 네트워크 정책, 사고 대응의 담당자를 명시해야 한다. 원래의 파일럿 엔지니어가 부재한 경우에도 이러한 책임은 명확하게 유지돼야 한다.
초기에 가장 중요한 질문은 조직이 어시스턴트로 무엇을 달성하려 하는가다. 로컬 함수를 검토하는 데 필요한 권한 세트는 종속성을 설치하거나 릴리스를 게시하는 데 필요한 권한 세트와 다르다. 이러한 활동을 “코딩”이라는 하나의 일반 범주로 취급하면 검토의 정확성이 떨어진다.
파일럿은 정보를 읽을 권한과 그 정보에 대해 행동할 권한도 구분해야 한다. 어시스턴트는 결함을 설명하기 위해 소스 파일이 필요할 수 있다. 그렇다고 빌드 스크립트 변경, 인증 설정 편집, 브랜치 푸시가 자동으로 정당화되는 것은 아니다. 유용한 접근 권한은 개발자의 전체 권한보다 좁게 유지될 수 있다.
자격 증명은 워크스테이션 동작과 클라우드 권한을 연결하므로 특히 주의해야 한다. 검토자는 작업이 실제로 사용하는 ID, 해당 ID가 자격 증명을 갱신하는 방식, 접근 권한을 취소할 수 있는 주체를 확인해야 한다. 승인된 프로필 이름의 존재는 근거의 일부일 뿐이다.
구성 검토에서는 자격 증명을 선택하거나 획득하는 파일을 누가 수정할 수 있는지도 살펴봐야 한다. 자동화된 작업이 자신의 ID 선택 메커니즘을 다시 쓸 수 있다면 정책의 설득력은 떨어진다. 이 메커니즘을 보호하는 일은 제안된 운영 방식의 일부여야 한다.
운영상의 부담에는 문제 해결도 포함된다. 팀은 만료된 자격 증명, 누락된 모델 접근 권한, 차단된 목적지, 지원되지 않는 클라이언트 동작을 구분할 수 있어야 한다. 그렇지 않으면 일상적인 장애가 원래 설계를 약화시키는 광범위한 예외를 초래할 수 있다.
엔터프라이즈 구매자에게 이는 인터페이스 기능만 비교하는 것보다 더 유용한 평가를 만든다. 후보 배포는 관리자가 활성 설정을 식별하고, 장애를 조사하며, 이전에 승인된 구성을 복원하는 방법을 보여줘야 한다. 이러한 기능은 파일럿이 유지 관리되는 서비스가 될 수 있는지에 영향을 미친다.
문서는 스크린샷만이 아니라 결정을 기록해야 한다. 설정 이미지는 검토를 뒷받침할 수 있지만, 특정 권한이 존재하는 이유나 권한이 실패했을 때 어떤 일이 발생하는지 설명할 수는 없다. 의도한 동작, 관찰된 결과, 차이를 해결할 책임자를 기록해야 한다.
이 지점에서 ChatGPT Bedrock 구성은 조직 차원의 과제가 된다. 기술 설정은 간결할 수 있지만 운영 합의는 불완전할 수 있다. 성공적인 검토는 다른 관리자도 이해하고 유지할 수 있는 범위가 제한된 서비스를 만들어야 한다.
단기적으로는 도입 전에 더 많은 조율이 필요하다. 파일럿이 성공한다면 장기적 이점은 사용자, 모델, 클라이언트 버전이 바뀌어도 책임이 명시적으로 유지되는 배포다.
로컬 유용성과 광범위한 연결성의 경쟁
이 배포의 가치는 데이터 흐름을 더 쉽게 검토할 수 있게 하는 제한 속에서도 유용한 작업이 가능한지에 달려 있다.
OpenAI의 GovCloud 구성 가이드는 관리자가 강제하는 요구 사항과 구성 가능한 기본값을 구분한다. 또한 애플리케이션 트래픽과 에이전트 명령이 생성하는 네트워크 트래픽도 구분한다.
이 예시는 관리형 제한에는 requirements.toml을, 제공자 설정에는 config.toml을 사용한다. 제한적인 기본 구성에서는 브라우저 제어, 컴퓨터 제어, 앱, 플러그인 및 기타 선택 기능을 비활성화한다. OpenAI는 애플리케이션 네트워크 설정이 기기 방화벽을 대체하지 않는다고 밝힌다.
이러한 구분이 중요한 이유는 모델 접근과 작업 연결성이 서로 다른 목적을 수행하기 때문이다. 모델은 결과 명령에 외부 서비스 접근 권한을 부여하지 않고도 제안된 코드 변경을 반환할 수 있다. 검토자는 이 경로들을 독립적으로 평가해야 한다.
유용한 평가는 제안된 경계 안에서 완료할 수 있는 작업에서 시작한다. 기존 코드 설명, 일관성 없는 오류 처리 식별, 준비된 픽스처에 대한 변경 초안 작성은 합리적인 테스트 사례다. 이들의 유용성은 모델 가용성을 근거로 가정하기보다 관찰된 결과를 통해 측정해야 한다.
다음으로 검토자는 일반적인 작업이 누락된 종속성을 만나는 지점을 파악해야 한다. 테스트에는 패키지 다운로드가 필요할 수 있다. 빌드는 내부 서비스를 예상할 수 있다. 제안된 워크플로는 로컬에서 사용할 수 없는 문서에 의존할 수 있다. 각 사례는 별도 결정을 내려야 하는 구체적 요구 사항을 드러낸다.
잘못된 대응은 모든 차단된 작업을 배포에 제한 없는 연결성이 필요하다는 증거로 간주하는 것이다. 일부 작업은 승인된 로컬 자료를 사용할 수 있다. 다른 작업에는 범위가 좁게 승인된 목적지가 필요하다. 또 일부는 종속성이 파일럿의 목적을 훼손하므로 파일럿 범위 밖에 남아야 한다.
이로써 광범위하게 연결된 어시스턴트와의 실용적인 비교가 가능해진다. 더 넓은 연결성은 준비 부담을 줄이면서 조사와 통합을 지원할 수 있다. 제한된 연결성은 탐색할 수 있는 외부 경로가 적다. 구매자는 어느 쪽이든 보편적으로 더 낫다고 보기보다 실제 작업을 기준으로 이 방식을 비교해야 한다.
OpenAI의 Bedrock API 호환성 문서 역시 Bedrock 기능과 호스팅 API를 구분한다. 지원되는 도구와 전송 기능의 차이를 식별하는 한편, 지역 가용성과 배포 운영은 AWS의 책임으로 명시한다.
이 비교는 중요한 구매 실수를 막는다. 유사한 모델 이름이나 익숙한 인터페이스 요소가 동등한 워크플로를 보장하지는 않는다. 클라이언트, 엔드포인트, 활성화된 도구, 허용된 목적지는 모두 사용자가 완료할 수 있는 작업에 영향을 미친다.
ChatGPT 데스크톱 GovCloud 배포의 경우, 유익한 파일럿은 예외 없이 작업이 성공하는 지점을 기록해야 한다. 또한 제한이 결과를 바꾸는 지점도 기록해야 한다. 이러한 관찰은 배포가 조직이 의도한 작업과 부합하는지 보여 준다.
출력 품질도 같은 평가에 포함돼야 한다. 네트워크 경계 내에 머무는 제안 패치도 애플리케이션을 잘못 이해할 수 있다. 검토자는 정확성, 유지보수성, 로컬 요구 사항 준수 여부를 평가해야 한다. 보안 근거는 엔지니어링 검토를 대체할 수 없다.
반대도 마찬가지다. 뛰어난 패치가 요청이 의도한 경로를 따랐음을 입증하지는 않는다. 조직에는 유용한 출력과 수용 가능한 처리에 관한 별도의 근거가 필요하다.
그에 따른 절충안은 정확하게 표현하면 관리할 수 있다. 배포는 무제한 제품이 다른 곳에서 제공하는 연결성을 축적하기보다, 입증된 필요에 따라 추가 기능을 확보해야 한다.
리전 추론은 보존 문제를 해결하지 않는다
위치, 대화 저장, 악용 모니터링은 팀이 배포를 무보존이라고 설명하기 전에 각각 별도의 답이 필요하다.
데이터 레지던시는 처리 또는 저장이 이루어지는 위치와 관련이 있다. 보존은 정보가 지속되는지, 그리고 어떤 조건에서 지속되는지와 관련이 있다. 리전 엔드포인트는 위치에 대한 질문에는 도움이 될 수 있지만, 모든 저장 관련 질문을 해결하지는 못한다.
AWS의 Responses API storage 문서는 이후 요청이 이전 응답을 참조할 수 있게 하는 저장된 대화 상태를 설명한다. 이 문서는 store=true가 기본값임을 명시하고, 저장된 응답의 보존 기간을 30일로 설명한다.
이 설정은 주의 깊게 살펴볼 필요가 있지만, 검토의 전부는 아니다. 팀은 대화 연속성과 서비스가 콘텐츠를 보존할 수 있는 다른 사유를 구분해야 한다. 그렇지 않으면 하나의 저장 메커니즘을 비활성화한 것을 근거로 증거가 뒷받침하는 범위보다 광범위한 주장을 하게 될 수 있다.
AWS의 data retention controls는 프로젝트 설정, 리전 계정 설정, 모델 기본값에서 도출되는 유효 정책을 설명한다. 이용 가능한 보존 모드와 적용 가능 여부는 선택한 모델 및 계정에 따라 달라질 수 있다.
즉각적인 의미는 검토자가 계획한 배포의 유효 정책을 확인해야 한다는 것이다. Bedrock에 관한 일반적 설명만으로는 모든 계정, 프로젝트, 모델 조합의 동작을 확정할 수 없다. 검토에는 모델 및 엔드포인트 선택과 함께 정책 근거를 보존해야 한다.
AWS의 abuse detection policy는 또 다른 구분을 제시한다. 이 정책은 적용 대상 OpenAI 모델에서 분류기가 플래그를 지정한 트래픽이 최대 30일 동안 보존될 수 있다고 설명한다. 자격을 갖춘 고객은 AWS 계정 팀을 통해 완전한 무데이터 보존을 요청할 수 있다.
이 문서들은 “무보존 지원”이라는 표현을 광범위하게 해석하는 데 제약을 둔다. 어떤 모드를 지원한다고 해서 특정 배포가 그 모드를 사용한다는 뜻은 아니다. 적절한 주장은 유효 구성, 모델 조건, 적용되는 예외에 따라 달라진다.
따라서 보안 검토에는 정확한 표현을 사용해야 한다. 팀이 리전 추론을 확인했지만 보존 검토를 완료하지 않았다면, 기록에는 정확히 그 사실을 명시해야 한다. 보존 방식에 추가 승인이 필요하다면 배포 제안서는 해결되지 않은 종속성을 식별해야 한다.
같은 원칙은 로컬 정보에도 적용된다. 클라우드 보존 설정은 워크스테이션, 리포지토리 또는 조직 기록에 무엇이 남는지에 답하지 않는다. 팀은 추론 서비스의 동작에서 이를 추정하지 말고, 그러한 위치를 별도로 검토해야 한다.
가상의 소스 코드 파일럿에서는 제출된 샘플을 승인된 전체 워크플로 전반에 걸쳐 추적해야 한다는 의미다. 로컬 입력, 요청 대상, 적용되는 서비스 정책, 생성되는 파일을 식별해야 한다. 각 요소는 처리 설명에 포함되어야 한다.
이 분석은 특정 기관 계정의 보존 방식이 부적절하다는 결론을 내리지 않는다. 이는 발표만으로는 그 질문을 해결할 수 없는 이유를 보여줄 뿐이다. 구매자는 더 강한 주장을 하기 전에 계정별 증거가 필요하다.
따라서 GovCloud 추론 제어는 검토에서 보존 제어와 나란히 다루되, 별도의 책임자와 승인 기준을 두어야 한다. 이를 포괄적인 “보안 AI”라는 레이블 아래 묶으면 해결되지 않은 질문을 파악하기 어려워진다.
상업적 측면에서의 결과는 명확하다. 배포는 위치 요건에는 부합하면서도 저장 조건에 대해서는 추가 작업이 필요할 수 있다. 구매자는 파일럿이 해당 요건의 적용을 받는 정보를 처리하기 전에 이 구분을 해결해야 한다.
신뢰할 수 있는 파일럿은 차단된 작업을 검증한다
성공적인 응답은 기본 기능을 입증하지만, 통제된 배포에는 금지된 동작이 계속 차단된다는 증거도 필요하다.
첫 번째 유용한 테스트는 승인된 워크플로가 샘플 데이터로 작동하는지 묻는다. 다음 테스트는 종속 요소가 실패했을 때 같은 워크플로가 수용 가능하게 동작하는지 묻는다. 두 결과 모두 승인 기록에 포함되어야 한다.
자격 증명 실패는 특히 많은 정보를 제공하는 사례다. 검토자는 승인된 절차를 통해 만료되었거나 유효하지 않은 자격 증명을 테스트해야 한다. 바람직한 관찰 결과는 의도한 경계를 유지하는 명확한 실패다. 설명되지 않은 인증 변경 이후 응답이 나타난다면 조사가 필요하다.
라우팅 실패도 비슷하게 다뤄야 한다. 승인된 추론 대상이 사용할 수 없게 되면, 팀은 클라이언트가 다음으로 무엇을 시도하는지 관찰해야 한다. 그 동작이 조직의 요건과 일치하기 전까지는 배포에 더 폭넓은 승인을 부여해서는 안 된다.
테스트에서는 사용자가 일반 설정을 통해 관리형 제한을 우회할 수 있는지도 살펴봐야 한다. 검토에는 구성 파일만으로 얻은 확신이 아니라 실행 중인 애플리케이션에서 나온 증거가 필요하다. 의도된 제한과 실제 적용되는 제한은 서로 다른 주장이다.
파일럿은 무해한 테스트 자료로 파일 경계를 검증할 수 있다. 워크플로가 접근을 허용하는 위치에 샘플 자료를 배치하고, 그 범위 밖에 있는 자료는 분리한다. 민감한 프로덕션 정보를 도입하지 않고 검토자가 동작을 관찰하도록 요청한다. 이렇게 하면 실패 원인을 더 쉽게 조사할 수 있다.
네트워크 테스트는 클라이언트의 모델 요청과 작업 중 실행되는 명령을 구분해야 한다. 추론을 위해 하나의 대상을 허용한다고 해서 작업이 생성하는 모든 연결에 대한 권한이 자동으로 부여되는 것은 아니다. 승인 기록은 각 관찰 결과가 어떤 활동을 다루는지 설명해야 한다.
워크플로에는 일반적인 엔지니어링 검토도 포함되어야 한다. 모델은 좁은 범위의 테스트는 통과하지만 유지보수 문제를 만드는 변경을 제안할 수 있다. 패치가 프로젝트 규칙을 따르는지, 예상 동작을 보존하는지, 다른 개발자가 이해할 수 있는 명확한 설명을 남기는지 확인해야 한다.
이러한 검증은 계속 늘어나는 스크린샷 모음이 아니라 재사용 가능한 증거를 만들어야 한다. 승인된 구성, 테스트 입력, 예상 결과, 관찰 결과, 미해결 문제를 기록해야 한다. 다른 검토자도 파일럿이 무엇을 입증했는지 이해할 수 있어야 한다.
롤백에는 별도의 승인 검증이 필요하다. 더 넓게 사용하기 전에 관리자가 이전 구성을 복원하고 임시 접근 권한을 제거하는 방법을 식별해야 한다. 원래 엔지니어의 기억에만 존재하는 롤백 절차는 사고 발생 시 신뢰하기 어렵다.
파일럿은 유용한 부정적 결과도 보존해야 한다. 승인된 제한 아래에서 완료할 수 없는 작업은 제안된 서비스의 경계를 보여준다. 이 정보는 구매자가 사용 사례를 좁힐지, 추가 기능을 검토할지 결정하는 데 도움이 된다.
여기서 검토한 증거에는 검증된 고객 도입 수치나 독립적인 성능 결과가 수반되지 않는다. 이 발표는 배포 경로를 평가하는 근거가 된다. 기관이 얼마나 많은 작업을 완료할지, 검토 노력을 얼마나 줄일지는 입증하지 않는다.
ChatGPT 데스크톱 GovCloud 배포에서는 대표 작업과 재현 가능한 관찰을 통해 이러한 불확실성을 해결하는 것이 가장 바람직하다. 광범위한 생산성 약속은 의사결정에 거의 도움이 되지 않는다. 허용된 작업, 차단된 동작, 복구에 관한 명확한 증거는 훨씬 더 도움이 된다.
더 폭넓은 도입 전에 주시할 사항
다음으로 유용한 신호는 호환성, 강제 가능한 정책, 승인된 경계 안에서 반복 가능한 작업과 관련된다.
첫째, 설치된 클라이언트, 선택한 모델, GovCloud 엔드포인트 전반에서 문서화된 호환성을 살펴봐야 한다. 배포 기록은 실제로 테스트한 조합을 식별해야 한다. 이후 제품 릴리스가 나오면 해당 조합과 관련된 변경 사항을 집중적으로 검토해야 한다.
명확한 호환성 문서는 팀이 배포를 유지할 수 있다는 신뢰를 높일 것이다. 문서화된 설정과 설치된 동작 사이에 설명되지 않는 차이가 있다면 그 신뢰는 약화될 것이다. 구매자는 버전별 증거를 초기 설정 때만 수집하는 것이 아니라 운영의 일부로 다뤄야 한다.
둘째, 일상적인 변경 후에도 관리형 제한이 계속 유효하다는 재현 가능한 증거를 살펴봐야 한다. 애플리케이션 재시작, 자격 증명 갱신 또는 승인된 업데이트 적용 후에도 정책이 불확실해져서는 안 된다. 이러한 이벤트는 중요한 검증을 반복할 실질적인 기회를 제공한다.
일관된 결과는 이 방식이 일상적인 관리 과정을 견딘다는 것을 보여주므로 더 폭넓은 도입을 뒷받침할 수 있다. 반복적인 수동 복구가 필요하다면 배포에 더 많은 운영 작업이 필요하다는 신호일 수 있다. 관련 신호는 조직 자체 조건에서 예측 가능한 동작이다.
셋째, 원래 목적을 넘어 권한을 확대하지 않고도 대표 작업이 계속 유용한지 살펴봐야 한다. 제한된 예외로 승인된 작업을 완료하는 파일럿은 광범위한 접근에 의존하는 인상적인 시연보다 더 강력한 근거를 제시한다.
이 신호에는 검토 부담도 포함해야 한다. 사람들이 출력물을 수정하거나, 누락된 맥락을 준비하거나, 차단된 종속성을 조사해야 하는 지점을 추적해야 한다. 이러한 관찰은 어시스턴트가 워크플로를 개선하는지, 아니면 작업을 다른 팀으로 이전하는지 판단하는 데 도움이 된다.
이는 평가 신호이지, 발표된 미래 릴리스나 약속된 이정표가 아니다. 검토한 출처는 더 폭넓은 기능의 일정, 독립적인 보안 조사 결과 또는 기관 도입을 입증하지 않는다. 구매자는 이용 가능한 구성을 필연적인 배포에 대한 예측으로 바꾸려 해서는 안 된다.
더 넓은 교훈은 조직이 AI 지원을 평가하는 방식과 관련된다. 모델 접근은 하나의 입력 요소일 뿐이다. 운영 방식은 어떤 정보가 워크플로에 들어오는지, 어떤 작업이 계속 가능한지, 누가 이후에 결과를 설명할 수 있는지를 결정한다.
이러한 방식을 문서화하는 팀은 확립된 knowledge management 관행을 활용할 수 있다. 명확한 의사결정 기록은 향후 검토자가 제한이 존재하는 이유와 이를 뒷받침한 증거를 이해하는 데 도움이 된다. 해당 기록에 사용하는 모든 도구에도 별도의 처리 검토가 필요하다.
좁은 범위의 작업, 승인된 샘플 정보, 의도한 요청 경로에 대한 서면 설명으로 시작해야 한다. 파일럿을 확대하기 전에 보안 팀에 수용 가능한 신원 확인, 연결성, 보존 및 복구 동작을 정의하도록 요청한다. 그런 다음 해당 요건을 관찰된 결과와 비교한다. 성공적인 시연만큼이나 실패도 신중하게 보존해야 한다. 실패는 제안된 경계 중 보완이 필요한 지점을 드러내기 때문이다. 클라이언트, 모델, 자격 증명 또는 활성화된 기능이 변경되면 기록을 다시 검토한다. 각 주장을 뒷받침하는 증거가 있고, 해결되지 않은 각 질문에 책임자가 있을 때 ChatGPT 데스크톱 GovCloud 배포를 더 쉽게 평가할 수 있다. 귀사 팀은 먼저 그 경계 안에서 어떤 유용한 워크플로를 검증할 수 있을까?
