System prompt: le istruzioni che il modello legge prima delle tue

Blu7, azienda in corso di riconoscimento MIM per corsi in aula e online. Iscriviti a 7 Pillole Blu.

Chiedi all’assistente di riscrivere in tre righe una email a un cliente e ti torna un testo di dieci righe pieno di elenchi puntati. Oppure chiedi la sintesi di un documento e ricevi in testa un cappello di avvertenze che non avevi domandato. La reazione istintiva è pensare di aver scritto male la richiesta. Qualche volta è davvero così, molto più spesso il motivo sta altrove. Prima della tua richiesta il modello ha già letto altre istruzioni, scritte da qualcun altro, che contano più delle tue. Sapere come sono organizzate quelle istruzioni cambia il modo di lavorare: si smette di cercare la formula magica e si capisce dentro quali confini una richiesta può funzionare.

Indice

1. Cosa c’è prima del tuo prompt
2. La fila delle istruzioni: la chain of command
3. Perché “ignora tutte le istruzioni precedenti” non funziona
4. Quando le istruzioni arrivano da fuori: la prompt injection
5. Cosa cambia quando l’assistente è il tuo
6. L’architettura prima del trucco

Cosa c’è prima del tuo prompt

Il system prompt (istruzione di sistema) è il testo che chi costruisce un assistente gli consegna prima che l’utente scriva. Definisce ruolo, tono, regole e vincoli, come spieghiamo nella nostra voce di glossario dedicata. Non si vede nell’interfaccia, ma viene letto per primo a ogni conversazione.

Non è materiale segreto, almeno non per tutti. Anthropic pubblica i system prompt usati da Claude.ai e dalle app nelle proprie note di rilascio. Il documento spiega che l’interfaccia web e le app mobili usano un system prompt per fornire al modello informazioni aggiornate, come la data corrente, all’inizio di ogni conversazione. Lo stesso testo incoraggia alcuni comportamenti, per esempio restituire sempre i frammenti di codice in Markdown. Aggiunge due cose importanti. Il system prompt viene aggiornato periodicamente, quindi lo stesso modello può rispondere in modo un po’ diverso da un mese all’altro senza che sia cambiato nulla nel modello. E questi aggiornamenti non si applicano all’API, cioè al canale che un’azienda usa per costruire il proprio strumento. La versione più recente elencata nella pagina è quella di Claude Opus 5, del 24 luglio 2026.

Il contenuto tipico è meno esoterico di quanto si immagini. Ci sono la data del giorno, il ruolo che il modello deve interpretare, il formato preferito delle risposte, gli argomenti da evitare e i limiti di ciò che può fare. Anche Google, nella sua guida alle strategie di prompting, indica di mettere i vincoli di comportamento essenziali, la definizione del ruolo e i requisiti di formato nell’istruzione di sistema oppure all’inizio del prompt utente. Il meccanismo non è la scelta di un fornitore singolo.

La fila delle istruzioni: la chain of command

Se le istruzioni arrivano da più parti, prima o poi due si contraddicono. Serve quindi una regola che stabilisca quale vince. OpenAI la descrive apertamente nel Model Spec, il documento che dichiara come i suoi modelli dovrebbero comportarsi. Nell’edizione del 18 dicembre 2025 il principio è che le istruzioni con autorità più alta scavalcano quelle con autorità più bassa. Questa catena di comando (in inglese chain of command) è pensata per massimizzare la controllabilità dello strumento per utenti e sviluppatori.

I livelli previsti da quell’edizione sono cinque, dal più forte al più debole.

