Скрытая архитектура AI SaaS
Создание AI SaaS-платформы научило меня одному.
Сложность не в том, чтобы вызвать LLM. Сложность в том, чтобы заставить ИИ работать в реальном бизнесе.
Сначала всё кажется простым. Вы думаете:
- API-ключи — это просто секреты.
- SSO — это просто подключение.
- Биллинг — это просто Stripe.
- Деплой — это просто Docker.
- ИИ — это просто вызов OpenAI.
Затем платформа становится реальной. Каждая простая тема превращается в сложную систему.
API-ключи API-ключ — это не просто строка. В корпоративном SaaS ключ должен обеспечивать:
- Области доступа (scopes) и срок действия.
- Отзыв и журналы аудита.
- Границы тенантов и ограничения частоты запросов (rate limits).
- Доступ на основе тарифного плана.
Ключ должен отвечать на вопросы: кто им владеет, к какому тенанту он относится и к чему он имеет доступ.
SSO и идентификация Подключить провайдера легко. Сложно решить, чему доверять.
- Доверять ли домену электронной почты или группам?
- Может ли администратор тенанта создать администратора платформы?
- Что произойдет, если пользователь принадлежит к нескольким тенантам?
Настоящий SSO требует валидации издателя (issuer validation), сопоставления ролей (role mapping) и изоляции сессий.
Эксплуатация ИИ Вызвать модель легко. Эксплуатировать ИИ сложно. Вам нужно отслеживать:
- Потребление токенов и затраты.
- Использование провайдеров и задержку (latency).
- Повторные попытки, таймауты и резервные варианты (fallbacks).
- Управление промптами (prompt governance) и границы данных.
Для демо-версии достаточно ответа. Бизнес-платформе нужно знать, какой тенант использовал какую модель и сколько именно это стоило.
Биллинг и управление Stripe обрабатывает платежи, но он не определяет ваш продукт. Серьезный SaaS связывает биллинг с:
- Квотами и ограничением функций (feature gates).
- Лимитами тенантов и статусом подписки.
- Режимами развертывания, такими как on-prem или облако клиента.
Биллинг становится коммерческим управлением. Он контролирует то, что клиенту разрешено использовать.
Выполнение и масштабирование Kubernetes не делает вас масштабируемым автоматически. Вы должны управлять нагрузками, разделяя:
- Очереди и воркеры (workers).
- Лимиты ресурсов и автомасштабирование.
- Сетевые политики и наблюдаемость (observability).
Вам нужно знать, какой воркер дает сбой и какой тенант создает наибольшую нагрузку.
Наблюдаемость Мониторинг — это не бонус. Это часть продукта.
- Инженерам нужно знать, что именно сломалось.
- Руководителям нужно знать, где создается ценность, а где растут затраты.
Главный урок: эти системы взаимосвязаны. Если в ИИ нет учета потребления (metering), он становится дорогим. Если в SSO нет изоляции, он становится опасным. Если биллинг не контролирует соблюдение правил (enforcement), он становится чисто косметическим.
Самое сложное в создании AI SaaS — это не промпт. Это заставить идентификацию, данные, затраты и инфраструктуру работать как единое целое.
Optional learning community: https://t.me/GyaanSetuAi