26 мая 2026 года The New Stack выпустил материал о том, что наблюдаемость AI-затрат быстро превращается из полезной дисциплины в обязательную. Для компаний, которые уже подключают LLM, агентные сценарии и внешние AI-сервисы, это означает неприятную, но знакомую вещь: расходы начинают расти раньше, чем появляется внятный ответ на вопрос, кто именно и за что платит. Для русскоязычной IT-аудитории сигнал прямой: если у вас нет карты сервисов, тегирования и связки с бизнес-метриками, счет за ИИ придет раньше, чем KPI по нему.
Как пишет The New Stack, об этом предупреждает Kin Lane, аналитик API-рынка и сооснователь Naftiko. Его тезис звучит без лишней драмы, но вполне жестко: бизнес вот-вот получит счет не только за новую волну AI-проектов, но и за старый технический хаос, который копился почти десятилетие. Речь идет об API-sprawl, разрастании приложений и сервисов, которые компании запускали быстрее, чем успевали понять их стоимость, назначение и владельцев. По версии Lane, генеративный ИИ не создал проблему с нуля, а просто резко поднял ставки.
В этом сравнении с ранней эпохой облачной миграции есть неприятная точность. Тогда тоже казалось, что новая технологическая модель снимет старые ограничения и упростит жизнь. На практике выиграли те, у кого уже были сильная инженерная база, понятная архитектура, дисциплина в доменах и нормальный разговор между бизнесом и разработкой. Остальные получили сложность, которую долго маскировали красивыми слайдами. Теперь тот же сценарий повторяется вокруг AI, только быстрее. Если компания не видит, какие модели использует, какие агенты вызывают какие API, где возникает токеновый расход и на какой бизнес-процесс он вообще работает, то она строит дорогую систему на болоте из неописанных зависимостей.
Где именно теряются деньги
Lane отдельно указывает на хронический разрыв между IT и бизнесом. По его словам, этот разрыв тянется большую часть нынешнего столетия: бизнес формулирует требования и перебрасывает их через стену, инженеры что-то строят, а связь с клиентом, выручкой и реальной операционной ценностью оказывается слабой. Agile здесь не всегда помогает. Во многих компаниях вместо общей рабочей модели получается декоративный agile, где стороны по-прежнему разговаривают на разных языках. Бизнес не хочет лезть в GitHub, инженеры не горят желанием обсуждать бюджетную логику, а потом все удивляются, почему AI-эксперимент внезапно превращается в постоянную статью расходов.
Именно поэтому наблюдаемость AI-затрат в материале подается не как еще один дашборд, а как слой бизнес-трассировки. Lane предлагает смотреть на AI не только через инфраструктуру, но и через артефакты, которые можно описать, разметить и связать с результатом. Он проводит параллель с UTM-метками из маркетинга: когда трафик можно атрибутировать к кампании, каналу и сообщению, становится понятнее, что работает, а что просто сжигает бюджет. Для AI логика похожая. Если компания не маркирует вызовы моделей, не связывает их с командами, продуктами, сценариями и целями, она получает набор расходов без контекста. В такой системе невозможно честно ответить, какой агент создает ценность, а какой только гоняет токены и дергает API.
На этом месте в разговор входит FinOps. Lane напоминает, что инструменты и практики для учета расходов вообще-то уже существуют, просто их часто не доводят до бизнес-смысла. В статье он выделяет три привычных зоны FinOps-активности: SaaS-менеджмент, где нужно понимать, какими сервисами пользуется компания и сколько стоит пользователь; контейнерные и вычислительные расходы, то есть стоимость самой инфраструктуры; и облачный биллинг, где важно удерживать под контролем общий счет провайдера. AI добавляет четвертое измерение, и оно особенно неприятное: стоимость зависит от модели, токенов, тарифного уровня и объема API-вызовов. То есть даже если у вас уже есть порядок в облаке, это не значит, что вы готовы к порядку в AI.
Самая сильная формулировка Lane в статье связана именно с этим эффектом масштаба. Он напоминает, что когда-то бизнесу обещали более дешевые серверные расходы в облаке, а спустя 15 лет счет во многих случаях оказался в разы выше прежнего. С AI, по его мнению, риск еще серьезнее. Это не обязательно означает катастрофу для всех, но означает, что старый инстинкт «сначала внедрим, потом разберемся» здесь обойдется особенно дорого. Если у компании нет FinOps-подхода для моделей, облаков и AI-сервисов, управлять экономикой будет уже не она, а поставщики этих сервисов.
Почему это важно не только для финансистов
Для разработчиков и платформенных команд вывод довольно приземленный. Период, когда AI-функции можно было спокойно подключать как «еще одну внешнюю API-шку», заканчивается. Возникает спрос на карту сервисного ландшафта, на разметку сценариев использования, на понятные доменные границы и на документацию, которую раньше многие считали скучной обязаловкой. В материале Lane прямо говорит: нельзя увидеть то, что вы не описали и не оформили как артефакт. Для CTO и продактов это означает, что разговор об ROI AI теперь придется вести не на уровне общих обещаний, а на уровне конкретных связей между затратой, сервисом, командой и бизнес-исходом.
При этом в статье есть и довольно трезвый луч надежды для тех, кто считает себя опоздавшим. Lane отмечает, что поздние игроки могут использовать свое отставание как преимущество: им не обязательно тащить за собой десятилетия легаси-бремени, если они строят данные и интеграции сразу на современных облачных шлюзах и актуальных хранилищах. Но это работает только для тех, кто готов инвестировать не в хайп, а в фундамент: governance, schema validation, стандарты документации, учет и договоренности между командами. Иными словами, скучные практики снова побеждают модные презентации.
Главный вопрос теперь не в том, будет ли бизнес тратить больше на AI, а в том, кто первым научится отличать полезный расход от шумного. Наблюдаемость AI-затрат становится точкой, где сходятся архитектура, финансы и продуктовая ответственность. И если агентные системы действительно войдут в корпоративный стек всерьез, выигрывать будут не те, кто быстрее всего подключил модель, а те, кто раньше остальных научился видеть ее цену в привязке к реальной работе бизнеса.