AS196745 es visible; la obligación no: cómo verificar a Datacenta

Summary

AS196745 es una identidad de red verificable: RIPE la registra como DATACENTA-AS, y una instantánea de RIPEstat del 20 de julio de 2026 muestra prefijos IPv4 e IPv6 visibles desde gran parte de sus colectores. Esa prueba acredita un origen de rutas; no identifica automáticamente al dueño de cada activo ni al responsable de cada obligación comercial.
El rastro societario contiene entidades que deben mantenerse separadas. SC208801, 15255267 y 03290605 remiten a sociedades distintas, mientras la web de X-Net y sus términos presentan a X-Net (Services) Ltd como proveedor que opera bajo la marca Datacenta Hosting. Las coincidencias de nombre no prueban una transferencia de contratos, recursos o pasivos.
El documento decisivo para un comprador no es una ficha BGP ni una página comercial, sino la Service Specification firmada. Los términos públicos remiten allí el espacio contratado, el nivel de Internet, el tráfico incluido, las reglas de cortafuegos y otras prestaciones, y dejan condicionados aspectos como copia de seguridad, ancho de banda garantizado, acceso físico, mantenimiento y salida.
Una revisión responsable debe enlazar tres clases de evidencia sin confundirlas: registros independientes para identidad y visibilidad, declaraciones del proveedor para conocer su oferta y documentos contractuales para fijar responsabilidades. Las lagunas entre esas capas son preguntas pendientes, no permisos para suponer la respuesta más favorable.

La coincidencia nominal no cierra el expediente

Una compra de alojamiento gestionado puede parecer fácil de delimitar desde fuera. Hay una marca, una página de servicios, un número de sistema autónomo y varias entradas en registros públicos. La tentación es leerlos como distintas vistas de una misma empresa. En este caso, esa simplificación borraría la cuestión más importante: quién se obliga exactamente frente al cliente y con qué recursos promete cumplir.

La evidencia pública ofrece una respuesta sólida a una pregunta estrecha. AS196745 existe, está activo en el registro consultado y aparece con el nombre DATACENTA-AS. El objeto de organización asociado por RIPE es ORG-DHL11-RIPE, cuya etiqueta es Datacenta Hosting Ltd, con el número SC208801 y la dirección Q.20 Dorset Innovation Park.[5][7] Esto permite conectar una identidad de red con una etiqueta registral. Es una conexión útil para investigar rutas, contactos y recursos numéricos. No equivale a una opinión jurídica sobre la sociedad que hoy contrata, ni a un inventario de quién posee edificios, servidores o circuitos.

La diferencia no es académica. Si un incidente exige aplicar créditos de servicio, recuperar datos, obtener acceso a equipos o reclamar por un plazo incumplido, el cliente no reclamará a una ruta BGP. Reclamará a la contraparte nombrada en sus documentos. Si esa contraparte usa una marca compartida con otras sociedades, el comprador necesita ver cómo se distribuyen las obligaciones entre ellas. Un nombre parecido puede orientar la búsqueda, pero no sustituye una garantía, una cesión documentada o una relación contractual explícita.

Por eso la diligencia debe avanzar de lo observable a lo exigible. Primero se fija qué registros dicen qué cosa y en qué fecha. Después se separan las declaraciones comerciales de las condiciones generales. Por último, se exige que la oferta concreta convierta las promesas relevantes en parámetros, responsabilidades y remedios. La fuerza del expediente no procede de acumular capturas con la palabra Datacenta, sino de poder seguir una cadena sin saltos desde la red utilizada hasta la entidad que factura y desde esa entidad hasta la obligación que puede hacerse valer.

Tres números societarios y funciones que no deben mezclarse

El primer número relevante es SC208801. Companies House muestra hoy a esa entidad como Datacenta Hosting (Scotland) Ltd, activa e incorporada en julio de 2000, con la actividad 63110 de procesamiento de datos, alojamiento y actividades relacionadas. El mismo registro indica que llevó el nombre DATACENTA HOSTING LIMITED desde septiembre de 2003 hasta el 17 de septiembre de 2024.[4] Esta es la sociedad cuyo número aparece en el objeto de organización de RIPE, aunque la etiqueta registral de ese objeto siga siendo Datacenta Hosting Ltd.[7]

El segundo número es 15255267. Corresponde a una sociedad inglesa incorporada en noviembre de 2023 como PBL 200 LTD. Companies House la muestra ahora con el nombre DATACENTA HOSTING LTD, adoptado el 23 de septiembre de 2024, y su historial incluye cuentas de sociedad inactiva para el periodo terminado en noviembre de 2024.[2][3] El cambio se produjo seis días después de que SC208801 dejara de usar su nombre anterior. Esa proximidad cronológica puede justificar una pregunta sobre una reorganización coordinada. No prueba que se transfirieran clientes, contratos, direcciones IP, equipos, propiedad intelectual, empleados o pasivos.

