Договор с агрегатором LLM и условия выхода

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

Хороший договор описывает выход как отдельную услугу с результатами, сроками и проверкой приемки. Право отказаться от договора и техническая способность уйти - разные вещи. Статья 782 ГК РФ регулирует односторонний отказ от договора возмездного оказания услуг, но сама по себе не создает формат выгрузки, период параллельной работы или обязанность сохранить снятую с поддержки модель. Эти условия стороны должны написать сами.

Границу переносимости задает полный реестр зависимости

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

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

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

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

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

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

Экспорт конфигураций должен быть исполнимым контрактом

В договоре нужен результат, который машина может проверить, а не архив снимков экрана. Укажите формат UTF-8, схему, версию схемы, стабильные идентификаторы, время среза и способ передачи. JSON или YAML подходят, если поставщик документирует поля и не прячет существенные настройки в свободный текст. Для больших объектов допустим архив, но внутри должен лежать манифест с контрольными суммами.

Минимальное приложение к договору можно описать так:

export_version: "1.0"
generated_at: "2026-07-27T10:15:00Z"
objects:
  - type: routing_policy
    id: support-prod
    revision: 18
    model: provider/model-version
    fallbacks:
      - provider/backup-model-version
    timeout_ms: 45000
    allowed_regions:
      - RU
    pii_masking_policy: mask-prod-v3
checksums:
  algorithm: sha256
  manifest: "<hex>"

Этот фрагмент не надо копировать без правки. Он показывает свойства приемлемой выгрузки: версия, время, идентичность объекта, явная версия модели, порядок резервов и ссылка на политику маскирования. Если экспорт возвращает только model: fast, вы переносите название псевдонима, но не его смысл.

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

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

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

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

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

Журналы нужны для аудита, сверки денег и повторного запуска

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

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

Одна строка NDJSON может выглядеть так:

{"event":"provider_attempt","occurred_at":"2026-07-27T10:15:04.381Z","request_id":"req_7f2","attempt":2,"requested_model":"alias/support-fast","resolved_model":"provider/model-version","region":"RU","status":200,"input_tokens":1840,"output_tokens":312,"price_basis":"provider-rate-2026-07-01","pii_policy":"mask-prod-v3"}

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

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

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

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

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

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

Удаление охватывает рабочие данные, кэши и резервные копии

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

Не привязывайте удаление только к расторжению. Триггерами могут быть требование заказчика, окончание цели обработки, отзыв согласия субъектом, выявление неправомерной обработки и истечение срока хранения. Часть 3 статьи 6 закона 152-ФЗ требует, чтобы поручение на обработку определяло перечень данных и операций, цели, конфиденциальность, меры защиты, документы о соблюдении требований и уведомление об инцидентах. Условия выхода должны продолжать это поручение, а не жить в коммерческом разделе отдельно от него.

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

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

Доказательство удаления не равно письму менеджера «все удалено». Приказ Роскомнадзора N 179 устанавливает требования к подтверждению уничтожения персональных данных; в зависимости от способа обработки подтверждением служат акт и выгрузка из журнала. Включите в результат дату, основание, категории данных, системы, способ уничтожения, ответственных лиц и сведения об оставшихся заблокированных копиях. Если часть данных сохраняется по закону, поставщик должен назвать категорию, правовое основание, срок и ограничение доступа.

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

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

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

Переходный период оплачивает управляемую параллельную работу

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

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

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

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

Изменение цены требует права отказаться до новой ставки

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

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

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

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

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

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

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

Снятие модели с поддержки запускает процедуру замены

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

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

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

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

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

Цепочка провайдеров не снимает ответственность с агрегатора

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

Если в запросах есть персональные данные российских граждан, договор должен отражать фактическую архитектуру и требования локализации, а не общую фразу о «соответствии 152-ФЗ». Укажите, где происходит первичная запись, где лежат журналы и резервные копии, кто видит содержимое запроса и уходит ли оно за пределы России. Одно расположение API-шлюза в российском центре обработки данных не доказывает, что нижестоящая модель обрабатывает запрос там же.

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

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

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

Выход принимают по доказательствам, а не по обещанию помочь

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

Каждая проблема возникла не в день миграции. Договор не определил объект экспорта, семантику преобразований, окно доступа и судьбу копий. Общая обязанность «оказать содействие» не дает проверяемого результата. Исправлять это после уведомления дорого, поскольку поставщик уже знает, что будущего оборота не будет.

Приложение о выходе можно принять по короткому списку:

1. Экспорт конфигурации проходит опубликованную схему, содержит все типы объектов из реестра и контрольные суммы.
2. Журналы покрывают согласованный период, связывают запрос, попытки, маршрут и расчет цены стабильными идентификаторами.
3. Новый маршрут прошел набор оценок заказчика, а параллельная работа и возврат трафика остаются доступны до подписания протокола.
4. Все старые API-ключи отозваны, доступы закрыты после выгрузки, а спорные данные заблокированы.
5. Поставщик передал акт удаления либо перечень законно сохраняемых и резервных копий с основаниями и предельными датами уничтожения.

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

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