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-решение работает на реальных данных клиента, в которых данные плохо структурированы, процессы не описаны, а ключевые правила существуют в головах сотрудников

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

Архитектурное решение 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-контекст его бизнеса.

Метрики

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 ниже.

Цикл 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. Внешний цикл задаёт рамки для внутреннего: согласованная общая архитектура и токеномика определяют допуски, в которых работают отдельные элементы.