Il 19 settembre 2026 l’Associated Press ha dato notizia di una class action depositata da quattro abbonati paganti di ChatGPT, Claude, Grok e Gemini contro Anthropic, OpenAI, SpaceXAI e Google. L’accusa non riguarda i danni dei modelli. Riguarda il fatto che i quattro laboratori si sarebbero messi d’accordo per rallentare lo sviluppo: secondo i ricorrenti un progresso rallentato per accordo ha un effetto anticoncorrenziale e riduce il valore che il consumatore ottiene da un abbonamento pagato ogni mese.

Chi vende software non è parte in causa, ma sta nella stessa catena. Chiunque abbia messo una funzione AI dentro un sito WordPress, un gestionale o un preventivo ha scritto da qualche parte, nel codice o nella testa del cliente, l’ipotesi che il modello sotto continui a migliorare, a costare quanto costa oggi e a esistere fra diciotto mesi. Quell’ipotesi adesso dipende anche da un’aula di tribunale americana, e non era mai successo prima.

Cosa contesta davvero la causa

Il punto giuridico è più stretto di come lo raccontano i titoli. I ricorrenti non sostengono che sia illegale rallentare: scrivono esplicitamente che ogni azienda può decidere da sola di frenare per motivi di sicurezza, e non si oppongono nemmeno all’idea che i laboratori chiedano un’esenzione antitrust al governo. Quello che contestano è la scorciatoia: accordarsi fra concorrenti per «sostituire la responsabilità individuale con la moderazione collettiva». L’avvocato Nick Rowley, che guida il collegio dei ricorrenti, la mette in termini più diretti: la sicurezza dell’AI non può essere regolata da accordi privati fra società a scopo di lucro.

Il coordinamento contestato ha una data precisa, il 12 settembre 2026: il saggio di Dario Amodei sul rallentamento e, lo stesso giorno, l’adesione di Sam Altman, Elon Musk e Demis Hassabis. Ma l’atto lo fa risalire a mesi prima. Cita una dichiarazione del luglio 2026 firmata da dipendenti dei principali laboratori, che riconosceva la «intense competitive pressure not to unilaterally slow» lo sviluppo, cioè l’intensa pressione competitiva a non rallentare unilateralmente, e chiedeva al governo statunitense di sostenere uno sforzo internazionale per governare il ritmo. Quella dichiarazione esiste, si chiama Pacing the Frontier, e secondo Fortune è stata firmata da oltre 1.200 dipendenti di OpenAI, Anthropic, Google DeepMind e Meta il 28 luglio 2026. Non chiede a nessuno di fermarsi oggi: chiede che esistano gli strumenti per poterlo fare domani in modo verificabile.

Da lì in poi, nella ricostruzione di Tom’s Hardware, la questione si è aperta su tre fronti contemporaneamente. Amodei ha proposto una cooperazione esplicita fra laboratori, riconoscendo lui stesso il rischio antitrust e augurandosi un’eccezione governativa. Sam Altman ha risposto su X che OpenAI accoglie «un quadro federale che fissi requisiti di sicurezza coerenti», ma che non intende aspettare «un’esenzione antitrust o una legge» per iniziare. E l’amministrazione Trump ha respinto l’idea alla radice: sempre secondo la stessa ricostruzione, il presidente ha definito i rischi dell’AI un imbroglio e ha parlato di una cospirazione contro il settore.

Tribunale, Casa Bianca e aziende tirano in tre direzioni diverse. Come finisca non lo sa nessuno, e non è questo il punto per chi costruisce. Il punto è che il calendario dei rilasci, che per tre anni è stato una variabile tecnica, adesso è anche una variabile legale e politica. Su una variabile del genere non si appoggia una roadmap commerciale.

Perché riguarda chi vende, non chi fa ricerca

L’assunzione sulla cadenza non sta quasi mai in un documento. Sta nelle frasi che si dicono in riunione: «quando esce il modello nuovo lo colleghiamo e i riassunti migliorano da soli», «questa parte per ora la facciamo a mano, fra sei mesi la chiude il modello». Sono promesse a tutti gli effetti, perché il cliente le ricorda.

Il costo si vede quando la promessa non si avvera. Se hai venduto una funzione a canone fisso e oggi, per raggiungere la qualità concordata, ti serve il modello di punta, il tuo margine migliora solo quando arriva un modello che fa la stessa cosa costando meno. Se quel modello non arriva per dodici mesi, il margine resta quello che è. È un rischio di fornitura identico a quello di un’agenzia che ha prezzato un abbonamento hosting contando su un calo del costo dello storage: quando si prezza una funzione AI si vende un tetto di costo, e quel tetto lo tieni tu, non il fornitore.

C’è anche il lato opposto, meno discusso. Un rallentamento concordato non è l’unico scenario che ti tocca: lo è anche un’accelerazione che ti costringe a rincorrere. Ogni modello nuovo che cambia il comportamento degli output è lavoro di riadattamento non preventivato. Chi ha collegato una funzione a un modello e l’ha lasciata lì per un anno lo ha già sperimentato almeno una volta.

