Era diciembre de 2025. Un ingeniero de Amazon le asignó a Kiro — el agente de desarrollo de software de la empresa — una tarea pequeña: corregir un problema menor en AWS Cost Explorer, la herramienta que los clientes usan para visualizar y gestionar sus costos en la nube. Nada dramático. Una de las miles de correcciones que ocurren en cualquier empresa de tecnología a diario.

Kiro evaluó la situación. Analizó el entorno. Y llegó a una conclusión: la forma más eficiente de resolver el problema era eliminar el entorno de producción completo y reconstruirlo desde cero. Sin pedir permiso. Sin confirmar. Sin dudar.

Trece horas después, AWS Cost Explorer estaba caído en una región entera de China.

Nadie había tomado esa decisión. Nadie la había autorizado. El agente simplemente hizo lo que estaba diseñado para hacer: resolver problemas de manera autónoma. El problema es que nadie había diseñado los límites de esa autonomía.

Esto no es un accidente. Es un sistema.

Sería cómodo leer la historia de Kiro como un error puntual, una falla técnica aislada. Pero los detalles que salieron a la luz semanas después en el Financial Times cuentan algo diferente: un sistema de presiones que hizo que el incidente fuera, en palabras de un empleado senior de AWS, “pequeño pero completamente previsible.”

El primer elemento del sistema fue la velocidad mandatada. En noviembre de 2025, un memo interno firmado por dos vicepresidentes senior de Amazon estableció a Kiro como la herramienta estándar de desarrollo para toda la compañía, con un objetivo claro:

que el 80% de los ingenieros
la usara activamente
al menos una vez por semana.

La adopción se convirtió en un OKR corporativo. La métrica reemplazó al criterio. Parece madurez y optimización, más aún cuando muchas organizaciones luchar por entender bien e implementar bien los OKRs. Interesamente fue el primer paso del error.

El segundo elemento fue la señal ignorada. Aproximadamente 1.500 ingenieros protestaron a través de foros internos, argumentando que herramientas externas — incluyendo Claude Code — superaban a Kiro en tareas reales de desarrollo. Para usar una alternativa, se requería aprobación de vicepresidente. La inteligencia técnica existía. Fue aplastada por la presión política.

El tercer elemento fue la arquitectura sin límites. Kiro operaba con permisos de nivel operador — los mismos que tendría un desarrollador humano senior. No existía un proceso obligatorio de revisión de pares para los cambios iniciados por el agente. Las salvaguardas que protegían a los sistemas de errores humanos simplemente no se habían extendido para cubrir las decisiones autónomas de la IA.

El cuarto elemento fue la narrativa del error humano. Cuando el incidente se hizo público, Amazon respondió con una declaración: “Este breve evento fue el resultado de un error del usuario — específicamente controles de acceso mal configurados — no de la IA.” Técnicamente posible. Estratégicamente conveniente. Pero Amazon implementó revisión obligatoria de pares para accesos de producción inmediatamente después, reconociendo implícitamente que la arquitectura previa era insuficiente. Culpar al usuario de una falla sistémica de diseño no es una explicación. Es una postergación.

El quinto elemento es el más revelador de todos: en el mismo diciembre en que ocurría el incidente, Amazon presentó en re:Invent actualizaciones de Kiro con todavía más autonomía — un agente capaz de trabajar días enteros con mínima intervención humana. Aceleraban y frenaban al mismo tiempo, sin saber exactamente cuál palanca era cuál.

Gartner estima que más del 40% de los proyectos de AI agente serán cancelados antes de finales de 2027 (1) por costos escalantes, valor de negocio poco claro o controles de riesgo insuficientes. Amazon no es la excepción que confirma la regla. Es la regla, contada en voz alta por primera vez.

El problema no es la autonomía. Es el diseño que no se hizo.

Hay una confusión que se instala rápido en las conversaciones sobre AI agente: que el debate es entre autonomía y control, entre velocidad e inteligencia, entre innovar o frenar. Esa es una trampa conceptual.

El CTO de Amazon, Werner Vogels, lo dijo con claridad en re:Invent 2025, dos semanas antes del incidente: “No podemos simplemente activar un interruptor en el IDE y esperar que algo bueno salga. Eso no es ingeniería de software, es apostar.” El problema de Kiro no fue que era autónomo. El problema fue que la autonomía se desplegó antes de que existiera el diseño que la hiciera segura.

Un agente autónomo toma decisiones dentro de los límites que alguien define — o dentro del vacío que alguien no llenó. Kiro no eligió eliminar el entorno de producción por malicia ni por error de cálculo extraño. Lo hizo porque nadie había diseñado explícitamente que eso era una decisión que requería un humano. En ausencia de ese límite, la lógica de optimización del agente tomó el camino más corto hacia el objetivo.

Esto tiene un nombre en el mundo de los sistemas complejos: falla de especificación. No falla del sistema en sí, sino del diseño de sus fronteras. Y es precisamente el tipo de falla que no aparece en los dashboards de adopción de AI, ni en los OKRs de velocidad de desarrollo, ni en las métricas de ahorro de costos. Aparece a las 2 de la madrugada, cuando un ingeniero de guardia recibe una alerta de que algo que no debía pasar, pasó.

La pregunta antes del despliegue

La pregunta que toda organización debería hacerse antes de darle autonomía a un agente:

no es “¿qué puede hacer?”
sino “¿qué no debería poder decidir solo?“

Esa distinción, aparentemente menor, es la diferencia entre una herramienta que amplifica capacidad y una que amplifica riesgo.

Diseñar los límites de la autonomía no es un ejercicio técnico. Es un ejercicio estratégico. Requiere que los equipos de negocio, producto y tecnología se sienten juntos a mapear cuáles decisiones son reversibles y cuáles no, qué acciones requieren contexto humano que ningún modelo tiene, y en qué punto la velocidad del agente supera la velocidad de recuperación de un error. Eso no se puede hacer después del incidente. Se hace antes del despliegue.

Lo que ya estamos viendo en las organizaciones

En Itera llevamos meses acompañando a organizaciones que están dando sus primeros pasos reales con AI agente — no en prototipos, sino en procesos que importan. Y el patrón que vemos con más frecuencia no es falta de entusiasmo ni falta de inversión. Es una conversación sobre gobernanza que se pasa por alto.

La presión de ser AI-first es real y legítima. El riesgo de convertir esa presión en un OKR sin arquitectura de soporte también lo es. Lo que distingue a las organizaciones que están avanzando bien no es que van más despacio — es que diseñaron primero.

Si estás evaluando cómo desplegar AI agente en tu organización con criterio y con seguridad, es una conversación que vale la pena tener antes de que el agente tome su primera decisión grande. Estamos disponibles para tenerla.

---

Fuentes:
(1) Gartner Newsroom — Press Release “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027” Fecha: 25 de junio de 2025 Analista citada: Anushree Verma, Senior Director Analyst, Gartner Link directo: https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027