O ChatGPT Work pode usar arquivos, aplicativos e sessões de navegador aprovados no computador do usuário para concluir tarefas locais. O acesso depende das permissões do espaço de trabalho, do acesso que o usuário já tem com suas contas, das permissões do sistema operacional, das aprovações de aplicativos e das políticas de dispositivo compatíveis.
Para uma visão geral dos controles de segurança, consulte o documento técnico sobre segurança empresarial do ChatGPT Work.
Os recursos locais dependem do aplicativo para desktop compatível, do sistema operacional, dos recursos contratados pelo espaço de trabalho, das permissões da função, da política do dispositivo e da etapa de liberação do produto.
Resumo dos controles de segurança
-
O aplicativo ChatGPT para desktop executa as etapas locais. Com o acesso ao computador local pelo Work na nuvem, a nuvem da OpenAI coordena a tarefa e o computador conectado executa as etapas que exigem execução local.
-
Os controles disponíveis para o Work local e o Work hospedado dependem da configuração do espaço de trabalho e da etapa de liberação do produto.
-
O acesso a arquivos, o Uso do computador, os navegadores e os aplicativos conectados têm permissões e aprovações distintas.
-
Se o usuário já tiver iniciado sessão em um sistema da empresa pelo navegador ou por um aplicativo, a tarefa poderá usar as permissões dessa conta.
-
As políticas compatíveis de dispositivos gerenciados podem restringir recursos locais sem substituir os controles de acesso do espaço de trabalho.
-
Os serviços da OpenAI abrangidos por essas proteções criptografam os dados dos espaços de trabalho Business, Enterprise e Edu em trânsito e em repouso. Por padrão, a OpenAI não usa esses dados para treinar seus modelos.
-
Arquivos locais, contexto da tarefa, dados do navegador, registros de sistemas conectados e eventos de auditoria podem seguir regras diferentes de armazenamento e retenção.
Onde as tarefas locais são executadas
Na execução local, a tarefa acessa recursos aprovados por meio do aplicativo para desktop no computador do usuário. Quando o acesso ao computador local pelo Work na nuvem está habilitado, a nuvem da OpenAI coordena a tarefa e aciona o computador conectado quando uma etapa exige execução local. Para executar essas etapas, o computador precisa estar online e conectado.
Os requisitos do dispositivo se aplicam à execução local. Se uma nova interação for executada em um contêiner na nuvem enquanto o computador estiver offline, o contêiner seguirá suas próprias políticas e não terá acesso aos arquivos nem às ferramentas locais. Consulte Como continuar usando o Work em outro dispositivo.
Os arquivos locais podem permanecer no dispositivo, mas os serviços da OpenAI podem receber trechos relevantes de arquivos, prompts, capturas de tela, conteúdo do navegador ou resultados de ferramentas para concluir uma tarefa. A execução local não significa que a inferência do modelo ocorra offline ou exclusivamente no dispositivo.
Arquivos e acesso ao dispositivo
Uma tarefa local pode trabalhar com informações que o usuário fornece ou disponibiliza, como arquivos compatíveis, conteúdo de aplicativos, sessões de navegador e sistemas conectados autorizados. O acesso depende dos privilégios que o usuário já tem e dos controles específicos de cada recurso.
Conceder acesso local ao Work não aprova automaticamente todos os aplicativos, não concede privilégios de administrador nem contorna as permissões da conta usada para acessar outro sistema. Uma conexão compartilhada aprovada pode ter privilégios diferentes dos da conta pessoal do usuário.
A leitura direta de arquivos, a edição de arquivos e os comandos de shell seguem as configurações de sandbox e de aprovação da tarefa. O Uso do computador acessa o conteúdo por meio de um aplicativo nativo aprovado, com as permissões desse aplicativo. Restringir o acesso direto a arquivos não impõe, por si só, a mesma restrição aos arquivos que o aplicativo consegue abrir.
Uso do computador e aprovações de aplicativos
As permissões do espaço de trabalho determinam quem pode usar o Work local. As políticas dos administradores podem limitar ainda mais os aplicativos nativos que o Uso do computador pode operar e determinar se os usuários podem salvar aprovações de aplicativos para sessões futuras. As permissões obrigatórias do sistema operacional e as aprovações de aplicativos continuam valendo. Quando uma tarefa usa um aplicativo ou uma conta com sessão iniciada, as permissões dessa conta determinam quais informações e ações estão disponíveis.
Permitir um aplicativo por meio de uma política de administrador não instala o plugin necessário, não concede permissões do sistema operacional nem aprova ações que ainda exigem revisão. Para conhecer os controles compatíveis e ver exemplos de configuração, consulte Controles gerenciados do navegador e do Uso do computador.
No macOS, a permissão de Gravação de Tela permite que o Uso do computador veja o conteúdo dos aplicativos. A permissão de Acessibilidade permite que ele clique, digite e navegue. No macOS, as tarefas compatíveis podem ser executadas em segundo plano. No Windows, o Uso do computador opera na área de trabalho ativa e visível e não pode ser executado em segundo plano enquanto o usuário continua usando a mesma sessão.
O usuário pode interromper a tarefa a qualquer momento. O Uso do computador não pode aprovar solicitações de segurança do sistema operacional, autenticar-se como administrador nem automatizar aplicativos de terminal ou o próprio ChatGPT.
Dispositivos bloqueados
Em configurações compatíveis do macOS, é possível permitir que uma tarefa aprovada de Uso do computador continue após o bloqueio do Mac. A disponibilidade depende da versão do aplicativo, da etapa de liberação do recurso, dos requisitos aplicáveis e da elegibilidade para controle remoto.
Ao habilitar o uso com o Mac bloqueado, você instala um plug-in de autorização do macOS que pode desbloquear o Mac temporariamente durante uma interação ativa e confiável do Uso do computador. O ChatGPT cobre todas as telas durante o desbloqueio temporário. Se detectar atividade local do teclado ou do dispositivo apontador, o ChatGPT bloqueia o Mac novamente e suspende o desbloqueio automático até que o usuário desbloqueie o Mac manualmente. Consulte Como funciona o uso com o Mac bloqueado.
Os administradores podem impedir que os usuários habilitem o uso com o Mac bloqueado em Macs gerenciados. Esse requisito não desativa o recurso se ele já estiver habilitado. No Windows, o Uso do computador exige uma área de trabalho ativa e desbloqueada. Consulte Restrições de uso com o computador bloqueado.
Sessões de navegador e contas já conectadas
O Work local não obtém acesso automático a todos os navegadores nem a todas as contas da empresa. O acesso depende do navegador usado, da conta com sessão iniciada e das aprovações exigidas para essa forma de usar o navegador.
| Forma de acesso ao navegador | Sessão e limites de segurança |
|---|---|
| Navegador integrado ao aplicativo para desktop | Usa um perfil separado do perfil habitual do usuário no navegador. O usuário pode iniciar sessão nesse perfil. Nos clientes compatíveis, as políticas gerenciadas do recurso Navegador restringem os sites que o agente pode acessar e os recursos do navegador que ele pode usar. O navegador integrado não pode automatizar uploads de arquivos. |
| Extensão do Chrome | Pode interagir com abas existentes e contas com sessão iniciada quando a extensão e o acesso ao site têm aprovação. Nos clientes compatíveis, as mesmas políticas gerenciadas do recurso Navegador se aplicam às ações que o agente realiza pela extensão. |
| Navegador operado pelo Uso do computador | O Uso do computador opera o navegador como um aplicativo nativo aprovado e pode usar contas com sessão já iniciada. As políticas do recurso Navegador que controlam o acesso a sites e o uso de recursos não se aplicam a essa forma de acesso. As políticas de aplicativos nativos, as permissões do sistema operacional, as aprovações de aplicativos e as permissões da conta com sessão iniciada continuam valendo. |
As políticas compatíveis do recurso Navegador podem restringir o acesso a sites, os uploads, os downloads, o acesso ao histórico de navegação e o acesso completo ao Chrome DevTools Protocol (CDP) para depurar o navegador. Os administradores também podem restringir a revisão automática de aprovações, as aprovações salvas e o prazo de validade das aprovações de acesso a sites. A aprovação de um usuário não pode se sobrepor à negativa de um administrador. Consulte Controles gerenciados do navegador.
O navegador hospedado na nuvem é separado dos navegadores locais do usuário e não herda automaticamente as sessões já iniciadas neles. Nos espaços de trabalho Enterprise e Edu, não é possível iniciar sessão em sites pelo navegador na nuvem.
Aplicativos, plugins e contas conectadas
Um aplicativo conectado pode dar acesso a informações ou ações em outro sistema. Um plugin pode usar um aplicativo como ferramenta. Disponibilizar um plugin não habilita automaticamente o aplicativo necessário, não autoriza uma conta nem permite todas as ações.
As configurações padrão de plugins e aplicativos dependem do plano e de o espaço de trabalho ser novo ou já existir. Os novos espaços de trabalho Enterprise e Edu começam com um conjunto selecionado de aplicativos habilitados. Esses padrões não alteram as configurações de espaços de trabalho existentes nem se aplicam aos espaços de trabalho Healthcare. Em geral, novos plugins e aplicativos vêm desabilitados por padrão nos planos Enterprise e Edu. No plano Business, os aplicativos vêm habilitados por padrão. Os administradores podem alterar a disponibilidade. Consulte as configurações padrão atuais de plugins e aplicativos e a visão geral do ChatGPT Work.
Antes que uma tarefa use um sistema conectado, confirme que o espaço de trabalho permite o aplicativo e todos os plugins necessários, que a conexão está autorizada e que a conta conectada pode acessar as informações solicitadas ou executar a ação pedida. As configurações de somente leitura, as ações permitidas e as exigências de confirmação variam conforme a integração.
Os plugins que oferecem recursos de navegador ou de Uso do computador exigem uma revisão própria de disponibilidade e instalação. Disponibilizar um plugin não se sobrepõe às políticas gerenciadas de navegador ou de aplicativos nativos, às permissões do sistema operacional nem às aprovações obrigatórias. Plugins exclusivos para desktop e ferramentas disponibilizadas localmente podem seguir processos de instalação diferentes. Consulte Controles de plugins.
Conexões pessoais e compartilhadas
Uma conexão pessoal usa as permissões do usuário conectado no sistema de origem. Uma conexão compartilhada ou pertencente ao agente usa as permissões da conta conectada, que podem dar acesso mais amplo do que o do próprio usuário.
Limite as contas compartilhadas aos dados e às ações necessários, restrinja quem pode usá-las e aplique os controles de ação ou de confirmação compatíveis. Os registros no sistema conectado continuam sujeitos às permissões e às políticas de retenção desse sistema.
Acesso de administradores e políticas de dispositivos gerenciados
Para o acesso ao computador local pelo Work na nuvem, verifique tanto a permissão de sincronização do espaço de trabalho quanto os requisitos de Segurança do agente para execução local.
Na execução local, os requisitos de MDM e os requisitos legados de dispositivos gerenciados têm prioridade sobre os de Segurança do agente. O arquivo de requisitos do sistema no dispositivo tem prioridade inferior aos requisitos de Segurança do agente. Dentro de uma mesma política, as substituições de configuração do ambiente específicas de um sistema operacional têm prioridade sobre as que valem para todos os sistemas operacionais. As configurações globais vêm em seguida. A política de maior prioridade prevalece mesmo que outra de menor prioridade seja mais específica. Alguns requisitos têm regras de mesclagem específicas para cada campo.
Use a API de políticas para gerenciar as configurações globais. Para gerenciar as configurações de Local ou Codex Cloud, use a interface de Segurança do agente. 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 do Terraform e confirme que as atribuições e a ordem das políticas continuam as mesmas.
Para o Work com acesso local e para os dots, o orquestrador compartilhado na nuvem aplica a política global compatível quando a política gerenciada está habilitada. Os requisitos locais aplicáveis de requirements.toml regem a execução no computador conectado. Os contêineres do Work na nuvem e os computadores dos dots na nuvem usam suas próprias configurações e requisitos de execução, em vez do pacote de ambiente gerenciado usado por outros tipos de executor. As restrições de execução local não se aplicam automaticamente a esses computadores na nuvem. Verifique as permissões dos recursos de nuvem e teste separadamente a execução local e a execução na nuvem.
Antes de habilitar a sincronização, verifique os seguintes requisitos:
-
Políticas distribuídas exclusivamente por MDM. O MDM distribui as políticas aos dispositivos. Antes de habilitar a sincronização, defina em Segurança do agente um conjunto básico de requisitos compatíveis para execução local.
-
Hooks empresariais. Se um fluxo de trabalho exclusivamente local depender de scripts ou de hooks de plugins, verifique quais hooks o orquestrador na nuvem aceita antes de habilitar o acesso ao computador local. Teste os eventos necessários e verifique a cobertura da auditoria.
Confira os controles do Work disponíveis em Configurações do espaço de trabalho > Permissões e funções. A configuração do espaço de trabalho e a etapa de liberação do produto determinam se o Work local e o Work hospedado aparecem como permissões distintas. Para mais orientações, consulte as perguntas frequentes para administradores do Work.
Habilite apenas os ambientes de execução aprovados para cada usuário ou grupo e verifique o acesso efetivo após fazer alterações.
As permissões do espaço de trabalho determinam quem pode usar o Work. Os administradores também podem restringir recursos compatíveis do aplicativo para desktop impondo requisitos definidos em requirements.toml. Dependendo da implantação, é possível distribuir esses requisitos pela configuração gerenciada do espaço de trabalho, por um arquivo de configuração no nível do sistema ou por ferramentas compatíveis de gerenciamento de dispositivos móveis do macOS.
Os usuários não podem substituir os requisitos obrigatórios. Já os padrões gerenciados definem configurações iniciais que os usuários talvez possam alterar. Nenhum dos dois substitui as funções do espaço de trabalho ou as permissões do sistema operacional.
Nos clientes locais que usam o caminho de configuração local existente, os requisitos gerenciados são carregados junto com a configuração. Uma atualização em segundo plano pode preparar os requisitos da nuvem para um carregamento posterior. No macOS, o cliente lê as alterações do MDM na próxima inicialização. Após alterar uma política local, reinicie o cliente local correspondente e verifique a configuração.
O comportamento de carregamento local não determina quando uma alteração de política na nuvem entra em vigor em uma tarefa em andamento que usa o acesso ao computador local pelo Work na nuvem. Antes de contar com a atualização, verifique quais controles estão efetivamente em vigor na tarefa.
| Configuração gerenciada | Finalidade de segurança |
|---|---|
features.computer_use = false |
Desabilitar os recursos nativos de Uso do computador. |
allow_appshots = false |
Impedir a captura de Appshots onde houver suporte. |
features.in_app_browser = false |
Desabilitar o navegador integrado ao aplicativo para desktop. |
features.browser_use = false |
Desabilitar as funcionalidades compatíveis do recurso Navegador. O uso externo desse recurso tem uma flag separada. |
features.browser_use_external = false |
Impedir que o agente use o recurso Navegador por meio de extensões de navegador compatíveis. |
features.apps = false ou features.plugins = false |
Restringir aplicativos conectados ou plugins compatíveis. |
computer_use.allow_locked_computer_use = false |
Impedir que usuários habilitem o uso com o Mac bloqueado em Macs gerenciados. Isso não desativa o recurso onde ele já está habilitado. |
Esses exemplos mostram restrições. Eles não listam os recursos habilitados por padrão. Quando você omite um requisito de recurso, continuam valendo as configurações habituais do cliente, da plataforma, da etapa de liberação e do usuário. As flags do recurso Navegador, o painel do navegador integrado e o Uso do computador por meio de aplicativos nativos têm controles separados. Verifique cada forma de acesso ao navegador de maneira independente.
As configurações e os métodos de distribuição disponíveis dependem do cliente, do sistema operacional, do espaço de trabalho e da configuração da implantação. Verifique as restrições em um dispositivo gerenciado representativo da implantação. Para conhecer as configurações de política compatíveis, ver exemplos e obter instruções de configuração do MDM, consulte Configuração gerenciada.
Rede local e recursos privados
O Work local pode acessar informações da empresa por meio de um navegador, aplicativo nativo, aplicativo conectado ou outra ferramenta compatível. Os controles de rede se aplicam de maneira diferente a cada forma de acesso. Ter acesso a uma VPN corporativa não autoriza, por si só, uma tarefa a usar um recurso interno.
Os requisitos de rede gerenciada e as políticas de origem do recurso Navegador são verificados separadamente. Verifique ambos nas versões do aplicativo e nos sistemas operacionais da sua implantação antes de contar com uma restrição de rede para limitar o recurso Navegador. A verificação das políticas do navegador não significa que o tráfego do navegador passe pelo proxy de rede usado pelos comandos. As políticas do recurso Navegador não controlam o tráfego de aplicativos nativos.
Os requisitos de rede gerenciada em [experimental_network] são experimentais e podem mudar. O suporte ao Windows é limitado. Teste a versão específica do cliente e o ambiente antes de aplicar esses requisitos aos usuários do Windows. As regras de domínio, por si só, não ativam o proxy gerenciado. É necessário definir experimental_network.enabled = true, e essa configuração não se sobrepõe a um sandbox que mantenha o acesso à rede desabilitado.
Verifique a conexão, a conta com sessão iniciada, o destino e a ação exigida pelo fluxo de trabalho. Para detalhes de configuração e limitações de cada plataforma, consulte Requisitos de acesso à rede.
Tratamento e retenção de dados
No acesso ao computador local pelo Work na nuvem, a coordenação na nuvem faz parte do fluxo de trabalho mesmo quando uma etapa é executada no computador. Analise os dados da conversa e o contexto da tarefa separadamente dos arquivos locais usados por uma ferramenta. Não presuma que a execução local implique armazenamento exclusivo no dispositivo nem que todos os arquivos de uma pasta sejam enviados.
O acesso ao computador local pelo Work na nuvem não oferece garantia estrita de zero retenção 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 compatíveis. O gerenciamento de chaves empresariais (EKM) abrange o conteúdo armazenado compatível nos espaços de trabalho elegíveis. O Work não oferece suporte à residência de inferência nos Emirados Árabes Unidos. Antes da implantação, confirme a cobertura de armazenamento, retenção e auditoria do espaço de trabalho. Se sua organização exige zero retenção de dados (ZDR), não habilite esse recurso. Se enforce_residency estiver habilitado em qualquer política de nuvem, a opção Permitir acesso ao computador local ficará desabilitada tanto para o Work quanto para os dots. Essa proteção não configura a residência de dados do espaço de trabalho nem desabilita, por si só, o Work na nuvem ou os dots.
Aplique os controles da sua organização para endpoints, acesso a arquivos, proxy e prevenção de perda de dados ao dispositivo e ao fluxo de trabalho específicos. Confirme se esses controles conseguem impedir que informações sensíveis entrem na tarefa antes do processamento. Os logs de auditoria e as exportações de conformidade ajudam no monitoramento e na investigação, mas não bloqueiam o processamento por si só.
O armazenamento e a retenção dependem da categoria das informações e de onde elas são salvas.
| Categoria de informações | O que verificar |
|---|---|
| Registros locais de conversas | Como o aplicativo para desktop armazena, exclui, compartilha ou faz backup dos registros locais. Não presuma que as configurações de retenção de conversas hospedadas se apliquem a todos os artefatos locais. |
| Arquivos locais e resultados gerados | Armazenamento no dispositivo, política de endpoint, uploads autorizados pelo usuário, compartilhamento externo e eventuais cópias salvas separadamente. |
| Prompts, trechos de arquivos e contexto de aplicativos | Conteúdo fornecido a um modelo ou serviço, termos aplicáveis ao espaço de trabalho e fluxo real dos dados durante a tarefa. |
| Voz e Appshots | Entrada do microfone, capturas de tela da janela em primeiro plano, texto acessível do aplicativo, armazenamento local da sessão e qualquer conteúdo enviado como contexto da tarefa. |
| Dados do navegador | Perfil do navegador usado, sessões já iniciadas, histórico de navegação, downloads, aprovações de sites e qualquer conteúdo da tarefa armazenado separadamente. |
| Registros de sistemas conectados | Permissões e retenção no sistema de origem, identidade da conta conectada e qualquer informação salva separadamente na conversa ou em outro destino. |
| Registros de conformidade e atividade | Eventos do Work local disponíveis no espaço de trabalho, integração compatível e política de retenção do sistema que recebe os registros. |
Nos espaços de trabalho Business, Enterprise e Edu compatíveis, os serviços da OpenAI abrangidos por essas proteções criptografam os dados empresariais em trânsito e em repouso. Por padrão, a OpenAI não usa esses dados para treinar nem aprimorar seus modelos. Essas proteções não significam que a OpenAI controle todos os arquivos dos dispositivos, aplicativos de terceiros, perfis de navegador ou registros dos sistemas de origem.
Antes de aplicar a registros locais um prazo de retenção definido para conversas hospedadas, uploads temporários ou logs de conformidade, confirme que ele se aplica à categoria de dados em questão.
Visibilidade para auditoria e conformidade
Habilitar o acesso ao computador local pelo Work na nuvem altera os eventos que seu coletor OpenTelemetry (OTel) atual recebe. O executor local ainda pode exportar eventos de execução compatíveis. Os eventos de orquestração na nuvem não chegam ao coletor OpenTelemetry atual.
Use a API de Compliance para obter os registros de nuvem compatíveis. Alterar o endpoint do coletor não restabelece o recebimento de eventos de orquestração na nuvem. Os registros da API de Compliance não substituem todos os eventos do fluxo anterior do OpenTelemetry. Consulte Verificar a cobertura do OpenTelemetry e da auditoria.
Os relatórios disponíveis dependem do plano do espaço de trabalho, de como o produto é usado, do evento, do aplicativo conectado e da configuração implantada. Verifique a cobertura do Work local antes de usar uma exportação do espaço de trabalho como base para responder a incidentes ou realizar uma análise regulatória.
Nas versões compatíveis, o recurso Navegador pode emitir eventos do OpenTelemetry ao verificar permissões de uso de recursos, como acesso a sites, uploads e downloads. Esses eventos registram a decisão e sua origem, com detalhes da política quando disponíveis. A origem da decisão pode ser desconhecida. Quando a exportação está configurada, esses eventos são enviados ao endpoint OpenTelemetry do cliente junto com os demais dados de telemetria do ambiente de execução local.
Configure a exportação do OpenTelemetry separadamente dos registros da API de Compliance. Esses eventos não fornecem um registro completo de todas as ações realizadas em navegadores ou aplicativos nativos. Consulte Configuração do OpenTelemetry.
Verifique se os sistemas relevantes registram a identidade da tarefa, os prompts e as respostas compatíveis, as chamadas a aplicativos conectados, as aprovações do navegador, as ações em aplicativos, a atividade em arquivos locais ou os eventos de endpoint. Os registros dos sistemas de origem e dos dispositivos podem mostrar informações diferentes das que constam nos registros do espaço de trabalho do ChatGPT.
A OpenAI não armazena um registro completo separado das ações realizadas no Chrome por meio da extensão. Não presuma que a API de Compliance registre todas as operações em arquivos locais, capturas de tela, ações no navegador, aprovações ou atualizações externas.
Comece com uma tarefa aprovada
Teste o Work local nos dispositivos gerenciados usados pelas suas equipes. Execute uma tarefa aprovada, como comparar pastas de trabalho selecionadas da área financeira. Confirme o acesso de cada usuário ao Work e disponibilize apenas os arquivos, aplicativos, sessões de navegador ou contas conectadas necessários para a tarefa.
Verifique se as ações aprovadas funcionam, se as ações restritas são bloqueadas e se os registros disponíveis atendem às suas necessidades de monitoramento. Peça ao usuário que revise os resultados e confirme que todas as alterações feitas em arquivos ou sistemas conectados correspondem ao que foi solicitado.