Michael Johnson22 октября OpenAI опубликовала описание работы FDE — команды forward-deployed engineering, которая вместе с корпоративными клиентами адаптирует ИИ к конкретным процессам. Руководитель направления Колин Джарвис объясняет, как инженеры изучают работу заказчика, согласуют критерии качества и превращают отдельные решения в повторно используемые компоненты.
Так компания описывает разрыв между результатом модели в тестовом запросе и способностью системы надёжно выполнять задачу в реальной среде. Когда узкое место связано с продуктом или интеграцией, команда дорабатывает решение с заказчиком; если модель не справляется с требованиями задачи, к работе подключаются исследователи OpenAI.
От задачи клиента к измеримому результату
В одном из примеров, относящемся к середине 2025 года, около 15 инженеров OpenAI работали с крупным производителем полупроводников над более чем десятью сценариями: генерацией направленных тестов, поиском причин отказов и помощью при проектировании. По данным компании, за первые три-шесть месяцев сценарии дошли до производства и раннего использования. OpenAI приводит экономию около 48% времени на генерации тестов и сокращение отладки с недель до часов.
Эти показатели относятся к описанным OpenAI процессам конкретного клиента. Для внедрения важен сам метод: заранее согласовать критерии успеха с практикующими специалистами, собрать реальные случаи и измерять результат всего рабочего процесса, включая проверку человеком.
Повторное использование вместо разовых интеграций
Первоначальные решения для производителя требовали много индивидуального кода. OpenAI пишет, что при перестройке приложений вокруг Codex отдельные интерфейсы заменили общими инструментами, плагинами и навыками. Компания оценивает сокращение пользовательского кода примерно в 90% для каждого описанного проекта. В примере августа 2026 года первое внедрение заняло два месяца, а подключение второй команды — один день.
Для собственного пилота полезно отдельно считать трудозатраты на первое внедрение и на подключение следующего подразделения. Если коннекторы, инструкции и проверки качества удаётся использовать повторно, перенос решения может требовать меньше индивидуальной разработки. Приведённые OpenAI сроки описывают её конкретный пример, а не гарантированный темп для любого проекта.
От клиентского пилота к налоговому продукту
Отдельный пример OpenAI — Tax AI для бухгалтерских фирм Crete, созданный совместно с Thrive Holdings. По сообщению компании, во время пилота система обработала 7 000 налоговых деклараций, а пропускная способность выросла примерно на 50%. Один из сложных сценариев — декларации по аренде недвижимости — потребовал шести недель инженерной работы и проверки специалистами, чтобы достичь 90% точности и полноты выявления.
OpenAI пишет, что полученные шаблоны затем помогли расширять Tax AI на другие сложные налоговые графики. Для практической оценки такого пилота следует учитывать не только долю корректных результатов, но и объём ручной проверки, скорость обработки и работу, необходимую для переноса решения на следующий тип документов.
Когда менять интеграцию, а когда — модель
В другом, отдельном проекте с крупным телеком-оператором команда развивала голосовую поддержку. По данным OpenAI, на ключевых внутренних тестах системы, оценивавших пригодность сценария к производству, результат первоначально составлял около 60%. За шесть месяцев он вырос до 80%, а затем превысил 90% после совместной работы инженеров внедрения, клиента и исследовательской команды. OpenAI связывает улучшение с тестированием распознавания речи, следования инструкциям и вызова функций в сценариях обслуживания клиентов.
Такой процесс помогает установить, где именно нужна работа: в интеграции и интерфейсе или в способности модели выполнять заданную функцию. OpenAI описывает внутренние оценки и клиентские проекты компании; эти результаты показывают, как она организует внедрение, а не задают универсальный прогноз для других заказчиков.
Что проверить в своём пилоте
До расширения внедрения зафиксируйте исходный способ выполнения задачи, объём ручной проверки и критерии приёмки. Проверьте систему на реальных случаях, включая редкие ошибки, и измеряйте время до принятого результата, долю исправлений и стоимость поддержки интеграции. При переносе в другую команду сравните те же показатели и отдельно посчитайте подключение источников данных и настройку доступа.
Рассказ OpenAI даёт практический ориентир: начинать с измеримой задачи, проверять решение в условиях реальной работы и строить компоненты так, чтобы следующий запуск мог опираться на результаты предыдущего. Именно это связывает отдельный пилот с повторяемым внедрением.