ИИ-агенты для бизнеса: какую задачу автоматизировать первой
Neaptide · 6 сентября 2026 г. · 9 мин чтения
Как выбрать задачу для ИИ-агента, провести пробный запуск и оценить затраты на проверку ответов. Учебный пример, калькулятор и журнал тестирования.
В этой статье

Для первого ИИ-агента выберите повторяющуюся задачу, для которой есть надёжные исходные данные, а сотрудник умеет проверить результат. Начать можно с черновиков ответов или сбора сведений. Во время пробного запуска измерьте, сколько времени остаётся на проверку и исправления: скорость самой модели ещё не показывает выгоду для бизнеса.
Рассмотрим учебную задачу: менеджер разбирает заявки на мастер-классы. В одном письме указаны дата и число гостей, в другом — только «хотим прийти командой». Данные из полей можно перенести обычной интеграцией. Для свободного текста сложнее определить, чего не хватает, найти условия и подготовить уточнение. Этот этап подходит для пробного внедрения ИИ.
Когда нужен агент, а когда достаточно обычной автоматизации
ИИ-агент — система, в которой модель может выбирать следующие шаги и использовать инструменты для выполнения задачи. До разработки уточните, насколько самостоятельной она должна быть. В заранее заданном сценарии, или workflow, шаги определены разработчиком; агент сам выбирает часть действий и источников. Такое различие описывает Anthropic.
| Задача | С чего начать |
|---|---|
| Перенести число гостей из поля формы в таблицу | Обычная интеграция: поля и правила известны |
| Выделить дату и число гостей из свободного текста, затем создать черновик | Заданный сценарий с вызовом модели и проверкой полей |
| Разобрать нестандартный запрос, выбрать источники, сопоставить условия и решить, нужно ли уточнение | Ограниченный агент с доступом к нужным источникам |
Прежде чем разрабатывать агента, проверьте, можно ли решить задачу формой, шаблоном ответа и обычной интеграцией. Сравнение с этим вариантом покажет, что именно добавляет ИИ. Сопоставления только с полностью ручной работой может быть недостаточно.
Как найти подходящую первую задачу
Возьмите несколько недавних обращений и попросите сотрудника показать, как он их обрабатывает. Отметьте, где он переносит данные, принимает решения и запрашивает недостающие сведения. По конкретным случаям легче выбрать задачу, чем по общей цели «автоматизировать продажи».
- Задача повторяется достаточно часто, чтобы собрать примеры и сравнить время выполнения.
- Есть актуальный источник сведений. Системе можно предоставить доступ только к необходимым данным.
- Сотрудник умеет проверять результат, не выполняя всю задачу заново.
- Ошибку можно исправить до отправки сообщения, списания денег или изменения записи.
- Назначен человек, который проверяет результат и разбирает случаи, с которыми система не справилась.
Если условия услуги разбросаны по пяти противоречивым документам, сначала приведите их в порядок. Модель не сможет надёжно определить утверждённый прайс, если это нигде не указано. Подготовка к пробному запуску иногда уже приносит пользу: появляется единый актуальный справочник и удобная форма заявки.
Пример: подготовка ответа на заявку в мастерскую
Продолжим пример с вымышленной мастерской Forma из предыдущей статьи. Ниже описан возможный процесс работы агента. Это учебный проект, а не внедрённая система; измерений на заявках клиентов здесь нет.

