Почему для расчёта ROI ИИ компаниям не хватает данных

Руководство хочет масштабировать ИИ. Бюджеты растут в три раза, а внедрение ускоряется.

Затем CFO задаёт вопрос, который сегодня звучит почти на каждом совете директоров: какие из этих инициатив действительно прибыльны?

Большинство организаций не могут ответить на этот вопрос не потому, что не видят затраты, а потому, что имеющиеся данные о затратах изначально не были предназначены для такого ответа.

Уроки, извлечённые из управления расходами на cloud, не решат проблему ИИ и ROI. Да, cloud научил целое поколение CFO тому, что биллинг без бизнес-контекста — это шум. Поэтому для расчёта ROI cloud они соединяли два набора данных: данные о затратах и бизнес-данные. AWS показывает, какой именно счёт, регион, тег и ресурс используются. Если добавить сопоставление клиентов и продуктов, ROI расходов на cloud становится понятнее.

Но с ИИ всё сложнее. Здесь нужны три источника данных: затраты, бизнес и telemetry — автоматический сбор данных из разнородных источников, который помогает увидеть общую картину того, что произошло и почему. Руководитель или инженерный лидер может иметь счета от AI-провайдера и выручку по клиентам. Но связать это с бизнес-ценностью они не могут. Количество tokens в счёте OpenAI не показывает, какой клиент вызвал какой вызов, какой feature он обслужил и дал ли prompt бизнес-результат. В биллинге провайдера этих данных нет.

AI-провайдеры не исправят эту проблему

Ситуация вряд ли изменится в ближайшее время, потому что AI-провайдеры не занимаются распределением затрат предприятия по его клиентам. Их бизнес — продавать tokens. Та гранулярность, которую они показывают, соответствует их биллинговым системам, а не требованиям CFO.

Не убеждает? Сравните, что даёт AWS, и что даёт AI-провайдер.

Биллинг AWS раскрывает resource IDs, иерархию аккаунтов, регион, SKU, метаданные тегов и использование по минутам. Каждый доллар можно отнести к workload, команде или сегменту клиентов, если всё было правильно размечено тегами. Этих данных достаточно, чтобы зрелые команды FinOps выстраивали unit economics уже много лет.

Счёт AI-провайдера даёт только tokens, потреблённые моделью, с опциональной группировкой по API key. Вот и вся детализация. Нет привязки на уровне запроса. Нет customer ID. Нет сопоставления с feature. Нет результата prompt. Нет идентификации retry. Многошаговые agent workflows сводятся к одному числу tokens. Представьте, что крупный банк получает ежемесячный счёт на несколько миллионов долларов за ИИ, но не видит, какие части бизнеса породили какие части затрат, и потому не может распределить их.

Если enterprise хочет понять, какие затраты на ИИ привели к какому клиенту или feature, он должен собирать эти данные сам — внутри приложения, до того как запрос покинет его.

Три обязательных источника

Измерение ROI ИИ требует трёх источников данных, сведённых в единую модель.

1. Данные о затратах, нормализованные между провайдерами. Каждый AI-провайдер показывает затраты по-своему. У OpenAI один taxonomy, у Anthropic — другой, у поставщиков fine-tuning и inference platforms — свои. Затраты на cloud GPU отражаются в биллинге AWS или Azure. Расходы на vector database приходят в счетах Pinecone или Snowflake. По умолчанию ничто из этого не совместимо. Нормализация необходима, но её недостаточно. Она сведёт все ваши ИИ-затраты к одной schema. Но она не покажет, что они дали на выходе.
2. Telemetry на уровне приложения. Это источник, которого не хватает большинству компаний, и именно он делает ROI ИИ структурно отличным от ROI cloud. Здесь нужно instrumenting AI calls внутри приложения по шести категориям: трассировка на уровне запроса, привязанная к customer ID или session ID; attribution к product surface, который вызвал вызов; захват шагов agent для многошаговых workflows; идентификация retry и fallback, чтобы затраты на восстановление не относились к основным вызовам; логирование выбора модели с фиксацией того, какая модель была выбрана и почему; и фиксация результата, которая связывает каждый вызов с тем, дал ли он бизнес-ценность. В биллинге провайдера этих данных нет. Всё это нужно собирать в момент вызова и хранить в системе, которую можно свести с данными о затратах.
3. Бизнес-данные. Выручка, сегменты клиентов, иерархии продуктов и использование features. Те же бизнес-данные, которые уже питают ваш CRM и аналитический стек, но сопоставленные с клиентами и features, к которым telemetry-слой привязывает вызовы.

Если свести эти три источника вместе, появляются unit economics, которые сегодня нужны для каждого решения об инвестициях в ИИ: стоимость одного взаимодействия с клиентом, margin по feature, прибыльность agent workflow, ROI по выбору модели. Ни один из этих показателей нельзя посчитать только по биллингу. Ни один нельзя посчитать только по telemetry. Нужны все три источника, смоделированные вместе так, чтобы затраты можно было связать с результатом.

Почему agentic ИИ делает это срочным

