El cuarto trimestre de 2025 fue un trimestre brutal para ser un líder de TI empresarial. Solo en octubre, AWS experimentó una falla en cascada de DNS de 15 horas que cerró 141 servicios y afectó a más de 3500 empresas en 60 países, entre ellas Snapchat, Roblox, Fortnite y sistemas de reservas de aerolíneas.
Azure siguió días después con una falla en la configuración de red en su región Este de EE. UU. 2 que se prolongó durante aproximadamente 50 horas. CloudFlare dejó de funcionar en noviembre debido a un error de software causado por un único cambio de permiso de la base de datos. En 2025 se producirán decenas de miles de interrupciones de SaaS.
Director de Producto y cofundador de APIContext.
Los CIO empresariales que dependen de AWS, GCP, Azure y las docenas de proveedores de nube que se encuentran debajo y alrededor de ellos no deberían tratarlos como anomalías. Deberían considerarlos como un adelanto.
Porque la reciente conversación dentro de Amazon sobre qué tan rápido los ingenieros deberían enviar código generado por IA es un canario en la mina de carbón para cada empresa que ejecuta cargas de trabajo críticas en infraestructura construida por otra persona.
El mandato de codificación de IA ya está aquí
Amazon no está sola. En toda la industria tecnológica, la adopción de herramientas de codificación de IA ha pasado de la experimentación a la anticipación a un ritmo notable. Entre los desarrolladores con sede en EE. UU., el 92 % informa el uso diario de asistentes de codificación de IA.
De las empresas Fortune 500, casi todas han adoptado al menos una plataforma de codificación Vibe. Google reveló que más del 25% de su nuevo código ahora está asistido por IA.
Vale la pena detenerse en ese último número: una fracción significativa del código que se ejecuta en la infraestructura de la nube de Google de la que depende su empresa no está escrita en su totalidad por un ingeniero que lea cada línea.
Para las empresas emergentes que crean herramientas internas, eso probablemente esté bien. Un error tiene un radio de explosión. Para los hiperescalares que sustentan la TI empresarial global, es un cálculo completamente diferente.
El momento de la verdad de AWS es significativo no porque Amazon sea singularmente imprudente, sino porque es la primera vez que la presión interna para realizar envíos más rápidos usando IA se ha filtrado de un importante proveedor de nube de manera documentada y reportada. Todos los principales proveedores de software B2B y de nube están atravesando esta tensión.
El desafío es que cuando estos servicios en la nube fallan, se convierte en su falla operativa, a menudo sin previo aviso y, a veces, incluso sin una actualización de estado oportuna.
Los problemas de confianza acechan en el código generado por IA
Comprender por qué estos problemas requieren comprender una característica no obvia de cómo fallan las herramientas de codificación de IA. Los modelos de lenguaje grandes generan código con la confianza de que es sintácticamente idéntico. Escriben una función de bloqueo distribuida crítica con la misma seguridad que escriben una utilidad de clasificación.
El código parece correcto. A menudo pasa la prueba. Las fallas son combinaciones específicas de condiciones de tiempo específicas, perfiles de carga específicos, condiciones de infraestructura para las cuales nadie pensó en escribir casos de prueba, y el modelo ciertamente no marcó.
No es especulativo.
Los investigadores de seguridad han documentado que el código generado por IA muestra tasas significativamente más altas de clases de vulnerabilidad comunes (desbordamientos de búfer, condiciones de carrera, validación de entrada incorrecta) que el código escrito a mano, no porque los modelos sean descuidados, sino porque aprenden de treinta años de errores humanos acumulados en sus datos de entrenamiento.
La interrupción de CloudFlare en noviembre de 2025, en la que una entrada duplicada en un archivo de administración de bot provocó una falla en cascada, ilustró perfectamente el modo de falla subyacente.
Aunque esto no está clasificado como un problema de codificación de Vibe, el cambio se implementó sin una cobertura adecuada de condiciones de tiempo de ejecución específicas importantes. Los resultados operativos fueron globales. El código de IA facilita la repetición de este patrón de falla exacto con alta frecuencia en más proveedores simultáneamente.
La línea de tendencia ya se mueve en tu contra
Los datos que miden la confiabilidad de las API entre los proveedores de la nube durante los últimos dos años son inequívocos: las cosas están empeorando.
En 2022, el 18% de los servicios en la nube alcanzaron un tiempo de actividad del 99,99%. Para 2023, esta cifra se habrá reducido al 7%. En nuestro análisis reciente de 27 servicios en la nube, ninguno alcanzó los cinco nueves, el estándar histórico de disponibilidad de las telecomunicaciones.
Nuestra investigación en casi 10 000 puntos finales de API y mil millones de llamadas de API estima que la mala calidad de la API ahora cuesta a las organizaciones miles de millones en esfuerzos de desarrollo, antes de contar el impacto de las interrupciones reales en el negocio posterior.
El monitoreo de terceros garantiza la degradación de los datos. El tiempo de inactividad semanal promedio de API aumentó un 60 % entre el primer trimestre de 2024 y el primer trimestre de 2025, de 34 minutos por semana a 55 minutos por semana. El tiempo de actividad promedio de la API cayó del 99,66 % al 99,46 %.
Estas cifras son pequeñas sobre el papel. En la práctica, una caída de 0,2 puntos en el tiempo de actividad en docenas de dependencias de la nube se agrava para las empresas que ejecutan arquitecturas complejas de múltiples proveedores.
Una industria que envía más código, cada vez más rápido, con menos participación humana por línea escrita, mientras mantiene la misma (o reducida) inversión en ingeniería del caos y pruebas de inyección de fallas, creará más fallas de producción. Los datos indican que eso está sucediendo.
La página de estado de su vendedor no es su sistema de advertencia principal
Esta es la parte de la conversación que más importa a los CIO empresariales y es la parte que a menudo se omite en las relaciones con los proveedores.
Cuando se produjo la falla de DNS de AWS en octubre de 2025, los usuarios enviaron más de 4 millones de informes de interrupción en las primeras dos horas.
Las empresas que lo supieron temprano no estaban leyendo el panel de estado de AWS; ya estaban monitoreando sus rutas API críticas desde puntos de vista independientes y activando alertas antes de que AWS reconociera oficialmente el alcance del incidente.
La interrupción de Azure en octubre de 2025 siguió un patrón similar: los usuarios no pudieron informar problemas porque el portal de soporte para informarlos se vio afectado por la interrupción. Las páginas de estado del proveedor constantemente retrasan el evento real por un margen significativo.
El problema básico es que la mayoría de los proveedores requieren intervención humana para actualizar sus páginas de estado. En medio de un incidente importante, los ingenieros que actualizan la página de estado están clasificando el incidente. Lo descubres cuando tienen tiempo de decírtelo, no cuando comienza el problema.
Lo que significa que para los equipos de TI empresariales cuyos SLA, compromisos con los clientes y planes de respuesta a incidentes dependen de conocer rápidamente las interrupciones, confiar en las páginas de estado de los proveedores es una brecha operativa que solo se verá afectada a medida que aumente la frecuencia de las interrupciones.
¿Qué deberían hacer los CIO ahora?
Por lo tanto, sus proveedores de nube, sus proveedores de software y, cada vez más, sus propios equipos internos están enviando más código asistido por IA.
Las prácticas de prueba y validación que detectarán los errores generados por la IA antes de que lleguen a producción no están escalando al mismo ritmo que la velocidad de desarrollo. El grupo de interrupciones del cuarto trimestre de 2025 no es una distracción: es un indicador adelantado.
La respuesta adecuada para los líderes de TI empresariales no es exigir que los proveedores dejen de utilizar herramientas de IA. Ese barco ya zarpó, la economía es muy convincente y, francamente, parte de este código es realmente bueno.
La respuesta adecuada es tratar las relaciones con los proveedores de la nube de la misma manera que un equipo de seguridad maduro trata las cadenas de suministro de software: con el entendimiento de que algo eventualmente saldrá mal y con la infraestructura para detectarlo de forma independiente antes de que ocurra en cascada. Concretamente, esto significa:
Monitoreo de API independiente que se ejecuta desde los puntos estratégicos de sus usuarios, no desde los centros de datos de sus proveedores. Cuando falla la capa DNS de un proveedor de nube, su propio monitoreo interno a menudo falla junto con ella, como sucedió con AWS en octubre de 2025. La observación externa desde diferentes puntos de vista geográficos revela lo que los paneles de control de los proveedores pasan por alto.
Visibilidad de referencia en tiempo real en todas las dependencias de la nube, no solo en su proveedor principal. Las arquitecturas empresariales ahora abarcan AWS, Azure, GCP y docenas de proveedores de SaaS con sus propias dependencias de infraestructura.
Una falla en cualquier parte de esa cadena puede propagarse inesperadamente. Es necesario observar toda la cadena de entrega, no sólo la relación de nivel uno.
Breve demora en la alerta con clasificación automatizada, no con monitoreo manual. El valor de conocer una interrupción diez minutos después de que comienza versus sesenta minutos después de que comienza es enorme: la diferencia entre la comunicación proactiva con el cliente y el control de daños reactivo.
El momento de verdadera conversación en AWS es, finalmente, que se está produciendo una conversación en toda la industria sobre cómo mantener la calidad a medida que se acelera la IA. Los líderes de TI empresarial no pueden esperar a que termine esa conversación.
Tus vendedores eventualmente se darán cuenta. Durante este tiempo, sus sistemas absorberán esa diversidad.
Se avecinan más cortes. La pregunta es si ve a sus clientes antes que ellos.
Hemos presentado las mejores computadoras portátiles para programación.
Este artículo fue producido en parte Perspectiva profesional de TechRadarNuestro canal para mostrar las mejores y más brillantes mentes de la industria tecnológica actual.
Las opiniones expresadas aquí son las del autor y no necesariamente las de TechRadarPro o Future plc. Si está interesado en contribuir, obtenga más información aquí:
