Português

Guia de configuração da HIPAA para o Codex

Configure o Codex para fluxos de trabalho que possam tratar informações de saúde protegidas

A quem se destina

Este guia destina-se a administradores de TI e profissionais de conformidade, para que se familiarizem com a responsabilidade partilhada pela gestão de Informações de Saúde Protegidas (PHI) no Codex. O Codex inclui a aplicação ChatGPT para computador, a extensão Codex para IDE e o Codex CLI, que são executados nos computadores dos seus utilizadores. Não abrange a utilização do Codex na cloud.

Se utilizar o ChatGPT for Healthcare, o ChatGPT for Clinicians ou um espaço de trabalho Regulated, tiver um OpenAI Business Associate Agreement (BAA) aplicável e dispuser do acesso necessário ao Codex, a OpenAI trata as PHI que recebe do Codex em conformidade com o BAA. A OpenAI trata de forma segura os pedidos, ficheiros e outras entradas que recebe através da sua utilização do Codex e devolve-lhe as saídas de forma segura.

A OpenAI e a sua organização partilham a responsabilidade pela segurança dos serviços da OpenAI. É responsável pela configuração segura das estações de trabalho locais, dos repositórios de código-fonte, da retenção local, dos servidores MCP locais, da atividade de Browser Use e Computer Use, das aplicações para computador e dos serviços de terceiros, como plugins e apps.

A OpenAI disponibiliza recursos para o ajudar a configurar o Codex, incluindo a nossa página Web, a documentação e o Documento técnico de segurança do Codex no Trust Portal. Consulte estes materiais antes de permitir que o Codex seja utilizado com PHI. Este guia fornece exemplos de como algumas destas ferramentas podem ser utilizadas.

Responsabilidade partilhada

Tal como acontece com a maioria das soluções de cloud, o fornecedor do serviço de cloud e o cliente partilham a responsabilidade pela conformidade. O ChatGPT Enterprise armazena entradas e saídas na cloud da OpenAI. As estações de trabalho dos seus utilizadores conservam as entradas e saídas do Codex. O Codex envia entradas, como pedidos e ficheiros, à OpenAI para inferência, e a OpenAI devolve as saídas. Para utilizações autenticadas através do ChatGPT, a OpenAI conserva registos de auditoria durante um período máximo de 30 dias, para que possa obtê-los através da Compliance API. A OpenAI não utiliza os dados do ChatGPT Enterprise nem os dados do Codex para treino.

A configuração da sua estação de trabalho local, especificamente os respetivos ficheiros de políticas TOML, determina o que o Codex pode fazer no computador de um utilizador. Afeta a possibilidade de o Codex ler e escrever ficheiros, executar comandos, utilizar o acesso à rede, invocar plugins ou conectores, chamar ferramentas MCP, abrir superfícies do browser e conservar transcrições locais.

Estas definições não alteram as obrigações da OpenAI ao abrigo do BAA, mas são fundamentais para as suas salvaguardas HIPAA. É responsável por configurar estas definições em conformidade com as suas políticas de tratamento de PHI.

Programa de segurança da OpenAI

A OpenAI mantém um programa de segurança empresarial concebido para proteger os dados tratados pelos serviços da OpenAI e ajudar as organizações reguladas a cumprir as respetivas obrigações de conformidade. Pode encontrar mais informações sobre o programa de segurança da OpenAI no Trust Portal.

A OpenAI implementa um programa de Gestão de Riscos Empresariais e uma estrutura formal de governação de riscos que inclui a apresentação de relatórios a comissões do conselho de administração. As atividades de garantia dos produtos ajudam a assegurar que os lançamentos preservam salvaguardas como a encriptação, o acesso com privilégios mínimos e o registo granular para apoiar a conformidade com a HIPAA. As avaliações de riscos dos produtos, a monitorização de controlos e as análises de conformidade ajudam a identificar riscos razoavelmente previsíveis para os seus dados, avaliar a eficácia das salvaguardas e apoiar a melhoria contínua dos controlos utilizados pelo ChatGPT Enterprise, pela plataforma API e pelos serviços relacionados com o Codex.

