ИИ не заменяет обычную автоматизацию, а дополняет её в одном месте. Там, где процесс раньше останавливался, потому что кому-то надо было прочитать письмо, разобрать документ или понять, чего хочет клиент. Всё остальное дешевле и надёжнее автоматизировать привычными средствами: правилами, скриптами, интеграциями между системами.
Разница между двумя видами автоматизации в предсказуемости. Обычная на одинаковый вход даёт одинаковый выход, и сбой в ней видно сразу. Процесс с моделью может отработать успешно и при этом неправильно, выдав правдоподобный ответ, который никто не проверил. Отсюда всё остальное содержание страницы: где модель нужна, где она лишняя и как собрать процесс, который не разваливается через месяц после запуска.
Чем автоматизация с ИИ отличается от обычной
Автоматизацию процессов продают лет двадцать, последние годы под именем цифровой трансформации, и схема везде одна. Описали процесс, разложили на шаги, каждый шаг отдали программе. Работает это ровно до того места, где на входе оказывается человеческий текст: письмо в свободной форме, скан договора, сообщение в мессенджере с тремя вопросами сразу. Дальше классическая автоматизация останавливается и требует, чтобы кто-то живой привёл данные к нужному виду.
Языковая модель снимает именно это ограничение. Взамен она приносит свойство, которого у обычного кода нет. Ответ модели меняется от запуска к запуску, а на неудобных данных она отвечает уверенно и неверно.
| Параметр | Обычная автоматизация | Автоматизация с ИИ |
|---|---|---|
| Предсказуемость результата | Одинаковый вход всегда даёт одинаковый выход | Ответ меняется от запуска к запуску, часть расхождений безобидна, часть нет |
| Видимость ошибки | Процесс падает, в журнале видно, на каком шаге | Процесс завершается успешно, ошибку видит только тот, кто читает результат |
| Стоимость изменения | Меняется код, правка занимает часы или дни | Меняется формулировка задачи для модели, правка занимает минуты |
| Тестируемость | Условие закрывается автотестом, поломку ловят автоматически | Изменение промпта проверяют прогоном на наборе реальных примеров, гарантий это не даёт |
| Требования к данным | Нужен строгий формат, обязательные поля, справочники | Формат свободный, зато качество ответа держится на качестве ваших документов |
| Стоимость эксплуатации | Хостинг и редкие правки | Хостинг, оплата вызовов модели по объёму, разбор спорных случаев, чистка базы знаний |
Строка про видимость ошибки здесь главная. В обычной автоматизации сломанный процесс кричит: заявки не создаются, письма не уходят, кто-то приходит разбираться в тот же день. Процесс с моделью ошибается тихо. Заявка создана, поле заполнено, статус зелёный, а в поле лежит не то, что человек имел в виду, и заметят это через неделю, если заметят вообще.
Отсюда практическое следствие. Автоматизацию с ИИ бессмысленно принимать по критерию «на демонстрации работает». Судить о ней стоит по тому, как она ведёт себя на плохих данных и что делает, когда не справилась.
Где ИИ действительно нужен
Полезных мест меньше, чем следует из рекламы, и они узнаваемые.
Вход процесса - свободный текст
Письма, заявки с сайта, обращения в мессенджерах, документы от контрагентов в чужих шаблонах. Формально это данные, фактически текст, который человек написал так, как ему было удобно.
Обычная автоматизация решает это формой ввода. Её стандартный ответ - заставить человека заполнить поля: выбери тему из списка, укажи номер договора, приложи файл в PDF. Иногда это правильное решение, оно дешевле любой модели. Но если на другом конце клиент, а не сотрудник, форму он не заполнит, а уйдёт к тем, кому можно написать словами.
Модель разбирает такой текст и превращает его в поля: тема, срочность, номер договора, что именно просят. Дальше начинается обычная автоматизация, которая эти поля умеет обрабатывать двадцать лет.
Нужно понять смысл, а не формат
Второй случай - когда правило описывается словами, но не описывается условием. Разложить обращения по десятку тем, половина из которых сформулирована на языке клиента. Достать сумму и срок из договоров, у каждого из которых своя вёрстка. Найти в накопленных документах ответ на вопрос, заданный другими словами, чем написано в документе.
Последнее - самый частый запрос по внутренним базам, и работает он так. Сначала обычный поиск находит подходящие куски документов, потом модель формулирует ответ по ним, а не по своей памяти. Приём называется генерацией с дополненной выборкой, в разговоре чаще RAG. Ценность в том, что ответ можно проверить: рядом с ним стоит источник, из которого он собран.
Разбор входящих документов, где к смыслу добавляются маршруты согласования и сроки хранения, тянет на отдельную тему. Автоматизация документооборота с ИИ будет разобрана отдельным материалом.
Исключений больше, чем правил
Третий признак сложнее и важнее. Бывают процессы, где правил формально много, а каждый второй случай оказывается исключением. Отдел пишет регламент на сорок страниц, но половину обращений всё равно разбирают руками, потому что в регламент они не попали.
Правильная сборка тут такая. Предсказуемые случаи прогоняются правилами и закрывают основной поток дёшево, без единого обращения к модели. Модель забирает остаток, который через правила не прошёл. Она работает обработчиком исключений, а не механизмом по умолчанию, и в эксплуатации это заметно дешевле: платите за хвост, а не за весь объём.
Где ИИ не нужен
В отраслевом обсуждении подрядчик описывал клиента, у которого языковая модель проверяла адреса электронной почты на корректность. Вся проверка сводилась к тому, есть ли в строке символ собачки. Обычный код делает это одной строкой, мгновенно и бесплатно, а вокруг модели был выстроен конвейер с оплатой за каждый вызов.
История смешная, но ошибка в ней типовая: модель ставят туда, где задача решается условием в коде. Стоит это денег на каждом запросе, работает медленнее и, в отличие от условия, иногда промахивается.
Три признака, что задача решается без ИИ. Правило формулируется одной фразой без слова «примерно». Вход всегда одинаковой структуры. Цена ошибки высокая, а объём маленький, поэтому автоматизация не окупится в принципе.
| Признак задачи | Что делать |
|---|---|
| Правило формулируется одной фразой без слова «примерно» | Обычный код, модель избыточна |
| Вход всегда одной структуры, поля на своих местах | Обычный код |
| Цена ошибки высокая, объём маленький | Оставить человеку, автоматизация не окупится |
| На входе текст в свободной форме, написанный людьми | Модель разбирает вход, дальше обычные правила |
| Правил много, но половина случаев в них не попадает | Правила на основной поток, модель на остаток |
| Ответ нужно искать в накопленных документах | Модель с поиском по вашим документам и ссылкой на источник |
Отдельный аргумент за фильтр из обычных условий перед моделью - его можно тестировать. Условие в коде проверяется автотестом за секунду, и если кто-то его сломает, это видно в тот же день. Изменение формулировки в промпте так не поймать, приходится прогонять набор реальных примеров и сравнивать результаты глазами. Чем больше работы забирают правила, тем дешевле система обходится в сопровождении.
Как выглядит процесс, собранный правильно
Разница между демонстрацией и рабочей системой держится на четырёх вещах, и все они скучные.
Правила первыми, модель потом
Перед вызовом модели стоит фильтр из обычных условий. Он отсекает то, что решается точным совпадением, проверкой формата или поиском по ключу. В нормально собранном процессе таким способом закрывается заметная доля потока, и на неё не тратится ни рубля оплаты за вызовы.
Побочный эффект приятный. Модель получает более узкую задачу, а на узкой задаче она ошибается реже.
Проверяется состояние системы, а не отчёт
Самое частое место, где ломаются интеграции. Система отправила запрос в CRM, сервер ответил, что запрос принят, в журнале зелёная строка. А карточка не изменилась: сработало правило автоматизации, поле оказалось обязательным, у учётной записи не хватило прав.
Правильная схема - после действия перечитать состояние и сверить с ожидаемым. Стало ли поле таким, каким должно было стать. Ответ «принято» от чужого сервера говорит только о том, что запрос доехал.
Часть работы скучная и дорогая, поэтому её обычно пропускают. Из-за неё зелёный индикатор неделями скрывает, что половина заявок никуда не записалась.
Отказ уходит человеку, а не роняет процесс
У каждого шага описано поведение при сбое. Рабочая схема простая: три попытки с паузой, дальше задача уходит в очередь к человеку вместе с описанием того, что именно не получилось.
Важнее техники тут организация. У очереди есть хозяин по имени и выделенное время на разбор. Очередь без хозяина копится молча, и через месяц системой перестают пользоваться, потому что «она всё равно половину теряет».
Опасные действия недоступны по архитектуре
Запрет на опасное действие живёт в правах доступа и в коде, а не в инструкции для модели. Если система не должна писать клиентам, у неё нет ключей от почты. Если у операции есть дневной лимит, лимит записан в коде и не зависит от того, что модель себе решила.
Формулировка в промпте вида «никогда не отправляй сообщения без подтверждения» - это просьба, и модели её нарушают. Особенно когда в обрабатываемый текст кто-то намеренно вписал другую инструкцию.
Систему, которая сама выбирает следующий шаг в рамках выданных ей прав, принято называть интеллектуальным агентом. Права в этом словосочетании важнее сообразительности. Как устроен контроль целиком, от выданных доступов до снятия подтверждений, разобрано в материале про человека в контуре.
Инструментальная часть тут вторична: связывают всё это обычные средства автоматизации, от самописных скриптов до n8n. Если нужен технический разбор, есть отдельный гайд про установку n8n на свой сервер.
С чего начинать
Первый процесс выбирается по четырём признакам. Он повторяется каждый день или каждую неделю. Объём заметный, десятки случаев в месяц, а не два. Результат измерим до начала работ: время на один случай, доля обращений, закрытых без человека, число заявок, потерянных за неделю. И ошибка на нём не стоит критических денег.
До автоматизации полезно потратить неделю на наблюдение. Не на описание того, как процесс должен работать, а на фиксацию того, как он работает сейчас: кто что делает, куда уходит время, где случаи ждут. Неделя таких отметок обычно меняет представление о том, какое место узкое, и заодно даёт цифру, с которой потом сравнивают результат.
Разбор процессов и выбор первой задачи я делаю отдельной работой, она называется аудит процессов. Общая карта темы, от выбора задачи до эксплуатации, лежит в материале про внедрение ИИ в бизнес.
Что автоматизируют чаще всего
Документооборот. Входящие счета, акты, договоры от контрагентов в чужих шаблонах. Модель достаёт реквизиты, суммы и сроки, обычная автоматизация раскладывает документы по маршрутам согласования. Выигрыш растёт с объёмом: на десятке документов в месяц смысла нет, на нескольких сотнях он появляется.
Поддержка клиентов. Основная боль малого бизнеса звучит одинаково от компании к компании: каждый день отвечают на одни и те же вопросы. Часть таких вопросов закрывается точным совпадением и не требует модели вообще, остаток модель разбирает по вашим документам со ссылкой на источник. Первый месяц ответы уходят через человека, дальше подтверждение снимают там, где промахов не было. Что из первой линии поддержки клиентов закрывается коробочным сервисом, а что требует своей сборки, разобрано в отдельном материале.
Обработка заявок и работа с CRM. Заявка приходит текстом в любое время суток, разбирается на поля, попадает в карточку с контекстом по прошлым сделкам. Здесь же заполнение карточек после разговоров и черновики документов. Направление разобрано подробно в материале про ИИ в отделе продаж.
Подготовка коммерческих предложений и типовых писем. Черновик собирается по карточке клиента и шаблону компании, человек проверяет условия и отправляет. Условие работоспособности одно: актуальные цены лежат в системе, а не в файле у коммерческого директора.
Сколько это стоит и когда окупается
Пилот на одной задаче в 2026 году стоит от 150 000 ₽. Это фиксированная цена, две-четыре недели, работающий результат или обоснованный отказ от идеи. Полный цикл, когда процесс собирают целиком с интеграциями, это внедрение под ключ от 450 000 ₽. Пилот засчитывается в стоимость внедрения полностью, если внедрение начинается по его итогам и по той же задаче.
Дальше идёт эксплуатация, и вот её обычно не считают. По публичным разборам рынка первый год добавляет 30-50% к стоимости разработки: вызовы модели по объёму, хостинг, разбор сбоев, доработки под изменившийся процесс, обучение новых сотрудников. Разбор по статьям есть на странице про то, сколько стоит внедрение, и в материале про расходы после запуска.
Окупаемость считают на своих числах, а не на чужих процентах из рекламных материалов. Сколько времени уходит на один случай сейчас, сколько будет уходить с учётом проверки результата, сколько таких случаев в месяц. При десятке случаев в месяц не окупится ничего, каким бы удачным ни было внедрение. Как собрать такой расчёт, разобрано в материале про окупаемость внедрения.
Что ломается со временем
Стоимость постройки за последние два года упала, стоимость плохой эксплуатации осталась прежней. Ломается предсказуемо, всегда в трёх местах.
База знаний зарастает. Документы копятся, старые версии никто не удаляет, и модель начинает честно отвечать по инструкции трёхлетней давности. Лечится регулярной чисткой, у которой есть ответственный и место в календаре.
Правила устаревают. Ограничения, написанные под старую модель или под прежний процесс, остаются в системе мёртвым грузом и иногда мешают работе. В одном публичном разборе автор выбросил около 60% накопленных им правил против галлюцинаций: модель к тому моменту уже отвечала по переданным данным, и правила ничего не чинили.
Процесс уезжает. Через полгода компания работает иначе: добавился канал, поменялся регламент, ушёл человек, который вручную закрывал редкие случаи. Система об этом не узнает и продолжит работать по старой схеме, пока кто-нибудь не заметит расхождение.
Частые вопросы
Чем автоматизация с ИИ отличается от обычной?
Предсказуемостью результата и тем, как видно ошибку. Обычная автоматизация на одинаковый вход всегда даёт одинаковый выход, а при сбое падает заметно, и чинить его идут в тот же день. Процесс с моделью может завершиться успешно и при этом дать неверный результат, поэтому в нём появляются вещи, которых в обычной автоматизации нет: проверка состояния системы после каждого действия, очередь для случаев, где модель не справилась, и человек, который эту очередь разбирает.
Нужна ли BPM-система, чтобы внедрять ИИ?
Нет. BPM-система - удобный способ описать и запустить процесс, но ИИ подключается к тому, что у вас уже есть: к CRM, почте, таблицам, мессенджеру. Если процесс живёт в amoCRM и переписке, автоматизировать можно прямо там. Покупка платформы до того, как выбран первый процесс, обычно кончается тем, что платформа есть, а обращения всё так же разбирают руками.
Можно ли автоматизировать процесс, который не описан?
Начать можно, закончить без описания нельзя. На практике описание получается по ходу: неделя наблюдения за тем, как процесс идёт сейчас, даёт схему точнее любого регламента, потому что в регламенте написано, как должно быть. Считайте это частью работы, а не предварительным условием. Занимает несколько дней и пригодится в любом случае, даже если автоматизацию потом отменят.
Что делать, если процесс постоянно меняется?
Смотреть, что именно меняется. Если меняются формулировки и частные случаи, модель это переживёт легче обычного кода: её задача описана словами, а слова правятся за минуты. Если меняется структура, то есть появляются новые шаги, каналы и ответственные, переделывать придётся всё, независимо от инструмента. И отдельно стоит спросить, почему процесс перекраивают каждый месяц. Иногда дешевле привести в порядок сам процесс, чем автоматизировать схему, которая не устоялась.
Сколько процессов можно автоматизировать сразу?
Один. Причина не в осторожности, а в наблюдении: длинная цепочка автоматических шагов разваливается быстрее, чем кажется, и чем больше шагов, тем дороже понять, где именно сломалось. Один процесс доводится до рабочего состояния за две-четыре недели, даёт понятный замер и показывает, где узкое место находится на самом деле. Второй берут после того, как первый отработал месяц.
Что дальше
- Внедрение ИИ в бизнес - карта темы целиком: этапы, сроки, что происходит после запуска.
- Человек в контуре - четыре уровня контроля и как проверить, что подрядчик их выстраивает.
- Аудит процессов - как выглядит разбор процессов и выбор первой задачи.
- Сколько стоит внедрение - вилки, из чего складывается сумма, как считать свой случай.
- Расходы после запуска - статьи эксплуатации, которых нет в коммерческом предложении.
- Окупаемость внедрения - как посчитать возврат на своих цифрах.
- ИИ в отделе продаж - самое частое прикладное направление, разобранное по шагам.
- Установка n8n на свой сервер - технический разбор для тех, кто собирает сам.
Если нужно понять, какой процесс у вас брать первым и стоит ли вообще ставить туда модель, это разбирается за тридцать минут по видео. Смотрим процесс, я говорю, где ИИ даст результат, а где хватит обычной автоматизации.
Написать можно в Telegram или на почту hi@za-ai.ru.