В Gartner прогнозируют, что уже к следующему году более 40% агентных ИИ-проектов будут закрыты. Как не попасть в эту статистику? Вместе с экспертами разберем, где именно в корпоративных системах ИИ дает максимальный эффект, как избежать ловушек с лицензионной политикой вендоров и почему каждый ИИ-агент должен работать как стажер с четкой должностной инструкцией и правом на ошибку. ИИ не должен становиться узким местом или точкой отказа для критичных бизнес-процессов — это подтверждают и мнения, прозвучавшие в ходе форума «Интеллектуальное предприятие — 2026».

Есть ли смысл встраивать ИИ в имеющиеся бизнес-системы?

«Вопрос о том, встраивать ли ИИ в существующее бизнес-приложение, надстраивать отдельным слоем или полностью менять систему, лучше рассматривать не как выбор из трех альтернатив, — считает Виталий Агапеев, руководитель центра ИИ-экспертизы ИТ-группы N3.Tech. — В работающем ИТ-ландшафте сосуществуют три разных слоя. Первый — слой записи: проводки, статусы, остатки, права доступа. Здесь нужен строгий детерминизм, поэтому ИИ в этом слое не нужен. Второй — слой действий: операции системы, которые можно вызывать программными способами, с валидацией, проверкой прав и журналированием. Третий — слой суждения: интерпретация, подготовка черновиков, ранжирование, объяснение. Именно здесь ИИ уместен. Проблема в том, что средний слой во многих системах не выстроен, поэтому реальный ИИ-проект примерно на 70% состоит из работ, которые непосредственно с ИИ не связаны».

Виталий Агапеев: «Реальный ИИ-проект примерно на 70% состоит из работ, которые непосредственно с ИИ не связаны»

Заменять систему записи ради ИИ, как правило, нет смысла, продолжает Агапеев, потому что причины замены систем этого типа обычно внешние: снятие с поддержки, требования регулятора, импортозамещение. Что очень важно, сроки жизненных циклов у бизнес-приложений и ИИ-систем сильно различаются — например, ERP «живет» 10–15 лет, поколение моделей меняется каждые 6–12 месяцев, а проект замены ядра длится два-три года. «За это время модельный слой успеет обновиться несколько раз. Жестко связывать компоненты с настолько разной скоростью изменений — серьезная архитектурная ошибка, не зависящая от конкретной технологии. По той же причине не стоит встраивать ИИ непосредственно внутрь монолитного приложения: быстро устаревающий компонент будет связан с системой, которая меняется значительно медленнее, — отмечает эксперт. — Рабочая конфигурация — отдельный слой, который обращается к системе через те же интерфейсы, что и человек. Он находится не “над” и не “под” системой, а “рядом” с ней: ИИ не получает привилегий, которых нет у пользователя, и не обращается к базе данных в обход бизнес-логики. Единственный случай, когда вопрос действительно может упираться в замену системы, — отсутствие вызываемых интерфейсов. Но и тогда решение следует принимать, исходя из интегрируемости системы, а не из того, встроен ли в нее ИИ».

Есть еще один важный фактор, который появился менее года назад, — лицензионная политика вендора. «В апреле 2026 года SAP обновил своей политики в отношении API (API Policy) и теперь запрещает внешним ИИ-агентам вызывать API SAP, кроме как через собственного ИИ-ассистента Joule, что означает двойной инференс и оплату за вызов, — поясняет Агапеев. — Между тем, Salesforce с архитектурой Headless 360 и ServiceNow с Action Fabric, напротив, открыли доступ к действиям платформ через REST и MCP. Подходы у вендоров разные, поэтому еще до проектирования архитектуры следует проверять соответствующие пункты лицензионных соглашений».

По мнению Ильи Бычкова, директора направления разработки практики «1С» компании «Рексофт», замена системы ради ИИ-модулей — самый дорогой, долгий и рискованный путь: выбрасываются в корзину предыдущие годы работ по настройке процессов, интеграции, а заодно накопленные данные и доверие пользователей. «Сам по себе ИИ почти никогда не оправдывает полную замену. К тому же вендоры систем AI-native часто переоценивают свои ИИ-продукты. Обычно они универсальны и не адаптированы к данным и процессам конкретного предприятия, а порой и отрасли. При внедрении данные все равно придется переносить, а людей переучивать. Встраивание ИИ в бизнес-приложения позволяет брать зрелые проверенные компоненты (например, готовые сервисы “1С”, GigaChat, YandexGPT) и настраивать их под контекст конкретного предприятия».

