Cloudflare AI Gateway: come evitare addebiti sul conto sbagliato

Cloudflare ha aggiornato Cloudflare AI Gateway: ora una richiesta priva della chiave del modello del cliente può essere bloccata prima che il costo finisca sulla fattura Cloudflare per l'AI. Il 14 settembre 2026, AI Gateway ha introdotto l'obbligo delle credenziali del provider: una richiesta verso un servizio di terze parti senza una chiave applicabile restituisce HTTP 400 invece di utilizzare Unified Billing.

Cloudflare AI Gateway cambia chi paga

AI Gateway può instradare una singola richiesta al modello attraverso diversi percorsi di autenticazione. La credenziale è la chiave che indica al provider del modello quale account deve sostenere il costo.

Prima di questa modifica, l'ordine era semplice. Cloudflare cercava innanzitutto una chiave del provider nella richiesta. Se non la trovava, verificava la presenza di una chiave Bring Your Own Key, o BYOK, salvata nel gateway con l'alias default. In mancanza di entrambe, poteva ricorrere alle credenziali gestite da Cloudflare tramite Unified Billing, detraendo il consumo dal saldo dei crediti Cloudflare.

Quest'ultimo fallback è utile quando si vuole che a pagare sia Cloudflare. Diventa invece una falla nel budget quando la richiesta appartiene a un cliente che avrebbe dovuto fornire la propria chiave OpenAI, Anthropic, Google o di un altro provider.

Ora Cloudflare consente di eliminare il terzo passaggio per il traffico diretto a provider di terze parti. Attivando Require provider credentials sul gateway, opzione rappresentata nell'API da byok_only: true, una richiesta senza credenziali del cliente applicabili si interrompe con HTTP 400. La stessa restrizione può essere applicata a una singola richiesta con cf-aig-no-wholesale: true. Cloudflare documenta qui l'ordine completo delle credenziali e i due controlli.

Il modo più semplice per capire il meccanismo è immaginare tre possibili soggetti paganti in coda:

1. Credenziale nella richiesta: il cliente invia la propria chiave del provider insieme alla chiamata. AI Gateway la inoltra senza modificarla, quindi il provider addebita il costo all'account associato a quella chiave.
2. Credenziale salvata nel gateway: se la chiamata non contiene una chiave del provider, AI Gateway ne utilizza una salvata in Cloudflare Secrets Store. Sugli endpoint Unified Billing, la chiave memorizzata applicabile deve avere l'alias default.
3. Cloudflare Unified Billing: se non esiste una chiave applicabile né del cliente né memorizzata, Cloudflare può usare la propria credenziale gestita e detrarre i crediti dall'account Cloudflare.

Con la nuova regola, la coda termina dopo il secondo passaggio. È questa la conseguenza concreta per l'azienda: le credenziali mancanti diventano un'interruzione visibile, anziché un trasferimento invisibile dei costi.

Ora i costi si fermano prima, invece di essere riconciliati dopo

Unified Billing applica una commissione del 5% all'acquisto dei crediti. L'esempio di Cloudflare è immediato: $100 di crediti generano un addebito di $105, mentre il prezzo di inferenza del provider viene trasferito senza ricarichi.

Portiamo il caso in un flusso di lavoro per un cliente. Se un'attività avrebbe dovuto utilizzare l'account del provider del cliente, ma la relativa chiave è assente, $100 di utilizzo del modello potrebbero invece consumare i crediti Cloudflare dell'operatore. Per finanziare quei crediti servono $105. L'account del cliente presso il provider non registra alcun utilizzo in fallback, mentre l'operatore si ritrova l'intero addebito di $105 e deve poi dimostrare quale cliente lo abbia generato.

Il problema principale non è la commissione del 5%. È il fatto che l'intero carico di lavoro da $100 sia finito sul budget sbagliato. I $5 aggiuntivi rendono soltanto l'errore più costoso.

Rendere obbligatorie le credenziali del provider trasforma un'indagine contabile in un errore applicativo. Si rinuncia al recupero automatico, ma si ottiene un confine netto su chi deve pagare. Per un confronto più ampio tra le commissioni dei gateway e la fatturazione diretta dei provider, consulta l'analisi dei costi degli AI gateway.

A chi serve questa impostazione

Un'agenzia che gestisce automazioni per i clienti

Un'agenzia può operare con un unico account Cloudflare mentre ogni cliente mantiene il proprio contratto con il provider dei modelli. Conviene attivare la regola del gateway sulle route finanziate dai clienti. Se durante l'onboarding manca una chiave o una rotazione la rimuove, il processo si ferma invece di intaccare il saldo prepagato dell'agenzia.

Il vantaggio è una chiara attribuzione degli addebiti. Il cliente fornisce una credenziale funzionante oppure riceve un errore di configurazione. L'agenzia non deve più ricostruire a posteriori una fattura condivisa, quando il carico di lavoro è già stato eseguito.

Un team SaaS che accetta le chiavi fornite dai clienti

Un prodotto SaaS che consente ai clienti di fornire le proprie chiavi può trattare HTTP 400 come uno stato di configurazione. Il prodotto segnala al cliente l'assenza della credenziale del provider e impedisce alla richiesta di attingere al pool di crediti Cloudflare della piattaforma.

È particolarmente utile quando una risposta riuscita nasconderebbe l'errore. Senza la restrizione, la funzione continua a operare ma paga l'azienda sbagliata. Con la restrizione, il prodotto fallisce abbastanza presto da consentire di correggere la configurazione dell'account.

