Inteligență artificială în timp real sigură pentru browser printr-un gateway API: jetoane efemere, politică pentru chiriași și controale ale sesiunii vocale

Browserul și aplicațiile mobile nu ar trebui să primească chei API de furnizor cu durată lungă de viață. Cu toate acestea, pentru IA vocală în timp real, trimiterea fiecărui pachet audio printr-un gateway poate adăuga latență, cost operațional și moduri de eșec. Cel mai bun model este păstrarea gateway-ului în planul de control: autentificarea utilizatorului, aplicarea politicii locatarului, rezervarea bugetului, crearea unei acreditări înguste, de scurtă durată, în timp real și lăsați mediile sensibile la latență să folosească transportul în timp real al furnizorului, acolo unde este cazul.

Acest articol descrie un model de implementare pentru echipe care formează agenți vocali, asistenți de apel, tutori mobili, copiloți de asistență sau interfețe vocale în aplicație printr-un gateway API AI. Scopul este siguranța browserului fără a pierde guvernarea chiriașilor.

Problema: conexiunile directe în timp real ocolesc comenzile

Un proxy simplu pe partea de server este atractiv, deoarece centralizează cheile și observabilitatea. Pentru solicitările standard de text, acesta este adesea modelul potrivit. Audio în timp real este diferit. O sesiune vocală poate implica intrare continuă pentru microfon, ieșire audio bidirecțională, întreruperi, apeluri de instrumente și așteptări stricte de latență. Trimiterea prin proxy a tuturor conținutului media prin gateway-ul dvs. poate transforma gateway-ul într-un releu media cu lățime de bandă grea, în locul unui serviciu de politică și de facturare.

Conexiunile directe de la browser la furnizor rezolvă latența, dar creează o altă problemă:

• Browserul nu poate deține în siguranță o cheie API standard a furnizorului.
• Verificările bugetului chiriașilor pot fi omise dacă aplicația se conectează direct.
• Restricțiile privind modelul, regiunea, vocea, modalitatea și instrumentele devin promisiuni pentru client.
• Atribuirea utilizării devine incompletă sau întârziată.
• Echipele de securitate pierd un punct de decizie auditabil înainte de începerea unei sesiuni.

Designul practic nu este „proxy fiecare octet”. Este „intermediază fiecare sesiune”.

Fapte, recomandări și previziuni

Fapte: furnizorii de AI în timp real acceptă tot mai mult transporturi cu latență redusă, cum ar fi WebRTC, WebSocket și SIP. Documentația publică pentru API-ul OpenAI în timp real descrie interfețe în timp real cu latență scăzută, inclusiv WebRTC. Ghidul WebRTC în timp real Azure OpenAI descrie o aplicație de browser care utilizează un serviciu de token de backend pentru a prelua un simbol efemer înainte de a începe conexiunea WebRTC și avertizează împotriva utilizării unei chei API standard într-o aplicație client. Îndrumarea în timp real pentru OpenAI Agents SDK recomandă, de asemenea, un flux în care un backend creează un token client efemer de scurtă durată, iar browserul îl folosește pentru a stabili o conexiune WebRTC.

Recomandări: tratați gateway-ul ca autoritate de sesiune. Ar trebui să decidă dacă poate exista o sesiune în timp real, cu ce model, în ce regiune, pentru ce chiriaș, în ce buget și cu ce instrumente. Clientul ar trebui să primească doar acreditările minime de scurtă durată necesare pentru a începe acea sesiune aprobată.

Predicții: API-urile furnizorilor în timp real vor rămâne neuniforme pentru o perioadă. Durata de viață a simbolurilor, câmpurile de configurare a sesiunii, controalele de deconectare de pe partea serverului, evenimentele de utilizare și suportul pentru regiune vor diferi. Gateway-urile ar trebui să modeleze în mod explicit capabilitățile furnizorului, în loc să pretindă că toate API-urile în timp real sunt perfect portabile.

Arhitectură de referință: gateway ca plan de control în timp real

Un flux în timp real sigur pentru browser are cinci părți:

