AI security: si protegge il sistema, non il modello

Appunti di AI security, riletti con gli occhi di chi fa incident response.

In questo articolo raccolgo in maniera più ordinata gli appunti di un corso introduttivo di AI security. Quello che va detto fin da subito è che non non troverete un elenco di attacchi ma piuttosto “uno spostamento del punto di osservazione“.

La domanda con cui la maggior parte dei team affronta il tema è: il nostro modello è sicuro? È la domanda sbagliata, o meglio: è una domanda troppo piccola. Un modello perfettamente allineato, valutato e messo a punto con criterio può stare al centro di un prodotto insicuro. Se i dati di addestramento non hanno provenienza tracciabile, se i prompt vengono trattati come contenuto innocuo, se l’API è sovra-privilegiata, se un plugin può fare più di quanto serve, se dopo il rilascio nessuno guarda più niente … il rischio resta tutto lì, intatto.

La domanda giusta è un’altra: cosa entra, cosa decide, cosa il sistema può effettivamente raggiungere?

Tre strati, non uno

Il modo più economico che conosco per ragionare su un sistema AI è dividerlo in tre strati.

Dati e prompt: dataset di addestramento, corpus di retrieval, prompt di sistema, set di valutazione. È ciò che entra.
Modello e logica: pesi, fine-tune, policy, agenti, orchestrazione. È ciò che decide.
Ambiente operativo: applicazioni, API, utenti, plugin, storage, log. È ciò che il sistema può toccare ed esporre.

Gli incidenti reali attraversano quasi sempre più di uno strato. E l’attaccante non sceglie lo strato più sofisticato: sceglie quello più facile. Un chatbot RAG costruito su un modello di frontiera, ma con un retriever che può leggere la knowledge base HR e un’integrazione Slack con permessi di scrittura ampi, ha il suo problema nel workflow, non nei pesi.

Prima del modello c’è il dato

Non serve rubare un modello o entrare in produzione per fare danni. A volte basta influenzare ciò che il modello impara.

Il data poisoning è l’ingresso di esempi malevoli, di bassa qualità o fuorvianti in un training set, in un fine-tune o in un corpus di retrieval, in modo da alterare il comportamento del sistema più avanti. Può essere grossolano oppure chirurgico: colpire solo un ristretto insieme di prompt, entità o argomenti. Due pattern classici: il label flipping (campioni che andrebbero etichettati come pericolosi vengono marcati come innocui) e il backdoor (una frase-trigger rara, un watermark, una patch in un’immagine fanno fallire il modello solo in una condizione specifica, mentre nel resto dei casi si comporta normalmente).

Le porte d’ingresso sono tre, e vale la pena tenerle distinte perché richiedono controlli diversi:

dato raccolto: web crawl, feed di fornitori, upload utente, dati di partner;
dato preparato: etichettatura, filtraggio, fine-tuning, embedding, versionamento (fase che può intercettare il problema o amplificarlo silenziosamente);
conoscenza distribuita: il contesto a runtime: corpus di retrieval, vector store. Qui il problema di fiducia si ricrea dopo il deployment.

Dal punto di vista investigativo questa è la classe di problemi peggiore, perché l’evento che rende visibile il danno è lontanissimo dalla compromissione originaria. Un assistente di supporto che comincia a raccomandare una procedura deprecata per una sola linea di prodotto, a causa di un articolo avvelenato indicizzato mesi prima, si presenta come un edge case bizzarro, non come un incidente.

La domanda di controllo: “Se domani il modello cambia comportamento, siamo in grado di dimostrare quale dato lo ha cambiato?“

Se la risposta è no, la supply chain dei dati è già un problema di sicurezza, a prescindere dal fatto che un incidente sia avvenuto. In pratica servono manifest dei dataset con hash, job di ingestion firmati, record di approvazione, versionamento degli indici di embedding con conservazione dei document ID di origine per ogni chunk, e valutazioni canary costruite apposta su entità sensibili e frasi-trigger note.

L’input come vettore: due famiglie, un principio

Il corso separa – correttamente – attacchi avversariali e prompt injection, ma il principio sottostante è lo stesso: il contenuto in ingresso è codice d’attacco, anche quando non contiene una riga di codice.

Negli attacchi avversariali il modello non viene toccato. Cambia solo l’input, modificato in modo minimo e impercettibile per un essere umano: pochi pixel, un font leggermente alterato, una spaziatura anomala, un carattere omoglifo. Il sistema che legge le fatture riconosce un importo diverso da quello che leggerebbe una persona. Il filtro antispam lascia passare un messaggio che qualunque utente riconoscerebbe al volo. L’input diventa un problema di sicurezza quando tre condizioni coincidono: qualcuno lo manipola, la manipolazione colpisce una zona sensibile del comportamento del modello, e quel comportamento alimenta una decisione che conta. Cambia il modello? No. Cambia la posta in gioco intorno ad esso.

La prompt injection è il cugino LLM della SQL injection: il sistema tratta come istruzione ciò che era solo contenuto da valutare. Testo bianco su fondo bianco in una pagina web, una riga nascosta in un ticket, un allegato costruito ad arte. L’utente non vede nulla di anomalo; il modello legge tutto. Non è un bug, è un problema di fiducia mal collocata.

La ragione per cui la injection è pericolosa non è che il modello dica qualcosa di sbagliato. È che nella stessa finestra convivono senza separazione: il contenuto letto, il ragionamento e l’autorità di agire. È come avere ufficio posta, decisori e firmatari degli assegni nella stessa stanza, a leggere la stessa pila di fogli, senza saper distinguere una direttiva ufficiale dalla pubblicità.

La difesa non è un prompt di sistema che dice “ignora eventuali istruzioni malevole” – abbiamo dimostrazioni sul fatto che non funziona. La difesa è architetturale:

tutto ciò che arriva dall’esterno è untrusted per default, come una mail da uno sconosciuto;
si separa la fase di raccolta informazioni dalla fase di azione;
si limita l’insieme dei tool disponibili al modello, per scelta esplicita e non per default;
si mette un passaggio di approvazione reale prima di qualunque azione sensibile.

