Безопасный для браузера искусственный интеллект в реальном времени через шлюз API: эфемерные токены, политика арендаторов и управление голосовыми сеансами

Браузеры и мобильные приложения не должны получать долгосрочные ключи API поставщика. Однако для голосового ИИ в реальном времени отправка каждого аудиопакета через шлюз может увеличить задержку, эксплуатационные расходы и режимы сбоя. Лучше всего оставить шлюз в плоскости управления: аутентифицировать пользователя, обеспечить соблюдение политики арендатора, зарезервировать бюджет, создать узкие кратковременные учетные данные реального времени и позволить чувствительным к задержкам носителям использовать транспорт реального времени провайдера, где это возможно.

В этой статье описывается шаблон реализации для команд, создающих голосовые агенты, помощники по вызову, мобильные репетиторы, вторые пилоты службы поддержки или голосовые интерфейсы в приложениях через шлюз AI API. Цель — безопасность браузера без потери управления арендатором.

Проблема: прямые соединения в реальном времени обходят ваш контроль

Простой прокси-сервер на стороне сервера привлекателен тем, что он централизует ключи и обеспечивает возможность наблюдения. Для стандартных текстовых запросов часто это правильная модель. Звук в реальном времени отличается. Голосовой сеанс может включать в себя непрерывный входной сигнал микрофона, двунаправленный аудиовыход, прерывания, вызовы инструментов и строгие ожидания задержки. Проксирование всех носителей через шлюз может превратить шлюз в ретранслятор мультимедиа с высокой пропускной способностью вместо службы политики и выставления счетов.

Прямое подключение браузера к провайдеру решает проблему задержки, но создает другую проблему:

Практический подход заключается не в том, чтобы «проксировать каждый байт». Это «посредник каждой сессии».

Факты, рекомендации и прогнозы

Факты. Поставщики искусственного интеллекта в реальном времени все чаще поддерживают транспорты с малой задержкой, такие как WebRTC, WebSocket и SIP. В общедоступной документации OpenAI Realtime API описаны интерфейсы реального времени с малой задержкой, включая WebRTC. Руководство по WebRTC в реальном времени Azure OpenAI описывает приложение браузера, использующее серверную службу токенов для получения эфемерного токена перед запуском подключения WebRTC, и предостерегает от использования стандартного ключа API в клиентском приложении. В руководстве OpenAI Agents SDK в реальном времени также рекомендуется использовать поток, в котором серверная часть создает недолговечный эфемерный клиентский токен, а браузер использует его для установления соединения WebRTC.

Рекомендации. Считайте шлюз центром управления сеансом. Он должен решить, может ли существовать сеанс в реальном времени, с какой моделью, в каком регионе, для какого арендатора, в рамках какого бюджета и с какими инструментами. Клиент должен получить только минимальные краткосрочные учетные данные, необходимые для начала утвержденного сеанса.

Прогнозы: API-интерфейсы поставщиков реального времени в течение некоторого времени будут оставаться неравномерными. Срок действия токенов, поля конфигурации сеанса, элементы управления отключением на стороне сервера, события использования и поддержка регионов будут различаться. Шлюзы должны явно моделировать возможности поставщика, а не делать вид, что все API реального времени идеально переносимы.

Эталонная архитектура: шлюз как плоскость управления в реальном времени

Безопасный для браузера поток операций в реальном времени состоит из пяти частей:

Шлюзу не обязательно ретранслировать каждый аудиокадр, чтобы оставаться авторитетным. Ему должно принадлежать решение о создании сеанса и путь согласования.

Рекомендуемая последовательность запросов

Предварительная проверка правил

Самый важный момент соблюдения требований — до того, как эфемерный токен будет отчеканен. Если у браузера есть кратковременные учетные данные, принудительное применение в середине сеанса может быть ограничено, если поставщик не поддерживает элементы управления обновлением сеанса, отключением, наблюдением или обратным вызовом.

Шлюз должен проверить как минимум:

Безопасным вариантом по умолчанию является отклонение неоднозначных запросов. Если клиент запрашивает модель, инструмент, голос или регион, которых нет в политике реального времени клиента, шлюз должен вернуть явную ошибку политики вместо молчаливого расширения доступа.

Дизайн записи сеанса

Прежде чем создавать учетные данные поставщика, создайте запись сеанса на стороне шлюза. Это дает вам привязку аудита, даже если создание поставщика прошло успешно, но браузер так и не подключился.

