--- id: "disclosure-request" kind: "glossary-term" title: "solicitação de divulgação" language: "pt-BR" category: "Dados de registro e privacidade" updated: "2026-10-10T23:12:43Z" canonical: "https://tldlog.com/pt/glossario/solicitacao-divulgacao/" translations: en: "https://tldlog.com/glossary/disclosure-request/" es: "https://tldlog.com/es/glosario/solicitud-divulgacion/" de: "https://tldlog.com/de/glossar/offenlegungsantrag/" fr: "https://tldlog.com/fr/glossaire/demande-divulgation/" it: "https://tldlog.com/it/glossario/richiesta-divulgazione/" ru: "https://tldlog.com/ru/glossariy/zapros-raskrytie-dannykh/" zh-Hans: "https://tldlog.com/zh/cihui/pilu-qingqiu/" --- # solicitação de divulgação Um pedido a um registrador ou registro de dados de registro que não estão visíveis ao público, como o nome ou o e-mail do titular. O solicitante, por exemplo a polícia ou um advogado de marcas, explica por que precisa deles. O registrador ou o registro decide se os divulga. Uma solicitação de divulgação é a forma de solicitar os dados do titular de um domínio que estão ocultos ao público, como um nome ou um endereço de e-mail. O pedido vai para a empresa que vende ou opera o domínio e deve explicar quem está pedindo e por quê. É essa empresa, não a ICANN, que decide se entrega os dados. ## O que é uma solicitação de divulgação Desde 2018, com a Especificação Temporária para dados de registro de gTLDs (Temporary Specification for gTLD Registration Data), boa parte dos dados pessoais nos registros de gTLDs fica oculta (acesso em níveis). Hoje o tema é regido pela Política de Dados de Registro (Registration Data Policy), em vigor desde 21 de agosto de 2025 e revisada em 12 de maio de 2026: registradores e registros devem ocultar os dados pessoais quando a lei exige e podem fazê-lo em alguns outros casos. O nome formal que a ICANN usa é “Reasonable Requests for Lawful Disclosure” (pedidos razoáveis de divulgação lícita). O pedido vai para o registrador ou para o registro, e quem o recebe decide. A ICANN não toma a decisão nem a reexamina. ## Quem pode pedir e com qual fundamento Qualquer pessoa pode pedir. Em outubro de 2026, um pedido deve conter pelo menos: - a identidade, os dados de contato e o tipo do solicitante (empresa ou pessoa física), com prova de poderes quando age em nome de outra pessoa; - os dados desejados; - os direitos legais do solicitante e o motivo específico do pedido; - uma declaração de boa-fé e o compromisso de tratar os dados de forma lícita. O registrador ou o registro deve analisar cada pedido apresentado corretamente com base no seu mérito. Quando a lei exige, pondera o interesse legítimo do solicitante em relação aos direitos do titular, e pode considerar outros fatores, como a jurisdição. Durante o piloto do RDRS, titulares de propriedade intelectual enviaram 1.202 dos 3.721 pedidos, e as autoridades policiais 605. Em outubro de 2026, na União Europeia (UE), o artigo 28(5) da diretiva NIS2 exige que os Estados-Membros obriguem os registros e os registradores de TLDs a fornecer dados de registro específicos a quem legitimamente solicita acesso, mediante um pedido lícito e devidamente justificado, de acordo com a legislação de proteção de dados da UE, e a responder em até 72 horas. ## Como enviar um pedido, passo a passo Para um nome de gTLD, em outubro de 2026: 1. Consultar os dados públicos no ICANN Lookup, para confirmar que os dados estão ocultos e descobrir o registrador. 2. Seguir o processo do registrador. Todo registrador e todo registro deve ter, na sua página inicial, um link para uma página que informe o formato do pedido, como as respostas são enviadas e o prazo previsto. 3. Ou usar o RDRS, que é gratuito e exige uma conta na ICANN. O solicitante escolhe uma categoria, descreve o que deseja, pode anexar até cinco arquivos PDF de até 5 MB cada e confirma que cumprirá a legislação de proteção de dados. 4. Se o registrador não participar, o RDRS permite salvar o formulário como PDF para enviá-lo diretamente. Em todos os casos, qualquer divulgação acontece fora do RDRS, pelo meio que o registrador escolher. Em outubro de 2026, o RDRS é voluntário para os registradores. No fim do piloto, em novembro de 2025, os registradores participantes cobriam 46% dos domínios sob gestão. A Diretoria da ICANN o prorrogou por até dois anos: até dezembro ou novembro de 2027, conforme o documento da ICANN. O RDRS não cobre os ccTLDs e não é uma forma de apresentar uma reclamação pela UDRP. Os ccTLDs aplicam as próprias regras e a própria legislação, por isso o solicitante deve contatar o registro; o EURid, por exemplo, oferece um formulário para dados do .eu. O registro do .es não está sujeito à política da ICANN nem ao RDRS, então, para um nome .es, consulte a Red.es ou um advogado. ## Prazos de resposta e solicitações urgentes Em outubro de 2026, um registrador ou registro deve confirmar o recebimento de um pedido no formato correto em até 2 dias úteis e responder em até 30 dias corridos após a confirmação, salvo circunstâncias excepcionais. Durante o piloto do RDRS, as aprovações levaram em média 7 dias e as recusas 17. A opção “Expedited” do RDRS não obriga o registrador a se apressar: no piloto, 169 dos 220 pedidos desse tipo foram passados para o regime normal, e, em uma emergência, a ICANN orienta os solicitantes a não contar com ela e a contatar o registrador diretamente. As solicitações urgentes foram acrescentadas à política em 12 de maio de 2026. Elas só podem vir de uma autoridade policial ou de outra autoridade de confiança autenticada, diante de uma ameaça iminente à vida, de lesão corporal grave, à infraestrutura crítica ou de exploração infantil. A resposta seria devida em até 24 horas, prorrogáveis com justificativa até no máximo 72 horas a partir do recebimento. Em outubro de 2026, essa regra não está em vigor: ela só se aplica quando a ICANN implementar uma política de autenticação dos solicitantes. A ICANN está preparando um teste com autoridades policiais, incluindo a INTERPOL e o Federal Bureau of Investigation (FBI) dos Estados Unidos. Em outubro de 2026, o RAA exige que todo registrador de gTLDs mantenha um contato de abuso monitorado 24 horas por dia para as autoridades da sua própria jurisdição e que analise as denúncias fundamentadas delas em até 24 horas: trata-se de denúncias, não de divulgação. ## O que acontece quando um pedido é recusado Uma recusa deve apresentar motivos específicos e, quando essa ponderação se aplica, explicar como os direitos do titular foram pesados em relação ao interesse do solicitante. As recusas são frequentes. Desde o lançamento até 30 de junho de 2026, o RDRS registrou 4.275 pedidos: 1.072 aprovados e 2.540 negados. Os motivos mais comuns no piloto foram que a lei impedia a divulgação e que o pedido estava incompleto. O solicitante pode então enviar um novo pedido com mais informações, ou reclamar à Conformidade Contratual da ICANN (Contractual Compliance) se o registrador não respondeu ou não seguiu as regras; a ICANN não reconsiderará a decisão em si. Em 12 de março de 2026, a Diretoria da ICANN decidiu não adotar as 18 recomendações do SSAD e instou o Conselho da GNSO a concluir um novo trabalho dentro da prorrogação do RDRS, que termina em novembro de 2027. A participação obrigatória dos registradores, os níveis de serviço de resposta e a autenticação das autoridades policiais estão em discussão; em outubro de 2026, nada disso está decidido. ## Fontes - [Registration Data Policy](https://www.icann.org/en/contracted-parties/consensus-policies/registration-data-policy) - [Frequently Asked Questions for the Registration Data Request Service (RDRS) for Requestors](https://www.icann.org/en/system/files/files/rdrs-requestors-faqs-25apr24-en.pdf) - [RDRS Two-Year Pilot Summary Report](https://www.icann.org/en/system/files/files/rdrs-two-year-pilot-summary-report-27feb26-en.pdf) - [Approved Resolutions | Regular Meeting of the ICANN Board | 12 March 2026](https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-12-03-2026-en) ## termos relacionados - [ocultação de dados](https://tldlog.com/pt/glossario/ocultacao-dados/) - [RDRS](https://tldlog.com/pt/glossario/rdrs/) - [Política de Dados de Registro](https://tldlog.com/pt/glossario/politica-dados-registro/)