Капитал / КИБ
ИИ-трансформация
Предлагаемая организационная модельКонцепция для обсуждения · Ноябрь 2026

Центр
ИИ-трансформации

От отдельных ИИ-экспериментов к новой модели работы бизнеса. Люди, процессы и инструменты — в единой системе изменений.

12человек
на старте
3взаимосвязанных
подразделения
4направления
трансформации
Бизнес + ИИобщая
ответственность

Мандат центра

Трансформировать
бизнес-процессы

Перепроектировать работу с учётом ИИ: от анализа текущих операций до нового регламента и подтверждённого результата.

Систематизировать
Shadow AI

Выявлять неформальные практики, сохранять полезные сценарии и переводить их в согласованную среду с понятными правилами.

Развивать
ИИ-компетенции

Учить на реальных задачах, поддерживать применение навыков и масштабировать опыт через сеть амбассадоров.

Давать удобные
инструменты

Обеспечить доступ к ИИ-помощникам, знаниям и автоматизации с последующим переходом на целевую платформу ВТБ.

01 / Организационная структура

Три команды.
Одна трансформация.

Единый портфель инициативПриоритеты, ресурсы и архитектура
связаны с задачами бизнеса

1
Руководитель Центра ИИ-трансформации

Михаил Степнов

Стратегия · Агентная разработка · Обучение

Лично разрабатывает ИИ-решения, ведёт ключевые внедрения и обучает команды.

Партнёрство с бизнесом и ИТВладельцы процессов, ИТ Капитала
и центральный ВТБ

Выберите подразделение, чтобы увидеть задачи и должностные роли.12 человек, включая руководителя центра
02 / Операционная модель

Из бизнес-задачи —
в работающий процесс.

FDE, проектные руководители и разработка включаются совместно. По мере зрелости инициативы меняется ведущая роль, сохраняется общая ответственность.

Короткие улучшения проходят упрощённый маршрут в рамках согласованных правил. Инициативы с интеграциями, несколькими подразделениями или изменением регламентов оформляются как системные проекты.

Бизнес-владелец процесса

Определяет проблему, предоставляет экспертизу и данные, принимает новый процесс и подтверждает достигнутый эффект.

ИТ ВТБ Капитал / КИБ

Согласует локальные интеграции, доступы, требования к эксплуатации и поддержку. РП ведут единый план зависимостей.

Центральный ВТБ

Задаёт целевую архитектуру и общие сервисы. Руководитель центра и РП согласуют дорожную карту, разработка обеспечивает техническую совместимость.

03 / Рост команды

Расширение вслед
за зрелостью портфеля.

Найм привязан к нагрузке, готовности процессов и задачам эксплуатации. Стартовый состав закрывает полный цикл; расширение даёт параллельность и устойчивость.

СТАРТОВЫЙ СОСТАВ12включая руководителя центра
РАСШИРЕННЫЙ СОСТАВ21включая руководителя центра
+9 новых позиций

Больше команд внедрения, больше системных проектов и отдельная компетенция MLOps.

Сравнение стартового и расширенного штата
ПодразделениеСтартРасширениеЧто даёт рост
Руководство центра1Руководитель центра1Руководитель центраЕдиный мандат и управление портфелем
Forward Deploy Engineers31 руководитель + 2 FDE51 руководитель + 4 FDE+2 FDE: охват новых бизнес-юнитов, обучение и развитие амбассадоров
Проектные руководители41 руководитель + 2 РП
+ 1 младший координатор
71 руководитель + 4 РП
+ 2 координатора
+2 РП и +1 координатор: больше параллельных проектов и управляемых согласований
Разработка платформы ИИ41 руководитель + 2 разработчика
+ 1 DevOps
81 руководитель + 3 разработчика
+ 2 DevOps + 2 MLOps
+1 разработчик, +1 DevOps, +2 MLOps: интеграции, надёжность и контроль качества ИИ
Всего в центре1221+9 позиций · Амбассадоры не включены

В расширенном составе стартовый младший координатор учитывается как один из двух проектных координаторов. Сроки и промежуточные волны найма определяются по фактической потребности.

ВОЛНА 01Собрать основу

Лидеры и стартовая команда

Три руководителя направлений и стартовые специалисты. Приоритет — запустить весь цикл от исследования процесса до внедрения и поддержки.

Условие стартаСогласованы мандат, спонсор со стороны бизнеса, штат и базовые ИТ-ресурсы.

