Автоматизация рутины и ИИ: роботы, конструкторы и языковые модели

Эта статья есть и на английском: English version.

Три класса из этой статьи покупают по одной и той же причине: есть работа, которую делают руками, и нет ресурса переписывать корпоративные системы. Робот перекладывает данные между окнами. Конструктор собирает приложение без разработчиков. Языковая модель отвечает на вопросы по вашим документам и готовит черновики. Все три обещают результат быстро и без большого проекта — и все три чаще других заканчиваются разочарованием.

Причина у разочарования общая. Ни один из этих инструментов не меняет процесс — все три его закрепляют. Робот исправно проходит три лишних согласования. Конструктор позволяет собрать за неделю приложение под непродуманный порядок работы. Модель уверенно отвечает по регламентам, в которых записано взаимоисключающее. Скорость, ради которой их берут, работает в обе стороны.

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

Что в этой статье

• Роботизация рутины: RPA и обработка документов — перекладывание данных и разбор входящих документов

• Конструкторы приложений: low-code и no-code — приложения без разработчиков и цена этой свободы

• LLM-платформы и ИИ-агенты — управляемый контур работы с языковыми моделями

• Как эти три контура связаны между собой — лестница автоматизации и порядок ходов

• Что общего в роли ИИ — что он усиливает и какой риск повышает

• Российские системы — распространённые решения по подклассам

• Типовые ошибки и чек-лист выбора — общий разбор и что проверить до покупки

Роботизация рутины: RPA и обработка документов

Это самый соблазнительный класс из всех. Робота показывают на демо, он за минуту делает то, на что у человека уходит полдня, и решение о покупке принимается прямо на встрече. А через год выясняется, что двадцать роботов требуют отдельного человека на поддержку и падают после каждого обновления в 1С. Разберём, что тут действительно работает, где проходит граница между роботом и нормальной интеграцией и почему роботизация неустроенного процесса стоит дороже, чем сам процесс.

Что делает робот — и чего не делает

RPA (robotic process automation, роботизация процессов) — это программа, которая работает в интерфейсах других программ так же, как человек: открывает окна, копирует поля, нажимает кнопки, переносит данные из одной системы в другую. IDP (intelligent document processing, интеллектуальная обработка документов) — соседний класс: он вытаскивает данные из документов (счета, накладные, договоры, акты) и передаёт их дальше в учёт.

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

Подклассы: из чего состоит контур роботизации

Программные роботы без участия человека (unattended RPA). Работают по расписанию на выделенной машине: ночная сверка, выгрузка выписок, разнесение платежей, заполнение отчётных форм.

Эффект: рутина, которая раньше съедала утро бухгалтера, происходит до его прихода.

Недостаток: робот молча ломается — и если никто не смотрит на журнал запусков, вы узнаете об этом от контрагента.

Роботы-помощники на рабочем месте (attended RPA). Запускаются сотрудником и делают за него кусок работы прямо во время задачи: собрать карточку клиента из трёх систем, заполнить типовую форму.

Эффект: быстрый и понятный выигрыш там, где сложный процесс не поддаётся полной автоматизации.

Недостаток: эффект размазан по людям и почти не виден в отчётности — обосновать вторую очередь проекта тяжело.

Интеллектуальная обработка документов (IDP). Распознавание, классификация документа, извлечение полей, сверка с учётной системой, отправка на ручную проверку в спорных случаях.

Эффект: входящий поток бумаг и сканов превращается в строки в системе, а люди работают только с исключениями.

Недостаток: точность никогда не равна ста процентам, и ошибка извлечения обходится дороже ручного ввода — потому что её никто не ищет.

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

Эффект: десять роботов становятся управляемым хозяйством, а не десятью скриптами на десяти компьютерах.

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

Анализ процессов: process mining и task mining. Восстановление реального хода процесса по логам систем и по действиям на рабочих местах — чтобы роботизировать не то, что громче просят, а то, что действительно съедает время.

Эффект: кандидаты на роботизацию выбираются по данным, а не по интуиции руководителя.

Недостаток: требует логов приличного качества и открытого разговора о том, чем занят рабочий день, — второе сложнее первого.

Кому нужна роботизация, кому рано — и после чего внедрять