«Самое главное в работе ИИ — это данные, контекст и правила работы с этим контекстом, — поддерживает Артем Селезнев, директор программы проектов компании Prime Finance. — Поэтому наш подход при проектировании ИИ-решений — создавать коннекторы для ИИ в уже внедренных решениях, чтобы максимально эффективно использовать имеющийся контекст. Многие команды, сопровождающие ранее внедренные системы, идут в ногу со временем и самостоятельно разрабатывают подобные коннекторы к решениям. Также надо отметить еще один, даже более важный вопрос — подготовка навигации по данным, полученным из систем. Здесь есть два решения: готовить и размечать данные непосредственно внутри систем или создавать навигационные навыки для ИИ снаружи».

Куда именно следует встраивать ИИ?

ИИ наиболее полезен там, где много данных и текста, много рутины, нужны прогнозы, поиск аномалий или интерфейс на естественном языке, отвечает на наш вопрос Бычков: «Есть ряд традиционных задач, которые ИИ делает эффективнее, чем человек. Во-первых, это ввод и обработка документов: распознавание “первички”, автоматическая классификация, получение структурированных данных. Во-вторых, поиск и помощь: копилоты, запросы к данным на естественном языке, подсказки в интерфейсе. Третье направление — прогноз и планирование: спрос, закупки, производство, движение денежных средств (ДДС), предиктивное обслуживание. Также ИИ хорошо справляется с контролем качества данных и аномалий: выявление дублей, ошибок ввода, отслеживание брака и выявление мошенничества. Полезен ИИ и для маршрутизации и приоритизации: классификации обращений, выбора следующего шага, распределения задач по исполнителям. Хорошо ИИ помогает в генерации контента: составлении черновиков писем, коммерческих предложений, документации, ответов поддержки. Также ИИ эффективен в разработке и эксплуатации — довольно широко применяется в ассистентах кодирования, разборе системных журналов, техподдержке».

Илья Бычков: «В системе нужно найти место, где ИИ применим и экономически обоснован, и не пытаться встраивать его куда попало»

Бычков выделяет три уровня возможного встраивания ИИ в обычные бизнес-приложения: «Первый — слой “над” системой: копилоты, запросы на естественном языке, аналитика. Этот слой не затрагивает ядро приложения, внедряется быстро и безопасно, поэтому это отличная точка для старта ИИ-трансформации. Второй слой — сервисы “внутри” или “рядом” с системой: распознавание, прогнозирование, классификация. Они подключаются через вызовы API и расширения, и именно здесь ИИ встраивается в прикладные модули. Также есть слой “под” системой: данные, СУБД, инфраструктура. Здесь ИИ эффективен для разбора системных журналов, мониторинга, контроля качества данных».

Что касается конкретных систем, то подход, по мнению Бычкова, может быть таким: «ИИ в ERP можно применять для распознавания и проведения первички, планирования закупок, производства и ДДС, контроля качества данных, а также в виде копилотов для отчетности. ИИ в CRM — это скоринг и приоритизация лидов, выбор следующего шага, черновики писем и коммерческих предложений, суммаризация истории клиента. ИИ в MES — контроль качества и выявление брака, проактивное обслуживание оборудования, разбор системных журналов технологических систем. ИИ в workflow и СЭД — классификация и маршрутизация обращений и документов, автоматическая подготовка черновиков ответов, подсказки по регламентам. Общий принцип такой: в системе нужно найти место, где ИИ применим и экономически обоснован, и не пытаться встраивать его куда попало».

Дмитрий Богомолов: «ИИ можно применять там, где возможная ошибка не критична, результат легко проверить, а окончательное решение остается за человеком»

Дмитрий Богомолов, руководитель по развитию и внедрению ИИ Prime Finance, рекомендует искать сценарии для встраивания ИИ не внутри отдельных модулей, а на «стыках» систем и людей: «Именно там обычно и скапливается рутина: найти данные в ERP или CRM, поднять документ в СЭД, сопоставить информацию из нескольких источников, классифицировать ее и подготовить результат для принятия решения. ИИ можно применять там, где возможная ошибка не критична, результат легко проверить, а окончательное решение остается за человеком. И не стоит встраивать ИИ куда только можно. Сначала нужно понять сам процесс и найти узкое место, а потом выбирать инструмент. ИИ лучше работает с неструктурированной информацией и вариативными задачами, RPA — с повторяющимися действиями, BI помогает увидеть результат. В связке они могут дать хороший эффект, но тащить весь набор технологий в каждый процесс точно не нужно. Если процесс можно надежно описать правилами, обычная автоматизация часто справится с ним быстрее, дешевле и с большей предсказуемостью, чем ИИ».