1. Aplicația client: browser sau aplicație mobilă care solicită o sesiune vocală.
2. Backend-ul aplicației: autentifică utilizatorul final și apelează gateway-ul sau încorporează logica de generare a simbolurilor gateway-ului dacă gateway-ul face parte din stiva de backend.
3. Gateway API AI: impune politica locatarilor, rezolvă profilul modelului, rezervă bugetul, înregistrează sesiunea și bate un secret efemer pentru clientul furnizorului.
4. Furnizor în timp real: termină WebRTC sau alt transport în timp real.
5. Registrul contabil și analizele: stabilește utilizarea odată ce sunt disponibile evenimentele furnizorului, datele privind durata sau rapoartele finale de utilizare.

Gateway-ul nu trebuie să transmită fiecare cadru audio pentru a rămâne autoritar. Trebuie să dețină decizia de creare a sesiunii și calea de reconciliere.

Flux de solicitare recomandat

1. Utilizatorul deschide o funcție vocală în aplicația client.
2. Clientul vă apelează backend-ul: POST /voice/sessions.
3. Backend-ul verifică sesiunea utilizatorului și trimite o solicitare mint către gateway cu ID-ul locatarului, ID-ul utilizatorului, caracteristica dorită, metadatele dispozitivului și originea.
4. Poarta de acces evaluează politica și bugetul.
5. Gateway-ul creează o înregistrare locală realtime_session înainte de a contacta furnizorul.
6. Gateway-ul apelează furnizorul cu acreditările sale de rulare protejate și creează o sesiune efemeră în timp real cu un domeniu restrâns.
7. Gateway-ul returnează în browser numai secretul clientului efemer și metadatele sesiunii aprobate.
8. Browserul stabilește conexiunea WebRTC direct cu furnizorul.
9. Gateway-ul ingerează evenimente de utilizare a furnizorului, apeluri inverse, rezultate ale sondajelor sau estimări conservatoare bazate pe durată.
10. Registrul contabil stabilește bugetul rezervat și scrie evenimentele de audit.

Verificări prealabile ale politicii

Cel mai important punct de aplicare este înainte ca jetonul efemer să fie bătut. Odată ce browserul are o autentificare de scurtă durată, aplicarea la mijlocul sesiunii poate fi limitată, cu excepția cazului în care furnizorul acceptă comenzile de actualizare a sesiunii, deconectare, observator sau apel invers.

Cel puțin, gateway-ul ar trebui să verifice:

• Starea chiriașului: activ, suspendat, probă, plătit anticipat, facturat sau pus în carantină.
• Drepturi utilizator: dacă acest utilizator poate folosi vocea în timp real, nu numai chatul text.
• Profil de model permis: model sau implementare în timp real aprobat, nu ID-uri de model arbitrare furnizate de client.
• Politica de regiune și de păstrare: dacă regiunea furnizorului selectat și setul de caracteristici corespund regulilor de date ale chiriașului.
• Durata maximă a sesiunii: de exemplu, 5, 15 sau 30 de minute conform planului.
• Modalități permise: intrare audio, ieșire audio, text, imagine sau apeluri pentru instrumente.
• Șablon de voce și instrucțiuni: fixat sau limitat de politică.
• Buget disponibil: sold preplătit, indemnizație lunară rezervată sau plafonul de cheltuieli pentru fiecare funcție.
• Concurență: sesiuni vocale active la nivel de chiriaș și la nivel de utilizator.
• Controale privind abuzurile: semnalizatoare de risc pentru utilizator, reputația originii, viteza neobișnuită a apelurilor sau comutatorul de oprire a locatarului.

O valoare implicită sigură este respingerea cererilor ambigue. Dacă clientul solicită un model, un instrument, o voce sau o regiune care nu se află în politica în timp real a chiriașului, gateway-ul ar trebui să returneze o eroare clară de politică în loc să extindă accesul în tăcere.

Design înregistrării sesiunii

Creați o înregistrare de sesiune la nivelul gateway-ului înainte de a crea acreditările furnizorului. Acest lucru vă oferă o ancoră de audit, chiar dacă crearea furnizorului reușește, dar browserul nu se conectează niciodată.

