Архитектура

Зачем эта функция в ОМВИ

ОМВИ строится вокруг портфеля переиспользуемых ИИ-продуктов, а не отдельных решений под каждый кейс. Удержать этот принцип невозможно без архитектуры: именно она следит, чтобы новая инициатива по возможности опиралась на существующие ИИ-продукты и платформенные сервисы, а не создавала десятую интеграцию с тем же LLM по-своему.

Архитектура связывает три слоя: бизнес-сценарий инициативы, портфель ИИ-продуктов и общий технологический ландшафт компании. Без этого стыка ИИ-функция быстро накапливает технический долг и теряет управляемость затрат (то, что Bain называет разрастанием инструментов и непрозрачной экономикой).

Где подключается

Этап ОМВИ	Роль архитектуры
Оценка / выбор продукта	Предлагает переиспользовать существующий ИИ-продукт или обосновать новый
Деливери	Проектирует целевую архитектуру решения, интеграции, стандарты
Перед продом	Проводит architecture review: соответствие стандартам, масштабируемость, поддерживаемость
Развитие портфеля	Поддерживает технологические гайдлайны и эталонные паттерны

Что функция получает на вход

• Бизнес-сценарий и нефункциональные требования (нагрузка, доступность, латентность).
• Карту интеграций с корпоративными системами и источниками данных.
• Варианты решения от деливери-трека или владельца ИИ-продукта.

Что функция отдаёт на выход

• Целевую архитектуру решения и обоснование выбора (build / reuse / buy).
• Технологические ограничения и стандарты (стек, интеграционные контракты, паттерны).
• Заключение architecture review как условие перехода через контрольную точку перед продом.

Ключевые артефакты стыка

• Architecture review — документ ревью архитектуры решения (есть в библиотеке артефактов ОМВИ).
• Карта ИИ-ландшафта — какие ИИ-продукты, модели и интеграции уже есть и где переиспользуются.
• Технологические гайдлайны — эталонные паттерны интеграции и развёртывания ИИ-продуктов.

Антипаттерны

• Каждой инициативе — своё решение. Дублирование интеграций и моделей, рост затрат и техдолга вместо переиспользования продуктов.
• Architecture review для галочки. Ревью проходит формально и не влияет на решение — стандарты деградируют.
• Архитектура в башне из слоновой кости. Гайдлайны написаны, но оторваны от реальной деливери, поэтому их обходят.

Архитектурное управление

Назначение

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

Цель — не нарисовать красивую схему, а понять, можно ли решение безопасно встроить в реальный бизнес-процесс и кто будет отвечать за его работу после запуска.

Связанный раздел: Architecture.

Основные идеи

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

Где архитектура встроена в конвейер

Этап	Архитектурный вопрос	Результат
Новая	есть ли очевидная технологическая зависимость	отметка в карточке или задача на уточнение
Оценка	какой ИИ-продукт подходит и какие системы затрагиваются	предварительный маршрут деливери
Деливери	как решение будет встроено, защищено, развернуто и поддержано	архитектурное заключение
Ожидает эффекта	работает ли решение в целевом процессе	подтверждение эксплуатации и метрик
Поддержка	кто сопровождает, как мониторится и обновляется	режим сопровождения

Минимальные архитектурные вопросы

Перед деливери нужно ответить:

• какой ИИ-продукт используется;
• какие системы являются источниками данных;
• какие системы получают результат;
• где выполняется обработка;
• какие данные проходят через решение;
• кто имеет доступ;
• как решение масштабируется;
• что происходит при ошибке;
• как ведутся журналы;
• как измеряется качество и использование;
• кто сопровождает решение после запуска;
• как выполнить откат.

Если ответы неизвестны, инициатива может оставаться в оценке или прототипе, но не должна считаться готовой к внедрению.

Типовые архитектурные контуры

Помощник по знаниям

Проверяются:

• источники документов;
• права доступа к документам;
• обновление базы знаний;
• ссылки на источники в ответах;
• разграничение внутреннего и внешнего доступа;
• журнал запросов;
• правила удаления или обновления документов.

Машинное обучение

Проверяются:

• витрины данных;
• качество и стабильность признаков;
• процесс обучения и проверки;
• версионирование модели;
• мониторинг качества;
• откат на предыдущую версию;
• стоимость вычислений.

Автоматизация процесса

Проверяются:

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

Код-агент

Проверяются:

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

Архитектурное заключение

Для инициатив со средним и высоким риском нужно фиксировать архитектурное заключение.

Минимальная структура:

• краткое описание решения;
• затронутые системы;
• источники и потребители данных;
• контур обработки;
• требования к доступам;
• интеграции;
• мониторинг;
• отказоустойчивость;
• план отката;
• ограничения;
• решение архитектора: допустить, допустить с условиями, вернуть на доработку, отклонить.

Архитектурное заключение должно быть связано с контрольной точкой (gate) перед переходом к внедрению или ожиданию эффекта.

Что блокирует внедрение

Инициатива не должна идти в рабочую среду, если:

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

Роль платформы ИИ Конвейер

Платформа ИИ Конвейер помогает архитектурному управлению через:

• связь инициативы с ИИ-продуктом;
• деливери-треки;
• задачи и ответственных;
• артефакты по этапам;
• обязательные поля;
• проверки перед переходом;
• историю решений;
• аналитику инициатив в деливери и ожидании эффекта.

В зрелой настройке для каждого ИИ-продукта должны быть свои типовые архитектурные требования и шаблоны артефактов.

Анти-паттерны архитектурного управления

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

Хорошая архитектурная практика делает внедрение скучным: понятно, где работает решение, кто его поддерживает, как его наблюдать и как безопасно остановить.