AI Architect (AIA) / AI-архитектор

Зачем эта роль

AIA существует, потому что у клиента, в котором появляется AI, должен быть один человек, отвечающий за то, что AI-решение работает в реальной корпоративной среде, а не только на демо. Без AIA AI-проект превращается либо в красивый POC, который не доживает до production (модель работает в лабораторных условиях, но падает на legacy-данных клиента, на нетипичных запросах, на корпоративных ограничениях по безопасности), либо в дорогую игрушку, в которой стоимость токенов съедает любую выручку.

AIA — решатель «AI distribution bottleneck». Это термин из стратегической гипотезы компании: «AI distribution bottleneck» — это не проблема обучения моделей и не проблема выбора архитектуры, а проблема доведения AI-решения до работы у конкретного клиента в его конкретной среде. Большинство AI-проектов в индустрии застревают именно здесь: технология есть, идея есть, POC есть — а в production оно не уходит. AIA закрывает этот участок.

Из чего вырастает AIA

AIA вырастает из ролей бизнес-аналитика и частично системного архитектора, но качественно отличается от обоих:

• Бизнес-аналитик отвечает на вопрос «что внедрить»; AIA отвечает на вопрос «как сделать так, чтобы внедрённое работало»
• Системный архитектор рисует архитектуру на бумаге; AIA доводит её до работающей конфигурации в реальной среде клиента — с его legacy, недокументированными процессами, политическими ограничениями и токеномикой

Ключевая разница — AIA несёт ответственность за production-deployment, а не за «правильно спроектированную схему». Спроектировать архитектуру AI-контура — это часть его работы; запустить её в реальной среде клиента и довести до состояния «работает ≥1 месяца стабильно» — это и есть его продукт.

Что входит в архитектуру AI-контура клиента

AI-контур клиента — это не одна модель, а целая инфраструктура, которую AIA проектирует и запускает:

• Выбор моделей и агентных систем под конкретные бизнес-задачи клиента (универсальная модель не существует; правильная связка зависит от природы задачи, объёма данных, требований к латентности, корпоративных ограничений)
• Проектирование контекстной инфраструктуры (Context Engineering) — той инфраструктуры, которая делает AI полезным в конкретной среде клиента (RAG, базы знаний, протоколы получения контекста, обновление контекста по мере жизни системы)
• Управление токеномикой и стоимостью как инженерной задачей — стоимость токенов закладывается в архитектуру, а не «выясняется по факту»; AIA проектирует решение так, чтобы экономика сходилась
• Интеграция с legacy-данными и недокументированными процессами клиента — AI-решение работает на реальных данных клиента, в которых данные плохо структурированы, процессы не описаны, а ключевые правила существуют в головах сотрудников

FDE и AIA: разделение ролей

FDE и AIA — обе производственные роли, обе работают «руками» внутри клиента, обе применяют AI как инструмент. Но они работают на разных уровнях абстракции и решают разные задачи. Это разделение критично для понимания, кого и когда привлекать на проект.

Короткая формулировка:

• FDE решает конкретную бизнес-задачу клиента, доводя её до production через SDD/EDD/вайб-кодинг. Горизонт — один проект, одна задача, одно работающее изменение.
• AIA проектирует и запускает AI-инфраструктуру клиента: какие модели, как организован контекст, как управляется токеномика, как интегрироваться с legacy-данными. Горизонт — год+ работы клиента с AI, на которой затем решаются конкретные задачи.

В чём это проявляется:

Метафора: AIA — архитектор больницы (проектирует среду, в которой можно оперировать: какое оборудование, какие протоколы, какая экономика). FDE — хирург (делает конкретную операцию в этой среде с ответственностью за результат на конкретном пациенте). Обе роли «руками» в системе клиента, но на разных уровнях абстракции.

Когда это важно понимать:

• Без AIA AI-проект застревает на POC: модель работает в лаборатории, но не в реальной среде клиента
• Без FDE архитектура остаётся на бумаге: красивая схема есть, работающего изменения у клиента нет
• На малых проектах граница может исчезать: один человек способен закрывать обе функции (см. Disrupt в обеих карточках)
• На крупных AI-проектах AIA приходит первым (проектирует контур), FDE — следом (реализует решения внутри готового контура)

AIA в системе NOTA

AIA — индивидуальный игрок, как FDE; не руководитель. На крупных AI-проектах работает в треугольнике с PM (управление проектом) и FDE (реализация); на проектах поменьше может работать в паре с FDE.

AIA применяет на стороне клиента методологический стек компании в категории «Знания, AI и технологии» — CODE-фреймворк, AMP-логика, ADLC, AX. Это аналог дисциплины SDD/EDD у FDE, но на уровне архитектуры AI-контура: не «как написать качественный код», а «как построить качественный AI-контур в чужой среде». Эволюция самого стека — зона PO Digital Shift; AIA — пользователь и поставщик обратной связи.

AIA — несущая роль для AI-портфеля компании. Чем сильнее AIA, тем выше доля AI-проектов, доходящих до production, и тем управляемее экономика AI-решений в портфеле.

Продукт должности

Архитектурное решение AI-контура клиента, развёрнутое в его реальной корпоративной среде с её ограничениями — а не лабораторный прототип. Закрывает то, что в стратегической гипотезе названо узким местом внедрения AI («AI distribution bottleneck»): технология выбрана, контекст спроектирован, токеномика управляема, интеграция с legacy-данными работает, методологический стек компании переведён в работающую конфигурацию у клиента.

Главный потребитель и его требования

Главный потребитель: CVD (получает рабочую AI-инфраструктуру клиента как фундамент для проектов портфеля).

CVD получает от AIA не «архитектурную схему AI-решения», а AI-контур, который работает в среде клиента и не разваливается через месяц после запуска. Конкретные требования:

• AI-решение в production, а не в POC. AI-проект должен дойти до Status Done/Guarantee — то есть быть запущенным в реальную работу клиента и продержаться в production стабильно. POC, который «технически работает, но клиент им не пользуется» — это не результат AIA.
• Управляемая токеномика. Стоимость AI-токенов на проекте должна быть прогнозируемой и согласованной с экономикой проекта. CVD должен видеть долю AI в выручке проекта по своему портфелю и понимать, не съедают ли токены маржу.
• Высокий технический рейтинг от клиента именно по AI-составляющей. Клиент должен оценивать AI-часть решения как минимум «выше ожиданий». Если технический рейтинг проекта высокий по разработке, но низкий по AI — это сигнал к AIA, не к FDE.
• Архитектурные решения принимаются заранее, не на ходу. К началу разработки FDE-командой AIA должен закрыть выбор моделей, контекстную инфраструктуру и интеграционную модель. Если решения принимаются во время разработки — это превышение бюджета и срыв сроков.
• Методологический стек применяется как живая дисциплина. CODE/AMP/ADLC/AX — не формальность для отчёта, а реальный фреймворк, который CVD может предъявить клиенту как доказательство профессиональной работы с AI.

Вторичный потребитель: конечный клиент — получает AI-решения, работающие в его среде, а не в лабораторных условиях, и архитектора, который понимает legacy-контекст его бизнеса.

Run / Change / Disrupt

Run (поддержание потока)

То, что AIA делает каждую неделю внутри AI-проектов:

• Прямая коммуникация с клиентом на уровне топ-менеджмента и технических руководителей: объяснение выбора моделей, токеномики, ограничений
• Проектирование AI-архитектуры под бизнес-задачу: выбор моделей и агентных систем, схема контекстной инфраструктуры
• Интеграция с legacy-данными клиента: разбор источников, проектирование пайплайнов, выявление недокументированных правил
• Управление токеномикой проекта: расчёт прогнозной стоимости, мониторинг фактической, оптимизация при отклонениях
• Production deployment AI-решения: доведение до состояния стабильной работы ≥1 месяц
• Применение методологического стека (CODE/AMP/ADLC/AX) на проектах
• Координация с FDE и PM на стыках архитектуры и реализации
• Передача обратной связи о применимости методологии в зону PO Digital Shift