El tercero es 03290605. Companies House identifica esta entidad como X-Net (Services) Ltd, activa y antes denominada KIMCELL LIMITED hasta abril de 2024.[1] La página de contacto de X-Net dice que X-Net es el nuevo nombre de Kimcell, que a su vez operaba comercialmente como Datacenta Hosting, y mantiene datos de soporte de Datacenta en Dorset.[15] Los términos de servicios gestionados van un paso más allá para la relación comercial: nombran a X-Net (Services) Ltd como proveedor que opera bajo la marca Datacenta Hosting.[16]

Estas piezas describen una constelación, no una fusión automática de identidades. El registro de red asocia AS196745 con ORG-DHL11-RIPE y SC208801; la sociedad que ahora lleva en Companies House el nombre exacto DATACENTA HOSTING LTD tiene el número 15255267; y los términos públicos atribuyen el papel de proveedor a X-Net (Services) Ltd. Cada dato puede ser verdadero a la vez porque responde a una función distinta. El problema aparece solo cuando un comprador presume que todas las funciones recaen jurídicamente en la misma persona sin pedir el puente documental.

Ese puente debería ser concreto. La propuesta, el pedido, la factura y la Service Specification tendrían que identificar de manera compatible a la contraparte. Si el servicio usa recursos registrados a nombre de otra entidad, conviene explicar bajo qué acuerdo se ponen a disposición. Si certificaciones, inmuebles, contratos de energía o circuitos están a nombre de una sociedad diferente, el comprador necesita saber qué derecho tiene su proveedor para depender de ellos y qué ocurre si cambia esa relación. Si hubo una transferencia empresarial, importan su fecha, alcance y efecto sobre acuerdos anteriores. Nada de esto puede deducirse del parecido entre nombres.

Lo que RIPE fija con precisión

La capa de red es más nítida, siempre que se mantenga dentro de sus límites. RDAP registra AS196745 como un sistema autónomo activo denominado DATACENTA-AS, con fecha de registro en diciembre de 2009 y ORG-DHL11-RIPE como organización registrante.[5] El objeto de organización de RIPE da a ORG-DHL11-RIPE la etiqueta Datacenta Hosting Ltd, el número SC208801, el país GB y la dirección Q.20 Dorset Innovation Park; la versión consultada fue modificada por última vez el 13 de mayo de 2026.[7]

Esos campos sirven para responder preguntas verificables. Permiten confirmar qué identificador de sistema autónomo se investiga, qué nombre muestra el registro, qué objeto de organización está vinculado y qué datos administrativos publica ese objeto. También ayudan a evitar homónimos: AS196745 no es una referencia vaga a “la red de Datacenta”, sino un recurso numérico concreto con una política registrada y observaciones externas asociables.

La ficha aut-num añade la política declarada. Enumera importaciones desde AS5511, AS60670 y AS206347.[6] RIPEstat, mediante su conjunto de vecinos observados, devuelve esos mismos tres sistemas autónomos como adyacencias observadas.[8] La coincidencia entre política declarada y observación es informativa: hay más que una afirmación comercial genérica sobre conectividad. Existe un rastro técnico que un comprador puede revisar y volver a consultar.

Pero el significado termina antes de muchas conclusiones habituales. Un objeto RIPE no identifica al propietario del inmueble donde termina una fibra. No dice quién firmó el contrato con cada proveedor, cuánto caudal se compró, qué puertos están activos, si los trazados físicos comparten una canalización o si una conmutación de respaldo funciona bajo carga. Tampoco determina qué sociedad emplea al personal de guardia o paga los equipos. La asociación registral es evidencia de administración de recursos de Internet; no es un levantamiento de activos ni una matriz de responsabilidades corporativas.

La mejor lectura de RIPE es, por tanto, positiva y acotada. Hay una identidad de red persistente, una asociación registral y una política que puede contrastarse con observaciones. Para una evaluación técnica, es un punto de partida valioso. Para una decisión contractual, es un índice hacia nuevas pruebas: autorización para operar los recursos, relación entre el registrante y el proveedor, diseño actual de conectividad y compromiso que aparece en la oferta firmada.

Una ruta globalmente visible no es una promesa de servicio

RIPEstat permite observar el plano de enrutamiento con más detalle. En la consulta fechada el 20 de julio de 2026 a las 16:00 UTC, AS196745 originaba seis prefijos IPv4 que sumaban 1.536 direcciones y diez prefijos IPv6 /48. RIPE RIS veía las rutas IPv4 desde 323 de 325 pares de observación y las IPv6 desde los 320 pares de esa instantánea.[9] La conclusión prudente es clara: el origen tenía una visibilidad muy amplia en ese conjunto de observadores y en ese momento.

