Новый Decisions API от OpenAI нацелен на ту часть ИИ-приложений, которая редко появляется в демонстрациях запуска: небольшое решение, принимаемое между двумя более крупными этапами.

Редакционная технологическая фотография с абстрактным процессом маршрутизации решений ИИ на мониторе.

Следует ли направить этот запрос в службу расчётов или техническую поддержку? Достаточно ли заполнен документ, чтобы передать его на следующий этап рабочего процесса? Безопасно ли автоматически выполнить сгенерированную команду оболочки? Должен ли голосовой ассистент задать уточняющий вопрос, перевести разговор на другого сотрудника или продолжить?

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

OpenAI открыла общий доступ к Decisions API 22 октября 2026 года. Он работает на GPT-6 Luna и возвращает ответы заданного типа, а не абзац текста: вероятность, вариант из заранее определённого набора или оценку по упорядоченной шкале. По словам OpenAI, конечная точка предназначена для ответа на такие ограниченные вопросы со скоростью до 10 раз выше, чем при использовании GPT-6 Luna через Responses API. Компания указывает цену 0,10 доллара за миллион входных токенов; плата за выходные токены для этой конечной точки не взимается.

Такая комбинация делает Decisions интересным для команд, которые уже создают ИИ-продукты. Как замена универсальному ассистенту он значительно менее интересен. Важен не вопрос о том, умеет ли модель рассуждать. Важно, может ли команда достаточно чётко определить узкое решение, чтобы измерять его качество, задать разумный порог и удерживать вытекающее из него действие внутри контролируемого рабочего процесса.

Что на самом деле возвращает API

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

predicate оценивает, истинно ли условие, и возвращает вероятность от нуля до единицы. Это подходит для вопросов вроде «Описывает ли этот тикет повторное списание, подтверждаемое записью о заказе?» или «Видны ли на этом изображении повреждения?»

choice выбирает одно значение из заранее определённого набора. Система маршрутизации может предлагать варианты billing, technical_support, account_access и human_review. Голосовое приложение может выбрать continue, clarify, transfer или end_call.

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

Конечная точка может задать до 400 вопросов в одном запросе — это больше прежнего ограничения в 200 вопросов, действовавшего во время публичного бета-тестирования. Это важно, когда множество независимых атрибутов нужно оценить по одним и тем же исходным данным. Но это не означает, что зависимые решения следует объединять. Если второй вопрос нужно задавать только после получения ответа на первый, отдельные запросы упрощают проверку и тестирование логики управления.

Главное продуктовое отличие API — типизированный вывод. Универсальную модель можно попросить вернуть JSON, но разработчику всё равно придётся проверять этот вывод и обрабатывать некорректные или неоднозначные значения. Decisions ограничивает пространство ответов на уровне API. Это уменьшает объём работы по разбору результатов, но не делает исходное суждение правильным.

Где API подходит в реальном приложении

Лучше всего он подходит для повторяющихся решений с ограниченным набором ответов и понятным следующим шагом. Воспринимайте конечную точку как быстрый слой принятия решений внутри уже существующей программы, а не как автономного сотрудника.

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

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

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

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

Голосовые приложения также хорошо подходят для этого сценария: медленное решение заметно человеку, который говорит. Decisions теперь поддерживает нативную интеграцию с GPT-Live, и её можно запускать по мере поступления входных или выходных транскриптов. Приложение может решить, следует ли ассистенту попросить уточнение, перевести звонок или обновить состояние взаимодействия. OpenAI сообщает, что в тестах Speak сократила время до следующего действия с 1,4 секунды до 0,13 секунды благодаря этой интеграции. Это результат, заявленный поставщиком, а не гарантия для любого голосового стека, но он показывает, почему специализированный эндпоинт может быть важнее в интерактивном цикле, чем в пакетной обработке.

Практическая архитектура: модель, порог, действие

Надёжная реализация требует трёх отдельных уровней.

Первый уровень — сам вопрос. Он должен описывать наблюдаемые признаки и различать близкие варианты ответа. «Это хорошо?» — не производственный вопрос. «Содержит ли сообщение просьбу отменить платную подписку, а не запрос информации о тарифах?» — уже гораздо ближе к нужной формулировке.

