Prompt di sistema: i due strati invisibili della conversazione

Quando si scrive una domanda a un assistente conversazionale e si riceve una risposta, l’impressione è che nella finestra ci siano solo due voci, quella dell’utente e quella del modello. È un’immagine incompleta. Prima ancora del primo carattere digitato, la conversazione è già popolata da un testo che l’utente non ha scritto e che in gran parte non vede. Quel testo stabilisce chi è il modello, come deve comportarsi, quali strumenti ha a disposizione, che giorno è oggi.

È il prompt di sistema della conversazione, e determina buona parte dello scambio prima che lo scambio cominci.

La formula va intesa in senso più largo di quello corrente, dove «prompt di sistema» indica solo il blocco di istruzioni nascoste che il fornitore inserisce a monte. Qui comprende tutto ciò che entra nella finestra di contesto oltre allo scambio esplicito di domande e risposte, e si compone di due strati. Uno è deciso dal fornitore e non è modificabile. L’altro lo costruisce l’utente, spesso senza rendersene conto, ogni volta che collega un servizio o installa un componente. Sono i due strati che questa analisi tiene distinti.

Il meccanismo vale per qualsiasi assistente basato su un modello linguistico. Ciò che cambia, da un ecosistema all’altro, è quanto lo strato utente si possa arricchire, dalle poche istruzioni personali fino al collegamento di servizi esterni e all’installazione di componenti che aggiungono capacità e regole alla conversazione.

L’analisi che segue usa Claude come riferimento concreto, perché è un caso in cui la parte governata dall’utente è tra le più sviluppate, e quindi la più adatta a mostrare di cosa è fatto questo strato.

Lo strato del fornitore

Il primo strato è scritto da chi produce il modello, viene inserito all’avvio di ogni conversazione e resta uguale per tutti, salvo gli aggiornamenti periodici. Nel caso di Claude è in buona parte leggibile, perché Anthropic pubblica il prompt di sistema delle proprie applicazioni web e mobile in una sezione di note di rilascio, aggiornata a ogni nuova versione del modello.

Chi accede tramite API scrive invece la propria parte, ma il modello non resta senza regole, perché i vincoli di sicurezza sono incorporati durante l’addestramento e l’uso resta soggetto alle politiche del fornitore. Cambia dove risiedono quei vincoli, non il fatto che esistano.

Leggere quel testo è istruttivo, perché mostra che molti comportamenti apparentemente spontanei del modello sono in realtà istruzioni esplicite. Lo strato raccoglie alcune componenti ricorrenti. La prima è l’identità del prodotto, cioè quale modello sta rispondendo e le poche informazioni che lo riguardano. Seguono le regole di comportamento e di sicurezza, non negoziabili per costruzione, che nessuna istruzione dell’utente può ribaltare.

C’è poi il tono e il formato di default, la base stilistica su cui si innestano le preferenze personali quando ci sono. Il blocco di solito più corposo è l’orchestrazione degli strumenti, con le schede tecniche che descrivono al modello nome, funzione e parametri di ciascuno. Chiudono i metadati di sessione, come la data e il modello in esecuzione, e le iniezioni dinamiche che la piattaforma può aggiungere nel corso dello scambio.

Su questo strato pesano due limiti di visibilità. Il primo è che il testo pubblicato è il prompt comportamentale di base, non la fotografia di tutto ciò che entra nella finestra in una sessione reale, dove si aggiungono le schede degli strumenti attivi e i metadati del momento. Il secondo, più sottile, è che quel testo sta in una pagina di documentazione, non nella conversazione. Il modello lo ha davanti a ogni scambio, l’utente no, e mentre dialoga non gli viene spontaneo cercarlo altrove, così anche la parte pubblicata resta fuori dal suo sguardo proprio nel momento in cui conta.

In genere questo strato costituisce la quota maggiore dell’intero prompt di sistema, spesso diverse volte più esteso della parte governata dall’utente. È il costo fisso della conversazione, non modificabile, ma costruito per lasciare all’utente un margine di intervento attraverso l’altra metà.

Lo strato dell’utente

Il secondo strato si forma con le scelte di chi usa l’assistente, e varia da persona a persona e da sessione a sessione. In Claude comprende componenti distinte, che conviene vedere una per una.

Le istruzioni scritte dall’utente si articolano su più livelli, con modalità di inserimento diverse.

Le preferenze utente valgono per ogni conversazione e sono il livello più semplice, quello dove si dice al modello come ci si chiama, che tono usare, quali convenzioni seguire, cosa evitare.

Le istruzioni di progetto valgono solo dentro un progetto specifico e si aggiungono alle preferenze quando si lavora lì, per dare al modello il contesto e le regole di quel lavoro senza doverli ripetere ogni volta.