{
  "session_id": "rt_01j...",
  "tenant_id": "tenant_123",
  "end_user_id": "user_hash_456",
  "provider": "provider_a",
  „provider_session_id”: nul,
  "model_profile": "voice-support-standard",
  "upstream_model_or_deployment": "real-model-x",
  "regiune": "estus",
  "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:...",
  "status": "batere"
}

Nu stocați în mod prestabilit sunetul brut al microfonului sau solicitările complete. Stocați hashuri de configurare, ID-uri, decizii de politică și metadate minime suficiente pentru audit, asistență și facturare. Dacă este necesară înregistrarea, faceți-o explicită, conștientă de consimțământ și bazată pe politicile chiriașilor.

Punctul final de generare a simbolurilor efemere

Un punct final orientat spre gateway poate arăta astfel:

POST /v1/realtime/sessions
Autorizare: Purtător 
Tip de conținut: application/json
{
  "tenant_id": "tenant_123",
  "end_user_id": "user_hash_456",
  "feature": "support_voice_agent",
  „origin”: „https://app.example.com”,
  "device_nonce": "8f3b...",
  "requested_profile": "voice-support-standard"
}

Răspunsul nu ar trebui să expună cheia dvs. de rulare din amonte:

{
  "session_id": "rt_01j...",
  "provider": "provider_a",
  "transport": "webrtc",
  "client_secret": "ephemeral_secret_here",
  "expires_at": "2026-08-21T10:01:00Z",
  „aprobat”: {
    "model_profile": "voice-support-standard",
    „max_duration_seconds”: 900,
    "modalities": ["audio_input", "audio_output"],
    "instrumente": ["lookup_order_status"]
  }
}

Leagă emisiunea de origine, sesiune utilizator autentificată, chiriaș și un nonce. Este posibil ca furnizorul să nu accepte toate aceste legături în mod nativ, așa că aplicați ceea ce puteți la gateway: limitați rata încercărilor de menținere, respingeți originile neașteptate, înregistrați metadatele dispozitivului și mențineți durata de viață scurtă a simbolului.

Șabloanele de sesiune: restrânse în mod implicit

Un șablon de sesiune în timp real ar trebui să fie mai restrictiv decât o solicitare generală de finalizare a chatului. Sesiunile de voce sunt interactive, mai greu de inspectat în timp real și pot rula mai mult decât se aștepta.

Câmpurile de șablon recomandate includ:

• Model sau implementare fix: ales de un profil de model de la gateway.
• Instrucțiuni: un șablon de prompt controlat de server cu variabile aprobate de chiriași.
• Voce: selectat dintr-o listă permisă.
• Modalitate: dezactivați modurile text, imagine sau instrument, cu excepția cazului în care produsul are nevoie de ele.
• Setări audio de intrare: detectarea rotației, comportamentul transcripției sau gestionarea tăcerii, acolo unde este acceptată.
• Constrângeri de ieșire: lungimea maximă a răspunsului sau comportamentul de răspuns acolo unde este acceptat.
• Lista de instrumente permise: numai instrumentele necesare pentru funcție.
• Durata de viață a sesiunii: expirare scurtă a acreditării plus durata maximă a apelului.

Șabloanele stricte reduc flexibilitatea, dar facilitează costurile, conformitatea și asistența. Dacă echipele de produse au nevoie de voci sau instrucțiuni dinamice, expuneți variantele de profil controlate în loc să transmiteți configurația arbitrară a clientului furnizorului.

Comenzi bugetare pentru voce în timp real

Utilizarea în timp real poate fi mai greu de stabilit înainte de sosirea utilizării finale a furnizorului. O sesiune poate dura cinci secunde sau douăzeci de minute. Poate include intrare audio, ieșire audio, transcriere, apeluri pentru instrumente și indicative text. Prin urmare, poarta de acces ar trebui să combine rezervarea, limitele și reconcilierea.

Înainte de batere

• Estimați un cost de sesiune în cel mai rău caz sau conservator din durata maximă, model, modalități și planul locatarului.
• Rezervați bugetul înainte de a emite secretul clientului.
• Respingeți noile sesiuni dacă locatarul nu are suficient echilibru sau a atins limitele zilnice de voce.

