Чем успешнее ИИ-пилот, тем быстрее бизнес хочет его масштабировать. Но именно на этом этапе скрытые компромиссы превращаются в реальные расходы и риски. Что нужно проверить до запуска, знает Георий Шатиров (К2Тех)
Почему красивое демо за две недели при масштабировании легко превращается в дорогого Франкенштейна? И что проверить, прежде чем дать ИИ тысячу пользователей, доступ к корпоративным данным и собственный бюджет?
Представьте: ИИ-команда показывает демо на десяти пользователях - все работает быстро и точно. Но документы загружены вручную, часть задач решается через внешний API, а разработчик подстраховывает модель. Руководитель предлагает уже в этом квартале подключить тысячу сотрудников, CRM и договоры.
И тут начинается настоящий проект. Неудачный пилот обычно умирает дешево. Удачный получает бюджет и при масштабировании вскрывает незаметные прежде проблемы.
Разберем, как не принять хорошее демо за готовую систему и как компромиссы пилота превращаются в ИИ-долг - в данных, безопасности, инфраструктуре и деньгах. Релевантный результат можно получить только из релевантных данных
Один из самых частых советов при внедрении ИИ - "сначала приведите в порядок данные". Но заниматься этим можно годами. Важнее понять, есть ли в корпоративных источниках ответы на реальные вопросы сотрудников.
Мы делали чат-бота для службы поддержки финансовой компании: загрузили официальные инструкции, настроили поиск по базе знаний и запустили пилот. Результат улучшился всего на 3-4%, хотя технически все работало: система находила документы, формулировала ответы и давала ссылки на источники.
Оказалось, проблема в самих данных. Сотрудники и раньше редко пользовались инструкциями, предпочитая спрашивать старших коллег: в документах не было ответов на многие реальные вопросы.
Поиск по базе знаний с передачей найденной информации ИИ-модели - этот подход называют RAG - не делает данные полнее или актуальнее. Он лишь помогает быстрее найти то, что уже есть. Если инструкция устарела, ИИ не исправит ее, а убедительно перескажет старую информацию.
Еще одна проблема - разные "версии правды". В одной системе клиент может быть записан по ИНН, в другой - по названию компании, в третьей - по номеру договора. ИИ способен скрыть эти расхождения за связным и уверенным ответом.
Поэтому для корпоративной базы знаний важно определить, кто отвечает за каждый источник, когда и как часто он обновляется и какой документ считать главным, если данные расходятся. Как понять, что вы готовы запустить пилот?
Возьмите 50-100 реальных вопросов пользователей из обращений в поддержку, чатов, звонков или писем. Для каждого попробуйте найти утвержденный источник ответа. Если значительная часть знаний существует только "в голове у Маши", сначала нужно собрать и систематизировать их, а уже потом подключать к ним ИИ.
Что проверить:
Есть ли в утвержденных источниках ответы на реальные вопросы пользователей?
Кто отвечает за актуальность каждого ключевого источника?
Какой источник считается главным, если данные противоречат друг другу?
Можно ли показать пользователю источник ответа и быстро исправить ошибку в нем? Подключите информационную безопасность еще при проектировании
Часто специалистов по информационной безопасности (ИБ) подключают только после успешного пилота, когда бизнес уже решил масштабировать проект. И тут возникают вопросы: какие данные передаются внешней ИИ-модели, где они хранятся и что произойдет при утечке.
С ИИ-агентами рисков еще больше. Они способны не только отвечать на вопросы, но и выполнять действия: отправлять письма, менять данные в CRM - системе для работы с клиентами - или запускать рабочие процессы. Поэтому контролировать нужно и данные, и полномочия ИИ.
Многие проекты останавливаются именно на согласовании с ИБ. Поэтому специалистов по безопасности стоит привлекать еще на этапе проработки идеи.
Простой запрет внешних ИИ-сервисов проблему не решает. В одной компании разработчики писали часть кода на личных ноутбуках, отправляли его себе в рабочий мессенджер и только потом переносили в защищенную корпоративную среду. Формально внутри нее все было безопасно, но часть работы происходила за ее пределами.
Полностью запретить сотрудникам использовать ИИ сложно: они будут искать обходные пути. Поэтому компании важно оценить риски и дать им удобную безопасную альтернативу. Например, у нас внутренним ИИ-сервисом пользуются более 70% сотрудников, поскольку с ним разрешено работать с корпоративными данными.
Что проверить:
Какие данные и в какие ИИ-модели разрешено передавать?
Есть ли у сотрудников удобная разрешенная альтернатива внешним сервисам?
Сохраняется ли история запросов, ответов и действий ИИ?
Что ИИ-агент может делать самостоятельно, а для чего требуется подтверждение человека?
Можно ли быстро закрыть доступ, заменить модель или остановить сценарий без перестройки всей системы? Проверьте, выдержит ли решение реальную нагрузку
Пилот на десять пользователей работает в комфортных условиях: нагрузка невелика, разработчик рядом, странный ответ можно быстро проверить, а недостающий документ - загрузить вручную.
При тысяче пользователей мелкие проблемы становятся системными. Возникают очереди запросов, перегрузки, долгое ожидание ответа и сбои отдельных компонентов. Для бизнеса это означает задержки, недоступность сервиса в часы пик, срыв операций и дополнительные расходы на поддержку.
Поэтому перед масштабированием недостаточно измерить точность модели. Нужно оценивать работу всего сервиса: время ответа, долю ошибок и стоимость успешно выполненной операции. Для ИИ-агентов важно также понимать, какую долю задач они правильно выполняют целиком - от получения задания до результата.
Что проверить
Есть ли набор реальных задач, на котором можно проверять каждую новую версию модели, инструкции для нее или базы знаний?
Какие показатели качества бизнес считает приемлемыми?
Что произойдет при пиковой нагрузке: запрос встанет в очередь, получит отказ или будет передан другой модели?
Кто первым заметит ухудшение работы - система мониторинга или пользователь?
Сколько стоит не отдельный запрос к ИИ, а одна успешно выполненная бизнес-операция? Считайте экономику операций, а не фонд оплаты труда
Плохая экономика часто начинается с идеи "заменим половину сотрудников". ИИ хорошо автоматизирует повторяющиеся операции, но работа человека почти никогда не состоит только из них.
Один из наших заказчиков хотел сократить половину секретарей. При зарплате 70 тыс. руб. экономия на двух ставках составляла 1,68 млн руб. в год без учета налогов. Мы обучили модель на архиве документов и получили точность 80%. Однако пилот стоил около 2 млн руб., а доработка и масштабирование потребовали бы еще 2-3 млн. Руководитель остановил проект: технически он работал, но вложения не окупались в разумный срок.
Поэтому лучше считать не число сотрудников, которых заменит ИИ, а стоимость конкретной операции до и после внедрения. Если дешевый запрос к модели требует дорогой ручной перепроверки, экономии может не быть.
Для этого можно использовать показатель "стоимость успешной операции". Он учитывает весь процесс, а не только расходы на работу ИИ-модели.
Простая формула:Эффект = количество операций × (стоимость операции до ИИ − стоимость успешной операции с ИИ) − постоянные расходы на систему.
В стоимость операции с ИИ нужно включать не только плату за использование модели, но и ручную проверку, инфраструктуру, поддержку и исправление ошибок.
Закрытый пилот - не провал. Гораздо хуже годами поддерживать проект только потому, что в него уже вложили деньги.
Что должно быть понятно:
Что именно автоматизирует ИИ: заявку, документ, звонок, отчет, договор или обращение?
Сколько такая операция стоит сейчас и сколько времени занимает?
Какую долю операций ИИ сможет выполнить без участия человека?
Сколько стоит ручная проверка ошибок и нестандартных случаев?
При каких результатах проект масштабируют, а при каких закрывают? После запуска у ИИ должен появиться хозяин
У обычной корпоративной системы есть владелец, правила обновления, поддержка и ответственные за ее работу. У ИИ-пилота часто есть только команда разработчиков. Для эксперимента этого достаточно, после запуска - уже нет.
Кто обновляет базу знаний, разбирается со сбоями, контролирует расходы на вычислительные мощности и может остановить систему? Без четкой ответственности она быстро устаревает. Новая версия ИИ-модели может изменить ее поведение, а обновление документов - повлиять на ответы. В итоге через полгода команда боится что-либо менять, потому что не знает, к чему это приведет.
Поэтому после пилота нужны правила управления ИИ-системой: кто за нее отвечает, кто может вносить изменения, как контролируются качество и расходы и когда систему нужно развивать, переделывать или закрывать. Такой подход называют AI Governance - системой управления ИИ в компании.
Признак зрелого подхода - управление не отдельными экспериментами, а всеми ИИ-проектами как единым портфелем. У каждого есть гипотеза, показатель эффективности, ограниченный бюджет на проверку, критерии успеха и ответственный. Неудачные идеи быстро закрывают, успешные получают ресурсы на развитие.
Что должно быть понятно
Кто со стороны бизнеса отвечает за результат, а не только за техническую часть?
Кто может менять модель, инструкции для нее, данные и связи с другими корпоративными системами?
Как фиксируются изменения и проверяется качество после них?
Кто контролирует расходы на работу системы и устанавливает лимиты?
Как часто решают, что делать с проектом дальше: развивать, переделывать или закрывать? Что проверить до первого пилота
Не стоит год строить идеальную инфраструктуру и только потом разрешать сотрудникам попробовать ИИ. Можно потратить много ресурсов на систему, которая в итоге никому не понадобится.
Лучше разделять эксперимент и полноценную корпоративную систему. Эксперимент может быть быстрым и временным, но его границы нужно определить заранее. Еще до старта важно понимать, какие вопросы придется решить, если пилот окажется успешным.
Что должно быть понятно
Какую операцию хотим изменить и как оцениваем ее эффективность сейчас?
Есть ли реальные запросы, документы или действия, на которых можно проверить ИИ?
Есть ли актуальные и достоверные источники информации и кто за них отвечает?
Какие данные разрешено передавать ИИ, что он может делать самостоятельно и где требуется участие человека?
Как система работает под реальной нагрузкой и как компания узнает об ухудшении ее работы?
Сколько стоит одна успешно выполненная операция с учетом проверки, инфраструктуры и поддержки?
Кто после пилота отвечает за качество, изменения, бюджет и решение остановить проект?
Если на два-три вопроса ответа пока нет, эксперимент можно продолжать. Но важно ограничить его бюджет и не обещать, что через месяц он превратится в готовую корпоративную систему.
Если же демо уже представляют внутри компании как готовый продукт, а на эти вопросы отвечают "потом разберемся", пилот начинает превращаться в того самого Франкенштейна.
https://www.rbc.ru/business/13/10/2026/6ac8d654182143263a5d7b9c