ответ сразу, без интриги. rpa ? robotic process automation — программные роботы, которые повторяют действия человека в интерфейсе: клики, ввод, копипаст между окнами. выбирают, когда процесс жёстко регламентирован, данные структурированы, а системы старые и без api — робот кликает по экрану вместо человека. ии-агента выбирают, когда во входе есть свободный текст и вариативность — письма, заявки, документы в произвольной форме — и когда системы позволяют работать через api. в 2026 для малого и среднего бизнеса агент — вариант по умолчанию: он решает более типичные для этого сегмента задачи и не ломается от каждого обновления интерфейса. rpa остаётся нишевым инструментом для legacy-систем — и это ниша скорее корпоративная. дальше — механика различий, таблица и честные случаи, когда rpa всё-таки лучше.
в чём принципиальная разница
rpa повторяет руки человека. робот записан на жёсткий сценарий: открыть окно, кликнуть в третье поле, скопировать значение, вставить в другую систему. он не понимает, что делает, — он воспроизводит. отсюда сила: идеальная предсказуемость на стабильном сценарии. и отсюда же слабость: любое отклонение — переехала кнопка, изменилась форма письма, пришёл нестандартный документ — и робот встал или, хуже, молча сделал ерунду.
агент повторяет голову человека — в узкой задаче. он читает вход как текст со смыслом: письмо «а можно перенести оплату на конец месяца?» для rpa — нераспознаваемый шум, для агента — запрос на перенос срока, который надо проверить по правилам компании и либо согласовать, либо эскалировать. агент работает через api ? программный интерфейс: системы обмениваются данными напрямую, без имитации кликов по экрану. быстрее и стабильнее, но api должен у системы быть. , принимает решения в заданных границах и зовёт человека на спорном.
грубая аналогия: rpa — это станок с чпу, агент — толковый стажёр. станок точнее на серийной детали, стажёр справится с «разбери вот эту кучу входящих, непонятное неси мне».
таблица сравнения
| rpa | ии-агент | |
|---|---|---|
| вход | структурированный: формы, таблицы, поля | любой: свободный текст, письма, документы |
| логика | жёсткий сценарий | правила + понимание смысла в границах |
| работа с системами | имитация кликов в интерфейсе | api и интеграции |
| реакция на изменения | ломается от смены интерфейса | устойчив к формулировкам; чувствителен к смене правил |
| ошибки | не ошибается в сценарии, но не видит, что сценарий устарел | может ошибиться в трактовке — поэтому обязательна эскалация |
| типовая цена | лицензии платформ от ~500к/год + внедрение; опенсорс дешевле, но с инженером | пилот 200к фикс, далее 3–10к/мес api |
| кому чаще нужен | корпорации с legacy-системами без api | малый и средний бизнес с потоком текстовых задач |
где rpa честно выигрывает
чтобы не превращать сравнение в агитацию, — случаи, где я сам сказал бы «вам rpa, а не агент»:
- система без api и без вариантов. старая учётная система, банк-клиент, госпортал, куда данные вносятся только руками через интерфейс. агенту туда хода нет, роботу — есть.
- массовый однотипный перенос данных. тысячи операций в день по абсолютно одинаковой схеме «скопировать из а, вставить в б». понимание смысла не нужно, нужна скорость и нулевая цена операции.
- регуляторные процессы, где нужна буквальная воспроизводимость. аудитору проще принять робота с жёстким сценарием, чем систему, принимающую решения. «робот делает ровно это, вот сценарий» — понятная строчка в регламенте.
заметьте общее: все три случая — про структурированные данные и неизменные сценарии. как только на входе появляется живой текст от живых людей, rpa сыпется.
где агент выигрывает без вопросов
входящие заявки в свободной форме, переписка с клиентами, разбор документов «как получилось» (счета, акты и кп от разных контрагентов в разных форматах), квалификация обращений, подготовка ответов по базе знаний. в каталоге агентов почти каждый пример — из этой категории, и это не случайно: в малом и среднем бизнесе рутина в основном текстовая. рутины «переносить данные между двумя старыми системами тысячу раз в день» у бизнеса до 100 млн выручки обычно просто нет.
гибрид: не «против», а «вместе»
в корпоративной практике всё чаще встречается связка, и она разумна: агент понимает, робот исполняет. агент читает входящее письмо, вытаскивает из него данные и решает, что делать, — а затем передаёт структурированный результат rpa-роботу, который вносит его в систему без api. каждый инструмент на своём месте: агент там, где нужен смысл, робот там, где нужен доступ к legacy.
для малого бизнеса, впрочем, гибрид — экзотика: если у ваших систем есть api (а у современных сервисов он есть), прослойка из rpa не нужна вовсе. не дайте продать себе «платформу rpa + ии» там, где хватает одного агента с интеграциями.
как выбрать за пять минут: три вопроса
- что на входе процесса? структурированные поля и таблицы → смотрите в сторону rpa или обычной интеграции. свободный текст → агент.
- есть ли у систем api? есть → rpa не нужен в принципе, выбирайте между интеграцией и агентом. нет и не будет → rpa как мост.
- меняется ли процесс? сценарий не менялся годами → rpa отработает. процесс живой, формулировки плавают, исключения регулярны → агент, потому что переписывать rpa-сценарий после каждого изменения дороже, чем кажется.
и универсальный фильтр из статьи про выбор процесса: начинать с одного процесса, а не с «платформы автоматизации всего».
частые вопросы
rpa умирает?
нет, но сжимается в свою нишу. legacy-систем без api в корпорациях хватит ещё на десятилетие, и там rpa продолжит работать. а вот истории «rpa-робот отвечает на письма клиентов» закончились: эту работу забрали агенты, потому что делают её принципиально лучше.
агент надёжен настолько же, насколько робот?
по-разному надёжен. робот не ошибается внутри сценария, но слеп к тому, что сценарий устарел. агент может неверно трактовать редкий случай — поэтому в нормальной архитектуре у него есть границы и эскалация: спорное уходит человеку, действия логируются. на живых процессах суммарная надёжность связки «агент + эскалация» выше, чем у робота, молча делающего неактуальное.
у нас уже есть rpa. выбрасывать?
нет. если роботы работают и окупаются — пусть работают. агентов имеет смысл ставить на соседние задачи, до которых rpa не дотянулся: всё, где вход текстовый. а вот расширять парк rpa на текстовые задачи не стоит — это дорога в вечную поддержку сценариев.
что из этого дешевле?
для малого и среднего бизнеса — агент, и заметно: пилот 200к фикс и копеечная операционка против лицензий rpa-платформ от полумиллиона в год. цифры по всему рынку внедрений — в разборе стоимости.