Le tre dipendenze che vengono scambiate per una sola

Quando si dice «dipendiamo da OpenAI» si stanno mettendo insieme tre cose che si rompono in modi diversi e si difendono con contromisure diverse.

La capacità è quanto il modello è bravo sul tuo compito specifico. Si degrada in modo silenzioso, perché il fornitore cambia il modello dietro lo stesso nome commerciale o ti sposta su un default nuovo. Non te ne accorgi da un errore: te ne accorgi da un cliente che si lamenta della qualità tre settimane dopo.

La disponibilità è il fatto che quell’endpoint esista ancora. Si rompe in modo netto e con preavviso pubblicato, ed è paradossalmente il rischio più gestibile dei tre.

Il prezzo è quanto paghi per unità di lavoro. Si muove in entrambe le direzioni e non ha quasi mai preavviso contrattuale se stai su un piano standard.

Un accordo fra laboratori per governare il ritmo, se regge, tocca soprattutto la prima. Una causa che lo smonta tocca soprattutto la terza. Una riorganizzazione interna di un fornitore tocca la seconda a prescindere da entrambe. Per questo la risposta operativa non è «scegliere il fornitore giusto»: è separare le tre dipendenze nel codice e nel contratto, così che ognuna si possa affrontare senza toccare le altre.

Il rischio che morde già oggi si chiama deprecazione

Mentre si discute di moratorie, il fatto verificabile è che i fornitori ritirano modelli con regolarità e lo scrivono in pagine pubbliche. OpenAI mantiene una pagina di deprecations con le date di ritiro; Anthropic ne ha una equivalente per i modelli Claude. Sono le uniche date vincolanti dell’intera vicenda: tutto il resto sono dichiarazioni, cause e post su X.

Da qui esce la prima regola concreta, che costa cinque minuti e che vedo saltare quasi sempre nei progetti che erediti: l’identificativo esatto del modello va scritto nella configurazione, non un alias tipo latest, e non sparso in sei file. Un alias significa che il fornitore può cambiarti il motore sotto i piedi in un martedì qualunque, senza che nel tuo repository cambi una riga e senza che tu abbia un commit da guardare quando il cliente chiama. Un identificativo fissato in un punto solo significa che la migrazione è una modifica di una riga, preceduta da un test.

La seconda regola è altrettanto noiosa: una volta al mese, qualcuno apre quelle due pagine e controlla se un modello che usi ha una data di ritiro. Dieci minuti, in agenda, con un nome sopra. Non esiste una notifica che arrivi al posto giusto quando il progetto è stato consegnato a un cliente e la casella di posta del fornitore è intestata a chi ha aperto l’account tre anni fa.

Tre righe da mettere nel preventivo

Non sono clausole legali e non sostituiscono un avvocato: sono tre frasi che spostano una conversazione difficile dal momento in cui il problema esplode al momento in cui il cliente firma, quando è ancora una conversazione tecnica.

Nominare fornitore e modello. «La funzione di riassunto usa il modello X del fornitore Y tramite API.» Sembra un dettaglio da nerd in un documento commerciale, e invece è la riga che rende visibile al cliente che quella funzione ha un fornitore terzo. Senza quella riga, il giorno del problema la dipendenza è tua.

Dire cosa succede se il modello sparisce. «Se il fornitore ritira il modello, la migrazione a un modello equivalente è un intervento concordato a parte» oppure «è compresa nel canone di manutenzione». Vanno bene entrambe. Quella che non va bene è non averlo scritto, perché allora il default è che il cliente si aspetti che sia gratis e immediata.

Impegnarsi sul risultato, non sul modello. Il livello di servizio va scritto come qualità misurata dell’output sui casi reali del cliente, non come nome commerciale del modello. È l’unica formulazione che ti lascia libero di cambiare fornitore senza rinegoziare, ed è anche l’unica onesta: al cliente non interessa quale modello gira, interessa che il preventivo esca giusto.

Il modello è un pezzo sostituibile, non il motore

La differenza fra un’integrazione che si migra in un pomeriggio e una che richiede due settimane non sta nel fornitore: sta in quanta logica di business è finita dentro il prompt.

L’assetto che regge è sempre lo stesso. Una funzione sola parla con l’API, e tutto il resto del codice parla con quella funzione. L’output torna in un formato dichiarato e validato prima di essere usato: se il modello nuovo risponde in prosa dove prima rispondeva in JSON, te ne accorgi dal validatore e non dal cliente. I prompt stanno nel repository, versionati, con accanto l’identificativo del modello con cui sono stati tarati, perché un prompt è taratura per quel modello lì e va riletto quando il modello cambia. E le regole che decidono il comportamento dell’applicazione, per esempio quando un preventivo va rifiutato o a chi si manda una notifica, stanno nel codice: un prompt che contiene le regole di business è una regola di business che nessuno può testare.

