Как рассчитать TCO корпоративного искусственного интеллекта и не ошибиться в бюджете

Запрос на внедрение искусственного интеллекта почти всегда начинается с вопроса о цене, а заканчивается спором о бюджете через девять месяцев после запуска. Между этими двумя точками лежит разница между стоимостью покупки и стоимостью владения, и в ИИ-проектах она больше, чем в любом другом классе корпоративных систем. Я разберу, из каких статей реально складывается TCO корпоративного искусственного интеллекта, как считать капитальную и операционную части, где прячутся расходы, которых нет ни в одном коммерческом предложении. Начнём с того, почему прайс поставщика и полная стоимость владения расходятся в разы, а не на проценты.

Что такое TCO и почему цена лицензии не равна стоимости владения

TCO, или полная стоимость владения, это сумма всех затрат на решение за весь срок его жизни, а не только за период внедрения. Концепция появилась в корпоративной ИТ-практике ещё в девяностые, когда выяснилось, что покупка рабочей станции составляет около четверти расходов на неё за пять лет. Для искусственного интеллекта пропорция стала ещё жёстче. В проектах, которые я видел за последние три года, стоимость доступа к модели или лицензии на платформу занимала от десяти до тридцати процентов полной стоимости владения на горизонте трёх лет.

Остальное распределяется между работой людей, подготовкой данных, интеграциями, контролем качества и эксплуатацией. Эти расходы редко попадают в коммерческое предложение, потому что значительная их часть ложится на внутренние подразделения заказчика. Подрядчик честно называет цену своей работы, а не цену изменений, которые придётся провести внутри компании.

Есть и вторая причина расхождения. Классическая корпоративная система после внедрения входит в режим затухающих затрат, когда основные деньги потрачены, а дальше идёт поддержка в размере пятнадцати или двадцати процентов от стоимости внедрения в год. Искусственный интеллект ведёт себя иначе. Его операционная стоимость пропорциональна объёму использования, а объём использования растёт по мере того, как сотрудники привыкают к инструменту. Успешное внедрение автоматически означает рост счёта.

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

Чем структура затрат ИИ-проекта отличается от обычной автоматизации

Разница сводится к четырём свойствам, и каждое из них напрямую влияет на расчёт.

• Переменная часть доминирует. В типовом внедрении учётной системы переменные расходы это трафик и немного вычислений. В языковых моделях переменная часть может превышать половину операционного бюджета.
• Качество нестабильно по своей природе. Модель даёт вероятностный результат, поэтому нужен постоянный контроль, а контроль это рабочее время людей, которое надо посчитать в деньгах.
• Решение деградирует без вмешательства. Меняются регламенты, ассортимент, формулировки клиентов, версии модели. База знаний, собранная в марте, к декабрю отвечает на часть вопросов неверно.
• Обновление модели ломает совместимость. Переход на новую версию требует перепроверки промптов, сценариев и тестовых наборов. Это плановая работа, которая повторяется один или два раза в год.

Из этого следует практический вывод. Считать TCO искусственного интеллекта по аналогии с корпоративным программным обеспечением нельзя, потому что модель затухающих расходов здесь не работает. Нужна отдельная схема расчёта, где переменная часть прогнозируется через нагрузку, а не через процент от стоимости внедрения.

Из чего складывается TCO корпоративного ИИ

Я разбиваю полную стоимость владения на шесть групп. Деление не академическое, оно удобно тем, что каждая группа имеет своего владельца внутри компании и свой драйвер роста. Дальше приведены ориентировочные доли от трёхлетнего TCO для среднего проекта промышленного уровня, но они сильно зависят от выбранной архитектуры.

Аналитика процесса и проектирование решения

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

Отдельная строка расходов это время экспертов заказчика. Чтобы собрать правила обработки заявок, нужен не аналитик подрядчика, а тот сотрудник, который эти заявки обрабатывает десять лет и держит правила в голове. Его время стоит денег и отвлекает от основной работы. В расчёте я закладываю от двадцати до шестидесяти часов экспертного времени на один автоматизируемый процесс средней сложности.

Данные и база знаний

От пятнадцати до тридцати пяти процентов, и это самая недооценённая группа. Компания обычно считает, что данные у неё уже есть, потому что документы лежат на файловом сервере, а история обращений хранится в системе учёта. Проблема в том, что для модели это сырьё, а не данные.

• Инвентаризация источников и проверка их актуальности. Регламенты в трёх версиях, из которых действует одна, это нормальная ситуация для крупной компании.
• Очистка и нормализация. Сканы без текстового слоя, таблицы в произвольных форматах, письма с вложенной перепиской.
• Разметка. Нужна для обучения классификаторов и для построения тестовых наборов. Стоимость зависит от квалификации разметчика, и в юридических или медицинских задачах это работа профильного специалиста, а не оператора.
• Построение и обновление векторного индекса, если решение использует поиск по корпоративным документам.
• Процесс поддержания данных в актуальном состоянии после запуска. Это постоянная работа, а не разовая задача.

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