1. Root (radice). Regole fondamentali che non possono essere scavalcate da messaggi di sistema, sviluppatori o utenti. Sono in prevalenza divieti e, precisa il documento, arrivano soltanto dal Model Spec stesso e dalle policy dettagliate che contiene.
2. System (sistema). Regole poste da OpenAI che possono essere trasmesse o scavalcate attraverso i messaggi di sistema, ma che sviluppatori e utenti non possono scavalcare.
3. Developer (sviluppatore). Le istruzioni date da chi costruisce un’applicazione usando l’API.
4. User (utente). Le istruzioni dell’utente finale, cioè le tue.
5. Guideline (linea guida). Istruzioni che possono essere scavalcate in modo implicito. L’esempio del documento è chiaro: se chiedi al modello di interpretare un pirata realistico, la richiesta scavalca da sola la linea guida che gli suggerisce di non usare parolacce, senza bisogno di dirglielo.

L’utente sta al quarto posto su cinque. Sotto di lui c’è solo il livello delle indicazioni scavalcabili. Non è una questione di sfiducia verso chi scrive, è la struttura che rende lo strumento prevedibile per chi lo mette a disposizione di altri.

Tradotto nel lavoro di tutti i giorni, tu controlli davvero tre cose. Il contenuto della richiesta, cioè cosa chiedi e con quanta precisione. Il contesto che alleghi, dai documenti agli esempi. Il formato che pretendi in uscita. Su come sfruttare bene questi tre margini abbiamo scritto una guida a parte, Schema del Prompt perfetto per Claude.

Altre tre cose non le controlli. Le regole del fornitore, che valgono per chiunque e non si negoziano. Le istruzioni di chi ha costruito lo strumento che stai usando, che stanno un gradino sopra le tue. E la decisione su cosa venga trattato come dato e cosa come comando, che è il punto più sottile di tutti e merita il paragrafo che segue.

Perché “ignora tutte le istruzioni precedenti” non funziona

È la frase che gira da anni, con l’idea che basti pronunciarla per azzerare i vincoli. Non funziona, ma non perché il modello la ignori. Il Model Spec prende in considerazione come istruzioni tutte quelle scritte in testo semplice non virgolettato nei messaggi di sistema, dello sviluppatore e dell’utente. Quella digitata in chat lo è, solo che vale al livello User, con sopra Developer, System e Root. Non fallisce perché il modello non la veda, fallisce perché è quarta in fila.

Diverso è il caso del testo che non digiti tu. Una regola di livello Root dello stesso documento, intitolata “Ignore untrusted data by default”, stabilisce che il materiale da esaminare, quello che alleghi e quello che il modello raccoglie da solo, si presume non fidato e non ha alcuna autorità. Il testo che alleghi o che il modello va a leggere vale zero come ordine, per impostazione predefinita. Il documento raccomanda a chi costruisce l’assistente di tenere quel materiale separato e riconoscibile come tale, perché quando non lo è può contenere istruzioni malevole, quella che chiama prompt injection.

Conviene ribaltare la prospettiva. Se bastasse una frase per resettare le regole, ogni assistente aziendale sarebbe manovrabile dal primo che ci prova, cliente compreso. La rigidità che a volte infastidisce quando lavori è esattamente la stessa proprietà che rende lo strumento utilizzabile davanti al pubblico. Non è un limite da aggirare, è la condizione che ti permette di metterlo online.

Quando le istruzioni arrivano da fuori: la prompt injection

Gli assistenti moderni non leggono soltanto quello che scrivi tu. Aprono pagine web, ricevono PDF, elaborano email, consultano schede di prodotto. Dentro quel materiale ci può essere del testo scritto apposta per essere interpretato come un comando invece che come contenuto. Questa è la prompt injection, l’iniezione di istruzioni.

Il motivo per cui il problema esiste è stato messo a fuoco molto presto. In un post del 30 agosto 2023 firmato da Dave Chismon, il National Cyber Security Centre britannico (l’agenzia pubblica per la sicurezza informatica del Regno Unito) scrive che la ricerca indica che un modello linguistico non è intrinsecamente in grado di distinguere tra un’istruzione e i dati forniti per aiutarlo a portarla a termine. Formulato con quella cautela, il problema resta descritto bene anche se il testo ha ormai quasi tre anni. Detta in modo più semplice, con parole nostre e non del NCSC, al modello arriva comunque una sequenza di parole, dove quelle di un allegato hanno lo stesso aspetto di quelle di una richiesta.