As salvaguardas de desenvolvimento seguro e CI/CD ajudam a reduzir o risco de as alterações aos serviços relacionados com o Codex introduzirem acessos não autorizados, fugas de dados ou problemas de integridade. Estas salvaguardas incluem acesso controlado ao código-fonte, revisão por pares, testes automatizados, verificações de segurança nos fluxos de trabalho de compilação e implementação, controlos de tratamento de segredos e processos de implementação monitorizados. Um processo controlado de entrega de software protege a camada de serviços da OpenAI, embora continue a ser responsável pela boa gestão dos repositórios locais, pela segurança das estações de trabalho e pelo comportamento permitido pela configuração dos ficheiros de políticas locais.

O programa de gestão de vulnerabilidades da OpenAI inclui análises contínuas, revisões de dependências e infraestruturas, triagem baseada na gravidade, acompanhamento da correção e validação das correções. A OpenAI também utiliza equipas vermelhas internas e externas, testes de segurança independentes e canais de divulgação responsável para identificar e resolver fragilidades de segurança antes que estas possam afetar os seus dados.

Os controlos de proteção de dados incluem a encriptação dos seus dados em trânsito e em repouso, controlos de identidade e acesso, administração baseada em funções, registo e controlos de retenção que seguem as definições aplicáveis da organização do ChatGPT Enterprise ou da API.

Início de sessão no Codex

Ao utilizar modelos da OpenAI, o Codex suporta dois métodos de início de sessão na OpenAI: início de sessão no ChatGPT para acesso por subscrição e início de sessão com API key para acesso baseado na utilização. O início de sessão no ChatGPT requer uma conta elegível para HIPAA, o OpenAI BAA aplicável, bem como o acesso ao Codex e as permissões do espaço de trabalho necessários. Para o início de sessão com API key, o BAA só abrange os dados tratados pela OpenAI se incluir API Services with Modified Retention como um Eligible Service. A OpenAI também tem de aprovisionar a organização da API com Modified Retention, salvo indicação em contrário. Consulte Produtos e funcionalidades elegíveis para HIPAA para obter mais informações. É responsável por celebrar um BAA com qualquer terceiro que possa aceder a PHI através de qualquer plugin ou app instalado.

Com o início de sessão no ChatGPT, a utilização do Codex segue as permissões do espaço de trabalho ChatGPT do utilizador, o controlo de acesso baseado em funções (RBAC) e as definições de retenção e residência do ChatGPT Enterprise. Com o início de sessão através de API key, a utilização do Codex segue as definições de retenção, partilha de dados e administração da organização da OpenAI API, em vez das definições do espaço de trabalho ChatGPT. O início de sessão com API key é frequentemente utilizado em fluxos de trabalho programáticos do Codex CLI, como tarefas CI/CD fidedignas, mas não deve expor API keys em ambientes de execução públicos ou não fidedignos.

As suas responsabilidades

Continua a ser responsável pelas estações de trabalho onde o Codex é executado. Efetue a sua própria análise de riscos para a utilização local do Codex, incluindo controlos como a configuração das estações de trabalho, a segurança do sistema operativo, a encriptação do disco, a proteção contra software malicioso, a gestão de dispositivos, a aplicação de correções, o acesso dos utilizadores, o armazenamento seguro de credenciais e a retenção local.

Cabe-lhe decidir que utilizadores podem utilizar o Codex, que métodos de início de sessão podem utilizar, a que espaços de trabalho podem aceder, se podem iniciar sessão com uma API key, que repositórios e pastas podem conter PHI e se o Codex pode utilizar serviços externos.

É também responsável pelos serviços de terceiros ativados e por determinar quais os utilizadores que têm acesso aos mesmos. Se a sua organização ativar um destino de browser, plugin, conector ou servidor MCP para o Microsoft SharePoint, Google Drive, GitHub ou outro serviço num ambiente com PHI, confirme que a sua organização aprova o serviço para PHI e dispõe de um BAA adequado ou de um aditamento comparável para cuidados de saúde. O BAA da OpenAI não transforma outro fornecedor num destino em conformidade com a HIPAA.

