I Costi API LLM Sono COGS, Non Spese Generali: Una Guida al Margine Lordo per Wrapper IA

Un fondatore che gestisce un assistente di scrittura basato sull'IA mi ha detto che i suoi "costi software" erano di $40.000 al mese. Analizzando la cifra, $34.000 erano fatture delle API di OpenAI e Anthropic — e nessuna di queste era inclusa nel suo costo del venduto. Era nella generica voce "Software & Abbonamenti", proprio accanto al suo strumento di project management da $19 al mese. Il suo margine lordo dichiarato era del 91%. Il suo margine lordo reale, una volta spostata l'inferenza dove doveva stare, era del 58%.

Non è un tecnicismo contabile. È la differenza tra un'impresa che assomiglia a un software e un'impresa che si comporta come una fabbrica — dove ogni unità venduta consuma un input variabile e reale. Se stai costruendo sopra GPT-5, Claude, Gemini, o qualsiasi modello ospitato, la tua fattura LLM non è una spesa generale. È costo del venduto, e trattarla diversamente significa che non sai realmente quanti soldi guadagni.

Perché Questo Errore è Così Facile da Commettere​

Il SaaS tradizionale ha addestrato una generazione di fondatori a pensare ai costi software come fissi. Paghi per l'hosting, paghi per il tuo CRM, paghi per Slack — e nessuna di queste fatture varia in base all'utilizzo del tuo prodotto da parte di un singolo cliente. Quindi, quando arriva la prima fattura API da OpenAI, è naturale classificarla nello stesso secchio mentale: "strumenti che paghiamo per far funzionare l'azienda".

Il problema è che una fattura API LLM non si comporta come un abbonamento SaaS. Si comporta come una materia prima. Ogni volta che un cliente invia un prompt, consumi token, e ogni token ha un prezzo. Un cliente che esegue 50 richieste al giorno ti costa significativamente di più da servire rispetto a uno che ne esegue 2. Questa è la definizione da manuale di costo del venduto: un costo che scala direttamente con la consegna del tuo prodotto a un cliente specifico, al contrario di un costo che pagheresti solo per tenere le luci accese indipendentemente dall'utilizzo.

I dati di settore confermano quanto questo sia diventato rilevante. Il report sullo stato dell'IA di ICONIQ del gennaio 2026 ha rilevato che l'inferenza ora rappresenta in media il 23% del fatturato totale nelle aziende B2B IA in fase di scaling, e l'84% di queste aziende ha riportato un'erosione del margine lordo di sei punti percentuali o più direttamente attribuibile ai costi dell'infrastruttura IA. Non è un errore di arrotondamento da assorbire in "costi operativi vari". È spesso il singolo fattore di costo più grande nell'azienda, e merita di essere trattato come tale.

La Linea COGS vs. OpEx, Tracciata Correttamente​

La regola che separa il COGS dalle spese operative non è cambiata solo perché l'input è un'API di un modello invece di un magazzino pieno di pezzi: i costi per fornire il tuo prodotto a un cliente pagante appartengono al COGS; i costi per costruire il tuo prodotto appartengono alla R&S sotto OpEx. Applicata a un wrapper IA, questa suddivisione si presenta così:

Appartiene al COGS:

• Costi di inferenza di produzione — ogni chiamata API che il tuo prodotto live fa per conto di un cliente pagante, sia essa un completamento chat, una chiamata di embedding, un passaggio di classificazione o un ciclo di chiamate di strumenti di un agente
• Hosting del modello / Calcolo GPU — se stai eseguendo un modello open-weight sulla tua infrastruttura o su Infrastructure noleggiata invece di chiamare un'API ospitata, il tempo di calcolo attribuibile al servizio delle richieste dei clienti
• Infrastruttura di inferenza di supporto — query del database vettoriale, esecuzioni di pipeline di embedding e overhead di orchestrazione che esistono specificamente per servire le richieste di produzione
• Costi di supporto specifici per l'IA — un ingegnere di supporto il cui lavoro è triage dei problemi di output del modello per i clienti è un costo di fornitura del prodotto, non una spesa SG&A generale

