Resumo

  • O GAC pediu um cronograma depois de descrever o objetivo como coleta e disponibilidade pública de dados de registro de pessoas jurídicas.
  • A ICANN respondeu que a Fase 2A poderá começar em FY2027, mas reiterou que a diferenciação continua facultativa e que as boas práticas não terão força contratual.

A correspondência publicada pela ICANN em 25 de agosto contém uma divergência de escopo antes mesmo de qualquer divergência sobre prazo.

Na carta de 11 de maio de 2026, Nicolas Caballero, presidente do Governmental Advisory Committee, afirmou que o trabalho destinado a viabilizar a coleta e a publicação de dados de registro de entidades jurídicas não havia avançado desde a adoção das recomendações do EPDP Fase 2A, em março de 2022. O GAC reiterou a posição de que as partes contratadas deveriam coletar e tornar públicos os dados de pessoas jurídicas, pediu confirmação do cronograma e se colocou à disposição para integrar um Implementation Review Team.

Tripti Sinha, presidente do Conselho da ICANN, respondeu em 24 de agosto. A organização prevê poder iniciar a implementação em FY2027, desde que sejam concluídos projetos que usam os mesmos recursos dedicados. O texto fala em começar, não em concluir, e mantém a previsão subordinada a capacidade, planejamento operacional e orçamento.

O trecho decisivo vem antes do calendário. Segundo a resposta, a equipe da Fase 2A decidiu não alterar os requisitos existentes de Consensus Policy sobre diferenciação entre dados de pessoas jurídicas e naturais. A Registration Data Policy permite que operadores de registro e registradores considerem a natureza jurídica e a presença de dados pessoais quando decidem aplicar regras de redação no RDDS, mas não os obriga a fazê-lo. As boas práticas previstas tampouco criarão obrigações contratuais.

Assim, “implementar a Fase 2A” e “tornar públicos os dados das pessoas jurídicas” não são expressões equivalentes no registro adotado. A primeira descreve um conjunto delimitado de entregas. A segunda é um resultado de política pública defendido pelo GAC.

O conteúdo normativo está nos verbos

O Conselho da ICANN adotou quatro recomendações em 10 de março de 2022. A primeira determina a criação de um ou mais campos para facilitar a diferenciação entre dados de pessoas jurídicas e naturais e/ou entre dados pessoais e não pessoais. As partes contratadas que optarem por diferenciar poderão usar os campos.

A segunda recomenda que quem fizer a diferenciação siga a orientação do relatório. A terceira trata da consideração dessa orientação caso controladores e processadores pertinentes desenvolvam um GDPR Code of Conduct dentro da ICANN. A quarta recomenda que quem optar por publicar um endereço de e-mail baseado no registrante ou no registro avalie a orientação jurídica obtida pela equipe do EPDP.

Há um mandato real para a ICANN org. O Conselho determinou que o President and CEO, ou seus designados, desenvolvesse e executasse um plano de implementação coerente com a orientação do GNSO Council. O caráter facultativo do uso não torna facultativa a responsabilidade institucional de produzir o mecanismo aprovado.

Também há um limite real. A justificativa de 2022 registrou que as recomendações não criavam novas obrigações para as partes contratadas. Explicou ainda que orientações e boas práticas fora do Registry Agreement, do Registrar Accreditation Agreement e das Consensus Policies não são requisitos contratuais. Por isso, ICANN Contractual Compliance não teria autoridade contratual para exigir sua adoção.

A resposta de agosto agrupa as recomendações 1, 2 e 4 no documento de boas práticas e as recomendações 1 e 3 no trabalho dirigido à ICANN org. A recomendação 1 participa dos dois conjuntos porque combina orientação com coordenação técnica. A sobreposição de tarefas não apaga a diferença de força.

A política vigente exige mais do que um rótulo

A Registration Data Policy trata coleta, transferência, escrow, publicação, redação, consentimento e divulgação lícita como operações distintas. O mesmo dado pode passar por várias delas, mas cada decisão precisa de fundamento próprio.

Na seção 9.2.1, operadores de registro e registradores devem aplicar as regras de redação quando isso for necessário para cumprir a lei aplicável. Eles também podem aplicá-las em outras situações especificadas. Ao decidir, podem considerar se os dados dizem respeito a uma pessoa jurídica, se contêm dados pessoais e qual é a localização relevante. A política não exige que façam essa diferenciação.

