La apuesta de Amazon por la inteligencia artificial en su nube ha dejado al descubierto algunos riesgos operativos. A mediados de diciembre, Amazon Web Services (AWS) registró una caída prolongada en un sistema interno clave para sus clientes, en un incidente que diversas fuentes vinculan directamente al uso de agentes de IA para tareas de programación y operación.
Lo ocurrido ha reavivado un debate muy vivo en el sector tecnológico europeo: hasta qué punto conviene delegar en asistentes de IA decisiones sensibles en entornos de producción, especialmente cuando hablamos de infraestructuras críticas de nube utilizadas por empresas, administraciones públicas y servicios digitales en todo el mundo.
Una interrupción de 13 horas en plena adopción de agentes de IA
Según han explicado fuentes citadas por medios como Financial Times y Reuters, AWS sufrió a mediados de diciembre una interrupción de alrededor de 13 horas en un sistema utilizado por los clientes para analizar y seguir sus gastos en la nube. Ese servicio, conocido internamente como herramienta de gestión de costes, permite a empresas de todo el mundo —incluidas muchas europeas— controlar en detalle el consumo de recursos en la plataforma.
El origen del problema se sitúa en Kiro, el agente de codificación con IA de AWS. Ingenieros de la compañía permitieron que este sistema, diseñado para ejecutar acciones técnicas de forma autónoma a partir de instrucciones humanas, llevara a cabo una serie de cambios en el entorno de producción, con el objetivo de solucionar una incidencia.
Diversas personas familiarizadas con el asunto sostienen que Kiro, funcionando como agente «autónomo» o agentic, determinó que la mejor forma de resolver el problema era «eliminar y recrear el entorno». Esta decisión desencadenó la caída del sistema de gestión de costes y dejó a los clientes sin acceso normal a esas funciones durante unas 13 horas.
La interrupción afectó a un único servicio localizado en una de las 39 regiones de AWS, concretamente en una de las dos regiones que la compañía mantiene en China continental. Amazon recalca que no se vieron comprometidos servicios de cómputo, almacenamiento, bases de datos ni tecnologías de IA, y que el impacto no se extendió al resto de regiones, incluida Europa. En este caso la afectación quedó vinculada a una de las regiones de AWS concretas.
Más allá de esa limitación geográfica, el incidente ha llamado la atención porque se trata de un servicio de soporte crítico para la gestión financiera de la nube, sobre el que se apoyan clientes empresariales y organizaciones que operan en mercados como España y el conjunto de la Unión Europea.
Versiones enfrentadas: ¿fallo de la IA o error humano?
La interpretación de lo ocurrido no es unánime. Por un lado, varios empleados de AWS citados por Financial Times aseguran que no se trató de un caso aislado. Hablan de al menos dos interrupciones de producción recientes en las que las herramientas de IA de la compañía —Kiro y también Amazon Q Developer— estuvieron en el centro de la cadena de acontecimientos.
Un ejecutivo de alto nivel de AWS llegó a afirmar que «ya hemos visto al menos dos interrupciones de producción» en los últimos meses. Según su relato, los ingenieros permitieron que los agentes de IA resolvieran problemas sin intervención humana directa, algo que consideran que hacía bastante previsible que se produjeran incidentes de este tipo.
Desde esta perspectiva interna más crítica, las herramientas de IA son tratadas como una extensión del operador humano y, en la práctica, heredan sus mismos permisos y capacidad de acción. En los casos investigados, los ingenieros involucrados no necesitaron una segunda aprobación humana para validar los cambios en producción, lo que rompe con el protocolo habitual de control y revisión por pares.
En el otro lado, la compañía defiende una versión muy distinta. Un portavoz de Amazon, en declaraciones por correo electrónico a Reuters y otros medios, insiste en que el incidente fue «breve» y que el origen está en un error del usuario, no en la inteligencia artificial. Habla de controles de acceso mal configurados, que otorgaron permisos excesivos al ingeniero que operaba con Kiro.
«Este breve evento se debió a un error del usuario —concretamente, controles de acceso mal configurados—, no de la IA«, subrayó el representante de AWS. La empresa sostiene que fue una coincidencia que se estuvieran usando herramientas de inteligencia artificial en ese momento y que «el mismo problema podría ocurrir con cualquier herramienta de desarrollo o incluso con una acción manual».
Kiro, Amazon Q Developer y el auge de la programación asistida por IA
El incidente llega en plena expansión de la programación asistida por IA dentro de AWS. Kiro, el sistema implicado, se lanzó en julio como un asistente de desarrollo que va más allá de los típicos «copilotos»: en lugar de limitarse a sugerir fragmentos de código, está pensado para ejecutar tareas complejas a partir de especificaciones técnicas aportadas por los ingenieros.
Amazon ya contaba antes con Amazon Q Developer, un chatbot con IA diseñado para ayudar a escribir, revisar y adaptar código. Empleados de la compañía apuntan que esta otra herramienta habría estado relacionada con un segundo incidente reciente, también vinculado a interrupciones de servicio, aunque en ese caso el impacto no alcanzó a sistemas de atención directa al cliente.
La estrategia de la empresa pasa por integrar de forma masiva estos agentes de IA en el trabajo diario de sus equipos técnicos. De acuerdo con fuentes internas, AWS se ha marcado como objetivo que cerca del 80 % de sus desarrolladores utilicen IA para tareas de programación, al menos una vez a la semana, y vigila de cerca las tasas de adopción.
Esta apuesta no es solo tecnológica, sino también de negocio. AWS genera aproximadamente en torno al 60 % de las ganancias operativas de Amazon, de modo que cualquier avance en productividad y reducción de costes mediante IA se considera clave para mantener su liderazgo frente a otros grandes proveedores de nube —como Microsoft Azure o Google Cloud— que también compiten intensamente en Europa y España.
Sin embargo, estos episodios han reforzado el escepticismo de parte de la plantilla. Algunos empleados cuestionan que las herramientas de IA aporten suficientes beneficios como para compensar los riesgos de operarlas en entornos sensibles, especialmente cuando todavía están en fases relativamente tempranas de madurez.
Medidas de seguridad adicionales y preocupación por la fiabilidad
Pese a restar importancia al papel de la IA, diversas fuentes aseguran que tras la caída de diciembre AWS ha reforzado sus políticas internas de seguridad. Entre las medidas aplicadas estarían la revisión obligatoria por pares para determinados accesos a entornos de producción, la limitación de permisos excesivos y una mayor supervisión de las acciones que los agentes de IA pueden llevar a cabo sin intervención humana explícita.
Estas iniciativas encajan con una preocupación compartida por muchos clientes, incluidos los europeos: hasta dónde es seguro automatizar decisiones críticas en infraestructuras de nube, donde un mal cambio de configuración puede impactar en servicios financieros, comercio electrónico, logística o administración electrónica.
Amazon, por su parte, sostiene que por defecto Kiro solicita siempre autorización antes de actuar, y que el problema concreto del incidente de diciembre se originó en que el ingeniero implicado contaba con «permisos más amplios de lo esperado». Eso encuadraría el suceso, a juicio de la compañía, en la categoría de fallo humano en el diseño de permisos, y no en un comportamiento impredecible de la IA.
En paralelo, AWS insiste en que no ha encontrado evidencia de que los errores sean más frecuentes cuando se usan herramientas de IA que cuando se trabaja con métodos tradicionales. A ojos de la empresa, este tipo de sistemas son simplemente una extensión de los flujos de desarrollo ya existentes, y no un elemento intrínsecamente más inseguro.
Con todo, el choque entre las declaraciones oficiales y los testimonios internos vuelve a poner en el centro la cuestión de la responsabilidad en incidentes provocados por automatización: qué parte corresponde al proveedor de la nube, qué parte al diseño de los permisos y pipelines, y cuál se asume como riesgo tecnológico inherente.
Impacto en clientes y contexto de otras grandes caídas
En este caso concreto, el alcance de la interrupción fue geográficamente acotado a una región de China continental y a un solo servicio de gestión de costes. Amazon subraya que clientes en otras regiones —incluida la infraestructura que la compañía opera en Europa para cumplir con la normativa comunitaria— no se vieron afectados por la caída de diciembre.
La compañía recalca también que los servicios esenciales de cálculo, almacenamiento, bases de datos y las propias plataformas de IA siguieron operando con normalidad. Es decir, no se trató de un apagón general de la nube, sino de una disrupción localizada en una herramienta complementaria, aunque relevante para el control del gasto.
Aun así, el episodio se interpreta a la luz de otras interrupciones previas de mayor magnitud. En octubre se produjo una caída importante en la nube de Amazon que desencadenó disrupciones globales, afectando tanto a servicios propios de la empresa como a aplicaciones muy populares, desde redes sociales hasta plataformas de videojuegos y mensajería.
Este tipo de incidentes recordados por el sector sirven de telón de fondo para valorar la tolerancia de clientes europeos ante fallos en infraestructuras críticas. En un contexto en el que muchas compañías en España y la UE migran sistemas clave a la nube, cada interrupción reabre el debate sobre dependencia tecnológica, resiliencia, planes de contingencia y diversificación de proveedores.
Para los operadores de nube, el desafío pasa por equilibrar la innovación en IA con garantías de estabilidad. La presión por incorporar agentes más autónomos y potentes convive con las exigencias regulatorias y de cumplimiento en mercados como el europeo, donde la futura regulación de la IA y las normas de ciberresiliencia exigirán justificar estas decisiones de diseño y seguridad.
Todo lo ocurrido alrededor de la caída de diciembre en AWS ilustra el punto en el que se encuentra hoy la computación en la nube: una infraestructura ya madura y crítica que empieza a apoyarse en agentes de IA cada vez más capaces, pero que al mismo tiempo debe reforzar sus controles para evitar que la automatización se convierta en un nuevo foco de riesgo. Mientras Amazon defiende que la causa fue un simple error humano y minimiza el impacto del suceso, las versiones internas que vinculan directamente las herramientas de IA con al menos dos interrupciones recientes muestran que la discusión sobre cómo y hasta dónde delegar en estos sistemas está lejos de cerrarse, tanto dentro de la compañía como entre sus clientes en Europa y el resto del mundo.