Appartiene alle OpEx (solitamente R&S):

• Inferenza di sviluppo e test — ogni prompt che un ingegnere invia mentre itera su una funzionalità, debugga una regressione o valuta una nuova versione del modello
• Esecuzioni di messa a punto e valutazione — costruire o migliorare il modello è R&S, non fornitura
• Strumenti IA interni — i posti ChatGPT Enterprise del tuo team o le licenze GitHub Copilot sono una spesa di produttività, non un costo per servire i clienti

Il passo pratico che rende possibile questa suddivisione è noioso ma essenziale: usa chiavi API separate o progetti di fatturazione per il traffico di produzione e sviluppo fin dal primo giorno. Se i tuoi ingegneri testano prompt con la stessa chiave che il tuo prodotto usa in produzione, non hai modo di allocare correttamente la fattura a posteriori, e finirai per sovrastimare o sottostimare il tuo margine reale ogni mese.

Che Aspetto ha il "Vero" Margine Lordo per i Prodotti IA​

Una volta fatta la suddivisione, aspettati che il numero che ne esce sia diverso da quello a cui sei abituato. Le aziende SaaS tradizionali puntano a margini lordi del 70-80% quasi per prassi. I prodotti IA nativi non ci arrivano allo stesso modo. Il playbook di pricing di Bessemer Venture Partners del febbraio 2026 colloca i margini lordi tipici dei prodotti IA al 50-60%, ben al di sotto del range 80-90% per il SaaS tradizionale, e i dati ICONIQ mostrano che la media di settore del margine lordo dei prodotti IA sta salendo — ma solo al 52%, in aumento dal 41% nel 2024 e dal 45% nel 2025.

Una regola pratica utile emersa dagli operatori che gestiscono questo aspetto attentamente: mantieni i costi LLM al di sotto di circa il 20% del COGS totale se vuoi un modello di business durevole e scalabile. Supera quella soglia e la compressione del margine tende ad accelerare man mano che cresci, invece di attenuarsi, perché i clienti più grandi usano il prodotto di più, non di meno. Alcune categorie ad alta intensità IA — assistenti di codifica, agenti di elaborazione documenti — hanno rapporti di costo LLM del 30-40% del COGS e rimangono comunque redditizie, ma solo perché hanno fissato il prezzo deliberatamente intorno a questa realtà, invece di arrivarci per caso.

Il numero che conta davvero non è il tuo margine lordo medio a livello aziendale — è il costo per cliente. Gli utenti pesanti di una funzionalità IA possono costare da 50 a 100 volte di più da servire in termini di inferenza grezza rispetto agli utenti leggeri sullo stesso identico livello di abbonamento. Se non monitori questo, non sai quali clienti sono redditizi e quali stai sussidiando silenziosamente ogni mese. Un piano a tariffa fissa che sembrava andare bene con i tuoi primi dieci clienti può iniziare a perdere soldi nel momento in cui uno di loro mette in produzione un flusso di lavoro e moltiplica il volume delle loro richieste per 20x.

Costruire il Modello di Costo per Richiesta​

Non hai bisogno di strumenti elaborati per iniziare — hai bisogno di disciplina nel registrare i numeri giusti per ogni richiesta. La formula di base è semplice:

costo_richiesta = (token_input / 1.000.000) × prezzo_input_per_milione
                + (token_output / 1.000.000) × prezzo_output_per_milione