Второй уровень — политика интерпретации ответа. Вероятность 0,82 не означает, что приложение обязано действовать. Команда должна решить, достаточно ли 0,82 для автоматической маршрутизации, должна ли оценка 0,55 запускать проверку и требуют ли некоторые категории участия человека при любой уверенности.

Третий уровень — действие. Модели не следует предоставлять широкие полномочия лишь потому, что она вернула допустимый вариант. Приложение должно сопоставлять разрешённое значение с известной функцией и отклонять всё, что не входит в это соответствие. Для чувствительных операций нужны независимая авторизация и, где это уместно, подтверждение человека.

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

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

Проектирование промпта теперь означает проектирование политики

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

Предположим, команда хочет маршрутизировать счета. Слабая формулировка может предложить модели «выбрать подходящий отдел». Производственный вопрос должен указать доступные отделы, поля, по которым определяется каждый из них, значение неполного документа и правило для противоречивых сигналов. В него также можно явно добавить вариант human_review, чтобы при неоднозначном вводе не заставлять модель выбирать одну из бизнес-очередей.

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

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

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

Низкая цена, но при большом объёме расчёт меняется

Опубликованная цена Decisions составляет $0,10 за миллион некэшированных входных токенов и $0,01 за миллион кэшированных. Плата за выходные токены для этого endpoint не взимается. На первый взгляд многие задачи маршрутизации выглядят почти бесплатными.

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

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

Endpoint позволяет задать много независимых вопросов в одном запросе. Это может сократить накладные расходы на запросы, но не должно превращаться в повод задавать по каждому элементу все мыслимые вопросы. Лишние вопросы повышают сложность, затрудняют оценку и могут подтолкнуть команды к использованию оценок, которые никто не проверял.

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

Конфиденциальность и региональные ограничения

API поддерживает размещение инференса в США и Европе, а OpenAI сообщает, что для соответствующих требованиям клиентов доступен режим Zero Data Retention. В документации для разработчиков также указана поддержка HIPAA для подходящих клиентов и описана доступность Private Link. Это полезные средства контроля, однако организации, внедряющей систему, всё равно нужно проверить соответствие требованиям, договоры, настройки endpoint и ограничения функций.

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

Структурированный JSON сам по себе не делает чувствительную информацию безопасной. Запись клиента, переданная через input_json, всё равно остаётся данными клиента. Изображения также чувствительны, если на них видны лица, адреса, медицинская информация или конфиденциальные экраны. Важно не то, принимает ли API такой формат, а наличие обоснованной причины передавать эти сведения в рамках рабочего процесса.

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

Что Decisions не заменяет

Этот endpoint не является универсальной системой извлечения данных. Если приложению нужен содержательный объект с большим числом полей, письменное объяснение или результат по пользовательской схеме, более подходящим может оказаться Responses API со Structured Outputs. Если модели нужно запросить инструмент с аргументами, более понятной абстракцией может быть вызов функций.

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

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

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

Небольшой пилот, способный дать полезные данные

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

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

Затем составьте конечный набор ответов. Добавьте human_review, если неопределённость является допустимым исходом. Определите, что разрешает каждый ответ, а что он не разрешает. Если действие нельзя сформулировать ясно, решение, вероятно, задано слишком широко.

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

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

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

Кому стоит попробовать, а кому лучше подождать

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

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

Командам стоит подождать, если они всё ещё ищут подходящий сценарий, не могут объяснить, как выглядит правильный ответ, или собираются разрешить endpoint самостоятельно выбирать произвольные инструменты и действия. Низкая цена токенов не компенсирует неопределённую политику. Быстрый ответ также не должен скрывать отсутствие разрешений, проверки или аудита.

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

Такое разделение не устранит ошибки модели. Зато их станет проще измерять, локализовать и исправлять. Для большинства команд именно в этом практический смысл тестирования Decisions: не в том, что каждому процессу нужен ещё один endpoint с ИИ, а в том, что некоторым процессам нужен меньший и более подотчётный слой принятия решений.