Cloudflare ha aggiunto un controllo ad AI Gateway che consente agli operatori di richiedere le credenziali del fornitore su richieste di modelli di terze parti. Il cambiamento è piccolo in termini di interfaccia, ma risolve un problema pratico di governance per i team che instradano il traffico AI attraverso un gateway: cosa dovrebbe accadere quando un cliente, un progetto o un tenant non ha fornito una chiave fornitore valida?
Prima di questo aggiornamento, Cloudflare AI Gateway poteva utilizzare la sua configurazione di fatturazione unificata come percorso di fallback per i fornitori di terze parti supportati. Ciò può essere utile quando una richiesta altrimenti fallirebbe, ma può anche confondere l’attribuzione dei costi e i limiti di conformità. La nuova impostazione Solo BYOK consente ai proprietari del gateway di prevenire tale fallback e di richiedere che le richieste utilizzino invece le credenziali Bring Your Own Key fornite esplicitamente.
Cloudflare afferma che l'impostazione può essere abilitata nella dashboard o tramite l'API con byok_only=true. È stata inoltre aggiunta un'intestazione per richiesta, cf-aig-no-wholesale, per i casi in cui i team desiderano bloccare l'uso all'ingrosso o delle credenziali gestite da Cloudflare sulle singole chiamate.
Cosa è cambiato
Il registro delle modifiche di AI Gateway del 14 settembre introduce un requisito di credenziali per le richieste di fornitori di terze parti. Quando abilitato, il gateway non tornerà silenziosamente alle credenziali di fatturazione unificata gestite da Cloudflare se il chiamante non ha fornito credenziali del fornitore accettabili.
Questa distinzione è importante perché i gateway AI si collocano sempre più tra molte applicazioni interne, clienti esterni e più fornitori di modelli. Una chiave mancante non è solo una modalità di guasto tecnico. Può decidere a quale persona giuridica viene fatturata, quale quota del fornitore di account viene consumata e se l'utilizzo viene visualizzato nel centro di costo corretto.
Il nuovo controllo offre ai team della piattaforma una modalità operativa più rigorosa. Invece di trattare le credenziali del cliente mancanti come un inconveniente di routing, il gateway può trattarle come una violazione delle policy. Ciò è particolarmente rilevante per le configurazioni dei rivenditori, le implementazioni con chiavi di proprietà del cliente e gli ambienti aziendali in cui il rapporto con il fornitore deve rimanere direttamente legato a un'unità aziendale o a un tenant.
Perché è importante per gli operatori di gateway AI
La progettazione del gateway AI si è spesso concentrata su routing, latenza, memorizzazione nella cache, tentativi e astrazione del modello. Il comportamento di fatturazione merita la stessa attenzione. Se un gateway modifica automaticamente la modalità credenziali quando un percorso non è disponibile, il reporting downstream può diventare fuorviante. Una richiesta può sembrare un normale traffico applicativo mentre la fattura arriva altrove.
Per le aziende che utilizzano un livello di controllo dei costi API AI centrale, ciò crea rischi operativi. I team finanziari potrebbero perdere dati puliti sui riaddebiti. I team di sicurezza potrebbero non sapere quali credenziali sono state effettivamente utilizzate. I team di prodotto potrebbero avere difficoltà a spiegare perché l'utilizzo di un tenant è stato fatturato tramite un account della piattaforma anziché tramite l'account del fornitore del tenant.
La modalità solo BYOK aiuta anche a mantenere gli impegni con i clienti. Alcuni acquirenti richiedono che i contratti dei fornitori, i termini di elaborazione dei dati o le impostazioni regionali governino le chiamate modello. Se un gateway può ricorrere a una credenziale di fatturazione gestita, tale impegno diventa più difficile da applicare a meno che il fallback non sia disabilitato dalla policy.
L'intestazione per-request aggiunge un'opzione più granulare. Una piattaforma può mantenere disponibile un comportamento di fatturazione unificata più ampio per alcuni carichi di lavoro, impedendolo al contempo per le richieste che comportano requisiti di conformità, rivenditore o attribuzione più severi. Ciò offre agli sviluppatori un percorso di migrazione senza forzare contemporaneamente ogni applicazione alla modalità più rigorosa.
Chi è interessato
Il pubblico più immediato è qualsiasi team che utilizza Cloudflare AI Gateway per inoltrare richieste a fornitori di IA di terze parti. Il cambiamento è particolarmente rilevante quando più team, tenant o clienti condividono un gateway e dove si prevede che le credenziali del fornitore siano di proprietà esterna all'account della piattaforma centrale.
I team della piattaforma AI aziendale dovrebbero verificare se il comportamento del loro gateway corrisponde alle policy interne. Se si suppone che un progetto utilizzi il proprio account OpenAI, Anthropic, Google, Mistral o un altro provider, il gateway dovrebbe rendere tale dipendenza visibile e applicabile. Un fallback che aiuta una demo ad avere successo può diventare un problema in produzione se nasconde una configurazione delle credenziali non funzionante.
I rivenditori e le piattaforme partner hanno una versione più nitida dello stesso problema. Se i clienti portano con sé le chiavi del proprio fornitore, gli operatori della piattaforma devono avere la certezza che il traffico non venga convertito accidentalmente in utilizzo fatturato dalla piattaforma. In caso contrario, i margini, le fatture, i registri di audit e la fiducia dei clienti potrebbero essere colpiti.
Anche gli sviluppatori ne sono colpiti, sebbene per lo più attraverso modalità di fallimento più chiare. Con l'applicazione solo BYOK, una richiesta priva di credenziali adeguate dovrebbe fallire anziché essere instradata attraverso un percorso di fatturazione alternativo.Ciò potrebbe richiedere migliori controlli di onboarding, una gestione più chiara degli errori e test di distribuzione che verifichino le chiavi del provider prima che il traffico venga attivato.
Conseguenze pratiche
Il primo passo pratico è l'inventario delle policy. I team dovrebbero decidere quali carichi di lavoro possono utilizzare la fatturazione unificata gestita da Cloudflare e quali devono utilizzare le credenziali del fornitore di proprietà del cliente o del progetto. Tale decisione dovrebbe essere esplicita, non lasciata al comportamento predefinito del gateway.
Il secondo passo è l'osservabilità. I log e l'analisi dell'utilizzo dovrebbero registrare quale modalità di credenziale è stata utilizzata, se una richiesta è stata bloccata perché era abilitato solo BYOK e quale tenant o progetto ha fornito la chiave. Senza tale visibilità, un controllo più rigoroso può ridurre l'ambiguità della fatturazione ma lasciare comunque agli operatori dati inadeguati per la risoluzione dei problemi.
Il terzo passaggio è il flusso di lavoro dello sviluppatore. Le applicazioni che dipendono da AI Gateway dovrebbero fallire precocemente quando mancano le credenziali. Un controllo all'avvio, una convalida della distribuzione o un avviso sulla console di amministrazione è meglio che scoprire il problema dopo che una richiesta di produzione è stata rifiutata.
L'incertezza rimanente riguarda meno la funzionalità in sé e più i modelli di adozione. Cloudflare ha documentato il nuovo controllo, ma ogni operatore deve ancora decidere dove applicarlo. Alcuni team preferiranno la resilienza della fatturazione di riserva per gli esperimenti interni. Altri renderanno solo BYOK l'impostazione predefinita per il traffico del tenant di produzione. Il cambiamento importante è che questa ora è una scelta di governance piuttosto che un comportamento implicito nascosto all'interno del livello di routing.