Внедрение ИИ в работу компании похоже на запуск ракеты: блестящий корпус и мощный двигатель впечатляют, но без четкого плана полета, надежной инфраструктуры и контроля траектории миссия обречена. Где чаще всего срываются запуски, как грамотно перейти от пилота к полноценному внедрению, почему не стоит гнаться за «самой мощной» моделью и зачем приручать теневой ИИ — «Эксперту» рассказал Роман Стятюгин, директор по ИИ‑продуктам VK Tech.
— Роман, как убедить совет директоров финансировать новую ИИ-инициативу после того, как несколько предыдущих провалились?
— Основной аргумент — это опыт, полученный в ходе пилотных проектов. Нужно показать: мы четко понимаем, что пошло не так. Первый проект — это скорее знакомство с технологией, а не инструмент достижения бизнес-целей. Мы объясняем, что в новой итерации мы переводим проект из категории исследований (R&D) в плоскость инженерной задачи. Это значит, что у нас есть четкий план, метрики и понимание пути из точки А в точку Б, что делает результат выполнимым.
— В 2025 г. исследование MIT (Массачусетского технологического института) показало, что 95% корпоративных ИИ-пилотов не дают измеримого результата, хотя инвестиции растут. В какой момент компания понимает, что тратит деньги впустую? И почему понимание приходит поздно?
— Часто главная проблема первых пилотов — размытые критерии успеха, отсутствие плана и метрик. Компания живет в «цикле ожидания»: вложили деньги, получили первый позитивный, но не финальный результат и начали цепляться за мысль: «осталось чуть-чуть» — протестировать еще одну модель, улучшить данные. Этот неконтролируемый процесс длится до тех пор, пока финансисты не поднимают флажок: прошел почти год, а результата нет. И только тогда приходится серьезно спрашивать: что мы делаем не так.
— Как сократить этот цикл?
— Нужно жестко формулировать критерии успеха на старте — по финансам, срокам и функционалу. Например, автоматизация саппорта. Целью должно быть не просто внедрение чат-бота, а повышение CSAT (удовлетворенности клиентов), скорости ответа или обработка большего потока запросов теми же сотрудниками. Всё это измеряется конкретными цифрами. Это и есть перевод из «исследовательского» проекта в «инженерный».
— Предположим, пилот показал отличные результаты, но проект забуксовал. На каком этапе теряется эффект?
— Существует огромный разрыв между пилотом и реальной эксплуатацией. Пилот — это, по сути, демонстрация в искусственных условиях: данные заранее подготовлены и очищены дата-сайентистами, выбраны определенные цепочки тестирования. В реальной жизни данные будут сырыми и некачественными, и на этом шаге вся экономика может развалиться, показатели качества упадут кратно. Для эффективной работы ИИ необходимы зрелые системы хранения и обработки данных, нужны автоматизированные пайплайны, системы контроля качества данных, возможность оценки внутреннего состояния системы. Это отдельные большие проекты, которые могут занять несколько месяцев.
На пилотах часто пропускают тестирование сложных сценариев, ограничиваясь только «счастливым путем» (Happy Path). Пилот позиционируется как быстрый — 8–12 недель, сложные кейсы и нагрузочное тестирование опускают ради экономии времени и денег.
Кроме того, пилоты часто создаются как «вертикальные» решения под одну задачу. Чтобы развернуть агента для другой задачи, приходится выстраивать всю вертикаль с нуля, вновь проходя через все риски. Поэтому сегодня бизнесу нужна платформа, которая универсализирует 70–80% работы, чтобы новые агенты делались быстро и по единым правилам.
— Что нужно закладывать в проект с самого начала, а не откладывать на потом?
— У нас есть организационный чек-лист для корпоративных внедрений. Необходим бизнес-оунер — человек, который понимает, на какие экономические метрики влияет агент, и готов вкладывать бюджет для достижения результата. Он должен понимать критерий успеха — конкретную метрику (скорость, уменьшение затрат, ROI).
Качество агента зависит на 50% от модели и на 50% от контекста. Нужно быть готовым тратить время на структурирование данных, переписывание инструкций, создание бизнес-глоссария. На примере внедрения агентов внутри VK Tech мы видели, что работа с данными занимает время, чтобы поднять точность ответов с 60–70% до приемлемого уровня.
Автоматизируемая зона должна быть структурирована, чтобы можно было проводить тесты и сравнивать показатели «до» и «после». Для пилота лучше выбирать более прозрачную и понятную зону. Критически важна безопасность — контроль действий агента, защита персональных данных. Лучше протестировать это уже на этапе пилота, чтобы избежать ошибок в продакшене.
Оценка технологической базы подскажет, есть ли готовые инструменты для быстрого старта или придется долго развертывать инфраструктуру.
— Есть мнение, что главное — выбрать модель помощнее. Близко к истине?
— Языковая модель — это база, но сама по себе она далека от автоматизации предприятия. Это алгоритм, но не сама система. Сейчас модели совершили суперкачественный скачок, и все последние версии значительно лучше предыдущих. Но сегодня главное — это обвязка вокруг модели, она дает автоматизацию.
Модели нужны инструменты, чтобы работать с внутренней предметной областью организации. Нужна интеграция с внутренними системами — CRM, ABS, MES. Модель должна работать в изолированных условиях под конкретную задачу, чтобы не навредить критическим системам. Важны библиотека навыков, накопление этих навыков внутри организации, передача их на уровень всей корпорации. Для многих кейсов не нужна мощная модель, потому что ответ формируется на основе документов компании, а собственные знания модели используются только для их саммаризации.
Также необходим семантический слой: онтология, бизнес-глоссарий, графовые связи между сущностями, чтобы модель понимала контекст именно нашей организации, а не общемировой, на котором она обучалась.
— Gartner прогнозирует, что к концу 2027 г. больше 40% agentic-проектов будут закрыты из-за роста затрат и слабого контроля. Получается, выигрывает не самый умный агент, а самый управляемый?
— Это ключевой вопрос. Агент — это модель плюс обвязка. Мы попадаем в западню: чем умнее агент, тем больше автономности хочется ему дать. Но автономия без контроля — это угроза безопасности. С другой стороны, избыточный контроль и детерминированность, может снизить гибкость и эффективность системы.
Решение — гармонизация, баланс. Нужно выделять зоны ограниченной автономности. Мы даем агенту доступ ровно к тем интеграциям и навыкам, которые нужны для конкретной задачи, а также вносим точки контроля в логику агента. Например, при обработке платежных документов, их обработка делегируется агенту, а сама оплата — через верификацию сотрудником.
— Насколько сложно компаниям нащупывать эти точки контроля?
— Сейчас в первую очередь автоматизируются низкорисковые, рутинные операции: подготовка типовых документов, разбор входящих запросов. В разработке автоматизируются отдельные этапы CI/CD, но архитектуру контролируют люди. Мы знаем, какой набор инструментов нужен агенту: модель, навыки, интеграции, ролевая модель, политики. Вопрос лишь в осторожности и проверке на безопасных процессах.
— Приведите пример метрики или сигнала, который служит тревожным звонком: агент делает что-то не так, систему нужно остановить?
— Это процесс наблюдаемости (observability) — логирование всех действий агента в реальном времени. Мы задаем норму: типовая задача решается за пять шагов и три обращения к модели. Если действия агента отличаются от нормы, входят в бесконечный цикл, мы останавливаем его через лимит попыток. Например, если агент не может ответить на вопрос пользователя после трех попыток, мы говорим: «Стоп, четвертый раз не пробуй, передай оператору». Это критично, чтобы попусту не тратить ресурсы.
— Подчас ИИ-проект заказывает IT-директор, а бизнес-подразделения узнают о нем постфактум. К чему это приводит?
— Инициативный IT-директор — всегда хорошо. Он понимает технологию и может определить оптимальный путь и даже подсказать бизнесу методологию старта. Плохо, когда это происходит в вакууме: если в реализации не задействованы другие эксперты из компании, проект не даст изменений. В цепочке должны быть как минимум три участника: автоматизатор (IT), бизнес-заказчик и служба безопасности. Только вместе они дают комплексный взгляд и правильную оценку результата.
— Сегодня много говорят про теневой ИИ. Что это такое и почему отсутствие корпоративного ИИ-решения превращает его в угрозу безопасности номер один?
— Теневой ИИ — это использование сотрудниками различных LLM-моделей под личными аккаунтами для выполнения рабочих задач. Риск — загрузка конфиденциальных данных вовне. Решение — не запрещать, а давать доступ к моделям через централизованный корпоративный контур. Это позволяет применить базовые политики безопасности, контролирует запросы и ответы.
Но это лишь гигиена. Следующий уровень — корпоративный ИИ, когда знания и навыки, полученные сотрудниками, не только хранятся в их персональных папках на компьютере, а валидируются и накапливаются на уровне компании, становясь ее капиталом. Создается библиотека навыков и централизованный контекст.
— Дорого ли обходится переход на корпоративные решения? Окупается ли?
— Зависит от сегмента. Для компаний критической инфраструктуры требования по безопасности, сертификации и контролю на порядок выше и дороже. Для рыночных компаний важнее масштабируемость инфраструктуры и решение конкретных бизнес-задач. Экономика складывается в рамках отдельного процесса или роли. Сейчас есть примеры, где агенты работают эффективнее сотрудников, но при этом обходятся дороже. Поэтому экономический эффект нужно считать в каждой конкретной ситуации, в зависимости от сегмента рынка и способа потребления.
