Rate Limiting delle Funzionalità AI: Impedisci a un Singolo Utente di Prosciugare il Budget

Applichi il rate limiting alle funzionalità AI a livello di utente, sessione ed endpoint — non affidandosi semplicemente al limite di API account-wide del suo provider LLM. Un singolo account compromesso, un bot di scraping o un bug lato client che si avvita in un loop di retry può trasformare una fattura mensile prevedibile in una sorpresa a cinque cifre prima ancora che scatti un avviso di spesa.

La maggior parte dei team lo scopre nel modo più doloroso. Rilasciano una funzionalità AI, la collegano a OpenAI o Anthropic, impostano una notifica di spesa e danno per scontato che sia sufficiente. Non lo è. Gli avvisi di spesa sono un rilevatore di fumo, non uno sprinkler: le dicono che la cucina è in fiamme, ma non la spengono. Quando arriva l'email, il danno è già addebitato sulla carta.

Perché i limiti del provider non bastano

Tutti i provider LLM applicano rate limit, ma sono calibrati sull'intero account, non sui singoli utenti. La documentazione sui rate limit di OpenAI descrive soglie di richieste al minuto e token al minuto che si applicano globalmente alla chiave API. Questo protegge l'infrastruttura del provider, non il suo business. Se un utente della sua app invia 500 richieste in loop, quel traffico confluisce nello stesso bucket di tutti gli altri utenti legittimi: è il suo prodotto a degradarsi o la sua fattura a impennarsi, non la loro.

Non è uno scenario ipotetico per noi. Il nostro tooling di outreach analizza il sito di ogni prospect con un'istanza self-hosted di Firecrawl e un modello locale, poi effettua una singola chiamata LLM che estrae i dati rilevanti e redige l'email. Se quella chiamata si bloccasse in un loop di retry, o un bug facesse processare due volte la stessa lista di prospect, il limite account-level di OpenAI non lo impedirebbe — comincerebbe semplicemente a limitare ogni altra richiesta su quella chiave API, incluse quelle non correlate, mentre il loop continua a consumare token indisturbato. Il tetto del provider protegge i server di OpenAI, non il nostro budget né il nostro altro traffico.

Questo è ancora più rilevante per le funzionalità AI rispetto ai normali endpoint API, perché la varianza del costo per richiesta è enorme. Una chiamata REST standard costa frazioni di centesimo indipendentemente da ciò che fa l'utente. Una chiamata LLM può costare 50 volte di più a seconda della lunghezza del prompt, della finestra di contesto e del fatto che il modello ragioni attraverso più passaggi. Un chatbot che consente agli utenti di incollare testo arbitrario, o un agente che può chiamare strumenti in loop, ha un raggio d'azione potenzialmente devastante rispetto a un classico endpoint CRUD.

Cosa limitare concretamente

Pensi per livelli, non con un unico numero:

• Frequenza di richieste per utente: richieste al minuto per utente autenticato, usando qualcosa come un token bucket in modo che brevi picchi siano tollerati, ma non l'abuso prolungato.
• Spesa in token per utente: imposti un tetto di token totali (input + output) per utente al giorno o per ciclo di fatturazione, separato dal conteggio delle richieste, poiché un singolo prompt lungo può costare più di cento brevi.
• Chiamate agli strumenti per sessione: se esegue un agente che può invocare strumenti o effettuare sotto-richieste, limiti il numero di passaggi per sessione. È esattamente per questo che la nostra pipeline di outreach è deliberatamente una chiamata singola — analisi, poi un colpo solo che estrae i fatti e redige l'email — anziché una catena multi-step "estrai, poi riassumi, poi redigi". Ogni passaggio aggiuntivo in una catena è un altro punto in cui può innescarsi un loop bloccato; un design a singola chiamata non lascia spazio a un processo impazzito per nascondersi. Un loop che invoca uno strumento 40 volte perché non trova mai una condizione di uscita è una failure mode comune e costosa nelle catene prive di questa disciplina.
• Fallback per IP e per dispositivo: per superfici non autenticate o in tier gratuito, aggiunga un limite secondario che non dipenda dall'identità dell'account, poiché è la prima cosa che un abusatore falsificherà.

