Resumen

  • El GAC describió el resultado buscado como la recogida y disponibilidad pública de datos de personas jurídicas y pidió un calendario tras cuatro años sin avances visibles.
  • ICANN respondió que la implementación podría empezar en FY2027, pero recordó que la política permite, sin exigir, la diferenciación y que las buenas prácticas no serán obligaciones contractuales.

La carta de ICANN del 24 de agosto no resuelve la controversia sobre los datos de registro. Sí resuelve algo previo: qué contiene, y qué no contiene, el encargo de la fase 2A que está pendiente de ejecución.

El 11 de mayo, Nicolas Caballero, presidente del Governmental Advisory Committee, escribió a Tripti Sinha, presidenta de la Junta de ICANN. A juicio del GAC, el trabajo destinado a posibilitar la recogida y publicación de datos de registro de entidades jurídicas no había progresado desde que la Junta adoptó las recomendaciones del EPDP fase 2A en marzo de 2022. La carta reiteró la posición gubernamental de que las partes contratadas deberían recoger y hacer públicos los datos de las personas jurídicas. Solicitó un calendario y ofreció participación en un Implementation Review Team.

La contestación anuncia una expectativa condicionada. ICANN org cree que podrá iniciar la implementación en FY2027, una vez concluyan proyectos que utilizan los mismos recursos especializados. La frase habla de comienzo, no de terminación. Tampoco fija una fecha irrevocable.

Junto a ese dato, la Junta separa dos planos. El equipo EPDP no modificó los requisitos existentes de Consensus Policy sobre la diferenciación entre personas jurídicas y físicas. La Registration Data Policy deja que registros y registradores consideren esa condición, o la presencia de datos personales, al decidir si aplican la redacción en RDDS; no les impone hacerlo. Las recomendaciones de buenas prácticas tampoco crearán obligaciones contractuales.

Por eso, “poner en práctica la fase 2A” no equivale necesariamente a materializar el objetivo político formulado por el GAC. El primer enunciado remite a un paquete adoptado. El segundo expresa el resultado normativo que el GAC considera deseable.

Una lectura por verbos, no por titulares

La resolución de la Junta del 10 de marzo de 2022 adoptó cuatro recomendaciones. La primera dice que se debe crear uno o varios campos para facilitar la distinción entre datos de personas jurídicas y físicas, y/o entre datos personales y no personales. Las partes contratadas que diferencien podrán usar esos campos.

La segunda recomienda que quienes decidan diferenciar sigan las orientaciones del informe. La tercera sitúa esas orientaciones ante un posible futuro código de conducta GDPR dentro de ICANN. La cuarta se dirige a quienes decidan publicar una dirección de correo basada en el titular o en el registro y les indica que evalúen el asesoramiento jurídico reunido por el equipo.

El mandato para ICANN org es auténtico. La Junta ordenó al presidente y director ejecutivo, o a sus delegados, elaborar y ejecutar un plan coherente con la guía del GNSO Council. La obligación de crear la capacidad técnica no desaparece porque el uso final sea voluntario.

El límite también es auténtico. La motivación de la Junta afirmó que las recomendaciones no generaban nuevas obligaciones para las partes contratadas. Añadió que las guías y buenas prácticas se situaban fuera del Registry Agreement, del Registrar Accreditation Agreement y de las Consensus Policies; por ello, ICANN Contractual Compliance no tendría autoridad contractual para exigir su cumplimiento.

La nueva carta distribuye las tareas en dos grupos. Las recomendaciones 1, 2 y 4 alimentarán un documento de buenas prácticas. Las recomendaciones 1 y 3 requieren actuaciones de ICANN org. La primera aparece en ambos lados porque combina un componente orientativo con la creación de campos. La coincidencia administrativa no altera el rango de cada componente.

La política vigente decide dato por dato

La Registration Data Policy no trata “publicación” como una consecuencia automática de “recogida”. Define y ordena por separado la recogida, la transferencia, el depósito, la publicación, la redacción, el consentimiento y la divulgación lícita.

Su sección 9.2.1 exige aplicar las reglas de redacción cuando sea necesario para cumplir la ley aplicable y permite aplicarlas por otras causas definidas. Para tomar esa decisión, un registro o registrador puede considerar si los datos corresponden a una persona jurídica o contienen datos personales, y también la ubicación geográfica. El texto dice expresamente que no está obligado a considerar esos factores.

No es contradictorio que una persona jurídica tenga datos personales asociados. Un registro empresarial puede identificar a una empleada, a un abogado externo, a una fundadora o a la persona encargada de la administración del dominio. La etiqueta del titular no clasifica por sí sola cada nombre, teléfono o dirección de correo.

