У ИИ-ассистента сервисного центра из примера ниже 16 800 евро чистого эффекта в месяц превращаются в 4 800, если проверять придётся каждый третий ответ вместо каждого десятого. Цена модели в этом расчёте почти ничего не решает. Маржа ИИ-продукта тает в эксплуатации: на проверке, мониторинге, облаке и людях вокруг модели.
В отдельном пилоте этих расходов почти не видно. Проблема проявляется, когда у компании десять или двадцать ИИ-инициатив сразу, и бюджет на эксплуатацию начинает расти быстрее, чем масштабируемая бизнес-ценность.
Корпоративное моделирование ИИ закрывает этот разрыв. Оно шире финансового обоснования отдельных проектов: с его помощью компания видит, где ИИ создаёт ценность, как эта ценность складывается в портфель инициатив и как одновременно управлять выгодой, затратами, рисками и компетенциями.
От обычного ПО корпоративный ИИ отличается в нескольких местах. Каждый ответ модели (инференс) стоит денег, и сумма зависит от нагрузки. Модель иногда ошибается. Людей нужно больше, и квалификация выше. Поэтому и экономику приходится считать по-другому.
Портфель важнее отдельного проекта
Многие компании до сих пор относятся к ИИ как к набору отдельных фич. На практике ИИ перестраивает процессы целиком: решения готовятся иначе, интеллектуальный труд перераспределяется, риски возникают в новых точках, а затраты смещаются от разовой разработки к постоянной эксплуатации. Изолированный бизнес-кейс под каждого ассистента или классификатор этого не покажет.
Хорошая модель показывает, как ИИ встроен в компанию. На какие процессы он влияет и на каких данных держится. Какие постоянные расходы и обязанности появляются. И чему компании нужно научиться, чтобы удачный эксперимент можно было повторять.
Как только инициативы появляются в нескольких подразделениях, встают одни и те же вопросы. Какие проекты дают быстрый ROI, а какие строят компетенции надолго? Какие затраты незаметны в пилоте и становятся главными в эксплуатации? Где строить общую платформу, а где хватит точечного решения? Ответ на любой из них меняет ответы на остальные, поэтому и считать их приходится вместе.
Пользы от отдельного успешного проекта мало, если его нельзя повторить. Выигрыш появляется, когда компания замечает похожие задачи, использует уже сделанное повторно и вкладывает деньги в общие решения. Пример: три команды независимо строят поиск по внутренним документам для юристов, поддержки и продаж. Каждая платит за свою векторную базу, свой набор для оценки качества и свою настройку доступа. Портфельный взгляд видит одну платформу и три интерфейса над ней.
Три группы инициатив требуют разных ожиданий
Хорошая карта портфеля делит инициативы на три типа. Первый тип: эффективность и автоматизация. Сюда входят обработка документов, суммаризация, классификация, маршрутизация обращений, поиск аномалий. Эффект виден быстро: меньше ручной работы, короче цикл обработки, меньше очередей.
Второй тип: усиление работы человека. Ассистенты, копилоты, рекомендации внутри рабочих процессов. Ценность здесь возникает меньше из экономии и больше из качества решений и производительности, поэтому измерять её сложнее.
Третий тип: стратегические продукты и платформы. Новые источники выручки, собственные доменные модели, платформы данных, партнёрские экосистемы, которые меняют положение компании на рынке. Отдача здесь длинная, риск высокий.
Разделение нужно, чтобы не требовать быстрого ROI от долгих ставок и, наоборот, не оставлять стратегические инициативы без экономической дисциплины.
Возьмём портфель из двенадцати инициатив. Если девять из них про автоматизацию, две про ассистентов и одна стратегическая без посчитанной стоимости инференса, компания получит много мелких побед и ни одной позиции, которую трудно скопировать. Если наоборот, половина бюджета уходит на ставки, которые окупятся через три года, а операционные проекты, оплачивающие эту паузу, недофинансированы.
Готовой пропорции нет. Но если хотя бы одна из трёх групп пуста, это повод для разговора на уровне руководства.
Отсюда и требование к выбору сценариев. ИИ должен усиливать то, чем компания уже отличается: уникальные данные, процессную дисциплину, доменную экспертизу, особый доступ к клиенту. Кто внедряет ИИ там, где проще всего собрать демо, получает много проектов и мало стратегического выигрыша. Если разложить инициативы по ценности, риску и сроку отдачи, разговор становится предметнее. Вопрос звучит так: где при реалистичных допущениях ИИ даст больше всего?
Сколько на самом деле стоит пилот на 40 000 обращений
Главное различие между классическим софтом и корпоративным ИИ лежит в стоимости обслуживания. В обычном ПО экономика вращается вокруг разработки и продаж. У ИИ добавляются постоянные и плавающие расходы. Это оплата каждого запроса к модели, которая зависит от объёма текста. Поиск по базе знаний и хранилища для него. Работа инженеров, которые держат модели в рабочем состоянии (MLOps). Мониторинг, контроль того, не стала ли модель хуже со временем (дрейф), и повторное обучение.
Часто сюда же входят проверка человеком, меры безопасности и дополнительные циклы оценки качества. Именно эти переменные решают, останется пилот впечатляющим или станет масштабируемым.
Поэтому ROI нельзя подавать как размытую историю про эффективность. Убедительная модель различает четыре вида выгоды: прямое снижение затрат, прирост производительности, стратегические преимущества (удержание, кросс-продажи, снижение регуляторного риска) и дополнительную выручку.
Каждая категория привязывается к операционному показателю. «Больше эффективности» на KPI не тянет. «На 20 процентов меньше времени на одно обращение при сохранении качества» уже тянет. С удержанием так же: снижение оттока после запуска сценария остаётся наблюдением, пока вы не оценили вклад сценария и не сопоставили дополнительную прибыль с затратами.
Как это выглядит в цифрах, покажем на условном примере. Сервисный центр обрабатывает 40 000 обращений в месяц, на каждое уходит в среднем 8 минут. ИИ-ассистент сокращает это время на 20 процентов, то есть на 1,6 минуты. В сумме это 64 000 минут, около 1 067 часов. При стоимости часа оператора 30 евро экономия составит примерно 32 000 евро в месяц.
Теперь затраты. Инференс по 0,03 евро на обращение даёт 1 200 евро. Проверка человеком 10 процентов ответов по 3 минуты занимает 200 часов, это 6 000 евро. Мониторинг, MLOps и поддержка обходятся в 8 000 евро в месяц. Итого 15 200 евро затрат и около 16 800 евро чистого эффекта.
В одну строку расчёт выглядит так:
Чистый эффект = обращения × сэкономленные минуты ÷ 60 × стоимость часа, минус (инференс + проверка человеком + эксплуатация)
40 000 × 1,6 ÷ 60 × 30 = 32 000 евро выгоды, затраты 1 200 + 6 000 + 8 000 = 15 200 евро, на выходе 16 800 евро в месяц. В строку удобно подставлять свои цифры. Самые чувствительные переменные в ней: доля проверки и стоимость часа.
Если качество требует проверять не 10, а 30 процентов ответов, затраты на проверку вырастают до 18 000 евро, общая сумма до 27 200, и чистый эффект падает до 4 800 евро. Цена инференса при этом могла бы упасть вдвое, и это сэкономило бы всего 600 евро. Пилот на 2 000 обращений этого не покажет: в нём проверяет всё один аналитик, а фиксированные расходы на эксплуатацию ещё не появились.
Так расчёт юнит-экономики из упражнения с калькулятором превращается в инструмент для решений. Он заставляет проговорить допущения, прикинуть реальную нагрузку и посчитать, как будут расти затраты. Становится видно, что дешёвый пилот под реальной нагрузкой дорог, что модель с высокой потребностью в проверке не держит маржу, а небольшое изменение длины контекста переворачивает экономику.
Ценность проверяют в нескольких измерениях
Юнит-экономика на бумаге ещё не доказывает, что сценарий работает в жизни. Частая ошибка: закрыть вопрос одним A/B-тестом, как при обычной продуктовой оптимизации. ИИ обычно меняет сразу несколько вещей: поведение пользователей, скорость обработки, характер ошибок, частоту эскалаций, доверие, стоимость обслуживания, иногда и распределение ролей между человеком и системой.
Офлайн-метрики тоже подводят. Модель, которая точнее на тестовом наборе, но отвечает на секунду медленнее, может проиграть в работе: оператор не дождётся подсказки и ответит сам, и в отчёте окажется хорошая модель, которой почти никто не пользуется.
Поэтому проверка идёт в несколько шагов. Офлайн-оценка показывает качество модели в контролируемых условиях. Управляемый пилот в реальной среде показывает поведение людей и процессов. Анализ ценности на уровне задач связывает качество модели с бизнес-показателями.
И нужно наблюдение на длинной дистанции. Хеннинг Хонхольд и коллеги из Google показали на KDD в 2015 году, что краткосрочный эффект эксперимента может расходиться с долгосрочным, потому что пользователи адаптируются.
Для ИИ-ассистента это особенно заметно: в первые недели люди проверяют каждый ответ, через три месяца привыкают и начинают доверять слишком сильно. Отсюда практическое правило: держать в карточке инициативы метрику доверия, например долю ответов, которые операторы правят, и смотреть её помесячно. Если через три месяца правок стало вдвое меньше, а частота ошибок модели на контрольной выборке не изменилась, ослабла проверка, и модель тут ни при чём.
Между пилотом и масштабом лежит платформа
Компании часто путают активность с трансформацией. Двадцать пилотов ещё не означают корпоративной способности работать с ИИ. Устойчивое развитие проходит три этапа.
На первом этапе компания закладывает основы: подбирает процессы, запускает пилоты для проверки ценности, проверяет доступность данных и смотрит на раннее поведение моделей. Цель этапа в обучении, расширяться вширь пока рано.
Второй этап посвящён порядку. Появляются общие инструменты: каталог моделей, единые способы оценки качества, общие хранилища данных, правила работы с данными, контроль качества моделей, процессы безопасности и соответствия требованиям. Только здесь разрозненная работа превращается в систему, которую можно повторять.
Многие недооценивают этот отрезок и думают, что между пилотом и масштабом лежит прежде всего бюджет. Чаще не хватает общей платформы.
Код самой модели в промышленной ML-системе занимает скромную долю. Остальное приходится на сбор и проверку данных, конфигурацию, мониторинг и инфраструктуру обслуживания, и именно эта часть строится на втором этапе.
На третьем этапе начинается масштабирование. ИИ встраивается в подразделения, входит в многошаговые процессы и переиспользуется между семействами моделей. Здесь решается, получает ли компания портфельные преимущества или просто множит проекты. Узким местом становятся зрелая продуктовая функция, понятное управление и общие стандарты, и их уже приходится считать частью самой бизнес-модели.
Простой признак перехода между этапами: сколько времени уходит на запуск следующего сценария. Если каждый новый пилот снова начинается с поиска данных, выбора векторной базы и сборки набора для оценки, компания всё ещё на первом этапе, сколько бы пилотов ни шло. Если новый сценарий собирается за недели из готовых блоков, второй этап пройден.
Компетенции заканчиваются раньше, чем возможности моделей
Многие программы упираются в нехватку людей раньше, чем в ограничения моделей. Продакт-менеджерам нужны грамотность в ИИ, понимание данных, навык моделирования затрат, логика оценки качества, знание этических и регуляторных ограничений и умение координировать несколько функций.
Без этого ИИ остаётся для продакта чёрным ящиком: впечатляет, но его невозможно ни приоритизировать, ни вести экономически.
Грамотность здесь проверяется без экзамена. Продакт должен сам пересчитать пример с сервисным центром при другой доле проверки и объяснить, откуда взялась каждая строка затрат. Если для этого нужен аналитик, решение о масштабировании фактически принимает аналитик.
Не менее важны инженерные компетенции. Работа под большой нагрузкой, контроль качества модели во времени, автоматическое повторное обучение, мониторинг и связка нескольких моделей в одном процессе к излишествам не относятся. От них зависит, останется ли система стабильной, безопасной и экономически оправданной. Аналитики данных и специалисты по качеству дополняют картину. Они готовят наборы для проверки, разбирают типы ошибок, задают пороги качества и проверяют модель на предвзятость и выдуманные ответы (галлюцинации).
Профили компетенций команды полезно формализовать заранее, чтобы пробелы были видны до провала программы. Зрелые организации строят системы обучения: внутренние академии, лаборатории, профессиональные сообщества, базы знаний, симуляции. Так ИИ перестаёт быть вотчиной нескольких специалистов, от отпуска которых зависит весь портфель.
Управление рисками считают в той же модели, что и затраты
Управление ИИ (governance) часто воспринимают как тормоз. Как только ИИ влияет на критичные решения, чувствительные данные или регулируемые процессы, оно становится частью бизнес-модели.
Сюда входят учёт данных, описание моделей, правила проверки человеком, оценка рисков и возможность задним числом узнать, какая версия модели что решила. Эти механизмы добавляют работу, но предотвращают более дорогой ущерб: галлюцинации в ответах клиентам, нарушения требований, несправедливые решения, дрейф, злоупотребления, взрывной рост затрат под нагрузкой.
Отдельную бюрократию для этого изобретать не нужно. Достаточно, чтобы у каждой инициативы появилась карточка рисков с оценкой вероятности, ценой ошибки и владельцем, и чтобы карточки пересматривались вместе с бюджетом каждый квартал.
Важно, чтобы риски не оставались абстракцией. Смоделируйте категории: галлюцинации и неточности, приватность и хранение данных, регуляторные риски, деградация модели, злоупотребления, смещение, волатильность затрат. Каждая влияет на ценообразование, границы продукта, уровни сервиса и допустимую глубину автоматизации.
Вернитесь к примеру с сервисным центром: доля проверяемых ответов (10 или 30 процентов) и есть решение о риске, и стоит оно 12 000 евро в месяц. Поэтому управление рисками нельзя ставить галочкой задним числом. Без него ИИ нельзя считать надёжной частью работы компании.
Цена ошибки бывает и крупнее. В 2021 году Zillow закрыла направление Zillow Offers, которое покупало дома по алгоритмическим оценкам, и списала около 304 миллионов долларов. Это не история про плохую модель. Это история про портфель, в котором не было ограничения на объём ставок при росте ошибки прогноза.
Для портфеля отсюда следует простое ограничение. У инициатив, где модель сама принимает денежные решения (покупает, кредитует, назначает цену), в карточке должен стоять лимит объёма, который автоматически снижается, если ошибка прогноза выходит за заранее записанный порог. Такой лимит стоит дешевле любой дополнительной точности модели и срабатывает даже тогда, когда никто ещё не заметил, что рынок изменился.
Нужна ли портфельная модель при пяти пилотах?
Тут обычно возражают: портфельное моделирование требует времени, а рынок ИИ меняется каждые полгода. Цены на инференс падают, появляются новые модели, и подробная модель затрат устаревает раньше, чем её утвердят. Не проще запустить двадцать быстрых пилотов на готовых API и посмотреть, какие выживут?
На ранней стадии с этим трудно спорить. Если у компании три-пять инициатив, каждая работает на внешнем API, у них нет общих данных и стоимость эксплуатации укладывается в пару процентов ИТ-бюджета, полная портфельная модель избыточна. Достаточно простой таблицы: сценарий, владелец, метрика, стоимость в месяц.
Ситуация меняется в трёх точках. Первая: хотя бы три инициативы используют одни и те же данные или один набор для оценки, и раздельная разработка удваивает затраты. Вторая: суммарная стоимость эксплуатации растёт быстрее, чем подтверждённая экономия, как в примере с проверкой 30 процентов ответов. Третья: инициатива касается регулируемого процесса, где ошибка обходится дороже, чем вся программа. В любой из этих точек пора переходить от списка пилотов к портфелю.
Единая модель вместо набора срезов
Полноценная модель состоит из нескольких слоёв, сведённых вместе. Стратегический слой показывает, чем компания отличается от других и какие долгие ставки делает. Слой устройства показывает, как связаны данные, модели и то, что видит пользователь.
Финансовый слой фиксирует стоимость обслуживания, повторное обучение, юнит-экономику, маржу, ROI и срок окупаемости. Слой управления отвечает за соответствие требованиям, безопасность и документацию. Слой квалификаций показывает, какие способности развивать. Слой экспериментов связывает офлайн-оценку, онлайн-проверку и валидацию бизнес-кейса. Без такой сборки моделирование ИИ остаётся ещё одной таблицей.
Минимальная карточка инициативы для такой модели умещается в шесть строк:
- группа портфеля: автоматизация, усиление человека или стратегическая ставка;
- владелец и операционная метрика, к которой привязана выгода;
- месячная стоимость эксплуатации под реальной нагрузкой (инференс, проверка, MLOps);
- доля ответов, которые проверяет человек, и цена одной ошибки;
- данные и наборы для оценки, общие с другими инициативами;
- главные риски с оценкой и владелец каждого.
Для сервисного центра из примера такая карточка заполняется за полчаса. Группа: автоматизация. Владелец: руководитель поддержки, метрика: минуты на одно обращение. Эксплуатация: 15 200 евро в месяц при 40 000 обращений. Проверка: 10 процентов ответов, а цена ошибки складывается из повторного обращения клиента и ещё одной работы оператора. Общие данные: база знаний поддержки, на которую уже смотрит отдел продаж. Главный риск: дрейф качества после смены тарифов, владелец: аналитик качества. Карточка короткая, но по ней уже видно, где сидит основная стоимость и кто отвечает, если доля проверки поползёт вверх.
Начать можно с одного упражнения. Разложите текущий список ИИ-инициатив по трём группам портфеля и у каждой запишите месячную стоимость эксплуатации под реальной нагрузкой. Обычно почти всё оказывается в автоматизации, у стратегических проектов стоимость не посчитана, а две-три инициативы, которым нужны одни и те же данные, строятся раздельно. С этих двух-трёх и начинается второй этап.