Non si è rotto nulla, ed è costato 1,8 milioni

Una riunione il 28 luglio e un numero che nessuno voleva

Il 28 luglio ingegneri senior di Amazon hanno informato i colleghi su cosa fosse successo a una serie di progetti interni di IA. Il Financial Times ne ha riportato i contenuti. Un progetto usava Claude Sonnet di Anthropic per confrontare i dati degli autori con le schede del commercio elettronico. Ha speso 1,8 milioni di dollari. È andato l'860 per cento oltre il budget. Ha girato cinque mesi prima che qualcuno lo intercettasse, e non è mai andato in produzione. Un team ha descritto lo schema come catastroficamente costoso.

Con esso sono arrivati due casi minori. Uno strumento di revisione finanziaria ha sforato di circa 541.000 dollari. Un progetto di logistica è finito circa 134.000 dollari sopra il piano. Un dipendente senior di Amazon ha riassunto il problema di fondo al FT in una frase: è difficile capire quanto costi qualunque cosa legata all'IA. Amazon ha risposto che sta sperimentando, imparando e migliorando l'uso della tecnologia, ha definito gli esempi scelti ad arte, e sta introducendo revisioni obbligatorie tra pari e tetti di spesa sui progetti di IA.

Partite dall'aritmetica, perché nessuno l'ha pubblicata. Se 1,8 milioni di dollari sono uno sforamento dell'860 per cento, il budget approvato era intorno ai 190.000 dollari. È il numero che un controllo avrebbe dovuto difendere.

Due mesi prima, lo stesso errore indossava un altro costume

Il 29 maggio Amazon ha chiuso KiroRank, una classifica interna sulla piattaforma di sviluppo Kiro che ordinava il personale per token di IA consumati. Era nata per spingere l'adozione. Ha spinto una pratica che i dipendenti hanno chiamato tokenmaxxing: puntare agenti su lavoro che non serviva a nessuno, perché la posizione si muovesse. Dave Treadwell, senior vice president, ha scritto al personale in un memo che la classifica era stata costruita con buone intenzioni e ha chiesto di non usare l'IA solo per il gusto di usarla.

Leggete i due episodi come uno. A maggio Amazon ha premiato il consumo e ha ricevuto consumo. A luglio ha scoperto consumo che nessuno aveva autorizzato e nessuno aveva letto. La classifica e il lavoro sfuggito non sono fallimenti di disciplina separati; sono la stessa lacuna, cioè che l'organizzazione aveva un contatore acceso e nessuna abitudine di leggerlo.

L'istruzione sta nel sostituto, non nella chiusura. Amazon non ha semplicemente cancellato la classifica. Ha sostituito la metrica con i rilasci normalizzati, che contano il codice assistito dall'IA che finisce davvero in produzione.

Perché un fallimento a contatore resta invisibile

Il software tradizionale annuncia i propri fallimenti. Un ciclo sbagliato esaurisce la memoria e il processo muore, una pagina va in timeout, scatta un allarme e qualcuno viene svegliato alle tre di notte. Una chiamata a modello mal configurata non fa niente di tutto questo. Riesce. Restituisce una risposta, addebita i token e riparte. Non c'è un blocco da rilevare perché dal punto di vista della piattaforma non è andato storto nulla, ed è esattamente la condizione in cui possono passare cinque mesi.

Poi tre cose allungano la finestra di rilevamento. La fatturazione è mensile, quindi la funzione finanza vede la forma di un problema settimane dopo la spesa, e la vede aggregata. Il prezzo è a token, quindi il costo scala con il volume e non con il numero di istanze, che è l'asse per cui è stata costruita la maggior parte del monitoraggio infrastrutturale. E gli agenti moltiplicano i token, perché un ciclo agentico fa molte chiamate al modello dove un'interfaccia di chat ne fa una.

Per un operatore europeo la conseguenza è la stessa a prescindere dalla regione: il contatore gira nell'account cloud, la fattura arriva a ciclo mensile, e nulla nel mezzo vi dice che il lavoro ha smesso di essere utile a marzo.

I controlli esistevano e non erano accesi

Questa è la parte scomoda della storia, ed è il motivo per cui appartiene a una rubrica di decisioni e non a una di tecnologia. Le mitigazioni erano disponibili sulla piattaforma per tutto il tempo. AWS pubblica l'inferenza in batch a metà del prezzo per token della modalità on demand per lavori che non richiedono una risposta immediata, che è esattamente il profilo di un confronto in background durato cinque mesi. Offre la cache dei prompt perché un contesto ripetuto non venga pagato a tariffa piena a ogni chiamata. Offre livelli di modello più economici e instradamento tra essi. Nulla di tutto ciò è esotico e nulla richiedeva una trattativa.

Un lavoro girato cinque mesi senza che servisse urgentemente una risposta è il carico batch da manuale. Farlo girare on demand non è un fallimento tecnico, è una decisione che nessuno è stato chiamato a prendere, perché la persona che ha configurato il lavoro non era la persona che vedeva la fattura.

Progettate contro quella separazione. Chi può avviare un lavoro a contatore dovrebbe vederne il costo corrente nella stessa interfaccia in cui lo avvia.

Quattro controlli prima che esca il vostro prossimo agente

Fissate un tetto rigido per lavoro, non per account. Un avviso di budget a livello di account vi dice che il totale si è mosso; non vi dice quale lavoro lo ha mosso, e quando un budget di account scatta i cinque mesi sono già passati. Secondo, pretendete in fase di approvazione una risposta esplicita a una domanda: serve una risposta adesso? Se la risposta è no, è un carico batch e va prezzato come tale.

Terzo, mettete una scadenza a ogni lavoro di lunga durata. Un compito di confronto che gira da marzo avrebbe dovuto richiedere il rinnovo da parte di una persona ad aprile. Quarto, misurate il risultato. Se il punteggio di un progetto è il lavoro assistito dall'IA che è andato in produzione, allora un rilascio mai arrivato vale zero per quanti token abbia consumato, e sarebbe emerso alla prima revisione mensile invece che alla quinta.

Da leggere ora: Amazon taglia il suo team AGI in un anno da 200 mld  |  I vostri dati controllati erano già mezzi macchina