В некоторые процессы действительно стоит встраивать искусственный интеллект. В других достаточно обычной интеграции, набора правил или программного робота. Проблемы начинаются, когда компания сначала решает внедрить ИИ, а уже потом ищет ему работу.
За последние месяцы я много раз слышал примерно одну и ту же постановку задачи: «Мы хотим внедрить ИИ в этот процесс».
Начинаешь разбираться, а процесс выглядит так. Сотрудник получает заявку, проверяет три поля, сравнивает сумму с лимитом и направляет документ одному из двух согласующих. Никакой неопределённости. Никакого анализа смысла. Четыре понятных шага и ни одного оценочного суждения.
Для такой задачи искусственный интеллект не нужен. Более того, он может сделать решение дороже, сложнее и менее предсказуемым.
Автоматизация не обязательно означает ИИ
Сегодня искусственным интеллектом называют почти всё: от простого чат-бота до системы обработки документов. Из-за этого возникает ощущение, что без большой языковой модели уже невозможно автоматизировать даже согласование счёта.
Но ИИ — лишь один из инструментов автоматизации.
Бизнес-процесс можно автоматизировать с помощью:
- специально разработанного модуля (с экранными формами для пользователя или без них);
- уже готовой системы, заточенной под этот бизнес-процесс;
- интеграции между информационными системами;
- скрипта или набора бизнес-правил;
- BPM-системы — системы управления бизнес-процессами: она ведёт заявку по этапам, назначает ответственных и следит за сроками;
- программного робота RPA (robotic process automation) — он повторяет действия человека в интерфейсах систем по заданным правилам;
- ИИ-компонента;
- сочетания нескольких этих технологий.
IBM включает в набор технологий автоматизации бизнес-процессов RPA, оркестрацию рабочих потоков, BPM, искусственный интеллект и облачные платформы. ИИ здесь не заменяет остальные инструменты, а занимает своё место среди них.
В хорошем проекте вопрос звучит не «как внедрить сюда ИИ», а «какой инструмент лучше решит эту задачу». Разница не косметическая: она определяет стоимость владения, требования к тестированию и то, как вы объясните результат проверяющему.
Классическая программа получает определённые данные, применяет заданные правила и выдаёт ожидаемый результат. Например, если сумма меньше миллиона рублей, заявка сразу направляется финансовому директору. Если больше — сначала согласовывается с руководителем подразделения и только потом отправляется финансовому директору. При одинаковых данных результат будет одинаковым.
Генеративная модель работает иначе: она интерпретирует входные данные и формирует вероятностный ответ. Это полезно, когда нужно понять смысл письма, разобрать нестандартный документ или подготовить ответ клиенту. Но для проверки лимита такая свобода не помогает.
Наоборот, появляется новый вопрос: как убедиться, что модель не решила истолковать простое правило по-своему?
Когда достаточно обычной автоматизации
Представим несколько рабочих задач.
Перенести сведения о новом контрагенте из одной системы в другую. Если у систем есть API, задачу решает интеграция. Если API нет, но сотрудник каждый раз выполняет одинаковые действия в интерфейсе, можно рассмотреть RPA или разработать специализированный модуль. Microsoft описывает desktop flows в Power Automate как развитие возможностей RPA для повторяющихся задач, выполняемых по правилам.
Провести заявку по нескольким этапам согласования, назначить ответственных и проконтролировать сроки. Здесь естественно выглядит BPM-система или система документооборота.
Рассчитать неустойку по известной формуле. Подойдёт обычный программный модуль.
Синхронизировать статусы перевозки между TMS (системой управления перевозками) и 1С. Нужна интеграция.
Распределить обращения по филиалам на основании региона, продукта и суммы. Если все признаки приходят в структурированном виде, достаточно таблицы решений — матрицы «условия → действие», которую бизнес-аналитик составляет и поддерживает без разработчика.
Добавление языковой модели в любой из этих сценариев не делает архитектуру современной. Оно просто добавляет ещё один компонент, который придётся размещать, защищать, тестировать, контролировать и поддерживать.
Стоит понимать, из чего складывается эта нагрузка. У ИИ-компонента появляются статьи затрат, которых нет у детерминированного модуля: вычислительные ресурсы на инференс, версионирование промптов, регресс-тесты на фиксированной выборке при каждом обновлении модели, мониторинг качества ответов, разбор инцидентов и — в регулируемых отраслях — объяснение принятого решения проверяющему. Всё это оправданно, когда модель делает работу, которую правилами не описать. И плохо окупается, когда она перекладывает данные из одного поля в другое.
Иногда это напоминает приглашение очень способного консультанта для перекладывания данных из одной таблицы в другую. Он, вероятно, справится. Но это не делает такой способ разумным.
Когда ИИ действительно оправдан
Граница проходит не между «старыми» и «новыми» технологиями. Она проходит между определённостью и необходимостью интерпретации.
ИИ становится полезен, когда процесс получает данные, которые трудно привести к единому формату.
Например, в транспортную компанию приходят накладные, акты, заявки и другие перевозочные документы. Они отличаются по форме, качеству сканирования, расположению полей и способу заполнения. Чтобы извлечь из них нужные сведения и сопоставить документы между собой, одних правил может оказаться недостаточно.
Другой пример — звонки в контакт-центр. Аудиозапись сначала нужно преобразовать в текст, затем определить тему разговора, найти признаки недовольства, проверить соблюдение сценария и подготовить краткое резюме. Здесь ИИ работает с речью и смыслом, которые нельзя исчерпывающе описать несколькими условиями.
Ещё один подходящий сценарий — входящие письма клиентов. Один человек напишет: «Хочу перенести дату доставки». Другой: «В четверг принять товар не сможем». Третий просто перешлёт длинную переписку. Намерение у них похожее, но формулировки разные.
ИИ может помочь:
- распознать и классифицировать неструктурированный документ;
- извлечь сведения из текста, изображения, видео или аудиозаписи;
- понять содержание обращения;
- сопоставить разные формулировки;
- подготовить резюме или проект ответа;
- найти релевантную информацию во внутренних знаниях.
Именно помочь, а не обязательно принять окончательное решение.
Отсюда и практический приём: ИИ-компонент возвращает не только извлечённые поля, но и оценку собственной уверенности. Всё, что ниже установленного порога, уходит человеку. Поток обрабатывается автоматически, а спорные случаи попадают туда, где их и должны разбирать.
Генеративные модели могут создавать убедительные, но неверные ответы. Профиль рисков генеративного ИИ NIST (NIST AI 600-1, июль 2024) выделяет конфабуляции — уверенно сформулированный ложный или ошибочный контент — отдельным классом рисков, раздел 2.2.
Поэтому ИИ-компонент обычно нужно окружать вполне классическими средствами: правилами, проверками, справочниками, интеграциями, журналом действий и контролем человека.
Получается не спор «ИИ против автоматизации», а рабочая комбинация. ИИ разбирает неструктурированные данные. Обычная программа проверяет обязательные поля и лимиты. BPM ведёт процесс по этапам. Человек разбирает исключения и принимает критичное решение.
Задача для правил или задача для ИИ
| Признак процесса | Обычная автоматизация | ИИ-компонент |
|---|---|---|
| Правила | описываются конечной таблицей условий | список исключений не заканчивается |
| Данные на входе | заполненные поля, справочники, фиксированные форматы | письма, сканы, речь, произвольный текст |
| Повторяемость | один вход всегда даёт один и тот же выход | допустима вариативность формулировок |
| Цена ошибки | проводка, лимит, юридически значимое действие | черновик, подсказка, классификация с проверкой |
| Что проверяет аудитор | код и журнал операций | дополнительно: версия модели, промпт, выборка тестов |
В реальном процессе признаки редко распределяются поровну. Чаще часть входа структурирована, а часть нет: заявка приходит заполненной формой, но с приложенным сканом договора. Правильный ответ здесь — не выбирать одно из двух, а поставить ИИ только на неструктурированный участок: разобрать скан, извлечь реквизиты, передать их дальше в обычную проверку.
Три признака, что ИИ в задаче будет лишним
1. Задачу можно полностью описать правилами
Если специалисты способны составить полную таблицу условий без бесконечного списка исключений, вероятностная модель, скорее всего, не нужна.
«Если тип клиента А и сумма меньше Б, направить по маршруту В» — это обычное бизнес-правило.
Не стоит поручать модели угадывать то, что можно однозначно посчитать.
2. На вход поступают структурированные и стабильные данные
Когда система получает заполненные поля с известными форматами и справочниками, ей не требуется интерпретировать смысл.
Дата уже записана как дата. Сумма — как число. Код контрагента выбран из справочника. Статус перевозки имеет одно из пяти допустимых значений.
Здесь задача обычно состоит в передаче, проверке или преобразовании данных. Это территория интеграций, правил и обычной программы.
3. Один и тот же вход обязан всегда давать один и тот же результат
Особенно это важно для расчётов, бухгалтерских проводок, лимитов, прав доступа и юридически значимых действий.
Если нельзя допустить вариативность, а решение не требует оценки контекста, лучше использовать детерминированный алгоритм. Его проще протестировать, объяснить проверяющему и восстановить по журналу операций.
ИИ можно подключить раньше: например, извлечь сведения из документа. Но окончательную проверку формулы, лимита или обязательного реквизита следует оставить обычной программе.
Простой тест перед началом проекта
Возьмите одну операцию из процесса и задайте три вопроса.
Первый: можно ли записать все действия исполнителя в виде точных условий?
Второй: получает ли он данные в готовых полях или вынужден читать документы, слушать разговоры и понимать контекст?
Третий: требуется ли от него интерпретация или только аккуратное выполнение инструкции?
Если правила полны, данные структурированы, а интерпретация не нужна, начинайте не с ИИ. Проверьте, можно ли решить задачу интеграцией, BPM, RPA или небольшим программным модулем.
Если же сотрудник постоянно работает с вариативными текстами, речью, изображениями и исключениями, ИИ стоит рассмотреть. Но даже тогда не нужно отдавать ему весь процесс. Достаточно найти участок, где интерпретация действительно занимает время или создаёт ошибки.
С чего мы начинаем в Daturum: карта процесса, а не выбор модели
Daturum занимается промышленным внедрением ИИ и ИИ-агентов для среднего и крупного бизнеса, в том числе в закрытом контуре и в регулируемых отраслях. И начинаем мы не с выбора нейросети, а с карты процесса — это фаза Discovery в методологии AI Factory.
Смотрим, какие действия выполняет сотрудник, какие данные он получает, где возникают исключения, сколько стоит ошибка и какой результат можно измерить. После такого разбора иногда выясняется, что компании нужен ИИ-ассистент. Иногда — распознавание документов в сочетании с набором проверок. А иногда достаточно исправить интеграцию между двумя системами.
Вывод «здесь ИИ не нужен» — это тоже результат проекта, а не его провал: заказчик получает работающий процесс, а не лишний компонент в контуре. Как это выглядит на практике, видно в реализованных проектах.
Хороший проект автоматизации не обязан содержать искусственный интеллект. Он должен решать конкретную проблему без лишней сложности.
Если процесс можно надёжно автоматизировать обычным способом, именно с него и стоит начать. ИИ пригодится там, где без понимания текста, речи, документов и контекста правила перестают справляться.
Частые вопросы
Чем RPA отличается от ИИ-агента?
RPA повторяет заранее описанную последовательность действий в интерфейсах систем: нажать, скопировать, вставить, сохранить. Правила задаёт человек, поведение робота воспроизводимо. ИИ-агент интерпретирует входные данные и сам выбирает следующий шаг из доступных ему инструментов. RPA хорош там, где действия одинаковы; ИИ-агент — там, где вход каждый раз разный.
Можно ли заменить BPM-систему языковой моделью?
Нет. BPM отвечает за маршрут, роли, сроки, эскалации и историю действий — то есть за детерминированную и проверяемую часть процесса. Языковая модель не даёт гарантии, что заявка пройдёт по нужному маршруту и что решение можно будет восстановить по журналу. Комбинация работает: BPM ведёт процесс, ИИ-компонент разбирает неструктурированные вложения внутри отдельных шагов.
Как понять, что процессу действительно нужен ИИ?
Задайте три вопроса из раздела «Простой тест»: полны ли правила, структурированы ли данные, нужна ли интерпретация. Если хотя бы на одном шаге сотрудник читает документы, слушает разговоры или разбирает произвольные формулировки — этот шаг кандидат на ИИ. Остальные шаги, скорее всего, останутся за обычной автоматизацией.
Почему ИИ-компонент дороже, чем кажется на старте?
Помимо разработки появляются постоянные статьи затрат: вычислительные ресурсы на инференс, версионирование промптов, регресс-тесты при каждом обновлении модели, мониторинг качества ответов и разбор инцидентов. В регулируемых отраслях добавляется требование объяснить принятое решение проверяющему. У детерминированного модуля этих затрат нет.
Что дальше
Если вы не уверены, нужен ли ИИ конкретному процессу, — это и есть предмет разбора на Hyperfast Presale: на рабочей сессии мы раскладываем процесс на шаги и за 2–24 часа собираем прототип на ваших данных, чтобы было видно, где выгоднее интеграция и правила, а где действительно нужна модель. Выход в промышленную эксплуатацию мы закрепляем в договоре измеримым бизнес-KPI.
Источники
- IBM. What is business process automation? — ibm.com/think/topics/business-process-automation
- Microsoft Learn. Introduction to desktop flows (Power Automate) — learn.microsoft.com/power-automate/desktop-flows/introduction
- NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, июль 2024, раздел 2.2 «Confabulation» — nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
Об авторе
Опубликовано 23 июля 2026 года.