Per scegliere uno strumento AI parti dal risultato: ti serve una risposta, un metodo riutilizzabile, un file completo o un’attività svolta dentro i sistemi aziendali? Poi considera le fonti necessarie, i passaggi da eseguire e le autorizzazioni richieste. La scelta diventa più chiara quando puoi descrivere anche come verificherai il risultato.
Chat, GPT personalizzati, agenti e Work intervengono a livelli diversi e possono collaborare nello stesso processo. Questa guida usa la terminologia di ChatGPT e propone criteri operativi per il lavoro IT. Con GPT intendiamo qui un GPT personalizzato; Work indica ChatGPT Work. Gli esempi aziendali sono proposte didattiche Take Two, non integrazioni già installate o risultati misurati.
Una mappa per orientarsi
| Esigenza | Punto di partenza | Risultato da chiedere |
|---|---|---|
| Capire un problema o mettere a fuoco un’idea | Chat | Spiegazione, ipotesi distinguibili, domande da chiarire |
| Applicare spesso lo stesso metodo a materiali diversi | Istruzioni riutilizzabili in un GPT, una skill o un plugin | Stessa struttura e criteri di verifica ripetibili |
| Portare più fonti e passaggi a un risultato completo | Work | File, analisi o attività pronta per la revisione |
| Collegare letture e azioni dentro un processo applicativo | Un agente con strumenti e controlli definiti | Esito dell’attività e riferimenti per verificarla |
| Eseguire regole e calcoli già noti | Script o automazione tradizionale | Output deterministico, errori espliciti e test |
La tabella è un criterio di scelta, non una divisione rigida delle funzioni. Puoi iniziare in Chat, formalizzare le istruzioni e far eseguire il lavoro in un ambiente operativo. Il modello usato, gli strumenti disponibili e il processo di controllo sono scelte distinte.
Chat per capire e preparare una decisione
Usa Chat per domande, esplorazione, bozze brevi e confronto. La documentazione OpenAI indica Work quando vuoi delegare un’attività con un esito verificabile. Entrambe le modalità possono usare plugin: controlla ciò che è effettivamente disponibile, senza dedurlo dal nome della modalità. Chat e Work nella documentazione ufficiale.
Se ricevi l’errore «invio vendite in timeout», puoi chiedere di organizzare i controlli da fare. Fornisci messaggio, servizio, orario e informazioni già raccolte. Chiedi una tabella che separi sintomi, ipotesi ed evidenze necessarie. Il risultato atteso è un percorso di indagine; la causa deve ancora essere confermata dai sistemi.
Chat è sufficiente quando il passaggio successivo resta nelle tue mani e non serve recuperare molte fonti o produrre un artefatto articolato. Una conversazione ben impostata può far emergere anche che manca un dato indispensabile prima di scegliere qualsiasi automazione.
GPT e istruzioni riutilizzabili per stabilizzare il metodo
Un GPT personalizzato può raccogliere istruzioni, riferimenti e capacità per un compito ricorrente. La documentazione attuale descrive la transizione dei GPT personalizzati a plugin e skill; le azioni personalizzate richiedono ricostruzione separata. Verifica il percorso disponibile nel tuo workspace prima di progettare una nuova soluzione su questa funzione. Guida ufficiale alla migrazione.
Per esempio, il team vuole preparare sempre le note sugli incidenti con cinque sezioni: sintomo, cronologia, interventi eseguiti, esito osservato e domande aperte. Vale la pena conservare quelle istruzioni, alcuni esempi e i criteri di verifica, invece di riscriverli a ogni richiesta.
Aspettati una maggiore uniformità del metodo, da controllare su casi concreti. Documenti superati o istruzioni ambigue possono produrre risposte uniformi ma sbagliate. Assegna un responsabile al metodo e aggiorna i riferimenti quando cambiano le procedure.
Work per arrivare a un risultato completo
Work è adatto a un incarico con più passaggi e un risultato da rivedere, usando file, plugin e strumenti approvati. Sul desktop può lavorare anche con risorse locali quando disponibili. Piano, ambiente e configurazione determinano le capacità effettive. Introduzione ufficiale a ChatGPT Work.
Un incarico concreto potrebbe essere: «Usa i CSV di questa cartella per preparare il report della giornata. Verifica casse attese, duplicati e revisioni. Crea HTML e una sintesi per il responsabile, con riferimenti ai dati. Fermati prima di inviare email».
Il risultato atteso comprende file, controlli eseguiti e problemi ancora aperti. Se la connessione al sistema sorgente non è disponibile, il lavoro può limitarsi ai file forniti: la richiesta non crea automaticamente l’integrazione mancante. E se vuoi una ripetizione giornaliera, va configurata una pianificazione; la creazione di un report oggi non significa che verrà prodotto anche domani.
Agenti per collegare strumenti e azioni
Un agente combina un modello con istruzioni e capacità operative; può scegliere passaggi e usare strumenti entro i controlli del suo ambiente. La documentazione OpenAI suggerisce di iniziare con un agente focalizzato e aggiungere specialisti quando cambiano responsabilità, strumenti o politiche di approvazione. Definizione degli agenti.
Per aprire ticket da alert, un agente può preparare la descrizione e chiamare un’integrazione autorizzata. Il flusso deve però validare l’evento, riconoscere lo stesso episodio e registrare l’identificativo della pratica. Il risultato atteso non è soltanto «ticket aperto», ma una pratica effettivamente presente e collegata all’evento corretto.
Una catena con passaggi sempre uguali può essere gestita da codice tradizionale. Usa la componente agentica dove serve interpretare materiali variabili, scegliere tra strumenti consentiti o gestire un’eccezione. Sommare CSV, validare campi o confrontare revisioni resta un buon compito per funzioni deterministiche.
Quando concatenare gli strumenti
Una chain è una sequenza in cui ogni fase consegna un risultato alla successiva. È utile quando permette di verificare un passaggio, limitare un’autorizzazione o separare lavori con criteri diversi. Non richiede per forza un agente per ogni fase.
Puoi iniziare passando manualmente un risultato verificato da una fase alla successiva. Per automatizzare il passaggio serve un coordinatore: codice, un motore di workflow o una funzione del prodotto realmente disponibile. Selezionare più GPT o aprire più conversazioni non crea da solo un flusso automatico.
Gli esempi seguenti sono proposte di progettazione. Nel caso multiagente, la documentazione OpenAI distingue uno specialista che prende in carico il lavoro da uno che opera come capacità delimitata sotto un coordinatore. Orchestrazione e passaggi tra agenti.
Esempio di report casse
- Una connessione in sola lettura acquisisce i riepiloghi e l’elenco delle casse attese.
- Uno script valida i file, sceglie le revisioni e calcola importi e copertura.
- L’AI scrive una sintesi usando i risultati calcolati, conservando i dati mancanti.
- Un controllo confronta periodo, importi e perimetro della sintesi con il report.
- La distribuzione segue una regola distinta, con destinatari e autorizzazioni definiti.
Il calcolo può continuare a funzionare anche quando la sintesi AI non riesce. I 295 scontrini del nostro esempio non devono essere ricalcolati da ogni agente: vanno trasmessi con la loro definizione e la copertura di tre casse su quattro. Puoi provare la parte deterministica nel laboratorio report casse da CSV.
Esempio di ticket da monitoring
Il ricevitore autentica l’evento e identifica l’episodio. La componente AI prepara il testo. Regole definite stabiliscono gruppo e priorità. Il connettore crea o aggiorna la pratica, poi il sistema verifica l’esito. Il componente che scrive la descrizione non ha bisogno di poter cancellare ticket o modificare le regole di assegnazione.
Un tentativo ripetuto dopo un timeout deve riconoscere la pratica eventualmente già creata. La chain deve quindi conservare un identificativo stabile e distinguere «nessuna risposta ricevuta» da «azione non eseguita». Esempio completo sull’apertura dei ticket.
Esempio di plugin di monitoring
Chat aiuta a chiarire cosa misurare. Un ambiente di lavoro prepara codice e test da una specifica. Le prove verificano soglie, output e dati mancanti. La revisione confronta il codice con quei requisiti. Il rilascio passa attraverso un’autorizzazione separata sull’ambiente di destinazione.
Chi genera il plugin può scrivere nella cartella di sviluppo senza ricevere accesso amministrativo ai server di produzione. Se l’obiettivo è ottenere un prototipo, il risultato corretto è codice verificabile; il prototipo non equivale a un controllo già installato. Guida allo sviluppo di un plugin.
Definire il contratto tra una fase e l’altra
Passa informazioni strutturate, con significato e stato espliciti. Per un report, il contratto può includere periodo, valuta, unità degli importi, casse attese e complete, risultati disponibili, fonti e identificativo dell’esecuzione. Per un ticket può includere episodio, asset, sintomo, evidenze e stato dell’operazione.
Il componente successivo deve sapere cosa fare se il contratto è incompleto. Un valore mancante non diventa zero; un’ipotesi non diventa causa confermata; un tentativo di creazione non diventa ticket aperto. Ogni fase verifica i prerequisiti che le servono prima di proseguire.
Stabilisci anche cosa accade dopo un errore: numero massimo di tentativi, scadenza, coda di verifica e responsabile. Il tempo di un’attività comprende recuperi, approvazioni e correzioni, oltre alla generazione della risposta. Aggiungere componenti può introdurre altri punti di guasto: la separazione deve rendere il processo più controllabile.
Valutare le autorizzazioni
Considera separatamente disponibilità dello strumento, account collegato, diritti sui dati e possibilità di eseguire azioni. Rendere disponibile un plugin non collega automaticamente un account. Una connessione condivisa può avere diritti diversi da quelli della persona che avvia il lavoro. Accessi e connessioni in Work.
Le scelte della tabella sono proposte Take Two per un progetto pilota. Vanno confrontate con i controlli effettivamente offerti dal prodotto e dalle applicazioni coinvolte.
| Attività | Accesso iniziale proposto | Condizione per estendere il perimetro |
|---|---|---|
| Capire un errore | Estratti pertinenti forniti dall’utente | Serve una fonte aggiuntiva identificata |
| Preparare il report casse | Lettura dei riepiloghi necessari e scrittura nella cartella di output | Sono definiti destinatari e regole di distribuzione |
| Generare un plugin | Cartella di sviluppo e ambiente di test | Test e revisione completati, rilascio autorizzato |
| Preparare un ticket | Lettura dell’evento e creazione di una bozza | Assegnazione, duplicati ed errori risultano gestiti |
| Pubblicare o inviare | Destinazione specifica e contenuto verificato | Approvazione o regola operativa esplicita |
Prima di concedere un permesso, chiediti: quali dati verranno letti? Quali oggetti potranno essere modificati? Dove potrà uscire il risultato? Per quanto tempo serve l’accesso? Chi potrà revocarlo e verificare le azioni? Una lettura può già esporre informazioni sensibili: limitarla a una fonte pertinente ha valore anche quando nessun file viene modificato.
Scrivere «non cancellare» nelle istruzioni non elimina tecnicamente una capacità di cancellazione. Dove il sistema lo permette, limita account, cartelle, ambienti e azioni disponibili. Per attività ricorrenti definisci inoltre un proprietario, un perimetro di esecuzione e criteri per fermare il flusso.
L’approvazione deve riguardare un’azione concreta: contenuto, destinazione, oggetti interessati e impatto. I controlli automatici validano dati o operazioni; la revisione umana decide se consentire il passaggio sensibile. Controlli e approvazioni nella documentazione OpenAI.
Il materiale recuperato da email, pagine e log resta materiale da analizzare. Non deve autorizzare nuovi accessi o azioni. E un secondo agente non è automaticamente un revisore indipendente: può condividere il primo errore. Affianca alla revisione evidenze originali, test e controlli sul sistema destinatario.
Misurare ciò che ottieni
Confronta il nuovo flusso con il lavoro attuale su un piccolo insieme di casi, scelti per coprire situazioni normali, dati mancanti, duplicati, errori e azioni non consentite. Valuta quanto lavoro di correzione resta e se l’esito è verificabile. Non attribuire una percentuale di risparmio senza misurarla.
| Tipo di lavoro | Criterio di accettazione proposto |
|---|---|
| Spiegazione o diagnosi | Le affermazioni rilevanti hanno evidenze o sono indicate come ipotesi |
| Report | Totali, periodo e copertura corrispondono alle fonti |
| Plugin | I test verificano requisiti ed errori, oltre al caso favorevole |
| Apertura ticket | La pratica esiste, è correlata all’evento e non è duplicata |
| Invio o pubblicazione | La destinazione ha ricevuto la versione approvata |
Registra durata complessiva, correzioni, esecuzioni fallite, azioni duplicate e costi del processo. Considera anche connettori, tentativi ripetuti e verifiche umane. Se cambia modello, istruzioni o integrazione, ripeti i casi più importanti. Per workflow sviluppati con API, OpenAI documenta l’uso di tracce ed eval per esaminare strumenti, passaggi e regressioni. Valutazione dei workflow agentici.
Scegliere il primo passo
Descrivi un risultato e un criterio di accettazione. Se basta un confronto, parti da Chat. Se il metodo ricorre, rendi riutilizzabili le istruzioni. Se occorre completare un’attività con più fonti, valuta Work. Se il lavoro deve entrare in un processo applicativo, definisci strumenti, regole e controlli dell’agente. Mantieni in codice i passaggi che dipendono da regole precise.
Costruisci prima il percorso più semplice che puoi verificare. Aggiungi una fase quando risolve un’esigenza concreta: nuove fonti, competenze diverse, calcoli, limiti di accesso o approvazioni. Il risultato da perseguire è un processo comprensibile che il team sappia usare, correggere e mantenere.
Puoi iniziare con il corso sui prompt strutturati o con gli articoli pratici per le attività IT. Le funzioni dei prodotti sono riferite alla documentazione consultata il 13 ottobre 2026; disponibilità e controlli vanno verificati nel proprio piano e workspace.