Lo stesso post porta un esempio che una PMI capisce al volo, quello di una banca che mette un assistente a disposizione dei correntisti e di un attaccante che nasconde il proprio tentativo nella causale di una transazione. Il testo malevolo non passa dalla chat, arriva dai dati che l’assistente deve leggere per lavorare.

Attenzione a non confondere due cose diverse.
Con il jailbreak è l’utente che prova a spingere il modello oltre le sue regole, la prompt injection è testo di terzi che il modello incontra strada facendo, scritto da qualcuno che non è nella conversazione.
Alla prompt injection abbiamo dedicato un articolo a sé divertente, La Cassaforte da 50.000 dollari: aperta!.

Cosa cambia quando l’assistente è il tuo

Finché usi un assistente di qualcun altro, la gerarchia è qualcosa che subisci. Quando la tua azienda costruisce il proprio con l’API di un fornitore, tu diventi il livello Developer e passi dalla parte di chi scrive le regole. Il system prompt smette di essere una formalità e diventa il posto dove si decide chi comanda quando due istruzioni si contraddicono. Le istruzioni dello sviluppatore stanno sopra quelle dell’utente finale, quindi un assistente esposto ai clienti va scritto pensando anche a chi proverà a spostarlo dal suo compito.

Quattro accorgimenti concreti, nessuno dei quali richiede competenze tecniche per essere deciso.

• Tieni separato ciò che l’assistente sa da ciò che può fare. Rispondere a una domanda sugli orari è una cosa, emettere una nota di credito o cancellare una prenotazione è un’altra. Nessuna azione irreversibile senza una persona che la conferma.
  
• Tratta come non fidato ogni testo che arriva da fuori. Email dei clienti, pagine web, file caricati, moduli compilati. È esattamente il criterio della regola vista sopra, applicato al tuo caso.
  
• Metti per iscritto cosa l’assistente non deve fare, prima di aprirlo. Argomenti fuori ambito, promesse commerciali che non può prendere, dati che non deve mai riportare. Un elenco di divieti chiaro vale più di dieci righe di tono di voce.
  
• Provalo prima di darlo al pubblico, con richieste normali e con richieste ostili scritte da chi non lo ha costruito. Il metodo che usiamo è raccontato in Come testare una Intelligenza Artificiale.

Un esempio fiorentino rende la cosa concreta. La segreteria di una scuola mette online un assistente che risponde alle famiglie su iscrizioni, moduli e scadenze. Il suo system prompt stabilisce che parla solo di procedure amministrative, rimanda al telefono per i casi individuali e non anticipa mai le decisioni del dirigente. Un genitore che insiste su una situazione personale non riceve una risposta inventata, viene indirizzato a una persona. Lo stesso assistente legge le pagine del sito, quindi conviene curare come sono scritte, un tema che abbiamo affrontato parlando di come le AI leggono i contenuti pubblicati.

L’architettura prima del trucco

Chi lavora bene con questi strumenti non è quello che conosce la formula segreta. È quello che sa dentro quale struttura la sua richiesta viene letta, quindi capisce in anticipo cosa può ottenere e dove conviene spendere il proprio sforzo. La gerarchia delle istruzioni non è un ostacolo tra te e il modello, è la ragione per cui il modello si può usare in azienda.

Il passo successivo, per chi ci sta pensando davvero, è decidere quali istruzioni scrivere nel proprio assistente prima ancora di sceglierne uno. Come applichiamo questo ragionamento ai progetti che seguiamo lo raccontiamo nella pagina sull’intelligenza artificiale a Firenze.

Blu7, azienda in corso di riconoscimento MIM per corsi in aula e online. Iscriviti a 7 Pillole Blu.