L'algoritmo segreto di Amazon ti ha rubato 1 miliardo di dollari — e la prossima potrebbe essere l'IA della tua azienda

Ero seduto nella sala riunioni di un cliente verso la fine del 2024 quando il loro VP del Pricing ha aperto una dashboard e ha detto, con genuino orgoglio: "Abbiamo automatizzato tutto. L'algoritmo gestisce ogni cosa."

Gli ho posto una sola domanda: "Puoi dirmi esattamente perché ieri ha fissato questo prezzo su questo prodotto?"

Silenzio. Non quello del riflettere. Quello di chi si rende conto di aver guidato un'auto senza sapere dove sono i freni.

Quel momento continua a ripresentarsi nella mia mente per via di ciò che ora sappiamo su Project Nessie di Amazon — un algoritmo di pricing segreto che ha estratto oltre 1 miliardo di dollari in profitti in eccesso prevedendo quando i concorrenti avrebbero seguito gli aumenti di prezzo di Amazon, per poi alzare deliberatamente i prezzi così da innescare quella risposta. Non un difetto. Non una conseguenza involontaria. Una funzionalità. E la Federal Trade Commission porterà Amazon a processo per questo nell'ottobre 2026.

Ecco ciò che mi turba di più: il VP in quella sala riunioni non stava facendo nulla di insolito. Stava facendo ciò che migliaia di aziende stanno facendo proprio ora — affidando a sistemi di IA opachi decisioni ad alto rischio che non sono in grado di spiegare, verificare o controllare. E il mondo normativo sta per rendere quella fiducia estremamente costosa.

Come si rubano 1 miliardo di dollari senza che nessuno se ne accorga?

Project Nessie è stato attivo dal 2014 al 2019. Non era un semplice strumento di allineamento dei prezzi. Era un motore di manipolazione del mercato camuffato da software di ottimizzazione.

Ecco come funzionava. I web crawler di Amazon monitoravano in tempo reale milioni di punti di prezzo su tutta Internet — Walmart, Target, ogni rivenditore con un sito web. La maggior parte di questi concorrenti usava un pricing semplice basato su regole: "Se Amazon scende a 19,99 $, allineati." Occhio per occhio. Lineare.

Nessie riconosceva questo schema e lo sfruttava. L'algoritmo calcolava la probabilità che un concorrente avrebbe seguito un aumento di prezzo di Amazon. Quando la sicurezza era elevata, Amazon alzava deliberatamente il prezzo. L'algoritmo stupido del concorrente si allineava diligentemente. Amazon manteneva il prezzo gonfiato. Profitto catturato.

E se il concorrente non seguiva? Nessie riportava automaticamente il prezzo al livello precedente. Nessun danno, nessuna colpa — se non che Amazon aveva appena testato il tetto di ciò che il mercato era disposto a sopportare.

L'algoritmo di Amazon non si accordava con i concorrenti in una stanza piena di fumo. Si accordava attraverso il codice — prevedendo le loro risposte automatizzate e sfruttandole con precisione cronometrica.

La portata era sbalorditiva. Nessie avrebbe fissato i prezzi per oltre 8 milioni di singoli articoli. Documenti interni mostrano che i vertici di Amazon hanno acceso e spento l'algoritmo almeno otto volte, attivandolo strategicamente durante i periodi di alto traffico, quando l'estrazione era più redditizia. I dirigenti definivano privatamente pratiche correlate "losche" e un "cancro taciuto". Continuarono comunque a usarlo.

La notte in cui ho capito cosa significa davvero "collusione implicita"

Ricordo la sera esatta in cui la cosa mi è diventata chiara. Io e il mio team stavamo esaminando uno studio della Carnegie Mellon sulle interazioni di pricing algoritmico — il tipo di articolo che leggi alle 23 con troppo caffè e un crescente senso di inquietudine.

I ricercatori avevano simulato ciò che accade quando un sofisticato agente di apprendimento per rinforzo compete contro semplici sistemi di pricing basati su regole. L'agente RL non aveva bisogno di comunicare con i suoi concorrenti. Non aveva bisogno di un accordo segreto. Semplicemente imparava che alzare i prezzi era più redditizio che tagliarli, perché gli altri algoritmi lo avrebbero seguito. Ogni volta.