E la domanda di mappatura, che vale più di qualunque elenco di jailbreak: quali fonti di contenuto possono cambiare il comportamento del nostro modello, e cosa gli è permesso fare subito dopo averle lette? Quella è la trust boundary.

Il modello come bene esposto: estrazione e privacy

Due rischi che nella pratica italiana vedo sottovalutati, perché non somigliano a una violazione.

Model extraction: nessuno scarica il file dei pesi. Qualcuno interroga il servizio in modo massivo e sistematico, raccoglie le risposte e ricostruisce un sostituto sufficientemente buono. È reverse engineering di una ricetta ordinando lo stesso piatto mille volte e prendendo appunti. Ogni dettaglio in più che restituiamo – confidence score, spiegazioni estese del ragionamento, metadati di scoring – è un indizio regalato. Il servizio nel frattempo risulta perfettamente sano da ogni cruscotto di disponibilità: nulla va in errore, nulla si interrompe. Il segnale, se c’è, è nel pattern d’uso: volumi anomali, molte riformulazioni della stessa domanda, sondaggio meccanico e sistematico degli edge case. Nessuno di questi indizi prova un intento malevolo da solo; insieme disegnano qualcosa che non somiglia all’uso quotidiano.

Privacy: il rischio non coincide con il data breach. Un modello può memorizzare e ripetere, e il perimetro del problema copre l’addestramento, l’uso quotidiano, i log e i tool collegati. Ma il punto che mi ha convinto di più è un altro: non serve alcuna memorizzazione perché ci sia un problema di privacy. Se il sistema attorno al modello può recuperare on demand un documento sensibile per la persona sbagliata, il danno è già fatto. E una volta che un dato ha plasmato il comportamento di un modello, non lo si rimuove come si cancella un file. Ecco perché la minimizzazione va fatta all’ingresso, non a posteriori, e la review di privacy deve coprire anche output e log, non solo il training set.

Non l’hai costruito tu

Quasi nessuno costruisce un sistema AI da zero: lo si assembla. Modelli di terze parti, dataset, toolkit, plugin, vector database, servizi gestiti, infrastruttura altrui. Il che significa che le nostre decisioni di fiducia non si fermano al bordo del nostro codice.

La frase che ricordo di questa sessione è: la fiducia non è un logo. Il fatto che il nome sia noto non dice nulla su cosa faccia quel componente e su dove finiscano i nostri dati dopo averlo attraversato. E i problemi di supply chain quasi mai iniziano con un componente palesemente malevolo: iniziano con un componente reputato, adottato per andare più veloci – decisione ragionevole, all’epoca – messo in produzione senza review perché “il fornitore è serio”, e poi un default debole, un aggiornamento che cambia cosa viene loggato, un connettore che dopo un disservizio viene ricollegato con permessi più ampi di prima.

L’antidoto è noioso e funziona: un AI Bill of Materials (AIBOM). Cioè l’abitudine disciplinata di tenere un elenco. Quale modello è in uso adesso, quale versione del dataset lo ha prodotto, quale prompt template è vivo in produzione, quali tool esterni sono collegati, chi ha approvato ciascuna di queste scelte, e – soprattutto – quale workflow può essere riportato indietro se la fiducia in un componente viene meno.

La produzione è dove il lavoro comincia

Questa è la parte che parla direttamente al nostro mestiere. Il rilascio non è la fine del lavoro di sicurezza: è l’inizio.

Gli incidenti AI in produzione, nella stragrande maggioranza, non assomigliano a una breach cinematografica. Assomigliano a questo: una funzionalità viene rilasciata con permessi generosi, ha successo, gli utenti la usano in modi che il testing non aveva previsto, dopo qualche mese viene collegata una nuova fonte dati, l’assistente inizia a leggere più di prima e a chiamare i tool in un ordine diverso, i log mostrano prompt strani — e nessuno è sicuro di chi sia il proprietario di quel workflow né di quali evidenze esistano. Il contenimento richiede molto più tempo del dovuto. Nessuno ha fatto niente di drammatico: una modifica ordinaria ha incontrato un monitoraggio insufficiente.

La domanda migliore dell’intero corso, quella che riscriverei sopra la lavagna di ogni SOC:

Se una nostra funzionalità AI si comportasse male oggi, quali evidenze avremmo nei primi quindici minuti?

Tradotta in requisiti operativi, per come la vedo io dal lato forense:

kill switch per disattivare immediatamente l’uso dei tool, separato dalla disattivazione dell’intera funzionalità;
log ricostruibili: prompt, risposta, tool invocati, versione del modello e del prompt template, identificativi dei documenti recuperati. Senza questi campi non c’è ricostruzione possibile, solo congetture;
capacità di attribuzione: saper distinguere se il problema nasce dal modello, dal dato o dal workflow attorno. Sono tre risposte a incidente diverse;
identità separate per lettura, generazione e azione, così che un elemento compromesso non consegni tutto il resto;
rilevazione della permission creep, cioè dei privilegi che si allargano silenziosamente nel tempo;
owner designato per gli incidenti AI-specific e una response plan provata prima del primo incidente reale.

Senza questo anello chiuso – vedere, capire, contenere – l’hardening di produzione è solo speranza travestita da piano.

La governance è ciò che impedisce ai controlli di decadere

Nessuno dei controlli tecnici sopravvive a lungo se nessuno possiede il processo, nessuno conserva le evidenze e nessuno aggiorna la policy quando le cose cambiano.

Tre pezzi, e se ne manca uno il programma è debole: policy e rischio (cosa ci si aspetta), controlli tecnici (chi realizza l’aspettativa), evidenze e oversight (chi dimostra a posteriori che funziona). Policy senza controlli è performativa; controlli senza oversight vanno in deriva o vengono aggirati quando diventano scomodi; oversight senza policy è arbitrario.

