En breve
Hacia 2022-2023, varios fabricantes de videowalls apostaron por un futuro gestionado desde la nube: la configuración del videowall, el enrutamiento de las fuentes y, a veces, el propio vídeo pasaban por un plano de control SaaS.
En 2026 esa apuesta tiene un veredicto claro: el modelo exclusivamente en la nube (cloud-only) no superó la revisión de cumplimiento normativo en ninguno de los sectores regulados en los que intentó implantarse.
Lo que sobrevivió, y lo que hoy es la arquitectura por defecto, es el patrón híbrido.
Este artículo explica qué va a la nube, qué se queda en local (on-premises) y por qué esa división no es una solución de compromiso, sino el diseño correcto.
Por qué fracasó la gestión de videowalls solo en la nube
Sobre el papel, la propuesta exclusivamente en la nube resultaba atractiva: gestionar todos los videowalls de todas las sedes desde un único navegador, distribuir las actualizaciones de forma centralizada y prescindir de servidores locales que mantener.
El problema es que el videowall de una sala de control, de un NOC o de un SOC muestra contenidos que los reguladores no permiten que salgan del edificio.
El videowall de un NOC muestra en directo la topología de red y los datos de averías que afectan a los clientes. El de un SOC muestra en directo las señales de las cámaras de seguridad y las alertas del SIEM.
La sala de control de una empresa de servicios públicos muestra telemetría SCADA de infraestructuras críticas.
Hacer pasar cualquiera de esos datos por una nube de terceros —aunque sea solo como una señal de control que permite inferir los datos subyacentes— desencadena una revisión de cumplimiento que las arquitecturas exclusivamente en la nube no pueden superar.
Las cuatro barreras del cumplimiento normativo
- RGPD / GDPR (UE). Las señales de cámara en directo con personas identificables son datos personales según el artículo 4(1). Tratarlas mediante un plano de control alojado fuera de la UE —o mediante un proveedor de nube con sede en EE. UU. sujeto a la CLOUD Act— exige garantías del nivel de Schrems II que la mayoría de las instalaciones no puede establecer.
- FZ-152 y FZ-187 (Rusia). La localización de los datos personales exige que los datos de los ciudadanos rusos se traten en servidores situados en Rusia. La FZ-187 añade normas sobre la infraestructura crítica de información: la energía, el transporte, las finanzas y las operaciones gubernamentales deben mantener la capa operativa dentro del país y, a menudo, aislada de la red (air-gap).
- FedRAMP y niveles de impacto del DoD (ámbito federal de EE. UU.). Un videowall de una instalación federal que maneje información controlada o clasificada no puede pasar por un plano de control SaaS comercial sin una autorización que el equipo de compras casi nunca obtiene.
- BSI C5 (Alemania). El catálogo federal alemán de criterios de seguridad en la nube fija un listón que la mayoría de los planos de control SaaS de propósito general no alcanza, lo que empuja a los despliegues del sector público alemán hacia diseños locales (on-premises) o de nube soberana.
Basta con cualquiera de ellas para descartar un videowall exclusivamente en la nube en un despliegue regulado. En la práctica, la mayoría de los grandes compradores de salas de control se enfrenta al menos a una.
El patrón híbrido: qué va en cada lugar
La arquitectura híbrida divide el sistema por una línea nítida: el plano de control puede residir en la nube; el plano de datos permanece en local. Mersive formuló esta división muy pronto y hoy es la opción por defecto de la categoría.
Qué puede residir en la nube
- La propia interfaz de gestión — la aplicación de navegador que un administrador usa para configurar los videowalls, alojada como aplicación SaaS
- Metadatos de configuración — definiciones de disposiciones, escenas con nombre, cuentas de usuario y permisos, catálogos de fuentes (la dirección de una fuente, no su contenido)
- Telemetría de la flota — qué videowalls están en línea, versiones de software y estado de salud en todas las sedes
- Registros de auditoría — la constancia de quién cambió qué y cuándo (los metadatos de los cambios, no el contenido mostrado)
Qué debe permanecer en local
- El propio vídeo — cada píxel de cada señal de fuente. Los flujos de cámara, los dashboards renderizados y las sesiones KVM nunca salen de la red local
- El compositor — el motor que dispone las fuentes sobre el videowall se ejecuta en el servidor local, junto a las pantallas que controla
- La ingesta de fuentes — los endpoints NDI, RTSP, IPMX y KVM se conectan al servidor local, no a un endpoint en la nube
- La vía de contingencia — si el plano de control en la nube no está accesible, el servidor local debe mantener el videowall en funcionamiento con su última configuración conocida. El videowall no puede depender de la conectividad con la nube para mostrar imagen.
El plano de control en la nube
El valor que realmente aporta el plano de control en la nube, una vez que el plano de datos se mantiene correctamente en local:
- Gestión multisede — una única interfaz para que un operador de NOC gestione los videowalls de una docena de instalaciones
- Despliegue centralizado de la configuración — enviar una nueva escena con nombre a todas las sedes a la vez
- Visibilidad de la flota — estado de salud y de versiones de todo el parque sin tocar cada servidor
La restricción que lo hace seguro: el plano de control gestiona direcciones y definiciones, nunca contenido. Un plano de control en la nube que ordena «colocar la fuente de 10.20.30.40 en la ventana 3» cumple la normativa.
Un plano de control en la nube que retransmite el vídeo desde 10.20.30.40, no. La arquitectura tiene que imponer esa frontera, no limitarse a documentarla.
El plano de vídeo en local
El servidor local hace el trabajo que no puede salir del edificio: ingiere todas las fuentes, ejecuta el compositor, controla las pantallas y conserva una copia local completa de la configuración, de modo que sobrevive a una caída de la nube.
En un despliegue regulado, el servidor local es también la frontera del air-gap: puede funcionar sin ninguna salida a internet, con el plano de control en la nube simplemente no disponible y el videowall gestionado en local.
Esta es la prueba para cualquier fabricante que se declare «híbrido»: se desconecta internet y el videowall debe seguir funcionando y seguir siendo gestionable en local.
Si el videowall se degrada o la interfaz de gestión deja de estar accesible, la arquitectura es dependiente de la nube, no híbrida.
El KVM en el modelo híbrido
IP-KVM es el caso en el que más importa la frontera local. Una sesión KVM es un operador que toma el control en directo de un equipo de origen: el tráfico más sensible del videowall.
En una arquitectura híbrida, la sesión KVM es estrictamente local: el plano de control en la nube puede saber que existe una ruta KVM y quién está autorizado a usarla.
El tráfico de teclado, vídeo y ratón, en cambio, circula íntegramente por la red local. Cualquier fabricante cuya ruta KVM pase por la nube no ha construido un sistema híbrido conforme a la normativa.
Dónde encaja Craft Wall
Craft Wall es, por diseño, una solución local ante todo (on-prem-first). El compositor, la ingesta de fuentes y la configuración completa se ejecutan en un servidor Linux estándar dentro de la instalación.
La interfaz de control en navegador se sirve por defecto desde ese mismo servidor local, lo que significa que el despliegue de base es el caso aislado de la red (air-gap), sin ninguna dependencia de la nube.
Un plano de control en la nube es la capa opcional superior, para los compradores que operan varias sedes y quieren una gestión centralizada.
Esa capa sigue la división estricta descrita arriba: solo metadatos y gestión, nunca vídeo, y el servidor local sigue siendo plenamente funcional si se retira la capa de nube. En un despliegue regulado, la capa de nube simplemente no se activa.
Consulte la arquitectura de referencia para NOC para el diseño local y la comparativa de ocho plataformas para ver en qué se diferencian los fabricantes en la cuestión de la dependencia de la nube.
Esa cuestión es una de las líneas divisorias más nítidas de la categoría.
Conclusión
El videowall exclusivamente en la nube fue una apuesta razonable que el entorno de cumplimiento normativo acabó liquidando. Lo híbrido no es una solución a medias: es la arquitectura correcta.
La nube hace lo que se le da bien (gestión multisede, despliegue centralizado) y la capa local hace lo que exige la normativa (cada píxel se queda en el edificio).
La prueba del comprador es sencilla y física: se desconecta internet y el videowall sigue funcionando. Si lo hace, la arquitectura es híbrida. Si no, es una arquitectura dependiente de la nube con la etiqueta de híbrida.
Siga leyendo: la arquitectura de referencia para NOC, para el diseño local, y el artículo sobre videowalls aumentados con IA, que explica por qué la inferencia local sigue la misma lógica de cumplimiento.
Para ver el contraste en la dependencia de la nube dentro de una evaluación real, consulte la comparativa Craft Wall frente a Userful.