Токены в договоре: кто платит за ИИ в IT-консалтинге

11 мин чтения
Stanislav Belyaev
Stanislav Belyaev Engineering Leader в Microsoft
Токены в договоре: кто платит за ИИ в IT-консалтинге

Клиент смотрит в счёт и видит строку «AI API usage – $3 200». Вопрос немедленный: «Это что вообще такое?» Консультант объясняет: токены, запросы к Claude API, стоимость инференса. Клиент кивает и уходит разбираться с финансовым директором. Через неделю юрист присылает письмо: «В договоре такой статьи расходов нет».

Именно так начинается большинство конфликтов вокруг AI-затрат в IT-консалтинге. Договор писался до того, как токены стали реальными деньгами – и ни одна из сторон не подумала зафиксировать эту статью расходов.

В моей практике я видел этот сценарий трижды за последний год – каждый раз в проектах, где техническая команда внедрила AI-инструменты быстрее, чем контрактный отдел успел обновить договор. По данным исследования Benchmarkit и Mavvrik (2025), около 85% организаций ошибаются в прогнозе AI-затрат более чем на 10%, а каждый четвёртый проект превышает запланированный AI-бюджет больше чем вполовину. При этом доля AI-затрат в IT-проектах уже составляет 5–15% от общего бюджета – цифра, которую больше нельзя прятать в «операционные расходы подрядчика».

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

За 2024–2026 годы рынок IT-консалтинга выработал три устойчивые схемы учёта AI-затрат. Они не продиктованы теорией контрактного права – они выросли из практики, конфликтов и переговоров.

Модель 1: Прямая передача затрат (pass-through) – прозрачность ценой сложности

Клиент платит фактические затраты на токены плюс наценку подрядчика (обычно 10–20%). Luxoft (DXC) используют именно эту схему: клиент получает доступ к панели потребления токенов в реальном времени, видит разбивку по моделям, задачам и пользователям.

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

Эта схема хорошо работает в Time & Materials-проектах, где заказчик и так принимает переменность затрат как данность.

Модель 2: Пакетирование (бандлинг) – простота ценой риска

EPAM и часть Softline работают иначе: AI-затраты входят в фиксированную ставку или фиксированный бюджет проекта. EPAM позиционирует это через платформу AI/RUN – пакет инструментов, который консультант приносит с собой.

Клиенту это понятно: одна строка в договоре, предсказуемый счёт. Подрядчику – рискованно: если потребление токенов оказалось выше расчётного, маржа съедается. Если ниже – подрядчик зарабатывает на неиспользованном ресурсе, что создаёт странный стимул использовать AI меньше, а не больше.

На практике EPAM решает это через агрессивное кэширование промежуточных результатов и маршрутизацию дешёвых моделей на рутинные задачи. Softline идёт ещё дальше – автоматические предохранители (circuit breakers), которые переключают задачу на более дешёвую модель, если стоимость запроса превышает порог.

Работает на Fixed Price-контрактах, где предсказуемость важнее прозрачности.

Модель 3: Гибрид – доминирует у крупных игроков

Big 4, Accenture, BCG используют схему, которую на практике называют «базовый лимит использования» (fair use allowance): базовый пакет токенов включён в стоимость проекта, превышение оплачивается отдельно по согласованной ставке. По оценкам отрасли, типичный AI-контракт у Big 4 начинается от $500 000.

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

Параметры гибридной модели, которые нужно согласовывать в договоре:

  • размер базового пакета (обычно рассчитывается на основе сценарного бюджетирования – подробнее ниже)
  • ставка за превышение
  • механизм контроля (кто и как мониторит потребление)
  • частота сверки (reconciliation) – ежемесячно, поквартально?

Сценарное бюджетирование: как считать базу

Любая из трёх моделей требует отправной точки – прогноза потребления токенов. Хорошая практика – три сценария.

Первый – базовый: если всё пойдёт как обычно, сколько запросов, к каким моделям, какой средний размер контекста? Это ваша точка отсчёта и основа для расчёта базового пакета в гибридной модели.

Второй – гарантированный объём (committed-use): то, что вы готовы гарантировать как минимум. Если у проекта есть объёмные соглашения с AI-провайдером (скидки за гарантированный объём потребления), этот уровень должен быть покрыт проектом в любом случае.

Третий – стресс-сценарий. Что если объём данных окажется втрое больше расчётного? Или клиент захочет добавить ещё два сценария применения в середине проекта? Буфер 10–15% от базового сценария покрывает незапланированные итерации. Буфер 30–40% нужен при высокой неопределённости задачи – типичная ситуация для ранних стадий проекта, где объём работ ещё не устоялся.

В контексте резкого падения стоимости инференсав 280 раз за два года по данным Stanford AI Index – есть ещё один аргумент для прозрачного учёта токенов: стоимость одного и того же набора задач через год может быть существенно ниже. Если в договоре зафиксирована фиксированная ставка без механизма пересмотра, клиент рискует переплачивать за подешевевший ресурс.

