Come risparmiare sui costi AI senza peggiorare il servizio

La spesa AI sale quasi sempre in modo poco spettacolare: un prompt si allunga, la cronologia cresce, partono due tentativi invece di uno, un modello costoso finisce anche sui casi facili. Poi arriva la fattura. La prima mossa non è inseguire il token meno caro: è misurare il costo di un risultato che qualcuno accetta davvero e togliere ciò che non contribuisce a quel risultato.

Questa guida ti aiuta a trovare la prima riduzione sensata, provarla su casi reali e capire quando fermarti. Non serve conoscere il codice del sistema. Serve poter vedere almeno le chiamate, i costi e qualche esempio di output.

Se hai poco tempo, fai queste tre cose

1. Separa la spesa per lavoro. Non fermarti a provider e modello. Distingui, per esempio, assistenza clienti, analisi documenti, generazione contenuti e attività interne.
2. Scegli un solo lavoro ricorrente. Prendi venti casi reali e segna per ciascuno costo, tentativi, risultato accettato e minuti di correzione umana.
3. Cambia una leva alla volta. Prima elimina chiamate e tentativi inutili; poi prova modello, lunghezza della risposta, riuso del contesto ed elaborazione in lotti. Tieni la variante soltanto se supera lo stesso controllo di qualità.

Se oggi non riesci a fare il punto 1, hai già trovato il primo problema: la spesa non è attribuibile. Prima di ottimizzare, va resa leggibile.

Dove stanno andando i soldi

I token sono le unità con cui i modelli leggono il materiale inviato, chiamato input, e producono la risposta, chiamata output. Ma la fattura di un sistema AI può contenere molto altro:

• Chiamate ripetute dopo un errore o una risposta scartata;
• Modelli e livelli di ragionamento più potenti del necessario;
• Cronologie, istruzioni e documenti reinviati a ogni richiesta;
• Risposte molto più lunghe di quanto serva;
• Ricerca documentale, archivi semantici, controlli di sicurezza, strumenti e spazio occupato;
• Controllo umano e rilavorazione;
• Capacità riservata o infrastruttura che resta inutilizzata.

Per questo “usiamo troppi token” è spesso una diagnosi incompleta. Questa tabella aiuta a scegliere da dove cominciare.

La metrica che evita i falsi risparmi

Una chiamata da un centesimo può costare più di una da cinque se deve essere ripetuta, corretta o scartata.

Usa questo denominatore:

Costo per risultato accettato = costo tecnico totale + costo di verifica e rilavorazione, diviso i risultati accettati.

Non serve un modello finanziario perfetto. Per un primo confronto bastano:

La media da sola non basta. Conserva anche il caso mediano e il 10% più costoso: spesso la spesa nasce nelle eccezioni.

Le leve, nell'ordine in cui le proverei

1. Elimina il lavoro che non doveva partire

È la leva più concreta perché non chiede al modello di diventare più bravo con meno informazioni.

Cerca chiamate duplicate, cicli, tentativi ripetuti senza limite, richieste lanciate anche quando mancano i dati minimi e risultati generati ma mai usati. Se dieci chiamate producono cinque risultati accettati, il problema non si risolve limando il prompt dell'8%.

Funziona bene quando: il flusso è cresciuto per aggiunte successive e nessuno possiede il conto completo delle chiamate.

Non basta quando: ogni chiamata è necessaria e la spesa è concentrata nel modello o nel contesto.

2. Usa potenza e ragionamento soltanto dove servono

Dividi i casi in tre gruppi: semplici, ambigui, ad alto rischio. Prova un modello o un livello di ragionamento più leggero sui primi, mantenendo quello più capace per gli altri.

Non promuovere questo instradamento perché “sembra uguale” su tre esempi. Esegui lo stesso lotto di casi e usa lo stesso controllo. Il modello più economico non fa risparmiare se genera più errori o più casi da passare a una persona.

Funziona bene quando: gran parte del volume è ripetitiva e soltanto una quota richiede davvero giudizio complesso.

Non funziona quando: il router non sa riconoscere i casi difficili o il controllo di qualità è vago.

3. Chiedi l'output che verrà davvero usato

Se al sistema servono cinque campi, non chiedere prima una relazione e poi estrarre i cinque campi. Definisci uno schema, limita la verbosità e fai fallire in modo leggibile ciò che non rispetta il formato.

