Автоматизация с помощью ИИ: какие процессы ему поручать, а какие — правилам

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

Я бы развернул этот порядок.

Сначала нужно понять, где сотрудник выполняет понятное правило, а где действительно интерпретирует текст, документ или ситуацию. Если весь маршрут можно описать условиями, ИИ, скорее всего, не нужен. Если неоднозначность появляется в одном-двух местах, не нужен и «автономный цифровой сотрудник». Достаточно встроить модель в обычный workflow и ограничить её конкретной задачей.

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

Главная ошибка — пытаться автоматизировать процесс одним инструментом

Бизнес-процесс почти никогда не состоит из операций одного типа.

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

Часть этих действий однозначна:

• электронная почта должна соответствовать формату;
• новый лид нужно проверить на дубли;
• заявки из конкретного региона передаются определённой группе;
• при ошибке CRM запрос нужно повторить;
• после нескольких неудачных попыток ответственному отправляется уведомление.

Здесь не нужна языковая модель. Нужны правила, интеграции и журнал выполнения.

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

Вот где ИИ для автоматизации действительно полезен.

Не во всём процессе. На одном его участке.

Разделите операции на пять типов

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

Тип операции	Пример	Рациональный подход
Известное правило	проверить поле, рассчитать сумму, выбрать маршрут по региону	код, условие или обычный workflow
Интерпретация	определить тему письма, выделить потребность, сделать краткое резюме	отдельный ИИ-шаг
Работа со знаниями	ответить по регламенту, инструкции или базе документов	RAG с указанием источников
Открытая многошаговая задача	самостоятельно выбрать последовательность инструментов	ограниченный ИИ-агент
Критическое решение	платёж, договор, изменение прав, публикация данных	правила и подтверждение человека

Workflow здесь — это заранее заданная последовательность действий и проверок. RAG — получение ответа с предварительным поиском по корпоративным документам. Human-in-the-loop — точка процесса, в которой человек проверяет результат или подтверждает действие.

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

Технически это возможно. Поддерживать такую систему будет тяжело.

В руководстве по автоматизации процессов с помощью ИИ команда n8n рекомендует сначала строить детерминированную часть, а модель добавлять только туда, где без интерпретации не обойтись.[1]

Условный пример: как обработать B2B-заявку без «агента на всё»

Представим компанию, которая получает заявки с сайта, почты и из Telegram. Сейчас сотрудники вручную читают сообщения, восстанавливают недостающие данные и создают сделки в CRM.

Рациональная схема может выглядеть так.

1. Система сохраняет исходное обращение

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

2. Обычная логика очищает и проверяет данные

Система нормализует телефон и почту, ищет дубли, проверяет обязательные поля. Если контактные данные явно некорректны, заявка не уходит в модель — сначала нужно запросить исправление.

3. ИИ решает одну задачу

Модель получает очищенный текст и возвращает структуру, например:

{
  "request_type": "автоматизация обработки заявок",
  "company": "ООО Пример",
  "urgency": "обычная",
  "missing_data": ["текущая CRM"],
  "summary": "Компания хочет сократить ручной разбор входящих обращений"
}

Здесь модель не назначает менеджера и не меняет статус сделки. Она только переводит свободный текст в рабочие поля.

4. Результат проходит проверку

Система сверяет структуру ответа, допустимые категории и обязательные поля. Неизвестный тип заявки или противоречие в данных ведут не к «лучшей догадке», а в очередь ручной проверки.

5. Правила продолжают процесс

После проверки обычный workflow создаёт сделку, выбирает ответственного и ставит задачу менеджеру. Если CRM временно недоступна, система повторяет запрос и фиксирует ошибку.

Получается не эффектная демонстрация агента, а понятный рабочий контур:

канал → сохранение исходных данных → проверка → ИИ-анализ → валидация → бизнес-правила → CRM → журнал

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

Когда ИИ не нужен

Есть простой критерий: если действие можно однозначно описать и проверить обычным кодом, начинать с модели не стоит.

Расчёты и лимиты. Скидки, налоги, остатки, сроки, квоты и финансовые формулы должны считать учётная система или код. Модель может объяснить результат человеку, но не должна придумывать сам расчёт.

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

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

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

Позиция простая: ИИ должен работать с неопределённостью, а не создавать её там, где раньше всё было однозначно.

Агент — не стартовая точка

Термин «агент» часто используют для любой автоматизации с языковой моделью. Архитектурно разница существенна.

В workflow путь задан заранее. Агент сам выбирает, какие инструменты вызвать и каким будет следующий шаг. Anthropic рекомендует начинать с самого простого решения и увеличивать сложность только тогда, когда это действительно улучшает выполнение задачи. Для хорошо определённых процессов workflow даёт больше предсказуемости, а агент оправдан там, где нужен меняющийся план и модель должна принимать промежуточные решения.[2] Microsoft также описывает workflow как управляемый контур с явным порядком выполнения, состоянием и точками участия человека.[3]