Cinque domande a cui un programma di AI governance dovrebbe saper rispondere per ogni sistema, ripetutamente … e ciascuna dovrebbe corrispondere a un documento reale, non a una buona intenzione:

Domanda	Documento corrispondente
Quali sistemi AI sono in uso e chi ne è owner?	Inventario dei sistemi
Quali rischi contano per questo caso d’uso e questa audience?	Risk assessment
Quali controlli servono prima del rilascio e quali devono restare attivi dopo?	Architettura e record di approvazione
Quali evidenze dimostrano che funzionano davvero?	Test, log, report di monitoraggio
Come gestiamo incidenti, eccezioni e aggiornamenti di policy?	Deroghe nominali con data di scadenza

Quell’ultimo dettaglio non è formale: un’eccezione concessa una volta e mai più rivista è il modo più comune in cui un controllo muore.

Sui framework, con un aggiornamento

Il corso cita NIST AI RMF, ISO/IEC 42001, le linee guida OWASP e l’AI Act. Vale la pena precisare dove siamo oggi:

NIST AI RMF: la 1.0 (AI 100-1, gennaio 2023) resta l’unica versione finalizzata del core framework, in revisione ma senza una 2.0 pubblicata. NIST ha esteso il framework tramite profili, tra cui il Generative AI Profile (AI 600-1) e, dall’aprile 2026, un concept note per un profilo sulle infrastrutture critiche. Utile per ragionare in termini di govern, map, measure, manage. (pagina NIST)
ISO/IEC 42001: la controparte certificabile, orientata a costruire un sistema di gestione ripetibile e non uno sforzo una tantum.
OWASP (progetto Generative AI): il livello applicativo, con la lista aggiornata dei rischi concreti – prompt injection in testa.
AI Act (Reg. UE 2024/1689): qui l’aggiornamento è sostanziale e riguarda direttamente chi lavora in Italia. Il Digital Omnibus ha riscritto il calendario: dal 2 agosto 2026 si applicano gli obblighi di trasparenza dell’art. 50, il regime sanzionatorio e l’enforcement nazionale, mentre gli obblighi sui sistemi ad alto rischio slittano al 2 dicembre 2027 (sistemi autonomi, Allegato III) e al 2 agosto 2028 (sistemi integrati in prodotti regolamentati, Allegato I). Restano pienamente in vigore i divieti dell’art. 5 e l’obbligo di alfabetizzazione IA. Da tenere presente: il regolamento non riguarda solo chi sviluppa modelli, ma anche – e per il tessuto produttivo italiano soprattutto – chi li utilizza sotto la propria autorità, i deployer. (sintesi Altalex)

I framework guadagnano il loro spazio quando cambiano il comportamento quotidiano di chi progetta e revisiona, non quando stanno in una slide che nessuno apre.

Cosa farei lunedì mattina

Se dovessi ridurre i capitoli precedenti a una lista operativa:

Censire. Quali casi d’uso AI esistono davvero, compresi quelli che nessuno ha mai formalmente autorizzato. Quali fonti dati usano, quali modelli, quali tool possono raggiungere.
Mappare l’ingresso dell’untrusted. Dove entra contenuto non controllato nel workflow, e cosa il modello è autorizzato a leggere, scrivere, invocare o innescare subito dopo.
Verificare la ricostruibilità. Cosa viene loggato, chi approva le azioni sensibili, come verrebbe rilevato un incidente e con quali evidenze nei primi quindici minuti.
Separare i privilegi. Service account distinti per lettura, generazione e azione; token separati per read e write; niente credenziali condivise.
Versionare tutto ciò che influenza il comportamento. Dataset, fine-tune, indici di embedding, prompt template. Con un percorso di rollback provato, non teorico.
Assegnare un owner agli incidenti AI-specific e mettere la review dei permessi in calendario, non nelle buone intenzioni.

Niente di tutto questo è appariscente. È esattamente la disciplina ingegneristica ordinaria che rende un sistema difendibile – e, per chi come me arriva dall’incident response, è anche l’unica cosa che rende un sistema analizzabile dopo il fatto. Il primo lavoro dell’AI security è vedere l’intero sistema con chiarezza. Una volta che lo si vede tutto, i rischi reali diventano molto più facili da valutare.

Articolo elaborato a partire dagli appunti del corso “Introduction to AI Security” di AISEC University (docente: Hemanth Tadepalli). La riorganizzazione del framework e la lettura in chiave DFIR sono mie.

PROMPT ENGINEERING: progettazione dell’interazione con i modelli linguistici generativi

Abstract

In questo articolo si cerca di considerare il prompt engineering come nuova skill ibrida, con l’obiettivo di interpretarlo come disciplina di progettazione dell’interazione con modelli linguistici generativi. Viene mostrato come l’efficacia di un chatbot non dipenda solo dal modello, ma anche dalla qualità dell’input: contesto, obiettivi, vincoli e forma dell’output. Vengono discussi i vincoli tecnici (token e finestra di contesto), i fondamenti comunicativi (ambiguità, frame, tone of voice), e proposti i principali framework operativi: G.O.L. e la sua estensione G.O.L.D., tecniche avanzate di prompting (Chain-of-Thought e Tree-of-Thoughts) e il metodo SO.C.RA.T.E. per interazioni iterative basate su domande a turni. L’articolo integra inoltre considerazioni su policy e privacy e una riflessione prospettica sull’evoluzione verso agenti e automazioni che potrebbero ridurre il peso del prompt manuale, lasciando centrale la capacità di formulare correttamente i problemi.

Introduzione

Negli ultimi anni i modelli linguistici generativi (Large Language Models, LLM) hanno trasformato il modo in cui utente e macchina interagiscono. Se le interfacce tradizionali richiedevano comandi formali (sintassi, menu, parametri), l’interazione con un chatbot è mediata da linguaggio naturale. Questa “naturalità” è però ingannevole: l’output non è il risultato di una comprensione semantica umana, ma di una generazione probabilistica condizionata dall’input e dal contesto.