Change (улучшение того, как роль работает)

То, что AIA делает на горизонте проекта/квартала, чтобы делать роль лучше:

• Накопление и систематизация типовых архитектурных паттернов AI-контуров под отраслевые задачи
• Развитие компетенций по новым моделям, новым агентным системам, новым подходам к проектированию контекстной инфраструктуры
• Совершенствование подхода к оптимизации стоимости токенов: накопление паттернов экономной архитектуры
• Развитие интеграционной библиотеки: типовые подходы к работе с legacy-данными, к восстановлению недокументированных процессов
• Передача найденных паттернов в зону PO Digital Shift для эволюции методологического стека

Disrupt (переизобретение роли)

То, что меняет саму конфигурацию роли в системе:

• Размывание границы между AIA и FDE: на проектах с глубокой AI-составляющей и хорошим уровнем AI-усиления одна роль может закрывать обе функции
• Превращение AI-архитектуры в самообучающуюся: AI-контур клиента сам адаптируется к новым задачам без участия архитектора в каждой настройке
• Переход от «AIA проектирует контур под задачу» к «AIA проектирует фабрику контуров»: метаархитектура, из которой генерируются конкретные конфигурации под конкретных клиентов
• Выход на стратегический уровень: AIA становится советником ЛПР клиента по AI-стратегии бизнеса в целом, а не только по архитектуре конкретных решений (приближение к функции CVD)

Метрики

AIA измеряется композитом из 3 метрик, покрывающих все три ноги EEQ (Effectiveness / Efficiency / Quality) и ориентированных на главный вопрос CVD: AI-решения доходят до production, клиент технически доверяет архитектору, экономика AI-контура управляема.

Логика композита: одна метрика — итоговый замер главного обещания (AI-решения, спроектированные AIA, доходят до production у клиента, а не остаются на стадии PoC). Вторая — техническое доверие со стороны клиента (стандартизованный замер восприятия архитектурного качества, отдельно от удовлетворения проектом в целом). Третья — экономическая управляемость AI-контура (стоимость токенов на единицу бизнес-результата для клиента, отражающая способность AIA проектировать с пониманием экономики, не только технического качества).

Метрики дополняют друг друга по логике «доходит до production / клиент верит / экономически управляемо». Если в production высокая доля, но Token Cost Efficiency низкая — AIA проектирует красиво, но клиент платит за это слишком много, контракт не масштабируется. Если Client Technical Rating высокий, но в production мало — клиент доверяет, но что-то системно блокирует переход PoC → production (это сигнал к COO/PM, а не к AIA, но проявляется через метрику AIA).

Полный список метрик с определениями и порогами — в свойстве Metrics ниже.

🟢 Full Zone of Genius (зона полной автономии)

Решения, которые AIA принимает сам, без согласования с кем-либо. Это широкая зона в AI-архитектуре и сужается на коммерческой/управленческой границе.

