IA em tempo real segura para navegador por meio de um gateway de API: tokens efêmeros, política de locatário e controles de sessão de voz
Uma arquitetura prática para IA de voz móvel e de navegador: mantenha a baixa latência de mídia em tempo real com credenciais de cliente de curta duração enquanto o gateway aplica políticas de locatário, verificações de orçamento, controles de ferramentas e trilhas de auditoria.
O navegador e os aplicativos para dispositivos móveis não devem receber chaves de API de provedor de longa duração. Para IA de voz em tempo real, entretanto, enviar cada pacote de áudio através de um gateway pode adicionar latência, custo operacional e modos de falha. O melhor padrão é manter o gateway no plano de controle: autenticar o usuário, aplicar a política de locatário, reservar orçamento, criar uma credencial estreita e de curta duração em tempo real e permitir que a mídia sensível à latência use o transporte em tempo real do provedor quando apropriado.
Este artigo descreve um padrão de implementação para equipes que criam agentes de voz, assistentes de chamada, tutores móveis, copilotos de suporte ou interfaces de voz no aplicativo por meio de um gateway de API de IA. O objetivo é a segurança do navegador sem perder a governança dos locatários.
O problema: conexões diretas em tempo real ignoram seus controles
Um proxy simples do lado do servidor é atraente porque centraliza chaves e observabilidade. Para solicitações de texto padrão, esse geralmente é o modelo certo. O áudio em tempo real é diferente. Uma sessão de voz pode envolver entrada contínua de microfone, saída de áudio bidirecional, interrupções, chamadas de ferramentas e expectativas estritas de latência. Fazer proxy de todas as mídias por meio do seu gateway pode transformá-lo em um media relay com uso intenso de largura de banda, em vez de um serviço de política e cobrança.
Conexões diretas do navegador ao provedor resolvem a latência, mas criam um problema diferente:
- O navegador não pode manter com segurança uma chave de API de provedor padrão.
- As verificações de orçamento do locatário poderão ser ignoradas se o aplicativo se conectar diretamente.
- Restrições de modelo, região, voz, modalidade e ferramenta tornam-se promessas do lado do cliente.
- A atribuição de uso fica incompleta ou atrasada.
- As equipes de segurança perdem um ponto de decisão auditável antes do início da sessão.
O design prático não é “proxy de cada byte”. É “intermediário de cada sessão”.
Fatos, recomendações e previsões
Fatos: os provedores de IA em tempo real oferecem cada vez mais suporte a transportes de baixa latência, como WebRTC, WebSocket e SIP. A documentação pública da API Realtime da OpenAI descreve interfaces em tempo real de baixa latência, incluindo WebRTC. A orientação WebRTC em tempo real do Azure OpenAI descreve um aplicativo de navegador usando um serviço de token de back-end para recuperar um token efêmero antes de iniciar a conexão WebRTC e alerta contra o uso de uma chave de API padrão em um aplicativo cliente. A orientação em tempo real do OpenAI Agents SDK também recomenda um fluxo em que um back-end cria um token de cliente efêmero de curta duração e o navegador o usa para estabelecer uma conexão WebRTC.
Recomendações: trate o gateway como a autoridade da sessão. Deve decidir se pode existir uma sessão em tempo real, com que modelo, em que região, para que inquilino, com que orçamento e com que ferramentas. O cliente deve receber apenas a credencial mínima de curta duração necessária para iniciar a sessão aprovada.
Previsões: as APIs dos provedores em tempo real permanecerão irregulares por um tempo. A vida útil do token, os campos de configuração da sessão, os controles de desconexão do lado do servidor, os eventos de uso e o suporte regional serão diferentes. Os gateways devem modelar explicitamente os recursos do provedor, em vez de fingir que todas as APIs em tempo real são perfeitamente portáveis.
Arquitetura de referência: gateway como plano de controle em tempo real
Um fluxo em tempo real seguro para navegador tem cinco partes:
- Aplicativo cliente: navegador ou aplicativo móvel que solicita uma sessão de voz.
- Back-end do aplicativo: autentica o usuário final e chama o gateway ou incorpora a lógica de criação de token do gateway se o gateway fizer parte da pilha de back-end.
- Gateway de API de IA: aplica a política de locatário, resolve o perfil do modelo, reserva o orçamento, registra a sessão e cria um segredo temporário do cliente do provedor.
- Provedor em tempo real: encerra o WebRTC ou outro transporte em tempo real.
- Ledger e análises: liquida o uso assim que eventos do provedor, dados de duração ou relatórios finais de uso estiverem disponíveis.
O gateway não precisa retransmitir todos os quadros de áudio para permanecer autoritativo. Ele deve possuir a decisão de criação da sessão e o caminho de reconciliação.
Fluxo de solicitação recomendado
- O usuário abre um recurso de voz no aplicativo cliente.
- O cliente chama seu back-end:
POST /voice/sessions. - O back-end verifica a sessão do usuário e encaminha uma solicitação mint para o gateway com ID do locatário, ID do usuário, recurso pretendido, metadados do dispositivo e origem.
- O gateway avalia políticas e orçamento.
- O gateway cria um registro
realtime_sessionlocal antes de entrar em contato com o provedor. - O gateway chama o provedor com sua credencial de tempo de execução protegida e cria uma sessão efêmera em tempo real com escopo restrito.
- O gateway retorna apenas o segredo efêmero do cliente e os metadados da sessão aprovada para o navegador.
- O navegador estabelece a conexão WebRTC diretamente com o provedor.
- O gateway ingere eventos de uso do provedor, retornos de chamada, resultados de pesquisas ou estimativas conservadoras baseadas na duração.
- O razão liquida o orçamento reservado e grava eventos de auditoria.
Verificações da política antes da cunhagem
O ponto de aplicação mais importante é antes que o token efêmero seja cunhado. Quando o navegador tiver uma credencial de curta duração, a aplicação no meio da sessão poderá ser limitada, a menos que o provedor ofereça suporte a controles de atualização, desconexão, observador ou retorno de chamada da sessão.
No mínimo, o gateway deve verificar:
- Status do locatário: ativo, suspenso, teste, pré-pago, faturado ou em quarentena.
- Direitos do usuário: se esse usuário pode usar voz em tempo real, e não apenas chat de texto.
- Perfil de modelo permitido: modelo ou implantação em tempo real aprovado, e não IDs de modelo arbitrários fornecidos pelo cliente.
- Região e política de retenção: se a região do provedor selecionado e o conjunto de recursos correspondem às regras de dados do locatário.
- Duração máxima da sessão: por exemplo, 5, 15 ou 30 minutos por plano.
- Modalidades permitidas: entrada de áudio, saída de áudio, texto, imagem ou chamadas de ferramentas.
- Modelo de voz e instrução: fixo ou limitado pela política.
- Orçamento disponível: saldo pré-pago, subsídio mensal reservado ou teto de gastos por recurso.
- Simultaneidade: sessões de voz ativas em nível de locatário e de usuário.
- Controles de abuso: sinalizadores de risco do usuário, reputação de origem, velocidade de chamada incomum ou interruptor de interrupção do locatário.
Um padrão seguro é rejeitar solicitações ambíguas. Se o cliente solicitar um modelo, ferramenta, voz ou região que não esteja na política em tempo real do locatário, o gateway deverá retornar um erro de política claro em vez de ampliar silenciosamente o acesso.
Design de registro de sessão
Crie um registro de sessão no gateway antes de criar a credencial do provedor. Isso fornece uma âncora de auditoria mesmo que a criação do provedor seja bem-sucedida, mas o navegador nunca se conecte.
Por padrão, não armazene áudio bruto do microfone ou prompts completos. Armazene hashes de configuração, IDs, decisões políticas e metadados mínimos suficientes para auditoria, suporte e cobrança. Se a gravação for necessária, torne-a explícita, consciente do consentimento e orientada pela política do locatário.
Endpoint de criação de token efêmero
Um endpoint voltado para gateway pode ter esta aparência:
A resposta não deve expor sua chave de tempo de execução upstream:
Vincule a emissão à origem, à sessão do usuário autenticado, ao locatário e a um nonce. O provedor pode não oferecer suporte nativo a todas essas ligações, portanto, aplique o que puder no gateway: limite a taxa de tentativas de criação, rejeite origens inesperadas, registre metadados do dispositivo e mantenha o tempo de vida do token curto.
Modelos de sessão: restritos por padrão
Um modelo de sessão em tempo real deve ser mais restritivo do que uma solicitação geral de conclusão de chat. As sessões de voz são interativas, mais difíceis de inspecionar em tempo real e podem durar mais tempo do que o esperado.
Os campos de modelo recomendados incluem:
- Modelo fixo ou implantação: escolhido por um perfil de modelo do lado do gateway.
- Instruções: um modelo de prompt controlado pelo servidor com variáveis aprovadas pelo locatário.
- Voz: selecionada em uma lista de permissões.
- Modalidades: desative os modos de texto, imagem ou ferramenta, a menos que o produto precise deles.
- Configurações de entrada de áudio: detecção de mudança de direção, comportamento de transcrição ou tratamento de silêncio quando compatível.
- Restrições de saída: comprimento máximo da resposta ou comportamento da resposta quando suportado.
- Lista de permissões de ferramentas: somente ferramentas necessárias para o recurso.
- Vida útil da sessão: expiração curta da credencial mais duração máxima da chamada.
Modelos rígidos reduzem a flexibilidade, mas facilitam os custos, a conformidade e o suporte. Se as equipes de produto precisarem de vozes ou instruções dinâmicas, exponha variantes de perfil controladas em vez de passar configurações arbitrárias do cliente para o provedor.
Controles de orçamento para voz em tempo real
Pode ser mais difícil definir o preço do uso em tempo real antes que o uso final do provedor chegue. Uma sessão pode durar cinco segundos ou vinte minutos. Pode incluir entrada de áudio, saída de áudio, transcrição, chamadas de ferramentas e tokens de texto. O gateway deve, portanto, combinar reserva, limites e reconciliação.
Antes da cunhagem
- Estime o pior caso ou o custo conservador da sessão com base na duração máxima, modelo, modalidades e plano de locatário.
- Reserve o orçamento antes de emitir o segredo do cliente.
- Rejeite novas sessões se o locatário não tiver saldo suficiente ou atingir os limites diários de voz.
Durante a sessão
- Acompanhe sessões ativas e taxa de consumo esperada.
- Aplique limites de simultaneidade de locatários e usuários.
- Use recursos de encerramento ou atualização de sessão suportados pelo provedor, se disponíveis.
- Acione alertas sobre duração anormal da sessão, reconectações repetidas ou uso incomum de voz.
Depois da sessão
- Ingerir eventos de uso do provedor ou relatórios finais de uso, quando disponíveis.
- Liquidar o orçamento reservado com base no custo real.
- Se o uso exato estiver atrasado ou incompleto, mantenha uma reserva conservadora até a reconciliação.
- Atribuir o uso ao locatário, usuário, recurso, perfil do modelo e ID da sessão.
Isso é menos exato do que o faturamento de texto síncrono no momento da resposta, mas é operacionalmente mais seguro do que emitir credenciais diretas sem reservas.
Chamadas de ferramentas em sessões em tempo real
Os agentes de voz em tempo real geralmente se tornam mais úteis quando podem chamar ferramentas: pesquisar uma conta, agendar um compromisso, atualizar um ticket ou acionar um fluxo de trabalho. Trate a execução da ferramenta separadamente do transporte de áudio.
A conexão de mídia do navegador não deve implicar permissão para realizar efeitos colaterais. O gateway ou back-end deve impor:
- Registro de ferramentas: cada ferramenta tem um proprietário, esquema, escopos e nível de risco.
- Listas de permissões: os modelos de sessão listam exatamente quais ferramentas estão disponíveis.
- Portões de aprovação: ações com efeitos colaterais exigem confirmação do usuário, aprovação humana ou aprovação de política.
- Credenciais separadas: as credenciais da ferramenta nunca são incorporadas na sessão do navegador.
- Trilha de auditoria unida: cada chamada de ferramenta faz referência ao ID da sessão em tempo real.
Por exemplo, um agente de voz de suporte pode ter permissão para ligar para lookup_order_status automaticamente, mas refund_payment pode exigir confirmação explícita e um evento de aprovação de back-end. O provedor em tempo real pode orquestrar a conversa, mas seu gateway deve controlar o limite de permissão.
Visibilidade sem proxy de cada byte
O fluxo de mídia WebRTC direto reduz a latência do gateway e a carga de largura de banda, mas a visibilidade se torna mais dependente dos eventos do provedor e dos metadados da sua própria sessão. Projete análises em torno de múltiplas fontes de evidências:
- Registros de criação de sessão do gateway.
- Eventos do ciclo de vida do cliente, como conexão, desconexão, tentativa de reconexão, microfone negado ou chamada encerrada.
- IDs de sessão do provedor, eventos de uso ou registros de uso final.
- Estimativas baseadas na duração quando o uso do provedor está atrasado.
- Registros de chamadas de ferramenta unidos por ID de sessão.
- Registros de reserva e liquidação de orçamento.
Não espere pela telemetria perfeita do provedor antes de iniciar os controles. Comece com reservas conservadoras e atribuição clara e, em seguida, melhore a precisão da liquidação à medida que os relatórios de uso do provedor amadurecem.
Lista de verificação de segurança
- Nunca envie chaves de API de provedor padrão para navegadores ou clientes móveis.
- Use segredos de cliente efêmeros de curta duração para inicialização de sessões em tempo real.
- Autentique o usuário final antes da criação do token.
- Vincule decisões de cunhagem a metadados de locatário, usuário, origem, nonce e dispositivo sempre que possível.
- Mantenha as credenciais de tempo de execução do provedor em um cofre de back-end ou armazenamento secreto de gateway.
- Registre uma linha de auditoria da sessão antes da criação do provedor.
- Use modelos de sessão aprovados pelo locatário em vez de configurações arbitrárias de cliente.
- Aplique simultaneidade, uso diário e limites máximos de duração.
- Use listas de permissões de ferramentas e portas de aprovação para efeitos colaterais.
- Minimize a solicitação bruta e a retenção de áudio por padrão.
- Mantenha uma matriz de capacidade do provedor para tempos de vida de tokens, regiões, ferramentas, eventos de uso e controles de encerramento.
Matriz de capacidade do provedor
Como as APIs em tempo real são diferentes, modele seu adaptador de gateway com base em recursos e não em suposições. Uma matriz simples pode orientar decisões políticas e de roteamento:
Se um locatário exigir residência na UE e terminação no lado do servidor, o gateway deverá rotear apenas para provedores e implantações que satisfaçam ambos. Se nenhum provedor atender à política, falha no fechamento.
Caminho de migração
Você não precisa criar todos os controles no primeiro dia. Uma implementação prática é:
- Apenas criação de sessão proxy: mantenha a mídia direta, mas exija que todas as sessões em tempo real sejam criadas pelo back-end ou gateway.
- Adicionar modelos de política: substitua o modelo fornecido pelo cliente e os campos de instrução por perfis aprovados.
- Adicionar reserva de orçamento: reserve o custo conservador da sessão antes da emissão do token.
- Adicione análises do ciclo de vida: colete o início da sessão, conexão, desconexão, duração, ID da sessão do provedor e status de liquidação.
- Adicionar governança de ferramentas: exija listas de permissões e aprovações para chamadas de ferramentas em tempo real.
- Adicionar capacidade de roteamento do provedor: selecione provedores por região, modalidade, suporte a eventos e controles de terminação.
- Adicione fluxos de trabalho opcionais de observação ou gravação: somente quando estiver em conformidade, consentido e aprovado pelo locatário.
Conclusão acionável
Para IA de voz em tempo real, um gateway de API de IA não deve se tornar automaticamente um media relay. A arquitetura mais segura e de menor latência é manter o gateway responsável pelo plano de controle: autenticar usuários, aplicar a política de locatário, reservar orçamento, criar um registro de auditoria, criar uma credencial efêmera de escopo restrito e reconciliar o uso após a sessão.
A principal regra de implementação é simples: os navegadores podem receber segredos de sessão de curta duração, nunca chaves de provedor de longa duração. Todo o resto segue esse limite: modelos rígidos, criação com reconhecimento de origem, limites de sessões simultâneas, aprovações de ferramentas, liquidação de uso e matrizes de capacidade do provedor. Isso proporciona às equipes de produtos experiências de voz em tempo real sem abrir mão do gerenciamento de chaves de API, do controle de custos de API de IA, da governança de API da equipe ou da análise de uso de IA.