Corso Prompt Engineering e GPT Custom: progettare sistemi LLM affidabili

In sintesi. Il corso di prompt engineering e progettazione di GPT custom di DNArt è un percorso da otto ore in aula per team che devono mettere un modello linguistico dentro un processo che produce fatture, e che oggi si fermano perché l’output non è mai due volte uguale. Al termine il team sa produrre output che un sistema può consumare senza revisione manuale, guardrail numerici che impediscono a un numero sbagliato di uscire, e un GPT custom blindato end-to-end. Non è un corso sui «dieci prompt che cambiano la vita». Il corso è un percorso di progettazione: si impara a trattare un modello linguistico come un componente di sistema, non come un oracolo da ispirare. Otto ore, materiale proprietario in otto capitoli, laboratorio finale su un GPT custom blindato end-to-end. Chi partecipa esce con output strutturati che una macchina può consumare, guardrail numerici e una gestione esplicita del «non lo so». Erogato in aula, sui casi di chi partecipa.

Corso di prompt engineering e progettazione di GPT custom, erogato da DNArt. Pubblicato il 23 agosto 2026 · Ultimo aggiornamento 23 agosto 2026 · A cura di Stefano Giurin, fondatore di DNArt, agenzia attiva a Faenza dal 2001.

Formato, prezzo e come si parte

• Formato base: otto ore in aula, divisibili in due mezze giornate, presso la tua sede o da remoto.
• Partecipanti: fino a una quindicina. L’edizione che abbiamo erogato al Gruppo Atomix il 5 giugno 2026, dal nostro registro d’aula DNArt, contava tredici partecipanti su otto ore.
• Prezzo: una giornata da otto ore in azienda sta fra 2.500 e 4.500 € (IVA non dovuta), listino DNArt in vigore dal 23 agosto 2026. Dove cade dipende da tre cose: durata, numero di partecipanti e sede. Per confronto, l’altro percorso in aula, Alfabetizzazione AI per studi professionali, stesso formato da otto ore in presenza, è a listino a 4.200 € perché comprende anche il kit di conformità e la verifica a trenta giorni.
• Come si parte: mezz’ora di call per capire su quali processi lavorerete, poi il preventivo con programma e date.

Finora abbiamo portato questo format in quattro contesti diversi: un’azienda (Gruppo Atomix, tredici persone), una scuola superiore a indirizzo grafico, un ente di formazione professionale (CefF Faenza) e professionisti singoli. Prenota 30 minuti e ti dico subito se il corso serve davvero o se il problema è a monte. In alternativa scrivimi a info@dnart.it.

Il problema: il prompt engineering ridotto a una raccolta di frasi efficaci

Per troppo tempo il prompt engineering è stato raccontato come una collezione di formule magiche, buone per stupire in una demo. Questa riduzione a formulario è limitante e, quando l’obiettivo è portare gli LLM dentro processi reali, anche pericolosa: più il contesto è critico, più l’illusione crolla.

Un Large Language Model non va ispirato. Va progettato.

La differenza si vede subito quando qualcosa va storto. Quando un modello «sembra capriccioso» quasi sempre non lo è: sta reagendo a istruzioni incomplete, ambigue o in conflitto. Se pensi al prompt come a un testo da rifinire stilisticamente, ottieni sistemi fragili e difficili da mantenere. Se lo pensi come a un progetto, puoi governarlo nel tempo: obiettivo, confini, criteri di qualità, fallback, test di regressione.

La bussola del corso è una frase sola: in produzione non vince la risposta migliore, vince quella che non tradisce. Meglio un output meno brillante ma stabile di uno geniale che fallisce sui casi limite.

Cosa si impara davvero

L’ambiguità è il nemico reale

Gran parte degli errori attribuiti ai modelli nasce da ambiguità non risolte: date senza anno («questo trimestre»), unità non dichiarate («crescita del 10» rispetto a cosa?), perimetri vaghi. Un prompt professionale incorpora un principio operativo semplice: se l’input è ambiguo, il sistema fa fino a tre domande di chiarimento prima di rispondere. Non è un freno, è controllo qualità — un modello che chiede chiarimenti è più affidabile di uno che riempie i vuoti.

Le tre tipologie di prompt, e perché confonderle costa caro

