Выбор AIaaS-провайдера для крупной организации — это не закупка «ещё одного SaaS». Вы выбираете слой, через который сотрудники и приложения будут обращаться к большим языковым моделям: с политиками безопасности, биллингом, аудитом и возможностью менять модели без переписывания всех интеграций.
Ниже — практический чеклист для CIO, CISO и архитекторов. Он помогает сравнить предложения не по красивым демо, а по критериям, которые влияют на риски, TCO и скорость масштабирования. Опирайтесь на него при RFP, пилоте и переговорах. Если нужна точка входа в архитектуру, начните с обзора платформы AIaaS и тарифов.
Сформулируйте задачу до сравнения прайсов
Самая частая ошибка — начинать с каталога моделей. Сначала зафиксируйте бизнес-сценарии, классы данных и ограничения по размещению. Без этого любой провайдер «подойдёт», а через квартал выяснится, что нельзя отправлять обращения клиентов или внутренние регламенты во внешний контур.
Опишите 2–3 приоритетных use case с владельцем, объёмом запросов и ожидаемым эффектом. Для каждого сценария укажите: есть ли персональные данные, коммерческая тайна, требования 152-ФЗ, нужна ли работа только в РФ-контуре.
Сведите требования в одностраничный brief для закупок и ИБ: цель пилота, запрещённые данные, обязательные интеграции, целевые KPI и бюджетный потолок. Этот документ экономит недели переписки на этапе RFP.
- Сценарий, KPI и владелец результата (не «ИИ ради ИИ»)
- Классы данных и допустимые зоны обработки
- Системы-источники: CRM, ITSM, ECM, контакт-центр, корпоративный поиск
- Ожидаемый объём: запросы/день, пиковые окна, доля автоматизации
Архитектура: шлюз важнее списка моделей
Корпоративный стандарт сегодня — единый AI Gateway: приложения и сотрудники ходят в модели через контролируемую точку, а не через десятки личных API-ключей. Без шлюза вы получаете теневой ИИ, разрозненные счета и отсутствие аудита.
Проверьте, есть ли у провайдера единый API, маршрутизация по моделям, политики на уровне ключей/проектов, логирование промптов и ответов с маскированием чувствительных полей. Это база для ИБ и FinOps.
Отдельно оцените совместимость с привычными SDK и OpenAI-подобным контрактом: чем меньше кастомной обвязки в каждом сервисе, тем быстрее масштабируются новые сценарии через API для разработчиков.
- Единый endpoint и совместимость с привычными SDK
- Маршрутизация: дешёвая модель на простые задачи, сильная — на сложные
- Квоты, роли, проекты, разделение сред (dev/stage/prod)
- Экспорт логов в SIEM и хранение в нужном контуре
Безопасность и соответствие 152-ФЗ
Для российских организаций критичны: где физически обрабатываются данные, кто имеет доступ к промптам, есть ли DLP до отправки в модель, как устроены NDA и subprocessors. Подробнее тема раскрыта в материале DLP и 152-ФЗ при работе с LLM.
Запросите у провайдера описание контуров, матрицу ролей, политику хранения логов, сроки удаления, возможность запрета обучения на ваших данных. Если ответа нет в письменном виде — это красный флаг для CISO.
Пройдите security questionnaire до пилота, а не после. Включите вопросы о MFA/SSO, ротации ключей, инцидент-менеджменте и праве на аудит. Устные заверения «у нас всё безопасно» в корпоративном контуре не считаются контролем.
- DLP/маскирование PII до вызова модели
- Разделение контуров и запрет обучения на корпоративных данных
- Аудит доступа, MFA, SSO (SAML/OIDC)
- Документы по 152-ФЗ, договоры и зоны ответственности
Каталог моделей и независимость от вендора
Смотрите не только на «топовую» модель, а на возможность переключаться. Сегодня оптимальны связки вроде Kimi / Qwen / DeepSeek под разные классы задач — см. гид по выбору моделей и каталог моделей.
Спросите: можно ли сменить модель без смены контракта и без переписывания интеграций? Есть ли A/B на уровне gateway? Как быстро подключаются новые релизы?
Зафиксируйте в RFP требование: маршрутизация и failover между моделями одного класса качества. Иначе через полгода вы окажетесь в vendor lock-in на уровне приложений, даже если договор формально «мультимодельный».
Биллинг и FinOps: кредиты, лимиты, прозрачность
Прозрачный биллинг — обязательное условие масштабирования. Ищите модель AI-кредитов или токенов с разбивкой по проектам, командам и сценариям. Иначе через два месяца FinOps не ответит, почему счёт вырос втрое. Практические паттерны — в статье AI-кредиты и биллинг.
На пилоте сразу включите лимиты и алерты. «Безлимит на старт» почти всегда заканчивается сюрпризом в счёте.
Попросите прогноз стоимости при росте x5 и x10, а также разбивку: inference, embeddings, хранение логов, support. Сравнивайте не прайс «за миллион токенов», а стоимость единицы бизнес-результата.
- Отчёты по проектам / cost-center / приложениям
- Лимиты и алерты в реальном времени
- Понятная себестоимость токена/кредита и наценка
- Прогноз расхода при росте нагрузки x5–x10
Интеграции и скорость вывода в прод
Провайдер должен ускорять внедрение, а не заставлять строить всё с нуля. Проверьте наличие готовых контуров под контакт-центр, Document AI, ITSM, корпоративную базу знаний, а также качество API и документации для разработчиков.
Оцените: есть ли sandbox, примеры, поддержка webhook/очередей, SLA на ответы поддержки в пилоте. Для enterprise важна не только модель, но и то, как быстро команда доводит сценарий до измеримого результата.
Отдельно проверьте готовность к вашему ландшафту: SSO, корпоративный прокси, частные сети, экспорт метрик в существующий мониторинг. «Работает у нас в облаке» не равно «встроится в ваш периметр за две недели».
SLA, поддержка и операционная зрелость
Зафиксируйте целевые RTO/RPO для критичных сценариев, каналы эскалации, язык поддержки, часы работы. Уточните, что происходит при деградации конкретной модели: есть ли failover на другую модель того же класса качества.
Попросите референсы сопоставимого масштаба в РФ: банки, телеком, ритейл, промышленность. Референс «мы работаем с ИИ» без деталей по контуру и нагрузке почти бесполезен.
В договоре опишите ответственность за инциденты: кто коммуницирует с бизнесом, в какие сроки предоставляется RCA, как компенсируется простой критичного канала. Без этого SLA остаётся слайдом в презентации.
Матрица рисков при выборе провайдера
Сведите риски в явную таблицу до переговоров о цене. Цена без учёта риска даёт ложную экономию: дешёвый доступ к модели может обернуться дорогим проектом по ИБ и переписыванием интеграций.
- Риск утечки данных: нет DLP / нет запрета обучения → высокий; централизованный gateway + redaction → управляемый
- Риск vendor lock-in: один API одной модели → высокий; единый контракт и маршрутизация → низкий
- Риск бюджетного сюрприза: общий ключ без лимитов → высокий; проектные квоты и алерты → низкий
- Риск операционного простоя: нет failover → высокий; запасной маршрут модели → управляемый
- Риск аудита: устные заверения → высокий; письменные политики и выгрузка в SIEM → низкий
Антипаттерны закупки AIaaS
Покупка «самой умной модели» без сценариев. Выбор по цене токена без учёта интеграций и сопровождения. Пилот на личных ключах «чтобы быстрее». Откладывание security questionnaire «на потом». Сравнение только демо-дня без bake-off на своих данных.
Ещё один антипаттерн — параллельные закупки разными департаментами. Через полгода у вас три договора, три биллинга и ни одной общей политики. Централизуйте слой AIaaS даже если use case остаются доменными.
Чеклист пилота на 4–8 недель
Пилот должен заканчиваться решением: масштабируем / дорабатываем / останавливаем. Не «всем понравилось». Ниже — минимальный набор артефактов.
Назначьте комитет go/no-go заранее: бизнес-владелец, ИТ, ИБ, FinOps. Без кворума пилот снова уйдёт в бесконечные «ещё две недели на доработки».
- Один сценарий, один владелец бизнеса, один владелец ИТ/ИБ
- Базовые метрики до старта: время обработки, доля ручного труда, CSAT/FCR, стоимость обращения
- Политики DLP и перечень запрещённых данных в промпте
- Лимиты бюджета и dashboard расхода по дням
- Критерии качества ответов и процедура human-in-the-loop
- Отчёт go/no-go с TCO на 12 месяцев
Красные флаги при выборе
Если провайдер не может показать архитектуру шлюза, отказывается фиксировать запрет обучения на ваших данных, не даёт разбивку биллинга или предлагает «просто ключ от одной модели» — это не корпоративный AIaaS, а перепродажа доступа.
Отдельно настораживает отсутствие российского юридического лица/договора под ваши требования compliance и неготовность пройти security questionnaire.
Проверьте, не подменяется ли «корпоративность» маркетинговым списком интеграций. Спросите демо именно ваших контролей: квота проекта, маскирование PII, выгрузка аудита, смена модели без релиза приложения.
Итоговая матрица решения
Сведите сравнение к таблице: безопасность, gateway, модели, биллинг, интеграции, SLA, цена пилота, цена масштаба. Веса критериев задайте заранее — иначе победит самый эффектный демо-день.
Если нужна помощь с формулировкой RFP или архитектурой пилота, команда AI Cloud готова разобрать ваш контур на странице контактов. Параллельно изучите платформу, gateway и материал что такое корпоративный AIaaS-шлюз.
Частые вопросы
Начните с сценариев и ограничений: какие данные нельзя выносить, какие системы нужно интегрировать, какой бюджет на пилот. Затем сравните провайдеров по шлюзу, DLP, биллингу и SLA — а не по маркетинговому списку моделей.
В зрелой модели — нет. Корпоративный AIaaS даёт единый контракт, единый биллинг и доступ к каталогу моделей через gateway. Это снижает юридическую и операционную нагрузку.
Обычно 4–8 недель на один измеримый сценарий: базовые метрики до внедрения, контроль качества и стоимости, решение go/no-go. Пилот без KPI почти всегда заканчивается «впечатлениями», а не решением.
Считайте не только цену токена/кредита, но и стоимость интеграций, сопровождения, доработок под ИБ, failover и стоимость смены модели. Заложите горизонт 12–24 месяца и сценарий роста нагрузки x5–x10.