Содержание слайдов

1. 1. Как внедрять AI в большом финтехе

   Выбираем конфигурацию агентного стека: данные, полномочия, риски и зрелость платформы. Александр Поломодов · Т-Банк

2. 2. Выбор «своё или чужое» ложный

   Открытый клиент, локальная модель и MCP отвечают по-разному

   Open source ≠ local inference

   Self-hosted ≠ безопасные действия

   Внутренний MCP ≠ узкие права

   Внешний API ≠ утечка по умолчанию

3. 3. Агент — больше, чем модель

   Управляемость появляется только вместе с идентичностью и техническими границами исполнения

4. 4. «Свой» — это четыре контроля

   Эти свойства не следуют друг из друга и должны проверяться отдельно

5. 5. Три оси выбираются независимо

   На каждой оси — свой путь данных, стоимость, точка отказа и lock-in

6. 6. Логотип не описывает конфигурацию

   Документация подтверждает возможности, не безопасность

   Наблюдаем

   OpenCode и Codex — открытые клиенты

   Codex поддерживает custom providers

   Claude поставляется разными путями

   Не следует

   Модель локальна и открыта

   Tool use одинаков у endpoints

   Sandbox включён и достаточен

7. 7. Контроль живёт на двух шлюзах

   Модельный шлюз управляет маршрутом данных, инструментальный — полномочиями и эффектом

8. 8. 01. Восемь конфигураций

   Архитектурные паттерны с разной ценой контроля, скорости и эксплуатации

9. 9. Восемь конфигураций на одной карте

   Не рейтинг, а восемь разных сочетаний пути данных и пути полномочий

10. 10. Локальность не отменяет эксплуатацию

    Два разных локальных режима

    1 · Автономный стек

    Air-gap и закреплённые версии

    Максимум собственной ответственности

    GPU, serving, evals, обновления

    3 · Клиент + local model

    Готовый UX и tool loop

    Совместимость доказывают evals

    Workstation остаётся границей

11. 11. Внешняя модель не требует внешних прав

    Планирует frontier-модель, права остаются внутри

    2 · Своя обвязка + API

    Свой процесс и слой инструментов

    Frontier quality без своих GPU

    Секреты фильтрует gateway

    7 · Planner + executor

    Наружу — типизированный план

    Credentials остаются внутри

    Policy проверяет бизнес-инварианты

12. 12. За скорость платят доверием

    Вендорский клиент отделим от корпоративных полномочий

    4 · Agent + internal gateway

    Сильный UX и свежая модель

    Capabilities принадлежат компании

    OBO, policy, trace на шлюзе

    5 · Полный SaaS

    Минимальное время до пилота

    Tenant, connectors, retention

    Высокий control-plane lock-in

13. 13. Гибкость требует платформы

    Маршрутизации нужны evals; личному стеку — границы

    6 · Multi-model router

    Цена, качество, latency, region

    Fallback по классу данных

    Evals для каждого маршрута

    8 · User agent + SaaS/MCP

    Быстрый личный workflow

    Shadow tokens и supply chain

    Registry, scopes, test tenant

14. 14. У конфигураций нет общего рейтинга

    Характеристики зависят от контекста внедрения

    Air-gap требует конфигурации 1

    Скорость пилота ведёт к 5

    Корпоративные actions — к 4

    Высокий risk — к 7

15. 15. 02. Цепочка полномочий

    Threat model от пользовательского намерения до фактического изменения системы

16. 16. Атакуют путь от данных к действию

    Каждая граница добавляет свой канал утечки, confused deputy или подмены цели

17. 17. Результат инструмента тоже недоверенный

    Issue, письмо, README и лог становятся новым управляющим каналом

    Маркировать внешние данные

    Фильтровать результаты и ошибки

    Сужать следующие capabilities

    Тестировать повторные атаки

18. 18. Политика должна быть технической

    Модель предлагает действие; право выполнить его проверяют вне модели

