L’hosting di ChatGPT MCP Server sposta il deployment in Sites, ma l’accesso resta il confine

ChatGPT ora supporta un flusso di lavoro ChatGPT MCP server in grado di creare, ospitare e distribuire strumenti tramite Sites, senza richiedere un provider di hosting separato. Il cambiamento elimina uno dei maggiori ostacoli pratici legati al Model Context Protocol, o MCP, che consente ai client AI di richiamare strumenti esterni attraverso un’interfaccia condivisa.

Un post pubblico di Tibo Thibault ha evidenziato la funzionalità il 1° ottobre 2026. La documentazione attuale di OpenAI conferma il flusso di lavoro sottostante. Un utente può chiedere a ChatGPT o Codex di aggiungere un MCP server a un Site, pubblicarlo e installare il plugin risultante.

Questo rende l’annuncio più significativo di un semplice aggiornamento di un website builder. Finora, un tipico ChatGPT MCP server richiedeva codice, un endpoint accessibile da Internet, infrastruttura di deployment e un processo di connessione separato. Sites riunisce diversi di questi passaggi in un unico ambiente conversazionale.

La sfida importante, quindi, non è ChatGPT contro un altro modello. È il deployment gestito e guidato dai prompt contro il percorso MCP convenzionale in self-hosting. OpenAI ha accorciato il tragitto da un’idea a uno strumento installato, ma autorizzazioni, test e distribuzione determinano ancora se quello strumento sia utile.

Cosa cambia con l’hosting di ChatGPT MCP Server

ChatGPT Sites può ora fungere sia da superficie applicativa sia da host per gli strumenti MCP utilizzati tramite un plugin.

ChatGPT Sites è l’ambiente di OpenAI per creare e pubblicare siti web interattivi e applicazioni leggere. Gli utenti descrivono ciò che desiderano, esaminano un’anteprima generata, richiedono revisioni e distribuiscono il risultato a un URL di Site.

Il nuovo elemento è la possibilità di aggiungere strumenti lato server a quel Site. La guida di Sites di OpenAI afferma che gli utenti possono chiedere a ChatGPT o Codex di aggiungere un MCP server a un Site nuovo o esistente. Devono descrivere le informazioni che tali strumenti possono leggere e le modifiche che possono apportare.

MCP è un protocollo per esporre strumenti e dati a client AI compatibili. Il server descrive le operazioni disponibili, i relativi input e output. ChatGPT può quindi richiamare tali operazioni quando un utente formula una richiesta pertinente.

Un proprietario di Site potrebbe creare, ad esempio, una dashboard di progetto e aggiungere strumenti per leggere le milestone e aggiornarne lo stato. La pubblicazione del Site crea un plugin associato che espone tali strumenti nelle conversazioni ChatGPT e Codex supportate.

Questa sequenza comprime diversi lavori che in precedenza erano separati:

• L’utente definisce il flusso di lavoro desiderato in una conversazione.

• ChatGPT o Codex crea il Site e i relativi strumenti MCP.

• Il proprietario esamina il Site e ne testa il comportamento.

• La pubblicazione produce un Site live e il suo plugin associato.

• L’utente installa e connette quel plugin.

• ChatGPT può richiamarne gli strumenti nelle conversazioni successive.

Il Site resta più di un’interfaccia statica. Può contenere informazioni, presentare una vista interattiva e fornire le operazioni esposte tramite MCP. L’esempio di OpenAI descrive un manuale del team con strumenti per cercarne e accedervi ai contenuti.

Questo schema si adatta anche a tracker di progetto, directory interne, calendari di lancio, strumenti di ricerca documentale e dashboard operative. Un team potrebbe combinare l’approccio con una base di conoscenza ricercabile, a condizione che dati e autorizzazioni siano progettati con attenzione.

Il proprietario deve pubblicare il Site prima che compaia il plugin associato. Anche l’aggiunta o la modifica degli strumenti richiede un’altra pubblicazione prima che tali cambiamenti diventino disponibili. Una bozza salvata non modifica silenziosamente il plugin live.

OpenAI descrive Sites come una beta pubblica. È disponibile per i workspace ChatGPT, gli account Plus e gli account Pro, anche se il rollout potrebbe non raggiungere ogni account contemporaneamente. Gli amministratori dei workspace possono controllare i diritti di creazione e pubblicazione.

