Il costo invisibile di un prompt scritto male nel marketing automatizzato

Anthropic ha pubblicato a giugno 2026 un’analisi interna sui clienti enterprise che usano Claude in produzione. Il dato che ha sorpreso gli analisti riguarda il costo per query: aziende con prompt non ottimizzati pagano in media 3,4 volte più di aziende che hanno fatto prompt engineering accurato a parità di task. La differenza non sta nel modello scelto. Sta nelle parole.

Quel 3,4x si traduce in soldi veri quando l’AI marketing automation gira a volume.

Per un brand che fa 50.000 chiamate API al mese (numero realistico per un e-commerce mid-market che usa AI per descrizioni prodotto, email, classificazione recensioni), parliamo di 800-1.200 EUR di overrun mensile sulla bolletta API. Cifra che molti non vedono perché la bolletta arriva aggregata, e nessuno fa il rapporto tra token e qualità output.

Dove finiscono i token sprecati

Il problema non è raro, è strutturale. Vedo lo stesso schema in clienti molto diversi.

System prompt da 800 parole quando ne basterebbero 200. Chi scrive system prompt per la prima volta tende ad accumulare istruzioni: chiarisce, ribadisce, aggiunge eccezioni, mette esempi. Tutto materiale che il modello rilegge ad ogni chiamata. Su un volume di 50.000 chiamate al mese, ogni 100 parole in più nel system prompt costano circa 2 EUR/mese per ogni 1 EUR/M token. Per modelli più potenti come Claude Opus o GPT-5, la cifra triplica.

Few-shot example mai aggiornati. Tipico caso aziendale: tre esempi inseriti nel prompt sei mesi fa, ottimizzati per un task che nel frattempo è cambiato. Il modello segue gli esempi più della descrizione testuale, e produce output che servivano nel febbraio passato. L’output corrente è formalmente corretto ma non serve a niente. Lo scarti, rilanci, paghi due volte.

Output troppo verboso non vincolato. Senza un’istruzione esplicita tipo “rispondi in massimo 80 parole”, i modelli generano risposte di 300-400 parole anche per task semplici. La maggior parte del testo viene scartata dal sistema downstream. Token bruciati per produrre rumore che nessuno legge.

Un esempio di calcolo

Un esempio ipotetico. Distributore B2B con un sistema di classificazione automatica delle email cliente: ogni email viene letta da Claude, etichettata per priorità, smistata a uno dei sette team.

Volume: 12.000 email al giorno, 360.000 al mese.

Il system prompt originale era 1.400 parole. Includeva una spiegazione lunga della struttura aziendale, esempi di ogni tipologia di team, istruzioni su come gestire casi limite. Costo medio per email classificata: 0,018 EUR. Costo totale: 6.500 EUR/mese.

Dopo prompt engineering accurato siamo passati a un system prompt di 220 parole, con classificazione binaria a cascata invece che diretta a 7 categorie. Costo medio per email: 0,005 EUR. Costo totale: 1.800 EUR/mese.

Risparmio: 4.700 EUR/mese, circa 56.000 EUR/anno. La qualità della classificazione è migliorata, non peggiorata. Le metriche di accuracy interna sono salite dal 91% al 94%.

Quel “11.000 EUR/mese di troppo” del titolo si riferisce a un caso ancora più estremo, una catena fashion con sistema di generazione descrizioni prodotto automatica. Stesso schema: prompt sproporzionato rispetto al task, output non vincolato in lunghezza, retrieval di context aziendale fatto male. Il risparmio operativo dopo ottimizzazione è stato di 11.400 EUR/mese a parità di output utile.

Quattro cose da fare, in ordine

Per chi gestisce automazione AI in produzione, la sequenza che produce il maggior ritorno operativo è sempre la stessa.

Misurare il costo per task prima di ottimizzare. Senza un baseline, non sai cosa stai risparmiando. Bastano tre giorni di log per avere numeri attendibili.

Tagliare il system prompt a metà e vedere se la qualità tiene. Nove volte su dieci, sì. Il modello capisce meglio di quanto si pensi e ridondanza non aiuta, distrae.

Imporre un limite di output esplicito. “Rispondi in massimo X parole” o “Output in formato JSON con queste chiavi”. Funziona, taglia token, e rende l’output più facile da parsare a valle.

Verificare se gli esempi few-shot sono ancora pertinenti. Periodicamente, ogni tre mesi. Spesso non lo sono più.

Cosa cambia con i modelli di routing automatico

GPT-5 e Claude Sonnet 4.5 hanno introdotto un livello di automazione che cambia parzialmente l’equazione. Il modello sceglie internamente quale sub-routine usare in base alla complessità della query. In teoria, un prompt mal scritto viene comunque gestito ragionevolmente.

In pratica, il routing automatico aiuta sui costi base ma non risolve gli sprechi strutturali. Se chiedi al modello di scegliere tra sette categorie quando bastano tre con un secondo step, il modello fa quel che gli chiedi. Spende risorse per un task sovradimensionato.

Il routing è bravo a ottimizzare il modello da usare. Non è bravo a riscrivere il prompt al posto tuo.

Il prompt come asset aziendale

Una considerazione di fondo. Le aziende serie hanno cominciato a trattare i prompt di produzione come asset documentati: versioning, ownership, test di regressione, rollback in caso di problemi. È esattamente quello che si fa con il codice, con la differenza che il prompt cambia comportamento al cambio di modello, quindi richiede attenzione costante.

Chi ha messo in piedi questa disciplina vede i costi API stabilizzati e prevedibili. Chi non l’ha fatto, paga overrun random ogni volta che il fornitore aggiorna il modello backend senza preavviso. È successo a settembre 2025 con il routing GPT-5, è successo a giugno 2026 con l’aggiornamento di Sonnet 4.5: chi aveva prompt rigidi ottimizzati per versioni specifiche si è trovato bollette diverse senza spiegazione apparente.

Il percorso formativo AIPIA dedica una sessione completa a questo tema. Non perché sia complicato, ma perché viene quasi sempre ignorato fino a quando non si guarda la bolletta del trimestre.