Журнал "Системы Безопасности" № 2‘2026

Ц И Ф Р О В А Я Т Р А Н С Ф О Р М А Ц И Я , И И , И Н Т Е Р Н Е Т В Е Щ Е Й 103 С тоит признать, что освоение даже самых простых инструментов low-code требует приобретения базовых навыков программиро- вания. И хорошо, если у заказчика есть хотя бы развитые системные администраторы, которые привыкли писать скрипты, или инициативные сотрудники, готовые учиться основам програм- мирования, несмотря на то, что основная спе- циальность у них может быть вообще не связа- на с информационными технологиями (ИТ). Как мы пришли к использованию искусственного интеллекта Вторым сложным аспектом является время, затрачиваемое на настройки low-code. Этапы выглядят примерно так: 1. Описать целевой вид бизнес-процесса. 2. Настроить интеграции с внешними система- ми (иногда уже тут приходится писать коннек- торы low-code). 3. Написать правила low-code. 4. Протестировать сценарий. 5. Внедрить, обучить пользователей. Зачастую проблемы начинаются уже на первом этапе. Чтобы описать целевой вид бизнес-про- цесса, иногда надо изучить много документа- ции, регламентов, нормативных актов, знать законы. Затем надо придумать блок-схему про- цесса. А если там больше двух сотен этапов? Часто на такое описание могут уйти недели и месяцы. Многие пользователи давно прибегают к общедоступным LLM-моделям для сокраще- ния трудоемкости этого этапа. Второй и третий этапы сами собой просятся на использование ИИ-помощников (ИИ здесь и далее – искусственный интеллект) в написании кода, и этим уже никого не удивить, особенно если синтаксис low-code похож на распростра- ненные языки. Тестировать и внедрять придется все-таки используя свою голову и время. Покрыть авто- тестами бизнес-процесс сложно. Функциональ- ное тестирование того, что должно работать с людьми, остается за человеком. Использование сторонних ИИ-инструментов И вот теперь представим ситуацию. Сотруд- ник берет пачку внутренних регламентов компании, какие-то реальные данные, свои идеи по целевому виду процесса и загружает все это в облачную LLM. Куда попадают дан- ные? Правильно, на сервера компании-опе- ратора этой LLM. Кто имеет доступ к этим данным? А если в них содержится коммер- ческая тайна или ноу-хау компании, обес- печивающее стратегическое преимущество на рынке? Эти вопросы очень часто звучат в сообществе руководителей на встречах, посвященных обсуждению внедрения ИИ в те или иные про- цессы. Во многих компаниях уже прямо запре- щено использовать сторонние ИИ-системы для работы с корпоративными данными. Проверка гипотезы Перед нами стоял ряд вопросов, ответив на которые, мы могли бы сделать вывод о необхо- димости реализации ИИ-помощников "под капотом" MES-платформ: l Действительно ли ИИ ускоряет настройку low- code и workflow с учетом необходимости вери- фицировать сгенерированные ИИ-сценарии? l Действительно ли качество сгенерированных ИИ-сценариев нас устраивает? l Какие ИИ-инструменты нам нужны? Для проверки этих гипотез мы подключали сто- ронние LLM к нашей лабораторной платформе, где у нас только те данные, за которые мы не переживаем. Результаты показали, что даже с учетом оплаты использования облачных ИИ платформ генера- ция бизнес-сценариев с помощью ИИ в разы выгоднее, чем оплата труда среднего менедже- ра или администратора на решение этой зада- чи. Но за менеджером (заказчиком) остаются этапы верификации, тестирования и внедрения. Обеспечение безопасного использования ИИ для настройки бизнес-процессов Обеспечить безопасное использование ИИ для настройки корпоративного программного обес- печения (ПО), включая MES- и ERP-платформы, можно только установив LLM внутри корпора- тивной сети заказчика. Это вызвано рядом тре- бований: l обеспечить хранение чувствительной инфор- мации только внутри корпоративного контура; l обеспечить устойчивость работы в условиях возможных блокировок доступа к различным ресурсам; l обеспечить контроль за тем, чтобы ИИ не основывался на ложных данных из внешней сети. Скорее всего, большинство компаний уже имеют или в скором времени будут иметь развернутую в корпоративном контуре LLM для решения широкого круга задач. И в таком случае MES будет лишь одним из сервисов, обращающихся за результатом работы корпоративной LLM. При этом, конечно, не всегда выгодно строить собственный ориентированный на LLM ЦОД. Это нецелесообразно для компа- ний не из ИТ-сектора, так как требует боль- ших CAPEX- и OPEX-затрат и наличия специ- фической экспертизы сотрудников. Можно ограничиться приватным LLM-облаком. Использование арендных вычислительных мощностей дает также гибкость в масштаби- ровании. И конечно же, не стоит забывать про настройку ролевой модели и ограничение возможности редактирования сценариев для пользователей, которые не должны менять бизнес-процессы. Перед запуском в работу можно также ввести этап верификации сценариев со стороны архи- текторов или службы информационной без- опасности. Заключение ИИ широко проникает в жизнь разработчиков как ПО, так и бизнес-процессов. Эффективность ИИ доказана во всех отраслях, и разработчики MES не остаются в стороне. Будем следить за развитием темы и, возможно, в одном из сле- дующих выпусков осветим реальные кейсы применения ИИ для настройки MES или другого класса промышленных систем. n www.secuteck.ru апрель – май 2026 Ваше мнение и вопросы по статье направляйте на ss @groteck.ru Василий Ежов Директор по IoT компании STAQ О беспечить безопасное использование ИИ для настройки корпоратив- ного программного обеспечения, включая MES- и ERP-платформы, можно только установив LLM внутри корпоративной сети заказчика. Безопасное использование ИИ для настройки платформ цифровизации производственных процессов В предыдущей статье "Современные платформы для построения сложных интеграций и комплексных бизнес-сценариев в корпоративных сетях без привлечения внешних разработчиков" (журнал "Системы безопасности" 2026/№ 1, стр. 114) мы рассмотрели подходы к безопасной и гибкой настройке сложного корпоративного программного обеспечения. Текущая статья опирается на подход, описанный в том материале.