Guia de implementação para administradores

Utilize este guia para planear uma implementação do ChatGPT Enterprise nos seguintes limites administrativos:

• Acesso ao espaço de trabalho.
• Política de execução local para as capacidades abrangidas na aplicação ChatGPT para computador, no Codex CLI e na extensão IDE.
• Codex cloud.
• Acesso à Platform API.
• Acesso a plugins e conectores.
• Permissões nos sistemas ligados.

Conclua os passos pela ordem indicada para uma nova implementação ou utilize as páginas associadas para alterar um limite.

Se gere um gateway de modelos para clientes Codex locais, consulte Implementar Codex através de um gateway para a qualificação do gateway, a distribuição de credenciais e a passagem para a configuração do cliente. Configure o acesso ao espaço de trabalho separadamente quando a sua implementação utilizar funcionalidades do espaço de trabalho.

Nas definições do espaço de trabalho, Codex e Work Local combina o acesso local ao Codex e ao Work em Permitir que os membros utilizem o Codex e o Work localmente. Alguns espaços de trabalho disponibilizam, em alternativa, secções independentes Codex Local e Work Local. Nessa disposição, Permitir que os membros utilizem o Codex localmente controla o Codex e Utilizar o Work localmente controla o Work. Ativar uma das opções não ativa a outra. Estas designações identificam permissões do espaço de trabalho, não produtos ou clientes distintos. As permissões de tokens e os limites de duração das credenciais são apresentados numa secção Tokens de acesso ou na secção de acesso local, consoante o espaço de trabalho. A configuração gerida é uma camada de políticas separada que pode limitar o comportamento suportado em tempo de execução para as capacidades abrangidas nesses clientes. Este guia identifica a interface específica quando o comportamento ou a disponibilidade diferem.

Para uma visão geral dos controlos de acesso, consulte Funções e permissões do espaço de trabalho. Utilize as orientações do Centro de Ajuda para os procedimentos atuais do espaço de trabalho ChatGPT e a documentação para programadores indicada nas ligações para o comportamento de execução local e alojada.

Para obter informações sobre segurança empresarial, privacidade e proteções da execução, consulte Aprovações e segurança do agente e o documento técnico de segurança do Codex.

Passo 1: Atribuir responsáveis e escolher uma implementação

Atribua um responsável por cada parte da implementação:

• Acesso ao espaço de trabalho: Adesão, licenças, funções e funcionalidades suportadas do espaço de trabalho.
• Política de execução local: Aprovações, perfis de permissões, acesso ao sistema de ficheiros e à rede, bem como outros requisitos para os clientes locais suportados.
• Codex cloud: Ambientes alojados, ligações a repositórios e política de execução na cloud.
• Sistemas ligados: Instalação da aplicação no fornecedor, contas e permissões.
• Relatórios e conformidade: Acesso a análises, exportações de auditoria e tratamento de dados em sistemas subsequentes.

Decida se cada público necessita das capacidades locais abrangidas na aplicação ChatGPT para computador, no Codex CLI, na extensão IDE, no Codex cloud ou numa combinação destes. Trate o acesso à Platform API como um limite separado de organização e projeto quando um fluxo de trabalho utiliza autenticação por API key.

Passo 2: Configurar o acesso e a identidade do espaço de trabalho

Utilize a adesão, as licenças, os grupos e as permissões RBAC suportadas do espaço de trabalho do ChatGPT para conceder aos públicos pretendidos as funcionalidades suportadas do espaço de trabalho. Verifique o acesso ao cliente local e ao Codex cloud de acordo com as orientações atuais do espaço de trabalho, em vez de pressupor que a mesma função controla todas as interfaces. Limite as funções de administração incorporadas às pessoas que administram o espaço de trabalho.

Os controlos e rótulos do espaço de trabalho mudam ao longo do tempo. Utilize estas fontes para consultar os procedimentos atuais:

• Gerir membros, tipos de lugar, funções e acesso
• Configurar o controlo de acesso baseado em funções
• Gerir as definições do espaço de trabalho
• Grupos e aprovisionamento
• Gestão do ciclo de vida dos utilizadores
• Autenticação