Нужна, когда на перекладывание данных между системами уходит труд двух и более человек в пересчёте на полную занятость. Это рабочий порог: ниже него проект окупается медленнее, чем меняется процесс. Другие симптомы «пора»: одни и те же цифры вбиваются вручную в две системы; закрытие месяца упирается в ночную сверку; поток однотипных документов растёт, а штат бухгалтерии — нет.

Рано или не нужно: если процесс меняется каждый квартал; если систем всего две и между ними есть штатная интеграция; если рутина держится на одном человеке и вопрос решается перестановкой обязанностей. И отдельно: если процесс никто не описывал — сначала описать.

С чем связана и когда внедрять. Роботизация ставится после стабилизации тех процессов, которые роботизируем. Правило простое: робот на нестабильном процессе ломается еженедельно. Порядок ходов удобно держать в голове как лестницу автоматизации рутины: убрать лишний шаг → связать системы штатной интеграцией → поставить робота → добавить обработку документов. Робот — третья ступень, а не первая. Вход — документы и интерфейсы существующих систем; выход — записи в учётных системах. В торгово-сервисной из двух траекторий внедрения роботизация появляется рано, рядом с документооборотом и цифровым рабочим местом: CRM → СЭД и ЭДО и цифровое рабочее место / RPA → порядок в справочниках → ERP, BI и EPM → системы поддержки принятия решений на базе генеративного ИИ. Оговорка та же: рано — не значит «на любом процессе». Робот ставится на тот процесс, который уже стабилен, даже если сам класс появляется в цепочке рано. Обе траектории разобраны в карте порядка внедрения в статье-хабе. Роботизация не строит контур, она снимает боль там, где контур уже сложился и стыки остались ручными.

Что роботизация даёт бизнесу — и её типовые недостатки

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

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

Почему робот на неустроенном процессе — дорогая ошибка

Это тот случай, когда технология работает ровно так, как обещали, а результата нет. В книге Джимшера Челидзе «Искусственный интеллект. Практическое руководство для внедрения» есть перечень семи грехов цифровизации, и четвёртый из них — отсутствие изменений в процессах. Систему ставят поверх старого порядка, и сотрудники продолжают работать по-прежнему. Вовлечённость остаётся на уровне десятой части, а обещанная отдача не наступает. Решение там сформулировано жёстко: сначала перестроить процесс, потом автоматизировать.

Порядок подтверждается и наблюдением оттуда же: большую часть эффекта даёт наведение порядка в процессе, ещё до всякой автоматизации. Технология поверх упорядоченного процесса добавляет сопоставимый прирост (на кейсах книги, где это показано на ИИ-проектах, — около 75 % улучшения даёт оптимизация процесса, и ещё около 89 % добавляет технология поверх, уже от нового уровня). Обратный порядок даёт автоматизированный хаос — быстрый, воспроизводимый и от этого более устойчивый, чем хаос ручной.

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

2026 год: контекст

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

Ориентир по масштабу. Пилотный робот стоит сотни тысяч рублей разово и занимает 2–4 недели, сложный процесс — до единиц миллионов и 6–12 недель. Лицензия на одного робота — сотни тысяч в год. Дешевеет не робот, а процесс: стабильный процесс роботизируется в разы быстрее.

Конструкторы приложений: low-code и no-code

У любой компании есть очередь к ИТ. В ней — три десятка мелких задач, каждая из которых «на неделю»: журнал заявок на командировки, учёт пропусков, реестр договоров подряда, форма для сбора идей. Ни одна не дотягивает до отдельного проекта, все вместе висят месяцами. Low-code — попытка эту очередь разгрузить: собрать приложение из готовых блоков, не привлекая разработчиков. Ниже — где это работает, где ломается и чем заканчивается свобода без правил.

Что делает класс — и чего не делает

Low-code — конструктор: интерфейсы, формы, справочники, маршруты согласования и интеграции собираются мышкой, а код пишется только там, где без него нельзя. No-code — тот же принцип, но без возможности программировать вовсе.

Чего класс не делает: не заменяет корпоративные системы и не тянет сложную логику. Расчёт себестоимости, производственное планирование, юридически значимый документооборот на конструкторе не строят — это территория ERP, MES и СЭД. И не отменяет ИТ-службу: приложение, собранное бухгалтером, всё равно кто-то должен сопровождать, обновлять и защищать.

Подклассы: из чего состоит класс

Конструкторы бизнес-приложений. Учётные приложения, реестры, формы, простые рабочие места.

Эффект: задача, которая ждала полгода в очереди к разработке, закрывается за две недели силами аналитика.

