Resumo

  • A Política de Dados de Registro publicada em 12 de maio de 2026 prevê, para um pedido urgente autenticado, confirmação de recebimento em duas horas e resposta em 24, com extensão justificada até 72 horas apenas em circunstâncias excepcionais.
  • A resposta pode entregar os dados não públicos solicitados ou negar o pedido, integral ou parcialmente, com motivos. O relógio não substitui a análise de mérito, não afasta a lei aplicável e não vincula as partes antes de o mecanismo de autenticação entrar em vigor.

Imagine que um pedido corretamente formulado chegue às 14h. Até as 16h, o registrador ou operador de registro que o recebeu precisa confirmar o recebimento. Às 14h do dia seguinte, o solicitante normalmente já deve ter uma resposta. Se circunstâncias realmente excepcionais exigirem mais tempo, o destinatário terá de avisar dentro das mesmas 24 horas, explicar a razão e informar quando responderá. O limite final é de 72 horas contadas do recebimento.

A sequência parece uma ordem de divulgação emergencial. Não é. Cada horário controla uma etapa do processo, e o resultado ainda pode ser a entrega dos dados ou uma recusa fundamentada.

Primeiro vem uma porta estreita. A seção 3.8 da Política da ICANN define Pedido Urgente como um subconjunto dos pedidos de divulgação lícita. Ele precisa ser apresentado por um Solicitante Autenticado e tratar de ameaça iminente à vida, lesão corporal grave, infraestrutura crítica ou exploração infantil. A divulgação deve ser necessária para combater ou enfrentar a ameaça. Escrever “urgente” no assunto da mensagem não abre esse canal.

Autenticação também não é mera identificação declarada. A seção 3.9 limita a categoria a um solicitante de autoridade policial ou a uma autoridade confiável ou competente autenticada por mecanismo implementado segundo uma Política de Consenso da ICANN. A emenda separa dois controles frequentemente confundidos: verificar quem pede e decidir se este pedido específico é necessário e lícito.

As regras gerais de divulgação permanecem. O pedido deve identificar o solicitante, listar os elementos de dados pretendidos, expor os direitos jurídicos e a justificativa específica, afirmar boa-fé e aceitar o tratamento lícito do que vier a receber. O registrador ou operador de registro precisa examinar cada pedido corretamente formulado pelos próprios méritos.

O relógio altera quanto tempo essa análise pode ficar sem solução. Para um pedido comum, a seção 10.5 permite até dois dias úteis para confirmar o recebimento e, salvo circunstâncias excepcionais, até 30 dias corridos depois disso para responder. Para um pedido urgente elegível, a seção 10.7 substitui esse ritmo: confirmação em duas horas e resposta sem demora indevida, no máximo em 24 horas.

A extensão é deliberadamente estreita. A política cita força maior que afete a infraestrutura e complexidade, como um pedido envolvendo grande quantidade de nomes de domínio. Feriados, licença planejada e viagem agendada estão expressamente excluídos. Uma escolha de escala de trabalho não pode transformar um padrão emergencial contínuo em fila de horário comercial.

Mesmo assim, “resposta” não é sinônimo de “entrega”. A seção 10.6 preserva dois resultados compatíveis. O operador pode fornecer os dados. Também pode negar tudo ou parte, identificar os motivos específicos e explicar como chegou à decisão. Quando aplicável, a explicação deve mostrar como ponderou os direitos e liberdades fundamentais do titular dos dados diante do interesse legítimo do solicitante.

Essa fronteira importa porque as informações são dados de registro não públicos. Um processo rápido reduz o custo do atraso em uma emergência real. Ele não cria a mesma base legal em todas as jurisdições, não prova que cada campo solicitado é necessário, não restaura um WHOIS público e não transforma a ICANN na autoridade que decide uma investigação policial. A decisão substantiva continua com o registrador ou operador de registro que recebeu o pedido.

Ainda há um interruptor essencial aberto. A Nota de Implementação 11 diz que as obrigações da seção 10.7 só entram em vigor quando a ICANN implementar integralmente uma Política de Consenso que estabeleça a autenticação dos solicitantes. O anúncio de 12 de maio repete essa condição. O registro do estado dos pareceres do GAC, atualizado em 23 de julho, também informa que a execução do prazo de 24 horas depende desse mecanismo.

Portanto, a emenda é política publicada com gatilho operacional adiado. Sem autenticação confiável, a via rápida pode favorecer impostores ou gastar as primeiras horas provando quem pede. Sem prazo de resposta, autenticação apenas criaria uma fila confiável sem velocidade de emergência. O histórico da consulta pública registra a solução em duas frentes: desenvolver a autenticação separadamente e fixar o tempo de resposta supondo que o solicitante já tenha sido autenticado.

Quando o gatilho for acionado, a prestação de contas deve aparecer em registros. A seção 11.2 exige que registradores e operadores de registro guardem pedidos, confirmações e respostas segundo as práticas normais, inclusive para eventual auditoria da ICANN. Os registros podem provar o cumprimento das duas, 24 e 72 horas. Sozinhos não provam que a divulgação ou a recusa foi juridicamente correta, mas tornam o silêncio mensurável.

O novo relógio é mais forte quando descrito com exatidão: ele autoriza velocidade, estrutura e uma decisão auditável, não divulgação automática.

Fontes