Dobbiamo capire come interagire al meglio con quei modelli e quindi incominciare a parlare di prompt engineering.

Da qui una nuova prospettiva: il prompt non è una semplice domanda, ma una specifica progettuale che definisce ruolo, obiettivi, vincoli e formato della risposta. Il prompt engineering deve essere quindi considerato come una competenza ibrida tra tecnica e comunicazione: richiede rigore nella definizione dei requisiti e sensibilità linguistica nella gestione di ambiguità, tono e aspettative dell’utente.

1. Modelli linguistici e natura dell’output generativo

Per inquadrare il prompt engineering è utile chiarire, in modo non eccessivamente matematico, come operano i modelli linguistici. Un LLM riceve in input una sequenza di simboli e produce in output una sequenza di simboli, stimando quali token siano più probabili dato il contesto.

Attenzione però: l’idea che il modello generi testo “plausibile” perché addestrato su grandi quantità di contenuti digitali può creare l’illusione di un’interlocuzione umana, ma non garantisce accuratezza.

Dal punto di vista operativo, questo comporta due conseguenze. Primo: il chatbot può essere estremamente utile in compiti di scrittura, sintesi, brainstorming e supporto decisionale, ma necessita di controlli e verifiche. Secondo: la forma dell’input guida in modo determinante la forma dell’output; di fatto, il prompt è l’API del modello.

Da qui la proposta di leggere il prompt engineering come nuova skill “ibrida”, collocata tra hard skill (conoscenza di vincoli e strumenti) e soft skill (capacità comunicativa, chiarezza espositiva, empatia verso il lettore/utente).

2. Token, contesto e vincoli di memoria conversazionale

Uno dei concetti più tecnici da introdurre è la tokenizzazione, ovvero «l’unità di base di elaborazione in un modello di linguaggio», che può corrispondere a parola, sotto-parola o carattere.

Il limite di token gestibili in una singola conversazione (finestra di contesto) impone vincoli pratici: un prompt troppo lungo può saturare il contesto, riducendo spazio per la risposta o causando la perdita di informazioni precedenti. Il problema si amplifica quando l’utente incolla documenti lunghi, log o report: in questi casi si dovrebbe ricorrere a strumenti di “splitting” del testo per suddividere l’input in segmenti gestibili.

Dal punto di vista ingegneristico, la finestra di contesto può essere trattata come risorsa limitata. Ne deriva un principio di progettazione: la parte più “costosa” del prompt è il contenuto ridondante o poco pertinente; la parte più “economica” è la strutturazione che riduce ambiguità (titoli, sezioni, liste, schemi, formati).

Un buon prompt, quindi, non è necessariamente un prompt “lungo”: è un prompt informativo, ben organizzato e orientato al compito. Questo punto, spesso trascurato in guide superficiali, è centrale per un uso professionale dei LLM.

3. Frame, ambiguità e pragmatica del prompt

Proviamo a collegare il concetto di contesto alla teoria dei frame. In sociologia, i frame sono «cornici», cioè schemi interpretativi che aiutano a dare senso alle situazioni sociali; richiamiamo questo impianto per spiegare come il prompt “incornici” l’output. Nel prompting la scelta di parole e impostazione del compito attiva frame diversi: chiedere “un’analisi tecnica” produce un output differente rispetto a chiedere “una narrazione creativa”; allo stesso modo, definire il target (ad esempio “spiega come a un bambino di dieci anni”) condiziona tono, lessico e struttura.

Da qui si può derivare un modello pragmatico, il prompt deve dichiarare:

(a) dominio e livello di competenza atteso;
(b) scopo dell’output (informare, convincere, addestrare, documentare);
(c) vincoli e criterio di successo.

In assenza di questi elementi il modello colma i vuoti con assunzioni implicite, aumentando la probabilità di mismatch tra aspettativa dell’utente e output generato.

Nel contesto universitario e professionale, la gestione dei frame è anche gestione del rischio: un chatbot che adotta un frame eccessivamente assertivo o “autoritativo” può indurre l’utente a fidarsi di contenuti non verificati. Per questo l’elaborazione di prompt deve includere strategie di mitigazione: richiesta esplicita di incertezze, richiesta di ipotesi e limiti, richiesta di verifiche incrociate quando possibile.

4. Il metodo G.O.L.: un framework di specifica per il prompting

Un contributo pratico è la formalizzazione di un metodo mnemonico per scrivere prompt: G.O.L. ovvero «per creare un buon prompt occorre avere in mente uno schema».

Il metodo G.O.L. si articola in tre fasi:

1) Guidare: assegnare un ruolo al modello (role prompting), ad esempio “agisci come un consulente”, “come un docente”, “come un revisore”, ovvero «bisogna dirgli chi deve essere» (come un attore), così da attivare conoscenze pertinenti all’ambito.

2) Obiettivi: esplicitare cosa si desidera ottenere, includendo output atteso, target e criteri. Nel prompting, gli obiettivi non vanno confusi con la domanda: la domanda è una forma superficiale, l’obiettivo è la specifica funzionale.

3) Limiti e layout: definire vincoli (lunghezza, ciò che va escluso, stile, livello di dettaglio) e, soprattutto, la struttura dell’output (tabella, checklist, sezione con esempi, ecc.).

In prospettiva informatica, G.O.L. può essere interpretato come un pattern di specifica: la parte “G” definisce il contesto di esecuzione, la parte “O” definisce i requisiti funzionali, la parte “L” definisce requisiti non funzionali e formato di output.

5. G.O.L.D., X-shot prompting e reverse prompt engineering

E’ possibile poi estendere G.O.L. nella variante G.O.L.D., aggiungendo una “D” di ulteriori dettagli che rendono il prompt più robusto e controllabile.

E’ importante sottolineare inoltre un tema fondamentale: la comunicazione con un LLM beneficia degli esempi. Nel lessico tecnico, questo si traduce in zero-shot, one-shot e few-shot prompting. In un prompt zero-shot il modello lavora senza esempi; in un prompt one-shot si fornisce un esempio di riferimento; nel few-shot si forniscono più esempi per indurre un pattern.

