Prezzi per agenti IA: quanto far pagare ai clienti

Indice

Pubblicato ad agosto 2026.

TL;DR: Non fissare il prezzo di un agente IA a ore. Dividilo in due voci: una fee di costruzione fissa per il sistema iniziale e un canone di manutenzione mensile per mantenerlo attivo. La fee di costruzione copre sviluppo, test e lavoro di integrazione. Il canone esiste perché gli agenti si rompono — i prompt si degradano, le API cambiano, emergono casi limite — e “finito” non è uno stato reale per qualsiasi cosa tocchi un modello. Salta il canone e nel giro di un mese starai facendo supporto gratuito.

[Prospettiva dell’operatore] Gestisco più di 30 agenti in produzione tra un brand di consulenza e Pickleland, una struttura di pickleball a Pflugerville, TX, e ho fissato i prezzi per lavori di costruzione di agenti per clienti basandomi su questa esperienza. L’errore più comune che vedo — sia nei freelance che nelle agenzie — è trattare un agente IA come un sito web: preventivo, costruzione, consegna, fattura pagata per intero. Gli agenti non sono siti web. Sono sistemi che continuano a richiedere attenzione perché ciò che sta sotto (un modello, un’API, il flusso di lavoro di un cliente) continua a cambiare. Fissa il prezzo tenendo conto di questa realtà, altrimenti ne pagherai il costo di tasca tua.

Perché la fatturazione oraria non funziona per il lavoro sugli agenti

La fatturazione oraria ti penalizza quando diventi più veloce. Più build di agenti consegni, più prompt riutilizzabili, eval e impalcature (scaffolding) accumuli — e più veloce diventa la build successiva. Se fatturi a ore, ogni guadagno di efficienza riduce la tua fattura. È il contrario di quello che dovrebbe succedere.

Penalizza anche il cliente, ma nella direzione opposta. Un cliente che assume per un agente IA non ha modo di giudicare se “12 ore” per un flusso di lavoro siano giuste, veloci o gonfiate. Sta comprando una scatola nera con un prezzo basato su un numero che non può verificare. Questa incertezza spinge i clienti a negoziare al ribasso, ritardare l’approvazione o scegliere il preventivo orario più economico invece del migliore.

La soluzione è la stessa che funziona per qualsiasi offerta produttizzata: fissa il prezzo su un ambito definito e sul valore del risultato, non sul tempo. Nel caso specifico del lavoro sugli agenti, questo significa due componenti separate a prezzo fisso — perché una build e la sua manutenzione sono prodotti genuinamente diversi, con strutture di costo diverse.

La struttura in due parti: fee di costruzione + canone di manutenzione

1. Fee di costruzione — un prezzo fisso una tantum per progettare, costruire, testare e distribuire l’agente. Si paga una sola volta, di solito in due rate (acconto all’avvio, saldo alla consegna).

2. Canone di manutenzione — una fee mensile ricorrente che parte dal mese successivo al lancio. Copre il monitoraggio, le correzioni ai prompt quando il modello o un’API a monte cambiano, e piccoli aggiustamenti che non alterano l’ambito.

Unire le due voci in un unico numero è l’errore di pricing più grande in questa nicchia. Un cliente che paga una sola volta non ha alcuna ragione economica per aspettarsi qualcosa dopo la consegna, e tu non hai alcuna ragione economica per continuare a controllare un agente che ti è stato pagato un mese fa. Separarle rende l’incentivo onesto: vieni pagato per mantenere qualcosa funzionante, quindi lo mantieni funzionante.

Questo rispecchia il framework che uso per decidere se costruire un’automazione — vedi ROI degli agenti IA: vale la pena automatizzare?. Quel post è scritto dal lato dell’acquirente: come un’azienda dovrebbe valutare se un agente ripaga il suo costo. Questo post è il lato del venditore della stessa matematica — il costo di costruzione e la tassa di manutenzione in quel framework sono esattamente le due cose a cui stai dando un prezzo qui.

Dimensionare la fee di costruzione

Dimensiona la fee di costruzione in base al livello di ambito, non indovinando le ore. Tre livelli coprono la maggior parte del lavoro con i clienti:

Questi range presuppongono un confine di ambito ben definito, la stessa disciplina descritta in come costruire un servizio produttizzato: un elenco scritto di cosa è incluso, un elenco scritto di cosa non lo è, e un numero fisso di flussi di lavoro o integrazioni con strumenti. Un cliente che chiede “un agente IA per la mia azienda” senza un flusso di lavoro definito non è pronto per comprare una build — è pronto per una call di scoping, che è un deliverable separato e più piccolo (io la fisso a un prezzo fisso di $500–$1,000 per un audit che produce il documento di ambito su cui viene quotata la fee di costruzione).

