Встроенные оценки модерации OpenAI в каждом ответе API: что новый сигнал безопасности меняет для команд с multi-provider routing

В changelog OpenAI API от 4 июня 2026 г. появилась функция, которую инженерные команды ждали с момента запуска отдельного moderation endpoint: возможность запросить оценки omni-moderation-latest для пользовательского ввода и сгенерированного вывода в рамках одного API-вызова — без дополнительного round-trip. Изменение распространяется на Responses API и Chat Completions API.

Для команд, строящих или эксплуатирующих multi-provider routing layer, это не просто удобное улучшение — это новый сигнал, который gateway теперь может встраивать непосредственно в путь генерации.

Что изменилось

Начиная с 4 июня 2026 г. любой запрос на генерацию может содержать объект moderation:

{
  "model": "gpt-5.5",
  "input": [{"role": "user", "content": "..."}],
  "moderation": {"model": "omni-moderation-latest"}
}

Ответ включает response.moderation.input и response.moderation.output, каждый из которых содержит flagged, categories и category_scores — в точности ту же структуру, что возвращает отдельный moderation endpoint. Ключевые детали:

• Бесплатно: модель модерации не добавляет стоимости к запросу.
• В обоих направлениях: вы получаете оценки как для пользовательского prompt, так и для вывода модели — это позволяет поймать проблемный контент даже тогда, когда входящий запрос был безупречным.
• Работает с tool-calls: модерация охватывает аргументы tool-call и выводы инструментов, появляющиеся в содержимом разговора. Она не распространяется на названия инструментов, схемы и response-format схемы.
• Ограничение при streaming: результаты модерации приходят после того, как полный вывод сформирован — они не включаются в partial delta.
• Обработка ошибок: если модерация не может завершиться, соответствующее поле содержит объект ошибки вместо оценок.

Модель модерации запускается параллельно с генерацией на стороне OpenAI, поэтому накладные расходы по latency на практике близки к нулю.

Почему это важно для команд AI engineering

До сих пор у команд, желающих модерировать вывод API, было два варианта: (a) делать отдельный вызов /moderations после генерации, добавляя ~200-400 мс задержки, или (b) поднимать собственный классификатор pipeline. Вариант (a) был терпим для batch-обработки, но болезненен для real-time диалоговых сценариев и coding-agent. Вариант (b) требовал поддержки отдельного деплоя модели.

Встроенная модерация объединяет оба пути в один API-вызов. Для сетапов, работающих только через OpenAI, миграция тривиальна — достаточно добавить одно JSON-поле. Но для multi-provider routing архитектур последствия более глубокие.

Взгляд с позиции router/operator

Это изменение вводит provider-специфичный сигнал, которого сегодня нет на конкурирующих endpoint. Это создаёт три конкретных развилки для операторов routing layer:

1. Фрагментация сигналов безопасности между провайдерами. OpenAI теперь возвращает структурированные оценки модерации inline. Anthropic возвращает stop_reason: "refusal" без разбивки по категориям. DeepSeek, Qwen/DashScope и большинство китайских провайдеров не возвращают ни того ни другого — они либо молча блокируют, либо возвращают ошибку. Если ваш routing layer должен обеспечивать единую политику безопасности контента, вы не можете рассчитывать на одинаковые данные от каждого провайдера. Ключевой вопрос: нормализовать ли «оценку безопасности» из разнородных сигналов (коды причины отказа, inline moderation, собственный классификатор) или запускать не зависящий от провайдера safety-pass на каждом выводе?

2. Routing-решения после генерации. При наличии встроенных оценок ваш gateway теперь может принимать решения о маршрутизации после генерации. Если GPT-5.5 вернул помеченный вывод (например, оценка violence > 0.8), gateway может автоматически повторить запрос со строгим system prompt, переключиться на другой tier модели или эскалировать на ручную проверку — всё это в рамках одного жизненного цикла запроса. Это новый паттерн, у которого раньше не было чёткого API-примитива.

3. Audit trail и соответствие требованиям. Встроенная модерация позволяет вести записи безопасности для каждого запроса и ответа без дополнительных API-вызовов. Для enterprise-команд, работающих в рамках EU AI Act или аналогичных регуляторных требований, это самый дешёвый путь к защищённому audit log: каждая генерация получает оценку безопасности прямо на уровне API — без дополнительной latency и стоимости.

Оговорка: эти оценки работают только при прямом routing на OpenAI. Если ваш gateway проксирует запросы через провайдера, не поддерживающего inline moderation, вы не получите ничего. Это делает функцию мягким сигналом привязки к провайдеру — не потому что она проприетарна, а потому что альтернативные провайдеры ещё не выпустили эквивалент.

На что обращать внимание пользователям TheRouter

Если ваша routing policy включает safety-контроль контента и трафик направляется к OpenAI, новый inline moderation primitive стоит встроить. Ключевой вопрос: должен ли gateway рассматривать объект moderation как опциональное поле для прозрачной передачи или нормализовать сигналы безопасности разных провайдеров в единый policy layer.

Для команд, использующих OpenAI-совместимый endpoint TheRouter: параметр moderation передаётся upstream провайдеру, и вы получаете оценки, когда upstream — OpenAI. Когда upstream — провайдер без поддержки inline moderation, поле молча игнорируется: ошибки нет, но и оценок нет. За этим стоит следить: по мере того как всё больше провайдеров будут добавлять аналогичные примитивы, ваш routing layer станет естественным местом для их агрегации.

Что отслеживать:

• Появятся ли у Anthropic, Google или DashScope эквивалентные встроенные safety-сигналы в ближайшие 6 месяцев.
• Требует ли ваша compliance-команда оценки безопасности для каждого ответа — если да, inline moderation сейчас покрывает лишь одного провайдера.
• Распространит ли OpenAI модель модерации на аудио-входы (пока поддерживаются только текст и изображения).