Почему строка «ИИ» всегда под огнём
Когда вы собираете все траты на ИИ в одну строку бюджета, эта строка становится главной мишенью встречи. Дело не в том, что совет директоров настроен враждебно, а в том, что у совета нет категории для ответа. Инфраструктура, лицензии, фонд оплаты труда — по каждой из этих строк у комнаты есть история одобрений и понятная динамика, есть с чем сравнивать. Строка «ИИ» не имеет ни истории, ни аналога. Такую строку не одобряют — её допрашивают.
И дальше почти гарантированно звучит вопрос про окупаемость. Он опасен не сложностью ответа, а тем, что следует за формой заявки: пока слайд выглядит как проект, вопросы будут проектными. Честное «пока не знаем», произнесённое без подготовленной рамки, — худшее, что можно сказать в этой комнате. Поэтому задача этой статьи не «обосновать ИИ». Задача — сменить форму заявки так, чтобы вопросы стали другими и на них существовал внятный ответ.
Тупик: слайд с обещанной экономией
Первое, что пробуют почти все, — бизнес-кейс: внедряем, сокращаем ручной труд, окупаемся. Слайд выглядит убедительно, и в этом ловушка.
Разберём, почему конструкция не держит нагрузку — по арифметике, а не по ощущениям. Экономия от автоматизации — это высвобожденное время, помноженное на стоимость этого времени. Но высвобожденное время появляется, только если люди реально меняют способ работы, а это управленческая переменная, а не модельная. Обещая экономию, вы обещаете чужое поведение. В момент защиты цифра неизбежно выдумана, и в комнате это чувствуют — чем увереннее она подана, тем подозрительнее.
Дальше протокол. Обещанное запишут и будут мерить по нему. Каждый следующий отчёт превращается в объяснение отклонения, а честное «задача оказалась устроена иначе» читается как провал. Одобрение куплено ценой конвертации неопределённости в личный долг перед комнатой.
Кейс с окупаемостью ещё и приглашает финансового директора играть на его поле. Расчёт окупаемости — его профессия, ваша цифра мягкая, и любой аудит её разберёт. Не та встреча, которую стоит назначать самому себе.
Отдельно — сравнение с людьми. Слайд вида «это заменит столько-то ставок» делает все затронутые отделы вашими противниками ещё до старта и при этом обычно врёт по существу: работа не исчезает, а переезжает — в проверку результата, в разбор странных случаев, в поддержку. И последнее: пообещав окупаемость, вы превратили открытую разведку в закрытый проект. Любая трата, не работающая на обещанную цифру, — стенд оценки, вторая модель, нормальные данные, — на следующих встречах выглядит как размывание бюджета. Вы сами закрыли себе путь к честным тратам.
Считать не сумму, а цену задачи
Вместо итоговой суммы на слайд выносится цена одной задачи. Формула: цена задачи равна цене токена, умноженной на среднее число токенов на задачу, умноженной на коэффициент накладных расходов. Каждая переменная берётся не с потолка.
Цена токена — из прайса провайдера: она публична, проверяема, совет может сверить её сам. Токены на задачу — измеряются, а не угадываются: берёте поток реальных задач (или честно собранных под реальный профиль), прогоняете, считаете. Коэффициент накладных — тоже измеряется: за пилотный период делите всё потраченное на число задач, доведённых до результата. В этот коэффициент сами войдут перегенерации, отказы, проверочные прогоны, разогрев кэша — то, что никогда не попадает в красивые предпросчёты. Если в контуре есть человек, проверяющий результат, его время — тоже часть цены задачи; без него цена врёт в самую опасную сторону.
Почему совету нужна цена, а не сумма: сумму нельзя проверить, цену — можно. С ценой задачи совет сам проделает сравнение с человеческим трудом, и эту арифметику сделает тот, кто в ней профессионален. Вам не придётся обещать экономию — она либо видна из цены, либо нет. И главное: цена задачи — проектная переменная. Кэширование повторяющихся запросов, маршрутизация простых случаев на дешёвую модель, урезание промпта — каждый рычаг меняет цену. Вы показываете сегодняшнюю цену, перечень рычагов и пол, ниже которого при текущем прайсе цена не опустится. Как цена задачи ведёт себя на живой нагрузке и почему тестовые прогоны почти всегда её занижают — мы разбирали в материале об инференсе на реальной нагрузке.
Одна оговорка: «задача» должна быть определена до расчёта. Если пользователи начинают упаковывать в один запрос больше, цена задачи плывёт вместе с определением, и тренд по ней врёт. Определение фиксируется; его изменения фиксируются отдельно.
Портфель с воротами, а не проект с обещанием
Если вопросы следуют за формой заявки, менять нужно заявку. Она делится на две части с разной логикой одобрения.
Первая — разведка: потолок трат на период, дата ворот и условие остановки. Ворота выглядят так: к такой-то дате есть прототип, который на нашем потоке задач делает такую-то работу по цене не выше такой-то; если нет — траты останавливаются и приносится список выясненного. Условие остановки должно быть проверяемо кем-то вне вашей команды, иначе это не ворота, а декорация.
Страх совета — не сумма, а безграничность. Потолок с датой переводит бесконечный страх в ограниченную ставку, а ограниченные ставки одобряют несравнимо легче. И ворота защищают вас не меньше, чем совет: остановленный проект с зафиксированными выводами — результат работы процесса, а не ваш личный провал. Добиться, чтобы эта рамка была принята заранее, — половина работы.
Вторая часть — продакшен, и он не требует отдельной строки «ИИ». Инференс лежит в инфраструктуре, лицензии — в лицензиях, люди — в фонде оплаты труда. Совокупный объём показывается один раз, дальше каждая часть живёт в категории, где совет умеет сравнивать. Цель не спрятать траты, а положить каждую туда, где у неё есть с чем сравниваться.
На встречу приносится одна страница: потолок на период; сегодняшняя цена задачи и план её снижения; дата ворот; условие остановки. Отдельной строкой — чего мы не сделаем, если деньги уйдут сюда: цена возможности должна быть видна так же ясно, как цена ставки.
Отчитываться нужно в той же форме, в которой просили: потрачено против потолка, тренд цены задачи, что показали ворота. Когда следующая заявка придёт в той же форме, у совета уже будет история сравнения, и разговор пойдёт о цифрах, а не о доверии.
Что не попадает на слайд, но съедает бюджет
Демо стоит копейки — система нет. Стенд оценки, который придётся поддерживать, пока провайдер меняет модели под вами; мониторинг; данные и пайплайны; человек, владеющий конфигурацией. Эти траты не масштабируются с нагрузкой — это постоянный пол, невидимый в бюджете пилота. Если не попросить их сразу, их возьмут из операционного времени вашей команды, и качество начнёт тихо гнить. Что считать в стоимости владения и что смело игнорировать — разбирали в материале о стоимости владения кодом.
Позиция редакции
Мы считаем, что траты на ИИ защищаются не кейсом с окупаемостью, а портфелем ограниченных ставок: потолок на разведку, ворота с проверяемым условием, раскрытая цена задачи для продакшена. Обещанная окупаемость — самый дорогой способ получить одобрение: «да» сегодня покупается отчётом об отклонении завтра.
Мы неправы в двух случаях. Первый: правила распределения капитала в организации жёстко требуют расчёт окупаемости для любой траты выше порога, а бюджета на разведку не существует и не появится. Тогда ворота процедурно не пройдут, и честнее защищать мягкую цифру, открыто заложив в неё право на пересмотр. Второй: совокупные траты на ИИ ниже порога, который совет вообще рассматривает. Тогда вся конструкция избыточна — тратьте в обычном порядке и не стройте машинерию ради машинерии.