От RPA к интеллектуальной автоматизации: выбор платформы для enterprise

Интеллектуальная автоматизация (гиперавтоматизация) – это симбиоз RPA, BPM, машинного обучения и LLM, позволяющий корпорациям оптимизировать бизнес-процессы. При выборе платформы важно избежать поверхностного подхода и ориентироваться на реальные сценарии использования. В статье рассматриваются риски неконтролируемого (теневого) ИИ, преимущества и недостатки open source и готовых корпоративных продуктов, а также классификация задач: где эффективнее классический RPA, а где – ИИ-агенты. Даны практические советы ИТ-менеджерам и закупщикам: сформулированы детальные технические критерии (интеграция, оркестрация, формы, безопасность, Low/No-Code), составлен сравнительный анализ подходов, приведен чек-лист принятия решения и рекомендации по проверке уникальности текста и снижению каннибализации. Все выводы основаны на исследованиях и опыте ведущих компаний в области автоматизации.

Современные тренды интеллектуальной автоматизации

Интеллектуальная автоматизация (ИИ + RPA) – следующий шаг в эволюции workflow-систем, когда софтверные роботы и искусственный интеллект дополняют технологии управления процессами. Сегодня на рынке быстро растет интерес к RPA, ML и LLM, а исследование TAdviser и SL Soft отмечает, что около 70% компаний уже получают отдачу от RPA, и почти две трети организаций планируют внедрять машинное обучение/LLM в ближайшие годы. При этом многие проекты ИИ пока остаются в пилотах и не приносят результата – из-за нереалистичных ожиданий и отсутствия должной интеграции.

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

Пример из практики:
В одном недавнем корпоративном проекте по работе с чувствительными юридическими документами исследователи пришли к выводу, что архитектура важнее выбора модели. Для надежного результата они развертывали open-source LLM в закрытом контуре заказчика, тщательно разделяли обработку документов на типы и жестко контролировали формат выхода. Это позволило добиться стабильного качества, хотя простого «подключи LLM – и все готово» не оказалось. Вывод: важно не полагаться на одну модель, а выстраивать вокруг нее управляемый пайплайн и обеспечивать воспроизводимость.

Риски неконтролируемого («теневого») ИИ

Даже если компания официально не внедрила платформы интеллектуальной автоматизации, ИИ уже часто «проникает в тень»: сотрудники начинают самостоятельно пользоваться облачными нейросетями (ChatGPT, Claude и др.) для решения ежедневных задач. По разным оценкам, до 80% работников используют такие открытые ИИ-инструменты без согласования с ИТ. Это создает так называемую теневую ИИ-автоматизацию – неформальный слой оптимизации, вне контроля служб безопасности и нормативного комплаенса.

Основные риски «теневого ИИ»:

• Утечки данных: каждый запрос и передача конфиденциального документа во внешнюю нейросеть может привести к утечке коммерческой тайны. Исследования показывают, что 38% сотрудников уже непреднамеренно передавали в ИИ-консоли чувствительную информацию. По данным IBM, подобные инциденты повышают среднюю стоимость утечки на $670 000.

• Нарушение соответствия (compliance): отсутствие прозрачности и контроля затрудняет аудит. Только около 30% компаний знают, какими ИИ-инструментами пользуются сотрудники. Это грозит рисками раскрытия персональных данных.

• Ошибки и недостоверность: модели могут «галлюцинировать» факты, генерировать неверные данные или код с уязвимостями – примерно 45% AI-сгенерированного кода содержит проблемы безопасности. Без надлежащей проверки ошибок эти системы могут принимать неверные решения.

• Зависимость от внешних сервисов: при использовании облачных LLM бизнес-процессы полагаются на сторонних провайдеров. Изменения тарифов или политики доступа могут внезапно вырубить критические сервисы. Это неустойчиво: необходимо сохранять возможность гибкого переноса нагрузки и быстрого переключения между разными ИИ-движками.

• Отсутствие корпоративной специфики: массовые open-source модели «не знают» отраслевых нюансов компании. Для нормальной работы требуется их адаптация (дообучение, RAG-подходы, векторные базы данных с корпоративными знаниями и т. д.). Без этого качество решений будет низким.

Итог: теневой ИИ лишь выявляет области, где сотрудники готовы к автоматизации, но сам по себе создает проблемы. Задача ИТ – превратить неконтролируемый ИИ в управляемый инструмент. Это достигается через внедрение корпоративных платформ интеллектуальной автоматизации, которые обеспечивают централизованный контроль, хранение корпоративных знаний и соблюдение корпоративной архитектуры. При таком подходе процессно-интеллектуальная автоматизация становится «вторым сотрудником компании» на официальных основаниях, а не хаотической подпольной практикой.

