RPA — это программа, которая управляет другими программами через их интерфейс. Открывает портал, логинится, находит поле, вводит значение, нажимает «сохранить». Быстро, без усталости и — главное — работает с системой, у которой нет ни API, ни выгрузки. Ради этого RPA и существует.
Языковая модель делает совсем другое: превращает неструктурированный вход в структуру. Из письма, скана накладной или расшифровки звонка она достаёт поля, с которыми можно работать дальше. Она ничего не кликает и не переносит данные между системами. Это две дополняющие способности, а не альтернативы, — поэтому у вопроса в привычной формулировке нет ответа.
Почти всегда процесс приходит к нам с уже готовым допущением: кто-то решил, что это задача для RPA или для AI, ещё до того, как посмотрели, что вообще умеют системы. Дешевле идти по трём вариантам по порядку.
API или база. Если он есть у обеих систем — это и есть ответ. Быстрее, дешевле в эксплуатации, переживает редизайн интерфейса и падает громко, а не тихо. Проверять надо в первую очередь, в том числе у вендоров, которые про API не писали.
Файл, который система и так делает. Ночная выгрузка, отчёт, CSV, который кто-то скачивает руками. Некрасиво и абсолютно надёжно — и снимает большую часть поводов водить мышкой по экрану.
И только потом робот. Автоматизация на уровне экрана — это то, что остаётся, когда до системы правда не дотянуться иначе. Это нормальный вариант, просто третий, а не первый.
Модель может стоять внутри любого из трёх вариантов и обычно там и стоит: читает то, что пришло текстом, и отдаёт структурированные поля шагу, который переносит данные.
Есть работа, которую больше нечем сделать. Легаси-системы с терминальным интерфейсом, у которых уже некого спросить. Государственные и банковские порталы без API — и без планов его сделать. Десктопные приложения, лицензия которых запрещает лезть в базу напрямую. В таких случаях робот на экране — не компромисс, а единственный путь, и путь вполне рабочий.
Ломается всё на масштабе задачи. Бот, который заходит в один портал, скачивает выписку и кладёт её в папку, проживёт годы. Бот, который прокликивает четырнадцать экранов в четырёх системах, каждую из которых кто-то переделывает без предупреждения, превращается в обслуживание, тихо стоящее дороже той работы, которую он заменил.
RPA ломается о вёрстку. Переехавшая кнопка, новое окно согласия, медленная загрузка, лишний шаг подтверждения — робот не понимает экран, он идёт по координатам и селекторам. Обновления вендора — его естественный враг.
Модель ломается об уверенность. Она не останавливается, когда не уверена, а выдаёт гладкий правдоподобный неверный ответ. Лечится порогами, ссылками на источник и маршрутом к человеку, а не надеждой.
RPA падает заметно, модель — тихо. Остановившийся бот — это алерт. Неверно прочитанное поле уходит в учёт и находится на закрытии месяца. Второй сценарий требует более аккуратной конструкции.
Оба ломаются о нерешённую политику. Если никто не записал, что делать с исключением, ни одна из технологий не придумает ответ. Это управленческое решение в техническом костюме.
Выпишите шаги одного процесса и отметьте у каждого, что ему нужно: перенести данные или что-то интерпретировать. Дальше по каждому шагу «перенести» спросите, есть ли уже API или выгрузка, — спрашивайте у вендора напрямую, потому что в документации этого часто нет. То, что останется после этих вопросов, и есть честная площадь для RPA, и она обычно заметно меньше, чем казалось.
По нашему опыту ответ чаще всего такой: небольшая интеграция плюс модель на одном-двух шагах, где читается язык, и никакого робота вообще. Если робот всё же нужен, мы держим его в самых узких границах — одна система, один путь по экранам, — чтобы редизайн стоил вечера, а не переделки.
Мы делаем эту разметку бесплатно на мини-аудите: шаги, что нужно каждому, у каких систем есть API, о котором вы не знали, и что нужно, чтобы обойтись без экранного робота.
Мы используем cookie только для аналитики — чтобы видеть, с каких страниц приходят заявки. Ничего больше и ничего до вашего согласия. Политика cookie