Архитектура ИИ на предприятии: что меняется, когда ИИ приходит в компанию

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

Что на самом деле означает архитектура корпоративного ИИ

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

Корпоративный архитектор не заменяет архитектора ИИ-решения или архитектора ИИ-платформы. Корпоративный масштаб задает другой вопрос: как множество ИИ-решений и общих возможностей ИИ вписываются в целевую архитектуру, политики, ландшафт данных, модель рисков и операционную модель компании?

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

Самый простой пример

Компания начинает с одного внутреннего помощника по документам. Первая версия ищет по утвержденным документам и отправляет найденный контекст языковой модели. На уровне решения это может выглядеть просто.

Затем вторая команда хочет ИИ для поддержки клиентов. Третья хочет агента, который может обновлять тикеты. Финансовый отдел хочет анализ документов. HR хочет внутреннего помощника. Разработчики хотят агентов для программирования. Внезапно у компании появляются несколько поставщиков, несколько классов данных, разные группы пользователей, пересекающиеся индексы поиска, разные правила логирования, новые разрешения для инструментов, дублирующиеся секреты и неясная ответственность.

В этот момент вопрос уже не в том, «работает ли помощник?» Корпоративный вопрос становится таким: какие возможности утверждены, кто ими владеет, какие данные могут пересекать какую границу, как обеспечиваются идентичности и разрешения, какие поставщики допустимы, что должно проходить аудит и как организация может менять модели или поставщиков, не теряя контроля?

Где заканчивается простой пример

Корпоративная архитектура не означает, что каждый компонент ИИ должен быть централизован. Некоторые возможности следует сделать общими; другие должны оставаться в ведении домена. Финансы, HR, инженерия и поддержка клиентов могут обоснованно требовать разных границ данных, поставщиков, критериев оценки и правил человеческого утверждения.

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

Что меняется в архитектуре, когда ИИ приходит в предприятие

1. Бизнес-владелец становится частью технической архитектуры

Традиционным приложениям уже нужны бизнес-владельцы. ИИ делает это требование более заметным, потому что приемлемое поведение нельзя определить только через время безотказной работы и функциональную корректность. Кто-то должен отвечать за предполагаемое использование, недопустимое использование, качество выходных данных, путь эскалации и последствия неверных или неподходящих результатов.

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

2. Доступа к данным недостаточно — необходимо определить полномочия на данные

ИИ предприятия часто объединяет операционные базы данных, документы, поисковые индексы, векторные хранилища, хранилища данных, SaaS-системы и внешние знания. Архитектура должна различать, где хранится информация, и какой источник является авторитетным для данного утверждения или действия.

Векторный индекс может улучшить поиск, но не должен незаметно становиться системой учёта компании. Ответ модели может суммировать запись ERP, но не должен заменять ERP как авторитетный источник. Кэшированный контекст может улучшить задержку, но становится небезопасным, когда меняются разрешения или базовое бизнес-состояние.

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

3. Идентичность становится многоуровневой

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

Эти идентичности не следует сводить к одному общему API-ключу. Авторизация должна оставаться привязанной к правильному субъекту, а привилегированные инструменты должны получать только те полномочия, которые требуются для текущей операции.

Для агентных систем это становится особенно важным: модель может предложить действие, но среда выполнения должна решить, разрешено ли запрашивающей идентичности его выполнить. Возможность модели — это не авторизация.

4. Разрешения смещаются от доступа к контенту к полномочиям на действия

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

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

5. Поставщик ИИ становится зависимостью предприятия

Вызов API модели — это также отношения с поставщиком. Архитектура может зависеть от доступности поставщика, условий обслуживания, условий обработки данных, поддерживаемых регионов, жизненного цикла модели, квот, ценообразования, совместимости API, средств безопасности и уведомлений об изменениях.

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

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

6. Риск ИИ становится процессом жизненного цикла

Риск ИИ не исчерпывается одним одобрением перед запуском. Модель, промпт, корпус для поиска, набор инструментов, провайдер, популяция пользователей и окружающий бизнес-процесс могут измениться после развёртывания. Профиль риска меняется вместе с ними.

ISO/IEC 23894:2023 явно рассматривает интеграцию управления рисками ИИ в организационные деятельности и функции. NIST AI RMF аналогично определяет управление рисками на протяжении жизненного цикла. Поэтому архитектура предприятия должна сделать анализ рисков частью изменений и операций, а не изолированным документом о соответствии.

Риск также должен быть пропорциональным. Ассистент для суммаризации и автономная система, изменяющая производственные записи, не должны получать одинаковые меры контроля только потому, что обе используют LLM.

7. Управление становится операционной системой, а не PDF-политикой

ISO/IEC 42001:2023 определяет требования к созданию, внедрению, поддержанию и постоянному улучшению системы управления ИИ. Архитектурное следствие важно: управление должно связывать политику с реальными реестрами, ответственностью, процессами, средствами контроля, доказательствами, проверками и циклами улучшения.

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

8. Оценка становится производственным контролем

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

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

Изменения модели, промпта, поиска и инструментов должны быть прослеживаемы к доказательствам оценки там, где изменение может существенно повлиять на поведение вывода.

9. Наблюдаемость должна включать поведение, данные и контекст модели

Показателей CPU, памяти и частоты ошибок HTTP недостаточно для рабочих нагрузок ИИ. Производственная наблюдаемость может потребовать идентификаторов модели и провайдера, задержки, использования токенов, стоимости, результатов поиска, вызовов инструментов, поведения отказов, оценок, событий безопасности и классификаций сбоев.

В то же время телеметрия ИИ может содержать конфиденциальные данные. Журналы промптов и ответов могут стать теневым хранилищем данных. Поэтому архитектура предприятия должна определить, что можно логировать, как это редактируется, кто имеет к этому доступ, как долго это хранится и когда детальная трассировка должна быть отключена.

10. Компоненты ИИ нуждаются в явном владении жизненным циклом

Модели могут быть переименованы, заменены, выведены из эксплуатации или изменены провайдерами. Модели эмбеддингов могут сделать стратегию индексации недействительной. Шаблоны промптов и системные инструкции могут изменить поведение. Среды выполнения агентов и протоколы могут развиваться. Внешние инструменты могут изменять свои схемы и разрешения.

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

11. Реагирование на инциденты должно учитывать специфические для ИИ режимы отказа

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

Поэтому корпоративный регламент действий должен включать не только «перезапустить сервис». Он может потребовать отключения маршрута модели, отзыва доступа к инструментам, заморозки корпуса, изменения версии промпта, отключения возможности агента, смены поставщика, эскалации к владельцу домена или сохранения трассировок для расследования.

Корпоративный ИИ создаёт кросс-функциональную ответственность

Практическая модель архитектуры корпоративного ИИ

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

Представляйте корпоративный ИИ как потоки данных и полномочий, а не как блоки

Предприятию нужен реестр ИИ, прежде чем оно сможет управлять ИИ

Организации не могут управлять системами ИИ, которые они не могут идентифицировать. Корпоративная архитектура должна вести реестр на уровне, полезном для принятия решений, а не просто список названий моделей.

Управление ИИ и архитектура корпоративного ИИ связаны, но не совпадают

Регулирование становится входными данными архитектуры

Для организаций, работающих в Европейском союзе, AI Act может создавать требования, влияющие на проектирование систем, документацию, прозрачность, управление и операционные процессы. Влияние на архитектуру зависит от роли организации в цепочке создания ценности ИИ и конкретной классификации системы; не все системы ИИ имеют одинаковые обязательства.

По состоянию на 8 октября 2026 года в текущем консолидированном тексте указано, что Регламент в целом применяется с 2 августа 2026 года. Правила управления и обязательства для моделей ИИ общего назначения начали применяться раньше, а отдельные положения для систем высокого риска имеют более поздние сроки. Комиссия также начала обеспечивать соблюдение новых требований к прозрачности с 2 августа 2026 года для соответствующих интерактивных систем и систем синтетического контента.

