Modernización de WAN: el ancho de banda no es la solución

04.07.2026

7 min de lectura

Las redes empresariales rara vez fallan por falta de Mbit. Fallan por latencia, control de rutas y SLAs poco claros entre operadores, la nube y las ubicaciones. Quien gestione la próxima licitación basándose principalmente en el precio por Mbit, suele financiar capacidad, pero hereda riesgos operativos de todos modos.

Lo más importante en resumen

La banda ancha como palanca equivocada. Para ERP, voz y flujos de trabajo cercanos a la nube, son decisivos la latencia, el jitter y la estabilidad de la ruta. Los paneles de KPI con disponibilidad y rendimiento ocultan cambios de ruta y el comportamiento de salida de la nube.
Madurez operativa antes que certificaciones. SD-WAN y SASE se miden por la gobernanza de políticas, la observabilidad y el failover bajo carga. Según Gartner, en 2025 seguirá siendo habitual el SASE de doble proveedor con contratos separados.
Métricas compartidas. La latencia por clase de aplicación, jitter, pérdida de paquetes, tiempo de failover y accesibilidad de salida de la nube deben incluirse en el RFP, el SLA y el modelo operativo. El estándar MEF 70.2 define atributos medibles de los servicios SD-WAN.
Gobernanza antes que comparación de funciones. Es prioritario definir las clases de ubicación, los límites operativos y las cláusulas de salida antes de comparar proveedores. La falta de un operador principal y puntos de medición comunes en un entorno multicarrier aumenta la carga en las interfaces.

RelacionadoConstellation Enterprise Intelligence de abril de 2026: Tres observaciones que deben incluirse en cada informe para el consejo de administración / Agilidad empresarial: Scrum en el nivel C fracasa

Por qué los KPIs de banda ancha pura inducen a error

La banda ancha describe teóricamente cuánto tráfico puede transportarse por unidad de tiempo. Dice poco sobre si una aplicación en una ubicación crítica sigue siendo usable bajo carga. Para ERP, voz, vídeo y flujos de trabajo cercanos a la nube, suelen ser decisivos la latencia, el jitter y la estabilidad de la ruta. Un enlace con alta capacidad y priorización poco clara puede tener un rendimiento peor en el día a día que una ruta más estrecha con un control comprensible.

Muchos paneles de KPI informan sobre disponibilidad y rendimiento. Omiten cambios de ruta, picos de carga y el comportamiento de salida de la nube. Precisamente ahí surgen los incidentes que el CIO luego identifica como «problema de red». Si compras y operaciones solo comparan niveles de banda ancha, optimizan una métrica que rara vez es la causa en caso de fallo. La pregunta relevante es qué calidad de servicio se exige contractual y técnicamente bajo escenarios de carga y fallos.

Los KPIs de banda ancha son además fáciles de medir, lo que los hace atractivos para las scorecards. Esto lleva a simplificar la complejidad. Una ubicación con dos rutas y una lógica de failover deficiente sigue siendo arriesgada, aunque ambas rutas sean «suficientemente anchas». Sin medición de rutas de aplicaciones ni una clara asignación de responsabilidades entre el operador y la conexión a la nube, la banda ancha se convierte en un mero número de comodidad.

SD-WAN, SASE y MPLS clásico en funcionamiento real

El MPLS sigue siendo relevante donde priman rutas deterministas, ventanas de latencia ajustadas y procesos operativos establecidos. El precio a pagar son tiempos de implementación más largos, topologías rígidas y, con frecuencia, un punto de acoplamiento estrecho con el operador. Quienes gestionan múltiples ubicaciones y cargas variables en la nube alcanzan sus límites en cuanto cada cambio de política se convierte en un ticket de cambio. El MPLS no resuelve automáticamente cómo gestionar la salida limpia del tráfico en entornos SaaS y de hiperescaladores.

