RPA или AI-агент: что выбрать для автоматизации

Чем RPA отличается от AI-агента

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

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

RPA и нейросети не конкуренты, а разные слои: робот умеет «нажимать», модель умеет «понимать».

RPA или AI-агент: сравнение по признакам процесса

Когда хватит скрипта или интеграции

Если процесс стабилен, а вход структурирован, агент не нужен: скрипт или обычная интеграция сделают то же, как правило, дешевле и надёжнее.

Сюда попадают передача данных между двумя системами по фиксированной схеме, ежедневная сверка выгрузок, отчёт из одних и тех же полей. Если у систем есть API, интеграция надёжнее робота, который кликает по экрану: ей не мешает смена вёрстки. Для простых связок есть и конструкторы без кода — их границы описаны в статье о выборе между no-code и разработкой. Вопрос «RPA или AI-агент» имеет смысл ставить, только когда простой вариант уже не справляется.

Что ломается у RPA

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

Чем агент уступает скрипту

• Точный расчёт по формуле. Арифметику и фиксированные правила надёжнее выполнять обычным кодом.
• Огромный поток одинаковых записей. Каждый вход проходит через модель, а обращения к моделям оплачиваются отдельно (как считать этот расход).
• Строго одинаковый результат. Если один и тот же вход обязан давать один и тот же выход, нужен детерминированный сценарий.

Связка: AI-агент и скрипт, API или RPA от стороннего подрядчика

Процесс обычно состоит из неструктурированного начала и жёсткого конца. Агент берёт начало: читает, классифицирует, извлекает данные, готовит черновик. Исполнитель берёт конец и записывает результат в систему по строгой схеме: за смысл отвечает агент с проверкой человека, за исполнение — детерминированный код. Задачи с потоком документов разобраны на странице про документооборот.

Что делаем мы. Мы делаем AI-агента и интеграции по API и выгрузкам. Экранных роботов (RPA) мы не делаем: если процессу нужен робот, на аудите оговариваем, кто его реализует. Доступность API и выгрузок ваших систем проверяем на экспресс-аудите и фиксируем в ТЗ и смете.

Пример: входящий счёт поставщика

1. Приём. Счёт приходит письмом: PDF, скан или фото. Агент определяет, что это счёт, и собирает реквизиты, позиции и суммы в черновик.
2. Сверка. Агент сопоставляет черновик с заказом и договором и помечает расхождения. Допуски и обязательные поля заданы правилами в коде.
3. Подтверждение человеком. Сотрудник подтверждает или правит черновик. Расхождения и суммы выше установленного лимита приходят с пояснением, где именно не сошлось.
4. Запись. Только после подтверждения детерминированная интеграция записывает данные в учётную систему по API или выгрузке, если система их даёт. В учётную систему агент не пишет: запись делает интеграция после подтверждения человеком, а черновики и карточки в рабочих системах (заявки, CRM) агент создаёт сам. Если нет ни API, ни выгрузки, остаётся RPA от стороннего подрядчика или ручной ввод.

Хватит ли потока: условная иллюстрация

Иллюстрация, не данные клиента и не прогноз. Допустим, бухгалтерия получает 1 000 счетов в месяц, и 12% из них приходят в нестандартном виде: скан, фото или свободное описание вместо таблицы. Таких счетов 1 000 × 0,12 = 120 в месяц. Если на ручной разбор одного уходит 10 минут, получается 120 × 10 = 1 200 минут, то есть 20 часов в месяц. Остальные 1 000 − 120 = 880 счетов приходят в стандартном виде, им хватает правил или скрипта; те 20 часов робот не уберёт, ему нужен структурированный вход.

Окупится ли агент на этих 20 часах? Нет. Допущения возьмём из статьи о расчёте окупаемости: агент забирает 50% ручной работы, час сотрудника стоит 800 ₽. Тогда экономия 20 × 0,5 × 800 = 8 000 ₽ в месяц, а плата за сопровождение по тарифу «Поддержка» — 40 000 ₽ в месяц; она покрывается только при 100 часах ручной работы в месяц на процесс. При таком объёме агент не окупится: разумнее разбирать нестандартные счета вручную или договориться с поставщиками о едином формате.

Из чего складывается стоимость владения

У RPA основная статья расходов — разработка сценария и его правки при каждом изменении интерфейса или формата; стоимость RPA-проектов мы не называем. У агента добавляются сопровождение и оплата обращений к моделям. Первый процесс у нас — от 200 000 ₽, 3-4 недели; экспресс-аудит 50 000 ₽ засчитывается в проект; сопровождение платное, минимум 6 месяцев. Из чего складывается цена — в статье о стоимости AI-агента.

Решения, которые не отдают ни роботу, ни агенту

Общая часть — в соседних статьях: случаи, где агент не нужен, и как устроено согласование человеком. Для выбора между роботом и агентом важнее другое: есть решения, которые нельзя отдавать ни тому, ни другому.

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

Как проверить на своих данных

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

1. Возьмите выборку. Достаньте несколько десятков последних реальных случаев, не отбирая удобные.
2. Разложите по входам. Сколько случаев пришло в одном формате, сколько в разных, сколько потребовало оценки по смыслу.
3. Посчитайте исключения. Доля нестандартных случаев и время на их разбор — как в иллюстрации выше.
4. Оцените цену ошибки. Переделка за минуту или потерянный клиент.
5. Идите от простого к сложному. Интеграция, скрипт, конструктор, RPA от подрядчика, агент, связка: следующий уровень нужен, только если предыдущий не справляется.