Open Source LLM vs коммерческие платформы автоматизации

При выборе решения важно учитывать разницу между самостоятельным развертыванием open-source моделей и покупкой готовой коммерческой платформы.

Преимущества и ограничения open-source

• Гибкость и контроль: организация получает полный доступ к «движку» LLM и может размещать модель внутри своей защищенной инфраструктуры, без передачи данных за рубеж. Например, эксперименты с локальными LLM в РФ подтверждают, что можно построить полностью изолированный контур обработки документов.

• Экономия на лицензиях: на первый взгляд отсутствие лицензионной платы дает экономию. Однако полностью бесплатной ручкой не получится. Нужно вкладываться в подготовку площадки, нанимать специалистов и время на интеграцию. Все компоненты (интерфейсы, API, логирование, системы аутентификации) придется разрабатывать и поддерживать самостоятельно.

• Требования к инфраструктуре: некоторые высокопроизводительные модели требуют мощной GPU-инфраструктуры. Например, в одном испытании оказалось, что легкие quantize-версии моделей допускали серьезные ошибки на длинных текстах, а полноразмерные модели требовали несколько GPU, что влияло на экономику развертывания. Компаниям нужно тщательно балансировать между скоростью, затратами и точностью модели.

• Безопасность и соответствие: хоть модель и внутри периметра, риски никуда не исчезают. Неконтролируемые запросы, уязвимости в открытом коде и ошибки пользователей при обучении или запросах могут приводить к утечкам и атакам. По данным PwC, свыше 45% инцидентов с корпоративным ИИ происходят из-за внутренних ошибок доступа, а не внешних атак. Поэтому при «домашнем» развертывании важно строить многоуровневую безопасность, разграничение прав и постоянный аудит.

• Отсутствие готового продукта: само по себе LLM – это не законченный продукт, а лишь один из компонентов. Нужно реализовать весь остальной «обвес»: сервисы логирования, управления очередями задач, интеграции с РПА-роботами, чат-ботами и т. д. Без этой «упаковки» ИИ останется просто лабораторной моделью, а не частью бизнес-процесса.

• Геополитические риски: многие известные open-source модели разрабатываются зарубежными сообществами. Изменения в лицензиях, санкции или технический форк могут внезапно сделать модель неактуальной или даже запретить ее использование. В случае проблем организации остается исходный код, но пропадает поддержка и обновления.

Преимущества коммерческих платформ

• Готовый стек и поддержка: корпоративная платформа объединяет в себе RPA, BPM, NLP/LLM и прочие компоненты с едиными интерфейсами, что ускоряет внедрение. Вендоры предоставляют стабильный продукт, регулярные обновления, SLA-поддержку и обученные сервис-команды.

• Интеграции «из коробки»: у популярных платформ типа ROBIN  уже встроены коннекторы к 1С, SAP, CRM, ERP, к облакам и офисному ПО. Это экономит месяцы разработки интеграций и снижает риски ошибок.

• Безопасность и сертификация: Коммерческий продукт часто сертифицирован на соответствие стандартам ИБ и уже проверен на уязвимости. Многие решения включают инструменты шифрования, токенизации и обезличивания данных, что критично для госкомпаний и банков.

• Экономия ресурсов: Отсутствует необходимость в собственной команде DevOps и ML-инженеров для поддержки ядра платформы. Кроме того, за счет масштаба вендоры могут эффективнее адаптировать новые модели и технологии – к примеру, быстро вставить обновленную нейросеть по доступности рынка.

• Поддержка импортозамещения: На российском рынке уже есть готовые RPA-платформы (ROBIN, Primo RPA, PIX Robotix, Sherpa и др.), соответствующие требованиям реестра отечественного ПО. Они гарантируют работу на локальных операционных системах и позволяют уйти от зарубежных решений без потери функциональности.

Вывод: open-source LLM дают максимальный контроль, но превращают проект в локомотив для ИТ-экспертов с большими затратами ресурсов. Коммерческие платформы предлагают консолидированное решение с поддержкой, что для большинства крупных компаний оказывается более рациональным вариантом.

Типы задач: RPA или ИИ-агенты

Бизнес-процессы различаются по предсказуемости и риску ошибок. Для жестко детерминированных задач, где алгоритм ясен и требования к результату строги (финансовые расчеты, массовая обработка транзакций, регламентированная отчетность), традиционная RPA-автоматизация остается наиболее эффективной. Программный робот выполняет заранее заданную последовательность действий (например: «открыть 1С, сформировать отчет, выгрузить его в Excel, отправить по почте») – что исключает человеческие ошибки. По данным исследования TAdviser/ROBIN, именно RPA демонстрирует наиболее ожидаемый эффект для автоматизации процессов, помогая крупным компаниям экономить время и снижать рутину.