Esto sí importa. Una organización que evalúa una dependencia digital no debería conformarse con que un proveedor diga que “tiene red”. Puede buscar el ASN, comprobar los anuncios, revisar el espacio originado y contrastar vecinos. La observación convierte parte del discurso en un hecho reproducible. También establece una línea base para detectar cambios posteriores: desaparición de prefijos, variaciones de origen o alteraciones en adyacencias serían señales para investigar.

No obstante, el BGP visible describe propagación, no calidad contractual. Los 323 pares que ven una ruta no son 323 circuitos del proveedor. Los tres vecinos observados no acreditan tres caminos físicamente independientes. Un mismo riesgo de obra civil, energía, configuración, plataforma o instalación puede afectar rutas que en el grafo lógico parecen separadas. El conjunto de datos tampoco publica el precio o la modalidad de tránsito, la capacidad comprometida, la saturación en hora punta, la protección frente a ataques, los tiempos de convergencia ni el rendimiento que experimenta un cliente concreto.

La distinción se vuelve crítica en una incidencia. Que un prefijo siga visible no significa que una aplicación esté disponible: puede haber fallos detrás del borde, filtros incorrectos, pérdida de paquetes, almacenamiento inaccesible o capacidad insuficiente. A la inversa, una variación temporal de visibilidad en un colector no prueba por sí sola una caída para todos los usuarios. BGP ayuda a formular y comprobar preguntas de red, pero no reemplaza mediciones del servicio contratado ni el lenguaje del SLA.

Por eso un comprador debería pedir el diseño que conecta la observación pública con su entrega específica. ¿Qué circuito llevará su tráfico? ¿Qué upstreams pueden transportar ese circuito y desde qué emplazamientos? ¿La diversidad prometida cubre proveedor, entrada al edificio, canalización y equipo de terminación? ¿Cómo se prueba la conmutación y cuándo fue la última prueba? ¿Qué capacidad está reservada y qué umbral activa una ampliación? ¿Qué métricas se conservan para demostrar pérdida, latencia y utilización? Las respuestas no están en RIPEstat; RIPEstat demuestra por qué vale la pena pedirlas con precisión.

Tampoco debe convertirse una instantánea en una garantía futura. Las cifras de prefijos y pares pertenecen a una hora concreta. Son evidencia fechada, no una cláusula de disponibilidad. La diligencia madura conserva esa fotografía como referencia, define qué cambios requerirían notificación y vincula cualquier compromiso relevante a la Service Specification. Así, la visibilidad pública cumple su función correcta: verificar una parte del mecanismo sin fingir que verifica el contrato entero.

PeeringDB: una discrepancia que sirve para preguntar

La ficha de AS196745 en PeeringDB identifica a Datacenta Hosting y declara una política de peering abierta. Al mismo tiempo, deja sin revelar el nivel de tráfico y el alcance geográfico, muestra cero prefijos IPv4 y cero IPv6, no enumera presencia en puntos de intercambio ni instalaciones públicas y figura actualizada por última vez en julio de 2022.[14] Leída literalmente y sin contexto, podría parecer el retrato de una red sin huella. Comparada con RIPEstat, queda claro que no puede usarse así: la observación de julio de 2026 muestra seis prefijos IPv4 y diez IPv6 /48 originados.[9]

La contradicción no invalida automáticamente ninguno de los sistemas. PeeringDB es un perfil mantenido por sus participantes y puede quedar incompleto o envejecido; RIPEstat observa anuncios desde colectores y no pretende describir contratos, puertos o edificios. Cada fuente tiene un objeto distinto. Lo relevante para la diligencia es que la ficha de PeeringDB no está suficientemente actualizada para cerrar un mapa presente de capacidad o ubicación.

Sus tablas vacías tampoco permiten afirmar que no haya interconexión privada, tránsito en una instalación no declarada o infraestructura física. La ausencia de una fila en un perfil voluntario es, como máximo, una ausencia de divulgación allí. Convertirla en prueba de inexistencia sería tan incorrecto como convertir una lista de vecinos BGP en prueba de fibras separadas.

La marca explica la oferta; el contrato identifica al obligado

Las páginas de Datacenta Hosting presentan una gama que incluye alojamiento gestionado, colocación en Dorset, aplicaciones administradas, controles ambientales, UPS, monitorización y capacidad de soporte continuo.[13] La página de red ofrece banda ancha, enlaces punto a punto, peering seleccionado y tránsito IP bajo AS196745.[11] La de copias dice que los datos cifrados se almacenan en el Reino Unido y que puede ofrecerse una ubicación secundaria.[10] La página de seguridad afirma que el operador posee sus instalaciones de alojamiento, no revende suelo o espacio de rack a otros proveedores de hosting y utiliza circuitos con rutas diversas.[12]