Урок архитектуры предприятия не в том, чтобы «встроить соответствие требованиям в модель». Он в том, чтобы сделать классификацию, роль поставщика/развёртывающего, документацию, прозрачность, надзор, журналирование и доказательства изменений отслеживаемыми до системы, которая фактически реализует сценарий использования.

Закупки и архитектура становятся связанными

Внешняя модель или управляемая платформа ИИ может стать глубокой зависимостью, даже если интеграция требует всего нескольких вызовов API. Поэтому архитектура предприятия должна делать вопросы закупок технически конкретными.

Архитектура предприятия решает, сколько контроля над ИИ действительно требует требование

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

ИИ превращает управление изменениями в поведенческую проблему

Обычное обновление зависимости может изменить производительность или совместимость. Изменение ИИ также может изменить поведение. Замена модели, изменение системного запроса, изменение поиска, добавление инструмента или изменение политики контекста могут изменить то, как система интерпретирует и отвечает, даже если окружающий код приложения почти не меняется.

ИИ предприятия всё ещё нужны NFR и ADR

ИИ не заменяет обычную архитектурную дисциплину. Нефункциональные требования остаются целевыми условиями: доступность, задержка, приватность, изоляция, аудируемость, восстанавливаемость, границы стоимости, объяснимость или другие требования к качеству. Записи архитектурных решений сохраняют выбранный ответ и его компромиссы.

Специфическое для ИИ отличие в том, что некоторые атрибуты качества должны оцениваться вероятностно или эмпирически. «Ответы должны быть полезными» — слишком расплывчато. Производственное требование должно определять задачу, данные, популяцию пользователей, допустимые условия отказа, метод измерения и порог там, где это практически возможно.

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

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

Jira и Confluence — примеры инструментов, которые могут поддерживать это разделение при осознанном использовании: Confluence может хранить требования, архитектуру, решения, риски и обоснования; Jira может управлять действенными работами по реализации и их состоянием. Важен принцип прослеживаемости, а не бренд инструмента.

Свидетельства исходного проекта: Enterprise Aaasaasa 0.1

Enterprise Aaasaasa 0.1 объединяет архитектуру платформы, концепции SaaS/API, интернационализацию, интеграцию ИИ и структурированное управление проектом. Проект был намеренно организован так, чтобы требования, архитектура, поставка прототипа, валидация и закрытие были отдельными этапами, а не одной недифференцированной фазой реализации.

Архитектурное направление включает концепции мультиэкземплярности / мультибазовости вместе с возможностями API, CRUD, i18n и ИИ. Это важно для корпоративного ИИ, потому что границы тенантов или экземпляров, владение базами данных и прикладные сервисы должны оставаться явными при добавлении функций ИИ.

Структура проекта также рассматривала задержки в архитектуре, разрастание объёма и вопросы защиты ИИ/данных как проектные риски, а не обнаруживала их только во время реализации. Заинтересованные стороны включали технические, безопасностные, спонсорские/руководящие и внешние сервисные перспективы, что ближе к реальной кросс-функциональной природе корпоративного ИИ, чем прототип, ориентированный только на модель.

Таким образом, полезное свидетельство — это интеграция архитектуры и реализации: бизнес и структура проекта, этапы, риски, архитектура, работа над бэкендом/API, фронтендом/ИИ, валидация и закрытие рассматриваются как связанные обязанности. Этот паттерн воспроизводим, хотя сам проект не следует представлять как доказательство внешнего корпоративного внедрения.

Поддерживающие паттерны реализации из более широкой работы над платформой

