IA in tempo reale sicura per i browser tramite un gateway API: token temporanei, policy tenant e controlli delle sessioni vocali

Il browser e le app mobili non dovrebbero ricevere chiavi API del provider di lunga durata. Per l’intelligenza artificiale vocale in tempo reale, tuttavia, l’invio di ogni pacchetto audio attraverso un gateway può aggiungere latenza, costi operativi e modalità di errore. La soluzione migliore è mantenere il gateway nel piano di controllo: autenticare l'utente, applicare la politica del tenant, riservare il budget, coniare credenziali in tempo reale ristrette e di breve durata e consentire ai media sensibili alla latenza di utilizzare il trasporto in tempo reale del provider, ove appropriato.

Questo articolo descrive un modello di implementazione per team che creano agenti vocali, assistenti alle chiamate, tutor mobili, copiloti di supporto o interfacce vocali in-app tramite un gateway API AI. L'obiettivo è la sicurezza del browser senza perdere la governance del tenant.

Il problema: le connessioni dirette in tempo reale ignorano i tuoi controlli

Un semplice proxy lato server è interessante perché centralizza le chiavi e l'osservabilità. Per le richieste di testo standard, questo è spesso il modello giusto. L'audio in tempo reale è diverso. Una sessione vocale può comportare input continuo del microfono, output audio bidirezionale, interruzioni, chiamate di strumenti e rigide aspettative di latenza. L'inoltro di tutti i contenuti multimediali tramite il gateway può trasformare il gateway in un media Relay con un utilizzo intensivo della larghezza di banda invece che in un servizio di policy e fatturazione.

Le connessioni dirette da browser a provider risolvono la latenza, ma creano un problema diverso:

• Il browser non può contenere in modo sicuro una chiave API del provider standard.
• I controlli del budget del tenant possono essere ignorati se l'app si connette direttamente.
• Le restrizioni relative a modello, regione, voce, modalità e strumento diventano promesse lato client.
• L'attribuzione dell'utilizzo diventa incompleta o ritardata.
• I team di sicurezza perdono un punto decisionale verificabile prima dell'inizio di una sessione.

Il design pratico non è "proxy ogni byte". È "mediatore di ogni sessione".

Fatti, consigli e previsioni

Fatti: i fornitori di intelligenza artificiale in tempo reale supportano sempre più trasporti a bassa latenza come WebRTC, WebSocket e SIP. La documentazione pubblica per l'API Realtime di OpenAI descrive le interfacce in tempo reale a bassa latenza, incluso WebRTC. Le linee guida WebRTC in tempo reale di Azure OpenAI descrivono un'applicazione browser che usa un servizio token back-end per recuperare un token temporaneo prima di avviare la connessione WebRTC e avvisano contro l'uso di una chiave API standard in un'applicazione client. Le linee guida in tempo reale dell'SDK di OpenAI Agents consigliano inoltre un flusso in cui un backend crea un token client temporaneo di breve durata e il browser lo utilizza per stabilire una connessione WebRTC.

Consigli: considera il gateway come l'autorità di sessione. Dovrebbe decidere se può esistere una sessione in tempo reale, con quale modello, in quale regione, per quale inquilino, con quale budget e con quali strumenti. Il cliente dovrebbe ricevere solo le credenziali minime di breve durata necessarie per avviare la sessione approvata.

Previsioni: le API dei provider in tempo reale rimarranno irregolari per un po'. La durata dei token, i campi di configurazione della sessione, i controlli di disconnessione lato server, gli eventi di utilizzo e il supporto regionale saranno diversi. I gateway dovrebbero modellare esplicitamente le funzionalità del provider invece di fingere che tutte le API in tempo reale siano perfettamente portabili.

Architettura di riferimento: gateway come piano di controllo in tempo reale

Un flusso in tempo reale sicuro per il browser è composto da cinque parti:

