Guia de implantação para administradores

Use este guia para planejar a implantação do ChatGPT Enterprise nas seguintes áreas de administração:

• Acesso ao espaço de trabalho.
• Política de execução local para os recursos abrangidos no aplicativo do ChatGPT para desktop, na CLI do Codex e na extensão para IDE.
• Codex Cloud.
• Acesso à API da plataforma.
• Plugins e acesso a conectores.
• Permissões nos sistemas conectados.

Para uma nova implantação, siga as etapas na ordem indicada. Para alterar uma área específica, consulte as páginas indicadas nos links.

Se você administra um gateway de modelos para clientes locais do Codex, consulte Implantar um gateway para validar o gateway, distribuir credenciais e orientar os usuários na configuração dos clientes. Se a implantação usar recursos do espaço de trabalho, configure o acesso a eles separadamente.

Nas configurações do espaço de trabalho, a seção Codex e Work locais reúne o acesso local ao Codex e ao Work na opção Permitir que os membros usem o Codex e o Work localmente. Alguns espaços de trabalho apresentam duas seções independentes, Codex local e Work local. Nesse caso, Permitir que os membros usem o Codex localmente controla o acesso ao Codex, e Usar o Work localmente controla o acesso ao Work. Ativar uma opção não ativa a outra. Esses rótulos identificam permissões do espaço de trabalho e não representam produtos ou clientes distintos. Dependendo do espaço de trabalho, as permissões de tokens e os limites de validade das credenciais aparecem na seção Tokens de acesso ou na seção de acesso local. A configuração gerenciada é uma camada de política separada que pode restringir como os recursos abrangidos se comportam durante a execução nesses clientes. Quando o comportamento ou a disponibilidade varia, este guia indica a qual interface a orientação se aplica.

Para uma visão geral dos controles de acesso, consulte Funções e permissões do espaço de trabalho. Consulte a Central de Ajuda para obter os procedimentos atuais do espaço de trabalho do ChatGPT e a documentação para desenvolvedores indicada nos links para entender o comportamento da execução local e em ambientes hospedados.

Para saber mais sobre segurança empresarial, privacidade e proteções durante a execução, consulte Aprovações e segurança de agentes e o documento técnico sobre segurança do Codex.

Etapa 1: Defina os responsáveis e escolha uma estratégia de implantação

Designe um responsável para cada parte da implantação:

• Acesso ao espaço de trabalho: membros, licenças, funções e recursos compatíveis do espaço de trabalho.
• Política de execução local: aprovações, perfis de permissões, acesso ao sistema de arquivos e à rede e outros requisitos para os clientes locais compatíveis.
• Codex Cloud: ambientes hospedados, conexões com repositórios e política de execução na nuvem.
• Sistemas conectados: instalação de aplicativos, contas e permissões no provedor.
• Relatórios e conformidade: acesso a análises, exportação de registros de auditoria e tratamento dos dados nos sistemas que os recebem.

Defina se cada público precisa dos recursos locais abrangidos no aplicativo do ChatGPT para desktop, na CLI do Codex ou na extensão para IDE, se precisa do Codex Cloud ou de uma combinação dessas opções. Quando um fluxo de trabalho usar autenticação por chave de API, trate o acesso à API da plataforma separadamente, nos níveis da organização e do projeto.

Etapa 2: Configure o acesso e a identidade no espaço de trabalho

Use a gestão de membros, as licenças, os grupos e as permissões de controle de acesso baseado em funções (RBAC) disponíveis no espaço de trabalho do ChatGPT para conceder a cada público acesso aos recursos compatíveis. Consulte as orientações atuais do espaço de trabalho para verificar o acesso aos clientes locais e ao Codex Cloud. A função que controla o acesso pode variar conforme a interface. Reserve as funções administrativas predefinidas para quem administra o espaço de trabalho.

Os controles e rótulos do espaço de trabalho mudam com o tempo. Consulte estas fontes para obter os procedimentos atuais:

• Gerenciar membros, tipos de licença, funções e acesso
• Configurar o controle de acesso baseado em funções
• Gerenciar as configurações do espaço de trabalho
• Grupos e provisionamento
• Gestão do ciclo de vida dos usuários
• Autenticação

Teste o login e o acesso aos recursos com um membro que tenha as permissões previstas. O acesso ao espaço de trabalho não concede acesso a repositórios, arquivos ou ações em um serviço conectado.

Configure o acesso ao computador local com o Work na nuvem

Se a implantação incluir acesso ao computador local para o modo Work ou para os dots, revise as políticas em Segurança de agentes antes da implantação. Migrar políticas e habilitar o acesso ao recurso são alterações independentes. O fluxo de confirmação permite habilitar o acesso sem criar uma política. Quando a política gerenciada está habilitada, a orquestração na nuvem segue as regras compatíveis da política global. Os requisitos de execução local e os controles do dispositivo regem o computador conectado. Os contêineres do Work na nuvem e os computadores dos dots na nuvem têm configurações e requisitos de execução próprios. Consulte Acesso ao computador local para o Work na nuvem e os dots para conhecer os requisitos específicos de configuração e elegibilidade de cada um.

Use a API de políticas para gerenciar as configurações globais. Para gerenciar as configurações locais ou do Codex Cloud, use a interface de Segurança de agentes. Os fluxos de trabalho existentes que usam a API para configurações globais continuam disponíveis após a migração. Teste seus scripts e integrações com o Terraform e confirme que as atribuições e a ordem das políticas continuam as mesmas.

Verifique a compatibilidade antes de habilitar a sincronização:

• Política de rede. Se você usa configurações que substituem os valores padrão por ambiente, teste a precedência das políticas de rede e os limites de execução. Uma restrição da política global pode continuar em vigor mesmo que o ambiente permita o acesso.

• Hooks empresariais. Se a implantação depender de hooks, verifique quais manipuladores são executados com a orquestração na nuvem. Antes de habilitar o acesso, teste os eventos e os cenários de falha que os hooks precisam tratar. Verifique separadamente o que a auditoria abrange.

• Requisitos de dados. O acesso ao computador local com o Work na nuvem não garante zero retenção de dados em sentido estrito. A residência de dados e a residência de inferência abrangem apenas conteúdo elegível e cargas de trabalho, regiões e configurações compatíveis. O gerenciamento de chaves empresariais (EKM) abrange o conteúdo armazenado compatível nos espaços de trabalho elegíveis. O modo Work não oferece suporte à residência de inferência nos Emirados Árabes Unidos. Se enforce_residency estiver habilitado em qualquer política de nuvem, a opção Permitir acesso ao computador local ficará desabilitada tanto para o modo Work quanto para os dots. Essa proteção não configura a residência de dados do espaço de trabalho nem, por si só, desabilita o Work na nuvem ou os dots. Se a sua organização exigir zero retenção de dados (ZDR), não habilite esse recurso.

Como proprietário do espaço de trabalho, revise as permissões do modo Work para os usuários ou grupos que precisam de acesso. Habilite o Work na nuvem e, em seguida, ative Permitir acesso ao computador local. Conceda acesso atribuindo as funções compatíveis. Consulte Funções e permissões do espaço de trabalho.

Etapa 3: Configure os requisitos de execução local

Quando um usuário inicia uma execução local compatível no aplicativo do ChatGPT para desktop, na CLI do Codex ou na extensão para IDE, os requisitos locais restringem o que pode ocorrer durante essa execução. Distribua requirements.toml por um canal compatível de nuvem, dispositivo ou sistema. Mantenha essa política separada das funções e dos grupos do espaço de trabalho do ChatGPT.

Use perfis de permissões para os clientes locais compatíveis. Evite basear novas implantações nas restrições legadas do modo sandbox. Por exemplo:

default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

Para desabilitar o Uso do computador em todas as interfaces compatíveis de navegador e desktop, restrinja cada chave pública de recurso envolvida:

[features]
browser_use = false
browser_use_full_cdp_access = false
browser_use_external = false
in_app_browser = false
computer_use = false

Para consultar a lista oficial de chaves, entender como a configuração é distribuída, verificar a ordem de precedência e ver mais exemplos, consulte Configuração gerenciada e a referência de requirements.toml.

Etapa 4: Padronize a configuração do repositório

Use configurações no nível do repositório para compartilhar as configurações padrão do projeto, as regras e as habilidades sem repetir a configuração para cada usuário. Versione a configuração em .codex ou .agents, conforme o local indicado na documentação do recurso:

A configuração do repositório pode fornecer valores padrão e fluxos de trabalho reutilizáveis. Ela não pode conceder acesso ao espaço de trabalho, a modelos, à API da plataforma ou a sistemas conectados.

Etapa 5: Configure o Codex Cloud

O Codex Cloud usa ambientes hospedados e repositórios de código-fonte conectados.

O Codex Cloud vem desativado por padrão nos espaços de trabalho Enterprise. As configurações existentes de Usar o Codex na nuvem são mantidas na transição do Codex Cloud (legado). Os espaços de trabalho que já tinham habilitado o acesso à nuvem mantêm esse acesso. Onde o acesso estava desabilitado, ele continua assim até que um administrador o habilite. O acesso continua sujeito às restrições da implantação e do espaço de trabalho.

Planeje cada área de administração:

1. Conceda ao público pretendido a permissão Usar o Codex na nuvem. Conceda separadamente a permissão Gerenciar ambientes do espaço de trabalho às pessoas que criam e editam ambientes compartilhados no espaço de trabalho. Consulte as orientações sobre funções no espaço de trabalho.
2. Instale e configure a integração compatível com o sistema de origem.
3. No sistema de origem, limite o acesso de cada público aos repositórios de que ele precisa.
4. Configure os ambientes de nuvem, os segredos, o acesso à internet e os requisitos compatíveis gerenciados na nuvem para esses repositórios.
5. Configure fluxos de trabalho hospedados opcionais, como a revisão de código.
6. Teste o acesso às tarefas com um membro que represente o público pretendido e o gerenciamento de ambientes com o administrador designado. Verifique as permissões de cada pessoa no espaço de trabalho, no ambiente e no repositório.

Os ambientes de nuvem não herdam a política do dispositivo local, as configurações de gerenciamento de dispositivos móveis (MDM) nem o acesso à rede local. Revise os requisitos compatíveis gerenciados na nuvem separadamente dos requisitos instalados no computador do usuário. Consulte Conectar a serviços para saber como acessar os destinos e Segurança de agentes para entender como os requisitos do espaço de trabalho restringem os ambientes de nuvem.

O Codex Cloud respeita as permissões e proteções de repositório disponibilizadas pelo sistema de origem conectado. O acesso ao espaço de trabalho não permite contornar esses controles. Consulte Ambientes de nuvem para obter orientações sobre configuração e execução.

Etapa 6: Configure os plugins e os recursos conectados

Avalie separadamente a instalação de plugins, as habilidades incluídas, os recursos que dependem de conectores, as ações dos conectores e a autorização no sistema de origem. Desabilitar um recurso que depende de um conector não necessariamente desinstala o plugin ou as habilidades incluídas nele.

Antes de incluir um plugin ou uma habilidade na implantação:

1. Confirme a origem, o responsável, o público pretendido e a data da revisão.
2. Revise as habilidades, os conectores, os servidores MCP e os hooks incluídos, além dos dados e das ações necessários para cada recurso.
3. Teste o plugin ou a habilidade com dados não sensíveis e apenas com as permissões necessárias.
4. Registre quem será responsável por novas revisões e pela desativação.

