Il Modulo XI (Costi e AI FinOps) contabilizza la spesa AI dal flusso di costi del provider e applica i budget. Al raggiungimento del tetto, un gate di budget nega la spesa. Questo è enforcement dal vivo, sempre cablato nel binario predefinito — non una funzionalità on-demand che configuri successivamente. Se un budget è configurato, il gate è attivo.
Gate di budget
Un gate di budget ha due modalità di enforcement:
- Throttle — limita il tasso di spesa, degradando gradualmente. L’agente viene rallentato, non fermato del tutto, finche il budget si riprende o un operatore lo alza.
- Block — negazione netta al tetto. L’agente riceve un segnale chiaro che il suo budget e esaurito e nessuna ulteriore spesa e autorizzata.
Entrambe le modalità sono deny-closed: se lo stato del budget è illeggibile — un errore del datastore, una riga corrotta, un record mancante — il gate nega, non permette mai. Uno stato di budget sconosciuto viene trattato come esaurito, non come illimitato. Questa è la stessa postura che il resto della piattaforma mantiene per i gate di enforcement (vedi governance).
Contabilita dei costi
La spesa è derivata dal flusso di costi del provider e dal pricing di riferimento verificato dall’operatore gestito dal Modulo X (Gestione modelli e provider). I campioni di costo provengono dalla telemetria osservata — i token, il modello, il provider — non dall’intercettazione delle chiamate API. La piattaforma non si interpone nel percorso di inferenza; legge il segnale di costo fuori banda, allo stesso modo in cui legge ogni altra osservazione.
Il pricing di riferimento è verificato dall’operatore, non fabbricato. Il Modulo X ti permette di dichiarare il prezzo per token o per richiesta per ogni modello e provider, e l’enforcement del budget usa quel pricing come base contabile. Se il prezzo dichiarato diverge da ciò che il provider effettivamente addebita, il gate di budget applica il prezzo dichiarato — la piattaforma non può conoscere la fattura del provider finche il provider non la comunica.
Configurare un budget
I budget si applicano a tre livelli:
- Per tenant — un tetto per tutta la spesa AI all’interno di un tenant.
- Per agente — un tetto per la spesa di un singolo agente, all’interno del suo tenant.
- Per modello — un tetto per la spesa su un modello specifico, all’interno di un tenant o agente.
L’enforcement e immediato. Una volta configurato un budget con un tetto è una modalità del gate (throttle o block), il gate è attivo. Non c’e riscaldamento, nessun ritardo, nessun “l’enforcement iniziera dopo il prossimo ciclo di fatturazione”. Il gate verifica la spesa accumulata rispetto al tetto su ogni evento di costo governato.
Gli ambiti dei budget si compongono per intersezione: un budget per agente e uno per tenant si applicano entrambi, e il primo tetto raggiunto attiva il suo gate. Un budget per modello all’interno di un agente e ulteriormente ristretto da qualsiasi budget per agente e per tenant al di sopra.
Cosa succede al tetto
Quando la spesa accumulata raggiunge o supera il tetto configurato:
- Il gate di budget nega la spesa — throttle o block, a seconda della modalità.
- La negazione viene registrata come una segnalazione nella superficie delle segnalazioni della piattaforma, con l’ambito del budget, il tetto è la spesa accumulata al momento della negazione.
- L’agente riceve un segnale chiaro che il suo budget e esaurito. La piattaforma non scarta silenziosamente la richiesta e non restituisce un errore ambiguo.
- Se le notifiche sono configurate, la negazione viene instradata tramite il Modulo XV.
Una spesa negata e un evento governato. Viene scritta nel registro di audit nella stessa transazione della negazione, quindi non c’e finestra in cui una negazione di budget non sia registrata.
Notifiche
Gli avvisi di budget si integrano con il Modulo XV (Integrazioni di output e notifiche). Quando un budget si avvicina o raggiunge il tetto, la segnalazione può essere instradata a qualsiasi destinazione configurata:
- Slack / Teams — notifica su canale o messaggio diretto.
- PagerDuty / Opsgenie — escalation dell’allarme.
- Webhook firmato — per integrazioni personalizzate.
- SIEM — aggiunto al flusso di esportazione dell’audit.
Le destinazioni delle notifiche sono configurate dall’operatore. Un gate di budget applica l’enforcement indipendentemente dal fatto che una destinazione di notifica sia configurata — il gate e l’enforcement, la notifica e il livello di consapevolezza.
L’interazione con il kill switch
Il kill switch e il gate di negazione a livello di estate e sovrascrive tutto, inclusi i gate di budget. Quando il kill switch e attivato:
- Tutta l’attuazione governata viene negata, inclusa qualsiasi spesa che i gate di budget avrebbero altrimenti consentito tramite throttle o permesso.
- La modalità throttle/block di un gate di budget è irrilevante — l’estate e fermato.
- La riabilitazione dell’estate richiede la consueta approvazione a doppio controllo (due umani distinti, nessun percorso break-glass per la riabilitazione).
Il gate di budget e il kill switch sono controlli indipendenti. Si compongono, non competono: il kill switch e una negazione sovrainsieme che sussume ogni altro gate.
Routing dei modelli e budget
Il Modulo X gestisce il routing dei modelli con pricing di riferimento verificato dall’operatore. L’enforcement del budget consuma questo pricing — non mantiene una propria tabella prezzi e non fabbrica dati di costo. La dipendenza e unidirezionale:
- Il Modulo X dichiara il catalogo dei modelli e i prezzi di riferimento.
- Il Modulo XI legge quei prezzi per contabilizzare la spesa e applicare i tetti di budget.
Se il Modulo X non ha un prezzo di riferimento per un modello, il Modulo XI non può contabilizzare la spesa rispetto a un budget. La spesa non governata (nessun prezzo, nessun budget) viene presentata come segnalazione, non passata silenziosamente.
Limiti onesti
L’enforcement del budget è attivo e deny-closed per le superfici che la piattaforma governa, ma ha limiti che dovresti comprendere prima di farci affidamento:
- L’accuratezza dei costi dipende dal provider. La piattaforma contabilizza la spesa usando il pricing di riferimento dichiarato dall’operatore e i conteggi di token osservati. Se la fatturazione effettiva del provider differisce dal prezzo dichiarato, il gate di budget applica il prezzo dichiarato, non la fattura. La piattaforma non fabbrica dati di costo e non inventa benchmark.
- La copertura è limitata dall’osservazione. L’enforcement del budget si applica alla spesa che passa attraverso canali governati — sorgenti che la piattaforma osserva. Un agente che chiama un modello attraverso un percorso non governato (nessuna sorgente collegata, nessuna telemetria emessa) e invisibile al gate di budget. La piattaforma presenta i percorsi non governati come segnalazioni quando può rilevarli, ma non può applicare l’enforcement su ciò che non può vedere.
- La piattaforma e pre-1.0. L’enforcement del budget è distribuito è cablato oggi, ma tratta il dettaglio contabile come lavoro in corso. Vedi trasparenza e limiti per la postura completa.
Correlati
- Catalogo dei moduli — Modulo XI (Costi e AI FinOps) e Modulo X (Gestione modelli e provider).
- Governance — il modello di enforcement deny-closed che seguono i gate di budget.
- Tour FinOps — la pagina prodotto per la governance dei costi.
- Kill switch — il gate di negazione a livello di estate che sovrascrive l’enforcement del budget.
- Trasparenza e limiti — cosa è attivo rispetto a cosa e in fase di progettazione.