Договор с LLM-провайдером: что проверить до запуска

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

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

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

Обещания из презентации не равны подписанным обязательствам. Фраза "мы не используем данные для обучения" ничего не стоит, если в приложении есть расплывчатое право на "улучшение сервиса". То же и с инцидентами: менеджер обещает быстрое уведомление, а в SLA прописано пять рабочих дней. Для банка, телеком-команды или SaaS это слишком долго.

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

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

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

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

Если вы просто меняете base_url и оставляете прежний SDK, код почти не меняется. Но риск никуда не исчезает. Он уходит в приложения к договору, исключения и мелкий шрифт.

Где провайдер хранит данные

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

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

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

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

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

Пример простой. Банк отправляет в LLM обращения клиентов с маскировкой ПДн, а провайдер держит сырые логи 45 дней в другой юрисдикции и еще 90 дней в резервной копии. Формально запрос уже обработан, но для комплаенса риск остался.

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

Кто еще получает доступ к данным

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

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

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

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

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

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

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

Как договор должен описывать инциденты

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

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

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

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

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

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

Отдельно разберите деньги и обязанности. Кто оплачивает форензику, внешних консультантов, уведомления клиентам и регулятору, если вина на стороне провайдера? Для компаний под 152-ФЗ это не мелочь: опоздает провайдер, объясняться придется вам.

Как пройти проверку до запуска

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

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

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

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

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

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

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

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

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

Пример: чат-ассистент для банка

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

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

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

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

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

Если команде нужен единый OpenAI-совместимый эндпоинт внутри РФ, можно сравнить прямую интеграцию с внешними провайдерами и вариант через RU LLM. У RU LLM логи и бэкапы хранятся в РФ, встроены маскирование PII и аудит-трейлы, а для перехода обычно достаточно сменить base_url на api.rullm.com и оставить прежние SDK, код и промпты.

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

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

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

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

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

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

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

Что сделать после проверки

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

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

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

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

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

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