Один запрос — один вызов, одна стоимость, один клиент, один результат — это простой случай.

Agentic workflows устроены иначе. Agent разбивает задачу на несколько шагов. На каждом шаге вызывается модель. Некоторые шаги переключаются на другую модель, если первая не сработала. Некоторые — повторяются после плохого результата. Некоторые шаги вызывают внешние tools, которые сами стоят денег. Один пользовательский запрос может породить десятки inference calls у нескольких провайдеров, а затраты будут накапливаться так, что по счёту провайдера это уже нельзя разобрать по частям.

Если telemetry не фиксирует гранулярность на уровне шага agent, никто не узнает, какие шаги прибыльны. Сводные расходы появятся в счёте лишь через три недели. К этому времени workflow уже работает в масштабе, клиенты подключены, а нерентабельные пути были повторены тысячи раз.

Когда вызовы делает agent, число событий, создающих затраты без привязки к бизнес-контексту, растёт на порядок. Окно для внедрения такой instrumenting-схемы до того, как она станет неуправляемой, быстро закрывается.

Что меняется, когда три источника соединяются

Как только три источника сведены вместе, меняется сам разговор об инвестициях в ИИ.

Пять разных способов построить одну и ту же ИИ-способность перестают выглядеть одинаково. Они сходятся по adoption metrics, но расходятся по стоимости в 10 раз. Команда выбирает подход, который даёт сопоставимый бизнес-результат в пять раз дешевле, потому что теперь разница видна. Продуктовые команды проектируют features с учётом margin уже на этапе архитектуры, а не после запуска на бюджетном review. Инженерные команды выбирают архитектуры моделей, имея данные о cost-per-outcome вместе с latency и quality. Руководство оценивает ИИ-инициативы так же, как любую другую капиталовложенную статью: через unit economics, а не через engagement chart. Счета в агрегированном виде показывают стоимость одного взаимодействия с клиентом. Engagement metrics показывают margin по feature. Выбор модели по интуиции сверяется с реальными результатами выбора модели по cost-per-outcome.

За считаные секунды все видят, какие ИИ-features прибыльны, какие стоит масштабировать, а какие нужно закрыть. Именно этого инсайта все и ищут, и компании, которые его получат, смогут лучше использовать преимущества ИИ.

Ловушка build

Затраты на ИИ сейчас растут по нарастающей. Совет директоров не будет ждать 18 месяцев, пока внутренний проект выйдет в production.

Искушение собрать всё своими силами никогда не было сильнее. AI coding tools изменили то, что небольшая engineering-команда может выпустить за квартал. Слой instrumenting выглядит посильным. Нормализация затрат кажется задачей на выходные. Semantic model выглядит как то, что senior engineer может набросать за один sprint.

Это ловушка. По трём причинам.

Первая — объём. Production-контур ИИ генерирует миллионы telemetry events в час, и этот объём растёт вместе с adoption agentic-подходов. Реальное ingestion, correlation и attribution на таком масштабе — это не то же самое, что vibe coding прототипа за один день. Это постоянная операционная система, которая должна работать правильно каждую минуту каждого дня.

Вторая — ландшафт поставщиков. Данные о затратах приходят с задержкой в биллинговых окнах от провайдеров с несовместимыми schema. Schema меняются без предупреждения. Новые AI-провайдеры ежемесячно входят на рынок, у каждого своя taxonomy и metering. Систему не строят один раз. Её постоянно поддерживают против движущейся цели, которая меняется быстрее, чем большинство внутренних release cycles.

Третья — это то, к чему приводят первые две: это бизнес-критическая инфраструктура. CFO и совет директоров будут принимать решения о распределении капитала на основе данных, которые производит эта система. Когда schema drift остаётся незамеченным две недели, когда поток telemetry agent перестаёт коррелировать с провайдером, который тихо изменил свой billing API, цена ошибки — не один sprint на уборку. Это один квартал неправильно распределённого капитала.

Для engineering-лидеров вопрос build vs. buy изменился. Это уже не вопрос «можем ли мы это построить?» Честный ответ — да. Настоящий вопрос в том, лучше ли потратить маржинальный час сильнейших инженеров на связывание данных о затратах, telemetry и бизнес-результатах или на создание AI-продуктов, которые и приносят ту выручку, которую эти затраты измеряют.

Эту возможность можно воспроизвести за недели. Выбор в том, тратить ли следующие 18 месяцев на её создание или следующие 18 месяцев на действия на её основе.

—

New Tech Forum — площадка для технологических лидеров, включая вендоров и других внешних авторов, чтобы подробно обсуждать новые enterprise-технологии. Отбор материалов субъективен и основан на нашем выборе технологий, которые, как мы считаем, важны и наиболее интересны читателям InfoWorld. InfoWorld не принимает маркетинговые материалы к публикации и оставляет за собой право редактировать весь присланный контент. Все запросы направляйте на doug_dineley@foundryco.com.

Материал — перевод статьи с английского.

Оригинал: Determining the ROI of AI requires data that most companies lack