Un platform engineer che interviene prima su una sola route

L'header della richiesta offre il perimetro di rollout più ristretto. Aggiungi cf-aig-no-wholesale: true a un unico percorso verso un provider di terze parti, verifica il comportamento in assenza della chiave e collega l'errore al monitoraggio prima di estendere la modifica a tutto il gateway.

La precedenza funziona volutamente in una sola direzione. Un header può rendere più rigido un gateway permissivo. Una richiesta non può impostarlo su false e rendere meno restrittivo un gateway sul quale Require provider credentials è già attivo. Cloudflare descrive queste restrizioni come additive.

Un responsabile FinOps che separa il controllo del pagante da quello del budget

Questa impostazione serve a decidere quale account è autorizzato a pagare. I limiti di spesa di AI Gateway stabiliscono invece quanto si può spendere. Sono controlli diversi e richiedono test distinti.

I limiti di spesa possono includere sia le richieste BYOK sia quelle Unified Billing, quando Cloudflare conosce il prezzo del modello. Possono essere definiti per modello, provider o metadati. Il costo, però, è una stima best effort e Cloudflare raccomanda di consultare la dashboard del provider per la fatturazione esatta. Considera la regola sulle credenziali del provider come il confine di responsabilità del pagamento e verifica separatamente il tetto di spesa.

Come configurare Cloudflare AI Gateway senza provocare disservizi inspiegabili

1. 1

   Associa ogni route al soggetto che deve pagare

   Separa il traffico verso provider di terze parti da Workers AI. Per ogni route di terze parti, specifica se la chiave del provider deve arrivare nella richiesta oppure provenire dalla chiave default memorizzata nel gateway. Non attivare una regola fail-closed finché questa responsabilità non è definita con chiarezza.

2. 2

   Scegli il perimetro di applicazione più ristretto

   Per un singolo percorso, invia cf-aig-no-wholesale: true. Per l'intero gateway, apri AI > AI Gateway, seleziona il gateway, apri Settings, attiva Require provider credentials e conferma. Un gateway gestito tramite API usa byok_only: true nella richiesta di aggiornamento.

3. 3

   Verifica entrambi i percorsi con credenziali valide

   Invia in staging una richiesta con la chiave del provider allegata. Invia poi una richiesta che utilizzi la chiave memorizzata con l'alias default. In entrambi i casi, controlla che l'utilizzo venga registrato sull'account del provider previsto. Se l'endpoint Unified Billing usa una chiave chiamata production, correggi l'alias prima di proseguire.

4. 4

   Rimuovi deliberatamente la chiave

   In staging, invia la stessa richiesta verso il provider di terze parti senza una chiave nella richiesta e senza una chiave default memorizzata applicabile. Il risultato atteso è HTTP 400, non una risposta del modello riuscita. Verifica che i criteri di retry non continuino a ripetere questo errore di configurazione.

5. 5

   Assegna l'errore a una persona e a una coda

   Affida la responsabilità di questo HTTP 400 al referente dell'integrazione o della piattaforma, perché è chi controlla gli header delle richieste, i secret memorizzati e la rotazione delle chiavi. L'assistenza clienti può spiegare l'errore e il reparto finanziario può verificarlo, ma nessuno dei due dovrebbe essere responsabile della correzione.

I compromessi, senza edulcorarli

Questa impostazione sostituisce il fallback silenzioso con un errore visibile. Se Unified Billing era il percorso di disponibilità scelto deliberatamente, l'attivazione lo elimina per le richieste verso provider di terze parti. Anche una chiave scaduta o non valida presente nella richiesta viene inoltrata al provider, anziché essere sostituita da un altro percorso di fatturazione; il provider upstream può quindi rifiutarla.

Workers AI è l'eccezione da non trascurare. Le richieste Workers AI non utilizzano credenziali di provider di terze parti, restano consentite e mantengono la modalità di fatturazione Workers AI configurata separatamente nel gateway. Attivare byok_only non equivale a un interruttore globale che impedisce qualsiasi addebito a Cloudflare.

Neppure i limiti di spesa eliminano ogni margine di rischio. La contabilità è a consistenza eventuale, quindi richieste simultanee possono portare temporaneamente la spesa oltre il limite. Inoltre, i costi vengono stimati in base ai token e ai prezzi noti dei modelli. Usa questi limiti, ma riconcilia gli addebiti esatti consultando le informazioni di fatturazione del provider e di Cloudflare.

La prossima mossa, già da lunedì

Scegli una route verso un provider di terze parti finanziata dal cliente. Applica prima la restrizione a livello di richiesta, quindi esegui in staging il test senza credenziali. Per superarlo, il risultato deve essere un HTTP 400 assegnato a un responsabile, senza fallback riuscito. Inserisci l'errore nella coda del team di integrazione o di piattaforma, indica chi deve ripristinare la chiave e soltanto dopo valuta l'attivazione della regola sull'intero gateway.

Se il team usa intenzionalmente Cloudflare Unified Billing per tutto il traffico verso provider di terze parti, lascia disattivata la regola. Se utilizza soltanto Workers AI, questa impostazione non cambia la relativa fattura. Se invece devono pagare gli account dei provider dei clienti o dei singoli reparti, intervieni questa settimana e verifica il comportamento in caso di errore prima che sia la prossima rotazione delle chiavi a farlo al posto tuo.

Per ricevere altre analisi operative su modifiche come questa, iscriviti alla newsletter.