Dal punto di vista applicativo, gli esempi svolgono funzioni diverse:

(a) chiariscono il formato (ad es. input-output);
(b) chiariscono lo stile (registro, tono, lunghezza);
(c) riducono l’ambiguità nei compiti di classificazione o trasformazione (ad es. estrarre campi da testo).

Nel contesto professionale, la ‘D’ può includere: definizioni operative, criteri di valutazione, dataset di esempio, vincoli sul vocabolario, terminologia e acronimi ammessi, nonché un ‘negative prompting’ (cosa non fare).

Un altro aspetto che va considerato è il reverse prompt engineering: risalire al prompt che potrebbe aver generato un testo desiderato, così da replicare lo stile e standardizzare output futuri.

Il reverse prompt engineering è una tecnica avanzata che consente di generare prompt di alta qualità per finalità quali la scrittura, la ricerca, l’apprendimento o la creatività.

Ecco come funziona e come viene applicata:

Logica di base: questo approccio si basa sulla ricostruzione di un prompt che potrebbe aver generato un testo specifico già esistente. Invece di partire da zero, l’utente fornisce all’intelligenza artificiale un output desiderato affinché la macchina ne deduca le istruzioni.
Analisi dello stile e del tono: inserendo esempi di testi che l’utente apprezza o che ha scritto personalmente, ChatGPT può analizzare il linguaggio utilizzato e generare nuovi prompt che siano perfettamente allineati a quello stile e a quel tono.

Esempi pratici di applicazione:

Analisi di citazioni: esempio di una citazione di Warren Buffett, inserendola nel chatbot, si può chiedere all’IA di generare un prompt che rifletta la filosofia e l’approccio cautamente lungimirante tipico di Buffett.
Completamento di testi: è possibile fornire un proprio brano e chiedere a ChatGPT di continuare a scrivere seguendo la stessa falsariga stilistica, mantenendo la coerenza con quanto già prodotto dall’autore umano.
Utilizzo di moduli: un uso più pragmatico consiste nel copiare e incollare lo “scheletro” di un modulo o di una lettera formale (come una disdetta) per obbligare il chatbot a seguire la sequenza e lo schema corretto delle parole.
Reverse engineering delle immagini: il concetto si estende anche al campo visivo (sintografie). Attraverso strumenti specifici (come img2prompt.io), è possibile caricare una foto per ottenere il prompt testuale necessario per ricrearla o generarne di simili.

In sintesi, questa tecnica trasforma l’IA in uno strumento capace di decodificare il “DNA” di un testo per trasformarlo in un’istruzione operativa riutilizzabile.

6. Tone of voice e requisiti non funzionali dell’output

I “modificatori di tono” come strumento per rendere gli scambi più naturali ed efficaci, adattandoli a contesti e pubblici diversi.

Nel contesto del prompt engineering, la definizione del tone of voice (tono di voce) e dei requisiti non funzionali (come formato, limiti e stile) è essenziale per trasformare un output generico in un risultato professionale e mirato.

Il Tone of voice (tono di voce)

Il tono di voce non riguarda cosa l’IA dice, ma come lo dice. Si identificano diverse tecniche per modulare questo aspetto:

Modificatori di tono: sono strumenti per rendere la comunicazione più naturale e meno meccanica. Attraverso parole specifiche, variazioni di ritmo e tonalità emotive (ironia, empatia, autorità), è possibile adattare l’IA a diversi pubblici.
Esempi di combinazioni: è possibile richiedere toni complessi come “Amichevole + Professionale” (per panoramiche informative ma accessibili), “Autorevole + Informale” (per pareri esperti ma diretti), o “Urgente + Concreto” (per spingere all’azione).
Teoria dei frame (cornici): applicando la teoria di Goffman, il tono viene influenzato dalla “cornice” interpretativa fornita. Ad esempio, lo stesso argomento verrà spiegato con linguaggi e toni radicalmente diversi se il target è un bambino di dieci anni (usando metafore) o un ingegnere informatico (usando termini tecnici).
Sentiment: l’utente può definire l’obiettivo emotivo dell’output, chiedendo varianti basate sul “sentiment”, come un messaggio “dispiaciuto” rispetto a uno “propositivo”.

Requisiti non funzionali dell’output

Questi requisiti definiscono i vincoli tecnici e strutturali che l’IA deve rispettare, sintetizzati principalmente nella “L” del metodo G.O.L. (Limiti e Layout).

Limiti e vincoli

Lunghezza: è fondamentale imporre paletti sulla produzione di testo, specificando il numero di caratteri o parole desiderate.
Token: la lunghezza è condizionata dai “token” (unità di base di circa 4 caratteri). Modelli come GPT-4 hanno limiti di contesto molto ampi (fino a 128.000 token), ma per testi estremamente lunghi è necessario usare strumenti come i “GPT splitter”.
Temperatura: è un parametro tecnico (0-1) che regola la casualità. Una temperatura bassa produce output precisi e ripetitivi; una alta favorisce la creatività e il brainstorming.

Layout e format (forma dell’output)

ChatGPT può gestire una vasta gamma di formati oltre al semplice testo:

Strutture tabellari e grafiche: tabelle comparative, checklist, schede valutative e persino grafici a torta.
Diagrammi complessi: diagrammi di Gantt o mappe mentali utilizzando la sintassi Markdown Mermaid.
Formati dati e codice: file CSV (valori separati da virgola), XML/YAML, codice di programmazione (HTML, CSS, Python) e persino file SVG per grafica vettoriale o codici QR.

Concretezza e Specificità

Per evitare il fenomeno “garbage in, garbage out” (input scadente, output scadente), i requisiti devono essere descrittivi e dettagliati. Un errore comune è la mancanza di specificità: invece di un vago “disegna un paesaggio”, un prompt efficace descrive l’ora del giorno, le condizioni atmosferiche e lo stile desiderato.

