«Найдём архитектора искусственного интеллекта» — частая первая реакция на решение внедрять ИИ, и частая ошибка. Иногда роль действительно нужна, иногда — это дорогое украшение для простого проекта. Разберём, что делает ИИ-архитектор, в какой момент он становится необходимым и чем его заменить, пока штатная роль не обоснована.
Что вообще делает ИИ-архитектор
Это роль на стыке данных, инфраструктуры и бизнеса. В зоне ответственности — решения, которые определяют стоимость и риски контура на годы:
- Карта сценариев и моделей. Какие задачи решаем ИИ, где достаточно готового API, где нужен RAG по документам, где — дообучение или своя модель.
- Шлюз и унификация. Единая точка доступа к моделям: лимиты, маршрутизация, подмена вендора без переписывания приложений, учёт затрат.
- Данные. Откуда берутся датасеты и базы знаний, кто ими владеет, как размечены права доступа, что попадает в локальный контур.
- Сквозная карта рисков. Модель угроз, изоляция, журналирование — в связке с ИБ, а не вместо неё.
- TCO и траектория масштабирования. Сколько контур будет стоить через год при росте нагрузки и какие решения залечат это в архитектуру заранее.
- Правила безопасности по умолчанию. Что обязано журналироваться, какие данные не покидают периметр, как устроены доступы — чтобы каждая новая команда не решала это заново.
- Взаимодействие с командами. Как отделы заказывают ИИ-возможности и по какому процессу — иначе архитектура останется картинкой в презентации.
Проще всего понять роль через отрицание: ИИ-архитектор не пишет промпты и не настраивает конкретную интеграцию — он решает, какие интеграции вообще нужны и как они уживаются.
Когда роль избыточна
Честный список ситуаций, где архитектор не нужен:
- Один чат-бот на сайте или один ассистент поддержки — готовое решение с простой интеграцией.
- Один процесс, один пилот. Команда делает прототип, чтобы проверить эффект; архитектурные решения умещаются в постановке задачи.
- SaaS без модификаций. Компания пользуется готовым сервисом и не строит своего.
В этих случаях архитектуру ведёт техлид проекта или внешний консультант на пару сессий. Нанимать отдельного специалиста — как держать штатного архитектора зданий под навес для машины.
Когда без архитектора становится дорого
Обратная картина возникает по мере роста. Признаки, что зоопарк уже сформировался:
- Каждый отдел покупает свой ИИ. Маркетинг — один сервис, поддержка — второй, юристы — третий; данные и бюджеты не пересекаются.
- Повторная разработка. Три команды независимо строят похожие RAG-системы по своим документам.
- Подмена вендора — это проект. Смена модели или тарифа требует переписывать каждое приложение по отдельности.
- Данные размазаны. Никто не знает, какие датасеты уже подготовлены и чьи в них права.
- Затраты неуправляемы. Счета за API растут быстрее пользы, лимитов и учёта нет.
Каждый пункт — прямые потери: в деньгах, сроках или рисках. Если узнали два-три — роль уже обоснована экономически.
Матрица решений вместо должности
Архитектура — это не человек, а набор зафиксированных решений. На старте их можно принять и без штатной роли:
| Решение | Стандарт здорового проекта |
|---|---|
| Доступ к моделям | Единый шлюз или корпоративный портал, приложения не ходят в API напрямую |
| Данные | Каталог датасетов и баз знаний, владелец и права у каждого массива |
| Резервирование | Основная и запасная модель для критичных сценариев |
| Контур для чувствительного | Локальная модель для данных, которым не место в облаке |
| Учёт | Лимиты и метрики затрат по командам |
Эта таблица — по сути техзадание на архитектуру. С ней роль можно закрыть техническим директором с внешней экспертизой: архитектурный аудит контура — типовая услуга с вилкой от 90 000 ₽ (типовая вилка класса работ, не оферта).
Чем проверить своего архитектора на старте
Если роль уже есть (штатная или внешняя), у неё должен быть измеримый выход. Попросите четыре артефакта:
- Карта систем и данных на одной странице: что где живёт, что кому принадлежит.
- Правила выбора контура: облако по договору или локально — по классу данных, а не по вкусу команды.
- План отказоустойчивости: что происходит при недоступности основного вендора.
- Дорожная карта на год с TCO: что станет дороже при росте и какие решения этому мешают заранее.
Нет артефактов — есть только должность. Полезные смежные материалы: выбор LLM для бизнеса и сравнение готового сервиса против своей разработки.
Практический тест на честность роли звучит так: покажите решение, которое архитектура запретила. Хороший архитектор регулярно говорит «нет» — покупке сервиса, который дублирует существующий, интеграции в обход шлюза, загрузке чувствительных данных в чужое облако. Если все предложения команды проходят без единого отказа, у вас не архитектор, а согласователь. Ценность роли ровно в том, чтобы дорогие ошибки не доезжали до продакшена.
Как роль соотносится с CIO, CISO и подрядчиком
ИИ-архитектор — не замена существующим ролям, а связующее звено:
- Перед CIO отвечает за техническую реализуемость дорожной карты и её стоимость.
- С CISO совместно ведёт модель угроз: архитектор проектирует контуры, безопасность их принимает.
- Подрядчику формулирует требования и принимает соответствие архитектуре — именно на этом стыке чаще всего теряются деньги, когда у заказчика нет своего видения целого.
Когда контуров несколько, заказная разработка без внутреннего архитектора превращается в набор несовместимых систем — как работать с подрядчиком, чтобы этого не случилось, разобрано в материале о проверке подрядчика перед договором.
Что учитывает архитектор после 243-ФЗ
Закон об ИИ добавил архитектуре одно новое измерение — происхождение и статус моделей. Что теперь входит в проектные решения:
- Происхождение модели. Для каждой системы фиксируется, чья базовая модель, каков её статус и как это отражено в договоре с вендором или подрядчиком. Для заказной разработки это вопрос номер один на старте — что требовать, подсказывает разбор о требованиях к подрядчику при заказе ИИ.
- Реестр ИИ-активов как архитектурный документ. Не бюрократия, а карта: какие системы, на каких моделях, с какими данными. Архитектор — естественный владелец этой карты.
- Долговечность решений. Переходный период закона длится до 2032 года, обязанности вводятся поэтапно — архитектура должна переживать смену требований без полной пересборки: фиксируйте версии, держите резервы, не пришивайте вендора к коду.
- Локализация чувствительных данных. Правила, какие контуры обязаны жить на своей инфраструктуре, — часть архитектуры, а не разовое решение ИБ.
Такой «правовой слой» архитектуры не усложняет проект — он страхует от переделок: системы, спроектированные без учёта происхождения моделей, придётся перестраивать первыми.
Вывод
Отдельный ИИ-архитектор — не признак серьёзности, а ответ на конкретную сложность: несколько систем, общие данные, сквозные риски. Пока система одна — архитектуру ведёт техлид по матрице стандартных решений. Когда отделы начали закупать ИИ независимо, а смена вендора превращается в проект — роль окупается быстро. В любом случае начните с карты систем и правил выбора контура: это дешёвый шаг, который делает очевидным, нужен ли вам человек.