Именно поэтому разумный договор содержит положение о пересмотре базовой ставки при изменении рыночной стоимости AI-сервисов более чем на X% за период.

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

Доступ сразу после регистрации

Начать обучение

Что должно быть в договоре: семь положений

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

Первое, без чего не работает ничего остального, – таксономия AI-затрат. Отдельная строка для каждого типа: обучение и файн-тюнинг, инференс (токены), подготовка данных, инфраструктура, управление изменениями. Без этой детализации «AI costs» в счёте – черный ящик, из которого вылезают споры.

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

Особо стоит выделить право маршрутизации моделей. Подрядчик вправе использовать более дешёвые модели для рутинных задач без уведомления клиента, если качество результата остаётся в пределах согласованных метрик. Именно маршрутизация – Kimi K2.6 или DeepSeek V4 Pro для сложных задач, Qwen 3.6 Flash или DeepSeek V4 Flash для черновиков – даёт 40–70% экономии по сравнению с использованием одной флагманской модели. Без этого права в договоре подрядчик формально обязан согласовывать каждую замену.

Остальное – более стандартно, но не менее важно:

  • Метрики результата – стоимость за результат вместо стоимости за токен. «Стоимость подготовки одного статус-отчёта» понятна бизнесу, «$0,014 за тысячу токенов» – нет.
  • Уведомление о смене модели – за 30 дней до материальной замены AI-модели в продакшне. Смена модели меняет поведение системы.
  • Конфиденциальность данных – явно: какие данные, в какое облако, под какие гарантии, на какой срок (критично для российского контекста).
  • IP-права на AI-выходы – кому принадлежат fine-tuned модели, промпты, производные датасеты. По умолчанию серая зона.

Регуляторный ландшафт СНГ для AI-контрактов

Правовой контекст СНГ: не про деньги, а про регуляторику

Стандартный разговор про AI-биллинг в Европе или США – это разговор про финансы. В СНГ добавляется слой, который важнее: регуляторный риск. Игнорировать его в договоре – ошибка.

Россия: самый сложный контекст

Гражданский кодекс (ст. 421) позволяет структурировать прямую передачу API-затрат несколькими способами: как материалы в договоре подряда (подрядные материалы), как расходы субподрядчика или как часть цены услуги. Каждый вариант имеет разные налоговые и НДС-последствия, и это нужно согласовывать с бухгалтерией, а не решать самостоятельно.

С января 2025 года действует двукратный коэффициент налогового вычета на расходы по отечественному AI-программному обеспечению (Федеральный закон 176-ФЗ). Иностранный AI получает стандартный коэффициент 1x. На практике это означает финансовый стимул использовать YandexGPT или GigaChat вместо OpenAI – и это нужно учитывать при выборе стека и формулировке договора.

Но главный риск в России – валютный контроль. Платежи за API-сервисы OpenAI, Anthropic и других американских или европейских провайдеров должны проходить через рублёвые счета типа «С». 80% валютной выручки подлежит обязательной продаже. Авансовые платежи нерезидентам ограничены 30%. На практике это означает, что обещать клиенту «доступ к Claude API» в российском проекте – значит принять на себя регуляторный риск, который может реализоваться в середине проекта.

Ожидаемый законопроект об ИИ (принятие анонсировано на сентябрь 2027 года) классифицирует иностранные AI-сервисы как «трансграничные AI-технологии». Если данные уходят за рубеж – это потенциально запрещённая операция. Формулировки ещё прорабатываются, но консервативная позиция выглядит так: в новых контрактах с российскими клиентами не гарантировать доступ к иностранным AI-API, строить архитектуру на отечественных или self-hosted решениях.

Суды при этом всё чаще рассматривают споры по российскому праву вместо международного арбитража – даже если договор предусматривал иное (так называемый «Закон Лугового», ст. 248.1–248.2 АПК РФ). Для IT-консалтинга это значит: международная арбитражная оговорка в договоре с российским контрагентом защищает хуже, чем принято считать.

Казахстан: наиболее структурированная среда

С 18 января 2026 года в Казахстане действует специальный закон об ИИпервый подобный документ в СНГ. Закон явно возлагает ответственность за AI-выходы на разработчика, владельца или пользователя системы. Для IT-консалтинга это означает необходимость явно определять в договоре, кто несёт ответственность за качество AI-генерируемого контента: подрядчик или клиент?

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

Налоговый контекст в Казахстане добавляет сложность: 20% налог у источника (withholding tax) на платежи нерезидентам за услуги. Если ваш AI-провайдер – иностранная компания без казахстанского юрлица, этот налог ложится на покупателя услуги.

Беларусь и Узбекистан: крайние точки спектра

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

Узбекистан – другой полюс. Никакого специального AI-законодательства, общее контрактное право, наиболее открытый валютный режим для платежей иностранным API-провайдерам. Растущий IT-аутсорсинговый хаб (свыше 100 тыс. занятых в секторе, около 12% годового роста). Для проектов, где важен доступ к западным AI-сервисам без ограничений, Узбекистан – наименее рискованная юрисдикция в СНГ.

Разобрались с контрактами – теперь практика. Попробуйте ИИ на 9 реальных задачах менеджера: бесплатный открытый модуль, без регистрации.

Доступ сразу после регистрации

Начать обучение

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

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

Fixed Price проект

AI-затраты закладываются в фиксированную цену с буфером 15–20% от сценарного расчёта. Договор содержит положение об изменении объёма работ: если клиент добавляет новые сценарии применения AI, это фиксируется как запрос на изменение с дополнительным бюджетом. Явно прописывается право подрядчика на маршрутизацию моделей.

Риск для подрядчика: при росте цен на API (теоретически возможном, хотя тренд пока обратный) буфер может не покрыть перерасход. Страхуется положением о форс-мажоре и регуляторных изменениях.

T&M проект

Прямая передача затрат с наценкой 10–15% – наиболее честная схема. Клиент видит фактические затраты, подрядчик получает управленческую маржу за мониторинг и оптимизацию. Панель потребления – обязательный элемент: без неё прозрачная передача затрат теряет смысл, превращаясь в «верьте нам на слово».

Энтерпрайз / гибридная модель

Базовый пакет токенов рассчитывается через три сценария. Размер базы = базовый сценарий + 15%. Ставка за превышение = рыночная цена провайдера + 12% управленческой надбавки. Сверка – ежемесячно. Право на пересмотр базовой ставки – при изменении рыночных цен более чем на 25% за квартал.

Проекты в России: дополнительные соображения

Здесь три принципа, каждый из которых снижает юридический риск.

Первый – не обещать в договоре конкретный AI-инструмент, если он иностранный. Формулировка «AI-технологии по выбору подрядчика» с указанием требований к качеству результата юридически устойчивее, чем «ChatGPT Enterprise» или «Claude API».

Второй – структурировать AI-затраты как «материалы» в рамках договора подряда. Это даёт наиболее предсказуемый налоговый режим.

Третий – включить положение о регуляторных изменениях с правом пересмотра условий в течение 60 дней после вступления в силу нового нормативного акта. Учитывая скорость изменений в AI-регулировании России – право не теоретическое.

Сравнительная таблица моделей

ПараметрПрямая передачаПакетированиеГибрид
Прозрачность для клиентаВысокаяНизкаяСредняя
Предсказуемость бюджетаНизкаяВысокаяСредняя
Риск для подрядчикаМинимальныйВысокийУмеренный
Операционная сложностьВысокаяНизкаяСредняя
Подходит дляT&M проектыFixed PriceКрупные проекты
ИспользуютLuxoft, DXCEPAM, SoftlineBig 4, Accenture

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

Что стоит за вопросом «кто платит»

Когда клиент спрашивает «кто платит за токены?», он на самом деле задаёт три разных вопроса. Во-первых – предсказуемость: он хочет знать, что счёт не вырастет втрое без предупреждения. Во-вторых – контроль: он хочет понимать, на что тратятся деньги. В-третьих – доверие: он хочет убедиться, что AI-затраты не превратились в центр скрытой маржи подрядчика.

Хороший договор отвечает на все три вопроса явно, а не оставляет их подразумеваемыми.

Интересно, что самый болезненный конфликт возникает не там, где стороны не договорились о цене – а там, где они договорились, но не договорились о механизме контроля. Клиент готов платить $3 200 за AI API. Клиент не готов узнать об этом из счёта, а не из ежемесячного отчёта подрядчика.

Это – навык работы с ИИ, который не очевиден из первого взгляда. Проблема «убедительного результата», которую фиксирует Stanford AI Index в концепции «неровной границы», работает и здесь: AI-инструменты выглядят простыми снаружи и оказываются сложными внутри. То же справедливо для договоров, которые их сопровождают.

Вопрос к вам: в каком из трёх конфликтов – предсказуемость, контроль, доверие – вы чаще всего оказывались в ситуации «договор этого не покрывал»?

Специализация

От разовой задачи к системной работе с ИИ

Курс построен для менеджеров в СНГ: инструменты, доступные без VPN, правовые и организационные контексты, практика на реальных задачах. Фундамент + специализация по проектному управлению.

От pre-mortem до антикризисного плана
Переиспользуемые промпт-шаблоны
Сквозной кейс на реальном проекте
~300 часов экономии в год
Stanislav Belyaev

Stanislav Belyaev

Engineering Leader в Microsoft

18 лет в управлении инженерными командами. Основатель mysummit.school. 700+ выпускников в Яндекс Практикуме и Стратоплане.