> Prompt engineering per PMI: gli errori più comuni e come evitarli

Quando una PMI inizia a usare modelli LLM (ChatGPT, Claude, Llama, ecc.) per automatizzare processi, il primo passo è capire come formulare richieste al modello. Non è difficile, ma è facile fare male — e quando fatto male costa tempo, credibilità interna e soldi spesi in token inutili.

Non è magia: è semplicemente una questione di essere precisi, coerenti e consapevoli dei limiti dello strumento che stai usando.

# Errore 1: Prompt vago e generico

Il classico:

• Input: "Fammi un riassunto del documento"
• Output: Un testo lungo, confuso, che dice poco di utile

Il modello non sa cosa è importante per te. Se il documento è un contratto e ti serve solo la clausola sulla durata, il modello può concentrarsi su aspetti irrilevanti. Se è un report finanziario e vuoi solo i margini lordi, farà lo stesso.

Come risolvere: Sii specifico sul contesto e sull'output desiderato. Fornisci una struttura.

• "Estrai da questo contratto: [1] durata dell'accordo, [2] importo totale, [3] eventuali penali. Rispondi in una tabella a tre colonne."
• "Questo è un report di vendita Q3. Dimmi soltanto il totale delle entrate, il numero di clienti acquisiti, e il costo medio per cliente."

Non è più lungo, è soltanto chiaro. Il modello capisce esattamente cosa fare e la probabilità che fallisca crolla.

# Errore 2: Non testare il prompt con varianti di input

Hai scritto un prompt che funziona perfettamente con un documento. Lo usi in produzione e crolla con il secondo documento.

Il motivo: il tuo prompt era tarato su quella forma specifica. Se il documento cambia layout, usa termini diversi, è più lungo o più corto, il risultato diventa inaffidabile.

Come risolvere: Prima di mettere un prompt in produzione, testalo con almeno 5-10 esempi reali. Documenti veri che riceverai davvero. Cerca di rompere il prompt: dai input incompleti, contradditori, ambigui. Se tiene, è un buon candidato per l'automazione.

Non è una perdita di tempo: è il modo per scoprire se risparmierai effettivamente tempo dopo, o se finirai a correggere gli errori del modello.

# Errore 3: Chiedere certezze quando il modello non può garantirle

Scenario tipico: una PMI di servizi chiede al modello di classificare un'email come "hotspot di rischio legale". Il modello risponde "Sì" o "No" con fiducia assoluta. Ma non è un avvocato, è un modello statistico. Se la classificazione è sbagliata, chi se ne assume la responsabilità?

Il modello è buono a identificare pattern, fare brainstorming, sintetizzare, riformulare. Non è affidabile per decisioni binarie che hanno conseguenze legali, finanziarie o di sicurezza.

Come risolvere: Progetta il prompt in modo che il modello sia uno strumento di supporto, non un giudice. Esempi:

• Anziché: "Questo contratto è rischioso? Sì/No"
• Fai: "Elenca le clausole di questo contratto che potrebbero comportare un rischio legale. Per ognuna, spiega brevemente il rischio potenziale. Una persona esperta verificherà poi le tue segnalazioni."

• Anziché: "Il cliente è affidabile?"
• Fai: "In base alle email scambiate, quali segnali suggeriscono che il cliente potrebbe non pagarci? Quali suggeriscono il contrario?" Poi tu decidi.

Il modello fornisce input, l'umano decide. Così è pulito, responsabile e più affidabile.

# Errore 4: Prompt troppo lungo o confuso con troppi esempi

Pensi che più informazioni = migliori risposte. Non è così. Un prompt con 500 parole di istruzioni, 20 esempi, e una dozzina di regole è più difficile da interpretare, non meno.

Inoltre: ogni token in input costa denaro. Se hai una pipeline che processa centinaia di richieste al giorno, un prompt bloated aumenta il costo senza aumentare la qualità.

Come risolvere: Riduci il prompt al minimo essenziale. Includi 2-3 esempi di input-output corretto (few-shot prompting), non 20. Se il prompt supera le 200 parole, è probabile che sia sovracomplicato.

Test: se riesci a spiegare il compito in una frase, il prompt dev'essere concentrato su quella frase, con aggiunta di chiarimenti solo dove serve.

# Errore 5: Non monitorare la qualità dell'output in produzione

Hai lanciato il bot, il prompt sembra funzionare, e non lo tocchi per mesi. Nel frattempo, il modello sta producendo risultati degradati, o il comportamento dell'LLM è cambiato (i modelli si aggiornano), o l'input ha iniziato a variare.

Non te ne accorgi fino a quando un cliente se lamenta.

Come risolvere: Misura costantemente l'output. Almeno settimanalmente, estrai un campione casuale di risultati e valutali: sono corretti? Sono coerenti? Se la qualità scende sotto una soglia accettabile (ad esempio: meno del 90% di risposte "buone"), agisci subito.

Annota cosa è cambiato (l'input, il modello, il prompt?) e aggiusta. Un prompt non è un "set and forget": è qualcosa da iterare costantemente.

# Errore 6: Non considerare il costo in token

Un prompt che sembra innocuo può rivelarsi molto caro se usato a scala. Supponiamo che il tuo prompt sia lungo 800 token e ricevi 1.000 richieste al giorno. Con GPT-4, stai spendendo tra 4.000 e 6.000 euro al mese solo in input (cifre indicative, variano con il pricing).

Con un prompt di 200 token e lo stesso volume, scendi a 1.000-1.500 euro.

Come risolvere: Prima di automatizzare con un LLM, calcola il costo totale mensile. Input token + output token + margine di sicurezza (20%). Se il costo è più alto dei benefici, o se non è giustificabile, scegli un modello più piccolo (Claude 3 Haiku, Llama, ecc.) oppure una soluzione diversa (regex, API dedicate, database lookup).

Non tutto ha bisogno di un LLM. Chiediti: stai pagando per la flessibilità di un modello generale, o avresti potuto risolvere il problema con uno strumento specifico?

# Errore 7: Prompt sempre in inglese senza motivo

I modelli più moderni gestiscono bene anche l'italiano. Eppure molte PMI scrivono il prompt in inglese "perché funziona meglio". A volte è vero (se il modello è stato addestrato più su dati inglesi), a volte è una convinzione non testata.

Come risolvere: Testa entrambi. Se il tuo flusso è interamente in italiano e il modello gestisce bene l'italiano, usa l'italiano nel prompt. È più facile da mantenere, meno errori di comunicazione, e più semplice da spiegare internamente a chi non parla inglese.

Se noti davvero una differenza qualitativa significativa (cosa rara con modelli moderni), allora scegli l'inglese consapevolmente. Ma non è il default.

# Quando il prompt engineering è utile per una PMI

È utile quando:

• Hai processi ripetitivi e standardizzati (classificazione di email, estrazione di dati, sintesi di documenti)
• L'output non richiede certezza assoluta, ma "buono al 85-90%" è abbastanza
• Hai abbastanza volume per giustificare il tempo di testing e iterazione
• Puoi permettere un layer di supervisione umana (almeno spot-checking)

NON è utile quando:

• Ti serve una risposta sicura e verificata (usa un avvocato, un commercialista, non un LLM)
• Il processo è già molto automatizzato con strumenti specifici
• Il volume è troppo basso per giustificare lo sforzo iniziale
• Non hai tempo per testare e iterare il prompt adeguatamente

Questo è il vero punto: il prompt engineering non è magico. È semplicemente la disciplina di essere preciso, testare, e iterare. Se la tua PMI non ha tempo per questo, non hai tempo nemmeno per usare bene un LLM.