{"id":1923,"date":"2026-03-06T14:23:09","date_gmt":"2026-03-06T13:23:09","guid":{"rendered":"https:\/\/userbot.ai\/blog\/?p=1923"},"modified":"2026-03-18T11:42:27","modified_gmt":"2026-03-18T10:42:27","slug":"l-ai-capisce-cio-che-scrivi-ma-non-cio-che-intendi","status":"publish","type":"post","link":"https:\/\/userbot.ai\/blog\/l-ai-capisce-cio-che-scrivi-ma-non-cio-che-intendi\/","title":{"rendered":"Il tuo agente AI capisce quello che scrivi. Ma non quello che intendi."},"content":{"rendered":"\n

Perch\u00e9 la differenza tra un agente che funziona e uno che delude spesso non sta nel modello scelto, ma nelle parole usate per istruirlo.<\/em><\/p>\n\n\n\n

\n\n\n\n

C’\u00e8 una scena che chi lavora con agenti AI<\/strong> riconosce immediatamente. <\/p>\n\n\n\n

L’agente \u00e8 stato configurato con cura, testato in decine di scenari, approvato. Va in produzione. <\/p>\n\n\n\n

E poi, in un caso che nessuno aveva previsto esplicitamente, non un caso strano, anzi, un caso normalissimo<\/strong>, fa qualcosa di sbagliato. <\/p>\n\n\n\n

Non di molto. <\/p>\n\n\n\n

Ma abbastanza da creare un problema.<\/p>\n\n\n\n

La reazione tipica \u00e8 cercare il bug nel codice, nel modello, nell’integrazione. Raramente si guarda dove il problema spesso davvero si nasconde: nelle istruzioni. Nel linguaggio con cui \u00e8 stato detto all’agente cosa fare.<\/strong><\/p>\n\n\n\n

Quello che segue non \u00e8 un articolo di tecnologia in senso stretto. \u00c8 un articolo su come funziona davvero la comunicazione con un Large Language Model<\/strong> e su perch\u00e9, padroneggiare questa differenza, \u00e8 una delle leve pi\u00f9 sottovalutate per chi commissiona o supervisiona un progetto AI. <\/p>\n\n\n\n

Partiamo dall’inizio, e cio\u00e8 da cosa distingue un LLM da un essere umano quando legge un testo.<\/strong><\/p>\n\n\n\n


Gli LLM leggono le parole. Gli umani leggono le intenzioni.<\/strong><\/strong><\/strong><\/h2>\n\n\n\n

Quando un collega riceve una procedura scritta male, la interpreta<\/strong>. Usa il contesto, l’esperienza, il buon senso. <\/p>\n\n\n\n

Se manca un’indicazione, suppone quella pi\u00f9 ragionevole. Se una regola non copre un caso specifico, estrapola l’intenzione di chi l’ha scritta.<\/strong><\/p>\n\n\n\n

Un LLM non fa niente di tutto questo; o meglio, lo fa in modo molto meno affidabile di quanto si pensi. I modelli linguistici hanno sviluppato una capacit\u00e0 impressionante di generare risposte pertinenti e coerenti. Ma non ragionano per intenzioni: ragionano per pattern linguistici<\/strong>. La differenza, in produzione, si vede.<\/p>\n\n\n\n

Un esempio concreto:<\/em><\/p>\n\n\n\n

Un agente per il supporto clienti di una societ\u00e0 di noleggio viene istruito a “gestire le richieste di modifica prenotazione”<\/em>. Arriva un cliente che vuole cancellare e ri-prenotare per date diverse. L’agente non gestisce la richiesta perch\u00e9 tecnicamente non \u00e8 una modifica, ma \u00e8 una cancellazione seguita da una nuova prenotazione. Un operatore umano avrebbe capito l’intenzione in mezzo secondo. L’agente no, perch\u00e9 quella casistica non era scritta da nessuna parte.<\/p>\n\n\n\n

Questo \u00e8 il punto di partenza da cui discendono tutti gli altri problemi che vedremo. Non \u00e8 una questione di intelligenza del modello: \u00e8 una questione strutturale, legata a come i LLM elaborano il linguaggio<\/strong>. Tenerlo a mente cambia il modo in cui si scrivono le istruzioni e, di conseguenza, il modo in cui si comporta l’agente.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n
\n

I modelli linguistici non condividono il nostro bagaglio implicito di esperienza e cultura. Ogni inferenza che per noi \u00e8 ovvia, per loro deve essere scritta.<\/em><\/p>\n<\/blockquote>\n\n\n\n


Il peso delle parole prescrittive<\/strong><\/strong><\/strong>: “must” vs “should”<\/strong><\/h2>\n\n\n\n

Se il problema di fondo \u00e8 che i modelli leggono il testo alla lettera, la prima conseguenza pratica riguarda il tipo di istruzioni che si danno. In particolare, la differenza tra un’indicazione prescrittiva<\/strong>, qualcosa che l’agente deve fare senza eccezioni, e una raccomandazione<\/strong>, che pu\u00f2 essere ignorata in presenza di ragioni sufficienti.<\/p>\n\n\n\n

Dire a un agente “usa sempre e solo la lingua italiana” \u00e8 diverso da dire “rispondi in italiano”. Nel secondo caso, il modello ha una via d’uscita implicita. Se l’utente scrive in inglese, se il contesto \u00e8 ambiguo, se riporta una fonte citata in francese, il modello potrebbe scegliere di non seguire quell’indicazione, perch\u00e9 l’istruzione stessa glielo consentiva.<\/p>\n\n\n\n

Nella pratica quotidiana, chi scrive le istruzioni di un agente tende a usare un linguaggio naturale usando termini come: “dovresti”, “di norma”, “cerca di”, perch\u00e9 \u00e8 il modo in cui comunichiamo tra esseri umani, dove il contesto colma le lacune. Con un LLM, quelle sfumature diventano varchi<\/strong> operativi.<\/strong> <\/p>\n\n\n\n

Un esempio concreto:<\/em><\/p>\n\n\n\n

Un agente configurato per “preferibilmente non citare i competitor<\/em>” discuter\u00e0 di competitor non appena un utente lo solleciter\u00e0 direttamente: non gli era stato proibito, solo sconsigliato.<\/p>\n\n\n\n


Le istruzioni condizionali: quando “o” non basta<\/strong><\/strong><\/strong><\/h2>\n\n\n\n

Un’altra conseguenza diretta del modo in cui i modelli leggono il testo riguarda le istruzioni condizionali<\/strong>: quelle del tipo “se accade X, fai Y”. Sono le pi\u00f9 comuni, e anche quelle in cui gli errori di formulazione sono pi\u00f9 difficili da intercettare prima di andare in produzione.<\/p>\n\n\n\n

Un esempio concreto:<\/em><\/p>\n\n\n\n

Un agente per la gestione di richieste HR viene istruito a trasferire la conversazione a un operatore umano “se l’utente esprime insoddisfazione o richiede informazioni riservate”. In test, funziona. Poi in produzione arriva un utente che \u00e8 chiaramente frustrato e, nello stesso messaggio, chiede dati sensibili sul proprio contratto. L’agente non trasferisce. Perch\u00e9 l’istruzione era formulata come una condizione singola “o” e il modello non l’ha estesa alla combinazione di entrambe.<\/p>\n\n\n\n


La versione corretta avrebbe dovuto essere esplicita: “se l’utente esprime insoddisfazione, o richiede informazioni riservate, o entrambe le cose”. Una piccola aggiunta, una differenza di comportamento significativa.<\/strong> E questo \u00e8 solo il caso pi\u00f9 semplice: gli stessi problemi emergono nelle condizioni negative, nelle eccezioni, nelle regole che si applicano “in tutti i casi tranne”, ovunque, cio\u00e8, ci sia una logica che il redattore dava per scontata e che il modello non pu\u00f2 inferire.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\n

Un buon sistema di istruzioni non si valuta su quanto funziona nei casi previsti. Si valuta su quanto funziona in quelli che nessuno aveva pensato di specificare.<\/em><\/p>\n<\/blockquote>\n\n\n\n

Le risposte dell’agente rimodellano la conversazione: il problema del contesto azzerato<\/strong><\/h2>\n\n\n\n

C’\u00e8 poi un effetto collaterale delle istruzioni scritte male che \u00e8 particolarmente insidioso<\/strong>, perch\u00e9 non si manifesta nella singola risposta sbagliata, ma nel modo in cui quella risposta cambia il filo dell’intera conversazione<\/strong>. <\/p>\n\n\n\n

Vediamo queste conversazioni:<\/p>\n\n\n\n

\n