Resumo

  • Em 3 de setembro, a ICANN publicou uma carta de 28 de agosto na qual os copresidentes do grupo de especialistas em aceitação universal informam ter enviado ao CEO um documento final apoiado por consenso.
  • A carta diz que a revisão posterior à consulta incluiu o aproveitamento de tecnologias de inteligência artificial para avançar UA, além de prioridades de implementação e um quadro de acompanhamento.
  • As contribuições públicas tratam a IA em duas posições: ferramenta para localizar ou corrigir falhas e categoria de sistemas — assistentes de código, filtros, analisadores e serviços de voz — que também precisa demonstrar seu próprio comportamento.
  • Um registro de duas faces deve ligar cada alegação ao papel, à versão, à cadeia humana de autorização, à função de UA, ao conjunto de testes e ao denominador. Produção automática não é resultado operacional.

O verbo “usar” esconde duas operações

O registro de correspondência da ICANN passou a mostrar, em 3 de setembro, a entrega feita pelo Universal Acceptance Expert Working Group. Na carta datada de 28 de agosto, Edmon Chung e Sarmad Hussain relatam que o grupo analisou as manifestações recebidas sobre a minuta, atualizou as diretrizes e encaminhou ao presidente e CEO da ICANN um documento final apoiado pelo consenso de seus integrantes.

Os copresidentes destacam uma alteração: aproveitar tecnologias de IA para promover a adoção de UA. Também dizem que o pacote sugere uma ordem de implementação e mede avanços em conscientização, apoio de políticas, implementação e desenvolvimento de capacidades.

“Usar IA”, porém, pode significar pedir a uma ferramenta que encontre validações ultrapassadas, produza casos de teste ou proponha uma correção. Nesse arranjo, a IA ajuda o responsável. O objeto probatório é sua saída, a revisão humana e a decisão autorizada de aceitar, descartar ou alterar a proposta.

Também pode significar que uma aplicação alimentada por IA recebe, transforma ou classifica o identificador do usuário. Geradores de código, filtros de spam, segurança de e-mail, interfaces de voz e fluxos de identidade podem determinar se um domínio internacionalizado ou uma caixa postal EAI funciona. Aqui, a IA não é a examinadora. Ela pertence ao que está sendo examinado.

Somar essas funções cria uma contabilidade sem unidade. Quantidade de repositórios varridos mede esforço. Percentual de trajetórias completas que chegam ao fim mede uma condição operacional. A primeira informação pode explicar uma mudança na segunda, mas não pode substituí-la.

Consenso do grupo não é adoção pela ICANN

A carta é precisa ao dizer que o texto foi enviado para consideração da ICANN. O grupo pode concluir sua tarefa e formar consenso sobre o próprio produto. Ainda cabem à organização a análise de viabilidade, a seleção de prioridades, a alocação de recursos e o relato da execução. Empresas e órgãos públicos continuam controlando os sistemas que operam.

Há também um limite documental. Nas superfícies consultadas, a correspondência aponta para a carta, não para as diretrizes finais. A página da consulta encerrada ainda oferece o texto de fevereiro e informa que a ICANN trabalhará com o grupo para finalizar e publicar. O índice de notícias de UA não exibia o arquivo final no corte da apuração.

Isso não prova inexistência nem inatividade. Delimita o que é possível afirmar. A inclusão de IA pode ser atribuída à descrição dos copresidentes; a formulação, o número e a prioridade exatos da cláusula final não podem ser reconstruídos. Os papéis mais detalhados vêm do histórico da consulta e devem continuar identificados como propostas recebidas.

A prontidão passa por uma sequência de funções

A minuta de fevereiro define prontidão de UA como capacidade de aceitar, validar, armazenar, processar, exibir e interoperar com todos os nomes de domínio e endereços de e-mail válidos, incluindo IDNs e EAI, conforme os padrões aplicáveis.

Um campo pode aceitar a entrada, enquanto a API a altera. O banco pode gravá-la, enquanto a autenticação não a recupera. O cadastro pode terminar e a recuperação de conta falhar. Um servidor pode receber a mensagem e a camada de segurança classificá-la incorretamente. O resultado de um componente só descreve aquele componente, naquela versão e naquele ensaio.

O próprio quadro separa conscientização, políticas, implementação e capacidade. Evento, norma de contratação, correção de software e jornada do usuário ocupam distâncias causais diferentes. Todos merecem dados. Não merecem ser somados como se fossem resultados equivalentes.

A consulta colocou a IA diante do espelho

O relatório que sintetiza 37 manifestações registra sugestões para usar IA no desenvolvimento, na detecção automatizada, em testes em escala e em verificações incorporadas ao fluxo de software. É o lado instrumental.

O mesmo documento registra a proposta de considerar sistemas de IA uma categoria própria de partes interessadas. Cita grandes modelos de linguagem, segurança de e-mail baseada em IA, geradores de código, ferramentas que analisam domínios e endereços, filtros de spam, assistentes de voz, cadeias de dados de treinamento e diagnósticos. É o lado submetido ao teste.

A manifestação da ISPCP pede indicadores específicos para IA, fases, metas e uma estrutura de governança. Continua sendo contribuição, não política aprovada nem dever contratual. Sua utilidade é mostrar que uma só categoria apagaria a direção da prova.

Uma linha para cada papel e estado

Daniel Kade propõe um quadro público compacto. A primeira coluna classifica a IA como instrumento de diagnóstico, geradora de proposta, apoio à decisão, componente testado ou operadora automatizada. Se o mesmo serviço ocupa dois papéis, recebe duas linhas relacionadas.

A segunda coluna registra autoridade: quem escolheu a ferramenta e o corpus, revisou a saída, aprovou a mudança, implantou, pode desligar e reverter. Um patch não se autoriza. O fornecedor do modelo não herda o controle do sistema onde a saída será usada.

O artefato precisa de estado: versão do modelo ou serviço quando disponível, especificação do teste, saída ou patch, revisão do repositório, build, dependências e horário. Uma atualização pode exigir novo ensaio ou uma decisão explícita de comparabilidade.

O escopo identifica a função: entrada, validação, armazenamento, processamento, exibição, autenticação, recuperação, entrega de mensagem ou interoperabilidade. O corpus registra escritas, línguas, casos válidos e inválidos, comprimento, bidi, caminhos de provedores, amostragem e exclusões.

Por fim, o resultado recebe uma classe: alerta, correção proposta, código revisto, implantação autorizada, observação de conformidade ou desfecho completo do usuário. Cada classe traz numerador, denominador, falhas, falsos positivos e negativos, correção e data de novo teste.

Segredos técnicos e dados pessoais podem permanecer protegidos. O que não pode permanecer oculto é a troca de sentido entre produzir uma sugestão e provar acesso real.

Fontes

  1. Correspondência da ICANN
  2. Carta dos copresidentes do UA EWG, 28 de agosto de 2026
  3. Consulta pública sobre a minuta
  4. Minuta das diretrizes para adoção de UA
  5. Relatório de síntese da consulta
  6. Manifestação da ISPCP
  7. Carta constitutiva do UA EWG
  8. Índice de anúncios de UA da ICANN