Avevano costruito il loro film su Sora. OpenAI ha chiuso il servizio

Critterz era stato raccontato come uno dei primi lungometraggi animati prodotti con un uso esteso di strumenti di intelligenza artificiale. La produzione, realizzata da Native Foreign insieme a Vertigo Films, puntava a dimostrare che l’AI potesse comprimere radicalmente tempi e costi rispetto a una produzione animata tradizionale, trasformando un processo normalmente lungo, costoso e ad alta intensità di lavoro in una filiera molto più rapida e leggera. Poi OpenAI ha annunciato la chiusura di Sora come esperienza web e app. Il servizio è stato dismesso ad aprile 2026, mentre l’API resterà disponibile solo fino a settembre. Per chi osserva l’AI dal lato dei prodotti consumer può sembrare una normale scelta di portafoglio, una decisione tra tante dentro un mercato che cambia rapidamente. Per chi invece aveva costruito una parte rilevante del proprio processo produttivo su quello strumento, la stessa decisione assume un significato molto diverso. Il caso è piccolo rispetto alla dimensione complessiva del mercato AI, ma racconta una dinamica molto più ampia. Quando un processo critico viene costruito su un servizio esterno, quel servizio smette di essere soltanto uno strumento e diventa una componente dell’infrastruttura operativa. Nel momento in cui quella componente cambia, riduce le funzionalità, modifica le condizioni di accesso o scompare, il problema non è più soltanto tecnologico, ma diventa organizzativo.

Quello che la chiusura di Sora dice davvero

La chiusura di Sora non va letta solo come la fine di un prodotto. Va letta come un promemoria su una caratteristica strutturale dell’AI generativa contemporanea, ovvero il fatto che molte delle tecnologie su cui aziende, team creativi e organizzazioni stanno costruendo processi reali sono ancora prodotti instabili, governati da priorità industriali che possono cambiare rapidamente e che non coincidono necessariamente con quelle di chi li utilizza. Un fornitore può decidere di riallocare risorse verso aree più redditizie, modificare il pricing, cambiare i limiti di utilizzo, integrare una funzionalità dentro un altro prodotto oppure chiudere un’app mantenendo solo l’API per un periodo transitorio. Nessuna di queste scelte è irrazionale dal punto di vista del fornitore, ma ciascuna può avere effetti molto concreti su chi nel frattempo ha costruito workflow, budget, tempi di produzione e aspettative operative su quella tecnologia. Il punto quindi non è stabilire se Sora fosse o meno un prodotto destinato a durare. Il punto è che molti progetti AI vengono adottati come se la stabilità del fornitore fosse garantita, mentre in realtà dipende da decisioni che l’organizzazione utilizzatrice non controlla e che possono cambiare in funzione di priorità commerciali, tecniche o strategiche esterne al proprio perimetro.

Il problema non era Sora

La storia di Critterz può essere raccontata come un caso sfortunato legato alle vicende di un singolo prodotto, ma questa lettura rischia di essere troppo parziale. Il problema non era Sora in sé. Il problema era costruire una parte significativa della propria infrastruttura produttiva su un servizio controllato da un’azienda terza, con logiche di business proprie e indipendenti da quelle di chi lo stava usando. Questo schema non riguarda solo l’industria cinematografica. Riguarda qualsiasi organizzazione che abbia integrato strumenti AI esterni dentro processi rilevanti, dalla produzione creativa all’analisi dati, dall’assistenza clienti alla generazione di documentazione interna, fino al supporto operativo nei team tecnici. In tutti questi casi il tema non è semplicemente se lo strumento funzioni, ma quanto quel processo diventi dipendente da una tecnologia che può cambiare senza che l’organizzazione abbia un reale potere di controllo. La dipendenza da un servizio esterno diventa un rischio operativo nel momento in cui quel servizio non è sostituibile rapidamente senza interrompere il lavoro. Non è una questione di fiducia nel fornitore, ma di architettura. La domanda rilevante è cosa succede se domani quello strumento cambia modello di prezzo, riduce le funzionalità, modifica il comportamento degli output o viene ritirato, e in molte aziende questa domanda non ha ancora una risposta esplicita.

Perché accade più spesso di quanto si pensi