1. App client: browser o app mobile che richiede una sessione vocale.
2. Backend dell'applicazione: autentica l'utente finale e chiama il gateway o incorpora la logica di conio dei token del gateway se il gateway fa parte dello stack backend.
3. Gateway API AI: applica la politica del tenant, risolve il profilo del modello, riserva il budget, registra la sessione e conia un segreto client temporaneo del provider.
4. Fornitore in tempo reale: termina WebRTC o un altro trasporto in tempo reale.
5. Registro e analisi: regola l'utilizzo una volta disponibili gli eventi del fornitore, i dati sulla durata o i report sull'utilizzo finale.

Il gateway non ha bisogno di inoltrare ogni frame audio per rimanere autorevole. Deve possedere la decisione di creazione della sessione e il percorso di riconciliazione.

Flusso di richiesta consigliato

1. L'utente apre una funzionalità vocale nell'app client.
2. Il client chiama il tuo backend: POST /voice/sessions.
3. Il backend verifica la sessione utente e inoltra una richiesta di conio al gateway con ID tenant, ID utente, funzionalità prevista, metadati del dispositivo e origine.
4. Il gateway valuta la politica e il budget.
5. Il gateway crea un record realtime_session locale prima di contattare il provider.
6. Il gateway chiama il provider con le sue credenziali di runtime protette e crea una sessione in tempo reale temporanea con ambito ristretto.
7. Il gateway restituisce al browser solo il segreto client temporaneo e i metadati della sessione approvati.
8. Il browser stabilisce la connessione WebRTC direttamente con il provider.
9. Il gateway acquisisce eventi di utilizzo del provider, richiamate, risultati di polling o stime prudenti basate sulla durata.
10. Il registro regola il budget riservato e scrive gli eventi di controllo.

Controlli preliminari alle norme

Il punto di applicazione più importante avviene prima che il token temporaneo venga coniato. Una volta che il browser dispone di credenziali di breve durata, l'applicazione a metà sessione potrebbe essere limitata a meno che il provider non supporti i controlli di aggiornamento, disconnessione, osservatore o richiamata della sessione.

Come minimo, il gateway dovrebbe controllare:

• Stato del tenant: attivo, sospeso, di prova, prepagato, fatturato o in quarantena.
• Diritto utente: se questo utente può utilizzare la voce in tempo reale, non solo la chat di testo.
• Profilo del modello consentito: modello o distribuzione in tempo reale approvati, non ID modello arbitrari forniti dal client.
• Politica geografica e di conservazione: se la regione del fornitore selezionato e il set di funzionalità corrispondono alle regole dei dati del tenant.
• Durata massima della sessione: ad esempio 5, 15 o 30 minuti in base al piano.
• Modalità consentite: input audio, output audio, testo, immagini o chiamate a strumenti.
• Modello vocale e di istruzioni: fisso o limitato da policy.
• Budget disponibile: saldo prepagato, indennità mensile prenotata o tetto di spesa per funzionalità.
• Concorrenza: sessioni vocali attive a livello di tenant e a livello di utente.
• Controlli degli abusi: indicatori di rischio dell'utente, reputazione dell'origine, velocità insolita delle chiamate o kill switch del tenant.

Un'impostazione predefinita sicura è rifiutare le richieste ambigue. Se il client richiede un modello, uno strumento, una voce o una regione che non rientra nella policy in tempo reale del tenant, il gateway dovrebbe restituire un chiaro errore di policy invece di ampliare silenziosamente l'accesso.

Progettazione del record della sessione

Crea un record di sessione lato gateway prima di coniare le credenziali del provider. Questo ti fornisce un ancoraggio di controllo anche se la creazione del provider ha esito positivo ma il browser non si connette mai.

