Введение

Национальная стратегия развития искусственного интеллекта в редакции 2024 г. выделяет большие генеративные модели, то есть «модели искусственного интеллекта, способные интерпретировать и создавать мультимодальные данные на уровне, сопоставимом с результатами интеллектуальной деятельности человека» [1, п. 5]. Такие модели всё чаще применяются для автоматизации интеллектуальных операций внутри компаний, например для работы с текстами, обращениями, задачами и документацией.

Эмпирические исследования показывают, что эффект от применения таких моделей заметен, но неравномерен. Так, ИИ-ассистент увеличил число обращений, которые операторы поддержки решают за час, в среднем на 14 %, а у новых сотрудников — на 34 % [2]. Консультанты, использовавшие GPT-4, в задачах в пределах возможностей модели выполняли на 12,2 % больше задач и на 25,1 % быстрее, однако в задачах за этой «границей» реже приходили к верному решению [3]. Разработчики с ИИ-ассистентом выполнили экспериментальную задачу на 55,8 % быстрее контрольной группы [4]. При этом в отчёте DORA рост использования ИИ связывается не только с улучшением документации и ускорением код-ревью, но и со снижением стабильности поставки программного обеспечения [5].

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

Таким образом, существует противоречие между быстрым распространением больших языковых моделей и отсутствием у предприятий методики, которая позволяет отобрать внутренние процессы для автоматизации, встроить LLM в процесс с контролем качества результата и измерить эффект в сопоставимых показателях «до/после».

Цель статьи — предложить модель проактивного ИИ-ассистента для операционных процессов продуктовой команды ИТ-компании и систему показателей для оценки её эффективности. Для достижения этой цели необходимо проанализировать подходы к применению ИИ во внутренних процессах, описать процессы объекта исследования, разработать модель и критерии отбора операций, а также сформировать систему показателей и дизайн эксперимента.

1. Подходы к применению ИИ во внутренних процессах ИТ-компании

В научной литературе выделяют три подхода к внедрению ИИ в бизнес-процессы. Первый подход — полная автоматизация рутинных операций, второй — аугментация, то есть поддержка решений человека, третий — гиперавтоматизация, которая сочетает интеллектуальные технологии с перестройкой организации [8]. Степень автоматизации также указана в ГОСТ Р 59277–2020 как один из признаков классификации систем искусственного интеллекта [9]. Для внутренних процессов, где ошибка может задержать работу команды или ухудшить обслуживание клиента, наиболее применим подход аугментации. В этом случае система готовит информацию и предложения, а решение остаётся за сотрудником.

Применение LLM в программной инженерии систематизировано в обзоре 395 научных работ [10]. В отечественной литературе LLM рассматриваются, в частности, как инструмент управления знаниями организации, а ключевыми ограничениями их внедрения названы организационные факторы [11]. Для задач обработки инцидентов уже накоплены результаты промышленного уровня. На выборке из более чем 40 000 инцидентов показано, что LLM способны рекомендовать первопричины и шаги по их устранению [12], а система RCACopilot определяет категорию первопричины с точностью до 0,766 и используется в эксплуатации [13]. Кроме того, автоматическая классификация обращений в поддержку показывает хорошее качество и доступна компаниям без выделенной команды машинного обучения [14].

В отечественных диссертационных исследованиях также предложены методы, близкие к задачам данного исследования. Среди них можно выделить классификацию заявок пользователей по типам и формирование очередей по срочности [15], интеллектуальную поддержку решений в управлении программными проектами, при которой руководители принимали в среднем 80 % рекомендаций системы [16], а также нейросетевую модель распределения задач между участниками Agile-команды [17]. Однако данные решения основаны на правилах, онтологиях или классификаторах, которые требуют ручной поддержки и обучающих выборок. Кроме того, как и зарубежные системы, они начинают работу только по запросу пользователя.

