Вопросы провайдеру LLM перед договором: что уточнить

Зачем задавать вопросы до договора

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

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

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

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

Какие данные уйдут в модель

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

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

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

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

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

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

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

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

Как устроены логи

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

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

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

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

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

Для банка, клиники или крупного ритейла без выгрузки логов обычно тяжело пройти внутреннюю проверку. Поэтому узнайте, можно ли получить их для аудита: по дате, по API-ключу, по request ID, в JSON или CSV. Если провайдер, например AI Router, заявляет аудит-логи и хранение данных внутри страны, это все равно стоит проверять на конкретных примерах и сроках, а не принимать на веру.

Где лежат данные и как их удаляют

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

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

Полезно прояснить пять вещей:

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

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

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

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

Как провайдер обновляет модели

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

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

Потом спросите, как команда предупреждает о смене версии. Нормальный вариант - уведомление заранее, понятный срок до переключения и список изменений. Важны не только качество ответов, но и лимиты, цена, формат вывода, поддержка tool calling и JSON. Если вы работаете через единый OpenAI-совместимый эндпоинт, проверьте и это: меняется ли что-то за тем же model ID или вы всегда видите точный идентификатор модели.

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

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

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

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

Что происходит при инциденте

Сбой редко выглядит аккуратно. Чаще ночью растет задержка, часть запросов падает, а команда клиента узнает об этом из жалоб пользователей. До договора стоит узнать не только общий SLA, но и рабочий порядок: кто замечает проблему, кто принимает обращение и что провайдер делает в первые 15-30 минут.

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

Отдельно уточните, кто дежурит днем и ночью. Есть ли 24/7 on-call или ночью тикеты просто ждут утра? Для LLM-сервисов это частая слабая точка, особенно если ваш продукт работает без перерыва.

Спросите о конкретных сроках:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обычно стоит отдельно проверить пять вещей:

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

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

Короткая проверка перед встречей

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

Лучше просить не общие обещания, а точные формулировки: сроки, каналы связи, кто отвечает и где это зафиксировано. Это полезнее, чем длинные рассказы о безопасности.

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

Если провайдер отвечает расплывчато, попросите короткое письмо после встречи. Удобно, когда у вас остается один лист с конкретными условиями: 30 дней на логи, 7 дней на удаление, уведомление за 14 дней до смены модели, аварийный канал 24/7, доступ сотрудников только по заявке.

Такой список экономит время при согласовании договора и быстро отделяет рабочий сервис от команды, которая пока не готова к продакшену.

Пример: чат поддержки для клиентов

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

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

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

Такой сценарий хорошо проверяет договор до запуска. Нужны прямые ответы на несколько вопросов:

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

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

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

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

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

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

Если после разговора остались серые зоны, отправьте короткое письмо и попросите ответить письменно. Устные формулировки легко меняются, а письменный ответ удобно проверить юристам, безопасности и команде разработки.

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

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

Если вам нужен один OpenAI-совместимый endpoint, хранение данных в Казахстане и аудит-логи, имеет смысл отдельно сравнить по этим пунктам AI Router. У сервиса airouter.kz можно сменить base_url на api.airouter.kz и работать с теми же SDK и промптами, поэтому проверку удобно делать на своем коде, а не на демонстрации.

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