Когда достаточно готового AI-ассистента, а когда нужна разработка

Выбирайте способ выполнения процесса

В этой статье ассистент помогает сотруднику получить ответ или подготовить результат, а агент может также вызывать инструменты и выполнять действия. Это рабочее различие, а не строгие категории продуктов: готовая платформа тоже может быть агентной, а заказная система — только готовить черновики.

Рекомендация Dev Crabs: опишите одну задачу в формате «получить вход → проверить условия → подготовить результат → согласовать → выполнить действие». Отметьте, где достаточно текста, где нужен доступ к данным, а где меняется состояние другой системы. Сравнивайте варианты на этой цепочке.

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

Что показывает внедрение в Uber

Факт из первоисточника: 22 октября 2026 года OpenAI сообщила о начале расширения ChatGPT Work в Uber после пилота. В сообщении названы внутренняя библиотека навыков, согласованные интеграции и обучение сотрудников. Источник перепроверен 30 октября.

Это сообщение вендора о rollout, а не подтверждение завершённого внедрения у всех сотрудников. Сопоставимых показателей окупаемости публикация не приводит: измеримые результаты обещают раскрывать по мере внедрения. Это опыт другой компании; Dev Crabs не приписывает себе участие в нём.

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

До выбора продукта проверьте доступность для вашей страны и организации, договорные условия и нужные функции. Например, OpenAI публикует отдельный список поддерживаемых стран ChatGPT; по проверке 30.10.2026 Россия в нём не указана. Упоминание ChatGPT Work здесь — контекст новости, а не рекомендация подключить его российской компании.

Три формата: продукт, настройка, свой процесс

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

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

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

Дерево выбора по рабочей задаче

1. Нужен только ответ или черновик? Проверьте готовый инструмент на разрешённых примерах. Если он даёт приемлемый результат, а ручной перенос устраивает процесс, отдельный агент может не понадобиться.
2. Нужны внутренние документы? Проверьте актуальность источников и разграничение доступа. Если это настраивается штатно — продолжайте пилот продукта. Если нет — оцените подключение данных или отдельный поиск.
3. Нужно менять данные в системе? Уточните, есть ли нужная операция в API или штатном подключении. Наличие логотипа CRM в каталоге не подтверждает поддержку конкретного поля, роли и действия.
4. Есть несколько шагов и согласование? Проверьте хранение состояния, подтверждение человеком, защиту от повторного выполнения и восстановление после частичного сбоя. Если платформа позволяет это настроить — сравните настройку с разработкой.
5. Обязательное требование не выполняется? Исключите вариант или сузьте задачу. Не компенсируйте недопустимую передачу данных удобным интерфейсом. Для оставшихся вариантов проведите одинаковую приёмку.
6. Кто будет отвечать после запуска? Если нет владельца процесса и поддержки, ограничьте первый этап черновиками и ручным подтверждением. Автономное выполнение требует отдельного решения об ответственности.

Результат выбора: «берём этот формат для этой задачи, потому что он прошёл такие-то проверки; возвращаемся к выбору при таких-то изменениях». Условия пересмотра — новая система, изменение правил обработки данных, неприемлемое качество или стоимость — запишите заранее.

Три учебных сценария

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

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

Что включить в первый пилот

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

• Один процесс и одинаковые примеры. Подготовьте типовые случаи, неполные данные, противоречивые документы и ошибки внешней системы. Отделите примеры настройки от контрольных.
• Эталон и критерий. Для ответа — корректность и источник; для черновика — поля; для действия — точное изменение нужного объекта. Заранее определите, какие ошибки блокируют выпуск.
• Проверка границ. Испытайте чужую роль, отозванный доступ, повторный запуск, тайм-аут и отмену согласования. Инструкции внутри входного документа не должны расширять права агента.
• Ручной труд и расходы. Считайте время проверки, исправления, полные передачи человеку и все вызовы сервисов. Успешный ответ после длинной ручной доработки не равен автоматизации процесса.
• Решение после пилота. Запишите: внедрять, доработать и повторить приёмку, сменить формат или оставить задачу человеку. Сохраните версии настроек и контрольный набор.

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

Стоимость и цена смены решения

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

Полная стоимость = внедрение + лицензии и вызовы + инфраструктура + сопровождение + проверка качества + ручная обработка + переход на другое решение.

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

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

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

Вопросы поставщику и подрядчику

1. Покажите весь сценарий на нашем обезличенном примере. Какие шаги выполняет продукт, какие — человек, какие ещё нужно разработать?
2. Какие операции доступны в нужных системах и от чьего имени они выполняются? Что произойдёт после отзыва доступа?
3. Где окажутся входные данные, результаты и журналы? Какие условия действуют для каждого внешнего сервиса?
4. Как проверить подтверждение, повторное выполнение и частичный сбой? Кто увидит проблему и сможет продолжить процесс?
5. Как фиксируются качество и расходы? Что нужно проверить после обновления модели, инструкции или подключения?
6. Кому принадлежат настройки и код, что можно выгрузить и как передать обслуживание другой команде?
7. Какие результаты пилота будут означать отказ от внедрения? Кто принимает это решение?

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

Частые вопросы