Sora è un caso visibile perché la chiusura è stata pubblica, ma la dinamica sottostante è molto più comune e molto meno evidente. I modelli cambiano comportamento, le API vengono aggiornate, i limiti di utilizzo vengono rivisti, le funzionalità vengono spostate da un piano all’altro, le policy cambiano e workflow che funzionavano in una certa configurazione possono smettere di funzionare nello stesso modo dopo un aggiornamento. Nella maggior parte dei casi non c’è un evento drammatico e non c’è un servizio che chiude dall’oggi al domani. C’è piuttosto una somma di piccole variazioni che obbligano i team ad adattare prompt, procedure, integrazioni, controlli e aspettative, spesso senza che il costo di questi adattamenti venga misurato come parte del costo reale di adozione dell’AI. Per un progetto marginale questo può essere soltanto un fastidio operativo. Per un processo core può diventare un costo nascosto, perché più un’organizzazione ha integrato quello strumento senza alternative, più ogni variazione esterna produce lavoro interno non pianificato, rallentamenti, rischi di continuità e perdita di controllo sul processo.

La domanda che i team operativi non si fanno abbastanza

Quando un’organizzazione adotta uno strumento AI per un processo rilevante, la domanda più frequente è se lo strumento funzioni, quanto faccia risparmiare, quanto velocizzi il lavoro o quanto migliori la qualità apparente degli output. La domanda meno frequente, e spesso più importante, è cosa succederebbe se quello stesso strumento cambiasse in modo significativo entro sei mesi. Questa seconda domanda viene spesso percepita come eccessivamente prudente, soprattutto in una fase in cui la velocità di adozione viene trattata come una metrica di modernità. Ma è esattamente la domanda che separa un esperimento da un’infrastruttura. Finché uno strumento viene usato per provare, esplorare o accelerare attività secondarie, il rischio è limitato. Quando invece entra dentro processi ricorrenti, dipendenze operative, scadenze, budget e responsabilità organizzative, il livello di attenzione deve cambiare. Non tutto deve essere costruito con lo stesso livello di ridondanza. Un tool usato per accelerare attività non critiche può essere sostituito con un certo margine di improvvisazione, mentre un servizio integrato dentro un processo core richiede una valutazione diversa. Serve sapere cosa è sostituibile rapidamente, cosa richiede settimane di lavoro e cosa, se cambia, blocca una parte reale dell’organizzazione. Questa mappa, nella maggior parte delle aziende, non esiste ancora.

Il punto non è evitare l’AI

La risposta non è rinunciare agli strumenti AI esterni, perché sarebbe una conclusione sbagliata e poco realistica. La risposta è smettere di trattarli come se fossero infrastrutture stabili quando spesso sono ancora prodotti in evoluzione, soggetti a cambiamenti di roadmap, pricing, policy, disponibilità e comportamento tecnico. Usare l’AI di un fornitore esterno può avere moltissimo senso, soprattutto quando permette di accelerare attività complesse, sperimentare nuovi processi o aumentare la produttività senza costruire tutto internamente. Ma costruire processi critici su un unico servizio, senza una strategia di portabilità, senza alternative, senza controllo sui dati, senza procedure di fallback e senza una valutazione del rischio operativo, significa trasformare una scelta tecnologica in una dipendenza organizzativa. Il caso Critterz è interessante proprio per questo. Non dimostra che l’AI non funzioni, né che non si debbano usare strumenti esterni per innovare processi creativi o produttivi. Dimostra piuttosto che anche quando l’AI funziona, il modo in cui viene incorporata nei processi può creare vulnerabilità che emergono solo quando il fornitore cambia direzione.

Quello che resta quando il servizio chiude

Quando un servizio chiude, o cambia in modo tale da non essere più utilizzabile come prima, resta una domanda molto semplice: cosa possiede davvero l’organizzazione che lo stava usando? La risposta può essere molto diversa da caso a caso. Un’organizzazione può avere soltanto output generati da un sistema esterno, oppure può avere metodo, dati, workflow, competenze, alternative e capacità di trasferire il processo altrove. Nel primo caso ha costruito velocità, ma anche fragilità. Nel secondo ha usato la tecnologia per accelerare un processo senza perdere il controllo della propria capacità operativa. È questa la distinzione che conta. L’AI può accelerare moltissimo un’attività, ma se tutta la capacità operativa resta agganciata a un singolo fornitore, la velocità iniziale può trasformarsi in dipendenza. Il punto non è la tecnologia in sé, ma la struttura della dipendenza che un’organizzazione costruisce quando incorpora strumenti esterni dentro processi rilevanti senza avere alternative, procedure di fallback e criteri chiari di sostituibilità. E quella struttura si decide prima che il servizio cambi, non dopo.