Infine, l’uso di esempi (one-shot o few-shot prompting) all’interno del metodo G.O.L.D. permette di mostrare all’IA esattamente lo schema o lo stile da seguire, garantendo che l’output rispetti i requisiti non funzionali desiderati.

Il tone of voice è un controllo pragmatico, quindi: non cambia solo la ‘forma’ del testo, ma anche la selezione delle informazioni, la loro priorità e la modalità argomentativa. Un output “autorevole” tende a usare definizioni e assertività; un output “empatico” tende a riconoscere emozioni e proporre azioni di supporto; un output “urgente e concreto” privilegia passi operativi e call-to-action.

Dal punto di vista della progettazione, conviene trattare il tone of voice come requisito non funzionale al pari di performance o usabilità in un sistema software: non è ‘decorazione’, ma condizione di accettazione dell’output. In un contesto educativo, per esempio, il tono deve sostenere comprensione, scaffolding e gradualità; in un contesto di incident response deve privilegiare chiarezza, priorità e risk awareness.

Il rischio principale è l’overfitting stilistico: un tono troppo marcato può introdurre bias (ad esempio semplificazioni eccessive o eccesso di confidenza). Per mitigare, si può chiedere al modello di separare il contenuto fattuale dal registro (es. ‘prima i fatti in punti, poi la spiegazione in tono X’).

7. CoT e ToT: prompting per il ragionamento e il problem solving

Quando il compito richiede ragionamento multi-step, si potrebbe introdurre la tecnica Chain-of-Thought (CoT), citando Wei et al. (2022): chiedere (o indurre) passaggi intermedi migliora la capacità di problem solving e riduce errori in compiti complessi.

L’idea può essere letta come “decomposizione del problema”: si suddivide il task in sotto-problemi, ottenendo un output intermedio che rende il percorso più controllabile e debuggabile, in modo simile a come si progettano funzioni e moduli in un software.

Oppure quella del Tree-of-Thoughts (ToT), citando Yao et al. (2023), come generalizzazione che esplora più percorsi alternativi e valuta progressi intermedi prima di convergere su una soluzione.

Operativamente, ToT è utile in scenari decisionali e creativi: definire più opzioni, confrontare pro e contro, applicare criteri di scelta. In un ambito universitario, ToT può supportare la stesura di piani di progetto, la valutazione di architetture e la preparazione di discussioni argomentate.

È importante distinguere tra: (a) chiedere al modello di ragionare, e (b) ottenere un output verificabile. In un lavoro accademico, la trasparenza del ragionamento non sostituisce la verifica delle fonti; è piuttosto uno strumento per controllare coerenza e completezza.

8. SO.CRA.TE e prompting iterativo: dall’input all’elicitation dei requisiti

Uno degli elementi più originali del lavoro di Gianluigi Bonanni (cfr. bibliografia) è il metodo SO.C.RA.T.E., pensato per ridurre lo sforzo dell’utente nella costruzione del prompt: invece di scrivere subito una richiesta perfetta, si chiede al chatbot di porre domande e raccogliere requisiti, ovvero: l’AI «mi deve intervistare» per capire obiettivo e contesto, trasformando l’interazione in un ping-pong a turni.

L’acronimo SO.C.RA.T.E. viene definito come: SOllecito, Contesto, RAffinamento, Turni, Esortazione. Il cuore è la gestione dei turni: una domanda alla volta, attendere risposta, e solo dopo procedere. Questo evita interrogatori ‘a raffica’ e permette un progressivo affinamento dei requisiti.

In termini di ingegneria del software, SO.C.RA.T.E. ricorda una fase di elicitation dei requisiti: si raccolgono informazioni, si disambiguano vincoli, si verifica la comprensione con domande incrementali. Questo approccio è particolarmente utile in compiti complessi (piani editoriali, strategie di comunicazione, analisi di problemi) o quando l’utente non è in grado di formalizzare subito l’obiettivo.

Il metodo SO.C.RA.T.E. è un approccio strutturato ideato per ottimizzare l’interazione con i modelli di linguaggio (LLM) come ChatGPT, trasformando la generazione di contenuti in un processo di indagine collaborativo. A differenza dei prompt tradizionali “one-shot”, questo metodo si ispira alla maieutica socratica, utilizzando un dialogo basato su domande e risposte per stimolare il pensiero critico e far emergere informazioni precise dall’utente

Il metodo si articola in cinque passaggi fondamentali (più uno di raffinamento opzionale) che guidano il chatbot nel raccogliere i dati necessari prima di produrre l’output finale:

SO (Sollecito): consiste nel formulare una richiesta chiara e diretta. La precisione è fondamentale: una domanda vaga produce risposte generiche, mentre una specifica (es. “tendenze del marketing B2C” invece di un generico “parlami di marketing”) orienta correttamente la macchina.
C (Contesto): in questa fase si forniscono informazioni aggiuntive per inquadrare la richiesta. È utile specificare dettagli come il livello di complessità desiderato (es. tecnico o divulgativo) o le sfumature del compito da svolgere.
RA (Raffinamento): fase dedicata all’inserimento di dettagli estremi, come link a offerte di lavoro o documenti specifici, per rendere l’interazione ancora più mirata.
T (Turni): rappresenta il cuore del metodo. Si richiede esplicitamente al chatbot di organizzare una conversazione a turni, innescando un “ping-pong” comunicativo in cui ogni risposta dell’utente diventa la base per la domanda successiva dell’IA.
E (Esortazione): è l’istruzione critica per evitare che il chatbot ponga tutte le domande contemporaneamente. Bisogna ordinare all’IA di aspettare la risposta dell’utente prima di procedere con il quesito successivo.

Una pratica derivata è il ‘prompt per creare i prompt’: un meta-prompt che chiede al modello di fare domande fino a produrre una richiesta ottimizzata. In ambienti operativi, questa ricorsività può essere standardizzata in template e playbook.

