Скелет для ИИ: почему BPM‑платформа важнее модели

На связи Илья Виноградов, руководитель команды «Технологическая платформа Digital Q.BPM». В этой статье расскажу, как ИИ‑агенты Digital Q.BPM ^[1] работают внутри платформы и поясню, почему именно платформа, а не модель, делает прикладные решения, созданные с помощью искусственного интеллекта ^[2], пригодными для промышленной эксплуатации и сопровождения.

Разберу четыре аспекта, выделяющие Digital Q.BPM на фоне других решений на рынке:

1. Структура платформы — тот самый скелет для ИИ;

2. Механика работы ИИ‑агентов внутри платформы на примере сквозного сценария;

3. Причины, почему результатам работы ИИ‑агентов Digital Q.BPM можно доверять;

4. Экономика: что изменилось, когда генерация стала почти бесплатной, и где по‑прежнему тратится время специалиста.

ИИ в разработке

О том, нужен ли ИИ в разработке, больше не спорят. В сентябре этого года Дэвид Хайнемайер Ханссон, создатель Ruby on Rails и один из самых известных скептиков технологической моды (он публично критиковал облака и вернул свои компании на собственное железо), заявил ^[3]: «Написание кода вручную перестало быть экономически выгодным для подавляющего большинства программистов, работающих в подавляющем большинстве компаний». Сам Дэвид не написал ни строки вручную примерно с марта 2026 года, а в его компании 37 signals ручное кодирование объявлено исключительным событием: «Это все равно что увидеть ошибку ^[4] в Sentry „что‑то пошло не так“. Почему агент не смог сделать то, что мы хотели?». Показательно здесь не само заявление, а то, кто его делает. Ханссон не склонен внедрять технологии ради хайпа. Если он практически полностью отказался от ручного написания кода, значит, экономика разработки действительно меняется.

При этом доверие к ИИ‑коду остается низким. Опрос Sonar, проведенному в начале 2026 года, показал ^[5] разрыв в цифрах: на ИИ приходится уже 42% кода, попадающего в коммиты. Однако 96% разработчиков не доверяют ему без проверки, а 38% считают ревью ИИ‑кода тяжелее ревью кода коллег. В итоге время, сэкономленное на написании кода, частично уходит на его проверку. И именно затраты на проверку сгенерированного кода теперь во многом определяют экономику агентной разработки.

Gartner в октябре 2025 года отметил ^[6], что к 2028 году внедрение подхода «от промпта к приложению» (prompt‑to‑app approach), применяемое непрофессиональными разработчиками, приведет к увеличению числа дефектов программного обеспечения на 2500%, что приведет к кризису качества и надежности программного обеспечения. Причина одна и та же: модель пишет код, не зная, в какой системе он будет жить. Gartner называет ^[7] это «код с недостаточным контекстом» (context‑deficient code).

В BPM‑платформе от «Диасофт» есть то, чего нет у обычного редактора кода: формальный скелет. Нотация BPMN 2.0 (Business Process Model and Notation) описывает, какие элементы могут использоваться при описании исполняемых процессов, как они соединяются между собой и что считается ошибкой. Стек платформы фиксирует технологии, на которых создаются формы и скрипты. Готовые компоненты задают структуру и требования к объектам, которые ИИ‑агент в принципе полномочен создавать.

Скелет первичен

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

1. Нотация. BPMN 2.0 и DMN (Decision Model and Notation) — формальные XML‑документы со схемой, по которой их можно проверить.

2. Технологический стек low‑code Digital Q. Интерфейсы на Angular, скрипты на Groovy, бэкенд на Java, Spring Boot и Go. Стек задает технологические границы: агент здесь не свободен.

3. Готовые компоненты платформы и правила их использования. Агенты работают с машиночитаемыми спецификациями процессов, на их основе строят и саму BPMN‑модель, и проверяют бизнес‑логику в режиме критика.

Соседние процессы, справочники, роли и существующие формы не обязательно попадают в контекст автоматически. Агент может опереться на них, если в запросе или контексте агента есть указатели необходимости обращения к этим данным через API или MCP (Model Context Protocol). Доступ к этим объектам системы ограничен правами и возможностями инструментов, подключенных к агенту.

Например, когда ИИ‑агент формирует процесс, его ограничивают компоненты платформы и вводные от бизнеса, например, переданная спецификация, доступные данные, права на изменение, правила, заданные в промпте и скиллах. Когда агент пишет скрипт, учитывается среда исполнения: доступные переменные процесса, их типы, язык и API.

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

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

Кстати, Ханссон в том же докладе объяснил, почему 37 signals не уходит с Rails даже после отказа от ручного кода. Фреймворк с жесткими соглашениями (convention over configuration) агенту удобнее, чем свобода. Соглашения экономят токены, а встроенные в фреймворк тесты дают агенту возможность проверить самого себя. BPM‑платформа доводит этот принцип до предела: ее соглашения записаны в нотации и проверяются схемой, а не договоренностью команды.