I token di output costano tipicamente 2-5x in più dei token di input per unità, perché la generazione è più intensiva dal punto di vista computazionale rispetto alla lettura di un prompt — quindi un modello di costo per richiesta che traccia solo i token totali senza separare input da output misurerà sistematicamente in modo errato qualsiasi cosa con completamenti lunghi. Come esempio pratico per il pricing di metà 2026: una richiesta con 2.000 token di input e una risposta di 500 token per un modello mainstream di fascia media all'incirca ($3 input / $15 output per milione di token) costa circa $0,0135. Eseguendo la stessa forma di richiesta 50.000 volte al mese, stai guardando circa $675 in costo di inferenza per quella singola funzionalità — un numero invisibile se è sepolto in una voce "costi cloud" a cinque cifre, ma molto visibile una volta che è etichettato per la funzionalità e il segmento di clienti che lo ha generato.

Per rendere tutto ciò attuabile:

1. Registra il conteggio dei token per ogni richiesta, non solo il costo — la maggior parte dei provider di modelli restituisce il conteggio dei token di input/output nella risposta API stessa, quindi questo è un cambiamento di logging, non una nuova fonte di dati.
2. Etichetta ogni richiesta con un ID cliente e un identificatore di funzionalità in modo da poter aggregare i costi per account e per superficie del prodotto, non solo per mese.
3. Calcola il costo per cliente per periodo di fatturazione e confrontalo con quanto quel cliente ti paga. Questo è il numero che ti dice se i tuoi livelli di prezzo corrispondono effettivamente al tuo costo di consegna, non al tuo margine medio aggregato.
4. Instrada verso modelli più economici dove la qualità lo consente. Non tutte le richieste necessitano del tuo modello più capace (e più costoso) — classificazione, estrazione e attività di formattazione semplice spesso funzionano in modo accettabile su un modello più piccolo ed economico, e il routing dei modelli è una delle poche leve di margine che controlli completamente, a differenza dei prezzi dei provider.

Fissare il Prezzo per Proteggere il Margine Che Hai Appena Trovato​

Una volta che l'inferenza è correttamente classificata come COGS, la tua conversazione sul prezzo cambia. Un'ancora comune che gli operatori usano è fatturare circa 3-5 volte il costo unitario del token, in modo che un'attività da $0,30 venga prezzata a $1,00 o più — non perché quel multiplo sia magico, ma perché lascia spazio per assorbire la varianza di utilizzo, la volatilità del prezzo del modello e i costi di supporto e infrastruttura che viaggiano insieme all'inferenza grezza.

La fatturazione basata sull'utilizzo è diventata lo standard con cui le aziende IA mantengono prezzi e COGS allineati: addebitare per token, per richiesta o per attività completata, e le tue entrate scalano con la stessa variabile che guida il tuo costo, invece di allontanarsi da essa come fa un abbonamento piatto quando l'utilizzo aumenta. Se non sei pronto per passare completamente alla fatturazione basata sull'utilizzo, costruisci almeno livelli di minimo garantito più eccedenze in modo che un cliente che supera l'utilizzo tipico non diventi silenziosamente un loss leader per il resto del mese.

Mantieni la Tua Struttura di Costo Revisionabile Quanto il Tuo Codice​

Niente di tutto questo è igiene contabile facoltativa — è la differenza tra sapere che il tuo modello di business funziona e scoprire che non funziona durante una chiamata di due diligence per la raccolta fondi, quando un associato di un investitore costruisce il modello di costo per cliente che avresti dovuto costruire sei mesi prima. I fondatori che evitano quella conversazione sono quelli che etichettano i costi di inferenza per clienti e funzionalità dalla prima chiamata API, non quelli che aspettano fino a quando la fattura OpenAI è troppo grande per essere ignorata.

Beancount.io ti offre una contabilità in testo semplice e con controllo di versione che rende semplice etichettare la spesa per l'inferenza nel conto giusto, separare l'utilizzo API di produzione dallo sviluppo e riconciliare il tuo COGS reale con le entrate ogni mese — nessuna categorizzazione a scatola chiusa, nessun vincolo al fornitore. Inizia gratuitamente e scopri perché gli sviluppatori e i fondatori IA nativi stanno passando alla contabilità in testo semplice.