Закупка LLM для крупной компании: инвойсинг и доступы

Почему закупка стопорится

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

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

Обычно тормозят четыре вещи:

• нет одного владельца процесса со стороны компании;
• ИТ и финансы считают проект в разных единицах;
• ИБ подключают слишком поздно;
• правила по логам, персональным данным и доступам обсуждают уже после выбора поставщика.

ИТ мыслит просто: нужен рабочий endpoint, совместимость с текущим SDK и быстрый старт без переписывания кода. Для инженеров это разумно. Когда пилот горит, команда ищет самый короткий путь. Иногда даже предлагает временный вариант с корпоративной картой или оплатой с последующей компенсацией. Для бухгалтерии и юристов это плохой сценарий. Потом сложно закрыть расходы, объяснить лимиты и понять, кто вообще взял на себя обязательства по сервису.

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

С ИБ требования еще жестче. Если в запросы могут попасть персональные данные, вопросы возникают сразу: где хранятся логи, кто видит промпты, как маскируются PII, сколько живут бэкапы, можно ли включить аудит. Когда эти вопросы задают в конце, процесс почти всегда встает.

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

Кто принимает решения и за что отвечает

Сделка часто буксует из-за размытых ролей. Если ИТ выбирает API, финансы ждут понятный счет, а ИБ узнает о проекте в последний момент, пилот зависает на недели.

Обычно нужны четыре владельца решения. Бизнес-владелец отвечает за цель пилота: зачем компании нужен LLM, какой процесс он меняет и сколько можно потратить без долгих согласований. ИТ отвечает за подключение: совместимость с SDK, формат API, лимиты, маршрутизацию запросов, мониторинг и сроки интеграции. Финансы проверяют схему расчетов, счет на юрлицо, закрывающие документы и бюджет. ИБ решает, какие данные можно отправлять в модель, кому давать доступ и какие журналы хранить.

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

Если компания берет OpenAI-совместимый шлюз вроде RU LLM, технических вопросов обычно становится меньше: можно сохранить SDK, код и промпты, а поменять только base_url. Но это не отменяет проверки со стороны ИБ и финансов. ИБ все равно смотрит на хранение логов в РФ, маскирование PII, аудит и требования 152-ФЗ. Финансы проверяют рублевый B2B-инвойсинг и документооборот.

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

Если пилот запускают для поддержки, бизнес-владелец фиксирует метрику, например снижение времени ответа на 15%. ИТ подключает API в тестовый контур. ИБ разрешает только обезличенные обращения. Финансы открывают лимит на пилот. При такой схеме каждый понимает, что именно он должен подписать.

Что согласовать до первого счета

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

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

Дальше определите, что именно команда будет отправлять в модель. Формулировка "только текст" бесполезна. Нужен список типов данных: обращения клиентов, внутренние документы, фрагменты CRM и тикетов, персональные данные или их маскированные версии.

Именно здесь обычно всплывает 152-ФЗ и реальный объем риска. Если в запросы попадают ФИО, телефоны, номера договоров или история заказов, ИБ и юристы должны сразу понимать, можно ли это отправлять, в каком виде и где будут храниться логи.

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

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

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

Кто отвечает за лимиты

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

Если доступ идет через шлюз вроде RU LLM, ИТ может сохранить текущие SDK и код, а финансы - получить B2B-инвойсинг в рублях и расчеты внутри РФ. Но даже в таком случае внутренний владелец расходов нужен с первого дня.

Как оформить B2B-инвойсинг по шагам

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

Одна таблица на весь контур

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

Одна такая таблица сразу снимает две частые проблемы. Финансы видят общий объем, а ИТ не заказывают доступы "на всякий случай" без понятного владельца бюджета.

Потом сравните провайдеров не по демо и не по обещаниям, а по пяти вопросам:

1. По какой юрсхеме идет договор: российское юрлицо, иностранный поставщик или реселлер.
2. В какой валюте выставляют счет и кто несет курсовой риск.
3. Какие документы вы получите для оплаты и ежемесячной сверки.
4. Есть ли лимиты по расходу и можно ли их менять без нового согласования.
5. Что происходит после пилота: новый договор, допсоглашение или переход в рабочий режим.

Для многих компаний после такого сравнения список сильно сужается. Если нужен B2B-инвойсинг в рублях, закрывающие документы по российской практике и хранение логов в РФ, лучше отсечь неподходящие варианты в самом начале, а не после тестов. Для российского контура шлюз вроде RU LLM часто удобен именно по этой причине: один OpenAI-совместимый endpoint, биллинг внутри РФ и расчеты по ставкам провайдеров без отдельной наценки на API.

Что зафиксировать до первого счета