Su WordPress a questo si aggiunge un vincolo che ho già trattato e che vale anche qui: la chiave del fornitore non sta nel sito. Il punto in cui il codice incontra il fornitore deve essere uno solo anche per questo motivo, non solo per la sostituibilità.

La valutazione la devi possedere tu

Tutto quello sopra serve a poco se, davanti a un modello nuovo, l’unica cosa che puoi dire al cliente è «mi sembra peggiore». Serve un numero, e il numero te lo fai da solo: venti o trenta casi reali presi dal lavoro di quel cliente, con la risposta che consideri corretta accanto, e un punteggio. Si rilancia a ogni cambio di modello, di versione e di prompt.

Ne ho scritto in dettaglio nei giorni scorsi, e in questo contesto quel lavoro cambia natura: una suite di valutazione costruita sui tuoi dati non serve solo a scegliere un modello, serve a dimostrare un cambiamento. È la prova che trasforma «il fornitore ha peggiorato il servizio» da lamentela in constatazione, e in un’eventuale discussione contrattuale è l’unica cosa che vale qualcosa.

Con quei numeri in mano diventa anche più semplice la scelta che quasi nessuno fa in modo deliberato, cioè se ti serve davvero il modello di punta o basta quello medio. Chi gira sul modello medio ha, per costruzione, più margine di manovra quando il mercato si muove: ha un gradino sopra di sé da usare come riserva di qualità, mentre chi è già sul massimo può solo peggiorare.

Il secondo fornitore si collega prima che serva

Avere un secondo fornitore configurato non vuol dire usarlo. Vuol dire avere la prova, aggiornata, che funziona: credenziali valide, adattatore scritto, suite di valutazione che gira anche contro di lui una volta al mese. Il costo è di qualche minuto al mese se l’architettura è quella descritta sopra, e diventa un progetto di due settimane se non lo è.

Non serve la ridondanza automatica, e quasi sempre non conviene: un fallback che scatta da solo nasconde il problema invece di segnalarlo, e ti fa scoprire a fine mese che hai fatturato per tre settimane con un modello che non avevi testato. Serve la possibilità di cambiare in mezza giornata, con una decisione umana. La differenza fra le due cose sta tutta in quanto spesso hai provato la seconda.

La mia take: il prossimo modello non è una voce di roadmap

Per tre anni rimandare un problema difficile al modello successivo è stata una mossa razionale e gratuita. Chi aspettava aveva ragione più spesso di chi costruiva la soluzione a mano. Quella regola ha smesso di valere, e non per un motivo tecnico: perché il ritmo dei rilasci è diventato oggetto di una trattativa fra aziende, di una causa e di una posizione politica, tre cose che si muovono su tempi che non hanno niente a che vedere con un ciclo di sviluppo.

La conseguenza pratica è piccola e antipatica: una funzione che oggi non funziona abbastanza bene con il modello che hai va risolta adesso, con meno ambizione, oppure non va venduta. Non va messa in roadmap con la nota «quando il modello migliora». È un mestiere più noioso di quello che raccontano le presentazioni, ma è anche l’unico modo di misurare il valore reale di un progetto AI senza che il risultato dipenda da un calendario che non controlli.

Cosa monitorare nei prossimi mesi

Le pagine di deprecazione dei fornitori che usi restano la sola fonte con date vincolanti, e vanno lette come si legge un preavviso di fine contratto. Sulla causa, l’elemento che conta per chi costruisce non è la sentenza ma l’eventuale fase di discovery: è lì che si vedrebbe se un coordinamento sui tempi di rilascio esiste davvero e in quale forma. Sul versante prezzi, vanno guardati i limiti di frequenza delle chiamate insieme alle tariffe, perché un limite più basso è un aumento di prezzo mascherato. E ogni volta che un fornitore annuncia un modello nuovo come sostituto di uno esistente, la domanda giusta non è se sia migliore in generale, ma quanto fa sui tuoi venti casi.

Da fare questa settimana

Quattro cose, nell’ordine, e solo la terza richiede più di un’ora. Primo: cerca nei progetti dove hai scritto un alias di modello al posto di un identificativo esatto e sostituiscilo, spostandolo in un punto solo della configurazione. Secondo: apri le pagine di deprecazione dei fornitori che usi e segna in agenda le date che ti riguardano. Terzo: prendi il cliente AI più importante che hai e scrivi venti casi reali con la risposta attesa, anche in un foglio di calcolo, perché senza quelli ogni discussione futura sulla qualità sarà un’opinione contro un’altra. Quarto: aggiungi al prossimo preventivo le tre righe su fornitore, migrazione e livello di servizio misurato.

Il resto, cioè se i laboratori rallenteranno davvero e se un giudice glielo lascerà fare, non lo decide nessuno di noi. Lo decidiamo noi, invece, se il giorno in cui succede qualcosa avremo una riga da cambiare o un progetto da rifare.

Fonti