Il risultato: i prezzi sono saliti su tutta la linea. Il surplus del consumatore — il termine economico per "le persone che ottengono affari equi" — è crollato.

Mi sono rivolto al mio co-fondatore e ho detto qualcosa come: "Questo non è un bug nel sistema. Questo è ciò che il sistema fa quando lo lasci ottimizzare senza vincoli."

È questo il problema centrale di Project Nessie, ed è il problema centrale della maggior parte dei deployment di IA aziendale che vedo oggi. L'algoritmo ha fatto esattamente ciò per cui era stato progettato. Ha massimizzato il profitto. Lo ha semplicemente fatto in un modo che, a seconda di come andrà il processo dell'ottobre 2026, potrebbe costituire un metodo di concorrenza sleale ai sensi della Sezione 5 del FTC Act.

Il diritto antitrust tradizionale richiede la prova di un "incontro delle volontà" — concorrenti che si accordano per fissare i prezzi. Ma cosa succede quando l'accordo è implicito, codificato nel comportamento prevedibile di algoritmi che interagiscono? È la domanda a cui risponderà il processo della FTC, e le implicazioni vanno ben oltre Amazon.

Perché il 2026 è l'anno in cui tutto cambia?

Il panorama legale per il processo decisionale algoritmico sta cambiando più rapidamente di quanto la maggior parte delle aziende si renda conto. Lo seguo da vicino perché i nostri clienti hanno bisogno di capire cosa sta arrivando, e ciò che sta arrivando è un muro di regolamentazione.

Il Cartwright Act emendato della California, in vigore da gennaio 2026, prende di mira specificamente i "common pricing algorithm" — strumenti usati da due o più concorrenti che incorporano informazioni sui concorrenti per influenzare i prezzi. La legge vieta esplicitamente l'uso di questi strumenti per colludere. Cosa ancora più importante, abbassa lo standard probatorio della domanda giudiziale a favore degli attori. Non è più necessario dimostrare che i concorrenti non avrebbero potuto agire in modo indipendente. Basta mostrare che hanno usato lo stesso strumento e che i prezzi sono saliti.

Pensate a cosa significa questo per ogni azienda che usa un fornitore terzo di pricing dinamico.

L'AI Act del Colorado, in vigore da giugno 2026, richiede valutazioni d'impatto con "ragionevole diligenza" per i sistemi di IA ad alto rischio — inclusi quelli che influenzano in modo significativo le decisioni su prezzi, credito e occupazione. Gli sviluppatori devono documentare rischi, limiti e potenziali esiti discriminatori.

La legge sulla trasparenza di New York richiede alle imprese di mostrare un avviso quando gli algoritmi usano dati personali per le decisioni di prezzo. L'era del pricing algoritmico invisibile sta finendo.

E poi c'è il processo della FTC stesso. Se il tribunale stabilisce che l'induzione predittiva di Amazon — alzare deliberatamente i prezzi per innescare l'allineamento dei concorrenti — costituisce un metodo di concorrenza sleale, crea un precedente che potrebbe applicarsi a qualsiasi azienda la cui IA influenzi i prezzi di mercato.

Se non riesci a spiegare perché il tuo algoritmo ha preso una decisione specifica, non puoi difendere quella decisione in tribunale. E nel 2026 ti verrà chiesto sempre più spesso di farlo.

Ho scritto dell'intera timeline normativa e delle sue implicazioni tecniche nella nostra analisi interattiva — vale la pena comprenderne i dettagli se la tua azienda ha a che fare in qualsiasi forma con il pricing algoritmico.

La trappola della Buy Box di cui nessuno parla

C'è una dimensione della vicenda Nessie che riceve meno attenzione ma che conta enormemente per capire come si accumula il potere algoritmico.

Amazon non si limitava ad alzare i prezzi. Li imponeva su tutta Internet.