Usare il prompt sbagliato nel contesto sbagliato genera instabilità e perdita di fiducia. Il caso tipico è chiedere a testo libero un output destinato a una dashboard: il modello sembra «quasi giusto», ma in produzione «quasi» significa parser rotto e report che salta.

La checklist a cinque voci

1. Scopo — cosa deve produrre e per chi.
2. Confini — cosa non deve fare, e come comportarsi quando glielo chiedono.
3. Formato — struttura dell’output, campi obbligatori, nessun campo extra.
4. Gestione dell’incertezza — regola sui dati mancanti: null, domanda o errore.
5. Criteri di qualità — brevità, completezza, tono, priorità.

Se questi cinque punti sono chiari, il prompt smette di essere una frase e diventa un progetto. La checklist è la parte più semplice del corso ed è quella che i partecipanti riutilizzano il giorno dopo.

Output strutturati: il controllo passa dal formato

Il linguaggio naturale, quello con cui scriviamo i prompt, è ambiguo per costruzione, e in un sistema probabilistico l’ambiguità diventa variabilità dell’output. Definire un formato riduce le risposte ammesse e aumenta la prevedibilità: quando chiedi struttura non stai limitando l’AI, stai guidando l’entropia.

In aula si lavora sui tre formati che coprono quasi tutti i casi professionali. Le tabelle, dove colonne fisse equivalgono ad aspettative chiare e costringono a distinguere dato, metrica e interpretazione. Le liste tipizzate, che funzionano solo se ogni elemento ha la stessa funzione semantica. E il JSON, che è un contratto vero fra il modello e il sistema che ne consuma l’output: o rispetta lo schema o fallisce, e questo è un vantaggio.

Da questo principio nasce una regola che in azienda fa la differenza: se un output deve essere usato da un sistema, non va pensato per un umano. La leggibilità viene dopo la validabilità.

Ragionamento: quando serve e quando è solo rumore

Negli ultimi anni si è diffusa l’idea che forzare il ragionamento passo-passo migliori sempre la qualità. È una semplificazione pericolosa: il ragionamento è una leva, non un valore assoluto, e un errore inserito in una catena apparentemente logica diventa più credibile — quindi più dannoso.

• Chain-of-Thought (Wei et al., 2022) — utile quando il problema è multi-step, gli step sono controllabili e l’esito dipende da una catena di trasformazioni. Spesso conviene farlo ragionare internamente e restituire solo l’esito con una breve verifica. Su copy e sintesi strategiche non aumenta l’accuratezza: aumenta la retorica.
• Self-consistency (Wang et al., 2022) — più soluzioni indipendenti confrontate fra loro per abbattere l’errore casuale. Potente ma costosa in token e tempo: si usa sugli output critici, non su tutto.
• ReAct (Yao et al., 2022) — il modello non immagina il mondo, ci interagisce tramite strumenti: ragiona, agisce, osserva, aggiorna. ReAct è il ponte verso le architetture composite e gli agenti AI veri.

Guardrail numerici: mai matematica a mente

Un numero sbagliato mina la credibilità più in fretta di qualsiasi errore testuale. E un LLM lasciato libero produce il valore più plausibile, non quello corretto: accettabile nel linguaggio, inaccettabile su KPI, percentuali, ROI e forecast.

La regola madre è la separazione dei ruoli: il modello interpreta e spiega, uno strumento deterministico calcola. Somme, medie, variazioni, CAGR: tutto delegato a Python o a un foglio di calcolo, anche le operazioni banali. In aula si vede anche la parte che quasi nessuno affronta — il parsing: separatori decimali ambigui, valute non dichiarate, periodi impliciti producono risultati formalmente corretti e semanticamente sbagliati. Se un dato non è valido, il sistema non calcola: segnala l’errore.

Anti-allucinazioni: progettare il «non lo so»

L’allucinazione di un modello linguistico non si elimina con una raccomandazione («non inventare»). Si riduce progettando il comportamento in assenza di informazione: prima si consultano i documenti forniti, e se l’informazione non c’è il sistema lo dichiara invece di riempire il buco con conoscenza generica. Il grounding è lo stesso principio che rende affidabile un assistente su normative e documenti tecnici, dove un’invenzione dall’aria sicura è il rischio peggiore.

GPT custom: da demo a prodotto