Os plugins funcionam nos modos Chat e Work nas versões do ChatGPT para Web, desktop e dispositivos móveis. Também funcionam no Codex no aplicativo do ChatGPT para desktop e pelo navegador de plugins da CLI do Codex. Eles não estão disponíveis na extensão para IDE. O ChatGPT e o Codex compartilham um único diretório público de plugins. Os controles do espaço de trabalho determinam quais desses plugins os membros podem acessar.

Consulte Controles de plugins e Controles de habilidades para entender o modelo completo.

Etapa 7: Configure a governança e a observabilidade

Escolha a ferramenta de relatórios de acordo com a pergunta que você precisa responder:

• Use Análises do espaço de trabalho para consultar de forma interativa as análises do espaço de trabalho do ChatGPT e do Codex.
• Use a API de análises para gerar relatórios agregados de forma programática pela API de análises do Codex.
• Use a API de Compliance para obter registros de auditoria e investigação.
• Use os limites de uso e controles de gastos do ChatGPT quando, de acordo com o plano, a atividade do Codex consumir créditos elegíveis do espaço de trabalho do ChatGPT.

Ao criar uma integração, consulte a documentação de referência da API que exige autenticação para verificar os requisitos de acesso, os schemas, os campos, as regras de retenção e o comportamento das solicitações em vigor.

Proteja os pontos de integração:

• Armazene as chaves de API e outras credenciais de integração no sistema de gerenciamento de segredos da organização.
• Restrinja ao público autorizado o acesso aos sistemas que recebem os dados e aos dados retidos.
• Proteja os registros exportados da API de Compliance de acordo com a sensibilidade dos dados e a política de retenção da organização. Teste os fluxos de coleta e exclusão com base no contrato vigente da API.

Etapa 8: Verifique e mantenha a implantação

Peça a um usuário do grupo piloto que inicie uma nova tarefa no modo Work e continue a tarefa em outro dispositivo. Com o computador conectado, teste uma ação permitida e outra bloqueada para verificar as aprovações, o acesso ao sistema de arquivos e as restrições de rede. Desconecte o computador e inicie outro turno. Verifique se o contêiner na nuvem não consegue acessar os arquivos locais e se os requisitos de execução do próprio contêiner se aplicam.

Registre as configurações em vigor e o resultado de cada teste. Se uma restrição não funcionar como esperado, resolva o problema antes que os usuários passem a depender dela. Siga o procedimento documentado para desabilitar a sincronização, levando em conta o comportamento previsto. Trate a remoção de acesso, a interrupção de tarefas e a retenção de dados como ações separadas.

Verifique cada área aplicável com identidades que representem os usuários previstos:

• Vínculo como membro do espaço de trabalho do ChatGPT, licença e permissões compatíveis da função.
• Recursos locais abrangidos no aplicativo do ChatGPT para desktop, na CLI do Codex e na extensão para IDE, incluindo o login e os requisitos de execução em vigor.
• Acesso ao Codex Cloud, configuração dos ambientes e permissões dos repositórios.
• Acesso à organização e aos projetos da API da plataforma nos fluxos de trabalho que usam chaves de API.
• Instalação de plugins, habilidades incluídas, acesso a conectores e ações compatíveis.
• Autorização nos sistemas conectados e acesso aos dados.
• Acesso dos administradores responsáveis aos recursos de análise e conformidade.

Registre o responsável por cada controle e a fonte do procedimento vigente. Com esse registro, os administradores podem atualizar os procedimentos quando houver mudanças na interface ou na política, sem alterar o modelo de administração.

Após a implantação inicial, revise o acesso, os recursos conectados, o consumo de créditos, o retorno recebido pelo suporte e os fluxos de trabalho que as equipes realmente usam. Ajuste o escopo da implantação e as orientações aos administradores conforme esses indicadores mudarem.

Se precisar desativar o acesso ao computador local com o Work na nuvem

Informe aos usuários afetados que desativar a opção Permitir acesso ao computador local interrompe os turnos em andamento. Os membros que mantiverem o acesso ao modo Work poderão enviar uma nova mensagem em uma conversa existente na nuvem para continuar sem acesso aos arquivos locais.