{
  "session_id": "rt_01j...",
  "tenant_id": "tenant_123",
  "end_user_id": "user_hash_456",
  "fornitore": "fornitore_a",
  "provider_session_id": nullo,
  "model_profile": "supporto vocale standard",
  "upstream_model_or_deployment": "realtime-model-x",
  "regione": "eastus",
  "session_config_hash": "sha256:...",
  "allowed_modalities": ["audio_input", "audio_output"],
  "allowed_tools": ["lookup_order_status"],
  "tool_approval_policy": "approve_side_effects",
  "budget_reservation_id": "resv_789",
  "max_duration_seconds": 900,
  "issued_at": "2026-08-21T10:00:00Z",
  "expires_at": "2026-08-21T10:01:00Z",
  "client_origin": "https://app.example.com",
  "device_id_hash": "sha256:...",
  "stato": "conio"
}

Per impostazione predefinita, non archiviare l'audio grezzo del microfono o le istruzioni complete. Archivia hash di configurazione, ID, decisioni politiche e metadati minimi sufficienti per controllo, supporto e fatturazione. Se è necessaria la registrazione, rendila esplicita, consapevole del consenso e basata sulle policy del locatario.

Endpoint di conio di token temporanei

Un endpoint rivolto al gateway potrebbe assomigliare a questo:

POST /v1/realtime/sessions
Autorizzazione: portatore 
Tipo di contenuto: application/json
{
  "tenant_id": "tenant_123",
  "end_user_id": "user_hash_456",
  "funzione": "support_voice_agent",
  "origine": "https://app.example.com",
  "device_nonce": "8f3b...",
  "requested_profile": "supporto vocale standard"
}

La risposta non deve esporre la chiave di runtime upstream:

{
  "session_id": "rt_01j...",
  "fornitore": "fornitore_a",
  "trasporto": "webrtc",
  "client_secret": "effimero_segreto_qui",
  "expires_at": "2026-08-21T10:01:00Z",
  "approvato": {
    "model_profile": "supporto vocale standard",
    "max_duration_seconds": 900,
    "modalità": ["audio_input", "audio_output"],
    "strumenti": ["lookup_order_status"]
  }
}

Associa l'emissione all'origine, alla sessione dell'utente autenticato, al tenant e a un nonce. Il provider potrebbe non supportare tutte queste associazioni in modo nativo, quindi applica ciò che puoi al gateway: limita la velocità dei tentativi di conio, rifiuta origini impreviste, registra i metadati del dispositivo e mantieni breve la durata del token.

Modelli di sessione: ristretti per impostazione predefinita

Un modello di sessione in tempo reale dovrebbe essere più restrittivo di una richiesta generale di completamento della chat. Le sessioni vocali sono interattive, più difficili da controllare in tempo reale e possono durare più a lungo del previsto.

I campi del modello consigliati includono:

• Modello fisso o distribuzione: scelto da un profilo di modello lato gateway.
• Istruzioni: un modello di prompt controllato dal server con variabili approvate dal tenant.
• Voce: selezionata da una lista consentita.
• Modalità: disabilita le modalità testo, immagine o strumento a meno che il prodotto non ne abbia bisogno.
• Impostazioni audio di input: rilevamento delle svolte, comportamento di trascrizione o gestione del silenzio, ove supportato.
• Vincoli di output: lunghezza massima della risposta o comportamento della risposta dove supportato.
• Lista consentita degli strumenti: solo gli strumenti richiesti per la funzione.
• Durata della sessione: scadenza breve delle credenziali più durata massima della chiamata.

I modelli rigorosi riducono la flessibilità, ma semplificano i costi, la conformità e il supporto. Se i team di prodotto necessitano di voci o istruzioni dinamiche, esponi varianti di profilo controllate invece di passare la configurazione client arbitraria al fornitore.

Controlli del budget per la voce in tempo reale

Può essere più difficile quantificare l'utilizzo in tempo reale prima che arrivi l'utilizzo finale del provider. Una sessione può durare cinque secondi o venti minuti. Può includere input audio, output audio, trascrizione, chiamate a strumenti e token di testo. Il gateway dovrebbe quindi combinare prenotazione, limiti e riconciliazione.

Prima del conio

• Stima il costo della sessione nel caso peggiore o conservativo in base alla durata massima, al modello, alle modalità e al piano del locatario.
• Riserva il budget prima di rilasciare il segreto client.
• Rifiuta nuove sessioni se l'inquilino non dispone di saldo sufficiente o ha raggiunto i limiti vocali giornalieri.

