Внедрение AI-first подхода в компании

Проблема

Компания принимает стратегическое решение: каждый продукт должен иметь AI-функциональность. На практике это разваливается в набор локальных историй:

• Каждая команда самостоятельно интегрируется с провайдером — выбирает SDK, ключи, retry-стратегию, кэш.
• Платформа не контролирует, какие модели уходят в продакшен.
• Расход на LLM разбросан по нескольким провайдерским аккаунтам без сводной картины.
• Compliance не успевает — каждая команда делает свой security-ревью.
• Опыт не переиспользуется: одну и ту же обвязку пишут несколь раз.

Полугодовая миграция «давайте все команды используют AI» превращается в бесконечную, потому что у платформы нет рычага управления — есть только рекомендации.

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

Решение

• Единая ось наблюдаемости. CTO видит расход на LLM по всей компании за минуту; не нужно собирать данные по разным провайдерским дашбордам.
• Новые AI-фичи запускаются командами без согласования с платформой. Платформа задаёт рамки (бюджеты, разрешённые модели), команды действуют внутри них самостоятельно.
• Единая стратегия governance с первого дня. Не приходится переписывать стандарты, когда команд становится 30 вместо 3.
• Готовность к смене курса. Решение «уйти с OpenAI» или «добавить on-prem модель» — конфигурация на стороне платформы, не переписывание десяти приложений.
• Перенос практик между командами. Команды видят, что работает у других (через метрики), и применяют те же модели/настройки.

Что предлагает Meridian

Meridian — это единая точка входа для всего AI-трафика компании. На неё подвешено:

• Единый набор провайдеров (см. Supported providers). Платформа подключает OpenAI, Anthropic, Bedrock, Azure, Vertex и нишевые провайдеры один раз; команды получают доступ к ним без отдельных контрактов.
• Единый OpenAI-совместимый API (Drop-in replacement). Команды используют те SDK, что уже знают — openai-python, anthropic-sdk, LangChain, Vercel AI SDK.
• Единый governance — Customer → Team → Virtual Key с бюджетами и rate limits на каждом уровне.
• Единая телеметрия — Prometheus + OpenTelemetry. Любая команда сразу попадает в корпоративный мониторинг без подключения дополнительных библиотек.
• Единые правила безопасности и compliance — одно решение по retention логов, маскировке, юрисдикции вместо десяти.

Сценарий

CTO на сесси планирования объявляет: каждая продуктовая команда должна попробовать сделать AI-функцию в своём продукте.

1. Платформенная команда разворачивает Meridian (один раз) — обычно начинают с одного узла, добавляют кластеризацию по мере роста (см. Кластеризация).
2. Платформа подключает в Meridian базовый набор провайдеров (OpenAI как «по умолчанию», Anthropic как fallback, Azure для регулируемых данных) и настраивает семантический кэш, логи, телеметрию.
3. Архитектор согласует базовые правила: какие модели допустимы по умолчанию, какие требуют отдельного согласования, что логируется и как долго хранится.
4. Каждая команда через портал самообслуживания выпускает свой VK и подставляет base_url/api_key в свой существующий код. Никаких новых SDK, никаких новых ключей в Secrets — только VK.
5. Через отчетный период у CTO есть сводная картина: сколько команд использует AI, на каких моделях, с какими расходами, какие команды столкнулись с проблемами.
6. Новые команды подключаются за минуты, не часы; единые правила распространяются автоматически.

Конфигурация

curl -X POST http://localhost:8080/api/governance/virtual-keys \
  -H "Content-Type: application/json" \
  -d '{
    "name": "team-search-prod",
    "description": "Поисковая команда, prod",
    "team_id": "team-search",
    "provider_configs": [
      { "provider": "openai",    "weight": 1.0, "allowed_models": ["gpt-4o-mini", "gpt-4o"] },
      { "provider": "anthropic", "weight": 0.0, "allowed_models": ["claude-3-5-sonnet-20241022"] }
    ],
    "budget":     { "max_limit": 1000.00, "reset_duration": "1M" },
    "rate_limit": { "request_max_limit": 100, "request_reset_duration": "1m" },
    "is_active": true
  }'

{
  "client": {
    "enable_logging": true,
    "enforce_auth_on_inference": true
  },
  "providers": {
    "openai":    { "keys": [ { "id": "k1", "value": "env.OPENAI_API_KEY",    "models": ["*"], "weight": 1.0 } ] },
    "anthropic": { "keys": [ { "id": "k1", "value": "env.ANTHROPIC_API_KEY", "models": ["*"], "weight": 1.0 } ] }
  },
  "vector_store": {
    "type": "redis",
    "config": { "address": "env.REDIS_ADDR" }
  },
  "plugins": {
    "semantic_cache": { "enabled": true, "similarity_threshold": 0.95 },
    "prometheus":     { "enabled": true },
    "otel":           { "enabled": true, "endpoint": "env.OTEL_EXPORTER_OTLP_ENDPOINT" }
  },
  "logs_store": {
    "type": "postgres",
    "config": { "dsn": "env.LOGS_DB_DSN" }
  },
  "governance": {
    "customers": [],
    "teams": [],
    "virtual_keys": []
  }
}

Ограничения и подводные камни

• Платформенная команда должна определить базовые правила заранее. Какие модели разрешены по умолчанию, какой бюджет получает новая команда, какие данные нельзя отправлять в LLM. Без этих правил self-service создаёт хаос.
• Compliance и юрисдикция данных требуют ясности: какие команды могут использовать каких провайдеров. Реализуется через allowed_models и provider_configs в VK, но политику должны прописать вы.

Связанные материалы

• Drop-in replacement — почему любые существующие OpenAI-совместимые SDK работают сразу.
• Поддерживаемые провайдеры — список встроенных, единых для всей компании.
• Самообслуживание команд и контроль затрат — как команды получают доступ без участия платформы.
• Снижение стоимости и сроков разработки — что эта модель даёт каждому отдельному сервису.
• Защита от vendor lock — стратегическая сторона единого API.
• Отладка и аудит LLM-приложений — сводная видимость по всем командам.