El campo Registrant Organization ofrece un ejemplo más concreto. El registrador debe dar al titular la oportunidad de facilitarlo y recogerlo si se suministra. También debe informar de que la organización será publicada si el titular acepta y que se considerará Registered Name Holder. Con acuerdo, el registrador debe publicar el valor; sin él, puede redactarlo conforme a la política.

La decisión pública, por tanto, requiere una cadena: el dato preciso, su procedencia, la posible presencia de información personal, la regla aplicable, el consentimiento cuando corresponda y la parte responsable. “Persona jurídica” es una pieza de esa cadena, no la conclusión completa.

EPP y RDAP necesitan semántica limitada

La respuesta de agosto prevé coordinación técnica para incorporar campos de diferenciación en EPP y reflejarlos en una versión actualizada del gTLD RDAP Profile. Un formato común puede eliminar ambigüedades útiles: qué valores existen, cómo se expresa el desconocimiento, quién actualiza, cómo se corrige y qué recibe el sistema siguiente.

Sin esa normalización, cada proveedor podría guardar una descripción distinta y los consumidores no sabrían si están viendo una declaración del titular, una conclusión del registrador o una inferencia automática. La interoperabilidad es, por sí misma, una mejora.

Pero la ingeniería no puede completar el mandato que falta. Un campo no dice quién está obligado a rellenarlo. Su valor no prueba la calidad de la clasificación. Que EPP lo transporte no obliga a RDAP a exponerlo. Que el perfil RDAP lo describa no decide si los demás valores del registro pueden publicarse.

El diseño técnico debe conservar la separación entre representar una decisión y estar autorizado para tomarla.

Cinco filas para saber qué se implementa

El plan público debería incluir una concordancia de alcance. No hace falta una nueva institución; basta con un registro preciso de instrumentos.

Una fila identificaría la posición del GAC como consejo y preferencia de política pública. Otra citaría las cuatro recomendaciones, la resolución de la Junta y los entregables asignados a ICANN org. Una tercera señalaría las cláusulas contractuales vigentes sobre publicación y redacción. La cuarta describiría los trabajos EPP y RDAP como representación interoperable. La quinta atribuiría la decisión concreta sobre un registro a la parte que aplica la política y el derecho pertinente.

Cada fila debería mostrar versión, responsable, fuerza, estado y procedimiento de cambio. Así, si se busca una obligación general de diferenciar, el documento señalaría la vía de política capaz de crearla. Si se termina un perfil técnico, no lo presentaría como prueba de que todos los registros usan el campo ni de que el objetivo de publicación del GAC ya se cumplió.

La concordancia no favorece a un bando. Protege a todos frente a una promesa imprecisa. Permite exigir a ICANN que entregue lo aprobado y evita atribuir a registradores una obligación que el instrumento citado no les asigna.

Lo que significa empezar en FY2027

El calendario sigue subordinado a la capacidad. ICANN menciona proyectos existentes, recursos dedicados, planificación operativa y presupuesto. También invita al GAC a intervenir en el ciclo FY2028. No aporta aún un diseño final, una guía publicada, un calendario de entrega ni una tasa de adopción.

La rendición de cuentas puede empezar antes de que exista el campo. Basta con informar qué dependencia se cerró, quién dirige el trabajo, qué recomendación sustenta cada tarea y qué fecha cambió. La transparencia de proyecto, sin embargo, no debe transformarse en una fuente de política sustantiva.

El GAC conserva plena capacidad para defender una regla más amplia. El GNSO conserva la vía para formular recomendaciones de Consensus Policy. La Junta conserva su función de adopción. La comunidad técnica conserva la autoridad sobre una especificación interoperable. Las partes contratadas conservan su responsabilidad sobre datos y ley en casos concretos.

La fase 2A será más creíble si muestra esos límites desde el primer documento. El reto no consiste en hacer que un campo parezca una solución total. Consiste en ejecutar el mandato real y nombrar honestamente la decisión adicional necesaria para ir más allá.

Fuentes

  1. Índice de correspondencia de ICANN
  2. Tripti Sinha a Nicolas Caballero, 24 de agosto de 2026
  3. Nicolas Caballero a Tripti Sinha, 11 de mayo de 2026
  4. Decisión de la Junta sobre el EPDP fase 2A
  5. Informe final del EPDP fase 2A
  6. Recomendaciones de fase 2A para consideración de la Junta
  7. Registration Data Policy de ICANN
  8. Recursos de RDAP de ICANN