Resumo
- A Intelion Cloud pode ser ancorada a uma sociedade limitada russa registrada em março de 2024, um contrato de serviço público detalhado e registros da organização RIPE no mesmo endereço em Moscou. O rótulo inglês
Intelion Cloud LTDestá, portanto, conectado a uma superfície corporativa e de rede real, embora cada registro ainda tenha seu próprio propósito. - O AS214186 estava totalmente visível para 326 coletores IPv4 do RIPEstat em 15 de julho de 2026, anunciando dois /24s válidos por RPKI. Esta é uma evidência operacional significativa, mas é uma pegada IPv4 compacta com um vizinho observado, nenhum IPv6 observado e blocos de endereços registrados em outra organização, em vez de prova de cada reivindicação de infraestrutura no site.
- A Intelion publica uma história de automação crível em torno de recursos de autoatendimento, OpenStack, redes virtuais, computação medida e um agente de suporte de IA. Os mesmos termos revelam os controles que importam: uma chave de acesso selecionada por padrão, ações aprovadas pelo cliente, limites de VM de um gigabit, inatividade acionada por ticket, opções de backup agendado e retenção dependente de saldo.
- A localidade e o suporte são específicos do serviço. Locais de computação russos não mantêm todas as solicitações de inferência na Rússia, e o texto de suporte público varia de suporte 24 horas a horários contratuais mais restritos. Um comprador precisa de um mapa de dados da carga de trabalho, uma matriz de suporte assinada e evidências atuais da operadora antes de tratar o nome da nuvem como garantia operacional.
Um nome de nuvem é um conjunto de promessas
O erro mais fácil na due diligence de nuvem é perguntar se um provedor é real e parar quando a resposta se torna sim. Um registro corporativo é encontrado. Um site aceita pagamento. Um sistema autônomo aparece em um banco de dados de roteamento. A caixa marcada como identidade é verificada, e todas as outras reivindicações começam a tomar emprestada a confiança dela.
A Intelion Cloud é um caso útil porque o registro público é forte o suficiente para recompensar a investigação e desigual o suficiente para punir atalhos. Este não é um nome de diretório sem produto por trás. A empresa oferece servidores GPU, infraestrutura virtual, máquinas dedicadas e um serviço de inferência. Publica termos legais em Markdown legível, bem como em PDF. Nomeia tecnologias, escolhas de design de rede, canais de suporte, locais de dados e regras de retenção. Seu sistema autônomo está anunciando rotas atualmente. Há material suficiente para entender como um relacionamento com o cliente deve funcionar.
No entanto, os registros não se resumem a um simples certificado de qualidade. O registro da empresa russa estabelece uma contraparte legal. O site descreve um serviço ambicioso. Os documentos do cliente alocam direitos e obrigações. Os registros do RIPE mostram administração de recursos numéricos. Os coletores de rotas mostram quais origens são visíveis em um determinado momento. Uma página de produto descreve o suporte. Nenhuma dessas fontes responde a todas as perguntas feitas pelas outras.
Essa separação não é pedantismo. Ela se mapeia diretamente para a falha. Se um pagamento for contestado, a entidade contratante e o registro de cobrança importam. Se um prefixo desaparecer, o sistema autônomo, a autorização de rota e a escalação com a operadora importam. Se uma solicitação de modelo contiver dados regulamentados, a região de processamento selecionada importa. Se uma máquina virtual parada ficar sem financiamento, a cláusula de retenção importa. Se uma GPU falhar fora do horário comercial, a diferença entre o monitoramento da instalação e o suporte técnico voltado ao cliente importa.
A maneira correta de ler a Intelion Cloud é, portanto, como um sistema operacional feito de várias promessas públicas. Identidade, automação, alcance de rede, localidade, suporte e recuperação são módulos separados. O provedor publicou mais detalhes do que muitas pequenas empresas de infraestrutura. Isso é um sinal positivo porque dá ao comprador algo testável. Também cria a obrigação de reconciliar declarações quando o site, o contrato e a observação externa descrevem arestas diferentes do mesmo serviço.
O julgamento central não é que a Intelion Cloud tenha pouca evidência. É que a evidência disponível muda o trabalho do comprador. A questão não é mais se existe um serviço por trás do nome. A questão é se o serviço específico que um cliente pretende comprar é delimitado com rigor suficiente para que cada promessa importante possa ser atribuída a um registro, um controle e um responsável responsivo.
A âncora corporativa é jovem e específica
A pesquisa do Serviço Fiscal Federal Russo retorna uma empresa para o número fiscal 9703176519: OOO "Intelion Oblako", uma sociedade limitada russa registrada em Moscou em 14 de março de 2024. O resultado fornece OGRN 1247700236519 e identifica Maksim Nikolaevich Vyaznikov como diretor geral. A página Sobre da Intelion publica os mesmos números fiscais e de registro, a mesma jurisdição de Moscou e um endereço na Presnenskaya Embankment. Ela nomeia Vyaznikov como CEO e descreve a atividade principal da empresa como processamento de dados, hospedagem e serviços relacionados.
Esse acordo entre uma pesquisa oficial de empresas e a página legal do provedor é a âncora de identidade mais limpa nas evidências. Ele conecta a marca voltada ao cliente a uma entidade legal capaz de fazer uma oferta pública, faturar clientes e receber notificações. O contrato de usuário repete o OGRN e o número fiscal e diz que o registro, o financiamento ou o uso da conta aceita a oferta. Os termos públicos também definem o painel de controle, o saldo da conta, os documentos eletrônicos e os canais para mensagens legais. Esses detalhes tornam a superfície comercial mais legível do que apenas uma página de marca.
A identidade de rede se junta em um ponto diferente. A organização registrada no RIPE ORG-ICL71-RIPE em setembro de 2024 sob o nome Intelion Cloud LTD e o mesmo endereço de Moscou. Cinco dias depois, o AS214186 foi registrado com o nome INTLMN e a organização Intelion como registrante. O registro do sistema autônomo foi modificado em fevereiro de 2026, enquanto o registro da organização foi alterado novamente em maio. Portanto, o site da empresa, a organização RIPE e o registro do sistema autônomo não são meramente nomes antigos que se assemelham entre si. Eles compartilham um endereço atual, marca e superfície de contato operacional.
Ainda existem limites úteis. A empresa é jovem. A data de registro em março de 2024 não prova que todas as instalações, funcionários ou atividades relacionadas começaram então, e não fornece um longo histórico de desempenho. A organização RIPE usa a representação inglesaLTDenquanto a empresa contratante é a OOO russa "Intelion Oblako". Um e-mail de contato na organização RIPE usa o domíniointelionmine.ru, enquanto a função de abuso usaintelion.cloud. Esse padrão pode refletir um relacionamento administrativo ou o histórico da empresa, mas os registros revisados aqui não definem um grupo corporativo ou transferem responsabilidade de uma marca para outra.
Um comprador deve tornar a junção explícita no pacote contratual. A ordem de serviço, o beneficiário da fatura, os termos de processamento de dados, o contato de abuso e a carta de rede devem identificar a entidade legal e a função que ela está desempenhando. Se equipamentos, acordos de operadora ou equipe de suporte forem fornecidos por afiliadas ou contratados, essas responsabilidades devem ser nomeadas. O registro público fornece um ponto de partida crível. Não deve forçar um cliente a inferir a cadeia legal durante uma interrupção.
A página Sobre também afirma que a Intelion está inscrita no registro de provedores de hospedagem da Rússia e fornece o número de empresa de TI credenciada 73678. Essas são pistas regulatórias relevantes, mas as evidências fixas não contêm um extrato governamental específico da empresa confirmando cada detalhe. A conclusão responsável é que a Intelion afirma publicamente esses status e fornece identificadores para verificação. Eles devem ser verificados em um exercício de procurement, especialmente quando a elegibilidade, o tratamento de dados ou o tratamento fiscal dependerem deles.
A identidade corporativa importa aqui porque o serviço não é meramente software baixável. Um cliente está confiando a uma empresa aceleradores físicos, armazenamento, acesso à rede, fundos de conta e possivelmente solicitações de modelo. Quanto mais forte a automação, mais consequente se torna a âncora legal. Uma conta pode provisionar capacidade em minutos; uma disputa sobre dados excluídos, serviço falho ou uma chave de acesso comprometida ainda se moverá na velocidade de contratos, evidências e pessoas.
O produto é mais legível do que o rótulo de nuvem
A página inicial da Intelion agora faz uma oferta concreta. Ela anuncia servidores GPU na Rússia, cobrança por segundo, a capacidade de parar a computação e parar de pagar por ela, retenção de disco após desligamento, IPv4 público, uma conexão de gigabit e acesso via SSH, VNC ou RDP. Um usuário cria uma conta, financia um saldo, inicia um servidor e se conecta. As cargas de trabalho pretendidas incluem treinamento de modelos, geração de imagem e vídeo, visão computacional, inferência e processamento de fala.
Os documentos subjacentes ampliam essa superfície. O contrato de usuário cobre servidores dedicados, a Plataforma de Nuvem e serviços relacionados. Os termos da Plataforma de Nuvem definem máquinas virtuais, discos virtuais, redes virtuais isoladas, backups, clusters de banco de dados, armazenamento de arquivos, endereços públicos e projetos. Os termos do servidor dedicado descrevem equipamentos físicos de propriedade do provedor montados para o cliente e normalmente fornecidos em 24 horas quando há capacidade.
Os termos da Plataforma de Inferência definem uma API HTTPS para modelos de linguagem ampla e outros modelos de aprendizado de máquina, com solicitações medidas e regiões de processamento explícitas.
Isso não é um produto. São pelo menos três acordos operacionais sob um nome.
O cliente de servidor dedicado recebe uso remoto de uma máquina física e aceita restrições específicas de hardware. O cliente de nuvem cria recursos lógicos em infraestrutura compartilhada e opera seu próprio sistema convidado. O cliente de inferência envia uma solicitação para um endpoint de modelo cujo provedor e região de processamento podem estar fora das próprias instalações da Intelion. O site pode comercializar todos os três como infraestrutura de IA, mas seus modos de falha, evidências e caminhos de dados são diferentes.
Essa distinção melhora o procurement. Um comprador em busca de um A100 para uma execução de treinamento curta deve perguntar sobre alocação de acelerador, persistência de disco, limite de rede, proveniência de imagem e recuperação de falha de host. Uma equipe comprando uma máquina dedicada de longa duração deve focar na substituição de componentes, mão remota, períodos de carência, peças de reposição e tempo de reconstrução. Um aplicativo que chama um endpoint de inferência deve se preocupar com a versão do modelo, registro de solicitações, região, dependência de provedor externo, limites de taxa e aviso de descontinuação.
A palavra nuvem não pode fazer esse trabalho analítico.
O inventário público também é visivelmente dinâmico. A página do H100 dizia que a placa estava indisponível em 15 de julho e direcionava os clientes para uma alternativa A100. Esse pequeno fato é mais útil do que uma alegação perene de ampla capacidade. Lembra aos compradores que um catálogo de produtos descreve o que um provedor deseja oferecer, enquanto um pedido descreve o que está realmente reservado. Para aceleradores escassos, a unidade de due diligence deve ser uma configuração datada: modelo, memória, quantidade, topologia de host, interconexão, classe de armazenamento, região, data de disponibilidade e direitos de substituição.
A Intelion nomeia OpenStack, OVN/Open vSwitch, PostgreSQL, Redis, Celery, NVMe e NUMA entre as tecnologias por trás de sua plataforma. Essa lista é consistente com um plano de controle de nuvem de autoatendimento moderno. Também precisa permanecer o que é: uma pista de arquitetura de primeira parte. Um logotipo de tecnologia não estabelece a versão implantada, estado de patch, isolamento de inquilino, durabilidade de armazenamento ou competência operacional. Essas questões exigem evidências de configuração e testes.
O que o registro público do produto estabelece é um limite substancial o suficiente para examinar. Os clientes não estão apenas sendo solicitados a confiar em um nome. Eles podem ver o modelo de recursos pretendido, limites de rede, base de cobrança, canal de suporte, regras de retenção e remédios de serviço. O próximo passo é entender onde a automação muda o trabalho, em vez de fingir que faz o trabalho desaparecer.
O autoatendimento move o trabalho para políticas e exceções
A parte atraente da oferta da Intelion é a velocidade. Um cliente seleciona recursos, financia uma conta e cria uma máquina através do painel de controle. Os termos dizem que o serviço começa quando um recurso é criado dentro de um projeto e há fundos suficientes. Os clientes escolhem máquinas virtuais, discos e redes, ajustam cotas e operam sistemas convidados remotamente. Os registros de cobrança são gerados a partir das medições do provedor dos serviços consumidos.
Esta é a automação empresarial em uma forma reconhecível. Uma sequência que antes exigia uma solicitação de hardware, uma ordem de compra, uma visita ao rack, uma instalação de sistema operacional e configuração manual de rede se torna uma transação controlada. O cliente recebe capacidade quando necessário e a libera quando a tarefa termina. Para trabalho de GPU intermitente, isso pode mudar tanto o custo quanto a velocidade de experimentação.
Mas o trabalho não desapareceu. Ele se moveu para o design de políticas, gerenciamento de capacidade, medição, segurança de conta, manutenção de imagens, revisão de exceções e recuperação. Alguém deve definir limites de projeto. Alguém deve decidir quais substituições de GPU são aceitáveis. Alguém deve investigar uma discrepância de cobrança. Alguém deve aprovar uma exceção de porta, restaurar uma carga de trabalho com falha ou explicar por que um recurso anunciado está indisponível. A plataforma é eficiente quando essas responsabilidades são explícitas; torna-se opaca quando o painel de controle é tratado como o serviço inteiro.
Os próprios documentos da Intelion revelam vários exemplos. Um host é descrito como conectado a 10 Gbps, compartilhado entre as máquinas virtuais executadas nele, enquanto cada VM é limitada a 1 Gbps. O provedor pode reduzir a largura de banda ou suspender o serviço quando o uso ameaça a infraestrutura compartilhada ou outros clientes. As portas públicas estão sujeitas a bloqueios permanentes, fechamentos padrão e exceções baseadas em solicitação. Os limites de conta e projeto podem ser ajustados, mas a possibilidade técnica e a aprovação do provedor ainda fazem parte do processo.
Esses são controles razoáveis de multilocação. Eles também são onde as expectativas do cliente encontram o critério do operador. Um aplicativo pode ter um endereço IPv4 público e ainda não conseguir usar um protocolo específico. Uma VM pode ter um teto de um gigabit enquanto a página de marketing descreve uma estrutura mais rápida dentro da instalação. Um projeto pode solicitar mais endereços, mas não recebê-los instantaneamente.
Um comprador deve converter cada controle relevante em uma regra operacional antes do lançamento: quem pode solicitar uma exceção, qual evidência é necessária, quanto tempo a aprovação normalmente leva e o que acontece se a solicitação for rejeitada.
A medição merece o mesmo tratamento. A cobrança por segundo é valiosa apenas se os eventos que iniciam, param e preservam recursos forem bem compreendidos. A página inicial diz que parar um servidor interrompe os encargos de computação e mantém o disco gratuito por 30 dias. Os termos de nuvem de julho fornecem a máquina de estados mais completa. Se uma VM não for executada por 30 dias consecutivos, a Intelion pode remover a instância enquanto mantém o disco e movê-lo para armazenamento frio medido após pelo menos 24 horas de aviso.
Se o saldo chegar a zero no armazenamento frio, o cliente tem 72 horas para financiar a conta antes que o provedor possa excluir o disco e seus dados sem outro aviso.
A mensagem de vendas simples e o contrato detalhado não são necessariamente contraditórios. O armazenamento gratuito de disco parado pode cobrir um período inicial, seguido por armazenamento frio pago. Mas a diferença é operacionalmente importante. Um cliente que ouve apenas "pare e não pague" pode projetar um processo de arquivamento que os termos não suportam indefinidamente. A automação tornou a transição de estado fácil; também tornou os alertas de saldo, a entrega de notificações e o monitoramento de retenção parte da proteção de dados.
O plano de controle deve, portanto, ser avaliado como um sistema de registro. O cliente pode exportar histórico de recursos, eventos de uso, alterações de configuração, mensagens de suporte e medições de cobrança? Os timestamps são consistentes? Um administrador pode distinguir uma ação do usuário de uma ação do provedor? Uma máquina parada, um disco frio e um recurso excluído são representados claramente? Os alertas podem alcançar mais de uma pessoa responsável? Esses não são recursos empresariais decorativos. Eles determinam se o cliente pode reconstruir o que aconteceu após um encargo contestado ou uma carga de trabalho perdida.
A Intelion publicou mecânicas suficientes para tornar essas perguntas precisas. Essa é uma vantagem. A tarefa do comprador é verificar se a interface, o contrato e a prática de suporte usam as mesmas definições.
O AS214186 é pequeno, atual e real
A evidência mais forte fora do próprio site da Intelion é o AS214186. O RIPE atribuiu o sistema autônomo em 16 de setembro de 2024, sob o nome INTLMN e registrou-o para Intelion Cloud LTD. O RIPEstat observou pela primeira vez uma rota de origem atual dele em 15 de outubro de 2024. Em 15 de julho de 2026, o sistema foi anunciado e visível para todos os 326 peers IPv4 do RIPE RIS incluídos na resposta.
A pegada era compacta: dois /24s IPv4, 512 endereços no total. O RIPEstat não viu anúncios IPv6 e um sistema autônomo vizinho. Ambos os /24s estavam presentes durante toda a janela de observação de 1 a 15 de julho. Resumos secundários de rotas também relataram dois prefixos IPv4, nenhum IPv6 e um upstream visível, AS12389, PJSC Rostelecom.
Esses fatos importam. Um sistema autônomo ativo dá à Intelion uma identidade de roteamento pública distinta de uma página de revendedor situada inteiramente atrás do espaço de endereço de outro host. A visibilidade total do coletor significa que as duas rotas de origem não eram anúncios obscuros vistos em uma borda. A data da primeira visão segue a alocação do ASN em cerca de um mês, o que é consistente com uma nova rede sendo colocada em operação. O registro também foi mantido em 2026.
Ao mesmo tempo, os números estabelecem um limite em torno da inferência. Dois /24s não provam uma rede geograficamente ampla, grande capacidade, trânsito diversificado, baixa latência ou muitos clientes. Um vizinho observado é uma pista de topologia, não um contrato completo de operadora. Nenhum anúncio IPv6 é uma limitação atual real na visão de roteamento público, mas não diz se o IPv6 existe em redes privadas ou está planejado. A tabela de rotas pode verificar a alcançabilidade na camada de origem. Não pode verificar a GPU, o armazenamento ou o suporte por trás de um endereço.
A ausência de um perfil de rede no PeeringDB para o AS214186 acrescenta pouco por si só. O PeeringDB é voluntário. Um pequeno serviço pode comprar trânsito, usar conexões privadas e operar perfeitamente sem manter uma página de peering pública. O que a ausência significa é que um comprador não pode usar esse diretório para verificar instalações, pontos de troca, escala de tráfego ou política de peering. O provedor deve fornecer evidências de interconexão atuais diretamente se isso for importante para o serviço.
É aqui que a escala deve ser lida honestamente. A superfície de roteamento pública da Intelion não está vazia, dormente ou meramente registrada. Também não é um vasto backbone da internet. Parece a pegada de origem focada de um jovem operador de nuvem: suficiente para anunciar espaço IPv4 voltado ao cliente sob seu próprio ASN, pequeno o suficiente para que cada prefixo e caminho externo importe. Para um comprador empresarial, essa concentração aumenta o valor de evidências exatas de rota, operadora e recuperação.
A autorização de origem não é propriedade do endereço
Ambos os anúncios atuais têm autorizações de origem RPKI válidas para AS214186. O validador do RIPEstat encontrou uma autorização de origem de rota válida para194.67.95.0/24e outra para185.182.108.0/24, cada uma permitindo que o AS214186 origine o /24. Este é um dos melhores detalhes no registro de rede.
A validade do RPKI reduz um risco específico. Redes que realizam validação de origem de rota podem ver que a autorização registrada concorda com o ASN de origem e o comprimento do prefixo da Intelion. Isso torna mais fácil rejeitar uma origem conflitante acidental ou não autorizada. Para uma rede de dois prefixos, manter ambas as autorizações válidas é um controle operacional prático, não um ornamento de conformidade.
Não responde a todas as perguntas de propriedade. Os registros de endereço do RIPE nomeiam RADIO-FSU/RADIO-MSU NETWORK Ltd como registrante para ambos os intervalos. Cada registro contém separadamente uma referência à Intelion: um nomeia Intelion Cloud LTD e vincula o site da empresa, enquanto o outro inclui o domínio. Isso é consistente com a Intelion estar autorizada a usar e anunciar espaço de endereço registrado em outra organização. Não é evidência de que a Intelion possua legalmente os blocos.
Essa distinção se torna importante durante a renovação, resposta a abuso ou migração. A organização que detém o recurso de endereço, a organização autorizada a originá-lo, a operadora que aceita a rota e o cliente que usa um endereço podem ser todos diferentes. Uma rota válida hoje não revela por si só por quanto tempo a Intelion pode usar os prefixos, quem pode alterar a autorização de rota ou o que acontece se o acordo subjacente terminar.
Um cliente que depende de endereços de origem estáveis deve solicitar a cadeia específica do serviço: qual prefixo será atribuído, quem é o titular registrado, qual acordo suporta o uso da Intelion, quem mantém a autorização de origem da rota, se o endereço pode ser movido entre operadoras e qual aviso se aplica se a renumeração se tornar necessária. Para um trabalho de treinamento curto, isso pode ser uma preocupação menor. Para integrações empresariais em lista de permissões, infraestrutura de e-mail ou software licenciado vinculado a um endereço, pode se tornar um risco de migração.
A conclusão positiva continua significativa. A Intelion não está simplesmente anunciando espaço não validado e pedindo que os observadores aceitem o nome. Os dois pares de origem-rota eram válidos na captura. A conclusão cuidadosa é igualmente importante: origem válida é evidência de roteamento autorizado, não uma escritura do bloco de endereços e não uma garantia dos serviços alcançados através dele.
A redundância precisa ser reconciliada uma camada de cada vez
O site da Intelion faz uma afirmação específica de resiliência. Diz que um data center perto de Samara usa linhas de internet MegaFon e Rostelecom fisicamente separadas e anuncia os /24s PI do provedor em ambas, permitindo que o tráfego se mova sem mudança de endereço se uma linha falhar. Esta é uma afirmação muito melhor do que a promessa usual de conectividade redundante porque identifica operadoras, comportamento de roteamento e o resultado esperado de falha.
O registro externo suporta parte dessa história e deixa parte em aberto. O objeto aut-num do RIPE declara política de importação e exportação com AS12389, Rostelecom, e AS21446, SOTEL LLC. O RIPEstat observou um vizinho em 15 de julho. Resumos secundários de rotas identificaram a Rostelecom como o upstream visível. Uma sonda de março de 2026 em Samara também alcançou a rede da Intelion através da Rostelecom. As fontes, portanto, concordam com um caminho atual da Rostelecom. Elas não mostram a MegaFon como vizinha observada na visão global capturada, enquanto a segunda rede declarada no objeto RIPE é SOTEL em vez de MegaFon.
Esta é uma discrepância a investigar, não um veredito. Uma operadora pode fornecer um serviço físico através de outro sistema autônomo. Uma sessão de backup pode não ser visível de todos os coletores, pode estar configurada mas inativa, ou pode ter mudado depois que um registro público foi escrito. Um site também pode simplificar um acordo de atacado em um nome de operadora de varejo. As evidências congeladas não podem determinar qual explicação se aplica.
O comprador deve resistir a duas conclusões igualmente fracas. Uma é que a alegação de operadora dupla deve ser falsa porque um vizinho foi observado. A outra é que dois nomes em um site provam caminhos independentes de ponta a ponta. Diversidade BGP, diversidade física de rota e diversidade comercial de fornecedores são controles diferentes. Duas sessões podem compartilhar um duto, um roteador, uma alimentação de energia ou um domínio de falha upstream. Uma origem visível ainda pode ter um design de espera que funciona conforme planejado.
Evidências atuais devem, portanto, ser solicitadas em cada camada. Uma visão de rota pode mostrar ambas as sessões e os prefixos anunciados sobre elas. Um desenho de topologia pode mostrar equipamentos de handoff e caminhos físicos de entrada. Ordens de operadora podem identificar o serviço contratado. Um registro de failover controlado pode mostrar se o tráfego estabelecido se move, quanto tempo a convergência leva e se os endereços do cliente permanecem estáveis. O histórico de monitoramento pode mostrar perda de pacotes e utilização antes e depois de uma transição.
A rede é compacta o suficiente para que isso seja gerenciável. Existem dois prefixos públicos, duas autorizações RPKI e uma política externa declarada pequena. A Intelion não precisa produzir uma grande narrativa de backbone. Ela precisa mostrar que a redundância específica vendida a um cliente é atual, testada e anexada à instalação e ao serviço no pedido.
A localidade pertence à carga de trabalho, não ao nome da empresa
A Intelion é uma empresa russa que vende servidores descritos como localizados na Rússia. Sua página Sobre marca Moscou, Região de Samara, Região de Tver e Tula como locais de operação e identifica Kemerovo e Cacássia como futuros. A página inicial descreve um data center ativo perto de Samara. Para um cliente em busca de capacidade de computação russa, essas são declarações diretamente relevantes.
Elas não são uma resposta universal de residência de dados. Um endereço legal não é um local de servidor. Um país de sistema autônomo não é um local de disco. Uma rota BGP diz à internet como alcançar um endereço, não onde os dados por trás dele estão armazenados. Mesmo uma lista de instalações não diz qual produto está disponível em qual site ou onde backups, registros do plano de controle, transcrições de suporte e dados de cobrança residem.
A própria estrutura de produto da Intelion torna essa distinção inevitável. Uma máquina virtual e seu disco podem ser colocados na infraestrutura russa do provedor. Um servidor dedicado ocupa um local físico específico. A Plataforma de Inferência pode tomar um caminho muito diferente. Seus termos de maio de 2026 definem duas classes de região de processamento: Rússia para modelos de pesos abertos na própria infraestrutura da Intelion, e Internacional para modelos em nuvem processados através do AWS Bedrock em regiões de Frankfurt ou EUA.
O provedor e a região do modelo selecionado devem estar visíveis no painel de controle e no endpoint da lista de modelos antes que uma solicitação seja enviada.
Essa é uma divulgação útil. Significa que um cliente não precisa fingir que todo endpoint de modelo é local simplesmente porque a fatura vem de um provedor russo. Também significa que o cliente tem que fazer uma escolha arquitetônica ativa. Uma solicitação enviada a um modelo internacional cruza a fronteira russa, e os termos atribuem ao cliente as responsabilidades associadas a essa transferência quando dados pessoais estão presentes.
Os termos de inferência adicionam mais detalhes. A Intelion diz que o conteúdo da solicitação e o gerado não são usados para treinar os modelos e não são retidos após o processamento, exceto para registro técnico de falhas ou requisitos legais. Metadados de uso, incluindo modelo, tempo, contagens de tokens, identificador de chave, identificador de cliente, status e custo, são retidos por três anos. Os clientes têm garantia de acesso a pelo menos 180 dias de seus próprios metadados de uso.
Essas declarações criam um mapa de dados mais útil do que a palavra genérica nuvem, mas permanecem alegações contratuais em vez de um teste independente de cada provedor de modelo.
Um mapa de dados empresarial deve, portanto, seguir a carga de trabalho através de todos os seus estados. Para uma VM, isso inclui a imagem, disco de inicialização, armazenamento anexado, backups, snapshots, logs do host, acesso ao console, artefatos de suporte e estado do recurso excluído. Para uma solicitação de inferência, inclui conteúdo da solicitação, conteúdo gerado, provedor do modelo, região, logs de falha transitórios, metadados de uso e quaisquer logs de aplicativo mantidos pelo cliente. Para administração de conta, inclui documentos de identidade, eventos de cobrança, detalhes de contato e conversas de suporte.
O comprador deve então atribuir uma geografia permitida e uma regra de retenção a cada estado. "Servidores na Rússia" é muito amplo para desempenhar essa função. Um requisito defensável soa mais assim: uma VM, disco e backup nomeados permanecem em um local russo nomeado; o acesso de suporte é registrado; endpoints de modelo internacionais são desabilitados para o projeto; a retenção de metadados é compreendida; e qualquer exceção requer uma mudança autorizada. Isso é soberania de dados como um controle operacional, não um slogan.
Os documentos públicos da Intelion tornam essa conversa possível. Eles também mostram por que a localidade não pode ser inferida do nome da empresa. A mesma conta pode alcançar computação local e infraestrutura de modelo internacional. O campo decisivo é o serviço e a região selecionados para a carga de trabalho.
O agente de suporte de IA cria uma decisão de controle de acesso
A Intelion se descreve como uma nuvem nativa de IA, e a expressão mais concreta dessa ideia aparece nos termos da Plataforma de Nuvem de julho. O provedor diz que oferece um agente de IA de software para ajudar a configurar e manter máquinas virtuais. Durante a criação da máquina, uma chave pública para o agente é controlada por uma caixa de seleção que está marcada por padrão, a menos que o cliente a desmarque. Os termos dizem que os funcionários não usam essa chave, o agente executa apenas ações acordadas com o cliente no chat, e o cliente pode revogar o acesso excluindo a chave.
Isso é mais do que um rótulo de marketing. Transforma o suporte em um fluxo de trabalho de automação privilegiado. O agente pode ser capaz de entrar em uma máquina do cliente e realizar ações que exigiriam um administrador. Se funcionar bem, pode reduzir o trabalho rotineiro de configuração e encurtar a distância entre uma conversa de suporte e uma mudança de configuração. Também pode tornar um erro de suporte mais rápido e mais repetível.
A questão central não é se um agente de IA é seguro no abstrato. É se o limite de acesso é visível e governável para a carga de trabalho do cliente. Uma caixa de seleção marcada por padrão significa que o cliente não deve confiar no consentimento passivo. Uma conta empresarial pode precisar de uma política que desabilite o acesso do agente por padrão e o habilite apenas para um ticket, máquina e janela de tempo específicos. Uma carga de trabalho regulamentada pode proibi-lo inteiramente.
Os termos fornecem um esqueleto útil para esse controle: uma chave distinta, acordo prévio no chat e revogação pelo cliente. Um comprador deve solicitar o resto das evidências. Qual identidade assina a chave do agente? A chave é única por cliente ou máquina? Quais comandos o agente pode executar? Onde a ação proposta é exibida? O cliente pode exigir uma segunda aprovação? Os comandos e saídas são registrados imutavelmente? A revogação fecha sessões ativas? Como erros de modelo, injeção de instruções e contas de suporte comprometidas são tratados? Os segredos podem ser mascarados antes que o contexto seja enviado a qualquer modelo?
Estes não são casos extremos especulativos. O valor comercial do agente vem de sua capacidade de agir. O raio de explosão vem da mesma propriedade. Os termos dizem que as ações são acordadas no chat, mas acordo pode significar qualquer coisa, desde uma prévia clara do comando até uma confirmação vaga de conversa. Um comprador empresarial deve definir o que constitui aprovação e reter o registro necessário para prová-lo.
O agente também muda o trabalho de suporte local em vez de substituí-lo. Alguém deve projetar suas permissões, manter seu software, revisar ações com falha, lidar com exceções e assumir quando a máquina está inacessível. O site da Intelion alega separadamente que um engenheiro no local pode reiniciar via IPMI, substituir um disco ou módulo de memória e lidar com uma GPU com falha. O agente de software e o engenheiro resolvem problemas diferentes. Um atua dentro da máquina lógica; o outro pode tocar em equipamentos físicos. Um modelo de suporte crível explica como o trabalho se move entre eles.
A Intelion merece crédito por colocar a mecânica de acesso do agente em termos públicos. Muitos serviços deixariam tal recurso em uma descrição de produto. A divulgação permite que o comprador faça a pergunta correta: não "a nuvem usa IA?", mas "qual autoridade o agente recebe, e como cada exercício dessa autoridade é aprovado, observado e revertido?"
O suporte está dividido em quatro relógios diferentes
O material público usa várias formas da palavra suporte, e elas não devem ser tratadas como sinônimos.
O primeiro relógio é o monitoramento de infraestrutura. A Intelion diz que coleta flutuações de porta, erros CRC e utilização 24 horas por dia e mantém um engenheiro no local no data center. Isso descreve detecção e intervenção física. É relevante para um switch, disco, módulo de memória ou GPU com falha. Não diz por si só quando uma mensagem será respondida.
O segundo relógio é a disponibilidade na página do produto. A página do H100 diz suporte técnico 24 horas em uma seção, depois exibe suporte sete dias por semana das 09:00 às 21:00, horário de Moscou, perto do cartão do produto. Essas declarações são mais amplas do que o horário comercial comum, mas não idênticas entre si. A página também diz que backup e administração de sistema podem ser serviços adicionais, sugerindo que o escopo da ajuda incluída é tão importante quanto o relógio.
O terceiro relógio é o contrato básico. A seção 13.3 do contrato de usuário de março de 2026 diz que o suporte técnico é fornecido em dias úteis das 09:00 às 18:00 UTC+3 por no máximo 30 minutos por dia; o tempo adicional é cobrado sob uma tarifa separada. As solicitações são aceitas por e-mail ou pela conta oficial do Telegram. A menos que uma ordem de serviço conceda algo mais forte, esta é a descrição pública mais consequente do direito de suporte do cliente.
O quarto relógio é o relógio de disponibilidade do serviço. A disponibilidade da Plataforma de Nuvem é descrita como 24x7x365. Isso diz quando o serviço deve funcionar, não quando um humano deve responder. Uma plataforma pode ter um compromisso de disponibilidade de 24 horas enquanto a mesa de suporte incluída funciona em um horário mais restrito. Esse design pode ser adequado para cargas de trabalho autogerenciadas e não críticas. Pode ser uma lacuna grave para um sistema de produção que precisa de diagnóstico imediato ou intervenção física.
O contraste não é prova de que a Intelion falha em responder fora do horário comercial. É prova de que o comprador não deve inferir um direito a partir de uma frase de produto. O provedor pode vender suporte aprimorado, manter uma escala de plantão operacional ou responder voluntariamente. O contrato público simplesmente não torna todas essas possibilidades parte da promessa básica.
Um cronograma de suporte útil deve nomear gravidade, canal, alvo de reconhecimento, alvo de engajamento técnico, frequência de atualização, objetivo de restauração e proprietário de escalação. Deve distinguir questões de conta de incidentes de infraestrutura, relatórios de abuso, eventos de segurança, solicitações de restauração de dados e administração paga. Também deve afirmar se o limite diário de 30 minutos se aplica durante uma interrupção causada pelo provedor e se um engenheiro no local pode ser acionado diretamente pela mesa de suporte em todos os horários.
O trabalho de suporte local é valioso precisamente porque as falhas de nuvem cruzam camadas. Uma API pode relatar que uma VM está em execução enquanto o convidado está inacessível. Uma rota pode estar globalmente visível enquanto um caminho de armazenamento está parado. Um cliente pode aprovar uma ação do agente que não pode corrigir uma GPU com falha. A organização precisa de alguém que possa correlacionar o estado do plano de controle, a observação da rede, a telemetria do host e o equipamento físico. O registro público mostra peças desse modelo operacional. O contrato precisa conectá-los.
Uma porcentagem perfeita ainda pode deixar uma lacuna prática
A linguagem de disponibilidade da Intelion é excepcionalmente ambiciosa. Os termos da Plataforma de Nuvem de julho afirmam disponibilidade 24x7x365 e 100% de operacionalidade por hora, sujeito a exclusões. Os termos do servidor dedicado afirmam 100% por mês, novamente com exclusões. A Plataforma de Inferência usa 99,5% de disponibilidade mensal e exclui modelos beta junto com falhas especificadas fora do controle da Intelion.
Essas porcentagens não devem ser calculadas como uma média em um número de toda a empresa. Elas se aplicam a diferentes serviços, períodos de medição e cadeias de dependência. Mais importante, a mecânica de remediação determina o que o número faz para um cliente.
Para a Plataforma de Nuvem, o trabalho técnico é excluído do tempo indisponível, incluindo trabalho planejado e não planejado direcionado a manter o equipamento funcionando ou corrigir falhas. A inatividade começa quando o cliente envia uma mensagem através do sistema de tickets e termina quando o trabalho de restauração é concluído. A compensação é tempo extra usando o mesmo serviço, geralmente correspondente ao período indisponível, e o cliente deve solicitá-la. Uma interrupção de mais de cinco minutos, mas menos de uma hora, é tratada como uma hora para compensação.
Essa estrutura cria três consequências práticas. Primeiro, o monitoramento pelo provedor não inicia necessariamente o relógio contratual de inatividade; o ticket do cliente sim. Segundo, a porcentagem principal não é uma medição histórica publicada para revisão externa. É uma promessa calculada sob exclusões definidas. Terceiro, a remediação é tempo de serviço, não necessariamente compensação pela perda consequencial do cliente, tempo da equipe ou carga de trabalho com falha.
Nada disso torna o SLA sem sentido. Um relógio claro, uma unidade mínima de compensação de uma hora e uma meta de 100% dão ao cliente um caminho contratual para uma remediação. Mas o arranjo recompensa clientes que monitoram de forma independente e abrem tickets prontamente. Uma equipe que assume que o monitoramento 24 horas do provedor cria automaticamente uma reivindicação pode descobrir que seu próprio timestamp de notificação é a evidência importante.
Os termos de nuvem também contêm uma cláusula incompleta onde o operador de comunicações e os detalhes do contrato deveriam ser identificados. Essa lacuna de redação fica ao lado das alegações mais específicas de operadora no site. Não apaga as rotas ou circuitos. Enfraquece a capacidade do contrato de identificar a dependência de rede sem contexto externo. Um cliente deve ter esse campo preenchido na ordem de serviço ou em um cronograma técnico anexo.
O teste certo não é se 100% parece plausível. É se a definição de serviço inclui o componente que o cliente se importa. Uma VM pode ser marcada como disponível enquanto um pacote de software opcional está quebrado; o acordo principal diz explicitamente que o SLA da VM não se estende a adições de software de terceiros. Um IP público pode ser alocado enquanto uma rota está prejudicada. Um endpoint de inferência pode estar acessível enquanto um modelo externo específico está indisponível.
Os compradores precisam de monitoramento em nível de componente e uma remediação vinculada ao impacto nos negócios, especialmente para trabalhos de treinamento de longa duração que podem perder mais do que os minutos da interrupção.
Retenção e recuperação estão por trás do botão amigável de parar
O botão de parar é central para a proposta comercial da Intelion. Pare o servidor, pare os encargos de computação, mantenha o disco por um período e retome depois. Para trabalho de IA intermitente, este é um modelo sensato. Mantém aceleradores caros sem cobrança enquanto preserva o ambiente que levou tempo para preparar.
O contrato revela as transições de estado por baixo dele. O cliente pode agendar backups, incluindo mais de uma rotina, mas a disponibilidade de um recurso de backup não é o mesmo que proteção automática de cada disco. A página do produto H100 também trata o backup como um serviço que pode ser adicionado. Portanto, um comprador deve assumir que a proteção de recuperação deve ser selecionada, configurada e testada, a menos que um pedido diga o contrário.
Após 30 dias sem inicialização da VM, a Intelion pode remover a instância enquanto mantém o disco e o move para armazenamento frio. O aviso é prometido com pelo menos 24 horas de antecedência antes dessa transição. O armazenamento frio é medido. Se o saldo da conta chegar a zero, uma janela de financiamento de 72 horas começa, após a qual o disco e seus dados podem ser excluídos sem outro aviso. Essa sequência torna o saldo da conta e a entrega de contato parte do design de recuperação.
Isso importa para equipes que usam capacidade de GPU em rajadas. Um ambiente de pesquisa pode ficar intocado entre experimentos. Um funcionário que saiu pode ser o único destinatário de avisos de cobrança. Um atraso no procurement pode impedir uma recarga de saldo durante a janela de carência. Nenhum desses eventos é uma falha do sistema de armazenamento, mas cada um pode resultar em perda de dados sob uma regra de retenção automatizada.
O remédio é a disciplina operacional. Dados importantes devem existir fora do ciclo de vida de um único disco medido. Os cronogramas de backup devem ser verificados por testes de restauração. Os alertas de conta devem alcançar um endereço operacional compartilhado. Os limites de financiamento e exclusão devem ser monitorados através de um sistema separado quando possível. Um plano de saída deve definir como imagens, dados e registros de configuração são exportados antes do término do serviço.
Os termos públicos da Intelion são valiosos porque mostram o mecanismo de exclusão antes que um cliente o descubra. O comprador deve usar essa clareza. O título reconfortante explica como pausar o custo. O contrato explica como não confundir um recurso pausado com um arquivo.
O que um comprador deve pedir à Intelion para provar
As evidências suportam uma empresa real, documentos de produto reais e uma superfície de roteamento pública ativa. Uma revisão de procurement pode, portanto, passar de questionários genéricos e solicitar um pacote de prova compacto e específico do serviço.
Primeiro, reconciliar a identidade. O pedido deve nomear a OOO "Intelion Oblako", seus números de registro e fiscais, o endereço para avisos e a marca sob a qual o suporte opera. Deve afirmar se alguma afiliada, operador de instalação ou contratado detém equipamentos, recursos de endereço ou dados do cliente. Os contatos de rede e abuso devem ser vinculados ao serviço, em vez de deixados como endereços de e-mail não atribuídos.
Segundo, congelar a configuração adquirida. Registre o modelo e a memória da GPU, CPU, RAM, classe de disco, arranjo de endereço público, limite de largura de banda da VM, região, imagem do sistema operacional, evento de cobrança e regra de substituição mais antiga. Se um cluster for necessário, registre a topologia de interconexão e o teste usado para aceitá-lo. Uma página de catálogo é muito fluida para servir como cronograma técnico.
Terceiro, solicitar evidências de rede atuais. O pacote útil é pequeno: ambos os prefixos de origem, autorizações de origem de rota atuais, os sistemas autônomos externos esperados em estados normal e de failover, uma visão de rota com data, handoffs físicos de operadora e um resultado recente de failover. Pergunte por que o site nomeia MegaFon e Rostelecom enquanto o objeto de política RIPE nomeia Rostelecom e SOTEL, e como a visão do coletor de um vizinho se encaixa no design pretendido. Uma resposta pode ser perfeitamente comum; ainda precisa ser explícita.
Quarto, construir uma matriz de localização de dados. Liste discos de VM, backups, snapshots, metadados do plano de controle, registros de suporte, documentos de identidade, dados de cobrança, conteúdo de inferência e metadados de inferência. Atribua a cada um uma região, processador, período de retenção, evento de exclusão e método de exportação. Desabilite rotas de modelo internacional onde não são permitidas. Não use a localização da fatura ou do endereço IP como proxy.
Quinto, governar a automação privilegiada. Decida se a chave de suporte de IA pode ser instalada por padrão. Exija uma identidade única, escopo estreito, habilitação limitada no tempo, pré-visualização da ação, registro de aprovação, log de comando e teste de revogação. Estabeleça o caminho de escalação humana para uma falha do agente e deixe claro quais segredos ou dados regulamentados o agente pode encontrar.
Sexto, assinar uma matriz de suporte. Coloque as horas incluídas, limite de 30 minutos, nível de suporte pago, canais de incidente, níveis de gravidade, alvos de reconhecimento e escalação no local em um cronograma. Separe o monitoramento da plataforma da resposta ao cliente. Nomeie as pessoas ou funções autorizadas a declarar um incidente, aprovar uma mudança arriscada e solicitar uma restauração.
Sétimo, testar a máquina de estados do SLA e retenção. Abra um incidente de teste e confirme qual timestamp inicia o relógio. Verifique como a compensação é solicitada. Pare uma VM não crítica, observe os avisos, revise a cobrança de armazenamento frio e restaure-a. Confirme que alertas de saldo baixo alcançam a equipe correta. Restaure a partir de um backup em um ambiente separado e registre o tempo e a perda de dados.
Oitavo, executar um benchmark de carga de trabalho que mede o serviço em vez do nome da GPU. Capture o tempo de conclusão do trabalho, a taxa de transferência de armazenamento, a transferência de rede, a recuperação de falhas, o atraso na fila e o custo total faturado. Repita após uma mudança de configuração. Os materiais públicos da Intelion não fornecem desempenho verificado independentemente, portanto, a execução de aceitação do próprio cliente deve se tornar a linha de base.
Essas solicitações são proporcionais às evidências. Elas não pedem a um jovem provedor que finja ser um hyperscaler global. Elas pedem que ele mostre que os recursos, caminhos, locais e pessoas específicos por trás de um contrato podem entregar o que o cliente está comprando.
O registro público é útil porque não é contínuo
A Intelion Cloud cruzou um limiar importante. O nome agora se conecta a uma empresa russa registrada, uma proposta de plano de controle funcional, termos detalhados para o cliente, um sistema autônomo ativo, duas rotas válidas por RPKI atuais e um modelo visível de conta e suporte. Um comprador pode fazer perguntas informadas porque há material real para interrogar.
O mesmo registro impede um endosso fácil. A superfície de roteamento pública é compacta. O registro de endereço e a origem da rota pertencem a organizações diferentes. As descrições da operadora não se alinham perfeitamente entre o site, a política RIPE e a visão do coletor. A infraestrutura russa não mantém todas as solicitações de inferência na Rússia. As frases de suporte do produto são mais amplas do que o contrato básico. Um número de disponibilidade de 100% depende de exclusões, tempo do ticket do cliente e uma remediação baseada em tempo de serviço.
Um disco parado pode eventualmente entrar em um caminho de exclusão impulsionado pelo saldo.
Essas não são razões para descartar o provedor. Elas são a forma real da decisão. O valor da Intelion virá de tornar a computação cara mais fácil de obter e operar. Sua garantia virá de manter os registros por trás dessa conveniência atuais, reconciliáveis e acionáveis quando algo falhar.
A conclusão justa é, portanto, condicional, mas não evasiva. A Intelion Cloud LTD tem mais substância operacional pública do que apenas um nome de nuvem. A tabela de rotas, os contratos e a mecânica do produto suportam essa afirmação. Se é a plataforma certa para uma carga de trabalho empresarial específica depende da próxima camada de prova: uma configuração fixa, um caminho testado, um mapa de dados em nível de carga de trabalho, acesso privilegiado controlado e uma promessa de escalação humana forte o suficiente para as consequências de uma falha.