Недостаток: каждое такое приложение — новая сущность в ландшафте; без учёта их через год никто не сможет перечислить.

Low-code процессные платформы. Маршруты согласований, задачи, регламенты — по сути BPM в конструкторе; граница с полноценным BPM проходит по сложности процессов и требованиям к аналитике.

Эффект: процесс описали и тут же запустили, без цикла «ТЗ — разработка — приёмка».

Недостаток: лёгкость запуска провоцирует автоматизацию непродуманных процессов — быстро закрепить хаос здесь проще, чем где-либо.

No-code для рабочих групп. Таблицы-базы, простые формы, автоматизации между сервисами — обычно приходят снизу, от самих сотрудников.

Эффект: команда решает свою задачу сама, не занимая ничью очередь.

Недостаток: классическая теневая ИТ-система: живёт на личном аккаунте сотрудника и исчезает вместе с ним.

Порталы и витрины. Внутренние порталы, личные кабинеты, каталоги сервисов поверх существующих систем.

Эффект: единая точка входа без переписывания систем под ней.

Недостаток: витрина наследует качество данных источников — на грязных справочниках она их только показывает шире.

Интеграционные коннекторы. Готовые связки с почтой, мессенджерами, учётными системами, шиной.

Эффект: приложение не остаётся островом.

Недостаток: соблазн связать всё со всем напрямую, в обход интеграционного слоя, — и получить новую паутину «точка-точка».

Кому нужен класс, кому рано — и после чего внедрять

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

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

С чем связан и когда внедрять. Порог входа зависит от масштаба. Небольшой компании достаточно общих справочников и правил интеграции. Среднему бизнесу и крупнее класс, как правило, ставится после базовой интеграционной шины. Без этой основы low-code плодит новые силосы — приложения с собственными копиями данных, которые потом никто не свяжет. Вход — данные из MDM и интеграционного слоя; выход — процессы, которые дозревают до BPM, и приложения, которые ИТ берёт на сопровождение.

Где low-code стоит в выборе «купить или разработать»

Стратегий реализации всегда три: купить готовое (Buy), настроить и дописать под себя (Modify) или разработать с нуля (Build). В книге Джимшера Челидзе «Искусственный интеллект. Практическое руководство для внедрения» есть наблюдение, ради которого стоит запомнить этот выбор. Готовые решения приживаются кратно чаще заказной разработки: на выборке кейсов книги — около 67 % успеха у покупки против 8 % у разработки с нуля. Оттуда же практическое правило: команда почти всегда хочет Build, потому что это интереснее, — и этому желанию стоит сопротивляться.

Low-code живёт ровно в середине, в зоне Modify: вы не покупаете готовый продукт под задачу и не строите систему с нуля, а собираете нужное из блоков платформы. Отсюда и правильный вопрос при выборе: закрывает ли готовое решение девять десятых потребности? Закрывает — берите его. Не закрывает, но задача не уникальна — вот здесь и работает конструктор. И только когда задача действительно уникальна для вашего бизнеса, разговор идёт о разработке.

Что класс даёт бизнесу — и его типовые недостатки

Эффект. Скорость: недели вместо кварталов на мелких задачах. Разгрузка ИТ: очередь худеет, разработчики возвращаются к тому, что действительно требует разработки. И вовлечённость: люди, которые собрали инструмент под себя, пользуются им иначе, чем те, кому его спустили.

Недостатки, о которых говорят меньше. Зоопарк: через два года в компании сотня приложений, из них треть заброшена, а кто автор — выясняется по журналу изменений. Стоимость сопровождения растёт незаметно и не в ИТ-бюджете. Потолок платформы: то, что легко на старте, упирается в производительность и сложную логику — и переписывать приходится всё сразу. Зависимость от вендора: перенести собранное на другую платформу почти невозможно, конструктор — это не переносимый код.

2026 год: контекст

Российские low-code платформы выросли из процессных систем, поэтому у нас класс ближе к BPM, чем к западным конструкторам приложений. Второй фактор — кадровый: дефицит разработчиков делает конструктор не модной игрушкой, а способом закрыть задачи, на которые всё равно некого посадить.

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

LLM-платформы и ИИ-агенты

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

Что делает класс — и чего не делает

Класс даёт компании управляемый контур работы с большими языковыми моделями — теми самыми LLM: где модель запускается, к каким данным имеет доступ, кто и что ей поручает, как это логируется и контролируется.

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