As secções seguintes explicam como pode utilizar o ficheiro de configuração de políticas requirements.toml e as definições relacionadas para controlar o funcionamento do Codex. Consulte a documentação da OpenAI para conhecer outras definições e repita periodicamente essa análise à medida que as capacidades do Codex forem alteradas.

Ativar o Codex

Siga as instruções de configuração administrativa do Codex Enterprise para ativar o Codex Local no seu espaço de trabalho e confirme que os utilizadores dispõem das permissões necessárias e que a sua organização tem um BAA com a OpenAI.

O BAA não abrange o Codex cloud. Não utilize o Codex cloud com PHI.

Configurar o controlo de acesso baseado em funções

Pode personalizar o acesso ao Codex e à respetiva configuração através do RBAC. Por exemplo, os utilizadores que não interagem com PHI podem receber uma configuração mais permissiva, enquanto os utilizadores que interagem com PHI podem receber a configuração deste guia. Controle o acesso ao Codex em toda a organização na página de funções e permissões de administração do ChatGPT. Para controlar o acesso de utilizadores específicos, crie grupos e edite as respetivas permissões.

Rever plugins e conectores

O Codex na aplicação ChatGPT para computador e o Codex CLI suportam plugins, que podem incluir conectores e competências. Os plugins não estão disponíveis na extensão IDE. Os conectores permitem trocar dados com fontes de dados de terceiros. Antes de ativar um plugin com um conector, determine se necessita de um BAA com qualquer terceiro que receba dados através do conector. As competências são instruções que funcionam no âmbito da configuração de políticas. Analise as competências para garantir que são adequadas à finalidade, tal como faria com qualquer outro script.

Os administradores do espaço de trabalho têm de disponibilizar um plugin através dos controlos de plugins e ativar separadamente os respetivos conectores antes de os utilizadores poderem usá-los. Configure o acesso aos conectores nas definições de conectores.

Configurar requisitos geridos e predefinições

Os requisitos e as predefinições geridas nos ficheiros de configuração TOML gerem o comportamento do Codex. Para definir restrições impostas pelo administrador que os utilizadores não podem substituir, utilize requisitos geridos em requirements.toml. A OpenAI recomenda a utilização de configuração gerida para impor os seus requisitos de tratamento de dados relativos a PHI.

Os administradores podem configurar requisitos geridos na nuvem na página de configuração gerida do Codex, utilizando sintaxe compatível com requirements.toml. Também podem distribuir requisitos através da gestão de dispositivos, como o MDM do macOS. O Codex aplica os requisitos por ordem de precedência, da mais baixa para a mais alta: requirements.toml do sistema, requisitos geridos na nuvem, requisitos legados de managed_config.toml e requisitos de MDM do macOS. As camadas com maior precedência substituem valores escalares e de lista comuns; alguns requisitos têm um comportamento de combinação específico do campo.

Para restringir os fluxos de trabalho com PHI a um espaço de trabalho ChatGPT aprovado, implemente allowed_login_methods = ["chatgpt"] e allowed_chatgpt_workspaces = ["<workspace-id>"] através do requirements.toml do sistema ou de MDM. Os requisitos geridos na nuvem ignoram ambas as definições e as restrições do espaço de trabalho, por si só, não bloqueiam o início de sessão com API key. Os fluxos de trabalho com API key também requerem requisitos do sistema ou MDM porque não recebem os requisitos geridos na nuvem do espaço de trabalho.

As predefinições geridas são distintas dos requisitos. Definem a configuração inicial com que o Codex é iniciado, mas os utilizadores podem alterar essas definições durante uma sessão. O Codex volta a aplicar as predefinições da próxima vez que for iniciado. Utilize as predefinições geridas para normalização, não para impor rigorosamente a conformidade. Por exemplo, pode definir um modelo, um perfil de permissões ou outro comportamento local preferido como predefinição. Se uma definição tiver de ser incontornável nos fluxos de trabalho com PHI, coloque-a nos requisitos. Para as predefinições geridas, as preferências geridas por MDM do macOS têm a precedência mais elevada, seguidas de managed_config.toml do sistema e, por fim, de config.toml local do utilizador.

