Перейти к основному содержимому

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

Назначение​

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

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

Связанный раздел: архитектура ИИ-конвейера.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Агент разработки​

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

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

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

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

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

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

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

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

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

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

Роль платформы​

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

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

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

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

Плохая архитектурная практика:

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

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