
OpenAI annuncia il ritiro dei GPT personalizzati e la migrazione ai plugin. Istruzioni e file passano, ma le azioni API vanno ricostruite: date e rischi.
I GPT personalizzati di ChatGPT saranno ritirati e OpenAI vuole trasferire i loro flussi di lavoro nei plugin. L’annuncio dell’11 settembre 2026, pubblicato nelle note ufficiali di rilascio, riguarda tutti i piani, anche se disponibilità della migrazione e regole operative possono cambiare secondo l’account e l’organizzazione. Non è un addio immediato: i GPT già creati restano utilizzabili fino alla data applicabile. Ma è la fine annunciata di un’idea che sembrava destinata a durare: costruire un assistente dentro una versione privata e specializzata di ChatGPT.
La novità non consiste semplicemente nel cambiare un pulsante del menu. Un GPT personalizzato poteva raccogliere istruzioni, documenti e, nei casi più evoluti, azioni verso servizi esterni. Un plugin riunisce invece competenze riutilizzabili e applicazioni collegate, potenzialmente utilizzabili in più contesti. OpenAI sposta il centro dell’esperienza dall’assistente con una propria identità al pacchetto di capacità che la piattaforma può attivare quando servono. E ciò che viene presentato come semplificazione cambia anche il modo in cui il lavoro è distribuito, controllato e condiviso.
Conviene quindi distinguere tre domande: che cosa succede ai GPT esistenti, che cosa viene effettivamente trasferito e chi conserva il potere di decidere quali integrazioni funzionino. È su quest’ultimo punto, molto più della nostalgia per i GPT Store, che si misura l’effetto industriale della decisione.
Un GPT personalizzato era una configurazione stabile di ChatGPT: un insieme di istruzioni permanenti, conoscenze caricate dal creatore e strumenti selezionati. Per un avvocato poteva significare una procedura per classificare documenti; per un insegnante un tutor con un programma prestabilito; per una redazione un assistente con regole di stile, controlli e fonti di riferimento. Non era necessario addestrare un modello da zero. Bastava creare un ambiente di istruzioni intorno a quelli già disponibili.
La documentazione sui nuovi plugin descrive un’impostazione differente. Un plugin può includere una o più skill, cioè istruzioni e procedure ripetibili, oppure applicazioni connesse, oppure entrambe. Le prime spiegano come affrontare un compito; le seconde danno accesso, con autorizzazioni proprie, a documenti, calendari, sistemi aziendali e altre fonti. Non è semplicemente il ritorno dei vecchi plugin di ChatGPT: il nome oggi indica una confezione di strumenti e conoscenze più ampia.
È una scelta che segue la logica dei sistemi agentici: non serve necessariamente entrare ogni volta in un personaggio digitale diverso. La piattaforma può richiamare la procedura pertinente all’interno di un’attività, combinandola con altri strumenti. Questa è la direzione del prodotto; non significa però che ogni plugin venga automaticamente attivato o che ogni vecchio GPT trovi un equivalente perfetto.
L’11 settembre 2026 OpenAI ha annunciato il ritiro programmato, non la disattivazione dei GPT già pubblicati. La FAQ sulla migrazione, consultata per l’aggiornamento di questo articolo del 1° novembre, indica l’11 dicembre 2026 come data standard prevista per il termine del servizio. Per gli ambienti FedRAMP e per alcune organizzazioni Enterprise che ottengono una proroga approvata compare invece l’11 febbraio 2027. Le eccezioni non valgono automaticamente per qualsiasi azienda.
Il calendario richiede attenzione perché la possibilità di creare nuovi GPT è cosa diversa dalla possibilità di usare quelli esistenti. Nei workspace Enterprise interessati la creazione di nuovi GPT è terminata il 26 ottobre 2026, con esclusione delle aree FedRAMP. Chi ha un GPT non ancora migrato può continuare a modificarlo, secondo autorizzazioni e regole del proprio ambiente, fino al ritiro; dopo la migrazione, l’originale resta temporaneamente utilizzabile ma diventa di sola lettura.
Per gli account personali OpenAI segnala che non si possono creare nuovi GPT; la gestione delle possibilità di migrazione dipende dal piano e dagli avvisi mostrati nell’account. La data indicata sul sito di assistenza non autorizza a dare per certa la presenza dell’opzione di migrazione per tutti gli utenti. Una verifica pratica, prima di iniziare, è controllare il proprio account e lo spazio di lavoro in cui il GPT è stato effettivamente creato.
La migrazione usa l’ultima versione pubblicata del GPT: bozze e modifiche non pubblicate non vengono trasferite. Le istruzioni passano nel plugin come competenza; i file della base di conoscenza diventano file di riferimento; le applicazioni collegate vengono associate come app, quando supportate. Il modello che era stato selezionato nel GPT non conserva necessariamente la stessa configurazione. Sono dettagli importanti perché il risultato può sembrare simile, ma rispondere in modo differente alle stesse domande.
Il punto davvero delicato sono le azioni personalizzate. Un GPT poteva interrogare un gestionale, un catalogo privato o un’API tramite una configurazione costruita appositamente. OpenAI precisa che queste azioni non passano automaticamente al plugin. Bisogna trovare un’app già compatibile oppure ricostruire l’integrazione, talvolta attraverso un server MCP personalizzato, e poi verificarne permessi, autenticazione e risultati. Non basta che il testo delle istruzioni sia stato copiato per concludere che il flusso di lavoro funzioni ancora.
Immaginiamo un GPT che legge un ordine cliente e restituisce un preventivo, ma che prima consulta un listino aggiornato tramite API. Dopo la migrazione potrebbe continuare a spiegare splendidamente come si calcola il prezzo e non avere più accesso al listino. Il rischio è precisamente questo: uno strumento apparentemente coerente che perde, in silenzio, la capacità operativa da cui dipendeva il lavoro. Ecco perché OpenAI raccomanda di testare gli stessi prompt, includendo casi complessi, prima di dismettere il vecchio ambiente.
Nel nuovo modello applicazioni, dati e azioni non vengono autorizzati una volta per tutte dal semplice fatto di installare un plugin. Ogni servizio connesso mantiene le proprie regole di accesso. Se il plugin deve leggere file aziendali, utilizzare il calendario o scrivere su una piattaforma esterna, servono le autorizzazioni previste da quel servizio e, nei casi sensibili, anche le approvazioni dell’utente o dell’amministratore. La guida ufficiale ai plugin presenta queste differenze come parte della struttura del prodotto, non come un’opzione cosmetica.
Questo spostamento può rendere più chiara la separazione fra conoscenza, istruzioni e potere di agire. Può anche moltiplicare i punti da controllare: un plugin può funzionare in un contesto, essere bloccato in un altro, oppure attivare soltanto alcune delle competenze previste. Per i team che delegano operazioni ripetitive, la qualità di un assistente non è più soltanto la qualità della risposta, ma la catena di autorizzazioni che produce quella risposta e le eventuali modifiche ai dati.
È lo stesso problema affrontato da Terza Pillola nella guida sulla sicurezza degli agenti AI. Un agente che legge informazioni e uno che può modificarle non pongono le stesse domande. Separare gli strumenti dal personaggio del chatbot può aiutare a governarne i permessi, purché l’utente sappia davvero quale capacità sta per essere eseguita.
La migrazione modifica anche la distribuzione. Il plugin creato a partire da un GPT è inizialmente privato: gli utenti che potevano accedere al vecchio assistente non ottengono automaticamente il sostituto. In un ambiente gestito la condivisione richiede le autorizzazioni dell’organizzazione; rendere pubblico un plugin personale prevede un percorso separato. Vale persino quando il GPT originario era stato distribuito ampiamente e tutti ne conoscevano il link.
Per chi crea strumenti di lavoro, questa è una conseguenza meno evidente della perdita di un’interfaccia. Un workflow può dipendere da un gruppo di colleghi, da una biblioteca di prompt comuni o da utenti esterni che nessuno ha censito. Se non si ricostruiscono gli accessi, l’automazione continua a esistere ma le persone che ne avevano bisogno non riescono più a utilizzarla. OpenAI chiarisce inoltre che poter usare un GPT creato da altri non concede il diritto di migrarlo: l’operazione spetta al creatore e, dove consentito, agli amministratori.
La questione mostra quanto conti l’intermediazione già descritta nel dossier sulla platform economy degli agenti AI. Una piattaforma non possiede necessariamente i contenuti e le procedure inventate dagli utenti; controlla però le modalità con cui possono essere distribuiti, scoperti e azionati. Quando cambia il contenitore, può cambiare anche la platea che riesce a utilizzare il contenuto.
Chi gestisce un solo assistente con istruzioni semplici può cavarsela con un controllo limitato: salvare la versione definitiva, migrare quando l’opzione appare e confrontare alcune risposte. Chi ha costruito procedure professionali dovrebbe invece eseguire un inventario dei GPT, individuare proprietario e utenti, annotare file e servizi collegati, verificare quali strumenti hanno capacità di scrittura e conservare prompt di prova con risultati attesi. Non è una precauzione astratta: sono precisamente le dipendenze che il passaggio di piattaforma rischia di interrompere.
Nel caso di workflow basati su API, occorre separare l’eventuale migrazione delle istruzioni dal ripristino dell’integrazione. Dopo il passaggio è utile ripetere una sequenza completa: lettura del dato, elaborazione, produzione del risultato, eventuale scrittura autorizzata e controllo finale. Vale anche per gli strumenti editoriali: un GPT che produce un file XML formalmente corretto può non recuperare più le fonti, i metadati o le tassonomie che usava prima, quindi limitarsi a testare il titolo di un articolo sarebbe insufficiente.
Chi utilizza GPT altrui ha invece un problema di dipendenza: non può decidere la migrazione del prodotto che usa. Deve verificare se il creatore ha predisposto una versione sostitutiva, se il proprio piano ne consente l’uso e se i collegamenti a servizi esterni restano accessibili. Non esiste una garanzia automatica di continuità neppure per gli assistenti pubblici più conosciuti. Nella pratica, il passaggio da una configurazione a un servizio implica anche una nuova gestione dei rapporti fra creatori, utenti e amministratori.
La spiegazione ufficiale è che plugin, skill e applicazioni possono riunire più facilmente istruzioni e strumenti in un unico flusso di lavoro. È una ragione tecnologica plausibile. Ma la decisione mostra anche una trasformazione del mercato: il valore si sposta dalla personalità dell’assistente all’orchestrazione di capacità, dati e accessi. Il modello linguistico diventa un componente della catena, mentre la piattaforma che decide quando attivare le procedure acquista centralità.
Non significa che i GPT fossero più liberi per definizione: dipendevano già da ChatGPT e dalle sue regole. Significa che una forma di distribuzione, costruita e popolata dagli utenti, può essere sostituita dall’architettura scelta dal fornitore. I file possono migrare, le istruzioni possono sopravvivere e perfino le vecchie conversazioni possono restare consultabili. Ma i collegamenti operativi, i permessi e il pubblico vanno ricostruiti.
Il paradosso è che i GPT personalizzati erano nati per dare agli utenti la sensazione di possedere un piccolo assistente su misura. Nel momento in cui diventano davvero utili, perché sanno lavorare con file, servizi e procedure, OpenAI sposta il loro futuro dentro un sistema di componenti più controllabile dalla piattaforma. La buona notizia è che molte competenze potranno essere recuperate. Quella meno rassicurante è che possedere le istruzioni non è mai equivalso a possedere l’infrastruttura che le esegue.