[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:ru":3,"public-menus:all":38,"post:enterprise-ai-architecture-what-changes-when-ai-enters-a-company:ru":205,"related:post:enterprise-ai-architecture-what-changes-when-ai-enters-a-company:ru:1":3405},{"statusCode":4,"data":5,"message":37},200,{"tenantId":6,"lang":7,"defaultLang":8,"siteUrl":9,"contactEmail":10,"brandName":11,"logoUrl":12,"siteName":11,"siteDescription":13,"ogImage":10,"robotsIndex":14,"socialLinks":10,"reservedSlugs":10,"seoPolicy":15},"stajic","ru","de","https:\u002F\u002Fstajic.de",null,"Stajic Platform","\u002FLogo_Planet.svg","Stajic Portal",true,{"branding":16,"relatedContent":17,"crossDomainLinks":18},{"logoUrl":12},{"enabled":14},[19,22,25,28,31,34],{"url":20,"label":21,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Ffigure.rocks","figure.rocks",{"url":23,"label":24,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Floving.rocks","loving.rocks",{"url":26,"label":27,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.com","bazify.com",{"url":29,"label":30,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.de","bazify.de",{"url":32,"label":33,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.at","bazify.at",{"url":35,"label":36,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.ba","bazify.ba","Portal settings resolved",[39,45],{"id":40,"name":41,"location":42,"isActive":14,"isDefault":43,"items":44},1,"main-navigation","header",false,[],{"id":46,"name":47,"location":48,"isActive":14,"isDefault":14,"items":49},4,"main-menu","sidebar",[50,66,79,93,103,118,133],{"id":51,"title":52,"url":60,"target":61,"icon":62,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":64,"portfolioId":10,"children":65},"item-18",{"de":53,"en":54,"es":55,"fr":56,"it":54,"ru":57,"sr":58,"zh":59},"Startseite","Home","Inicio","Accueil","Главная","Почетна","首页","\u002Ffull-stack-web-developer-munich-performance-seo-and-maintainable-builds","_self","i-lucide-home","page",111,[],{"id":67,"title":68,"url":75,"target":61,"icon":76,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":77,"portfolioId":10,"children":78},"item-22",{"de":69,"en":69,"es":70,"fr":69,"it":71,"ru":72,"sr":73,"zh":74},"Vision","Visión","Visione","Видение","Визија","想象","\u002Fueber-uns-webdesign-muenchen-webaplikation","i-lucide-eye",113,[],{"id":80,"title":81,"url":89,"target":61,"icon":90,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":91,"portfolioId":10,"children":92},"item-19",{"de":82,"en":83,"es":84,"fr":83,"it":85,"ru":86,"sr":87,"zh":88},"Leistungen","Services","Servicios","Servizi","Услуги","Услуге","服务","\u002Fservices-dienstleistungen-muenchen","i-lucide-wrench",116,[],{"id":94,"title":95,"url":99,"target":61,"icon":100,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":101,"portfolioId":10,"children":102},"item-23",{"de":96,"en":96,"es":96,"fr":96,"it":96,"ru":97,"sr":97,"zh":98},"Blog","Блог","博客","\u002Fblog","i-lucide-book-open",112,[],{"id":104,"title":105,"url":114,"target":61,"icon":115,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":116,"portfolioId":10,"children":117},"item-32",{"de":106,"en":107,"es":108,"fr":109,"it":110,"ru":111,"sr":112,"zh":113},"Neue Technologien","New Technologies","Nuevas tecnologías","Nouvelles technologies","Nuove tecnologie","Новые технологии","Нове технологије","新技术！","\u002Fneue-webtechnologien","i-lucide-sparkles",122,[],{"id":119,"title":120,"url":129,"target":61,"icon":130,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":131,"portfolioId":10,"children":132},"item-20",{"de":121,"en":122,"es":123,"fr":124,"it":125,"ru":126,"sr":127,"zh":128},"Kontakt","Contact us!","Contacto","Contact","Contatto","Контакт","Контактирајте нас","联系我们！","\u002Fcontact","i-lucide-mail",115,[],{"id":134,"title":135,"url":144,"target":61,"icon":145,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":147},"item-21",{"de":136,"en":137,"es":138,"fr":139,"it":140,"ru":141,"sr":142,"zh":143},"Unsere Arbeit","Our Work","Nuestro trabajo","Nos réalisations","I nostri lavori","Наши работы","Наши радови","文件夹","\u002Fportfolio","i-lucide-briefcase",114,[148,161,175,181,193],{"id":149,"title":150,"url":144,"target":61,"icon":159,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":160},"item-24",{"de":151,"en":152,"es":153,"fr":154,"it":155,"ru":156,"sr":157,"zh":158},"Alle Projekte","All Projects","Todos los proyectos","Tous les projets","Tutti i progetti","Все проекты","Сви пројекти","所有项目","i-lucide-grid-3x3",[],{"id":162,"title":163,"url":171,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":174},"item-29",{"de":164,"en":165,"es":166,"fr":167,"it":168,"ru":169,"sr":170,"zh":143},"Local Roots, Global Reach","Local Roots - Global Reach","Empresa local ","Entreprise locale","Azienda locale","Местная компания","Локално предузеће глобално тржиште","\u002Fportfolio\u002Flocal-roots-global-reach-communication-media-systems-for-modern-business","i-lucide-folder","custom",[],{"id":176,"title":177,"url":179,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":180},"item-28",{"de":178,"en":178,"es":178,"fr":178,"it":178,"ru":178,"sr":178,"zh":178},"Solr Suggester","\u002Fportfolio\u002Fsolr-fuzzy-suggester-und-solr-infix-suggester-abfrage-ueber-ajax-und-filterung",[],{"id":182,"title":183,"url":191,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":192},"item-27",{"de":184,"en":185,"es":186,"fr":187,"it":188,"ru":189,"sr":190,"zh":185},"Firmenwebseite SEO","Company Website SEO","Sitio web corporativo SEO","Site web d’entreprise SEO","Sito web aziendale SEO","Корпоративный сайт SEO","Пословна веб-страница SEO","\u002Fportfolio\u002Fseo-sem-branding-mobile-webseite-muenchen",[],{"id":194,"title":195,"url":203,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":204},"item-31",{"de":196,"en":197,"es":198,"fr":199,"it":200,"ru":201,"sr":202,"zh":197},"Digitalisierungsportal","Digitalization Portal","Portal de digitalización","Portail de numérisation","Portale di digitalizzazione","Портал цифровизации","Портал за дигитализацију","\u002Fportfolio\u002Fdigitalisierungsportal-archiv-museum-bibliothek-ead-lido-mets-mods",[],{"statusCode":4,"data":206,"message":3404},{"id":207,"title":208,"slug":209,"content":210,"contentJson":211,"excerpt":1562,"featuredImage":1563,"featuredImageAlt":1564,"featuredImageCaption":10,"featuredImageTitle":10,"featuredImageCopyright":10,"featuredImageAuthor":10,"featuredImageSourceUrl":10,"featuredImageLicense":10,"featuredImageIsAiGenerated":43,"status":1565,"publishedAt":1566,"createdAt":1567,"updatedAt":1568,"seoLocalePaths":1569,"categories":1578,"author":1594,"translations":1599},"485","Архитектура ИИ на предприятии: что меняется, когда ИИ приходит в компанию","enterprise-ai-architecture-what-changes-when-ai-enters-a-company","\u003Cp>Архитектура корпоративного ИИ — это общеорганизационная архитектура, необходимая, когда ИИ становится частью реальных систем, данных, решений и операций компании. Модель — лишь один из компонентов. Как только ИИ подключается к корпоративным данным, идентичностям, разрешениям, бизнес-процессам, внешним поставщикам и производственным системам, архитектура должна также определять полномочия над данными, границы доступа, владение рисками, зависимости от поставщиков, возможность аудита, оценку, управление жизненным циклом, соответствие требованиям и операционную ответственность. Таким образом, корпоративный ИИ отличается и от отдельного ИИ-решения, и от общей ИИ-платформы: он координирует, как множество систем с поддержкой ИИ встраиваются в более широкую организацию.\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--info my-6 rounded-xl border p-5 border-blue-300 bg-blue-50 dark:border-blue-900 dark:bg-blue-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Прямой ответ\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>Что меняется, когда ИИ приходит в компанию?\u003C\u002Fstrong> Существующие обязанности корпоративной архитектуры расширяются и включают вероятностное поведение моделей, новые потоки данных, поиск и обоснование, зависимости от моделей и поставщиков, оценку, специфичную для ИИ, полномочия агентов и инструментов, жизненный цикл моделей и промптов, управление рисками ИИ, обязательства по прозрачности и новые режимы операционных сбоев. Архитектура должна связать эти вопросы с существующими структурами компании в области идентичности, безопасности, данных, закупок, поставки и управления, а не создавать параллельную «вселенную ИИ».\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Caside class=\"editorjs-callout editorjs-callout--warning my-6 rounded-xl border p-5 border-amber-300 bg-amber-50 dark:border-amber-900 dark:bg-amber-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Корпоративный ИИ — это не «чат-бот побольше»\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Чат-бот может быть пользовательским интерфейсом. Архитектура корпоративного ИИ — это система границ за ним: к каким данным ИИ может получить доступ, какой источник является авторитетным, кто может использовать какую возможность, могут ли внешние поставщики получать данные, какие действия может выполнять агент, как оцениваются выходные данные, что должно регистрироваться, кто отвечает за инциденты и как изменения утверждаются и откатываются.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Caside class=\"editorjs-callout editorjs-callout--note my-6 rounded-xl border p-5 border-gray-300 bg-gray-50 dark:border-gray-700 dark:bg-gray-900\u002F40\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Примечание об актуальности источников — 8 октября 2026 г.\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Архитектурные принципы в этой статье задуманы как стабильные. Регулирование, стандарты и возможности поставщиков зависят от версии. ISO\u002FIEC 42001:2023 и ISO\u002FIEC 23894:2023 — действующие опубликованные стандарты. NIST заявляет, что AI RMF 1.0 пересматривается. Согласно текущему консолидированному тексту Закона ЕС об ИИ, Регламент в целом применяется с 2 августа 2026 года, тогда как отдельные положения о высоком риске имеют более поздние даты применения. Юридическую классификацию всегда необходимо проверять по действующему законодательству и конкретному случаю использования.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cnav class=\"editorjs-toc\" data-editorjs-toc=\"true\" aria-label=\"Содержание\">\u003Cstrong class=\"editorjs-toc__title\">Содержание\u003C\u002Fstrong>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-0\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-6\" class=\"editorjs-toc__link\">Что на самом деле означает архитектура корпоративного ИИ\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-11\" class=\"editorjs-toc__link\">Самый простой пример\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-16\" class=\"editorjs-toc__link\">Где заканчивается простой пример\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-19\" class=\"editorjs-toc__link\">Что меняется в архитектуре, когда ИИ приходит в предприятие\u003C\u002Fa>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-1\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-20\" class=\"editorjs-toc__link\">1. Бизнес-владелец становится частью технической архитектуры\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-23\" class=\"editorjs-toc__link\">2. Доступа к данным недостаточно — необходимо определить полномочия на данные\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-28\" class=\"editorjs-toc__link\">3. Идентичность становится многоуровневой\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-32\" class=\"editorjs-toc__link\">4. Разрешения смещаются от доступа к контенту к полномочиям на действия\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-35\" class=\"editorjs-toc__link\">5. Поставщик ИИ становится зависимостью предприятия\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-39\" class=\"editorjs-toc__link\">6. Риск ИИ становится процессом жизненного цикла\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-43\" class=\"editorjs-toc__link\">7. Управление становится операционной системой, а не PDF-политикой\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-46\" class=\"editorjs-toc__link\">8. Оценка становится производственным контролем\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-50\" class=\"editorjs-toc__link\">9. Наблюдаемость должна включать поведение, данные и контекст модели\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-53\" class=\"editorjs-toc__link\">10. Компоненты ИИ нуждаются в явном владении жизненным циклом\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-56\" class=\"editorjs-toc__link\">11. Реагирование на инциденты должно учитывать специфические для ИИ режимы отказа\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-59\" class=\"editorjs-toc__link\">Корпоративный ИИ создаёт кросс-функциональную ответственность\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-62\" class=\"editorjs-toc__link\">Практическая модель архитектуры корпоративного ИИ\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-66\" class=\"editorjs-toc__link\">Представляйте корпоративный ИИ как потоки данных и полномочий, а не как блоки\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-68\" class=\"editorjs-toc__link\">Предприятию нужен реестр ИИ, прежде чем оно сможет управлять ИИ\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-71\" class=\"editorjs-toc__link\">Управление ИИ и архитектура корпоративного ИИ связаны, но не совпадают\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-73\" class=\"editorjs-toc__link\">Регулирование становится входными данными архитектуры\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-78\" class=\"editorjs-toc__link\">Закупки и архитектура становятся связанными\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-81\" class=\"editorjs-toc__link\">Архитектура предприятия решает, сколько контроля над ИИ действительно требует требование\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-84\" class=\"editorjs-toc__link\">ИИ превращает управление изменениями в поведенческую проблему\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-87\" class=\"editorjs-toc__link\">ИИ предприятия всё ещё нужны NFR и ADR\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-91\" class=\"editorjs-toc__link\">Архитектура корпоративного ИИ должна быть связана с реализацией\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-94\" class=\"editorjs-toc__link\">Свидетельства исходного проекта: Enterprise Aaasaasa 0.1\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-101\" class=\"editorjs-toc__link\">Поддерживающие паттерны реализации из более широкой работы над платформой\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-104\" class=\"editorjs-toc__link\">Как основные стандарты сочетаются друг с другом\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-107\" class=\"editorjs-toc__link\">Распространённые режимы отказа корпоративного ИИ\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-109\" class=\"editorjs-toc__link\">Распространённые заблуждения\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-111\" class=\"editorjs-toc__link\">Практическая последовательность решений по архитектуре корпоративного ИИ\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-113\" class=\"editorjs-toc__link\">Чек-лист архитектуры корпоративного ИИ\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-115\" class=\"editorjs-toc__link\">Крайние случаи и ограничения\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-120\" class=\"editorjs-toc__link\">Что могло бы изменить этот ответ?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-123\" class=\"editorjs-toc__link\">Связанные канонические знания\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-130\" class=\"editorjs-toc__link\">Часто задаваемые вопросы\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-132\" class=\"editorjs-toc__link\">Глоссарий\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-134\" class=\"editorjs-toc__link\">Заключение\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-138\" class=\"editorjs-toc__link\">Первоисточники и актуальные рекомендации\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fnav>\n\u003Ch2 id=\"section-6\">Что на самом деле означает архитектура корпоративного ИИ\u003C\u002Fh2>\n\u003Cp>Архитектура корпоративного ИИ описывает, как возможности ИИ интегрируются в существующую организацию, не нарушая границы, которые уже делают корпоративные системы управляемыми: бизнес-ответственность, идентичность, авторизацию, классификацию данных, ответственность за систему-источник, управление изменениями, закупки, аудит, непрерывность и операции.\u003C\u002Fp>\n\u003Cp>Корпоративный архитектор не заменяет архитектора ИИ-решения или архитектора ИИ-платформы. Корпоративный масштаб задает другой вопрос: как множество ИИ-решений и общих возможностей ИИ вписываются в целевую архитектуру, политики, ландшафт данных, модель рисков и операционную модель компании?\u003C\u002Fp>\n\u003Cp>Это делает архитектуру корпоративного ИИ дисциплиной координации между технологиями и организацией. Технически хорошая интеграция модели все равно может быть провалом корпоративной архитектуры, если она создает теневые потоки данных, дублирует идентичность, обходит закупки, не поддается аудиту, не имеет владельца или не может быть безопасно изменена.\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Архитектура ИИ-решения, платформы и корпоративного ИИ — это разные масштабы\u003C\u002Fh3>\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left dark:border-gray-700 dark:bg-gray-900\">\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Архитектура ИИ-решения\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Архитектура ИИ-платформы\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Архитектура корпоративного ИИ\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Основной масштаб\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Основной вопрос\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Фокус ответственности\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Условие успеха\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-11\">Самый простой пример\u003C\u002Fh2>\n\u003Cp>Компания начинает с одного внутреннего помощника по документам. Первая версия ищет по утвержденным документам и отправляет найденный контекст языковой модели. На уровне решения это может выглядеть просто.\u003C\u002Fp>\n\u003Cp>Затем вторая команда хочет ИИ для поддержки клиентов. Третья хочет агента, который может обновлять тикеты. Финансовый отдел хочет анализ документов. HR хочет внутреннего помощника. Разработчики хотят агентов для программирования. Внезапно у компании появляются несколько поставщиков, несколько классов данных, разные группы пользователей, пересекающиеся индексы поиска, разные правила логирования, новые разрешения для инструментов, дублирующиеся секреты и неясная ответственность.\u003C\u002Fp>\n\u003Cp>В этот момент вопрос уже не в том, «работает ли помощник?» Корпоративный вопрос становится таким: какие возможности утверждены, кто ими владеет, какие данные могут пересекать какую границу, как обеспечиваются идентичности и разрешения, какие поставщики допустимы, что должно проходить аудит и как организация может менять модели или поставщиков, не теряя контроля?\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">От изолированной функции ИИ к корпоративной архитектуре\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. Изолированный сценарий использования\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Одна команда подключает одну модель к одному рабочему процессу и подтверждает локальную ценность.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. Появляются общие зависимости\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Нескольким командам нужны поставщики, доступ к моделям, поиск, идентичность, секреты, наблюдаемость и оценка.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. Пересекаются корпоративные границы\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">ИИ затрагивает регулируемые данные, системы-источники, внешних поставщиков, привилегированные действия и бизнес-решения.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. Ответственность должна стать явной\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Бизнесу, архитектуре, данным, безопасности, юридическому отделу и комплаенсу, закупкам и операциям нужны определенные обязанности.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. Жизненный цикл становится организационным\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Изменения моделей, промптов, поставщиков и новые возможности агентов становятся управляемыми изменениями, а не локальными правками разработчиков.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. Архитектура становится повторяемой\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Организация устанавливает многоразовые шаблоны, записи решений, контроли, исключения и этапы проверки для новых ИИ-нагрузок.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-16\">Где заканчивается простой пример\u003C\u002Fh2>\n\u003Cp>Корпоративная архитектура не означает, что каждый компонент ИИ должен быть централизован. Некоторые возможности следует сделать общими; другие должны оставаться в ведении домена. Финансы, HR, инженерия и поддержка клиентов могут обоснованно требовать разных границ данных, поставщиков, критериев оценки и правил человеческого утверждения.\u003C\u002Fp>\n\u003Cp>Таким образом, корпоративная цель — не одна модель, одна векторная база данных или один универсальный помощник. Цель — согласованная архитектура с явной вариативностью: общие политики и многоразовые возможности там, где они снижают риск и дублирование, плюс контролируемые исключения там, где бизнес- или регуляторные требования различаются.\u003C\u002Fp>\n\u003Ch2 id=\"section-19\">Что меняется в архитектуре, когда ИИ приходит в предприятие\u003C\u002Fh2>\n\u003Ch3 id=\"section-20\">1. Бизнес-владелец становится частью технической архитектуры\u003C\u002Fh3>\n\u003Cp>Традиционным приложениям уже нужны бизнес-владельцы. ИИ делает это требование более заметным, потому что приемлемое поведение нельзя определить только через время безотказной работы и функциональную корректность. Кто-то должен отвечать за предполагаемое использование, недопустимое использование, качество выходных данных, путь эскалации и последствия неверных или неподходящих результатов.\u003C\u002Fp>\n\u003Cp>Команда модели не может в одиночку решить, приемлем ли ответ для HR, финансов, юридического отдела или использования с взаимодействием с клиентами. Поэтому архитектура ИИ предприятия связывает технический дизайн с явно определённой бизнес-способностью, ответственным владельцем, группой пользователей и контекстом принятия решений.\u003C\u002Fp>\n\u003Ch3 id=\"section-23\">2. Доступа к данным недостаточно — необходимо определить полномочия на данные\u003C\u002Fh3>\n\u003Cp>ИИ предприятия часто объединяет операционные базы данных, документы, поисковые индексы, векторные хранилища, хранилища данных, SaaS-системы и внешние знания. Архитектура должна различать, где хранится информация, и какой источник является авторитетным для данного утверждения или действия.\u003C\u002Fp>\n\u003Cp>Векторный индекс может улучшить поиск, но не должен незаметно становиться системой учёта компании. Ответ модели может суммировать запись ERP, но не должен заменять ERP как авторитетный источник. Кэшированный контекст может улучшить задержку, но становится небезопасным, когда меняются разрешения или базовое бизнес-состояние.\u003C\u002Fp>\n\u003Cp>Поэтому ИИ предприятия нуждается в происхождении, актуальности, классификации источников, распространении авторизации и правилах аннулирования в дополнение к обычной интеграции данных.\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--success my-6 rounded-xl border p-5 border-emerald-300 bg-emerald-50 dark:border-emerald-900 dark:bg-emerald-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Правило данных предприятия\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>Система ИИ может преобразовывать, извлекать и рассуждать о данных предприятия, не становясь авторитетом для этих данных.\u003C\u002Fstrong> Архитектура должна сохранять путь обратно к авторитетному источнику, когда вариант использования требует доказательств, проверки или последующих действий.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch3 id=\"section-28\">3. Идентичность становится многоуровневой\u003C\u002Fh3>\n\u003Cp>У ИИ предприятия больше идентичностей, чем у человека-пользователя. Запрос может включать идентичность пользователя, идентичность приложения, идентичность сервиса, идентичность агента, учётные данные провайдера, учётные данные инструмента и контекст арендатора или организации.\u003C\u002Fp>\n\u003Cp>Эти идентичности не следует сводить к одному общему API-ключу. Авторизация должна оставаться привязанной к правильному субъекту, а привилегированные инструменты должны получать только те полномочия, которые требуются для текущей операции.\u003C\u002Fp>\n\u003Cp>Для агентных систем это становится особенно важным: модель может предложить действие, но среда выполнения должна решить, разрешено ли запрашивающей идентичности его выполнить. Возможность модели — это не авторизация.\u003C\u002Fp>\n\u003Ch3 id=\"section-32\">4. Разрешения смещаются от доступа к контенту к полномочиям на действия\u003C\u002Fh3>\n\u003Cp>Помощнику только для чтения в основном нужен контролируемый доступ к информации. Агент предприятия может создавать заявки, изменять записи, отправлять сообщения, запускать рабочие процессы или управлять внешними системами. Это вводит другой класс риска, потому что система может изменять состояние, а не просто описывать его.\u003C\u002Fp>\n\u003Cp>Архитектура должна разделять возможности чтения, записи, утверждения и администрирования; определять точки участия человека там, где последствия это оправдывают; и сохранять журнал аудита, который определяет, что было запрошено, что было одобрено и что фактически изменилось.\u003C\u002Fp>\n\u003Ch3 id=\"section-35\">5. Поставщик ИИ становится зависимостью предприятия\u003C\u002Fh3>\n\u003Cp>Вызов API модели — это также отношения с поставщиком. Архитектура может зависеть от доступности поставщика, условий обслуживания, условий обработки данных, поддерживаемых регионов, жизненного цикла модели, квот, ценообразования, совместимости API, средств безопасности и уведомлений об изменениях.\u003C\u002Fp>\n\u003Cp>Это означает, что выбор провайдера — не только решение на основе бенчмарков. Закупки, безопасность, конфиденциальность, юридическая экспертиза, планирование непрерывности и стратегия выхода могут стать входными данными для архитектуры.\u003C\u002Fp>\n\u003Cp>Абстракция провайдера может снизить связанность, но только там, где базовые возможности действительно переносимы. Использование инструментов, структурированный вывод, ограничения контекста, мультимодальность, средства контроля безопасности, тонкая настройка и функции хостинговых агентов могут существенно различаться у разных провайдеров.\u003C\u002Fp>\n\u003Ch3 id=\"section-39\">6. Риск ИИ становится процессом жизненного цикла\u003C\u002Fh3>\n\u003Cp>Риск ИИ не исчерпывается одним одобрением перед запуском. Модель, промпт, корпус для поиска, набор инструментов, провайдер, популяция пользователей и окружающий бизнес-процесс могут измениться после развёртывания. Профиль риска меняется вместе с ними.\u003C\u002Fp>\n\u003Cp>ISO\u002FIEC 23894:2023 явно рассматривает интеграцию управления рисками ИИ в организационные деятельности и функции. NIST AI RMF аналогично определяет управление рисками на протяжении жизненного цикла. Поэтому архитектура предприятия должна сделать анализ рисков частью изменений и операций, а не изолированным документом о соответствии.\u003C\u002Fp>\n\u003Cp>Риск также должен быть пропорциональным. Ассистент для суммаризации и автономная система, изменяющая производственные записи, не должны получать одинаковые меры контроля только потому, что обе используют LLM.\u003C\u002Fp>\n\u003Ch3 id=\"section-43\">7. Управление становится операционной системой, а не PDF-политикой\u003C\u002Fh3>\n\u003Cp>ISO\u002FIEC 42001:2023 определяет требования к созданию, внедрению, поддержанию и постоянному улучшению системы управления ИИ. Архитектурное следствие важно: управление должно связывать политику с реальными реестрами, ответственностью, процессами, средствами контроля, доказательствами, проверками и циклами улучшения.\u003C\u002Fp>\n\u003Cp>Корпоративная политика в области ИИ, не связанная с одобрением провайдеров, идентификацией, журналированием, управлением изменениями, оценкой и реагированием на инциденты, имеет ограниченный архитектурный эффект. Организации нужны механизмы, делающие политику исполнимой или хотя бы наблюдаемой.\u003C\u002Fp>\n\u003Ch3 id=\"section-46\">8. Оценка становится производственным контролем\u003C\u002Fh3>\n\u003Cp>Традиционное приёмочное тестирование предполагает, что один и тот же вход обычно даёт один и тот же детерминированный результат. Генеративный ИИ может быть недетерминированным, чувствительным к контексту и зависящим от изменяющихся внешних знаний. Поэтому производственная приёмка требует оценок, специфичных для задачи, наборов регрессионных тестов и наблюдаемых порогов, а не только модульных тестов.\u003C\u002Fp>\n\u003Cp>Платформа может предоставить переиспользуемую инфраструктуру оценки, но предприятию всё равно необходимо владеть эталонными данными предметной области и контрольными точками выпуска. Центральная команда по ИИ не может придумать правильный ответ для каждой бизнес-области.\u003C\u002Fp>\n\u003Cp>Изменения модели, промпта, поиска и инструментов должны быть прослеживаемы к доказательствам оценки там, где изменение может существенно повлиять на поведение вывода.\u003C\u002Fp>\n\u003Ch3 id=\"section-50\">9. Наблюдаемость должна включать поведение, данные и контекст модели\u003C\u002Fh3>\n\u003Cp>Показателей CPU, памяти и частоты ошибок HTTP недостаточно для рабочих нагрузок ИИ. Производственная наблюдаемость может потребовать идентификаторов модели и провайдера, задержки, использования токенов, стоимости, результатов поиска, вызовов инструментов, поведения отказов, оценок, событий безопасности и классификаций сбоев.\u003C\u002Fp>\n\u003Cp>В то же время телеметрия ИИ может содержать конфиденциальные данные. Журналы промптов и ответов могут стать теневым хранилищем данных. Поэтому архитектура предприятия должна определить, что можно логировать, как это редактируется, кто имеет к этому доступ, как долго это хранится и когда детальная трассировка должна быть отключена.\u003C\u002Fp>\n\u003Ch3 id=\"section-53\">10. Компоненты ИИ нуждаются в явном владении жизненным циклом\u003C\u002Fh3>\n\u003Cp>Модели могут быть переименованы, заменены, выведены из эксплуатации или изменены провайдерами. Модели эмбеддингов могут сделать стратегию индексации недействительной. Шаблоны промптов и системные инструкции могут изменить поведение. Среды выполнения агентов и протоколы могут развиваться. Внешние инструменты могут изменять свои схемы и разрешения.\u003C\u002Fp>\n\u003Cp>Корпоративная архитектура должна определить, кто обнаруживает эти изменения, кто их тестирует, кто их утверждает, как уведомляются потребители, как работает откат и какие доказательства требуются, прежде чем новая версия станет версией по умолчанию.\u003C\u002Fp>\n\u003Ch3 id=\"section-56\">11. Реагирование на инциденты должно учитывать специфические для ИИ режимы отказа\u003C\u002Fh3>\n\u003Cp>Инцидент, связанный с ИИ, может быть сбоем у поставщика, утечкой данных, путём внедрения через промпт, отказом авторизации, загрязнением поисковой выдачи, неожиданным поведением модели, небезопасным выполнением инструментов, скачком затрат, устаревшими знаниями, регрессией оценки или изменением поведения внешней модели.\u003C\u002Fp>\n\u003Cp>Поэтому корпоративный регламент действий должен включать не только «перезапустить сервис». Он может потребовать отключения маршрута модели, отзыва доступа к инструментам, заморозки корпуса, изменения версии промпта, отключения возможности агента, смены поставщика, эскалации к владельцу домена или сохранения трассировок для расследования.\u003C\u002Fp>\n\u003Ch2 id=\"section-59\">Корпоративный ИИ создаёт кросс-функциональную ответственность\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Аспект\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Типичный корпоративный владелец или участник\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Вопрос архитектуры\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Бизнес-использование\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Бизнес-владелец \u002F владелец продукта\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Какое решение или рабочий процесс ИИ разрешено поддерживать или автоматизировать?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Архитектура решения\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Архитектор ИИ \u002F архитектор решений\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Как конкретная рабочая нагрузка удовлетворяет свои функциональные требования и требования к качеству?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Общие возможности ИИ\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Платформа ИИ \u002F платформенная инженерия\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Какие переиспользуемые сервисы моделей, поиска, агентов и наблюдаемости предоставляются?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Корпоративная согласованность\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Корпоративная архитектура\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Как системы ИИ вписываются в целевую архитектуру, стандарты, шаблоны интеграции и организационную ответственность?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Полномочия по данным\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Владелец данных \u002F владелец домена\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Какие данные являются авторитетными, актуальными, разрешёнными и достаточно управляемыми?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Идентификация и безопасность\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">IAM \u002F архитектура безопасности\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Какие идентификаторы могут получать доступ к каким данным и выполнять какие действия?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Риски и соответствие\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Риски \u002F юридический отдел \u002F комплаенс \u002F приватность\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Какие обязательства, запрещённые виды использования, меры контроля и доказательства применяются к этому сценарию?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Зависимость от поставщика\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Закупки \u002F управление поставщиками \u002F архитектура\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Какие контрактные, операционные риски и риски выхода возникают из-за поставщика?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Эксплуатация\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">SRE \u002F эксплуатация \u002F владелец платформы\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Как система мониторится, поддерживается, деградирует, восстанавливается и изменяется?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Принятие доменом\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Бизнес-специалисты \u002F специалисты домена\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Что считается правильным, безопасным или полезным результатом в этом домене?\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Caside class=\"editorjs-callout editorjs-callout--warning my-6 rounded-xl border p-5 border-amber-300 bg-amber-50 dark:border-amber-900 dark:bg-amber-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Матрица RACI сама по себе не является архитектурой\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Матрицы ответственности полезны только тогда, когда они связаны с реальными границами систем, утверждениями, владением данными, интерфейсами, регламентами действий и процессами изменений. Корпоративный ИИ требует подотчётной ответственности, которая может быть прослежена до технических мер контроля и операционных действий.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-62\">Практическая модель архитектуры корпоративного ИИ\u003C\u002Fh2>\n\u003Caside class=\"editorjs-callout editorjs-callout--note my-6 rounded-xl border p-5 border-gray-300 bg-gray-50 dark:border-gray-700 dark:bg-gray-900\u002F40\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Предлагаемая многоуровневая модель\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Следующая модель представляет собой практический синтез для рассуждения об архитектуре корпоративного ИИ. Она не представлена как стандарт ISO или NIST. Её цель — сделать кросс-организационные границы явными.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Уровень\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Основная ответственность\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Бизнес и политика\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Утверждённые сценарии использования, подотчётные владельцы, аппетит к риску, запрещённые виды использования, человеческая подотчётность, бизнес-приёмка.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Идентификация и полномочия\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Идентификаторы пользователей\u002Fсервисов\u002Fагентов, роли, границы арендатора или организации, привилегированные действия, пути утверждения.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Корпоративные данные\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Системы учёта, источники документов, данные как продукты, происхождение, классификация, хранение, актуальность и доступ.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Платформа ИИ\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Доступ к поставщику\u002Fмодели, примитивы поиска, среды выполнения агентов, брокеры инструментов, инфраструктура оценки, наблюдаемость, квоты и секреты.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Решения на основе ИИ\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Рабочие процессы домена, промпты\u002Fинструкции, поиск в домене, бизнес-логика, критерии приёмки и пользовательский опыт.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Интеграция и инструменты\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">API, корпоративные приложения, рабочие процессы, обмен сообщениями, файловые системы, внешние сервисы и выполнение действий.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Риски и управление\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Инвентаризация, оценка, доказательства соответствия, управление исключениями, утверждение моделей\u002Fпоставщиков, проверка и аудит.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Эксплуатация и жизненный цикл\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Развёртывание, мониторинг, инциденты, релизы, изменения моделей\u002Fпоставщиков, вывод из эксплуатации, откат и непрерывность.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>Архитектура наиболее сильна, когда каждый уровень может заявить как свои обязанности, так и то, за что он не отвечает. Например, платформа ИИ может обеспечивать соблюдение политики поставщика и собирать трассировки, не становясь источником истины для данных HR. Решение может определять промпты домена, не владея корпоративной IAM. Бизнес-владелец может утвердить сценарий использования, и при этом не ожидается, что он будет эксплуатировать шлюз вывода.\u003C\u002Fp>\n\u003Ch2 id=\"section-66\">Представляйте корпоративный ИИ как потоки данных и полномочий, а не как блоки\u003C\u002Fh2>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Значимый запрос к корпоративному ИИ\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. Бизнес-контекст\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Пользователь запрашивает задачу в рамках утверждённого сценария использования с подотчётным бизнес-владельцем.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. Идентификация и авторизация\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Система определяет пользователя, приложение, сервис и границы арендатора или организации до предоставления привилегированного доступа.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. Получение авторитетных данных\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Решение читает или извлекает только источники, разрешённые для текущего идентификатора и задачи.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. Обработка ИИ\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Утверждённая модель\u002Fпоставщик обрабатывает минимально необходимый контекст в соответствии с определёнными правилами маршрутизации и обработки данных.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. Граница инструмента или действия\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Любое действие, изменяющее состояние, независимо авторизуется и может требовать одобрения человеком в зависимости от последствий.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. Валидация\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Результат проверяется на соответствие критериям приёмки, доказательствам или правилам безопасности, специфичным для решения.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">7\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">7. Аудит и наблюдаемость\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Разрешённые метаданные, решения, маршруты, вызовы инструментов и результаты записываются без создания неконтролируемых журналов конфиденциальных данных.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">8\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">8. Обратная связь и жизненный цикл\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Сбои и результаты оценки питают изменения моделей, промптов, данных, политик и процессов через контролируемое управление изменениями.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-68\">Предприятию нужен реестр ИИ, прежде чем оно сможет управлять ИИ\u003C\u002Fh2>\n\u003Cp>Организации не могут управлять системами ИИ, которые они не могут идентифицировать. Корпоративная архитектура должна вести реестр на уровне, полезном для принятия решений, а не просто список названий моделей.\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Поле реестра\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Почему это важно\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Сценарий использования и владелец\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Связывает технологию с подотчётной бизнес-целью.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Пользователи и затронутые стороны\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Определяет, кто взаимодействует с системой или на кого она влияет.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Модель\u002Fпоставщик\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Идентифицирует внешнюю зависимость, возможности и риск жизненного цикла.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Источники данных\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Поддерживает проверку полномочий, приватности, классификации и происхождения.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Место развёртывания\u002Fвыполнения\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Уточняет место обработки, подключение и операционный контроль.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Инструменты\u002Fдействия\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Показывает, может ли ИИ изменять внешнее состояние и с какими последствиями.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Человеческий надзор\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Фиксирует, где требуется проверка, утверждение или эскалация.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Риск\u002Fклассификация\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Связывает систему с организационными и регуляторными мерами контроля.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Доказательства оценки\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Показывает, что было протестировано и при каких условиях валидности.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Текущая версия\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Позволяет проследить инциденты и регрессии до фактического развёрнутого состояния.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Состояние жизненного цикла\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Предложено, экспериментально, утверждено, в производстве, ограничено, устарело или выведено из эксплуатации.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-71\">Управление ИИ и архитектура корпоративного ИИ связаны, но не совпадают\u003C\u002Fh2>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Управление против архитектуры\u003C\u002Fh3>\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left dark:border-gray-700 dark:bg-gray-900\">\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Управление ИИ\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Архитектура корпоративного ИИ\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Цель\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Пример\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Сбой при изоляции\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-73\">Регулирование становится входными данными архитектуры\u003C\u002Fh2>\n\u003Cp>Для организаций, работающих в Европейском союзе, AI Act может создавать требования, влияющие на проектирование систем, документацию, прозрачность, управление и операционные процессы. Влияние на архитектуру зависит от роли организации в цепочке создания ценности ИИ и конкретной классификации системы; не все системы ИИ имеют одинаковые обязательства.\u003C\u002Fp>\n\u003Cp>По состоянию на 8 октября 2026 года в текущем консолидированном тексте указано, что Регламент в целом применяется с 2 августа 2026 года. Правила управления и обязательства для моделей ИИ общего назначения начали применяться раньше, а отдельные положения для систем высокого риска имеют более поздние сроки. Комиссия также начала обеспечивать соблюдение новых требований к прозрачности с 2 августа 2026 года для соответствующих интерактивных систем и систем синтетического контента.\u003C\u002Fp>\n\u003Cp>Урок архитектуры предприятия не в том, чтобы «встроить соответствие требованиям в модель». Он в том, чтобы сделать классификацию, роль поставщика\u002Fразвёртывающего, документацию, прозрачность, надзор, журналирование и доказательства изменений отслеживаемыми до системы, которая фактически реализует сценарий использования.\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--note my-6 rounded-xl border p-5 border-gray-300 bg-gray-50 dark:border-gray-700 dark:bg-gray-900\u002F40\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Правовая сфера зависит от конкретного сценария использования\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Эта статья описывает архитектурные последствия, а не юридическую консультацию. Архитектура ИИ предприятия должна сохранять информацию, необходимую юридическим специалистам и специалистам по соответствию для классификации фактической системы и сопоставления обязательств с конкретными мерами контроля. Архитектура не должна жёстко фиксировать одну регуляторную интерпретацию так, как если бы все рабочие нагрузки ИИ имели одинаковый статус.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-78\">Закупки и архитектура становятся связанными\u003C\u002Fh2>\n\u003Cp>Внешняя модель или управляемая платформа ИИ может стать глубокой зависимостью, даже если интеграция требует всего нескольких вызовов API. Поэтому архитектура предприятия должна делать вопросы закупок технически конкретными.\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Вопрос закупки\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Архитектурное следствие\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Где обрабатываются данные?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Регион, сетевой путь, резидентность данных и средства контроля передачи.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Сохраняются ли данные клиента или используются для улучшения поставщиком?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Минимизация данных, договорные меры контроля и соответствие требованиям к поставщику.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Как версионируются или выводятся из эксплуатации модели?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Регрессионное тестирование, совместимость, резервный вариант и планирование жизненного цикла.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Каковы квоты и ограничения обслуживания?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Архитектура мощности, контроль допуска и обработка отказов.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Насколько переносима интеграция?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Абстракция поставщика, стоимость выхода и усилия по миграции.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Какая информация об инцидентах доступна?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Наблюдаемость, возможности криминалистического анализа и эскалация поддержки.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Какие субпроцессоры или внешние сервисы задействованы?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Картирование зависимостей и оценка рисков.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Что меняется без явного одобрения клиента?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Обнаружение изменений, контрольные точки выпуска и стратегия приёмки.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-81\">Архитектура предприятия решает, сколько контроля над ИИ действительно требует требование\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Требование\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Возможный архитектурный ответ\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Быстрый доступ к управляемым моделям\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Управляемый поставщик с корпоративной идентификацией, контролем шлюза и договорным анализом.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Приватные данные с управляемой оркестрацией\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Управляемая плоскость управления плюс контролируемое клиентом исполнение или приватная плоскость данных, где это поддерживается.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Строгая локальность или суверенитет\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ограниченная регионом, суверенная, приватная или самостоятельно размещённая архитектура в соответствии с реальным требованием.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Изолированная среда\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Локально размещённые модели, локальный поиск, локальные инструменты, офлайн-обновление\u002Fраспространение и изолированная наблюдаемость.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Переносимость поставщика\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Принадлежащее приложению доменное состояние плюс адаптеры и контракты, изолирующие специфичное для поставщика поведение там, где это практически возможно.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Наивысший контроль над семантикой агента\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Самостоятельно управляемая или глубоко контролируемая среда исполнения с явным владением инструментами, контекстом, состоянием и жизненным циклом.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>Наиболее контролируемая архитектура не обязательно является лучшей архитектурой предприятия. Большая ответственность увеличивает обязанности по исправлению, мощности, безопасности, тестированию, операциям с моделями и реагированию на инциденты. Архитектура предприятия должна повышать уровень контроля только там, где требование оправдывает дополнительную операционную нагрузку.\u003C\u002Fp>\n\u003Ch2 id=\"section-84\">ИИ превращает управление изменениями в поведенческую проблему\u003C\u002Fh2>\n\u003Cp>Обычное обновление зависимости может изменить производительность или совместимость. Изменение ИИ также может изменить поведение. Замена модели, изменение системного запроса, изменение поиска, добавление инструмента или изменение политики контекста могут изменить то, как система интерпретирует и отвечает, даже если окружающий код приложения почти не меняется.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Путь изменения ИИ в производстве\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. Изменение выявлено\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Предлагается или обнаруживается изменение модели, поставщика, запроса, источника поиска, инструмента, политики или среды исполнения.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. Влияние картировано\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Определяются затронутые решения, классы данных, пользователи, средства контроля рисков, стоимость, контракты и операционные зависимости.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. Архитектурное решение обновлено\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Существенные выборы и компромиссы фиксируются; заменённые решения остаются исторически отслеживаемыми.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. Оценка выполнена\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Запускаются соответствующие регрессионные, безопасностные, поисковые, задержковые, стоимостные и доменные тесты.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. Одобрение применено\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Уровень одобрения следует за последствиями, риском и организационной политикой.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. Контролируемое развёртывание\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Где уместно, используется версионированный выпуск, канареечное или поэтапное развёртывание.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">7\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">7. Собраны производственные доказательства\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Отслеживаются телеметрия, инциденты, обратная связь и доменные результаты.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">8\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">8. Откат или приёмка\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Изменение принимается, ограничивается, откатывается или заменяется на основе доказательств.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-87\">ИИ предприятия всё ещё нужны NFR и ADR\u003C\u002Fh2>\n\u003Cp>ИИ не заменяет обычную архитектурную дисциплину. Нефункциональные требования остаются целевыми условиями: доступность, задержка, приватность, изоляция, аудируемость, восстанавливаемость, границы стоимости, объяснимость или другие требования к качеству. Записи архитектурных решений сохраняют выбранный ответ и его компромиссы.\u003C\u002Fp>\n\u003Cp>Специфическое для ИИ отличие в том, что некоторые атрибуты качества должны оцениваться вероятностно или эмпирически. «Ответы должны быть полезными» — слишком расплывчато. Производственное требование должно определять задачу, данные, популяцию пользователей, допустимые условия отказа, метод измерения и порог там, где это практически возможно.\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--success my-6 rounded-xl border p-5 border-emerald-300 bg-emerald-50 dark:border-emerald-900 dark:bg-emerald-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Цепочка прослеживаемости предприятия\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>Бизнес-потребность → требование \u002F NFR → архитектурное решение → реализация → оценка \u002F валидация → производственное наблюдение → решение об изменении.\u003C\u002Fstrong> ИИ добавляет новые переменные в эту цепочку; он не делает цепочку ненужной.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-91\">Архитектура корпоративного ИИ должна быть связана с реализацией\u003C\u002Fh2>\n\u003Cp>Архитектура, которая никогда не доходит до бэклога, внедрения, приёмки и эксплуатации, остаётся концептуальной. Поэтому корпоративному ИИ нужна прослеживаемость от архитектурных решений к работам по реализации и обратно — от свидетельств реализации к архитектуре.\u003C\u002Fp>\n\u003Cp>Jira и Confluence — примеры инструментов, которые могут поддерживать это разделение при осознанном использовании: Confluence может хранить требования, архитектуру, решения, риски и обоснования; Jira может управлять действенными работами по реализации и их состоянием. Важен принцип прослеживаемости, а не бренд инструмента.\u003C\u002Fp>\n\u003Ch2 id=\"section-94\">Свидетельства исходного проекта: Enterprise Aaasaasa 0.1\u003C\u002Fh2>\n\u003Caside class=\"editorjs-callout editorjs-callout--note my-6 rounded-xl border p-5 border-gray-300 bg-gray-50 dark:border-gray-700 dark:bg-gray-900\u002F40\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Свидетельства проекта, а не заявление о рыночном подтверждении\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Enterprise Aaasaasa 0.1 используется здесь как свидетельство исходного проекта структурированного подхода к корпоративной архитектуре и реализации. Это контекст PoC \u002F корпоративного проекта, а не доказательство массового принятия клиентами, промышленного использования в корпоративном масштабе или коммерческого успеха.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cp>Enterprise Aaasaasa 0.1 объединяет архитектуру платформы, концепции SaaS\u002FAPI, интернационализацию, интеграцию ИИ и структурированное управление проектом. Проект был намеренно организован так, чтобы требования, архитектура, поставка прототипа, валидация и закрытие были отдельными этапами, а не одной недифференцированной фазой реализации.\u003C\u002Fp>\n\u003Cp>Архитектурное направление включает концепции мультиэкземплярности \u002F мультибазовости вместе с возможностями API, CRUD, i18n и ИИ. Это важно для корпоративного ИИ, потому что границы тенантов или экземпляров, владение базами данных и прикладные сервисы должны оставаться явными при добавлении функций ИИ.\u003C\u002Fp>\n\u003Cp>Структура проекта также рассматривала задержки в архитектуре, разрастание объёма и вопросы защиты ИИ\u002Fданных как проектные риски, а не обнаруживала их только во время реализации. Заинтересованные стороны включали технические, безопасностные, спонсорские\u002Fруководящие и внешние сервисные перспективы, что ближе к реальной кросс-функциональной природе корпоративного ИИ, чем прототип, ориентированный только на модель.\u003C\u002Fp>\n\u003Cp>Таким образом, полезное свидетельство — это интеграция архитектуры и реализации: бизнес и структура проекта, этапы, риски, архитектура, работа над бэкендом\u002FAPI, фронтендом\u002FИИ, валидация и закрытие рассматриваются как связанные обязанности. Этот паттерн воспроизводим, хотя сам проект не следует представлять как доказательство внешнего корпоративного внедрения.\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Элемент проекта\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Урок для архитектуры корпоративного ИИ\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Этап требований\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Возможности ИИ должны начинаться с определённой потребности, объёма, критериев приёмки и ограничений качества.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Этап архитектуры\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Данные, API, границы экземпляров\u002Fбаз данных и интеграция ИИ — это явная проектная работа.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Этап прототипа\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Архитектура должна стать достаточно исполнимой, чтобы выявить риски интеграции.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Этап валидации\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Работающий прототип — это не то же самое, что подтверждённая приёмка.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Реестр рисков\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Объём, задержки архитектуры и вопросы защиты ИИ\u002Fданных управляются как риски реализации.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Структура заинтересованных сторон\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Корпоративный ИИ охватывает спонсора\u002Fбизнес, архитектуру, безопасность, внешних поставщиков и реализацию.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Закрытие проекта\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Решения, оставшиеся риски и свидетельства валидации должны сохраняться за пределами спринта реализации.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-101\">Поддерживающие паттерны реализации из более широкой работы над платформой\u003C\u002Fh2>\n\u003Cp>Отдельная работа по реализации в более широкой платформе Aaasaasa даёт конкретные примеры границ, которые архитектура корпоративного ИИ должна сохранять: RBAC с областью тенанта в CMS, явное разделение провайдера\u002Fмодели\u002Fсреды выполнения\u002Fразрешений в Aaasaasa AI Client и поиск с приоритетом происхождения в Source of Truth Research Engine.\u003C\u002Fp>\n\u003Cp>Эти проекты не следует объединять в одну заявленную производственную платформу. Их ценность здесь уже: они демонстрируют реализованные паттерны для области идентичности, границ провайдеров, контролируемых разрешений среды выполнения, происхождения поиска и прослеживаемости свидетельств, которые напрямую относятся к корпоративному ИИ.\u003C\u002Fp>\n\u003Ch2 id=\"section-104\">Как основные стандарты сочетаются друг с другом\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Источник\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Что он вносит в архитектуру корпоративного ИИ\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">ISO\u002FIEC 42001:2023\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Система управления ИИ на уровне организации: политики, цели, процессы, ответственность, мониторинг и постоянное улучшение.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">ISO\u002FIEC 23894:2023\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Руководство по интеграции управления рисками, специфичными для ИИ, в деятельность и функции организации.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">NIST AI RMF 1.0\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Добровольная структура, ориентированная на жизненный цикл, для управления рисками ИИ; организована вокруг Govern, Map, Measure и Manage.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">NIST AI 600-1\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Профиль генеративного ИИ, расширяющий AI RMF рисками и действиями, специфичными для генеративного ИИ.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">EU AI Act\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Обязательные регуляторные требования в ЕС, применимость которых зависит от роли, типа системы и классификации.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">ISO\u002FIEC\u002FIEEE 42010:2022\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Общие концепции описания архитектуры для выражения интересов, точек зрения, решений и взаимосвязей.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>Эти источники решают разные задачи. ISO\u002FIEC 42001 не заменяет техническую архитектуру. ISO\u002FIEC 23894 и NIST AI RMF не определяют один обязательный программный стек. EU AI Act — это закон, а не паттерн проектирования платформы. Архитектура должна переводить применимые организационные, риск-ориентированные и правовые требования в реализуемые границы системы и свидетельства.\u003C\u002Fp>\n\u003Ch2 id=\"section-107\">Распространённые режимы отказа корпоративного ИИ\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Режим отказа\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Почему это не работает\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Каждая команда покупает ИИ независимо\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Создаёт теневых провайдеров, дублированные секреты, несогласованную обработку данных и слабое влияние на риск поставщика.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Одна центральная команда ИИ владеет всеми доменными решениями\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Централизует технический контроль, но теряет доменную ответственность и создаёт узкое место.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Векторная база данных становится источником истины\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Инфраструктура поиска незаметно заменяет авторитетные системы и правила актуальности.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Один общий API-ключ для всех пользователей и агентов\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Уничтожает атрибуцию, минимальные привилегии и осмысленную аудируемость.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Изменение модели развёртывается как незначительный патч библиотеки\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Поведенческие регрессии могут попасть в производство без доменной оценки.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Все промпты и выходные данные логируются навсегда\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Наблюдаемость создаёт неконтролируемое хранилище конфиденциальных данных.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Управление — это только документация\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Политики существуют без точек принудительного исполнения, свидетельств или операционной ответственности.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Соответствие делегируется провайдеру\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Собственная роль организации, вариант использования, данные и операционные обязательства остаются нерешёнными.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Агент может вызывать инструменты, потому что модель поддерживает использование инструментов\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Возможность ошибочно принимается за авторизацию.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Здоровье платформы равно бизнес-корректности\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Доступность конечных точек и доступность модели не доказывают качество доменных ответов или приемлемость результатов.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Нет стратегии выхода из зависимости от модели\u002Fпровайдера\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Изменение цены, политики, возможностей или доступности становится аварийной миграцией.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-109\">Распространённые заблуждения\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Заблуждение\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Более правильная модель\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«Корпоративный ИИ — это чат-бот для всей компании».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Чат-бот — лишь один из интерфейсов; архитектура корпоративного ИИ управляет лежащими в основе данными, идентификацией, провайдером, средой выполнения, рисками и операциями.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«Если мы используем надёжного поставщика моделей, вопрос управления решён».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Контроли поставщика не определяют ваш сценарий использования, полномочия на данные, права пользователей, бизнес-приёмку или юридическую роль.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«Частный ИИ означает, что всё должно быть развёрнуто на собственных серверах».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Требования к приватности могут приводить к нескольким архитектурам; требуемую границу контроля необходимо указывать точно.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«Управление ИИ относится к юристам, архитектура — к ИТ».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Эти две дисциплины должны быть связаны, поскольку политические обязательства требуют реализуемых контролей и доказательств.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«Одна корпоративная модель — это проще».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Стандартизация может помочь, но рабочие нагрузки могут требовать разных модальностей, регионов, затрат, уровней качества или моделей контроля.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«Риск ИИ — это риск модели».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Риск может возникать в данных, промптах, поиске, идентификации, инструментах, интерфейсах, операциях, пользователях и организационных процессах.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«Участие человека в цикле делает агента безопасным».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Одобрение человеком помогает только если проверяющий обладает полезным контекстом, полномочиями, временем и чёткой точкой принятия решения.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«Успешный пилот доказывает готовность к корпоративному внедрению».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Пилот доказывает ограниченную работоспособность; готовность к корпоративному внедрению также требует интеграции, управления, жизненного цикла, операций и воспроизводимых контролей.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-111\">Практическая последовательность решений по архитектуре корпоративного ИИ\u003C\u002Fh2>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">От возможности к управляемой корпоративной способности\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. Определите бизнес-способность\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Укажите пользователя, решение или рабочий процесс, ожидаемую ценность и ответственного владельца.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. Классифицируйте данные и полномочия\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Определите системы учёта, персональные\u002Fконфиденциальные данные, требования к хранению, актуальности и происхождению.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. Определите границы идентификации и действий\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Установите, кто может читать, генерировать, решать, одобрять и изменять внешние системы.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. Выберите ответственность решения и платформы\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Решите, что относится к рабочей нагрузке, что можно совместно использовать и что остаётся в ведении предприятия.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. Оцените зависимость от провайдера и среды выполнения\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Оцените управляемые, самостоятельно размещённые, частные, суверенные или гибридные варианты с учётом реальных требований.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. Сопоставьте риски и нормативные обязательства\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Определите уровень риска, организационные контроли и применимые юридические обязанности для конкретной системы.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">7\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">7. Определите измеримую приёмку\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Создайте критерии оценки качества, надёжности, безопасности, поиска, стоимости и операционного поведения.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">8\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">8. Зафиксируйте архитектурные решения\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Сохраните обоснование, альтернативы, компромиссы, зависимости и условия, которые потребуют пересмотра.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">9\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">9. Свяжите архитектуру с реализацией\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Переведите проект в бэклог, этапы, критерии приёмки, технические работы и ответственность.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">10\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">10. Проверьте в условиях, приближенных к производственным\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Тестируйте реалистичные сценарии идентификации, данных, сбоев, задержек, провайдера, инструментов и восстановления, а не только чистые демонстрации.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">11\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">11. Установите операции и контроль изменений\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Определите мониторинг, реагирование на инциденты, обновления модели\u002Fпровайдера, регрессионное тестирование, откат и вывод из эксплуатации.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">12\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">12. Возвращайте доказательства в архитектуру\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Используйте производственные наблюдения, аудиты, инциденты и оценки для пересмотра решений и контролей.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-113\">Чек-лист архитектуры корпоративного ИИ\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Вопрос\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Ожидаемое доказательство\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Какую бизнес-способность поддерживает этот ИИ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Названный владелец, группа пользователей, предполагаемое решение\u002Fрабочий процесс и цель приёмки.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Какой источник является авторитетным для каждого важного факта?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Системы учёта, авторитет документов, правила происхождения и актуальности.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Какие идентификаторы существуют?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Идентификаторы человека, приложения, сервиса, агента, арендатора\u002Fорганизации и провайдера различимы.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Что может читать ИИ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Источники данных с ограничением по авторизации и явные правила для конфиденциальных данных.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Что может изменять ИИ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Инвентаризация инструментов\u002Fдействий, модель разрешений, путь одобрения и отката.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Какой провайдер\u002Fмодель используется и почему?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Архитектурное решение, включая качество, безопасность, стоимость, регион, жизненный цикл и соображения выхода.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Что произойдёт, если провайдер недоступен?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Режим пониженной функциональности, резервный вариант, отказ или план непрерывности.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Как оценивается качество?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Наборы данных для конкретных задач, оценщики, пороги, критерии регрессии и условия валидности.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Что логируется?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Схема телеметрии, редактирование, доступ, хранение и цель аудита.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Кто отвечает за риск ИИ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Названная организационная ответственность, связанная с конкретной системой.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Какая юридическая классификация применяется?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Документированная оценка на основе действующего законодательства и фактического сценария использования.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Как утверждаются изменения модели\u002Fпромпта\u002Fпоиска?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Версионирование, оценка, запись архитектуры\u002Fизменений и этап развёртывания.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Кто реагирует на инцидент с ИИ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Регламент, технический владелец, бизнес\u002Fдомен эскалация и эскалация к провайдеру.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Как система выводится из эксплуатации?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Очистка данных, отзыв доступа, выход от провайдера, сохранение доказательств и удаление зависимостей.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-115\">Крайние случаи и ограничения\u003C\u002Fh2>\n\u003Cp>Небольшая компания с одним сценарием использования ИИ с низким риском может не нуждаться в формальной функции архитектуры корпоративного ИИ. Те же принципы можно применять в лёгкой форме: чёткий владелец, одобренные данные, явный провайдер, базовая оценка, контроль доступа и операционная ответственность.\u003C\u002Fp>\n\u003Cp>Высоко регулируемая организация может нуждаться в более строгом разделении, независимой валидации, формальных процессах соответствия, локальном хостинге или работе в изолированной среде. Эти контроли определяются сценарием использования и нормативной средой, а не словом «корпоративный».\u003C\u002Fp>\n\u003Cp>Организация также может использовать в основном SaaS-продукты ИИ, а не создавать системы ИИ. Корпоративная архитектура всё равно важна, поскольку идентификация, доступ к данным, договорные условия, теневой ИИ, хранение, аудит и концентрация поставщиков остаются организационными вопросами.\u003C\u002Fp>\n\u003Cp>Централизованная платформа не обязательна. Федеративная ответственность за платформу может быть оправдана, когда домены имеют существенно разные требования, при условии что ответственность за идентификацию, риски, инвентаризацию и совместимость на уровне предприятия остаётся согласованной.\u003C\u002Fp>\n\u003Ch2 id=\"section-120\">Что могло бы изменить этот ответ?\u003C\u002Fh2>\n\u003Cp>Архитектура меняется, когда меняются толерантность организации к риску, нормативная классификация, чувствительность данных, географический охват, стратегия провайдера, внутренние навыки или критичность для бизнеса. Публичный маркетинговый помощник и система, участвующая в решениях о трудоустройстве, финансах, здравоохранении или критической инфраструктуре, не должны наследовать одинаковые модели контроля.\u003C\u002Fp>\n\u003Cp>Реализация также меняется по мере развития стандартов, регулирования и платформ ИИ. NIST AI RMF 1.0 в настоящее время пересматривается, EU AI Act имеет поэтапные даты применения, а возможности моделей и провайдеров продолжают быстро меняться. Поэтому архитектура корпоративного ИИ должна сохранять стабильные границы ответственности, рассматривая механизмы провайдеров и нормативные детали как версионируемые входные данные.\u003C\u002Fp>\n\u003Ch2 id=\"section-123\">Связанные канонические знания\u003C\u002Fh2>\n\u003Cp>Архитектура корпоративного ИИ строится на архитектуре решений и платформы. Уровень решения описывает одну рабочую нагрузку. Уровень платформы описывает многоразовые возможности ИИ. Уровень предприятия связывает и то и другое с общеорганизационными данными, идентификацией, управлением, рисками, закупками и операциями.\u003C\u002Fp>\n\u003Cp>Генерация с дополненной выборкой (RAG) — лишь один из механизмов внутри этой архитектуры. RAG может улучшить доступ к корпоративным знаниям, но сам по себе не решает вопросы авторитетности данных, разрешений, управления или достоверности ответов.\u003C\u002Fp>\n\u003Caside class=\"editorjs-referral my-6\">\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fru\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works\" class=\"flex flex-col sm:flex-row gap-4 rounded-xl border border-gray-200 dark:border-gray-700 p-4 transition hover:border-primary-500\">\u003Cdiv class=\"min-w-0 flex-1\">\u003Cstrong class=\"block text-lg text-gray-900 dark:text-gray-100\">Что такое RAG? Самое простое объяснение того, как это работает\u003C\u002Fstrong>\u003Cp class=\"mt-2 text-sm text-gray-600 dark:text-gray-300\">Простое объяснение того, как извлечение внешних знаний подключается к языковой модели, не превращая поиск в источник истины.\u003C\u002Fp>\u003Cspan class=\"mt-3 inline-flex text-sm font-medium text-primary-600 dark:text-primary-400\">Читать основы RAG →\u003C\u002Fspan>\u003C\u002Fdiv>\u003C\u002Fa>\u003C\u002Faside>\n\u003Cp>Для корпоративных сценариев с большим объёмом доказательств обоснованность ответа также требует явной границы: вывод считается подтверждённым только в рамках доказательств, версии, области применения и допущений, при которых он был получен.\u003C\u002Fp>\n\u003Caside class=\"editorjs-referral my-6\">\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fru\u002Fblog\u002Fthe-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers\" class=\"flex flex-col sm:flex-row gap-4 rounded-xl border border-gray-200 dark:border-gray-700 p-4 transition hover:border-primary-500\">\u003Cdiv class=\"min-w-0 flex-1\">\u003Cstrong class=\"block text-lg text-gray-900 dark:text-gray-100\">Граница обоснованности ответа: недостающий слой между релевантностью и надёжными ответами ИИ\u003C\u002Fstrong>\u003Cp class=\"mt-2 text-sm text-gray-600 dark:text-gray-300\">Фреймворк для явного определения условий, при которых утверждение ИИ остаётся подтверждённым, и того, какие изменения требуют ограничения или пересчёта.\u003C\u002Fp>\u003Cspan class=\"mt-3 inline-flex text-sm font-medium text-primary-600 dark:text-primary-400\">Читать «Границу обоснованности ответа» →\u003C\u002Fspan>\u003C\u002Fdiv>\u003C\u002Fa>\u003C\u002Faside>\n\u003Cp>Смежные корпоративные темы включают управление ИИ, частный ИИ, суверенный ИИ, изолированный ИИ, многоарендную архитектуру ИИ, RBAC против изоляции арендаторов, абстракцию поставщиков, маршрутизацию моделей и производственную архитектуру ИИ.\u003C\u002Fp>\n\u003Ch2 id=\"section-130\">Часто задаваемые вопросы\u003C\u002Fh2>\n\u003Csection class=\"editorjs-faq my-6 rounded-xl border border-gray-200 p-5 dark:border-gray-700\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Часто задаваемые вопросы о корпоративной архитектуре ИИ\u003C\u002Fh3>\u003Cdiv id=\"faq1\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Что такое корпоративная архитектура ИИ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Корпоративная архитектура ИИ — это общеорганизационная архитектура, определяющая, как решения ИИ и общие возможности ИИ интегрируются с бизнес-ответственностью, корпоративными данными, идентификацией, безопасностью, поставщиками, управлением, рисками, соответствием, жизненным циклом и операциями.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq2\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Корпоративная архитектура ИИ — это то же самое, что платформа ИИ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Нет. Платформа ИИ предоставляет многоразовые технические возможности, такие как доступ к моделям, поиск, среды выполнения агентов и наблюдаемость. Корпоративная архитектура ИИ определяет, как эта платформа и отдельные решения ИИ вписываются в более широкую архитектуру и операционную модель организации.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq3\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Требует ли корпоративный ИИ одной центральной модели?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Нет. Стандартизация может снизить сложность, но разные рабочие нагрузки могут требовать разных поставщиков, моделей, регионов, уровней контроля или модальностей. Важное требование — явная политика и ответственность за жизненный цикл.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq4\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Почему авторитетность данных важна для корпоративного ИИ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Потому что полученная или сгенерированная информация не является автоматически авторитетной. Корпоративные системы должны сохранять, какой источник является системой записи, актуальны ли данные, кто может получить к ним доступ и как сгенерированное утверждение можно проследить до доказательств.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq5\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">В чём разница между управлением ИИ и корпоративной архитектурой ИИ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Управление ИИ определяет политики, подотчётность и права принятия решений. Корпоративная архитектура ИИ определяет границы систем, интерфейсы, потоки данных и технические механизмы, с помощью которых эти политики могут быть реализованы и подтверждены.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq6\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Применяется ли Закон ЕС об ИИ ко всем корпоративным системам ИИ одинаково?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Нет. Обязательства зависят от таких факторов, как роль организации, вариант использования и классификация системы, а также соответствующие действующие положения. Правовая классификация должна выполняться для конкретной системы в соответствии с действующим законодательством.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq7\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Достаточно ли успешного пилота ИИ для корпоративного развёртывания?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Нет. Пилот демонстрирует ограниченную возможность. Корпоративное развёртывание также требует идентификации, авторитетности данных, безопасности, управления поставщиками, оценки, жизненного цикла, реагирования на инциденты, мониторинга, соответствия и подотчётной операционной ответственности.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq8\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Следует ли предприятиям размещать ИИ на собственных серверах?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Только когда требование оправдывает дополнительный контроль и операционную ответственность. Управляемые, частные, суверенные, самостоятельно размещённые и гибридные подходы — это архитектурные варианты, пригодность которых зависит от требований к данным, регулированию, доступности, стоимости, возможностям и эксплуатации.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-132\">Глоссарий\u003C\u002Fh2>\n\u003Csection class=\"editorjs-glossary my-6 rounded-xl border border-gray-200 dark:border-gray-700 p-5\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Ключевые термины корпоративной архитектуры ИИ\u003C\u002Fh3>\u003Cdl>\u003Cdiv id=\"enterprise-ai-architecture\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Корпоративная архитектура ИИ\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Общеорганизационная архитектура, определяющая, как системы ИИ, платформы, данные, идентификации, поставщики, средства контроля рисков и операции сочетаются друг с другом.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"ai-management-system\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Система управления ИИ\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Организационная система управления для установления политик, целей и процессов, связанных с ИИ; ISO\u002FIEC 42001 определяет требования к такой системе.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"data-authority\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Авторитетность данных\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Правило, определяющее, какой источник или система является авторитетным для конкретного факта, записи, состояния или контекста решения.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"system-of-record\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Система записи\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Авторитетная система, отвечающая за официальное текущее состояние бизнес-записи или сущности предметной области.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"ai-inventory\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Реестр ИИ\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Структурированная запись вариантов использования ИИ, владельцев, моделей\u002Fпоставщиков, данных, инструментов, рисков, доказательств оценки, состояния жизненного цикла и связанных средств контроля.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"provider-dependency\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Зависимость от поставщика\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Техническая, договорная и операционная зависимость, возникающая, когда рабочая нагрузка ИИ зависит от внешней модели или управляемой платформы.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"human-oversight\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Человеческий надзор\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Определённая проверка, утверждение, вмешательство или эскалация со стороны человека, применяемые там, где этого требуют последствия системы, неопределённость или регулирование.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"genaiops\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">GenAIOps\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Операционные практики для рабочих нагрузок генеративного ИИ, охватывающие выбор модели, подсказки, данные обоснования, оценку, развёртывание, мониторинг и управление жизненным циклом.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"ai-risk-management\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Управление рисками ИИ\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Организационный процесс выявления, оценки, обработки, мониторинга и пересмотра рисков, связанных с системами ИИ на протяжении их жизненного цикла.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"architecture-decision\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Архитектурное решение\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Существенный проектный выбор вместе с его контекстом, обоснованием, альтернативами, компромиссами и статусом жизненного цикла.\u003C\u002Fdd>\u003C\u002Fdiv>\u003C\u002Fdl>\u003C\u002Fsection>\n\u003Ch2 id=\"section-134\">Заключение\u003C\u002Fh2>\n\u003Cp>Когда ИИ приходит в компанию, предприятие приобретает не просто новый программный компонент. Оно приобретает новый класс поведения и зависимостей, который пронизывает данные, идентификацию, поставщиков, бизнес-решения, безопасность, операции, управление и управление изменениями.\u003C\u002Fp>\n\u003Cp>Архитектурный ответ — не централизовать всё. Он состоит в том, чтобы сделать ответственности явными: какие данные авторитетны, какие идентификации могут действовать, какие поставщики одобрены, какие средства контроля являются общими, какие решения остаются за предметной областью, как оценивается поведение, как обрабатываются инциденты и как система меняется со временем.\u003C\u002Fp>\n\u003Cp>В этом и состоит ключевое отличие корпоративной архитектуры ИИ: она превращает изолированную возможность ИИ в организационно управляемую систему, не делая вид, что модели, платформы, бизнес-домены и корпоративные средства контроля — это одно и то же.\u003C\u002Fp>\n\u003Ch2 id=\"section-138\">Первоисточники и актуальные рекомендации\u003C\u002Fh2>\n\u003Cp>Внешние стандарты, регулирование и актуальные рекомендации по архитектуре поставщиков ниже были проверены 8 октября 2026 года. Разделы, относящиеся к конкретному проекту, явно помечены как оригинальные доказательства проекта, и их не следует воспринимать как утверждения об общеотраслевых фактах.\u003C\u002Fp>\n\u003Ca href=\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F42001\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">ISO\u002FIEC 42001:2023 — Система управления искусственным интеллектом\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Международный стандарт, определяющий требования к созданию, внедрению, поддержанию и постоянному улучшению системы управления ИИ в организациях.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F77304.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">ISO\u002FIEC 23894:2023 — Руководство по управлению рисками ИИ\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Международное руководство по интеграции управления рисками, специфичными для ИИ, в деятельность и функции организации.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.nist.gov\u002Fitl\u002Fai-risk-management-framework\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">NIST AI Risk Management Framework\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Добровольный фреймворк NIST, ориентированный на жизненный цикл, для управления рисками ИИ. NIST заявляет, что AI RMF 1.0 в настоящее время пересматривается.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.nist.gov\u002Fpublications\u002Fartificial-intelligence-risk-management-framework-generative-artificial-intelligence\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">NIST AI 600-1 — Профиль генеративного ИИ\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Сопутствующий профиль NIST, описывающий риски, специфичные для генеративного ИИ, и действия по управлению рисками в соответствии с AI RMF.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Feur-lex.europa.eu\u002Feli\u002Freg\u002F2024\u002F1689\u002F2026-07-27\u002Feng\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">EUR-Lex — Регламент (ЕС) 2024\u002F1689, консолидированный текст\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Текущий консолидированный текст Закона об ИИ, использованный для дат применения и регуляторной структуры по состоянию на 8 октября 2026 года.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fdigital-strategy.ec.europa.eu\u002Fen\u002Fpolicies\u002Fregulatory-framework-ai\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Европейская комиссия — нормативная база Закона об ИИ\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Текущий обзор Комиссии по этапам применения Закона об ИИ, включая применимость в 2026 году и более поздние сроки для отдельных положений о высокорисковых системах.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fget-started\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Microsoft Azure Well-Architected — рабочие нагрузки ИИ\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Актуальное руководство по архитектуре рабочих нагрузок ИИ, включая недетерминированное поведение, данные, проектирование приложений и эксплуатацию.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fmlops-genaiops\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Microsoft — MLOps и GenAIOps для рабочих нагрузок ИИ\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Актуальное руководство по жизненному циклу эксплуатации, данным, поддержке моделей, развертыванию, мониторингу и непрерывному развитию.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fresponsible-ai\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Microsoft — ответственный ИИ в рабочих нагрузках Azure\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Актуальное руководство, связывающее политику в области ИИ с контролем данных, идентификацией, аудитом агентов, доступом на основе ролей и эксплуатационными мерами защиты.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">ISO\u002FIEC\u002FIEEE 42010:2022 — Описание архитектуры\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Актуальный стандарт описания архитектуры, поддерживающий явные интересы, точки зрения и взаимосвязи в архитектуре системы.\u003C\u002Fp>\u003C\u002Fa>",{"time":212,"blocks":213,"version":1561},1791478638792,[214,220,228,235,242,250,255,260,265,270,305,310,315,320,325,351,356,361,366,371,376,381,386,391,396,401,406,412,417,422,427,432,437,442,447,452,457,462,467,472,477,482,487,492,497,502,507,512,517,522,527,532,537,542,547,552,557,562,567,572,621,627,632,638,670,675,680,710,715,720,761,766,790,795,800,805,810,816,821,826,858,863,889,894,899,904,934,939,944,949,955,960,965,970,975,981,986,991,996,1001,1030,1035,1040,1045,1050,1076,1081,1086,1127,1132,1164,1169,1211,1216,1266,1271,1276,1281,1286,1291,1296,1301,1306,1311,1316,1321,1330,1335,1343,1348,1353,1391,1396,1440,1445,1450,1455,1460,1465,1470,1480,1489,1498,1507,1516,1525,1534,1543,1552],{"id":215,"data":216,"type":218,"tunes":219},"intro",{"text":217},"Архитектура корпоративного ИИ — это общеорганизационная архитектура, необходимая, когда ИИ становится частью реальных систем, данных, решений и операций компании. Модель — лишь один из компонентов. Как только ИИ подключается к корпоративным данным, идентичностям, разрешениям, бизнес-процессам, внешним поставщикам и производственным системам, архитектура должна также определять полномочия над данными, границы доступа, владение рисками, зависимости от поставщиков, возможность аудита, оценку, управление жизненным циклом, соответствие требованиям и операционную ответственность. Таким образом, корпоративный ИИ отличается и от отдельного ИИ-решения, и от общей ИИ-платформы: он координирует, как множество систем с поддержкой ИИ встраиваются в более широкую организацию.","paragraph",{},{"id":221,"data":222,"type":226,"tunes":227},"direct-answer",{"body":223,"title":224,"variant":225},"\u003Cstrong>Что меняется, когда ИИ приходит в компанию?\u003C\u002Fstrong> Существующие обязанности корпоративной архитектуры расширяются и включают вероятностное поведение моделей, новые потоки данных, поиск и обоснование, зависимости от моделей и поставщиков, оценку, специфичную для ИИ, полномочия агентов и инструментов, жизненный цикл моделей и промптов, управление рисками ИИ, обязательства по прозрачности и новые режимы операционных сбоев. Архитектура должна связать эти вопросы с существующими структурами компании в области идентичности, безопасности, данных, закупок, поставки и управления, а не создавать параллельную «вселенную ИИ».","Прямой ответ","info","callout",{},{"id":229,"data":230,"type":226,"tunes":234},"not-bigger-chatbot",{"body":231,"title":232,"variant":233},"Чат-бот может быть пользовательским интерфейсом. Архитектура корпоративного ИИ — это система границ за ним: к каким данным ИИ может получить доступ, какой источник является авторитетным, кто может использовать какую возможность, могут ли внешние поставщики получать данные, какие действия может выполнять агент, как оцениваются выходные данные, что должно регистрироваться, кто отвечает за инциденты и как изменения утверждаются и откатываются.","Корпоративный ИИ — это не «чат-бот побольше»","warning",{},{"id":236,"data":237,"type":226,"tunes":241},"current-date",{"body":238,"title":239,"variant":240},"Архитектурные принципы в этой статье задуманы как стабильные. Регулирование, стандарты и возможности поставщиков зависят от версии. ISO\u002FIEC 42001:2023 и ISO\u002FIEC 23894:2023 — действующие опубликованные стандарты. NIST заявляет, что AI RMF 1.0 пересматривается. Согласно текущему консолидированному тексту Закона ЕС об ИИ, Регламент в целом применяется с 2 августа 2026 года, тогда как отдельные положения о высоком риске имеют более поздние даты применения. Юридическую классификацию всегда необходимо проверять по действующему законодательству и конкретному случаю использования.","Примечание об актуальности источников — 8 октября 2026 г.","note",{},{"id":243,"data":244,"type":248,"tunes":249},"toc",{"title":245,"maxLevel":246,"minLevel":247},"Содержание",3,2,"tableOfContents",{},{"id":251,"data":252,"type":42,"tunes":254},"h-meaning",{"text":253,"level":247},"Что на самом деле означает архитектура корпоративного ИИ",{},{"id":256,"data":257,"type":218,"tunes":259},"p-meaning-1",{"text":258},"Архитектура корпоративного ИИ описывает, как возможности ИИ интегрируются в существующую организацию, не нарушая границы, которые уже делают корпоративные системы управляемыми: бизнес-ответственность, идентичность, авторизацию, классификацию данных, ответственность за систему-источник, управление изменениями, закупки, аудит, непрерывность и операции.",{},{"id":261,"data":262,"type":218,"tunes":264},"p-meaning-2",{"text":263},"Корпоративный архитектор не заменяет архитектора ИИ-решения или архитектора ИИ-платформы. Корпоративный масштаб задает другой вопрос: как множество ИИ-решений и общих возможностей ИИ вписываются в целевую архитектуру, политики, ландшафт данных, модель рисков и операционную модель компании?",{},{"id":266,"data":267,"type":218,"tunes":269},"p-meaning-3",{"text":268},"Это делает архитектуру корпоративного ИИ дисциплиной координации между технологиями и организацией. Технически хорошая интеграция модели все равно может быть провалом корпоративной архитектуры, если она создает теневые потоки данных, дублирует идентичность, обходит закупки, не поддается аудиту, не имеет владельца или не может быть безопасно изменена.",{},{"id":271,"data":272,"type":303,"tunes":304},"scope-comparison",{"rows":273,"title":291,"layout":292,"columns":293},[274,279,283,287],{"id":275,"label":276,"values":277},"scope","Основной масштаб",[278,278,278],"",{"id":280,"label":281,"values":282},"question","Основной вопрос",[278,278,278],{"id":284,"label":285,"values":286},"ownership","Фокус ответственности",[278,278,278],{"id":288,"label":289,"values":290},"success","Условие успеха",[278,278,278],"Архитектура ИИ-решения, платформы и корпоративного ИИ — это разные масштабы","table",[294,297,300],{"id":295,"label":296},"solution","Архитектура ИИ-решения",{"id":298,"label":299},"platform","Архитектура ИИ-платформы",{"id":301,"label":302},"enterprise","Архитектура корпоративного ИИ","comparison",{},{"id":306,"data":307,"type":42,"tunes":309},"h-simple",{"text":308,"level":247},"Самый простой пример",{},{"id":311,"data":312,"type":218,"tunes":314},"p-simple-1",{"text":313},"Компания начинает с одного внутреннего помощника по документам. Первая версия ищет по утвержденным документам и отправляет найденный контекст языковой модели. На уровне решения это может выглядеть просто.",{},{"id":316,"data":317,"type":218,"tunes":319},"p-simple-2",{"text":318},"Затем вторая команда хочет ИИ для поддержки клиентов. Третья хочет агента, который может обновлять тикеты. Финансовый отдел хочет анализ документов. HR хочет внутреннего помощника. Разработчики хотят агентов для программирования. Внезапно у компании появляются несколько поставщиков, несколько классов данных, разные группы пользователей, пересекающиеся индексы поиска, разные правила логирования, новые разрешения для инструментов, дублирующиеся секреты и неясная ответственность.",{},{"id":321,"data":322,"type":218,"tunes":324},"p-simple-3",{"text":323},"В этот момент вопрос уже не в том, «работает ли помощник?» Корпоративный вопрос становится таким: какие возможности утверждены, кто ими владеет, какие данные могут пересекать какую границу, как обеспечиваются идентичности и разрешения, какие поставщики допустимы, что должно проходить аудит и как организация может менять модели или поставщиков, не теряя контроля?",{},{"id":326,"data":327,"type":349,"tunes":350},"simple-flow",{"steps":328,"title":347,"orientation":348},[329,332,335,338,341,344],{"label":330,"description":331},"1. Изолированный сценарий использования","Одна команда подключает одну модель к одному рабочему процессу и подтверждает локальную ценность.",{"label":333,"description":334},"2. Появляются общие зависимости","Нескольким командам нужны поставщики, доступ к моделям, поиск, идентичность, секреты, наблюдаемость и оценка.",{"label":336,"description":337},"3. Пересекаются корпоративные границы","ИИ затрагивает регулируемые данные, системы-источники, внешних поставщиков, привилегированные действия и бизнес-решения.",{"label":339,"description":340},"4. Ответственность должна стать явной","Бизнесу, архитектуре, данным, безопасности, юридическому отделу и комплаенсу, закупкам и операциям нужны определенные обязанности.",{"label":342,"description":343},"5. Жизненный цикл становится организационным","Изменения моделей, промптов, поставщиков и новые возможности агентов становятся управляемыми изменениями, а не локальными правками разработчиков.",{"label":345,"description":346},"6. Архитектура становится повторяемой","Организация устанавливает многоразовые шаблоны, записи решений, контроли, исключения и этапы проверки для новых ИИ-нагрузок.","От изолированной функции ИИ к корпоративной архитектуре","auto","processFlow",{},{"id":352,"data":353,"type":42,"tunes":355},"h-stop",{"text":354,"level":247},"Где заканчивается простой пример",{},{"id":357,"data":358,"type":218,"tunes":360},"p-stop-1",{"text":359},"Корпоративная архитектура не означает, что каждый компонент ИИ должен быть централизован. Некоторые возможности следует сделать общими; другие должны оставаться в ведении домена. Финансы, HR, инженерия и поддержка клиентов могут обоснованно требовать разных границ данных, поставщиков, критериев оценки и правил человеческого утверждения.",{},{"id":362,"data":363,"type":218,"tunes":365},"p-stop-2",{"text":364},"Таким образом, корпоративная цель — не одна модель, одна векторная база данных или один универсальный помощник. Цель — согласованная архитектура с явной вариативностью: общие политики и многоразовые возможности там, где они снижают риск и дублирование, плюс контролируемые исключения там, где бизнес- или регуляторные требования различаются.",{},{"id":367,"data":368,"type":42,"tunes":370},"h-layers",{"text":369,"level":247},"Что меняется в архитектуре, когда ИИ приходит в предприятие",{},{"id":372,"data":373,"type":42,"tunes":375},"h-business",{"text":374,"level":246},"1. Бизнес-владелец становится частью технической архитектуры",{},{"id":377,"data":378,"type":218,"tunes":380},"p-business-1",{"text":379},"Традиционным приложениям уже нужны бизнес-владельцы. ИИ делает это требование более заметным, потому что приемлемое поведение нельзя определить только через время безотказной работы и функциональную корректность. Кто-то должен отвечать за предполагаемое использование, недопустимое использование, качество выходных данных, путь эскалации и последствия неверных или неподходящих результатов.",{},{"id":382,"data":383,"type":218,"tunes":385},"p-business-2",{"text":384},"Команда модели не может в одиночку решить, приемлем ли ответ для HR, финансов, юридического отдела или использования с взаимодействием с клиентами. Поэтому архитектура ИИ предприятия связывает технический дизайн с явно определённой бизнес-способностью, ответственным владельцем, группой пользователей и контекстом принятия решений.",{},{"id":387,"data":388,"type":42,"tunes":390},"h-data-authority",{"text":389,"level":246},"2. Доступа к данным недостаточно — необходимо определить полномочия на данные",{},{"id":392,"data":393,"type":218,"tunes":395},"p-data-authority-1",{"text":394},"ИИ предприятия часто объединяет операционные базы данных, документы, поисковые индексы, векторные хранилища, хранилища данных, SaaS-системы и внешние знания. Архитектура должна различать, где хранится информация, и какой источник является авторитетным для данного утверждения или действия.",{},{"id":397,"data":398,"type":218,"tunes":400},"p-data-authority-2",{"text":399},"Векторный индекс может улучшить поиск, но не должен незаметно становиться системой учёта компании. Ответ модели может суммировать запись ERP, но не должен заменять ERP как авторитетный источник. Кэшированный контекст может улучшить задержку, но становится небезопасным, когда меняются разрешения или базовое бизнес-состояние.",{},{"id":402,"data":403,"type":218,"tunes":405},"p-data-authority-3",{"text":404},"Поэтому ИИ предприятия нуждается в происхождении, актуальности, классификации источников, распространении авторизации и правилах аннулирования в дополнение к обычной интеграции данных.",{},{"id":407,"data":408,"type":226,"tunes":411},"authority-rule",{"body":409,"title":410,"variant":288},"\u003Cstrong>Система ИИ может преобразовывать, извлекать и рассуждать о данных предприятия, не становясь авторитетом для этих данных.\u003C\u002Fstrong> Архитектура должна сохранять путь обратно к авторитетному источнику, когда вариант использования требует доказательств, проверки или последующих действий.","Правило данных предприятия",{},{"id":413,"data":414,"type":42,"tunes":416},"h-identity",{"text":415,"level":246},"3. Идентичность становится многоуровневой",{},{"id":418,"data":419,"type":218,"tunes":421},"p-identity-1",{"text":420},"У ИИ предприятия больше идентичностей, чем у человека-пользователя. Запрос может включать идентичность пользователя, идентичность приложения, идентичность сервиса, идентичность агента, учётные данные провайдера, учётные данные инструмента и контекст арендатора или организации.",{},{"id":423,"data":424,"type":218,"tunes":426},"p-identity-2",{"text":425},"Эти идентичности не следует сводить к одному общему API-ключу. Авторизация должна оставаться привязанной к правильному субъекту, а привилегированные инструменты должны получать только те полномочия, которые требуются для текущей операции.",{},{"id":428,"data":429,"type":218,"tunes":431},"p-identity-3",{"text":430},"Для агентных систем это становится особенно важным: модель может предложить действие, но среда выполнения должна решить, разрешено ли запрашивающей идентичности его выполнить. Возможность модели — это не авторизация.",{},{"id":433,"data":434,"type":42,"tunes":436},"h-permissions",{"text":435,"level":246},"4. Разрешения смещаются от доступа к контенту к полномочиям на действия",{},{"id":438,"data":439,"type":218,"tunes":441},"p-permissions-1",{"text":440},"Помощнику только для чтения в основном нужен контролируемый доступ к информации. Агент предприятия может создавать заявки, изменять записи, отправлять сообщения, запускать рабочие процессы или управлять внешними системами. Это вводит другой класс риска, потому что система может изменять состояние, а не просто описывать его.",{},{"id":443,"data":444,"type":218,"tunes":446},"p-permissions-2",{"text":445},"Архитектура должна разделять возможности чтения, записи, утверждения и администрирования; определять точки участия человека там, где последствия это оправдывают; и сохранять журнал аудита, который определяет, что было запрошено, что было одобрено и что фактически изменилось.",{},{"id":448,"data":449,"type":42,"tunes":451},"h-provider",{"text":450,"level":246},"5. Поставщик ИИ становится зависимостью предприятия",{},{"id":453,"data":454,"type":218,"tunes":456},"p-provider-1",{"text":455},"Вызов API модели — это также отношения с поставщиком. Архитектура может зависеть от доступности поставщика, условий обслуживания, условий обработки данных, поддерживаемых регионов, жизненного цикла модели, квот, ценообразования, совместимости API, средств безопасности и уведомлений об изменениях.",{},{"id":458,"data":459,"type":218,"tunes":461},"p-provider-2",{"text":460},"Это означает, что выбор провайдера — не только решение на основе бенчмарков. Закупки, безопасность, конфиденциальность, юридическая экспертиза, планирование непрерывности и стратегия выхода могут стать входными данными для архитектуры.",{},{"id":463,"data":464,"type":218,"tunes":466},"p-provider-3",{"text":465},"Абстракция провайдера может снизить связанность, но только там, где базовые возможности действительно переносимы. Использование инструментов, структурированный вывод, ограничения контекста, мультимодальность, средства контроля безопасности, тонкая настройка и функции хостинговых агентов могут существенно различаться у разных провайдеров.",{},{"id":468,"data":469,"type":42,"tunes":471},"h-risk",{"text":470,"level":246},"6. Риск ИИ становится процессом жизненного цикла",{},{"id":473,"data":474,"type":218,"tunes":476},"p-risk-1",{"text":475},"Риск ИИ не исчерпывается одним одобрением перед запуском. Модель, промпт, корпус для поиска, набор инструментов, провайдер, популяция пользователей и окружающий бизнес-процесс могут измениться после развёртывания. Профиль риска меняется вместе с ними.",{},{"id":478,"data":479,"type":218,"tunes":481},"p-risk-2",{"text":480},"ISO\u002FIEC 23894:2023 явно рассматривает интеграцию управления рисками ИИ в организационные деятельности и функции. NIST AI RMF аналогично определяет управление рисками на протяжении жизненного цикла. Поэтому архитектура предприятия должна сделать анализ рисков частью изменений и операций, а не изолированным документом о соответствии.",{},{"id":483,"data":484,"type":218,"tunes":486},"p-risk-3",{"text":485},"Риск также должен быть пропорциональным. Ассистент для суммаризации и автономная система, изменяющая производственные записи, не должны получать одинаковые меры контроля только потому, что обе используют LLM.",{},{"id":488,"data":489,"type":42,"tunes":491},"h-management-system",{"text":490,"level":246},"7. Управление становится операционной системой, а не PDF-политикой",{},{"id":493,"data":494,"type":218,"tunes":496},"p-management-system-1",{"text":495},"ISO\u002FIEC 42001:2023 определяет требования к созданию, внедрению, поддержанию и постоянному улучшению системы управления ИИ. Архитектурное следствие важно: управление должно связывать политику с реальными реестрами, ответственностью, процессами, средствами контроля, доказательствами, проверками и циклами улучшения.",{},{"id":498,"data":499,"type":218,"tunes":501},"p-management-system-2",{"text":500},"Корпоративная политика в области ИИ, не связанная с одобрением провайдеров, идентификацией, журналированием, управлением изменениями, оценкой и реагированием на инциденты, имеет ограниченный архитектурный эффект. Организации нужны механизмы, делающие политику исполнимой или хотя бы наблюдаемой.",{},{"id":503,"data":504,"type":42,"tunes":506},"h-eval",{"text":505,"level":246},"8. Оценка становится производственным контролем",{},{"id":508,"data":509,"type":218,"tunes":511},"p-eval-1",{"text":510},"Традиционное приёмочное тестирование предполагает, что один и тот же вход обычно даёт один и тот же детерминированный результат. Генеративный ИИ может быть недетерминированным, чувствительным к контексту и зависящим от изменяющихся внешних знаний. Поэтому производственная приёмка требует оценок, специфичных для задачи, наборов регрессионных тестов и наблюдаемых порогов, а не только модульных тестов.",{},{"id":513,"data":514,"type":218,"tunes":516},"p-eval-2",{"text":515},"Платформа может предоставить переиспользуемую инфраструктуру оценки, но предприятию всё равно необходимо владеть эталонными данными предметной области и контрольными точками выпуска. Центральная команда по ИИ не может придумать правильный ответ для каждой бизнес-области.",{},{"id":518,"data":519,"type":218,"tunes":521},"p-eval-3",{"text":520},"Изменения модели, промпта, поиска и инструментов должны быть прослеживаемы к доказательствам оценки там, где изменение может существенно повлиять на поведение вывода.",{},{"id":523,"data":524,"type":42,"tunes":526},"h-observability",{"text":525,"level":246},"9. Наблюдаемость должна включать поведение, данные и контекст модели",{},{"id":528,"data":529,"type":218,"tunes":531},"p-observability-1",{"text":530},"Показателей CPU, памяти и частоты ошибок HTTP недостаточно для рабочих нагрузок ИИ. Производственная наблюдаемость может потребовать идентификаторов модели и провайдера, задержки, использования токенов, стоимости, результатов поиска, вызовов инструментов, поведения отказов, оценок, событий безопасности и классификаций сбоев.",{},{"id":533,"data":534,"type":218,"tunes":536},"p-observability-2",{"text":535},"В то же время телеметрия ИИ может содержать конфиденциальные данные. Журналы промптов и ответов могут стать теневым хранилищем данных. Поэтому архитектура предприятия должна определить, что можно логировать, как это редактируется, кто имеет к этому доступ, как долго это хранится и когда детальная трассировка должна быть отключена.",{},{"id":538,"data":539,"type":42,"tunes":541},"h-lifecycle",{"text":540,"level":246},"10. Компоненты ИИ нуждаются в явном владении жизненным циклом",{},{"id":543,"data":544,"type":218,"tunes":546},"p-lifecycle-1",{"text":545},"Модели могут быть переименованы, заменены, выведены из эксплуатации или изменены провайдерами. Модели эмбеддингов могут сделать стратегию индексации недействительной. Шаблоны промптов и системные инструкции могут изменить поведение. Среды выполнения агентов и протоколы могут развиваться. Внешние инструменты могут изменять свои схемы и разрешения.",{},{"id":548,"data":549,"type":218,"tunes":551},"p-lifecycle-2",{"text":550},"Корпоративная архитектура должна определить, кто обнаруживает эти изменения, кто их тестирует, кто их утверждает, как уведомляются потребители, как работает откат и какие доказательства требуются, прежде чем новая версия станет версией по умолчанию.",{},{"id":553,"data":554,"type":42,"tunes":556},"h-operations",{"text":555,"level":246},"11. Реагирование на инциденты должно учитывать специфические для ИИ режимы отказа",{},{"id":558,"data":559,"type":218,"tunes":561},"p-operations-1",{"text":560},"Инцидент, связанный с ИИ, может быть сбоем у поставщика, утечкой данных, путём внедрения через промпт, отказом авторизации, загрязнением поисковой выдачи, неожиданным поведением модели, небезопасным выполнением инструментов, скачком затрат, устаревшими знаниями, регрессией оценки или изменением поведения внешней модели.",{},{"id":563,"data":564,"type":218,"tunes":566},"p-operations-2",{"text":565},"Поэтому корпоративный регламент действий должен включать не только «перезапустить сервис». Он может потребовать отключения маршрута модели, отзыва доступа к инструментам, заморозки корпуса, изменения версии промпта, отключения возможности агента, смены поставщика, эскалации к владельцу домена или сохранения трассировок для расследования.",{},{"id":568,"data":569,"type":42,"tunes":571},"h-ownership",{"text":570,"level":247},"Корпоративный ИИ создаёт кросс-функциональную ответственность",{},{"id":573,"data":574,"type":292,"tunes":620},"ownership-table",{"content":575,"stretched":43,"withHeadings":14},[576,580,584,588,592,596,600,604,608,612,616],[577,578,579],"Аспект","Типичный корпоративный владелец или участник","Вопрос архитектуры",[581,582,583],"Бизнес-использование","Бизнес-владелец \u002F владелец продукта","Какое решение или рабочий процесс ИИ разрешено поддерживать или автоматизировать?",[585,586,587],"Архитектура решения","Архитектор ИИ \u002F архитектор решений","Как конкретная рабочая нагрузка удовлетворяет свои функциональные требования и требования к качеству?",[589,590,591],"Общие возможности ИИ","Платформа ИИ \u002F платформенная инженерия","Какие переиспользуемые сервисы моделей, поиска, агентов и наблюдаемости предоставляются?",[593,594,595],"Корпоративная согласованность","Корпоративная архитектура","Как системы ИИ вписываются в целевую архитектуру, стандарты, шаблоны интеграции и организационную ответственность?",[597,598,599],"Полномочия по данным","Владелец данных \u002F владелец домена","Какие данные являются авторитетными, актуальными, разрешёнными и достаточно управляемыми?",[601,602,603],"Идентификация и безопасность","IAM \u002F архитектура безопасности","Какие идентификаторы могут получать доступ к каким данным и выполнять какие действия?",[605,606,607],"Риски и соответствие","Риски \u002F юридический отдел \u002F комплаенс \u002F приватность","Какие обязательства, запрещённые виды использования, меры контроля и доказательства применяются к этому сценарию?",[609,610,611],"Зависимость от поставщика","Закупки \u002F управление поставщиками \u002F архитектура","Какие контрактные, операционные риски и риски выхода возникают из-за поставщика?",[613,614,615],"Эксплуатация","SRE \u002F эксплуатация \u002F владелец платформы","Как система мониторится, поддерживается, деградирует, восстанавливается и изменяется?",[617,618,619],"Принятие доменом","Бизнес-специалисты \u002F специалисты домена","Что считается правильным, безопасным или полезным результатом в этом домене?",{},{"id":622,"data":623,"type":226,"tunes":626},"ownership-warning",{"body":624,"title":625,"variant":233},"Матрицы ответственности полезны только тогда, когда они связаны с реальными границами систем, утверждениями, владением данными, интерфейсами, регламентами действий и процессами изменений. Корпоративный ИИ требует подотчётной ответственности, которая может быть прослежена до технических мер контроля и операционных действий.","Матрица RACI сама по себе не является архитектурой",{},{"id":628,"data":629,"type":42,"tunes":631},"h-model",{"text":630,"level":247},"Практическая модель архитектуры корпоративного ИИ",{},{"id":633,"data":634,"type":226,"tunes":637},"model-note",{"body":635,"title":636,"variant":240},"Следующая модель представляет собой практический синтез для рассуждения об архитектуре корпоративного ИИ. Она не представлена как стандарт ISO или NIST. Её цель — сделать кросс-организационные границы явными.","Предлагаемая многоуровневая модель",{},{"id":639,"data":640,"type":292,"tunes":669},"enterprise-model-table",{"content":641,"stretched":43,"withHeadings":14},[642,645,648,651,654,657,660,663,666],[643,644],"Уровень","Основная ответственность",[646,647],"Бизнес и политика","Утверждённые сценарии использования, подотчётные владельцы, аппетит к риску, запрещённые виды использования, человеческая подотчётность, бизнес-приёмка.",[649,650],"Идентификация и полномочия","Идентификаторы пользователей\u002Fсервисов\u002Fагентов, роли, границы арендатора или организации, привилегированные действия, пути утверждения.",[652,653],"Корпоративные данные","Системы учёта, источники документов, данные как продукты, происхождение, классификация, хранение, актуальность и доступ.",[655,656],"Платформа ИИ","Доступ к поставщику\u002Fмодели, примитивы поиска, среды выполнения агентов, брокеры инструментов, инфраструктура оценки, наблюдаемость, квоты и секреты.",[658,659],"Решения на основе ИИ","Рабочие процессы домена, промпты\u002Fинструкции, поиск в домене, бизнес-логика, критерии приёмки и пользовательский опыт.",[661,662],"Интеграция и инструменты","API, корпоративные приложения, рабочие процессы, обмен сообщениями, файловые системы, внешние сервисы и выполнение действий.",[664,665],"Риски и управление","Инвентаризация, оценка, доказательства соответствия, управление исключениями, утверждение моделей\u002Fпоставщиков, проверка и аудит.",[667,668],"Эксплуатация и жизненный цикл","Развёртывание, мониторинг, инциденты, релизы, изменения моделей\u002Fпоставщиков, вывод из эксплуатации, откат и непрерывность.",{},{"id":671,"data":672,"type":218,"tunes":674},"p-model-1",{"text":673},"Архитектура наиболее сильна, когда каждый уровень может заявить как свои обязанности, так и то, за что он не отвечает. Например, платформа ИИ может обеспечивать соблюдение политики поставщика и собирать трассировки, не становясь источником истины для данных HR. Решение может определять промпты домена, не владея корпоративной IAM. Бизнес-владелец может утвердить сценарий использования, и при этом не ожидается, что он будет эксплуатировать шлюз вывода.",{},{"id":676,"data":677,"type":42,"tunes":679},"h-data-flow",{"text":678,"level":247},"Представляйте корпоративный ИИ как потоки данных и полномочий, а не как блоки",{},{"id":681,"data":682,"type":349,"tunes":709},"enterprise-flow",{"steps":683,"title":708,"orientation":348},[684,687,690,693,696,699,702,705],{"label":685,"description":686},"1. Бизнес-контекст","Пользователь запрашивает задачу в рамках утверждённого сценария использования с подотчётным бизнес-владельцем.",{"label":688,"description":689},"2. Идентификация и авторизация","Система определяет пользователя, приложение, сервис и границы арендатора или организации до предоставления привилегированного доступа.",{"label":691,"description":692},"3. Получение авторитетных данных","Решение читает или извлекает только источники, разрешённые для текущего идентификатора и задачи.",{"label":694,"description":695},"4. Обработка ИИ","Утверждённая модель\u002Fпоставщик обрабатывает минимально необходимый контекст в соответствии с определёнными правилами маршрутизации и обработки данных.",{"label":697,"description":698},"5. Граница инструмента или действия","Любое действие, изменяющее состояние, независимо авторизуется и может требовать одобрения человеком в зависимости от последствий.",{"label":700,"description":701},"6. Валидация","Результат проверяется на соответствие критериям приёмки, доказательствам или правилам безопасности, специфичным для решения.",{"label":703,"description":704},"7. Аудит и наблюдаемость","Разрешённые метаданные, решения, маршруты, вызовы инструментов и результаты записываются без создания неконтролируемых журналов конфиденциальных данных.",{"label":706,"description":707},"8. Обратная связь и жизненный цикл","Сбои и результаты оценки питают изменения моделей, промптов, данных, политик и процессов через контролируемое управление изменениями.","Значимый запрос к корпоративному ИИ",{},{"id":711,"data":712,"type":42,"tunes":714},"h-inventory",{"text":713,"level":247},"Предприятию нужен реестр ИИ, прежде чем оно сможет управлять ИИ",{},{"id":716,"data":717,"type":218,"tunes":719},"p-inventory-1",{"text":718},"Организации не могут управлять системами ИИ, которые они не могут идентифицировать. Корпоративная архитектура должна вести реестр на уровне, полезном для принятия решений, а не просто список названий моделей.",{},{"id":721,"data":722,"type":292,"tunes":760},"inventory-table",{"content":723,"stretched":43,"withHeadings":14},[724,727,730,733,736,739,742,745,748,751,754,757],[725,726],"Поле реестра","Почему это важно",[728,729],"Сценарий использования и владелец","Связывает технологию с подотчётной бизнес-целью.",[731,732],"Пользователи и затронутые стороны","Определяет, кто взаимодействует с системой или на кого она влияет.",[734,735],"Модель\u002Fпоставщик","Идентифицирует внешнюю зависимость, возможности и риск жизненного цикла.",[737,738],"Источники данных","Поддерживает проверку полномочий, приватности, классификации и происхождения.",[740,741],"Место развёртывания\u002Fвыполнения","Уточняет место обработки, подключение и операционный контроль.",[743,744],"Инструменты\u002Fдействия","Показывает, может ли ИИ изменять внешнее состояние и с какими последствиями.",[746,747],"Человеческий надзор","Фиксирует, где требуется проверка, утверждение или эскалация.",[749,750],"Риск\u002Fклассификация","Связывает систему с организационными и регуляторными мерами контроля.",[752,753],"Доказательства оценки","Показывает, что было протестировано и при каких условиях валидности.",[755,756],"Текущая версия","Позволяет проследить инциденты и регрессии до фактического развёрнутого состояния.",[758,759],"Состояние жизненного цикла","Предложено, экспериментально, утверждено, в производстве, ограничено, устарело или выведено из эксплуатации.",{},{"id":762,"data":763,"type":42,"tunes":765},"h-governance",{"text":764,"level":247},"Управление ИИ и архитектура корпоративного ИИ связаны, но не совпадают",{},{"id":767,"data":768,"type":303,"tunes":789},"governance-comparison",{"rows":769,"title":782,"layout":292,"columns":783},[770,774,778],{"id":771,"label":772,"values":773},"purpose","Цель",[278,278],{"id":775,"label":776,"values":777},"example","Пример",[278,278],{"id":779,"label":780,"values":781},"failure","Сбой при изоляции",[278,278],"Управление против архитектуры",[784,787],{"id":785,"label":786},"governance","Управление ИИ",{"id":788,"label":302},"architecture",{},{"id":791,"data":792,"type":42,"tunes":794},"h-regulation",{"text":793,"level":247},"Регулирование становится входными данными архитектуры",{},{"id":796,"data":797,"type":218,"tunes":799},"p-regulation-1",{"text":798},"Для организаций, работающих в Европейском союзе, AI Act может создавать требования, влияющие на проектирование систем, документацию, прозрачность, управление и операционные процессы. Влияние на архитектуру зависит от роли организации в цепочке создания ценности ИИ и конкретной классификации системы; не все системы ИИ имеют одинаковые обязательства.",{},{"id":801,"data":802,"type":218,"tunes":804},"p-regulation-2",{"text":803},"По состоянию на 8 октября 2026 года в текущем консолидированном тексте указано, что Регламент в целом применяется с 2 августа 2026 года. Правила управления и обязательства для моделей ИИ общего назначения начали применяться раньше, а отдельные положения для систем высокого риска имеют более поздние сроки. Комиссия также начала обеспечивать соблюдение новых требований к прозрачности с 2 августа 2026 года для соответствующих интерактивных систем и систем синтетического контента.",{},{"id":806,"data":807,"type":218,"tunes":809},"p-regulation-3",{"text":808},"Урок архитектуры предприятия не в том, чтобы «встроить соответствие требованиям в модель». Он в том, чтобы сделать классификацию, роль поставщика\u002Fразвёртывающего, документацию, прозрачность, надзор, журналирование и доказательства изменений отслеживаемыми до системы, которая фактически реализует сценарий использования.",{},{"id":811,"data":812,"type":226,"tunes":815},"legal-note",{"body":813,"title":814,"variant":240},"Эта статья описывает архитектурные последствия, а не юридическую консультацию. Архитектура ИИ предприятия должна сохранять информацию, необходимую юридическим специалистам и специалистам по соответствию для классификации фактической системы и сопоставления обязательств с конкретными мерами контроля. Архитектура не должна жёстко фиксировать одну регуляторную интерпретацию так, как если бы все рабочие нагрузки ИИ имели одинаковый статус.","Правовая сфера зависит от конкретного сценария использования",{},{"id":817,"data":818,"type":42,"tunes":820},"h-procurement",{"text":819,"level":247},"Закупки и архитектура становятся связанными",{},{"id":822,"data":823,"type":218,"tunes":825},"p-procurement-1",{"text":824},"Внешняя модель или управляемая платформа ИИ может стать глубокой зависимостью, даже если интеграция требует всего нескольких вызовов API. Поэтому архитектура предприятия должна делать вопросы закупок технически конкретными.",{},{"id":827,"data":828,"type":292,"tunes":857},"procurement-table",{"content":829,"stretched":43,"withHeadings":14},[830,833,836,839,842,845,848,851,854],[831,832],"Вопрос закупки","Архитектурное следствие",[834,835],"Где обрабатываются данные?","Регион, сетевой путь, резидентность данных и средства контроля передачи.",[837,838],"Сохраняются ли данные клиента или используются для улучшения поставщиком?","Минимизация данных, договорные меры контроля и соответствие требованиям к поставщику.",[840,841],"Как версионируются или выводятся из эксплуатации модели?","Регрессионное тестирование, совместимость, резервный вариант и планирование жизненного цикла.",[843,844],"Каковы квоты и ограничения обслуживания?","Архитектура мощности, контроль допуска и обработка отказов.",[846,847],"Насколько переносима интеграция?","Абстракция поставщика, стоимость выхода и усилия по миграции.",[849,850],"Какая информация об инцидентах доступна?","Наблюдаемость, возможности криминалистического анализа и эскалация поддержки.",[852,853],"Какие субпроцессоры или внешние сервисы задействованы?","Картирование зависимостей и оценка рисков.",[855,856],"Что меняется без явного одобрения клиента?","Обнаружение изменений, контрольные точки выпуска и стратегия приёмки.",{},{"id":859,"data":860,"type":42,"tunes":862},"h-control",{"text":861,"level":247},"Архитектура предприятия решает, сколько контроля над ИИ действительно требует требование",{},{"id":864,"data":865,"type":292,"tunes":888},"control-table",{"content":866,"stretched":43,"withHeadings":14},[867,870,873,876,879,882,885],[868,869],"Требование","Возможный архитектурный ответ",[871,872],"Быстрый доступ к управляемым моделям","Управляемый поставщик с корпоративной идентификацией, контролем шлюза и договорным анализом.",[874,875],"Приватные данные с управляемой оркестрацией","Управляемая плоскость управления плюс контролируемое клиентом исполнение или приватная плоскость данных, где это поддерживается.",[877,878],"Строгая локальность или суверенитет","Ограниченная регионом, суверенная, приватная или самостоятельно размещённая архитектура в соответствии с реальным требованием.",[880,881],"Изолированная среда","Локально размещённые модели, локальный поиск, локальные инструменты, офлайн-обновление\u002Fраспространение и изолированная наблюдаемость.",[883,884],"Переносимость поставщика","Принадлежащее приложению доменное состояние плюс адаптеры и контракты, изолирующие специфичное для поставщика поведение там, где это практически возможно.",[886,887],"Наивысший контроль над семантикой агента","Самостоятельно управляемая или глубоко контролируемая среда исполнения с явным владением инструментами, контекстом, состоянием и жизненным циклом.",{},{"id":890,"data":891,"type":218,"tunes":893},"p-control-1",{"text":892},"Наиболее контролируемая архитектура не обязательно является лучшей архитектурой предприятия. Большая ответственность увеличивает обязанности по исправлению, мощности, безопасности, тестированию, операциям с моделями и реагированию на инциденты. Архитектура предприятия должна повышать уровень контроля только там, где требование оправдывает дополнительную операционную нагрузку.",{},{"id":895,"data":896,"type":42,"tunes":898},"h-change-management",{"text":897,"level":247},"ИИ превращает управление изменениями в поведенческую проблему",{},{"id":900,"data":901,"type":218,"tunes":903},"p-change-1",{"text":902},"Обычное обновление зависимости может изменить производительность или совместимость. Изменение ИИ также может изменить поведение. Замена модели, изменение системного запроса, изменение поиска, добавление инструмента или изменение политики контекста могут изменить то, как система интерпретирует и отвечает, даже если окружающий код приложения почти не меняется.",{},{"id":905,"data":906,"type":349,"tunes":933},"change-process",{"steps":907,"title":932,"orientation":348},[908,911,914,917,920,923,926,929],{"label":909,"description":910},"1. Изменение выявлено","Предлагается или обнаруживается изменение модели, поставщика, запроса, источника поиска, инструмента, политики или среды исполнения.",{"label":912,"description":913},"2. Влияние картировано","Определяются затронутые решения, классы данных, пользователи, средства контроля рисков, стоимость, контракты и операционные зависимости.",{"label":915,"description":916},"3. Архитектурное решение обновлено","Существенные выборы и компромиссы фиксируются; заменённые решения остаются исторически отслеживаемыми.",{"label":918,"description":919},"4. Оценка выполнена","Запускаются соответствующие регрессионные, безопасностные, поисковые, задержковые, стоимостные и доменные тесты.",{"label":921,"description":922},"5. Одобрение применено","Уровень одобрения следует за последствиями, риском и организационной политикой.",{"label":924,"description":925},"6. Контролируемое развёртывание","Где уместно, используется версионированный выпуск, канареечное или поэтапное развёртывание.",{"label":927,"description":928},"7. Собраны производственные доказательства","Отслеживаются телеметрия, инциденты, обратная связь и доменные результаты.",{"label":930,"description":931},"8. Откат или приёмка","Изменение принимается, ограничивается, откатывается или заменяется на основе доказательств.","Путь изменения ИИ в производстве",{},{"id":935,"data":936,"type":42,"tunes":938},"h-nfr-adr",{"text":937,"level":247},"ИИ предприятия всё ещё нужны NFR и ADR",{},{"id":940,"data":941,"type":218,"tunes":943},"p-nfr-adr-1",{"text":942},"ИИ не заменяет обычную архитектурную дисциплину. Нефункциональные требования остаются целевыми условиями: доступность, задержка, приватность, изоляция, аудируемость, восстанавливаемость, границы стоимости, объяснимость или другие требования к качеству. Записи архитектурных решений сохраняют выбранный ответ и его компромиссы.",{},{"id":945,"data":946,"type":218,"tunes":948},"p-nfr-adr-2",{"text":947},"Специфическое для ИИ отличие в том, что некоторые атрибуты качества должны оцениваться вероятностно или эмпирически. «Ответы должны быть полезными» — слишком расплывчато. Производственное требование должно определять задачу, данные, популяцию пользователей, допустимые условия отказа, метод измерения и порог там, где это практически возможно.",{},{"id":950,"data":951,"type":226,"tunes":954},"nfr-adr-chain",{"body":952,"title":953,"variant":288},"\u003Cstrong>Бизнес-потребность → требование \u002F NFR → архитектурное решение → реализация → оценка \u002F валидация → производственное наблюдение → решение об изменении.\u003C\u002Fstrong> ИИ добавляет новые переменные в эту цепочку; он не делает цепочку ненужной.","Цепочка прослеживаемости предприятия",{},{"id":956,"data":957,"type":42,"tunes":959},"h-delivery",{"text":958,"level":247},"Архитектура корпоративного ИИ должна быть связана с реализацией",{},{"id":961,"data":962,"type":218,"tunes":964},"p-delivery-1",{"text":963},"Архитектура, которая никогда не доходит до бэклога, внедрения, приёмки и эксплуатации, остаётся концептуальной. Поэтому корпоративному ИИ нужна прослеживаемость от архитектурных решений к работам по реализации и обратно — от свидетельств реализации к архитектуре.",{},{"id":966,"data":967,"type":218,"tunes":969},"p-delivery-2",{"text":968},"Jira и Confluence — примеры инструментов, которые могут поддерживать это разделение при осознанном использовании: Confluence может хранить требования, архитектуру, решения, риски и обоснования; Jira может управлять действенными работами по реализации и их состоянием. Важен принцип прослеживаемости, а не бренд инструмента.",{},{"id":971,"data":972,"type":42,"tunes":974},"h-original",{"text":973,"level":247},"Свидетельства исходного проекта: Enterprise Aaasaasa 0.1",{},{"id":976,"data":977,"type":226,"tunes":980},"original-evidence-note",{"body":978,"title":979,"variant":240},"Enterprise Aaasaasa 0.1 используется здесь как свидетельство исходного проекта структурированного подхода к корпоративной архитектуре и реализации. Это контекст PoC \u002F корпоративного проекта, а не доказательство массового принятия клиентами, промышленного использования в корпоративном масштабе или коммерческого успеха.","Свидетельства проекта, а не заявление о рыночном подтверждении",{},{"id":982,"data":983,"type":218,"tunes":985},"p-enterprise-aaasaasa-1",{"text":984},"Enterprise Aaasaasa 0.1 объединяет архитектуру платформы, концепции SaaS\u002FAPI, интернационализацию, интеграцию ИИ и структурированное управление проектом. Проект был намеренно организован так, чтобы требования, архитектура, поставка прототипа, валидация и закрытие были отдельными этапами, а не одной недифференцированной фазой реализации.",{},{"id":987,"data":988,"type":218,"tunes":990},"p-enterprise-aaasaasa-2",{"text":989},"Архитектурное направление включает концепции мультиэкземплярности \u002F мультибазовости вместе с возможностями API, CRUD, i18n и ИИ. Это важно для корпоративного ИИ, потому что границы тенантов или экземпляров, владение базами данных и прикладные сервисы должны оставаться явными при добавлении функций ИИ.",{},{"id":992,"data":993,"type":218,"tunes":995},"p-enterprise-aaasaasa-3",{"text":994},"Структура проекта также рассматривала задержки в архитектуре, разрастание объёма и вопросы защиты ИИ\u002Fданных как проектные риски, а не обнаруживала их только во время реализации. Заинтересованные стороны включали технические, безопасностные, спонсорские\u002Fруководящие и внешние сервисные перспективы, что ближе к реальной кросс-функциональной природе корпоративного ИИ, чем прототип, ориентированный только на модель.",{},{"id":997,"data":998,"type":218,"tunes":1000},"p-enterprise-aaasaasa-4",{"text":999},"Таким образом, полезное свидетельство — это интеграция архитектуры и реализации: бизнес и структура проекта, этапы, риски, архитектура, работа над бэкендом\u002FAPI, фронтендом\u002FИИ, валидация и закрытие рассматриваются как связанные обязанности. Этот паттерн воспроизводим, хотя сам проект не следует представлять как доказательство внешнего корпоративного внедрения.",{},{"id":1002,"data":1003,"type":292,"tunes":1029},"enterprise-aaasaasa-table",{"content":1004,"stretched":43,"withHeadings":14},[1005,1008,1011,1014,1017,1020,1023,1026],[1006,1007],"Элемент проекта","Урок для архитектуры корпоративного ИИ",[1009,1010],"Этап требований","Возможности ИИ должны начинаться с определённой потребности, объёма, критериев приёмки и ограничений качества.",[1012,1013],"Этап архитектуры","Данные, API, границы экземпляров\u002Fбаз данных и интеграция ИИ — это явная проектная работа.",[1015,1016],"Этап прототипа","Архитектура должна стать достаточно исполнимой, чтобы выявить риски интеграции.",[1018,1019],"Этап валидации","Работающий прототип — это не то же самое, что подтверждённая приёмка.",[1021,1022],"Реестр рисков","Объём, задержки архитектуры и вопросы защиты ИИ\u002Fданных управляются как риски реализации.",[1024,1025],"Структура заинтересованных сторон","Корпоративный ИИ охватывает спонсора\u002Fбизнес, архитектуру, безопасность, внешних поставщиков и реализацию.",[1027,1028],"Закрытие проекта","Решения, оставшиеся риски и свидетельства валидации должны сохраняться за пределами спринта реализации.",{},{"id":1031,"data":1032,"type":42,"tunes":1034},"h-supporting",{"text":1033,"level":247},"Поддерживающие паттерны реализации из более широкой работы над платформой",{},{"id":1036,"data":1037,"type":218,"tunes":1039},"p-supporting-1",{"text":1038},"Отдельная работа по реализации в более широкой платформе Aaasaasa даёт конкретные примеры границ, которые архитектура корпоративного ИИ должна сохранять: RBAC с областью тенанта в CMS, явное разделение провайдера\u002Fмодели\u002Fсреды выполнения\u002Fразрешений в Aaasaasa AI Client и поиск с приоритетом происхождения в Source of Truth Research Engine.",{},{"id":1041,"data":1042,"type":218,"tunes":1044},"p-supporting-2",{"text":1043},"Эти проекты не следует объединять в одну заявленную производственную платформу. Их ценность здесь уже: они демонстрируют реализованные паттерны для области идентичности, границ провайдеров, контролируемых разрешений среды выполнения, происхождения поиска и прослеживаемости свидетельств, которые напрямую относятся к корпоративному ИИ.",{},{"id":1046,"data":1047,"type":42,"tunes":1049},"h-standards",{"text":1048,"level":247},"Как основные стандарты сочетаются друг с другом",{},{"id":1051,"data":1052,"type":292,"tunes":1075},"standards-table",{"content":1053,"stretched":43,"withHeadings":14},[1054,1057,1060,1063,1066,1069,1072],[1055,1056],"Источник","Что он вносит в архитектуру корпоративного ИИ",[1058,1059],"ISO\u002FIEC 42001:2023","Система управления ИИ на уровне организации: политики, цели, процессы, ответственность, мониторинг и постоянное улучшение.",[1061,1062],"ISO\u002FIEC 23894:2023","Руководство по интеграции управления рисками, специфичными для ИИ, в деятельность и функции организации.",[1064,1065],"NIST AI RMF 1.0","Добровольная структура, ориентированная на жизненный цикл, для управления рисками ИИ; организована вокруг Govern, Map, Measure и Manage.",[1067,1068],"NIST AI 600-1","Профиль генеративного ИИ, расширяющий AI RMF рисками и действиями, специфичными для генеративного ИИ.",[1070,1071],"EU AI Act","Обязательные регуляторные требования в ЕС, применимость которых зависит от роли, типа системы и классификации.",[1073,1074],"ISO\u002FIEC\u002FIEEE 42010:2022","Общие концепции описания архитектуры для выражения интересов, точек зрения, решений и взаимосвязей.",{},{"id":1077,"data":1078,"type":218,"tunes":1080},"p-standards-1",{"text":1079},"Эти источники решают разные задачи. ISO\u002FIEC 42001 не заменяет техническую архитектуру. ISO\u002FIEC 23894 и NIST AI RMF не определяют один обязательный программный стек. EU AI Act — это закон, а не паттерн проектирования платформы. Архитектура должна переводить применимые организационные, риск-ориентированные и правовые требования в реализуемые границы системы и свидетельства.",{},{"id":1082,"data":1083,"type":42,"tunes":1085},"h-failures",{"text":1084,"level":247},"Распространённые режимы отказа корпоративного ИИ",{},{"id":1087,"data":1088,"type":292,"tunes":1126},"failures-table",{"content":1089,"stretched":43,"withHeadings":14},[1090,1093,1096,1099,1102,1105,1108,1111,1114,1117,1120,1123],[1091,1092],"Режим отказа","Почему это не работает",[1094,1095],"Каждая команда покупает ИИ независимо","Создаёт теневых провайдеров, дублированные секреты, несогласованную обработку данных и слабое влияние на риск поставщика.",[1097,1098],"Одна центральная команда ИИ владеет всеми доменными решениями","Централизует технический контроль, но теряет доменную ответственность и создаёт узкое место.",[1100,1101],"Векторная база данных становится источником истины","Инфраструктура поиска незаметно заменяет авторитетные системы и правила актуальности.",[1103,1104],"Один общий API-ключ для всех пользователей и агентов","Уничтожает атрибуцию, минимальные привилегии и осмысленную аудируемость.",[1106,1107],"Изменение модели развёртывается как незначительный патч библиотеки","Поведенческие регрессии могут попасть в производство без доменной оценки.",[1109,1110],"Все промпты и выходные данные логируются навсегда","Наблюдаемость создаёт неконтролируемое хранилище конфиденциальных данных.",[1112,1113],"Управление — это только документация","Политики существуют без точек принудительного исполнения, свидетельств или операционной ответственности.",[1115,1116],"Соответствие делегируется провайдеру","Собственная роль организации, вариант использования, данные и операционные обязательства остаются нерешёнными.",[1118,1119],"Агент может вызывать инструменты, потому что модель поддерживает использование инструментов","Возможность ошибочно принимается за авторизацию.",[1121,1122],"Здоровье платформы равно бизнес-корректности","Доступность конечных точек и доступность модели не доказывают качество доменных ответов или приемлемость результатов.",[1124,1125],"Нет стратегии выхода из зависимости от модели\u002Fпровайдера","Изменение цены, политики, возможностей или доступности становится аварийной миграцией.",{},{"id":1128,"data":1129,"type":42,"tunes":1131},"h-misconceptions",{"text":1130,"level":247},"Распространённые заблуждения",{},{"id":1133,"data":1134,"type":292,"tunes":1163},"misconceptions-table",{"content":1135,"stretched":43,"withHeadings":14},[1136,1139,1142,1145,1148,1151,1154,1157,1160],[1137,1138],"Заблуждение","Более правильная модель",[1140,1141],"«Корпоративный ИИ — это чат-бот для всей компании».","Чат-бот — лишь один из интерфейсов; архитектура корпоративного ИИ управляет лежащими в основе данными, идентификацией, провайдером, средой выполнения, рисками и операциями.",[1143,1144],"«Если мы используем надёжного поставщика моделей, вопрос управления решён».","Контроли поставщика не определяют ваш сценарий использования, полномочия на данные, права пользователей, бизнес-приёмку или юридическую роль.",[1146,1147],"«Частный ИИ означает, что всё должно быть развёрнуто на собственных серверах».","Требования к приватности могут приводить к нескольким архитектурам; требуемую границу контроля необходимо указывать точно.",[1149,1150],"«Управление ИИ относится к юристам, архитектура — к ИТ».","Эти две дисциплины должны быть связаны, поскольку политические обязательства требуют реализуемых контролей и доказательств.",[1152,1153],"«Одна корпоративная модель — это проще».","Стандартизация может помочь, но рабочие нагрузки могут требовать разных модальностей, регионов, затрат, уровней качества или моделей контроля.",[1155,1156],"«Риск ИИ — это риск модели».","Риск может возникать в данных, промптах, поиске, идентификации, инструментах, интерфейсах, операциях, пользователях и организационных процессах.",[1158,1159],"«Участие человека в цикле делает агента безопасным».","Одобрение человеком помогает только если проверяющий обладает полезным контекстом, полномочиями, временем и чёткой точкой принятия решения.",[1161,1162],"«Успешный пилот доказывает готовность к корпоративному внедрению».","Пилот доказывает ограниченную работоспособность; готовность к корпоративному внедрению также требует интеграции, управления, жизненного цикла, операций и воспроизводимых контролей.",{},{"id":1165,"data":1166,"type":42,"tunes":1168},"h-framework",{"text":1167,"level":247},"Практическая последовательность решений по архитектуре корпоративного ИИ",{},{"id":1170,"data":1171,"type":349,"tunes":1210},"decision-framework",{"steps":1172,"title":1209,"orientation":348},[1173,1176,1179,1182,1185,1188,1191,1194,1197,1200,1203,1206],{"label":1174,"description":1175},"1. Определите бизнес-способность","Укажите пользователя, решение или рабочий процесс, ожидаемую ценность и ответственного владельца.",{"label":1177,"description":1178},"2. Классифицируйте данные и полномочия","Определите системы учёта, персональные\u002Fконфиденциальные данные, требования к хранению, актуальности и происхождению.",{"label":1180,"description":1181},"3. Определите границы идентификации и действий","Установите, кто может читать, генерировать, решать, одобрять и изменять внешние системы.",{"label":1183,"description":1184},"4. Выберите ответственность решения и платформы","Решите, что относится к рабочей нагрузке, что можно совместно использовать и что остаётся в ведении предприятия.",{"label":1186,"description":1187},"5. Оцените зависимость от провайдера и среды выполнения","Оцените управляемые, самостоятельно размещённые, частные, суверенные или гибридные варианты с учётом реальных требований.",{"label":1189,"description":1190},"6. Сопоставьте риски и нормативные обязательства","Определите уровень риска, организационные контроли и применимые юридические обязанности для конкретной системы.",{"label":1192,"description":1193},"7. Определите измеримую приёмку","Создайте критерии оценки качества, надёжности, безопасности, поиска, стоимости и операционного поведения.",{"label":1195,"description":1196},"8. Зафиксируйте архитектурные решения","Сохраните обоснование, альтернативы, компромиссы, зависимости и условия, которые потребуют пересмотра.",{"label":1198,"description":1199},"9. Свяжите архитектуру с реализацией","Переведите проект в бэклог, этапы, критерии приёмки, технические работы и ответственность.",{"label":1201,"description":1202},"10. Проверьте в условиях, приближенных к производственным","Тестируйте реалистичные сценарии идентификации, данных, сбоев, задержек, провайдера, инструментов и восстановления, а не только чистые демонстрации.",{"label":1204,"description":1205},"11. Установите операции и контроль изменений","Определите мониторинг, реагирование на инциденты, обновления модели\u002Fпровайдера, регрессионное тестирование, откат и вывод из эксплуатации.",{"label":1207,"description":1208},"12. Возвращайте доказательства в архитектуру","Используйте производственные наблюдения, аудиты, инциденты и оценки для пересмотра решений и контролей.","От возможности к управляемой корпоративной способности",{},{"id":1212,"data":1213,"type":42,"tunes":1215},"h-checklist",{"text":1214,"level":247},"Чек-лист архитектуры корпоративного ИИ",{},{"id":1217,"data":1218,"type":292,"tunes":1265},"checklist-table",{"content":1219,"stretched":43,"withHeadings":14},[1220,1223,1226,1229,1232,1235,1238,1241,1244,1247,1250,1253,1256,1259,1262],[1221,1222],"Вопрос","Ожидаемое доказательство",[1224,1225],"Какую бизнес-способность поддерживает этот ИИ?","Названный владелец, группа пользователей, предполагаемое решение\u002Fрабочий процесс и цель приёмки.",[1227,1228],"Какой источник является авторитетным для каждого важного факта?","Системы учёта, авторитет документов, правила происхождения и актуальности.",[1230,1231],"Какие идентификаторы существуют?","Идентификаторы человека, приложения, сервиса, агента, арендатора\u002Fорганизации и провайдера различимы.",[1233,1234],"Что может читать ИИ?","Источники данных с ограничением по авторизации и явные правила для конфиденциальных данных.",[1236,1237],"Что может изменять ИИ?","Инвентаризация инструментов\u002Fдействий, модель разрешений, путь одобрения и отката.",[1239,1240],"Какой провайдер\u002Fмодель используется и почему?","Архитектурное решение, включая качество, безопасность, стоимость, регион, жизненный цикл и соображения выхода.",[1242,1243],"Что произойдёт, если провайдер недоступен?","Режим пониженной функциональности, резервный вариант, отказ или план непрерывности.",[1245,1246],"Как оценивается качество?","Наборы данных для конкретных задач, оценщики, пороги, критерии регрессии и условия валидности.",[1248,1249],"Что логируется?","Схема телеметрии, редактирование, доступ, хранение и цель аудита.",[1251,1252],"Кто отвечает за риск ИИ?","Названная организационная ответственность, связанная с конкретной системой.",[1254,1255],"Какая юридическая классификация применяется?","Документированная оценка на основе действующего законодательства и фактического сценария использования.",[1257,1258],"Как утверждаются изменения модели\u002Fпромпта\u002Fпоиска?","Версионирование, оценка, запись архитектуры\u002Fизменений и этап развёртывания.",[1260,1261],"Кто реагирует на инцидент с ИИ?","Регламент, технический владелец, бизнес\u002Fдомен эскалация и эскалация к провайдеру.",[1263,1264],"Как система выводится из эксплуатации?","Очистка данных, отзыв доступа, выход от провайдера, сохранение доказательств и удаление зависимостей.",{},{"id":1267,"data":1268,"type":42,"tunes":1270},"h-edge",{"text":1269,"level":247},"Крайние случаи и ограничения",{},{"id":1272,"data":1273,"type":218,"tunes":1275},"p-edge-1",{"text":1274},"Небольшая компания с одним сценарием использования ИИ с низким риском может не нуждаться в формальной функции архитектуры корпоративного ИИ. Те же принципы можно применять в лёгкой форме: чёткий владелец, одобренные данные, явный провайдер, базовая оценка, контроль доступа и операционная ответственность.",{},{"id":1277,"data":1278,"type":218,"tunes":1280},"p-edge-2",{"text":1279},"Высоко регулируемая организация может нуждаться в более строгом разделении, независимой валидации, формальных процессах соответствия, локальном хостинге или работе в изолированной среде. Эти контроли определяются сценарием использования и нормативной средой, а не словом «корпоративный».",{},{"id":1282,"data":1283,"type":218,"tunes":1285},"p-edge-3",{"text":1284},"Организация также может использовать в основном SaaS-продукты ИИ, а не создавать системы ИИ. Корпоративная архитектура всё равно важна, поскольку идентификация, доступ к данным, договорные условия, теневой ИИ, хранение, аудит и концентрация поставщиков остаются организационными вопросами.",{},{"id":1287,"data":1288,"type":218,"tunes":1290},"p-edge-4",{"text":1289},"Централизованная платформа не обязательна. Федеративная ответственность за платформу может быть оправдана, когда домены имеют существенно разные требования, при условии что ответственность за идентификацию, риски, инвентаризацию и совместимость на уровне предприятия остаётся согласованной.",{},{"id":1292,"data":1293,"type":42,"tunes":1295},"h-change-answer",{"text":1294,"level":247},"Что могло бы изменить этот ответ?",{},{"id":1297,"data":1298,"type":218,"tunes":1300},"p-change-answer-1",{"text":1299},"Архитектура меняется, когда меняются толерантность организации к риску, нормативная классификация, чувствительность данных, географический охват, стратегия провайдера, внутренние навыки или критичность для бизнеса. Публичный маркетинговый помощник и система, участвующая в решениях о трудоустройстве, финансах, здравоохранении или критической инфраструктуре, не должны наследовать одинаковые модели контроля.",{},{"id":1302,"data":1303,"type":218,"tunes":1305},"p-change-answer-2",{"text":1304},"Реализация также меняется по мере развития стандартов, регулирования и платформ ИИ. NIST AI RMF 1.0 в настоящее время пересматривается, EU AI Act имеет поэтапные даты применения, а возможности моделей и провайдеров продолжают быстро меняться. Поэтому архитектура корпоративного ИИ должна сохранять стабильные границы ответственности, рассматривая механизмы провайдеров и нормативные детали как версионируемые входные данные.",{},{"id":1307,"data":1308,"type":42,"tunes":1310},"h-related",{"text":1309,"level":247},"Связанные канонические знания",{},{"id":1312,"data":1313,"type":218,"tunes":1315},"p-related-1",{"text":1314},"Архитектура корпоративного ИИ строится на архитектуре решений и платформы. Уровень решения описывает одну рабочую нагрузку. Уровень платформы описывает многоразовые возможности ИИ. Уровень предприятия связывает и то и другое с общеорганизационными данными, идентификацией, управлением, рисками, закупками и операциями.",{},{"id":1317,"data":1318,"type":218,"tunes":1320},"p-related-2",{"text":1319},"Генерация с дополненной выборкой (RAG) — лишь один из механизмов внутри этой архитектуры. RAG может улучшить доступ к корпоративным знаниям, но сам по себе не решает вопросы авторитетности данных, разрешений, управления или достоверности ответов.",{},{"id":1322,"data":1323,"type":1328,"tunes":1329},"ref-rag",{"url":1324,"title":1325,"excerpt":1326,"ctaLabel":1327},"https:\u002F\u002Fstajic.de\u002Fru\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works","Что такое RAG? Самое простое объяснение того, как это работает","Простое объяснение того, как извлечение внешних знаний подключается к языковой модели, не превращая поиск в источник истины.","Читать основы RAG","referralArticle",{},{"id":1331,"data":1332,"type":218,"tunes":1334},"p-related-3",{"text":1333},"Для корпоративных сценариев с большим объёмом доказательств обоснованность ответа также требует явной границы: вывод считается подтверждённым только в рамках доказательств, версии, области применения и допущений, при которых он был получен.",{},{"id":1336,"data":1337,"type":1328,"tunes":1342},"ref-avb",{"url":1338,"title":1339,"excerpt":1340,"ctaLabel":1341},"https:\u002F\u002Fstajic.de\u002Fru\u002Fblog\u002Fthe-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers","Граница обоснованности ответа: недостающий слой между релевантностью и надёжными ответами ИИ","Фреймворк для явного определения условий, при которых утверждение ИИ остаётся подтверждённым, и того, какие изменения требуют ограничения или пересчёта.","Читать «Границу обоснованности ответа»",{},{"id":1344,"data":1345,"type":218,"tunes":1347},"p-related-4",{"text":1346},"Смежные корпоративные темы включают управление ИИ, частный ИИ, суверенный ИИ, изолированный ИИ, многоарендную архитектуру ИИ, RBAC против изоляции арендаторов, абстракцию поставщиков, маршрутизацию моделей и производственную архитектуру ИИ.",{},{"id":1349,"data":1350,"type":42,"tunes":1352},"h-faq",{"text":1351,"level":247},"Часто задаваемые вопросы",{},{"id":1354,"data":1355,"type":1354,"tunes":1390},"faq",{"items":1356,"title":1389},[1357,1361,1365,1369,1373,1377,1381,1385],{"id":1358,"answer":1359,"question":1360},"faq1","Корпоративная архитектура ИИ — это общеорганизационная архитектура, определяющая, как решения ИИ и общие возможности ИИ интегрируются с бизнес-ответственностью, корпоративными данными, идентификацией, безопасностью, поставщиками, управлением, рисками, соответствием, жизненным циклом и операциями.","Что такое корпоративная архитектура ИИ?",{"id":1362,"answer":1363,"question":1364},"faq2","Нет. Платформа ИИ предоставляет многоразовые технические возможности, такие как доступ к моделям, поиск, среды выполнения агентов и наблюдаемость. Корпоративная архитектура ИИ определяет, как эта платформа и отдельные решения ИИ вписываются в более широкую архитектуру и операционную модель организации.","Корпоративная архитектура ИИ — это то же самое, что платформа ИИ?",{"id":1366,"answer":1367,"question":1368},"faq3","Нет. Стандартизация может снизить сложность, но разные рабочие нагрузки могут требовать разных поставщиков, моделей, регионов, уровней контроля или модальностей. Важное требование — явная политика и ответственность за жизненный цикл.","Требует ли корпоративный ИИ одной центральной модели?",{"id":1370,"answer":1371,"question":1372},"faq4","Потому что полученная или сгенерированная информация не является автоматически авторитетной. Корпоративные системы должны сохранять, какой источник является системой записи, актуальны ли данные, кто может получить к ним доступ и как сгенерированное утверждение можно проследить до доказательств.","Почему авторитетность данных важна для корпоративного ИИ?",{"id":1374,"answer":1375,"question":1376},"faq5","Управление ИИ определяет политики, подотчётность и права принятия решений. Корпоративная архитектура ИИ определяет границы систем, интерфейсы, потоки данных и технические механизмы, с помощью которых эти политики могут быть реализованы и подтверждены.","В чём разница между управлением ИИ и корпоративной архитектурой ИИ?",{"id":1378,"answer":1379,"question":1380},"faq6","Нет. Обязательства зависят от таких факторов, как роль организации, вариант использования и классификация системы, а также соответствующие действующие положения. Правовая классификация должна выполняться для конкретной системы в соответствии с действующим законодательством.","Применяется ли Закон ЕС об ИИ ко всем корпоративным системам ИИ одинаково?",{"id":1382,"answer":1383,"question":1384},"faq7","Нет. Пилот демонстрирует ограниченную возможность. Корпоративное развёртывание также требует идентификации, авторитетности данных, безопасности, управления поставщиками, оценки, жизненного цикла, реагирования на инциденты, мониторинга, соответствия и подотчётной операционной ответственности.","Достаточно ли успешного пилота ИИ для корпоративного развёртывания?",{"id":1386,"answer":1387,"question":1388},"faq8","Только когда требование оправдывает дополнительный контроль и операционную ответственность. Управляемые, частные, суверенные, самостоятельно размещённые и гибридные подходы — это архитектурные варианты, пригодность которых зависит от требований к данным, регулированию, доступности, стоимости, возможностям и эксплуатации.","Следует ли предприятиям размещать ИИ на собственных серверах?","Часто задаваемые вопросы о корпоративной архитектуре ИИ",{},{"id":1392,"data":1393,"type":42,"tunes":1395},"h-glossary",{"text":1394,"level":247},"Глоссарий",{},{"id":1397,"data":1398,"type":1397,"tunes":1439},"glossary",{"title":1399,"entries":1400},"Ключевые термины корпоративной архитектуры ИИ",[1401,1405,1409,1413,1417,1421,1424,1427,1431,1435],{"term":1402,"anchor":1403,"definition":1404},"Корпоративная архитектура ИИ","enterprise-ai-architecture","Общеорганизационная архитектура, определяющая, как системы ИИ, платформы, данные, идентификации, поставщики, средства контроля рисков и операции сочетаются друг с другом.",{"term":1406,"anchor":1407,"definition":1408},"Система управления ИИ","ai-management-system","Организационная система управления для установления политик, целей и процессов, связанных с ИИ; ISO\u002FIEC 42001 определяет требования к такой системе.",{"term":1410,"anchor":1411,"definition":1412},"Авторитетность данных","data-authority","Правило, определяющее, какой источник или система является авторитетным для конкретного факта, записи, состояния или контекста решения.",{"term":1414,"anchor":1415,"definition":1416},"Система записи","system-of-record","Авторитетная система, отвечающая за официальное текущее состояние бизнес-записи или сущности предметной области.",{"term":1418,"anchor":1419,"definition":1420},"Реестр ИИ","ai-inventory","Структурированная запись вариантов использования ИИ, владельцев, моделей\u002Fпоставщиков, данных, инструментов, рисков, доказательств оценки, состояния жизненного цикла и связанных средств контроля.",{"term":609,"anchor":1422,"definition":1423},"provider-dependency","Техническая, договорная и операционная зависимость, возникающая, когда рабочая нагрузка ИИ зависит от внешней модели или управляемой платформы.",{"term":746,"anchor":1425,"definition":1426},"human-oversight","Определённая проверка, утверждение, вмешательство или эскалация со стороны человека, применяемые там, где этого требуют последствия системы, неопределённость или регулирование.",{"term":1428,"anchor":1429,"definition":1430},"GenAIOps","genaiops","Операционные практики для рабочих нагрузок генеративного ИИ, охватывающие выбор модели, подсказки, данные обоснования, оценку, развёртывание, мониторинг и управление жизненным циклом.",{"term":1432,"anchor":1433,"definition":1434},"Управление рисками ИИ","ai-risk-management","Организационный процесс выявления, оценки, обработки, мониторинга и пересмотра рисков, связанных с системами ИИ на протяжении их жизненного цикла.",{"term":1436,"anchor":1437,"definition":1438},"Архитектурное решение","architecture-decision","Существенный проектный выбор вместе с его контекстом, обоснованием, альтернативами, компромиссами и статусом жизненного цикла.",{},{"id":1441,"data":1442,"type":42,"tunes":1444},"h-conclusion",{"text":1443,"level":247},"Заключение",{},{"id":1446,"data":1447,"type":218,"tunes":1449},"p-conclusion-1",{"text":1448},"Когда ИИ приходит в компанию, предприятие приобретает не просто новый программный компонент. Оно приобретает новый класс поведения и зависимостей, который пронизывает данные, идентификацию, поставщиков, бизнес-решения, безопасность, операции, управление и управление изменениями.",{},{"id":1451,"data":1452,"type":218,"tunes":1454},"p-conclusion-2",{"text":1453},"Архитектурный ответ — не централизовать всё. Он состоит в том, чтобы сделать ответственности явными: какие данные авторитетны, какие идентификации могут действовать, какие поставщики одобрены, какие средства контроля являются общими, какие решения остаются за предметной областью, как оценивается поведение, как обрабатываются инциденты и как система меняется со временем.",{},{"id":1456,"data":1457,"type":218,"tunes":1459},"p-conclusion-3",{"text":1458},"В этом и состоит ключевое отличие корпоративной архитектуры ИИ: она превращает изолированную возможность ИИ в организационно управляемую систему, не делая вид, что модели, платформы, бизнес-домены и корпоративные средства контроля — это одно и то же.",{},{"id":1461,"data":1462,"type":42,"tunes":1464},"h-sources",{"text":1463,"level":247},"Первоисточники и актуальные рекомендации",{},{"id":1466,"data":1467,"type":218,"tunes":1469},"p-sources-note",{"text":1468},"Внешние стандарты, регулирование и актуальные рекомендации по архитектуре поставщиков ниже были проверены 8 октября 2026 года. Разделы, относящиеся к конкретному проекту, явно помечены как оригинальные доказательства проекта, и их не следует воспринимать как утверждения об общеотраслевых фактах.",{},{"id":1471,"data":1472,"type":1478,"tunes":1479},"src-iso-42001",{"link":1473,"meta":1474},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F42001",{"image":1475,"title":1476,"description":1477},{"url":278},"ISO\u002FIEC 42001:2023 — Система управления искусственным интеллектом","Международный стандарт, определяющий требования к созданию, внедрению, поддержанию и постоянному улучшению системы управления ИИ в организациях.","linkTool",{},{"id":1481,"data":1482,"type":1478,"tunes":1488},"src-iso-23894",{"link":1483,"meta":1484},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F77304.html",{"image":1485,"title":1486,"description":1487},{"url":278},"ISO\u002FIEC 23894:2023 — Руководство по управлению рисками ИИ","Международное руководство по интеграции управления рисками, специфичными для ИИ, в деятельность и функции организации.",{},{"id":1490,"data":1491,"type":1478,"tunes":1497},"src-nist-rmf",{"link":1492,"meta":1493},"https:\u002F\u002Fwww.nist.gov\u002Fitl\u002Fai-risk-management-framework",{"image":1494,"title":1495,"description":1496},{"url":278},"NIST AI Risk Management Framework","Добровольный фреймворк NIST, ориентированный на жизненный цикл, для управления рисками ИИ. NIST заявляет, что AI RMF 1.0 в настоящее время пересматривается.",{},{"id":1499,"data":1500,"type":1478,"tunes":1506},"src-nist-genai",{"link":1501,"meta":1502},"https:\u002F\u002Fwww.nist.gov\u002Fpublications\u002Fartificial-intelligence-risk-management-framework-generative-artificial-intelligence",{"image":1503,"title":1504,"description":1505},{"url":278},"NIST AI 600-1 — Профиль генеративного ИИ","Сопутствующий профиль NIST, описывающий риски, специфичные для генеративного ИИ, и действия по управлению рисками в соответствии с AI RMF.",{},{"id":1508,"data":1509,"type":1478,"tunes":1515},"src-eu-consolidated",{"link":1510,"meta":1511},"https:\u002F\u002Feur-lex.europa.eu\u002Feli\u002Freg\u002F2024\u002F1689\u002F2026-07-27\u002Feng",{"image":1512,"title":1513,"description":1514},{"url":278},"EUR-Lex — Регламент (ЕС) 2024\u002F1689, консолидированный текст","Текущий консолидированный текст Закона об ИИ, использованный для дат применения и регуляторной структуры по состоянию на 8 октября 2026 года.",{},{"id":1517,"data":1518,"type":1478,"tunes":1524},"src-eu-timeline",{"link":1519,"meta":1520},"https:\u002F\u002Fdigital-strategy.ec.europa.eu\u002Fen\u002Fpolicies\u002Fregulatory-framework-ai",{"image":1521,"title":1522,"description":1523},{"url":278},"Европейская комиссия — нормативная база Закона об ИИ","Текущий обзор Комиссии по этапам применения Закона об ИИ, включая применимость в 2026 году и более поздние сроки для отдельных положений о высокорисковых системах.",{},{"id":1526,"data":1527,"type":1478,"tunes":1533},"src-ms-ai",{"link":1528,"meta":1529},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fget-started",{"image":1530,"title":1531,"description":1532},{"url":278},"Microsoft Azure Well-Architected — рабочие нагрузки ИИ","Актуальное руководство по архитектуре рабочих нагрузок ИИ, включая недетерминированное поведение, данные, проектирование приложений и эксплуатацию.",{},{"id":1535,"data":1536,"type":1478,"tunes":1542},"src-ms-ops",{"link":1537,"meta":1538},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fmlops-genaiops",{"image":1539,"title":1540,"description":1541},{"url":278},"Microsoft — MLOps и GenAIOps для рабочих нагрузок ИИ","Актуальное руководство по жизненному циклу эксплуатации, данным, поддержке моделей, развертыванию, мониторингу и непрерывному развитию.",{},{"id":1544,"data":1545,"type":1478,"tunes":1551},"src-ms-responsible",{"link":1546,"meta":1547},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fresponsible-ai",{"image":1548,"title":1549,"description":1550},{"url":278},"Microsoft — ответственный ИИ в рабочих нагрузках Azure","Актуальное руководство, связывающее политику в области ИИ с контролем данных, идентификацией, аудитом агентов, доступом на основе ролей и эксплуатационными мерами защиты.",{},{"id":1553,"data":1554,"type":1478,"tunes":1560},"src-iso-42010",{"link":1555,"meta":1556},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html",{"image":1557,"title":1558,"description":1559},{"url":278},"ISO\u002FIEC\u002FIEEE 42010:2022 — Описание архитектуры","Актуальный стандарт описания архитектуры, поддерживающий явные интересы, точки зрения и взаимосвязи в архитектуре системы.",{},"2.31","Архитектура ИИ для предприятий объясняет, как ИИ меняет корпоративные системы в таких областях, как полномочия на данные, идентификация, разрешения, поставщики, риски, управление, оценка, соответствие требованиям и операции.","\u002Fuploads\u002F2026\u002F10\u002Fenterprise-ai-architecture-what-changes-when-ai-enters-a-company-1791478161363-czrwaq.webp","enterprise-ai-architecture-what-changes-when-ai-enters-a-company-1791478161363-czrwaq","PUBLISHED","2026-10-08T10:48:00.000Z","2026-10-08T16:48:07.244Z","2026-10-08T17:02:36.954Z",{"en":1570,"de":1571,"sr":1572,"es":1573,"fr":1574,"it":1575,"ru":1576,"zh":1577},"\u002Fblog\u002Fenterprise-ai-architecture-what-changes-when-ai-enters-a-company","\u002Fde\u002Fblog\u002Fenterprise-ai-architecture-what-changes-when-ai-enters-a-company","\u002Fsr\u002Fblog\u002Fenterprise-ai-architecture-what-changes-when-ai-enters-a-company","\u002Fes\u002Fblog\u002Fenterprise-ai-architecture-what-changes-when-ai-enters-a-company","\u002Ffr\u002Fblog\u002Fenterprise-ai-architecture-what-changes-when-ai-enters-a-company","\u002Fit\u002Fblog\u002Fenterprise-ai-architecture-what-changes-when-ai-enters-a-company","\u002Fru\u002Fblog\u002Fenterprise-ai-architecture-what-changes-when-ai-enters-a-company","\u002Fzh\u002Fblog\u002Fenterprise-ai-architecture-what-changes-when-ai-enters-a-company",[1579,1582,1586,1590],{"id":1580,"name":1581,"slug":785},59,"Управление и аудит",{"id":1583,"name":1584,"slug":1585},57,"Границы данных","data-boundaries",{"id":1587,"name":1588,"slug":1589},80,"Доступ и идентичность","access-and-identity",{"id":1591,"name":1592,"slug":1593},84,"Политики и границы данных","policy-and-data",{"id":1595,"login":1596,"email":1597,"displayName":1598},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[1600,2744],{"lang":1601,"title":1602,"content":1603,"contentJson":1604,"excerpt":2743},"en","Enterprise AI Architecture: What Changes When AI Enters a Company","{\"time\":1791478189041,\"blocks\":[{\"id\":\"intro\",\"type\":\"paragraph\",\"data\":{\"text\":\"Enterprise AI architecture is the organization-wide architecture required when AI becomes part of a company's real systems, data, decisions and operations. The model is only one component. Once AI is connected to enterprise data, identities, permissions, business processes, external providers and production systems, the architecture must also define data authority, access boundaries, risk ownership, provider dependencies, auditability, evaluation, lifecycle control, compliance and operational responsibility. Enterprise AI therefore differs from both a single AI solution and a shared AI platform: it coordinates how many AI-enabled systems fit into the wider organization.\"},\"tunes\":{}},{\"id\":\"direct-answer\",\"type\":\"callout\",\"data\":{\"variant\":\"info\",\"title\":\"Direct answer\",\"body\":\"\u003Cstrong>What changes when AI enters a company?\u003C\u002Fstrong> Existing enterprise architecture responsibilities expand to include probabilistic model behavior, new data flows, retrieval and grounding, model\u002Fprovider dependencies, AI-specific evaluation, agent\u002Ftool authority, model and prompt lifecycle, AI risk management, transparency obligations, and new operational failure modes. The architecture must connect these concerns to the company's existing identity, security, data, procurement, delivery and governance structures instead of creating a parallel “AI universe.”\"},\"tunes\":{}},{\"id\":\"not-bigger-chatbot\",\"type\":\"callout\",\"data\":{\"variant\":\"warning\",\"title\":\"Enterprise AI is not “a bigger chatbot”\",\"body\":\"A chatbot can be a user interface. Enterprise AI architecture is the system of boundaries behind it: what data the AI may access, which source is authoritative, who may use which capability, whether external providers may receive the data, what actions an agent may execute, how outputs are evaluated, what must be logged, who owns incidents, and how changes are approved and rolled back.\"},\"tunes\":{}},{\"id\":\"current-date\",\"type\":\"callout\",\"data\":{\"variant\":\"note\",\"title\":\"Current-source note — 8 October 2026\",\"body\":\"The architectural principles in this article are intended to be stable. Regulation, standards and vendor capabilities are version-sensitive. ISO\u002FIEC 42001:2023 and ISO\u002FIEC 23894:2023 are current published standards. NIST states that AI RMF 1.0 is being revised. Under the current consolidated EU AI Act text, the Regulation applies generally from 2 August 2026, while specified high-risk provisions have later application dates. Legal classification must always be checked against the current law and the concrete use case.\"},\"tunes\":{}},{\"id\":\"toc\",\"type\":\"tableOfContents\",\"data\":{\"title\":\"Contents\",\"minLevel\":2,\"maxLevel\":3},\"tunes\":{}},{\"id\":\"h-meaning\",\"type\":\"header\",\"data\":{\"text\":\"What enterprise AI architecture really means\",\"level\":2},\"tunes\":{}},{\"id\":\"p-meaning-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Enterprise AI architecture describes how AI capabilities are integrated into an existing organization without breaking the boundaries that already make enterprise systems governable: business ownership, identity, authorization, data classification, system-of-record responsibility, change management, procurement, audit, continuity and operations.\"},\"tunes\":{}},{\"id\":\"p-meaning-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The enterprise architect does not replace the AI Solution Architect or AI Platform Architect. The enterprise scope asks a different question: How do multiple AI solutions and shared AI capabilities fit into the company's target architecture, policies, data landscape, risk model and operating model?\"},\"tunes\":{}},{\"id\":\"p-meaning-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"This makes enterprise AI architecture a coordination discipline across technology and organization. A technically good model integration can still be an enterprise architecture failure if it creates shadow data flows, duplicates identity, bypasses procurement, cannot be audited, has no owner, or cannot be safely changed.\"},\"tunes\":{}},{\"id\":\"scope-comparison\",\"type\":\"comparison\",\"data\":{\"title\":\"Solution, platform and enterprise AI architecture are different scopes\",\"layout\":\"table\",\"columns\":[{\"id\":\"solution\",\"label\":\"AI Solution Architecture\"},{\"id\":\"platform\",\"label\":\"AI Platform Architecture\"},{\"id\":\"enterprise\",\"label\":\"Enterprise AI Architecture\"}],\"rows\":[{\"id\":\"scope\",\"label\":\"Primary scope\",\"values\":[\"\",\"\",\"\"]},{\"id\":\"question\",\"label\":\"Primary question\",\"values\":[\"\",\"\",\"\"]},{\"id\":\"ownership\",\"label\":\"Ownership focus\",\"values\":[\"\",\"\",\"\"]},{\"id\":\"success\",\"label\":\"Success condition\",\"values\":[\"\",\"\",\"\"]}]},\"tunes\":{}},{\"id\":\"h-simple\",\"type\":\"header\",\"data\":{\"text\":\"The simplest example\",\"level\":2},\"tunes\":{}},{\"id\":\"p-simple-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"A company starts with one internal document assistant. The first version searches approved documents and sends retrieved context to a language model. At solution level, this may look straightforward.\"},\"tunes\":{}},{\"id\":\"p-simple-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Then a second team wants AI for customer support. A third wants an agent that can update tickets. Finance wants document analysis. HR wants an internal assistant. Developers want coding agents. Suddenly the company has several providers, several data classes, different user groups, overlapping retrieval indexes, different logging rules, new tool permissions, duplicated secrets and unclear ownership.\"},\"tunes\":{}},{\"id\":\"p-simple-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"At that point, the question is no longer “Does the assistant work?” The enterprise question becomes: Which capabilities are approved, who owns them, what data can cross which boundary, how are identities and permissions enforced, which providers are acceptable, what must be audited, and how can the organization change models or suppliers without losing control?\"},\"tunes\":{}},{\"id\":\"simple-flow\",\"type\":\"processFlow\",\"data\":{\"title\":\"From isolated AI feature to enterprise architecture\",\"orientation\":\"auto\",\"steps\":[{\"label\":\"1. Isolated use case\",\"description\":\"One team connects one model to one workflow and validates local value.\"},{\"label\":\"2. Shared dependencies appear\",\"description\":\"Multiple teams need providers, model access, retrieval, identity, secrets, observability and evaluation.\"},{\"label\":\"3. Enterprise boundaries are crossed\",\"description\":\"AI touches regulated data, systems of record, external vendors, privileged actions and business decisions.\"},{\"label\":\"4. Ownership must become explicit\",\"description\":\"Business, architecture, data, security, legal\u002Fcompliance, procurement and operations need defined responsibilities.\"},{\"label\":\"5. Lifecycle becomes organizational\",\"description\":\"Model changes, prompt changes, provider changes and new agent capabilities become governed changes rather than local developer edits.\"},{\"label\":\"6. Architecture becomes repeatable\",\"description\":\"The organization establishes reusable patterns, decision records, controls, exceptions and validation gates for new AI workloads.\"}]},\"tunes\":{}},{\"id\":\"h-stop\",\"type\":\"header\",\"data\":{\"text\":\"Where the simple example stops\",\"level\":2},\"tunes\":{}},{\"id\":\"p-stop-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Enterprise architecture does not mean that every AI component must be centralized. Some capabilities should be shared; others must remain domain-owned. Finance, HR, engineering and customer support may legitimately require different data boundaries, providers, evaluation criteria and human-approval rules.\"},\"tunes\":{}},{\"id\":\"p-stop-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The enterprise objective is therefore not one model, one vector database or one universal assistant. The objective is coherent architecture with explicit variation: common policies and reusable capabilities where they reduce risk and duplication, plus controlled exceptions where business or regulatory requirements differ.\"},\"tunes\":{}},{\"id\":\"h-layers\",\"type\":\"header\",\"data\":{\"text\":\"What changes in the architecture when AI enters the enterprise\",\"level\":2},\"tunes\":{}},{\"id\":\"h-business\",\"type\":\"header\",\"data\":{\"text\":\"1. Business ownership becomes part of the technical architecture\",\"level\":3},\"tunes\":{}},{\"id\":\"p-business-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Traditional applications already need business owners. AI makes that requirement more visible because acceptable behavior cannot be defined only by uptime and functional correctness. Someone must own the intended use, unacceptable use, output quality, escalation path and consequences of wrong or inappropriate results.\"},\"tunes\":{}},{\"id\":\"p-business-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"A model team cannot decide alone whether an answer is acceptable for HR, finance, legal or customer-facing use. Enterprise AI architecture therefore connects technical design to an explicit business capability, accountable owner, user group and decision context.\"},\"tunes\":{}},{\"id\":\"h-data-authority\",\"type\":\"header\",\"data\":{\"text\":\"2. Data access is not enough — data authority must be defined\",\"level\":3},\"tunes\":{}},{\"id\":\"p-data-authority-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Enterprise AI frequently combines operational databases, documents, search indexes, vector stores, data warehouses, SaaS systems and external knowledge. The architecture must distinguish where information is stored from which source is authoritative for a given claim or action.\"},\"tunes\":{}},{\"id\":\"p-data-authority-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"A vector index can improve retrieval but should not silently become the company's system of record. A model response can summarize an ERP record but should not replace the ERP as the authoritative source. Cached context can improve latency but becomes unsafe when permissions or underlying business state change.\"},\"tunes\":{}},{\"id\":\"p-data-authority-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Enterprise AI therefore needs provenance, freshness, source classification, authorization propagation and invalidation rules in addition to ordinary data integration.\"},\"tunes\":{}},{\"id\":\"authority-rule\",\"type\":\"callout\",\"data\":{\"variant\":\"success\",\"title\":\"Enterprise data rule\",\"body\":\"\u003Cstrong>The AI system may transform, retrieve and reason over enterprise data without becoming the authority for that data.\u003C\u002Fstrong> The architecture should preserve a path back to the authoritative source whenever the use case requires evidence, verification or consequential action.\"},\"tunes\":{}},{\"id\":\"h-identity\",\"type\":\"header\",\"data\":{\"text\":\"3. Identity becomes multi-layered\",\"level\":3},\"tunes\":{}},{\"id\":\"p-identity-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Enterprise AI has more identities than the human user. A request may involve a user identity, application identity, service identity, agent identity, provider credential, tool credential and tenant or organizational context.\"},\"tunes\":{}},{\"id\":\"p-identity-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"These identities should not be collapsed into one shared API key. Authorization must remain attributable to the correct principal, and privileged tools should receive only the authority required for the current operation.\"},\"tunes\":{}},{\"id\":\"p-identity-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"For agentic systems, this becomes especially important: a model can propose an action, but the runtime must decide whether the requesting identity is allowed to execute it. Model capability is not authorization.\"},\"tunes\":{}},{\"id\":\"h-permissions\",\"type\":\"header\",\"data\":{\"text\":\"4. Permissions move from content access to action authority\",\"level\":3},\"tunes\":{}},{\"id\":\"p-permissions-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"A read-only assistant mainly needs controlled access to information. An enterprise agent can create tickets, modify records, send messages, trigger workflows or operate external systems. That introduces a different risk class because the system can change state rather than merely describe it.\"},\"tunes\":{}},{\"id\":\"p-permissions-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The architecture should separate read, write, approval and administrative capabilities; define human-in-the-loop points where consequence justifies them; and preserve an audit trail that identifies what was requested, what was approved and what actually changed.\"},\"tunes\":{}},{\"id\":\"h-provider\",\"type\":\"header\",\"data\":{\"text\":\"5. The AI provider becomes an enterprise dependency\",\"level\":3},\"tunes\":{}},{\"id\":\"p-provider-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Calling a model API is also a supplier relationship. The architecture may depend on provider availability, service terms, data-processing conditions, supported regions, model lifecycle, quotas, pricing, API compatibility, security controls and change notices.\"},\"tunes\":{}},{\"id\":\"p-provider-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"This means provider selection is not only a benchmark decision. Procurement, security, privacy, legal review, continuity planning and exit strategy can all become architecture inputs.\"},\"tunes\":{}},{\"id\":\"p-provider-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Provider abstraction can reduce coupling, but only where the underlying capabilities are genuinely portable. Tool use, structured output, context limits, multimodality, safety controls, fine-tuning and hosted-agent features may differ materially between providers.\"},\"tunes\":{}},{\"id\":\"h-risk\",\"type\":\"header\",\"data\":{\"text\":\"6. AI risk becomes a lifecycle process\",\"level\":3},\"tunes\":{}},{\"id\":\"p-risk-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"AI risk is not completed by one approval before launch. The model, prompt, retrieval corpus, tool set, provider, user population and surrounding business process can all change after deployment. The risk profile changes with them.\"},\"tunes\":{}},{\"id\":\"p-risk-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"ISO\u002FIEC 23894:2023 explicitly addresses integration of AI risk management into organizational activities and functions. NIST AI RMF similarly frames risk management across the lifecycle. Enterprise architecture should therefore make risk review part of change and operations rather than an isolated compliance document.\"},\"tunes\":{}},{\"id\":\"p-risk-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Risk should also be proportional. A summarization assistant and an autonomous system that changes production records should not receive identical controls merely because both use an LLM.\"},\"tunes\":{}},{\"id\":\"h-management-system\",\"type\":\"header\",\"data\":{\"text\":\"7. Governance becomes an operating system, not a policy PDF\",\"level\":3},\"tunes\":{}},{\"id\":\"p-management-system-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"ISO\u002FIEC 42001:2023 defines requirements for establishing, implementing, maintaining and continually improving an AI management system. The architecture consequence is important: governance must connect policy to real inventories, ownership, processes, controls, evidence, reviews and improvement loops.\"},\"tunes\":{}},{\"id\":\"p-management-system-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"An enterprise AI policy that is not connected to provider approval, identity, logging, change management, evaluation and incident response has limited architectural effect. The organization needs mechanisms that make policy enforceable or at least observable.\"},\"tunes\":{}},{\"id\":\"h-eval\",\"type\":\"header\",\"data\":{\"text\":\"8. Evaluation becomes a production control\",\"level\":3},\"tunes\":{}},{\"id\":\"p-eval-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Traditional acceptance testing assumes that the same input normally produces the same deterministic result. Generative AI can be nondeterministic, sensitive to context and dependent on changing external knowledge. Production acceptance therefore needs task-specific evals, regression suites and observable thresholds rather than only unit tests.\"},\"tunes\":{}},{\"id\":\"p-eval-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The platform can provide reusable evaluation infrastructure, but the enterprise still needs ownership of domain ground truth and release gates. A central AI team cannot invent the correct answer for every business domain.\"},\"tunes\":{}},{\"id\":\"p-eval-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Model, prompt, retrieval and tool changes should be traceable to evaluation evidence where the change can materially affect output behavior.\"},\"tunes\":{}},{\"id\":\"h-observability\",\"type\":\"header\",\"data\":{\"text\":\"9. Observability must include behavior, data and model context\",\"level\":3},\"tunes\":{}},{\"id\":\"p-observability-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"CPU, memory and HTTP error rates are not sufficient for AI workloads. Production observability may need model\u002Fprovider identifiers, latency, token usage, cost, retrieval results, tool calls, refusal behavior, evaluation scores, safety events and failure classifications.\"},\"tunes\":{}},{\"id\":\"p-observability-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"At the same time, AI telemetry can contain sensitive data. Prompt and response logs may become a shadow data store. Enterprise architecture must therefore define what can be logged, how it is redacted, who can access it, how long it is retained and when detailed tracing must be disabled.\"},\"tunes\":{}},{\"id\":\"h-lifecycle\",\"type\":\"header\",\"data\":{\"text\":\"10. AI components need explicit lifecycle ownership\",\"level\":3},\"tunes\":{}},{\"id\":\"p-lifecycle-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Models can be renamed, replaced, retired or changed by providers. Embedding models can invalidate an index strategy. Prompt templates and system instructions can change behavior. Agent runtimes and protocols can evolve. External tools can change their schemas and permissions.\"},\"tunes\":{}},{\"id\":\"p-lifecycle-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Enterprise architecture must decide who detects these changes, who tests them, who approves them, how consumers are notified, how rollback works and what evidence is required before a new version becomes the default.\"},\"tunes\":{}},{\"id\":\"h-operations\",\"type\":\"header\",\"data\":{\"text\":\"11. Incident response must include AI-specific failure modes\",\"level\":3},\"tunes\":{}},{\"id\":\"p-operations-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"An AI incident may be a provider outage, data leak, prompt-injection path, authorization failure, retrieval contamination, unexpected model behavior, unsafe tool execution, cost spike, stale knowledge, evaluation regression or a change in external model behavior.\"},\"tunes\":{}},{\"id\":\"p-operations-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The enterprise runbook therefore needs more than “restart the service.” It may require disabling a model route, revoking tool access, freezing a corpus, changing a prompt version, disabling an agent capability, switching provider, escalating to a domain owner or preserving traces for investigation.\"},\"tunes\":{}},{\"id\":\"h-ownership\",\"type\":\"header\",\"data\":{\"text\":\"Enterprise AI creates cross-functional ownership\",\"level\":2},\"tunes\":{}},{\"id\":\"ownership-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Concern\",\"Typical enterprise owner or contributor\",\"Architecture question\"],[\"Business use\",\"Business owner \u002F product owner\",\"What decision or workflow is AI allowed to support or automate?\"],[\"Solution architecture\",\"AI \u002F solution architect\",\"How does the concrete workload meet its functional and quality requirements?\"],[\"Shared AI capabilities\",\"AI platform \u002F platform engineering\",\"Which reusable model, retrieval, agent and observability services are provided?\"],[\"Enterprise coherence\",\"Enterprise architecture\",\"How do AI systems fit target architecture, standards, integration patterns and organizational ownership?\"],[\"Data authority\",\"Data owner \u002F domain owner\",\"Which data is authoritative, current, permitted and sufficiently governed?\"],[\"Identity and security\",\"IAM \u002F security architecture\",\"Which identities can access which data and execute which actions?\"],[\"Risk and compliance\",\"Risk \u002F legal \u002F compliance \u002F privacy\",\"Which obligations, prohibited uses, controls and evidence apply to this use case?\"],[\"Supplier dependency\",\"Procurement \u002F vendor management \u002F architecture\",\"What contractual, operational and exit risks arise from the provider?\"],[\"Operations\",\"SRE \u002F operations \u002F platform owner\",\"How is the system monitored, supported, degraded, recovered and changed?\"],[\"Domain acceptance\",\"Business\u002Fdomain specialists\",\"What counts as a correct, safe or useful result in this domain?\"]]},\"tunes\":{}},{\"id\":\"ownership-warning\",\"type\":\"callout\",\"data\":{\"variant\":\"warning\",\"title\":\"A RACI chart is not architecture by itself\",\"body\":\"Responsibility matrices are useful only when they connect to real system boundaries, approvals, data ownership, interfaces, runbooks and change processes. Enterprise AI needs accountable ownership that can be traced to technical controls and operational actions.\"},\"tunes\":{}},{\"id\":\"h-model\",\"type\":\"header\",\"data\":{\"text\":\"A practical enterprise AI architecture model\",\"level\":2},\"tunes\":{}},{\"id\":\"model-note\",\"type\":\"callout\",\"data\":{\"variant\":\"note\",\"title\":\"Proposed layered model\",\"body\":\"The following model is a practical synthesis for reasoning about enterprise AI architecture. It is not presented as an ISO or NIST standard. Its purpose is to make cross-organizational boundaries explicit.\"},\"tunes\":{}},{\"id\":\"enterprise-model-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Layer\",\"Primary responsibility\"],[\"Business and policy\",\"Approved use cases, accountable owners, risk appetite, prohibited uses, human accountability, business acceptance.\"],[\"Identity and authority\",\"User\u002Fservice\u002Fagent identities, roles, tenant or organizational scope, privileged actions, approval paths.\"],[\"Enterprise data\",\"Systems of record, document sources, data products, provenance, classification, retention, freshness and access.\"],[\"AI platform\",\"Provider\u002Fmodel access, retrieval primitives, agent runtimes, tool brokers, evaluation infrastructure, observability, quotas and secrets.\"],[\"AI solutions\",\"Domain workflows, prompts\u002Finstructions, domain retrieval, business logic, acceptance criteria and user experience.\"],[\"Integration and tools\",\"APIs, enterprise applications, workflows, messaging, file systems, external services and action execution.\"],[\"Risk and governance\",\"Inventory, assessment, compliance evidence, exception management, model\u002Fprovider approval, review and audit.\"],[\"Operations and lifecycle\",\"Deployment, monitoring, incidents, releases, model\u002Fprovider changes, deprecation, rollback and continuity.\"]]},\"tunes\":{}},{\"id\":\"p-model-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"The architecture is strongest when each layer can state both its responsibilities and its non-responsibilities. For example, the AI platform can enforce provider policy and collect traces without becoming the source of truth for HR data. A solution can define domain prompts without owning enterprise IAM. A business owner can approve a use case without being expected to operate the inference gateway.\"},\"tunes\":{}},{\"id\":\"h-data-flow\",\"type\":\"header\",\"data\":{\"text\":\"Map enterprise AI as data and authority flows, not boxes\",\"level\":2},\"tunes\":{}},{\"id\":\"enterprise-flow\",\"type\":\"processFlow\",\"data\":{\"title\":\"A consequential enterprise AI request\",\"orientation\":\"auto\",\"steps\":[{\"label\":\"1. Business context\",\"description\":\"The user requests a task under an approved use case with an accountable business owner.\"},{\"label\":\"2. Identity and authorization\",\"description\":\"The system resolves user, application, service and tenant or organizational scope before privileged access.\"},{\"label\":\"3. Authoritative data acquisition\",\"description\":\"The solution reads or retrieves only sources permitted for the current identity and task.\"},{\"label\":\"4. AI processing\",\"description\":\"An approved model\u002Fprovider processes the minimum necessary context under defined routing and data-handling rules.\"},{\"label\":\"5. Tool or action boundary\",\"description\":\"Any state-changing action is independently authorized and may require human approval according to consequence.\"},{\"label\":\"6. Validation\",\"description\":\"The result is checked against solution-specific acceptance, evidence or safety rules.\"},{\"label\":\"7. Audit and observability\",\"description\":\"Permitted metadata, decisions, routes, tool calls and outcomes are recorded without creating uncontrolled sensitive-data logs.\"},{\"label\":\"8. Feedback and lifecycle\",\"description\":\"Failures and evaluation results feed model, prompt, data, policy and process changes through controlled change management.\"}]},\"tunes\":{}},{\"id\":\"h-inventory\",\"type\":\"header\",\"data\":{\"text\":\"An enterprise needs an AI inventory before it can govern AI\",\"level\":2},\"tunes\":{}},{\"id\":\"p-inventory-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Organizations cannot manage AI systems they cannot identify. Enterprise architecture should maintain an inventory at a level that is useful for decisions, not merely a list of model names.\"},\"tunes\":{}},{\"id\":\"inventory-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Inventory field\",\"Why it matters\"],[\"Use case and owner\",\"Connects technology to accountable business purpose.\"],[\"Users and affected parties\",\"Defines who interacts with or is affected by the system.\"],[\"Model\u002Fprovider\",\"Identifies external dependency, capability and lifecycle risk.\"],[\"Data sources\",\"Supports authority, privacy, classification and provenance review.\"],[\"Deployment\u002Fruntime location\",\"Clarifies processing location, connectivity and operational control.\"],[\"Tools\u002Factions\",\"Shows whether the AI can change external state and at what consequence.\"],[\"Human oversight\",\"Records where review, approval or escalation is required.\"],[\"Risk\u002Fclassification\",\"Connects the system to organizational and regulatory controls.\"],[\"Evaluation evidence\",\"Shows what was tested and under which validity conditions.\"],[\"Current version\",\"Allows incidents and regressions to be traced to actual deployed state.\"],[\"Lifecycle state\",\"Proposed, experimental, approved, production, restricted, deprecated or retired.\"]]},\"tunes\":{}},{\"id\":\"h-governance\",\"type\":\"header\",\"data\":{\"text\":\"AI governance and enterprise AI architecture are related but not the same\",\"level\":2},\"tunes\":{}},{\"id\":\"governance-comparison\",\"type\":\"comparison\",\"data\":{\"title\":\"Governance versus architecture\",\"layout\":\"table\",\"columns\":[{\"id\":\"governance\",\"label\":\"AI Governance\"},{\"id\":\"architecture\",\"label\":\"Enterprise AI Architecture\"}],\"rows\":[{\"id\":\"purpose\",\"label\":\"Purpose\",\"values\":[\"\",\"\"]},{\"id\":\"example\",\"label\":\"Example\",\"values\":[\"\",\"\"]},{\"id\":\"failure\",\"label\":\"Failure if isolated\",\"values\":[\"\",\"\"]}]},\"tunes\":{}},{\"id\":\"h-regulation\",\"type\":\"header\",\"data\":{\"text\":\"Regulation becomes an architecture input\",\"level\":2},\"tunes\":{}},{\"id\":\"p-regulation-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"For organizations operating in the European Union, the AI Act can create requirements that affect system design, documentation, transparency, governance and operating processes. The architectural impact depends on the organization's role in the AI value chain and the concrete system classification; not every AI system has the same obligations.\"},\"tunes\":{}},{\"id\":\"p-regulation-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"As of 8 October 2026, the current consolidated text states that the Regulation generally applies from 2 August 2026. Governance rules and obligations for general-purpose AI models began applying earlier, while specified high-risk system provisions have later dates. The Commission also began enforcing new transparency requirements from 2 August 2026 for relevant interactive and synthetic-content systems.\"},\"tunes\":{}},{\"id\":\"p-regulation-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The enterprise architecture lesson is not “put compliance in the model.” It is to make classification, provider\u002Fdeployer role, documentation, transparency, oversight, logging and change evidence traceable to the system that actually implements the use case.\"},\"tunes\":{}},{\"id\":\"legal-note\",\"type\":\"callout\",\"data\":{\"variant\":\"note\",\"title\":\"Legal scope is use-case specific\",\"body\":\"This article describes architecture implications, not legal advice. Enterprise AI architecture should preserve the information needed for legal and compliance specialists to classify the actual system and map obligations to concrete controls. Architecture should not hard-code one regulatory interpretation as if every AI workload had the same status.\"},\"tunes\":{}},{\"id\":\"h-procurement\",\"type\":\"header\",\"data\":{\"text\":\"Procurement and architecture become connected\",\"level\":2},\"tunes\":{}},{\"id\":\"p-procurement-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"An external model or managed AI platform can become a deep dependency even when integration requires only a few API calls. Enterprise architecture should therefore make procurement questions technically concrete.\"},\"tunes\":{}},{\"id\":\"procurement-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Procurement question\",\"Architecture consequence\"],[\"Where is data processed?\",\"Region, network path, data residency and transfer controls.\"],[\"Is customer data retained or used for provider improvement?\",\"Data minimization, contractual controls and provider eligibility.\"],[\"How are models versioned or retired?\",\"Regression testing, compatibility, fallback and lifecycle planning.\"],[\"What are quotas and service limits?\",\"Capacity architecture, admission control and failure handling.\"],[\"How portable is the integration?\",\"Provider abstraction, exit cost and migration effort.\"],[\"What incident information is available?\",\"Observability, forensic capability and support escalation.\"],[\"Which subprocessors or external services are involved?\",\"Dependency mapping and risk assessment.\"],[\"What changes without explicit customer approval?\",\"Change detection, release gates and acceptance strategy.\"]]},\"tunes\":{}},{\"id\":\"h-control\",\"type\":\"header\",\"data\":{\"text\":\"Enterprise architecture decides how much AI control the requirement actually needs\",\"level\":2},\"tunes\":{}},{\"id\":\"control-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Requirement\",\"Possible architectural response\"],[\"Fast access to managed models\",\"Managed provider with enterprise identity, gateway controls and contractual review.\"],[\"Private data with managed orchestration\",\"Managed control plane plus customer-controlled execution or private data plane where supported.\"],[\"Strict locality or sovereignty\",\"Region-restricted, sovereign, private or self-hosted architecture according to the real requirement.\"],[\"Air-gapped environment\",\"Locally hosted models, local retrieval, local tooling, offline update\u002Fdistribution and isolated observability.\"],[\"Provider portability\",\"Application-owned domain state plus adapters and contracts that isolate provider-specific behavior where practical.\"],[\"Highest control of agent semantics\",\"Self-managed or deeply controlled runtime with explicit tool, context, state and lifecycle ownership.\"]]},\"tunes\":{}},{\"id\":\"p-control-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"The most controlled architecture is not automatically the best enterprise architecture. More ownership increases responsibility for patching, capacity, security, testing, model operations and incident response. Enterprise architecture should escalate control only where the requirement justifies the additional operational burden.\"},\"tunes\":{}},{\"id\":\"h-change-management\",\"type\":\"header\",\"data\":{\"text\":\"AI turns change management into a behavioral problem\",\"level\":2},\"tunes\":{}},{\"id\":\"p-change-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"A normal dependency update can alter performance or compatibility. An AI change can also alter behavior. Replacing a model, changing a system prompt, changing retrieval, adding a tool or changing the context policy can modify how the system interprets and responds even if the surrounding application code barely changes.\"},\"tunes\":{}},{\"id\":\"change-process\",\"type\":\"processFlow\",\"data\":{\"title\":\"A production AI change path\",\"orientation\":\"auto\",\"steps\":[{\"label\":\"1. Change identified\",\"description\":\"Model, provider, prompt, retrieval source, tool, policy or runtime change is proposed or detected.\"},{\"label\":\"2. Impact mapped\",\"description\":\"Affected solutions, data classes, users, risk controls, cost, contracts and operational dependencies are identified.\"},{\"label\":\"3. Architecture decision updated\",\"description\":\"Material choices and trade-offs are recorded; superseded decisions remain historically traceable.\"},{\"label\":\"4. Evaluation executed\",\"description\":\"Relevant regression, safety, retrieval, latency, cost and domain tests are run.\"},{\"label\":\"5. Approval applied\",\"description\":\"Approval level follows consequence, risk and organizational policy.\"},{\"label\":\"6. Controlled rollout\",\"description\":\"Versioned release, canary or staged deployment is used where appropriate.\"},{\"label\":\"7. Production evidence collected\",\"description\":\"Telemetry, incidents, feedback and domain outcomes are monitored.\"},{\"label\":\"8. Rollback or acceptance\",\"description\":\"The change is accepted, restricted, rolled back or superseded based on evidence.\"}]},\"tunes\":{}},{\"id\":\"h-nfr-adr\",\"type\":\"header\",\"data\":{\"text\":\"Enterprise AI still needs NFRs and ADRs\",\"level\":2},\"tunes\":{}},{\"id\":\"p-nfr-adr-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"AI does not replace ordinary architecture discipline. Non-functional requirements remain the target conditions: availability, latency, privacy, isolation, auditability, recoverability, cost boundaries, explainability or other quality requirements. Architecture Decision Records preserve the chosen response and its trade-offs.\"},\"tunes\":{}},{\"id\":\"p-nfr-adr-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The AI-specific difference is that some quality attributes must be evaluated probabilistically or empirically. “Answers must be useful” is too vague. A production requirement should identify the task, data, user population, acceptable failure conditions, measurement method and threshold where practical.\"},\"tunes\":{}},{\"id\":\"nfr-adr-chain\",\"type\":\"callout\",\"data\":{\"variant\":\"success\",\"title\":\"Enterprise traceability chain\",\"body\":\"\u003Cstrong>Business need → requirement \u002F NFR → architecture decision → implementation → evaluation \u002F validation → production observation → change decision.\u003C\u002Fstrong> AI adds new variables to this chain; it does not make the chain unnecessary.\"},\"tunes\":{}},{\"id\":\"h-delivery\",\"type\":\"header\",\"data\":{\"text\":\"Enterprise AI architecture must connect to delivery\",\"level\":2},\"tunes\":{}},{\"id\":\"p-delivery-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Architecture that never reaches backlog, implementation, acceptance and operations remains conceptual. Enterprise AI therefore needs traceability from architecture decisions into delivery work and back from implementation evidence into architecture.\"},\"tunes\":{}},{\"id\":\"p-delivery-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Jira and Confluence are examples of tools that can support this separation when used deliberately: Confluence can preserve requirements, architecture, decisions, risks and rationale; Jira can manage actionable delivery work and state. The important principle is the traceability, not the brand of tool.\"},\"tunes\":{}},{\"id\":\"h-original\",\"type\":\"header\",\"data\":{\"text\":\"Original project evidence: Enterprise Aaasaasa 0.1\",\"level\":2},\"tunes\":{}},{\"id\":\"original-evidence-note\",\"type\":\"callout\",\"data\":{\"variant\":\"note\",\"title\":\"Project evidence, not market-proof claim\",\"body\":\"Enterprise Aaasaasa 0.1 is used here as original project evidence for structured enterprise architecture and delivery thinking. It is a PoC \u002F enterprise project context, not evidence of mass customer adoption, enterprise-scale production usage or commercial traction.\"},\"tunes\":{}},{\"id\":\"p-enterprise-aaasaasa-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Enterprise Aaasaasa 0.1 combines platform architecture, SaaS\u002FAPI concepts, internationalization, AI integration and structured project governance. The project was deliberately organized so that requirements, architecture, prototype delivery, validation and closure were separate milestones rather than one undifferentiated implementation phase.\"},\"tunes\":{}},{\"id\":\"p-enterprise-aaasaasa-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The architecture direction includes multi-instance \u002F multi-database concepts together with API, CRUD, i18n and AI capabilities. That matters for enterprise AI because tenant or instance boundaries, database ownership and application services must remain explicit when AI features are added.\"},\"tunes\":{}},{\"id\":\"p-enterprise-aaasaasa-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The project structure also treated architecture delay, scope creep and AI\u002Fdata-protection concerns as project risks rather than discovering them only during implementation. Stakeholders included technical, security, sponsor\u002Fsteering and external-service perspectives, which is closer to the real cross-functional nature of enterprise AI than a model-only prototype.\"},\"tunes\":{}},{\"id\":\"p-enterprise-aaasaasa-4\",\"type\":\"paragraph\",\"data\":{\"text\":\"The useful evidence is therefore the integration of architecture and delivery: business and project structure, milestones, risks, architecture, backend\u002FAPI, frontend\u002FAI work, validation and closure are treated as connected responsibilities. That pattern is reusable even though the project itself should not be presented as proof of external enterprise adoption.\"},\"tunes\":{}},{\"id\":\"enterprise-aaasaasa-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Project element\",\"Enterprise AI architecture lesson\"],[\"Requirements milestone\",\"AI capability must begin from defined need, scope, acceptance and quality constraints.\"],[\"Architecture milestone\",\"Data, API, instance\u002Fdatabase boundaries and AI integration are explicit design work.\"],[\"Prototype milestone\",\"Architecture must become executable enough to expose integration risks.\"],[\"Validation milestone\",\"A functioning prototype is not the same as validated acceptance.\"],[\"Risk register\",\"Scope, architecture delay and AI\u002Fdata-protection concerns are managed as delivery risks.\"],[\"Stakeholder structure\",\"Enterprise AI spans sponsor\u002Fbusiness, architecture, security, external providers and delivery.\"],[\"Project closure\",\"Decisions, remaining risks and validation evidence must survive beyond the implementation sprint.\"]]},\"tunes\":{}},{\"id\":\"h-supporting\",\"type\":\"header\",\"data\":{\"text\":\"Supporting implementation patterns from the wider platform work\",\"level\":2},\"tunes\":{}},{\"id\":\"p-supporting-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Separate implementation work in the wider Aaasaasa platform provides concrete examples of boundaries that enterprise AI architecture must preserve: tenant-scoped RBAC in the CMS, explicit provider\u002Fmodel\u002Fruntime\u002Fpermission separation in Aaasaasa AI Client, and provenance-first retrieval in the Source of Truth Research Engine.\"},\"tunes\":{}},{\"id\":\"p-supporting-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"These projects should not be collapsed into one claimed production platform. Their value here is narrower: they demonstrate implemented patterns for identity scope, provider boundaries, controlled runtime permissions, retrieval provenance and evidence traceability that are directly relevant to enterprise AI.\"},\"tunes\":{}},{\"id\":\"h-standards\",\"type\":\"header\",\"data\":{\"text\":\"How the main standards fit together\",\"level\":2},\"tunes\":{}},{\"id\":\"standards-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Source\",\"What it contributes to enterprise AI architecture\"],[\"ISO\u002FIEC 42001:2023\",\"Organization-level AI management system: policies, objectives, processes, responsibility, monitoring and continual improvement.\"],[\"ISO\u002FIEC 23894:2023\",\"Guidance for integrating AI-specific risk management into organizational activities and functions.\"],[\"NIST AI RMF 1.0\",\"Voluntary lifecycle-oriented framework for managing AI risks; organized around Govern, Map, Measure and Manage.\"],[\"NIST AI 600-1\",\"Generative AI profile extending AI RMF with generative-AI-specific risks and actions.\"],[\"EU AI Act\",\"Binding regulatory obligations in the EU whose applicability depends on role, system type and classification.\"],[\"ISO\u002FIEC\u002FIEEE 42010:2022\",\"General architecture-description concepts for expressing concerns, viewpoints, decisions and relationships.\"]]},\"tunes\":{}},{\"id\":\"p-standards-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"These sources solve different problems. ISO\u002FIEC 42001 is not a replacement for technical architecture. ISO\u002FIEC 23894 and NIST AI RMF do not define one mandatory software stack. The EU AI Act is law, not a platform design pattern. Architecture must translate the applicable organizational, risk and legal requirements into implementable system boundaries and evidence.\"},\"tunes\":{}},{\"id\":\"h-failures\",\"type\":\"header\",\"data\":{\"text\":\"Common enterprise AI failure modes\",\"level\":2},\"tunes\":{}},{\"id\":\"failures-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Failure mode\",\"Why it fails\"],[\"Every team buys AI independently\",\"Creates shadow providers, duplicated secrets, inconsistent data handling and weak leverage over supplier risk.\"],[\"One central AI team owns every domain decision\",\"Centralizes technical control but loses domain accountability and creates a bottleneck.\"],[\"Vector database becomes the source of truth\",\"Retrieval infrastructure silently replaces authoritative systems and freshness rules.\"],[\"One shared API key for all users and agents\",\"Destroys attribution, least privilege and meaningful auditability.\"],[\"Model change deployed like a minor library patch\",\"Behavioral regressions can reach production without domain evaluation.\"],[\"All prompts and outputs are logged forever\",\"Observability creates an uncontrolled sensitive-data repository.\"],[\"Governance is only documentation\",\"Policies exist without enforcement points, evidence or operational ownership.\"],[\"Compliance is delegated to the provider\",\"The organization's own role, use case, data and operational obligations remain unresolved.\"],[\"Agent can call tools because the model supports tool use\",\"Capability is mistaken for authorization.\"],[\"Platform health equals business correctness\",\"Endpoint uptime and model availability do not prove domain answer quality or acceptable outcomes.\"],[\"No exit strategy for model\u002Fprovider dependency\",\"A pricing, policy, capability or availability change becomes an emergency migration.\"]]},\"tunes\":{}},{\"id\":\"h-misconceptions\",\"type\":\"header\",\"data\":{\"text\":\"Common misconceptions\",\"level\":2},\"tunes\":{}},{\"id\":\"misconceptions-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Misconception\",\"Better model\"],[\"“Enterprise AI means a company-wide chatbot.”\",\"The chatbot is one interface; enterprise AI architecture governs the underlying data, identity, provider, runtime, risk and operations.\"],[\"“If we use a reputable model provider, governance is solved.”\",\"Provider controls do not define your use case, data authority, user permissions, business acceptance or legal role.\"],[\"“Private AI means everything must be self-hosted.”\",\"Privacy requirements can lead to several architectures; the required control boundary must be stated precisely.\"],[\"“AI governance belongs to legal, architecture belongs to IT.”\",\"The two disciplines must connect because policy obligations need implementable controls and evidence.\"],[\"“One enterprise model is simpler.”\",\"Standardization can help, but workloads can require different modalities, regions, costs, quality levels or control models.\"],[\"“AI risk is model risk.”\",\"Risk can originate in data, prompts, retrieval, identity, tools, interfaces, operations, users and organizational process.\"],[\"“Human-in-the-loop makes an agent safe.”\",\"Human approval helps only if the reviewer has useful context, authority, time and a clear decision point.\"],[\"“A successful pilot proves enterprise readiness.”\",\"A pilot proves bounded capability; enterprise readiness also requires integration, governance, lifecycle, operations and repeatable controls.\"]]},\"tunes\":{}},{\"id\":\"h-framework\",\"type\":\"header\",\"data\":{\"text\":\"A practical enterprise AI architecture decision sequence\",\"level\":2},\"tunes\":{}},{\"id\":\"decision-framework\",\"type\":\"processFlow\",\"data\":{\"title\":\"From opportunity to governed enterprise capability\",\"orientation\":\"auto\",\"steps\":[{\"label\":\"1. Define the business capability\",\"description\":\"State the user, decision or workflow, expected value and accountable owner.\"},{\"label\":\"2. Classify data and authority\",\"description\":\"Identify systems of record, personal\u002Fconfidential data, retention, freshness and provenance requirements.\"},{\"label\":\"3. Define identity and action boundaries\",\"description\":\"Determine who may read, generate, decide, approve and change external systems.\"},{\"label\":\"4. Select solution and platform responsibilities\",\"description\":\"Decide what belongs to the workload, what can be shared and what remains enterprise-owned.\"},{\"label\":\"5. Assess provider and runtime dependency\",\"description\":\"Evaluate managed, self-hosted, private, sovereign or hybrid options against real requirements.\"},{\"label\":\"6. Map risk and regulatory obligations\",\"description\":\"Determine risk level, organizational controls and applicable legal responsibilities for the concrete system.\"},{\"label\":\"7. Define measurable acceptance\",\"description\":\"Create evaluation criteria for quality, reliability, safety, retrieval, cost and operational behavior.\"},{\"label\":\"8. Record architecture decisions\",\"description\":\"Preserve rationale, alternatives, trade-offs, dependencies and conditions that would trigger reconsideration.\"},{\"label\":\"9. Connect architecture to delivery\",\"description\":\"Translate the design into backlog, milestones, acceptance criteria, technical work and ownership.\"},{\"label\":\"10. Validate in production-shaped conditions\",\"description\":\"Test realistic identity, data, failure, latency, provider, tool and recovery scenarios rather than only clean demos.\"},{\"label\":\"11. Establish operations and change control\",\"description\":\"Define monitoring, incident response, model\u002Fprovider updates, regression testing, rollback and retirement.\"},{\"label\":\"12. Feed evidence back into architecture\",\"description\":\"Use production observations, audits, incidents and evaluations to revise decisions and controls.\"}]},\"tunes\":{}},{\"id\":\"h-checklist\",\"type\":\"header\",\"data\":{\"text\":\"Enterprise AI architecture checklist\",\"level\":2},\"tunes\":{}},{\"id\":\"checklist-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Question\",\"Expected evidence\"],[\"What business capability does this AI support?\",\"Named owner, user group, intended decision\u002Fworkflow and acceptance objective.\"],[\"Which source is authoritative for each important fact?\",\"Systems of record, document authority, provenance and freshness rules.\"],[\"Which identities exist?\",\"Human, application, service, agent, tenant\u002Forg and provider identities are distinguishable.\"],[\"What can the AI read?\",\"Authorization-scoped data sources and explicit sensitive-data rules.\"],[\"What can the AI change?\",\"Tool\u002Faction inventory, permission model, approval and rollback path.\"],[\"Which provider\u002Fmodel is used and why?\",\"Architecture decision including quality, security, cost, region, lifecycle and exit considerations.\"],[\"What happens if the provider is unavailable?\",\"Degraded mode, fallback, refusal or continuity plan.\"],[\"How is quality evaluated?\",\"Task-specific datasets, graders, thresholds, regression criteria and validity conditions.\"],[\"What is logged?\",\"Telemetry schema, redaction, access, retention and audit purpose.\"],[\"Who owns AI risk?\",\"Named organizational responsibility connected to the concrete system.\"],[\"What legal classification applies?\",\"Documented assessment based on the current law and the actual use case.\"],[\"How are model\u002Fprompt\u002Fretrieval changes approved?\",\"Versioning, evaluation, architecture\u002Fchange record and rollout gate.\"],[\"Who responds to an AI incident?\",\"Runbook, technical owner, business\u002Fdomain escalation and provider escalation.\"],[\"How is the system retired?\",\"Data cleanup, access revocation, provider exit, evidence retention and dependency removal.\"]]},\"tunes\":{}},{\"id\":\"h-edge\",\"type\":\"header\",\"data\":{\"text\":\"Edge cases and limits\",\"level\":2},\"tunes\":{}},{\"id\":\"p-edge-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"A small company with one low-risk AI use case may not need a formal enterprise AI architecture function. The same principles can be applied lightly: clear owner, approved data, explicit provider, basic evaluation, access control and operational responsibility.\"},\"tunes\":{}},{\"id\":\"p-edge-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"A highly regulated organization may need stronger separation, independent validation, formal conformity processes, local hosting or air-gapped operation. Those controls are driven by the use case and regulatory environment, not by the word “enterprise.”\"},\"tunes\":{}},{\"id\":\"p-edge-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"An organization can also use mostly SaaS AI products rather than building AI systems. Enterprise architecture still matters because identity, data access, contractual terms, shadow AI, retention, audit and supplier concentration remain organizational concerns.\"},\"tunes\":{}},{\"id\":\"p-edge-4\",\"type\":\"paragraph\",\"data\":{\"text\":\"A centralized platform is not mandatory. Federated platform ownership can be valid when domains have materially different requirements, provided enterprise-level identity, risk, inventory and interoperability responsibilities remain coherent.\"},\"tunes\":{}},{\"id\":\"h-change-answer\",\"type\":\"header\",\"data\":{\"text\":\"What would change this answer?\",\"level\":2},\"tunes\":{}},{\"id\":\"p-change-answer-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"The architecture changes when the organization's risk tolerance, regulatory classification, data sensitivity, geographic scope, provider strategy, internal skills or business criticality changes. A public marketing assistant and a system participating in employment, finance, healthcare or critical infrastructure decisions should not inherit identical control models.\"},\"tunes\":{}},{\"id\":\"p-change-answer-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The implementation also changes as standards, regulation and AI platforms evolve. NIST AI RMF 1.0 is currently under revision, the EU AI Act has phased application dates, and model\u002Fprovider capabilities continue to change rapidly. Enterprise architecture should therefore preserve stable responsibility boundaries while treating provider mechanisms and regulatory details as versioned inputs.\"},\"tunes\":{}},{\"id\":\"h-related\",\"type\":\"header\",\"data\":{\"text\":\"Related canonical knowledge\",\"level\":2},\"tunes\":{}},{\"id\":\"p-related-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Enterprise AI architecture builds on solution and platform architecture. The solution layer explains one workload. The platform layer explains reusable AI capabilities. The enterprise layer connects both to organization-wide data, identity, governance, risk, procurement and operations.\"},\"tunes\":{}},{\"id\":\"p-related-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Retrieval-Augmented Generation is only one mechanism inside this architecture. RAG can improve access to enterprise knowledge, but it does not solve data authority, permissions, governance or answer validity by itself.\"},\"tunes\":{}},{\"id\":\"ref-rag\",\"type\":\"referralArticle\",\"data\":{\"url\":\"https:\u002F\u002Fstajic.de\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works\",\"title\":\"What Is RAG? The Simplest Explanation of How It Works\",\"excerpt\":\"A plain-English explanation of how external knowledge retrieval connects to the language model without turning retrieval into the source of truth.\",\"ctaLabel\":\"Read the RAG foundation\"},\"tunes\":{}},{\"id\":\"p-related-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"For evidence-heavy enterprise use cases, answer validity also needs an explicit boundary: an output is only supported under the evidence, version, scope and assumptions that produced it.\"},\"tunes\":{}},{\"id\":\"ref-avb\",\"type\":\"referralArticle\",\"data\":{\"url\":\"https:\u002F\u002Fstajic.de\u002Fblog\u002Fthe-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers\",\"title\":\"The Answer Validity Boundary: The Missing Layer Between Relevance and Reliable AI Answers\",\"excerpt\":\"A framework for making explicit the conditions under which an AI claim remains supported and what changes require restriction or recalculation.\",\"ctaLabel\":\"Read the Answer Validity Boundary\"},\"tunes\":{}},{\"id\":\"p-related-4\",\"type\":\"paragraph\",\"data\":{\"text\":\"Downstream enterprise topics include AI Governance, Private AI, Sovereign AI, Air-Gapped AI, Multi-Tenant AI Architecture, RBAC versus Tenant Isolation, Provider Abstraction, Model Routing and Production AI Architecture.\"},\"tunes\":{}},{\"id\":\"h-faq\",\"type\":\"header\",\"data\":{\"text\":\"Frequently asked questions\",\"level\":2},\"tunes\":{}},{\"id\":\"faq\",\"type\":\"faq\",\"data\":{\"title\":\"Enterprise AI architecture FAQ\",\"items\":[{\"id\":\"faq1\",\"question\":\"What is enterprise AI architecture?\",\"answer\":\"Enterprise AI architecture is the organization-wide architecture that defines how AI solutions and shared AI capabilities integrate with business ownership, enterprise data, identity, security, providers, governance, risk, compliance, lifecycle and operations.\"},{\"id\":\"faq2\",\"question\":\"Is enterprise AI architecture the same as an AI platform?\",\"answer\":\"No. An AI platform provides reusable technical capabilities such as model access, retrieval, agent runtimes and observability. Enterprise AI architecture defines how that platform and individual AI solutions fit into the organization's wider architecture and operating model.\"},{\"id\":\"faq3\",\"question\":\"Does enterprise AI require one central model?\",\"answer\":\"No. Standardization can reduce complexity, but different workloads may require different providers, models, regions, control levels or modalities. The important requirement is explicit policy and lifecycle ownership.\"},{\"id\":\"faq4\",\"question\":\"Why is data authority important for enterprise AI?\",\"answer\":\"Because retrieved or generated information is not automatically authoritative. Enterprise systems need to preserve which source is the system of record, whether data is current, who may access it and how a generated claim can be traced back to evidence.\"},{\"id\":\"faq5\",\"question\":\"What is the difference between AI governance and enterprise AI architecture?\",\"answer\":\"AI governance defines policies, accountability and decision rights. Enterprise AI architecture defines the system boundaries, interfaces, data flows and technical mechanisms through which those policies can be implemented and evidenced.\"},{\"id\":\"faq6\",\"question\":\"Does the EU AI Act apply to every enterprise AI system in the same way?\",\"answer\":\"No. Obligations depend on factors such as the organization's role, the system's use case and classification, and the relevant provisions in force. Legal classification must be performed for the concrete system under the current law.\"},{\"id\":\"faq7\",\"question\":\"Is a successful AI pilot enough for enterprise deployment?\",\"answer\":\"No. A pilot demonstrates bounded capability. Enterprise deployment also needs identity, data authority, security, provider governance, evaluation, lifecycle, incident response, monitoring, compliance and accountable operational ownership.\"},{\"id\":\"faq8\",\"question\":\"Should enterprises self-host AI?\",\"answer\":\"Only when the requirement justifies the added control and operational responsibility. Managed, private, sovereign, self-hosted and hybrid approaches are architecture options whose fit depends on data, regulatory, availability, cost, capability and operational requirements.\"}]},\"tunes\":{}},{\"id\":\"h-glossary\",\"type\":\"header\",\"data\":{\"text\":\"Glossary\",\"level\":2},\"tunes\":{}},{\"id\":\"glossary\",\"type\":\"glossary\",\"data\":{\"title\":\"Key enterprise AI architecture terms\",\"entries\":[{\"term\":\"Enterprise AI architecture\",\"definition\":\"Organization-wide architecture governing how AI systems, platforms, data, identities, providers, risk controls and operations fit together.\",\"anchor\":\"enterprise-ai-architecture\"},{\"term\":\"AI management system\",\"definition\":\"An organizational management system for establishing AI-related policies, objectives and processes; ISO\u002FIEC 42001 specifies requirements for such a system.\",\"anchor\":\"ai-management-system\"},{\"term\":\"Data authority\",\"definition\":\"The rule that identifies which source or system is authoritative for a particular fact, record, state or decision context.\",\"anchor\":\"data-authority\"},{\"term\":\"System of record\",\"definition\":\"The authoritative system responsible for the official current state of a business record or domain entity.\",\"anchor\":\"system-of-record\"},{\"term\":\"AI inventory\",\"definition\":\"A structured record of AI use cases, owners, models\u002Fproviders, data, tools, risk, evaluation evidence, lifecycle state and related controls.\",\"anchor\":\"ai-inventory\"},{\"term\":\"Provider dependency\",\"definition\":\"The technical, contractual and operational reliance created when an AI workload depends on an external model or managed platform.\",\"anchor\":\"provider-dependency\"},{\"term\":\"Human oversight\",\"definition\":\"Defined human review, approval, intervention or escalation applied where system consequence, uncertainty or regulation requires it.\",\"anchor\":\"human-oversight\"},{\"term\":\"GenAIOps\",\"definition\":\"Operational practices for generative-AI workloads covering model selection, prompts, grounding data, evaluation, deployment, monitoring and lifecycle management.\",\"anchor\":\"genaiops\"},{\"term\":\"AI risk management\",\"definition\":\"The organizational process of identifying, assessing, treating, monitoring and revising risks associated with AI systems across their lifecycle.\",\"anchor\":\"ai-risk-management\"},{\"term\":\"Architecture decision\",\"definition\":\"A material design choice together with its context, rationale, alternatives, trade-offs and lifecycle status.\",\"anchor\":\"architecture-decision\"}]},\"tunes\":{}},{\"id\":\"h-conclusion\",\"type\":\"header\",\"data\":{\"text\":\"Conclusion\",\"level\":2},\"tunes\":{}},{\"id\":\"p-conclusion-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"When AI enters a company, the enterprise does not merely gain a new software component. It gains a new class of behavior and dependency that cuts across data, identity, suppliers, business decisions, security, operations, governance and change management.\"},\"tunes\":{}},{\"id\":\"p-conclusion-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The architectural response is not to centralize everything. It is to make responsibilities explicit: which data is authoritative, which identities may act, which providers are approved, which controls are shared, which decisions remain domain-owned, how behavior is evaluated, how incidents are handled and how the system changes over time.\"},\"tunes\":{}},{\"id\":\"p-conclusion-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"That is the core distinction of enterprise AI architecture: it turns isolated AI capability into an organizationally governable system without pretending that models, platforms, business domains and enterprise controls are the same thing.\"},\"tunes\":{}},{\"id\":\"h-sources\",\"type\":\"header\",\"data\":{\"text\":\"Primary sources and current guidance\",\"level\":2},\"tunes\":{}},{\"id\":\"p-sources-note\",\"type\":\"paragraph\",\"data\":{\"text\":\"External standards, regulation and current vendor architecture guidance below were checked on 8 October 2026. Project-specific sections are explicitly marked as original project evidence and should not be read as claims of general industry fact.\"},\"tunes\":{}},{\"id\":\"src-iso-42001\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F42001\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"ISO\u002FIEC 42001:2023 — Artificial intelligence management system\",\"description\":\"International standard specifying requirements for establishing, implementing, maintaining and continually improving an AI management system within organizations.\"}},\"tunes\":{}},{\"id\":\"src-iso-23894\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F77304.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"ISO\u002FIEC 23894:2023 — Guidance on AI risk management\",\"description\":\"International guidance for integrating AI-specific risk management into organizational activities and functions.\"}},\"tunes\":{}},{\"id\":\"src-nist-rmf\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.nist.gov\u002Fitl\u002Fai-risk-management-framework\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"NIST AI Risk Management Framework\",\"description\":\"NIST's voluntary lifecycle-oriented framework for managing AI risk. NIST states that AI RMF 1.0 is currently being revised.\"}},\"tunes\":{}},{\"id\":\"src-nist-genai\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.nist.gov\u002Fpublications\u002Fartificial-intelligence-risk-management-framework-generative-artificial-intelligence\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"NIST AI 600-1 — Generative AI Profile\",\"description\":\"NIST companion profile describing generative-AI-specific risks and risk-management actions aligned to the AI RMF.\"}},\"tunes\":{}},{\"id\":\"src-eu-consolidated\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Feur-lex.europa.eu\u002Feli\u002Freg\u002F2024\u002F1689\u002F2026-07-27\u002Feng\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"EUR-Lex — Regulation (EU) 2024\u002F1689, consolidated text\",\"description\":\"Current consolidated AI Act text used for application dates and regulatory structure as checked on 8 October 2026.\"}},\"tunes\":{}},{\"id\":\"src-eu-timeline\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fdigital-strategy.ec.europa.eu\u002Fen\u002Fpolicies\u002Fregulatory-framework-ai\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"European Commission — AI Act regulatory framework\",\"description\":\"Current Commission overview of AI Act application phases, including 2026 applicability and later dates for specified high-risk provisions.\"}},\"tunes\":{}},{\"id\":\"src-ms-ai\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fget-started\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"Microsoft Azure Well-Architected — AI workloads\",\"description\":\"Current architecture guidance on AI workloads, including nondeterministic behavior, data, application design and operations.\"}},\"tunes\":{}},{\"id\":\"src-ms-ops\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fmlops-genaiops\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"Microsoft — MLOps and GenAIOps for AI workloads\",\"description\":\"Current guidance on operational lifecycle, data, model maintenance, deployment, monitoring and continuous evolution.\"}},\"tunes\":{}},{\"id\":\"src-ms-responsible\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fresponsible-ai\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"Microsoft — Responsible AI in Azure workloads\",\"description\":\"Current guidance connecting AI policy to data control, identity, agent auditability, role-based access and operational safeguards.\"}},\"tunes\":{}},{\"id\":\"src-iso-42010\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"ISO\u002FIEC\u002FIEEE 42010:2022 — Architecture Description\",\"description\":\"Current architecture-description standard supporting explicit concerns, viewpoints and relationships across system architecture.\"}},\"tunes\":{}}],\"version\":\"2.31.6\"}",{"time":1605,"blocks":1606,"version":2742},1791478189041,[1607,1611,1616,1621,1626,1630,1634,1638,1642,1646,1670,1674,1678,1682,1686,1709,1713,1717,1721,1725,1729,1733,1737,1741,1745,1749,1753,1758,1762,1766,1770,1774,1778,1782,1786,1790,1794,1798,1802,1806,1810,1814,1818,1822,1826,1830,1834,1838,1842,1846,1850,1854,1858,1862,1866,1870,1874,1878,1882,1886,1934,1939,1943,1948,1979,1983,1987,2016,2020,2024,2064,2068,2086,2090,2094,2098,2102,2107,2111,2115,2146,2150,2175,2179,2183,2187,2216,2220,2224,2228,2233,2237,2241,2245,2249,2254,2258,2262,2266,2270,2298,2302,2306,2310,2314,2333,2337,2341,2381,2385,2416,2420,2461,2465,2514,2518,2522,2526,2530,2534,2538,2542,2546,2550,2554,2558,2565,2569,2576,2580,2584,2613,2617,2649,2653,2657,2661,2665,2669,2673,2680,2687,2693,2700,2707,2714,2721,2728,2735],{"id":215,"data":1608,"type":218,"tunes":1610},{"text":1609},"Enterprise AI architecture is the organization-wide architecture required when AI becomes part of a company's real systems, data, decisions and operations. The model is only one component. Once AI is connected to enterprise data, identities, permissions, business processes, external providers and production systems, the architecture must also define data authority, access boundaries, risk ownership, provider dependencies, auditability, evaluation, lifecycle control, compliance and operational responsibility. Enterprise AI therefore differs from both a single AI solution and a shared AI platform: it coordinates how many AI-enabled systems fit into the wider organization.",{},{"id":221,"data":1612,"type":226,"tunes":1615},{"body":1613,"title":1614,"variant":225},"\u003Cstrong>What changes when AI enters a company?\u003C\u002Fstrong> Existing enterprise architecture responsibilities expand to include probabilistic model behavior, new data flows, retrieval and grounding, model\u002Fprovider dependencies, AI-specific evaluation, agent\u002Ftool authority, model and prompt lifecycle, AI risk management, transparency obligations, and new operational failure modes. The architecture must connect these concerns to the company's existing identity, security, data, procurement, delivery and governance structures instead of creating a parallel “AI universe.”","Direct answer",{},{"id":229,"data":1617,"type":226,"tunes":1620},{"body":1618,"title":1619,"variant":233},"A chatbot can be a user interface. Enterprise AI architecture is the system of boundaries behind it: what data the AI may access, which source is authoritative, who may use which capability, whether external providers may receive the data, what actions an agent may execute, how outputs are evaluated, what must be logged, who owns incidents, and how changes are approved and rolled back.","Enterprise AI is not “a bigger chatbot”",{},{"id":236,"data":1622,"type":226,"tunes":1625},{"body":1623,"title":1624,"variant":240},"The architectural principles in this article are intended to be stable. Regulation, standards and vendor capabilities are version-sensitive. ISO\u002FIEC 42001:2023 and ISO\u002FIEC 23894:2023 are current published standards. NIST states that AI RMF 1.0 is being revised. Under the current consolidated EU AI Act text, the Regulation applies generally from 2 August 2026, while specified high-risk provisions have later application dates. Legal classification must always be checked against the current law and the concrete use case.","Current-source note — 8 October 2026",{},{"id":243,"data":1627,"type":248,"tunes":1629},{"title":1628,"maxLevel":246,"minLevel":247},"Contents",{},{"id":251,"data":1631,"type":42,"tunes":1633},{"text":1632,"level":247},"What enterprise AI architecture really means",{},{"id":256,"data":1635,"type":218,"tunes":1637},{"text":1636},"Enterprise AI architecture describes how AI capabilities are integrated into an existing organization without breaking the boundaries that already make enterprise systems governable: business ownership, identity, authorization, data classification, system-of-record responsibility, change management, procurement, audit, continuity and operations.",{},{"id":261,"data":1639,"type":218,"tunes":1641},{"text":1640},"The enterprise architect does not replace the AI Solution Architect or AI Platform Architect. The enterprise scope asks a different question: How do multiple AI solutions and shared AI capabilities fit into the company's target architecture, policies, data landscape, risk model and operating model?",{},{"id":266,"data":1643,"type":218,"tunes":1645},{"text":1644},"This makes enterprise AI architecture a coordination discipline across technology and organization. A technically good model integration can still be an enterprise architecture failure if it creates shadow data flows, duplicates identity, bypasses procurement, cannot be audited, has no owner, or cannot be safely changed.",{},{"id":271,"data":1647,"type":303,"tunes":1669},{"rows":1648,"title":1661,"layout":292,"columns":1662},[1649,1652,1655,1658],{"id":275,"label":1650,"values":1651},"Primary scope",[278,278,278],{"id":280,"label":1653,"values":1654},"Primary question",[278,278,278],{"id":284,"label":1656,"values":1657},"Ownership focus",[278,278,278],{"id":288,"label":1659,"values":1660},"Success condition",[278,278,278],"Solution, platform and enterprise AI architecture are different scopes",[1663,1665,1667],{"id":295,"label":1664},"AI Solution Architecture",{"id":298,"label":1666},"AI Platform Architecture",{"id":301,"label":1668},"Enterprise AI Architecture",{},{"id":306,"data":1671,"type":42,"tunes":1673},{"text":1672,"level":247},"The simplest example",{},{"id":311,"data":1675,"type":218,"tunes":1677},{"text":1676},"A company starts with one internal document assistant. The first version searches approved documents and sends retrieved context to a language model. At solution level, this may look straightforward.",{},{"id":316,"data":1679,"type":218,"tunes":1681},{"text":1680},"Then a second team wants AI for customer support. A third wants an agent that can update tickets. Finance wants document analysis. HR wants an internal assistant. Developers want coding agents. Suddenly the company has several providers, several data classes, different user groups, overlapping retrieval indexes, different logging rules, new tool permissions, duplicated secrets and unclear ownership.",{},{"id":321,"data":1683,"type":218,"tunes":1685},{"text":1684},"At that point, the question is no longer “Does the assistant work?” The enterprise question becomes: Which capabilities are approved, who owns them, what data can cross which boundary, how are identities and permissions enforced, which providers are acceptable, what must be audited, and how can the organization change models or suppliers without losing control?",{},{"id":326,"data":1687,"type":349,"tunes":1708},{"steps":1688,"title":1707,"orientation":348},[1689,1692,1695,1698,1701,1704],{"label":1690,"description":1691},"1. Isolated use case","One team connects one model to one workflow and validates local value.",{"label":1693,"description":1694},"2. Shared dependencies appear","Multiple teams need providers, model access, retrieval, identity, secrets, observability and evaluation.",{"label":1696,"description":1697},"3. Enterprise boundaries are crossed","AI touches regulated data, systems of record, external vendors, privileged actions and business decisions.",{"label":1699,"description":1700},"4. Ownership must become explicit","Business, architecture, data, security, legal\u002Fcompliance, procurement and operations need defined responsibilities.",{"label":1702,"description":1703},"5. Lifecycle becomes organizational","Model changes, prompt changes, provider changes and new agent capabilities become governed changes rather than local developer edits.",{"label":1705,"description":1706},"6. Architecture becomes repeatable","The organization establishes reusable patterns, decision records, controls, exceptions and validation gates for new AI workloads.","From isolated AI feature to enterprise architecture",{},{"id":352,"data":1710,"type":42,"tunes":1712},{"text":1711,"level":247},"Where the simple example stops",{},{"id":357,"data":1714,"type":218,"tunes":1716},{"text":1715},"Enterprise architecture does not mean that every AI component must be centralized. Some capabilities should be shared; others must remain domain-owned. Finance, HR, engineering and customer support may legitimately require different data boundaries, providers, evaluation criteria and human-approval rules.",{},{"id":362,"data":1718,"type":218,"tunes":1720},{"text":1719},"The enterprise objective is therefore not one model, one vector database or one universal assistant. The objective is coherent architecture with explicit variation: common policies and reusable capabilities where they reduce risk and duplication, plus controlled exceptions where business or regulatory requirements differ.",{},{"id":367,"data":1722,"type":42,"tunes":1724},{"text":1723,"level":247},"What changes in the architecture when AI enters the enterprise",{},{"id":372,"data":1726,"type":42,"tunes":1728},{"text":1727,"level":246},"1. Business ownership becomes part of the technical architecture",{},{"id":377,"data":1730,"type":218,"tunes":1732},{"text":1731},"Traditional applications already need business owners. AI makes that requirement more visible because acceptable behavior cannot be defined only by uptime and functional correctness. Someone must own the intended use, unacceptable use, output quality, escalation path and consequences of wrong or inappropriate results.",{},{"id":382,"data":1734,"type":218,"tunes":1736},{"text":1735},"A model team cannot decide alone whether an answer is acceptable for HR, finance, legal or customer-facing use. Enterprise AI architecture therefore connects technical design to an explicit business capability, accountable owner, user group and decision context.",{},{"id":387,"data":1738,"type":42,"tunes":1740},{"text":1739,"level":246},"2. Data access is not enough — data authority must be defined",{},{"id":392,"data":1742,"type":218,"tunes":1744},{"text":1743},"Enterprise AI frequently combines operational databases, documents, search indexes, vector stores, data warehouses, SaaS systems and external knowledge. The architecture must distinguish where information is stored from which source is authoritative for a given claim or action.",{},{"id":397,"data":1746,"type":218,"tunes":1748},{"text":1747},"A vector index can improve retrieval but should not silently become the company's system of record. A model response can summarize an ERP record but should not replace the ERP as the authoritative source. Cached context can improve latency but becomes unsafe when permissions or underlying business state change.",{},{"id":402,"data":1750,"type":218,"tunes":1752},{"text":1751},"Enterprise AI therefore needs provenance, freshness, source classification, authorization propagation and invalidation rules in addition to ordinary data integration.",{},{"id":407,"data":1754,"type":226,"tunes":1757},{"body":1755,"title":1756,"variant":288},"\u003Cstrong>The AI system may transform, retrieve and reason over enterprise data without becoming the authority for that data.\u003C\u002Fstrong> The architecture should preserve a path back to the authoritative source whenever the use case requires evidence, verification or consequential action.","Enterprise data rule",{},{"id":413,"data":1759,"type":42,"tunes":1761},{"text":1760,"level":246},"3. Identity becomes multi-layered",{},{"id":418,"data":1763,"type":218,"tunes":1765},{"text":1764},"Enterprise AI has more identities than the human user. A request may involve a user identity, application identity, service identity, agent identity, provider credential, tool credential and tenant or organizational context.",{},{"id":423,"data":1767,"type":218,"tunes":1769},{"text":1768},"These identities should not be collapsed into one shared API key. Authorization must remain attributable to the correct principal, and privileged tools should receive only the authority required for the current operation.",{},{"id":428,"data":1771,"type":218,"tunes":1773},{"text":1772},"For agentic systems, this becomes especially important: a model can propose an action, but the runtime must decide whether the requesting identity is allowed to execute it. Model capability is not authorization.",{},{"id":433,"data":1775,"type":42,"tunes":1777},{"text":1776,"level":246},"4. Permissions move from content access to action authority",{},{"id":438,"data":1779,"type":218,"tunes":1781},{"text":1780},"A read-only assistant mainly needs controlled access to information. An enterprise agent can create tickets, modify records, send messages, trigger workflows or operate external systems. That introduces a different risk class because the system can change state rather than merely describe it.",{},{"id":443,"data":1783,"type":218,"tunes":1785},{"text":1784},"The architecture should separate read, write, approval and administrative capabilities; define human-in-the-loop points where consequence justifies them; and preserve an audit trail that identifies what was requested, what was approved and what actually changed.",{},{"id":448,"data":1787,"type":42,"tunes":1789},{"text":1788,"level":246},"5. The AI provider becomes an enterprise dependency",{},{"id":453,"data":1791,"type":218,"tunes":1793},{"text":1792},"Calling a model API is also a supplier relationship. The architecture may depend on provider availability, service terms, data-processing conditions, supported regions, model lifecycle, quotas, pricing, API compatibility, security controls and change notices.",{},{"id":458,"data":1795,"type":218,"tunes":1797},{"text":1796},"This means provider selection is not only a benchmark decision. Procurement, security, privacy, legal review, continuity planning and exit strategy can all become architecture inputs.",{},{"id":463,"data":1799,"type":218,"tunes":1801},{"text":1800},"Provider abstraction can reduce coupling, but only where the underlying capabilities are genuinely portable. Tool use, structured output, context limits, multimodality, safety controls, fine-tuning and hosted-agent features may differ materially between providers.",{},{"id":468,"data":1803,"type":42,"tunes":1805},{"text":1804,"level":246},"6. AI risk becomes a lifecycle process",{},{"id":473,"data":1807,"type":218,"tunes":1809},{"text":1808},"AI risk is not completed by one approval before launch. The model, prompt, retrieval corpus, tool set, provider, user population and surrounding business process can all change after deployment. The risk profile changes with them.",{},{"id":478,"data":1811,"type":218,"tunes":1813},{"text":1812},"ISO\u002FIEC 23894:2023 explicitly addresses integration of AI risk management into organizational activities and functions. NIST AI RMF similarly frames risk management across the lifecycle. Enterprise architecture should therefore make risk review part of change and operations rather than an isolated compliance document.",{},{"id":483,"data":1815,"type":218,"tunes":1817},{"text":1816},"Risk should also be proportional. A summarization assistant and an autonomous system that changes production records should not receive identical controls merely because both use an LLM.",{},{"id":488,"data":1819,"type":42,"tunes":1821},{"text":1820,"level":246},"7. Governance becomes an operating system, not a policy PDF",{},{"id":493,"data":1823,"type":218,"tunes":1825},{"text":1824},"ISO\u002FIEC 42001:2023 defines requirements for establishing, implementing, maintaining and continually improving an AI management system. The architecture consequence is important: governance must connect policy to real inventories, ownership, processes, controls, evidence, reviews and improvement loops.",{},{"id":498,"data":1827,"type":218,"tunes":1829},{"text":1828},"An enterprise AI policy that is not connected to provider approval, identity, logging, change management, evaluation and incident response has limited architectural effect. The organization needs mechanisms that make policy enforceable or at least observable.",{},{"id":503,"data":1831,"type":42,"tunes":1833},{"text":1832,"level":246},"8. Evaluation becomes a production control",{},{"id":508,"data":1835,"type":218,"tunes":1837},{"text":1836},"Traditional acceptance testing assumes that the same input normally produces the same deterministic result. Generative AI can be nondeterministic, sensitive to context and dependent on changing external knowledge. Production acceptance therefore needs task-specific evals, regression suites and observable thresholds rather than only unit tests.",{},{"id":513,"data":1839,"type":218,"tunes":1841},{"text":1840},"The platform can provide reusable evaluation infrastructure, but the enterprise still needs ownership of domain ground truth and release gates. A central AI team cannot invent the correct answer for every business domain.",{},{"id":518,"data":1843,"type":218,"tunes":1845},{"text":1844},"Model, prompt, retrieval and tool changes should be traceable to evaluation evidence where the change can materially affect output behavior.",{},{"id":523,"data":1847,"type":42,"tunes":1849},{"text":1848,"level":246},"9. Observability must include behavior, data and model context",{},{"id":528,"data":1851,"type":218,"tunes":1853},{"text":1852},"CPU, memory and HTTP error rates are not sufficient for AI workloads. Production observability may need model\u002Fprovider identifiers, latency, token usage, cost, retrieval results, tool calls, refusal behavior, evaluation scores, safety events and failure classifications.",{},{"id":533,"data":1855,"type":218,"tunes":1857},{"text":1856},"At the same time, AI telemetry can contain sensitive data. Prompt and response logs may become a shadow data store. Enterprise architecture must therefore define what can be logged, how it is redacted, who can access it, how long it is retained and when detailed tracing must be disabled.",{},{"id":538,"data":1859,"type":42,"tunes":1861},{"text":1860,"level":246},"10. AI components need explicit lifecycle ownership",{},{"id":543,"data":1863,"type":218,"tunes":1865},{"text":1864},"Models can be renamed, replaced, retired or changed by providers. Embedding models can invalidate an index strategy. Prompt templates and system instructions can change behavior. Agent runtimes and protocols can evolve. External tools can change their schemas and permissions.",{},{"id":548,"data":1867,"type":218,"tunes":1869},{"text":1868},"Enterprise architecture must decide who detects these changes, who tests them, who approves them, how consumers are notified, how rollback works and what evidence is required before a new version becomes the default.",{},{"id":553,"data":1871,"type":42,"tunes":1873},{"text":1872,"level":246},"11. Incident response must include AI-specific failure modes",{},{"id":558,"data":1875,"type":218,"tunes":1877},{"text":1876},"An AI incident may be a provider outage, data leak, prompt-injection path, authorization failure, retrieval contamination, unexpected model behavior, unsafe tool execution, cost spike, stale knowledge, evaluation regression or a change in external model behavior.",{},{"id":563,"data":1879,"type":218,"tunes":1881},{"text":1880},"The enterprise runbook therefore needs more than “restart the service.” It may require disabling a model route, revoking tool access, freezing a corpus, changing a prompt version, disabling an agent capability, switching provider, escalating to a domain owner or preserving traces for investigation.",{},{"id":568,"data":1883,"type":42,"tunes":1885},{"text":1884,"level":247},"Enterprise AI creates cross-functional ownership",{},{"id":573,"data":1887,"type":292,"tunes":1933},{"content":1888,"stretched":43,"withHeadings":14},[1889,1893,1897,1901,1905,1909,1913,1917,1921,1925,1929],[1890,1891,1892],"Concern","Typical enterprise owner or contributor","Architecture question",[1894,1895,1896],"Business use","Business owner \u002F product owner","What decision or workflow is AI allowed to support or automate?",[1898,1899,1900],"Solution architecture","AI \u002F solution architect","How does the concrete workload meet its functional and quality requirements?",[1902,1903,1904],"Shared AI capabilities","AI platform \u002F platform engineering","Which reusable model, retrieval, agent and observability services are provided?",[1906,1907,1908],"Enterprise coherence","Enterprise architecture","How do AI systems fit target architecture, standards, integration patterns and organizational ownership?",[1910,1911,1912],"Data authority","Data owner \u002F domain owner","Which data is authoritative, current, permitted and sufficiently governed?",[1914,1915,1916],"Identity and security","IAM \u002F security architecture","Which identities can access which data and execute which actions?",[1918,1919,1920],"Risk and compliance","Risk \u002F legal \u002F compliance \u002F privacy","Which obligations, prohibited uses, controls and evidence apply to this use case?",[1922,1923,1924],"Supplier dependency","Procurement \u002F vendor management \u002F architecture","What contractual, operational and exit risks arise from the provider?",[1926,1927,1928],"Operations","SRE \u002F operations \u002F platform owner","How is the system monitored, supported, degraded, recovered and changed?",[1930,1931,1932],"Domain acceptance","Business\u002Fdomain specialists","What counts as a correct, safe or useful result in this domain?",{},{"id":622,"data":1935,"type":226,"tunes":1938},{"body":1936,"title":1937,"variant":233},"Responsibility matrices are useful only when they connect to real system boundaries, approvals, data ownership, interfaces, runbooks and change processes. Enterprise AI needs accountable ownership that can be traced to technical controls and operational actions.","A RACI chart is not architecture by itself",{},{"id":628,"data":1940,"type":42,"tunes":1942},{"text":1941,"level":247},"A practical enterprise AI architecture model",{},{"id":633,"data":1944,"type":226,"tunes":1947},{"body":1945,"title":1946,"variant":240},"The following model is a practical synthesis for reasoning about enterprise AI architecture. It is not presented as an ISO or NIST standard. Its purpose is to make cross-organizational boundaries explicit.","Proposed layered model",{},{"id":639,"data":1949,"type":292,"tunes":1978},{"content":1950,"stretched":43,"withHeadings":14},[1951,1954,1957,1960,1963,1966,1969,1972,1975],[1952,1953],"Layer","Primary responsibility",[1955,1956],"Business and policy","Approved use cases, accountable owners, risk appetite, prohibited uses, human accountability, business acceptance.",[1958,1959],"Identity and authority","User\u002Fservice\u002Fagent identities, roles, tenant or organizational scope, privileged actions, approval paths.",[1961,1962],"Enterprise data","Systems of record, document sources, data products, provenance, classification, retention, freshness and access.",[1964,1965],"AI platform","Provider\u002Fmodel access, retrieval primitives, agent runtimes, tool brokers, evaluation infrastructure, observability, quotas and secrets.",[1967,1968],"AI solutions","Domain workflows, prompts\u002Finstructions, domain retrieval, business logic, acceptance criteria and user experience.",[1970,1971],"Integration and tools","APIs, enterprise applications, workflows, messaging, file systems, external services and action execution.",[1973,1974],"Risk and governance","Inventory, assessment, compliance evidence, exception management, model\u002Fprovider approval, review and audit.",[1976,1977],"Operations and lifecycle","Deployment, monitoring, incidents, releases, model\u002Fprovider changes, deprecation, rollback and continuity.",{},{"id":671,"data":1980,"type":218,"tunes":1982},{"text":1981},"The architecture is strongest when each layer can state both its responsibilities and its non-responsibilities. For example, the AI platform can enforce provider policy and collect traces without becoming the source of truth for HR data. A solution can define domain prompts without owning enterprise IAM. A business owner can approve a use case without being expected to operate the inference gateway.",{},{"id":676,"data":1984,"type":42,"tunes":1986},{"text":1985,"level":247},"Map enterprise AI as data and authority flows, not boxes",{},{"id":681,"data":1988,"type":349,"tunes":2015},{"steps":1989,"title":2014,"orientation":348},[1990,1993,1996,1999,2002,2005,2008,2011],{"label":1991,"description":1992},"1. Business context","The user requests a task under an approved use case with an accountable business owner.",{"label":1994,"description":1995},"2. Identity and authorization","The system resolves user, application, service and tenant or organizational scope before privileged access.",{"label":1997,"description":1998},"3. Authoritative data acquisition","The solution reads or retrieves only sources permitted for the current identity and task.",{"label":2000,"description":2001},"4. AI processing","An approved model\u002Fprovider processes the minimum necessary context under defined routing and data-handling rules.",{"label":2003,"description":2004},"5. Tool or action boundary","Any state-changing action is independently authorized and may require human approval according to consequence.",{"label":2006,"description":2007},"6. Validation","The result is checked against solution-specific acceptance, evidence or safety rules.",{"label":2009,"description":2010},"7. Audit and observability","Permitted metadata, decisions, routes, tool calls and outcomes are recorded without creating uncontrolled sensitive-data logs.",{"label":2012,"description":2013},"8. Feedback and lifecycle","Failures and evaluation results feed model, prompt, data, policy and process changes through controlled change management.","A consequential enterprise AI request",{},{"id":711,"data":2017,"type":42,"tunes":2019},{"text":2018,"level":247},"An enterprise needs an AI inventory before it can govern AI",{},{"id":716,"data":2021,"type":218,"tunes":2023},{"text":2022},"Organizations cannot manage AI systems they cannot identify. Enterprise architecture should maintain an inventory at a level that is useful for decisions, not merely a list of model names.",{},{"id":721,"data":2025,"type":292,"tunes":2063},{"content":2026,"stretched":43,"withHeadings":14},[2027,2030,2033,2036,2039,2042,2045,2048,2051,2054,2057,2060],[2028,2029],"Inventory field","Why it matters",[2031,2032],"Use case and owner","Connects technology to accountable business purpose.",[2034,2035],"Users and affected parties","Defines who interacts with or is affected by the system.",[2037,2038],"Model\u002Fprovider","Identifies external dependency, capability and lifecycle risk.",[2040,2041],"Data sources","Supports authority, privacy, classification and provenance review.",[2043,2044],"Deployment\u002Fruntime location","Clarifies processing location, connectivity and operational control.",[2046,2047],"Tools\u002Factions","Shows whether the AI can change external state and at what consequence.",[2049,2050],"Human oversight","Records where review, approval or escalation is required.",[2052,2053],"Risk\u002Fclassification","Connects the system to organizational and regulatory controls.",[2055,2056],"Evaluation evidence","Shows what was tested and under which validity conditions.",[2058,2059],"Current version","Allows incidents and regressions to be traced to actual deployed state.",[2061,2062],"Lifecycle state","Proposed, experimental, approved, production, restricted, deprecated or retired.",{},{"id":762,"data":2065,"type":42,"tunes":2067},{"text":2066,"level":247},"AI governance and enterprise AI architecture are related but not the same",{},{"id":767,"data":2069,"type":303,"tunes":2085},{"rows":2070,"title":2080,"layout":292,"columns":2081},[2071,2074,2077],{"id":771,"label":2072,"values":2073},"Purpose",[278,278],{"id":775,"label":2075,"values":2076},"Example",[278,278],{"id":779,"label":2078,"values":2079},"Failure if isolated",[278,278],"Governance versus architecture",[2082,2084],{"id":785,"label":2083},"AI Governance",{"id":788,"label":1668},{},{"id":791,"data":2087,"type":42,"tunes":2089},{"text":2088,"level":247},"Regulation becomes an architecture input",{},{"id":796,"data":2091,"type":218,"tunes":2093},{"text":2092},"For organizations operating in the European Union, the AI Act can create requirements that affect system design, documentation, transparency, governance and operating processes. The architectural impact depends on the organization's role in the AI value chain and the concrete system classification; not every AI system has the same obligations.",{},{"id":801,"data":2095,"type":218,"tunes":2097},{"text":2096},"As of 8 October 2026, the current consolidated text states that the Regulation generally applies from 2 August 2026. Governance rules and obligations for general-purpose AI models began applying earlier, while specified high-risk system provisions have later dates. The Commission also began enforcing new transparency requirements from 2 August 2026 for relevant interactive and synthetic-content systems.",{},{"id":806,"data":2099,"type":218,"tunes":2101},{"text":2100},"The enterprise architecture lesson is not “put compliance in the model.” It is to make classification, provider\u002Fdeployer role, documentation, transparency, oversight, logging and change evidence traceable to the system that actually implements the use case.",{},{"id":811,"data":2103,"type":226,"tunes":2106},{"body":2104,"title":2105,"variant":240},"This article describes architecture implications, not legal advice. Enterprise AI architecture should preserve the information needed for legal and compliance specialists to classify the actual system and map obligations to concrete controls. Architecture should not hard-code one regulatory interpretation as if every AI workload had the same status.","Legal scope is use-case specific",{},{"id":817,"data":2108,"type":42,"tunes":2110},{"text":2109,"level":247},"Procurement and architecture become connected",{},{"id":822,"data":2112,"type":218,"tunes":2114},{"text":2113},"An external model or managed AI platform can become a deep dependency even when integration requires only a few API calls. Enterprise architecture should therefore make procurement questions technically concrete.",{},{"id":827,"data":2116,"type":292,"tunes":2145},{"content":2117,"stretched":43,"withHeadings":14},[2118,2121,2124,2127,2130,2133,2136,2139,2142],[2119,2120],"Procurement question","Architecture consequence",[2122,2123],"Where is data processed?","Region, network path, data residency and transfer controls.",[2125,2126],"Is customer data retained or used for provider improvement?","Data minimization, contractual controls and provider eligibility.",[2128,2129],"How are models versioned or retired?","Regression testing, compatibility, fallback and lifecycle planning.",[2131,2132],"What are quotas and service limits?","Capacity architecture, admission control and failure handling.",[2134,2135],"How portable is the integration?","Provider abstraction, exit cost and migration effort.",[2137,2138],"What incident information is available?","Observability, forensic capability and support escalation.",[2140,2141],"Which subprocessors or external services are involved?","Dependency mapping and risk assessment.",[2143,2144],"What changes without explicit customer approval?","Change detection, release gates and acceptance strategy.",{},{"id":859,"data":2147,"type":42,"tunes":2149},{"text":2148,"level":247},"Enterprise architecture decides how much AI control the requirement actually needs",{},{"id":864,"data":2151,"type":292,"tunes":2174},{"content":2152,"stretched":43,"withHeadings":14},[2153,2156,2159,2162,2165,2168,2171],[2154,2155],"Requirement","Possible architectural response",[2157,2158],"Fast access to managed models","Managed provider with enterprise identity, gateway controls and contractual review.",[2160,2161],"Private data with managed orchestration","Managed control plane plus customer-controlled execution or private data plane where supported.",[2163,2164],"Strict locality or sovereignty","Region-restricted, sovereign, private or self-hosted architecture according to the real requirement.",[2166,2167],"Air-gapped environment","Locally hosted models, local retrieval, local tooling, offline update\u002Fdistribution and isolated observability.",[2169,2170],"Provider portability","Application-owned domain state plus adapters and contracts that isolate provider-specific behavior where practical.",[2172,2173],"Highest control of agent semantics","Self-managed or deeply controlled runtime with explicit tool, context, state and lifecycle ownership.",{},{"id":890,"data":2176,"type":218,"tunes":2178},{"text":2177},"The most controlled architecture is not automatically the best enterprise architecture. More ownership increases responsibility for patching, capacity, security, testing, model operations and incident response. Enterprise architecture should escalate control only where the requirement justifies the additional operational burden.",{},{"id":895,"data":2180,"type":42,"tunes":2182},{"text":2181,"level":247},"AI turns change management into a behavioral problem",{},{"id":900,"data":2184,"type":218,"tunes":2186},{"text":2185},"A normal dependency update can alter performance or compatibility. An AI change can also alter behavior. Replacing a model, changing a system prompt, changing retrieval, adding a tool or changing the context policy can modify how the system interprets and responds even if the surrounding application code barely changes.",{},{"id":905,"data":2188,"type":349,"tunes":2215},{"steps":2189,"title":2214,"orientation":348},[2190,2193,2196,2199,2202,2205,2208,2211],{"label":2191,"description":2192},"1. Change identified","Model, provider, prompt, retrieval source, tool, policy or runtime change is proposed or detected.",{"label":2194,"description":2195},"2. Impact mapped","Affected solutions, data classes, users, risk controls, cost, contracts and operational dependencies are identified.",{"label":2197,"description":2198},"3. Architecture decision updated","Material choices and trade-offs are recorded; superseded decisions remain historically traceable.",{"label":2200,"description":2201},"4. Evaluation executed","Relevant regression, safety, retrieval, latency, cost and domain tests are run.",{"label":2203,"description":2204},"5. Approval applied","Approval level follows consequence, risk and organizational policy.",{"label":2206,"description":2207},"6. Controlled rollout","Versioned release, canary or staged deployment is used where appropriate.",{"label":2209,"description":2210},"7. Production evidence collected","Telemetry, incidents, feedback and domain outcomes are monitored.",{"label":2212,"description":2213},"8. Rollback or acceptance","The change is accepted, restricted, rolled back or superseded based on evidence.","A production AI change path",{},{"id":935,"data":2217,"type":42,"tunes":2219},{"text":2218,"level":247},"Enterprise AI still needs NFRs and ADRs",{},{"id":940,"data":2221,"type":218,"tunes":2223},{"text":2222},"AI does not replace ordinary architecture discipline. Non-functional requirements remain the target conditions: availability, latency, privacy, isolation, auditability, recoverability, cost boundaries, explainability or other quality requirements. Architecture Decision Records preserve the chosen response and its trade-offs.",{},{"id":945,"data":2225,"type":218,"tunes":2227},{"text":2226},"The AI-specific difference is that some quality attributes must be evaluated probabilistically or empirically. “Answers must be useful” is too vague. A production requirement should identify the task, data, user population, acceptable failure conditions, measurement method and threshold where practical.",{},{"id":950,"data":2229,"type":226,"tunes":2232},{"body":2230,"title":2231,"variant":288},"\u003Cstrong>Business need → requirement \u002F NFR → architecture decision → implementation → evaluation \u002F validation → production observation → change decision.\u003C\u002Fstrong> AI adds new variables to this chain; it does not make the chain unnecessary.","Enterprise traceability chain",{},{"id":956,"data":2234,"type":42,"tunes":2236},{"text":2235,"level":247},"Enterprise AI architecture must connect to delivery",{},{"id":961,"data":2238,"type":218,"tunes":2240},{"text":2239},"Architecture that never reaches backlog, implementation, acceptance and operations remains conceptual. Enterprise AI therefore needs traceability from architecture decisions into delivery work and back from implementation evidence into architecture.",{},{"id":966,"data":2242,"type":218,"tunes":2244},{"text":2243},"Jira and Confluence are examples of tools that can support this separation when used deliberately: Confluence can preserve requirements, architecture, decisions, risks and rationale; Jira can manage actionable delivery work and state. The important principle is the traceability, not the brand of tool.",{},{"id":971,"data":2246,"type":42,"tunes":2248},{"text":2247,"level":247},"Original project evidence: Enterprise Aaasaasa 0.1",{},{"id":976,"data":2250,"type":226,"tunes":2253},{"body":2251,"title":2252,"variant":240},"Enterprise Aaasaasa 0.1 is used here as original project evidence for structured enterprise architecture and delivery thinking. It is a PoC \u002F enterprise project context, not evidence of mass customer adoption, enterprise-scale production usage or commercial traction.","Project evidence, not market-proof claim",{},{"id":982,"data":2255,"type":218,"tunes":2257},{"text":2256},"Enterprise Aaasaasa 0.1 combines platform architecture, SaaS\u002FAPI concepts, internationalization, AI integration and structured project governance. The project was deliberately organized so that requirements, architecture, prototype delivery, validation and closure were separate milestones rather than one undifferentiated implementation phase.",{},{"id":987,"data":2259,"type":218,"tunes":2261},{"text":2260},"The architecture direction includes multi-instance \u002F multi-database concepts together with API, CRUD, i18n and AI capabilities. That matters for enterprise AI because tenant or instance boundaries, database ownership and application services must remain explicit when AI features are added.",{},{"id":992,"data":2263,"type":218,"tunes":2265},{"text":2264},"The project structure also treated architecture delay, scope creep and AI\u002Fdata-protection concerns as project risks rather than discovering them only during implementation. Stakeholders included technical, security, sponsor\u002Fsteering and external-service perspectives, which is closer to the real cross-functional nature of enterprise AI than a model-only prototype.",{},{"id":997,"data":2267,"type":218,"tunes":2269},{"text":2268},"The useful evidence is therefore the integration of architecture and delivery: business and project structure, milestones, risks, architecture, backend\u002FAPI, frontend\u002FAI work, validation and closure are treated as connected responsibilities. That pattern is reusable even though the project itself should not be presented as proof of external enterprise adoption.",{},{"id":1002,"data":2271,"type":292,"tunes":2297},{"content":2272,"stretched":43,"withHeadings":14},[2273,2276,2279,2282,2285,2288,2291,2294],[2274,2275],"Project element","Enterprise AI architecture lesson",[2277,2278],"Requirements milestone","AI capability must begin from defined need, scope, acceptance and quality constraints.",[2280,2281],"Architecture milestone","Data, API, instance\u002Fdatabase boundaries and AI integration are explicit design work.",[2283,2284],"Prototype milestone","Architecture must become executable enough to expose integration risks.",[2286,2287],"Validation milestone","A functioning prototype is not the same as validated acceptance.",[2289,2290],"Risk register","Scope, architecture delay and AI\u002Fdata-protection concerns are managed as delivery risks.",[2292,2293],"Stakeholder structure","Enterprise AI spans sponsor\u002Fbusiness, architecture, security, external providers and delivery.",[2295,2296],"Project closure","Decisions, remaining risks and validation evidence must survive beyond the implementation sprint.",{},{"id":1031,"data":2299,"type":42,"tunes":2301},{"text":2300,"level":247},"Supporting implementation patterns from the wider platform work",{},{"id":1036,"data":2303,"type":218,"tunes":2305},{"text":2304},"Separate implementation work in the wider Aaasaasa platform provides concrete examples of boundaries that enterprise AI architecture must preserve: tenant-scoped RBAC in the CMS, explicit provider\u002Fmodel\u002Fruntime\u002Fpermission separation in Aaasaasa AI Client, and provenance-first retrieval in the Source of Truth Research Engine.",{},{"id":1041,"data":2307,"type":218,"tunes":2309},{"text":2308},"These projects should not be collapsed into one claimed production platform. Their value here is narrower: they demonstrate implemented patterns for identity scope, provider boundaries, controlled runtime permissions, retrieval provenance and evidence traceability that are directly relevant to enterprise AI.",{},{"id":1046,"data":2311,"type":42,"tunes":2313},{"text":2312,"level":247},"How the main standards fit together",{},{"id":1051,"data":2315,"type":292,"tunes":2332},{"content":2316,"stretched":43,"withHeadings":14},[2317,2320,2322,2324,2326,2328,2330],[2318,2319],"Source","What it contributes to enterprise AI architecture",[1058,2321],"Organization-level AI management system: policies, objectives, processes, responsibility, monitoring and continual improvement.",[1061,2323],"Guidance for integrating AI-specific risk management into organizational activities and functions.",[1064,2325],"Voluntary lifecycle-oriented framework for managing AI risks; organized around Govern, Map, Measure and Manage.",[1067,2327],"Generative AI profile extending AI RMF with generative-AI-specific risks and actions.",[1070,2329],"Binding regulatory obligations in the EU whose applicability depends on role, system type and classification.",[1073,2331],"General architecture-description concepts for expressing concerns, viewpoints, decisions and relationships.",{},{"id":1077,"data":2334,"type":218,"tunes":2336},{"text":2335},"These sources solve different problems. ISO\u002FIEC 42001 is not a replacement for technical architecture. ISO\u002FIEC 23894 and NIST AI RMF do not define one mandatory software stack. The EU AI Act is law, not a platform design pattern. Architecture must translate the applicable organizational, risk and legal requirements into implementable system boundaries and evidence.",{},{"id":1082,"data":2338,"type":42,"tunes":2340},{"text":2339,"level":247},"Common enterprise AI failure modes",{},{"id":1087,"data":2342,"type":292,"tunes":2380},{"content":2343,"stretched":43,"withHeadings":14},[2344,2347,2350,2353,2356,2359,2362,2365,2368,2371,2374,2377],[2345,2346],"Failure mode","Why it fails",[2348,2349],"Every team buys AI independently","Creates shadow providers, duplicated secrets, inconsistent data handling and weak leverage over supplier risk.",[2351,2352],"One central AI team owns every domain decision","Centralizes technical control but loses domain accountability and creates a bottleneck.",[2354,2355],"Vector database becomes the source of truth","Retrieval infrastructure silently replaces authoritative systems and freshness rules.",[2357,2358],"One shared API key for all users and agents","Destroys attribution, least privilege and meaningful auditability.",[2360,2361],"Model change deployed like a minor library patch","Behavioral regressions can reach production without domain evaluation.",[2363,2364],"All prompts and outputs are logged forever","Observability creates an uncontrolled sensitive-data repository.",[2366,2367],"Governance is only documentation","Policies exist without enforcement points, evidence or operational ownership.",[2369,2370],"Compliance is delegated to the provider","The organization's own role, use case, data and operational obligations remain unresolved.",[2372,2373],"Agent can call tools because the model supports tool use","Capability is mistaken for authorization.",[2375,2376],"Platform health equals business correctness","Endpoint uptime and model availability do not prove domain answer quality or acceptable outcomes.",[2378,2379],"No exit strategy for model\u002Fprovider dependency","A pricing, policy, capability or availability change becomes an emergency migration.",{},{"id":1128,"data":2382,"type":42,"tunes":2384},{"text":2383,"level":247},"Common misconceptions",{},{"id":1133,"data":2386,"type":292,"tunes":2415},{"content":2387,"stretched":43,"withHeadings":14},[2388,2391,2394,2397,2400,2403,2406,2409,2412],[2389,2390],"Misconception","Better model",[2392,2393],"“Enterprise AI means a company-wide chatbot.”","The chatbot is one interface; enterprise AI architecture governs the underlying data, identity, provider, runtime, risk and operations.",[2395,2396],"“If we use a reputable model provider, governance is solved.”","Provider controls do not define your use case, data authority, user permissions, business acceptance or legal role.",[2398,2399],"“Private AI means everything must be self-hosted.”","Privacy requirements can lead to several architectures; the required control boundary must be stated precisely.",[2401,2402],"“AI governance belongs to legal, architecture belongs to IT.”","The two disciplines must connect because policy obligations need implementable controls and evidence.",[2404,2405],"“One enterprise model is simpler.”","Standardization can help, but workloads can require different modalities, regions, costs, quality levels or control models.",[2407,2408],"“AI risk is model risk.”","Risk can originate in data, prompts, retrieval, identity, tools, interfaces, operations, users and organizational process.",[2410,2411],"“Human-in-the-loop makes an agent safe.”","Human approval helps only if the reviewer has useful context, authority, time and a clear decision point.",[2413,2414],"“A successful pilot proves enterprise readiness.”","A pilot proves bounded capability; enterprise readiness also requires integration, governance, lifecycle, operations and repeatable controls.",{},{"id":1165,"data":2417,"type":42,"tunes":2419},{"text":2418,"level":247},"A practical enterprise AI architecture decision sequence",{},{"id":1170,"data":2421,"type":349,"tunes":2460},{"steps":2422,"title":2459,"orientation":348},[2423,2426,2429,2432,2435,2438,2441,2444,2447,2450,2453,2456],{"label":2424,"description":2425},"1. Define the business capability","State the user, decision or workflow, expected value and accountable owner.",{"label":2427,"description":2428},"2. Classify data and authority","Identify systems of record, personal\u002Fconfidential data, retention, freshness and provenance requirements.",{"label":2430,"description":2431},"3. Define identity and action boundaries","Determine who may read, generate, decide, approve and change external systems.",{"label":2433,"description":2434},"4. Select solution and platform responsibilities","Decide what belongs to the workload, what can be shared and what remains enterprise-owned.",{"label":2436,"description":2437},"5. Assess provider and runtime dependency","Evaluate managed, self-hosted, private, sovereign or hybrid options against real requirements.",{"label":2439,"description":2440},"6. Map risk and regulatory obligations","Determine risk level, organizational controls and applicable legal responsibilities for the concrete system.",{"label":2442,"description":2443},"7. Define measurable acceptance","Create evaluation criteria for quality, reliability, safety, retrieval, cost and operational behavior.",{"label":2445,"description":2446},"8. Record architecture decisions","Preserve rationale, alternatives, trade-offs, dependencies and conditions that would trigger reconsideration.",{"label":2448,"description":2449},"9. Connect architecture to delivery","Translate the design into backlog, milestones, acceptance criteria, technical work and ownership.",{"label":2451,"description":2452},"10. Validate in production-shaped conditions","Test realistic identity, data, failure, latency, provider, tool and recovery scenarios rather than only clean demos.",{"label":2454,"description":2455},"11. Establish operations and change control","Define monitoring, incident response, model\u002Fprovider updates, regression testing, rollback and retirement.",{"label":2457,"description":2458},"12. Feed evidence back into architecture","Use production observations, audits, incidents and evaluations to revise decisions and controls.","From opportunity to governed enterprise capability",{},{"id":1212,"data":2462,"type":42,"tunes":2464},{"text":2463,"level":247},"Enterprise AI architecture checklist",{},{"id":1217,"data":2466,"type":292,"tunes":2513},{"content":2467,"stretched":43,"withHeadings":14},[2468,2471,2474,2477,2480,2483,2486,2489,2492,2495,2498,2501,2504,2507,2510],[2469,2470],"Question","Expected evidence",[2472,2473],"What business capability does this AI support?","Named owner, user group, intended decision\u002Fworkflow and acceptance objective.",[2475,2476],"Which source is authoritative for each important fact?","Systems of record, document authority, provenance and freshness rules.",[2478,2479],"Which identities exist?","Human, application, service, agent, tenant\u002Forg and provider identities are distinguishable.",[2481,2482],"What can the AI read?","Authorization-scoped data sources and explicit sensitive-data rules.",[2484,2485],"What can the AI change?","Tool\u002Faction inventory, permission model, approval and rollback path.",[2487,2488],"Which provider\u002Fmodel is used and why?","Architecture decision including quality, security, cost, region, lifecycle and exit considerations.",[2490,2491],"What happens if the provider is unavailable?","Degraded mode, fallback, refusal or continuity plan.",[2493,2494],"How is quality evaluated?","Task-specific datasets, graders, thresholds, regression criteria and validity conditions.",[2496,2497],"What is logged?","Telemetry schema, redaction, access, retention and audit purpose.",[2499,2500],"Who owns AI risk?","Named organizational responsibility connected to the concrete system.",[2502,2503],"What legal classification applies?","Documented assessment based on the current law and the actual use case.",[2505,2506],"How are model\u002Fprompt\u002Fretrieval changes approved?","Versioning, evaluation, architecture\u002Fchange record and rollout gate.",[2508,2509],"Who responds to an AI incident?","Runbook, technical owner, business\u002Fdomain escalation and provider escalation.",[2511,2512],"How is the system retired?","Data cleanup, access revocation, provider exit, evidence retention and dependency removal.",{},{"id":1267,"data":2515,"type":42,"tunes":2517},{"text":2516,"level":247},"Edge cases and limits",{},{"id":1272,"data":2519,"type":218,"tunes":2521},{"text":2520},"A small company with one low-risk AI use case may not need a formal enterprise AI architecture function. The same principles can be applied lightly: clear owner, approved data, explicit provider, basic evaluation, access control and operational responsibility.",{},{"id":1277,"data":2523,"type":218,"tunes":2525},{"text":2524},"A highly regulated organization may need stronger separation, independent validation, formal conformity processes, local hosting or air-gapped operation. Those controls are driven by the use case and regulatory environment, not by the word “enterprise.”",{},{"id":1282,"data":2527,"type":218,"tunes":2529},{"text":2528},"An organization can also use mostly SaaS AI products rather than building AI systems. Enterprise architecture still matters because identity, data access, contractual terms, shadow AI, retention, audit and supplier concentration remain organizational concerns.",{},{"id":1287,"data":2531,"type":218,"tunes":2533},{"text":2532},"A centralized platform is not mandatory. Federated platform ownership can be valid when domains have materially different requirements, provided enterprise-level identity, risk, inventory and interoperability responsibilities remain coherent.",{},{"id":1292,"data":2535,"type":42,"tunes":2537},{"text":2536,"level":247},"What would change this answer?",{},{"id":1297,"data":2539,"type":218,"tunes":2541},{"text":2540},"The architecture changes when the organization's risk tolerance, regulatory classification, data sensitivity, geographic scope, provider strategy, internal skills or business criticality changes. A public marketing assistant and a system participating in employment, finance, healthcare or critical infrastructure decisions should not inherit identical control models.",{},{"id":1302,"data":2543,"type":218,"tunes":2545},{"text":2544},"The implementation also changes as standards, regulation and AI platforms evolve. NIST AI RMF 1.0 is currently under revision, the EU AI Act has phased application dates, and model\u002Fprovider capabilities continue to change rapidly. Enterprise architecture should therefore preserve stable responsibility boundaries while treating provider mechanisms and regulatory details as versioned inputs.",{},{"id":1307,"data":2547,"type":42,"tunes":2549},{"text":2548,"level":247},"Related canonical knowledge",{},{"id":1312,"data":2551,"type":218,"tunes":2553},{"text":2552},"Enterprise AI architecture builds on solution and platform architecture. The solution layer explains one workload. The platform layer explains reusable AI capabilities. The enterprise layer connects both to organization-wide data, identity, governance, risk, procurement and operations.",{},{"id":1317,"data":2555,"type":218,"tunes":2557},{"text":2556},"Retrieval-Augmented Generation is only one mechanism inside this architecture. RAG can improve access to enterprise knowledge, but it does not solve data authority, permissions, governance or answer validity by itself.",{},{"id":1322,"data":2559,"type":1328,"tunes":2564},{"url":2560,"title":2561,"excerpt":2562,"ctaLabel":2563},"https:\u002F\u002Fstajic.de\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works","What Is RAG? The Simplest Explanation of How It Works","A plain-English explanation of how external knowledge retrieval connects to the language model without turning retrieval into the source of truth.","Read the RAG foundation",{},{"id":1331,"data":2566,"type":218,"tunes":2568},{"text":2567},"For evidence-heavy enterprise use cases, answer validity also needs an explicit boundary: an output is only supported under the evidence, version, scope and assumptions that produced it.",{},{"id":1336,"data":2570,"type":1328,"tunes":2575},{"url":2571,"title":2572,"excerpt":2573,"ctaLabel":2574},"https:\u002F\u002Fstajic.de\u002Fblog\u002Fthe-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers","The Answer Validity Boundary: The Missing Layer Between Relevance and Reliable AI Answers","A framework for making explicit the conditions under which an AI claim remains supported and what changes require restriction or recalculation.","Read the Answer Validity Boundary",{},{"id":1344,"data":2577,"type":218,"tunes":2579},{"text":2578},"Downstream enterprise topics include AI Governance, Private AI, Sovereign AI, Air-Gapped AI, Multi-Tenant AI Architecture, RBAC versus Tenant Isolation, Provider Abstraction, Model Routing and Production AI Architecture.",{},{"id":1349,"data":2581,"type":42,"tunes":2583},{"text":2582,"level":247},"Frequently asked questions",{},{"id":1354,"data":2585,"type":1354,"tunes":2612},{"items":2586,"title":2611},[2587,2590,2593,2596,2599,2602,2605,2608],{"id":1358,"answer":2588,"question":2589},"Enterprise AI architecture is the organization-wide architecture that defines how AI solutions and shared AI capabilities integrate with business ownership, enterprise data, identity, security, providers, governance, risk, compliance, lifecycle and operations.","What is enterprise AI architecture?",{"id":1362,"answer":2591,"question":2592},"No. An AI platform provides reusable technical capabilities such as model access, retrieval, agent runtimes and observability. Enterprise AI architecture defines how that platform and individual AI solutions fit into the organization's wider architecture and operating model.","Is enterprise AI architecture the same as an AI platform?",{"id":1366,"answer":2594,"question":2595},"No. Standardization can reduce complexity, but different workloads may require different providers, models, regions, control levels or modalities. The important requirement is explicit policy and lifecycle ownership.","Does enterprise AI require one central model?",{"id":1370,"answer":2597,"question":2598},"Because retrieved or generated information is not automatically authoritative. Enterprise systems need to preserve which source is the system of record, whether data is current, who may access it and how a generated claim can be traced back to evidence.","Why is data authority important for enterprise AI?",{"id":1374,"answer":2600,"question":2601},"AI governance defines policies, accountability and decision rights. Enterprise AI architecture defines the system boundaries, interfaces, data flows and technical mechanisms through which those policies can be implemented and evidenced.","What is the difference between AI governance and enterprise AI architecture?",{"id":1378,"answer":2603,"question":2604},"No. Obligations depend on factors such as the organization's role, the system's use case and classification, and the relevant provisions in force. Legal classification must be performed for the concrete system under the current law.","Does the EU AI Act apply to every enterprise AI system in the same way?",{"id":1382,"answer":2606,"question":2607},"No. A pilot demonstrates bounded capability. Enterprise deployment also needs identity, data authority, security, provider governance, evaluation, lifecycle, incident response, monitoring, compliance and accountable operational ownership.","Is a successful AI pilot enough for enterprise deployment?",{"id":1386,"answer":2609,"question":2610},"Only when the requirement justifies the added control and operational responsibility. Managed, private, sovereign, self-hosted and hybrid approaches are architecture options whose fit depends on data, regulatory, availability, cost, capability and operational requirements.","Should enterprises self-host AI?","Enterprise AI architecture FAQ",{},{"id":1392,"data":2614,"type":42,"tunes":2616},{"text":2615,"level":247},"Glossary",{},{"id":1397,"data":2618,"type":1397,"tunes":2648},{"title":2619,"entries":2620},"Key enterprise AI architecture terms",[2621,2624,2627,2629,2632,2635,2638,2640,2642,2645],{"term":2622,"anchor":1403,"definition":2623},"Enterprise AI architecture","Organization-wide architecture governing how AI systems, platforms, data, identities, providers, risk controls and operations fit together.",{"term":2625,"anchor":1407,"definition":2626},"AI management system","An organizational management system for establishing AI-related policies, objectives and processes; ISO\u002FIEC 42001 specifies requirements for such a system.",{"term":1910,"anchor":1411,"definition":2628},"The rule that identifies which source or system is authoritative for a particular fact, record, state or decision context.",{"term":2630,"anchor":1415,"definition":2631},"System of record","The authoritative system responsible for the official current state of a business record or domain entity.",{"term":2633,"anchor":1419,"definition":2634},"AI inventory","A structured record of AI use cases, owners, models\u002Fproviders, data, tools, risk, evaluation evidence, lifecycle state and related controls.",{"term":2636,"anchor":1422,"definition":2637},"Provider dependency","The technical, contractual and operational reliance created when an AI workload depends on an external model or managed platform.",{"term":2049,"anchor":1425,"definition":2639},"Defined human review, approval, intervention or escalation applied where system consequence, uncertainty or regulation requires it.",{"term":1428,"anchor":1429,"definition":2641},"Operational practices for generative-AI workloads covering model selection, prompts, grounding data, evaluation, deployment, monitoring and lifecycle management.",{"term":2643,"anchor":1433,"definition":2644},"AI risk management","The organizational process of identifying, assessing, treating, monitoring and revising risks associated with AI systems across their lifecycle.",{"term":2646,"anchor":1437,"definition":2647},"Architecture decision","A material design choice together with its context, rationale, alternatives, trade-offs and lifecycle status.",{},{"id":1441,"data":2650,"type":42,"tunes":2652},{"text":2651,"level":247},"Conclusion",{},{"id":1446,"data":2654,"type":218,"tunes":2656},{"text":2655},"When AI enters a company, the enterprise does not merely gain a new software component. It gains a new class of behavior and dependency that cuts across data, identity, suppliers, business decisions, security, operations, governance and change management.",{},{"id":1451,"data":2658,"type":218,"tunes":2660},{"text":2659},"The architectural response is not to centralize everything. It is to make responsibilities explicit: which data is authoritative, which identities may act, which providers are approved, which controls are shared, which decisions remain domain-owned, how behavior is evaluated, how incidents are handled and how the system changes over time.",{},{"id":1456,"data":2662,"type":218,"tunes":2664},{"text":2663},"That is the core distinction of enterprise AI architecture: it turns isolated AI capability into an organizationally governable system without pretending that models, platforms, business domains and enterprise controls are the same thing.",{},{"id":1461,"data":2666,"type":42,"tunes":2668},{"text":2667,"level":247},"Primary sources and current guidance",{},{"id":1466,"data":2670,"type":218,"tunes":2672},{"text":2671},"External standards, regulation and current vendor architecture guidance below were checked on 8 October 2026. Project-specific sections are explicitly marked as original project evidence and should not be read as claims of general industry fact.",{},{"id":1471,"data":2674,"type":1478,"tunes":2679},{"link":1473,"meta":2675},{"image":2676,"title":2677,"description":2678},{"url":278},"ISO\u002FIEC 42001:2023 — Artificial intelligence management system","International standard specifying requirements for establishing, implementing, maintaining and continually improving an AI management system within organizations.",{},{"id":1481,"data":2681,"type":1478,"tunes":2686},{"link":1483,"meta":2682},{"image":2683,"title":2684,"description":2685},{"url":278},"ISO\u002FIEC 23894:2023 — Guidance on AI risk management","International guidance for integrating AI-specific risk management into organizational activities and functions.",{},{"id":1490,"data":2688,"type":1478,"tunes":2692},{"link":1492,"meta":2689},{"image":2690,"title":1495,"description":2691},{"url":278},"NIST's voluntary lifecycle-oriented framework for managing AI risk. NIST states that AI RMF 1.0 is currently being revised.",{},{"id":1499,"data":2694,"type":1478,"tunes":2699},{"link":1501,"meta":2695},{"image":2696,"title":2697,"description":2698},{"url":278},"NIST AI 600-1 — Generative AI Profile","NIST companion profile describing generative-AI-specific risks and risk-management actions aligned to the AI RMF.",{},{"id":1508,"data":2701,"type":1478,"tunes":2706},{"link":1510,"meta":2702},{"image":2703,"title":2704,"description":2705},{"url":278},"EUR-Lex — Regulation (EU) 2024\u002F1689, consolidated text","Current consolidated AI Act text used for application dates and regulatory structure as checked on 8 October 2026.",{},{"id":1517,"data":2708,"type":1478,"tunes":2713},{"link":1519,"meta":2709},{"image":2710,"title":2711,"description":2712},{"url":278},"European Commission — AI Act regulatory framework","Current Commission overview of AI Act application phases, including 2026 applicability and later dates for specified high-risk provisions.",{},{"id":1526,"data":2715,"type":1478,"tunes":2720},{"link":1528,"meta":2716},{"image":2717,"title":2718,"description":2719},{"url":278},"Microsoft Azure Well-Architected — AI workloads","Current architecture guidance on AI workloads, including nondeterministic behavior, data, application design and operations.",{},{"id":1535,"data":2722,"type":1478,"tunes":2727},{"link":1537,"meta":2723},{"image":2724,"title":2725,"description":2726},{"url":278},"Microsoft — MLOps and GenAIOps for AI workloads","Current guidance on operational lifecycle, data, model maintenance, deployment, monitoring and continuous evolution.",{},{"id":1544,"data":2729,"type":1478,"tunes":2734},{"link":1546,"meta":2730},{"image":2731,"title":2732,"description":2733},{"url":278},"Microsoft — Responsible AI in Azure workloads","Current guidance connecting AI policy to data control, identity, agent auditability, role-based access and operational safeguards.",{},{"id":1553,"data":2736,"type":1478,"tunes":2741},{"link":1555,"meta":2737},{"image":2738,"title":2739,"description":2740},{"url":278},"ISO\u002FIEC\u002FIEEE 42010:2022 — Architecture Description","Current architecture-description standard supporting explicit concerns, viewpoints and relationships across system architecture.",{},"2.31.6","Enterprise AI architecture explains how AI changes company systems across data authority, identity, permissions, providers, risk, governance, evaluation, compliance and operations.",{"lang":7,"title":208,"content":210,"contentJson":2745,"excerpt":1562},{"time":212,"blocks":2746,"version":1561},[2747,2750,2753,2756,2759,2762,2765,2768,2771,2774,2790,2793,2796,2799,2802,2812,2815,2818,2821,2824,2827,2830,2833,2836,2839,2842,2845,2848,2851,2854,2857,2860,2863,2866,2869,2872,2875,2878,2881,2884,2887,2890,2893,2896,2899,2902,2905,2908,2911,2914,2917,2920,2923,2926,2929,2932,2935,2938,2941,2944,2959,2962,2965,2968,2981,2984,2987,2999,3002,3005,3021,3024,3037,3040,3043,3046,3049,3052,3055,3058,3071,3074,3085,3088,3091,3094,3106,3109,3112,3115,3118,3121,3124,3127,3130,3133,3136,3139,3142,3145,3157,3160,3163,3166,3169,3180,3183,3186,3202,3205,3218,3221,3237,3240,3259,3262,3265,3268,3271,3274,3277,3280,3283,3286,3289,3292,3295,3298,3301,3304,3307,3319,3322,3336,3339,3342,3345,3348,3351,3354,3359,3364,3369,3374,3379,3384,3389,3394,3399],{"id":215,"data":2748,"type":218,"tunes":2749},{"text":217},{},{"id":221,"data":2751,"type":226,"tunes":2752},{"body":223,"title":224,"variant":225},{},{"id":229,"data":2754,"type":226,"tunes":2755},{"body":231,"title":232,"variant":233},{},{"id":236,"data":2757,"type":226,"tunes":2758},{"body":238,"title":239,"variant":240},{},{"id":243,"data":2760,"type":248,"tunes":2761},{"title":245,"maxLevel":246,"minLevel":247},{},{"id":251,"data":2763,"type":42,"tunes":2764},{"text":253,"level":247},{},{"id":256,"data":2766,"type":218,"tunes":2767},{"text":258},{},{"id":261,"data":2769,"type":218,"tunes":2770},{"text":263},{},{"id":266,"data":2772,"type":218,"tunes":2773},{"text":268},{},{"id":271,"data":2775,"type":303,"tunes":2789},{"rows":2776,"title":291,"layout":292,"columns":2785},[2777,2779,2781,2783],{"id":275,"label":276,"values":2778},[278,278,278],{"id":280,"label":281,"values":2780},[278,278,278],{"id":284,"label":285,"values":2782},[278,278,278],{"id":288,"label":289,"values":2784},[278,278,278],[2786,2787,2788],{"id":295,"label":296},{"id":298,"label":299},{"id":301,"label":302},{},{"id":306,"data":2791,"type":42,"tunes":2792},{"text":308,"level":247},{},{"id":311,"data":2794,"type":218,"tunes":2795},{"text":313},{},{"id":316,"data":2797,"type":218,"tunes":2798},{"text":318},{},{"id":321,"data":2800,"type":218,"tunes":2801},{"text":323},{},{"id":326,"data":2803,"type":349,"tunes":2811},{"steps":2804,"title":347,"orientation":348},[2805,2806,2807,2808,2809,2810],{"label":330,"description":331},{"label":333,"description":334},{"label":336,"description":337},{"label":339,"description":340},{"label":342,"description":343},{"label":345,"description":346},{},{"id":352,"data":2813,"type":42,"tunes":2814},{"text":354,"level":247},{},{"id":357,"data":2816,"type":218,"tunes":2817},{"text":359},{},{"id":362,"data":2819,"type":218,"tunes":2820},{"text":364},{},{"id":367,"data":2822,"type":42,"tunes":2823},{"text":369,"level":247},{},{"id":372,"data":2825,"type":42,"tunes":2826},{"text":374,"level":246},{},{"id":377,"data":2828,"type":218,"tunes":2829},{"text":379},{},{"id":382,"data":2831,"type":218,"tunes":2832},{"text":384},{},{"id":387,"data":2834,"type":42,"tunes":2835},{"text":389,"level":246},{},{"id":392,"data":2837,"type":218,"tunes":2838},{"text":394},{},{"id":397,"data":2840,"type":218,"tunes":2841},{"text":399},{},{"id":402,"data":2843,"type":218,"tunes":2844},{"text":404},{},{"id":407,"data":2846,"type":226,"tunes":2847},{"body":409,"title":410,"variant":288},{},{"id":413,"data":2849,"type":42,"tunes":2850},{"text":415,"level":246},{},{"id":418,"data":2852,"type":218,"tunes":2853},{"text":420},{},{"id":423,"data":2855,"type":218,"tunes":2856},{"text":425},{},{"id":428,"data":2858,"type":218,"tunes":2859},{"text":430},{},{"id":433,"data":2861,"type":42,"tunes":2862},{"text":435,"level":246},{},{"id":438,"data":2864,"type":218,"tunes":2865},{"text":440},{},{"id":443,"data":2867,"type":218,"tunes":2868},{"text":445},{},{"id":448,"data":2870,"type":42,"tunes":2871},{"text":450,"level":246},{},{"id":453,"data":2873,"type":218,"tunes":2874},{"text":455},{},{"id":458,"data":2876,"type":218,"tunes":2877},{"text":460},{},{"id":463,"data":2879,"type":218,"tunes":2880},{"text":465},{},{"id":468,"data":2882,"type":42,"tunes":2883},{"text":470,"level":246},{},{"id":473,"data":2885,"type":218,"tunes":2886},{"text":475},{},{"id":478,"data":2888,"type":218,"tunes":2889},{"text":480},{},{"id":483,"data":2891,"type":218,"tunes":2892},{"text":485},{},{"id":488,"data":2894,"type":42,"tunes":2895},{"text":490,"level":246},{},{"id":493,"data":2897,"type":218,"tunes":2898},{"text":495},{},{"id":498,"data":2900,"type":218,"tunes":2901},{"text":500},{},{"id":503,"data":2903,"type":42,"tunes":2904},{"text":505,"level":246},{},{"id":508,"data":2906,"type":218,"tunes":2907},{"text":510},{},{"id":513,"data":2909,"type":218,"tunes":2910},{"text":515},{},{"id":518,"data":2912,"type":218,"tunes":2913},{"text":520},{},{"id":523,"data":2915,"type":42,"tunes":2916},{"text":525,"level":246},{},{"id":528,"data":2918,"type":218,"tunes":2919},{"text":530},{},{"id":533,"data":2921,"type":218,"tunes":2922},{"text":535},{},{"id":538,"data":2924,"type":42,"tunes":2925},{"text":540,"level":246},{},{"id":543,"data":2927,"type":218,"tunes":2928},{"text":545},{},{"id":548,"data":2930,"type":218,"tunes":2931},{"text":550},{},{"id":553,"data":2933,"type":42,"tunes":2934},{"text":555,"level":246},{},{"id":558,"data":2936,"type":218,"tunes":2937},{"text":560},{},{"id":563,"data":2939,"type":218,"tunes":2940},{"text":565},{},{"id":568,"data":2942,"type":42,"tunes":2943},{"text":570,"level":247},{},{"id":573,"data":2945,"type":292,"tunes":2958},{"content":2946,"stretched":43,"withHeadings":14},[2947,2948,2949,2950,2951,2952,2953,2954,2955,2956,2957],[577,578,579],[581,582,583],[585,586,587],[589,590,591],[593,594,595],[597,598,599],[601,602,603],[605,606,607],[609,610,611],[613,614,615],[617,618,619],{},{"id":622,"data":2960,"type":226,"tunes":2961},{"body":624,"title":625,"variant":233},{},{"id":628,"data":2963,"type":42,"tunes":2964},{"text":630,"level":247},{},{"id":633,"data":2966,"type":226,"tunes":2967},{"body":635,"title":636,"variant":240},{},{"id":639,"data":2969,"type":292,"tunes":2980},{"content":2970,"stretched":43,"withHeadings":14},[2971,2972,2973,2974,2975,2976,2977,2978,2979],[643,644],[646,647],[649,650],[652,653],[655,656],[658,659],[661,662],[664,665],[667,668],{},{"id":671,"data":2982,"type":218,"tunes":2983},{"text":673},{},{"id":676,"data":2985,"type":42,"tunes":2986},{"text":678,"level":247},{},{"id":681,"data":2988,"type":349,"tunes":2998},{"steps":2989,"title":708,"orientation":348},[2990,2991,2992,2993,2994,2995,2996,2997],{"label":685,"description":686},{"label":688,"description":689},{"label":691,"description":692},{"label":694,"description":695},{"label":697,"description":698},{"label":700,"description":701},{"label":703,"description":704},{"label":706,"description":707},{},{"id":711,"data":3000,"type":42,"tunes":3001},{"text":713,"level":247},{},{"id":716,"data":3003,"type":218,"tunes":3004},{"text":718},{},{"id":721,"data":3006,"type":292,"tunes":3020},{"content":3007,"stretched":43,"withHeadings":14},[3008,3009,3010,3011,3012,3013,3014,3015,3016,3017,3018,3019],[725,726],[728,729],[731,732],[734,735],[737,738],[740,741],[743,744],[746,747],[749,750],[752,753],[755,756],[758,759],{},{"id":762,"data":3022,"type":42,"tunes":3023},{"text":764,"level":247},{},{"id":767,"data":3025,"type":303,"tunes":3036},{"rows":3026,"title":782,"layout":292,"columns":3033},[3027,3029,3031],{"id":771,"label":772,"values":3028},[278,278],{"id":775,"label":776,"values":3030},[278,278],{"id":779,"label":780,"values":3032},[278,278],[3034,3035],{"id":785,"label":786},{"id":788,"label":302},{},{"id":791,"data":3038,"type":42,"tunes":3039},{"text":793,"level":247},{},{"id":796,"data":3041,"type":218,"tunes":3042},{"text":798},{},{"id":801,"data":3044,"type":218,"tunes":3045},{"text":803},{},{"id":806,"data":3047,"type":218,"tunes":3048},{"text":808},{},{"id":811,"data":3050,"type":226,"tunes":3051},{"body":813,"title":814,"variant":240},{},{"id":817,"data":3053,"type":42,"tunes":3054},{"text":819,"level":247},{},{"id":822,"data":3056,"type":218,"tunes":3057},{"text":824},{},{"id":827,"data":3059,"type":292,"tunes":3070},{"content":3060,"stretched":43,"withHeadings":14},[3061,3062,3063,3064,3065,3066,3067,3068,3069],[831,832],[834,835],[837,838],[840,841],[843,844],[846,847],[849,850],[852,853],[855,856],{},{"id":859,"data":3072,"type":42,"tunes":3073},{"text":861,"level":247},{},{"id":864,"data":3075,"type":292,"tunes":3084},{"content":3076,"stretched":43,"withHeadings":14},[3077,3078,3079,3080,3081,3082,3083],[868,869],[871,872],[874,875],[877,878],[880,881],[883,884],[886,887],{},{"id":890,"data":3086,"type":218,"tunes":3087},{"text":892},{},{"id":895,"data":3089,"type":42,"tunes":3090},{"text":897,"level":247},{},{"id":900,"data":3092,"type":218,"tunes":3093},{"text":902},{},{"id":905,"data":3095,"type":349,"tunes":3105},{"steps":3096,"title":932,"orientation":348},[3097,3098,3099,3100,3101,3102,3103,3104],{"label":909,"description":910},{"label":912,"description":913},{"label":915,"description":916},{"label":918,"description":919},{"label":921,"description":922},{"label":924,"description":925},{"label":927,"description":928},{"label":930,"description":931},{},{"id":935,"data":3107,"type":42,"tunes":3108},{"text":937,"level":247},{},{"id":940,"data":3110,"type":218,"tunes":3111},{"text":942},{},{"id":945,"data":3113,"type":218,"tunes":3114},{"text":947},{},{"id":950,"data":3116,"type":226,"tunes":3117},{"body":952,"title":953,"variant":288},{},{"id":956,"data":3119,"type":42,"tunes":3120},{"text":958,"level":247},{},{"id":961,"data":3122,"type":218,"tunes":3123},{"text":963},{},{"id":966,"data":3125,"type":218,"tunes":3126},{"text":968},{},{"id":971,"data":3128,"type":42,"tunes":3129},{"text":973,"level":247},{},{"id":976,"data":3131,"type":226,"tunes":3132},{"body":978,"title":979,"variant":240},{},{"id":982,"data":3134,"type":218,"tunes":3135},{"text":984},{},{"id":987,"data":3137,"type":218,"tunes":3138},{"text":989},{},{"id":992,"data":3140,"type":218,"tunes":3141},{"text":994},{},{"id":997,"data":3143,"type":218,"tunes":3144},{"text":999},{},{"id":1002,"data":3146,"type":292,"tunes":3156},{"content":3147,"stretched":43,"withHeadings":14},[3148,3149,3150,3151,3152,3153,3154,3155],[1006,1007],[1009,1010],[1012,1013],[1015,1016],[1018,1019],[1021,1022],[1024,1025],[1027,1028],{},{"id":1031,"data":3158,"type":42,"tunes":3159},{"text":1033,"level":247},{},{"id":1036,"data":3161,"type":218,"tunes":3162},{"text":1038},{},{"id":1041,"data":3164,"type":218,"tunes":3165},{"text":1043},{},{"id":1046,"data":3167,"type":42,"tunes":3168},{"text":1048,"level":247},{},{"id":1051,"data":3170,"type":292,"tunes":3179},{"content":3171,"stretched":43,"withHeadings":14},[3172,3173,3174,3175,3176,3177,3178],[1055,1056],[1058,1059],[1061,1062],[1064,1065],[1067,1068],[1070,1071],[1073,1074],{},{"id":1077,"data":3181,"type":218,"tunes":3182},{"text":1079},{},{"id":1082,"data":3184,"type":42,"tunes":3185},{"text":1084,"level":247},{},{"id":1087,"data":3187,"type":292,"tunes":3201},{"content":3188,"stretched":43,"withHeadings":14},[3189,3190,3191,3192,3193,3194,3195,3196,3197,3198,3199,3200],[1091,1092],[1094,1095],[1097,1098],[1100,1101],[1103,1104],[1106,1107],[1109,1110],[1112,1113],[1115,1116],[1118,1119],[1121,1122],[1124,1125],{},{"id":1128,"data":3203,"type":42,"tunes":3204},{"text":1130,"level":247},{},{"id":1133,"data":3206,"type":292,"tunes":3217},{"content":3207,"stretched":43,"withHeadings":14},[3208,3209,3210,3211,3212,3213,3214,3215,3216],[1137,1138],[1140,1141],[1143,1144],[1146,1147],[1149,1150],[1152,1153],[1155,1156],[1158,1159],[1161,1162],{},{"id":1165,"data":3219,"type":42,"tunes":3220},{"text":1167,"level":247},{},{"id":1170,"data":3222,"type":349,"tunes":3236},{"steps":3223,"title":1209,"orientation":348},[3224,3225,3226,3227,3228,3229,3230,3231,3232,3233,3234,3235],{"label":1174,"description":1175},{"label":1177,"description":1178},{"label":1180,"description":1181},{"label":1183,"description":1184},{"label":1186,"description":1187},{"label":1189,"description":1190},{"label":1192,"description":1193},{"label":1195,"description":1196},{"label":1198,"description":1199},{"label":1201,"description":1202},{"label":1204,"description":1205},{"label":1207,"description":1208},{},{"id":1212,"data":3238,"type":42,"tunes":3239},{"text":1214,"level":247},{},{"id":1217,"data":3241,"type":292,"tunes":3258},{"content":3242,"stretched":43,"withHeadings":14},[3243,3244,3245,3246,3247,3248,3249,3250,3251,3252,3253,3254,3255,3256,3257],[1221,1222],[1224,1225],[1227,1228],[1230,1231],[1233,1234],[1236,1237],[1239,1240],[1242,1243],[1245,1246],[1248,1249],[1251,1252],[1254,1255],[1257,1258],[1260,1261],[1263,1264],{},{"id":1267,"data":3260,"type":42,"tunes":3261},{"text":1269,"level":247},{},{"id":1272,"data":3263,"type":218,"tunes":3264},{"text":1274},{},{"id":1277,"data":3266,"type":218,"tunes":3267},{"text":1279},{},{"id":1282,"data":3269,"type":218,"tunes":3270},{"text":1284},{},{"id":1287,"data":3272,"type":218,"tunes":3273},{"text":1289},{},{"id":1292,"data":3275,"type":42,"tunes":3276},{"text":1294,"level":247},{},{"id":1297,"data":3278,"type":218,"tunes":3279},{"text":1299},{},{"id":1302,"data":3281,"type":218,"tunes":3282},{"text":1304},{},{"id":1307,"data":3284,"type":42,"tunes":3285},{"text":1309,"level":247},{},{"id":1312,"data":3287,"type":218,"tunes":3288},{"text":1314},{},{"id":1317,"data":3290,"type":218,"tunes":3291},{"text":1319},{},{"id":1322,"data":3293,"type":1328,"tunes":3294},{"url":1324,"title":1325,"excerpt":1326,"ctaLabel":1327},{},{"id":1331,"data":3296,"type":218,"tunes":3297},{"text":1333},{},{"id":1336,"data":3299,"type":1328,"tunes":3300},{"url":1338,"title":1339,"excerpt":1340,"ctaLabel":1341},{},{"id":1344,"data":3302,"type":218,"tunes":3303},{"text":1346},{},{"id":1349,"data":3305,"type":42,"tunes":3306},{"text":1351,"level":247},{},{"id":1354,"data":3308,"type":1354,"tunes":3318},{"items":3309,"title":1389},[3310,3311,3312,3313,3314,3315,3316,3317],{"id":1358,"answer":1359,"question":1360},{"id":1362,"answer":1363,"question":1364},{"id":1366,"answer":1367,"question":1368},{"id":1370,"answer":1371,"question":1372},{"id":1374,"answer":1375,"question":1376},{"id":1378,"answer":1379,"question":1380},{"id":1382,"answer":1383,"question":1384},{"id":1386,"answer":1387,"question":1388},{},{"id":1392,"data":3320,"type":42,"tunes":3321},{"text":1394,"level":247},{},{"id":1397,"data":3323,"type":1397,"tunes":3335},{"title":1399,"entries":3324},[3325,3326,3327,3328,3329,3330,3331,3332,3333,3334],{"term":1402,"anchor":1403,"definition":1404},{"term":1406,"anchor":1407,"definition":1408},{"term":1410,"anchor":1411,"definition":1412},{"term":1414,"anchor":1415,"definition":1416},{"term":1418,"anchor":1419,"definition":1420},{"term":609,"anchor":1422,"definition":1423},{"term":746,"anchor":1425,"definition":1426},{"term":1428,"anchor":1429,"definition":1430},{"term":1432,"anchor":1433,"definition":1434},{"term":1436,"anchor":1437,"definition":1438},{},{"id":1441,"data":3337,"type":42,"tunes":3338},{"text":1443,"level":247},{},{"id":1446,"data":3340,"type":218,"tunes":3341},{"text":1448},{},{"id":1451,"data":3343,"type":218,"tunes":3344},{"text":1453},{},{"id":1456,"data":3346,"type":218,"tunes":3347},{"text":1458},{},{"id":1461,"data":3349,"type":42,"tunes":3350},{"text":1463,"level":247},{},{"id":1466,"data":3352,"type":218,"tunes":3353},{"text":1468},{},{"id":1471,"data":3355,"type":1478,"tunes":3358},{"link":1473,"meta":3356},{"image":3357,"title":1476,"description":1477},{"url":278},{},{"id":1481,"data":3360,"type":1478,"tunes":3363},{"link":1483,"meta":3361},{"image":3362,"title":1486,"description":1487},{"url":278},{},{"id":1490,"data":3365,"type":1478,"tunes":3368},{"link":1492,"meta":3366},{"image":3367,"title":1495,"description":1496},{"url":278},{},{"id":1499,"data":3370,"type":1478,"tunes":3373},{"link":1501,"meta":3371},{"image":3372,"title":1504,"description":1505},{"url":278},{},{"id":1508,"data":3375,"type":1478,"tunes":3378},{"link":1510,"meta":3376},{"image":3377,"title":1513,"description":1514},{"url":278},{},{"id":1517,"data":3380,"type":1478,"tunes":3383},{"link":1519,"meta":3381},{"image":3382,"title":1522,"description":1523},{"url":278},{},{"id":1526,"data":3385,"type":1478,"tunes":3388},{"link":1528,"meta":3386},{"image":3387,"title":1531,"description":1532},{"url":278},{},{"id":1535,"data":3390,"type":1478,"tunes":3393},{"link":1537,"meta":3391},{"image":3392,"title":1540,"description":1541},{"url":278},{},{"id":1544,"data":3395,"type":1478,"tunes":3398},{"link":1546,"meta":3396},{"image":3397,"title":1549,"description":1550},{"url":278},{},{"id":1553,"data":3400,"type":1478,"tunes":3403},{"link":1555,"meta":3401},{"image":3402,"title":1558,"description":1559},{"url":278},{},"Post erfolgreich abgerufen",{"items":3406,"source":3490,"manualIds":3491,"manualMatchedIds":3492},[3407,3414,3421,3428,3435,3442,3449,3456,3463,3470,3477,3483],{"id":3408,"slug":3409,"title":3410,"excerpt":3411,"featuredImage":3412,"publishedAt":3413},"483","what-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","Что такое архитектор ИИ-решений? Границы системы, обязанности и компромиссы","Архитектор решений ИИ превращает бизнес-требования в готовую к производству систему ИИ, охватывающую данные, модели, инструменты, безопасность, среду выполнения, оценку и операции.","\u002Fuploads\u002F2026\u002F10\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs-1791476643267-1st5xz.webp","2026-10-08T12:23:00.000Z",{"id":3415,"slug":3416,"title":3417,"excerpt":3418,"featuredImage":3419,"publishedAt":3420},"381","enterprise-grade-multi-tenant-architecture-for-an-international-platform","Мультитенантная архитектура корпоративного уровня для международной платформы","Loving Rocks является корпоративной свадебной платформой, разработанной с истинной многоарендной архитектурой, изолированными базами данных для каждого арендатора и встроенной интернационализацией для глобальной масштабируемости, безопасности и долгосрочной операционной стабильности.","\u002Fuploads\u002F2026\u002F01\u002Fenterprise-grade-multi-tenant-architecture-for-an-international-platform-1769789121298-b6v7ak.webp","2026-01-30T12:04:00.000Z",{"id":3422,"slug":3423,"title":3424,"excerpt":3425,"featuredImage":3426,"publishedAt":3427},"486","source-of-truth-in-ai-systems-where-reliable-knowledge-actually-comes-from","Источник истины в системах ИИ: откуда на самом деле берутся надёжные знания","Источник истины определяет, какой источник является авторитетным для конкретного факта или состояния. Узнайте, чем он отличается от RAG, происхождения данных, памяти, контекста, векторных баз данных и систем учёта.","\u002Fuploads\u002F2026\u002F10\u002Fsource-of-truth-in-ai-systems-where-reliable-knowledge-actually-comes-from-1791479103235-6bq9em.webp","2026-10-08T13:02:00.000Z",{"id":3429,"slug":3430,"title":3431,"excerpt":3432,"featuredImage":3433,"publishedAt":3434},"495","sovereign-ai-control-of-models-data-infrastructure-and-dependencies","Суверенный ИИ: контроль над моделями, данными, инфраструктурой и зависимостями","Суверенный ИИ — это эффективный контроль над моделями, данными, инфраструктурой, программным обеспечением, операциями и стратегическими зависимостями, а не просто место размещения модели ИИ.","\u002Fuploads\u002F2026\u002F10\u002Fsovereign-ai-control-of-models-data-infrastructure-and-dependencies-1791488833132-niy85x.webp","2026-10-08T15:45:00.000Z",{"id":3436,"slug":3437,"title":3438,"excerpt":3439,"featuredImage":3440,"publishedAt":3441},"489","agentic-ai-explained-when-an-ai-system-can-plan-use-tools-and-act","Агентный ИИ: когда система ИИ может планировать, использовать инструменты и действовать","Агентный ИИ использует модели внутри многошаговых циклов выполнения, где они могут выбирать инструменты, наблюдать результаты, обновлять состояние и адаптировать своё следующее действие в рамках явных границ времени выполнения и разрешений.","\u002Fuploads\u002F2026\u002F10\u002Fagentic-ai-explained-when-an-ai-system-can-plan-use-tools-and-act-1791481499084-wnji2a.webp","2026-10-08T11:43:00.000Z",{"id":3443,"slug":3444,"title":3445,"excerpt":3446,"featuredImage":3447,"publishedAt":3448},"468","ai-agent-memory-is-not-rag-how-to-separate-memory-retrieval-state-and-context","Память ИИ-агента — это не RAG: как разграничить память, извлечение, состояние и контекст","Память агента, RAG, состояние и контекст часто используются так, будто они взаимозаменяемы. Это не так. Эта практическая архитектурная модель разделяет четыре уровня, показывает, где место каждого из них, и объясняет, что ломается, когда системы объединяют их в одно целое.","\u002Fuploads\u002F2026\u002F09\u002Fai-agent-memory-is-not-rag-how-to-separate-memory-retrieval-state-and-context-1790350560308-np0xy6.webp","2026-09-25T11:34:00.000Z",{"id":3450,"slug":3451,"title":3452,"excerpt":3453,"featuredImage":3454,"publishedAt":3455},"481","generative-ai-explained-models-retrieval-tools-and-applications-are-not-the-same-thing","Генеративный ИИ: модели, поиск, инструменты и приложения — это не одно и то же","Генеративный ИИ — это больше, чем модель. Узнайте, как модели, поиск информации, инструменты, контекст, среды выполнения и приложения сочетаются друг с другом в производственных системах ИИ.","\u002Fuploads\u002F2026\u002F10\u002Fgenerative-ai-explained-models-retrieval-tools-and-applications-are-not-the-same-thing-1791475411822-pp0dvz.webp","2026-10-08T12:00:00.000Z",{"id":3457,"slug":3458,"title":3459,"excerpt":3460,"featuredImage":3461,"publishedAt":3462},"494","air-gapped-ai-how-ai-systems-work-without-internet-or-cloud-access","Air-Gapped AI: как работают ИИ-системы без интернета и облачного доступа","AI-системы в изолированной среде запускают модели, RAG и AI-приложения внутри изолированного домена безопасности без зависимости от интернета или облачных сервисов. Узнайте, как модели, данные, обновления и инструменты работают в автономном режиме.","\u002Fuploads\u002F2026\u002F10\u002Fair-gapped-ai-how-ai-systems-work-without-internet-or-cloud-access-1791487983978-e6xqf0.webp","2026-10-08T11:32:00.000Z",{"id":3464,"slug":3465,"title":3466,"excerpt":3467,"featuredImage":3468,"publishedAt":3469},"466","the-gpu-is-not-the-product-future-proof-private-ai-architecture","GPU — не продукт: перспективная архитектура приватного ИИ","Инфраструктура приватного ИИ не должна проектироваться вокруг одного GPU или одной модели. Более устойчивый подход объединяет быстрые GPU для инференса, ИИ-системы с большим объемом памяти, узлы физического ИИ и опциональные передовые облачные модели за уровнем маршрутизации, учитывающим возможности.","\u002Fuploads\u002F2026\u002F09\u002Fthe-gpu-is-not-the-product-future-proof-private-ai-architecture-1790140878812-8hsl39.webp","2026-09-23T01:19:00.000Z",{"id":3471,"slug":3472,"title":3473,"excerpt":3474,"featuredImage":3475,"publishedAt":3476},"460","ai-agent-reliability-why-the-final-answer-is-not-enough","Надёжность ИИ-агентов: почему финального ответа недостаточно","Правильный вывод не доказывает правильность рассуждений, безопасность выполнения или надежность системы.","\u002Fuploads\u002F2026\u002F09\u002Fai-agent-reliability-why-the-final-answer-is-not-enough-1788955466306-pl0qhz.webp","2026-09-09T04:01:00.000Z",{"id":3478,"slug":3479,"title":1325,"excerpt":3480,"featuredImage":3481,"publishedAt":3482},"478","what-is-rag-the-simplest-explanation-of-how-it-works","RAG звучит сложно, но идея проста: прежде чем ИИ ответит, он сначала находит полезную информацию из источника знаний и передаёт эту информацию языковой модели. В этом руководстве объясняются RAG, LLM, состояние, память и инструменты с помощью одной простой ментальной модели.","\u002Fuploads\u002F2026\u002F09\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works-1790377492124-khjagt.webp","2026-09-25T19:03:00.000Z",{"id":3484,"slug":3485,"title":3486,"excerpt":3487,"featuredImage":3488,"publishedAt":3489},"492","mcp-explained-what-it-connects-what-it-does-not-do-and-where-it-fits","MCP: объяснение — что он подключает, чего не делает и где ему место","Протокол контекста модели соединяет приложения ИИ с внешними инструментами, ресурсами и подсказками через стандартную границу клиент-сервер. Узнайте, что делает MCP, чего он не делает и где он вписывается в архитектуру агента.","\u002Fuploads\u002F2026\u002F10\u002Fmcp-explained-what-it-connects-what-it-does-not-do-and-where-it-fits-1791486640275-7ub1cq.webp","2026-10-08T15:09:00.000Z","fallback",[],[]]