El Cisco AI Summit es un foro anual impulsado por Cisco para analizar cómo la inteligencia artificial está pasando de experimento tecnológico a infraestructura empresarial crítica. En su segunda edición, el encuentro reunió a responsables de producto, ingeniería e infraestructura para abordar cuestiones que van desde modelos y agentes hasta geopolítica, trabajo o diseño. Dentro de ese marco amplio, varias intervenciones coincidieron en una tensión concreta que atraviesa hoy a las organizaciones: la nube ha sido clave para escalar la IA, pero también está redefiniendo dónde empiezan y terminan la dependencia, el control y la soberanía operativa.
En el Cisco AI Summit participaron AWS, Microsoft y Google que no dibujaron posiciones enfrentadas, sino planos distintos de una misma realidad. La promesa de flexibilidad del multicloud existe, pero se enfrenta a dos límites persistentes. El primero es organizativo: operar IA en entornos reales exige métricas claras, controles, supervisión humana y gobernanza. El segundo es sistémico y físico: ciclos de hardware, energía, latencia y mantenimiento a escala industrial. El resultado es que moverse entre nubes es técnicamente posible, pero operativamente costoso, y no siempre deseable.
AWS: cuando la nube se encuentra con el “legacy” y con la soberanía
Matt Garman situó buena parte del problema en un terreno poco visible en los discursos de marketing: el peso del código heredado. En plataformas como S3, con grandes bases de código y años de iteraciones, el salto de productividad que ya se observa en tareas sencillas se diluye cuando los sistemas deben mantener garantías estrictas de durabilidad, memoria y fiabilidad. A medida que la IA intenta operar “más abajo en el stack”, la dificultad aumenta. No se trata de generar interfaces o prototipos, sino de actuar dentro de sistemas que no admiten errores ni comportamientos no deterministas.
Esa fricción técnica se cruza con una tensión política que Garman describió de forma explícita. En conversaciones con empresas europeas, la confianza en el proveedor convive con la desconfianza hacia el país en el que opera. La pregunta ya no es solo si la plataforma es segura, sino qué ocurriría ante un conflicto político o una decisión regulatoria extrema. Esa inquietud, más allá de su probabilidad real, condiciona decisiones de arquitectura.
La respuesta que AWS planteó en ese contexto fue la creación de la EU Sovereign Cloud, concebida como una entidad separada, incorporada en la Unión Europea, sujeta a leyes europeas y con gobierno independiente. Garman subrayó aspectos operativos concretos: residencia completa de datos y metadatos en la región, capacidad de operar de forma aislada del backbone global y codiseño con autoridades europeas. La soberanía, en este enfoque, deja de ser un concepto abstracto y se traduce en arquitectura y procesos.
Otro elemento central de su intervención fue la noción de “guardrails”. Para Garman, uno de los principales frenos a la adopción interna de agentes no es la falta de capacidad, sino el miedo a perder control. La autonomía sin límites genera riesgo operativo inmediato. El ejemplo de un agente que estuvo a punto de borrar infraestructura por considerar que era “la vía más rápida” ilustra bien el problema. La velocidad solo se vuelve aceptable cuando existen barandillas claras que delimitan qué puede y qué no puede hacer el sistema.
Microsoft: capacidad disponible, adopción limitada
Kevin Scott abordó el fenómeno desde una perspectiva distinta, centrada en la brecha entre capacidad y uso real. Su diagnóstico fue el del capabilities overhang: los modelos actuales ya ofrecen mucha más potencia de la que la mayoría de organizaciones es capaz de absorber. Donde esa brecha se está cerrando más rápido es en programación, un ámbito en el que el impacto de la IA es inmediato y verificable.
Ese ejemplo sirve para entender por qué la adopción no depende solo de acceso a tecnología, sino de la capacidad de una organización para integrarla en su forma de trabajar. Scott recordó que hace años ya era evidente que las leyes de escalado funcionarían y que los modelos acabarían comportándose como una plataforma sobre la que otros construirían. Desde su perspectiva, uno de los logros de los grandes proveedores ha sido distribuir esa capacidad de forma abierta, accesible mediante APIs, en lugar de concentrarla en un único actor que decida qué se construye y qué no.
Sin embargo, esa apertura convive con un límite claro: la infraestructura sigue siendo un recurso restringido. Cada vez que parece superarse un cuello de botella, la demanda vuelve a crecer. Scott insistió en que la infraestructura permanecerá “constrained” durante un tiempo, y que operar plataformas fiables implica asumir una complejidad constante: mantener sistemas en funcionamiento, entender fallos y evitar que se repitan.
En este contexto, el multicloud no elimina la dependencia, sino que la redistribuye. La capacidad puede estar más abierta, pero sigue gestionándose desde plataformas que asumen la obligación de operar sistemas complejos y fiables a escala.
Google: especialización, latencia y ciclos industriales
llevó la discusión al plano más físico del problema. Su intervención giró en torno al trade-off entre especialización y generalidad. Aceleradores altamente especializados pueden ofrecer mejoras de un orden de magnitud en coste o rendimiento, pero a cambio pierden flexibilidad. No todas las cargas son trasladables, y mucho menos eficientes, en cualquier tipo de hardware.
Ese grado de especialización introduce un problema adicional: el ciclo de diseño. Cuanto más específico es un chip, más necesario resulta anticipar qué cargas dominarán dentro de dos o tres años. Vahdat habló abiertamente de la dificultad de acortar esos ciclos por debajo de los 18 meses y de la necesidad de predecir un futuro que cambia con rapidez.
La referencia a centros de datos en el espacio apareció como un ejercicio de primeros principios, no como una solución inmediata. Orbitar permite acceso constante a energía solar y potenciales mejoras en latencia, pero introduce retos enormes en refrigeración, mantenimiento y operación robótica. Más que una hoja de ruta, funciona como indicador de hasta qué punto la demanda de IA está presionando los límites de la infraestructura terrestre.
El hilo conductor de su intervención fue la velocidad. Energía, cadena de suministro y memoria aparecen como factores que cambian de relevancia casi semana a semana. La escala a la que se está hablando, pasar de decenas de megavatios a gigavatios, obliga a asumir que la infraestructura ya no puede crecer al ritmo del software.
Dependencia como resultado de arquitectura
Leídas en conjunto, las tres intervenciones dibujan una dependencia que no se explica solo por concentración de mercado. Aparece como consecuencia directa de cómo se despliega la IA en producción.
Desde AWS, la fricción surge cuando la IA intenta operar dentro de sistemas heredados y entornos regulados, donde la soberanía y la resiliencia pesan tanto como la eficiencia. Desde Microsoft, la tensión se sitúa en la capacidad de las organizaciones para absorber una potencia que ya está disponible, pero que exige plataformas fiables y complejas. Desde Google, el límite se impone desde la física: especialización, latencia, energía y ciclos industriales.
El multicloud sigue siendo una herramienta útil para repartir riesgo y ganar margen de maniobra. Pero no elimina la dependencia. Cuando la IA se integra en el corazón de los sistemas, esa dependencia se decide menos en los contratos y más en la arquitectura, en los controles operativos y en los límites de una infraestructura que ya no escala al ritmo de las promesas.
