Бюджет внедрения ИИ: стоимость разработки, эксплуатации и окупаемость

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

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

Мои ориентиры по стоимости и срокам

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

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

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

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

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

Что должно быть в смете помимо вызова модели

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

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

Разработка и обмен данными. В смету входят приём писем или документов, обращение к модели, расчёты, проверки и сохранение результата. Для связи с 1С, Битрикс24, amoCRM, почтой или сайтом обычно используется API - программный интерфейс, через который системы обмениваются данными. Ограничения этого интерфейса, лимиты запросов и необходимость ручных выгрузок могут заметно увеличить работу.

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

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

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

Как рассчитать расходы на модель

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

Для предварительной оценки нужны четыре показателя:

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

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

Для каждого типа вызова расчёт выглядит так:

Месячная стоимость = число вызовов × (средний объём входа × тариф входа + средний объём ответа × тариф выхода).

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

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

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

Как управлять расходом без потери качества

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

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

Как размещение модели меняет бюджет

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

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

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

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

Ни российское облако, ни локальная модель сами по себе не подтверждают соблюдение 152-ФЗ. Компания определяет обязанности и основания обработки с профильными специалистами, а я реализую согласованные технические требования. Для проектов со счетами, актами и другими документами полезно заранее разобрать и проверку данных перед загрузкой в 1С.

Ограничения, которые стоит проверить до основной разработки

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

Возможности внешних систем

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

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

Способ получения данных

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

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

Корпоративные требования

Когда я руководил развитием продукта для выбора варианта разработки месторождения в «Газпром нефти», работа учитывала корпоративные стандарты безопасности, обработки данных и импортозамещения. Эти требования влияли на устройство системы и состав работ.

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

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

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

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

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

Наконец, отдельная ИИ-система нужна не для каждой задачи. Если достаточно штатной настройки Битрикс24, amoCRM или 1С, разумно начать с профильного интегратора. Если действия полностью описываются правилами, их можно выполнить обычным кодом без языковой модели. А когда сотрудники каждую неделю меняют порядок работы, сначала полезно согласовать сам процесс.

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

Когда можно считать окупаемость

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

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

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

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

При положительной месячной разнице простой срок окупаемости считается так:

Срок окупаемости в месяцах = разовые вложения / (месячная денежная выгода − текущие месячные расходы).

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

Освобождённые часы и деньги нужно учитывать отдельно

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

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

Поддержка не является обязательной подпиской

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

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

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

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