{
  "session_id": "rt_01j...",
  "tenant_id": "tenant_123",
  "end_user_id": "user_hash_456",
  "провайдер": "провайдер_а",
  «provider_session_id»: ноль,
  "model_profile": "стандарт голосовой поддержки",
  "upstream_model_or_deployment": "realtime-model-x",
  "регион": "истус",
  "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_секунд»: 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:...",
  "статус": "чеканка"

По умолчанию не сохраняйте необработанный звук микрофона или полные подсказки. Храните хэши конфигурации, идентификаторы, решения по политике и минимальный метаданные, достаточные для аудита, поддержки и выставления счетов. Если запись требуется, сделайте ее явной, с учетом согласия и на основе политики клиента.

Конечная точка создания эфемерного токена

Конечная точка, обращенная к шлюзу, может выглядеть так:

POST /v1/realtime/sessions
Авторизация: носитель 
Тип контента: приложение/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": "стандарт голосовой поддержки"

Ответ не должен раскрывать ключ среды выполнения исходного потока:

{
  "session_id": "rt_01j...",
  "провайдер": "провайдер_а",
  "транспорт": "webrtc",
  "client_secret": "ephemeral_secret_here",
  "expires_at": "2026-08-21T10:01:00Z",
  "одобрено": {
    "model_profile": "стандарт голосовой поддержки",
    «max_duration_секунд»: 900,
    "modality": ["audio_input", "audio_output"],
    "tools": ["lookup_order_status"]
  }

Привяжите выдачу к источнику, сеансу аутентифицированного пользователя, арендатору и одноразовому номеру. Поставщик может не поддерживать все эти привязки изначально, поэтому применяйте все, что можете, на шлюзе: ограничивайте попытки создания монет, отклоняйте неожиданные источники, записывайте метаданные устройства и сокращайте срок действия токена.

Шаблоны сеансов: по умолчанию сужаются

Шаблон сеанса в реальном времени должен быть более строгим, чем общий запрос на завершение чата. Голосовые сеансы интерактивны, их сложнее проверять в режиме реального времени, и они могут длиться дольше, чем ожидалось.

Рекомендуемые поля шаблона включают:

Строгие шаблоны снижают гибкость, но упрощают затраты, соблюдение требований и поддержку. Если командам разработчиков нужны динамические голоса или инструкции, предоставляйте контролируемые варианты профиля вместо того, чтобы передавать поставщику произвольную конфигурацию клиента.

Управление бюджетом для голосовой связи в реальном времени

Использование в реальном времени может быть сложнее оценить до того, как появится окончательный поставщик услуг. Сеанс может длиться пять секунд или двадцать минут. Он может включать в себя аудиовход, аудиовыход, транскрипцию, вызовы инструментов и текстовые токены. Поэтому шлюз должен сочетать в себе резервирование, ограничения и сверку.

Перед созданием

Во время сеанса

После сеанса

Это менее точно, чем синхронное текстовое выставление счетов в момент ответа, но с точки зрения эксплуатации оно безопаснее, чем выдача прямых учетных данных без резервирования.

Вызовы инструментов внутри сеансов в реальном времени

Голосовые агенты в реальном времени часто становятся более полезными, когда они могут вызывать инструменты: искать учетную запись, записываться на прием, обновлять заявку или запускать рабочий процесс. Рассматривайте выполнение инструмента отдельно от передачи звука.

Медиа-подключение браузера не должно подразумевать разрешение на выполнение побочных эффектов. Шлюз или серверная часть должны обеспечивать следующее:

Например, голосовому агенту службы поддержки может быть разрешено автоматически вызывать lookup_order_status, но для refund_pay может потребоваться явное подтверждение и событие внутреннего утверждения. Поставщик реального времени может организовать диалог, но границы разрешений должен определять ваш шлюз.

Видимость без проксирования каждого байта

Прямой медиапоток WebRTC снижает задержку шлюза и нагрузку на полосу пропускания, но видимость становится более зависимой от событий поставщика и метаданных вашего собственного сеанса. Создавайте аналитику на основе нескольких источников данных:

Не ждите идеальных телеметрических данных поставщика, прежде чем запускать элементы управления. Начните с консервативного резервирования и четкой атрибуции, а затем повышайте точность расчетов по мере развития отчетов об использовании поставщика.

Контрольный список безопасности

Матрица возможностей поставщика

Поскольку API реального времени различаются, моделируйте адаптер шлюза исходя из возможностей, а не предположений. Простая матрица может способствовать принятию решений по маршрутизации и политике:

{
  "провайдер_а": {
    "транспорты": ["webrtc", "websocket"],
    «ephemeral_client_tokens»: правда,
    "token_ttl_секунды": 60,
    «server_side_disconnect»: правда,
    «session_update»: правда,
    "usage_events": "final_and_incremental",
    "регионы": ["нас", "ес"],
    «tool_approval_supported»: правда
  },
  "provider_b": {
    "транспорты": ["веб-сокет"],
    «ephemeral_client_tokens»: правда,
    «токен_ттл_секунды»: 120,
    «server_side_disconnect»: ложь,
    «session_update»: ложь,
    "usage_events": "final_only",
    "регионы": ["нас"],
    «tool_approval_supported»: ложь
  }

Если арендатору требуется резидентство в ЕС и завершение на стороне сервера, шлюз должен маршрутизироваться только к поставщикам и развертываниям, которые удовлетворяют обоим требованиям. Если ни один поставщик не соответствует политике, закрытие при сбое.

Путь миграции

Вам не нужно создавать каждый элемент управления с первого дня. Практическое внедрение:

Практическое заключение

Для голосового ИИ в реальном времени шлюз AI API не должен автоматически становиться ретранслятором мультимедиа. Более безопасная архитектура с меньшей задержкой заключается в том, чтобы шлюз отвечал за плоскость управления: аутентифицировал пользователей, применял политику арендатора, резервировал бюджет, создавал запись аудита, создавал эфемерные учетные данные с узкой областью действия и согласовывал использование после сеанса.

Основное правило реализации простое: браузеры могут получать кратковременные секреты сеанса, а не долгоживущие ключи поставщика. Все остальное вытекает из этой границы: строгие шаблоны, создание с учетом происхождения, ограничение количества одновременных сессий, утверждение инструментов, урегулирование использования и матрицы возможностей поставщика. Это дает группам разработчиков возможность голосового взаимодействия в режиме реального времени, не отказываясь от управления ключами API, контроля затрат AI API, командного управления API или аналитики использования ИИ.

Связанное чтение

• хранилище учетных данных поставщика для среды выполнения ключи
• регистр резервирования бюджета и расчетов