OpenAI Presence: что должно быть готово до запуска клиентского агента

Предложение и его границы

The Decoder сообщает, что OpenAI развивает Presence для производственного использования агентов в клиентском обслуживании и внутренних процессах. Издание отличает это предложение от Workspace Agents, ориентированных преимущественно на внутренние сценарии.

Когда стандартных возможностей недостаточно, по описанию материала подключаются Forward Deployed Engineers OpenAI. Они помогают выбирать процессы, связывать системы, задавать правила и проводить испытания до запуска. Это работа по внедрению, а не только выдача доступа к модели.

На момент публикации Presence был доступен подходящим корпоративным заказчикам и не являлся открытым продуктом. Автор отдельно отмечал недостаток конкретики о соблюдении требований вроде EU AI Act. Мы не восполняем этот пробел предположением о готовой юридической гарантии.

Один запрос целиком

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

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

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

Приёмка на исключениях

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

• У покупателя нет номера заказа: агент предлагает разрешённый способ уточнения.
• Система учёта не отвечает: обращение сохраняется, статус не выдумывается.
• Клиент оспаривает сведения: история передаётся сотруднику вместе с основанием ответа.
• Запрос содержит чужие персональные данные: доступ проверяется до поиска подробностей.

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

Кто остаётся после внедрения

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

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

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