Перед оплатой пропишите лимит на пилот, срок оплаты, период сверки и кто подписывает расхождения. Не оставляйте формулировки вроде "по факту использования" без метода расчета. Иначе у финансов сразу появится вопрос, как проверять объем и кто подтверждает, что он верный.

Еще один полезный шаг - заранее описать условие перехода в прод. Например: пилот идет 30 дней с потолком расходов 500 000 рублей, затем проект переходит в рабочий режим только после приемки со стороны ИТ, ИБ и владельца бюджета. Если пилот не прошел, доступы закрывают, а счета останавливают на согласованной дате.

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

Как выдать доступы без лишнего риска

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

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

Базовая схема довольно простая:

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

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

Для крупных компаний одного разделения ключей мало. Нужны журналы запросов, где видно, какой ключ вызвал модель, когда это произошло и какой сервис стоял за вызовом. При этом сами журналы не должны превращаться в склад персональных данных. Если через LLM проходят ФИО, телефоны, номера договоров или обращения клиентов, такие поля лучше маскировать до записи в лог. В российском контексте это прямо связано с 152-ФЗ. Если нужен российский контур, у RU LLM есть хранение логов и бэкапов в РФ, встроенное маскирование PII и аудит по каждому запросу. Это заметно упрощает разговор с ИБ и юристами.

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

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

Пример: пилот для службы поддержки

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

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

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

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

ИБ задает простое правило: в пилот попадают только обезличенные обращения клиентов. Имя, телефон, адрес, номер договора и другие персональные данные либо удаляют до отправки, либо маскируют автоматически. Для компании с требованиями 152-ФЗ это нормальная граница даже на тестовом этапе.

Через две недели команда смотрит не на общее впечатление, а на цифры:

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

Если время ответа упало хотя бы на 15-20%, а качество не просело, пилот можно расширять. Если расходы растут, а пользы мало, не стоит покупать больше доступа в надежде, что все само выровняется. Гораздо честнее открыть журнал запросов, найти слабые промпты, посмотреть, где поддержка передает слишком грязный текст, и только потом решать вопрос с масштабированием.

Именно так проект перестает быть абстрактной идеей. У каждой команды есть своя зона ответственности, у пилота есть лимит, а у результата - цифры, которые можно показать ИТ, финансам и ИБ.

Где чаще всего ошибаются

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

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

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

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

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

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

Помогает простая дисциплина:

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

Если команда работает через шлюз вроде RU LLM, часть этих вопросов проще закрыть сразу: сохранить прежний SDK, отдельно настроить доступы и аудит, а расчеты вести по B2B-счету в рублях. Но внутренние правила все равно нужны. Без них хаос просто переедет на новый инструмент.

Быстрая проверка перед оплатой и запуском

Перед оплатой не нужен еще один длинный раунд согласований. Нужен короткий созвон на 20-30 минут, где ИТ, финансы и ИБ подтверждают несколько вещей. Если хотя бы одна из них висит в воздухе, запуск почти всегда сдвигается по срокам или ломается на первом инциденте.

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

Проверьте:

• договор и счет согласованы без открытых правок, понятны реквизиты, валюта, порядок оплаты перерасхода и закрывающие документы;
• назначены владельцы за доступы, бюджет и логи;
• по каждому ключу стоят лимиты и есть привязка к сервису или команде;
• правила по 152-ФЗ записаны в понятном виде: где хранятся логи, попадают ли в них персональные данные, кто видит промпты, как работает маскирование PII, сколько живут бэкапы, кто может выгружать аудит;
• есть план отключения: отзыв доступов, замена ключей, резервный маршрут на другой API и человек, который принимает решение об остановке.

Если вы работаете через шлюз вроде RU LLM, добавьте еще одну проверку: кто меняет base_url в проде и кто подтверждает, что старые ключи внешнего провайдера больше не используются там, где этого быть не должно.

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

Что делать дальше

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

Сразу назначьте владельцев по именам. ИТ отвечает за интеграцию и лимиты, финансы - за договор, счет и оплату, ИБ - за доступы к API, логи и правила работы с данными. Если ответственность не закреплена, проект почти всегда застревает на мелочах.

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

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

Для работы внутри РФ смотрите не только на цену токена. Проверьте, есть ли B2B-инвойсинг в рублях, хранение логов в России, аудит, маскирование PII и понятный процесс под требования 152-ФЗ. Именно эти детали потом спрашивают финансы, ИБ и внутренний аудит.

Если нужен единый OpenAI-совместимый слой с биллингом и логами внутри РФ, можно смотреть на RU LLM. В таком варианте команда сохраняет текущие SDK, код и промпты, а у ИТ и безопасности появляется один контролируемый вход вместо набора прямых подключений к разным провайдерам.

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