All’interno di ogni livello, il numero effettivo si muove in base a tre fattori: quanti strumenti distinti l’agente chiama, quanto dei test deve essere fatto su dati reali e disordinati del cliente invece che su casi di test puliti, e quanto è tollerante la modalità di fallimento. Un agente che redige un post social per la revisione umana può sbagliare occasionalmente a basso costo. Un agente che invia un’email di conferma o sposta denaro non può — e questo cambia il budget dei test più di quanto cambi il codice.

Dimensionare il canone di manutenzione

Fisso il canone come percentuale della fee di costruzione, non come cifra fissa, perché il costo di manutenzione scala con la complessità del sistema allo stesso modo del costo di costruzione.

maintenance_retainer_per_month = build_fee × monthly_rate

monthly_rate:
  stable integrations, low API-change risk        → 3–5%
  volatile APIs (social platforms, scraped data)   → 6–10%
  multi-agent systems, custom eval suite to keep up → 8–12%

Per una build multi-step da $6,000 su uno stack moderatamente stabile, sono circa $250–$400/mese. Questo numero dovrebbe risultare strettamente legato alla tassa di manutenzione che applico alle mie automazioni — un 20% fisso del costo di costruzione all’anno, che equivale allo stesso range del 3–5% mensile nella fascia bassa. Il canone rivolto al cliente si colloca sullo stesso ordine di grandezza perché il fattore di costo sottostante — la deriva dei prompt, i cambiamenti alle API a monte, i casi limite che emergono dopo il lancio — non cambia solo perché a pagare è qualcun altro.

Quello che il canone esplicitamente non include: nuovi flussi di lavoro, nuove integrazioni o modifiche di ambito. Quelli sono nuovi preventivi per fee di costruzione. Un canone che assorbe silenziosamente un “puoi farlo gestire anche questo altro caso” si trasforma in lavoro di feature non pagato nel giro di un trimestre — la stessa modalità di fallimento descritta in perché le offerte produttizzate hanno bisogno di un confine di ambito rigido, applicata al lavoro continuativo invece che alla build iniziale.

Ancora il prezzo a ciò che sostituisce, non a quanto costa costruirlo

La fee di costruzione non dovrebbe essere giustificata al cliente con le tue ore — dovrebbe essere giustificata dal costo manuale che elimina. Prima di fare un preventivo, esegui lo stesso calcolo del costo manuale del framework ROI, applicato al lato del cliente:

manual_cost_per_year = time_per_instance × hourly_rate × frequency_per_year
                      + error_cost_per_year

Se il team di un cliente dedica 5 ore a settimana a un compito che un agente può svolgere, a un costo pienamente caricato di $40/ora, sono $10,400/anno di costo manuale. Una fee di costruzione di $6,000 con un canone di $300/mese ($3,600/anno) si ripaga in ben meno di un anno e continua a ripagarsi ogni anno successivo. Quel confronto — costo manuale contro costo di build più canone — è il vero argomento di vendita. Portalo in ogni proposta. Un prezzo senza un punto di confronto è solo un numero; un prezzo accanto a ciò che sostituisce è un argomento.

Questo fissa anche un tetto naturale: se il costo manuale da sostituire è piccolo, il cliente non dovrebbe comprare un sistema multi-agente da $15,000, e tu non dovresti vendergliene uno. Dimensionare correttamente il livello rispetto al costo effettivo che viene sostituito è ciò che mantiene il pricing onesto in entrambe le direzioni.

Clausole contrattuali che prevengono lo scope creep

Oltre al prezzo, in ogni contratto di build di un agente che scrivo inserisco quattro clausole:

1. Una definizione scritta di “finito”. Casi di test specifici che l’agente deve superare prima che sia dovuto il pagamento finale — non “funziona bene”, ma un elenco: “classifica correttamente 9 lead campione su 10 dal dataset fornito”, “pubblica con successo sulla pagina Facebook collegata senza intervento manuale”. Criteri di accettazione ambigui sono la fonte numero uno di lavoro extra non pagato.
2. Condizioni di proprietà, dichiarate in modo chiaro. Il cliente possiede la logica del flusso di lavoro e ogni dato specifico del cliente. Tu mantieni l’impalcatura riutilizzabile, i template di prompt e i banchi di eval che non sono specifici della sua attività — lo stesso punto sul riutilizzo della proprietà intellettuale trattato in sistemi di delivery dei servizi produttizzati. Dillo in anticipo; evita una conversazione scomoda in seguito.
3. Un passaggio di consegne definito per la cancellazione del canone. Se il cliente cancella la manutenzione, chiarisci cosa succede: l’agente continua a funzionare così com’è senza ulteriori correzioni, oppure viene disattivato dopo un periodo di preavviso. Lasciarlo indefinito significa restare responsabile di un sistema che nessuno ti paga più per controllare.
4. Richieste di modifica quotate separatamente, per iscritto, prima che il lavoro inizi. Non “ci penseremo” — una tariffa o un minimo per richiesta, indicati nel contratto, così che un cliente che chiede una modifica di ambito non sia ogni volta una trattativa.

