Unit economics delle feature LLM nei prodotti B2B

Lo stack di costo reale di una feature LLM

Diretto: token del modello (input + output), embedding, reranker, infra vector o search, chiamate tool/API e markup vendor. Indiretto: engineering per eval e osservabilità, minuti di human review, escalate di support e spreco di run falliti. Gli agent moltiplicano il costo con loop e chiacchiere tra tool. Il RAG moltiplica il costo con volume di chunk e prompt ingenui 'metti più contesto'. Misura entrambi i path separatamente. Costruisci un modello semplice: successful_tasks × (modello + retrieval + review_minutes × loaded_rate) + infra fissa. Se non riesci a stimare, non puoi prezzare.

• Traccia il costo per task riuscito, non per messaggio chat
• Includi run falliti e abbandonati nella media
• Separa volume di pilot da volume enterprise contrattualizzato
• Rivedi le assunzioni quando cambiano modelli o prompt

Driver di costo di token e retrieval

I token di input dominano quando scarichi storie lunghe o cinquanta chunk retrieved. Limita il contesto, diversifica le fonti, cachea gli embedding e riusa il retrieval con attenzione tra follow-up. Scegli i tier di modello per task: classifier ed extractor economici upstream; modelli più forti solo dove la qualità del giudizio ripaga. Lo streaming non riduce i token fatturabili. Per il dettaglio ops RAG, vedi pratiche di costo e latenza RAG. Per gli agent, metti cap duri su iterazioni e tool call per run.

Human review come costo di prima classe

Ogni minuto di approvazione è COGS di prodotto se i reviewer sono staffati per la feature. Progetta code, SLA e batching così la review non cancella i guadagni di automazione. Instrada agli umani solo casi ad alto rischio o bassa confidence. Misura l'override rate: override alto significa che paghi due volte (modello + umano) con poco lift. Prodottizza il gate con design human-in-the-loop; le approvazioni ad-hoc su Slack non scalano economicamente.

• Prezza il tempo dei reviewer nella feature dal giorno uno
• Auto-approve solo dove rischio ed eval lo consentono
• Traccia il tempo mediano all'approvazione come metrica ops
• Evita UX di review che forza a rileggere interi documenti

Costi di support e fiducia

Le risposte sbagliate creano ticket, rimborsi e tempo di sales engineering. Bilancia per spiegabilità: citazioni, run trace e refusal chiari riducono i loop 'perché ha detto così'. Allinea le aspettative a SLA e modelli di support. AI 'best effort' serve comunque un escape hatch umano e gestione della severity documentata. Osserva i failure mode con osservabilità così spike di costo e regressioni di qualità emergono prima che se ne accorga finance.

Pricing e packaging dell'add-on AI

Pattern comuni: quota inclusa nel piano, usage a meter, tier più alto per AI, o per-seat con cap di fair-use. Allinea il packaging ai driver di costo: tenant pesanti di retrieval non devono condividere flat fee illimitate con light user per sempre. Pubblica soft e hard limit. Soft: avvisa e degrada con grazia. Hard: ferma lo spend con un upgrade path chiaro. Overage silenziosi distruggono fiducia; flat fee senza cap distruggono il margine. Lega le decisioni di packaging a quale pattern AI hai spedito: chat, RAG e agent hanno forme di usage diverse.

Margini e kill criteria

Imposta un target di contribution margin dopo modello, retrieval e review. Se l'economia del pilot funziona solo a volume giocattolo o con review non pagata del founder, non sopravviverà all'expand enterprise. Definisci trigger di kill o redesign: costo per successo sopra X, override rate sopra Y, ticket di support per 100 task sopra Z. Confronta build vs buy e tagli di scope usando prioritizzazione MVP e la forma del contratto via fixed price vs time and materials quando sono coinvolti partner di delivery.

• Rivedi le unit economics mensilmente durante il pilot
• Separa il budget di learning R&D dal COGS
• Non nascondere loss leader AI senza una strategia esplicita
• Ri-forecast quando abiliti write path o agent

Cost control di engineering che funzionano davvero

Hard cap: max token, max tool call, max chunk di retrieval, budget giornalieri per tenant. Caching: embedding, query identiche ripetute dove la freshness lo consente. Routing: modelli piccoli prima, escalate a bassa confidence. Versioning di prompt e grafo evita regressioni di costo silenziose. I gate di eval catturano 'vittorie di qualità' che triplicano la size del contesto. Per gli agent, preferisci grafi espliciti a loop open-ended; vedi design agentic. Per lo sprawl di tool, vincola con tool layer disciplinati.

Instrumentation per finance e ops

Tagga ogni run con tenant, feature, modello e outcome. Esporta aggregati giornalieri di costo e successo a finance senza scaricare i contenuti dei prompt. Alloca l'infra condivisa (vector DB, gateway) in modo equo così un tenant pesante non si nasconde sotto il COGS di piattaforma. Anche le scelte di sicurezza influenzano il costo: over-retention dei trace e logging duplicato gonfiano lo storage. Bilancia con sicurezza AI e retention di audit.

Prossimi passi

Costruisci un foglio con costo per task riuscito a tre volumi. Se il margine muore a scala enterprise, ridisegna prima di vendere seat AI illimitati. Vedi acceptance contractor per AI, altre risorse, case study, prenota una call o contatti per stress-testare pricing e architettura prima del prossimo ciclo commerciale.

Domande frequenti