RPA, скрипт или ИИ-агент: что выбрать для автоматизации

Если у системы есть API, а вход структурирован, берите интеграцию по API или скрипт. Если API нет, а интерфейс годами не меняется, подойдёт RPA-робот. Если вход неструктурирован (письма, сканы, свободный текст) и исключений много, нужен ИИ-агент, а точнее гибрид: агент понимает и размечает вход, а детерминированный код исполняет. Чат-бот нужен, когда системе достаточно отвечать, а не действовать.

Выбор определяется не модой, а свойствами процесса: как меняется интерфейс, из чего состоит вход, как часто случай не укладывается в правило и сколько стоит ошибка. В статье критерии, матрица ситуаций, дерево вопросов и сравнение стоимости владения. Названий RPA-платформ и цен вендоров здесь нет намеренно: решение зависит от процесса, а не от каталога. Если вы выбираете между агентом и чат-ботом, начните со статьи «Чем ИИ-агент отличается от чат-бота».

Шесть критериев выбора: как отличить задачу для скрипта от задачи для агента

Все шесть вопросов задаются про процесс. Ответы на них почти всегда сами указывают на технологию.

Критерии работают вместе. Структурированный вход и стабильный API дают скрипт, даже если задача выглядит «умной». Неструктурированный вход при высокой цене ошибки даёт агента, у которого нет права действовать без человека, и это не противоречие, а нормальная схема.

Шесть вариантов: API, скрипт, RPA, чат-бот, агент и гибрид

Интеграция по API

Системы обмениваются данными через программный интерфейс: HTTP-сервисы, обмен файлами известного формата, очередь сообщений. Самый устойчивый вариант: формат документирован, ошибки видны, проверка простая. Ломается, когда нужной операции в API нет или когда документация расходится с поведением системы. Примеры для 1С разобраны на странице «Интеграция 1С».

Скрипт

Небольшая программа по расписанию или событию: выгрузить, преобразовать, загрузить. Детерминирован, дёшево делается, легко проверяется. Перестаёт быть удобным, когда правил становится много, а они постоянно меняются: скрипт превращается в набор исключений, который понимает один автор.

RPA-робот

Управляет интерфейсом так же, как пользователь: открывает окна, кликает, вводит текст, читает с экрана. Нужен, когда API нет, а систему менять нельзя. Ломается при смене вёрстки, разрешения экрана, обновлении клиента, неожиданных всплывающих окнах, и часто ошибается тихо: робот нажал не туда, а система ничего не сообщила.

Чат-бот

Отвечает на вопросы по сценарию или по базе знаний, в том числе с языковой моделью внутри. Хорош, когда решение принимает человек. Сам данные в системы не заводит, поэтому его ошибка — неверный ответ, а не неверная запись. Подробнее — чат-бот для бизнеса.

ИИ-агент

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

Гибрид

Агент или модель понимает вход и размечает его, а исполняет детерминированный код с проверкой. Это самая частая рабочая схема, ей посвящён отдельный раздел ниже.

Матрица: ситуация, что брать, почему и когда не подойдёт

Условные ситуации; в вашем процессе набор свойств будет другим, но логика выбора та же.

Дерево вопросов: как выбрать за десять минут

Идите по вопросам сверху вниз и останавливайтесь на первом подходящем ответе.

1. Вход структурирован (поля, коды, стандартные форматы)? Да — к вопросу 2. Нет, это письма, сканы, свободный текст — к вопросу 4.
2. У систем есть API для нужных операций? Да — интеграция по API или скрипт. Нет — к вопросу 3.
3. Интерфейс стабилен, и вы знаете, когда он обновляется? Да — RPA-робот. Нет — сначала добиваться API или менять систему: RPA на нестабильном интерфейсе станет постоянной статьёй расходов.
4. Нужно только ответить или нужно действие? Ответить — чат-бот или ассистент по базе знаний. Действие — к вопросу 5.
5. Цена ошибки высока (деньги, клиент, необратимость)? Да — гибрид, где агент только готовит, а действие подтверждает человек. Нет — к вопросу 6.
6. Исключений так много, что правила не описать? Да — агент с правами по матрице действий. Нет — гибрид: агент размечает, код исполняет.
7. Нужна объяснимость для аудита? Если да, то решение должно приниматься правилом в коде, а модель только размечает вход, при любом ответе выше.

Гибрид: агент понимает и размечает, код исполняет

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