С другой стороны, недетерминированные задачи (поиск информации на разных сайтах, анализ «неструктурированных» данных, коммуникация с клиентом на естественном языке) лучше решать с помощью ИИ-агентов на базе LLM. Когда шаги процесса зависят от контекста и заранее не определены, простой скрипт робота быстро перестает работать: при малейших изменениях интерфейсов или логики приходится переписывать сценарии. ИИ-агент же способен сам «разбираться в ситуации»: он анализирует текстовые требования, находит нужные данные, формулирует обращения и адаптируется к нестандартным ситуациям. Например, задача «собрать характеристики товара с различных маркетплейсов» удобнее решается LLM: агент может анализировать сайт, распознавать текст и изображение, тогда как для RPA пришлось бы писать отдельный робот под каждый сайт.

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

Пример применения: сотруднику нужен обзор подрядчика (хотя бы частично). Тогда процесс может выглядеть так: по нажатию кнопки сотрудник вводит ФИО/ИНН партнера в форму (человек остается в цикле), после чего RPA-роботы последовательно обращаются в реестры, платежные системы и внешние источники. Если встретились разночтения или неполные данные, на помощь приходит LLM-агент, собирая отчеты из PDF-документов или уточняя информацию через чат. Результат консолидируется на экранной форме и вновь предлагается на проверку сотруднику. Такой гибридный подход – RPA + AI-agent + человек – обеспечивает баланс скорости и надежности.

Личная эффективность vs процессная автоматизация

При внедрении ИИ в компании часто задаются вопросом: чего хотим добиться – повышения личной эффективности сотрудников или полной автоматизации процесса?

• Личная эффективность: ИИ-инструменты (чат-боты, генераторы текста/кода/отчетов) активно помогают работникам решать локальные задачи быстрее. Сотрудники копируют и адаптируют ответы, письма, презентации. Но сам бизнес-процесс при этом почти не меняется: роль человека остается ключевой, а ИИ лишь облегчает рутинные операции. Такой подход дает мгновенный, но ограниченный эффект – сотрудники работают продуктивнее, однако количество ручных операций остается высоким.

• Процессная автоматизация: Здесь акцент на реорганизации процесса и распределении ролей между людьми, RPA-роботами и AI-системами. Система сама маршрутизирует задания: некритичные задачи выполняют роботы и агенты, а людей подключают только для важных решений или исключений. Это дает больший эффект на масштаб: сокращаются издержки, минимизируются ошибки, обеспечивается неизменность результата и легкость расширения на новые кейсы. Именно к этому стремятся digital-лидеры – заменить повторяющиеся операции роботом, а сотрудников перевести на более творческую работу.

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

Критерии выбора платформы интеллектуальной автоматизации

При выборе решения нужно проанализировать множество аспектов. Ниже приведены ключевые параметры и вопросы, которые следует учитывать (большинство из них можно оценить в ходе демо или пилотного проекта):

Функциональный охват:

• Поддерживает ли платформа создание сквозных процессов, объединяющих сотрудников, программных роботов и AI-агентов?
• Можно ли использовать RPA-робота как один из шагов процесса и запускать несколько роботов параллельно в разных ветках?
• Есть ли интеграция с LLM/AI-агентами по общепринятым протоколам (например, MCP/Webhooks) для запуска нативных ИИ-задач внутри процесса?
• Поддерживаются ли интерактивные экранные формы для диалога с сотрудником на любом этапе (как входящие, так и выходные)?
• Реализована ли оркестрация процессов по ролям: можно ли задать, что конкретный шаг выполняет работник X, а следующий – бот на свободной машине? И есть ли визуальный конструктор процессов с мониторингом статусов и логами на каждом этапе?

• Можно ли без кода интегрировать платформу с существующими системами (1С, CRM, ERP) через API или стандартные коннекторы?
• Есть ли готовые модули OCR/ML для распознавания и классификации документов (счета, акты, ТЗ) и инструмент для извлечения сущностей/атрибутов из текста?
• Поддерживает ли платформа подключение кастомных действий на разных языках (Python, .NET) для расширения стандартного набора?
• Есть ли чат-боты (текстовые, голосовые) с интерфейсами для сотрудников (веб-чат, мессенджеры, телефония), чтобы делегировать задачи ботам «на входе» процесса?

• Предоставляется ли единый веб-портал (кроссплатформенный) для работы с процессами, задачами и формами? Нужна ли установка клиента только на исполнителе робота/агента?
• Как выглядят экранные формы: можно ли их гибко настраивать, добавлять свои поля, писать CSS/JS для кастомизации?
• Имеется ли поддержка таблиц, вложенных форм, многошаговых диалоговых процессов (human-in-the-loop)?