Come gestire le due obiezioni che emergono ogni volta

“Perché costa extra mantenere qualcosa che già funziona?” Perché “funziona” è un’istantanea, non uno stato. Il fornitore del modello può deprecare o modificare il comportamento di un modello, la piattaforma su cui l’agente pubblica può cambiare la sua API, e l’azienda stessa del cliente può cambiare il flusso di lavoro attorno a cui è stato costruito l’agente. Niente di tutto questo è un bug in ciò che hai consegnato — è il normale tasso di decadimento di qualsiasi sistema collegato a parti esterne e in movimento. Presento il canone esplicitamente come un’assicurazione contro quel decadimento, non come “supporto” continuativo — il supporto implica che qualcosa si sia rotto; un canone significa che qualcuno lo controlla prima che si rompa.

“Non posso semplicemente usare uno strumento no-code e saltare del tutto la fee di costruzione?” A volte sì — e lo dico apertamente. Se il flusso di lavoro è davvero semplice (un unico trigger, un’unica azione, nessuna logica personalizzata), una piattaforma di automazione no-code è la risposta onesta, e indirizzerò il cliente lì invece di fare un preventivo per una build. La fee di costruzione è giustificata quando c’è vera logica, lavoro di integrazione o giudizio coinvolti che uno strumento drag-and-drop non può esprimere. Rifiutare un incarico che non è adatto è ciò che rende credibili quelli che accetti.

Gli strumenti che uso per gestire tutto questo

Notion — qui vive il documento di ambito: cosa è incluso, cosa non lo è, l’elenco dei test di accettazione e le condizioni di proprietà, condivisi con il cliente prima di raccogliere qualsiasi acconto.

Airtable — una riga per ogni incarico attivo, con lo stato della build, la data di fatturazione del canone e l’ultima volta che l’output di ciascun agente è stato controllato a campione.

Claude è ciò su cui costruisco la maggior parte di questi agenti — il pricing del canone sopra presuppone uno stack di modelli con prezzi e comportamento ragionevolmente stabili, il che cambia l’assunzione di volatilità nella formula del tasso mensile se usi un fornitore meno stabile.

FAQ

L’acconto dovrebbe essere del 50% o un’altra cifra?

50% all’inizio, 50% alla consegna a fronte dei criteri di accettazione scritti è la struttura più semplice ed è quella che uso di default. Per build multi-agente più grandi (il livello $15,000+), divido in tre: acconto, un pagamento intermedio a un prototipo funzionante, e il saldo alla consegna — soprattutto per evitare che una grande fattura finale arrivi a un cliente che è diventato silenzioso a metà progetto.

E se il cliente vuole pagare solo la manutenzione, senza che io abbia costruito l’agente originale?

Accetto questo tipo di incarichi, ma fisso il prezzo del primo mese più alto per coprire un audit: leggere i prompt e il codice esistenti, eseguire i test di accettazione che avrei scritto io stesso, e documentare quello che trovo. Non puoi impegnarti responsabilmente in un canone di manutenzione su un sistema che non hai costruito e non hai verificato — il mese di audit è ciò che trasforma un’incognita in un numero reale.

Come faccio a sapere se la mia assunzione di tasso mensile (3–12%) è troppo bassa?

Traccia le ore di manutenzione effettive per un trimestre rispetto a quanto ha pagato il canone. Se spendi costantemente più tempo di quanto il canone copra, alza la tariffa al rinnovo — non assorbirlo silenziosamente. La formula è un punto di partenza calibrato sulla stessa logica della tassa di manutenzione che uso per i miei agenti; la frequenza reale dei cambiamenti alle API e la tolleranza del cliente per i casi limite la faranno spostare.

Mi serve un contratto separato per la call di scoping?

Per tutto ciò che va oltre una rapida telefonata, sì — fissa un prezzo per l’audit di scoping come deliverable piccolo a sé stante, con un proprio output scritto (il documento di ambito), anche se hai intenzione di scontare il suo costo dalla fee di costruzione se il cliente procede. Questo evita che la fase di scoping stessa diventi lavoro di vendita non pagato.

Prossimi passi: Il mio corso AI Agents for Beginners copre la costruzione degli agenti che questo framework di pricing presuppone tu sappia già consegnare. Il programma cowork è per gli operatori che vogliono un ambiente strutturato per costruire e fissare il prezzo di questo tipo di lavoro. Se preferisci farti costruire prima l’audit e il documento di ambito, prenota una sessione di 30 minuti.