1. Модель читает письмо и возвращает данные в заранее заданной структуре: контрагент, позиции, количество, срок. Это данные, а не команды.
2. Валидатор проверяет структуру: обязательные поля заполнены, ИНН имеет верный формат, контрагент найден в справочнике, количество и суммы в допустимых пределах.
3. Если проверка пройдена, детерминированный код через API создаёт черновик в CRM или 1С. Если нет, случай идёт в очередь человека с пометкой, что именно не сошлось.
4. Человек подтверждает то, что подтверждает матрица действий, и только после этого уходит письмо или проводится документ.

Что это даёт:

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

Где гибрида недостаточно: когда решение требует цепочки шагов, каждый из которых зависит от результата предыдущего и заранее не расписан. Тогда нужен агент с выбором действий, но уже с матрицей прав, подтверждениями и журналом. Применение к процессам — на странице «ИИ-агент для бизнеса».

Объяснимость: когда решение должно быть воспроизводимым

Требование объяснимости часто всплывает в самом конце и ломает выбор. Правило в коде воспроизводимо: те же входные данные дают то же решение, и по тексту правила видно причину. Языковая модель вероятностна: ответ может отличаться даже на тех же данных, а текстовое объяснение модели — подсказка, а не доказательство.

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

Стоимость владения: что происходит при смене интерфейса

Разработка на старте — часть стоимости. Остальное зависит от того, как часто меняются вход и системы вокруг. Условно, стоимость владения складывается из разработки, поддержки при изменениях (частота изменений умножается на стоимость исправления), проверки человеком и инфраструктуры. Конкретные числа даёт обследование, а сравнивать варианты стоит по тому, что именно их ломает.

Из таблицы следует главное: RPA и агент ломаются тише и дороже, чем API и скрипт, потому что нужна проверка всего сценария, а не одного вызова. Если система меняется часто, а API есть, API окажется дешевле владеть, даже если на старте он требует больше работы. Общий подход к расчёту — в статье «Стоимость владения IT-системой».

Типичные ошибки выбора

Шесть ошибок, которые встречаются чаще других:

• Агент там, где хватило бы скрипта. Вход структурирован, правила стабильны, а проект усложнён моделью, правами и мониторингом без необходимости.
• RPA поверх системы с API. Робот кликает по интерфейсу, хотя та же операция доступна программным вызовом.
• Чат-бот вместо агента. Ждут, что бот заведёт заявку, а он только отвечает. Сначала выясняют, нужно ответить или сделать.
• Агент без подтверждений на дорогих действиях. Права есть, а границ нет, и первая ошибка оказывается в учёте.
• Один инструмент на всё. Процесс состоит из разных частей, и каждой нужен свой способ: чтение письма — модель, запись в учёт — API.
• Выбор по названию технологии. Решение принимается до того, как кто-то посмотрел на реальный вход и посчитал исключения.

Как проверить выбор за неделю на ваших данных

Спор о технологии заканчивается, когда есть выборка реального входа. Для этого не нужен проект, хватит нескольких дней разбора:

1. выгрузить реальные входы за период: письма, документы, обращения, а не те, которые удобно показывать;
2. разметить вручную: структура входа, типовые случаи, исключения, мусор;
3. посчитать доли каждого класса: типовой вход, исключения, нечитаемое;
4. для каждого класса выбрать способ: правило, API, модель с проверкой, человек;
5. отдельно оценить цену ошибки по классам: обратима ли она, затрагивает ли деньги;
6. сделать прототип выбранной схемы и прогнать его на той же выборке, сравнив с ручной разметкой;
7. записать решение вместе с условиями, при которых его пересмотрят: например, смена формата входа.

Результат такого разбора — доли на вашей выборке, а не обещание: проценты экономии до замера не называют.

Что делаем мы и с чего начать

Мы делаем и интеграции, и скрипты, и агентов, поэтому выбор не привязан к одному инструменту: если задачу решает интеграция по API, так и скажем, и проект получится проще и дешевле. Агента предлагаем, когда вход неструктурирован, а исключения нельзя описать правилами, и сразу вместе с матрицей действий, подтверждениями и журналом. Услуга описана на странице «Автоматизация и ИИ-агенты».

Начните с одного процесса и выборки реального входа. Если разбора за неделю недостаточно, обследование — 200 000 ₽ за один-два процесса, оно вычитается из следующего этапа; цены и сроки ступеней — на странице тарифов. На выходе карта процесса, матрица «ситуация — что брать», требования и вилка бюджета, а исходники и документация остаются у вас.