Подклассы: из чего состоит класс

Платформы запуска моделей. Инфраструктура: облачные модели по API или собственный контур на своих серверах, управление доступом, лимиты, логи.

Эффект: сотрудники работают с моделями внутри периметра, а не через личные аккаунты.

Недостаток: собственный контур — это железо и люди; облако — вопрос к тому, какие данные вы туда отдаёте.

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

Эффект: ответы опираются на регламенты компании и ссылаются на источник, а не сочиняются; базу можно пополнять мгновенно, без переобучения.

Недостаток: качество ответа равно качеству документов — на противоречивых регламентах ассистент уверенно выберет одну из версий и не скажет, что версий было две.

Ко-пилоты в рабочих местах. Помощник внутри инструмента — в почте, коде, документах, CRM: делает черновик, человек правит.

Эффект: экономит время на рутинной части работы, оставляя решение за человеком.

Недостаток: эффект размазан и плохо меряется; без замера «до» разговор об окупаемости превращается в спор ощущений.

ИИ-агенты. Не отвечают, а действуют: сами обращаются к системам, выполняют шаги процесса.

Эффект: закрывают операции целиком, а не подсказывают по ним.

Недостаток: агенту нужны границы, инструменты и сценарий на случай сбоя; без явного критерия «готово» он выполнит задачу слишком буквально — и это будет ваша формулировка, а не его ошибка.

Мультиагентные системы. Несколько агентов с оркестратором — под сложные процессы с параллельными потоками.

Эффект: автоматизация того, что одной ролью не закрывается.

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

MLOps и AI Governance. Эксплуатация моделей: версии, мониторинг качества, переобучение; и управленческий слой — какие сценарии разрешены, кто владелец, как принимаются решения о запуске.

Эффект: модели живут как продукты с ответственным, а не как эксперименты энтузиастов.

Недостаток: самый пропускаемый подкласс — до первого инцидента кажется бюрократией.

RAG или дообучение: что выбирать

Два способа приземлить модель на вашу специфику часто путают. RAG подключает документы в момент ответа: данные актуальны всегда, обновление — это просто добавить файл, стоимость низкая, и всегда видно, на что модель опиралась. Дообучение (FineTuning) меняет саму модель: оно про стиль, отраслевую терминологию и манеру ответа, стоит дороже, фиксируется на дату обучения и требует переобучения при изменениях.

Практическое правило простое: факты и документы — это RAG; стиль и терминология — дообучение. Большинство корпоративных задач, с которых начинают, — это RAG, а не дообучение, хотя звучит второе солиднее.

Кому нужен класс, кому рано — и после чего внедрять

Нужен, когда накоплены данные и документы, есть процесс, который стоит усилить, и есть владелец, готовый отвечать за результат. Симптомы «пора»: сотрудники массово ищут ответы в разрозненных регламентах; типовая переписка съедает часы; в компании уже используют публичные модели — просто неуправляемо.

Рано или не нужен: если процесс не описан и данные не приведены в порядок — ИИ-слой ставить не на что. И отдельный признак «рано»: нет ответа на вопрос, кто владелец сценария и по какому показателю мы поймём, что он работает.

С чем связан и когда внедрять. Это верхний слой пирамиды ИТ-систем: он ставится поверх той зрелости, которая уже есть, а не вместо неё. Верхняя ступень обеих траекторий — системы поддержки принятия решений для руководства, собранные на этом слое. Вход — данные всех систем ландшафта, база знаний и правила из Data Governance; выход — во все контуры, которые ИИ усиливает. И порядок работ здесь тот же, что у роботизации: сначала процесс приводят в порядок, потом накрывают ИИ. Цифры этого правила — выше, в разделе про робота на неустроенном процессе. Менять слагаемые местами нельзя: на хаосе вы получите ускоренный хаос.

Что класс даёт бизнесу — и его типовые недостатки

Эффект. Скорость работы со знаниями: ответ по регламентам за секунды вместо получаса поисков. Снятие рутины: черновики, разборы, классификация. И управляемость самого ИИ: вместо десятков личных аккаунтов — контур с правами, логами и правилами.

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

Отдельный слой — личная работа руководителя с моделью: не корпоративный контур, а собственные цели, решения и подготовка к встречам. Мы делаем это в «Соколе»: модель работает поверх контекста руководителя, а не поверх корпоративных документов. Честная граница: он не подключается к вашим системам и не является ни LLM-платформой, ни оркестратором агентов из этого раздела.

