Выбор провайдера LLM для компании в Казахстане: вопросы

С чего начать

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

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

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

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

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

Какие данные вы на самом деле отправляете

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

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

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

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

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

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

Что спросить про хранение данных

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

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

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

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

Срок хранения лучше проверять не по словам менеджера, а по документам и настройкам. Если вам отвечают "логи храним недолго", этого мало. Нужна цифра: 7 дней, 30 дней, 180 дней. И сразу стоит спросить, можно ли сократить этот срок под ваш проект.

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

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

Какие документы запросить до пилота

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

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

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

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

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

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

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

Как проверить поддержку и SLA

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

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

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

Вот что стоит спросить:

• Кто отвечает за наш аккаунт и кто разбирает инциденты?
• В какие часы работает поддержка и на каком языке идет общение?
• Куда писать или звонить, если сервис остановился прямо сейчас?
• Сколько занимает первый ответ по обычному запросу и по критичному сбою?
• Что вы делаете, если недоступна модель или провайдер модели?

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

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

Как проверить совместимость API

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

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

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

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

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

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

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

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

Всем провайдерам отправляйте один и тот же список вопросов. Иначе ответы будет трудно сравнивать. Если кто-то заявляет совместимость с OpenAI API, просите показать это на практике: можно ли оставить текущий SDK и код, а поменять только base_url и ключ.

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

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

Пример: сеть клиник выбирает провайдера

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

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

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

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

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

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

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

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

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

Третья ошибка - слишком быстрый пилот. Разработчики получают API-ключ, отправляют пару запросов, видят нормальный ответ и считают проверку завершенной. Юристы и ИБ подключаются позже, когда отказываться от варианта уже жалко. Тогда и всплывают вопросы про хранение данных внутри Казахстана, аудит, маскирование PII и формат документов.

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

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

Короткий чек-лист перед договором

Перед подписью проверьте пять вещей на бумаге:

• Где хранятся данные, логи и резервные копии.
• Сколько хранятся запросы и кто видит логи.
• Какие сроки ответа и эскалации зафиксированы в SLA.
• Что реально поддерживается по API и можно ли оставить текущий SDK и код.
• Какие счета, акты и другие документы получит ваша бухгалтерия.

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

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

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

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

После такой сверки обычно остаются 2-3 варианта. Дальше достаточно короткого пилота на 5-7 дней с одинаковым сценарием, одинаковой нагрузкой и общими метриками по цене, задержке, качеству ответа и удобству интеграции.

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

Для компаний, которым важны хранение данных внутри Казахстана, маскирование PII, журнал аудита и ежемесячные B2B-документы в тенге, в таблицу сравнения можно добавить AI Router и проверить его на том же сценарии. У сервиса airouter.kz один OpenAI-совместимый эндпоинт, а такие вещи, как хранение данных внутри страны и работа с логами, можно обсуждать предметно еще до пилота.

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