Amazon manteneva un gruppo dedicato alla sorveglianza dei prezzi che monitorava i venditori terzi sul suo marketplace. Se un venditore offriva un prodotto a un prezzo inferiore sul proprio sito web o su una piattaforma rivale, Amazon gli toglieva l'accesso alla Buy Box — l'interfaccia in cui avviene il 98% delle vendite di Amazon.

Il messaggio era chiaro: il tuo prezzo su Amazon è il tuo prezzo minimo ovunque. Sconta altrove e perdi il tuo principale canale di ricavi.

Questo creava un prezzo minimo che estendeva il potere di pricing algoritmico di Amazon ben oltre la sua stessa piattaforma. I venditori non potevano vendere sotto Amazon nemmeno sui propri siti web. I concorrenti non potevano guadagnare quote di mercato offrendo prezzi più bassi perché il lato dell'offerta era bloccato.

Ci penso ogni volta che qualcuno mi dice "il mercato si autocorreggerà". Il mercato può autocorreggersi solo quando i partecipanti sono liberi di competere. Quando un algoritmo controlla sia il prezzo sia il meccanismo di applicazione, non hai un mercato. Hai un sistema.

Perché il tuo "wrapper" di IA è una responsabilità pronta a scoppiare

È qui che la questione diventa personale per me, perché è il problema a cui dedico la maggior parte del mio tempo cercando di risolverlo.

La maggior parte dei deployment di IA aziendale che incontro segue lo stesso schema: prendere un'API pubblica — GPT-4, Claude, qualunque cosa sia di tendenza — avvolgerla in un sottile strato applicativo, infilare le regole di business in un prompt enorme e chiamarlo "basato sull'IA". Rilasciarlo. Passare oltre.

Io lo chiamo la trappola del wrapper, e ho visto aziende intelligenti caderci dritte dentro.

Un cliente — non lo nominerò, ma è nel retail — aveva costruito l'intero sistema di pricing dinamico come un wrapper attorno a un LLM pubblico. Il prompt era enorme. Conteneva regole di prezzo, dati sui concorrenti, obiettivi di margine, aggiustamenti stagionali. Il sistema funzionava... la maggior parte delle volte. Quando non funzionava, nessuno sapeva spiegare perché. Quando il fornitore del modello rilasciava un aggiornamento, gli output cambiavano in modo imprevedibile. Quando il loro ufficio legale chiedeva una traccia di audit delle decisioni di prezzo, il team di ingegneria si limitava a fissarli.

Ricordo di essere stato seduto con il loro CTO dopo una settimana particolarmente brutta in cui il sistema aveva generato raccomandazioni di prezzo che, se attuate, sarebbero apparse molto simili al tipo di comportamento coordinato che la FTC stava indagando nel caso Amazon. Non intenzionalmente. Non maliziosamente. Il modello aveva semplicemente appreso dai suoi dati di addestramento schemi che si dava il caso producessero output dall'aspetto collusivo.

"Non possiamo dimostrare che non stesse colludendo," mi disse il CTO. "E secondo le nuove regole della California, questo potrebbe bastare per farci causa."

Aveva ragione.

I problemi strutturali dei wrapper vanno oltre la conformità:

Non puoi verificare una scatola nera. Quando il modello sottostante è controllato da terzi, non puoi dimostrare perché è stata presa una specifica decisione di prezzo. Con l'AI Act del Colorado, ne avrai bisogno.

Non puoi garantire la coerenza. Piccoli cambiamenti nel prompt, o aggiornamenti invisibili del modello da parte del fornitore dell'API, possono produrre output radicalmente diversi. Prova a spiegarlo a un regolatore.

Non hai alcun vantaggio competitivo difendibile. Se la tua "soluzione di IA" è un prompt in GPT-4, qualsiasi concorrente può replicarla in un giorno. E quando Google e Microsoft integreranno queste capacità nativamente nelle loro piattaforme, i wrapper autonomi diventeranno ridondanti da un giorno all'altro.