Отдельная работа по реализации в более широкой платформе Aaasaasa даёт конкретные примеры границ, которые архитектура корпоративного ИИ должна сохранять: RBAC с областью тенанта в CMS, явное разделение провайдера/модели/среды выполнения/разрешений в Aaasaasa AI Client и поиск с приоритетом происхождения в Source of Truth Research Engine.

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

Как основные стандарты сочетаются друг с другом

Эти источники решают разные задачи. ISO/IEC 42001 не заменяет техническую архитектуру. ISO/IEC 23894 и NIST AI RMF не определяют один обязательный программный стек. EU AI Act — это закон, а не паттерн проектирования платформы. Архитектура должна переводить применимые организационные, риск-ориентированные и правовые требования в реализуемые границы системы и свидетельства.

Распространённые режимы отказа корпоративного ИИ

Распространённые заблуждения

Практическая последовательность решений по архитектуре корпоративного ИИ

Чек-лист архитектуры корпоративного ИИ

Крайние случаи и ограничения

Небольшая компания с одним сценарием использования ИИ с низким риском может не нуждаться в формальной функции архитектуры корпоративного ИИ. Те же принципы можно применять в лёгкой форме: чёткий владелец, одобренные данные, явный провайдер, базовая оценка, контроль доступа и операционная ответственность.

Высоко регулируемая организация может нуждаться в более строгом разделении, независимой валидации, формальных процессах соответствия, локальном хостинге или работе в изолированной среде. Эти контроли определяются сценарием использования и нормативной средой, а не словом «корпоративный».

Организация также может использовать в основном SaaS-продукты ИИ, а не создавать системы ИИ. Корпоративная архитектура всё равно важна, поскольку идентификация, доступ к данным, договорные условия, теневой ИИ, хранение, аудит и концентрация поставщиков остаются организационными вопросами.

Централизованная платформа не обязательна. Федеративная ответственность за платформу может быть оправдана, когда домены имеют существенно разные требования, при условии что ответственность за идентификацию, риски, инвентаризацию и совместимость на уровне предприятия остаётся согласованной.

Что могло бы изменить этот ответ?

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

Реализация также меняется по мере развития стандартов, регулирования и платформ ИИ. NIST AI RMF 1.0 в настоящее время пересматривается, EU AI Act имеет поэтапные даты применения, а возможности моделей и провайдеров продолжают быстро меняться. Поэтому архитектура корпоративного ИИ должна сохранять стабильные границы ответственности, рассматривая механизмы провайдеров и нормативные детали как версионируемые входные данные.

Связанные канонические знания

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

Генерация с дополненной выборкой (RAG) — лишь один из механизмов внутри этой архитектуры. RAG может улучшить доступ к корпоративным знаниям, но сам по себе не решает вопросы авторитетности данных, разрешений, управления или достоверности ответов.

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

Смежные корпоративные темы включают управление ИИ, частный ИИ, суверенный ИИ, изолированный ИИ, многоарендную архитектуру ИИ, RBAC против изоляции арендаторов, абстракцию поставщиков, маршрутизацию моделей и производственную архитектуру ИИ.

Часто задаваемые вопросы

Глоссарий

Заключение

Когда ИИ приходит в компанию, предприятие приобретает не просто новый программный компонент. Оно приобретает новый класс поведения и зависимостей, который пронизывает данные, идентификацию, поставщиков, бизнес-решения, безопасность, операции, управление и управление изменениями.

Архитектурный ответ — не централизовать всё. Он состоит в том, чтобы сделать ответственности явными: какие данные авторитетны, какие идентификации могут действовать, какие поставщики одобрены, какие средства контроля являются общими, какие решения остаются за предметной областью, как оценивается поведение, как обрабатываются инциденты и как система меняется со временем.

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

Первоисточники и актуальные рекомендации

Внешние стандарты, регулирование и актуальные рекомендации по архитектуре поставщиков ниже были проверены 8 октября 2026 года. Разделы, относящиеся к конкретному проекту, явно помечены как оригинальные доказательства проекта, и их не следует воспринимать как утверждения об общеотраслевых фактах.