Типичная ситуация: продукт запускается с несколькими тарифами. На бесплатном плане пользователь может обработать ограниченное число документов в месяц, на платном — больше, на корпоративном — без ограничений, но с разграничением по ролям внутри организации. Как только в продукт добавляется ИИ-функция — классификация, генерация, суммаризация — возникают три вопроса, которые нельзя решить «потом»:
- Как считать потребление ИИ-функций и привязывать его к тарифу?
- Как разграничить доступ к ИИ-результатам между ролями внутри одного аккаунта?
- Как защитить клиентские данные от попадания в контекст другого тенанта?
Ниже — демонстрационный сценарий с разбором архитектурных допущений. Конкретные числа и детали реализации зависят от вашей платформы; этот разбор показывает логику принятия решений, а не готовый рецепт.
Готовый продукт или заказная разработка: как выбрать точку входа
Прежде чем проектировать систему лимитов и ролей, стоит ответить на один вопрос: у вас уже есть SaaS-платформа, в которую нужно встроить ИИ, или вы строите продукт с нуля?
Встройка ИИ в существующий SaaS
Если платформа уже работает, задача сводится к интеграции ИИ-микросервиса в существующую авторизационную модель. Ключевое допущение: ваша система уже умеет хранить план подписки и роль пользователя в токене или сессии. Тогда ИИ-микросервис получает эти данные при каждом запросе и применяет политику доступа до обращения к модели.
Разработка SaaS с ИИ с нуля
Здесь архитектуру подписок, ролей и лимитов нужно проектировать вместе с ИИ-слоем, а не добавлять их после. Это меняет приоритеты: сначала модель данных тенанта, потом функции ИИ.
В обоих случаях мы рекомендуем начинать с одного измеримого процесса — например, классификации входящих заявок или генерации черновиков — и фиксировать критерии приёмки до старта разработки. Подробнее о логике выбора первого процесса — в материале ИИ для бизнеса: выбор процессов для первого внедрения и расчёт экономики.
Архитектура ИИ-решения: подписки, роли и лимиты
Слой подписок и тарифных планов
В демонстрационном сценарии тарифный план хранится на уровне организации (тенанта), а не пользователя. Это стандартное допущение для B2B SaaS: одна компания покупает план, несколько сотрудников им пользуются.
Структура данных в упрощённом виде:
-- Демонстрационная схема (упрощение; реальная схема зависит от платформы)
CREATE TABLE tenant_plans (
tenant_id UUID PRIMARY KEY,
plan_key VARCHAR(32), -- 'free' | 'pro' | 'enterprise'
ai_calls_limit INT, -- NULL = без ограничений
reset_at TIMESTAMPTZ -- дата следующего сброса счётчика
);
CREATE TABLE ai_usage_log (
id BIGSERIAL PRIMARY KEY,
tenant_id UUID,
user_id UUID,
feature_key VARCHAR(64), -- 'classify' | 'summarize' | 'generate'
tokens_used INT,
created_at TIMESTAMPTZ DEFAULT now()
);Допущение: счётчик звонков к ИИ-функциям сбрасывается по расписанию (например, раз в месяц). Если у вас pay-as-you-go модель, логика счётчика меняется: вместо лимита хранится баланс токенов.
Ролевая модель внутри тенанта
В B2B SaaS типичная иерархия ролей выглядит так:
- Owner — управляет планом, платёжными данными и настройками ИИ.
- Admin — управляет пользователями, видит все ИИ-результаты в рамках тенанта.
- Member — использует ИИ-функции в рамках своих объектов (заявок, документов, проектов).
- Viewer — только читает результаты, не инициирует ИИ-запросы.
Ключевое архитектурное решение: проверка роли должна происходить до передачи данных в ИИ-модель, а не после получения ответа. Это исключает ситуацию, когда пользователь с ролью Viewer технически инициирует запрос к модели, а отказ приходит уже после потраченных токенов.
Пример middleware-проверки (демонстрационный псевдокод):
# Демонстрационный пример; реализация зависит от стека
def ai_feature_guard(request, feature_key: str, min_role: str):
tenant = get_tenant(request.tenant_id)
user_role = get_user_role(request.user_id, tenant.id)
if not role_allows(user_role, min_role):
raise PermissionDenied(f"Role {user_role} cannot use {feature_key}")
usage = get_current_usage(tenant.id, feature_key)
if tenant.plan.ai_calls_limit and usage >= tenant.plan.ai_calls_limit:
raise QuotaExceeded(f"Tenant {tenant.id} exceeded limit for {feature_key}")
return True # разрешить запрос к ИИ-микросервисуИзоляция данных между тенантами
Это наиболее критичный аспект при разработке SaaS с ИИ. Если ИИ-функция использует контекст (историю диалога, документы, профиль клиента), необходимо явно ограничивать контекст текущим тенантом.
Три распространённых подхода к изоляции контекста:
- Stateless-запросы — каждый запрос к ИИ содержит только данные текущего пользователя; история не хранится на стороне ИИ-сервиса. Просто, но теряется контекст между сессиями.
- Tenant-scoped vector store — для каждого тенанта отдельное пространство в векторной базе. Поиск по документам ограничен namespace тенанта. Допущение: нужна векторная БД с поддержкой namespace-изоляции.
- Шифрование на уровне тенанта — данные в хранилище шифруются ключом тенанта. Актуально для Enterprise-планов с требованиями к data residency.
Допущение для демонстрационного сценария: мы рассматриваем вариант 2 как базовый для B2B SaaS среднего размера. Вариант 3 — предмет отдельной разработки под конкретные compliance-требования.
Контроль рисков: что может пойти не так
Риск 1: утечка токенов между тенантами
Возникает, если ИИ-запросы кешируются без учёта tenant_id в ключе кеша. Даже семантически похожие запросы от разных тенантов должны обрабатываться независимо.
Митигация: включать tenant_id в ключ кеша обязательно; для семантического кеша — добавлять tenant_id как обязательный фильтр при поиске ближайших векторов.
Риск 2: неожиданный перерасход квоты
Пользователь запускает массовую обработку документов через API, не зная о лимите. Счётчик исчерпывается раньше конца месяца, остальные пользователи тенанта теряют доступ к ИИ-функциям.
Митигация: уведомления при достижении 70% и 90% квоты; мягкий лимит с возможностью докупить токены без смены плана.
Риск 3: роль не проверяется на уровне API
Фронтенд скрывает кнопку для Viewer, но API-эндпоинт не проверяет роль. Прямой вызов API обходит ограничение.
Митигация: проверка роли только на уровне backend; фронтенд-скрытие — UX-решение, не security-контроль.
Риск 4: неконтролируемый рост стоимости ИИ-вызовов
При масштабировании стоимость ИИ-функций растёт быстрее выручки, если лимиты установлены слишком щедро или не отслеживается реальное потребление.
Митигация: логировать каждый ИИ-вызов с количеством токенов; агрегировать по тенанту и фиче еженедельно; пересматривать тарифные лимиты на основе реальных данных потребления.
Что нужно подготовить до начала разработки
Перед тем как заказывать разработку или интеграцию ИИ-функций в SaaS, команда должна зафиксировать следующее:
- Список тарифных планов и конкретные лимиты для каждого (количество ИИ-запросов, типы доступных функций, период сброса счётчика).
- Ролевую матрицу: какая роль может инициировать ИИ-запрос, какая — только читать результат, какая — управлять настройками ИИ.
- Требования к изоляции данных: достаточно namespace-изоляции или нужно шифрование на уровне тенанта.
- Список ИИ-функций для первого релиза с описанием входных данных и ожидаемого формата вывода.
- Критерии приёмки пилота: по каким метрикам будет оцениваться качество ИИ-результатов.
Без зафиксированной ролевой матрицы и лимитов разработка неизбежно возвращается к этим вопросам на этапе тестирования — это стоит дороже, чем час проектирования до старта.
План внедрения: от пилота к production
Этап 1. Проектирование модели данных и политик доступа
Фиксируем схему тенантов, планов и ролей. Описываем политики доступа к каждой ИИ-функции в виде явных правил (какая роль + какой план = доступ разрешён/запрещён/ограничен). Результат этапа — согласованная схема и матрица политик.
Этап 2. Интеграция ИИ-микросервиса с авторизационным слоем
Подключаем ИИ-функцию (классификация, генерация, суммаризация) через middleware, который проверяет роль и квоту до обращения к модели. Настраиваем логирование потребления токенов. Результат — работающий ИИ-эндпоинт с проверкой прав и счётчиком.
Этап 3. Пилот на одном процессе
Запускаем ИИ-функцию на реальных данных одного тенанта (или тестовой группы пользователей). Измеряем: точность ИИ-результатов по заранее согласованным критериям, процент запросов, отклонённых по квоте или роли, реальное потребление токенов относительно прогноза.
Этап 4. Контроль качества и масштабирование
По результатам пилота корректируем лимиты и политики. Добавляем уведомления о квоте. Готовим инструменты для Owner-роли: просмотр потребления, управление пользователями и ролями. После этого открываем функцию для всех тенантов.
О том, как оценивать качество ИИ-результатов и выстраивать проверку человеком на этапе пилота, подробнее написано в материале Обработка документов с ИИ: извлечение данных и проверка человеком — план пилота с критериями масштабирования.
Экономика: как считать объём разработки
Явное допущение: конкретные сроки и стоимость зависят от вашего стека, зрелости платформы и числа ИИ-функций. Ниже — логика оценки, не коммерческое предложение.
Условная формула объёма разработки для одной ИИ-функции в существующем SaaS:
Объём = (проектирование политик) + (интеграция микросервиса) + (логирование и счётчики) + (UI для управления квотой) + (тестирование изоляции)
Где каждый блок оценивается отдельно исходя из:
- сложности существующей авторизационной модели
- числа ролей и тарифных планов
- требований к изоляции данных (namespace vs шифрование)
- наличия или отсутствия векторного хранилищаЕсли платформа строится с нуля, к этому добавляется разработка самой модели тенантов и биллингового слоя — это отдельный проект с другим объёмом.
Обсудите проект с PORTcore
Если вы строите SaaS с ИИ-функциями или встраиваете ИИ в существующую платформу, первый практический шаг — зафиксировать ролевую матрицу и лимиты до начала разработки. Мы проектируем и интегрируем ИИ-микросервисы в существующие архитектуры, включая авторизационный слой, счётчики потребления и изоляцию данных между тенантами. Если нужна не интеграция, а разработка контентных ИИ-функций — генерации, классификации или суммаризации — это тоже предмет отдельного разговора.
Перейдите в каталог услуг PORTcore, чтобы выбрать подходящую точку входа: интеграция ИИ-микросервиса, разработка ИИ-агента или автоматизация контентного процесса. Опишите ваш сценарий — обсудим объём и критерии приёмки пилота.
Связанные материалы
Подходящие офферы
Если статья попала в вашу задачу, вот два оффера, с которых можно перейти к внедрению без лишнего discovery.
Интеграция Bitrix/сайта с marketplace API
Подключаем внешние marketplace API к сайту или Bitrix, чтобы синхронизация не разваливалась на ручных костылях.
Технический SEO аудит сайта
Проводим аудит SEO-техники и выдаем приоритетный план исправлений с фокусом на коммерческие страницы.