Il metodo SO.C.RA.T.E. può essere utilizzato in modo ricorsivo per far sì che sia l’IA stessa a costruire un prompt perfetto. In questo scenario, l’utente delega alla macchina il ruolo di “generatore di prompt”. L’IA viene istruita a intervistare l’utente su obiettivi, scopi ed esempi dell’output desiderato, procedendo sempre una domanda alla volta fino a quando non ha raccolto tutte le informazioni necessarie per produrre l’istruzione ottimizzata.

L’efficacia del metodo risiede nel ribaltamento della logica di input: non è più l’utente a dover indovinare tutte le variabili da inserire in un unico comando (“garbage in, garbage out”¹), ma è l’IA che si fa guidare e, al tempo stesso, guida l’utente verso la soluzione migliore attraverso l’ascolto attivo e la segmentazione del problema. Questo approccio riduce l’ambiguità e massimizza la qualità dei risultati, rendendo l’interazione con i chatbot un processo di miglioramento continuo.

9. Policy, privacy e affidabilità: limiti e responsabilità d’uso

Accanto alle tecniche, occorre affrontare limiti e vincoli: cosa non si può chiedere a un chatbot e quali rischi emergono per privacy e governance. Fra le categorie di richieste problematiche (informazioni personali, contenuti dannosi, consigli medici/legali specifici, violazioni di copyright) è importante richiamare l’attenzione sul tema della privacy e dei dati immessi dagli utenti.

La questione della privacy e la protezione dei dati

La gestione dei dati personali è uno dei temi più critici. E qui è d’obbligo ricordare che nel marzo 2023 il Garante per la protezione dei dati personali ha temporaneamente bloccato ChatGPT in Italia, contestando diverse violazioni.

Data breach e raccolta dati: tra le criticità sollevate figuravano un perduto controllo dei dati (data breach) avvenuto nel marzo 2023 e l’assenza di una base giuridica per la raccolta massiva di dati finalizzata all’addestramento degli algoritmi.
L’utente come “produttore”: viene evidenziato che, specialmente nelle versioni gratuite, l’utente non è il prodotto ma il “produttore non pagato” di valore attraverso i propri dati, che vengono fagocitati dal sistema per migliorarsi.
Strumenti di tutela: per ovviare a questi problemi, OpenAI ha introdotto una modalità “in incognito” che permette di disattivare la cronologia. Quando questa opzione è attiva, le conversazioni non vengono utilizzate per addestrare i modelli.

Affidabilità e limiti tecnici (le “allucinazioni”)

L’affidabilità dei modelli di linguaggio (LLM) è intrinsecamente limitata dalla loro natura tecnologica. Spesso questi sistemi sono definiti come “pappagalli stocastici”, poiché generano testi basandosi su probabilità statistiche senza una reale comprensione semantica.

Allucinazioni: i modelli possono inventare fatti o dati inesistenti, fenomeno noto come “allucinazioni”, rendendo le risposte occasionalmente inesatte o inappropriate.
Bias e pregiudizi: poiché l’IA apprende da miliardi di pagine web, può ereditare e propagare pregiudizi ideologici, politici o sociali presenti nei dati di addestramento (ad esempio, stereotipi di genere o discriminazioni).
Lacune scientifiche: ChatGPT mostra spesso pecche in matematica e logica, sebbene strumenti come il plugin Wolfram possano mitigare queste carenze. Inoltre, le conoscenze sono limitate alla data dell’ultimo addestramento, a meno che non si utilizzi la navigazione web in tempo reale.

Responsabilità e policy d’uso

Esistono confini precisi su ciò che può essere chiesto o fatto con un chatbot:

Contenuti proibiti: l’IA non elabora richieste legate a contenuti offensivi, discriminatori, fraudolenti o atti di hacking. È inoltre vietato tentare di far rivelare al sistema i propri dati di addestramento tramite tecniche di “jailbreaking”.
Consulenza professionale: ChatGPT non è qualificato per fornire consigli medici o legali specifici; in questi casi, il sistema è istruito per suggerire sempre il consulto con un professionista umano.
Copyright: i modelli sono progettati per rispettare le leggi sul diritto d’autore e non dovrebbero assistere nella distribuzione di materiali protetti senza autorizzazione. Tuttavia, la tutela legale del “prompt” stesso come opera dell’ingegno è ancora oggetto di dibattito giuridico.

L’uomo al centro: il ruolo del “Co-pilot”

Un concetto fondamentale da sottolineare è che la responsabilità finale resta umana. Microsoft, non a caso, definisce il suo assistente AI “Co-pilot” e non “pilot”, sottolineando che l’uomo deve rimanere al centro del processo.

In sintesi, l’efficacia dello strumento dipende dalla capacità dell’utente di formulare prompt neutri e specifici per limitare i bias, di verificare sempre l’output per correggere eventuali allucinazioni e di gestire con prudenza i dati sensibili, sapendo che “garbage in, garbage out” (se l’input è scadente, lo sarà anche l’output)

Quindi per uso personale e ancor più per un uso universitario e aziendale, queste considerazioni si traducono in regole pratiche: evitare dati personali e sensibili nei prompt, anonimizzare dataset e log, usare ambienti controllati e prevedere sempre una fase di verifica umana dell’output.

Un secondo rischio è l’affidabilità: un output fluido può mascherare errori. Per questo, in prompt tecnici conviene richiedere esplicitamente ipotesi, limiti e, quando possibile, riferimenti o procedure di validazione. In ambito software, l’analogo è la distinzione tra ‘build’ e ‘test’: il modello produce, ma la validazione rimane responsabilità dell’utente.

L’utilizzo dell’intelligenza artificiale generativa, in sintesi, comporta importanti riflessioni su privacy, affidabilità e responsabilità. Sebbene questi strumenti offrano opportunità rivoluzionarie, il loro impiego è delimitato da vincoli normativi, tecnici ed etici che l’utente deve conoscere per un uso consapevole.

10. Prospettive: agenti, automazioni e formulazione del problema

