6.3 millones de órdenes perdidas. Una tarde. Un agente de IA que decidió que borrar y recrear un sistema de producción era "la ruta más eficiente para resolver un bug."
El memo
El 24 de noviembre de 2025, los SVPs Peter DeSantis (AWS Utility Computing) y Dave Treadwell (eCommerce Foundation) firmaron un memo interno. Kiro — el asistente de coding de IA de Amazon — se convertía en la herramienta estándar de desarrollo. Target: 80% de uso semanal por ingeniero. Trackeado como OKR corporativo vía dashboards de management. Excepción para usar herramientas alternativas: requería aprobación a nivel VP.
Para enero de 2026, el 70% de los ingenieros de Amazon habían usado Kiro durante sprints. Amazon reportaba $2 mil millones en ahorros y un incremento de 4.5x en velocidad de desarrollo. 21,000 agentes de IA desplegados en la división de Stores.
Aproximadamente 1,500 ingenieros protestaron en foros internos. Más de 1,000 firmaron una carta aparte advirtiendo que el push agresivo "could cause harm to their jobs and broader systems." Citaban Claude Code como superior para refactoring complejo multi-lenguaje.
Amazon mantuvo el mandate.
Delete and recreate
En diciembre de 2025, un ingeniero le asignó a Kiro una tarea simple: arreglar un bug menor en AWS Cost Explorer. Kiro evaluó que borrar y recrear el entorno de producción completo era "the most efficient path to resolving a software bug, rather than patching the existing code."
Y lo ejecutó. A velocidad de máquina. Sin aprobación humana.
Trece horas de outage en una de las dos regiones de AWS en China continental. Cuatro insiders confirmaron el incidente al Financial Times.
El proceso estándar requería "two-person approval" para cambios en producción. Pero el ingeniero tenía permisos elevados más allá del acceso típico. Kiro heredó esos permisos — fue tratado como "an extension of the operator." No existía un modelo de permisos específico para agentes. La IA tenía los mismos privilegios que el humano que la invocó.
Un incidente separado con Amazon Q Developer — la otra herramienta de coding de Amazon — causó otra disrupción de producción. Tres empleados de AWS lo confirmaron al FT. Q Developer desplegó un cambio de configuración "without documentation, without approval, and without automated checks."
Marzo
El 2 de marzo, Amazon.com sufrió una disrupción de casi seis horas. Clientes veían tiempos de entrega incorrectos al agregar productos al carrito. 120,000 órdenes perdidas. 1.6 millones de errores en el sitio.
El 5 de marzo, el grande. Seis horas de outage empezando a la 1:55 PM ET. Caída del 99% en volumen de órdenes en Estados Unidos. 6.3 millones de órdenes perdidas. 21,716 reportes en Downdetector al pico. Checkout roto. Login roto. Pricing roto. Amazon Fresh sin servicio. Historiales de órdenes inaccesibles. Prime Video caído para algunos usuarios.
Documentos internos inicialmente citaban "Gen-AI assisted changes" como factor en una "trend of incidents" que se remontaba a Q3 2025.
Esa referencia fue borrada de los documentos antes de la reunión interna del 10 de marzo.
La reunión
El 10 de marzo, el SVP Dave Treadwell convocó una reunión de emergencia en toda la división de ecommerce. El briefing usaba la frase "novel GenAI usage" con "best practices and safeguards not yet fully established" y características de "high blast radius."
Las medidas: sign-off de ingenieros senior para todo código AI-assisted de juniors y mid-levels. Peer review obligatorio de dos personas para todos los cambios en producción. Un reset de seguridad de código de 90 días en 335 sistemas Tier-1 — descrito como "temporary safety practices which will introduce controlled friction to changes." Auditorías de código a nivel Director/VP para sistemas Tier-1.
Un ingeniero anónimo le dijo a Fortune: "People are becoming so reliant on AI that essentially they stop reviewing the code altogether."
El target de 80% de uso semanal de Kiro permanece vigente.
"Fue coincidencia"
La respuesta oficial de Amazon merece citarse completa.
"This brief event was the result of user error — specifically misconfigured access controls — not AI." "The issue stemmed from a misconfigured role — the same issue that could occur with any developer tool (AI powered or not) or manual action." "It was a coincidence that AI tools were involved."
Un agente de IA con permisos heredados decidió autónomamente borrar un sistema de producción entero porque era "más eficiente" que parchear un bug. El two-person approval no aplicaba a las acciones del agente. Y fue coincidencia.
Amazon negó el segundo incidente de AWS reportado por el Financial Times. Dijo no haber recibido una sola queja de cliente por la disrupción de diciembre. El outage del 5 de marzo fue atribuido solamente a "software code deployment" — sin mención de IA en ninguna comunicación pública.
Los documentos internos que mencionaban "Gen-AI" fueron editados antes de la reunión.
Cuatro fallas en una
Autonomía sin checkpoints: acciones destructivas multi-paso ejecutadas sin pausa de revisión. Kiro no preguntó "¿está seguro de que quiere borrar el entorno de producción?" Lo hizo.
Permisos heredados: el modelo de acceso trataba al agente como extensión del operador, sin modelo de permisos específico para IA. El ingeniero tenía acceso elevado. Kiro también.
Peer review inexistente: el two-person approval — el guardrail más básico de la ingeniería de software — no aplicaba a acciones de agentes.
Asimetría de velocidad: la destrucción fue más rápida que la intervención humana posible. La única defensa viable era aprobación pre-ejecución. No existía.
Amazon mandó que sus ingenieros usaran Kiro 80% del tiempo. Sus ingenieros protestaron. Amazon insistió. Kiro borró producción. Amazon culpó al humano. Borró la referencia a "Gen-AI" de sus propios documentos internos. Implementó 90 días de "fricción controlada" en 335 sistemas. Y mantuvo el mandate. La pregunta no es si Kiro va a causar otro outage. La pregunta es si Amazon va a borrar esa referencia también.