L’URL di deployment è un URL di produzione. OpenAI consiglia ai creator di salvare una versione e rivedere le modifiche prima del deployment. Questa distinzione conta perché l’editing conversazionale può sembrare informale anche quando il software risultante ha utenti reali.

Il risultato è un percorso di deployment sensibilmente più breve. Non elimina le operazioni software, ma ne trasferisce molte in un prodotto gestito e in un flusso di lavoro conversazionale.

Perché il deployment guidato dai prompt mette pressione al percorso self-hosted

Sites trasforma il deployment MCP da un progetto infrastrutturale a un’attività di configurazione del prodotto per molti flussi di lavoro più piccoli.

Un deployment MCP remoto convenzionale richiede ancora un server funzionante raggiungibile da ChatGPT sulla rete Internet pubblica. Lo sviluppatore deve implementare gli strumenti, esporre un endpoint HTTPS, configurare l’autenticazione e mantenere il servizio disponibile.

Il quickstart MCP di OpenAI illustra questo percorso. Gli sviluppatori installano un software development kit MCP, creano un server, espongono un endpoint /mcp e connettono l’URL pubblico tramite i controlli per sviluppatori di ChatGPT.

Questo resta il percorso appropriato quando un team necessita di infrastruttura personalizzata, integrazioni complesse, scalabilità indipendente o controllo sul runtime. Offre inoltre agli sviluppatori autorità diretta su pianificazioni di deployment, log, networking e archiviazione dei dati.

Tuttavia, molti strumenti interni non iniziano con tali requisiti. Nascono da richieste ristrette, come cercare in un manuale, aggiornare una milestone o recuperare un record di progetto. Il lavoro infrastrutturale può superare l’ambito funzionale della prima versione.

ChatGPT Sites punta a colmare questa lacuna. Un utente può descrivere il Site, i suoi dati e le operazioni che ChatGPT dovrebbe eseguire. Codex può quindi generare il livello di strumenti necessario e collegarlo a un plugin installabile.

Questo non rende irrilevante la conoscenza ingegneristica. Cambia il punto in cui tale conoscenza diventa necessaria.

La prima versione può emergere attraverso una creazione guidata anziché tramite uno stack di deployment assemblato manualmente. L’attenzione ingegneristica può spostarsi verso confini degli strumenti, autorizzazione, gestione degli errori e qualità dei dati.

Questo è il rovesciamento centrale. MCP è stato progettato per standardizzare le connessioni, eppure gestire un server continuava a creare attrito per chi desiderava soltanto un flusso di lavoro mirato. OpenAI ora utilizza un host gestito per ridurre questo onere operativo.

La pressione ricade anzitutto sui modelli di hosting leggeri e sui prototipi interni. Uno sviluppatore potrebbe non avere più bisogno di un progetto cloud separato solo per verificare se un flusso di lavoro con tre strumenti risolva un problema reale.

La pressione raggiunge anche i builder AI no-code e low-code. ChatGPT ora collega specifica conversazionale, generazione dell’applicazione, hosting e installazione del plugin in un unico ambiente account. Questo riduce la distanza tra un prototipo e uno strumento ChatGPT utilizzabile.

Tuttavia, il self-hosting conserva vantaggi significativi. Un Site gestito non offre automaticamente la flessibilità di deployment, l’osservabilità, la portabilità o la capacità richieste da ogni sistema di produzione.

OpenAI applica inoltre limiti di utilizzo specifici per piano durante la beta pubblica. Tali limiti coprono Sites a livello di account e possono influenzare la capacità di creare Sites, aggiungere spazio di archiviazione o mantenere un Site molto utilizzato pubblicamente disponibile.

La documentazione invita gli utenti a controllare i limiti visualizzati nel proprio account. Non fornisce una capacità fissa valida universalmente.

Questa incertezza impedisce una conclusione semplice secondo cui Sites sostituisca l’hosting MCP convenzionale. Crea invece un’impostazione predefinita gestita per deployment più piccoli o in fase iniziale.

Gli sviluppatori dovrebbero considerare i due percorsi come impegni operativi differenti:

• Gli strumenti ospitati su Site privilegiano velocità, deployment integrato e un flusso di lavoro guidato.

• Gli strumenti self-hosted privilegiano controllo dell’infrastruttura, architettura personalizzata e operazioni indipendenti.

• I plugin ospitati su Site ereditano i controlli di account e workspace di OpenAI.

• I server self-hosted ereditano comunque i requisiti di connessione, autorizzazione e revisione di ChatGPT.

Per molti team, la scelta dipenderà meno dalla generazione del codice che dalla governance. Creare uno strumento MCP sta diventando più facile. Decidere chi possa richiamarlo resta la decisione di prodotto più difficile.

Come il Site diventa un plugin installabile

Il flusso di lavoro collega un Site pubblicato a un plugin, ma installazione e autorizzazione restano passaggi distinti.

La guida all’hosting di OpenAI descrive una sequenza specifica. Il creator parte da un Site di sua proprietà, chiede a ChatGPT o Codex di aggiungere strumenti MCP, li esamina e pubblica il Site.

Dopo il completamento della configurazione MCP, ChatGPT presenta una scheda del plugin associata a quel Site. Il creator può esaminare la scheda, selezionare Install e completare il flusso di connessione.

Il plugin installato può quindi essere menzionato in una conversazione ChatGPT o Codex supportata. ChatGPT può anche selezionare un plugin installato quando corrisponde alla richiesta dell’utente.

Questo passaggio di packaging è importante perché un endpoint MCP grezzo e un’esperienza ChatGPT distribuibile non sono identici. Il plugin fornisce un’unità riconoscibile che gli utenti possono installare, trovare, selezionare e gestire.

I plugin possono includere skill, applicazioni connesse, strumenti supportati da MCP ed estensioni interattive. Un’applicazione MCP ospitata su Site diventa un componente all’interno di questo sistema di packaging più ampio.

L’attuale directory dei plugin appare su ChatGPT web, desktop e mobile. Tuttavia, OpenAI avverte che le singole funzionalità possono variare in base a superficie, account, regione, piano, ruolo e configurazione del workspace.

Questa precisazione è importante. La presenza di un plugin nella directory non garantisce che ogni strumento o vista inclusi funzioni in modo identico ovunque.

Le applicazioni MCP locali illustrano la distinzione. OpenAI afferma che un’applicazione locale può essere eseguita tramite un plugin su ChatGPT Desktop. Salvare quel plugin in un account non rende i suoi strumenti locali disponibili sul web o su mobile.

L’hosting su Site affronta questa limitazione fornendo un runtime remoto. Anche in questo caso, il supporto preciso del plugin sulle varie superfici dipende dalle funzionalità incluse e dall’attuale disponibilità del prodotto.

Il Site associato ha anche un proprio modello di accesso. Un destinatario potrebbe aver bisogno del permesso per visualizzare il Site, del permesso per usare il plugin e dell’autorizzazione per qualsiasi servizio connesso.

L’installazione del plugin non aggira questi livelli. Condividere un Site da solo non condivide il plugin, e condividere un plugin non concede accesso a dati non correlati.

Questa separazione protegge da un’assunzione facile ma pericolosa. Il fatto che uno strumento sia installabile non significa che possa leggere tutto ciò che il suo creator può leggere.

Ogni utente potrebbe dover connettere un account idoneo. Quando un Site accede ad applicazioni connesse, i visitatori usano le proprie connessioni e i propri permessi esistenti.

Si consideri una dashboard di progetto connessa a un issue tracker. Il Site potrebbe mostrare le issue assegnate ed esporre un’azione di aggiornamento. Un destinatario dovrebbe vedere solo i record consentiti dal proprio account dell’issue tracker.

Lo stesso principio si applica a repository di documenti, record dei clienti e manuali interni. Il Site fornisce l’interfaccia e gli strumenti ospitati, ma il servizio sottostante rimane un confine di autorizzazione.

Questo modello crea un percorso più pratico verso strumenti personali e per workspace. Introduce inoltre un problema di troubleshooting multilivello quando l’accesso non riesce.

Una chiamata a uno strumento non riuscita può dipendere da Sites, dalla connessione del plugin, da un ruolo nel workspace, dall'applicazione sottostante o dall'account del provider dell'utente. I creatori dovranno testare ogni livello in modo indipendente.

L'esperienza di installazione rappresenta quindi un reale progresso del prodotto, ma non una portabilità universale. OpenAI ha unificato il flusso di creazione e packaging mantenendo domini di sicurezza distinti.

Le autorizzazioni sono il confine del prodotto

La funzionalità più forte del nuovo flusso è anche il suo rischio maggiore: uno strumento generato conversazionalmente può compiere azioni reali.