19. 19. 03. Как выбирать

    Сначала допустимый путь данных, затем цена действия и операционная ответственность

20. 20. Сначала данные, потом продукты

    Три вопроса быстро сужают восемь конфигураций до допустимого набора

21. 21. Базовый выбор зависит от внедрения

    Выбирайте минимальную конфигурацию с обязательными границами

    Пилот · 4 / 5 — Один repo, read-only или PR

    Корплатформа · 4 → 6 — Сначала gateway и evals

    Регулируемый контур · 1 / 7 — Fail closed, OBO, sandbox

22. 22. Гипотеза: два шлюза держат платформу

    Вокруг собственных модельного и инструментального шлюзов можно держать несколько клиентов и моделей

23. 23. 05. Кейс: крупный финтех

    Проверяем восемь конфигураций на масштабе, риске и уже построенной платформе

24. 24. Масштаб превращает выбор в платформу

    Локальный инструмент быстро становится общей инфраструктурой разработки

    10 000+ — Инженеры — Тысячи репозиториев и стеков

    55+ млн — Клиенты — Цена массового сбоя растёт

    регулируемый — Контур — Данные, деньги и 24/7

25. 25. Мы начинаем не с чистого листа

    Модельный и инструментальный шлюзы, корпоративный контекст и agent mode уже задают архитектурные границы

26. 26. У финтеха четыре жёстких ограничения

    Данные, полномочия, устойчивость и цепочка поставки должны контролироваться одновременно

27. 27. Регулятор требует управлять всей системой

    Модель угроз, политика ИБ, доверие поставщикам и проверка высокорисковых автодействий человеком

28. 28. Шесть критериев отсекают красивые демо

    Допустимость определяется путями данных и полномочий, а пригодность — эксплуатацией и свидетельствами

29. 29. Для финтеха подходят не все восемь

    Два пути становятся основными, три — специальными, один — следующей ступенью, два остаются в песочнице

30. 30. 5/8 — не default

    Быстрый старт не компенсирует непрозрачность

    5 · Полный SaaS

    Изолированный low-risk пилот

    Enterprise tenant и export logs

    Exit plan до подключения

    8 · Личный стек

    Только test tenant

    Без рабочих данных и прав

    Registry для MCP и версий

31. 31. 1 и 3 закрывают особые контуры

    Локальность даёт автономность ценой GPU, совместимости, обновлений и дежурств

    1 · Автономный стек

    Настоящий air-gap

    Полный операционный контроль

    Максимальная стоимость владения

    3 · Клиент + local model

    Чувствительный локальный код

    Совместимость через evals

    Workstation остаётся границей

32. 32. 7 оставляет полномочия внутри

    Внешняя модель предлагает типизированный план, внутренний исполнитель проверяет и применяет его

    Planner снаружи

    Только разрешённый контекст

    План без credentials

    Версионированная схема

    Executor внутри

    OBO и policy-as-code

    Dry-run и идемпотентность

    Человек для высокого риска

33. 33. 2 и 4 — два рабочих центра

    Собственные стратегические агенты и массовый вендорский UX сходятся в одном корпоративном control plane

34. 34. 6 объединяет портфель только после evals

    Маршрутизация опирается на класс данных, качество, цену и доступность — и не меняет policy скрытым fallback

35. 35. Источники подтверждают свойства, не рейтинг

    Поставщики, MCP, NIST, OWASP и Банк России

    OpenCode · Codex · Claude Code

    GLM-5 · GigaChat API

    MCP authorization · NIST · OWASP

    Банк России · 152-ФЗ · банковская тайна

36. 36. Финтеху нужен портфель конфигураций

    2 / 4 — основные пути

    6 — после собственных evals

    1 / 3 — закрытые контуры

    7 — high-risk исполнение

    5 — изолированный пилот, 8 — песочница

    Владейте путём данных, путём полномочий и проверкой