Resumen
- Intelion Cloud se puede vincular a una sociedad de responsabilidad limitada rusa registrada en marzo de 2024, un acuerdo de servicio público detallado y registros de la organización RIPE en la misma dirección de Moscú. La etiqueta en inglés Intelion Cloud LTD está, por lo tanto, conectada a una superficie corporativa y de red real, aunque cada registro todavía tiene su propio propósito.
- AS214186 era completamente visible para los 326 colectores IPv4 de RIPEstat el 15 de julio de 2026, anunciando dos /24 válidos por RPKI. Esta es una evidencia operativa significativa, pero es una huella IPv4 compacta con un vecino observado, sin IPv6 observado y bloques de direcciones registrados a otra organización, en lugar de una prueba de cada reclamo de infraestructura en el sitio web.
- Intelion publica una historia de automatización creíble en torno a recursos de autoservicio, OpenStack, redes virtuales, computación medida y un agente de soporte de IA. Los mismos términos revelan los controles que importan: una clave de acceso seleccionada por defecto, acciones aprobadas por el cliente, límites de VM de un gigabit, tiempo de inactividad activado por ticket, opciones de copia de seguridad programadas y retención dependiente del saldo.
- La localidad y el soporte son específicos del servicio. Las ubicaciones de computación rusas no mantienen cada solicitud de inferencia en Rusia, y la redacción del soporte público varía desde las 24 horas hasta horarios contractuales más restringidos. Un comprador necesita un mapa de datos de la carga de trabajo, una matriz de soporte firmada y evidencia actual del operador antes de tratar el nombre de la nube como una garantía operativa.
Un nombre de nube es un conjunto de promesas
El error más fácil en la diligencia debida de la nube es preguntarse si un proveedor es real y detenerse cuando la respuesta se vuelve afirmativa. Se encuentra un registro corporativo. Un sitio web acepta pagos. Un sistema autónomo aparece en una base de datos de enrutamiento. La casilla marcada como identidad se verifica, y todos los demás reclamos comienzan a tomar prestada la confianza de ella.
Intelion Cloud es un caso útil porque el registro público es lo suficientemente sólido como para recompensar la investigación y lo suficientemente desigual como para castigar los atajos. No es un nombre de directorio sin un producto detrás. La empresa ofrece servidores GPU, infraestructura virtual, máquinas dedicadas y un servicio de inferencia. Publica términos legales en Markdown legible y PDF. Nombra tecnologías, opciones de diseño de red, canales de soporte, ubicaciones de datos y reglas de retención. Su sistema autónomo está actualmente anunciando rutas.
Hay suficiente material para entender cómo se supone que debe funcionar una relación con el cliente.
Sin embargo, los registros no colapsan en un simple certificado de calidad. El registro de la empresa rusa establece una contraparte legal. El sitio web describe un servicio ambicioso. Los documentos del cliente asignan derechos y obligaciones. Los registros RIPE muestran la administración de recursos numéricos. Los colectores de rutas muestran qué orígenes son visibles en un momento dado. Una página de producto describe el soporte. Ninguna de estas fuentes responde todas las preguntas planteadas por las otras.
Esa separación no es pedantería. Se asigna directamente a fallos. Si un pago es disputado, la entidad contratante y el registro de facturación importan. Si un prefijo desaparece, el sistema autónomo, la autorización de ruta y la escalada del operador importan. Si una solicitud de modelo contiene datos regulados, la región de procesamiento seleccionada importa. Si una máquina virtual detenida queda sin fondos, la cláusula de retención importa. Si una GPU falla fuera del horario laboral, la diferencia entre la monitorización de la instalación y el soporte técnico presencial importa.
Por lo tanto, la forma correcta de leer Intelion Cloud es como un sistema operativo compuesto por varias promesas públicas. La identidad, la automatización, el alcance de la red, la localidad, el soporte y la recuperación son módulos separados. El proveedor ha publicado más detalles que muchas pequeñas empresas de infraestructura. Esa es una señal positiva porque le da al comprador algo comprobable. También crea la obligación de conciliar declaraciones cuando el sitio, el contrato y la observación externa describen diferentes bordes del mismo servicio.
El juicio central no es que Intelion Cloud tenga muy poca prueba. Es que la prueba disponible cambia el trabajo del comprador. La pregunta ya no es si hay un servicio detrás del nombre. La pregunta es si el servicio específico que un cliente pretende comprar está lo suficientemente delimitado como para que cada promesa importante pueda asignarse a un registro, un control y un respondedor responsable.
El ancla corporativa es joven y específica
La búsqueda del Servicio Federal de Impuestos de Rusia devuelve una empresa para el número de impuesto 9703176519: OOO "Intelion Oblako", una sociedad de responsabilidad limitada rusa registrada en Moscú el 14 de marzo de 2024. El resultado proporciona OGRN 1247700236519 e identifica a Maksim Nikolaevich Vyaznikov como director general. La página "Acerca de" de Intelion publica los mismos números de impuesto y registro, la misma jurisdicción de Moscú y una dirección en el terraplén Presnenskaya.
Nombra a Vyaznikov como director ejecutivo y describe la actividad principal de la empresa como procesamiento de datos, alojamiento y servicios relacionados.
Ese acuerdo entre una búsqueda oficial de empresas y la propia página legal del proveedor es el ancla de identidad más limpia en la evidencia. Conecta la marca orientada al cliente con una entidad legal capaz de hacer una oferta pública, facturar a los clientes y recibir notificaciones. El acuerdo de usuario repite el OGRN y el número de impuesto y dice que el registro, la financiación o el uso de la cuenta aceptan la oferta. Los términos públicos también definen el panel de control, el saldo de la cuenta, los documentos electrónicos y los canales para mensajes legales.
Estos detalles hacen que la superficie comercial sea más legible que una página de marca sola.
La identidad de red se une en un punto diferente. La organización registrada en RIPE ORG-ICL71-RIPE se registró en septiembre de 2024 bajo el nombre Intelion Cloud LTD y la misma dirección de Moscú. Cinco días después, AS214186 se registró con el nombre INTLMN y la organización Intelion como registrante. El registro del sistema autónomo se modificó en febrero de 2026, mientras que el registro de la organización se cambió nuevamente en mayo. El sitio web de la empresa, la organización RIPE y el registro del sistema autónomo no son, por lo tanto, meros nombres antiguos que se parecen entre sí.
Comparten una dirección actual, una marca y una superficie de contacto operativa.
Todavía hay límites útiles. La empresa es joven. La fecha de registro de marzo de 2024 no prueba que cada instalación, empleado o actividad relacionada comenzara entonces, y no proporciona un historial largo de rendimiento. La organización RIPE utiliza la representación en inglésLTDmientras que la empresa contratante es la rusa OOO "Intelion Oblako". Un correo electrónico de contacto en la organización RIPE utiliza el dominiointelionmine.ru, mientras que el rol de abuso utilizaintelion.cloud. Ese patrón puede reflejar una relación administrativa o la historia de la empresa, pero los registros revisados aquí no definen un grupo corporativo ni transfieren responsabilidad de una marca a otra.
Un comprador debe hacer explícita la unión en el paquete contractual. La orden de servicio, el beneficiario de la factura, los términos de procesamiento de datos, el contacto de abuso y la carta de red deben identificar la entidad legal y el rol que está desempeñando. Si el equipo, los acuerdos con operadores o el personal de soporte son proporcionados por afiliados o contratistas, esas responsabilidades deben nombrarse. El registro público proporciona un punto de partida creíble. No debería obligar a un cliente a inferir la cadena legal durante una interrupción.
La página "Acerca de" también afirma que Intelion está inscrita en el registro de proveedores de alojamiento de Rusia y otorga el número de empresa de TI acreditada 73678. Esas son pistas regulatorias relevantes, pero la evidencia fija no contiene un extracto gubernamental específico de la empresa que confirme cada detalle. La conclusión responsable es que Intelion afirma públicamente esos estatus y proporciona identificadores para su verificación. Deben verificarse en un ejercicio de adquisición, particularmente cuando la elegibilidad, el manejo de datos o el tratamiento fiscal dependen de ellos.
La identidad corporativa importa aquí porque el servicio no es simplemente un software descargable. Un cliente está confiando a una empresa aceleradores físicos, almacenamiento, acceso a la red, fondos de la cuenta y posiblemente solicitudes de modelo. Cuanto más fuerte es la automatización, más consecuente se vuelve el ancla legal. Una cuenta puede aprovisionar capacidad en minutos; una disputa sobre datos eliminados, servicio fallido o una clave de acceso comprometida aún se moverá a la velocidad de los contratos, la evidencia y las personas.
El producto es más legible que la etiqueta de la nube
La página de inicio de Intelion ahora hace una oferta concreta. Anuncia servidores GPU en Rusia, facturación por segundo, la capacidad de detener la computación y dejar de pagar por ella, retención de disco después del apagado, IPv4 pública, una conexión de gigabit y acceso a través de SSH, VNC o RDP. Un usuario crea una cuenta, financia un saldo, lanza un servidor y se conecta. Las cargas de trabajo previstas incluyen entrenamiento de modelos, generación de imágenes y video, visión por computadora, inferencia y procesamiento de voz.
Los documentos subyacentes amplían esa superficie. El acuerdo de usuario cubre servidores dedicados, la Plataforma Cloud y servicios relacionados. Los términos de la Plataforma Cloud definen máquinas virtuales, discos virtuales, redes virtuales aisladas, copias de seguridad, clústeres de bases de datos, almacenamiento de archivos, direcciones públicas y proyectos. Los términos del servidor dedicado describen equipos físicos propiedad del proveedor ensamblados para el cliente y normalmente suministrados dentro de las 24 horas cuando existe capacidad.
Los términos de la Plataforma de Inferencia definen una API HTTPS para modelos de lenguaje grande y otros modelos de aprendizaje automático, con solicitudes medidas y regiones de procesamiento explícitas.
Eso no es un solo producto. Son al menos tres acuerdos operativos bajo un mismo nombre.
El cliente de servidor dedicado recibe uso remoto de una máquina física y acepta restricciones específicas del hardware. El cliente de nube crea recursos lógicos en infraestructura compartida y opera su propio sistema invitado. El cliente de inferencia envía una solicitud a un endpoint de modelo cuyo proveedor y región de procesamiento pueden estar fuera de las propias instalaciones de Intelion. El sitio web puede comercializar los tres como infraestructura de IA, pero sus modos de fallo, evidencia y rutas de datos son diferentes.
Esta distinción mejora la adquisición. Un comprador que busca un A100 para una ejecución de entrenamiento corta debe preguntar sobre la asignación del acelerador, la persistencia del disco, el límite de red, la procedencia de la imagen y la recuperación ante fallos del host. Un equipo que compra una máquina dedicada de larga duración debe centrarse en el reemplazo de componentes, la asistencia remota, los períodos de gracia, los repuestos y el tiempo de reconstrucción.
Una aplicación que llama a un endpoint de inferencia debe preocuparse por la versión del modelo, el registro de solicitudes, la región, la dependencia del proveedor externo, los límites de velocidad y el aviso de descontinuación. La palabra nube no puede hacer ese trabajo analítico.
El inventario público también es visiblemente dinámico. La página de H100 decía que la tarjeta no estaba disponible el 15 de julio y dirigía a los clientes a una alternativa A100. Ese pequeño hecho es más útil que una afirmación permanente de amplia capacidad. Recuerda a los compradores que un catálogo de productos describe lo que un proveedor quiere ofrecer, mientras que un pedido describe lo que realmente está reservado.
Para aceleradores escasos, la unidad de diligencia debida debe ser una configuración fechada: modelo, memoria, cantidad, topología del host, interconexión, clase de almacenamiento, región, fecha de disponibilidad y derechos de sustitución.
Intelion nombra OpenStack, OVN/Open vSwitch, PostgreSQL, Redis, Celery, NVMe y NUMA entre las tecnologías detrás de su plataforma. Esa lista es consistente con un plano de control de nube de autoservicio moderno. También debe seguir siendo lo que es: una pista de arquitectura de primera parte. Un logotipo de tecnología no establece la versión implementada, el estado del parche, el aislamiento del inquilino, la durabilidad del almacenamiento o la competencia operativa. Esas preguntas requieren evidencia de configuración y pruebas.
Lo que el registro público del producto establece es un límite lo suficientemente sustancial como para examinarlo. No se pide a los clientes que simplemente confíen en un nombre. Pueden ver el modelo de recursos previsto, los límites de red, la base de facturación, el canal de soporte, las reglas de retención y los remedios del servicio. El siguiente paso es entender dónde la automatización cambia el trabajo en lugar de pretender que hace desaparecer el trabajo.
El autoservicio traslada el trabajo a la política y las excepciones
La parte atractiva de la oferta de Intelion es la velocidad. Un cliente selecciona recursos, financia una cuenta y crea una máquina a través del panel de control. Los términos dicen que el servicio comienza cuando se crea un recurso dentro de un proyecto y existen fondos suficientes. Los clientes eligen máquinas virtuales, discos y redes, ajustan cuotas y operan sistemas invitados de forma remota. Los registros de facturación se generan a partir de las mediciones del proveedor de los servicios consumidos.
Esto es automatización empresarial en una forma reconocible. Una secuencia que antes requería una solicitud de hardware, una orden de compra, una visita al rack, una instalación del sistema operativo y una configuración manual de red se convierte en una transacción controlada. El cliente recibe capacidad cuando la necesita y la libera cuando la tarea termina. Para trabajos GPU intermitentes, eso puede cambiar tanto el costo como la velocidad de experimentación.
Pero el trabajo no ha desaparecido. Se ha trasladado al diseño de políticas, la gestión de capacidad, la medición, la seguridad de la cuenta, el mantenimiento de imágenes, la revisión de excepciones y la recuperación. Alguien debe definir los límites del proyecto. Alguien debe decidir qué sustituciones de GPU son aceptables. Alguien debe investigar una discrepancia en la facturación. Alguien debe aprobar una excepción de puerto, restaurar una carga de trabajo fallida o explicar por qué un recurso anunciado no está disponible.
La plataforma es eficiente cuando esas responsabilidades son explícitas; se vuelve opaca cuando el panel de control se trata como todo el servicio.
Los propios documentos de Intelion revelan varios ejemplos. Un host se describe como conectado a 10 Gbps, compartido entre las máquinas virtuales que se ejecutan en él, mientras que cada VM está limitada a 1 Gbps. El proveedor puede reducir el ancho de banda o suspender el servicio cuando el uso amenaza la infraestructura compartida u otros clientes. Los puertos públicos están sujetos a bloqueos permanentes, cierres predeterminados y excepciones basadas en solicitudes. Los límites de cuenta y proyecto se pueden ajustar, pero la posibilidad técnica y la aprobación del proveedor siguen siendo parte del proceso.
Esos son controles razonables de múltiples inquilinos. También son donde las expectativas del cliente se encuentran con la discreción del operador. Una aplicación puede tener una dirección IPv4 pública y aún así no poder usar un protocolo en particular. Una VM puede tener un límite de un gigabit mientras que la página de marketing describe una fibra más rápida dentro de la instalación. Un proyecto puede solicitar más direcciones pero no recibirlas instantáneamente.
Un comprador debe convertir cada control relevante en una regla operativa antes del lanzamiento: quién puede solicitar una excepción, qué evidencia se necesita, cuánto tiempo toma normalmente la aprobación y qué sucede si la solicitud es rechazada.
La medición merece el mismo tratamiento. La facturación por segundo es valiosa solo si los eventos que inician, detienen y preservan los recursos se entienden bien. La página de inicio dice que detener un servidor detiene los cargos de computación y mantiene el disco libre durante 30 días. Los términos de la nube de julio proporcionan la máquina de estados más completa. Si una VM no se ha ejecutado durante 30 días consecutivos, Intelion puede eliminar la instancia mientras conserva el disco y moverlo a almacenamiento en frío medido después de al menos 24 horas de aviso.
Si el saldo llega a cero en el almacenamiento en frío, el cliente tiene 72 horas para financiar la cuenta antes de que el proveedor pueda eliminar el disco y sus datos sin otro aviso.
El mensaje de ventas simple y el contrato detallado no son necesariamente contradictorios. El almacenamiento de disco detenido gratuito puede cubrir un período inicial, seguido de almacenamiento en frío pagado. Pero la diferencia es operativamente importante. Un cliente que escucha solo "detener y no pagar" puede diseñar un proceso de archivo que los términos no respaldan indefinidamente. La automatización ha hecho que la transición de estado sea fácil; también ha hecho que las alertas de saldo, la entrega de notificaciones y el monitoreo de retención sean parte de la protección de datos.
Por lo tanto, el plano de control debe evaluarse como un sistema de registro. ¿Puede un cliente exportar el historial de recursos, los eventos de uso, los cambios de configuración, los mensajes de soporte y las mediciones de facturación? ¿Son consistentes las marcas de tiempo? ¿Puede un administrador distinguir una acción del usuario de una acción del proveedor? ¿Están representadas claramente una máquina detenida, un disco frío y un recurso eliminado? ¿Pueden las alertas llegar a más de una persona responsable? Estas no son características empresariales decorativas.
Determinan si el cliente puede reconstruir lo que sucedió después de un cargo disputado o una carga de trabajo perdida.
Intelion ha publicado la mecánica suficiente para hacer precisas esas preguntas. Esa es una ventaja. La tarea del comprador es verificar que la interfaz, el contrato y la práctica de soporte usen las mismas definiciones.
AS214186 es pequeño, actual y real
La evidencia más fuerte fuera del propio sitio de Intelion es AS214186. RIPE asignó el sistema autónomo el 16 de septiembre de 2024, bajo el nombre INTLMN y lo registró a Intelion Cloud LTD. RIPEstat observó por primera vez una ruta de origen actual desde él el 15 de octubre de 2024. El 15 de julio de 2026, el sistema fue anunciado y visible para los 326 pares IPv4 de RIPE RIS incluidos en la respuesta.
La huella era compacta: dos /24 IPv4, 512 direcciones en total. RIPEstat no vio anuncios IPv6 y un sistema autónomo vecino. Ambos /24 habían estado presentes durante la ventana de observación del 1 al 15 de julio. Los resúmenes de ruta secundarios también informaron dos prefijos IPv4, ningún IPv6 y un upstream visible, AS12389, PJSC Rostelecom.
Estos hechos importan. Un sistema autónomo activo le da a Intelion una identidad de enrutamiento pública distinta de una página de revendedor que se encuentra completamente detrás del espacio de direcciones de otro host. La visibilidad total del colector significa que las dos rutas de origen no eran anuncios oscuros vistos en un borde. La fecha de primera vista sigue a la asignación del ASN en aproximadamente un mes, lo que es consistente con una nueva red que se pone en operación. El registro también se ha mantenido en 2026.
Al mismo tiempo, los números establecen un límite alrededor de la inferencia. Dos /24 no prueban una red geográficamente amplia, gran capacidad, tránsito diverso, baja latencia o muchos clientes. Un vecino observado es una pista de topología, no un contrato de operador completo. Ningún anuncio IPv6 es una limitación actual real en la vista de enrutamiento público, pero no dice si IPv6 existe dentro de redes privadas o está planificado. La tabla de rutas puede verificar la accesibilidad en la capa de origen. No puede verificar la GPU, el almacenamiento o el soporte detrás de una dirección.
La ausencia de un perfil de red PeeringDB para AS214186 agrega poco por sí misma. PeeringDB es voluntario. Un servicio pequeño puede comprar tránsito, usar conexiones privadas y operar perfectamente bien sin mantener una página de interconexión pública. Lo que significa la ausencia es que un comprador no puede usar ese directorio para verificar instalaciones, puntos de intercambio, escala de tráfico o política de interconexión. El proveedor debe proporcionar evidencia de interconexión actual directamente si es importante para el servicio.
Aquí es donde la escala debe leerse honestamente. La superficie de enrutamiento público de Intelion no está vacía, inactiva o simplemente registrada. Tampoco es una gran red troncal de Internet. Parece la huella de origen enfocada de un operador de nube joven: suficiente para anunciar espacio IPv4 orientado al cliente bajo su propio ASN, lo suficientemente pequeño como para que cada prefijo y ruta externa importe. Para un comprador empresarial, esa concentración aumenta el valor de la evidencia exacta de ruta, operador y recuperación.
La autorización de origen no es propiedad de la dirección
Ambos anuncios actuales tienen autorizaciones de origen RPKI válidas para AS214186. El validador de RIPEstat encontró una autorización de origen de ruta válida para194.67.95.0/24y otra para185.182.108.0/24, cada una permitiendo a AS214186 originar el /24. Este es uno de los mejores detalles en el registro de red.
La validez de RPKI reduce un riesgo específico. Las redes que realizan validación de origen de ruta pueden ver que la autorización registrada coincide con el ASN de origen y la longitud del prefijo de Intelion. Eso hace que sea más fácil rechazar un origen conflictivo accidental o no autorizado. Para una red de dos prefijos, mantener ambas autorizaciones válidas es un control operativo práctico más que un adorno de cumplimiento.
No responde todas las preguntas de propiedad. Los registros de direcciones de RIPE nombran a RADIO-FSU/RADIO-MSU NETWORK Ltd como registrante para ambos rangos. Cada registro contiene por separado una referencia a Intelion: uno nombra a Intelion Cloud LTD y enlaza el sitio de la empresa, mientras que el otro incluye el dominio. Esto es consistente con que Intelion está autorizada para usar y anunciar espacio de direcciones registrado a otra organización. No es evidencia de que Intelion posea legalmente los bloques.
Esa distinción se vuelve importante durante la renovación, la respuesta a abusos o la migración. La organización que posee el recurso de dirección, la organización autorizada para originarlo, el operador que acepta la ruta y el cliente que usa una dirección pueden ser todos diferentes. Una ruta válida hoy no revela por sí misma cuánto tiempo puede Intelion usar los prefijos, quién puede cambiar la autorización de ruta o qué sucede si el acuerdo subyacente termina.
Un cliente que depende de direcciones de origen estables debe preguntar por la cadena específica del servicio: qué prefijo se asignará, quién es el titular registrado, qué acuerdo respalda el uso de Intelion, quién mantiene la autorización de origen de ruta, si la dirección puede moverse entre operadores y qué aviso se aplica si es necesario renumerar. Para un trabajo de entrenamiento corto, esto puede ser una preocupación menor. Para integraciones empresariales en listas blancas, infraestructura de correo o software con licencia vinculado a una dirección, puede convertirse en un riesgo de migración.
La conclusión positiva sigue siendo significativa. Intelion no está simplemente anunciando espacio no validado y pidiendo a los observadores que acepten el nombre. Los dos pares de origen de ruta eran válidos en el momento de la captura. La conclusión cuidadosa es igualmente importante: el origen válido es evidencia de enrutamiento autorizado, no una escritura del bloque de direcciones y no una garantía de los servicios a los que se llega a través de él.
La redundancia debe reconciliarse capa por capa
El sitio web de Intelion hace una afirmación de resiliencia específica. Dice que un centro de datos cerca de Samara utiliza líneas de Internet físicamente separadas de MegaFon y Rostelecom y anuncia los /24 PI del proveedor sobre ambas, permitiendo que el tráfico se mueva sin un cambio de dirección si una línea falla. Esa es una declaración mucho mejor que la promesa habitual de conectividad redundante porque identifica operadores, comportamiento de enrutamiento y el resultado esperado de fallo.
El registro externo respalda parte de esa historia y deja parte abierta. El objeto aut-num de RIPE declara política de importación y exportación con AS12389, Rostelecom, y AS21446, SOTEL LLC. RIPEstat observó un vecino el 15 de julio. Los resúmenes de ruta secundarios identificaron a Rostelecom como el upstream visible. Una sonda de marzo de 2026 en Samara también alcanzó la red de Intelion a través de Rostelecom. Por lo tanto, las fuentes coinciden en una ruta actual de Rostelecom. No muestran a MegaFon como un vecino observado en la vista global capturada, mientras que la segunda red declarada en el objeto RIPE es SOTEL en lugar de MegaFon.
Esta es una discrepancia para investigar, no un veredicto. Un operador puede proporcionar un servicio físico a través de otro sistema autónomo. Una sesión de respaldo puede no ser visible desde todos los colectores, puede estar configurada pero inactiva, o puede haber cambiado después de que se escribió un registro público. Un sitio web también puede simplificar un acuerdo mayorista en un nombre de operador minorista. La evidencia congelada no puede determinar qué explicación se aplica.
El comprador debe resistir dos conclusiones igualmente débiles. Una es que la afirmación de operador dual debe ser falsa porque se observó un vecino. La otra es que dos nombres en un sitio web prueban caminos independientes de extremo a extremo. La diversidad de BGP, la diversidad de ruta física y la diversidad de proveedores comerciales son controles diferentes. Dos sesiones pueden compartir un conducto, un enrutador, una fuente de alimentación o un dominio de fallo ascendente. Un origen visible puede tener un diseño de respaldo que funcione según lo previsto.
Por lo tanto, se debe solicitar evidencia actual en cada capa. Una vista de ruta puede mostrar ambas sesiones y los prefijos anunciados sobre ellas. Un dibujo de topología puede mostrar el equipo de entrega y las rutas de entrada física. Las órdenes de operador pueden identificar el servicio contratado. Un registro de conmutación por error controlado puede mostrar si el tráfico establecido se mueve, cuánto tiempo toma la convergencia y si las direcciones del cliente permanecen estables. El historial de monitoreo puede mostrar pérdida de paquetes y utilización antes y después de una transición.
La red es lo suficientemente compacta como para que esto sea manejable. Hay dos prefijos públicos, dos autorizaciones RPKI y una pequeña política externa declarada. Intelion no necesita producir una gran narrativa de red troncal. Necesita mostrar que la redundancia específica vendida a un cliente es actual, probada y adjunta a la instalación y al servicio en la orden.
La localidad pertenece a la carga de trabajo, no al nombre de la empresa
Intelion es una empresa rusa que vende servidores descritos como ubicados en Rusia. Su página "Acerca de" marca Moscú, la región de Samara, la región de Tver y Tula como ubicaciones operativas e identifica Kemerovo y Jakasia como próximas. La página de inicio describe un centro de datos activo cerca de Samara. Para un cliente que busca capacidad de cómputo en Rusia, estas son declaraciones directamente relevantes.
No son una respuesta universal de residencia de datos. Una dirección legal no es una ubicación de servidor. Un país de sistema autónomo no es una ubicación de disco. Una ruta BGP le dice a Internet cómo llegar a una dirección, no dónde se almacenan los datos detrás de ella. Incluso una lista de instalaciones no dice qué producto está disponible en qué sitio o dónde residen las copias de seguridad, los registros del plano de control, las transcripciones de soporte y los datos de facturación.
La propia estructura de productos de Intelion hace inevitable esta distinción. Una máquina virtual y su disco pueden colocarse en la infraestructura rusa del proveedor. Un servidor dedicado ocupa un sitio físico particular. La Plataforma de Inferencia puede tomar un camino muy diferente. Sus términos de mayo de 2026 definen dos clases de región de procesamiento: Rusia para modelos de peso abierto en la propia infraestructura de Intelion, e Internacional para modelos en la nube procesados a través de AWS Bedrock en Fráncfort o regiones de EE. UU.
El proveedor y la región del modelo seleccionado deben ser visibles en el panel de control y el endpoint de lista de modelos antes de enviar una solicitud.
Esa es una divulgación útil. Significa que un cliente no tiene que pretender que cada endpoint de modelo es local simplemente porque la factura proviene de un proveedor ruso. También significa que el cliente debe tomar una decisión arquitectónica activa. Una solicitud enviada a un modelo internacional cruza la frontera rusa, y los términos asignan al cliente las responsabilidades asociadas con esa transferencia cuando hay datos personales presentes.
Los términos de inferencia agregan más detalles. Intelion dice que la solicitud y el contenido generado no se utilizan para entrenar los modelos y no se retienen después del procesamiento, excepto para el registro técnico de fallos o requisitos legales. Los metadatos de uso, incluidos modelo, tiempo, recuentos de tokens, identificador de clave, identificador de cliente, estado y costo, se retienen durante tres años. Se promete a los clientes acceso a al menos 180 días de sus propios metadatos de uso.
Estas declaraciones crean un mapa de datos más útil que la palabra general "nube", pero siguen siendo afirmaciones contractuales en lugar de una prueba independiente de cada proveedor de modelos.
Por lo tanto, un mapa de datos empresarial debe seguir la carga de trabajo a través de todos sus estados. Para una VM, eso incluye la imagen, el disco de arranque, el almacenamiento adjunto, las copias de seguridad, las instantáneas, los registros del host, el acceso a la consola, los artefactos de soporte y el estado del recurso eliminado. Para una solicitud de inferencia, incluye el contenido de la solicitud, el contenido generado, el proveedor del modelo, la región, los registros de fallos transitorios, los metadatos de uso y cualquier registro de aplicación mantenido por el cliente.
Para la administración de la cuenta, incluye documentos de identidad, eventos de facturación, detalles de contacto y conversaciones de soporte.
El comprador debe asignar una geografía permitida y una regla de retención a cada estado. "Servidores en Rusia" es demasiado amplio para realizar esa función. Un requisito defendible suena más como esto: una VM nombrada, un disco y una copia de seguridad permanecen en una ubicación rusa nombrada; se registra el acceso de soporte; los endpoints de modelo internacional están deshabilitados para el proyecto; se comprende la retención de metadatos; y cualquier excepción requiere un cambio autorizado. Esa es soberanía de datos como un control operativo en lugar de un eslogan.
Los documentos públicos de Intelion hacen posible esa conversación. También muestran por qué la localidad no puede inferirse del nombre de la empresa. La misma cuenta puede acceder a computación local e infraestructura de modelo internacional. El campo decisivo es el servicio y la región seleccionados para la carga de trabajo.
El agente de soporte de IA crea una decisión de control de acceso
Intelion se describe a sí mismo como una nube nativa de IA, y la expresión más concreta de esa idea aparece en los términos de la Plataforma Cloud de julio. El proveedor dice que ofrece un agente de IA de software para ayudar a configurar y mantener máquinas virtuales. Durante la creación de la máquina, una clave pública para el agente se controla mediante una casilla de verificación que está seleccionada por defecto a menos que el cliente la desmarque. Los términos dicen que los empleados no usan esa clave, el agente realiza solo acciones acordadas con el cliente en el chat, y el cliente puede revocar el acceso eliminando la clave.
Esto es más que una etiqueta de marketing. Convierte el soporte en un flujo de trabajo de automatización privilegiado. El agente puede entrar en una máquina del cliente y realizar acciones que de otro modo requerirían un administrador. Si funciona bien, puede reducir el trabajo de configuración rutinario y acortar la distancia entre una conversación de soporte y un cambio de configuración. También puede hacer que un error de soporte sea más rápido y más repetible.
El problema central no es si un agente de IA es seguro en abstracto. Es si el límite de acceso es visible y gobernable para la carga de trabajo del cliente. Una casilla de verificación seleccionada por defecto significa que el cliente no debe confiar en el consentimiento pasivo. Una cuenta empresarial puede necesitar una política que deshabilite el acceso del agente por defecto y lo habilite solo para un ticket, máquina y ventana de tiempo específicos. Una carga de trabajo regulada puede prohibirlo por completo.
Los términos proporcionan un esqueleto útil para ese control: una clave distinta, acuerdo previo en el chat y revocación por parte del cliente. Un comprador debe preguntar por el resto de la evidencia. ¿Qué identidad firma la clave del agente? ¿Es la clave única por cliente o máquina? ¿Qué comandos puede ejecutar el agente? ¿Dónde se muestra la acción propuesta? ¿Puede un cliente requerir una segunda aprobación? ¿Se registran los comandos y las salidas de forma inmutable? ¿La revocación cierra las sesiones activas? ¿Cómo se manejan los errores del modelo, la inyección de instrucciones y las cuentas de soporte comprometidas?
¿Se pueden enmascarar los secretos antes de enviar el contexto a cualquier modelo?
Estos no son casos límite especulativos. El valor comercial del agente proviene de su capacidad para actuar. El radio de explosión proviene de la misma propiedad. Los términos dicen que las acciones se acuerdan en el chat, pero el acuerdo puede significar cualquier cosa, desde una vista previa clara del comando hasta una confirmación conversacional vaga. Un comprador empresarial debe definir lo que constituye aprobación y conservar el registro necesario para probarlo.
El agente también cambia el trabajo de soporte local en lugar de reemplazarlo. Alguien debe diseñar sus permisos, mantener su software, revisar las acciones fallidas, manejar las excepciones y asumir el control cuando la máquina es inalcanzable. El sitio de Intelion afirma por separado que un ingeniero in situ puede reiniciar a través de IPMI, reemplazar un disco o módulo de memoria y solucionar una GPU fallida. El agente de software y el ingeniero resuelven diferentes problemas. Uno actúa dentro de la máquina lógica; el otro puede tocar el equipo físico. Un modelo de soporte creíble explica cómo se mueve el trabajo entre ellos.
Intelion merece crédito por poner la mecánica de acceso del agente en términos públicos. Muchos servicios dejarían esa característica en una descripción de producto. La divulgación permite al comprador hacer la pregunta correcta: no "¿la nube usa IA?" sino "¿qué autoridad recibe el agente, y cómo se aprueba, observa y revoca cada ejercicio de esa autoridad?"
El soporte está dividido en cuatro relojes diferentes
El material público utiliza varias formas de la palabra soporte, y no deben tratarse como sinónimos.
El primer reloj es la monitorización de infraestructura. Intelion dice que recopila fluctuaciones de puertos, errores CRC y utilización las 24 horas del día y mantiene un ingeniero in situ en el centro de datos. Eso describe detección e intervención física. Es relevante para un conmutador, disco, módulo de memoria o GPU fallidos. No indica por sí mismo cuándo se responderá un mensaje.
El segundo reloj es la disponibilidad de la página del producto. La página de H100 dice soporte técnico las 24 horas en una sección, luego muestra soporte los siete días de la semana de 09:00 a 21:00 hora de Moscú cerca de la tarjeta del producto. Esas declaraciones son más amplias que el horario de oficina ordinario pero no idénticas entre sí. La página también dice que la copia de seguridad y la administración del sistema pueden ser servicios adicionales, lo que sugiere que el alcance de la ayuda incluida es tan importante como el reloj.
El tercer reloj es el contrato base. La sección 13.3 del acuerdo de usuario de marzo de 2026 dice que el soporte técnico se proporciona en días laborables de 09:00 a 18:00 UTC+3 durante no más de 30 minutos al día; el tiempo adicional se cobra según una tarifa separada. Las solicitudes se aceptan por correo electrónico o la cuenta oficial de Telegram. A menos que una orden de servicio otorgue algo más sólido, esta es la descripción pública más consecuente del derecho de soporte del cliente.
El cuarto reloj es el reloj de disponibilidad del servicio. La disponibilidad de la Plataforma Cloud se describe como 24x7x365. Eso dice cuándo se supone que el servicio funciona, no cuándo un humano debe responder. Una plataforma puede tener un compromiso de disponibilidad las 24 horas mientras que el servicio de soporte incluido trabaja un horario más restringido. Ese diseño puede ser adecuado para cargas de trabajo autogestionadas no críticas. Puede ser una brecha grave para un sistema de producción que necesita diagnóstico inmediato o intervención física.
El contraste no es una prueba de que Intelion no responda fuera del horario laboral. Es una prueba de que el comprador no debe inferir un derecho a partir de una frase del producto. El proveedor puede vender soporte mejorado, mantener un rol de guardia operativa o responder voluntariamente. El contrato público simplemente no hace que todas esas posibilidades sean parte de la promesa base.
Un horario de soporte útil debe nombrar gravedad, canal, objetivo de acuse de recibo, objetivo de compromiso técnico, frecuencia de actualización, objetivo de restauración y propietario de escalada. Debe distinguir las preguntas de la cuenta de los incidentes de infraestructura, los informes de abuso, los eventos de seguridad, las solicitudes de restauración de datos y la administración pagada. También debe indicar si el límite diario de 30 minutos se aplica durante una interrupción causada por el proveedor y si un ingeniero in situ puede ser contactado directamente por el servicio de soporte en todo momento.
El trabajo de soporte local es valioso precisamente porque los fallos de la nube cruzan capas. Una API puede informar que una VM se está ejecutando mientras que el invitado es inaccesible. Una ruta puede ser globalmente visible mientras que una ruta de almacenamiento está estancada. Un cliente puede aprobar una acción del agente que no puede arreglar una GPU fallida. La organización necesita a alguien que pueda correlacionar el estado del plano de control, la observación de la red, la telemetría del host y el equipo físico. El registro público muestra piezas de ese modelo operativo. El contrato necesita conectarlas.
Un porcentaje perfecto aún puede dejar una brecha práctica
El lenguaje de disponibilidad de Intelion es inusualmente ambicioso. Los términos de la Plataforma Cloud de julio establecen disponibilidad 24x7x365 y 100 por ciento de operatividad por hora, sujeto a exclusiones. Los términos del servidor dedicado establecen 100 por ciento por mes, nuevamente con exclusiones. La Plataforma de Inferencia utiliza 99.5 por ciento de disponibilidad mensual y excluye modelos beta junto con fallos específicos fuera del control de Intelion.
Esos porcentajes no deben promediarse en un número para toda la empresa. Se aplican a diferentes servicios, períodos de medición y cadenas de dependencia. Más importante aún, la mecánica del remedio determina lo que el número hace por un cliente.
Para la Plataforma Cloud, el trabajo técnico se excluye del tiempo no disponible, incluido el trabajo planificado y no planificado dirigido a mantener el equipo en funcionamiento o corregir fallos. El tiempo de inactividad comienza cuando el cliente envía un mensaje a través del sistema de tickets y termina cuando finaliza el trabajo de restauración. La compensación es tiempo adicional utilizando el mismo servicio, que generalmente coincide con el período no disponible, y el cliente debe solicitarlo. Una interrupción de más de cinco minutos pero menos de una hora se trata como una hora para la compensación.
Esta estructura crea tres consecuencias prácticas. Primero, la monitorización por parte del proveedor no necesariamente inicia el reloj de interrupción contractual; el ticket del cliente lo hace. Segundo, el porcentaje principal no es una medición histórica publicada para revisión externa. Es una promesa calculada bajo exclusiones definidas. Tercero, el remedio es tiempo de servicio, no necesariamente compensación por la pérdida consecuencial del cliente, el tiempo del personal o la carga de trabajo fallida.
Nada de eso hace que el SLA carezca de significado. Un reloj claro, una unidad de compensación mínima de una hora y un objetivo del 100 por ciento le dan al cliente una ruta contractual hacia un remedio. Pero el acuerdo recompensa a los clientes que monitorean de forma independiente y abren tickets rápidamente. Un equipo que asume que la monitorización las 24 horas del proveedor crea automáticamente un reclamo puede descubrir que su propia marca de tiempo de notificación es la evidencia importante.
Los términos de la nube también contienen una cláusula incompleta donde se debían identificar el operador de comunicaciones y los detalles del contrato. Esa brecha de redacción se encuentra junto a las afirmaciones de operador más específicas en el sitio web. No borra las rutas o los circuitos. Sí debilita la capacidad del contrato para identificar la dependencia de red sin contexto externo. Un cliente debe tener ese campo completado en la orden de servicio o en un anexo técnico adjunto.
La prueba correcta no es si el 100 por ciento suena plausible. Es si la definición del servicio incluye el componente que le importa al cliente. Una VM puede marcarse como disponible mientras un paquete de software opcional está roto; el acuerdo principal dice explícitamente que el SLA de VM no se extiende a adiciones de software de terceros. Se puede asignar una IP pública mientras una ruta está deteriorada. Un endpoint de inferencia puede ser accesible mientras un modelo externo particular no está disponible.
Los compradores necesitan monitoreo a nivel de componente y un remedio vinculado al impacto comercial, especialmente para trabajos de entrenamiento de larga duración que pueden perder más que los minutos de la interrupción.
La retención y la recuperación están detrás del botón de detener amigable
El botón de detener es central para la propuesta comercial de Intelion. Detener el servidor, detener los cargos de computación, mantener el disco por un período y reanudar más tarde. Para trabajo de IA intermitente, ese es un modelo sensato. Mantiene los aceleradores costosos sin facturar mientras preserva el entorno que tomó tiempo preparar.
El contrato revela las transiciones de estado subyacentes. El cliente puede programar copias de seguridad, incluyendo más de una rutina, pero la disponibilidad de un recurso de copia de seguridad no es lo mismo que la protección automática de cada disco. La página de producto de H100 también trata la copia de seguridad como un servicio que puede agregarse. Por lo tanto, un comprador debe asumir que la protección de recuperación debe seleccionarse, configurarse y probarse a menos que una orden diga lo contrario.
Después de 30 días sin lanzar una VM, Intelion puede eliminar la instancia mientras conserva el disco y lo mueve al almacenamiento en frío. Se promete un aviso al menos 24 horas antes de esa transición. El almacenamiento en frío se mide. Si el saldo de la cuenta llega a cero, comienza una ventana de financiación de 72 horas, después de la cual el disco y sus datos pueden eliminarse sin otro aviso. Esa secuencia hace que el saldo de la cuenta y la entrega de contacto sean parte del diseño de recuperación.
Esto importa para los equipos que utilizan capacidad de GPU en ráfagas. Un entorno de investigación puede permanecer intacto entre experimentos. Un empleado que se ha ido puede ser el único destinatario de los avisos de facturación. Un retraso en la adquisición puede impedir una recarga de saldo durante la ventana de gracia. Ninguno de esos eventos es un fallo del sistema de almacenamiento, sin embargo, cada uno puede terminar en pérdida de datos bajo una regla de retención automatizada.
El remedio es disciplina operativa. Los datos importantes deben existir fuera del ciclo de vida de un único disco medido. Los horarios de copia de seguridad deben verificarse mediante pruebas de restauración. Las alertas de cuenta deben llegar a una dirección operativa compartida. Los umbrales de financiación y eliminación deben monitorizarse a través de un sistema separado cuando sea posible. Un plan de salida debe definir cómo se exportan las imágenes, los datos y los registros de configuración antes de que finalice el servicio.
Los términos públicos de Intelion son valiosos porque muestran el mecanismo de eliminación antes de que un cliente lo descubra. El comprador debe usar esa claridad. El titular tranquilizador explica cómo pausar el costo. El contrato explica cómo no confundir un recurso en pausa con un archivo.
Lo que un comprador debería pedirle a Intelion que pruebe
La evidencia respalda una empresa real, documentos de producto reales y una superficie de enrutamiento público activa. Por lo tanto, una revisión de adquisición puede pasar más allá de los cuestionarios genéricos y solicitar un paquete de prueba compacto y específico del servicio.
Primero, conciliar la identidad. La orden debe nombrar a OOO "Intelion Oblako", sus números de registro e impuesto, la dirección para notificaciones y la marca bajo la cual opera el soporte. Debe indicar si algún afiliado, operador de instalaciones o contratista posee equipos, recursos de dirección o datos del cliente. Los contactos de red y abuso deben estar vinculados al servicio en lugar de dejarse como direcciones de correo electrónico no asignadas.
Segundo, congelar la configuración comprada. Registrar el modelo y la memoria de GPU, CPU, RAM, clase de disco, disposición de dirección pública, límite de ancho de banda de VM, región, imagen operativa, evento de facturación y la regla de sustitución más temprana. Si se requiere un clúster, registrar la topología de interconexión y la prueba utilizada para aceptarlo. Una página de catálogo es demasiado fluida para servir como anexo técnico.
Tercero, solicitar evidencia de red actual. El paquete útil es pequeño: ambos prefijos de origen, autorizaciones de origen de ruta actuales, los sistemas autónomos externos esperados en estados normal y de conmutación por error, una vista de ruta con fecha, entregas de operador físico y un resultado reciente de conmutación por error. Preguntar por qué el sitio nombra a MegaFon y Rostelecom mientras que el objeto de política de RIPE nombra a Rostelecom y SOTEL, y cómo la vista de un vecino colector se ajusta al diseño previsto. Una respuesta puede ser perfectamente ordinaria; aún necesita ser explícita.
Cuarto, construir una matriz de ubicación de datos. Listar discos VM, copias de seguridad, instantáneas, metadatos del plano de control, registros de soporte, documentos de identidad, datos de facturación, contenido de inferencia y metadatos de inferencia. Asignar a cada uno una región, procesador, período de retención, evento de eliminación y método de exportación. Deshabilitar las rutas de modelo internacional donde no estén permitidas. No usar la ubicación de la factura o la dirección IP como proxy.
Quinto, gobernar la automatización privilegiada. Decidir si la clave de soporte de IA puede instalarse por defecto. Exigir una identidad única, alcance limitado, habilitación con límite de tiempo, vista previa de la acción, registro de aprobación, registro de comandos y prueba de revocación. Establecer la ruta de escalada humana para un fallo del agente y dejar claro qué secretos o datos regulados puede encontrar el agente.
Sexto, firmar una matriz de soporte. Poner las horas incluidas, el límite de 30 minutos, el nivel de soporte pagado, los canales de incidentes, los niveles de gravedad, los objetivos de acuse de recibo y la escalada in situ en un solo cronograma. Separar la monitorización de la plataforma de la respuesta al cliente. Nombrar a las personas o roles autorizados para declarar un incidente, aprobar un cambio riesgoso y solicitar una restauración.
Séptimo, probar el SLA y la máquina de estados de retención. Abrir un incidente de prueba y confirmar qué marca de tiempo inicia el reloj. Verificar cómo se solicita la compensación. Detener una VM no crítica, observar avisos, revisar el cobro de almacenamiento en frío y restaurarla. Confirmar que las alertas de saldo bajo llegan al equipo correcto. Restaurar desde una copia de seguridad en un entorno separado y registrar el tiempo y la pérdida de datos.
Octavo, ejecutar un benchmark de carga de trabajo que mida el servicio en lugar del nombre de la GPU. Capturar el tiempo de finalización del trabajo, el rendimiento del almacenamiento, la transferencia de red, la recuperación de fallos, el retraso en la cola y el costo total facturado. Repetirlo después de un cambio de configuración. Los materiales públicos de Intelion no proporcionan rendimiento verificado de forma independiente, por lo que la propia ejecución de aceptación del cliente debe convertirse en la línea base.
Estas solicitudes son proporcionales a la evidencia. No piden a un proveedor joven que finja ser un hiperescalador global. Le piden que muestre que los recursos, rutas, ubicaciones y personas particulares detrás de un contrato pueden entregar lo que el cliente está comprando.
El registro público es útil porque no es perfecto
Intelion Cloud ha cruzado un umbral importante. El nombre ahora se conecta a una empresa rusa registrada, una propuesta de plano de control funcional, términos detallados para el cliente, un sistema autónomo activo, dos rutas actuales válidas por RPKI y un modelo de cuenta y soporte visible. Un comprador puede hacer preguntas informadas porque hay material real para interrogar.
El mismo registro impide un respaldo fácil. La superficie de ruta pública es compacta. El registro de direcciones y el origen de la ruta pertenecen a diferentes organizaciones. Las descripciones de operadores no se alinean perfectamente en el sitio web, la política de RIPE y la vista del colector. La infraestructura rusa no mantiene cada solicitud de inferencia en Rusia. Las frases de soporte del producto son más amplias que el acuerdo base. Una cifra de disponibilidad del 100 por ciento depende de exclusiones, el tiempo del ticket del cliente y un remedio de tiempo de servicio.
Un disco detenido puede eventualmente entrar en una ruta de eliminación impulsada por el saldo.
No son razones para descartar al proveedor. Son la forma real de la decisión. El valor de Intelion provendrá de hacer que la computación costosa sea más fácil de obtener y operar. Su garantía provendrá de mantener los registros detrás de esa conveniencia actuales, reconciliables y procesables cuando algo falla.
La conclusión justa es, por lo tanto, condicional pero no evasiva. Intelion Cloud LTD tiene más sustancia operativa pública que un nombre de nube solo. La tabla de rutas, los contratos y la mecánica del producto respaldan esa afirmación. Si es la plataforma adecuada para una carga de trabajo empresarial particular depende de la siguiente capa de prueba: una configuración fija, una ruta probada, un mapa de datos a nivel de carga de trabajo, acceso privilegiado controlado y una promesa de escalada humana lo suficientemente fuerte para las consecuencias del fallo.