Production-ready AI приложение — это приложение, которое стабильно, безопасно и экономически эффективно работает под реальной нагрузкой. Между прототипом и production лежит пропасть: то, что работает на localhost с 10 запросами в день, ломается при 10 000 запросах и реальных пользователях. Этот чеклист из 25 пунктов поможет убедиться, что ваше AI-приложение готово к запуску.
Безопасность (пункты 1-8)
1. API-ключи не в коде. Все секреты хранятся в переменных окружения или secrets manager. Файл .env добавлен в .gitignore.
2. PII фильтрация. Персональные данные маскируются перед отправкой в LLM. Проверены паттерны: email, телефон, ИНН, паспорт, банковские карты.
3. Защита от prompt injection. Реализованы: валидация ввода (regex), изоляция системного промпта, guard-модель для подозрительных запросов.
4. Rate limiting. Настроены лимиты по RPM и TPM на каждый API-ключ. Защита от brute force на эндпоинтах авторизации.
5. Output validation. Ответы модели проверяются перед отправкой пользователю: нет запрещённого контента, корректный формат, нет утечки системного промпта.
6. CORS настроен. Разрешены только доверенные origins. Wildcard * не используется в production.
7. HTTPS везде. Все API-эндпоинты работают только через HTTPS. HTTP-запросы редиректятся на HTTPS.
8. Аудит логирование. Все действия с API-ключами, авторизация и подозрительная активность логируются. Логи не содержат секретов и PII.
# Пример: чеклист как код
SECURITY_CHECKS = {
"api_keys_not_in_code": lambda: not any(
"sk-" in line or "msk_" in line
for f in glob("**/*.py", recursive=True)
for line in open(f)
),
"env_in_gitignore": lambda: ".env" in open(".gitignore").read(),
"pii_filter_enabled": lambda: config.get("pii_filter.enabled") is True,
"rate_limit_configured": lambda: config.get("rate_limit.rpm") is not None,
"https_enforced": lambda: config.get("server.ssl.enabled") is True,
}
for check_name, check_fn in SECURITY_CHECKS.items():
status = "PASS" if check_fn() else "FAIL"
print(f"[{status}] {check_name}")Надёжность и производительность (пункты 9-16)
9. Failover настроен. При сбое основного провайдера запросы автоматически перенаправляются на резервную модель.
10. Таймауты установлены. Для каждого внешнего вызова установлен таймаут (connect: 5s, read: 30s). Нет запросов без таймаута.
11. Circuit breaker. После N последовательных ошибок провайдер временно исключается из ротации.
12. Graceful degradation. Предусмотрено поведение при полной недоступности AI: кэшированные ответы, шаблоны, уведомление пользователю.
13. Retries с backoff. Повторные запросы при 429/500/503 с экспоненциальным backoff и jitter.
async function callWithRetry(
fn: () => Promise<Response>,
maxRetries = 3
): Promise<Response> {
for (let attempt = 0; attempt <= maxRetries; attempt++) {
try {
return await fn();
} catch (error: any) {
if (attempt === maxRetries) throw error;
const retryable = [429, 500, 502, 503].includes(error.status);
if (!retryable) throw error;
const delay = Math.min(1000 * 2 ** attempt, 30000);
const jitter = Math.random() * 1000;
await new Promise((r) => setTimeout(r, delay + jitter));
}
}
throw new Error("Unreachable");
}14. Streaming работает. SSE-стриминг протестирован с реальными клиентами. Обработаны disconnect и partial response.
15. Конкурентность. Приложение корректно обрабатывает параллельные запросы. Нет race conditions в биллинге (pessimistic locking).
16. Нагрузочное тестирование. Проведён load test с ожидаемым пиковым трафиком (x2-x3 от среднего).
Мониторинг и observability (пункты 17-21)
17. Health check endpoint. GET /health возвращает статус приложения, проверяет подключение к БД и доступность провайдеров.
18. Метрики собираются. Prometheus/Grafana или аналог: RPM, латентность (p50/p95/p99), error rate, расход токенов.
19. Алерты настроены. Уведомления при: error rate > 5%, латентность > 10s, бюджет исчерпан на 80%, аномальный рост расходов.
20. Structured logging. Логи в формате JSON с request_id, tenant_id, model, duration, tokens. Централизованный сбор (ELK, Loki).
21. Трейсинг. Каждый запрос имеет уникальный trace_id, который проходит через все компоненты системы.
Бизнес и compliance (пункты 22-25)
22. Биллинг протестирован. Pessimistic hold работает корректно: нет overdraft, нет потерянных hold-ов, settlement точный.
23. Compliance документы. Политика конфиденциальности, условия использования, DPA с провайдерами, уведомление в Роскомнадзор (если PII).
24. Финансовая модель. Наценка покрывает инфраструктуру и маржу. Есть алерты на случай, если средняя стоимость запроса превышает допустимый порог.
25. Disaster recovery план. Документированная процедура: runbook для типовых инцидентов, контакты ответственных, RTO/RPO определены.
ModelSwitch берёт на себя значительную часть этих пунктов: безопасное управление ключами, rate limiting, failover через AI Gateway, встроенный мониторинг расходов, аудит логи и compliance через российское юридическое лицо. Используя ModelSwitch как инфраструктурный слой, вы можете сфокусироваться на продуктовых метриках, а не на операционной сложности.
Заключение
Этот чеклист — не одноразовая проверка, а живой документ. Проходите по нему перед каждым значимым релизом, добавляйте пункты, специфичные для вашего продукта, и автоматизируйте проверки в CI/CD. Production-ready AI приложение — это не только качественная модель, но и безопасная, надёжная и наблюдаемая инфраструктура вокруг неё.