ВОЛНА 02Расширить внедрение

FDE, РП и координация

До +2 FDE, +2 РП и +1 координатора. Наём можно вести поэтапно — в ответ на очередь подтверждённых инициатив.

Сигнал для наймаПроверенные кейсы готовы к запуску, а загрузка команды ограничивает охват бизнес-юнитов.

ВОЛНА 03Усилить эксплуатацию

Разработка, DevOps и MLOps

До +1 разработчика, +1 DevOps и +2 MLOps. Техническую волну можно ускорить, если этого требуют нагрузка и риски эксплуатации.

Сигнал для наймаРастут число интеграций и критичность сервисов; требуется отдельное сопровождение качества ИИ.

04 / Технологическая опора

Легковесная платформа.
Долгосрочная ценность.

Временная платформа даёт бизнесу рабочие инструменты до готовности целевой платформы центрального ВТБ. Переносимость закладывается с первого дня.

01Рабочее место сотрудникаИИ-чат, помощники, шаблоны и библиотека сценариев
02Знания и бизнес-действияПоиск по разрешённым данным, документы и интеграции
03Управляемый доступ к моделямЕдиные интерфейсы, версии, лимиты и оценка качества
04Корпоративный контурSSO, права, журналирование и мониторинг

Переход на целевую
платформу ВТБ

Центр сохраняет процессы, знания и сценарии. Технологические компоненты последовательно переводятся на общие сервисы.

  1. Согласовать границы

    Зафиксировать с ИТ ВТБ Капитал и центральным ВТБ временные компоненты, стандарты интеграций и критерии перехода.

  2. Изолировать зависимости

    Отделить бизнес-логику от конкретных моделей; хранить конфигурации, промпты и тестовые наборы в переносимом виде.

  3. Проверить готовность

    Сопоставить функциональность, доступы, качество, стоимость и поддержку. Согласовать владельцев миграции.

  4. Перенести и вывести из эксплуатации

    Мигрировать сценарии и данные по согласованному плану, провести приёмку, обучить пользователей и отключить заменённые компоненты.

Объём собственной разработки пересматривается по мере готовности общих сервисов. Обязательства по срокам центральной платформы в этом плане не предполагаются.

05 / Первый цикл работы

Первые 90 дней.

Предлагаемый ориентир после запуска центра. Последовательность уточняется с учётом найма, доступов и корпоративных согласований.

ДНИ 01–30

Понять и договориться

  • Согласовать мандат центра и владельцев процессов.
  • Исследовать приоритетные бизнес-юниты и практики Shadow AI.
  • Зафиксировать исходные показатели процессов.
  • Определить амбассадоров и маршрут согласований с ИТ и ИБ.
Результат этапаКарта возможностей, реестр инициатив, критерии отбора и согласованный план пилотов.
ДНИ 31–60

Проверить в работе

  • Запустить согласованные пилоты на реальных задачах.
  • Дать сотрудникам минимальный набор разрешённых инструментов.
  • Провести практикумы и обучение амбассадоров.
  • Подготовить паспорта системных проектов вместе с РП.
Результат этапаПроверенные сценарии, обратная связь пользователей и решение по каждому пилоту.
ДНИ 61–90

Закрепить и развивать

  • Перевести успешные пилоты в проекты или рабочие практики.
  • Утвердить регламенты, поддержку и владельцев решений.
  • Сравнить результаты с исходным состоянием.
  • Уточнить портфель, потребность в найме и план миграции.
Результат этапаПортфель внедрений с ответственными, подтверждённые результаты и обоснование следующей волны.

Как подтверждаем
эффект

РП ведут реестр эффектов. FDE собирают данные о практике, разработка — о работе инструментов. Бизнес подтверждает результат.

Процесс

Длительность операций, трудозатраты, объём ручных действий, ошибки и повторная работа.

Применение навыков

Регулярное использование, перенос обучения на рабочие задачи и тиражирование через амбассадоров.

Управляемость

Доля учтённых практик Shadow AI, переход в согласованные инструменты и назначенные владельцы.

Качество и экономика

Качество ответов на тестовых наборах, доступность сервисов и затраты на модели, инфраструктуру и поддержку.

Целевые значения устанавливаются после базового замера. Высвобождённое время и фактическая денежная экономия учитываются отдельно; финансовый эффект подтверждается с бизнесом и финансовой функцией.