Инфраструктура и вычислительные мощности

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

Для российского рынка сейчас актуальны три варианта. Доступ к моделям через интерфейс программирования у отечественных поставщиков с оплатой по факту использования. Аренда вычислительных мощностей с графическими ускорителями в российских облаках для размещения открытых моделей. Покупка собственного оборудования с установкой в своём или арендованном центре обработки данных. Каждый вариант даёт свою кривую затрат, и пересечение этих кривых обычно находится между восемнадцатью и тридцатью месяцами эксплуатации.

Интеграции с корпоративным контуром

От десяти до двадцати пяти процентов. Модель сама по себе не приносит пользы, она должна получать данные из рабочих систем и возвращать результат туда, где его увидит сотрудник или клиент.

• Подключение к системам учёта, документооборота, обслуживания клиентов, кадровым и финансовым контурам.
• Разработка промежуточного слоя, который управляет вызовами модели, хранит историю, повторяет неудачные запросы, ограничивает нагрузку.
• Авторизация и разграничение прав. Сотрудник не должен получить через ассистента доступ к документам, которых не видит в системе напрямую. Это требование, которое дорого реализовать и дорого проверить.
• Журналирование всех обращений для последующего разбора инцидентов.
• Доработка систем на стороне заказчика. Если учётная система не умеет отдавать нужные данные по запросу, её придётся дорабатывать, и это бюджет другого подразделения.

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

Контроль качества, безопасность и соответствие требованиям

От восьми до двадцати процентов. Эта группа растёт тем быстрее, чем ближе решение к клиенту и к персональным данным.

• Построение тестовых наборов и методики оценки. Без набора эталонных примеров вы не сможете доказать, что новая версия модели не стала хуже предыдущей.
• Регулярная проверка ответов экспертами. В первые месяцы промышленной работы это может быть от пяти до пятнадцати процентов рабочего времени одного специалиста.
• Защита от нежелательного поведения модели, фильтрация запросов и ответов, проверка на попытки обойти ограничения через текст.
• Выполнение требований по обработке персональных данных, если они попадают в контур решения. Размещение данных на территории России, обезличивание, учёт целей обработки, оформление согласий.
• Аттестация и согласование с подразделением информационной безопасности. В крупных компаниях это самостоятельный проект по срокам.

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

Поддержка, дообучение и развитие после запуска

От пятнадцати до тридцати процентов на трёхлетнем горизонте. Этой строки почти никогда нет в первоначальном бюджете, потому что в момент согласования проект мыслится как разовая работа.

• Дежурство и реагирование на сбои, причём с учётом того, что модель может работать, но давать неверный результат.
• Обновление базы знаний и сценариев при изменении процессов.
• Переход на новые версии модели с перепроверкой всех сценариев.
• Обучение сотрудников и повторное обучение при ротации персонала. Решение, которым не умеют пользоваться, не даёт эффекта, но стоит столько же.
• Развитие функциональности по запросам пользователей. Поток таких запросов появляется через два или три месяца после запуска и не прекращается.

Для промышленного решения я закладываю от двадцати до тридцати пяти процентов стоимости внедрения в год на поддержку и развитие. Для решений, встроенных в клиентские процессы, ближе к верхней границе.

CapEx и OpEx: как разделить затраты в ИИ-проекте

Разделение на капитальные и операционные расходы нужно не для красоты отчёта. От него зависят три вещи. Как проект проходит согласование, как затраты отражаются в финансовом результате по годам, и кто внутри компании отвечает за перерасход.

К капитальной части относится то, что создаёт долгоживущий актив. Это оборудование с графическими ускорителями и серверная инфраструктура, бессрочные лицензии, работы по созданию программного решения, которое признаётся нематериальным активом, а также существенные работы по подготовке данных, если результат используется многократно и его можно отделить от текущей деятельности. Российская практика учёта опирается на стандарты по основным средствам и нематериальным активам, и формулировки в договоре с подрядчиком заметно влияют на то, удастся ли капитализировать работы.

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

Как выбор архитектуры перекладывает деньги между CapEx и OpEx

Одно и то же решение можно собрать так, что оно будет почти полностью капитальным или почти полностью операционным. Покупка серверов с ускорителями даёт крупный единовременный расход, амортизацию на три или пять лет и предсказуемую стоимость обработки запроса при высокой загрузке. Работа через интерфейс программирования внешнего поставщика не требует вложений на старте, но превращает каждый запрос сотрудника в строку расхода.

Это не технический выбор, а финансовый. Я видел проекты, где техническое решение диктовалось исключительно тем, что в компании был доступен инвестиционный бюджет и не было возможности увеличить операционный. Разумнее делать наоборот и считать оба сценария на одном горизонте, но полезно признать, что ограничения бюджетного процесса реальны и их надо учитывать в расчёте.

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

Что обычно забывают отнести хоть куда-нибудь

