Come Scrivere System Prompt che Funzionano Davvero

Un system prompt è la fondazione di qualsiasi applicazione AI. Determina il comportamento del modello in ogni interazione successiva. La differenza tra un chatbot utile e uno inutile è quasi sempre nel system prompt — non nel modello scelto.

La differenza tra un system prompt e un prompt utente è la persistenza: il system prompt viene inviato a ogni singolo scambio, invisibile all'utente finale, e stabilisce le regole del gioco per l'intera conversazione. È l'equivalente delle istruzioni che daresti a un nuovo collaboratore il primo giorno — se sono vaghe o incomplete, ogni interazione successiva ne risente. Chi ha già letto la guida ai framework di prompt engineering riconoscerà molti principi condivisi: qui li applichiamo specificamente alla costruzione di un'istruzione persistente.

I 6 elementi di un system prompt efficace

1. Identità e ruolo

Definisci chi è il modello, con quale expertise e quale prospettiva risponde. Senza questo elemento, il modello risponde con un tono "neutro generico" che raramente coincide con quello che vuoi per il tuo prodotto.

Sei un assistente specializzato nel supporto clienti di [Nome Azienda],
un SaaS per la gestione delle spese aziendali. Hai accesso alla knowledge
base aggiornata dei nostri prodotti e policy.

2. Obiettivo principale

Una sola frase che definisce lo scopo primario. Serve come bussola per il modello quando due istruzioni sembrano in tensione tra loro — torna sempre all'obiettivo principale per decidere come comportarsi.

Il tuo obiettivo è risolvere i problemi dei clienti in modo rapido ed
empatico, riducendo il numero di ticket escalati al team umano.

3. Tono e stile comunicativo

Più specifico è meglio è. "Sii professionale" lascia troppo margine di interpretazione; specificare cosa evitare e cosa preferire riduce la variabilità tra una risposta e l'altra.

Tono: professionale ma caldo, non formale. Usa "tu" non "lei".
Evita: gergo tecnico non necessario, risposte generiche, frasi fatte.
Preferisci: risposte brevi e dirette, con elenchi puntati quando utile.

4. Vincoli operativi

Qui definisci i limiti non negoziabili — le cose che, se il modello le facesse, causerebbero un problema reale (legale, economico, di fiducia). Sono le istruzioni su cui vale la pena essere più espliciti ed esaustivi.

NON fare:
- Promettere rimborsi o sconti senza autorizzazione
- Discutere competitor
- Rispondere a domande fuori dal perimetro del prodotto
- Inventare informazioni non presenti nella knowledge base

5. Gestione dei casi edge

La maggior parte dei system prompt copre bene i casi normali e lascia scoperti quelli limite — che sono esattamente i casi in cui un utente giudica se il sistema è affidabile o no. Vale la pena elencare esplicitamente gli scenari più probabili.

Se non conosci la risposta: ammettilo e offri di escalare a un operatore.
Se il cliente è agitato: riconosci prima il disagio, poi risolvi il problema.
Se la richiesta è fuori perimetro: declina educatamente e suggerisci il canale giusto.

6. Formato dell'output

Senza vincoli di formato, la lunghezza e la struttura delle risposte variano in modo imprevedibile — un problema soprattutto se l'output finisce in un'interfaccia con spazio limitato o viene letto ad alta voce da un assistente vocale.

Rispondi sempre in italiano.
Lunghezza: 2-4 frasi per domande semplici, max 150 parole per problemi complessi.
Includi sempre un passo successivo chiaro alla fine della risposta.

Template completo copia-incolla

# IDENTITÀ
Sei [ruolo] di [azienda/contesto].

# OBIETTIVO
Il tuo scopo principale è [obiettivo in una frase].

# TONO
Tono: [aggettivi specifici]
Usa: [cosa includere]
Evita: [cosa escludere]

# VINCOLI
Non fare mai:
- [vincolo 1]
- [vincolo 2]

# EDGE CASES
Se [situazione A]: [comportamento A]
Se [situazione B]: [comportamento B]

# OUTPUT
Lingua: [lingua]
Lunghezza: [specifiche]
Formato: [struttura preferita]

Errori che vedo più spesso

• System prompt troppo lungo: i modelli perdono coerenza con istruzioni eccessive. Prioritizza i vincoli più importanti
• Istruzioni contraddittorie: "sii breve" e "spiega tutto nel dettaglio" non possono coesistere
• Nessun edge case: il modello si comporta male proprio nei casi non previsti
• Non testare con utenti reali: il system prompt perfetto in laboratorio spesso fallisce sul campo

Versionare il system prompt come si versiona il codice

Un system prompt in produzione cambia nel tempo — si affina man mano che emergono nuovi edge case reali. Trattalo come codice: tienilo in un file versionato (non incollato direttamente nell'interfaccia di un pannello di terzi dove si perde la storia delle modifiche), annota perché ogni modifica è stata fatta, e prima di rilasciare una nuova versione testala sullo stesso set di domande usato per le versioni precedenti — così puoi confrontare se hai davvero migliorato o solo spostato il problema altrove.

Domande frequenti

Quanto deve essere lungo un system prompt?

Non c'è un numero fisso, ma la regola pratica è: abbastanza lungo da coprire identità, obiettivo, tono, vincoli ed edge case principali, abbastanza corto da restare leggibile e mantenibile. Se supera le 500-600 parole, spesso conviene chiedersi se alcune istruzioni sono davvero necessarie o sono lì "per sicurezza".

Il system prompt è sicuro, o un utente può aggirarlo?

Nessun system prompt è a prova di bomba al 100% — esistono tecniche (prompt injection) per provare a farlo ignorare. Per applicazioni con dati o azioni sensibili, il system prompt va accompagnato da controlli lato codice (validazione dei permessi, filtri sull'output) che non dipendono solo dal fatto che il modello "obbedisca".

Serve un system prompt diverso per ogni funzionalità del prodotto?

Spesso sì, se le funzionalità hanno obiettivi molto diversi (es. supporto clienti vs. generazione contenuti). Un unico system prompt "tuttofare" tende a produrre compromessi su entrambi i fronti — meglio system prompt specifici, anche se condividono una base comune di identità e vincoli.