I creatori devono decidere se ciascuno strumento si limita a leggere informazioni o può anche modificarle. Un'operazione di ricerca e un'operazione di aggiornamento possono apparire una accanto all'altra, ma comportano conseguenze operative diverse.

OpenAI invita i creatori a esaminare i contenuti di Sites e il comportamento degli strumenti prima di condividere l'accesso. Chiede in particolare di valutare se gli utenti debbano solo leggere i dati o anche eseguire azioni di scrittura.

L'accesso in scrittura può includere la modifica di una milestone, la creazione di un record, l'invio di informazioni o l'aggiornamento di contenuti archiviati. Queste operazioni richiedono un controllo più rigoroso di quanto possa suggerire un'interfaccia generata.

Un'anteprima rifinita di Sites non dimostra che le sue regole di accesso siano corrette. Non dimostra nemmeno che ogni input produca l'azione lato server prevista.

I creatori dovrebbero testare record rappresentativi, livelli di autorizzazione, dati mancanti, input non validi e azioni negate. Dovrebbero inoltre verificare i risultati aprendo Sites dopo che uno strumento ha eseguito una modifica.

I controlli Enterprise aggiungono un ulteriore livello. OpenAI afferma che diverse autorizzazioni dei plugin possono essere gestite in modo indipendente, tra cui l'uso dei plugin, il caricamento dei plugin, la creazione di plugin con MCP, la condivisione dei plugin e la loro pubblicazione in una directory del workspace.

Alcune autorizzazioni sono disattivate per impostazione predefinita negli ambienti Enterprise. Un amministratore potrebbe dover abilitare il ruolo pertinente prima che un creatore possa pubblicare un Site o condividere il suo plugin.

Questo design limita la distribuzione accidentale, ma può anche far apparire la funzionalità incoerente tra gli account. Un utente potrebbe creare e installare subito uno strumento, mentre un altro potrebbe non vedere i controlli necessari.

L'accesso pubblico merita ancora maggiore attenzione. L'affermazione sociale originale suggeriva che un creatore potesse limitare uno strumento a persone selezionate o condividerlo con il mondo. La documentazione ufficiale supporta la condivisione controllata nel workspace e un percorso separato per la pubblicazione pubblica.

Non descrive la condivisione di plugin personali come universalmente aperta. Gli utenti Pro e degli account personali al momento non possono invitare direttamente altri utenti ChatGPT a un plugin ospitato su Sites tramite un link di condivisione.

I membri Business ed Enterprise possono condividere con i colleghi, nel rispetto delle autorizzazioni del workspace. I destinatari devono avere accesso sia al plugin sia al relativo Site, quindi devono installarlo e connetterlo autonomamente.

La distribuzione tramite directory pubblica segue un processo diverso. Gli sviluppatori inviano un plugin per la revisione, soddisfano i requisiti di identità e autorizzazione e pubblicano solo dopo l'approvazione.

I requisiti di revisione di OpenAI richiedono un endpoint MCP reale e accessibile pubblicamente per gli invii remoti. La revisione può esaminare schemi degli strumenti, schemi di sicurezza, annotazioni, gestione dei dati utente e comportamento previsto.

Le linee guida per la revisione distinguono inoltre tra operazioni di sola lettura, distruttive e open-world. Queste classificazioni influenzano il modo in cui i revisori comprendono il comportamento e i rischi di uno strumento.

Uno strumento non può diventare di sola lettura semplicemente perché la sua descrizione lo definisce innocuo. Le annotazioni dichiarate e il comportamento effettivo devono coincidere.

Questo standard conta per gli strumenti generati da Sites tanto quanto per i server codificati manualmente. La creazione in linguaggio naturale può ridurre lo sforzo di implementazione, ma non può sostituire un modello di sicurezza accurato.

La principale questione irrisolta è quanto affidabilmente i creatori comuni riusciranno a riconoscere confini non sicuri degli strumenti. Gli sviluppatori sanno che una funzione di aggiornamento apparentemente piccola può attivare sistemi a valle o esporre campi sensibili.

Gli utenti meno tecnici potrebbero concentrarsi sul fatto che il flusso di lavoro funzioni. Potrebbero non esaminare campi di risposta superflui, effetti collaterali indiretti o regole di autorizzazione incoerenti.