Estas declaraciones ayudan a entender qué quiere vender la marca. No son inútiles por ser comerciales: proporcionan vocabulario para preparar preguntas, descubren dependencias potenciales y permiten comprobar si la propuesta concreta cubre lo anunciado. Pero las páginas revisadas no muestran inventario de capacidad libre, asignaciones por cliente, contratos de circuito, resultados de pruebas, alcance de certificados ni evidencia independiente de propiedad. Además, parte del contenido carece de fecha visible en el paquete examinado. Cada afirmación debe conservar su atribución hasta que un documento actual la confirme.

La identidad del proveedor en los términos añade una capa decisiva. El texto de X-Net presenta a X-Net (Services) Ltd como proveedor que opera bajo la marca Datacenta Hosting.[16] Esto no borra la asociación de AS196745 con ORG-DHL11-RIPE, ni convierte a SC208801 o 15255267 en la misma entidad. Indica dónde empieza la lectura de las obligaciones publicadas. Un cliente potencial debería comprobar que su cotización y su factura usan esa misma contraparte o, si usan otra, obtener una explicación y condiciones coherentes.

También debería pedir que las dependencias entre sociedades sean visibles en la asignación de riesgo. Si X-Net (Services) Ltd presta el servicio utilizando red, inmuebles, personal o certificaciones vinculados a otra entidad, el cliente necesita saber qué acuerdos sostienen ese uso y si continuarán durante toda la vigencia. Si la sociedad contratante subcontrata una función, importan los derechos de auditoría, la continuidad ante terminación y la responsabilidad por actos del subcontratista. Si no hay subcontratación porque los activos pertenecen a la misma contraparte, el contrato puede decirlo con claridad.

La palabra “marca” tampoco reduce la responsabilidad por sí sola. Operar comercialmente como Datacenta Hosting es compatible con un contrato plenamente exigible de X-Net (Services) Ltd. El riesgo surge cuando la documentación deja que el comprador atribuya a esa contraparte activos o promesas que solo aparecen en páginas bajo otra identidad. La solución no es descartar la oferta; es hacer coincidir propuesta, especificación, términos, factura, activos críticos y responsables antes de asumir una dependencia.

La Service Specification es la superficie real de control

Los términos de servicios gestionados publicados por X-Net explican por qué la Service Specification merece más atención que cualquier eslogan. Según esos términos, allí se determinan el espacio máximo de servidor, los niveles de servicio de Internet, el tráfico incluido, las reglas de cortafuegos y otros detalles de rendimiento.[16] En otras palabras, el documento genérico establece un marco, pero la prestación comprada toma forma en una especificación particular.

Ese reparto tiene consecuencias. Un folleto puede hablar de conectividad y copias; una especificación puede definir cuánta conectividad y qué copia se incluyen para un cliente concreto. Sin ese segundo documento, dos compradores de la misma marca podrían estar adquiriendo servicios materialmente distintos. La diligencia no debe preguntar solo “¿ofrecen backup?”, sino “¿está seleccionado para este servicio, qué sistemas cubre, con qué frecuencia se ejecuta, dónde se conserva y qué obligación de restauración asume la contraparte?”.

El ancho de banda ilustra el problema. Los términos no prometen una velocidad mínima de transferencia salvo que se seleccione ancho de banda garantizado.[16] Una referencia comercial a tránsito IP o una ruta muy visible no llena ese vacío. El comprador debe decidir qué caudal mínimo necesita, si la medida se aplica al puerto, al percentil, al flujo o al servicio completo, durante qué intervalos se evalúa y qué ocurre al incumplirse. También necesita distinguir tráfico incluido de capacidad disponible: un cupo de transferencia y una tasa mínima son conceptos distintos.

La misma precisión es necesaria para los niveles de servicio. “Internet service levels” en la Service Specification debería convertirse, para la oferta concreta, en métricas observables: alcance del componente cubierto, ventana de medición, exclusiones, fuente de datos, proceso de reclamación y remedio. Si el objetivo del cliente es continuidad de una aplicación, un SLA limitado a la interfaz de red puede ser insuficiente. Si el proveedor administra sistema operativo, almacenamiento o aplicación, la especificación debe decir dónde empieza y termina cada responsabilidad.

Las reglas de cortafuegos abren otra frontera. No basta saber que existe un cortafuegos. Conviene identificar quién aprueba cambios, quién los ejecuta, qué plazo rige para solicitudes ordinarias y urgentes, cómo se registran, quién revisa reglas obsoletas y qué acceso conserva el cliente. Si una configuración impide una recuperación o expone un servicio, la trazabilidad de la orden será tan importante como el dispositivo empleado.

