Acesso ao computador local para Work Cloud e dots

O Work e os dots podem utilizar ficheiros e ferramentas permitidos num computador ligado enquanto a cloud da OpenAI coordena a tarefa. Ative o acesso ao computador local separadamente para cada funcionalidade.

Comece pelas orientações comuns sobre políticas, compatibilidade e auditoria abaixo e, em seguida, siga as orientações de configuração e de utilização do Work ou dos dots para a funcionalidade que pretende ativar.

Este guia ajuda os proprietários de espaços de trabalho empresariais a rever os requisitos das políticas e a ativar o acesso ao computador local para o Work e os dots. A disponibilidade depende do espaço de trabalho e da implementação gradual.

Consulte Agent Security para obter informações sobre a base Global, as substituições por ambiente e as listas de campos do orquestrador e do executor.

Vantagens do acesso ao computador local

Ativar o acesso ao computador local nestas funcionalidades ajuda as equipas a continuar o trabalho entre dispositivos. Os administradores podem gerir centralmente os requisitos suportados em Agent Security para a execução num computador local. Estes requisitos de execução não se aplicam quando o Work utiliza um contentor na cloud ou um dot utiliza um computador na cloud. A execução na cloud utiliza controlos separados para o acesso ao navegador, o acesso à rede e a utilização do computador.

Work

• Continuar uma conversa do Work entre dispositivos. Comece num computador e, em seguida, reveja os resultados ou dê instruções adicionais a partir da aplicação Web ou móvel. As tarefas que utilizam o acesso ao computador local com o Work Cloud utilizam coordenação na cloud.

• Utilizar recursos aprovados no computador. Uma tarefa que utilize esta funcionalidade pode utilizar ficheiros e ferramentas locais permitidos através de um computador ligado enquanto acompanha o trabalho a partir de outro dispositivo. Mantenha esse computador online e ligado para os passos que dele necessitem.

• Gerir centralmente os requisitos de execução local. Defina os requisitos empresariais suportados em Agent Security para a execução local. Reveja separadamente as políticas do Work Cloud para a execução na cloud.

Dots

• Realizar trabalho de engenharia localmente. Investigue erros, implemente alterações e execute compilações utilizando repositórios locais, ferramentas de desenvolvimento e skills permitidos.

• Coordenar trabalho de programação. Crie conversas locais do Work ou do Codex e controle conversas locais existentes do Codex.

• Utilizar aplicações de ambiente de trabalho e o navegador local para tarefas suportadas, incluindo tarefas que exigem um início de sessão local quando o navegador na cloud não as consegue concluir.

Antes e depois de ativar o acesso ao computador local com o Work Cloud

Uma tarefa tem duas partes: coordenação e execução. A coordenação decide os passos a realizar e mantém a conversa em curso. A execução é o trabalho realizado por uma ferramenta, como executar um comando de shell. Esta funcionalidade transfere a coordenação para a cloud da OpenAI. Não transfere todas as ferramentas ou ficheiros para fora do computador.

Como configurar o acesso ao computador local

Rever a política em Agent Security

Onde rever

Abra Consola de administração → Agent Security. Esta opção substitui Políticas e configuração. A sua implementação gradual é independente do acesso ao computador local para o Work e os dots.

• Definições de políticas: Reveja a base Global e quaisquer substituições Local. Mantenha os controlos do orquestrador, incluindo aprovações e pesquisa na Web, em Global; os ambientes não os podem substituir. Utilize os controlos dedicados da interface, quando disponíveis, incluindo Políticas de aprovação permitidas e Modos de pesquisa na Web permitidos, e TOML para outros campos suportados. Consulte os controlos do orquestrador e do executor para saber onde se aplica cada definição.

• Requisitos e predefinições: Os requisitos estabelecem limites que os utilizadores não podem substituir. As predefinições fornecem valores iniciais dentro desses limites e não podem substituir um requisito.

• Acesso às funcionalidades: Utilize Definições do espaço de trabalho → Permissões e funções. O acesso ao computador local exige uma adesão separada para o Work e para os dots.

O que é transferido

Quando as políticas legadas da cloud elegíveis são migradas, as respetivas definições são transferidas para Global, preservando as atribuições e a ordem das políticas. Reveja as políticas migradas em Agent Security e utilize a tabela abaixo para verificar a configuração atual. Se automatizar as atualizações de políticas, reveja também a última linha. Consulte Agent Security para obter orientações sobre a migração.

Qual a política que tem precedência

Estas regras aplicam-se a níveis diferentes. Cada seta abaixo indica a ordem da prioridade mais alta para a mais baixa.

