Российские лоукод-платформы расширяют возможности: к визуальной настройке процессов, данных и интерфейсов добавляются инструменты искусственного интеллекта, средства интеграции и управления приложениями. При этом ускорение разработки не снимает вопросов архитектуры, безопасности, сопровождения и стоимости эксплуатации.
Лоукод платформы решают разные задачи
Российские лоукод-платформы (low-code) заметно различаются по происхождению и специализации. Одни развиваются вокруг управления бизнес-процессами, другие — документооборота и корпоративного контента, третьи — CRM. Поэтому даже при близком наборе базовых инструментов они могут лучше подходить для разных задач.
Поэтому при сравнении low-code-платформ имеет смысл учитывать не только набор базовых инструментов, но и то, для каких задач изначально развивалось решение. В зависимости от проекта важными могут оказаться работа с данными и ролями, возможности изменения логики, интеграции с другими системами и средства дальнейшей эксплуатации.
ИИ становится частью low-code-разработки
Одно из заметных изменений 2026 г. — ИИ встраивается в low-code сразу с двух сторон: помогает создавать приложения и становится частью процессов, которые в них работают.
ИИ в low-code работает на двух уровнях. Он становится частью корпоративных приложений, с которыми взаимодействуют пользователи, и одновременно начинает участвовать в их создании — от проектирования до настройки отдельных элементов. Именно эти два сценария выделяет Юрий Востриков, генеральный директор BPMSoft.
При этом задачи ИИ зависят от того, где он применяется. В бизнес-процессах это семантический поиск, извлечение данных из документов, подготовка отчетов и другие операции с информацией. В работе ИТ-команд ИИ помогает сокращать трудозатраты на разработку, тестирование, администрирование и поддержку, говорит Рамазан Салпагаров, директор по развитию платформы LDM.
Меняется и пользовательский интерфейс. Привычные формы и карточки сохранятся, но будут дополняться диалогом с ИИ, считает Виталий Томко, руководитель проектов по развитию платформы Directum. Пользователь сможет выбирать способ взаимодействия с системой в зависимости от задачи.
Встроить ИИ в процесс сложнее, чем подключить модель
При использовании ИИ в реальном бизнес-процессе нужно заранее определить его роль: какие данные он получает, что может делать самостоятельно, какие результаты требует проверки сотрудника и что должно происходить при ошибке.
Игорь Простоквашин, ведущий бизнес-аналитик, эксперт по реализации проектов Comindware, считает важным заранее определить роль ИИ в процессе. По его словам, для модели должны быть заданы входные данные, допустимые действия и порядок передачи результата сотруднику, если уверенности в ответе недостаточно. «Если запустить агента поверх хаоса, вы автоматизируете хаос, просто быстрее и дороже», — отмечает он.
По мнению Виталия Томко, low-code помогает встроить ИИ в конкретные задачи бизнес-процесса — там, где его применение дает понятный эффект. При таком подходе ИИ становится еще одним инструментом внутри приложения наряду с бизнес-правилами, маршрутами, поиском и интеграциями.
Это важно и с точки зрения затрат. Наталия Долженкова, исполнительный директор Elma, обращает внимание, что не каждую операцию следует передавать большой языковой модели. Там, где задача надежно решается обычным правилом, поиском или интеграцией, применение ИИ может лишь увеличить стоимость обработки. Платформа должна подключать модель там, где действительно требуется анализ неструктурированных данных или работа с неопределенностью.
Еще один критерий — возможность сменить модель без переделки всего приложения. Требования к стоимости, качеству и размещению данных могут меняться, поэтому логику процесса желательно отделять от конкретной модели.
У low-code остаются технологические границы
Low-code не отменяет обычную разработку. Для сложных интеграций, нестандартной логики или высоких нагрузок может понадобиться участие разработчиков. В таких случаях важно, чтобы платформу можно было расширять кодом и интегрировать с другими системами через API и готовые коннекторы.
Игорь Простоквашин связывает с этим рост значения открытости платформы. По его мнению, для заказчика важно, насколько удобно low-code-решение можно разместить поверх уже работающих учетных систем и связать с ними, вместо того чтобы перестраивать весь ИТ-ландшафт.
Рамазан Салпагаров предлагает смотреть на микросервисную архитектуру практичнее: она оправдана, когда сложность изменения монолитной системы начинает мешать независимой работе команд, масштабированию и отказоустойчивости. При этом во многих случаях важнее не количество сервисов, а хорошее разделение системы на модули с понятными связями между ними.
Самостоятельная разработка требует контроля со стороны ИТ
Если подразделения самостоятельно создают приложения, со временем в компании могут появиться десятки решений с разными моделями данных, интеграциями и правилами доступа. Это уже требует контроля со стороны ИТ — иначе ускорение разработки оборачивается усложнением всей инфраструктуры.
Игорь Простоквашин сравнивает результат неконтролируемой самостоятельной разработки с новой теневой ИТ-инфраструктурой. Сгенерированный или собранный на low-code продукт все равно приходится тестировать, защищать и поддерживать. Поэтому самостоятельная разработка работает, когда приложения создаются в общей управляемой среде с едиными требованиями к данным, ролям и проверке со стороны ИТ.
С появлением ИИ требования становятся выше. Наталия Долженкова отмечает, что аналитикам приходится понимать уже не только сам бизнес-процесс, но и данные, которые получает ИИ: откуда они берутся, какие результаты считаются правильными и как их следует проверять.
Компаниям приходится определять, какие изменения сотрудники могут вносить самостоятельно, а какие требуют участия аналитика, архитектора или разработчика. В обучение стоит включать и правила создания, проверки и публикации приложений.
Low-code сокращает ручную разработку, но не отменяет специалистов
Low-code берет на себя часть типовых операций разработки — создание форм, маршрутов, настройку прав доступа и использование стандартных компонентов. За счет этого разработчики могут сосредоточиться на более сложной логике, интеграциях и нестандартных задачах.
Наталия Долженкова считает, что основным ограничением для крупных компаний становится даже не количество разработчиков, а постоянно растущий список задач автоматизации. Если каждая из них проходит полный цикл традиционной разработки, ИТ-служба превращается в узкое место. Low-code дает возможность передать часть работы аналитикам и специалистам бизнеса, а разработчиков подключать там, где требуется их квалификация.
Меняется и спрос на ИТ-специалистов. Рамазан Салпагаров предполагает, что сочетание low-code и ИИ способно снизить объем ручной веб- и серверной разработки. Одновременно, по его оценке, возрастет потребность в системных инженерах и аналитиках: ИТ-ландшафт становится сложнее, а требования и связи между системами надо описывать и контролировать.
Юрий Востриков при этом общего дефицита квалифицированных разработчиков сейчас не наблюдает. По его мнению, более востребованными становятся специалисты другого профиля — те, кто одновременно понимает технологии, специфику отрасли и задачи бизнеса.
Безопасность low-code зависит от контроля разработки и работы с данными
Чем больше сотрудников могут создавать и изменять приложения, тем важнее разграничить права доступа, определить, кто может вносить изменения и как они попадают в рабочую систему.
Для части заказчиков к этому добавляются требования к технологическому стеку и сертификации. Виталий Томко обращает внимание на совместимость с российскими операционными системами и системами управления базами данных, а также требования, связанные с объектами критической информационной инфраструктуры.
С распространением ИИ возникает еще один уровень контроля — над данными и действиями модели. Нужно определить, к какой информации она получает доступ, какие операции может выполнять и где будет работать — во внешнем сервисе или внутри корпоративного контура.
Наталия Долженкова указывает, что корпоративный агент должен работать в рамках прав конкретного пользователя и оставлять цифровой след своих действий. Выбор между внешней и локальной моделью при этом зависит от требований к безопасности, стоимости и инфраструктуре.
Если результат работы ИИ влияет на дальнейшие действия в процессе, важна и возможность восстановить ход принятия решения. Игорь Простоквашин считает необходимым фиксировать, какие данные получила модель, что она предложила и кто подтвердил результат. Такая прослеживаемость особенно важна в регулируемых процессах.
Выбирать платформу надо с учетом дальнейшей эксплуатации
По мере сближения базовых возможностей платформ простого сравнения функций становится недостаточно. Пилот помогает проверить, как решение работает с реальными данными, интегрируется с другими системами, разграничивает доступ и переносит изменения из тестовой среды в рабочую.
Отдельно стоит оценить, какие задачи смогут выполнять специалисты бизнес-подразделений, а где потребуется разработчик. Если предполагается использование ИИ, добавляются вопросы размещения моделей, доступа к данным, прав агента и контроля его действий.
При этом скорость создания прототипа сама по себе мало говорит о будущих затратах. Доработка, интеграция, сопровождение и развитие системы требуют ресурсов, поэтому оценивать платформу имеет смысл с учетом всего срока ее эксплуатации.