Что проверить до запуска: краш-тесты

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

• Попытка сломать намеренно — некорректные и провокационные запросы: что система выдаст под давлением.

• Устойчивость к заражённым данным — что будет, если в базу знаний попадёт неверный или подложный документ.

• Проверка на предвзятость — не дискриминирует ли решение по признакам, по которым не должно.

• Объяснимость — сможете ли вы объяснить решение системы, если его придётся защищать перед клиентом или регулятором.

• Сценарий отказа — что происходит, когда модель недоступна или ответила ерунду: кто подхватывает работу.

• Нагрузка — как система ведёт себя в пик, а не на демонстрации.

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

Ориентир по масштабу. Обследование занимает недели, пилот — 1,5–3 месяца, промышленная эксплуатация — 6–9. По деньгам развилка принципиальная. На облачных моделях платят подписку и объём обращений, счёт идёт от сотен тысяч рублей к единицам миллионов в год. Собственный контур на своём железе — это капитальные затраты другого порядка плюс инженеры сопровождения. Поддержку закладывайте сразу: без неё ассистент деградирует вместе с базой знаний.

Как эти три контура связаны между собой

Самая частая ошибка при выборе — сравнивать эти классы между собой. «Робот или конструктор?», «RPA или ИИ-агент?» Вопрос поставлен неверно: они закрывают разные слои одной задачи и стоят на разных ступенях зрелости.

Общая рамка — лестница автоматизации рутины. Порядок ходов один и тот же, независимо от того, какой класс вы рассматриваете: убрать лишний шаг → связать системы штатной интеграцией → поставить робота → добавить обработку документов. Робот здесь третья ступень, а не первая. Конструктор и языковая модель встраиваются в ту же лестницу, просто на других её участках. Low-code закрывает случай, когда нужного шага в системах вообще нет. LLM — случай, когда шаг требует понимания текста, а не переноса полей.

Три вопроса, которые разводят классы. Данные лежат в системах, но их надо переложить и между системами нет API — это RPA. Нужного приложения нет вовсе, а задача не тянет на проект разработки — это low-code. Задача про смысл текста: найти ответ в регламентах, разобрать письмо, сделать черновик — это LLM. Если ответ на все три вопроса «нет», автоматизировать пока нечего: надо описывать процесс.

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

Где они соприкасаются на практике. IDP — это уже стык RPA и ИИ: языковые модели сняли главную боль классического распознавания, необходимость размечать шаблон под каждый новый тип документа. Low-code-платформы продают ИИ-генерацию приложений по описанию. RPA-вендоры продают агентов в одном пакете с оркестратором. Границы между тремя классами размываются на уровне продуктов, но не на уровне требований к компании: порог входа остаётся у каждого свой.

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

Что общего в роли ИИ

Этот раздел в остальных статьях цикла отвечает на вопрос «что ИИ добавляет классу». Здесь он звучит иначе: один из трёх классов сам построен на ИИ, а два других им усиливаются. Поэтому вынесу общее.

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

Что на подходе (прогноз, не факт): агенты, собирающие сценарий робота или интеграцию из описания задачи; роботы, переживающие изменение интерфейса без переписывания; агенты, ведущие типовой процесс целиком с точками контроля.

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

Честная граница — она же главный вывод раздела. ИИ здесь снижает порог входа и ровно этим усиливает риск класса, а не лечит его. Раньше, чтобы наплодить неуправляемых приложений, нужен был хотя бы аналитик; теперь достаточно текстового описания. Раньше робот на сбое останавливался — это было неприятно, но честно. Языковая модель на его месте не останавливается, она выдаёт правдоподобный ответ, и заметить это некому.

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

В книге Джимшера Челидзе «Искусственный интеллект. Практическое руководство для внедрения» есть ловушка, которая описывает общий провал всех трёх классов, — «ИИ как пластырь»: технологическое решение накладывают на организационную проблему. Робот на неописанном процессе, конструктор без архитектурных правил и ассистент по противоречивым регламентам — это три вида одного и того же пластыря. Лечится он не отказом от инструмента, а порядком действий: сначала процесс, потом автоматизация.

Российские системы