Uma pessoa jurídica pode ter dados pessoais em seu registro. O domínio de uma empresa pode listar uma funcionária, um diretor, uma assessora externa ou alguém responsável pela administração. Classificar o titular como organização não transforma automaticamente todos os nomes, telefones e e-mails associados em dados não pessoais.

O campo Registrant Organization mostra a lógica atual. O registrador deve oferecer ao Registered Name Holder a possibilidade de informar o valor e deve coletá-lo se fornecido. Também deve avisar que a organização será publicada se o titular concordar e que ela será considerada o Registered Name Holder. Com concordância, o valor deve ser publicado; sem ela, poderá ser redigido conforme a política.

Portanto, uma decisão de publicação precisa registrar o campo concreto, sua origem, a possível presença de dados pessoais, a cláusula aplicável, o papel do consentimento e o ator responsável. A categoria “pessoa jurídica” é uma entrada dessa análise, não sua saída automática.

O padrão transporta significado, não poder

A carta prevê coordenação com a comunidade técnica para revisar campos de diferenciação no Extensible Provisioning Protocol e chegar a um gTLD RDAP Profile atualizado.

Uma representação comum é útil. Sem ela, um fornecedor pode usar texto livre, outro um valor binário pouco explicado e um terceiro uma inferência sem caminho de correção. O padrão pode definir valores, estado desconhecido, ausência de diferenciação, atualização e compatibilidade. Pode fazer com que EPP e RDAP mantenham a mesma semântica.

Mas a sintaxe não decide quem deve preencher o campo. O valor não prova como a classificação foi feita. Seu transporte em EPP não obriga a exposição em RDAP. A existência no perfil não substitui a Registration Data Policy, a lei aplicável nem a responsabilidade de quem processa o registro.

O campo pode tornar interoperável uma decisão autorizada. Não pode criar por conta própria a autorização de publicar.

Um quadro público de escopo

Antes de medir a entrega, a ICANN deveria publicar uma concordância simples entre cinco camadas.

A primeira identificaria a posição do GAC como aconselhamento e preferência de política pública. A segunda mostraria as recomendações adotadas e a direção dada à ICANN org. A terceira apontaria os instrumentos contratuais que controlam coleta, redação, consentimento, publicação e divulgação. A quarta descreveria a especificação EPP/RDAP como representação técnica. A quinta atribuiria a decisão sobre um registro real à parte que aplica política e lei.

Cada linha deveria trazer versão, responsável, força, estado e caminho formal de mudança. Se o objetivo for tornar a diferenciação obrigatória, o quadro deve indicar qual processo pode alterar a política. Se o RDAP Profile for concluído, deve dizer que isso não comprova adoção geral nem cumprimento do objetivo mais amplo do GAC.

Esse documento não precisa escolher um vencedor no debate entre transparência e privacidade. Sua função é tornar auditável a pergunta anterior: o que está sendo construído, sob qual autoridade e com qual efeito.

FY2027 é o próximo ponto de observação

A carta convida o GAC a continuar participando do ciclo de planejamento FY2028 e promete atualizações. Ainda não há, nas fontes fechadas deste artigo, um desenho final de campo, texto de boas práticas, data de conclusão ou evidência de adoção por registradores e registros.

É possível cobrar progresso sem confundir papéis. A ICANN pode mostrar quais dependências terminaram, quem é responsável e como cada entrega se liga a uma recomendação. O GAC pode defender uma mudança adicional. O GNSO pode deliberar pela via competente. A comunidade técnica pode definir uma semântica limpa. As partes contratadas podem aplicar a política e a lei a casos concretos.

Participação consultiva não é emenda contratual. Direção do Conselho à ICANN org não é ordem nova a todo registrador. Campo não é permissão de divulgação. Atualização de projeto não é política.

A resposta de 24 de agosto tornou essas distinções públicas. A prova de governança começará quando documentos, esquemas e expectativas operacionais se aproximarem: a fronteira continuará legível ou será apagada pela implementação?

Fontes

  1. Índice de correspondência da ICANN
  2. Tripti Sinha a Nicolas Caballero, 24 de agosto de 2026
  3. Nicolas Caballero a Tripti Sinha, 11 de maio de 2026
  4. Decisão do Conselho sobre a Fase 2A, 10 de março de 2022
  5. Relatório final do EPDP Fase 2A
  6. Recomendações da Fase 2A para consideração do Conselho
  7. Registration Data Policy da ICANN
  8. Recursos de RDAP da ICANN