• Entre políticas: Uma política de prioridade superior prevalece sobre uma política de prioridade inferior, mesmo quando a política de prioridade inferior é mais específica.

• Dentro de uma política: Para as definições de execução suportadas, substituição por ambiente → Global. Um ambiente sem uma substituição herda a definição Global aplicável.

• Requisitos locais: Requisitos de MDM do macOS → campos legados de managed_config.toml interpretados como requisitos → requisitos geridos na cloud de Agent Security → requirements.toml do sistema. A camada MDM aplica-se no macOS; as predefinições seguem regras de configuração separadas.

Alguns requisitos têm regras de combinação específicas por campo. Consulte Configuração gerida e a Referência de configuração para obter informações sobre o âmbito das políticas, os campos suportados e o âmbito da execução.

Como as políticas se aplicam ao Work e aos dots

O comportamento comum ao Work e aos dots com acesso local abrange os seguintes âmbitos:

• Coordenação de tarefas: Quando a política gerida está ativada, o serviço na cloud que coordena a tarefa aplica os requisitos suportados de Global em Agent Security, como os requisitos de aprovação e os modos de pesquisa na Web permitidos.

• Execução local: Quando uma ferramenta é executada num computador ligado, aplica os requisitos de execução local suportados de Agent Security e as políticas de dispositivo aplicáveis, incluindo as políticas distribuídas através de MDM, quando suportadas. Estas podem incluir restrições do sistema de ficheiros e de rede. Apenas se aplicam os campos suportados pelo executor local; configurar um campo em MDM ou no requirements.toml local não garante que seja aplicado localmente.

• Execução na cloud: Os contentores na cloud do Work e os computadores na cloud dos dots utilizam controlos de execução separados. As restrições locais do sistema de ficheiros e de rede não se aplicam automaticamente a estes ambientes na cloud.

Para configurar as capacidades comuns na cloud, aceda a Consola de administração → Permissões e funções → Capacidades do espaço de trabalho → Capacidades do computador na cloud. Estas permissões abrangem tanto o Work Cloud como os dots. Reveja Utilização do navegador na cloud e Acesso à rede na cloud separadamente; configurar uma não configura a outra. As políticas Global e as substituições Codex Cloud não configuram estas permissões.

Verificar a compatibilidade e os requisitos de dados

Reveja a elegibilidade, a cobertura dos dados e os controlos de que a sua organização depende antes de ativar qualquer uma das funcionalidades. A infraestrutura partilhada não significa que o Work e os dots tenham suporte idêntico.

Rever a elegibilidade do Work e dos dots

• Work: A residência aplica-se apenas a conteúdo elegível e a cargas de trabalho, regiões e configurações suportadas. O EKM abrange conteúdo armazenado suportado em espaços de trabalho elegíveis. Confirme a cobertura do seu fluxo de trabalho em vez de presumir que todos os passos de acesso local ou integrações ligadas estão abrangidos. O Work não é suportado com residência de inferência nos EAU. Consulte Residência de dados e residência de inferência e Segurança do Work na cloud.

• Residência dos dots: Durante a versão beta Enterprise, os dots não suportam residência de dados nem residência de inferência. Os espaços de trabalho elegíveis podem aderir após reconhecerem essas limitações; ativar os dots não torna os respetivos dados ou processamento conformes com os requisitos de residência.

• Exclusões dos dots: Os dots não estão disponíveis para espaços de trabalho FedRAMP, espaços de trabalho com EKM e espaços de trabalho com a residência de inferência definida como AE (EAU). Os espaços de trabalho HIPAA podem participar se cumprirem os restantes requisitos de elegibilidade.

Verificar o tratamento de dados e a salvaguarda de acesso local

• Processamento na cloud: O Work com acesso local e os dots continuam a utilizar coordenação na cloud. As conversas, os resultados das ferramentas e outros elementos de contexto das tarefas não permanecem exclusivamente no computador ligado.

• Salvaguarda de residência: Se alguma política da cloud ativar enforce_residency, Permitir acesso ao computador local fica indisponível tanto para o Work como para os dots. Esta salvaguarda não define a residência do espaço de trabalho nem, por si só, desativa o Work Cloud ou os dots. Os espaços de trabalho elegíveis continuam a poder aderir aos dots após reconhecerem as limitações de residência da versão beta; o acesso local permanece bloqueado.

• Retenção e acesso aos dados: Nenhuma das experiências oferece retenção de dados estritamente nula. O Zero Data Retention da API é um controlo separado da API. Os compromissos de não visualização de dados («eyes-off») e os controlos de monitorização de abusos também são distintos da retenção nula. Se um fluxo de trabalho exigir que nenhum dado seja retido, não o ative para estas experiências.