Una Service Specification eficaz también debería contener una jerarquía documental. Cuando una página comercial, una propuesta y los términos generales usan expresiones diferentes, ¿qué documento prevalece? ¿La especificación incorpora anexos de seguridad, tratamiento de datos, soporte y salida? ¿Los cambios requieren firma de ambas partes o pueden introducirse mediante una notificación? ¿Las referencias a servicios opcionales significan que están incluidos o solo disponibles por un precio adicional? Resolver estas preguntas antes de la firma evita discutir, durante una incidencia, qué versión de una promesa era vinculante.

La identidad vuelve a entrar aquí. El nombre legal y el número de la contraparte deben figurar sin ambigüedad en la especificación y concordar con el pedido. Si la entidad que administra AS196745 es distinta, la relación debe documentarse en la medida en que afecte a la entrega. Si el soporte se presta desde una marca o sociedad diferente, deben quedar claros el canal, el horario, la autoridad para actuar y la responsabilidad final. Una firma al pie de un documento incompleto no corrige una cadena de identidad opaca; una especificación detallada sí puede convertir esa cadena en obligaciones auditables.

Copia de seguridad: de la disponibilidad comercial a la recuperación demostrada

La página de Datacenta Hosting dedicada a backup dice que las copias pueden ejecutarse localmente dentro de cada centro de datos y de forma remota entre centros, que los datos cifrados se almacenan en el Reino Unido y que puede ofrecerse un sitio secundario.[10] Son elementos relevantes para diseñar resiliencia. Sin embargo, los términos generales asignan la copia al cliente salvo que se solicite y acuerde una opción de backup.[16] La combinación obliga a comprobar la compra concreta: una capacidad ofrecida no es una capacidad contratada.

El primer cierre documental es el alcance. La especificación debería enumerar sistemas, volúmenes, bases de datos, configuraciones y credenciales incluidos. Debería indicar si la copia es consistente con la aplicación o solo una captura de almacenamiento, qué elementos quedan fuera y quién mantiene agentes o claves. En un servicio gestionado, frases amplias como “backup diario” pueden ocultar diferencias decisivas: hora de corte, retención, tratamiento de fallos, cifrado, separación de privilegios y posibilidad de borrar simultáneamente producción y copias.

El segundo cierre es la topología. “Local” y “remoto” necesitan ubicaciones exactas o, cuando la seguridad impida publicarlas abiertamente, una descripción verificable bajo confidencialidad. El cliente debe saber si producción y copia comparten edificio, energía, plataforma de control, dominio de identidad o personal operativo. También debe saber si el sitio secundario está incluido, reservado y disponible para su carga, o si es una opción que solo se contrataría después de un incidente. La página comercial no responde esas preguntas.

El tercero es la recuperación. RPO y RTO no deberían aparecer como siglas decorativas, sino como objetivos medibles vinculados a escenarios. El RPO define cuánto cambio puede perderse; el RTO, cuánto puede tardar la restauración del servicio dentro del alcance acordado. Para evaluar si son creíbles hacen falta pruebas: frecuencia, conjuntos restaurados, criterios de éxito, incidencias encontradas y correcciones. El paquete de fuentes no contiene resultados actuales de restauración, de modo que no permite afirmar que una recuperación haya tenido éxito.

La inmutabilidad requiere el mismo rigor. Una copia puede estar cifrada y aun así ser eliminable por una cuenta comprometida. El comprador debería preguntar por controles de borrado, separación administrativa, retención bloqueada, supervisión y procedimiento de emergencia. De nuevo, no se trata de exigir una arquitectura única, sino de comprobar que la arquitectura ofrecida corresponde al riesgo del cliente y está incluida en la Service Specification.

Finalmente, la responsabilidad debe llegar hasta la validación. ¿Quién detecta un trabajo fallido? ¿Quién avisa? ¿En cuánto tiempo? ¿Quién decide iniciar una restauración y quién verifica que la aplicación es utilizable? Si la respuesta depende del cliente, este necesita acceso a alertas y conocimientos suficientes. Si depende del proveedor, el compromiso y su horario deben quedar escritos. La evidencia pública abre esta conversación; solo el acuerdo específico puede cerrarla.

Mantenimiento, acceso y soporte: ventanas que necesitan límites

Los términos permiten mantenimiento programado y de emergencia.[16] Esa flexibilidad es comprensible para operar infraestructura, pero no define por sí sola el impacto aceptable para un cliente. La Service Specification debería aclarar preavisos, ventanas habituales, componentes afectados, posibilidad de aplazamiento, comunicaciones durante el trabajo y tratamiento de interrupciones que excedan lo previsto. También debería separar mantenimiento excluido del SLA de indisponibilidad atribuible a una ejecución defectuosa.

La noción de soporte continuo en las páginas comerciales necesita una traducción contractual equivalente.[13] “24/7” puede referirse a monitorización, recepción de tickets, intervención técnica o presencia física; no son la misma promesa. El comprador debe pedir niveles de severidad, tiempos de acuse y actuación, rutas de escalado, autoridad del personal de guardia y cobertura de terceros. Si una incidencia depende de un operador de tránsito o de un equipo situado en otra instalación, importa quién coordina y con qué plazo.

