Стоимость корпоративного ИИ: из чего складывается бюджет внедрения

Лицензионные и подписочные модели

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

Поставщики ИИ-решений предлагают несколько основных схем оплаты:

• Фиксированная лицензия — годовой или многолетний контракт с фиксированной суммой, часто привязанной к количеству пользователей или модулей функциональности
• Модель потребления — вы платите за фактический объём использования: количество запросов к API, обработанные документы, часы вычислительных ресурсов
• Гибридные схемы — базовая подписка с минимальным платежом плюс дополнительная оплата за превышение лимитов
• Одноразовая покупка с годовой поддержкой — реже встречается в корпоративном сегменте, но существует для специализированных решений

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

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

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

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

Как правильно считать лицензионные расходы

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

Второй шаг — заложить запас мощности. Даже если вы сейчас планируете небольшой проект на 50 пользователей, закладывайте в смету возможность расширения минимум на 30–50%. ИИ-решения часто становятся более полезными по мере развития, и спрос растёт органически. Если вы сейчас выберете лицензию на 50 пользователей, а через год поймёте, что нужна на 80, вам придётся покупать дополнительный пакет, часто с потерей за счёт масштабирования и эффективности переговорной позиции.

Третий важный момент — сроки контракта. Годовой контракт почти всегда выгоднее, чем ежемесячные платежи. Если поставщик предлагает ежемесячную подписку в 100 тысяч рублей, а годовую в 1 млн 50 тысяч, второй вариант на 12,5% дешевле. Но главное преимущество не только в цене, а в стабильности. Однолетний контракт даёт вам предсказуемость бюджета, что критично для финансового планирования.

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

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

Здесь нужно разобраться в архитектуре взаимодействия. Существует несколько вариантов:

• Облачное решение — поставщик полностью отвечает за инфраструктуру, вы отправляете запросы через API, данные обрабатываются на серверах поставщика
• On-premises (на собственных серверах) — вы установили ИИ-систему на своих серверах или в частном облаке, сами отвечаете за мощности и масштабирование
• Гибридная модель — часть вычислений происходит локально, часть в облаке поставщика

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

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

Если вы выбираете on-premises решение, вы должны заложить бюджет не только на саму систему, но и на инфраструктуру, которая её поддержит. Современные модели ИИ требуют мощных видеокарт (GPU) или специализированных чипов. Стоимость одного GPU среднего уровня начинается от 2–3 миллионов рублей, а для серьёзной работы компании нужно минимум несколько таких устройств, плюс резервные. Это значит, что только на оборудование можно потратить 10–20 миллионов рублей.

Но оборудование — это не всё. Нужна охлаждающая система, особый стеллаж для установки, резервная линия электропередач (GPU потребляют много электроэнергии), система мониторинга и управления отказоустойчивостью. Если одна видеокарта выходит из строя во время обработки критичного запроса, это может привести к потере данных или перерыву в работе. Нужна система, которая автоматически перенесёт вычисления на другое оборудование.

Сравнение затрат: облако vs локальная инфраструктура

Финансово это выглядит примерно так. Компания решила внедрить ИИ-модель для обработки изображений. Объём работ — обработка 10 тысяч изображений в день.

Вариант 1: облачное решение. Она платит поставщику по 10 рублей за изображение. За день — 100 тысяч рублей, за месяц — 3 млн рублей, за год — 36 млн. Плюс небольшие расходы на интеграцию и настройку (в этом примере пренебрегаем).

Вариант 2: локальная инфраструктура. Компания покупает три видеокарты (9 млн рублей), монтирует их на серверный стеллаж с охлаждением и резервными системами (2 млн), нанимает инженера для поддержки инфраструктуры (150 тысяч в месяц), платит за электричество (примерно 500 тысяч в месяц). Помимо этого, нужна лицензия на ПО для управления вычислениями (примерно 500 тысяч в год). В первый год такого решения компания потратит: 9 млн (оборудование) + 2 млн (установка) + 1.8 млн (инженер за 12 месяцев) + 6 млн (электричество) + 0.5 млн (ПО) = примерно 19.3 млн рублей.

Со второго года расходы упадут до 8.3 млн (оборудование больше не покупаем), но оборудование начнёт изнашиваться. Обычно срок жизни серьезного GPU на интенсивных вычислениях — 3–5 лет. Это означает, что компании нужно закладывать годовые амортизационные расходы на замену.