Le istruzioni generali di Cowork, infine, si impostano a parte e vengono lette all’avvio di ogni sessione di quell’ambiente.

Nessuna di queste aggiunge capacità nuove, tutte orientano il comportamento.

Le capacità le aggiungono gli altri componenti.

I server MCP, dallo standard aperto Model Context Protocol, collegano l’assistente a servizi e strumenti esterni, dalla ricerca web all’accesso ai file, da una casella di posta a un database. Ogni server porta con sé le schede tecniche dei suoi strumenti, e quelle schede entrano nel contesto all’avvio, con un costo spesso invisibile, perché un server con molti strumenti aggiunge altrettante descrizioni ancora prima della prima domanda.

Le skill sono cartelle di istruzioni che insegnano una procedura o una competenza specifica, dallo stile di scrittura di un’azienda al modo di compilare un documento, e si caricano in modo progressivo, all’avvio entra solo la loro descrizione e il corpo solo quando servono, il che permette di tenerne installate molte senza appesantire ogni conversazione.

I plugin, infine, sono pacchetti che raggruppano skill, connettori e altre estensioni in un’unica installazione distribuita tramite marketplace, e portano nel contesto ciò che contengono secondo le regole di ciascuna parte.

Non tutte queste voci sono presenti dappertutto, perché lo strato utente cambia con l’ambiente. Negli ambienti dedicati al lavoro con il codice se ne aggiungono altre due, gli hook, che eseguono azioni automatiche e deterministiche al verificarsi di una condizione, fuori dal ragionamento del modello, e i file di memoria, dove l’assistente conserva informazioni da una sessione all’altra.

Il tratto comune di tutte queste componenti resta lo stesso, ognuna per funzionare deve dichiarare al modello la propria esistenza, e per farlo occupa spazio nel contesto.

Sommati, questi elementi disegnano l’impronta dello strato utente, la parte del prompt di sistema che porta la firma di chi usa l’assistente.

Perché la distinzione conta

Tenere separati i due strati ha conseguenze pratiche. La prima è la gerarchia, perché i due strati non sono sullo stesso piano. Lo strato di sistema fissa confini che l’utente non può oltrepassare, le regole di sicurezza, l’identità del modello, i vincoli di comportamento non negoziabili, e nessuna istruzione dell’utente li può ribaltare. Dentro quei confini, però, lo strato utente ha un potere reale, e arriva a modificare gli stessi comportamenti di default del sistema.

La formula corretta non è «il sistema vince sempre», ma «il sistema fissa i limiti, l’utente governa ciò che sta dentro».

La seconda è la conoscibilità. Lo strato utente non si lascia leggere in un unico posto, perché si compone di sorgenti diverse, ognuna in un punto suo, e la sua impronta complessiva esiste per intero solo dentro una sessione attiva, nel momento in cui la piattaforma assembla i pezzi. Elencare ciò che si è installato non equivale a sapere quanto pesa, né a vedere le sovrapposizioni, le descrizioni doppie, i componenti collegati e poi dimenticati. Per conoscere davvero il proprio strato utente occorre osservarlo mentre è in funzione, non ricostruirlo a memoria da un inventario.

Da qui il punto pratico. Dei due strati, uno solo è alla portata dell’utente, ed è anche quello che tende a crescere senza controllo, perché ogni servizio collegato e ogni componente installato resta e continua a occupare spazio in ogni conversazione anche quando non serve più. Riconoscere che quello strato esiste, e che è il proprio, è il primo passo per trattarlo come qualcosa che si ispeziona e si mantiene, non come un accumulo silenzioso.

Cambia il modo di leggere il comportamento dell’assistente

Vedere questi strati cambia il modo di leggere il comportamento dell’assistente. Una risposta che sorprende, un rifiuto inatteso, un tono che stona smettono di sembrare capricci del modello e diventano l’effetto di istruzioni precise, in parte scritte dal fornitore, in parte accumulate dall’utente. Il modello non ha un carattere spontaneo, lavora dentro un contesto che gli viene assemblato attorno a ogni avvio, e una parte di quel contesto porta la firma di chi lo usa.

Per un’organizzazione che adotta questi strumenti la conseguenza è concreta. La qualità e la prevedibilità delle risposte dipendono anche da come è tenuto lo strato utente, che andrebbe progettato e mantenuto come qualsiasi altra configurazione, con revisioni periodiche di ciò che è collegato e installato, invece di lasciarlo sedimentare. È l’unica parte su cui si può davvero intervenire, ed è anche quella che ripaga l’attenzione.