Un GPT custom, quello che in azienda chiamereste «assistente su misura», non è una conversazione intelligente: è un comportamento incapsulato e ripetibile, più vicino a un prodotto software che a una chat. La maggior parte fallisce perché nasce senza confini, senza criteri di qualità e senza gestione dei casi limite — brillante in demo, fragile il lunedì mattina.

Un GPT senza scope è una demo. Non è un prodotto. Se non definisci il perimetro, il modello lo inventa — e lo fa in modo probabilistico.

Nel corso si progettano i sette elementi non negoziabili: missione e pubblico con un criterio di successo; scope e soprattutto fuori-scope, con l’alternativa da offrire quando si rifiuta; gerarchia delle istruzioni, perché senza priorità il modello non sa risolvere i conflitti; routine operative ripetibili; schema di output come contratto di integrazione; guardrail tecnici e comportamentali; grounding sui documenti. Il laboratorio finale mette tutto insieme su un GPT blindato end-to-end.

Il manuale: otto capitoli che restano ai partecipanti

Dai nostri dati d’aula. Nel nostro registro d’aula DNArt questo format risulta erogato finora in quattro contesti diversi: abbiamo tenuto la giornata da otto ore al Gruppo Atomix, in azienda, il 5 giugno 2026, su un campione di tredici partecipanti; poi con gli insegnanti di un liceo grafico sull’AI dentro la suite Adobe, con un’aula al CefF di Faenza e con alcuni professionisti senior in percorsi individuali. Il manuale lo riscriviamo dopo ogni edizione: quella in distribuzione è la versione del 23 agosto 2026.

Il corso non poggia su slide riassuntive ma su un manuale proprietario scritto da me, consegnato a chi partecipa. Sono otto capitoli, ed è l’indice a dire com’è fatto il percorso, perché si segue nell’ordine:

1. Fondamenta del prompt engineering moderno — dal prompt come frase al prompt come specifica.
2. Output strutturati — tabelle, liste tipizzate, JSON come contratto.
3. Ragionamento avanzato — quando serve e quando è solo rumore.
4. Architetture composite e multi-agent — scomporre invece di gonfiare un prompt solo.
5. GPT custom da demo a prodotto — i sette elementi non negoziabili.
6. Guardrail numerici — mai matematica a mente.
7. Anti-allucinazioni — progettare il «non lo so».
8. Laboratorio finale — un GPT blindato end-to-end.

Gli esempi non sono didattici: sono quelli che uso in aula. Dal capitolo 2, la forma di un output che un sistema può consumare — «Rispondi in JSON con i campi obbligatori: insight, rischio, azione. Non aggiungere campi extra. Se un valore non è disponibile, usa null. Se non puoi rispettare lo schema, segnala errore e fermati». Dal capitolo 6, il controllo che impedisce a un numero sbagliato di uscire — «Verifica invarianti numeriche. Se un check fallisce, segnala errore e interrompi l’output». Due righe che sono la differenza fra una demo e un componente di sistema.

Come è organizzato

• Durata — formato base otto ore, divisibile in due mezze giornate (programma d’aula DNArt, versione del 23 agosto 2026). Versioni più lunghe se si vuole più laboratorio.
• Dove — in presenza presso la tua sede o da remoto. In presenza rende molto di più nella parte di laboratorio.
• Partecipanti — gruppi fino a una quindicina di persone. Dal nostro registro d’aula DNArt: al Gruppo Atomix la giornata da otto ore è stata erogata il 5 giugno 2026 a un gruppo di tredici partecipanti, in azienda.
• Materiali — il manuale proprietario in otto capitoli, dalle fondamenta al GPT blindato, che resta ai partecipanti.
• Su cosa si lavora — sui vostri casi reali. Chi porta un documento o un processo vero esce con qualcosa che funziona, non con appunti.

Il preventivo dipende da durata, numero di partecipanti e sede: si definisce dopo una call, quando è chiaro su quali processi volete lavorare. Se invece quello che ti serve è mettere lo studio in regola con l’obbligo di alfabetizzazione AI, il percorso dedicato è Alfabetizzazione AI per studi professionali, che ha un listino pubblico.

Per chi è

È per team che hanno già superato la fase della curiosità: marketing e comunicazione che producono contenuti a volume, uffici tecnici che lavorano su documenti, chi sta costruendo automazioni e si accorge che il pezzo fragile è sempre il prompt. Serve un minimo di dimestichezza con gli strumenti — chi non ha mai aperto ChatGPT parte dal percorso di alfabetizzazione.