El SD-WAN acerca el control y la visibilidad a la aplicación y a la ubicación. En la práctica real, lo que cuenta no es tanto la etiqueta como la madurez operativa: gobernanza de políticas, ventanas de cambio, observabilidad y la capacidad de conmutar rutas de manera comprensible bajo carga. Sin una línea base clara y sin roles definidos entre los equipos de red, seguridad y soporte del operador, surgen verdades paralelas sobre el mismo incidente. Entonces, el SD-WAN se convierte en una capa adicional que debe explicar por qué se eligió una ruta, en lugar de eliminar la causa raíz.

Los enfoques SASE agrupan funciones de WAN y seguridad, prometiendo una política unificada en el edge y el acceso a la nube. Para los CDO y CIO, el caso operativo es decisivo: ¿quién gestiona la política?, ¿quién visualiza las métricas de extremo a extremo? y ¿quién responde cuando la identidad, el Secure Web Gateway y la selección de rutas están cubiertos por distintos contratos de servicio? Guías de fabricantes como la Cisco SASE Design Guide (versión de septiembre de 2025) y la Cisco SASE/SSE Architecture Guide (versión de enero de 2025) organizan las cuestiones operativas relativas a alta disponibilidad, enrutamiento y detección de redes de confianza. Separando el plano de control y el plano de datos, marcan así los límites de confianza y operación. La guía de diseño mantiene incluso deliberadamente fuera del alcance actual la integración del SD-WAN con Secure Access. El Magic Quadrant for SASE Platforms de Gartner (9 de julio de 2025) señala que los despliegues con dos proveedores siguen siendo comunes en el mercado. La identidad, el Secure Web Gateway y la selección de rutas suelen estar entonces en contratos y líneas de soporte separadas. Una guía arquitectónica ayuda a discutir el objetivo final, pero no sustituye la validación en escenarios reales de carga y cumplimiento.

La verdadera prueba de fuego surge en entornos mixtos de MPLS, acceso a internet y rampas de acceso a la nube. Las aplicaciones no eligen rutas según categorías de revistas. Siguen lo que el DNS, el enrutamiento y la política permiten en cada momento. Quien no refleje esta realidad en el pliego de condiciones terminará comprando soluciones improvisadas más adelante.

Métricas que compras y operaciones deben compartir

Compras necesita criterios comparables. Operaciones requiere control medible. Ambos objetivos solo se logran si las mismas métricas figuran en el RFP, el SLA y el modelo operativo. Entre las más relevantes destacan: latencia de ida y vuelta y unidireccional por clase de aplicación, jitter y pérdida de paquetes bajo carga definida, tiempo de conmutación por fallos incluyendo la convergencia de políticas, disponibilidad de salidas críticas a la nube, así como el tiempo hasta la declaración conjunta de la causa raíz entre el operador y el NOC interno.

La disponibilidad por sí sola es demasiado genérica. Un enlace puede estar «activo» y, sin embargo, inutilizar el servicio de voz. Por eso, los umbrales cercanos a la aplicación deben incluirse en el contrato, no solo el estado del puerto. Igualmente relevante es el método de medición: quién mide, dónde, en qué intervalo, con qué perfil de tráfico y con qué derecho a acceder a los datos en bruto. Sin esta clarificación, el incidente terminará en una disputa sobre la metodología.

La transparencia sobre la selección de rutas y los cambios de política debe incluirse en la misma tabla. Cuando el SD-WAN o el SASE controlan rutas de forma dinámica, debe documentarse qué decisión se aplica bajo qué condiciones y durante cuánto tiempo permanece rastreable. El estándar MEF 70.2 de la Mplify Alliance (antes MEF Forum) define atributos de servicio para servicios SD-WAN. Allí, compradores y proveedores acuerdan propiedades medibles de los flujos de aplicaciones y la demarcación entre suscriptor y proveedor. Deutsche Telekom señala en la descripción del producto Premium Internet Underlay que los SLAs clásicos de rendimiento de internet no suelen incluir métricas de latencia, jitter y pérdida de paquetes. El departamento de compras vincula los créditos de servicio y los tiempos de escalado a las mismas métricas que el equipo de operaciones utiliza en la sala de crisis.

