Resumen

  • La ICANN incorporó el 3 de septiembre a su registro de correspondencia una carta fechada el 28 de agosto. Los copresidentes del grupo de expertos sobre aceptación universal dicen que entregaron al director ejecutivo un documento final respaldado por consenso.
  • La carta señala que las revisiones tras la consulta incluyeron aprovechar tecnologías de inteligencia artificial para la adopción de UA, además de una propuesta de prioridades y medición del progreso.
  • En las contribuciones públicas, la IA aparece como herramienta de detección, prueba y programación, pero también como categoría de sistemas que deben aceptar correctamente dominios y correos internacionalizados.
  • Cada resultado necesita declarar el lado que ocupa la IA, la versión observada, quién autorizó el cambio, qué recorrido se probó y qué denominador sostiene la cifra. Una actividad no demuestra un desenlace.

La misma IA puede abrir y cerrar la puerta

Imaginemos un asistente que corrige una regla antigua que solo admite caracteres ASCII. El cambio supera la revisión, llega a producción y permite crear una cuenta con una dirección EAI. Esa secuencia contiene varias pruebas: una sugerencia, una decisión humana, un despliegue y un resultado de usuario.

Ahora cambiemos el último componente. Un filtro de correo con aprendizaje automático marca como sospechoso el mensaje de confirmación enviado a esa misma dirección. El formulario ya es compatible, pero el recorrido sigue roto. Decir que “la IA mejoró UA” solo describe la primera intervención y oculta la segunda.

Ese doble papel se vuelve una cuestión institucional tras la nueva entrada de correspondencia de la ICANN. La carta del 28 de agosto, publicada el 3 de septiembre, informa que el Universal Acceptance Expert Working Group revisó los comentarios a su borrador, actualizó el texto y remitió un documento final al presidente y director ejecutivo de la ICANN.

Los copresidentes citan como ejemplo la incorporación de tecnologías de IA para avanzar en la adopción. También describen prioridades de implementación y un marco para medir conocimiento, apoyo normativo, ejecución y creación de capacidades. No afirman que la ICANN ya haya aprobado, financiado o ejecutado todo el paquete. Lo presentaron para su consideración.

El texto verificable todavía tiene un límite

Las páginas públicas consultadas no ofrecen el documento final junto a la carta. La consulta cerrada conserva el borrador de febrero y todavía dice que la ICANN trabajará con el grupo para finalizarlo y publicarlo. El índice temático de UA tampoco lo muestra en la fecha de corte.

Esto no permite concluir que el archivo no exista ni que nadie haya empezado a trabajar. Sí impone una disciplina editorial: la carta demuestra una entrega y resume algunos cambios, pero no deja leer la redacción final. No se puede adjudicar a la versión definitiva una categoría, un número de directriz o una obligación que solo aparece en una contribución.

La diferencia de autoridad también importa. El grupo de expertos puede alcanzar consenso sobre su producto. La ICANN conserva la decisión de evaluar la viabilidad, ordenar prioridades y asignar responsabilidades. Los operadores de aplicaciones, correo, DNS y plataformas mantienen el control sobre sus propios despliegues. El usuario aporta la prueba de si el recorrido funciona. Ninguna capa hereda automáticamente la autoridad de la anterior.

Seis verbos impiden una falsa certificación

El borrador de febrero describe un sistema preparado para UA mediante acciones concretas: aceptar, validar, almacenar, procesar, mostrar e interoperar con todos los nombres de dominio y correos válidos, incluidos IDN y EAI.

Una prueba puede cubrir uno de esos verbos y fallar en el siguiente. Un campo acepta el texto, una API lo normaliza de manera distinta, una base lo guarda y un proceso de recuperación no sabe reutilizarlo. Un servidor recibe el mensaje y un clasificador lo retiene. Un asistente de voz reconoce el nombre, pero el enlace generado no conserva el orden bidireccional.

Por eso el borrador distingue sensibilización, apoyo de políticas, implementación y desarrollo de capacidades. Una campaña pertenece a la primera familia. Una cláusula de contratación está en la segunda. El uso real y el éxito extremo a extremo pertenecen a la tercera. Los cursos y herramientas forman la cuarta. Son señales complementarias, no sumandos equivalentes.

Si una futura pantalla mezcla número de talleres, repositorios analizados, parches sugeridos y recorridos exitosos, una organización puede mejorar su puntuación sin reparar el punto donde el usuario queda fuera. El problema no es que la actividad carezca de valor. Es que está más lejos del resultado.

La consulta dibujó las dos direcciones

El informe que resume 37 aportaciones reúne propuestas para emplear IA en detección automática, pruebas a escala, asistentes de programación y controles integrados en los procesos de desarrollo.

Pero también registra que los sistemas de IA podrían ser una categoría propia de interesados. Entre los ejemplos aparecen modelos de lenguaje, seguridad de correo, filtros de spam, generadores de código, servicios de voz, analizadores de dominios y direcciones, cadenas de datos de entrenamiento y herramientas de diagnóstico. En ese segundo grupo, la IA no es quien examina: es una dependencia que puede alterar el resultado.

La aportación de ISPCP pide indicadores específicos, fases, hitos y una estructura de gobernanza. Sigue siendo una recomendación sometida a consulta. No es política consensuada ni obligación contractual. Su relevancia consiste en hacer visible una arquitectura que un único rótulo borraría.

Un comprobante con dos lados

Daniel Kade propone que cada piloto o afirmación publique una fila mínima. El primer campo debe indicar si la IA actuó como instrumento, diagnóstico, generador de propuesta, componente evaluado, apoyo a una decisión u operador autónomo. Si cumple dos papeles, necesita dos filas vinculadas.

Después hay que nombrar a los responsables. ¿Quién eligió la herramienta y aprobó el corpus? ¿Quién revisó el resultado? ¿Quién podía fusionar el código, ponerlo en producción, detenerlo y revertirlo? La procedencia automática no sustituye esa cadena de autorización.

El objeto técnico necesita identidad suficiente: versión del modelo o servicio cuando sea conocida, especificación de la prueba, salida o parche, revisión del repositorio, compilación y dependencias. Un cambio posterior debe activar una nueva prueba o una explicación de por qué el resultado antiguo sigue siendo comparable.

El comprobante debe fijar la superficie UA: entrada, validación, almacenamiento, procesamiento, visualización, inicio de sesión, recuperación, entrega de correo o interoperabilidad. Debe describir escrituras y lenguas, casos válidos e inválidos, longitudes, texto bidireccional, rutas de proveedor, selección de la muestra y exclusiones.

Por último, la clase de afirmación no puede quedar implícita. Detectar no es corregir. Proponer no es revisar. Integrar no es desplegar. Desplegar no es demostrar conformidad completa. Una prueba de componente no es un recorrido de usuario. Cada estado requiere fecha, numerador, denominador, fallos, falsos positivos, falsos negativos, revisión humana y vía de corrección.

No hace falta publicar secretos de seguridad, pesos del modelo ni datos personales. Hace falta evitar que una cifra viaje de una clase a otra sin pruebas nuevas.

Fuentes

  1. Registro de correspondencia de la ICANN
  2. Carta de los copresidentes del grupo de UA, 28 de agosto de 2026
  3. Consulta pública sobre el borrador de directrices
  4. Borrador de las directrices para la adopción de UA
  5. Informe resumen de la consulta
  6. Aportación de ISPCP
  7. Carta orgánica del grupo de expertos
  8. Índice de anuncios sobre aceptación universal