Applichi tutto questo lato server, nello stesso servizio che detiene la chiave API del provider. Il throttling lato client è un abbellimento dell'UX, non un controllo di sicurezza. Se la logica di rate limiting è ispezionabile e aggirabile dal browser, non sta proteggendo il suo budget.

Lo costruisca come un gate, non come un ripensamento

Il pattern più pulito è un gate di spesa e rate che si interpone tra la sua applicazione e la chiamata LLM, in modo che ogni richiesta — indipendentemente dalla funzionalità che l'ha generata — passi attraverso lo stesso controllo. Quel gate deve tracciare:

1. L'utilizzo corrente rispetto al limite dell'utente (Redis con una sliding window o un token bucket funziona bene)
2. Un tetto rigido che restituisce un errore chiaro anziché accodare o ritentare silenziosamente
3. Un modo per alzare i limiti per specifici utenti verificati senza fare un nuovo deploy

I retry meritano attenzione particolare. Un wrapper naive di retry-on-failure attorno a una chiamata LLM, combinato con un errore di rate limit, può degenerare: la richiesta fallisce, il client riprova, il retry viene anch'esso limitato, e ora si ha un thundering herd che martella il gate ogni secondo. Usi un backoff esponenziale e imposti un tetto ai retry totali per richiesta, non solo al minuto.

Se sta anche gestendo più provider per ragioni di costo o affidabilità, lo stesso gate è il punto giusto dove applicare i limiti prima di instradare il traffico — un motivo in più per centralizzare questa logica anziché distribuire controlli su ogni endpoint AI. Abbiamo analizzato i trade-off di quel livello di routing nel nostro articolo su LLM cost optimization e in multi-LLM provider failover.

Un pattern che riduce anche i costi, non solo il rischio

La richiesta meno costosa è quella che non viene mai effettuata. Nel nostro tooling di outreach, analizziamo il sito di ogni prospect con un'istanza self-hosted di Firecrawl e un modello locale, e abbiamo riscontrato che una singola chiamata che estrae i fatti rilevanti e redige l'email in un colpo solo supera una catena multi-step "estrai, poi riassumi, poi redigi" sia in termini di costo che di latenza. Meno chiamate per unità di lavoro significa che i rate limit sono naturalmente più difficili da raggiungere e il tetto per utente rende di più. Prima di ricorrere a throttling aggressivo, verifichi se la sua funzionalità sta effettuando più chiamate LLM del necessario per completare il compito. Il rate limiting limita il danno da un attore malevolo; la disciplina sul numero di chiamate riduce il danno che un utente normale può causare semplicemente usando il prodotto come previsto.

Come si inserisce questo discorso con le chiavi dei vendor

Se sta usando un vendor AI gestito anziché le proprie chiavi provider, le chieda direttamente come isola il traffico di un cliente da quello di un altro, e se i limiti sono configurabili per account o fissi. È una delle domande da aggiungere a qualsiasi conversazione con un vendor, insieme alle domande sul modello di pricing che descriviamo in BYOK vs managed LLM keys. Se un vendor non sa rispondere chiaramente, assuma che l'isolamento non esista e pianifichi il proprio gate sopra di esso in ogni caso.

Il minimo da rilasciare prima del lancio

Se fa solo tre cose prima che una funzionalità AI vada in produzione: metta un tetto di token per utente davanti a ogni chiamata LLM, limiti i loop di tool call in qualsiasi flusso agentico, e si assicuri che i retry abbiano un backoff invece di comporsi. Nulla di tutto questo richiede infrastrutture esotiche — un'istanza Redis e qualche decina di righe di middleware coprono la maggior parte dei prodotti. È un'assicurazione economica contro l'unica failure mode che trasforma una funzionalità AI altrimenti ben gestita in una voce di budget da dover spiegare.

Se sta definendo l'ambito di una funzionalità AI e vuole un secondo parere sulle protezioni prima del rilascio, ne parliamo.