Как внедрять ИИ-агентов в корпорации: инструкция OpenAI

Разбор рекомендаций OpenAI руководителям: один процесс, должностная инструкция агента, метрики глубины и ценности. И чем это закрывается на открытых платформах.

  • Что именно советует OpenAI
  • Почему пять пунктов из шести - не про ИИ
  • Две группы метрик: глубина и ценность
  • Пять ролей, которые нужно назвать поимённо

Что именно советует OpenAI

Документ обращён к руководителям и написан подчёркнуто операционно: не про возможности моделей, а про то, в каком порядке действовать.

Шесть шагов. Выбрать один процесс - и только один.

Критерий отбора жёсткий:

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

Он должен повторяться достаточно часто, чтобы на нём было чему учиться, и быть достаточно важным, чтобы его стоило перекраивать. Сформулировать результат и способ измерения до старта.

Назначить владельца, KPI, базовый уровень и ограничители.

Причём мерить двумя наборами метрик, а не одним. Написать агенту должностную инструкцию.

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

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

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

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

8,3×столько выходных токенов на активного пользователя дают компании из верхних 10% по использованию ИИ против типичных; в январе разрыв был 2,6×
13на столько сообщений в неделю больше пишут ИИ сотрудники в начале карьеры, чем руководители, — через полгода после внедрения
1процесс в первой итерации: не портфель инициатив, а один повторяемый маршрут с измеримым результатом

Почему пять пунктов из шести - не про ИИ

Если убрать слово «агент», останется описание любого управляемого изменения:

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

Это не обесценивает руководство - наоборот, объясняет, почему проваливаются ИИ-проекты у компаний, которые не умеют проводить обычные изменения.

Технология не создаёт управленческую дисциплину, она её обнажает.

Специфичен ровно один пункт - **должностная инструкция агента**

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

У агента ничего этого нет

Всё, что не записано и не ограничено технически, он сделает - или не сделает - непредсказуемо. Поэтому граница «здесь решает сам, здесь обязан остановиться»

перестаёт быть вопросом культуры и становится конфигурацией

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

Две группы метрик: глубина и ценность

Главная методическая мысль руководства: измерять двумя наборами и не путать их. Глубина показывает, что агент реально делает; ценность - изменилось ли что-нибудь в процессе. Объём выдачи не относится ни к тому, ни к другому: рост числа обращений к ИИ говорит лишь о том, что у него стали больше просить.

Глубина — что агент делаетЦенность — что изменилось в процессе
Сколько задач доведено до конца без человекаВремя цикла процесса
Сколько подключено контекста и инструментовКачество результата и доля переделок
Сколько вылезает исключенийСтоимость выполнения
Какая нагрузка на ревьюВыручка и риск

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

Кто отвечает за что

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

Где инструкция упирается в технику

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

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

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

Ответ зависит от того, где живут данные.

Оценить, где ИИ даст эффект в вашем процессе

Пункт руководства → что нужно от платформы

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

ТребованиеМеханизмНа что смотреть при выборе
Остановиться и позвать человекаПрерывание с сохранением состоянияЯвная модель состояния и точки сохранения, а не линейный сценарий
Предъявить доказательства работыСквозная трассировка шаговЧитаемый журнал решений, пригодный для разбора инцидента
Права доступа и инструментыРаздельные разрешения и шлюз к моделямПодключение инструментов по MCP, журнал обращений
Упаковать удачное в навыкиВерсионируемые модули с владельцемРеестр навыков, а не подсказки в личных чатах
Перенести обвязку на следующий процессПереносимость конфигурацииОткрытая лицензия и отсутствие привязки к поставщику модели
Дать людям место пробоватьВизуальная сборка сценарияОтдельный контур для экспериментов, изолированный от продуктива

Что открытые платформы закрывают, а что остаётся на вас

Даёт платформа

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

Не даёт никакая платформа

  • владельца процесса, который примет результат
  • критерий «сделано», согласованный до старта
  • знание исключений, которых нет в регламенте
  • решение, где агент обязан остановиться
  • интеграцию с вашими учётными системами и правами

Первые тридцать дней по этой схеме

  1. 01

    Неделя 1 · Отбор процесса

    Из списка кандидатов оставить один: повторяемый, с несколькими системами, передачей между людьми и результатом, который можно проверить.

  2. 02

    Неделя 1 · Замер до старта

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

  3. 03

    Неделя 2 · Должностная инструкция агента

    Записать триггер, результат, источники контекста, инструменты, права и точки остановки. Согласовать с ИБ до сборки, а не после.

  4. 04

    Неделя 2-3 · Сборка в своём контуре

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

  5. 05

    Неделя 3 · Прогон на реальных случаях

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

  6. 06

    Неделя 4 · Передача и перенос обвязки

    Научить power users менять правила, зафиксировать конфигурацию как переносимую заготовку для следующего процесса.

Первый шаг

Разобрать один процесс по этой схеме

30 минут

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

  • Повторяется ли процесс и как часто
  • Какие системы и передачи в нём участвуют
  • Кто примет результат со стороны бизнеса
  • Где агент обязан остановиться
Разобрать процесс

Что делаем мы

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

Условия и границы первой итерации собраны на странице разработки ИИ-агентов, выбор движка разобран в обзоре открытых платформ.

Источники

Дата проверки: 2026-09-16

Обсудить статью: Как внедрять ИИ-агентов в корпорации…

Укажите email или телефон, чтобы мы могли вам ответить.

Отправить через: