Как планировать бюджет на искусственный интеллект в компании

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

Из чего складывается бюджет на ИИ-проект

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

Разовые затраты на запуск

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

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

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

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

Регулярные расходы на содержание

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

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

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

Как соотносятся эти две части на практике

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

Варианты внедрения и их стоимость

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

Готовые платформы и подписки

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

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

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

Гибридные решения

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

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

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

Своя разработка под задачу

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

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

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

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

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

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

Своя инфраструктура, облако или оплата по токенам

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

Оплата по токенам

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

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

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

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

Аренда вычислительных мощностей в облаке

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

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

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

Покупка собственного оборудования

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

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

Как комбинировать способы оплаты

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

Пошаговый расчёт бюджета

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

1. Оценка задачи и ожидаемого результата.
2. Выбор типа решения и способа развёртывания.
3. Расчёт стартовых инвестиций.
4. Прогноз ежемесячных расходов на двадцать четыре месяца.
5. Резерв на доработки.

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

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

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

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

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

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

Проект без резерва не экономит деньги. Он просто переносит разговор о деньгах на тот момент, когда отказаться от доработок уже нельзя.

Пример расчёта: как разложить миллион

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

Статья расходов	Сумма, руб.	Доля
Исследование задачи, разбор обращений, постановка	60 000	6 %
Подготовка базы знаний и приведение данных в порядок	150 000	15 %
Разработка решения и интеграция с чатом и учётной системой	300 000	30 %
Тестирование, пилот, обучение операторов, регламенты	90 000	9 %
Эксплуатация за 9 месяцев после запуска	250 000	25 %
Резерв на доработки	150 000	15 %
Итого	1 000 000	100 %

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

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

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

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

Распределение бюджета по направлениям

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

Пропорции первого года

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

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

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

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

Правило первой трети

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

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

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

Пилот стоит дорого не тогда, когда он маленький и плохой, а тогда, когда он большой и ничего не измеряет.

Бюджет при нескольких проектах одновременно

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

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

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

Скрытые расходы, которые не попадают в смету

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

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

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

Что меняется при масштабировании решения

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

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

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

Три подхода к планированию мощности

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

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

Что ещё растёт вместе с решением

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

Расчёт ROI и экономического эффекта

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

Как посчитать выгоду в деньгах

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

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

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

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

Эффекты, которые трудно измерить

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

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

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

Ошибки при расчёте ROI

Типовых искажений немного, и они повторяются из проекта в проект.

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

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

Ошибки при планировании бюджета на ИИ

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

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

Как проверить смету за десять минут

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

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

Последний вопрос самый продуктивный. Честный ответ на него обычно добавляет к смете от пятнадцати до тридцати процентов и избавляет от неприятных открытий в середине проекта.

С чего начать при минимальном бюджете

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

Рабочая последовательность при бюджете до двухсот тысяч рублей выглядит так.

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

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

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

Чего не стоит делать при малом бюджете

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

Ориентиры по затратам для разного масштаба бизнеса

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

Масштаб	Запуск первого решения	Содержание в месяц	Годовой бюджет направления
Малый бизнес и стартапы	от 0 до 400 тыс. руб.	от 10 до 60 тыс. руб.	до 1 млн руб.
Средний бизнес	от 500 тыс. до 4 млн руб.	от 50 до 300 тыс. руб.	от 1,5 до 10 млн руб.
Крупный бизнес	от 4 до 25 млн руб. на решение	от 300 тыс. до 2 млн руб.	от 15 млн руб. и выше

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

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

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

Как выбрать подрядчика и не переплатить

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

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

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

Когда подрядчик не нужен

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

Как снизить расходы на ИИ

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

Технические способы перечислены в порядке отношения результата к усилиям.

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

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

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

Частые вопросы

Сколько в среднем стоит внедрение искусственного интеллекта

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

За какой срок проект окупается

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

Что входит в ежемесячные расходы после запуска

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

Можно ли начать без бюджета

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

Нужна ли своя модель для защиты данных

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

Какие компетенции нужны внутри компании

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

Как заложить бюджет, если цены на модели постоянно меняются

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

Что делать, если бюджет уже исчерпан, а результата нет

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

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