ИИ нужен не потому, что в процессе много ручной работы, а потому что результат зависит от понимания неструктурированных данных, вариативного контекста или вероятностного решения.
Начните не с модели, а с потери
Зафиксируйте конкретную потерю: время ответа, ошибки, пропущенные заявки, нагрузку на специалистов, стоимость обработки или невозможность масштабировать качество.
Формулировка «хотим внедрить ИИ» не является задачей. Рабочая формулировка звучит так: «менеджеры тратят 18 часов в неделю на классификацию обращений, а 12% заявок попадают не в тот отдел».
- Какой результат ухудшается?
- Где именно возникает задержка или ошибка?
- Как потеря измеряется сейчас?
Когда достаточно обычной автоматизации
Если правила можно однозначно записать в виде «если — то», данные уже структурированы, а задача сводится к переносу полей, уведомлениям, статусам или синхронизации систем, LLM обычно не нужна.
В таких сценариях надёжнее рабочий процесс, API-интеграция, настройка CRM, RPA или небольшая серверная функция. Это дешевле, предсказуемее и проще проверяется.
- Перенос данных между CRM и таблицей
- Назначение ответственного по фиксированным правилам
- Контроль обязательных полей и сроков
- Регулярные уведомления и отчёты
Когда ИИ действительно полезен
ИИ оправдан, когда входные данные неструктурированы, формулировки различаются, требуется извлекать смысл, сравнивать документы, распознавать речь, искать по базе знаний или подготавливать ответ с учётом контекста.
Даже в этом случае модель должна работать внутри управляемого контура: с ограниченными источниками, проверками, журналом действий и понятным способом передать сложный случай человеку.
- Классификация свободных обращений
- Извлечение фактов из документов
- Поиск ответа по корпоративной базе знаний
- Обработка звонков и диалогов
- Подготовка черновика с обязательной проверкой
Пять критериев готовности
Процесс должен иметь владельца, понятную точку начала и окончания, доступные примеры данных, измеримую базовую метрику и допустимый уровень ошибки.
Если хотя бы двух элементов нет, разумнее сначала провести короткий аудит, а не начинать разработку.
- Владелец процесса
- Данные и примеры
- Базовая метрика
- Цена ошибки
- План действий при сбое
Итоговое решение
Выбор технологии должен сравнивать минимум три варианта: исправление процесса, обычную автоматизацию и ИИ-компонент. В пилот идёт не самый эффектный, а самый проверяемый вариант.