El Cisco AI Summit abrió su segunda edición con una idea que marcó el tono del encuentro: la inteligencia artificial ha dejado de ser una promesa futura para convertirse en una fuerza que ya está reescribiendo las reglas de la economía, la empresa y la infraestructura digital.
En su intervención inicial, Chuck Robbins situó el momento actual como un punto de inflexión comparable, e incluso superior en velocidad, a cualquier transición tecnológica previa, subrayando que el verdadero desafío ya no es si la IA es capaz, sino si las organizaciones pueden absorberla con confianza, seguridad y solidez operativa. Jeetu Patel llevó ese diagnóstico un paso más allá al identificar con claridad los límites que empiezan a frenar su despliegue real: una restricción física de infraestructura (potencia, cómputo, red y memoria), un déficit de confianza que convierte la seguridad en condición previa de adopción, y una brecha de datos que obliga a replantear cómo se entrenan y operan los sistemas.
Desde ese marco, el Summit no se planteó como una sucesión de anuncios ni como un debate abstracto sobre modelos, sino como una conversación abierta sobre los condicionantes materiales, sistémicos y organizativos que determinarán qué usos de la IA llegarán a producción y cuáles se quedarán en fase experimental.
Durante 2023 y buena parte de 2024, el debate sobre inteligencia artificial se construyó casi por completo alrededor del modelo: su tamaño, sus capacidades emergentes, sus benchmarks y sus promesas. En el Cisco AI Summit esa conversación no desaparece, pero queda relativizada por una constatación recurrente: en muchas organizaciones ya existe más capacidad de la que realmente se está utilizando. El reto no es seguir ampliando el techo cognitivo, sino convertir esa potencia en algo estable, gobernable y asumible en términos de coste.
Ese cambio de enfoque tiene consecuencias directas para la empresa. Si la IA empieza a integrarse de forma transversal en las aplicaciones, como señaló Matt Garman, deja de tener sentido hablar de proyectos de IA como algo separado del resto del sistema. La inferencia se convierte en una capa permanente de la arquitectura y, con ella, afloran límites que no se resuelven afinando el software. Memoria, energía, interconexión, latencia y ciclos de construcción y operación pasan a condicionar qué puede ponerse en producción y qué no.
Cuando la capacidad sobra, el sistema manda
Kevin Scott, CTO de Microsoft, apuntó a una idea que suele incomodar a quienes miran la IA solo como una carrera de modelos: no estamos cerca del punto de rendimientos decrecientes en la infraestructura que alimenta esta transición. Al mismo tiempo, describió una “capabilities overhang”: los modelos “ya son mucho más potentes” de lo que se está usando en el mundo real.
Esa sobrecapacidad, vista desde dentro de una empresa que vive de plataformas, tiene una lectura práctica: el problema no es solo generar más capacidad, sino convertirla en progreso y no en actividad. Scott lo llevó a un terreno familiar para cualquier directivo que haya sufrido dashboards inflados: “review has become the bottleneck”, dijo sobre el uso de agentes de código, y advirtió contra confundir producción de código con avance real. En otras palabras, si el sistema permite “rociar” código, el cuello de botella se desplaza al control, la revisión y la integración.
Y ahí aparece el giro: la IA, cuando se mueve de piloto a operación, deja de ser una cuestión de “capacidad del modelo” y se convierte en una disciplina de sistemas. Scott insistió en una realidad muy concreta del lado hyperscaler: aunque a veces parezca que el sector está a punto de salir del entorno de escasez, la demanda sigue “explotando”, y cuesta imaginar cómo se puede “ponerse por delante” si construir centros de datos y desplegar potencia sigue siendo tan difícil.
Para ilustrarlo, aportó una cifra que funciona como recordatorio de escala: equipos “muy ambiciosos” en Microsoft que usan agentes de programación están limitados por su atención para gestionar la complejidad… y por un coste de inferencia que rondaría los 150.000 dólares al año. No es una cifra universal, pero sí un indicador de que el salto a “uso intensivo” de IA no es gratuito. Tiene forma de presupuesto, de factura y de capacidad disponible.
Silicio: el cuello de botella no siempre es la GPU
En la intervención de Lip-Bu Tan (Intel), la conversación bajó todavía más al terreno físico. Ante la pregunta de qué limita antes el crecimiento, si energía/refrigeración o capacidad de fabricación, su respuesta fue directa: “el mayor reto” para muchos clientes es la memoria, y no espera solución “hasta 2028”. La frase es relevante por lo que implica: el mercado tiende a pensar en la IA como “cómputo”, pero el cómputo moderno se estrangula por su capacidad de mover datos y sostenerlos cerca del procesador con suficiente ancho de banda.
El diagnóstico de Tan no se quedó en esa capa. Enumeró una cadena de restricciones que, juntas, parecen más un stack industrial que una decisión de IT:
- Cómputo: presión de clientes por más capacidad y un cambio de percepción sobre el papel del CPU en cargas de trabajo.
- Térmica y potencia: en procesadores de alto rendimiento, “a veces hay que bajar los gigahertz” por problemas térmicos; el aire “ya no sirve”, y entran en juego refrigeración líquida, microfluídica o inmersión.
- Interconexión: el paso de cobre a óptica como “nueva ola” para velocidad y latencia.
- Software de clúster: la dificultad de diagnosticar fallos y cuellos en entornos de GPU/CPU agrupadas; “Kubernetes es genial, pero no puedes encontrar el problema real ahí”, dijo, apuntando a una capa de observabilidad y gestión de clúster que todavía no está resuelta.
Este punto, en un evento organizado por Cisco, tiene un subtexto evidente: cuando la red y la observabilidad dejan de ser “infraestructura invisible”, pasan a ser parte de la competitividad, no solo de la seguridad.
Tan, además, dibujó cómo estas fricciones reordenan estrategias industriales. Habló de la necesidad de una foundry estadounidense y de una Intel que intenta operar dos culturas, producto e industria de servicios, con un lenguaje poco habitual en escenarios de IA: “es un negocio de grind”, un negocio de desgaste y confianza, donde hay que probar yields y previsibilidad antes de que un cliente ponga su producto más crítico en tus manos.
También añadió un elemento que conecta infraestructura con geopolítica sin entrar en la sesión dedicada a ello: frente a la idea de que China se quedaría atrás por falta de acceso a herramientas, describió sorpresa por la escala de talento y por una industria capaz de “hacerlo a la manera del pobre” si no tiene las mejores herramientas, además de una ventaja regulatoria en la velocidad de aprobaciones y despliegue de potencia. Esto importa para Europa no por comparación directa con China, sino por la moraleja: la infraestructura es política industrial, permisos, energía y tiempos de obra.
Infraestructura: la especialización promete eficiencia… y exige predecir el futuro
Amin Vahdat (Google), desde el lado de infraestructura, ofreció una lectura complementaria: la ventaja no está solo en tener chips, sino en co-diseñarlos con los usos y en coordinar el stack completo. Presentó el “arma secreta” de Google como la capacidad de trabajar “a través del stack” para resolver el problema final, de forma que TPUs no se diseñan aisladas, sino con entrada de investigación y casos de uso internos.
Pero la idea más operativa para un lector corporativo fue otra: la especialización. Vahdat defendió que ya no es obligatorio vivir en arquitecturas generalistas; se puede especializar por carga de trabajo y lograr mejoras muy grandes, a costa de perder generalidad (no correrías una base de datos en un XPU). Habló de factores del orden de 10x en coste/escala/energía cuando se especializa.
La trampa está en el calendario. Tanto hardware como software tienen “lead times” de 2-3 años. Para especializar de verdad haría falta reducir dramáticamente ese plazo. Vahdat lo llevó al extremo intelectual: si el ciclo bajara a meses, la especialización cambiaría el mundo, pero hoy el paso de idea a escala “sería de 3 años”. Con el ciclo actual, especializar equivale a apostar: hay que predecir qué cargas dominarán dentro de tres años.
Ese dilema es central para directivos que compran IA “como servicio”, porque la especialización se traslada al precio y al acceso. Quien controla hardware especializado controla la curva coste/rendimiento. Y quien no, paga la tarifa del mercado, a menudo sin ver el stack.
Energía: la eficiencia no “ganará el día” tan rápido como se espera
Vahdat también cuestionó una esperanza que se repite en debates de IA: que la eficiencia (del modelo, del hardware, del software) acabará resolviendo la presión energética. Su lectura fue casi un aviso: la velocidad de mejora en eficiencia es espectacular, pero se consume “instantáneamente” porque, a medida que crecen capacidades, se hacen más cosas con ellas.
Aquí, su argumento conecta con el la paradoja de Jevons que apareció en la conversación con AWS: cuando el recurso se abarata o se vuelve más eficiente, aumenta el consumo total porque se abren más usos y más demanda. Lo relevante para un directivo no es el concepto académico, sino su consecuencia: aunque la IA sea más eficiente, eso no garantiza que el consumo baje, porque la organización tenderá a usarla más, más a menudo y en más procesos.
Redes y latencia: de los centros de datos a la idea de espacio
Tanto AWS como Google tocaron un tema que, en un evento de Cisco, adquiere otra lectura: la latencia y la red como parte del diseño, no como un “detalle” de infraestructura.
En Google, la conversación se deslizó hacia “data centers orbitales”. Vahdat enumeró atractivos de primera principios: órbitas con solar 24/7, potenciales ganancias de latencia por no depender de fibra, y hasta la hipótesis de reducción de latencia por “speed of light” si se conectan satélites, además de beneficios de eficiencia. Pero subrayó que hay problemas masivos por resolver: refrigeración, mantenimiento, y un punto crítico, la forma en que desplegamos y mantenemos infraestructura “no escala” al ritmo que se está pidiendo. Recordó que Google pasó de centros de datos de 10 megavatios a hablar de 10 gigavatios, un factor 1.000 que obliga a “reconsiderar cómo haces todo”.
AWS, con un tono más terrestre, llegó a una conclusión parecida desde otro ángulo: “verter hormigón lleva el mismo tiempo”, y la parte física del despliegue es una restricción dura. La idea de centros de datos en el espacio le pareció interesante, pero muy lejana por peso, coste de lanzamiento y ausencia de estructuras permanentes; su “bottleneck” hoy es el transporte a órbita.
Este contraste es útil: el espacio funciona como experimento mental que revela lo mismo que el dato “mundano”: construir infraestructura es lento, y la IA está empujando a pensar en horizontes que la industria del software no suele aceptar.
Cloud: el salto a producción no es “poner un modelo”, es gobernar el despliegue
La intervención de Matt Garman fue probablemente la más pegada a la realidad que sufren las empresas. Su primera respuesta fue casi un diagnóstico de gestión: muchas empresas empezaron con pruebas de concepto sin definir criterios de éxito, como “viaje de aprendizaje”, y luego se preguntan por qué no pasan a producción.
Ilustró ese problema con un caso sanitario: “ambient listening” para automatizar notas clínicas. Un administrador hospitalario celebraba que los médicos ganaran tiempo, pero se frustraba porque “no he ahorrado un solo dólar”. Otro veía valor porque había reducido el riesgo de attrition (con una cifra de referencia del 30% de riesgo de fuga en 12 meses) y por eso escalaba el despliegue. La misma tecnología, dos lecturas distintas porque el KPI era distinto.
Ese ejemplo es más importante de lo que parece: cuando la IA entra en operación, los beneficios se mueven entre productividad, experiencia de empleado, retención, calidad y riesgo. Si solo se mide ahorro inmediato, muchas iniciativas “fallan” aunque estén creando valor en otra línea del P&L o en riesgo futuro.
Garman añadió otro freno que conecta con la pieza 2 de vuestra serie: en flujos agenticos, las empresas temen seguridad, “sprawl” de agentes, identidad y control; y temen cómo escalar desde un piloto, como “compré una instancia EC2 con GPUs” a “quiero desplegarlo globalmente”, con el matiz de que esa GPU en piloto suele estar infrautilizada. El paso de POC a producto exige, en su lenguaje, resolver seguridad, operación y escalado, no solo elegir un modelo.
Cuando habló de “AI-first cloud”, lo aterrizó con una tesis que reconfigura la arquitectura: no habrá aplicaciones “AI” y “no AI”; habrá aplicaciones, y todas llevarán inferencia integrada. Eso implica integrar IA en almacenamiento, VPC, permisos, pruebas y trade-offs entre modelos en producción. Y ahí apareció Bedrock como plataforma que intenta ofrecer “model choice” y seguridad dentro de VPC, junto a un ecosistema de partners que también operan sobre AWS.
En la parte más delicada, Jeetu Patel llevó la conversación a márgenes y chips. Garman fue explícito: tener Trainium mejora margen frente a depender solo de GPUs, aunque no prometió que eso se traduzca en mayor rentabilidad neta; sugirió que AWS tiende a pasar bajadas de precio al cliente para acelerar el “flywheel”. Esto, leído desde empresa usuaria, tiene otra implicación: el hyperscaler invierte en silicio no solo por independencia tecnológica, sino por control de coste y por capacidad de absorber demanda sin dejarla en manos de un único proveedor.
Cuando el debate entró en el terreno de la capacidad real —potencia instalada, disponibilidad de energía, ciclos de construcción y costes operativos— la infraestructura dejó de ser un concepto abstracto para convertirse en el factor que condiciona el despliegue efectivo de la IA.
Garman describió la complejidad de planificar sobre horizontes múltiples: centros de datos con amortización de 20-30 años, servidores de 5-6, red de 6-10, y decisiones de energía a largo plazo. En ese contexto, dijo que el año anterior AWS añadió “casi 4 gigavatios” de nueva capacidad.
También dejó una observación que ayuda a entender por qué el mercado vive en escasez: no han retirado servidores A100 porque siguen “completamente vendidos”, y hay demanda para generaciones previas por razones estructurales (precisión de coma flotante, HPC, tamaños de modelo, etc.). En otras palabras: el ciclo de “obsolescencia” en IA no es tan limpio como parece desde fuera; conviven generaciones porque los requisitos de precisión y coste varían, y porque la demanda supera a la oferta.
La cadena completa: memoria, potencia, red, sistemas, gobierno del despliegue
Si se juntan las cuatro intervenciones, lo que vemos no es una lista de “tendencias”, sino una cadena de dependencias donde cada eslabón puede frenar el despliegue:
- Memoria como factor limitante (Intel) y como preocupación recurrente (Google), con horizonte de alivio incierto y fuerte impacto en coste.
- Energía y refrigeración como disciplina industrial, con transición clara a técnicas avanzadas y con la intuición de que la eficiencia será consumida por el crecimiento de usos.
- Interconexión y latencia, pasando de cobre a óptica y elevando la red a variable de competitividad y fiabilidad.
- Sistemas y operación: review, gobernanza y control, con costes reales de inferencia y un ecosistema aún en construcción para gestionar complejidad.
- Cloud como motor de escalado, pero con fricciones de métricas, seguridad agentica, identidad y productización del POC, además de decisiones de silicio y capacidad con horizontes de décadas.
Qué debería extraer un directivo en España si compra “IA como servicio”
Leído desde la perspectiva de una empresa que consume inteligencia artificial como servicio, el debate sobre infraestructura deja de ser una discusión ajena o reservada a los hyperscalers. Se convierte en una cuestión de gestión cotidiana. La experiencia que describió AWS en el sector sanitario ilustra bien el punto: una misma tecnología puede percibirse como un fracaso o como un éxito según el indicador elegido. Si el único criterio es el ahorro inmediato, iniciativas que reducen rotación, riesgo operativo o desgaste del personal parecen no justificar la inversión. Cuando el KPI se formula de otro modo, la ecuación cambia. Definir qué significa “funcionar” antes de escalar deja de ser una formalidad y pasa a ser una condición para que la IA llegue a producción.
A ese cálculo se suma un coste que rara vez aparece en los titulares: el de operar sistemas intensivos en IA. Kevin Scott puso cifras a una realidad que muchas organizaciones empiezan a descubrir por experiencia propia. La factura no se limita al consumo de cloud. Incluye supervisión humana, revisión, integración con sistemas existentes y control continuo del comportamiento de los modelos. A medida que la inferencia se vuelve permanente, estos costes dejan de ser marginales y pasan a formar parte del presupuesto estructural de IT.
También cambia la naturaleza de la dependencia. No se trata solo de elegir un proveedor de modelos, sino de asegurar acceso a capacidad en un contexto de escasez persistente. Cuando la infraestructura no es abundante, quien puede construir, aprovisionar y operar marca el ritmo. Esa asimetría se traduce en contratos, compromisos de capacidad, acuerdos de nivel de servicio y estrategias de continuidad que condicionan la autonomía real de las empresas usuarias.
Todo ello se ve amplificado por una característica que atraviesa varias intervenciones del Summit: la infraestructura no escala al ritmo del software. Centros de datos, energía, permisos y amortización responden a tiempos industriales. La observación de AWS sobre el hormigón resume bien esa fricción. Por mucho que avance el modelo, hay límites físicos que no se aceleran al mismo compás.
En ese contexto, la red vuelve a ocupar un lugar central. Con interconexión óptica, clústeres distribuidos y arquitecturas híbridas, lo que antes se entendía como transporte de datos pasa a formar parte del propio proceso de ejecución. La latencia, la segmentación y la observabilidad influyen directamente en qué aplicaciones de IA son viables y cuáles no.
La incógnita: ¿quién consigue velocidad sin romper fiabilidad?
Amin Vahdat dijo que lo que más le preocupa “cambia por semanas”, pero volvió una y otra vez a un concepto: velocidad, la capacidad de iterar y desplegar a la escala que se pide. La pregunta de fondo es si el sector conseguirá acelerar ciclos industriales (energía, construcción, supply chain, memoria) sin sacrificar fiabilidad y sin convertir la IA en una capa caótica difícil de gobernar.
Porque el riesgo no es que falte inteligencia en el modelo. El riesgo, más prosaico, es que el stack no aguante el ritmo al que las organizaciones intentan enchufarla.