Таким образом, большинство описанных решений работает по реактивной (pull) модели, при которой сотрудник сам обращается к ассистенту с запросом. Проактивные агенты, напротив, предвосхищают потребность пользователя и сами инициируют помощь [18]. Эксперименты с проактивным ассистентом для программистов показали его преимущества, но также показали, что слишком частые вмешательства ухудшают опыт пользователя [19]. Это согласуется с результатами исследований прерываний, которые заставляют работать быстрее, но ценой роста стресса [20]. Следовательно, проактивный ассистент должен не добавлять поток уведомлений, а сокращать его. Сравнение подходов к организации ИИ-ассистента приведено в таблице 1.

Таблица 1

Сравнение подходов к организации ИИ-ассистента

Для представления сценариев с участием LLM целесообразно использовать нотацию BPMN. Так, обобщённый сценарий поддержки принятия решений на основе больших языковых моделей описывается как последовательность стандартных задач в этой нотации [21].

2. Объект исследования и описание процессов «как есть»

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

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

Обработка обращений клиентов сейчас устроена следующим образом. Обращения принимает служба поддержки (первая линия). Если ошибка подтверждается, специалист поддержки регистрирует инцидент в трекере задач и назначает ответственную команду. На этом его часть работы формально завершена, однако регистрация в трекере не гарантирует, что инцидент быстро заметят. Трекер отправляет уведомления по каждому событию во всех задачах и упоминаниях, поэтому из-за их объёма руководитель направления уведомления не отслеживает. Новые инциденты он просматривает на преднастроенных панелях трекера, но нерегулярно. В результате самым быстрым способом привлечь внимание к инциденту остаётся личное сообщение руководителю направления, и специалист поддержки дублирует в нём инцидент. Скорость реакции команды, таким образом, зависит от ручного канала связи, а не от устройства процесса.

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

Согласно Scrum Guide, ежедневная встреча (Daily Scrum) — это 15-минутное событие для разработчиков, цель которого — проверить прогресс в достижении цели спринта и при необходимости скорректировать план работ на ближайший день. Такая встреча должна улучшать коммуникацию, выявлять препятствия и ускорять принятие решений, сокращая потребность в других встречах [22]. На практике на ежедневной встрече команды дополнительно обсуждаются распределение новых инцидентов, статусы отдельных задач, напоминания о завершении задач до фиксации релиз-кандидата, препятствия и задачи без движения. Когда на ежедневную встречу переносится оперативная координация, взятие задач в работу задерживается до следующей встречи, а сама встреча удлиняется.

3. Модель проактивного ИИ-ассистента

Предлагаемая модель представлена на рисунке 1 и включает пять уровней: источники сигналов (трекер задач, система контроля версий, инциденты, календарь спринта), сбор данных и детерминированные правила, обработку на основе LLM (первичный разбор инцидентов, поиск препятствий в комментариях к задачам, формирование дайджеста), доставку сигналов по push-модели и сотрудника, который проверяет сигнал и принимает решение. Под первичным разбором инцидента понимается определение модуля продукта и критичности, поиск похожих прошлых инцидентов и связанных задач и предложение кандидата в исполнители; в англоязычной литературе эта операция называется триажем (triage). Отметки «полезно» и «ложное» возвращаются в модель как обратная связь и используются для настройки правил, порогов и запросов к LLM.

Рис. 1. Модель проактивного ИИ-ассистента продуктовой команды

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

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

Таблица 2

Сценарии ИИ-ассистента и их приоритет в MVP

4. Система показателей и дизайн эксперимента

Гипотеза исследования состоит в том, что применение LLM-ассистента на операциях продуктовой команды, отобранных по заданным критериям, при контроле результата сотрудником сократит время реакции и трудозатраты на эти операции без снижения качества результата. Для проверки гипотезы используются показатели, приведённые в таблице 3.

Таблица 3

Система показателей для оценки эффекта «до/после»