Il flusso gestito di OpenAI può fornire protezioni, ma la documentazione assegna comunque al creatore la responsabilità dei test. Indica ai proprietari di esaminare gli strumenti, testare dati di esempio e controllare i risultati prima della condivisione.

Questo rende la governance il vero vincolo all'adozione. Uno strumento utile necessita sia di una capacità chiara sia di un confine di autorizzazione difendibile.

I casi d'uso dei server MCP di ChatGPT iniziano in piccolo

I migliori utilizzi iniziali sono flussi di lavoro circoscritti, con limiti sui dati evidenti, azioni reversibili e risultati che gli utenti possono ispezionare.

Un manuale del team è l'esempio più chiaro di OpenAI. Un Site può presentare il manuale, mentre gli strumenti MCP consentono a ChatGPT di cercarne i contenuti e recuperare sezioni pertinenti durante una conversazione.

Questo caso d'uso dispone di un corpus definito e di un output relativamente semplice. Il creatore può confrontare la risposta di ChatGPT con il Site sottostante e identificare informazioni mancanti o errate.

Un dashboard di progetto offre un secondo modello. Gli strumenti di lettura potrebbero recuperare milestone, responsabili, blocchi o scadenze. Uno strumento di scrittura controllato potrebbe aggiornare lo stato di una milestone dopo la conferma dell'utente.

Questo flusso offre una verifica visibile. L'utente può riaprire il dashboard e confermare che il record richiesto sia cambiato correttamente.

Gli strumenti per trovare documenti offrono un altro punto di partenza pratico. Un Site potrebbe esporre strumenti che cercano nelle cartelle approvate, restituiscono titoli corrispondenti e aprono record a cui l'utente corrente può accedere.

Questi strumenti diventano più preziosi se abbinati a una buona organizzazione delle informazioni. Un flusso di lavoro della conoscenza personale o di team dipende comunque da materiale di origine accurato, autorizzazioni stabili e confini di recupero chiari.

Anche directory interne, calendari di lancio e report sullo stato si adattano al modello. Ciascuno può utilizzare un piccolo insieme di strumenti con input delimitati e output comprensibili.

I flussi di lavoro a rischio più elevato richiedono maggiore cautela. Uno strumento che invia messaggi, elimina record, pubblica contenuti, modifica autorizzazioni o avvia processi esterni può produrre conseguenze al di fuori del Site.

Tali azioni dovrebbero esporre parametri chiari e richiedere una conferma appropriata. I creatori dovrebbero evitare di combinare un ampio accesso ai dati con un'ampia autorità di scrittura in un unico prototipo iniziale.

Il Site dovrebbe inoltre mostrare uno stato sufficiente affinché gli utenti possano verificare i risultati. Una conferma conversazionale non è una prova sufficiente che un'azione esterna sia stata completata correttamente.

Qui l'hosting di server MCP di ChatGPT si differenzia da un generatore di siti web convenzionale. L'output non è soltanto contenuto o codice di interfaccia. Può diventare un partecipante operativo nelle conversazioni future.

Questo crea un effetto cumulativo. Una volta installato, il plugin può essere selezionato ogni volta che ChatGPT lo ritiene pertinente, oppure quando un utente lo menziona direttamente.

I metadati sono quindi importanti. I nomi e le descrizioni degli strumenti dovrebbero rendere chiaro l'ambito previsto. Descrizioni ambigue possono far selezionare lo strumento sbagliato o incoraggiare richieste inadatte.

L'ambiente gestito cambia anche l'iterazione. I creatori possono chiedere a ChatGPT o Codex di aggiungere un nuovo strumento, rivedere un'azione esistente o modificare l'interfaccia del Site.

Queste modifiche non diventano automaticamente attive. Il proprietario deve pubblicare nuovamente il Site, quindi confermare che il plugin esponga la versione prevista dello strumento.

Questo requisito di pubblicazione crea un utile punto di controllo. I team possono esaminare le capacità modificate prima che raggiungano gli utenti.

Tuttavia, crea anche potenziale confusione tra versioni. Una bozza di Site, un Site pubblicato e un plugin installato potrebbero non riflettere sempre lo stesso comportamento previsto.

I team dovrebbero mantenere semplici note di rilascio, casi di test nominati e un proprietario per ciascuno strumento. Anche un piccolo plugin interno trae beneficio dal sapere quale versione gli utenti stiano attualmente invocando.