Ridurre l'output è spesso più sicuro che togliere informazioni dall'input: cambia la forma della risposta, non ciò che il modello può conoscere.

Funziona bene quando: le risposte vengono lette da software o finiscono in campi strutturati.

Non basta quando: il vero costo viene da documenti e cronologie molto lunghi.

4. Riusa il contesto stabile con la cache

I provider principali offrono forme di prompt caching. In pratica, le istruzioni e i documenti identici possono essere riutilizzati senza pagarli ogni volta come nuovo input, secondo regole e prezzi del provider.

Metti la parte stabile all'inizio e quella variabile alla fine. Poi verifica i campi di utilizzo: il supporto alla cache non garantisce che ogni chiamata riusi davvero il blocco. Considera anche costo di scrittura, durata e spazio occupato.

Funziona bene quando: molte richieste condividono un prefisso ampio e realmente identico.

Non funziona quando: il contenuto cambia continuamente, viene riusato troppo poco o la cache costa più di quanto evita.

5. Porta nel contesto soltanto ciò che serve a quel caso

Inviare tutto è semplice da costruire e costoso da mantenere. La soluzione non è aggiungere in astratto un sistema di ricerca documentale, spesso chiamato RAG. È recuperare poche fonti pertinenti, conservarne il riferimento e verificare che i fatti obbligatori siano ancora presenti.

Per una cronologia lunga, separa fatti, decisioni, vincoli e punti aperti dal dialogo ormai consumato. Per un archivio, recupera sezioni precise invece dell'intero manuale. Per il risultato di un tool, passa i campi utili e un riferimento alla fonte invece di pagine grezze.

Funziona bene quando: gran parte dell'input non cambia la decisione finale.

Non funziona quando: la selezione elimina un'eccezione, una scadenza o una fonte necessaria. Il test Distill qui sotto mostra entrambe le possibilità.

6. Sposta in lotti il lavoro che può aspettare

Classificazioni notturne, estrazioni massive e valutazioni offline non devono per forza usare lo stesso percorso delle richieste interattive. Al 15 settembre 2026, OpenAI e Anthropic documentano uno sconto del 50% per le rispettive API batch, in cambio di elaborazione asincrona e vincoli specifici.

Funziona bene quando: il risultato può arrivare più tardi e il lotto è abbastanza stabile.

Non funziona quando: la persona aspetta la risposta, il carico è piccolo o il ritardo crea più lavoro operativo.

7. Valuta contratti e infrastruttura soltanto dopo

Capacità riservata, sconti di volume e modelli ospitati in proprio possono ridurre il costo unitario. Possono anche trasformare una fattura variabile in capacità inutilizzata, manutenzione e reperibilità.

Questa leva viene dopo, non prima. Ha senso quando volume, profilo di carico e requisito di qualità sono già stabili.

Distill: un test promosso e uno bocciato

Nel DL Frontier Lab abbiamo provato una domanda precisa: quanto contesto possiamo togliere conservando i fatti necessari al lavoro?

Nel primo test, dedicato a riprendere un'attività di ricerca dopo una settimana, il pacchetto completo conteneva il rapporto precedente, l'handoff e il record della sessione. La variante conservava soltanto handoff e sessione.

• Dimensione misurata: da 8.074 a 1.353 parole;
• Riduzione: 83,24%;
• Fatti richiesti conservati: 5 su 5;
• Verdetto: promossa.

Le parole erano un proxy ripetibile della dimensione del contesto, non token fatturati dal provider. Quindi il risultato prova una forte riduzione dell'input su quel lavoro; non prova un risparmio universale dell'83,24% in euro.

Il secondo test sembrava ancora migliore: da 4.326 a 604 parole. Però la variante ricordava soltanto 3 fatti su 5 e perdeva due scadenze operative. Verdetto: bocciata per qualità.

Il dato utile non è “possiamo comprimere dell'83%”. È questo: la selezione funziona quando il pacchetto ridotto contiene già le fonti giuste; fallisce quando una fonte esclusa possiede un fatto che il lavoro deve ricordare.

Puoi leggere protocollo e limiti nella nota Distill del DL Frontier Lab.

Che cosa tende a funzionare di più

Non esiste una classifica universale, ma esiste un ordine prudente:

1. Chiamate, tentativi ripetuti e risultati inutili: impatto alto e rischio basso, perché elimini spreco puro.
2. Output più corto e strutturato: facile da misurare, spesso poco invasivo.
3. Routing di modello e ragionamento: può incidere molto sui volumi alti, ma richiede un buon test di qualità.
4. Cache del contesto stabile: molto efficace se il riuso è reale; irrilevante senza hit.
5. Selezione e distillazione del contesto: potenziale alto, rischio più alto; serve un gate sui fatti.
6. Batch: risparmio di listino chiaro sui provider che lo offrono, ma soltanto per lavori non urgenti.
7. Self-hosting o capacità riservata: può avere senso su carichi maturi; è una decisione infrastrutturale, non un trucco sui token.

Questo ordine evita di cominciare dalla leva più affascinante e finire con un sistema più complicato del problema.

Le scorciatoie che spesso non fanno risparmiare

• Scegliere il modello più economico per tutto. I tentativi ripetuti e le correzioni possono mangiare il vantaggio.
• Accorciare prompt e documenti alla cieca. Una frase tolta può contenere proprio l'eccezione costosa.
• Aggiungere un RAG senza misurare selezione delle fonti e qualità. Introduce altre chiamate, spazio occupato e nuovi punti di errore.
• Fare addestramento aggiuntivo, o fine-tuning, come prima mossa. Può servire per comportamento e specializzazione; non ripara un flusso che chiama troppo o porta dati inutili.
• Mettere in cache contenuto quasi sempre diverso. Paghi scrittura o storage senza riuso sufficiente.
• Ospitare un modello in proprio perché il listino API sembra alto. Il costo totale include GPU, picchi, osservabilità, aggiornamenti e persone reperibili.
• Guardare soltanto la fattura del modello. Strumenti, controlli di sicurezza, database, revisione e output scartati restano invisibili.

Un piano di prova in quattordici giorni

Giorni 1-2: rendi la spesa leggibile

Esporta almeno trenta giorni di utilizzo. Mappa provider, modello, ambiente e tipo di lavoro. Se mancano le etichette, ricostruisci un campione da log, endpoint o chiavi progetto.

Giorni 3-4: scegli il caso e il gate

Prendi un lavoro con volume o costo sufficiente. Raccogli venti casi rappresentativi, inclusi quelli difficili. Scrivi i fatti che devono sopravvivere e gli errori che rendono l'output inutilizzabile.

Giorni 5-8: costruisci la baseline

Esegui il flusso attuale. Registra costo tecnico, chiamate, tentativi ripetuti, qualità e minuti di controllo. Non correggere i numeri dopo aver visto la variante.

Giorni 9-11: prova una sola leva

Scegli la prima leva compatibile con il segnale: togli chiamate, limita la risposta, cambia instradamento, riusa il contesto, riducilo o sposta il lavoro in lotti. Mantieni tutto il resto uguale.

Giorni 12-14: decidi e lascia una ricevuta

Confronta soltanto i risultati che superano il gate. Promuovi, correggi o ripristina. Registra configurazione precedente, nuova configurazione, perimetro, risultato e prossimo controllo.

La scheda da copiare

• Lavoro: ___
• Volume mensile: ___
• Costo tecnico attuale: ___
• Risultati accettati: ___
• Costo per risultato accettato: ___
• Fatti che devono sopravvivere: ___
• Errori che bloccano la promozione: ___
• Prima leva da provare: ___
• Lotto di test: ___
• Regola di rollback: ___

Se non riesci a riempire costo, risultati accettati o fatti obbligatori, non sei pronto a ottimizzare. Sei pronto a costruire la baseline.

Nota sui prezzi e sulle funzioni dei provider

Le funzioni cambiano. Questa guida è stata verificata il 15 settembre 2026 sulle documentazioni ufficiali di OpenAI, Anthropic, Google Cloud e AWS. Elaborazione in lotti, cache e scelta automatica del modello hanno prezzi, soglie, durata e campi di utilizzo diversi. Controlla sempre la pagina corrente del fornitore prima di approvare un business case.

Fonti operative consultate:

• OpenAI: elaborazione Batch e prompt caching;
• Anthropic: prompt caching e Message Batches;
• Google Cloud: prezzi Vertex AI;
• AWS Bedrock: prompt caching e instradamento intelligente.

Se la spesa attraversa più provider o nessuno riesce ad attribuirla ai lavori reali, il servizio AI Spend Audit ricostruisce baseline, sprechi e prime prove entro un perimetro concordato. La richiesta è assistita: non è un acquisto automatico e non promette una percentuale di risparmio prima di vedere i dati.