Работа агента на примере одного сквозного сценария

Представьте, стоит задача описать процесс производства бутылок для масла. Аналитик заходит в «Реестр процессов» Digital Q.BPM, инициирует создание новой BPMN‑диаграммы и решает использовать ИИ‑агента, которому передается следующий промпт:

«Нужно создать процесс производства бутылок для масла полного цикла производства. Используй пользовательские задания, где уместно».

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

Запускается моделирование. В режиме предпросмотра аналитикам доступны предлагаемые агентом шаги, которые начинают в реальном времени отрисовываться на диаграмме:

1. Начало

2. Получить заказ на бутылки

3. Заказ подтвержден?

4. Согласовать спецификацию с клиентом?

5. Закупить сырье и материалы

6. Рассчитать необходимое количество

7. Отправить заказ поставщикам

8. Получить подтверждение от поставщика

9. Подготовка пресс‑формы

10. Настройка оборудования для литья

11. Изготовить пресс‑формы

12. Выдувка бутылок

13. Контроль качества

14. Качество соответствует?

15. Утилизация брака

16. Упаковка готовых бутылок

17. Маркировка партии

18. Отгрузка продукции клиенту

19. Завершение

Система создает как пользовательские задания, так и проверки, и автоматические действия. Она предлагает каркас в нотации в соответствии со стандартами и правилами самой платформы. Дальше включается работа аналитиков: можно поменять как саму диаграмму, так и скорректировать промпт агента, который в рамках новой итерации учтет изменения, применит память ^[8] контекста и внесет замечания в процесс.

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

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

Вернемся к нашему процессу. Дальше идет диалог с агентом:

— Добавь шлюз после согласования.

— Вынеси проверку лимита в отдельную подзадачу.

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

Low‑code закрывает типовую логику ^[9] форм и процессов. Для нетиповой логики, расчетов, трансформации данных и обработки ответов внешних систем, агент помогает разработчику написать Groovy‑скрипты. А там, где кода не требуется, справляется сам: простую экранную форму отрисовывает без участия разработчика. Завершает работу генерацией документации в виде текстового описания, которое можно отдать в регламент или на согласование бизнесу.

Открытость: работа через MCP

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

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

Почему результату можно доверять

Агент в Digital Q.BPM устроен так, что его работу легко проверить. На этом держатся четыре опоры.

1. Результат всегда в стеке платформы. Ни одной «свободной» технологии. Angular, Java, BPMN XML. Тот, кто будет сопровождать решение, не встретит ничего незнакомого, поскольку скрипты и модели снабжены комментариями.

2. Модель проверяется. При сохранении платформа автоматически проверяет структуру BPMN, DMN, схемы формы, наличие обязательных полей, уникальность идентификаторов, корректность связей между узлами, существование ссылок на формы, правила, пользователей и сервисы, синтаксис выражений и скриптов, заполненность настроек задач. Тупиковая ветка или ссылка на несуществующую форму не пройдут незамеченными, кто бы их ни создал: человек или агент.

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

4. Последнее слово за человеком. Агент только предлагает варианты, в то время как пользователь принимает окончательное решение и сохраняет изменения. Ни одна модель не попадает в репозиторий без подтверждения пользователем.

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

Миф 1: «Агент заменит аналитика». Агент берет на себя рутинные операции, но оценка бизнес‑логики и принятие решений остаются за специалистом.

Миф 2: «Агент напишет процесс с нуля». Технически агент может создать модель с нуля, но без бизнес‑контекста, требований и корпоративных стандартов она может не соответствовать реальным задачам компании.

Миф 3: «Чем больше модель, тем лучше». Качество результата зависит не только от возможностей языковой модели, но и от того, какие инструменты, правила и контекст доступны агенту.

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

Именно поэтому BPM остается актуальным в эпоху ИИ‑агентов. Он позволяет сочетать детерминированные процессы с автономными действиями ИИ в заданных границах. Этот принцип сформулировала ^[10] Camunda в апреле 2026 года.

Процесс задает рамки агенту, а не агент процессу. Мы построили своих ИИ‑агентов именно исходя из этого принципа. В Digital Q агент устроен как управляемый процесс с логикой, инструментами, памятью и интеграциями, а чат с ним — лишь один из интерфейсов.

Экономика: генерация подешевела, проверка — нет

В 2025 году про ускорение от ИИ говорили осторожно. DORA 2025 назвала ^[11] ИИ усилителем: «Он выявляет сильные стороны высокоэффективных организаций и недостатки тех, кто испытывает трудности». В 2026 году тон сменился. Ханссон называет точную дату перелома, 24 ноября 2025 года, когда вышло поколение моделей, с которым агенты стали выдавать код, пригодный к слиянию почти без правок. В августе 2026 года он выпустил около 150 тысяч строк кода против 30 тысяч в год, которые писал вручную. Стоимость строки кода упала до стоимости токенов.