A tabela seguinte resume algumas definições disponíveis para configurar o Codex. Consulte estas definições e os recursos em Referências para configurar o Codex de forma alinhada com as suas necessidades de conformidade.

Ferramenta de configuração Definições disponíveis Explicação
Método de início de sessão Início de sessão no ChatGPT; início de sessão com API key apenas com Serviços de API abrangidos por um BAA e com Retenção Modificada. Determina se são aplicados os controlos do espaço de trabalho do ChatGPT ou os controlos da organização da API.
Política de aprovação allowed_approval_policies: "on-request", "untrusted", "never" e granular em tabela inline1 Configura quando o Codex solicita aprovação.
Responsável pela aprovação allowed_approvals_reviewers = ["user", "auto_review"] Configura a forma como o Codex encaminha as aprovações dos limites da sandbox.
Perfis de permissões2 default_permissions = ":workspace"
Permita apenas :read-only e :workspace.
Esta política permite acesso só de leitura e ao espaço de trabalho, mas não acesso total.
Pesquisa na Web allowed_web_search_modes = ["cached", "indexed", "live", "disabled"] Configura a forma como o Codex utiliza a Web.
Funcionalidades de browser e computer-use true ou false Configura funcionalidades específicas de cada superfície.
Servidores MCP Deixe [mcp_servers] vazio por predefinição; inclua na lista de permissões apenas servidores exatos e aprovados. Desativa os serviços MCP locais por predefinição. Adicione apenas servidores ou conectores aprovados.
  1. O valor "granular" permite que os administradores autorizem políticas de aprovação granulares. Em allowed_approval_policies, codifique-o como uma tabela inline que defina todas as categorias de aprovação:
   allowed_approval_policies = [
     "on-request",
     "untrusted",
     "never",
     { granular = { sandbox_approval = true, rules = true, mcp_elicitations = true, request_permissions = true, skill_approval = true } },
   ]

Para selecionar uma política granular em config.toml, configure approval_policy com a mesma estrutura de tabela inline. Quando uma categoria é false, o Codex rejeita esses pedidos em vez de solicitar aprovação.

  1. As listas de permissões de perfis de permissões requerem o Codex 0.138.0 ou posterior. Para impor a restrição da tabela, inclua a lista de permissões completa em requirements.toml:
   default_permissions = ":workspace"

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

Quando [allowed_permission_profiles] está presente, os perfis omitidos são recusados. Por conseguinte, omitir :danger-full-access impede os utilizadores de selecionar acesso total.

Mantenha untrusted em allowed_approval_policies para preservar a política de aprovação mais rigorosa que o Codex deriva para projetos com trust_level = "untrusted". Não defina approval_policy = "untrusted" diretamente; o Codex e o ChatGPT Work já não suportam essa definição. Consulte Migrar da política de aprovação untrusted descontinuada.

Exemplo 1: Ativar o plugin Google Drive

Ative o Google Drive apenas para um grupo aprovado depois de confirmar o respetivo fluxo de dados, âmbitos OAuth, controlos de acesso e situação do BAA de terceiros. O BAA da OpenAI rege o tratamento de PHI pela OpenAI; não abrange automaticamente a Google enquanto destinatária ou detentora de PHI.

Este conector gerido pelo espaço de trabalho requer o início de sessão no ChatGPT e não está disponível com autenticação por API key.

O Codex utiliza a chave de configuração apps para as definições de conectores. Este exemplo define predefinições locais para o conector do Google Drive. Substitua <approved-google-drive-app-id> pelo ID exato da aplicação da sua instalação aprovada; um nome a apresentar ou um ID estimado não aplicará a configuração.

# Example config.toml change for a group approved to use
# the Google Drive connector with PHI, after legal and security review.
[features]
apps = true
[apps."<approved-google-drive-app-id>"]
enabled = true
destructive_enabled = false
default_tools_approval_mode = "prompt"

Estas predefinições configuráveis pelo utilizador bloqueiam as ferramentas de conectores marcadas como destrutivas e solicitam aprovação, salvo se forem substituídas por definições ao nível da aplicação ou específicas da ferramenta. Não são controlos administrativos incontornáveis. Utilize controlos do espaço de trabalho e RBAC para restringir o acesso e requisitos geridos para desativar uma aplicação ou exigir aprovação para ferramentas específicas aprovadas. Quando disponíveis, analise os registos de auditoria do Google Workspace relativos à atividade dos conectores.

