Resumen

  • El 6 de septiembre, el Consejo de ICANN autorizó al presidente y director ejecutivo, o a sus delegados, a contratar con un proveedor preferente servicios de refuerzo de personal para Engineering & IT. La resolución se publicó el día 9.
  • ICANN menciona desarrollo de software, aseguramiento de calidad, gestión de contenidos y otras competencias técnicas, además de capacidad ajustable y cobertura operativa en más husos horarios.
  • Sus Directrices de Delegación dicen que autoridad y responsabilidad pueden delegarse, pero la rendición de cuentas no. La política contractual también separa la firma delegada de la responsabilidad de aprobación.
  • Falta en la decisión pública un mapa por clases de rol. Un recibo acotado podría identificar responsable interno, función externa, clase de privilegio, límite de aprobación y constancia de salida sin revelar personas ni sistemas sensibles.

El Consejo compró una opción de capacidad, no otra autoridad

Las resoluciones aprobadas el 6 de septiembre de 2026 autorizan al presidente y director ejecutivo de ICANN, o a quienes este designe, a celebrar un contrato con el proveedor preferente y efectuar los desembolsos correspondientes. El objeto publicado es el refuerzo estratégico de personal para Engineering & IT.

La justificación describe una arquitectura laboral flexible. Expertos externos complementan la capacidad interna, permiten aumentar recursos cuando cambian las prioridades, aportan habilidades que quizá no hagan falta de forma permanente y amplían la cobertura entre husos horarios. Entre las áreas nombradas están ingeniería de software, aseguramiento de calidad y gestión de contenidos. El apoyo alcanza iniciativas estratégicas y servicios operativos continuos.

Nada de ello convierte automáticamente ejecución en autoridad. Quien prepara un cambio no tiene por qué aprobarlo. Quien aplica un plan de pruebas puede detener una versión sin fijar política institucional. Quien atiende una incidencia puede actuar bajo un procedimiento sin ser dueño del riesgo aceptado. La elasticidad funciona cuando esas diferencias siguen siendo visibles.

La resolución no demuestra que hoy estén confundidas. Tampoco aporta el mapa que permitiría comprobarlo desde fuera. Hay datos de negociación tachados y no constan públicamente proveedor, precio, plazo, firma, número de personas, ubicación ni estado actual de ejecución. La ausencia de esos datos no autoriza a inventarlos.

La propia ICANN ya definió el principio

Las Delegation of Authority Guidelines, modificadas en octubre de 2024, formulan una regla más importante que cualquier organigrama: la autoridad y la responsabilidad pueden delegarse; la rendición de cuentas, no. El Consejo conserva la rendición de cuentas por los poderes que le asignan los Bylaws. Cuando una materia corresponde al presidente y director ejecutivo, este puede encargar a otras personas que la lideren, pero conserva la responsabilidad.

Las mismas directrices sitúan las operaciones cotidianas bajo el presidente y director ejecutivo, dentro del alcance de las resoluciones del Consejo, y dejan al Consejo la supervisión. Repartir trabajo es normal. Perder el punto de atribución no lo es.

La Contracting and Disbursement Policy, vigente desde enero, convierte la idea en procedimiento. Establece umbrales de aprobación y, con la excepción prevista para presupuestos de proyecto específicamente aprobados, reserva al Consejo las obligaciones superiores a 750.000 dólares. Un directivo puede delegar por escrito la firma de determinados compromisos, con aprobación jurídica y comunicación a los demás directivos. Sin embargo, no delega su facultad de aprobar y sigue siendo responsable.

Esa distinción sirve para el trabajo técnico: firma, ejecución, aprobación y rendición de cuentas pueden recaer en actores distintos, siempre que el vínculo entre ellos no dependa de memoria informal.

La mezcla de plantillas lleva años operando

Las actas del 3 de mayo de 2025 remontan el modelo a 2014. Ese año, tras autorización del Consejo, ICANN contrató a una firma externa para ampliar su capacidad informática. Hubo procesos de solicitud de propuestas en 2014 y 2017, seguidos de renovaciones consecutivas hasta mayo de 2025. La firma entonces vigente prestaba apoyo en desarrollo, calidad y contenidos.

Ese antecedente no identifica al proveedor preferente de 2026 ni prueba que el nuevo acto sea una renovación. Sí muestra que la capacidad externa forma parte de una estrategia duradera y no de una respuesta improvisada.

El Form 990 del ejercicio 2025 aporta escala general, no detalle del nuevo contrato. Informa de 136 contratistas independientes que recibieron más de 100.000 dólares en el periodo aplicable y describe a varios de los proveedores mejor pagados como consultores de TI. También aclara que sus recuentos regionales incluyen empleados directos, personas cedidas por un empleador tercero y contratistas independientes de larga duración.

La declaración afirma que las políticas escritas de conflictos de interés abarcan a contratistas independientes y que se completan declaraciones anuales. La página de prácticas para empleados detalla por separado deberes de confidencialidad y conflictos para el personal. Son indicios afirmativos de control, no una matriz pública de los permisos asociados al contrato de septiembre.

Publicar clases de control sin publicar una superficie de ataque

No hace falta difundir nombres individuales, hosts, credenciales, vulnerabilidades ni procedimientos activos. El nivel adecuado es un recibo de rol y control vinculado a las resoluciones 2026.09.06.03–.04 y, si el contrato se firma, a un identificador estable.

Por cada línea de trabajo podría indicar el directivo responsable dentro de ICANN y el propietario operativo interno. Describiría la clase de función externa, la clasificación del sistema o los datos y el nivel de privilegio. Aclararía qué puede preparar, ejecutar, recomendar o nunca aprobar el rol, además de la separación de tareas, la escalada, las reglas de subcontratación y el estado de compromisos de confidencialidad y conflictos.

La salida completa el control: fechas de revisión y vencimiento, constancia de revocación de accesos, custodia del código y la evidencia operativa, y registro de correcciones. Puede publicarse todo ello sin identificar a la persona detrás de una cuenta ni facilitar datos útiles para un atacante.

Es una propuesta editorial de Daniel Kade, no una obligación de ICANN ni la descripción de un sistema existente. Las fuentes no prueban permisos excesivos, aprobaciones confusas o una baja deficiente. Solo permiten ver que el Consejo explicó la capacidad buscada, pero no proyectó al público la interfaz con la autoridad interna.

Conocer el proveedor no resolvería el límite

La resolución compañera mantiene confidenciales ciertos datos de negociación hasta que el presidente y director ejecutivo decida liberarlos. Conocer después nombre, importe o plazo mejoraría la transparencia contractual. No diría por sí solo quién responde por un cambio ni cómo se clausura un permiso.

Las Governance Guidelines encomiendan al Consejo supervisar a la dirección, el riesgo empresarial y la planificación de tecnología. El índice de documentos de gobernanza reúne el reparto institucional. Falta un conector más pequeño: la proyección pública, agregada y segura de ese reparto sobre una plantilla mixta.

ICANN considera esta autorización una función administrativa que no requiere comentario público. Un recibo de roles no convertiría la operación en plebiscito. Haría comprobable la doctrina ya publicada: la capacidad puede cruzar el contrato; la rendición de cuentas no se va con ella.

Fuentes