В разных отраслях набор систем, модулей или функций, куда имеет смысл встраивать ИИ, будет разным, уверен Агапеев, поэтому полезно определить критерии, по которым выбирать подходящие задачи: «Задача подходит для ИИ, если одновременно выполняются три условия: входные данные неструктурированы либо их объем превышает человеческую способность их обработать; результат можно проверить, и есть источник для сверки; цена ошибки ограничена либо действие можно отменить с небольшими затратами. Если хотя бы одно условие не выполняется, встраивать ИИ не стоит. Этот фильтр сразу отсекает популярные в презентациях сценарии вроде “умного согласования бюджета” или “ИИ считает себестоимость”».

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

Другой подходящей, по мнению Агапеева областью применения ИИ является поиск и объяснение состояния — подготовка ответов на вопросы вроде «почему заказ встал», которые снимают нагрузку с первой линии поддержки и аналитиков, работающих «интерфейсами» между бизнесом и ИТ. «В системах workflow ИИ поможет приоритизировать очередь: он может отсевать заведомо понятные случаи, чтобы человек разбирал спорные. В производственных системах это прогноз отклонений качества и проактивное обслуживание, причем здесь речь идет о “классическом” машинном обучении, а не о языковых моделях, и все упирается в качество телеметрии. В CRM — извлечение фактов из переписки в карточку, подготовка черновиков коммуникаций и скоринг клиентов, — добавляет эксперт. — Важно разделять подсказку и действие. В первом случае человек остается в контуре, а ценой ошибки будет потерянное время. Во втором в контуре остается система, а ценой ошибки будут деньги и обязательства. Эти два сценария предъявляют разные требования к надежности, тем не менее, часто бывает так, что их смешивают в одном “пилоте”, а затем удивляются результату».

Принципы и правила встраивания ИИ

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

Артем Селезнев: «Работайте с ИИ как с хорошим и ответственным стажером»

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

С точки зрения Бычкова, ключевое правило — подключать ИИ как изолированный сервис, чтобы отказ или деградация модели не приводили к сбою основной системы: «Обязательно должны быть предусмотрены резервный сценарий на случай отказа ИИ, человек в контуре для выполнения критичных действий и заранее просчитанная “экономика” внедрения. При таком подходе ключевые свойства системы не деградируют, а усиливаются: система остается предсказуемой и управляемой, а ИИ добавляет ей новую ценность».

Недетерминированный компонент не должен находиться на критическом пути — такое главное правило формулирует Агапеев: «Отказ или деградация модели должны означать, что система продолжает работать как раньше, только без подсказки. Так ли это, можно проверить тестом на отключение. Следовательно, ИИ должен записывать данные посредством тех же интерфейсов, что и человек, и тогда валидация, права доступа и журналирование наследуются, а не создаются заново в обход существующих механизмов контроля. У агента должна быть собственная учетная запись, а его права не должны превышать прав инициатора операции, в противном случае первая же вредоносная инъекция в промпт превратит ассистента в универсальный способ обойти разграничение доступа. Есть и другое важное правило: каждое автономное действие требует обратимости и лимитов — компенсирующей операции и ограничений по сумме, количеству и области применения. Каждый артефакт должен быть прослеживаемым: какая модель и ее версия использовались, на каком контексте, кто подтвердил результат. Без этого невозможно ни разобрать инцидент, ни отозвать задним числом решения, принятые с дефектной версией модели».

Агапеев обращает внимание еще на несколько аспектов, которые нередко упускают: «Расход на инференс — это параметр архитектуры, а не счет, который приходит потом. К тому же агентный цикл, где модель сама решает, какие инструменты вызвать и сколько раз, потребляет в продуктиве на порядок больше, чем в “пилоте”. Поэтому оценивать нужно стоимость одной бизнес-операции при пиковой нагрузке. Кроме того, метрики нужно снимать с бизнес-операции, а не с модели, и не точность классификатора, а долю документов без ручного касания, время цикла, долю переделок. Причем базовую линию нужно зафиксировать до внедрения, иначе эффект принципиально недоказуем. Наконец, модель должна оставаться за абстракцией, а интерфейсы — открытыми, чтобы смена поставщика не потребовала переписывания интеграционного модуля. Gartner прогнозирует, что к концу 2027 года более 40% агентных ИИ-проектов будут закрыты из-за роста издержек, неясной ценности и недостаточного контроля рисков. Исследование инициативы NANDA в MIT показывает, что 95% “пилотов” генеративного ИИ не дают измеримого эффекта. Следовательно, проблема не в ИИ как таковом, а в подходе: сначала нужно понять, какой процесс мы меняем и зачем, и только потом выбирать модель».

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