• Выбор моделей и агентных систем под бизнес-задачу. Какую модель использовать, какие модели комбинировать, какую агентную схему построить, где AI уместен, а где обычный код. CVD и FDE получают результат, не диктуют процесс.
• Архитектура контекстной инфраструктуры. Как структурировать контекст AI-системы, какие источники подключать, как обновлять контекст, как балансировать релевантность и стоимость. Это профессиональное суждение AIA.
• Решения по токеномике на уровне архитектуры. Какие модели использовать на каких этапах (дешёвая → дорогая), какую часть выносить в кэш, какую — в локальные модели, как структурировать промпты для оптимизации стоимости. AIA решает в рамках утверждённого бюджета AI-проекта.
• Подход к интеграции с legacy-данными. Как восстанавливать недокументированные процессы, какие источники подключать, как валидировать данные, какие пайплайны строить. AIA решает по контексту клиента.
• Применение конкретных блоков методологического стека (CODE/AMP/ADLC/AX) к проекту. AIA применяет стек как обязательную дисциплину, но конкретное применение на проекте — его суждение.
• Тактические переговоры с уровнем топ-менеджмента и техническими руководителями клиента по архитектурным вопросам. Объяснение выбора моделей, токеномики, ограничений, рисков. AIA общается с клиентом напрямую как мини-консультант на архитектурном уровне; не нужно проводить каждое объяснение через CVD.
• Решения по production deployment AI-решения. Когда решение готово к production, какие тесты на стабильность провести, как мониторить, как откатывать. AIA несёт ответственность за факт деплоя.

Принцип: всё, что касается как строится и как работает AI-контур у клиента — это зелёная песочница AIA. Зрелость AIA измеряется тем, насколько широка его автономия в архитектурных решениях без потери качества и без выхода за рамки токеномики.

🟡 Decisions Requiring Collaboration (коллегиальные решения)

Решения, которые AIA принимает в коллаборации с другими ролями. Здесь критично понимать с кем и как принимается решение.

• Архитектурные решения уровня проекта, влияющие на сроки и реализацию → с FDE и PM. Как: AIA формулирует архитектуру и токеномику, FDE валидирует реализуемость и оценивает трудоёмкость, PM проверяет влияние на план проекта.
• Изменение базового AI-стека на проекте (новая модель-провайдер, новая агентная платформа) → с FDE и CVD. Как: AIA обосновывает выбор техническими и продуктовыми аргументами, FDE проверяет совместимость с реализацией, CVD проверяет влияние на портфель и долгосрочные обязательства перед клиентом.
• Серьёзные изменения в коммуникации с клиентом по AI-стратегии (отказ от подхода, предложение альтернативы вместо запрошенного, эскалация архитектурного риска) → с CVD и PM. Как: AIA формулирует архитектурную позицию, CVD решает, как это донести до ЛПР, PM координирует тактическую коммуникацию.
• Превышение прогнозной токеномики на проекте → с CVD и PM. Как: AIA сигнализирует о превышении на ранней фазе, CVD оценивает влияние на маржу проекта и принимает решение о дальнейшей экономике (компенсация скоупом, переговоры с клиентом, оптимизация архитектуры).
• Применение нового блока методологического стека на проекте, ещё не валидированного на других внедрениях → с PO Digital Shift. Как: AIA формулирует, что хочет применить и зачем, PO Digital Shift валидирует применимость и помогает с адаптацией.
• Включение найденного архитектурного паттерна в методологический стек компании → с PO Digital Shift. Как: AIA поставляет паттерн с описанием контекста и ограничений, PO Digital Shift решает, войдёт ли это в стек и в каком виде.
• Архитектурные решения, затрагивающие внутреннюю AI-инфраструктуру компании (выбор провайдеров, общий tooling) → с COO и Sysadmin. Как: AIA формулирует потребность с проекта, Sysadmin оценивает совместимость с инфраструктурой, COO принимает решение о включении в общую практику.

🔴 Decisions That Should Never Be Made (зона запрета)

Решения, которые AIA не принимает ни в одиночку, ни в коллаборации.