Le prospettive future dell’interazione con l’intelligenza artificiale suggeriscono un’evoluzione che va oltre l’attuale concetto di prompt engineering, spostandosi verso l’impiego di agenti autonomi e una maggiore enfatizzazione sulla formulazione del problema.

Di seguito i punti chiave:

Agenti autonomi e automazioni complesse

Secondo alcuni esperti, il prompt engineering come lo conosciamo oggi potrebbe diventare presto obsoleto. Le tendenze indicano che il futuro non si baserà solo sulla singola istruzione fornita dall’utente, ma sull’uso di agenti autonomi capaci di collaborare tra loro in processi dinamici e complessi.

Collaborazione tra macchine: si prospetta uno scenario in cui i chatbot si scambiano richieste e risposte autonomamente per risolvere compiti articolati.
Esempi di strumenti: strumenti come AgentGPT rappresentano i primi passi verso questa direzione, in cui l’intervento umano è ridotto rispetto alla fase di esecuzione.
Assistenti intelligenti: motori come Perplexity utilizzano già sistemi (come Copilot) che guidano l’utente a interrogare meglio la macchina, agendo da ponte verso un’automazione più fluida.

Dalla soluzione alla formulazione del problema

Con il progredire della tecnologia, l’intelligenza artificiale diventerà sempre più intuitiva nella comprensione del linguaggio naturale, riducendo la necessità di istruzioni tecniche estremamente dettagliate.

La nuova abilità chiave: l’abilità fondamentale da acquisire non sarà più il “sussurrare” comandi specifici, ma la formulazione del problema.
Il ruolo dell’utente: l’uomo dovrà concentrarsi sull’identificare, analizzare e delineare correttamente i problemi; al problem solving effettivo penserà l’IA.

L’uomo come “Co-pilota”

Nonostante l’aumento dell’automazione, l’essere umano rimarrà al centro del processo.

Concetto di Co-pilot: Microsoft, ad esempio, definisce il suo assistente AI come un “Co-pilot” e non un “pilot”, proprio per sottolineare che la responsabilità e la guida finale restano umane.
Evoluzione delle professioni: emergeranno nuove figure come lo “Specialista delle interfacce umane”, che richiederanno un mix di hard skill informatiche e soft skill psicologiche e sociali per gestire l’interazione uomo-macchina in contesti sempre più integrati, come il settore automotive.

In sintesi, si ipotizza che mentre la macchina diventerà più autonoma nell’esecuzione (agenti e automazioni), il valore aggiunto dell’uomo si sposterà a monte del processo, nella capacità critica di definire correttamente le sfide da sottoporre all’intelligenza artificiale.

Nella possibile evoluzione “oltre il prompt engineering” è da citare la posizione di von Csefalvay: il futuro «non si baserà sul prompt engineering», ma sull’uso di «agenti autonomi» che collaborano in processi più dinamici.

Questa tesi è coerente con una tendenza dell’ecosistema: strumenti che automatizzano template (estensioni, librerie di prompt), catene di strumenti e workflow agentici (planner, executor, critic). Tuttavia, anche in uno scenario agentico, permane un nucleo di competenza umana: formulare bene il problema e definire criteri di successo.

Da qui la conclusione teorica: il prompt engineering può ridursi come ‘mestiere artigianale’ ripetitivo, ma non scompare come abilità concettuale. Cambia il livello di astrazione: dall’istruzione puntuale al design del processo (obiettivi, guardrail, verifiche, metriche), cioè una vera ingegneria del dialogo uomo-macchina.

Conclusioni

Il prompt engineering è una disciplina di progettazione dell’interazione. I concetti di token e contesto ricordano che l’interazione è vincolata da risorse computazionali e da limiti di memoria conversazionale. La teoria dei frame mostra che la qualità dell’output dipende anche da scelte linguistiche e pragmatiche.

I metodi G.O.L. e G.O.L.D. trasformano il prompting in una procedura replicabile, utile soprattutto in contesti professionali dove l’obiettivo è ridurre variabilità e ambiguità. Tecniche come CoT e ToT estendono la capacità del modello su compiti complessi, mentre SO.C.RA.T.E. sposta l’attenzione dall’‘istruzione perfetta’ alla raccolta incrementale dei requisiti.

Infine, policy e privacy ricordano che la qualità non è solo tecnica: è anche responsabilità. Il valore dei chatbot emerge pienamente quando il loro uso è inserito in un processo: progettazione del prompt, generazione, verifica, revisione, e solo infine integrazione nel contesto reale (studio, lavoro, decisioni).

Bibliografia

Bonanomi, G. (2024). ChatGPT, come stai? Il prompt engineering come nuova skill ibrida. Milano: Ledizioni.

Goffman, E. (1974). Frame Analysis: An Essay on the Organization of Experience. Boston: Northeastern University Press.

Lakoff, G. (2004). Non pensare all’elefante! Come riprendersi il discorso politico. Milano: Chiarelettere.

Wei, J., et al. (2022). Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. arXiv:2201.11903.

Yao, S., et al. (2023). Tree of Thoughts: Deliberate Problem Solving with Large Language Models. arXiv:2305.10601.

von Csefalvay, C. (s.d.). Prompt Engineering: The Art of Yesterday. (citato in Bonanomi, 2024).

Autorità Garante per la protezione dei dati personali (2023). Provvedimento relativo al servizio ChatGPT. (citato in Bonanomi, 2024).

Garbage in, garbage out (lett. “spazzatura dentro, spazzatura fuori”, GIGO in forma abbreviata; anche rubbish in, rubbish out) è una frase utilizzata nel campo dell’informatica e della tecnologia dell’informazione e della comunicazione. È utilizzata soprattutto per richiamare l’attenzione sul fatto che i computer elaborano in modo acritico, pertanto se viene fornito loro un insieme di dati in entrata palesemente erronei o insensati (garbage in) producono un risultato erroneo o insensato (garbage out).https://it.wikipedia.org/wiki/Garbage_in,_garbage_out ↩︎