Exemplo 2: Utilizar o GitHub localmente

Para desenvolvimento local, muitas equipas utilizam o Git ou o GitHub CLI na estação de trabalho do programador. Isto é diferente do Codex cloud. Se os repositórios, problemas, pull requests ou comentários puderem conter PHI, confirme que a sua organização aprova o ambiente GitHub para esses dados antes de ativar este caminho.

# Example requirements.toml addition for local GitHub use.
# This doesn't enable Codex cloud. It keeps repository actions reviewable.
[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before changing repository history." },
  { pattern = [{ token = "gh" }], decision = "prompt", justification = "Require review before using GitHub CLI." },
]

Esta política não bloqueia a utilização do GitHub. Cria um ponto de revisão antes de o Codex alterar o histórico do repositório ou utilizar comandos do GitHub CLI.

Opcional: Utilizar um servidor MCP do GitHub validado

Se a sua equipa utilizar um servidor MCP do GitHub em vez de apenas comandos Git locais, inclua a identidade exata do servidor aprovado numa lista de permissões e restrinja as ferramentas ao conjunto mínimo aprovado.

# Optional: allow a vetted GitHub MCP server.
# Use the exact approved server identity for your environment.
# requirements.toml
[mcp_servers.github]
identity = { url = "https://github-mcp.example.com/mcp" }
# config.toml
[mcp_servers.github]
url = "https://github-mcp.example.com/mcp"
enabled = true
default_tools_approval_mode = "prompt"
enabled_tools = ["<approved-read-tools>", "<approved-pr-tools>"]

Passos práticos de implementação

  1. Selecione o método de início de sessão aprovado. Decida se os utilizadores irão autenticar-se no Codex Local com o ChatGPT, utilizar API keys ou utilizar ambos em fluxos de trabalho distintos.
  2. Confirme o BAA com a OpenAI. Confirme que o seu BAA abrange os métodos de início de sessão aprovados. Para fluxos de trabalho com API key, confirme que inclui API Services with Modified Retention como Eligible Service e que a OpenAI aprovisionou a organização da API com Modified Retention. Contacte o seu OpenAI Account Director para ativar o suporte HIPAA do Codex num espaço de trabalho ChatGPT.
  3. Ative o Codex Local e defina grupos RBAC. Utilize a configuração de administrador do Codex Enterprise para ativar o Codex Local, criar um pequeno grupo Codex Admin e atribuir acesso ao Codex através de grupos RBAC como Codex Users e Codex PHI Users.
  4. Implemente requirements.toml imposto pelo administrador e as predefinições geridas. Utilize requisitos geridos na nuvem, MDM ou a configuração do sistema para definições suportadas da política inicial. Utilize a configuração do sistema ou MDM para restrições de início de sessão, fixação do espaço de trabalho e fluxos de trabalho com API key. Configure perfis de permissões, políticas de aprovação, modos de pesquisa na Web, restrições de funcionalidades, requisitos de rede, regras de comandos e listas de permissões MCP.
  5. Forme os utilizadores sobre aprovações e limites da sandbox. Utilize Aprovações e segurança dos agentes para explicar quando o Codex pode atuar dentro da sandbox, quando solicita aprovação e por que motivo os utilizadores devem rever as ações de rede, transferência de ficheiros, escrita em repositórios e conectores de terceiros.
  6. Analise os plugins de terceiros antes da utilização de PHI. Antes de ativar plugins com conectores como o Google Drive e o GitHub, destinos de browser ou servidores MCP, confirme que a sua organização aprova qualquer terceiro que receba PHI e tem um BAA adequado com essa entidade.
  7. Acompanhe, reveja e atualize a implementação. Utilize exportações da Compliance API, análises do espaço de trabalho, registos de pontos finais, registos de auditoria de plugins e serviços ligados e registos de auditoria de repositórios para confirmar que a configuração implementada permanece alinhada com as suas políticas internas.

Referências