În timpul sesiunii

• Urmăriți sesiunile active și rata de ardere estimată.
• Aplicați limite de concurență pentru locatari și utilizatori.
• Utilizați funcțiile de reziliere acceptate de furnizor sau de actualizare a sesiunii, dacă sunt disponibile.
• Declanșați alerte pentru durata anormală a sesiunii, reconectari repetate sau utilizare neobișnuită a vocii.

După sesiune

• Ingerați evenimentele de utilizare ale furnizorului sau rapoartele finale de utilizare, acolo unde sunt disponibile.
• Rezolvați bugetul rezervat la costul real.
• Dacă utilizarea exactă este întârziată sau incompletă, păstrați o rezervare conservatoare până la reconciliere.
• Atribuiți utilizarea locatarului, utilizatorului, caracteristicii, profilului modelului și ID-ului de sesiune.

Acest lucru este mai puțin exact decât facturarea text sincronă în momentul răspunsului, dar este mai sigur din punct de vedere operațional decât emiterea de acreditări directe fără rezervare.

Apeluri de instrumente în cadrul sesiunilor în timp real

Agenții vocali în timp real devin adesea mai utili atunci când pot apela instrumente: caută un cont, rezervă o întâlnire, actualizează un bilet sau declanșează un flux de lucru. Tratați execuția instrumentului separat de transportul audio.

Conexiunea media a browserului nu ar trebui să implice permisiunea de a produce efecte secundare. Gateway-ul sau backend-ul ar trebui să impună:

• Registrul de instrumente: fiecare instrument are un proprietar, o schemă, un domeniu de aplicare și un nivel de risc.
• Liste permise: șabloanele de sesiune listează exact ce instrumente sunt disponibile.
• Porți de aprobare: acțiunile cu efecte secundare necesită confirmarea utilizatorului, aprobarea umană sau aprobarea politicii.
• Acreditări separate: acreditările instrumentului nu sunt niciodată încorporate în sesiunea browserului.
• Pistă de audit alăturată: fiecare apel de instrument face referire la ID-ul sesiunii în timp real.

De exemplu, unui agent vocal de asistență i se poate permite să apeleze automat lookup_order_status, dar refund_payment poate necesita confirmare explicită și un eveniment de aprobare backend. Furnizorul de timp real poate orchestra conversația, dar gateway-ul dvs. ar trebui să guverneze limita permisiunii.

Vizibilitate fără proxy fiecare octet

Fluxul media direct WebRTC reduce latența gateway-ului și încărcarea lățimii de bandă, dar vizibilitatea devine mai dependentă de evenimentele furnizorului și de propriile metadate ale sesiunii. Proiectați analize în jurul mai multor surse de dovezi:

• Înregistrările de creare a sesiunilor de pe gateway.
• Evenimente ale ciclului de viață la nivelul clientului, cum ar fi conectat, deconectat, încercare de reconectare, microfon refuzat sau apel încheiat.
• ID-urile de sesiune ale furnizorului, evenimentele de utilizare sau înregistrările finale de utilizare.
• Estimări bazate pe durată atunci când utilizarea furnizorului este întârziată.
• Jurnalele de apeluri de instrumente unite prin ID de sesiune.
• Înregistrările privind rezervarea și decontarea bugetului.

Nu așteptați o telemetrie perfectă a furnizorului înainte de a lansa comenzile. Începeți cu rezerve conservatoare și atribuire clară, apoi îmbunătățiți acuratețea decontărilor pe măsură ce raportarea privind utilizarea furnizorului ajunge la maturitate.

Lista de verificare a securității