La capacidad sigue siendo parte del conjunto, pero es secundaria a la calidad del servicio bajo carga. Las discusiones presupuestarias se vuelven más honestas cuando los costes de Capex y Opex se vinculan a la calidad medible de las rutas y a los gastos derivados de conexiones redundantes, observabilidad y límites de soporte.

Riesgos de múltiples operadores y cláusulas de salida

Las estrategias de múltiples operadores reducen la dependencia, pero aumentan la carga en las interfaces. Dos operadores implican dos procesos de fallos, dos entornos de portal y, a menudo, dos interpretaciones de la misma cifra de latencia. Sin un rol claro de liderazgo en los incidentes y sin puntos de medición comunes, la ventaja sigue siendo teórica. La diversidad en las capas 1 y 2 aporta poco si ambas rutas pasan por el mismo cuello de botella regional o por la misma entrada a la nube.

Las cláusulas de salida determinan si un cambio de arquitectura será económicamente viable en el futuro. Son clave los plazos de rescisión, los períodos mínimos de permanencia por ubicación, el apoyo en la migración, la exportación de datos y configuraciones, así como los costes del funcionamiento en paralelo durante el cambio. Igualmente relevante es qué ocurre con la asignación de direcciones IP, las clases de QoS y el historial de tickets al cambiar de operador. Si falta esto, el «segundo operador estratégico» se convierte en una solución especial permanente.

Los riesgos contractuales suelen esconderse en detalles de definición. Un «esfuerzo máximo» en el acceso a internet, una responsabilidad poco clara en la nube y la medición de los SLA solo hasta el borde del proveedor trasladan el riesgo en silencio a la empresa. Por ello, el departamento de compras debería exigir matrices de propiedad: operador, gestión de SD-WAN/SASE, proveedor de nube y LAN local. Cada vacío en esta matriz será un punto de escalada posterior. Las pruebas independientes en laboratorio refuerzan los riesgos operativos. En una evaluación de Miercom sobre alta disponibilidad y optimización de rutas en SD-WAN, se observaron diferencias notables entre proveedores en el comportamiento del failover y la dependencia del plano de control. En un sistema comparado, los evaluadores registraron alrededor de diez segundos de interrupción del tráfico durante el failover. El *Gartner Magic Quadrant for SD-WAN* (30 de septiembre de 2024) y el *Magic Quadrant for SASE Platforms* (9 de julio de 2025) ofrecen un mapa del mercado, pero no sustituyen a la matriz de propiedad para la propia operación.

Plantilla de decisión para la próxima licitación

Una plantilla útil comienza con las clases de ubicación y las rutas de aplicación. Los nombres de los productos llegan al final. Las ubicaciones críticas de producción y finanzas requieren requisitos distintos de latencia y failover que las pequeñas oficinas. Las ubicaciones con alta dependencia de la nube necesitan salidas definidas y rutas medibles hacia las regiones relevantes. De ahí se derivan las opciones arquitectónicas: núcleo MPLS, guiado por SD-WAN, integrado en SASE o híbrido.

En un segundo paso, el equipo define los límites operativos: quién modifica las políticas, quién las aprueba, quién ofrece soporte 24/7 y quién gestiona la única fuente de verdad para la telemetría. Paralelamente, el departamento de compras establece la mecánica contractual: métodos de medición, intervalos de reporting, créditos, cláusulas de salida y rutas de migración. Solo entonces se comparan proveedores y operadores. Así, el catálogo de funciones pasa a un segundo plano y el riesgo operativo lidera la decisión.

La plantilla debe separar tres niveles de decisión: idoneidad técnica en el escenario propio, modelo operativo (incluyendo habilidades y herramientas) y riesgos contractuales y de salida. Una solución técnicamente brillante pero operativamente confusa cuesta más al CIO y al CDO que una variante más conservadora con responsabilidades claras. El control del capex se logra cuando el funcionamiento en paralelo, la infraestructura de medición y la sustitución de contratos antiguos figuran como partidas obligatorias en el caso de negocio, y no como sorpresas posteriores.

Para evaluar las ofertas, los tests de escenarios son más útiles que las presentaciones. Laboratorios independientes como Miercom analizan, entre otros aspectos, el fallo del plano de control, el failover de enlaces y los cambios de ruta controlados por SLA ante latencias o jitter violados. Gartner evalúa a los proveedores en las *Critical Capabilities for SD-WAN* y *for SASE Platforms* según casos de uso. Las PoC internas con fallos simulados de ubicaciones, problemas en regiones de nube y conflictos de políticas muestran si los SLA funcionan en el escenario propio.

La conclusión para la estrategia TI y el departamento de compras es clara: la próxima interconexión de ubicaciones es una decisión de gobernanza y contractual, donde la tecnología de red es la capa de ejecución. Quien mantenga el ancho de banda como KPI principal optimiza el factor equivocado. Quien aclare antes las métricas, los riesgos de múltiples operadores y las rutas de salida -antes de comparar funciones- gestiona capex y riesgos operativos de forma conjunta y mantiene la capacidad de acción durante la licitación.

Preguntas frecuentes

¿Cuándo sigue siendo MPLS la opción viable en la interconexión de sedes?

MPLS sigue siendo relevante donde priman rutas deterministas, ventanas de latencia ajustadas y procesos operativos consolidados. El precio a pagar son tiempos de implementación más largos, topologías rígidas y, con frecuencia, una dependencia excesiva del operador. En entornos con múltiples sedes y cargas variables en la nube, este modelo llega a sus límites cuando cada cambio de política se convierte en un ticket de modificación. Paralelamente, la salida ordenada hacia entornos SaaS y de hiperescala debe quedar definida en el diseño operativo y contractual.

¿Cómo evitar disputas metodológicas en incidentes de WAN?

El contrato debe especificar quién mide, en qué intervalo, con qué perfil de tráfico y con qué derecho de acceso a los datos en bruto. Umbrales cercanos al usuario final en latencia, jitter y pérdida de paquetes sustituyen al estado puro del puerto como variable de control. El área de compras vincula los créditos de servicio y los tiempos de escalación a las mismas métricas que el equipo operativo utiliza en la sala de crisis. Sin esta alineación, el incidente termina en una disputa sobre la metodología aplicada.

¿Qué riesgos prácticos conlleva una estrategia multicarrier en incidentes?

Dos operadores implican dos procesos de gestión de incidencias, dos entornos de portal y, a menudo, dos interpretaciones de una misma cifra de latencia. Sin un rol líder en la gestión del incidente y sin puntos de medición comunes, la ventaja de la diversidad queda en un plano teórico. La separación en capas 1 y 2 aporta poco si ambas rutas comparten el mismo cuello de botella regional o la misma rampa de acceso a la nube. Una matriz de ownership que abarque al operador, la operación de SD-WAN o SASE, el proveedor de cloud y la red local cierra estas brechas antes de la puesta en producción.

¿Cómo evalúan compras y operaciones si una solución SD-WAN se adapta al escenario propio?

Las pruebas de escenario y los PoC internos constituyen la base de evaluación antes de analizar catálogos de características o presentaciones. Laboratorios independientes como Miercom verifican el fallo del plano de control, el failover de enlaces y los cambios de ruta basados en SLA ante violaciones de latencia o jitter. En un sistema de comparación, los testers midieron alrededor de diez segundos de interrupción del tráfico durante el failover. Fallos simulados en sedes, problemas en regiones de cloud y conflictos de políticas revelan si los umbrales contractuales son efectivos en el caso real de carga y cumplimiento.

Más para leer en Digital Chiefs

Digital ChiefsReinicio sin modelo de control sigue siendo costoso Digital ChiefsMade for Germany: Cuanto valen realmente 735 mil millones Digital ChiefsEl Chief AI Officer ya está aquí. El problema sigue igual

Más de la red MBF Media