El acceso físico también está condicionado. Los términos requieren aviso y lo encuadran en los horarios de soporte.[16] Para un cliente que coloca su propio servidor, esto puede afectar diagnóstico, sustitución y retirada. Conviene documentar identificación de visitantes, acompañamiento, plazo para acceso urgente, manos remotas disponibles, costes y procedimiento cuando el horario ordinario no basta. Una afirmación de soporte amplio no elimina una restricción específica de acceso.

Las pruebas de energía y refrigeración pertenecen a esta misma capa. Las páginas describen UPS, controles ambientales y monitorización,[13] pero el paquete no aporta resultados recientes de pruebas ni capacidad reservada. Una revisión seria pediría alcance y fecha de ensayos, mantenimiento preventivo, respuesta ante alarmas y dependencias compartidas. No necesita publicar detalles sensibles; sí necesita evidencia suficiente para que el cliente entienda qué mecanismo sostiene su servicio y cómo se comprueba.

La salida revela quién controla realmente la dependencia

Los términos dicen que, al terminar, el cliente debe retirar su servidor por su cuenta dentro de siete días. También prevén almacenamiento y una eventual disposición de equipos no recogidos.[16] Esta cláusula convierte la salida en una obligación operativa con reloj propio. Un cliente que espere negociar logística después de la terminación puede descubrir que la ventana contractual ya está corriendo.

La planificación debería empezar antes de contratar. Para equipo físico, hacen falta inventario, propiedad identificada, contactos autorizados, embalaje, transporte, acceso y procedimiento de borrado o custodia. Si hay piezas pertenecientes al proveedor y otras al cliente, la separación debe estar documentada. Si un servidor contiene datos regulados o claves, la cadena de custodia importa tanto como el plazo.

Para servicios virtuales, la salida es distinta pero no menos concreta. El comprador debe saber en qué formato puede exportar máquinas, volúmenes, bases de datos, registros y configuraciones; cuánto tarda la preparación; qué coste tiene; y durante cuánto tiempo se conserva una copia después de terminar. También necesita un plan para DNS, certificados, reglas de cortafuegos, listas permitidas y cualquier dependencia de direcciones IP. Una exportación de datos sin esos elementos puede dejar una aplicación técnicamente recuperable pero operativamente inmóvil.

La identidad societaria vuelve a ser relevante cuando se ejecuta el plan. ¿Quién autoriza la entrega de equipos? ¿Quién conserva las copias? ¿Quién factura almacenamiento posterior? ¿Qué sucede si la marca cambia mientras el contrato sigue vigente? La especificación y el anexo de salida deben nombrar responsables, no solo canales comerciales. Si los activos o recursos están vinculados a otra entidad, se necesita asegurar que la contraparte contratante puede cumplir la devolución incluso cuando cambie esa relación.

Un buen mecanismo de salida también limita la dependencia sin exigir una migración inmediata. Puede incluir pruebas periódicas de exportación, documentación actualizada, asistencia a la transición, borrado certificado y continuidad durante un periodo acordado. Estas condiciones no se deducen de AS196745 ni de la existencia de un sitio secundario. Son decisiones económicas y operativas que deben negociarse mientras ambas partes quieren cerrar el acuerdo, no cuando una de ellas ya ha decidido terminarlo.

El expediente que un comprador debería pedir

La revisión puede organizarse como una cadena de pruebas. No todas tienen que ser públicas y no todas requieren el mismo nivel de detalle, pero cada una debería responder a una pregunta concreta y tener un propietario. Un paquete razonable incluiría los siguientes bloques.

1. Identidad contractual. La propuesta, el pedido, la Service Specification, los términos y la factura modelo deberían mostrar el nombre legal, número societario y dirección de la contraparte. El proveedor debería explicar la relación de X-Net (Services) Ltd con Datacenta Hosting (Scotland) Ltd, DATACENTA HOSTING LTD, ORG-DHL11-RIPE y AS196745 en la medida necesaria para entender la entrega. Si hubo transferencias o licencias relevantes, deben identificarse los documentos y fechas que las sostienen. El objetivo no es obtener un organigrama decorativo, sino saber quién responde por red, instalaciones, personal, datos, certificaciones y SLA.

2. Autoridad sobre los recursos de red. La evidencia RIPE ya muestra la asociación registral. Falta cerrar cómo la contraparte contractual está autorizada a utilizar y operar esos recursos durante el acuerdo. El proveedor puede aportar una declaración de estructura, contrato intragrupo u otra evidencia apropiada. También debería confirmar qué prefijos soportarán el servicio, si el cliente depende de direcciones portables o del proveedor y qué asistencia habrá para renumerar o migrar.