Non sei proprietario della tua intelligenza. I tuoi dati di mercato più sensibili — strategie di prezzo, analisi dei concorrenti, obiettivi di margine — passano attraverso i server di qualcun altro. In un mondo di crescenti requisiti di sovranità dei dati, questo non è solo rischioso. È negligente.

Cosa abbiamo costruito invece (e perché è stato più difficile di quanto ci aspettassimo)

In VeriPrajna abbiamo intrapreso una strada diversa. La chiamiamo Deep AI e, sarò onesto, è nettamente più difficile da costruire di un wrapper. Ci sono stati momenti in cui mi sono chiesto se al mercato sarebbe importato qualcosa della differenza.

L'idea centrale è l'intelligenza sovrana: l'intero stack di inferenza distribuito sull'infrastruttura del cliente stesso. Nessun dato lascia il perimetro aziendale. Il "cervello" dell'IA gira su hardware controllato dal cliente.

Usiamo modelli open-source ad alte prestazioni — Llama 3, Mistral — orchestrati attraverso una containerizzazione sicura. Inferenza locale. Nessuna conservazione dei dati da parte di terzi. Nessuna latenza da API esterne.

Ma il modello è solo l'inizio. La vera sfida ingegneristica è ciò che lo circonda.

Abbiamo costruito quella che chiamiamo RAG 2.0 — Retrieval-Augmented Generation che crea un "cervello semantico" a partire dai documenti proprietari, dai log e dai dati operativi di un'azienda. Fondamentale: il nostro sistema di retrieval è consapevole del RBAC. Rispetta i controlli di accesso esistenti dell'organizzazione. Se un dipendente non può visualizzare un documento in SharePoint, nemmeno l'IA può recuperarlo. Sembra ovvio. Quasi nessun sistema basato su wrapper lo fa.

Poi c'è l'architettura multi-agente. Invece di stipare tutto in un unico prompt enorme — l'approccio "prega e prompta" — scomponiamo i compiti complessi in agenti specializzati. Un agente di pianificazione decide il flusso di lavoro. Un agente di context engineering estrae i segnali rilevanti da dati ad alto volume. Un agente di conformità convalida ogni output rispetto ai requisiti normativi prima che raggiunga l'utente. Un agente di verifica controlla l'accuratezza.

Ricordo un'accesa discussione con uno dei miei ingegneri su se l'agente di conformità valesse la latenza che aggiungeva. La sua posizione: "Gli utenti vogliono velocità. Stiamo aggiungendo 200 millisecondi per un controllo che scatta a ogni richiesta." La mia posizione: "Una singola raccomandazione di prezzo non conforme che finisce in un atto giudiziario costerà più di ogni millisecondo che abbiamo mai risparmiato." Abbiamo tenuto l'agente di conformità.

Le aziende che vinceranno il prossimo decennio non sono quelle con i prompt più ingegnosi. Sono quelle che trattano l'IA come una seria disciplina ingegneristica costruita su dati che possiedono e di cui si fidano davvero.

Per l'intera architettura tecnica — i componenti specifici, i pattern di orchestrazione, i livelli di governance — ho documentato tutto nel nostro approfondimento tecnico.

Cosa succede quando gli algoritmi iniziano a ragionare?

La prossima ondata sta già arrivando, e rende tutto ciò che ho descritto più urgente.

Gli attuali sistemi di IA fanno passare un input attraverso una rete neurale una volta e restituiscono un risultato. Il paradigma emergente — ciò che i ricercatori chiamano Reasoning AI — usa computazione aggiuntiva al momento dell'inferenza per pensare. Il modello simula molteplici azioni potenziali e le loro conseguenze prima di impegnarsi in una decisione. Pianifica diverse mosse in anticipo, come un motore scacchistico applicato alla strategia aziendale.

In uno scenario di pricing, un agente di Reasoning AI non si limita a prevedere il prossimo prezzo probabile. Simula come i concorrenti potrebbero reagire a un aumento di prezzo, modella gli effetti di secondo e terzo ordine e adatta la sua strategia in tempo reale. Può tornare indietro dai percorsi subottimali prima ancora che vengano attuati.