На первый взгляд, облако (36 млн в год) дороже, чем локальная инфраструктура (19.3 млн в первый год). Но если посчитать на пять лет, то облако будет стоить 180 млн, а локальное решение — примерно 48 млн (19.3 + 8.3 × 4 с учётом амортизации). Облако дороже в пять раз. Но это справедливо только если компания предсказуемо работает с одним и тем же объёмом данных. Если объём вырастет в два раза (20 тысяч изображений в день), облако просто подстроится под новый объём. В локальной инфраструктуре пришлось бы покупать ещё оборудование.

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

Третий вариант — гибридная инфраструктура

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

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

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

Интеграция с существующими системами

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

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

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

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

Более правильный подход — это API-интеграция. Вы описываете, какие данные нужны из какой системы, с какой периодичностью, в каком формате. Затем разработчик пишет код (или использует готовый коннектор), который автоматически эту интеграцию выполняет. Но это требует, чтобы целевая система имела открытый API. Если система устаревшая или сложная, API может быть отсутствовать или недокументирован.

В таких случаях приходится использовать более сложные подходы. Например, техника ETL (Extract, Transform, Load) — специалист пишет скрипт, который достаёт данные из системы одним способом (например, через базу данных), преобразует их в нужный формат и загружает в ИИ. Это работает, но требует доступа к базе данных, что часто требует согласованиия с владельцем системы и может затронуть безопасность.

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

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

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

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

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

Мониторинг качества интеграции

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

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

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

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

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

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

Кто нуждается в обучении и почему

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

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

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

Управление изменениями (change management) — это часто забываемый аспект. Люди сопротивляются переменам. Если вы просто установили ИИ и сказали людям, что теперь они будут его использовать, часть из них просто не будет это делать или будет использовать неэффективно. Нужны люди (часто менеджеры или специальные change management специалисты), которые будут объяснять, почему это внедрение нужно, какие проблемы оно решает, как оно облегчит работу.

Числовой пример. Компания с 200 сотрудниками внедряет ИИ для анализа текстов в поддержке клиентов. Разбивка обучения:

• 5 разработчиков — полное техническое обучение у поставщика (500 тыс. рублей)
• 2 бизнес-аналитика — недельное углублённое обучение (100 тыс. рублей)
• 40 операторов поддержки — краткое обучение на месте (160 тыс. рублей, из расчёта 4 тыс. за сотрудника на 4 часа обучения)
• Специалист по change management для проведения презентаций и ответов на вопросы (зарплата за три месяца — 450 тыс. рублей)

Итого примерно 1.2 млн рублей на обучение персонала. И это только прямые расходы. Косвенные расходы — это потеря производительности во время обучения. 40 операторов учатся 4 часа вместо работы, это потеря примерно половины рабочего дня. Если средний оператор поддержки генерирует для компании доход в 5 тысяч рублей в день, то потеря за один день обучения всей команды составит примерно 100 тысяч рублей.

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

Как структурировать обучение эффективно

Не все сотрудники нужно обучать одновременно. Лучший подход — фазовое внедрение с последовательным обучением. Сначала обучается небольшая группа пилотных пользователей (например, 10 операторов из 40). Они интенсивно работают с системой в течение двух недель. На этом этапе выясняются основные проблемы и неудобства. Затем опыт адаптируется, и остаток команды обучается уже по отработанной схеме, что требует меньше времени и ресурсов.

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

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

Настройка и тонирование моделей под задачи компании

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

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

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

Существует несколько подходов к адаптации модели:

• Fine-tuning — вы предоставляете поставщику примеры ваших данных (в данном случае фотографии растений вашей компании с правильными диагнозами), и он дополнительно обучает модель на этих данных. Это требует от 100 до 1000 примеров, в зависимости от сложности задачи
• Prompt engineering — вы настраиваете инструкции, которые даёте ИИ, чтобы улучшить результаты. Например, вместо просто "определи болезнь растения" вы даёте инструкцию "определи болезнь редкого растения семейства орхидей, основываясь на следующих признаках". Это не требует обучения, но требует экспериментирования
• Создание собственной модели — вы обучаете с нуля собственную модель на данных вашей компании. Это самый дорогой вариант, но часто даёт лучшие результаты

Fine-tuning обычно стоит от 500 тысяч до 2 млн рублей, в зависимости от размера модели и количества требуемых примеров. Требуется подготовка данных (помечивание примеров с правильными ответами), что может быть трудоёмким. Если у вас есть 500 фотографий растений, вам нужно их вручную помечивать: на какой фото заболевание А, на какой Б, на какой нормальное здоровое растение. Для каждого примера нужно потратить 5–10 минут. Это означает 40–80 часов работы, что стоит примерно 200–400 тысяч рублей (если привлекать специалистов).

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

