Выбор между AI-агентом и RPA чаще всего проваливается не на технологии, а на том, что инструмент выбирают сразу на весь процесс. Одни платят за модель там, где хватило бы скрипта на двадцать строк, другие годами дописывают исключения в робота, которому достался вход с бесконечным числом вариантов, — и в обоих случаях деньги уходят в поддержку, а не в результат. RPA повторяет действия человека по одному и тому же порядку, AI-агент справляется там, где порядок каждый раз разный. Я разберу, где проходит граница, как считать стоимость владения и надёжность связки и когда не нужно ни то, ни другое.
RPA надёжен ровно до первой смены формата
RPA — это программный робот, который повторяет действия человека в интерфейсах: открывает, копирует, вставляет, нажимает. Он не понимает смысла операции, он воспроизводит последовательность. Отсюда сразу и сильные, и слабые стороны.
Сильные: полная предсказуемость, дешёвое исполнение, простая проверка результата. Если сценарий описан верно, робот выполнит его миллион раз одинаково и не устанет к вечеру пятницы.
Предел наступает там, где появляется вариативность. Изменилась вёрстка страницы, поставщик прислал накладную в другом формате, клиент написал ту же просьбу другими словами — сценарий ломается. Поддержка RPA в таких процессах и уходит в бесконечное дописывание исключений, и это хороший признак, что инструмент выбран не под вход.
AI-агент понимает незнакомое, но ошибается правдоподобно
AI-агент работает не по шагам, а по цели: он интерпретирует входные данные и решает, что делать дальше. Ему не нужно перечислять все формулировки клиентского вопроса — он поймёт незнакомую. Не нужно описывать каждый вариант накладной — он извлечёт поля из непривычного формата.
Плата за это — вероятностная природа. Один и тот же вход может дать чуть разные ответы, и качество приходится измерять статистически, на выборке, а не проверкой «работает или нет». Неприятнее всего то, что агент не падает с ошибкой, а выдаёт уверенный неверный результат. Отсюда требования к контролю, о которых мы писали в статье про мониторинг агента после запуска.
Три вопроса к процессу, которые решают выбор
Вопрос первый: сколько вариантов входа? Если данные приходят в одном фиксированном формате — это RPA. Если формулировки, форматы и структура каждый раз разные — это агент.
Вопрос второй: нужно ли понимать смысл? Перенести значение из поля в поле смысла не требует. Определить, о чём обращение и насколько оно срочное, — требует.
Вопрос третий: какова цена ошибки и кто её ловит? RPA ошибается предсказуемо: сломался — упал. Агент ошибается иначе: выдаёт правдоподобный, но неверный результат. Если такую ошибку никто не заметит, нужен контрольный слой или другой инструмент.
Отвечать на эти вопросы стоит не по памяти, а по реальным данным. Возьмите входящие за последний месяц — письма, накладные, обращения — и разложите их по форматам. Если девять из десяти приходят в двух-трёх шаблонах, спор об интеллекте закончен в пользу скрипта. Если шаблонов столько же, сколько отправителей, — в пользу модели.
Где связка сильнее обоих по отдельности
Самые устойчивые системы не выбирают между подходами, а разделяют роли. Агент берёт на себя понимание, RPA или обычный код — исполнение.
Пример из обработки входящих документов: агент читает пришедший счёт в любом формате и извлекает поля, а дальше жёсткий сценарий проверяет их по справочнику и заносит в учётную систему. Смысловая часть отдана тому, кто умеет в смысл; операционная — тому, кто гарантирует повторяемость.
Тот же принцип в продажах: AI-агент разбирает обращение клиента и решает, что это за запрос, а создание задачи и обновление полей в CRM выполняются детерминированной логикой, где ничего не «интерпретируется».
Во что обходится каждый подход в эксплуатации
Стоимость внедрения обычно обсуждают, стоимость владения — редко, хотя именно она определяет, доживёт ли автоматизация до второго года.
У RPA основной расход — поддержка сценариев. Каждое изменение в интерфейсе системы, с которой работает робот, требует правки. Обновилась CRM, поставщик поменял форму накладной — нужен человек, который это починит. Расход предсказуемый, но постоянный и растущий вместе с числом сценариев.
У AI-агента основной расход — токены и контроль качества. Первое считается арифметикой от объёма. Второе забывают заложить: кто-то должен регулярно смотреть выборку ответов и ловить деградацию, потому что упавший сценарий заметен сразу, а поплывшее качество — нет.
Практический вывод для расчёта бюджета: у RPA стоимость владения растёт от числа процессов, у агента — от объёма обращений. Это разные кривые, и на разных масштабах выгоднее оказывается разное.
Почему RPA ломается при изменении интерфейса
Главная эксплуатационная особенность RPA в том, что робот работает с внешним видом системы, а не с её данными. Он находит кнопку по положению или по признаку на экране, и любое изменение этого признака его останавливает.
Отсюда предсказуемый сценарий: поставщик обновил свою систему, подвинул поле, переименовал вкладку — и робот, работавший год, перестаёт работать в понедельник. Хуже, если он не останавливается, а продолжает нажимать не туда: тогда ошибка обнаруживается по последствиям.
Оценивать это нужно заранее и в часах. Спросите, как часто обновляются системы, с которыми будет работать робот, и заложите время на его починку после каждого обновления. Если система обновляется ежемесячно и вы не контролируете эти обновления, стоимость владения окажется заметно выше расчётной, и выяснится это уже после подписания договора.
Резать процесс по шагам, а не выбирать инструмент на весь процесс
Большинство реальных процессов не попадает ни в одну категорию целиком: часть шагов строго формальна, часть требует понимания. Попытка отнести весь процесс к одному подходу и есть источник дорогих ошибок.
Решение — резать процесс по шагам, а не выбирать инструмент для всего. Практический приём: выпишите шаги и по каждому ответьте на один вопрос — данные на входе всегда в одном формате? Шаги с ответом «да» отдаются формальной автоматизации, с ответом «нет» — агенту.
Обычно граница проходит в понятном месте: понимание входящего сообщения и извлечение из него сути — работа агента, дальнейшие действия в системах — работа скрипта. Такое разделение ещё и удобнее в отладке: понятно, на чьей стороне ошибка.
Надёжность цепочки — произведение звеньев, а не среднее
Ошибка часто в том, что надёжность каждого звена оценивают по отдельности, а результат получают общий. Если понимание работает с одной точностью, а исполнение с другой, итоговая доля правильно завершённых операций — их произведение, и она заметно ниже каждой из частей.
Условный пример: пять звеньев, каждое верно в девяноста пяти случаях из ста. Перемножаем — на выходе около семидесяти семи верных операций из ста, то есть с браком окажется больше каждой пятой. Ни одно звено при этом не выглядит проблемным, и на демонстрации каждого по отдельности всё будет хорошо.
Отсюда правило: чем длиннее цепочка, тем важнее контрольная точка в середине — шаг, где результат проверяется до того, как на нём построены следующие действия. Проверка может быть автоматической, но она должна существовать, иначе ошибка первого шага доедет до последнего в увеличенном виде.
Что спросить у подрядчика, который предлагает одно из двух
Подрядчики обычно специализируются на чём-то одном и склонны видеть в задаче то, что умеют. Это не злой умысел, но проверить стоит.
Три вопроса дают достаточно. Первый: сколько вариантов входных данных вы предполагаете и что произойдёт с непредусмотренным вариантом? Ответ «такого не будет» означает, что о нём не подумали. Второй: сколько времени займёт починка после обновления смежной системы? Третий: как мы узнаем, что автоматизация ошиблась, если она не остановилась, а сделала неправильно?
Третий вопрос самый показательный. У продуманного решения на него есть конкретный ответ — сверка, контрольная выборка, уведомление. Отсутствие ответа означает, что ошибки будут обнаруживаться по жалобам клиентов, а это самый дорогой способ.
Когда интеллект не нужен вообще
Отдельно стоит сказать про случай, который в презентациях обычно опускают: часть задач не требует ни того, ни другого. Если процесс описывается десятком условий, его дешевле и надёжнее реализовать обычным кодом — без модели, без робота, без ежемесячной платы за токены.
Простой критерий: если вы можете полностью описать задачу правилами за час и правила не меняются каждую неделю — берите код. Модель имеет смысл там, где перечислить все случаи невозможно в принципе.
Есть и третий вариант, о котором вспоминают последним: процесс не нужно автоматизировать совсем. Если операция случается несколько раз в месяц и занимает у сотрудника десять минут, никакая автоматизация не окупится — ни робот, ни агент, ни код. Сначала стоит посчитать, сколько часов в месяц уходит на шаг, и только потом выбирать инструмент.
Моя позиция здесь такая: агент оправдан только там, где без понимания смысла процесс не работает, а всё остальное лучше отдать скучной детерминированной логике. Когда к нам в 404ai приходят с запросом «сделайте AI-агента», первым делом мы проверяем, нельзя ли решить задачу без модели, и если можно — так и говорим.
Как проверить выбор на своих данных до договора
Решение «агент, робот или код» принимается не на встрече с подрядчиком, а на выборке. Порядок укладывается в неделю. Выгрузите реальные входные данные процесса за месяц и разметьте форматы. Выпишите шаги и отметьте, какие требуют понимания смысла. Посчитайте, сколько часов в месяц занимает каждый шаг сейчас, — это и есть потолок того, что можно сэкономить. Договоритесь о метрике: доля операций, завершённых без ручного вмешательства, и доля ошибок, пойманных до последствий.
После этого спор о технологиях обычно заканчивается сам: видно, какие шаги отдать модели, какие скрипту, а какие оставить человеку. По такой же схеме мы ведём пилоты — цель, метрика, проверка на данных клиента и условие остановки, если метрика не двигается; подробнее — на странице о подходе. Если хотите пройти этот разбор на своём процессе, его можно начать с диагностики.
