1. Ищите не «AI-задачу», а дорогую повторяемость.

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

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

2. До пилота определите, что будет считаться эффектом.

Необязательно начинать с сложного ROI. Для первого этапа достаточно 2–3 метрик: минут на одну операцию, количество операций в месяц, доля ошибок, время ответа клиенту, число ручных касаний или стоимость работы сотрудника.

Пример: если менеджер тратит 12 минут на первичный разбор заявки, а заявок 400 в месяц, процесс потребляет около 80 часов. Это уже измеримая база для пилота.

3. AI нужен только там, где жёстких правил недостаточно.

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

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

4. Пилот должен проверять один риск.

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

Пилот должен быть достаточно маленьким, чтобы его можно было выбросить без боли, и достаточно реальным, чтобы он работал на настоящих данных.

5. Продакшн начинается с исключений и контроля.

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

Поэтому процесс проектируется как связка AI + правила + человек в контрольной точке, а не как автономный бот любой ценой.

6. Что прислать для первого разбора.

  • что сейчас происходит по шагам;
  • кто делает работу вручную;
  • пример входных данных;
  • какой результат нужен на выходе;
  • примерный объём операций в неделю или месяц;
  • какая ошибка считается критичной.
Двух-трёх абзацев обычно достаточно. Если процесс нельзя описать коротко, это уже полезный сигнал для аудита.
GUTSU / AIОбсудить автоматизацию →TELEGRAMПрактические AI-разборы →