Учёт подрядчиков LLM-сервиса без слепых зон в договорах

Где появляются слепые зоны

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

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

В LLM-сервисах эта путаница особенно опасна. Когда компания работает через единый шлюз, она видит один endpoint и привычный SDK. Это удобно, но роли все равно нужно разложить по отдельности: кто проксирует запрос, кто хостит модель, кто ведет биллинг и кто считается обработчиком персональных данных по 152-ФЗ.

Обычно слепые зоны появляются в четырех местах:

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

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

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

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

Кто входит в цепочку LLM-сервиса

В схеме почти никогда нет одного подрядчика. Даже если команда видит один API и один счет, за сервисом обычно стоит несколько сторон с разными обязанностями.

Провайдер модели отвечает за саму модель, лимиты, тарифы и правила использования. Хостер держит вычисления и инфраструктуру: GPU, сеть, хранилище, резервные копии, а иногда и журналы. Интегратор встраивает LLM в продукт, настраивает вызовы, ретраи, фильтры, хранение промптов, аналитику и мониторинг. API-шлюз собирает несколько провайдеров в одну точку входа, маршрутизирует запросы, считает биллинг и иногда маскирует PII или ведет журнал аудита. Внутренняя команда заказчика тоже часть цепочки, потому что именно она решает, что писать в логи, кто видит промпты, где хранить ответы и какие данные вообще можно отправлять в модель.

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

Где роли путают чаще всего

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

Это хорошо видно на примере RU LLM. Сервис дает один OpenAI-совместимый endpoint, единый биллинг в рублях и поддержку внутри РФ. Но дальше возможны разные сценарии: запрос может уйти к внешнему провайдеру через прокси, а может быть обработан на open-weight модели, которую RU LLM хостит на своей GPU-инфраструктуре в российских ЦОДах. Для договора это не одна и та же ситуация.

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

Что занести в реестр подрядчиков

Учет подрядчиков LLM-сервиса работает только тогда, когда по каждой записи можно за пару минут понять, кто это, что он делает в цепочке, какие данные получает и кому писать при инциденте. Строки вроде "провайдер модели" или "интегратор" мало что дают. Нужна карточка подрядчика, а не просто список названий.

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

После этого подрядчику присваивают точную роль. Лучше писать не "работает с LLM", а "маршрутизирует запросы", "хостит модель", "встраивает API в продукт", "хранит логи" или "поддерживает доступы". Рядом нужно указать границы ответственности: кто отвечает за доступность API, кто маскирует ПДн, кто удаляет логи, кто разбирает инциденты.

Если команда идет через шлюз вроде RU LLM, полезно записать отдельно сам шлюз, провайдера модели и интегратора. Иначе три разные функции легко сольются в одну запись.

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

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

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

Полезный минимум для карточки такой:

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

Хороший реестр отвечает на практичный вопрос без звонков и догадок: кто участвует в обработке, что именно он видит и чем это закрыто на бумаге.

Как собрать схему по шагам

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

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

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

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

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

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

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

Если команда использует единый шлюз, не стоит писать в реестре только "один поставщик API". Отдельно отметьте сам шлюз, место хранения логов в РФ, модельный бэкенд и тех, кто получает доступ к трассировке запросов. Тогда договорная схема LLM будет совпадать с тем, как сервис работает каждый день.

Кто отвечает за данные и логи

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

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

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

Маскирование PII лучше не оставлять общей фразой. Полезнее прямо прописать, какие поля подрядчик обязан скрывать до записи в лог, а какие не должен писать вовсе. Обычно это ФИО, телефон, почта, номер договора и свободный текст из промпта, если нет ясной причины хранить его целиком. Там же стоит задать срок хранения: 30, 90 или 180 дней, в зависимости от задач поддержки, ИБ и внутренних проверок.

Журнал аудита и 152-ФЗ

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

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

Пример схемы для команды в банке

Банк запускает помощника для операторов и внутренний поиск по регламентам. Вместо прямых договоров с каждым провайдером моделей команда подключает один OpenAI-совместимый endpoint, например через RU LLM, и меняет только base_url в текущем SDK. Для разработки это удобно, но для юристов и ИБ этого мало. Одна точка входа не убирает цепочку подрядчиков, а просто скрывает ее за одним API.

В рабочей схеме обычно есть четыре роли. Банк остается владельцем продукта и заказчиком обработки. API-шлюз принимает запрос, ведет биллинг и маршрутизацию. Часть запросов уходит внешним провайдерам моделей, а часть можно направлять на модели, размещенные в РФ. Отдельно стоит интегратор, который встраивает сценарий в АБС, CRM или контактный центр.

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

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

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

Ошибки обычно начинаются не в коде, а в самой схеме подрядчиков. Команда видит один API и делает вывод, что подрядчик тоже один. Для закупки это выглядит аккуратно, но для риска и 152-ФЗ такой взгляд слишком узкий.

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

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

Третья ошибка - не разделять роли. Запись "поставщик LLM" слишком общая. Она не показывает, кто именно хостит модель, кто держит логи, кто ведет журнал аудита и кто отвечает за техподдержку.

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

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

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

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

Короткая проверка выглядит так:

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

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

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

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

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

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

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

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

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