Но подешевела только генерация. Час аналитика, который проверяет маршрут процесса, и час разработчика, который тестирует интеграцию, стоят столько же, сколько год назад. The Pragmatic Engineer, подводя итоги спора вокруг доклада, формулирует это прямо: инженеры теперь отвечают за гораздо больший объем кода, который они не писали. Поэтому мы измеряем не «во сколько раз быстрее работает агент», а сколько времени человека остается после генерации. В таблице ниже колонка «С агентом» — это именно время человека на проверку и доработку результата.

Оценки по внутренним замерам команды Digital Q.BPM за период с июня 2026 года по настоящее время:

Таблица честнее любого лозунга. Там, где результат проверяется взглядом (диаграмма, документ, простая форма), человек тратит на приемку 20–40 минут вместо 2–4 часов работы: выигрыш в пять‑восемь раз. Там, где нужно тестировать граничные случаи (Groovy‑скрипт) — в два раза. Там, где проверка равна разработке (форма с несколькими интеграциями), выигрыш пока невелик: код коннектора агент напишет за минуты, но доступы, тестовые стенды и отладка обмена с внешней системой остаются на человеке. Это не предел: как только агент получает инструменты целевой системы через MCP, ускоряется та часть работы, которую платформа умеет проверять за человека.

Из этого следуют три правила, которые мы советуем нашим заказчикам при использовании ИИ‑агентов.

1. Давайте агенту контекст. Роли, справочники, соседние процессы, а лучше подключенная база знаний: через RAG‑модуль агент читает документы из Digital Q.Knowledge и Confluence. Чем больше он знает о системе, тем меньше context‑deficient code на выходе.

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

3. Не генерируйте то, что уже есть. Если в платформе есть готовый компонент, задача агента — подключить его, не создавая заново. Это одновременно защита от галлюцинаций и главная статья экономии токенов.

Прототип вместо документа

Зачастую требования описывают комплексом документов, которые живут на порталах и в переписке. Документы неделями согласовываются, по ходу согласования переписываются, и к моменту готовности либо отстают от рынка, либо сильно трансформируются. Это напрямую бьет по TTM, производительности команды и затратам проекта.

ИИ‑агенты позволяют за дни, а иногда и за часы собирать исполняемые прототипы процессов без интеграций: ход процесса, структуру объектов, экранные формы. Это касается не только BPMN‑диаграмм: по текстовому описанию агенты Digital Q собирают и экранные формы, и управленческие дашборды в Digital Q.Sensor. Бизнес‑заказчик проходит по шагам и принимает решение в модели вместо бумаги, и согласование требований становится проще и быстрее.

Оживление прототипа остается за разработчиками: на этапе внедрения они дорабатывают интеграции, настраивают безопасность и ролевую модель, шлифуют экранные формы. Это та часть работы, где агент нужен не всегда и не во всем, и по нашему опыту ^[12] именно ее лучше начинать, когда прототип уже принят.

Контур и безопасность

ИИ‑агент Digital Q.BPM работает на платформе Digital Q.Agents, общей для всех продуктов Digital Q: мультиагентная система, шлюз вызова моделей и интеллектуальный поиск RAG. Digital Q.BPM с ИИ‑агентами работает on‑premise, в контуре заказчика, данные заказчика за контур не выходят. Поддерживаются открытые модели, например Qwen, и коммерческие российские: YandexGPT и GigaChat. Можно подключить собственную модель клиента. Все вызовы моделей идут через единый шлюз AI Gateway: он задает лимиты токенов, переключает провайдеров, подхватывает резервную модель при недоступности основной и показывает расход по пользователям и сценариям. Смена модели становится настройкой в шлюзе вместо отдельного проекта.

Логирование запросов к агенту и его ответов ведется также в защищенном контуре. По умолчанию логи хранятся в течение 90 дней, доступ к ним имеет администратор платформы и сотрудник ИБ. Логирование можно отключить или настроить по правилам заказчика: например, писать только метаданные (время, пользователь, тип операции) без содержимого запросов. Это позволяет оптимизировать нагрузку на инфраструктуру и гибко настроить хранение данных.

Платформа соответствует требованиям регуляторов: поддерживаются сценарии с сертифицированными во ФСТЭК средствами защиты, разграничение прав доступа на уровне ролей и объектов, аудит действий пользователей и агентов.

Что дальше

Gartner в 2025 году заменил ^[13] квадрант iBPMS (intelligent Business Process Management Suite) на BOAT (Business Orchestration and Automation Technologies) и включил агентные функции в обязательный набор. При этом тот же Gartner ждет, что к концу 2027 года более 40% проектов в области искусственного интеллекта будут закрыты из‑за растущих затрат, неясной коммерческой ценности или недостаточного контроля рисков.

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

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

Мышцы будут расти с каждым релизом моделей. Скелет останется вашим.