Durante la sessione

• Monitora le sessioni attive e la velocità di combustione prevista.
• Applica limiti di concorrenza di tenant e utenti.
• Utilizza le funzionalità di terminazione o aggiornamento della sessione supportate dal provider, se disponibili.
• Attiva avvisi in caso di durata anomala della sessione, riconnessioni ripetute o utilizzo insolito della voce.

Dopo la sessione

• Importa eventi di utilizzo del provider o report sull'utilizzo finale, ove disponibili.
• Calcola il budget riservato al costo effettivo.
• Se l'utilizzo esatto è ritardato o incompleto, mantieni una prenotazione conservativa fino alla riconciliazione.
• Attribuire l'utilizzo a tenant, utente, funzionalità, profilo modello e ID sessione.

Questo è meno esatto della fatturazione tramite SMS sincrono al momento della risposta, ma è operativamente più sicuro rispetto all'emissione di credenziali dirette senza prenotazione.

Chiamate dello strumento all'interno di sessioni in tempo reale

Gli agenti vocali in tempo reale spesso diventano più utili quando possono chiamare strumenti: cercare un account, prenotare un appuntamento, aggiornare un ticket o attivare un flusso di lavoro. Tratta l'esecuzione dello strumento separatamente dal trasporto audio.

La connessione multimediale del browser non dovrebbe implicare l'autorizzazione a produrre effetti collaterali. Il gateway o il backend dovrebbero applicare:

• Registro degli strumenti: ogni strumento ha un proprietario, uno schema, ambiti e un livello di rischio.
• Liste consentite: i modelli di sessione elencano esattamente gli strumenti disponibili.
• Varchi di approvazione: le azioni con effetti collaterali richiedono la conferma dell'utente, l'approvazione umana o l'approvazione delle norme.
• Credenziali separate: le credenziali dello strumento non vengono mai incorporate nella sessione del browser.
• Traccia di controllo unita: ogni chiamata allo strumento fa riferimento all'ID della sessione in tempo reale.

Ad esempio, un agente vocale dell'assistenza potrebbe essere autorizzato a chiamare lookup_order_status automaticamente, ma refund_payment potrebbe richiedere una conferma esplicita e un evento di approvazione del backend. Il provider in tempo reale può orchestrare la conversazione, ma il tuo gateway dovrebbe governare il limite delle autorizzazioni.

Visibilità senza proxy per ogni byte

Il flusso multimediale diretto WebRTC riduce la latenza del gateway e il carico della larghezza di banda, ma la visibilità diventa più dipendente dagli eventi del provider e dai metadati della sessione. Progettare analisi attorno a più fonti di prova:

• Record di creazione della sessione dal gateway.
• Eventi del ciclo di vita lato client come connessione, disconnessione, tentativo di riconnessione, microfono negato o chiamata terminata.
• ID di sessione del provider, eventi di utilizzo o record di utilizzo finale.
• Stime basate sulla durata quando l'utilizzo del provider viene ritardato.
• Registri delle chiamate agli strumenti uniti per ID sessione.
• Record di prenotazione e liquidazione del budget.

Non aspettare la telemetria perfetta del fornitore prima di avviare i controlli. Inizia con prenotazioni prudenti e attribuzioni chiare, quindi migliora la precisione della liquidazione man mano che i report sull'utilizzo del fornitore maturano.

Lista di controllo sulla sicurezza

