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