Teste o início de sessão e o acesso às funcionalidades com um membro que tenha as permissões pretendidas. O acesso ao espaço de trabalho não concede acesso a repositórios, ficheiros ou ações num serviço ligado.

Configurar o acesso ao computador local com Work Cloud

Se a sua implementação incluir acesso ao computador local para Work ou dots, consulte as políticas em Agent Security antes da implementação. A migração de políticas e o acesso às funcionalidades são alterações separadas; o fluxo de confirmação não exige a criação de políticas para ativar o acesso. A política Global suportada rege a orquestração na nuvem quando a política gerida está ativada. Os requisitos de execução local e os controlos de dispositivos regem o computador ligado. Os contentores na nuvem do Work e os computadores na nuvem do dots utilizam a sua própria configuração e os seus próprios requisitos de execução. Siga as orientações em Acesso ao computador local para Work Cloud e dots para conhecer os requisitos de configuração e elegibilidade específicos de cada um.

Utilize a API de políticas para gerir as definições Global. Para gerir as definições Local ou Codex Cloud, utilize a interface do Agent Security. Os fluxos de trabalho existentes da API Global continuam disponíveis após a migração. Teste os seus scripts e integrações com o Terraform e confirme que as atribuições e a ordenação das políticas se mantêm inalteradas.

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

Política de rede. Quando estiverem disponíveis substituições de definições por ambiente, teste as exceções de experimental_network documentadas em Configuração gerida. Uma restrição global pode continuar em vigor apesar de uma permissão no ambiente.

• Hooks empresariais. Quando ativado para o seu espaço de trabalho, o acesso ao computador local com o Work Cloud suporta hooks MCP definidos pelo administrador que são executados no coordenador na nuvem (orquestrador) para eventos de ciclo de vida e de ferramentas suportados. Os hooks de comandos e os hooks provenientes da configuração local ou de plugins não são suportados com a orquestração na nuvem, mesmo quando as ferramentas são executadas localmente.

• Hooks não suportados. Os hooks de comandos e os hooks provenientes da configuração local ou de plugins não são suportados com a orquestração na nuvem, mesmo quando as ferramentas são executadas localmente. Quando tanto a orquestração como a execução são locais, os hooks existentes suportados continuam a funcionar em conversas do Work e do Codex exclusivamente locais. Os administradores podem continuar a configurar hooks geridos suportados no Agent Security para esses fluxos de trabalho.

• Auditoria. Antes de depender destes hooks, teste a ligação de callback, confirme os eventos que recebe e verifique como as falhas afetam a tarefa. Os hooks MCP não fornecem um registo de auditoria completo da Compliance API.

• Requisitos de dados. O acesso ao computador local com o Work Cloud não garante retenção estritamente nula de dados. 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 suportadas. O Enterprise Key Management (EKM) abrange conteúdo armazenado suportado em espaços de trabalho elegíveis. O Work não é suportado com residência de inferência nos EAU. Se enforce_residency estiver ativado em qualquer política de nuvem, a opção Permitir acesso ao computador local fica desativada tanto para o Work como para o dots. Esta salvaguarda não configura a residência do espaço de trabalho nem, por si só, desativa o Work Cloud ou o dots. Se a sua organização exigir ZDR, não ative esta funcionalidade.

Como proprietário do espaço de trabalho, reveja as permissões do Work para os utilizadores ou grupos pretendidos. Ative o Work Cloud e, em seguida, ative Permitir acesso ao computador local. Utilize atribuições de funções suportadas para conceder acesso. Consulte Funções e permissões do espaço de trabalho.

Passo 3: Configurar os requisitos de execução local

Os requisitos locais restringem o comportamento da execução quando um utilizador inicia uma execução local suportada na aplicação ChatGPT para computador, no Codex CLI ou na extensão IDE. Distribua requirements.toml através de um canal de cloud, dispositivo ou sistema suportado. Mantenha esta política separada das funções e dos grupos do espaço de trabalho do ChatGPT.