• Non inviare mai chiavi API del provider standard al browser o ai client mobili.
• Utilizzare segreti client temporanei di breve durata per l'avvio della sessione in tempo reale.
• Autenticare l'utente finale prima del conio dei token.
• Lega le decisioni di conio ai metadati di tenant, utente, origine, nonce e dispositivo, ove possibile.
• Conserva le credenziali di runtime del provider in un archivio back-end o in un archivio segreto del gateway.
• Registra una riga di controllo della sessione prima del conio del provider.
• Utilizza modelli di sessione approvati dal tenant invece di configurazioni client arbitrarie.
• Applica limiti di concorrenza, utilizzo quotidiano e durata massima.
• Utilizza liste consentite degli strumenti e cancelli di approvazione per gli effetti collaterali.
• Riduci al minimo il prompt non elaborato e la conservazione dell'audio per impostazione predefinita.
• Mantenere una matrice di capacità del fornitore per la durata dei token, le regioni, gli strumenti, gli eventi di utilizzo e i controlli di terminazione.

Matrice delle capacità del fornitore

Poiché le API in tempo reale differiscono, modella il tuo adattatore gateway in base alle funzionalità anziché alle ipotesi. Una matrice semplice può guidare le decisioni relative al routing e alle politiche:

{
  "fornitore_a": {
    "trasporti": ["webrtc", "websocket"],
    "ephemeral_client_tokens": vero,
    "token_ttl_seconds": 60,
    "server_side_disconnect": vero,
    "session_update": vero,
    "usage_events": "final_and_incremental",
    "regioni": ["noi", "ue"],
    "tool_approval_supported": vero
  },
  "provider_b": {
    "trasporti": ["websocket"],
    "ephemeral_client_tokens": vero,
    "token_ttl_seconds": 120,
    "server_side_disconnect": falso,
    "session_update": falso,
    "usage_events": "final_only",
    "regioni": ["noi"],
    "tool_approval_supported": falso
  }
}

Se un tenant richiede la residenza nell'UE e la terminazione lato server, il gateway deve instradare solo verso provider e implementazioni che soddisfano entrambi. Se nessun fornitore soddisfa la politica, viene chiuso con errore.

Percorso di migrazione

Non è necessario sviluppare tutti i controlli fin dal primo giorno. Un'implementazione pratica è:

1. Solo creazione di sessioni proxy: mantiene i media diretti, ma richiede che tutte le sessioni in tempo reale vengano coniate dal backend o dal gateway.
2. Aggiungi modelli di policy: sostituisci i campi del modello e delle istruzioni forniti dal cliente con profili approvati.
3. Aggiungi prenotazione budget: prenota un costo di sessione conservativo prima dell'emissione del token.
4. Aggiungi analisi del ciclo di vita: raccogli l'inizio della sessione, la connessione, la disconnessione, la durata, l'ID della sessione del fornitore e lo stato della liquidazione.
5. Aggiungi la governance degli strumenti: richiedi liste consentite e approvazioni per le chiamate agli strumenti in tempo reale.
6. Aggiungi routing delle funzionalità del fornitore: seleziona i fornitori per regione, modalità, supporto eventi e controlli di terminazione.
7. Aggiungi un osservatore facoltativo o flussi di lavoro di registrazione: solo se conforme, consentito e approvato dal locatario.

Conclusione attuabile

Per l'intelligenza artificiale vocale in tempo reale, un gateway API AI non dovrebbe diventare automaticamente un media Relay. L'architettura più sicura e con latenza inferiore consiste nel mantenere il gateway responsabile del piano di controllo: autenticare gli utenti, applicare policy del tenant, riservare budget, creare un record di controllo, coniare credenziali temporanee con ambito ristretto e riconciliare l'utilizzo dopo la sessione.

La regola di implementazione principale è semplice: i browser possono ricevere segreti di sessione di breve durata, mai chiavi del provider di lunga durata. Tutto il resto segue da quel confine: modelli rigorosi, conio basato sull'origine, limiti di sessioni simultanee, approvazioni degli strumenti, accordi sull'utilizzo e matrici di capacità del fornitore. Ciò offre ai team di prodotto esperienze vocali in tempo reale senza rinunciare alla gestione delle chiavi API, al controllo dei costi dell'API AI, alla governance delle API del team o all'analisi dell'utilizzo dell'AI.

Leggi correlati

• archivio credenziali del provider per il runtime chiavi
• registro di prenotazione e liquidazione del budget