Amazon decidió endurecer los controles sobre el uso de inteligencia artificial para programar después de detectar varios incidentes y caídas en sus sistemas. La empresa convocó a una reunión obligatoria con ingenieros para revisar el problema y, como medida inmediata, resolvió que los cambios de software hechos con ayuda de IA por perfiles junior o de nivel medio ya no podrán avanzar sin la aprobación de un ingeniero senior. Si bien el hecho es que Amazon empezó a ver riesgos operativos en cambios técnicos asistidos por inteligencia artificial, entre el público la noticia se leyó como que “la IA tomó el control”.
Según material interno citado por el Financial Times, dentro de Amazon existe preocupación por una “tendencia de incidentes” recientes con “high blast radius”. Esta expresión se usa cuando un error no queda aislado y termina impactando una parte grande del sistema. En ese mismo documento aparecían como factores contribuyentes los cambios asistidos por IA generativa y el uso de herramientas para las que todavía no están del todo definidas las mejores prácticas y salvaguardas. Amazon, de todos modos, sostuvo públicamente que esta revisión forma parte de su operación normal y de su proceso de mejora continua.
La IA generativa y su rol en la programación industrial
En sus comienzos, las herramientas de IA generativa servían para sugerir líneas de código como un autocompletado avanzado. Pero ahora algunas también pueden actuar como agentes de software, interpretando una instrucción, modificando archivos, ejecutando tareas y disparando acciones en cadena dentro del entorno de desarrollo. Kiro, la herramienta mencionada en los reportes sobre Amazon Web Services (AWS), se presenta como un sistema de desarrollo agentic y explica que sus agentes pueden activarse por eventos y ejecutar tareas en segundo plano de manera autónoma según instrucciones predefinidas.
En ese contexto, en diciembre AWS sufrió una interrupción de 13 horas en una herramienta de gestión de costos después de que ingenieros permitieran a Kiro realizar cambios y el sistema optara por “borrar y recrear el entorno”. Días después, además, Amazon sufrió otra caída de varias horas vinculada a un despliegue erróneo de código, que afectó funciones como el checkout, los precios y el acceso a cuentas.
Sin embargo, Amazon rechaza la lectura más alarmista de ese episodio. Al respecto, la compañía dijo que el evento fue “extremadamente limitado”, que afectó a un solo servicio en una de sus regiones y que la causa fue un rol mal configurado. Este problema, según remarcó, podría ocurrir con cualquier herramienta de desarrollo, con IA o sin ella, e incluso con una acción manual. También negó que hubiera existido un segundo incidente de AWS como el que describía el reporte original.
Leído en conjunto, el episodio muestra que Amazon está descubriendo, en tiempo real, el costo de darles herramientas cada vez más autónomas a sus equipos de ingeniería antes de que los mecanismos de control estén completamente maduros. La empresa no está abandonando la IA, pero sí está volviendo a poner una capa más fuerte de supervisión humana en los cambios que pueden tocar sistemas sensibles.
Por qué el público se alerta con “la IA se apoderó de Amazon”
La lectura distópica hollywoodense de que “la IA se apoderó de Amazon” surge porque, desde afuera, el caso suena como si una IA hubiera decidido por sí sola qué hacer dentro de la infraestructura de una de las empresas más grandes del mundo. Y, en parte, esa impresión nace de algo real: estas herramientas no se limitan a sugerir o corregir sobre código, sino que pueden ejecutar tareas, encadenar acciones y operar con autonomía dentro de los permisos que les dan sus usuarios. Cuando una herramienta así toma una decisión técnica mala, como reemplazar un entorno entero en vez de corregir una parte puntual, el resultado se parece a que “la IA hizo lo que quiso”.
Sin embargo, lo que muestran estos reportes no es una IA con conciencia, voluntad propia o control independiente de Amazon. Lo que muestran es una automatización muy potente corriendo con permisos, instrucciones y configuraciones definidas por humanos. Si el modelo interpreta mal una consigna, si el entorno le da demasiado alcance, o si los resguardos son débiles, puede ejecutar una secuencia dañina sin entender las consecuencias como lo haría una persona. De hecho, Amazon sostuvo que en el caso de AWS el problema estuvo ligado a un rol mal configurado, es decir, a controles mal armados alrededor de la herramienta.
Tal vez te interese: Proyecto Kuiper: Amazon lanza su segundo lote de satélites
