ChatGPT e Codex agora rodam no Bedrock no GovCloud. O guia ainda não autoriza sua carga de trabalho
A AWS documentou como rodar o ChatGPT desktop e o Codex com inferência no Amazon Bedrock no AWS GovCloud (US). A adoção vira uma decisão de endpoint, identidade e rede.
Ouça este artigo · 5 min
Narração completa do artigo, gerada por IA.

Para uma agência federal ou um fornecedor de defesa, a primeira pergunta sobre uma ferramenta de IA para código raramente é “ela é boa?”. É “para onde vai o prompt?”. O prompt de um desenvolvedor pode conter código-fonte, nomes de sistemas e dados que não podem sair de um limite aprovado. Enquanto não houver uma resposta limpa, a ferramenta fica fora da lista de aprovadas.
A AWS publicou uma dessas respostas em 30 de outubro: uma configuração que direciona a inferência de modelo do aplicativo ChatGPT desktop, incluindo o modo Work para tarefas de várias etapas, e do agente de código Codex, para o Amazon Bedrock no AWS GovCloud (US), usando a Responses API na região US-West.
O que a configuração faz
A configuração tem três partes, cada uma um controle conhecido, não novo.
Identidade. O login usa apenas o modo API. O app se autentica com uma chave de API do Bedrock ou pela cadeia de credenciais do SDK da AWS, que inclui single sign-on via IAM Identity Center. Nesse modo, a identidade e a política de dispositivo da AWS governam o acesso, não as funções usuais do workspace do ChatGPT.
Configuração sob gestão. Dois arquivos controlam o app: um arquivo de usuário e um arquivo de administrador que define requisitos. Os dois precisam estar no lugar antes do primeiro lançamento, o que significa distribuição via gestão de dispositivos e não por cada desenvolvedor.
Rede. O app fica restrito ao endpoint aprovado do Bedrock, com as outras conexões externas desativadas. A AWS diz que a retenção zero de dados é suportada, ou seja, prompts e respostas não são gravados em armazenamento durável pela AWS nem compartilhados com fornecedores de modelo.
O preço é por token, sem licenças por assento, o que muda a conversa de compras de licenças para consumo. O app roda em Windows, Linux e macOS, com integrações de IDE para VS Code, JetBrains e Xcode.
O que ela não resolve
A AWS é incomumente direta sobre os limites, e eles são a parte importante.
Não autoriza nada. O post afirma que usar o GovCloud e seguir o guia não autoriza uma carga de trabalho por si só. A organização continua responsável pela sua revisão de segurança e de autorização. O fato de o GovCloud ser um ambiente acreditado não torna toda configuração de serviço dentro dele aprovada para um determinado sistema.
Trocar um endpoint não é suporte. A AWS observa que apontar o app para uma URL diferente não estabelece que a configuração é suportada. Os times devem confirmar a versão desktop suportada, o modelo e a região aprovados, e manter essa combinação sob controle de mudanças. Uma atualização do desktop que altera o comportamento de rede é uma mudança no limite.
Recursos desativados fazem parte do pacote. Restringir o app a um endpoint significa que recursos que chamam outros serviços ficam desligados. É exatamente esse o ponto, e isso precisa ser explicado aos desenvolvedores antes do rollout, ou os primeiros tickets de suporte vão pedir exceções.
Três decisões que isso leva para o time de plataforma
A arquitetura transforma a adoção de IA para código em decisões que um time de plataforma já sabe tomar.
- Qual endpoint é o limite. Um endpoint de inferência aprovado, imposto por política de rede e configuração de dispositivo, substitui uma lista de domínios de fornecedores a liberar.
- Qual identidade chama esse endpoint. Prefira o caminho de SSO em vez de chaves de API estáticas, para que o acesso fique atrelado a uma pessoa, revogável e registrado no mesmo lugar que as outras atividades de cloud.
- Quem aprova mudanças de configuração. O arquivo de administrador agora é um artefato de segurança. Versione, revise as mudanças e registre qual versão cada dispositivo executa.
Esta é a mesma lição que tiramos quando os mesmos modelos Claude chegaram via Azure e AWS com limites diferentes: o caminho de entrega é uma decisão de governança, muitas vezes maior que o modelo. Ela também acrescenta um elo à cadeia de fornecimento de modelos que toda organização regulada deveria mapear. Aqui, o criador do modelo, o operador de cloud e o fornecedor do aplicativo cliente controlam cada um uma parte do caminho.
Para compradores regulados fora do governo, o padrão se transfere diretamente. Um banco ou uma farmacêutica que já tem uma região de cloud aprovada, como a de São Paulo, pode aplicar os mesmos três controles, mas precisa antes verificar se os modelos e as APIs de que precisa são oferecidos nessa região. O guia entrega a configuração. A autorização, como a AWS diz, continua sendo trabalho do cliente.