Podlodka AI Engineers Club · 4 августа 2026
Как внедрять AI в большом финтехе
Выбираем конфигурацию агентного стека: данные, полномочия, риски и зрелость платформы. Александр Поломодов · Т-Банк
/ Podlodka AI · Агентный стек крупного финтеха
Выбираем конфигурацию агентного стека: данные, полномочия, риски и зрелость платформы. Александр Поломодов · Т-Банк
Выбираем конфигурацию агентного стека: данные, полномочия, риски и зрелость платформы. Александр Поломодов · Т-Банк
Открытый клиент, локальная модель и внутренний MCP отвечают на разные вопросы
Open source ≠ local inference
Self-hosted ≠ безопасные действия
Внутренний MCP ≠ узкие права
Внешний API ≠ утечка по умолчанию
Управляемость появляется только вместе с идентичностью и техническими границами исполнения
Эти свойства не следуют друг из друга и должны проверяться отдельно
На каждой оси — свой путь данных, стоимость, точка отказа и lock-in
Документация подтверждает возможности, но не безопасность конкретного внедрения
Что действительно видно
OpenCode и Codex — открытые клиенты
Codex поддерживает custom providers
Claude поставляется разными путями
Что из этого не следует
Модель локальна и открыта
Tool use одинаков у endpoints
Sandbox включён и достаточен
Модельный шлюз управляет маршрутом данных, инструментальный — полномочиями и эффектом
Архитектурные паттерны с разной ценой контроля, скорости и эксплуатации
Не рейтинг, а разные точки на осях пути данных и полномочий
Максимум контроля и быстрый локальный старт — два разных режима
1 · Автономный стек
Air-gap и закреплённые версии
Максимальная своя ответственность
GPU, serving, evals, обновления
3 · Клиент + local model
Готовый UX и tool loop
Совместимость доказывают evals
Workstation остаётся границей
Полномочия можно оставить внутри, даже если планирование выполняет frontier-модель
2 · Своя обвязка + API
Свой process и tool layer
Frontier quality без своих GPU
Секреты фильтрует gateway
7 · Planner + executor
Наружу — типизированный план
Credentials остаются внутри
Policy проверяет бизнес-инварианты
Вендорский клиент можно отделить от корпоративных полномочий — либо отдать поставщику весь стек
4 · Agent + internal gateway
Сильный UX и свежая модель
Capabilities принадлежат компании
OBO, policy, trace на шлюзе
5 · Полный SaaS
Минимальное время до пилота
Tenant, connectors, retention
Высокий control-plane lock-in
Маршрутизация требует зрелых evals, а пользовательский стек — корпоративных границ
6 · Multi-model router
Цена, качество, latency, region
Safe fallback по классу данных
Evals для каждого маршрута
8 · User agent + SaaS/MCP
Быстрый личный workflow
Shadow tokens и supply chain
Registry, scopes, test tenant
Одна характеристика меняется от масштаба, договора, модели и зрелости команды
Air-gap требует конфигурации 1
Скорость пилота ведёт к 5
Корпоративные actions — к 4
Высокий risk — к 7
Threat model от пользовательского намерения до фактического изменения системы
Каждая граница добавляет свой канал утечки, confused deputy или подмены цели
Issue, письмо, README и лог становятся новым управляющим каналом
Маркировать внешние данные
Фильтровать результаты и ошибки
Сужать следующие capabilities
Тестировать повторные атаки
Модель предлагает действие; право выполнить его проверяют вне модели
Сначала допустимый путь данных, затем цена действия и операционная ответственность
Три вопроса быстро сужают восемь конфигураций до допустимого набора
Выбирайте не максимум автономности, а минимальную конфигурацию, которая обеспечивает обязательные границы
Пилот · 4 / 5 — Один repo, read-only или PR
Корплатформа · 4 → 6 — Сначала gateway и evals
Регконтур · 1 / 7 — Fail closed, OBO, sandbox
Несколько клиентов и моделей допустимы вокруг собственных model и tool gateways
Проверяем восемь конфигураций на масштабе, риске и уже построенной платформе
Локальный инструмент быстро становится общей инфраструктурой разработки
10 000+ — Инженеры — Тысячи репозиториев и стеков
55+ млн — Клиенты — Цена массового сбоя растёт
regulated — Контур — Данные, деньги и 24/7
Модельный шлюз, MCP/tool gateway, корпоративный контекст и agent mode уже задают архитектурные границы
Данные, полномочия, устойчивость и цепочка поставки должны контролироваться одновременно
Модель угроз, политика ИБ, доверие поставщикам и проверка высокорисковых автодействий человеком
Допустимость определяется путями данных и полномочий, а пригодность — эксплуатацией и свидетельствами
Два пути становятся основными, три — специальными, один — следующей ступенью, два остаются в песочнице
Скорость старта не компенсирует непрозрачный путь данных, токенов и обновлений
5 · Полный SaaS
Изолированный low-risk пилот
Enterprise tenant и export logs
Exit plan до подключения
8 · Личный стек
Только test tenant
Без рабочих данных и прав
Registry для MCP и версий
Локальность покупает автономность ценой GPU, совместимости, обновлений и on-call эксплуатации
1 · Автономный стек
Настоящий air-gap
Полный операционный контроль
Максимальная стоимость владения
3 · Клиент + local model
Чувствительный локальный код
Совместимость через evals
Workstation остаётся границей
Внешняя модель предлагает типизированный план, внутренний исполнитель проверяет и применяет его
Planner снаружи
Только разрешённый контекст
План без credentials
Версионированная схема
Executor внутри
OBO и policy-as-code
Dry-run и идемпотентность
Человек для высокого риска
Собственные стратегические агенты и массовый вендорский UX сходятся в одном корпоративном control plane
Маршрутизация опирается на класс данных, качество, цену и доступность — и не меняет policy скрытым fallback
2 / 4 — основные пути
6 — после собственных evals
1 / 3 — закрытые контуры
7 — high-risk исполнение
5 / 8 — только песочница
Владейте путём данных, полномочий и проверки