Reveja a cobertura de retenção, eliminação e auditoria para os dados e as ferramentas efetivamente envolvidos antes da implementação. No Work, as conversas, o estado de execução alojado, os ficheiros e os dados de aplicações ligadas podem seguir ciclos de vida diferentes; eliminar uma conversa não remove todas as cópias relacionadas.

Verificar os hooks e a compatibilidade de rede

• Hooks empresariais suportados: Quando a política gerida e os hooks remotos estão ativados, o Work Cloud com acesso local e os dots utilizam hooks MCP remotos geridos por administradores. O orquestrador na cloud chama o serviço MCP ligado nos eventos de tarefas e ferramentas suportados. Configure os processadores mcp_tool em requirements.toml de Global. O Work Cloud sem acesso local não utiliza estes hooks; estes hooks empresariais não estão disponíveis para contas pessoais.

• Work Cloud e dots com acesso local: Os processadores de comando/shell, de prompt e de agente; os hooks de configuração local, de plugins ou de diretórios locais; os hooks com âmbito de ambiente; e os hooks MCP SessionEnd não são suportados com orquestração na cloud, mesmo quando a tarefa executa ferramentas no computador. Se o seu fluxo de trabalho depender de um destes hooks, continue a utilizar um fluxo de trabalho exclusivamente local que o suporte até ter revisto uma alternativa.

• Conversas exclusivamente locais no Work e no Codex: Quando tanto a orquestração como a execução são locais, os hooks existentes suportados continuam a funcionar. Os administradores continuam a poder configurar hooks geridos suportados em Agent Security para este fluxo de trabalho.

• Falhas e cobertura de auditoria: Teste a conectividade dos callbacks, os eventos necessários e o comportamento em caso de falha. Uma recusa explícita suportada pode bloquear uma ação, mas um erro de callback PreToolUse, um tempo limite excedido ou uma resposta malformada podem fazer o hook falhar sem bloquear a ferramenta. Os hooks não fornecem um registo de auditoria completo da Compliance API nem abrangem todos os percursos internos de subagentes.

• Controlos de rede e de aplicações: Verifique o campo, o método de distribuição e o ambiente de execução na Referência de configuração. Os controlos aplicados por aplicações ou dispositivos podem continuar a aplicar-se quando o orquestrador na cloud não utiliza uma definição. As portas de escuta HTTP/SOCKS geridas e os serviços de escuta de proxy fora de loopback não são suportados pelo ambiente de execução na cloud; o suporte de regras de sockets depende do percurso de execução. Reveja Precedência das políticas de rede e limites do ambiente de execução e, em seguida, teste as ações permitidas e bloqueadas e a conectividade necessária.

Para questões sobre ficheiros locais, execução na cloud ou precedência das políticas, consulte as Perguntas frequentes para administradores do Work, Segurança local do Work e Segurança do Work na cloud.

Ativar o acesso ao computador local

Conceda acesso ao computador local separadamente para o Work e os dots. Utilize as predefinições do espaço de trabalho e as funções personalizadas suportadas para conceder acesso aos utilizadores ou grupos pretendidos.

Antes da implementação, reveja as políticas e os requisitos de compatibilidade acima. Recomenda-se rever ou criar políticas em Agent Security, mas o fluxo de confirmação não exige a criação de políticas antes de ativar o acesso. A migração de políticas não concede acesso ao computador local.

Work

1. Como proprietário do espaço de trabalho, abra Definições do espaço de trabalho > Permissões e funções.

2. Ative Work Cloud para os utilizadores pretendidos. Utilizar o Codex localmente na aplicação ChatGPT para computador não é um pré-requisito para esta funcionalidade.

3. Em Work Cloud, ative Permitir acesso ao computador local. Reveja a janela de confirmação e, em seguida, abra Agent Security para rever ou definir políticas, ou confirme para ativar o acesso.

4. Peça aos utilizadores que atualizem a aplicação ChatGPT para computador para a versão 26.929 ou superior. A atualização é necessária para que o acesso ao computador local com o Work Cloud entre em vigor.

5. Peça a um membro com as permissões pretendidas que selecione Cloud no campo de composição da aplicação para computador e inicie uma nova tarefa. Continue a tarefa a partir de outro dispositivo suportado e verifique o acesso a um ficheiro ou ferramenta local aprovado enquanto o computador está ligado.

Dots

1. Como proprietário do espaço de trabalho, abra Definições do espaço de trabalho > Permissões e funções e ative os dots para os utilizadores pretendidos, respeitando os requisitos de elegibilidade acima.

2. Em Utilizar Dots, ative Permitir acesso ao computador local. Reveja a janela de confirmação e, em seguida, abra Agent Security para rever ou definir políticas, ou confirme para ativar o acesso.

