«Нужен ИИ-сотрудник для отдела продаж» — не задача, а пожелание. Из него непонятно, что получит система на входе, что ей разрешено делать и кто заметит ошибку. Рабочая постановка звучит иначе: «Разобрать входящее письмо, найти сведения в разрешённых источниках, подготовить черновик ответа и передать его менеджеру. Ничего не отправлять и не менять в CRM без человека».
Создание ИИ-сотрудников стоит начинать именно с такой узкой формулировки. Тогда пилот можно проверить на реальных примерах, а решение о продолжении принять по результатам, а не по впечатлению от эффектной демонстрации.
Выбирайте не должность, а одну операцию
Должность состоит из десятков разных действий: переговоров, поиска информации, согласований, работы с исключениями и ответственности за итог. Попытка автоматизировать всё сразу скрывает границы проекта и делает результат непроверяемым.
Для первого пилота лучше выбрать короткий рабочий эпизод с понятным началом и концом. Например: классифицировать обращение, собрать справку из внутренних документов, подготовить резюме встречи или заполнить черновик карточки. Важно, чтобы результат можно было проверить до того, как он повлияет на клиента, деньги или данные.
| Слишком широко | Пригодно для пилота |
|---|---|
| Автоматизировать поддержку | Определять тему письма и готовить черновик по утверждённой базе знаний |
| Заменить менеджера | Собирать данные по новой заявке и предлагать следующий шаг для проверки |
| Ускорить документооборот | Извлекать реквизиты из одного типа документов и отмечать пропуски |
Пять проверок перед разработкой
- Задача повторяется. Есть поток похожих случаев, а не единичная просьба раз в квартал.
- Входные данные доступны. Понятно, откуда брать письма, документы или записи и какие из них системе разрешено видеть.
- Результат можно проверить. Эксперт способен объяснить, что считать хорошим ответом, а что — ошибкой.
- Ошибка обратима. На первом этапе система готовит черновик или рекомендацию, а значимое действие остаётся за человеком.
- У процесса есть владелец. Кто-то отвечает за примеры, правила, разбор спорных случаев и решение по итогам пилота.
Если команда не может показать неправильный результат и назвать человека, который его проверит, задача к пилоту ещё не готова.
Пример: входящее обращение клиента
Возьмём типовой сценарий без привязки к конкретному проекту. Клиент присылает письмо, менеджер определяет тему, ищет сведения в базе знаний и готовит ответ. Повторяются не все письма, но часть маршрута можно описать и проверить.
| Шаг | Что делает система | Что остаётся человеку |
|---|---|---|
| Получение | Читает письмо и вложения в пределах выданных прав | Определяет правила доступа и хранения |
| Разбор | Предлагает тему и находит подходящие материалы | Проверяет спорные и чувствительные случаи |
| Результат | Готовит черновик со ссылками на источники | Редактирует и решает, отправлять ли ответ |
Граница здесь важнее самой модели: система не обещает клиенту сроки, не меняет данные в CRM и не отправляет письмо. Неясные обращения уходят менеджеру вместе с причиной остановки. Такой сценарий уже можно проверять: видны вход, результат, исключения и ответственное лицо.
Когда ИИ только усложнит решение
Не всякая автоматизация требует языковой модели. Если входные данные структурированы, а решение описывается однозначными правилами, обычный сценарий часто дешевле, стабильнее и проще в сопровождении.
- Не берите в пилот процесс, правила которого меняются от сотрудника к сотруднику.
- Не подключайте данные, для которых не определены права доступа и срок хранения.
- Не начинайте с действия, где одна ошибка сразу приводит к платёжной, юридической или репутационной проблеме.
- Не автоматизируйте редкую операцию, если подготовка интеграций будет дороже самой ручной работы.
- Не используйте ИИ там, где достаточно фильтра, шаблона или обычного бизнес-правила.
Отдельные варианты применения и границы решения собраны на странице «ИИ-сотрудники для бизнеса». Но выбор технологии имеет смысл только после разбора конкретного процесса.
Что подготовить к пилоту
- Схему текущей работы. Откуда приходит задача, кто её выполняет, какими системами пользуется и где возникает задержка.
- Набор реальных примеров. Нужны не только удобные случаи, но и короткие письма, противоречивые данные, нетипичные вложения и запросы вне темы.
- Разрешённые источники. Версии документов, базы знаний и поля систем, на которые можно опираться. Если источник устарел, ИИ аккуратно воспроизведёт устаревшую информацию.
- Матрицу полномочий. Что система читает, что может подготовить и какие действия ей запрещены.
- Правила передачи человеку. Недостаточно данных, конфликт источников, чувствительная тема и низкая уверенность должны приводить к остановке, а не к догадке.
Если сценарий требует поиска по корпоративным материалам, интеграции с CRM или нескольких последовательных действий, полезно заранее обсудить архитектуру. DYNAMICSUN занимается разработкой сервисов на базе LLM, но на старте важнее не название модели, а доступность данных и возможность проверить результат.
Как провести пилот без самообмана
Сначала измерьте текущий процесс. Сколько времени занимает операция, сколько исправлений требуется и где возникают ошибки? Затем прогоните на одинаковом наборе примеров текущий способ работы и новый сценарий. Условия проверки нельзя менять после того, как вы увидели результат.
| Что измерять | Как смотреть | Тревожный сигнал |
|---|---|---|
| Качество результата | Доля принятых, исправленных и отклонённых черновиков | Одна и та же ошибка повторяется |
| Работа проверяющего | Время на чтение, правку и поиск источника | Проверка занимает не меньше ручной подготовки |
| Исключения | Какие случаи переданы человеку и почему | Система уверенно отвечает там, где должна остановиться |
| Стабильность | Повторная проверка одинаковых и похожих случаев | Незначительная формулировка резко меняет итог |
Экономику считайте вместе с контролем человека, интеграциями и сопровождением, а не только со стоимостью запроса к модели. Для отдельного расчёта пригодится материал об оценке эффекта ИИ-сотрудника до запуска.
После пилота: масштабировать, сузить или остановить
Масштабировать
Качество проходит заранее заданный порог, проверка действительно экономит время, исключения корректно передаются человеку, а владельцу процесса понятны затраты на поддержку. Расширяйте полномочия по одному шагу и снова проверяйте риски.
Сузить задачу
Сценарий работает только для части обращений или одного типа документа. Это нормальный результат: оставьте устойчивый участок, а остальное направляйте человеку. Узкий рабочий инструмент полезнее широкого «умного» помощника, которому нельзя доверять.
Остановить
Если данные ненадёжны, проверка съедает выигрыш или цена ошибки остаётся неприемлемой, пилот выполнил свою работу: показал, куда пока не стоит инвестировать. Решение остановиться — не провал, если критерии были определены заранее.
Частые вопросы
Нужна ли сразу интеграция с CRM?
Не всегда. Первый тест можно провести на обезличенной выборке или в режиме подготовки черновика. Но такой тест не покажет качество реальной интеграции, права доступа и поведение при сбоях — их проверяют отдельно.
Какую модель выбрать?
После постановки задачи. Для одного сценария важнее точность на внутренних примерах, для другого — скорость, размещение в нужном контуре или стоимость. Сравнивать модели нужно на одинаковом наборе реальных случаев.
Когда можно убрать ручную проверку?
Не по календарю и не после удачной демонстрации. Это отдельное решение: нужны данные о качестве на нужном потоке, понятная цена ошибки, журнал действий и надёжная передача исключений человеку.
С чего начать разговор с подрядчиком?
Принесите схему одной операции, несколько обычных и сложных примеров, список источников и ограничения по действиям. Этого достаточно, чтобы обсуждать границы пилота предметно, а не выбирать технологию в отрыве от процесса.
Есть процесс-кандидат?
Опишите одну операцию, входные данные и цену ошибки. На встрече разберём границы сценария, требования к интеграциям и способ проверки результата до начала разработки.
Обсудить задачу