Оценка качества адаптированной модели

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

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

Часто адаптированная модель не достигает желаемого качества с первой попытки. Тогда требуется цикл улучшения: вы смотрите, на каких примерах модель ошибается, добавляете больше примеров такого типа, переобучаете модель, тестируете снова. Этот цикл может повторяться несколько раз, и на него может уйти несколько недель работы специалиста, что стоит 500 тысяч — 1 млн рублей.

Непрерывная адаптация

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

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

Это означает, что нужна выделенная команда (или часть команды) для постоянного мониторинга качества модели, сбора новых данных и переобучения. Это может быть один инженер, работающий неполный день, или целая небольшая команда, в зависимости от критичности системы. Зарплата такого специалиста — 150–250 тысяч рублей в месяц, что означает годовой расход 1.8–3 млн рублей только на поддержание качества модели.

Техническая поддержка и обслуживание

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

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

Виды проблем, с которыми придётся сталкиваться

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

Проблемы с качеством результатов — модель начинает давать неправильные результаты. Это может быть потому, что входящие данные изменили формат, или потому, что модель "дрейфовала" (её качество постепенно падает с течением времени). Требуется анализ и переобучение модели.

Сбои интеграции — данные перестали передаваться из одной системы в другую. Может быть проблема с API, с аутентификацией, с форматом данных. Нужно быстро найти и исправить.

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

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

Стоимость поддержки обычно рассчитывается как процент от стоимости лицензии поставщика, примерно 15–25% в год. Если лицензия стоит 10 млн рублей в год, поддержка поставщика будет стоить 1.5–2.5 млн рублей в год. Плюс к этому компания может нанять собственного инженера, который будет координировать работу с поставщиком и заниматься локальными проблемами. Такой инженер будет стоить 200–300 тысяч рублей в месяц.

Скрытые расходы на поддержку

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

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

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

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

Итого на техническую поддержку компания должна закладывать 20–30% от годовой стоимости всех расходов на ИИ-систему, помимо лицензии. Если общие расходы в первый год составили 50 млн рублей (лицензии, инфраструктура, интеграция, обучение, адаптация), то на поддержку нужно закладывать дополнительно 10–15 млн рублей в год.

Риски и неожиданные расходы

Все предыдущие статьи расходов можно посчитать заранее с точностью плюс-минус двадцать процентов. Риски считаются иначе. Это не строка в смете, а вероятностная величина, которую нужно закладывать резервом. Компании, которые внедряют ИИ впервые, обычно резерв не закладывают вовсе, и именно поэтому проект выходит за рамки бюджета не на десять процентов, а в полтора-два раза.

Разберём основные источники незапланированных расходов по убыванию частоты встречаемости.

Данные оказались хуже, чем предполагалось

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

Типичные обнаружения:

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

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

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

Пилот прошёл успешно, промышленная эксплуатация провалилась

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

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

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

Изменение условий поставщика

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

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

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

Кадровый риск

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

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

Регуляторные и юридические расходы

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

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

Размер резерва

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

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

Как оптимизировать бюджет на ИИ-внедрение

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

Начинайте с узкой задачи с измеримым результатом

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

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

Хорошие кандидаты для первого проекта:

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

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

Разделяйте обязательное и желаемое

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

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

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

Считайте полную стоимость владения, а не стоимость внедрения

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

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

Статья расходов	Год 1	Год 2	Год 3
Лицензии и подписки	есть	есть	есть
Оборудование и инфраструктура	основная часть	эксплуатация	эксплуатация и частичная замена
Интеграция и разработка	основная часть	доработки	доработки
Подготовка данных	основная часть	поддержание качества	поддержание качества
Обучение персонала	основная часть	новые сотрудники	новые сотрудники
Адаптация и переобучение моделей	есть	есть	есть
Поддержка и обслуживание	частично	полный год	полный год
Внутренние трудозатраты	высокие	средние	низкие
Резерв на риски	30-40 процентов	15 процентов	15 процентов

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

Переговорная позиция и структура контракта

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

Что реально влияет на условия:

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

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

Что можно делать внутренними силами, а что нельзя

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

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

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

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

Порядок действий при расчёте бюджета

Сводя всё вместе, последовательность работы с бюджетом ИИ-проекта выглядит так.

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

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

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

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