BYOK vs Chiavi LLM Gestite: Come Prezzare le Funzionalità AI

Per default, includa i costi LLM nel prezzo dell'abbonamento (chiavi gestite) e offra il bring-your-own-key (BYOK) come opzione per gli account enterprise che dispongono già di contratti con i modelli o di requisiti di compliance. Il default sbagliato può erodere il margine a scala oppure introdurre un attrito sufficiente a distruggere la conversione self-serve.

Questa decisione si pone nel momento in cui si aggiunge qualsiasi funzionalità basata su LLM a un prodotto SaaS: un assistente in chat, una ricerca AI, un agente che redige email. Qualcuno deve pagare i token e qualcuno deve gestire l'API key. Sbagliare significa either trovarsi a sostenere costi di inferenza imprevedibili mentre il prodotto diventa virale, oppure costringere ogni utente in prova a registrarsi su OpenAI prima ancora di vedere qualsiasi valore.

I due modelli, senza giri di parole

Chiavi gestite: il suo backend detiene una (o poche) API key, chiama l'LLM per conto di ogni tenant e incorpora il costo dei token nel prezzo dell'abbonamento. Il cliente non vede mai né una chiave né il nome del provider.

BYOK: il cliente genera una propria API key da Anthropic, OpenAI o Azure, la incolla nella pagina delle impostazioni e la sua applicazione utilizza la chiave e il rapporto di fatturazione del cliente. Lei fattura il software e il workflow, non l'inferenza.

La maggior parte dei prodotti adotta il modello gestito come default perché garantisce una migliore esperienza di onboarding. Nessuno vuole abbandonare il flusso di registrazione per creare un account separato da qualche altra parte prima di poter provare il prodotto. Tuttavia, il pricing gestito significa che il margine lordo dipende dai prezzi dei token e dai pattern di utilizzo che non si controllano completamente — è esattamente il rischio descritto in multi-llm-provider-failover: una variazione di prezzo o un'interruzione di un singolo vendor diventa un problema suo, non una voce di costo trasferibile.

Perché questa è una decisione di pricing, non solo di architettura

I team tendono a trattare il BYOK come un toggle tecnico: aggiungere un campo nelle impostazioni, salvare la chiave, fine. In realtà è una decisione di pricing e packaging che determina l'economia unitaria del prodotto.

Con le chiavi gestite, ogni utente intensivo erode il margine. Un cliente che esegue 50.000 completamenti al mese sul piano da $99/mese è sussidiato dai clienti che ne eseguono 500. Va bene a piccola scala, ma si rompe nel momento in cui i clienti ad alto utilizzo si concentrano sul tier più economico — una variante della stessa trappola descritta in saas-pricing-models: il flat pricing funziona finché la varianza di utilizzo non diventa abbastanza ampia da penalizzare i migliori clienti o il margine.

Con il BYOK il margine è protetto perché il cliente paga direttamente il provider LLM. Ma si introduce un attrito in fase di setup per ogni utente e si assume un carico di supporto: chiavi scadute, rate limit raggiunti, tier di accesso al modello errati e clienti confusi che cercano di capire perché "il suo prodotto" restituisce un errore che in realtà proviene dall'account del loro provider.

Il calcolo dei costi da fare prima di decidere

Prima di scegliere un default, strumenti il consumo effettivo di token per funzionalità — non una stima ricavata da una singola sessione demo. Registri i token in input e in output per ogni richiesta in staging, esegua i prompt reali con le lunghezze di output attese e moltiplichi per gli utenti attivi mensili previsti per ciascun tier. Il divario tra "quello che avevamo ipotizzato" e "come appare l'utilizzo reale" è in genere un fattore da 3 a 5x, soprattutto per le funzionalità agentiche che effettuano più tool call per ogni azione utente.