3. Diseño de conectividad. Un diagrama actual debería identificar upstreams, puntos de entrega, equipos de borde, dominios de fallo y caminos de conmutación. Las referencias a AS5511, AS60670 y AS206347 sirven para contrastar la capa lógica, no para completar el diseño físico. La documentación debería distinguir diversidad de operador, de ruta, de entrada, de energía y de equipo. Las pruebas de failover deberían incluir fecha, alcance, resultado y acciones pendientes.

4. Capacidad reservada. La oferta necesita especificar puerto, ancho de banda garantizado si se compra, tráfico incluido, política de exceso y mecanismo de ampliación. Para cómputo y almacenamiento, debería indicar recursos comprometidos, sobreasignación relevante, límites y umbrales de expansión. Nada en las fuentes revisadas prueba existencias actuales de racks, servidores, discos o caudal libre; esa evidencia debe proceder de la oferta y de los controles internos que el proveedor esté dispuesto a demostrar.

5. Emplazamientos y controles físicos. La dirección Q.20 Dorset Innovation Park aparece en el objeto RIPE,[7] y las páginas comerciales describen servicios en Dorset,[13] pero eso no basta para identificar todos los lugares de producción y backup ni su titularidad. El cliente debería obtener la ubicación aplicable, la función de cada sitio, dependencias comunes, derechos de acceso y evidencia actual sobre energía, refrigeración, detección, protección y mantenimiento. Las afirmaciones de propiedad o rutas diversas deben confirmarse para la solución comprada.

6. Copia y recuperación. El anexo debería enumerar conjuntos protegidos, frecuencia, retención, cifrado, ubicación, separación administrativa, inmutabilidad y supervisión. RPO y RTO necesitan escenarios, no solo cifras. Las últimas pruebas de restauración deberían demostrar qué se recuperó y hasta qué punto, sin exponer datos de otros clientes. Si el servicio secundario es opcional, la especificación debe decir expresamente si se contrata y qué capacidad queda disponible.

7. Operación y escalado. Deben figurar horario de cada función, niveles de gravedad, tiempos de respuesta, contactos, autoridad de guardia, monitorización, conservación de registros y coordinación con terceros. El comprador debería conocer qué alarmas puede ver y qué informes recibirá. Una promesa de soporte continuo cobra valor cuando se sabe quién actúa, sobre qué componentes y con qué objetivo temporal.

8. Mantenimiento y créditos. El acuerdo debería definir preaviso, ventanas, excepciones de emergencia, comunicación y criterios para atribuir una interrupción. Los créditos necesitan una fórmula, un proceso de solicitud y un límite comprensible. Si ciertos eventos quedan excluidos, la exclusión debe ser estrecha y verificable. De lo contrario, la flexibilidad operativa puede vaciar la métrica que el cliente creía comprar.

9. Seguridad y alcance de certificaciones. Las páginas del proveedor pueden señalar controles y credenciales, pero el comprador debe verificar certificados vigentes, entidad titular, ubicaciones, servicios y exclusiones cubiertos. También necesita responsabilidades sobre parches, vulnerabilidades, acceso privilegiado, registros, notificación de incidentes y subprocesadores. Una insignia sin alcance no responde si el servicio concreto está dentro del sistema certificado.

10. Acceso y manos remotas. Para colocación o equipos dedicados, la especificación debería fijar aviso, disponibilidad fuera de horario, autorización, acompañamiento, tareas permitidas y tarifas. Debe existir una vía de emergencia compatible con el objetivo de recuperación. Si solo el proveedor puede tocar un equipo, el plazo de manos remotas se convierte en parte de la continuidad y merece una métrica propia.

11. Portabilidad y terminación. El anexo de salida debería cubrir datos, máquinas virtuales, configuraciones, DNS, certificados, direcciones, registros y hardware. Necesita formatos, plazos, costes, asistencia, retención posterior, borrado y resolución de equipos no retirados. El límite de siete días de los términos debe evaluarse contra la logística real del cliente y modificarse en la especificación si resulta insuficiente.

12. Conciliación continua. La diligencia no termina al firmar. Un cambio de nombre legal, registrante de ASN, upstream, instalación, proveedor crítico o certificado debería activar notificación y revisión. El comprador puede conservar una línea base de Companies House, RIPE y RIPEstat y volver a consultarla de forma proporcionada. Si la evidencia pública cambia, el contrato debe ofrecer un canal para obtener la explicación vigente.

Esta lista no pretende imponer el mismo volumen documental a cualquier compra. Un servidor no crítico y una plataforma esencial no justifican idéntico esfuerzo. Sí propone una regla común: cada control que determine el riesgo debe aparecer en un documento que corresponda al servicio concreto. Cuando una respuesta solo remite a una página web, el expediente aún contiene una afirmación; cuando identifica parámetro, responsable, evidencia y remedio, empieza a contener un control.