Для малого и среднего бизнеса внедрение ИИ в бизнес-процессы лучше начинать не с агента, а с понятного workflow:

• если маршрут можно нарисовать блок-схемой, сначала собирайте workflow;
• если меняется только понимание входящего текста, добавьте один ИИ-шаг;
• если нужен ответ по документам, добавьте поиск по базе знаний;
• к агенту переходите, когда заранее невозможно определить последовательность действий.

И даже тогда инструменты агента нужно ограничить. Одно дело — найти информацию и подготовить черновик. Другое — менять данные клиентов или инициировать оплату.

Пилот должен проверять процесс, а не впечатлять демонстрацией

ИИ для автоматизации процессов стоит сначала проверить на одной операции, а не на всём контуре. Например:

• определить тему обращения;
• извлечь реквизиты из письма;
• подготовить резюме заявки;
• найти ответ в базе знаний;
• предложить черновик сообщения сотруднику.

Не стоит в первой версии одновременно подключать все каналы, давать модели право менять CRM и строить сложную агентную логику. Иначе при ошибке будет непонятно, что именно не работает.

1. Зафиксируйте исходное состояние. До разработки измерьте, сколько времени занимает операция сейчас, сколько раз сотрудник возвращается к заявке, какие ошибки встречаются и где образуется очередь. Без исходной точки любое улучшение будет выглядеть убедительно — просто потому, что появилось новое приложение.
2. Соберите реальные примеры. Для теста нужны разные заявки: неполные сообщения, опечатки, две задачи в одном письме, противоречивые данные и случаи, которые обязан разбирать человек.
3. Определите ожидаемый результат. Для классификации нужен список допустимых категорий. Для извлечения — обязательные поля. Для ответа по документам — правило, по которому система признаёт, что подтверждённой информации нет.
4. Запустите в режиме подсказки. Пусть система предлагает результат, а сотрудник его подтверждает. Так можно собрать ошибки, не передавая модели критические действия.
5. Измеряйте качество после запуска. ИИ-процесс может продолжать технически работать, но постепенно хуже решать задачу. Меняются входящие запросы, документы, модель или продуктовые правила. Поэтому одной приёмки недостаточно: качество нужно проверять на рабочих данных и отслеживать после запуска.[4]

Что измерять

Набор метрик зависит от процесса, но обычно нужны три группы.

Процесс:

• время обработки;
• количество ручных действий;
• размер очереди;
• доля возвратов на доработку.

Качество ИИ-шага:

• правильность категории;
• полнота извлечённых полей;
• доля ответов с подтверждённым источником;
• количество случаев, переданных человеку.

Эксплуатация:

• стоимость одной операции;
• задержка;
• ошибки API и повторные попытки;
• доля ответов, не прошедших валидацию.

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

Без журналов пилот превращается в спор мнений

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

Поэтому нужно сохранять как минимум:

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

Microsoft отдельно отмечает, что для ИИ-систем обычных метрик доступности и числа ошибок недостаточно. Нужны данные о контексте, источниках, вызовах инструментов и качестве результата.[5]

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

С чего начать

Внедрение ИИ в бизнес не стоит начинать с выбора модели.

Возьмите один процесс и разложите его по шагам: кто действует, какие данные получает, какое решение принимает, что может пойти не так и как проверить результат. После этого пометьте:

• где достаточно правила;
• где нужна интерпретация;
• где требуется поиск по документам;
• где решение должен подтвердить человек;
• где вообще есть основания для агента.

После такого разбора становится понятно, где ИИ в бизнес-процессах действительно нужен, а где архитектуру можно сделать проще. И дешевле.

Если вы рассматриваете автоматизацию бизнеса с помощью ИИ, сначала стоит описать повторяющиеся операции, данные и ошибки. На аудите бизнес-процессов можно проверить, нужен ли здесь ИИ, обычная автоматизация или изменение самого процесса, а затем определить границы первого пилота. Общий подход к таким решениям описан на странице ИИ и автоматизация бизнес-процессов.

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

Какие процессы подходят для автоматизации с помощью ИИ?

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

Можно ли автоматизировать бизнес без ИИ?

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

Когда нужен RAG?

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

Когда оправдан ИИ-агент?

Когда задача многошаговая, путь заранее неизвестен и модель должна выбирать инструменты по промежуточным результатам. Для фиксированного маршрута агент обычно добавляет лишнюю стоимость и сложность.

Нужно ли оставлять человека в процессе?

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

Источники

1. Production AI Playbook: Deterministic Steps & AI Steps — Elvis Saravia и команда n8n, 2 апреля 2026 года.
2. Building effective agents — Anthropic, 19 декабря 2024 года.
3. Microsoft Agent Framework Workflows — Microsoft Learn, обновлено 29 апреля 2026 года.
4. Production AI Playbook: Evaluation and Monitoring — команда n8n и Elvis Saravia, 5 мая 2026 года.
5. Observability for Generative AI and agentic AI systems — Microsoft Learn, обновлено 17 марта 2026 года.