Em resumo
Por volta de 2022-2023, vários fornecedores de videowall apostaram em um futuro gerenciado na nuvem — a configuração do videowall, o roteamento de fontes e, às vezes, o próprio vídeo, tudo passando por um plano de controle SaaS.
Em 2026, essa aposta já tem um veredito claro: o modelo exclusivamente em nuvem foi reprovado na revisão de conformidade em todos os setores regulados em que tentou entrar.
O que sobreviveu — e hoje é a arquitetura padrão — é o modelo híbrido. Este artigo mostra o que vai para a nuvem, o que permanece on-premises e por que essa divisão não é um meio-termo, mas a concepção correta.
Por que o gerenciamento de videowall exclusivamente em nuvem fracassou
A proposta exclusivamente em nuvem era atraente no papel: gerenciar todos os videowalls de todos os sites a partir de um único navegador, distribuir atualizações de forma centralizada e não ter servidor on-premises para manter.
O problema é que um videowall em uma sala de controle, NOC ou SOC exibe conteúdo que os reguladores não permitem que saia do prédio.
Um videowall de NOC mostra a topologia de rede ao vivo e falhas com impacto nos clientes; um de SOC, feeds ao vivo de câmeras de segurança e alertas de SIEM; a sala de controle de uma concessionária, telemetria SCADA de infraestrutura crítica.
Encaminhar qualquer uma dessas informações por uma nuvem de terceiros — ainda que só como sinal de controle que permita inferir os dados subjacentes — desencadeia uma revisão de conformidade que as arquiteturas exclusivamente em nuvem não conseguem superar.
As quatro barreiras de conformidade
- GDPR (UE). Feeds de câmeras ao vivo com pessoas identificáveis são dados pessoais nos termos do artigo 4(1). Tratá-los por um plano de controle hospedado fora da UE — ou por um provedor de nuvem sediado nos EUA, sujeito ao CLOUD Act norte-americano — requer salvaguardas no padrão da decisão Schrems II, que a maioria das instalações não consegue estabelecer.
- FZ-152 e FZ-187 (Rússia). A localização de dados pessoais exige que os dados de cidadãos russos sejam processados em servidores na Rússia. A FZ-187 acrescenta regras para a infraestrutura crítica de informação: energia, transporte, finanças e operações governamentais precisam manter a camada operacional no país e, muitas vezes, em air gap.
- FedRAMP e níveis de impacto do DoD (governo federal dos EUA). Um videowall em uma instalação federal que lida com informações controladas ou classificadas não pode passar por um plano de controle SaaS comercial sem uma autorização que a equipe de aquisição quase nunca obtém.
- BSI C5 (Alemanha). O catálogo federal alemão de critérios de segurança em nuvem estabelece um patamar que a maioria dos planos de controle SaaS de uso geral não atinge, o que empurra as implantações do setor público alemão para arquiteturas on-premises ou de nuvem soberana.
Qualquer um desses regimes basta para desqualificar um videowall exclusivamente em nuvem de uma implantação regulada. Na prática, a maioria dos grandes compradores de salas de controle enfrenta pelo menos um deles.
O padrão híbrido — o que fica onde
A arquitetura híbrida divide o sistema ao longo de uma linha bem definida: o plano de controle pode ficar na nuvem; o plano de dados permanece on-premises. A Mersive formulou essa divisão cedo, e hoje ela é o padrão da categoria.
O que pode ficar na nuvem
- A própria interface de gerenciamento — a aplicação de navegador que o administrador usa para configurar os videowalls, hospedada como aplicação SaaS
- Metadados de configuração — definições de layout, cenas nomeadas, contas de usuário e permissões, catálogos de fontes (o endereço de uma fonte, não o seu conteúdo)
- Telemetria do parque — quais videowalls estão online, versões de software e estado de saúde em todos os sites
- Logs de auditoria — o registro de quem alterou o quê e quando (os metadados das alterações, não o conteúdo exibido)
O que precisa permanecer on-premises
- O próprio vídeo — cada pixel de cada feed de fonte. Streams de câmeras, renderizações de dashboards e sessões KVM nunca saem da rede local
- O compositor — o mecanismo que dispõe as fontes no videowall roda no servidor on-premises, ao lado das telas que ele alimenta
- Ingestão de fontes — endpoints NDI, RTSP, IPMX e KVM se conectam ao servidor on-premises, não a um endpoint na nuvem
- O caminho de contingência (fallback) — se o plano de controle na nuvem ficar inacessível, o servidor on-premises precisa manter o videowall funcionando com a última configuração conhecida. O videowall não pode depender da conectividade com a nuvem para exibir imagens.
O plano de controle na nuvem
O valor que o plano de controle na nuvem realmente entrega, desde que o plano de dados seja mantido corretamente no ambiente local:
- Gerenciamento multissite — uma única interface para o operador de NOC que gerencia videowalls em uma dúzia de instalações
- Distribuição centralizada de configurações — enviar uma nova cena nomeada para todos os sites de uma só vez
- Visibilidade do parque — estado de saúde e de versões em todo o parque, sem acessar cada servidor
A restrição que torna isso seguro: o plano de controle lida com endereços e definições, nunca com conteúdo. Um plano de controle na nuvem que diz “coloque a fonte em 10.20.30.40 na janela 3” está em conformidade.
Um plano de controle na nuvem que retransmite o vídeo de 10.20.30.40 não está. A arquitetura precisa impor essa linha, e não apenas documentá-la.
O plano de vídeo on-premises
O servidor on-premises faz o trabalho que não pode sair do prédio: ingere todas as fontes, executa o compositor, alimenta as telas e mantém uma cópia local completa da configuração, para sobreviver a uma queda da nuvem.
Em uma implantação regulada, o servidor on-premises também é a fronteira do air gap: ele pode operar sem nenhum acesso de saída à internet, com o plano de controle na nuvem simplesmente indisponível e o videowall gerenciado localmente.
Este é o teste para qualquer fornecedor que se diga “híbrido”: desconecte a internet, e o videowall precisa continuar funcionando e ser gerenciável localmente.
Se o videowall se degradar ou a interface de gerenciamento ficar inacessível, a arquitetura é dependente da nuvem, e não híbrida.
KVM no modelo híbrido
O IP-KVM é o caso em que a fronteira on-premises mais importa. Uma sessão KVM é um operador assumindo o controle ao vivo de um computador de origem — o tráfego mais sensível do videowall.
Em uma arquitetura híbrida, a sessão KVM é estritamente on-premises: o plano de controle na nuvem pode saber que existe uma rota KVM e quem está autorizado a usá-la.
Já o tráfego de teclado, vídeo e mouse flui inteiramente pela rede local. Qualquer fornecedor cujo caminho KVM passe pela nuvem não construiu um sistema híbrido em conformidade.
Onde o Craft Wall se encaixa
Por concepção, o Craft Wall prioriza a operação on-premises. O compositor, a ingestão de fontes e a configuração completa rodam em um servidor Linux de prateleira dentro da instalação.
A interface de controle baseada em navegador é servida, por padrão, por esse mesmo servidor on-premises — o que significa que a implantação de base é o caso em air gap, sem nenhuma dependência de nuvem.
Um plano de controle na nuvem é a camada opcional por cima, para compradores que operam vários sites e querem gerenciamento centralizado.
Ele segue a divisão rigorosa descrita acima: somente metadados e gerenciamento, nunca vídeo, com o servidor on-premises totalmente funcional se a camada de nuvem for removida. Em uma implantação regulada, a camada de nuvem simplesmente não é habilitada.
Veja a arquitetura de referência para NOC para o projeto on-premises e o comparativo de oito plataformas para ver como os fornecedores diferem na questão da dependência de nuvem — uma das linhas divisórias mais nítidas da categoria.
Conclusão
O videowall exclusivamente em nuvem foi uma aposta razoável que o ambiente de conformidade inviabilizou.
O modelo híbrido não é uma meia medida — é a arquitetura correta: a nuvem faz aquilo em que a nuvem é boa (gerenciamento multissite, distribuição centralizada) e a camada on-premises faz o que a regulação exige (cada pixel permanece no prédio).
O teste do comprador é simples e físico: desconecte a internet, e o videowall continua funcionando. Se continuar, a arquitetura é híbrida. Se não continuar, é uma arquitetura dependente da nuvem disfarçada de híbrida.
Leia a seguir: a arquitetura de referência para NOC, para o projeto on-premises, e o artigo sobre videowalls aumentados por IA, que explica por que a inferência on-premises segue a mesma lógica de conformidade.
Veja também o comparativo Craft Wall vs Userful, que mostra o contraste de dependência de nuvem em uma avaliação real.
