Il 9 aprile 2026, OpenAI ha pubblicato sul proprio blog l'annuncio di dismissione di Sora 1, il modello generativo video di prima generazione, con un preavviso di 90 giorni. Switch off effettivo: 8 luglio 2026. Migrazione consigliata: Sora 2 Turbo, prezzi diversi, API parzialmente compatibile, capacità diverse.
Per i consumer che usavano Sora per creare clip su TikTok, è stata un fastidio. Per le agenzie pubblicitarie e le aziende che avevano integrato Sora 1 in pipeline di produzione automatizzate — generazione di B-roll per content marketing, varianti video per A/B testing, automazione di asset video per cataloghi e-commerce — è stato un problema serio.
Non è il primo caso. È la quarta dismissione di un modello in un anno (dopo GPT-4 base, davinci-003, Codex). E non sarà l'ultima. È utile fermarsi e capire cosa significa, davvero, per chi mette l'AI nei processi produttivi.
Il preavviso di 90 giorni è un pattern, non una garanzia
OpenAI — come tutti i provider di AI proprietaria — pubblica policy di dismissione che prevedono di solito 90 o 180 giorni di preavviso. Il problema è che non sono contrattualmente vincolanti per gli utenti standard: sono best practice, non SLA. Per ottenere garanzie scritte servono contratti enterprise dedicati, tipicamente con minimi di spend annuali a sei cifre.
Per la tua agenzia da 12 persone, per il tuo studio fotografico che ha automatizzato la generazione di mood board, per il tuo ufficio marketing che produce 200 banner al mese — quei contratti enterprise non sono un'opzione. Hai 90 giorni e basta.
Le tre forme di lock-in che il marketing nasconde
Quando un fornitore parla di "facilità di switch", sta parlando della superficie tecnica: l'API è documentata, ci sono SDK, puoi cambiare provider con poche righe di codice. Tutto vero. Ma il lock-in vero non è lì.
1. Lock-in di prompt
Ogni modello risponde diversamente allo stesso prompt. Hai passato sei mesi a calibrare frasi, esempi few-shot, system instructions specifiche per il comportamento di GPT-4o. Cambiare modello significa rifare quella calibrazione da zero. Per un agente complesso (un assistente legale, un ticket router, un classificatore di documenti), si parla di settimane di lavoro per riportare la qualità a livelli accettabili.
2. Lock-in di pricing
Quando hai costruito il business case del tuo prodotto sul costo dei token di un modello, e quel modello viene dismesso a favore di uno che costa il 40% in più, il margine evapora. Devi rivedere prezzi, contratti con i clienti finali, magari rifiutare casi d'uso che prima erano sostenibili.
3. Lock-in di capability
I modelli non sono fungibili. Sora 1 generava clip da 60 secondi a 1080p; Sora 2 Turbo arriva a 30 secondi a 720p (più veloce, più economico per generazione, ma diverso). Se il tuo prodotto era costruito sul caso d'uso "clip da 60 secondi", devi cambiare il prodotto, non solo l'API.
Cosa NON significa "evitare il lock-in"
La reazione facile dopo questi episodi è: "internalizziamo tutto, on-premise, modelli open-weight, mai più un provider esterno". È una reazione sbagliata almeno la metà delle volte. Ne abbiamo parlato in un articolo dedicato: l'on-premise non è gratis, richiede competenze, ha senso sopra certi volumi e per certi profili di dato.
Evitare il lock-in non significa non usare mai modelli proprietari. Significa progettare i sistemi sapendo che ogni modello è una commodity sostituibile, e che la tua proprietà intellettuale deve stare nel layer sopra il modello, non nel modello.
Cinque pratiche concrete per ridurre l'esposizione
- Astrai sempre il provider. Mai chiamare direttamente l'SDK OpenAI/Anthropic/Google nel codice di business. Crea uno strato sottile (anche 50 righe) che riceve un prompt e restituisce una risposta, e che dietro può parlare con qualunque provider. Quando il modello cambia, cambi una sola classe.
- Versiona prompt e valutazioni come codice. I prompt sono asset. Devono stare in git, avere test, avere una suite di valutazione automatica (anche semplice: 30 esempi rappresentativi con output atteso o rubrica di qualità). Quando devi switchare modello, fai partire la suite e vedi subito cosa si rompe.
- Tieni un piano B sempre pronto. Il tuo prodotto deve avere almeno due provider configurati anche se ne usi uno solo. Cambia il provider in dev una volta al mese per dieci minuti — saprai se il fallback funziona prima di averne bisogno.
- Usa modelli open-weight per i casi a basso rischio. Riassunti, classificazione semplice, tagging, estrazione strutturata — funzionano benissimo con Llama 3.x o Qwen su una GPU media. Lasci i provider proprietari per i casi davvero sopra il limite del tuo modello locale. Riduci esposizione e costi insieme.
- Negozia clausole di continuità con i clienti. Se vendi un servizio AI a un cliente B2B, includi nel contratto la clausola che il modello sottostante può essere sostituito da un equivalente in caso di dismissione, e che la qualità è garantita su KPI specifici (non su modello specifico). Sembra ovvio, lo trascurano in molti.
"Quando un fornitore decide quando il tuo prodotto smette di funzionare, non hai un prodotto. Hai un canale di rivendita." — un nostro cliente del settore agency, dopo la dismissione di davinci-003 nel 2024.
Cosa abbiamo fatto noi nei nostri prodotti
Celeris (RAG), Nexus (knowledge graph), Automata (agenti) sono progettati con un layer di astrazione che permette di sostituire il modello sottostante in mezz'ora. Per i clienti enterprise, di default usiamo modelli open-weight su infrastruttura italiana. Per casi specifici dove serve un modello frontier (es. ragionamento avanzato su documenti complessi), facciamo girare l'inferenza via provider proprietario, ma con il fallback locale sempre attivo: se il provider diventa indisponibile o cambia condizioni, il sistema continua a rispondere con qualità accettabile.
È più lavoro? Sì, all'inizio. Ma quando un fornitore spegne un servizio con 90 giorni di preavviso, lo gestisci con un cambio di configurazione e una notte di test — non con una settimana di emergenza che blocca lo sviluppo del prodotto.
Sora 1 dismissed by July 2026 è un campanello. Suonerà ancora, e per modelli più centrali. La domanda da farsi adesso non è "cosa fare quando succede al mio business case", è "cosa farò il giorno in cui succederà al modello che ho integrato nel prodotto". Se non hai una risposta in mezz'ora, hai un problema.