• Nu trimiteți niciodată chei API standard ale furnizorului către browser sau clienți mobili.
• Utilizați secretele client efemere de scurtă durată pentru pornirea sesiunii în timp real.
• Autentificați utilizatorul final înainte de baterea simbolului.
• Leagă deciziile de batere la metadatele chiriașului, utilizatorului, originii, nonce și dispozitivului, acolo unde este posibil.
• Păstrează datele de conectare ale furnizorului într-un seif backend sau într-un depozit secret al gateway-ului.
• Înregistrați un rând de auditare a sesiunii înainte de baterea furnizorului.
• Utilizați șabloane de sesiune aprobate de chiriași în loc de configurarea arbitrară a clientului.
• Aplicați concurența, utilizarea zilnică și limitele de durată maximă.
• Utilizați liste de instrumente permise și porți de aprobare pentru efecte secundare.
• Reduceți la minimum promptul brut și reținerea sunetului în mod prestabilit.
• Mențineți o matrice a capacităților furnizorilor pentru duratele de viață a simbolurilor, regiunile, instrumentele, evenimentele de utilizare și controalele de terminare.

Matricea capacității furnizorului

Deoarece API-urile în timp real diferă, modelați adaptorul de gateway în funcție de capabilități, mai degrabă decât de presupuneri. O matrice simplă poate conduce deciziile privind rutarea și politicile:

{
  „provider_a”: {
    "transporturi": ["webrtc", "websocket"],
    „ephemeral_client_tokens”: adevărat,
    "token_ttl_seconds": 60,
    „server_side_disconnect”: adevărat,
    „session_update”: adevărat,
    "usage_events": "final_and_incremental",
    „regiuni”: [„noi”, „eu”],
    „tool_approval_supported”: adevărat
  },
  „provider_b”: {
    "transports": ["websocket"],
    „ephemeral_client_tokens”: adevărat,
    "token_ttl_seconds": 120,
    „server_side_disconnect”: fals,
    „session_update”: fals,
    "usage_events": "final_only",
    „regiuni”: [„noi”],
    „tool_approval_supported”: fals
  }
}

Dacă un chiriaș solicită rezidența în UE și terminarea pe server, gateway-ul ar trebui să direcționeze numai către furnizori și implementări care le satisfac pe ambele. Dacă niciun furnizor nu respectă politica, nu se închide.

Cale de migrare

Nu trebuie să construiți fiecare control în prima zi. O lansare practică este:

1. Numai crearea de sesiuni proxy: păstrați media direct, dar solicitați ca toate sesiunile în timp real să fie create de backend sau de gateway.
2. Adăugați șabloane de politici: înlocuiți modelele furnizate de client și câmpurile de instrucțiuni cu profiluri aprobate.
3. Adăugați rezervarea bugetului: rezervați costul conservator al sesiunii înainte de emiterea simbolului.
4. Adăugați analiza ciclului de viață: colectați începutul sesiunii, conectați, deconectați, durata, ID-ul sesiunii furnizorului și starea decontării.
5. Adăugați guvernanța instrumentelor: necesită liste de permise și aprobări pentru apelurile în timp real pentru instrumente.
6. Adăugați ruta pentru capacitatea furnizorului: selectați furnizorii în funcție de regiune, modalitate, asistență pentru evenimente și comenzi de terminare.
7. Adăugați fluxuri de lucru opționale de observator sau de înregistrare: numai acolo unde sunt conforme, consimțite și aprobate de chiriași.

Concluzie acționabilă

Pentru IA vocală în timp real, un gateway API AI nu ar trebui să devină automat un releu media. Arhitectura mai sigură și cu latență mai scăzută este aceea de a menține gateway-ul responsabil de planul de control: autentificarea utilizatorilor, aplicarea politicii locatarului, rezervarea bugetului, crearea unei înregistrări de audit, crearea unei acreditări efemere cu sferă restrânsă și reconcilierea utilizării după sesiune.

Regula de implementare de bază este simplă: browserele pot primi secrete de sesiune de scurtă durată, niciodată chei de furnizor cu durată lungă de viață. Orice altceva decurge de la acea limită: șabloane stricte, batere conștientă de origine, limite de sesiuni concurente, aprobări de instrumente, decontare de utilizare și matrice de capabilități ale furnizorului. Acest lucru oferă echipelor de produse experiențe vocale în timp real, fără a renunța la gestionarea cheilor API, la controlul costurilor API AI, la guvernarea API-ului echipei sau la analiza utilizării AI.

Lectură similară

• registru de rezervare și decontare buget