3. Peça aos utilizadores que atualizem a aplicação ChatGPT para computador para a versão 26.929 ou superior. A atualização é necessária para que o acesso ao computador local entre em vigor.

4. Peça aos utilizadores que abram os detalhes do seu dot na aplicação ChatGPT para computador e escolham Computadores. Localize O seu computador (ou o nome do computador), selecione Permitir e, em seguida, confirme com Permitir acesso.

5. Peça a um membro com as permissões pretendidas e um computador ligado que teste uma tarefa local com o seu dot.

Rever o OpenTelemetry e a cobertura de auditoria

Para o Work com acesso local e os dots, distinga a telemetria de execução local dos registos de auditoria na cloud ao rever a cobertura do OpenTelemetry (OTel). O executor local continua a poder exportar eventos de execução suportados. Os eventos de orquestração na cloud não chegam ao coletor OpenTelemetry existente.

Utilize a Compliance API para os registos na cloud suportados. Alterar o endpoint do coletor não restaura os eventos de orquestração na cloud. Os registos da Compliance API não substituem todos os eventos do fluxo OpenTelemetry anterior.

Para os dots, utilize a Analytics API para dados de utilização e a Compliance API para registos de auditoria suportados. Valide os registos de que o seu fluxo de trabalho necessita, bem como a entrega ao coletor local; os hooks MCP não substituem a cobertura de auditoria.

Consulte Segurança do Work na cloud para obter informações sobre a cobertura de auditoria na cloud.

Experiência do utilizador final

Tanto no Work como nos dots, os passos locais exigem que o computador relevante esteja online e ligado, com a aplicação ChatGPT para computador em execução e com sessão iniciada na conta e no espaço de trabalho adequados.

Work

• Tarefas elegíveis. As novas tarefas elegíveis iniciadas na aplicação ChatGPT para computador com Cloud selecionado podem utilizar o executor local desse computador enquanto este estiver ligado e o acesso local estiver ativado.

• Início de sessão. Utilize Iniciar sessão com o ChatGPT no espaço de trabalho pretendido. As API keys e os tokens de acesso do Codex não ativam o acesso ao computador local com o Work Cloud.

• Computador indisponível. Se o computador estiver indisponível quando começar um novo turno, uma tarefa elegível existente pode continuar num contentor na cloud sem os ficheiros ou as ferramentas locais desse computador. O contentor não aplica os requisitos empresariais da execução local. Uma tarefa não pode mudar da execução local para a cloud durante um turno.

• Acesso desativado. Desativar o acesso ao computador local com o Work Cloud interrompe os turnos em execução. Os utilizadores podem iniciar um novo turno numa conversa existente na cloud; este utiliza o Work Cloud sem acesso a ficheiros locais.

• Conversas e projetos existentes. As tarefas criadas antes de esta funcionalidade ser ativada mantêm o seu modo original: exclusivamente local ou na cloud sem acesso a ficheiros locais. Inicie uma nova tarefa após ativar a funcionalidade para utilizar o acesso ao computador local com o Work Cloud.

• Definição Local/Cloud. Para as empresas, o seletor Local/Cloud na aplicação e a sua predefinição mantêm-se inalterados no lançamento. As tarefas elegíveis com Cloud selecionado utilizam coordenação na cloud e o computador ligado para os passos locais.

Dots

• Ligar um computador. Abra os detalhes do dot na aplicação ChatGPT para computador e, em seguida, escolha Computadores. Localize O seu computador (ou o nome do computador), selecione Permitir e, em seguida, confirme com Permitir acesso. O computador fica disponível para tarefas locais suportadas.

• Computador offline. A autorização de acesso guardada mantém-se, mas o trabalho que exige esse computador não pode prosseguir enquanto este estiver indisponível. Offline não significa que o acesso tenha sido revogado.

• Remover acesso. Escolha Revogar acesso e confirme para remover a autorização do dot para esse computador. Desligado significa que o acesso foi removido; é diferente de Offline.

• Alterações de acesso pelo administrador. Se um administrador desativar o acesso ao computador local para os dots, uma tarefa local já autorizada pode ainda estar a terminar. Não presuma que o comportamento do Work de interromper imediatamente os turnos em execução se aplica aos dots.

• Tarefas em execução. Uma tarefa local em execução não migra automaticamente para a cloud. As alterações de ligação podem interromper o trabalho ou recarregar o ambiente de execução. O dot pode continuar o trabalho subsequente no seu computador na cloud, mas uma tarefa subordinada local que já não tenha acesso não pode ser retomada nesse computador nem é transferida automaticamente para a cloud.