Utilize perfis de permissões para os clientes locais suportados, em vez de criar novas implementações com base em restrições legadas do modo sandbox. Por exemplo:

default_permissions = ":workspace"

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

Para desativar o Computer Use nas interfaces de funcionalidades suportadas do browser e do computador, restrinja cada chave pública de funcionalidade que participa na experiência:

[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, o comportamento de distribuição, a precedência e mais exemplos, consulte Configuração gerida e a referência de requirements.toml.

Passo 4: Normalizar a configuração do repositório

Utilize a configuração ao nível do repositório para partilhar predefinições, regras e skills do projeto sem duplicar a configuração para cada utilizador. Registe a configuração em .codex ou .agents de acordo com a localização documentada da funcionalidade:

A configuração do repositório pode fornecer predefinições e fluxos de trabalho reutilizáveis. Não pode conceder acesso ao espaço de trabalho, aos modelos, à Platform API ou aos sistemas ligados.

Passo 5: Configurar o Codex cloud

O Codex cloud utiliza ambientes alojados e repositórios de código-fonte ligados.

O Codex Cloud está desativado por predefinição nos espaços de trabalho Enterprise. As definições existentes de Utilizar o Codex na nuvem transitam do Codex Cloud (Legacy): os espaços de trabalho que já tinham ativado o Cloud mantêm o acesso, e aqueles com o Cloud desativado mantêm-no desativado até que um administrador o ative. O acesso continua sujeito à disponibilização e às restrições do espaço de trabalho.

Planeie cada limite:

1. Conceda ao público pretendido a permissão Utilizar o Codex na nuvem. Conceda separadamente a permissão Gerir ambientes do espaço de trabalho às pessoas que criam e editam ambientes partilhados no espaço de trabalho. Consulte as orientações sobre funções do espaço de trabalho.
2. Instale e configure a integração suportada com o sistema de origem.
3. Limite o acesso a repositórios no sistema de origem aos repositórios de que cada público necessita.
4. Configure ambientes na nuvem, segredos, acesso à Internet e requisitos suportados geridos na nuvem para esses repositórios.
5. Configure fluxos de trabalho alojados opcionais, como a revisão de código.
6. Teste o acesso a tarefas com um membro representativo e a gestão de ambientes com o administrador designado. Verifique as permissões de cada pessoa relativas ao espaço de trabalho, ao ambiente e ao repositório.

Os ambientes na nuvem não herdam a política do dispositivo local, as definições de MDM nem o acesso à rede local. Reveja os requisitos suportados geridos na nuvem separadamente dos requisitos instalados no computador de um utilizador. Consulte Ligar a serviços para obter informações sobre o acesso a destinos e Agent Security para saber como os requisitos do espaço de trabalho restringem os ambientes na nuvem.

O Codex cloud respeita as permissões e proteções dos repositórios disponibilizadas pelo sistema de origem ligado. O acesso ao espaço de trabalho não contorna esses controlos. Consulte Ambientes na nuvem para obter orientações sobre configuração e execução.

Passo 6: Configurar plugins e capacidades ligadas

Analise a instalação de plugins, as skills incluídas, as capacidades baseadas em conectores, as ações dos conectores e a autorização no sistema de origem como decisões separadas. Desativar uma capacidade baseada num conector não desinstala necessariamente o plugin nem as skills que inclui.

Antes de incluir um plugin ou uma skill na implementação:

1. Confirme a respetiva origem, o responsável, o público pretendido e a data de revisão.
2. Analise as skills incluídas, os conectores, os MCP servers, os hooks e os dados e ações exigidos por cada capacidade.
3. Teste com dados não confidenciais e com o nível mínimo de acesso necessário.
4. Registe quem é responsável pela nova revisão e pela desativação.

Os plugins funcionam no Chat e no Work no ChatGPT na Web, no computador e em dispositivos móveis, no Codex na aplicação ChatGPT para computador e através do navegador de plugins do Codex CLI. Não estão disponíveis na extensão IDE. O ChatGPT e o Codex partilham um único diretório público universal de plugins; os controlos do espaço de trabalho determinam a que plugins desse diretório os membros podem aceder.

Consulte Controlos de plugins e Controlos de skills para conhecer o modelo completo.

Passo 7: Configurar a governação e a observabilidade

Escolha a interface de relatórios adequada à questão:

• Utilize Análises do espaço de trabalho para análises interativas do espaço de trabalho do ChatGPT e análises do Codex.
• Utilize a Analytics API para relatórios agregados e programáticos através da Codex Analytics API.
• Utilize a Compliance API para registos de auditoria e investigação.
• Utilize Limites de utilização e controlos de despesas do ChatGPT quando a atividade do Codex dependente do plano consumir créditos elegíveis do espaço de trabalho do ChatGPT.

Ao criar uma integração, utilize a documentação de referência da API que exige autenticação para consultar os requisitos de acesso, esquemas, campos, retenção e comportamento dos pedidos em vigor.

Proteja o limite da integração:

• Armazene API keys e outras credenciais de integração no sistema de gestão de segredos da organização.
• Limite o acesso aos sistemas subsequentes e aos dados retidos ao público aprovado.
• Proteja os registos exportados da Compliance API de acordo com a sua sensibilidade e a política de retenção da organização, e teste os fluxos de trabalho de recolha e eliminação de acordo com o contrato atual.

Passo 8: Verificar e manter a implementação

Após ativar o acesso ao computador local com o Work Cloud, crie uma nova tarefa e continue a conversa noutro dispositivo suportado. As tarefas existentes não são migradas e mantêm o seu comportamento original, exclusivamente local ou exclusivamente na nuvem. Mantenha o computador online para os passos que necessitem dos seus ficheiros ou ferramentas. Teste uma ação que a política deva permitir e uma ação que deva bloquear, verificando as aprovações aplicáveis e as restrições do sistema de ficheiros e da rede separadamente para a execução local e na nuvem. Teste também o início de um novo turno enquanto o computador local está indisponível. Uma tarefa elegível pode continuar num contentor na nuvem sem acesso aos ficheiros ou ferramentas locais desse computador. Uma tarefa não pode passar da execução local para a nuvem durante um turno.

Registe as definições efetivas e o resultado de cada teste. Se uma restrição não funcionar como previsto, resolva o problema antes de os utilizadores dependerem dela. Siga o comportamento documentado para desativar a sincronização. Trate a remoção de acesso, a interrupção de tarefas e a retenção de dados como ações separadas.

Verifique todos os limites aplicáveis com identidades representativas:

• Adesão, licença e permissões das funções suportadas do espaço de trabalho do ChatGPT.
• Capacidades locais abrangidas na aplicação ChatGPT para computador, no Codex CLI e na extensão IDE, incluindo o início de sessão e os requisitos de execução efetivos.
• Acesso ao Codex cloud, configuração do ambiente e permissões dos repositórios.
• Acesso à organização e ao projeto da Platform API para fluxos de trabalho com API key.
• Instalação de plugins, skills incluídas, acesso a conectores e ações suportadas.
• Autorização e acesso a dados nos sistemas ligados.
• Acesso a análises e conformidade para os administradores responsáveis.

Registe o responsável e a fonte procedimental atual de cada controlo. Este registo permite aos administradores atualizar os procedimentos quando a interface ou a política mudar, sem alterar o modelo de administração.

Após a implementação inicial, analise o acesso, as capacidades ligadas, a utilização de créditos, os comentários do suporte e os fluxos de trabalho efetivamente utilizados pelas equipas. Ajuste o âmbito da implementação e as orientações para administradores quando estes indicadores mudarem.

Se precisar de desativar o acesso ao computador local com o Work Cloud

Desativar o acesso ao computador local com o Work Cloud interrompe os turnos em curso. Os utilizadores podem iniciar um novo turno numa conversa existente na nuvem. Esse turno utiliza automaticamente o Work Cloud sem acesso a ficheiros locais. Informe os utilizadores de que devem iniciar um novo turno após a interrupção e explique que os ficheiros locais deixarão de estar disponíveis para a conversa na nuvem.