Non è per chi cerca conferme sul fatto che l’AI risolva tutto da sola. Metà del corso serve a capire dove non arriva, e perché è meglio saperlo prima di metterla in un processo che produce fatture.

Se ti riconosci nella prima descrizione, prenota 30 minuti: in mezz’ora si capisce se il corso serve, e con quale taglio.

Chi lo eroga

Sono Stefano Giurin, fondatore di DNArt. Il percorso professionale, verificabile sul profilo LinkedIn: comunicazione dal 1994 come art director, DNArt attiva a Faenza dal 2001, SEO dal 2008, modelli linguistici dal lancio del primo ChatGPT nel novembre 2022. da allora insegno prompt engineering e costruzione di assistenti AI su misura. Sono autore di SEO: La Guida Pratica di Base, pubblicato nel 2024 (Amazon, ASIN B0CRBZ1MRT) e il profilo professionale completo è su LinkedIn. Il lavoro che faccio è raccontato anche fuori da qui: l’intervista su NDi.life è una fonte terza che si può leggere e verificare.

Corsi già erogati in aula, dal nostro registro d’aula DNArt: Gruppo Atomix (otto ore, tredici partecipanti), insegnanti di liceo grafico sull’AI nella suite Adobe, CefF Faenza, più percorsi individuali con professionisti senior. Il metodo che insegno è lo stesso che uso nei sistemi che costruisco per i clienti, dagli agenti AI alla produzione di contenuti.

Metodo e riferimenti

Le tecniche di ragionamento che vediamo in aula non sono opinioni di settore: hanno una letteratura, e in aula si cita quella. Il chain-of-thought è descritto in Wei et al., 2022; la self-consistency in Wang et al., 2022; il pattern ReAct, che sta sotto quasi tutti gli agenti in circolazione, in Yao et al., 2022. Sugli output strutturati il riferimento operativo è la documentazione Structured Outputs di OpenAI. Il resto — checklist a cinque voci, regola delle tre domande di chiarimento, sette elementi del GPT custom — è metodo mio, messo alla prova in aula e nei sistemi che DNArt costruisce per i clienti.

Domande frequenti

Serve saper programmare?

R: No. In aula si scrivono specifiche e schemi, non codice. L’unica parte che sfiora la programmazione è il concetto di schema JSON, che si impara in mezz’ora perché è una lista di campi con delle regole. Chi programma trova comunque materiale suo nella parte su guardrail e integrazione.

Va bene se in azienda usiamo Claude o Gemini invece di ChatGPT?

R: Sì. Il metodo è indipendente dal fornitore: ambiguità, formato, guardrail e grounding valgono su qualsiasi modello. Le differenze fra i tre strumenti si vedono in aula sui compiti reali dei partecipanti, senza tifoserie.

Il corso invecchia con l’uscita di nuovi modelli?

R: La parte di metodo no, ed è la maggior parte. Ambiguità, contratti di output, separazione fra linguaggio e calcolo, gestione dell’incertezza: sono principi di progettazione, non funzioni di prodotto. Invecchia il confronto fra strumenti, che infatti si aggiorna a ogni edizione.

Quanto è teorico?

R: Poco. Ogni blocco si chiude con un esercizio sui casi dei partecipanti e l’ultima parte è un laboratorio su un GPT custom completo. Chi porta un processo vero esce con la prima versione funzionante.

Vale come formazione ai fini dell’AI Act?

R: Contribuisce, ma non è la stessa cosa. L’art. 4 dell’AI Act chiede una misura documentata, quindi anche policy interna, registro firmato e tracciatura dell’uso. Quel pacchetto è il percorso di alfabetizzazione AI, che nasce apposta per essere dimostrabile.

Parliamone mezz’ora

Dimmi su quali processi vorreste usare gli LLM e ti dico se il corso serve davvero o se il problema è a monte. Prenota 30 minuti, oppure scrivimi a info@dnart.it.

Pagina pubblicata il 23 agosto 2026 e aggiornata il 23 agosto 2026. I dati sulle edizioni già erogate provengono dal registro d’aula DNArt; il riferimento economico citato è il listino DNArt in vigore alla stessa data, IVA non dovuta.