Система читает заявку и сопоставляет пожелания клиента с утверждёнными условиями. Если сведений хватает, она готовит черновик ответа со ссылкой на источник. Если даты нет — предлагает уточнить её. По одному расписанию нельзя определить свободные места: для этого нужен отдельный актуальный источник.
| Входные данные | Ожидаемое поведение | Что считать ошибкой |
|---|---|---|
| «Хотим прийти вшестером», даты нет | Подготовить вопрос о дате | Самостоятельно выбрать дату |
| Два документа с разной ценой, актуальный не определён | Передать противоречие ответственному | Взять удобную цену без объяснения |
| Запрос на группу больше разрешённой | Отметить исключение для менеджера | Пообещать размещение всей группы |
| Источник недоступен | Сообщить, каких данных не удалось получить | Подставить предполагаемые условия |
На этом этапе системе достаточно читать необходимые данные и сохранять отдельный черновик. Если позже разрешите отправку, сотрудник должен подтверждать конкретный текст и получателя. Также нужно проверить, что повторный запуск после сбоя не отправляет второе письмо без ведома сотрудника.
Как проверить агента до работы с реальными клиентами
- Сначала измерьте текущий процесс: время непосредственной работы, ожидание, исправления и результат. Ожидание ответа клиента и рабочие минуты сотрудника учитывайте отдельно.
- Соберите набор обычных случаев и исключений. Для каждого заранее запишите ожидаемый результат, допустимое уточнение и недопустимое действие.
- Часть примеров используйте для настройки, часть отложите для проверки. Не оценивайте систему только на обращениях, по которым только что исправляли её инструкции.
- Прогоните тестовые случаи без отправки сообщений клиентам. Сохраните версию модели, инструкции, результат и время проверки.
- Посчитайте результат по всем попыткам. Неудачный ответ с последующей ручной обработкой тоже входит в затраты.
- Решите, что делать дальше: расширить пилот, сузить задачу, исправить источник данных или остановить работу.
Одного процента правильных ответов недостаточно. Ошибка в имени и выдуманная цена имеют разные последствия. Отдельно записывайте неверные условия, пропущенные уточнения и действия без разрешения. Для редких, но важных ошибок подготовьте специальные тесты: если ошибка не встретилась в небольшой выборке, это ещё не доказывает, что она невозможна.
До проверки определите условия продолжения проекта. Например: каждый черновик просматривает сотрудник, неподтверждённые цены не попадают к клиенту, время ручной работы сокращается, необработанные исключения не накапливаются. Допустимое время и число исправлений выберите по своей задаче. Единого процента успешности или обязательного числа тестов для всех проектов нет.
Как посчитать пользу с учётом проверки человеком
Для учебного расчёта возьмём 300 подходящих обращений в месяц. Ручная обработка каждого занимает 12 минут. Предположим, после внедрения на проверку, исправления и полную ручную обработку неудачных ответов в среднем уходит 5 минут на попытку. Эти числа заданы для примера и не являются измерением качества модели.
Высвобожденное время: 300 × (12 − 5) / 60 = 35 часов в месяц.
Ценность времени: 35 × 30 € = 1 050 €.
За вычетом расходов: 1 050 − 250 = 800 € в месяц.
Условный срок возврата разовых затрат: 2 400 / 800 = 3 месяца.В расчёте 300 попыток относятся только к выбранной задаче, а не ко всем заявкам компании. Средние пять минут включают работу человека и с удачными, и с неудачными ответами. В 250 € входят расходы на модель, сервисы и сопровождение, не учтённые ранее. Разовые 2 400 € на подготовку и внедрение — вымышленная сумма, а не стоимость услуги Neaptide.
Освободившиеся 35 часов не означают, что на счёте компании появятся 1 050 €. Если сотрудник при той же зарплате займётся другой работой, вы получите время для дополнительных задач. О денежной экономии можно говорить, когда известны сократившиеся расходы. Рост выручки тоже нужно измерять отдельно.

| Минут ручной работы на попытку | Сколько часов освободилось за месяц | Стоимость времени за вычетом расходов в месяц |
|---|---|---|
| 5 | 35 | 800 € |
| 8 | 20 | 350 € |
| 11 | 5 | −100 € |
Если после внедрения на задачу остаётся 11 минут ручной работы, ежемесячные расходы превышают рассчитанную стоимость сэкономленного времени. Посмотрите, что задерживает проверку: неудобный формат, отсутствие ссылок или слишком широкий круг задач. После исправлений повторите замер. Покупка более дорогой модели сама по себе не решает эти проблемы.
Что подготовить для обсуждения с разработчиком
Кратко опишите задачу: кто её выполняет, какие данные получает, где проверяет факты и какой результат готовит. Укажите действия при нехватке сведений и то, что система не должна делать самостоятельно. Добавьте обезличенные примеры, текущие замеры времени и бюджет на пробный запуск. Это позволит оценить конкретную работу.
После изменения модели, инструкций или источников повторяйте контрольные тесты и измеряйте время исправлений. Цель первого запуска — получить данные для решения о продолжении. Если форма и шаблоны оказались удобнее агента, проверка помогла избежать ненужной разработки.