È anche il punto in cui l'architettura delle chiamate conta quanto il modello di pricing. Nel nostro strumento di outreach, avevamo originariamente diviso la qualificazione dei lead in chiamate separate: una per estrarre i dati aziendali da una pagina scraped, un'altra per redigere l'email. Consolidando tutto in un'unica chiamata che estrae i dati e redige l'email in un solo passaggio, abbiamo ridotto significativamente la spesa per token e, se possibile, migliorato la qualità dell'output, perché il modello disponeva del contesto completo in un'unica richiesta invece di perderlo tra un passaggio e l'altro. Se si gestiscono chiavi gestite, questo tipo di consolidamento è la differenza tra una funzionalità redditizia a $49/mese e una che non lo è. Vale la pena eseguire l'analisi descritta in llm-cost-optimization prima di finalizzare qualsiasi modello di pricing, perché una funzionalità con molte chiamate concatenate rende il pricing gestito molto più difficile da sostenere e l'attrito del BYOK molto più difficile da giustificare.

Quando il BYOK è il default giusto

Si consideri lo stesso cliente da 50.000 completamenti al mese dell'esempio precedente in un'ottica BYOK: con le chiavi gestite è lui ad essere sussidiato dai clienti con 500 completamenti; con il BYOK, la sua bolletta per i token va direttamente sul suo account OpenAI o Anthropic e smette di essere un problema proprio. È questo il pattern da osservare, non una checklist da applicare meccanicamente. Il BYOK tende a essere la scelta giusta quando:

• I clienti sono enterprise che dispongono già di contratti LLM negoziati (sconti sul volume, condizioni di data residency o un vendor specifico imposto dal proprio team di compliance)
• L'utilizzo è per natura ad alto volume e discontinuo, come un assistente alla programmazione o un processore di documenti in bulk, dove il pricing per seat non riesce ad assorbire la varianza come nel caso del tier da $99/mese descritto sopra
• Il team di sicurezza dell'acquirente richiede che nessuna terza parte (inclusa la propria azienda) possa accedere ai prompt o agli output, il che è frequente nei settori sanitario e legale
• Si sta vendendo uno strumento per sviluppatori il cui pubblico già gestisce API key come parte del normale flusso di lavoro

Quando le chiavi gestite sono il default giusto

Le chiavi gestite hanno più senso esattamente per il profilo descritto nell'aneddoto sul nostro strumento di outreach: una funzionalità in cui si controlla il pattern delle chiamate in modo sufficientemente preciso da poter consolidare due chiamate in una come leva per proteggere il margine, anziché trasferire quel costo al cliente. Questo è possibile solo se si detiene la chiave e si riceve la fattura. Il modello gestito tende a essere la scelta giusta quando:

• Si vende a buyer non tecnici che non genereranno mai autonomamente un'API key
• L'utilizzo per cliente è sufficientemente prevedibile da essere incorporato in piani flat o a tier, come presuppone un tier da $49 o $99 al mese
• Il time-to-value conta più della protezione del margine — il che è quasi sempre vero prima di aver raggiunto il product-market fit
• La funzionalità AI è una componente di un prodotto più ampio, non il prodotto stesso, quindi il costo dei token è una frazione piccola del COGS complessivo

L'approccio ibrido su cui convergono i prodotti più maturi

Si cominci con il modello gestito per il self-serve e i tier inferiori, dove l'attrito in fase di onboarding è il rischio maggiore rispetto alla protezione del margine. Si aggiunga il BYOK come opzione per il tier enterprise nel momento in cui i clienti lo richiedono — di solito gli stessi clienti che hanno bisogno di SSO, audit log e un DPA firmato. Questo rispecchia il modo in cui vengono prese la maggior parte delle decisioni di multi-tenant-saas-architecture in generale: si costruisce prima il default semplice, si aggiunge il percorso configurabile solo quando un segmento reale di clienti lo richiede e si mantengono i due percorsi dietro la stessa interfaccia di funzionalità, così che passare un tenant dal modello gestito al BYOK non richieda una riscrittura.

Qualunque default si scelga, non lo si renda hardcoded. Si salvi la sorgente della chiave (gestita vs fornita dal tenant) come valore di configurazione per tenant fin dal primo giorno, anche se tutti i tenant partono con il modello gestito. Adattare a posteriori il BYOK a una codebase che presupponeva un'unica API key globale è un progetto più impegnativo di quanto sembri — il tipo di debito tecnico descritto in technical-debt-management che costa poco evitare in anticipo e molto eliminare in seguito.

Se sta definendo l'ambito di una funzionalità AI e non è sicuro di quale modello si adatti al suo customer base e agli obiettivi di margine, ne parliamo.