Questa è una capacità straordinaria. È anche un rischio straordinario. Perché un'IA capace di ragionare sulle risposte dei concorrenti è un'IA capace, per progettazione, di mettere in atto esattamente quel tipo di induzione predittiva che ha messo Amazon nei guai.

La differenza tra "ottimizzazione" e "manipolazione" diventa sottilissima quando l'algoritmo è abbastanza intelligente da modellare l'intero panorama competitivo e scegliere il percorso che massimizza l'estrazione.

Ecco perché la governance non può essere un ripensamento. Deve essere integrata nell'architettura fin dal primo giorno — non come una casella di conformità da spuntare, ma come un vincolo strutturale su ciò che al sistema è consentito fare.

Come si costruisce un'IA capace di difendersi in tribunale?

Me lo chiedono di continuo, di solito formulato come "come rendiamo conforme la nostra IA?". Penso che sia la domanda sbagliata. La conformità è una soglia minima. La domanda giusta è: come si costruisce un'IA che ti sentiresti a tuo agio a spiegare a un giudice, riga per riga, decisione per decisione?

Il NIST AI Risk Management Framework ci fornisce un vocabolario per questo. Definisce sette caratteristiche di un'IA affidabile: sicura, protetta, spiegabile, rispettosa della privacy, equa, responsabile e valida. Ma i framework non si implementano da soli.

Ciò che ho imparato costruendo questi sistemi è che tre cose contano più di ogni altra:

Primo, non lasciare mai che l'algoritmo sia il decisore finale su scelte ad alto rischio. Human-in-the-loop non è una parola di moda. È uno scudo legale. Quando un regolatore chiede "chi ha deciso di alzare questo prezzo?", "il nostro algoritmo" è la peggior risposta possibile. "Il nostro team di pricing, informato da raccomandazioni algoritmiche che ha esaminato e approvato" è difendibile.

Secondo, verifica proattivamente la presenza di schemi collusivi. Non aspettare che la FTC bussi alla porta. Fai girare regolarmente il tuo algoritmo di pricing in ambienti competitivi simulati. Se converge costantemente su prezzi più alti quando compete contro altri algoritmi, hai un problema — e vuoi scoprirlo prima che lo faccia l'avvocato di un attore.

Terzo, possiedi il tuo stack. Se la tua IA gira sull'infrastruttura di qualcun altro, usa il modello di qualcun altro, e non puoi accedere ai pesi, ai dati di addestramento o alla logica decisionale, non hai un sistema di IA. Hai una dipendenza da un fornitore con un rischio legale esistenziale.

La domanda da 1 miliardo di dollari

Project Nessie di Amazon ha estratto 1 miliardo di dollari dai consumatori attraverso un algoritmo che prevedeva e sfruttava il comportamento dei concorrenti. I vertici interni dell'azienda sapevano che era problematico. Lo usarono comunque perché l'aspetto economico era irresistibile.

Il processo dell'ottobre 2026 determinerà se quell'estrazione fosse illegale. Ma per ogni azienda che impiega l'IA nel pricing, nella supply chain, nel prestito o in qualsiasi ambito in cui le decisioni algoritmiche influenzano i mercati e i consumatori, il verdetto quasi non conta. Il controllo è già qui. California, Colorado e New York hanno già approvato leggi. La FTC sta già indagando. Lo standard legale su ciò che costituisce responsabilità algoritmica si sta irrigidendo in tempo reale.

Ho fondato VeriPrajna perché credevo che il divario tra ciò che l'IA può fare e ciò che l'IA dovrebbe fare sarebbe diventato il problema aziendale definitorio del decennio. Project Nessie ha dimostrato che quel divario può valere un miliardo di dollari in responsabilità. Le aziende che lo colmano — costruendo un'IA che possiedono, comprendono e sono in grado di difendere — non si limiteranno a evitare l'esposizione legale. Costruiranno quel tipo di fiducia con i regolatori, i clienti e i mercati che diventa un vantaggio competitivo inattaccabile.

L'algoritmo più pericoloso non è quello che sbaglia. È quello che è redditizio in modi che non sai spiegare.