Есть расходы, которые не попадают ни в капитальную, ни в операционную часть просто потому, что их никто не считает. Они оплачиваются рабочим временем людей, которое уже заложено в фонд оплаты труда.

• Время экспертов на сбор знаний и проверку ответов.
• Время руководителей на согласования, демонстрации и защиту проекта.
• Время службы информационной безопасности на анализ рисков.
• Снижение производительности подразделения в период перехода на новый процесс.
• Работа юристов над документами по обработке данных и над договорами с поставщиками моделей.

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

Методология расчёта TCO: пошаговый алгоритм

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

1. Зафиксируйте границу системы. Определите, что входит в расчёт, а что остаётся снаружи.
2. Выберите горизонт. Для ИИ-решений это тридцать шесть месяцев, реже шестьдесят.
3. Соберите перечень статей затрат по шести группам, описанным выше, не пропуская внутреннее время.
4. Для каждой статьи определите тип поведения. Разовая, повторяющаяся с фиксированной суммой, зависящая от нагрузки.
5. Постройте прогноз нагрузки по месяцам с учётом роста использования. Это отдельная задача, и к ней я вернусь в части о токенах.
6. Рассчитайте три сценария. Пессимистичный, базовый и сценарий активного роста использования.
7. Добавьте резерв на изменения. От пятнадцати до двадцати пяти процентов для первого проекта в компании, от десяти процентов для последующих.
8. Распределите итог по подразделениям и продуктам, чтобы расчёт можно было проверить и защитить.

Граница системы и горизонт расчёта

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

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

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

По горизонту есть простое правило. Он должен быть не короче срока амортизации самого долгоживущего элемента и не короче срока, за который предполагается окупаемость. Горизонт в двенадцать месяцев почти всегда выгоден для варианта с оплатой по факту использования и почти всегда невыгоден для собственной инфраструктуры, поэтому короткий горизонт это способ подтолкнуть решение, а не способ его оценить.

Аллокация затрат на продукты и подразделения

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

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

Сложный подход использует несколько драйверов для разных групп затрат.

• Вычисления распределяются по фактическому потреблению, измеренному в единицах обработанного текста или в часах работы ускорителя.
• Хранение данных и индексы распределяются по объёму.
• Работа команды поддержки распределяется по учтённому времени или по количеству обращений от каждого решения.
• Платформенные затраты, которые нельзя привязать к потреблению, распределяются равными долями или по числу активных пользователей.
• Затраты на безопасность и соответствие требованиям разумно относить на решения, которые работают с персональными данными, а не размазывать на все.

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

Расчёт операционной стоимости: токены и нагрузка

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

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

Платные операции делятся на входящие и исходящие токены, и цена у них разная. Исходящие стоят дороже, обычно в два или три раза. Это важно, потому что структура запроса определяет итоговый счёт сильнее, чем выбранный тариф.

Как спрогнозировать объём токенов до запуска

Прогноз строится не от количества пользователей, а от количества операций и состава одной операции. Порядок действий такой.

1. Опишите один типовой сценарий обработки от начала до конца. Сколько обращений к модели он содержит, какие данные подаются на вход, какой длины ответ ожидается.
2. Посчитайте токены каждого обращения. Инструкция для модели, фрагменты найденных документов, история диалога, описание доступных инструментов, сам вопрос пользователя, ответ.
3. Умножьте на число обращений в сценарии. Для простого ответа на вопрос это одно обращение, для агентского сценария с проверками и вызовом внешних систем от пяти до пятнадцати.
4. Умножьте на прогнозируемое число операций в месяц.
5. Добавьте накладные операции. Повторы при ошибках, проверка ответа второй моделью, автоматическая оценка качества, обработка документов при обновлении базы знаний.
6. Постройте кривую роста использования на двадцать четыре месяца, а не плоскую линию.

Основная ошибка на втором шаге. Люди считают вопрос пользователя и ответ модели, а забывают про контекст. В решении с поиском по корпоративным документам в модель уходят найденные фрагменты, и это обычно от трёх до восьми тысяч токенов на один запрос. Сам вопрос занимает тридцать токенов. То есть девяносто девять процентов входящего объёма формирует не пользователь, а архитектура поиска.

Второй по частоте просчёт связан с диалогом. Если ассистент помнит переписку, то каждая следующая реплика тащит за собой всю предыдущую. Диалог из десяти реплик стоит не в десять раз дороже одной, а в пятьдесят или шестьдесят раз, потому что объём передаваемого контекста растёт на каждом шаге. Решения этой проблемы существуют, от сжатия истории до хранения только последних реплик, но их нужно заложить в проект заранее, а не после первого счёта.

Счёт за модель определяется тем, сколько текста вы отправляете, а не тем, сколько вопросов задают сотрудники. Оптимизация контекста даёт экономию в разы, смена тарифа даёт экономию в проценты.

Стоимость запроса и стоимость дня работы агента