Cómo leer las lagunas sin convertirlas en acusaciones

La discrepancia entre registros puede provocar dos reacciones igualmente pobres. Una es ignorarla porque los nombres “se parecen”. La otra es tratarla como prueba automática de que algo va mal. Ninguna respeta la evidencia. Companies House, RIPE, RIPEstat, PeeringDB y las páginas del proveedor describen objetos diferentes, con procesos y fechas diferentes. La tarea analítica consiste en determinar qué puede probar cada uno y qué pregunta deja pendiente.

Companies House es la referencia adecuada para nombres societarios, números, estados y presentaciones públicas de las entidades citadas.[1][2][3][4] RIPE es la referencia para la identidad registral de AS196745, su objeto de organización y la política declarada.[5][6][7] RIPEstat aporta una observación fechada de rutas y vecinos.[8][9] PeeringDB muestra lo que el perfil publicó o dejó sin publicar en su última actualización.[14] Las páginas de Datacenta Hosting y X-Net presentan la oferta y la identidad comercial declarada.[10][11][12][13][15] Los términos exponen el marco contractual público y el papel central de la Service Specification.[16]

Esta clasificación permite graduar confianza. La existencia de 15255267 y su nombre actual no depende de una afirmación promocional. La propiedad de un edificio afirmada en una página del proveedor no queda independientemente verificada por ese solo texto. La amplia visibilidad de rutas observada en una instantánea es más fuerte que una descripción genérica de conectividad, pero más estrecha que una garantía de rendimiento. Y ninguna de esas fuentes sustituye el contrato de un cliente real.

Cuando falta una pieza, la redacción correcta es “no cerrado con las fuentes revisadas”, no “inexistente”. No hay en este paquete contratos de circuitos, resultados de restauración, inventarios de capacidad ni certificados con su alcance actual. Eso impide afirmar su contenido; no permite afirmar que no existan. El proveedor puede cerrar la laguna con evidencia adicional durante una compra. La distinción protege tanto al comprador de una confianza infundada como al proveedor de una inferencia injusta.

También mejora la negociación. Una pregunta basada en evidencia es más eficaz que una sospecha general: “RIPE asocia el ASN a SC208801, mientras nuestros términos nombran a X-Net (Services) Ltd; muéstrenos la relación operativa y contractual aplicable” es verificable. “Su estructura parece confusa” no lo es. “RIPEstat observa tres vecinos, pero necesitamos diversidad física; entregue el diseño y la última prueba” define el hueco. “Demuestre que su red es buena” no define una respuesta suficiente.

Una decisión basada en controles, no en semejanzas

Al final, el caso Datacenta no se resuelve eligiendo cuál registro parece más auténtico. Todos pueden aportar información válida dentro de su ámbito. Se resuelve comprobando si la oferta crea una cadena continua entre el servicio deseado, los recursos que lo soportan, las entidades que los controlan y la sociedad que acepta responder.

Una decisión favorable puede ser racional aun con una estructura de varias entidades, siempre que las relaciones estén documentadas y las obligaciones sean exigibles. También puede ser racional aceptar ciertos controles menos ambiciosos para una carga de bajo impacto. Lo que no es racional es valorar la solución como si la asociación registral, la visibilidad BGP, la marca y el contrato fueran sinónimos. Esa equivalencia no aparece en las fuentes.

El comprador debería poder resumir su conclusión en términos simples. Sabe quién firma y factura. Sabe por qué esa entidad puede usar AS196745 y los demás activos esenciales. Conoce los lugares y dominios de fallo relevantes para su servicio. Ha elegido de manera expresa ancho de banda, backup y soporte. Ha visto pruebas proporcionadas de conmutación y restauración. Entiende mantenimiento, acceso, créditos y salida. Y dispone de una Service Specification que prevalece donde una página comercial es general.

Si alguna frase depende de “suponemos que”, todavía hay una tarea de cierre. Puede resolverse con una aclaración contractual, un anexo, una prueba o una decisión consciente de aceptar el riesgo. Lo importante es que no quede escondida detrás de una coincidencia de nombre o de un gráfico de rutas.

AS196745 aporta una señal pública valiosa: una red activa, visible y susceptible de observación independiente. La documentación societaria aporta otra: los nombres y números relevantes no son intercambiables. Los términos aportan la tercera y más práctica: los detalles capaces de convertir la oferta en obligación viven en la Service Specification. Juntas, esas señales no dictan si comprar. Sí dictan cómo evitar comprar una promesa cuya identidad, alcance o remedio solo se descubre cuando ya hace falta ejercerlo.

AS196745 es visible; la obligación no: cómo verificar a Datacenta Hosting antes de firmar