Kiro ha deciso che la soluzione migliore era cancellare tutto. A metà dicembre, un gruppo di ingegneri di AWS (Amazon Web Services) ha lasciato che Kiro, il tool IA interno per la scrittura e gestione del codice, risolvesse autonomamente un problema su un sistema AWS.
Kiro ha valutato la situazione e ha scelto la strada più radicale: eliminare l’ambiente e ricrearlo da zero. Il sistema è rimasto offline per 13 ore. Peccato non fosse un test ma la realtà.
Non si è trattato di un episodio isolato. Secondo quattro persone a conoscenza dei fatti, interpellate dal Financial Times, era già la seconda volta in pochi mesi che uno strumento IA interno di Amazon finiva al centro di un’interruzione di servizio.
“Abbiamo già visto almeno due interruzioni in produzione”, ha detto al FT un dipendente senior di AWS. “Gli ingegneri hanno lasciato che l’agente IA risolvesse un problema senza intervenire. Le interruzioni erano piccole ma del tutto prevedibili.”
AWS non è un prodotto qualsiasi: rappresenta il 60% degli utili operativi dell’intero gruppo Amazon. È l’infrastruttura su cui girano applicazioni, siti e servizi di migliaia di aziende nel mondo. Quando va down, le conseguenze si avvertono da lontano, come già accaduto nell’ottobre 2025, quando un’interruzione di 15 ore aveva portato offline anche ChatGPT di OpenAI.
“Errore dell’utente, non dell’IA”
La risposta ufficiale di Amazon è arrivata con una distinzione netta: “In entrambi i casi, si è trattato di un errore dell’utente, non dell’IA.” L’azienda ha precisato che l’ingegnere coinvolto nell’incidente di dicembre “disponeva di permessi più ampi del previsto”, inquadrando il problema come una questione di controllo degli accessi, non di comportamento dello strumento.
Formalmente, la posizione regge. Kiro, per impostazione predefinita, richiede autorizzazione prima di agire. In questo caso, i permessi erano stati configurati in modo troppo ampio, e nessun secondo responsabile aveva approvato le modifiche, come sarebbe invece prassi normale.
Lo strumento ha dunque operato nello spazio che gli era stato lasciato aperto. Ma è proprio qui che la difesa di Amazon si complica. Kiro è uno strumento agentico: è progettato per prendere decisioni e agire in autonomia.
Se il suo punto di forza è ridurre la necessità di supervisione umana, scaricare la responsabilità sull’operatore che non ha supervisionato abbastanza diventa un argomento alquanto spinoso.
Vendere uno strumento di cui si dubita
Quello che rende la vicenda più sorprendente non è l’incidente in sé (tecnicamente contenuto, geograficamente limitato) ma il contesto in cui emerge.
Amazon sta spingendo attivamente Kiro sul mercato esterno, presentandolo come un salto qualitativo rispetto al semplice “vibe coding”: non uno strumento per generare codice velocemente, ma un assistente capace di lavorare su specifiche strutturate e prendere decisioni complesse.
Nel frattempo, internamente, ha fissato un obiettivo preciso: l’80% degli sviluppatori deve usare strumenti IA per attività di scrittura del codice almeno una volta a settimana. L’adozione viene monitorata. Non è un invito, è una metrica.
Alcuni dipendenti, però, restano scettici. Nei fatti, sono gli stessi ingegneri che conoscono meglio il sistema a mettere in dubbio l’affidabilità di questi strumenti per la maggior parte del lavoro quotidiano.
La pressione ad adottare viene così dall’alto; la resistenza viene da chi lavora con l’infrastruttura ogni giorno. È una tensione che Amazon (ma sospettiamo non sia l’unica) non riesce a risvolvere, e che gli incidenti di questi mesi rendono più difficile ignorare.
AWS, agenti autonomi ma responsabilità condivisa
A seguito dell’incidente di dicembre, AWS ha annunciato l’introduzione di misure correttive. Ossia revisione obbligatoria tra colleghi e formazione del personale. Passi sensati, che però confermano implicitamente quanto fosse fragile il sistema di controllo precedente.
Il problema strutturale resta comunque aperto. Quando un agente IA opera con le stesse autorizzazioni di un ingegnere umano, come è avvenuto in questi casi, e prende una decisione sbagliata, chi ne risponde?
Amazon dice: l’utente che ha configurato male i permessi. Ma se lo strumento è progettato per agire senza intervento, e se l’obiettivo dichiarato è ridurre il carico di supervisione, attribuire all’operatore la piena responsabilità delle conseguenze suona come una clausola di esonero più che come un’analisi tecnica.
È una questione che va ben oltre Amazon. Chiunque stia integrando agenti autonomi in ambienti critici (propri o dei suoi clienti) prima o poi si troverà a rispondere alla stessa domanda.
Fonte: Financial Times