Дальше прогноз переводится в деньги через две производные величины, которые я считаю обязательными для любого ИИ-проекта. Стоимость одной обработанной операции и стоимость дня работы решения.

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

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

Покажу порядок величин на условном примере внутреннего ассистента по базе знаний для компании на пятьсот сотрудников. Цифры иллюстративные, но соотношения между строками типичны.

Параметр	Базовый сценарий	Сценарий активного роста
Активных пользователей в месяц	150	420
Запросов на пользователя в день	3	7
Входящих токенов на запрос	6 000	6 000
Исходящих токенов на запрос	500	500
Запросов в месяц	около 9 900	около 64 700
Стоимость одного запроса	около 1,6 рубля	около 1,6 рубля
Расход на модель в месяц	около 16 тысяч рублей	около 104 тысяч рублей

Разница между колонками возникает не из-за роста цен, а из-за роста использования. Это и есть главное свойство операционной части. Проект, который удался, стоит дороже проекта, который не прижился, и бюджет на второй год нужно защищать исходя из сценария роста, а не из факта первых трёх месяцев.

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

API, облако или своя модель: сравнение TCO на 3 года

Это решение определяет структуру затрат на весь срок жизни решения, и переделать его потом дорого. Я разберу три варианта по одной схеме, а затем покажу, где находится точка пересечения кривых.

Оплата по фактической нагрузке

Доступ к моделям через программный интерфейс поставщика. На российском рынке это сервисы Яндекса и Сбера, а также ряд провайдеров, предоставляющих доступ к открытым моделям в своей инфраструктуре.

• Стартовые вложения близки к нулю, первый запрос можно отправить в день подписания договора.
• Затраты полностью операционные и растут строго вместе с использованием.
• Обновление моделей происходит на стороне поставщика, вам не нужно держать компетенцию по эксплуатации ускорителей.
• Масштабирование вверх мгновенное, пиковая нагрузка не требует запаса мощности.
• Данные покидают ваш контур, что требует отдельной проработки с юристами и службой безопасности.
• Цена и состав моделей меняются по решению поставщика, долгосрочный расчёт опирается на тариф, который вы не контролируете.

Вариант уверенно выигрывает при небольших и средних объёмах, при неравномерной нагрузке и на старте любого проекта. Начинать с собственного оборудования, не зная реального профиля использования, означает купить мощность наугад.

Локальное развёртывание на своём железе

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

Аренда ускорителей в облаке занимает промежуточное положение. Платёж фиксированный и не зависит от числа запросов, что выгодно при высокой и ровной загрузке. Но ускоритель оплачивается круглосуточно, включая ночь и выходные, и при низкой загрузке вы платите за простой. Переход от оплаты за запросы к оплате за мощность имеет смысл, когда среднесуточная загрузка превышает примерно тридцать или сорок процентов от пропускной способности арендованной конфигурации.

Покупка оборудования добавляет к расчёту статьи, которые в облаке скрыты в цене аренды.

• Серверы с ускорителями и срок их полезного использования, который для таких карт разумно брать равным трём или четырём годам из-за скорости смены поколений.
• Размещение в центре обработки данных, электроснабжение и охлаждение. Конфигурация на восемь ускорителей потребляет порядка шести или десяти киловатт, и расход на электричество с охлаждением за три года сопоставим с частью стоимости самого сервера.
• Резервирование. Один сервер это одна точка отказа, и для промышленной эксплуатации нужен запас мощности.
• Сетевое оборудование и системы хранения под модели и индексы.
• Команда эксплуатации. Это самая недооценённая строка, потому что требуется редкая и дорогая компетенция по работе с ускорителями и обслуживанию моделей.
• Простой мощности в период, пока решение ещё не вышло на расчётную нагрузку.

Взамен вы получаете то, что в ряде отраслей невозможно купить никакими деньгами. Данные не выходят за пределы вашего контура, модель не меняется без вашего решения, стоимость обработки запроса при высокой загрузке становится в несколько раз ниже тарифной, а предсказуемость платежа не зависит от поведения пользователей.

Своя инфраструктура это не способ сэкономить, а способ обменять переменные расходы на фиксированные и получить контроль над данными. Экономия появляется только при высокой и устойчивой загрузке.

По моим расчётам на разных проектах точка, где собственная инфраструктура начинает выигрывать по полной стоимости владения, лежит в диапазоне от восемнадцати до тридцати месяцев при условии ровной загрузки не ниже половины мощности. Если загрузка ниже или проект может быть закрыт через год, оплата по факту использования остаётся дешевле на всём горизонте.

Готовая платформа против собственной разработки

Третье измерение выбора касается не вычислений, а прикладного слоя. Покупать готовую платформу для сборки ассистентов и агентов или разрабатывать решение под себя.

Готовая платформа сокращает срок до первого результата с месяцев до недель и снимает с вас разработку промежуточного слоя, журналирования, разграничения прав и интерфейса. Платите подписку, обычно привязанную к числу пользователей или объёму обработки. Ограничение в том, что нетиповые сценарии либо не реализуются вовсе, либо реализуются дорогими доработками, а стоимость подписки растёт линейно вместе с охватом.

Собственная разработка дороже на старте и требует удержания команды, зато даёт полную свободу в интеграциях и фиксированную стоимость владения, не зависящую от числа пользователей. Имеет смысл, когда ИИ становится частью основного продукта компании или когда сценарии принципиально не укладываются в типовые.

Практический ориентир для выбора. Если автоматизируется внутренний процесс поддержки, подбора персонала, работы с документами, берите готовую платформу и не изобретайте промежуточный слой. Если решение будет видеть клиент и влиять на выручку, считайте собственную разработку, потому что через два года вам понадобится то, чего в типовой платформе не будет.

Расходы, которые чаще всего забывают включить в смету

Это список, собранный по фактическим перерасходам на проектах. Ни одна из строк не является экзотикой, но в первоначальной смете их обычно нет.

• Повторная обработка документов при обновлении модели векторного поиска. Смена модели означает пересчёт всего индекса, и для архива в несколько сотен тысяч документов это заметная сумма.
• Токены на автоматическую оценку качества. Если качество проверяется второй моделью, это добавляет от десяти до тридцати процентов к расходу на модель.
• Тестовые прогоны. Перед каждым обновлением сценариев прогоняется эталонный набор, и каждый прогон платный.
• Обработка неудачных запросов. Таймауты, ошибки формата, повторы. В промышленной эксплуатации это от трёх до восьми процентов объёма.
• Среды разработки и тестирования. Отдельные контуры с отдельными лимитами, которые тоже потребляют мощность.
• Хранение журналов обращений. Требование безопасности хранить историю год или три превращается в объёмы, которые надо считать.
• Обучение сотрудников и материалы к нему, включая повторные циклы при ротации.
• Поддержка версии модели, которую поставщик собирается вывести из обслуживания. Миграция на новую версию это проект на несколько недель работы команды.
• Юридическое сопровождение, оценка воздействия на персональные данные, доработка внутренних регламентов.
• Стоимость ошибок модели. Неверный ответ клиенту, неправильно классифицированное обращение, пропущенный документ. Это редко считают в деньгах, хотя посчитать можно через стоимость разбора инцидента и компенсаций.
• Снижение производительности подразделения в первые шесть или восемь недель, пока люди привыкают к новому порядку работы.

Сумма этих строк на проектах, которые я видел, составляла от двадцати до тридцати пяти процентов от исходной сметы. Именно поэтому в алгоритме расчёта стоит резерв, и именно поэтому первый ИИ-проект в компании почти всегда выходит за первоначальный бюджет. Второй уже нет, потому что к этому моменту список известен.

Переход от пилота к промышленной эксплуатации

Пилот и промышленная эксплуатация различаются не масштабом, а требованиями. Поэтому экстраполяция бюджета пилота на полноценное внедрение даёт заниженную оценку даже при корректной арифметике.

Почему затраты растут скачком, а не линейно

Умножение на десять пользователей не означает умножение на десять расходов. Появляются требования, которых на пилоте не было вовсе.

• Доступность. Пилот может лежать полдня, и это обсудят в рабочем чате. Промышленное решение требует резервирования, дежурства и соглашения об уровне обслуживания, и это сразу двойная инфраструктура плюс люди.
• Полнота данных. Пилот работал на отобранной части архива, промышленное решение обязано покрывать весь объём, включая плохо оформленные документы.
• Разграничение прав. На пилоте участники видели одно и то же. В эксплуатации у каждого свой уровень доступа, и это переделка архитектуры поиска, а не настройка.
• Безопасность. Аттестация, проверка защищённости, согласование с регулятором при работе с персональными данными. Срок этого этапа может превысить срок самой разработки.
• Поддержка пользователей. Двадцать участников пилота задают вопросы разработчику напрямую. Пятьсот пользователей требуют первой линии поддержки и базы типовых обращений.
• Пиковая нагрузка. Средняя нагрузка перестаёт быть ориентиром, система проектируется под пик, а не под среднее.
• Качество краевых случаев. На пилоте девяносто процентов точности выглядят отлично. В эксплуатации десять процентов ошибок это сотни инцидентов в месяц, и каждый требует разбора.

Мой рабочий коэффициент перехода от стоимости пилота к стоимости промышленного решения составляет от трёх до шести. Это не наценка подрядчика, а стоимость свойств, которые на пилоте не требовались. Если пилот стоил миллион, промышленное решение на том же процессе будет стоить от трёх до шести миллионов на запуск, плюс операционная часть.

Критерии готовности к промышленной эксплуатации

Решение о переходе я принимаю по проверяемому списку, а не по общему ощущению, что пилот удался. Если хотя бы три пункта не выполнены, масштабирование преждевременно.

1. Есть эталонный набор не менее двухсот примеров с проверенными ответами, и по нему измерено качество.
2. Качество измерено на полном массиве данных, а не на отобранной выборке.
3. Посчитана стоимость одной операции по факту, а не по оценке.
4. Построен прогноз нагрузки на двадцать четыре месяца с тремя сценариями.
5. Описан сценарий отказа. Что происходит с процессом, если решение недоступно сутки.
6. Определён владелец решения на стороне бизнеса, у которого есть бюджет и ответственность за результат.
7. Согласована схема обработки данных со службой безопасности и юристами.
8. Настроены учёт потребления и оповещения о превышении лимитов.
9. Определён порядок работы с ошибками модели, включая то, кто разбирает инциденты и за какое время.
10. Измерен базовый уровень процесса до внедрения, чтобы эффект можно было доказать цифрами.

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

Как считать окупаемость: метрики эффекта и срок возврата

Полная стоимость владения сама по себе ничего не говорит о целесообразности проекта. Она становится осмысленной только в паре с эффектом, и здесь начинается самая спорная часть любого ИИ-проекта. Расходы измеряются точно, потому что приходят счётом от поставщика. Эффект измеряется оценочно, потому что складывается из сэкономленного времени, предотвращённых ошибок и дополнительной выручки, которую трудно отделить от других факторов.

Эффект делится на три категории по степени доказуемости, и смешивать их в одном расчёте нельзя.

• Прямая экономия денег. Сокращение расходов на внешних подрядчиков, отказ от покупки лицензий другой системы, снижение стоимости обработки документа при оплате за объём. Проверяется по бухгалтерии, спорить не о чем.
• Высвобожденное время сотрудников. Считается в часах и переводится в деньги по полной стоимости часа с накладными. Доказуемо при условии, что был зафиксирован базовый уровень до внедрения.
• Косвенные эффекты. Рост конверсии, снижение оттока, ускорение найма, уменьшение числа претензий. Реальны, но на них влияет слишком много факторов, чтобы приписывать результат одному решению.

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

Как превратить высвобожденное время в деньги без самообмана

Главная ловушка расчёта выглядит так. Решение экономит каждому из двухсот сотрудников по двадцать минут в день, за год это получается внушительная сумма, проект окупается за четыре месяца. Арифметика верна, вывод ложен. Двадцать минут, размазанные по дню между другими задачами, не превращаются ни в сокращение штата, ни в дополнительный объём работы. Они растворяются.

Высвобожденное время становится деньгами только в трёх случаях.

1. Подразделение растёт, и экономия позволяет не нанимать новых людей. Это проверяемо по плану найма, и такую экономию легко подтвердить документом.
2. Время измеряется сдельно. Оператор обрабатывает обращения, рост числа обработанных обращений на человека виден в системе и означает отказ от расширения смены.
3. Высвобожденные часы перенаправлены на работу, которая приносит выручку. Менеджер по продажам тратит меньше времени на подготовку документов и больше на встречи, и число встреч учитывается.

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

Срок возврата и что с ним делать

Срок возврата считается как отношение затрат на запуск к ежемесячному эффекту, уменьшенному на операционные расходы. Важно считать именно по чистому эффекту, а не по валовому, иначе получится цифра, которая развалится при первом же пересчёте.

Ориентиры по российскому рынку, которые я вижу на практике. Решения по обработке документов и внутренней поддержке окупаются за срок от восьми до восемнадцати месяцев. Решения в клиентском обслуживании при большом потоке обращений от шести до двенадцати месяцев. Агентские сценарии в сложных процессах от восемнадцати месяцев и дольше, причём с большим разбросом. Если расчёт показывает окупаемость за три месяца, в нём почти наверняка не учтена часть расходов или завышен эффект.

Проект с честным сроком возврата в четырнадцать месяцев переживёт второй бюджетный цикл. Проект с нарисованным сроком в четыре месяца закроют через год, когда факт не совпадёт с обещанием, причём закроют вместе с доверием к следующим инициативам.

Когда корпоративный ИИ не окупается: сигналы на старте

Часть проектов не окупается не из-за ошибок исполнения, а из-за свойств задачи. Эти свойства видны заранее, и дешевле заметить их до подписания договора. Ниже перечислены признаки, каждый из которых по отдельности тревожен, а два или три вместе означают, что считать дальше нет смысла.

• Процесс выполняется редко. Если операция происходит двести раз в год, никакая экономия на операции не покроет стоимость внедрения и поддержки.
• Процесс не описан и постоянно меняется. Автоматизировать можно то, что имеет правила. Если правила живут в голове у трёх разных людей и противоречат друг другу, сначала нужен не искусственный интеллект, а регламент.
• Данных нет или они в непригодном виде. Архив из сканов без текстового слоя означает, что бюджет уйдёт на распознавание и очистку, а не на решение задачи.
• Цена ошибки очень высока, а проверка результата занимает столько же времени, сколько выполнение. Если юрист обязан перечитать весь документ, подготовленный моделью, экономии не возникает.
• Нет владельца на стороне бизнеса. Проект, который двигает только служба информационных технологий, не меняет процесс и не даёт эффекта.
• Процесс выполняется быстро и дёшево вручную. Операция, занимающая у человека сорок секунд, редко стоит автоматизации языковой моделью.
• Требуется точность, близкая к абсолютной, без возможности участия человека. Вероятностная модель такой гарантии не даёт по своей природе.
• Ожидается сокращение штата, но решение о сокращении не принято. Тогда экономия не материализуется, а эффект останется на бумаге.

Отдельно о мотивации проекта. Если инициатива сформулирована как необходимость внедрить искусственный интеллект, а не как необходимость решить конкретную проблему процесса, расчёт TCO превращается в упражнение по обоснованию заранее принятого решения. Такие проекты доходят до пилота, показывают любопытный результат и затухают, оставляя после себя расходы без эффекта. Это самый частый способ потратить бюджет на ИИ в российских компаниях, и он не связан ни с технологией, ни с подрядчиком.

Как снизить TCO без потери качества решения

Снижение стоимости владения почти никогда не достигается торгом с поставщиком. Оно достигается архитектурными решениями, которые принимаются на этапе проектирования. Ниже приёмы, упорядоченные по соотношению эффекта и трудоёмкости.

1. Сократите контекст. Передавайте в модель три наиболее релевантных фрагмента вместо десяти. Качество обычно не меняется, расход на входящие токены падает в два или три раза. Это самый результативный приём из всех.
2. Разнесите задачи по моделям разного класса. Классификация обращения, извлечение данных из формы, определение темы письма отлично решаются небольшими и дешёвыми моделями. Тяжёлую модель оставьте для генерации ответов и сложных рассуждений. Экономия от сорока до семидесяти процентов операционного бюджета.
3. Кэшируйте повторяющиеся запросы. В корпоративной среде от пятнадцати до сорока процентов вопросов повторяются почти дословно. Готовый ответ из хранилища стоит ноль.
4. Сократите историю диалога. Храните последние реплики и краткое изложение предыдущих вместо полной переписки.
5. Отсеивайте запросы до обращения к модели. Простая проверка на то, относится ли вопрос к области решения, экономит на всём потоке нерелевантных обращений.
6. Поставьте лимиты на уровне сценария. Максимум шагов для агента, максимум токенов на операцию, суточный бюджет с оповещением. Это защита от аварийного расхода, а не экономия в обычном режиме.
7. Автоматизируйте оценку качества выборочно. Проверяйте второй моделью не каждый ответ, а пять или десять процентов случайной выборки.
8. Используйте пакетную обработку там, где ответ не нужен немедленно. Классификация архива документов или разбор обращений за сутки не требует мгновенного отклика, и тарифы на отложенную обработку обычно ниже.
9. Обновляйте индекс поиска частями. Пересчитывать весь массив при добавлении сотни документов не нужно.
10. Унифицируйте платформу между решениями. Второе и третье ИИ-решение в компании стоят существенно дешевле первого, если переиспользуют промежуточный слой, журналирование, разграничение прав и команду эксплуатации.

Чего делать не стоит. Экономить на тестовых наборах и контроле качества, потому что без них вы потеряете способность замечать деградацию. Экономить на разграничении прав доступа. Выбирать самую дешёвую модель без проверки на своих данных, потому что разница в качестве перекладывается в ручную доработку, а часы людей дороже токенов.

Как сравнивать коммерческие предложения подрядчиков

Предложения на один и тот же проект отличаются в три или пять раз, и причина почти всегда в разном объёме работ, а не в разной жадности. Сравнение возможно только после приведения к одной границе системы.

Вопросы, которые я задаю всем участникам отбора в одинаковой формулировке.

• Что входит в стоимость подготовки данных и кто выполняет очистку исходных документов.
• Сколько часов нашего экспертного времени потребуется и на каких этапах.
• Какая модель используется, кто оплачивает её работу и по какому тарифу.
• Какая стоимость обработки одной операции получается на расчётном объёме.
• Как измеряется качество, какой целевой показатель фиксируется в договоре и как он проверяется при приёмке.
• Что входит в поддержку, каково время реакции и какова стоимость за год.
• Кому принадлежат результаты работ, включая промпты, сценарии, тестовые наборы и векторный индекс.
• Что происходит при смене версии модели поставщиком и за чей счёт выполняется миграция.
• Какие интеграции включены, а какие требуют доработок на нашей стороне.
• Как решение передаётся нашей команде, если мы решим эксплуатировать его самостоятельно.

Два пункта из этого списка требуют особого внимания. Принадлежность артефактов определяет, сможете ли вы сменить подрядчика без повторного прохождения всего пути. Если тестовые наборы и сценарии остаются у исполнителя, стоимость перехода к другому поставщику равна стоимости нового внедрения, и это надо учитывать в расчёте как риск.

Второй пункт это фиксация качества. Предложение без измеримого показателя приёмки дешевле того, где показатель зафиксирован, но разница компенсируется вашими расходами на доработку после запуска. Сравнивайте не цену проекта, а цену проекта вместе с обязательствами по качеству и с объёмом работ, который остаётся на вашей стороне.

Признаки, по которым предложение стоит отложить

• Фиксированная цена без этапа аналитики. Это означает либо огромный скрытый запас, либо неизбежный пересчёт в середине проекта.
• Отсутствие строки на подготовку данных. Либо её выполнит ваша команда, не зная об этом, либо работа не будет выполнена вовсе.
• Обещание качества выше девяноста пяти процентов до знакомства с вашими данными.
• Отсутствие расчёта операционной стоимости на год. Подрядчик либо не считал, либо не хочет показывать.
• Описание пилота как готового решения, без перечня того, что добавится при промышленном запуске.

Чек-лист расчёта TCO перед запуском проекта

Этот список я использую как форму приёмки расчёта. Если по каждому пункту есть ответ в документе, расчёт можно защищать перед финансовой службой.

1. Зафиксирована граница системы, перечислены исключённые расходы с объяснением.
2. Выбран горизонт расчёта не менее тридцати шести месяцев.
3. Собраны все шесть групп затрат, включая внутреннее время сотрудников в денежном выражении.
4. Затраты разделены на капитальные и операционные, формулировки согласованы с бухгалтерией.
5. Построена модель нагрузки с разбивкой по месяцам и с кривой роста использования.
6. Посчитана стоимость входящих и исходящих токенов отдельно, учтён объём контекста.
7. Рассчитаны три сценария, включая сценарий активного роста потребления.
8. Сравнены как минимум два варианта архитектуры на одном горизонте.
9. Включены расходы на обновление модели и пересчёт индекса хотя бы один раз за горизонт.
10. Учтены расходы на безопасность, соответствие требованиям и юридическое сопровождение.
11. Заложена поддержка в размере от двадцати до тридцати пяти процентов стоимости внедрения в год.
12. Добавлен резерв от пятнадцати до двадцати пяти процентов для первого проекта.
13. Зафиксирован базовый уровень процесса до внедрения в измеримых показателях.
14. Эффект разделён по степени доказуемости, в расчёт окупаемости включены только проверяемые категории.
15. Определён владелец решения на стороне бизнеса и источник бюджета на эксплуатацию.
16. Настроен учёт потребления по решениям и подразделениям с оповещениями о превышении.
17. Описан порядок пересчёта TCO по факту, например раз в квартал в первый год.

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

Частые вопросы о стоимости владения корпоративным ИИ

Почему подрядчик не называет цену сразу

Потому что стоимость определяется не классом задачи, а состоянием ваших данных и процессов. Один и тот же ассистент по базе знаний обходится в разы дешевле компании с актуальным структурированным архивом, чем компании с тремя тысячами документов в произвольных форматах и без описанных правил. Назвать цифру до знакомства с данными можно только с огромным запасом, и этот запас вы оплатите. Разумный порядок это небольшой платный этап обследования, который завершается сметой и расчётом операционной стоимости.

Сколько стоят токены в месяц

Для внутреннего ассистента на полторы или две сотни активных пользователей расход на модель при оплате по факту использования составляет обычно от десяти до сорока тысяч рублей в месяц. Для решения в клиентском обслуживании с потоком в несколько десятков тысяч обращений от пятидесяти до трёхсот тысяч. Для агентских сценариев в сложных процессах диапазон шире и начинается от ста тысяч. Эти цифры ориентировочные, и они полезны только как проверка на разумность собственного расчёта. Считать всё равно нужно от объёма контекста и числа операций.

Локальная модель дороже облака

На коротком горизонте дороже всегда. На трёхлетнем зависит от загрузки. При ровной загрузке выше половины мощности собственная инфраструктура выигрывает, обычно начиная с периода от восемнадцати до тридцати месяцев. При загрузке ниже трети вы платите за простой ускорителей, и оплата по факту использования остаётся выгоднее на всём горизонте. Кроме экономики есть второй мотив, который для ряда отраслей решает вопрос независимо от цифр, это требование не выпускать данные за пределы контура.

Во сколько обходится поддержка

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

С чего дешевле начать

С одного процесса, который выполняется часто, имеет описанные правила и измеримый результат. Оплата по факту использования вместо покупки оборудования, готовая платформа вместо собственной разработки, пилот на реальных данных вместо презентации. Обязательно с фиксацией базового уровня до начала работ, иначе эффект потом нечем будет доказать. Такой старт стоит от нескольких сотен тысяч до полутора миллионов рублей и даёт главное, чего не даст ни один расчёт на бумаге, это ваш собственный профиль нагрузки и качество на ваших данных. Дальнейшие решения об архитектуре и масштабировании принимаются уже на фактах.

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