La conversación sobre la infraestructura de IA está dominada por la computación.
GPU.
Energía.
Refrigeración.
Centros de datos.
Memoria.
Almacenamiento.
Interconexión.
Todo ello importa.
Pero hay otra capa de infraestructura que recibe mucha menos atención:
Los recursos numéricos de Internet.
Una empresa de IA puede poseer GPU, asegurar contratos de energía, desplegar fibra de alta capacidad y construir una infraestructura sofisticada para servir modelos.
Pero si los clientes no pueden acceder a esa infraestructura de forma fiable, toda esa capacidad de cómputo pierde su valor.
Los sistemas de IA orientados al público siguen dependiendo de la infraestructura de Internet.
Las API de modelos necesitan puntos de acceso.
Las nubes de GPU necesitan conectividad para sus clientes.
Los centros de datos necesitan redes enrutadas.
Las plataformas empresariales de IA necesitan integraciones estables.
Los sistemas de seguridad pueden depender de identidades de red conocidas.
Los servicios multirregionales pueden requerir un enrutamiento independiente.
Detrás de estos sistemas se encuentran direcciones IPv4 e IPv6, números de sistema autónomo, políticas de enrutamiento, registros administrativos y declaraciones de seguridad.
Por tanto, las empresas de IA no deberían considerar las direcciones IP como un asunto secundario.
Forman parte de la pila de infraestructura.
Y cuando un recurso numérico se integra en las operaciones, la gobernanza de direcciones IP se convierte en una cuestión de continuidad del negocio.
La infraestructura de IA también es infraestructura de Internet
Una empresa de IA puede verse principalmente como una compañía de software o de computación.
Sin embargo, desde el punto de vista operativo, muchas empresas de IA se parecen cada vez más a compañías de infraestructura.
Pensemos en una plataforma de IA que opera:
- API públicas de modelos
- Servicios de nube de GPU
- Infraestructura empresarial de inferencia
- Clústeres de entrenamiento
- Paneles orientados al cliente
- Redes privadas
- Centros de datos multirregionales
- Puertas de enlace en la nube
- Integraciones con socios
Cada uno de estos sistemas acaba interactuando con identificadores de red.
En un nivel básico, las direcciones IP públicas indican a Internet dónde se puede acceder a los servicios.
En un nivel más profundo, esas direcciones pueden vincularse a:
- DNS
- Listas de permitidos de clientes
- Firewalls
- VPN
- Seguridad de API
- Enrutamiento
- Geolocalización
- Sistemas de gestión de abusos
- Monitorización
- Bases de datos de reputación
Una dirección IP puede comenzar como capacidad.
Con el tiempo, puede convertirse en identidad.
Esa distinción es sumamente importante para las empresas de IA que amplían su infraestructura con rapidez.
Lo primero que deben entender las empresas de IA: las direcciones IP son recursos coordinados
Los recursos numéricos públicos de Internet no existen como números independientes elegidos por cada empresa.
Forman parte de un marco mundial de coordinación.
La Autoridad de Números Asignados de Internet (IANA) mantiene los registros mundiales de IPv4, IPv6 y números de sistema autónomo, mientras que los recursos numéricos se administran mediante el sistema de registros regionales de Internet.
Esta arquitectura existe por una razón técnica importante:
Los identificadores de Internet deben seguir siendo únicos en todo el mundo.
RFC 7020 describe el sistema de registro de números de Internet utilizado para el espacio de direcciones IP y los números AS únicos a escala mundial.
Para las empresas de IA, la necesidad de unicidad no es controvertida.
Dos redes de producción sin relación entre sí no pueden basarse en derechos exclusivos incompatibles sobre el mismo prefijo enrutado mundialmente.
La cuestión de gobernanza más importante comienza una vez establecida la unicidad:
¿Cuánta autoridad debería tener la capa de coordinación sobre la vida comercial y operativa de un recurso numérico que ya está en funcionamiento?
Ahí es donde el problema se vuelve más complejo.
Un registro no es lo mismo que una red en funcionamiento
Una de las distinciones más importantes que debe comprender un equipo de infraestructura de IA es la separación entre:
La información del registro
y
la realidad operativa de Internet.
Un registro puede conservar información sobre un bloque IPv4.
Pero una entrada de base de datos no mueve paquetes por sí sola.
BGP intercambia información de enrutamiento entre redes.
Los routers aplican políticas.
Los proveedores ascendentes propagan anuncios.
RPKI puede aportar información de seguridad sobre qué ASN está autorizado a originar un prefijo.
Después, las aplicaciones y los clientes dependen de la conectividad resultante.
Por eso he sostenido que:
Un registro describe la realidad; no la crea.
El registro debería ayudar a mantener el libro de datos preciso.
Debería preservar la unicidad.
Debería registrar los cambios legítimos.
Debería facilitar la seguridad y la coordinación operativa.
Pero la existencia de una base de datos no debe confundirse con la propiedad de la realidad económica y operativa construida alrededor de los recursos que contiene.
Esta distinción se desarrolla con más detalle en La Declaración de Derechos de la Coordinación de la Unicidad, donde sostengo que la capa común de recursos numéricos debería centrarse en la unicidad, la exactitud de los registros, la prueba de control, las declaraciones de seguridad, la capacidad de auditoría y la continuidad operativa.
Para las empresas de IA que construyen infraestructuras costosas alrededor de recursos IP, esta distinción no es filosófica.
Es gestión de riesgos.
La escasez de IPv4 cambia la cuestión de gobernanza
IPv4 es diferente de un recurso de software ordinario.
Una empresa puede crear otra base de datos.
Puede aprovisionar máquinas virtuales adicionales.
Puede fabricar o comprar más hardware si el suministro lo permite.
No puede fabricar otra Internet IPv4 única a escala mundial.
IPv4 es finito.
Cuando la escasez adquiere relevancia económica, los recursos numéricos dejan de parecer simples elementos administrativos.
Se convierten en activos operativos.
Esto es especialmente relevante para la infraestructura de IA.
Supongamos que una empresa de nube de IA necesita miles de direcciones IPv4 públicas para:
- Cargas de trabajo de clientes
- Puertas de enlace públicas
- API
- Infraestructura de gestión
- Puntos de acceso dedicados
- Dispositivos de seguridad
- Servicios regionales
Su estrategia de IPv4 puede incluir:
- Asignaciones existentes
- Recursos comprados
- Transferencias
- Arrendamiento
- Direcciones asignadas por proveedores
- Acuerdos de uso de IP propias
Estas estructuras crean dependencias diferentes.
Por tanto, la pregunta no es simplemente:
«¿Cuántas direcciones IP necesitamos?»
La pregunta más adecuada es:
«¿Bajo qué estructura de gobernanza seguirán siendo utilizables esas direcciones?»
Las empresas de IA deberían separar la capacidad de la identidad
Esta puede ser la distinción más importante de la infraestructura.
No todas las direcciones IP tienen el mismo valor para una empresa.
Algunas direcciones son prescindibles.
Una carga temporal de desarrollo puede pasar de una dirección a otra sin grandes consecuencias.
Otras direcciones se integran profundamente con el paso del tiempo.
Imaginemos un proveedor de API de IA.
Sus clientes empresariales incluyen direcciones de origen específicas en sus listas de permitidos.
Los bancos y clientes regulados configuran controles de seguridad en torno a ellas.
Los socios las documentan.
Los sistemas de monitorización acumulan años de historial en torno a ellas.
Los firewalls dependen de ellas.
Los sistemas internos de cumplimiento las referencian.
En ese momento, la dirección deja de ser mera capacidad.
Se ha convertido en parte de la identidad de redde la empresa.
Desarrollé esta distinción en Sobre LARUS One — La economía de la identidad de red, la continuidad del cliente y los ingresos del proveedor. La idea central es sencilla: el coste real de una dirección importante no suele ser el precio del número, sino el coste de cambiarlo.
Las empresas de IA deberían identificar pronto qué direcciones son solo capacidad y cuáles se están convirtiendo en identidad.
No deberían gobernar ambas categorías de la misma manera.
Haga la pregunta correcta: ¿cuánto costaría renumerar?
Los equipos de infraestructura preguntan con frecuencia:
¿Cuánto cuesta IPv4?
Esa es una cuestión de adquisición.
Para una infraestructura crítica, otra pregunta puede ser más importante:
¿Cuánto costaría sustituir estas direcciones?
Consideremos una plataforma de IA consolidada con clientes de todo el mundo.
Cambiar un prefijo público esencial podría exigir actualizar:
- Registros DNS
- Políticas de firewall
- Listas de permitidos de clientes
- Listas de permitidos de socios
- Configuraciones de seguridad de API
- Configuraciones de VPN
- BGP
- RPKI
- Monitorización
- DNS inverso
- Registros de geolocalización
- Documentos de cumplimiento
Algunos cambios pueden automatizarse.
Otros requieren la actuación de clientes o socios.
Eso crea una dependencia externa.
Cuantos más sistemas externos reconozcan una dirección, más costosa será la renumeración.
Las empresas de IA que crecen con rapidez deberían modelar este coste antes de que su infraestructura quede profundamente integrada.
Su ASN también importa
Las direcciones IP son solo una parte de la identidad de red.
Los grandes operadores de infraestructura de IA también pueden utilizar números de sistema autónomo.
Un ASN cobra especial relevancia cuando una empresa aplica políticas de enrutamiento independientes o se conecta mediante varios proveedores.
Una arquitectura simplificada podría ser:
Infraestructura de IA → prefijo IPv4 propio → ASN propio → varias redes ascendentes
Esto puede ofrecer más independencia de enrutamiento que depender por completo de direcciones asignadas por el proveedor.
Pero la independencia también conlleva responsabilidades.
Un operador debe comprender:
- Política BGP
- Anuncios de rutas
- Filtrado de prefijos
- RPKI
- Información IRR
- Relaciones con proveedores ascendentes
- Respuesta a incidentes
Una empresa de IA no necesita convertirse en especialista en gobernanza de Internet por el mero hecho de operar un ASN.
Pero alguien dentro de la organización debe comprender esa dependencia.
Un ASN no debería convertirse en un número olvidado en una hoja de cálculo hasta el día en que falle el enrutamiento.
Las empresas de IA deben comprender RPKI
RPKI es uno de los mecanismos más importantes de seguridad del enrutamiento vinculados a los recursos numéricos de Internet.
Una autorización de origen de ruta, o ROA, permite al titular de un recurso indicar qué ASN está autorizado para originar un prefijo.
RIPE NCC describe una ROA como un objeto RPKI firmado que autoriza a un ASN de origen a anunciar uno o varios prefijos, incluida, en su caso, una longitud máxima de prefijo.
Para un operador de infraestructura de IA, esto importa cada vez que cambia la arquitectura de enrutamiento.
Supongamos que su empresa de IA:
- Adquiere un bloque IPv4.
- Lo despliega desde ASN 64500.
- Crea la ROA correspondiente.
- Más adelante cambia a ASN 64501.
- Actualiza BGP, pero olvida la ROA.
La ruta puede ser operativamente legítima.
Pero la declaración de seguridad está desactualizada.
Las redes que realizan la validación del origen de rutas pueden considerar inválida la nueva ruta.
La lección es sencilla:
RPKI debe seguir la realidad de la red en funcionamiento.
Por tanto, los cambios de red y los cambios de registro o seguridad deberían formar parte del mismo proceso operativo.
La infraestructura de seguridad no debería convertirse en una herramienta de presión para la gobernanza
RPKI es valioso precisamente porque responde a una cuestión técnica concreta:
¿Está este ASN autorizado para originar este prefijo?
Ese alcance limitado es una fortaleza.
La infraestructura de seguridad se vuelve peligrosa cuando se transforma en un mecanismo general para imponer decisiones en disputas no relacionadas.
Un desacuerdo sobre:
- Estructura comercial
- Arrendamiento
- Geografía de los clientes
- Modelo de negocio
- Política institucional
no constituye automáticamente un problema de seguridad del enrutamiento.
RPKI debería reflejar una autorización técnica legítima.
No debería convertirse en una capa de castigo por desacuerdos institucionales ajenos.
Este principio deriva del marco más amplio que describo en Primacía del código en ejecución: los sistemas de coordinación deberían interpretarse según la función técnica mínima que realmente necesitan las redes en funcionamiento.
La declaración de misión del propio IETF ofrece un contexto útil. RFC 3935 describe la tradición del consenso aproximado y el código en ejecución, que fundamenta la legitimidad técnica en el criterio de ingeniería y la implementación en el mundo real.
Para las empresas de IA, la traducción práctica es:
La seguridad debe proteger la red. La gobernanza no debe convertir la infraestructura de seguridad en un punto de control ajeno a su función.
Comprar IPv4 no elimina automáticamente el riesgo de gobernanza
Una empresa de IA puede responder a su dependencia de IPv4 tomando esta decisión:
Simplemente deberíamos comprar nuestras direcciones.
Un control similar a la propiedad puede aportar ventajas importantes.
Pero comprar no hace desaparecer la capa de registro.
Después de adquirir IPv4, la empresa aún puede depender de:
- Registros administrativos
- Procedimientos de transferencia
- Servicios RPKI
- DNS inverso
- Acceso a cuentas
- Contactos administrativos
- Contratos con registros
- Continuidad institucional
Esto significa que la empresa ha trasladado el riesgo.
No necesariamente lo ha eliminado.
Eso no significa que comprar IPv4 sea incorrecto.
Significa que la adquisición debería distinguir entre:
adquisición comercial
y
arquitectura de continuidad.
Una transacción firmada puede establecer una posición comercial.
No responde automáticamente a todas las preguntas sobre el futuro del enrutamiento, la continuidad del registro, los servicios de seguridad o la dependencia institucional.
Arrendar IPv4 también plantea cuestiones de gobernanza
Lo mismo se aplica al arrendamiento.
Una empresa de IA puede arrendar IPv4 porque desea:
- Un coste inicial menor
- Un despliegue rápido
- Capacidad flexible
- Expansión multirregional
- Necesidades temporales de direcciones
Esto puede ser totalmente racional.
Pero la empresa debería saber:
- ¿Quién controla realmente el recurso de direcciones?
- ¿El proveedor es directo o actúa mediante un intermediario?
- ¿Qué ASN puede originar el prefijo?
- ¿Quién crea la ROA?
- ¿Quién controla el DNS inverso?
- ¿Qué ocurre si se deteriora la reputación?
- ¿Quién gestiona los abusos?
- ¿Qué ocurre en la renovación?
- ¿Qué ocurre si falla la relación ascendente asociada al recurso?
El peor momento para descubrir estas dependencias es después de que las direcciones se hayan convertido en identidades de red críticas.
La cuestión del intermediario es en realidad una cuestión de riesgo
Por eso el lenguaje habitual de adquisiciones puede inducir a error.
El mercado pregunta:
¿Quién puede conseguirnos IPv4?
Un operador de infraestructura de IA debería preguntar:
¿Quién asume el riesgo que hay detrás de IPv4?
Un mercado puede mostrar inventario.
Un intermediario puede presentar a una contraparte.
Un contrato puede describir las condiciones.
Pero las empresas de IA que construyen infraestructura de producción necesitan comprender qué sucede después de la transacción.
Si las direcciones se integran en los sistemas de los clientes, su valor depende cada vez más de la continuidad.
Por eso sostuve en Por qué existe i.LEASE y por qué la cuestión del intermediario es en realidad una cuestión de riesgo del registro que la ejecución de IPv4 debería evaluarse según la estructura de riesgo que existe bajo la transacción visible.
El mismo principio se aplica a las empresas de IA.
No evalúe el suministro de IPv4 únicamente por:
El precio por dirección.
Evalúe también:
La continuidad por dirección.
La portabilidad debería importar a los equipos de infraestructura de IA
Una de las mayores debilidades estructurales de la gobernanza de recursos numéricos de Internet es la ausencia de un mecanismo universal de portabilidad a nivel de recurso.
Distingo la portabilidad de recursos de la migración ordinaria de empresas o miembros.
La pregunta no es:
¿Puede la empresa cambiar de oficina?
Tampoco es:
¿Puede la empresa unirse a otra organización?
La pregunta es:
¿Puede el recurso numérico específico conservar la administración de su registro, la prueba de control, las declaraciones de seguridad y la continuidad operativa si falla la estructura administrativa actual?
Esa distinción importa para la infraestructura de IA.
Imaginemos que una empresa de IA ha construido una importante plataforma para clientes en torno a un bloque IPv4 estable.
Si la institución de registro que lo rodea sufre:
- Una crisis de gobernanza
- Insolvencia
- Parálisis jurídica
- Un fallo técnico
- Un conflicto grave
¿debería la empresa tener que renumerar su infraestructura simplemente porque el proveedor administrativo se volvió inestable?
Mi postura es que no.
Una red en funcionamiento necesita una vía de continuidad.
Por eso La Declaración de Derechos de la Coordinación de la Unicidad incluye la portabilidad como principio fundamental de diseño.
Proteja la función de registro, no la inmortalidad institucional
Esta distinción es especialmente relevante para las empresas de IA porque su infraestructura es cada vez más costosa y más importante para las operaciones.
Una empresa puede invertir miles de millones en construir capacidad de cómputo.
Sería irracional diseñar la capa de identidad de red de modo que dependa de la salud institucional permanente de una sola organización.
Las funciones del registro importan.
Incluyen:
- Unicidad de los números
- Registros precisos
- RDAP/WHOIS
- DNS inverso
- RPKI
- Historial de transferencias
- Metadatos de seguridad
Pero la continuidad de estas funciones no exige lógicamente la inmortalidad de la institución.
Desarrollo este argumento en La falacia de la continuidad del registro: proteja el libro de datos, no al guardián.
El principio es directo:
Proteja el libro de datos.
Proteja la cadena de seguridad.
Proteja la red en funcionamiento.
Proteja a los clientes.
La institución que administra esas funciones debería seguir siendo sustituible.
Para las empresas de IA, esto es ingeniería básica de infraestructura.
Exigimos conmutación por error en la computación.
Exigimos conmutación por error en la energía.
Exigimos conmutación por error en el almacenamiento.
Exigimos conmutación por error en la conectividad.
¿Por qué debería quedar exenta la capa de recursos numéricos?
Las empresas de IA deberían tratar el riesgo del registro como cualquier otro riesgo de infraestructura
Un registro de riesgos de infraestructura de IA maduro ya puede incluir:
- Suministro de GPU
- Disponibilidad de energía
- Concentración de centros de datos
- Fallo del tránsito
- Concentración de la nube
- Ciberseguridad
- Fallo de hardware
- Riesgo de proveedores
Añada:
Riesgo de recursos numéricos de Internet.
Este riesgo incluye varias categorías.
Riesgo administrativo
¿Quién controla las cuentas y credenciales necesarias para gestionar los recursos?
Riesgo del registro
¿Qué dependencias institucionales rodean a los recursos?
Riesgo de enrutamiento
¿Qué ASN anuncian los prefijos?
Riesgo de RPKI
¿Coinciden las declaraciones de seguridad con la realidad del enrutamiento?
Riesgo del proveedor
¿Depende la red de direcciones asignadas por el proveedor?
Riesgo de renovación
¿Podrían desaparecer las direcciones arrendadas al vencer el contrato?
Riesgo de identidad
¿Cuántos clientes y socios dependen de direcciones concretas?
Riesgo de portabilidad
¿Qué ocurre si debe cambiar el servicio administrativo?
Estas preguntas son pequeñas en comparación con el presupuesto de cómputo de una empresa de IA.
Sus consecuencias pueden no serlo.
Los equipos de infraestructura de IA necesitan su propio inventario de recursos numéricos
Toda empresa seria de infraestructura de IA debería poder responder:
¿De qué recursos numéricos de Internet dependemos?
El inventario debería incluir:
- Prefijos IPv4
- Prefijos IPv6
- ASN
- Titular del recurso
- Registro
- ASN de origen
- Estado de RPKI
- Autoridad de DNS inverso
- Estructura de arrendamiento o propiedad
- Fecha de renovación
- Proveedores ascendentes
- Clientes críticos
- Listas externas de permitidos
- Propietarios de cuentas administrativas
No deje esta información únicamente en la cabeza de un ingeniero de redes.
Trátela como metadatos de infraestructura.
La empresa debería poder afrontar cambios de personal sin perder el control de sus recursos numéricos.
Las empresas de IA deberían clasificar las IP según su criticidad
No todas las direcciones necesitan la máxima protección de continuidad.
Cree categorías.
Capacidad prescindible
Ejemplos:
- Entornos de desarrollo
- Pruebas temporales
- Experimentos de corta duración
El coste de renumeración es bajo.
Capacidad de producción
Ejemplos:
- Cargas de trabajo de clientes
- Infraestructura general de aplicaciones
- Servicios regionales en la nube
La continuidad importa, pero la sustitución aún puede ser manejable.
Identidad crítica para el negocio
Ejemplos:
- Principales puntos de acceso de API
- Puertas de enlace orientadas a socios
- Infraestructura regulada
- Direcciones de listas de permitidos de seguridad
- Sistemas relacionados con pagos
- Redes esenciales de clientes
La renumeración puede exigir una coordinación externa considerable.
Identidad no renumerable o con un coste de renumeración extremadamente alto
Esta categoría debería ser poco frecuente.
Pero cuando una dirección está integrada en clientes, sistemas de seguridad, socios, entornos de cumplimiento y varios proveedores, el coste de cambiarla puede superar al de mantener una arquitectura específica de continuidad.
El gasto en infraestructura debería seguir esta clasificación.
La respuesta de IPv6 no es suficiente
Las empresas de IA deberían desplegar IPv6 cuando tenga sentido técnico y comercial.
Pero IPv6 no hace desaparecer de la noche a la mañana la cuestión de la gobernanza de IPv4.
Una plataforma de IA aún puede interactuar con:
- Clientes que solo admiten IPv4
- Redes empresariales heredadas
- Productos de seguridad
- Sistemas de socios
- Servicios externos
- Listas de permitidos de clientes
La pregunta de planificación pertinente no es:
«¿IPv4 o IPv6?»
Es:
«¿Qué cargas de trabajo aún requieren IPv4, cuáles pueden funcionar con IPv6 y qué continuidad necesita cada identidad?»
Esa es una decisión de infraestructura.
No debería reducirse a una postura ideológica sobre la sustitución de un protocolo por otro.
La geografía no debería convertirse en propiedad
La infraestructura de IA es intrínsecamente mundial.
Un modelo puede entrenarse en un país.
Su API puede operar en otro.
Los clientes pueden estar en cualquier lugar.
El tráfico puede atravesar redes de varios continentes.
La administración de direcciones IP puede estar asociada históricamente a un registro regional de Internet concreto.
Pero la geografía de la región de servicio no debe confundirse con la propiedad del destino económico del recurso.
Esto es especialmente importante para las empresas mundiales de IA.
Internet enruta a escala mundial.
Un prefijo no adquiere una nacionalidad política por el mero hecho de que una base de datos concreta lo haya administrado históricamente.
La capa de coordinación necesita registros precisos.
No necesita decidir si los clientes de una empresa de IA son suficientemente locales para merecer acceso a un recurso escaso.
Esta distinción forma parte de una idea más amplia desarrollada a lo largo de mis notas:
La coordinación ligera funciona. La gobernanza pesada crea riesgos innecesarios.
¿Cómo debería ser una gobernanza ligera de direcciones IP?
Una capa útil de coordinación de recursos numéricos debería responder a un conjunto reducido de preguntas.
¿Es único el recurso?
No debería haber registros duplicados incompatibles.
¿Quién demuestra el control?
El sistema debería conservar pruebas fiables.
¿Son exactos los registros?
Los contactos y la información de los recursos deberían reflejar la realidad.
¿Son válidas las declaraciones de seguridad?
RPKI y los mecanismos relacionados deberían reflejar una autorización legítima de enrutamiento.
¿Se pueden auditar los cambios?
Las transferencias y actualizaciones deberían tener un historial fiable.
¿Pueden aislarse las disputas?
Un desacuerdo no debería destruir innecesariamente una red en funcionamiento.
¿Existe una vía de sustitución?
La función de registro debería sobrevivir al fallo de una institución.
Eso basta para sustentar una Internet interoperable a escala mundial.
Todo lo demás debería superar un umbral más exigente antes de hacerse obligatorio.
La pregunta siempre debería ser:
¿El código en ejecución realmente requiere esta regla?
Primacía del código en ejecución para la infraestructura de IA
Las empresas de IA están especialmente bien situadas para comprender este principio.
Los ingenieros de software ya distinguen entre:
lo que dice la especificación
y
lo que el sistema hace realmente.
La infraestructura de Internet debería abordarse con la misma disciplina.
La red en funcionamiento es real.
Los clientes son reales.
Las rutas son reales.
Las dependencias de seguridad son reales.
Un documento de políticas resulta útil cuando ayuda a coordinar esa realidad.
Se vuelve peligroso cuando pretende situarse por encima de ella.
Por eso la primacía del código en ejecución importa más allá de las empresas tradicionales de telecomunicaciones.
Las empresas de IA se están convirtiendo en operadores de infraestructura de Internet.
Deberían heredar la disciplina técnica que permitió funcionar a Internet:
coordinar lo que debe coordinarse y descentralizar todo lo que no requiere una decisión central.
Lista práctica de gobernanza IP para empresas de IA
Antes de ampliar una infraestructura de IA, plantee estas preguntas:
- ¿Qué recursos IPv4 e IPv6 sostienen la producción?
- ¿Qué ASN forman parte de nuestra red?
- ¿Quién figura como titular del recurso?
- ¿Qué registro administra cada recurso?
- ¿Quién controla el acceso administrativo?
- ¿Qué ASN origina cada prefijo de producción?
- ¿Son correctas nuestras ROA?
- ¿Quién puede modificar RPKI?
- ¿Quién controla el DNS inverso?
- ¿Son exactos los contactos WHOIS/RDAP?
- ¿Qué recursos están arrendados?
- ¿Qué recursos se poseen directamente?
- ¿Qué recursos proceden de proveedores?
- ¿Cuáles son las fechas de renovación?
- ¿Qué ocurre si un arrendador falla?
- ¿Qué ocurre si un registro deja de estar disponible?
- ¿Qué clientes han incluido nuestras direcciones en listas de permitidos?
- ¿Cuánto costaría renumerar cada prefijo crítico?
- ¿El recurso es solo capacidad o se ha convertido en identidad?
- ¿Existe una vía creíble de continuidad o sustitución?
Si la empresa no puede responder a estas preguntas, su infraestructura de recursos numéricos aún no está plenamente gobernada.
Lo que debería entender el consejo de administración
La gobernanza de direcciones IP no debería permanecer exclusivamente dentro del equipo de ingeniería de redes una vez que la empresa alcanza una escala suficiente.
Los consejos de administración y los altos directivos no necesitan entender la configuración de BGP.
Sí deberían comprender el modelo de riesgo.
Las preguntas pertinentes son:
¿Son estables las identidades de red críticas?
¿Pueden los clientes seguir accediendo al servicio si cambia un proveedor?
¿Puede un problema del registro interrumpir el negocio?
¿Cuánto costaría la renumeración?
¿Dónde están los puntos únicos de dependencia institucional?
Son preguntas de gobernanza porque afectan a la continuidad, el capital, las relaciones con los clientes y la flexibilidad estratégica.
Lo que deberían preguntar los inversores
Los inversores que realizan la diligencia de infraestructura de una empresa de IA también deberían examinar los recursos numéricos.
Una pregunta útil de diligencia no es simplemente:
«¿Tienen suficientes direcciones IP?»
Pregunte en cambio:
- ¿Cómo se obtienen?
- ¿Qué proporción se arrienda?
- ¿Qué proporción se posee directamente?
- ¿Quién asume el riesgo del registro?
- ¿Qué direcciones son críticas para el negocio?
- ¿El enrutamiento se controla internamente?
- ¿Están documentados los procesos de RPKI y del registro?
- ¿Qué ocurre si terminan relaciones esenciales vinculadas a las direcciones?
Una empresa de IA con una capacidad de cómputo extraordinaria, pero una identidad de red frágil, sigue teniendo un riesgo de concentración de infraestructura.
El riesgo es simplemente menos visible.
La cuestión de gobernanza más amplia
La IA puede convertirse en uno de los mayores nuevos consumidores de capital de infraestructura mundial.
Eso la convierte en una parte interesada importante en el futuro de la gobernanza de Internet.
Pero las empresas de IA no deberían entrar en ese debate pidiendo un control más centralizado.
Deberían pedir una mejor ingeniería.
La capa de recursos numéricos debería ser:
- Exacta
- Auditable
- Segura
- Portable
- Sustituible
- Resistente a la captura
- Centrada en la continuidad
Internet sí necesita coordinación.
No necesita una soberanía innecesaria sobre los identificadores.
La distinción será más importante a medida que siga aumentando el valor económico construido sobre los recursos numéricos.
Reflexiones finales
Las empresas de IA están aprendiendo a pensar estratégicamente en chips, energía, refrigeración, terrenos, fibra y centros de datos.
Deberían añadir a esa lista los recursos numéricos de Internet.
Las direcciones IPv4, las direcciones IPv6, los ASN, BGP, RPKI, el DNS inverso y los registros administrativos pueden parecer detalles profundos de la pila de infraestructura.
No lo son.
Contribuyen a determinar si los clientes pueden acceder a la infraestructura cuya construcción ha costado tanto dinero a la empresa.
A medida que crezcan las empresas de IA, algunas direcciones IP seguirán siendo capacidad prescindible.
Otras se convertirán en una identidad de red profundamente integrada.
El modelo de gobernanza debería reconocer la diferencia.
Las preguntas correctas no son solo:
¿Cuántas direcciones IP tenemos?
¿Cuánto cuestan?
Pregunte:
¿Quién las controla?
¿Quién puede enrutarlas?
¿Quién puede modificar las declaraciones de seguridad?
¿Qué dependencias institucionales las rodean?
¿Pueden sobrevivir a un cambio de proveedor?
¿Pueden sobrevivir a un fallo del registro?
¿Qué ocurre cuando divergen la realidad operativa y la administrativa?
Este es el significado más profundo de la gobernanza de direcciones IP.
El registro debería proteger la unicidad.
Debería proteger la precisión.
Debería proteger las declaraciones legítimas de seguridad.
Debería hacer comprensibles las transferencias y los cambios de control.
Pero no debería convertirse en propietario del destino operativo construido alrededor de los números que registra.
La infraestructura de IA dependerá cada vez más de una identidad de red estable.
Esa infraestructura merece la misma disciplina de diseño aplicada a cualquier otra capa crítica:
Ningún punto único de fallo innecesario.
Ningún administrador irremplazable cuando la conmutación por error sea técnicamente posible.
Ninguna confusión entre coordinación y soberanía.
Proteja el libro de datos.
Proteja la red en funcionamiento.
Proteja al cliente.
Eso es lo que las empresas de IA deberían saber sobre la gobernanza de direcciones IP.
Lecturas internas en Heng.lu
- La Declaración de Derechos de la Coordinación de la Unicidad
- Primacía del código en ejecución: el parche necesario para preservar el diseño original de Internet
- La falacia de la continuidad del registro: proteja el libro de datos, no al guardián
- Sobre LARUS One — La economía de la identidad de red, la continuidad del cliente y los ingresos del proveedor
- Por qué existe i.LEASE y por qué la cuestión del intermediario es en realidad una cuestión de riesgo del registro
Lecturas externas autorizadas
- IANA — Recursos numéricos
- RFC 7020 — El sistema de registro de números de Internet
- RFC 3935 — Declaración de misión del IETF
- RIPE NCC — ¿Qué es RPKI?
- RIPE NCC — Validación del origen BGP
Preguntas frecuentes (FAQ)
1. ¿Por qué deberían preocuparse las empresas de IA por la gobernanza de direcciones IP?Las empresas de IA que operan API, nubes de GPU, centros de datos, plataformas empresariales y otras infraestructuras orientadas a Internet pueden llegar a depender de direcciones IP públicas y ASN. La gobernanza afecta a la forma en que estos recursos se registran, enrutan, protegen, transfieren y mantienen operativos.
2. ¿Qué recursos numéricos de Internet deberían controlar las empresas de IA?Como mínimo, las empresas deberían mantener inventarios de prefijos IPv4 de producción, prefijos IPv6, números de sistema autónomo, relaciones con registros, orígenes de enrutamiento, configuración RPKI, DNS inverso y contratos de recursos.
3. ¿Cuál es la diferencia entre una dirección IP y una identidad de red?Una dirección IP comienza como un identificador técnico. Puede convertirse en identidad de red cuando clientes, socios, firewalls, API, sistemas de seguridad y procesos de cumplimiento dependen de que esa dirección concreta permanezca estable.
4. ¿Deberían las empresas de IA comprar direcciones IPv4?La compra puede tener sentido para necesidades previsibles a largo plazo, pero una adquisición comercial no elimina las dependencias del registro, el enrutamiento, RPKI y la administración. Por tanto, la decisión debería incluir un análisis de continuidad.
5. ¿Deberían las empresas de IA arrendar IPv4?El arrendamiento puede ofrecer capacidad flexible y un menor coste inicial. Antes de que la producción dependa del bloque, las empresas deberían evaluar el origen del recurso, la estructura del proveedor, la autoridad de enrutamiento, RPKI, el DNS inverso, la reputación, la renovación y la continuidad.
Categorías: Blog