• Реализация отдельных фич и кода. Это зона FDE. AIA проектирует архитектуру и интеграции; реализация — за FDE. Исключение — малые проекты без FDE, где AIA может закрывать обе функции; но это не «принимать решения за FDE», а «работать в его отсутствие».
• Управление сроками и прогрессом проекта (структура спринтов, ритуалы, приоритеты бэклога). Это зона PM. AIA работает по плану PM, а не подменяет его.
• Стратегические отношения с ЛПР клиента. Это зона CVD. AIA общается с клиентом тактически по архитектурным вопросам, но не выстраивает стратегию аккаунта и не ведёт диалог о расширении сотрудничества.
• Коммерческие решения (стоимость работы, скидки, условия контракта). Это зона CVD и GM. AIA может зафиксировать факты по архитектуре и токеномике, но не торгуется с клиентом и не делает коммерческих предложений.
• Эволюция методологического стека компании (какие новые блоки добавить в CODE/AMP/ADLC/AX, как переработать существующие). Это зона PO Digital Shift. AIA поставляет паттерны и обратную связь с проектов, но не решает, что войдёт в стек.
• Внутренняя AI-инфраструктура компании (выбор провайдеров для внутреннего использования, корпоративный AI-tooling). Это зона Sysadmin и COO. AIA может предложить выбор с опытом проектов, но решение принимает Sysadmin/COO.
• Изменения в общих процессах и регламентах компании (как все AIA должны работать, общие SLA, общие правила работы с клиентом). Это зона COO. AIA формулирует свою практику, но решение о превращении в стандарт принимает COO.
• Кадровые решения по своей команде или другим AIA. Это зона CVD как руководителя дивизиона и HR Manager. AIA может дать обратную связь, но не принимает решений о найме, увольнении, ротации.
• Решения по продажам и привлечению новых клиентов. Это зона CSO и CVD. AIA может показать AI-решение в демо или принять участие в пресейле по запросу, но не ведёт продажу.

Принцип: красная песочница AIA — это граница с производственными ролями (FDE, PM) внутри проекта, граница со стратегическими ролями (CVD, PO Digital Shift, CSO) и граница с операционными ролями компании (COO, Sysadmin). AIA — производственная роль с глубокой автономией в AI-архитектуре; попытка зайти в управление, методологию, коммерцию или внутреннюю инфраструктуру подменяет другие роли и снижает качество системы.

Цикл PDCA

AIA управляет двумя вложенными циклами с разной частотой. Внешний цикл — управление AI-контуром клиента целиком; внутренний — управление каждым архитектурным решением внутри проекта.

Цикл управления архитектурным решением (короткий, по архитектурному элементу)

• Plan — постановка элемента архитектуры: уточнение бизнес-задачи, выбор модели/агентной схемы, проектирование контекста, расчёт прогнозной токеномики, проектирование точек интеграции с legacy.
• Do — реализация: проектирование детальной архитектуры элемента, координация с FDE по реализации, валидация на тестовых данных клиента.
• Check — валидация элемента: тесты на реальных данных клиента, замер фактической токеномики против прогноза, проверка интеграции с legacy.
• Act — корректировка следующего элемента: уточнение архитектурных предпосылок, пересмотр прогноза токеномики, корректировка подхода к интеграции по реальным данным клиента.

Цикл управления AI-контуром клиента (длинный, по периоду проекта/года)

• Plan — постановка контура: общая архитектура AI-решения, общая токеномика, общая стратегия интеграции с legacy, выбор применимых блоков методологического стека.
• Do — реализация контура: выполнение по архитектурным элементам, координация с FDE/PM на стыках, диалог с уровнем топ-менеджмента клиента по архитектуре и токеномике.
• Check — production deployment и стабилизация: запуск в реальную среду клиента, мониторинг стабильности и токеномики, замер технического рейтинга от клиента.
• Act — корректировка контура и наследие: оптимизация работающего контура по результатам production-эксплуатации, фиксация типовых паттернов в копилку компании, передача находок в зону PO Digital Shift, участие в разборе по итогам проекта под управлением PM.

Внутренний цикл (архитектурный элемент) питает внешний (контур): прогнозы и факты токеномики по элементам складываются в общую экономику контура; интеграционные находки по отдельным источникам данных формируют итоговую картину работы с legacy. Внешний цикл задаёт рамки для внутреннего: согласованная общая архитектура и токеномика определяют допуски, в которых работают отдельные элементы.