• Как платформа передает данные и документы между шагами? Например, выход одного робота становится входом для другого, можно ли легко связать результаты через ссылки на данные?
• Поддерживается ли передача файлов и двусторонний обмен данными между RPA-ботами, ИИ-агентами и пользовательскими формами?
• Есть ли функции контроля форматов и валидации входных данных, чтобы минимизировать ошибки на этапе передачи между элементами процесса?

Планирование и балансировка нагрузки:

• Платформа должна уметь автоматически распределять задачи по доступным ресурсам: если рабочая станция занята, следующий свободный робот должен выбираться сам.

• Можно ли ставить задачи роботу в очередь при отсутствии свободного рабочего места? Поддерживается ли автозапуск роботов по расписанию (с учетом производственного календаря)?

• Есть ли сценарий автоматического рестарта роботов при ошибках (retry)? Возможность запуска на разных ОС/стэках: например, робот для Linux запускается на Linux, для Windows – на Windows?

• Возможность миксовать «голубые» (с GUI) и «серые» (без GUI) роботов на одних машинах, если позволяет лицензия.

Безопасность и корпоративные требования:

• Платформа должна поддерживать ролевую модель: управление правами доступа к процессам, роботам, данным, интерфейсам разработки. Есть ли отдельные роли администратора, разработчика, аналитика, исполнителя?
• Нужна ли поддержка многотенантности (логическая изоляция нескольких подразделений/компаний)?
• Реализована ли система журналирования действий вплоть до уровней доступа к данным и компонентов? Можно ли запрещать экспорт/копирование схем без прав?
• Требуется ли сертификация решений (например, ФСТЭК/ФСБ по отечественному ПО) или работа на «отечественных» ОС? Учитывает ли платформа требования импортозамещения: например, отсутствие привязки к Microsoft Workflow Foundation, способность работать на Linux и «русских» ОС?
• Существуют ли инструменты защиты от угроз ИИ (фильтры промптов, модули анонимизации и дедупликации конфиденциальной информации)?

Мониторинг и управление:

• Реализован ли дашборд «мониторинга процессов» с визуализацией всех запущенных экземпляров, шагов, статусов и предупреждений?

• Сколько уровней логов ведется: лог процесса, лог каждого робота, лог системных действий? Есть ли централизованная консоль для управления ошибками и возможностью принудительной остановки процесса?

• Поддерживаются ли уведомления: в интерфейсе, на почту или мессенджер (например, о новых задачах, приближении дедлайнов и пр.)

Разработки Low-code/No-code:

• Важно, чтобы конечные пользователи могли создавать и настраивать процессы без программирования. Проверяйте, есть ли интуитивный визуальный конструктор на основе блок-схем, библиотека готовых действий (Actions) и механизм переиспользования фрагментов.

• Уточняйте раздельные режимы: Low-code – с доступом к коду и скриптам для разработчиков, No-code – для бизнес-аналитиков без кода вообще. Это повышает безопасность и поддерживаемость автоматизаций.

• Оцените скорость разработки: наличие каталогов шаблонов, возможность импортировать готовые сценарии.

Ниже приведено сравнение ключевых характеристик при подходе «open-source + самописная интеграция» versus «коммерческая платформа».

Чек-лист при выборе платформы интеллектуальной автоматизации

1. Оценить цели автоматизации: Персональная эффективность или полная реорганизация процессов? Сформулировать конечные KPI (например, время выполнения заказа, число ошибок).

2. Определить типы задач: Выяснить, какие процессы детерминированы (лучше подходят под RPA), а какие – творческие/неструктурированные (где требуются AI-агенты). Построить списки случаев использования для каждого.

3. Составить требования: Технические (интеграции, API, масштабируемость), организационные (роль человека, отчетность), ИБ (шифрование, аудит) и нормативные (импортозамещение, сертификаты).

4. Рынок решений: Сравнить несколько платформ (не более 3–5). Для каждой проанализировать ключевые функции из списка выше. Обратить внимание на отечественных игроков при наличии требований локализации.

5. Пилотный проект: Запустить PoC на реальном сценарии с участием конечных пользователей. Оценить удобство разработки (Low/No-Code), качество интеграции и реальный прирост эффективности.

6. Юридические и контрактные нюансы: Проверить условия лицензии (особенно для LLM), поддержки и обновлений. Убедиться, что соглашение соответствует политике безопасности организации.

7. Финальное сравнение: Составить итоговую таблицу с критериями, присвоить баллы, провести оценку рисков (включая «теневой ИИ», если платформа не будет внедрена).

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