Исследование построено как сравнение показателей до и после внедрения ассистента в одной команде. Показатели H1 и H2 рассчитываются ретроспективно по истории трекера и системы контроля версий не менее чем за три–четыре спринта, что позволяет получить базовый уровень без ожидания. Использовались данные внутренней системы управления задачами, доступные на чтение всем сотрудникам компании; в статье приводятся только агрегированные обезличенные показатели. Показатель H3 определяется по журналу встреч, который руководитель направления заполняет в день каждой встречи в течение двух спринтов до внедрения и такого же периода после него. В журнале фиксируется только время по категориям вопросов, без записи содержания обсуждений. Чтобы учесть возможный перенос операционных вопросов из встреч в переписку, дополнительно подсчитывается число операционных обсуждений в командном чате по тем же категориям. Пилотное внедрение длится не менее трёх спринтов. У исследования есть ряд ограничений: малая выборка (около 10 человек) не позволяет говорить о статистической значимости, нагрузка в разных спринтах различается, а праздничные периоды искажают данные. Поэтому результаты будут интерпретироваться как оценка эффекта в конкретной организации, а не как обобщаемый вывод.

5. Промежуточные результаты

На текущем этапе исследования уточнены научная проблема, объект, предмет и гипотеза. Выполнен обзор подходов, который показал, что эффект от генеративного ИИ неравномерен и требует контроля качества, а проактивная модель взаимодействия полезна при условии дозирования сигналов. Также разработаны модель ассистента, критерии отбора операций и система показателей, описаны процессы «как есть».

Предварительный анализ данных трекера задач за период с 14.01.2026 по 13.10.2026 (14 спринтов, 18 инцидентов) показал, что медианное время от регистрации инцидента до первой реакции команды составляет 95,1 ч (около четырёх суток), а 80-й перцентиль — 434,7 ч (около 18 суток; у 80 % инцидентов первая реакция команды наступила не позднее этого срока). Период анализа пришлось расширить, поскольку значительная часть инцидентов регистрируется в трекере в обход начального статуса и не попадает в выборку по строгому определению показателя. За шесть спринтов (с 08.06.2026 по 11.10.2026) в релиз-кандидат к началу регрессионного тестирования не попали 3 из 51 ключевой задачи, запланированной к выпуску (5,9 %), а ещё 5 из 8 ключевых задач без привязки к выпуску не были завершены к концу спринта; всего в срок не выполнено 8 из 59 ключевых задач (13,6 %). Для сравнения, по всем задачам спринта к фиксации релиз-кандидата не были объединены 23,0 % (64 из 278), поскольку задачи берутся в спринт с запасом. Журнал встреч для показателя H3 ведётся с 12.10.2026; базовое значение будет получено по итогам двух полных спринтов. Значения H1 и H2 будут использованы как базовый уровень для сравнения после пилотного внедрения. Ограничением базовых данных является то, что время фиксации релиз-кандидата в трекере не записывается и оценено по истории объединений в системе контроля версий.

Заключение

Таким образом, предложенная модель переводит ИИ-ассистента из реактивной модели в проактивную. Ассистент сам отслеживает операционные сигналы, обрабатывает их с помощью LLM и направляет нужному сотруднику, сохраняя за человеком принятие решений. Критерии отбора операций и система показателей H1–H4 позволяют проверить эффект количественно. Дальнейшими шагами исследования являются разработка прототипа, сбор базовых показателей и пилотное внедрение с последующим сравнением показателей до и после внедрения. Практическая значимость работы состоит в том, что модель и критерии отбора операций могут быть перенесены на другие продуктовые команды со сходным процессом.

Литература:

1. О развитии искусственного интеллекта в Российской Федерации: Указ Президента Рос. Федерации от 10.10.2019 № 490 (ред. от 15.02.2024) (вместе с Национальной стратегией развития искусственного интеллекта на период до 2030 года). URL: http://www.kremlin.ru/acts/bank/44731 (дата обращения: 07.10.2026).
2. Brynjolfsson E., Li D., Raymond L. R. Generative AI at Work: NBER Working Paper No. 31161. Cambridge (MA): National Bureau of Economic Research, 2023. DOI: 10.3386/w31161.
3. Dell'Acqua F., McFowland E., Mollick E. R. [et al.]. Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of AI on Knowledge Worker Productivity and Quality: Harvard Business School Working Paper No. 24–013. 2023. DOI: 10.2139/ssrn.4573321.
4. Peng S., Kalliamvakou E., Cihon P., Demirer M. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. 2023. arXiv:2302.06590. DOI: 10.48550/arXiv.2302.06590.
5. Harvey N., DeBellis D. Announcing the 2024 DORA report // Google Cloud Blog. 2024. 22 Oct. URL: https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report (дата обращения: 07.10.2026).
6. Дороговцева А. А., Овчаренко Н. К. Искусственный интеллект в системе управления предприятием: эволюция, инновации и перспективы // Экономика, предпринимательство и право. 2024. Т. 14, № 11. С. 6259–6272. DOI: 10.18334/epp.14.11.121944.
7. Скворцова Н. А., Захаров А. В., Булатов И. И. Цифровая трансформация бизнес-процессов на основе технологий искусственного интеллекта (российский и международный опыт) // Экономика, предпринимательство и право. 2025. Т. 15, № 1. С. 131–152. DOI: 10.18334/epp.15.1.122526.
8. Ермакова С. Э., Еникеев И. М., Еникеева Е. М. Актуальные вопросы теории и практики применения технологий искусственного интеллекта в бизнес-процессах // Креативная экономика. 2025. Т. 19, № 5. С. 1253–1274. DOI: 10.18334/ce.19.5.123109.
9. ГОСТ Р 59277–2020. Системы искусственного интеллекта. Классификация систем искусственного интеллекта. Введ. 2021–03–01. М., 2021.
10. Hou X., Zhao Y., Liu Y. [et al.]. Large Language Models for Software Engineering: A Systematic Literature Review // ACM Transactions on Software Engineering and Methodology. 2024. Vol. 33, № 8. Art. 220. DOI: 10.1145/3695988.
11. Зеленков Ю. А. Управление знаниями организации и большие языковые модели // Российский журнал менеджмента. 2024. Т. 22, № 3. С. 573–601. DOI: 10.21638/spbu18.2024.309.
12. Ahmed T., Ghosh S., Bansal C. [et al.]. Recommending Root-Cause and Mitigation Steps for Cloud Incidents using Large Language Models // Proceedings of the 45th International Conference on Software Engineering (ICSE 2023). 2023. DOI: 10.48550/arXiv.2301.03797.
13. Chen Y., Xie H., Ma M. [et al.]. Automatic Root Cause Analysis via Large Language Models for Cloud Incidents // Proceedings of the Nineteenth European Conference on Computer Systems (EuroSys '24). New York: ACM, 2024. P. 674–688. DOI: 10.1145/3627703.3629553.
14. Truss M., Boehm S. AI-based Classification of Customer Support Tickets: State of the Art and Implementation with AutoML. 2024. arXiv:2406.01789.
15. Талызин Д. Г. Автоматизация процессов обработки заявок в системах поддержки пользователей корпоративных информационных систем: дис. … канд. техн. наук. М., 2010. 154 с.
16. Малахова А. И. Модели и методы интеллектуальной поддержки принятия решений в организационном управлении программными проектами: автореф. дис. … канд. техн. наук. Уфа, 2013.
17. Корчагин С. Г. Управление процессами принятия решений в рамках командно-ориентированной организационной системы на основе аппарата нейросетевого моделирования: автореф. дис. … канд. техн. наук. Воронеж, 2024.
18. Lu Y., Yang S., Qian C. [et al.]. Proactive Agent: Shifting LLM Agents from Reactive Responses to Active Assistance. 2024. arXiv:2410.12361.
19. Chen V., Zhu A., Zhao S. [et al.]. Need Help? Designing Proactive AI Assistants for Programming // Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems (CHI '25). New York: ACM, 2025. Art. 881. DOI: 10.1145/3706598.3714002.
20. Mark G., Gudith D., Klocke U. The Cost of Interrupted Work: More Speed and Stress // Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI 2008). New York: ACM, 2008. P. 107–110. DOI: 10.1145/1357054.1357072.
21. Смирнов А. В., Левашова Т. В., Пономарев А. В. Обобщенный сценарий поддержки принятия решений на основе использования больших языковых моделей в информационно-управляющих системах // Информационно-управляющие системы. 2026. № 4. С. 2–16. DOI: 10.31799/1684–8853–2026–4-2–16.
22. Schwaber K., Sutherland J. The Scrum Guide. 2020. URL: https://scrumguides.org/scrum-guide.html (дата обращения: 07.10.2026).