Il miglior primo progetto non è quindi l'assistente più ampio immaginabile. È un flusso di lavoro mirato per il quale il proprietario può rispondere chiaramente a quattro domande:

• Quali informazioni può leggere lo strumento?

• Cosa può modificare lo strumento?

• Chi può invocarlo?

• Come possono gli utenti verificare il risultato?

Se queste risposte restano vaghe, una distribuzione più rapida porta soltanto prima l'incertezza in produzione.

Tre segnali mostreranno se Sites cambierà l'adozione di MCP

Il prossimo test non riguarda quanti Sites verranno generati, ma quanti strumenti ospitati diventeranno flussi di lavoro affidabili e ripetibili.

Il primo segnale è l'affidabilità tra le diverse superfici. OpenAI afferma che la directory dei plugin è disponibile sul web, desktop e mobile, mentre le singole funzionalità possono variare tra queste superfici.

Bisogna osservare se gli strumenti ospitati su Sites si comportano in modo coerente su ciascun client supportato. Installazione, autorizzazione, selezione degli strumenti e output coerenti rafforzerebbero la tesi di Sites come livello generale di distribuzione MCP.

Differenze persistenti tra le superfici indebolirebbero questa tesi. I creatori dovrebbero comunque progettare aspettative separate per utenti desktop, web e mobile.

Il secondo segnale è l'adozione nel workspace. Gli ambienti Business ed Enterprise offrono condivisione controllata, ma gli amministratori regolano le autorizzazioni richieste.

Bisogna osservare se le organizzazioni abilitano la creazione di Sites, la creazione di plugin MCP e la condivisione nel workspace per ampi gruppi di dipendenti. Un'adozione oltre i team di sviluppo dimostrerebbe che la distribuzione conversazionale risponde a una reale esigenza operativa.

Politiche predefinite restrittive produrrebbero il risultato opposto. Sites potrebbe restare uno strumento per prototipi se i team di sicurezza non riescono a verificare con sicurezza azioni generate e dati connessi.

Il terzo segnale è la qualità dei plugin pubblici. La distribuzione privata e la pubblicazione pubblica sono percorsi diversi, e l'invio alla directory include una revisione formale.

Bisogna osservare i plugin supportati da Sites che passano da esperimenti personali a prodotti pubblici approvati. La loro affidabilità, le informative sulla privacy, le pratiche di supporto e la soddisfazione degli utenti metteranno alla prova il modello gestito in presenza di una domanda reale.

Un flusso costante di strumenti approvati rafforzerebbe l'affermazione di OpenAI secondo cui Sites può supportare qualcosa di più delle dimostrazioni interne. Ripetuti fallimenti nelle autorizzazioni o comportamenti poco chiari degli strumenti rivelerebbero i limiti della distribuzione guidata da prompt.

L'incertezza rimanente è quindi pratica, non concettuale. OpenAI ha documentato il flusso di creazione, hosting, pubblicazione, installazione e condivisione. Il meccanismo è reale.

Ciò che non è ancora stato stabilito è quanto bene gestisca traffico sostenuto, autorizzazioni complesse, debug operativo e manutenzione a lungo termine tra molti creatori.

Per gli sviluppatori, la mossa immediata è testare un flusso di lavoro delimitato rispetto al percorso convenzionale self-hosted. Confrontate tempi di configurazione, chiarezza delle autorizzazioni, diagnosi degli errori, controllo degli aggiornamenti e copertura dei client.

Per gli acquirenti enterprise, la priorità è la governance. Esaminate quali ruoli possono creare strumenti, chi approva le azioni di scrittura, come si comportano gli account connessi e quali prove ricevono gli utenti dopo le modifiche.

Per i knowledge worker, l'opportunità è diretta. Un utile dashboard interno o una raccolta di riferimenti può ora diventare uno strumento conversazionale senza iniziare come progetto infrastrutturale autonomo.

Il cambiamento dei server MCP di ChatGPT conta perché la distribuzione si sta avvicinando alla richiesta stessa. La domanda decisiva è se i team riescano a mantenere accesso, test e proprietà altrettanto vicini. Scegliete un flusso di lavoro ristretto, definite i suoi confini prima di crearlo e testatelo con utenti che dispongono di autorizzazioni diverse. Queste prove riveleranno se Sites sia soltanto un hosting più rapido o una nuova via durevole per creare strumenti di IA.