Ниже — решения, устойчиво встречающиеся на российских проектах. Класс LLM молодой, и список меняется быстрее, чем выходят обзоры: реестровый статус конкретной редакции проверяйте на момент выбора.

• RPA-платформы — PIX RPA · Primo RPA · ROBIN · Sherpa RPA

• Обработка документов (IDP) — Directum Ario · Content AI · Smart Engines · Docsvision AI

• Low-code и процессные платформы — ELMA365 · Comindware

• Базовые модели и облачные платформы — GigaChat (Сбер) · YandexGPT и облачная платформа Яндекса · T-Pro

• Платформы сборки ассистентов и агентов — Just AI

По ELMA365 реестровая запись проверена напрямую (№ 309764, проверка — август 2026); по остальным позициям статус на момент выбора уточняйте сами.

Выбор в каждом из трёх контуров начинается не с продукта. В роботизации — со списка процессов-кандидатов: под три сценария и под тридцать нужны разные платформы, и разница в цене владения кратная. В конструкторах — с ответа на вопрос, кто будет собирать приложения: платформы для ИТ-аналитиков и платформы для «граждан» устроены по-разному, и попытка дать вторые первым заканчивается одинаково плохо. В LLM-контуре — с двух вопросов: где физически обрабатываются ваши данные и что происходит с решением, когда вендор меняет модель под капотом.

Типовые ошибки и чек-лист выбора

Ошибки в трёх контурах разные по форме и одинаковые по сути, поэтому собрал их в один список.

1. Ставить робота вместо интеграции. Если между системами есть API, робот в интерфейсе — временное решение, которое почему-то живёт годами и дорожает.

2. Автоматизировать неописанный процесс. Сценарий робота или схема в конструкторе станут первым описанием процесса — и закрепят все его нелепости.

3. Строить на конструкторе то, что должно быть в корпоративной системе. Потолок платформы обнаружится в самый неудобный момент, и переписывать придётся всё сразу.

4. Дать конструктор без правил. Свобода без реестра приложений и владельцев превращается в зоопарк за год-полтора.

5. Начинать с технологии, а не с задачи. Вопрос «где нам применить ИИ» почти всегда дороже вопроса «какой процесс болит».

6. Путать RAG и дообучение. Факты и документы — RAG, стиль и терминология — дообучение; ошибка стоит бюджета и квартала.

7. Считать эффект в часах, а не в деньгах. Высвобожденное время без перераспределения нагрузки — не экономия, а отчёт.

8. Не назначать владельца. У робота, приложения и ИИ-сценария есть автор, но нет хозяина — через полгода никто не знает, что это делает и можно ли выключить.

9. Разрешать теневую автоматизацию. Роботы под чужими учётными записями, приложения на личных аккаунтах, работа с моделями через личную почту — риск вскрывается при первой проверке.

10. Считать пилот, а не эксплуатацию. Во всех трёх классах стоимость владения растёт с использованием и живёт не в проектном бюджете.

Чек-лист перед выбором системы

1. Проверена альтернатива: этот шаг можно убрать? эти системы можно связать штатно? готовое решение закрывает девять десятых задачи? Разговор о покупке идёт после этих трёх вопросов, а не до.

2. Есть список процессов-кандидатов с оценкой трудозатрат и частоты изменений — на бумаге, до встречи с вендорами.

3. Пилот назначен на стабильный процесс, а не на самый болезненный. Громкий процесс обычно потому и громкий, что постоянно меняется.

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

5. Определена модель поддержки: кто чинит робота после обновления системы, кто сопровождает приложение, собранное не программистом, кто обновляет базу знаний. Я бы отказался от проекта, у которого этот пункт пустой, — он деградирует за год.

6. Посчитана эксплуатация на год, а не бюджет пилота: лицензии, обращения к моделям, поддержка, переобучение.

7. Заданы права и журналы: отдельные учётные записи, минимальные права, логирование — и назначен человек, который в эти журналы смотрит.

Что дальше

Общая карта классов — в статье Типы основных ИТ-систем. Другие разборы цикла: Производство, активы и склад · Клиенты и продажи · Деньги, планирование и аналитика · Данные и документы · Люди и ИТ-функция.

Разобраться глубже помогут книги Джимшера Челидзе «Цифровая трансформация для директоров и собственников» и «Искусственный интеллект. С неба на землю» — третья редакция, скачать бесплатно. Если у вас останутся вопросы, можете обратиться к нам за обучением или консультациями.