[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:fr":3,"public-menus:all":38,"post:enterprise-ai-architecture-what-changes-when-ai-enters-a-company:fr":205,"related:post:enterprise-ai-architecture-what-changes-when-ai-enters-a-company:fr:1":3403},{"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","fr","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":3402},{"id":207,"title":208,"slug":209,"content":210,"contentJson":211,"excerpt":1563,"featuredImage":1564,"featuredImageAlt":1565,"featuredImageCaption":10,"featuredImageTitle":10,"featuredImageCopyright":10,"featuredImageAuthor":10,"featuredImageSourceUrl":10,"featuredImageLicense":10,"featuredImageIsAiGenerated":43,"status":1566,"publishedAt":1567,"createdAt":1568,"updatedAt":1569,"seoLocalePaths":1570,"categories":1579,"author":1595,"translations":1600},"485","Architecture de l’IA en entreprise : ce qui change lorsque l’IA entre dans une entreprise","enterprise-ai-architecture-what-changes-when-ai-enters-a-company","\u003Cp>L'architecture d'IA d'entreprise est l'architecture à l'échelle de l'organisation requise lorsque l'IA fait partie des systèmes, des données, des décisions et des opérations réels d'une entreprise. Le modèle n'est qu'un composant. Une fois que l'IA est connectée aux données d'entreprise, aux identités, aux autorisations, aux processus métier, aux fournisseurs externes et aux systèmes de production, l'architecture doit également définir l'autorité sur les données, les frontières d'accès, la propriété des risques, les dépendances vis-à-vis des fournisseurs, l'auditabilité, l'évaluation, le contrôle du cycle de vie, la conformité et la responsabilité opérationnelle. L'IA d'entreprise diffère donc à la fois d'une solution d'IA unique et d'une plateforme d'IA partagée : elle coordonne la manière dont de nombreux systèmes dotés d'IA s'intègrent dans l'organisation au sens large.\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\">Réponse directe\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>Qu'est-ce qui change lorsque l'IA entre dans une entreprise ?\u003C\u002Fstrong> Les responsabilités existantes de l'architecture d'entreprise s'étendent pour inclure le comportement probabiliste des modèles, les nouveaux flux de données, la récupération et l'ancrage, les dépendances aux modèles et aux fournisseurs, l'évaluation spécifique à l'IA, l'autorité des agents et des outils, le cycle de vie des modèles et des invites, la gestion des risques liés à l'IA, les obligations de transparence et les nouveaux modes de défaillance opérationnelle. L'architecture doit relier ces préoccupations aux structures existantes de l'entreprise en matière d'identité, de sécurité, de données, d'approvisionnement, de livraison et de gouvernance, au lieu de créer un « univers de l'IA » parallèle.\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\">L'IA d'entreprise n'est pas « un chatbot plus grand »\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Un chatbot peut être une interface utilisateur. L'architecture d'IA d'entreprise est le système de frontières qui se trouve derrière : à quelles données l'IA peut accéder, quelle source fait autorité, qui peut utiliser quelle capacité, si des fournisseurs externes peuvent recevoir les données, quelles actions un agent peut exécuter, comment les sorties sont évaluées, ce qui doit être journalisé, qui est responsable des incidents et comment les changements sont approuvés et annulés.\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\">Note sur les sources actuelles — 8 octobre 2026\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Les principes architecturaux de cet article sont destinés à être stables. La réglementation, les normes et les capacités des fournisseurs dépendent des versions. L'ISO\u002FIEC 42001:2023 et l'ISO\u002FIEC 23894:2023 sont des normes publiées en vigueur. Le NIST indique que l'AI RMF 1.0 est en cours de révision. Selon le texte consolidé actuel du règlement européen sur l'IA, le règlement s'applique généralement à partir du 2 août 2026, tandis que certaines dispositions relatives aux systèmes à haut risque ont des dates d'application ultérieures. La classification juridique doit toujours être vérifiée par rapport au droit en vigueur et au cas d'usage concret.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cnav class=\"editorjs-toc\" data-editorjs-toc=\"true\" aria-label=\"Sommaire\">\u003Cstrong class=\"editorjs-toc__title\">Sommaire\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\">Ce que signifie réellement l'architecture d'IA d'entreprise\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-11\" class=\"editorjs-toc__link\">L'exemple le plus simple\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-16\" class=\"editorjs-toc__link\">Où l'exemple simple s'arrête\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-19\" class=\"editorjs-toc__link\">Ce qui change dans l'architecture lorsque l'IA entre dans l'entreprise\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. La propriété métier devient partie intégrante de l'architecture technique\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-23\" class=\"editorjs-toc__link\">2. L'accès aux données ne suffit pas — l'autorité sur les données doit être définie\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-28\" class=\"editorjs-toc__link\">3. L'identité devient multicouche\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-32\" class=\"editorjs-toc__link\">4. Les permissions passent de l'accès au contenu à l'autorité d'action\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-35\" class=\"editorjs-toc__link\">5. Le fournisseur d'IA devient une dépendance d'entreprise\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-39\" class=\"editorjs-toc__link\">6. Le risque lié à l'IA devient un processus de cycle de vie\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-43\" class=\"editorjs-toc__link\">7. La gouvernance devient un système d'exploitation, pas un PDF de politique\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-46\" class=\"editorjs-toc__link\">8. L'évaluation devient un contrôle de production\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-50\" class=\"editorjs-toc__link\">9. L'observabilité doit inclure le comportement, les données et le contexte du modèle\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-53\" class=\"editorjs-toc__link\">10. Les composants d'IA nécessitent une propriété explicite du cycle de vie\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-56\" class=\"editorjs-toc__link\">11. La réponse aux incidents doit inclure des modes de défaillance spécifiques à l'IA\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-59\" class=\"editorjs-toc__link\">L'IA d'entreprise crée une propriété transversale\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-62\" class=\"editorjs-toc__link\">Un modèle pratique d'architecture d'IA d'entreprise\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-66\" class=\"editorjs-toc__link\">Cartographier l'IA d'entreprise comme des flux de données et d'autorité, pas comme des boîtes\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-68\" class=\"editorjs-toc__link\">Une entreprise a besoin d'un inventaire IA avant de pouvoir gouverner l'IA\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-71\" class=\"editorjs-toc__link\">La gouvernance de l'IA et l'architecture d'IA d'entreprise sont liées mais pas identiques\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-73\" class=\"editorjs-toc__link\">La réglementation devient une entrée d'architecture\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-78\" class=\"editorjs-toc__link\">Achats et architecture deviennent liés\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-81\" class=\"editorjs-toc__link\">L'architecture d'entreprise décide du niveau de contrôle de l'IA réellement nécessaire\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-84\" class=\"editorjs-toc__link\">L'IA transforme la gestion du changement en problème comportemental\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-87\" class=\"editorjs-toc__link\">L'IA d'entreprise a toujours besoin d'exigences non fonctionnelles et de décisions d'architecture\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-91\" class=\"editorjs-toc__link\">L'architecture IA d'entreprise doit être connectée à la livraison\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-94\" class=\"editorjs-toc__link\">Preuve du projet original : Enterprise Aaasaasa 0.1\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-101\" class=\"editorjs-toc__link\">Modèles d'implémentation de soutien issus du travail plus large sur la plateforme\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-104\" class=\"editorjs-toc__link\">Comment les principales normes s'articulent\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-107\" class=\"editorjs-toc__link\">Modes de défaillance courants de l'IA d'entreprise\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-109\" class=\"editorjs-toc__link\">Idées fausses courantes\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-111\" class=\"editorjs-toc__link\">Une séquence de décision pratique pour l'architecture d'IA d'entreprise\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-113\" class=\"editorjs-toc__link\">Liste de contrôle de l'architecture d'IA d'entreprise\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-115\" class=\"editorjs-toc__link\">Cas limites et limites\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-120\" class=\"editorjs-toc__link\">Qu'est-ce qui changerait cette réponse ?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-123\" class=\"editorjs-toc__link\">Connaissances canoniques associées\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-130\" class=\"editorjs-toc__link\">Questions fréquentes\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-132\" class=\"editorjs-toc__link\">Glossaire\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-134\" class=\"editorjs-toc__link\">Conclusion\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-138\" class=\"editorjs-toc__link\">Sources primaires et orientations actuelles\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fnav>\n\u003Ch2 id=\"section-6\">Ce que signifie réellement l'architecture d'IA d'entreprise\u003C\u002Fh2>\n\u003Cp>L'architecture d'IA d'entreprise décrit comment les capacités d'IA sont intégrées dans une organisation existante sans briser les frontières qui rendent déjà les systèmes d'entreprise gouvernables : propriété métier, identité, autorisation, classification des données, responsabilité des systèmes d'enregistrement, gestion des changements, approvisionnement, audit, continuité et opérations.\u003C\u002Fp>\n\u003Cp>L'architecte d'entreprise ne remplace pas l'architecte de solution d'IA ni l'architecte de plateforme d'IA. La portée d'entreprise pose une question différente : comment de multiples solutions d'IA et capacités d'IA partagées s'intègrent-elles dans l'architecture cible, les politiques, le paysage de données, le modèle de risque et le modèle opérationnel de l'entreprise ?\u003C\u002Fp>\n\u003Cp>Cela fait de l'architecture d'IA d'entreprise une discipline de coordination entre la technologie et l'organisation. Une intégration de modèle techniquement bonne peut néanmoins constituer un échec d'architecture d'entreprise si elle crée des flux de données fantômes, duplique l'identité, contourne l'approvisionnement, ne peut pas être auditée, n'a pas de propriétaire ou ne peut pas être modifiée en toute sécurité.\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Les architectures d'IA de solution, de plateforme et d'entreprise sont des portées différentes\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\">Architecture de solution d'IA\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\">Architecture de plateforme d'IA\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\">Architecture d'IA d'entreprise\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\">Portée principale\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\">Question principale\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\">Axe de propriété\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\">Condition de succès\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\">L'exemple le plus simple\u003C\u002Fh2>\n\u003Cp>Une entreprise commence avec un seul assistant documentaire interne. La première version recherche dans des documents approuvés et envoie le contexte récupéré à un modèle de langage. Au niveau de la solution, cela peut sembler simple.\u003C\u002Fp>\n\u003Cp>Puis une deuxième équipe veut de l'IA pour le support client. Une troisième veut un agent capable de mettre à jour des tickets. La finance veut de l'analyse documentaire. Les RH veulent un assistant interne. Les développeurs veulent des agents de codage. Soudain, l'entreprise a plusieurs fournisseurs, plusieurs classes de données, différents groupes d'utilisateurs, des index de récupération qui se chevauchent, des règles de journalisation différentes, de nouvelles autorisations d'outils, des secrets dupliqués et une propriété floue.\u003C\u002Fp>\n\u003Cp>À ce stade, la question n'est plus « L'assistant fonctionne-t-il ? » La question d'entreprise devient : quelles capacités sont approuvées, qui en est propriétaire, quelles données peuvent franchir quelle frontière, comment les identités et les autorisations sont-elles appliquées, quels fournisseurs sont acceptables, ce qui doit être audité et comment l'organisation peut-elle changer de modèles ou de fournisseurs sans perdre le contrôle ?\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">D'une fonctionnalité d'IA isolée à l'architecture d'entreprise\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. Cas d'usage isolé\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Une équipe connecte un modèle à un flux de travail et valide la valeur locale.\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. Des dépendances partagées apparaissent\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Plusieurs équipes ont besoin de fournisseurs, d'accès aux modèles, de récupération, d'identité, de secrets, d'observabilité et d'évaluation.\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. Les frontières de l'entreprise sont franchies\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">L'IA touche des données réglementées, des systèmes d'enregistrement, des fournisseurs externes, des actions privilégiées et des décisions métier.\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. La propriété doit devenir explicite\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Les métiers, l'architecture, les données, la sécurité, le juridique et la conformité, l'approvisionnement et les opérations doivent avoir des responsabilités définies.\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. Le cycle de vie devient organisationnel\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Les changements de modèle, d'invite, de fournisseur et les nouvelles capacités d'agent deviennent des changements gouvernés plutôt que des modifications locales de développeurs.\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. L'architecture devient reproductible\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">L'organisation établit des modèles réutilisables, des enregistrements de décisions, des contrôles, des exceptions et des points de validation pour les nouvelles charges de travail d'IA.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-16\">Où l'exemple simple s'arrête\u003C\u002Fh2>\n\u003Cp>L'architecture d'entreprise ne signifie pas que chaque composant d'IA doit être centralisé. Certaines capacités doivent être partagées ; d'autres doivent rester la propriété du domaine. La finance, les RH, l'ingénierie et le support client peuvent légitimement exiger des frontières de données, des fournisseurs, des critères d'évaluation et des règles d'approbation humaine différents.\u003C\u002Fp>\n\u003Cp>L'objectif d'entreprise n'est donc pas un modèle unique, une base de données vectorielle unique ou un assistant universel unique. L'objectif est une architecture cohérente avec une variation explicite : des politiques communes et des capacités réutilisables là où elles réduisent le risque et la duplication, plus des exceptions contrôlées là où les exigences métier ou réglementaires diffèrent.\u003C\u002Fp>\n\u003Ch2 id=\"section-19\">Ce qui change dans l'architecture lorsque l'IA entre dans l'entreprise\u003C\u002Fh2>\n\u003Ch3 id=\"section-20\">1. La propriété métier devient partie intégrante de l'architecture technique\u003C\u002Fh3>\n\u003Cp>Les applications traditionnelles ont déjà besoin de responsables métier. L'IA rend cette exigence plus visible car un comportement acceptable ne peut pas être défini uniquement par la disponibilité et la conformité fonctionnelle. Quelqu'un doit être responsable de l'usage prévu, de l'usage inacceptable, de la qualité des résultats, du chemin d'escalade et des conséquences de résultats erronés ou inappropriés.\u003C\u002Fp>\n\u003Cp>Une équipe de modèle ne peut pas décider seule si une réponse est acceptable pour les RH, la finance, le juridique ou un usage orienté client. L'architecture d'IA d'entreprise relie donc la conception technique à une capacité métier explicite, un responsable redevable, un groupe d'utilisateurs et un contexte décisionnel.\u003C\u002Fp>\n\u003Ch3 id=\"section-23\">2. L'accès aux données ne suffit pas — l'autorité sur les données doit être définie\u003C\u002Fh3>\n\u003Cp>L'IA d'entreprise combine fréquemment des bases de données opérationnelles, des documents, des index de recherche, des bases vectorielles, des entrepôts de données, des systèmes SaaS et des connaissances externes. L'architecture doit distinguer où l'information est stockée de quelle source fait autorité pour une affirmation ou une action donnée.\u003C\u002Fp>\n\u003Cp>Un index vectoriel peut améliorer la récupération mais ne devrait pas devenir silencieusement le système d'enregistrement de l'entreprise. Une réponse de modèle peut résumer un enregistrement ERP mais ne devrait pas remplacer l'ERP comme source faisant autorité. Un contexte mis en cache peut améliorer la latence mais devient dangereux lorsque les permissions ou l'état métier sous-jacent changent.\u003C\u002Fp>\n\u003Cp>L'IA d'entreprise a donc besoin de provenance, de fraîcheur, de classification des sources, de propagation des autorisations et de règles d'invalidation en plus de l'intégration de données ordinaire.\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\">Règle des données d'entreprise\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>Le système d'IA peut transformer, récupérer et raisonner sur les données d'entreprise sans devenir l'autorité pour ces données.\u003C\u002Fstrong> L'architecture doit préserver un chemin de retour vers la source faisant autorité chaque fois que le cas d'usage nécessite des preuves, une vérification ou une action conséquente.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch3 id=\"section-28\">3. L'identité devient multicouche\u003C\u002Fh3>\n\u003Cp>L'IA d'entreprise a plus d'identités que l'utilisateur humain. Une requête peut impliquer une identité utilisateur, une identité d'application, une identité de service, une identité d'agent, un identifiant de fournisseur, un identifiant d'outil et un contexte de locataire ou d'organisation.\u003C\u002Fp>\n\u003Cp>Ces identités ne doivent pas être fusionnées en une seule clé API partagée. L'autorisation doit rester attribuable au bon principal, et les outils privilégiés ne doivent recevoir que l'autorité requise pour l'opération en cours.\u003C\u002Fp>\n\u003Cp>Pour les systèmes agentiques, cela devient particulièrement important : un modèle peut proposer une action, mais l'environnement d'exécution doit décider si l'identité demandeuse est autorisée à l'exécuter. La capacité du modèle n'est pas une autorisation.\u003C\u002Fp>\n\u003Ch3 id=\"section-32\">4. Les permissions passent de l'accès au contenu à l'autorité d'action\u003C\u002Fh3>\n\u003Cp>Un assistant en lecture seule a principalement besoin d'un accès contrôlé à l'information. Un agent d'entreprise peut créer des tickets, modifier des enregistrements, envoyer des messages, déclencher des workflows ou exploiter des systèmes externes. Cela introduit une classe de risque différente car le système peut changer l'état plutôt que simplement le décrire.\u003C\u002Fp>\n\u003Cp>L'architecture doit séparer les capacités de lecture, d'écriture, d'approbation et d'administration ; définir les points de validation humaine là où les conséquences le justifient ; et préserver une piste d'audit qui identifie ce qui a été demandé, ce qui a été approuvé et ce qui a réellement changé.\u003C\u002Fp>\n\u003Ch3 id=\"section-35\">5. Le fournisseur d'IA devient une dépendance d'entreprise\u003C\u002Fh3>\n\u003Cp>Appeler une API de modèle est aussi une relation fournisseur. L'architecture peut dépendre de la disponibilité du fournisseur, des conditions de service, des conditions de traitement des données, des régions prises en charge, du cycle de vie du modèle, des quotas, de la tarification, de la compatibilité API, des contrôles de sécurité et des notifications de changement.\u003C\u002Fp>\n\u003Cp>Cela signifie que la sélection d'un fournisseur n'est pas seulement une décision de benchmark. L'approvisionnement, la sécurité, la confidentialité, l'examen juridique, la planification de la continuité et la stratégie de sortie peuvent tous devenir des entrées d'architecture.\u003C\u002Fp>\n\u003Cp>L'abstraction du fournisseur peut réduire le couplage, mais uniquement là où les capacités sous-jacentes sont véritablement portables. L'utilisation d'outils, la sortie structurée, les limites de contexte, la multimodalité, les contrôles de sécurité, le fine-tuning et les fonctionnalités d'agents hébergés peuvent différer sensiblement entre les fournisseurs.\u003C\u002Fp>\n\u003Ch3 id=\"section-39\">6. Le risque lié à l'IA devient un processus de cycle de vie\u003C\u002Fh3>\n\u003Cp>Le risque lié à l'IA n'est pas clos par une seule approbation avant le lancement. Le modèle, le prompt, le corpus de récupération, l'ensemble d'outils, le fournisseur, la population d'utilisateurs et le processus métier environnant peuvent tous changer après le déploiement. Le profil de risque change avec eux.\u003C\u002Fp>\n\u003Cp>L'ISO\u002FIEC 23894:2023 traite explicitement de l'intégration de la gestion des risques liés à l'IA dans les activités et fonctions organisationnelles. Le NIST AI RMF encadre de même la gestion des risques tout au long du cycle de vie. L'architecture d'entreprise devrait donc faire de l'examen des risques une partie du changement et des opérations plutôt qu'un document de conformité isolé.\u003C\u002Fp>\n\u003Cp>Le risque doit également être proportionné. Un assistant de synthèse et un système autonome qui modifie des enregistrements de production ne devraient pas recevoir des contrôles identiques simplement parce que tous deux utilisent un LLM.\u003C\u002Fp>\n\u003Ch3 id=\"section-43\">7. La gouvernance devient un système d'exploitation, pas un PDF de politique\u003C\u002Fh3>\n\u003Cp>L'ISO\u002FIEC 42001:2023 définit les exigences pour établir, mettre en œuvre, maintenir et améliorer continuellement un système de management de l'IA. La conséquence architecturale est importante : la gouvernance doit relier la politique à de véritables inventaires, responsabilités, processus, contrôles, preuves, revues et boucles d'amélioration.\u003C\u002Fp>\n\u003Cp>Une politique d'IA d'entreprise qui n'est pas liée à l'approbation des fournisseurs, à l'identité, à la journalisation, à la gestion des changements, à l'évaluation et à la réponse aux incidents a un effet architectural limité. L'organisation a besoin de mécanismes qui rendent la politique applicable ou du moins observable.\u003C\u002Fp>\n\u003Ch3 id=\"section-46\">8. L'évaluation devient un contrôle de production\u003C\u002Fh3>\n\u003Cp>Les tests d'acceptation traditionnels supposent que la même entrée produit normalement le même résultat déterministe. L'IA générative peut être non déterministe, sensible au contexte et dépendante de connaissances externes changeantes. L'acceptation en production nécessite donc des évaluations spécifiques aux tâches, des suites de régression et des seuils observables plutôt que de simples tests unitaires.\u003C\u002Fp>\n\u003Cp>La plateforme peut fournir une infrastructure d'évaluation réutilisable, mais l'entreprise doit toujours assumer la responsabilité de la vérité terrain du domaine et des portes de mise en production. Une équipe IA centrale ne peut pas inventer la bonne réponse pour chaque domaine métier.\u003C\u002Fp>\n\u003Cp>Les modifications de modèle, de prompt, de récupération et d'outils devraient être traçables jusqu'aux preuves d'évaluation lorsque le changement peut affecter matériellement le comportement de sortie.\u003C\u002Fp>\n\u003Ch3 id=\"section-50\">9. L'observabilité doit inclure le comportement, les données et le contexte du modèle\u003C\u002Fh3>\n\u003Cp>Les taux d'erreur CPU, mémoire et HTTP ne suffisent pas pour les charges de travail d'IA. L'observabilité en production peut nécessiter des identifiants de modèle\u002Ffournisseur, la latence, l'utilisation de jetons, le coût, les résultats de récupération, les appels d'outils, le comportement de refus, les scores d'évaluation, les événements de sécurité et les classifications de défaillance.\u003C\u002Fp>\n\u003Cp>En même temps, la télémétrie d'IA peut contenir des données sensibles. Les journaux de prompts et de réponses peuvent devenir un magasin de données fantôme. L'architecture d'entreprise doit donc définir ce qui peut être journalisé, comment il est expurgé, qui peut y accéder, combien de temps il est conservé et quand la traçabilité détaillée doit être désactivée.\u003C\u002Fp>\n\u003Ch3 id=\"section-53\">10. Les composants d'IA nécessitent une propriété explicite du cycle de vie\u003C\u002Fh3>\n\u003Cp>Les modèles peuvent être renommés, remplacés, retirés ou modifiés par les fournisseurs. Les modèles d'embedding peuvent invalider une stratégie d'index. Les modèles de prompts et les instructions système peuvent modifier le comportement. Les environnements d'exécution et protocoles d'agents peuvent évoluer. Les outils externes peuvent modifier leurs schémas et permissions.\u003C\u002Fp>\n\u003Cp>L'architecture d'entreprise doit décider qui détecte ces changements, qui les teste, qui les approuve, comment les consommateurs sont notifiés, comment le retour arrière fonctionne et quelles preuves sont requises avant qu'une nouvelle version ne devienne la version par défaut.\u003C\u002Fp>\n\u003Ch3 id=\"section-56\">11. La réponse aux incidents doit inclure des modes de défaillance spécifiques à l'IA\u003C\u002Fh3>\n\u003Cp>Un incident lié à l'IA peut être une panne de fournisseur, une fuite de données, un chemin d'injection de prompt, une défaillance d'autorisation, une contamination de la récupération, un comportement inattendu du modèle, une exécution d'outil non sécurisée, un pic de coûts, des connaissances obsolètes, une régression d'évaluation ou un changement de comportement d'un modèle externe.\u003C\u002Fp>\n\u003Cp>Le runbook d'entreprise doit donc aller au-delà de « redémarrer le service ». Il peut nécessiter de désactiver une route de modèle, de révoquer l'accès à un outil, de geler un corpus, de changer une version de prompt, de désactiver une capacité d'agent, de changer de fournisseur, d'escalader vers un propriétaire de domaine ou de préserver les traces pour l'investigation.\u003C\u002Fp>\n\u003Ch2 id=\"section-59\">L'IA d'entreprise crée une propriété transversale\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\">Préoccupation\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Propriétaire ou contributeur d'entreprise typique\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Question d'architecture\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Usage métier\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Propriétaire métier \u002F propriétaire de produit\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quelle décision ou quel flux de travail l'IA est-elle autorisée à soutenir ou à automatiser ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Architecture de solution\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Architecte IA \u002F de solution\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Comment la charge de travail concrète satisfait-elle ses exigences fonctionnelles et de qualité ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Capacités IA partagées\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Plateforme IA \u002F ingénierie de plateforme\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quels services réutilisables de modèle, de récupération, d'agent et d'observabilité sont fournis ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Cohérence d'entreprise\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Architecture d'entreprise\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Comment les systèmes d'IA s'intègrent-ils à l'architecture cible, aux normes, aux modèles d'intégration et à la propriété organisationnelle ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Autorité des données\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Propriétaire des données \u002F propriétaire de domaine\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quelles données font autorité, sont à jour, autorisées et suffisamment gouvernées ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Identité et sécurité\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">IAM \u002F architecture de sécurité\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quelles identités peuvent accéder à quelles données et exécuter quelles actions ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Risque et conformité\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Risque \u002F juridique \u002F conformité \u002F vie privée\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quelles obligations, utilisations interdites, contrôles et preuves s'appliquent à ce cas d'usage ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Dépendance fournisseur\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Achats \u002F gestion des fournisseurs \u002F architecture\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quels risques contractuels, opérationnels et de sortie découlent du fournisseur ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Opérations\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">SRE \u002F opérations \u002F propriétaire de plateforme\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Comment le système est-il surveillé, supporté, dégradé, récupéré et modifié ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Acceptation du domaine\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Spécialistes métier\u002Fdomaine\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Qu'est-ce qui compte comme un résultat correct, sûr ou utile dans ce domaine ?\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\">Une matrice RACI n'est pas une architecture en soi\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Les matrices de responsabilité ne sont utiles que lorsqu'elles se connectent à de véritables frontières de système, approbations, propriété des données, interfaces, runbooks et processus de changement. L'IA d'entreprise a besoin d'une propriété responsable qui peut être tracée jusqu'aux contrôles techniques et aux actions opérationnelles.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-62\">Un modèle pratique d'architecture d'IA d'entreprise\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\">Modèle en couches proposé\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Le modèle suivant est une synthèse pratique pour raisonner sur l'architecture d'IA d'entreprise. Il n'est pas présenté comme une norme ISO ou NIST. Son objectif est de rendre explicites les frontières inter-organisationnelles.\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\">Couche\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Responsabilité principale\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Métier et politique\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Cas d'usage approuvés, propriétaires responsables, appétit pour le risque, utilisations interdites, responsabilité humaine, acceptation métier.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Identité et autorité\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Identités utilisateur\u002Fservice\u002Fagent, rôles, périmètre locataire ou organisationnel, actions privilégiées, chemins d'approbation.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Données d'entreprise\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Systèmes d'enregistrement, sources documentaires, produits de données, provenance, classification, rétention, fraîcheur et accès.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Plateforme IA\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Accès fournisseur\u002Fmodèle, primitives de récupération, environnements d'exécution d'agents, courtiers d'outils, infrastructure d'évaluation, observabilité, quotas et secrets.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Solutions IA\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Flux de travail métier, prompts\u002Finstructions, récupération de domaine, logique métier, critères d'acceptation et expérience utilisateur.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Intégration et outils\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">API, applications d'entreprise, flux de travail, messagerie, systèmes de fichiers, services externes et exécution d'actions.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Risque et gouvernance\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Inventaire, évaluation, preuves de conformité, gestion des exceptions, approbation des modèles\u002Ffournisseurs, revue et audit.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Opérations et cycle de vie\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Déploiement, surveillance, incidents, versions, changements de modèle\u002Ffournisseur, dépréciation, retour arrière et continuité.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>L'architecture est la plus solide lorsque chaque couche peut énoncer à la fois ses responsabilités et ses non-responsabilités. Par exemple, la plateforme IA peut appliquer la politique du fournisseur et collecter des traces sans devenir la source de vérité pour les données RH. Une solution peut définir des prompts de domaine sans posséder l'IAM d'entreprise. Un propriétaire métier peut approuver un cas d'usage sans qu'on attende de lui qu'il exploite la passerelle d'inférence.\u003C\u002Fp>\n\u003Ch2 id=\"section-66\">Cartographier l'IA d'entreprise comme des flux de données et d'autorité, pas comme des boîtes\u003C\u002Fh2>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Une requête d'IA d'entreprise à conséquences\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. Contexte métier\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">L'utilisateur demande une tâche dans le cadre d'un cas d'usage approuvé avec un propriétaire métier responsable.\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. Identité et autorisation\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Le système résout l'utilisateur, l'application, le service et le périmètre locataire ou organisationnel avant tout accès privilégié.\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. Acquisition de données faisant autorité\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">La solution lit ou récupère uniquement les sources autorisées pour l'identité et la tâche en cours.\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. Traitement IA\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Un modèle\u002Ffournisseur approuvé traite le contexte minimal nécessaire selon des règles définies de routage et de traitement des données.\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. Frontière d'outil ou d'action\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Toute action modifiant l'état est autorisée indépendamment et peut nécessiter une approbation humaine selon les conséquences.\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. Validation\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Le résultat est vérifié par rapport aux règles d'acceptation, de preuve ou de sécurité spécifiques à la solution.\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. Audit et observabilité\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Les métadonnées autorisées, décisions, routes, appels d'outils et résultats sont enregistrés sans créer de journaux non contrôlés de données sensibles.\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. Retour d'information et cycle de vie\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Les échecs et les résultats d'évaluation alimentent les changements de modèle, de prompt, de données, de politique et de processus via une gestion contrôlée des changements.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-68\">Une entreprise a besoin d'un inventaire IA avant de pouvoir gouverner l'IA\u003C\u002Fh2>\n\u003Cp>Les organisations ne peuvent pas gérer les systèmes d'IA qu'elles ne peuvent pas identifier. L'architecture d'entreprise doit maintenir un inventaire à un niveau utile pour les décisions, pas simplement une liste de noms de modèles.\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\">Champ d'inventaire\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Pourquoi c'est important\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Cas d'usage et propriétaire\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Relie la technologie à un objectif métier responsable.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Utilisateurs et parties affectées\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Définit qui interagit avec le système ou est affecté par celui-ci.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modèle\u002Ffournisseur\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Identifie la dépendance externe, la capacité et le risque de cycle de vie.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sources de données\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Soutient l'examen de l'autorité, de la vie privée, de la classification et de la provenance.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Emplacement de déploiement\u002Fexécution\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Clarifie l'emplacement de traitement, la connectivité et le contrôle opérationnel.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Outils\u002Factions\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Montre si l'IA peut modifier l'état externe et à quel niveau de conséquence.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Surveillance humaine\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Enregistre où une revue, une approbation ou une escalade est requise.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Risque\u002Fclassification\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Relie le système aux contrôles organisationnels et réglementaires.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Preuves d'évaluation\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Montre ce qui a été testé et dans quelles conditions de validité.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Version actuelle\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Permet de tracer les incidents et régressions jusqu'à l'état réellement déployé.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">État du cycle de vie\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Proposé, expérimental, approuvé, en production, restreint, déprécié ou retiré.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-71\">La gouvernance de l'IA et l'architecture d'IA d'entreprise sont liées mais pas identiques\u003C\u002Fh2>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Gouvernance versus architecture\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\">Gouvernance de l'IA\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\">Architecture d'IA d'entreprise\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\">Objectif\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\">Exemple\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\">Échec si isolé\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\">La réglementation devient une entrée d'architecture\u003C\u002Fh2>\n\u003Cp>Pour les organisations opérant dans l'Union européenne, l'AI Act peut créer des exigences qui affectent la conception des systèmes, la documentation, la transparence, la gouvernance et les processus opérationnels. L'impact architectural dépend du rôle de l'organisation dans la chaîne de valeur de l'IA et de la classification concrète du système ; tous les systèmes d'IA n'ont pas les mêmes obligations.\u003C\u002Fp>\n\u003Cp>Depuis le 8 octobre 2026, le texte consolidé actuel indique que le Règlement s'applique généralement à partir du 2 août 2026. Les règles de gouvernance et les obligations pour les modèles d'IA à usage général ont commencé à s'appliquer plus tôt, tandis que certaines dispositions relatives aux systèmes à haut risque ont des dates ultérieures. La Commission a également commencé à faire appliquer de nouvelles exigences de transparence à partir du 2 août 2026 pour les systèmes interactifs et de contenu synthétique concernés.\u003C\u002Fp>\n\u003Cp>La leçon d'architecture d'entreprise n'est pas de « mettre la conformité dans le modèle ». Elle consiste à rendre la classification, le rôle de fournisseur\u002Fdéployeur, la documentation, la transparence, la supervision, la journalisation et les preuves de changement traçables jusqu'au système qui met réellement en œuvre le cas d'usage.\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\">La portée juridique dépend du cas d'usage\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Cet article décrit des implications architecturales, et non un avis juridique. L'architecture d'IA d'entreprise doit préserver les informations nécessaires aux spécialistes juridiques et de conformité pour classifier le système réel et associer les obligations à des contrôles concrets. L'architecture ne doit pas figer une interprétation réglementaire comme si chaque charge de travail d'IA avait le même statut.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-78\">Achats et architecture deviennent liés\u003C\u002Fh2>\n\u003Cp>Un modèle externe ou une plateforme d'IA gérée peut devenir une dépendance profonde même lorsque l'intégration ne nécessite que quelques appels d'API. L'architecture d'entreprise doit donc rendre les questions d'achat techniquement concrètes.\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\">Question d'achat\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Conséquence architecturale\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Où les données sont-elles traitées ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Région, chemin réseau, résidence des données et contrôles de transfert.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les données clients sont-elles conservées ou utilisées pour l'amélioration du fournisseur ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Minimisation des données, contrôles contractuels et éligibilité du fournisseur.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Comment les modèles sont-ils versionnés ou retirés ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Tests de régression, compatibilité, repli et planification du cycle de vie.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quels sont les quotas et les limites de service ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Architecture de capacité, contrôle d'admission et gestion des défaillances.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quelle est la portabilité de l'intégration ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Abstraction du fournisseur, coût de sortie et effort de migration.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quelles informations sur les incidents sont disponibles ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Observabilité, capacité d'investigation et escalade du support.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quels sous-traitants ou services externes sont impliqués ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Cartographie des dépendances et évaluation des risques.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Qu'est-ce qui change sans approbation explicite du client ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Détection des changements, portes de release et stratégie d'acceptation.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-81\">L'architecture d'entreprise décide du niveau de contrôle de l'IA réellement nécessaire\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\">Exigence\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Réponse architecturale possible\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Accès rapide à des modèles gérés\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Fournisseur géré avec identité d'entreprise, contrôles de passerelle et revue contractuelle.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Données privées avec orchestration gérée\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Plan de contrôle géré plus exécution contrôlée par le client ou plan de données privé lorsque pris en charge.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Localité ou souveraineté stricte\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Architecture restreinte à une région, souveraine, privée ou auto-hébergée selon l'exigence réelle.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Environnement isolé (air-gapped)\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modèles hébergés localement, recherche locale, outillage local, mise à jour\u002Fdistribution hors ligne et observabilité isolée.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Portabilité du fournisseur\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">État de domaine détenu par l'application plus adaptateurs et contrats qui isolent le comportement spécifique au fournisseur lorsque c'est pratique.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Contrôle maximal de la sémantique des agents\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Runtime auto-géré ou profondément contrôlé avec propriété explicite des outils, du contexte, de l'état et du cycle de vie.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>L'architecture la plus contrôlée n'est pas automatiquement la meilleure architecture d'entreprise. Plus de propriété augmente la responsabilité en matière de correctifs, de capacité, de sécurité, de tests, d'opérations de modèles et de réponse aux incidents. L'architecture d'entreprise ne doit élever le niveau de contrôle que là où l'exigence justifie la charge opérationnelle supplémentaire.\u003C\u002Fp>\n\u003Ch2 id=\"section-84\">L'IA transforme la gestion du changement en problème comportemental\u003C\u002Fh2>\n\u003Cp>Une mise à jour normale de dépendance peut altérer les performances ou la compatibilité. Un changement d'IA peut aussi altérer le comportement. Remplacer un modèle, modifier un prompt système, changer la recherche, ajouter un outil ou modifier la politique de contexte peut modifier la façon dont le système interprète et répond, même si le code applicatif environnant change à peine.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Un chemin de changement d'IA en production\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. Changement identifié\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Un changement de modèle, de fournisseur, de prompt, de source de recherche, d'outil, de politique ou de runtime est proposé ou détecté.\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. Impact cartographié\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Les solutions affectées, classes de données, utilisateurs, contrôles de risque, coûts, contrats et dépendances opérationnelles sont identifiés.\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. Décision d'architecture mise à jour\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Les choix importants et les compromis sont consignés ; les décisions remplacées restent traçables historiquement.\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. Évaluation exécutée\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Les tests pertinents de régression, de sécurité, de recherche, de latence, de coût et de domaine sont exécutés.\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. Approbation appliquée\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Le niveau d'approbation suit les conséquences, le risque et la politique organisationnelle.\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. Déploiement contrôlé\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Une release versionnée, un canari ou un déploiement progressif est utilisé lorsque approprié.\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. Preuves de production collectées\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">La télémétrie, les incidents, les retours et les résultats métier sont surveillés.\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. Retour arrière ou acceptation\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Le changement est accepté, restreint, annulé ou remplacé sur la base des preuves.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-87\">L'IA d'entreprise a toujours besoin d'exigences non fonctionnelles et de décisions d'architecture\u003C\u002Fh2>\n\u003Cp>L'IA ne remplace pas la discipline architecturale ordinaire. Les exigences non fonctionnelles restent les conditions cibles : disponibilité, latence, confidentialité, isolation, auditabilité, récupérabilité, limites de coût, explicabilité ou autres exigences de qualité. Les enregistrements de décisions d'architecture préservent la réponse choisie et ses compromis.\u003C\u002Fp>\n\u003Cp>La différence propre à l'IA est que certains attributs de qualité doivent être évalués de manière probabiliste ou empirique. « Les réponses doivent être utiles » est trop vague. Une exigence de production doit identifier la tâche, les données, la population d'utilisateurs, les conditions d'échec acceptables, la méthode de mesure et le seuil lorsque c'est pratique.\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\">Chaîne de traçabilité d'entreprise\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>Besoin métier → exigence \u002F NFR → décision d'architecture → mise en œuvre → évaluation \u002F validation → observation en production → décision de changement.\u003C\u002Fstrong> L'IA ajoute de nouvelles variables à cette chaîne ; elle ne la rend pas inutile.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-91\">L'architecture IA d'entreprise doit être connectée à la livraison\u003C\u002Fh2>\n\u003Cp>Une architecture qui n'atteint jamais le backlog, l'implémentation, l'acceptation et les opérations reste conceptuelle. L'IA d'entreprise a donc besoin d'une traçabilité depuis les décisions d'architecture vers le travail de livraison et en retour depuis les preuves d'implémentation vers l'architecture.\u003C\u002Fp>\n\u003Cp>Jira et Confluence sont des exemples d'outils qui peuvent soutenir cette séparation lorsqu'ils sont utilisés délibérément : Confluence peut conserver les exigences, l'architecture, les décisions, les risques et la justification ; Jira peut gérer le travail de livraison actionnable et l'état. Le principe important est la traçabilité, non la marque de l'outil.\u003C\u002Fp>\n\u003Ch2 id=\"section-94\">Preuve du projet original : 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\">Preuve de projet, non affirmation de preuve de marché\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Enterprise Aaasaasa 0.1 est utilisé ici comme preuve de projet original pour une réflexion structurée sur l'architecture d'entreprise et la livraison. Il s'agit d'un contexte de PoC \u002F projet d'entreprise, et non d'une preuve d'adoption massive par les clients, d'utilisation en production à l'échelle de l'entreprise ou de traction commerciale.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cp>Enterprise Aaasaasa 0.1 combine l'architecture de plateforme, les concepts SaaS\u002FAPI, l'internationalisation, l'intégration de l'IA et la gouvernance structurée de projet. Le projet a été délibérément organisé de sorte que les exigences, l'architecture, la livraison du prototype, la validation et la clôture soient des jalons distincts plutôt qu'une phase d'implémentation indifférenciée.\u003C\u002Fp>\n\u003Cp>L'orientation architecturale inclut des concepts multi-instances \u002F multi-bases de données ainsi que des capacités API, CRUD, i18n et IA. Cela importe pour l'IA d'entreprise car les frontières de locataire ou d'instance, la propriété des bases de données et les services applicatifs doivent rester explicites lorsque des fonctionnalités d'IA sont ajoutées.\u003C\u002Fp>\n\u003Cp>La structure du projet a également traité les retards d'architecture, la dérive du périmètre et les préoccupations liées à l'IA et à la protection des données comme des risques de projet plutôt que de les découvrir seulement lors de l'implémentation. Les parties prenantes incluaient des perspectives techniques, de sécurité, de sponsor\u002Fpilotage et de services externes, ce qui est plus proche de la nature réelle interfonctionnelle de l'IA d'entreprise qu'un prototype uniquement basé sur un modèle.\u003C\u002Fp>\n\u003Cp>La preuve utile est donc l'intégration de l'architecture et de la livraison : la structure métier et de projet, les jalons, les risques, l'architecture, le backend\u002FAPI, le travail frontend\u002FIA, la validation et la clôture sont traités comme des responsabilités connectées. Ce modèle est réutilisable même si le projet lui-même ne doit pas être présenté comme une preuve d'adoption externe en entreprise.\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\">Élément du projet\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Leçon d'architecture IA d'entreprise\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Jalon des exigences\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La capacité d'IA doit commencer par un besoin défini, un périmètre, une acceptation et des contraintes de qualité.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Jalon d'architecture\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les données, l'API, les frontières d'instance\u002Fbase de données et l'intégration de l'IA sont un travail de conception explicite.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Jalon de prototype\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'architecture doit devenir suffisamment exécutable pour exposer les risques d'intégration.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Jalon de validation\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Un prototype fonctionnel n'est pas la même chose qu'une acceptation validée.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Registre des risques\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le périmètre, les retards d'architecture et les préoccupations liées à l'IA et à la protection des données sont gérés comme des risques de livraison.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Structure des parties prenantes\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'IA d'entreprise couvre le sponsor\u002Fmétier, l'architecture, la sécurité, les fournisseurs externes et la livraison.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Clôture du projet\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les décisions, les risques restants et les preuves de validation doivent survivre au-delà du sprint d'implémentation.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-101\">Modèles d'implémentation de soutien issus du travail plus large sur la plateforme\u003C\u002Fh2>\n\u003Cp>Un travail d'implémentation distinct dans la plateforme Aaasaasa plus large fournit des exemples concrets de frontières que l'architecture IA d'entreprise doit préserver : RBAC à portée de locataire dans le CMS, séparation explicite fournisseur\u002Fmodèle\u002Fruntime\u002Fpermission dans Aaasaasa AI Client, et récupération axée sur la provenance dans le Source of Truth Research Engine.\u003C\u002Fp>\n\u003Cp>Ces projets ne doivent pas être fusionnés en une seule plateforme de production revendiquée. Leur valeur ici est plus étroite : ils démontrent des modèles implémentés pour la portée d'identité, les frontières de fournisseur, les permissions d'exécution contrôlées, la provenance de récupération et la traçabilité des preuves qui sont directement pertinents pour l'IA d'entreprise.\u003C\u002Fp>\n\u003Ch2 id=\"section-104\">Comment les principales normes s'articulent\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\">Source\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Ce qu'elle apporte à l'architecture IA d'entreprise\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\">Système de management de l'IA au niveau de l'organisation : politiques, objectifs, processus, responsabilité, surveillance et amélioration continue.\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\">Lignes directrices pour intégrer la gestion des risques spécifiques à l'IA dans les activités et fonctions organisationnelles.\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\">Cadre volontaire orienté cycle de vie pour gérer les risques liés à l'IA ; organisé autour de Govern, Map, Measure et 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\">Profil d'IA générative étendant l'AI RMF avec des risques et actions spécifiques à l'IA générative.\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\">Obligations réglementaires contraignantes dans l'UE dont l'applicabilité dépend du rôle, du type de système et de la classification.\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\">Concepts généraux de description d'architecture pour exprimer les préoccupations, points de vue, décisions et relations.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>Ces sources résolvent des problèmes différents. ISO\u002FIEC 42001 ne remplace pas l'architecture technique. ISO\u002FIEC 23894 et NIST AI RMF ne définissent pas une pile logicielle obligatoire unique. L'EU AI Act est une loi, pas un modèle de conception de plateforme. L'architecture doit traduire les exigences organisationnelles, de risque et légales applicables en frontières système implémentables et en preuves.\u003C\u002Fp>\n\u003Ch2 id=\"section-107\">Modes de défaillance courants de l'IA d'entreprise\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\">Mode de défaillance\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Pourquoi cela échoue\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Chaque équipe achète l'IA indépendamment\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Crée des fournisseurs fantômes, des secrets dupliqués, un traitement des données incohérent et un faible levier sur le risque fournisseur.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Une équipe IA centrale possède chaque décision de domaine\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Centralise le contrôle technique mais perd la responsabilité du domaine et crée un goulot d'étranglement.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La base de données vectorielle devient la source de vérité\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'infrastructure de récupération remplace silencieusement les systèmes faisant autorité et les règles de fraîcheur.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Une clé API partagée pour tous les utilisateurs et agents\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Détruit l'attribution, le moindre privilège et l'auditabilité significative.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Un changement de modèle déployé comme un correctif de bibliothèque mineur\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les régressions comportementales peuvent atteindre la production sans évaluation du domaine.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Tous les prompts et sorties sont journalisés pour toujours\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'observabilité crée un référentiel de données sensibles non contrôlé.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La gouvernance n'est que de la documentation\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les politiques existent sans points d'application, preuves ou responsabilité opérationnelle.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La conformité est déléguée au fournisseur\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le rôle, le cas d'usage, les données et les obligations opérationnelles de l'organisation restent non résolus.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'agent peut appeler des outils parce que le modèle prend en charge l'utilisation d'outils\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La capacité est confondue avec l'autorisation.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La santé de la plateforme équivaut à l'exactitude métier\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La disponibilité des points de terminaison et des modèles ne prouve pas la qualité des réponses du domaine ou des résultats acceptables.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Aucune stratégie de sortie pour la dépendance au modèle\u002Ffournisseur\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Un changement de prix, de politique, de capacité ou de disponibilité devient une migration d'urgence.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-109\">Idées fausses courantes\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\">Idée fausse\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Meilleur modèle\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« L'IA d'entreprise signifie un chatbot à l'échelle de l'entreprise. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le chatbot est une interface ; l'architecture d'IA d'entreprise gouverne les données sous-jacentes, l'identité, le fournisseur, l'environnement d'exécution, les risques et les opérations.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« Si nous utilisons un fournisseur de modèle réputé, la gouvernance est résolue. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les contrôles du fournisseur ne définissent pas votre cas d'usage, l'autorité sur les données, les permissions des utilisateurs, l'acceptation métier ou le rôle juridique.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« L'IA privée signifie que tout doit être auto-hébergé. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les exigences de confidentialité peuvent conduire à plusieurs architectures ; la frontière de contrôle requise doit être énoncée précisément.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« La gouvernance de l'IA relève du juridique, l'architecture relève de l'informatique. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les deux disciplines doivent être connectées car les obligations politiques nécessitent des contrôles implémentables et des preuves.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« Un modèle d'entreprise unique est plus simple. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La standardisation peut aider, mais les charges de travail peuvent nécessiter différentes modalités, régions, coûts, niveaux de qualité ou modèles de contrôle.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« Le risque lié à l'IA est un risque de modèle. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le risque peut provenir des données, des invites, de la récupération, de l'identité, des outils, des interfaces, des opérations, des utilisateurs et des processus organisationnels.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« L'humain dans la boucle rend un agent sûr. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'approbation humaine n'aide que si le réviseur dispose d'un contexte utile, de l'autorité, du temps et d'un point de décision clair.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« Un pilote réussi prouve la préparation à l'échelle de l'entreprise. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Un pilote prouve une capacité limitée ; la préparation à l'échelle de l'entreprise nécessite également l'intégration, la gouvernance, le cycle de vie, les opérations et des contrôles reproductibles.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-111\">Une séquence de décision pratique pour l'architecture d'IA d'entreprise\u003C\u002Fh2>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">De l'opportunité à une capacité d'entreprise gouvernée\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. Définir la capacité métier\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Énoncer l'utilisateur, la décision ou le flux de travail, la valeur attendue et le propriétaire responsable.\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. Classifier les données et l'autorité\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Identifier les systèmes de référence, les données personnelles\u002Fconfidentielles, les exigences de rétention, de fraîcheur et de provenance.\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. Définir les frontières d'identité et d'action\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Déterminer qui peut lire, générer, décider, approuver et modifier les systèmes externes.\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. Sélectionner les responsabilités de la solution et de la plateforme\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Décider ce qui appartient à la charge de travail, ce qui peut être partagé et ce qui reste la propriété de l'entreprise.\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. Évaluer la dépendance au fournisseur et à l'environnement d'exécution\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Évaluer les options gérées, auto-hébergées, privées, souveraines ou hybrides par rapport aux exigences réelles.\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. Cartographier les risques et les obligations réglementaires\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Déterminer le niveau de risque, les contrôles organisationnels et les responsabilités juridiques applicables pour le système concret.\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. Définir une acceptation mesurable\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Créer des critères d'évaluation pour la qualité, la fiabilité, la sécurité, la récupération, le coût et le comportement opérationnel.\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. Enregistrer les décisions d'architecture\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Préserver la justification, les alternatives, les compromis, les dépendances et les conditions qui déclencheraient une reconsidération.\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. Relier l'architecture à la livraison\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Traduire la conception en backlog, jalons, critères d'acceptation, travail technique et propriété.\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. Valider dans des conditions réalistes de production\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Tester des scénarios réalistes d'identité, de données, de défaillance, de latence, de fournisseur, d'outil et de récupération plutôt que de simples démonstrations propres.\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. Établir les opérations et le contrôle des changements\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Définir la surveillance, la réponse aux incidents, les mises à jour du modèle\u002Ffournisseur, les tests de régression, le retour arrière et la mise hors service.\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. Réinjecter les preuves dans l'architecture\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Utiliser les observations de production, les audits, les incidents et les évaluations pour réviser les décisions et les contrôles.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-113\">Liste de contrôle de l'architecture d'IA d'entreprise\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\">Question\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Preuve attendue\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quelle capacité métier cette IA soutient-elle ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Propriétaire nommé, groupe d'utilisateurs, décision\u002Fflux de travail prévu et objectif d'acceptation.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quelle source fait autorité pour chaque fait important ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Systèmes de référence, autorité documentaire, règles de provenance et de fraîcheur.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quelles identités existent ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les identités humaines, applicatives, de service, d'agent, de locataire\u002Forganisation et de fournisseur sont distinguables.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Que peut lire l'IA ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sources de données limitées par autorisation et règles explicites sur les données sensibles.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Que peut modifier l'IA ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Inventaire des outils\u002Factions, modèle de permissions, approbation et chemin de retour arrière.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quel fournisseur\u002Fmodèle est utilisé et pourquoi ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Décision d'architecture incluant la qualité, la sécurité, le coût, la région, le cycle de vie et les considérations de sortie.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Que se passe-t-il si le fournisseur est indisponible ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Mode dégradé, solution de repli, refus ou plan de continuité.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Comment la qualité est-elle évaluée ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Jeux de données spécifiques à la tâche, évaluateurs, seuils, critères de régression et conditions de validité.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Qu'est-ce qui est journalisé ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Schéma de télémétrie, rédaction, accès, rétention et objectif d'audit.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Qui est responsable du risque lié à l'IA ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Responsabilité organisationnelle nommée liée au système concret.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quelle classification juridique s'applique ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Évaluation documentée basée sur le droit en vigueur et le cas d'usage réel.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Comment les modifications de modèle\u002Finvite\u002Frécupération sont-elles approuvées ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Versionnage, évaluation, enregistrement d'architecture\u002Fchangement et porte de déploiement.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Qui répond à un incident d'IA ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Procédure, propriétaire technique, escalade métier\u002Fdomaine et escalade fournisseur.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Comment le système est-il mis hors service ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Nettoyage des données, révocation des accès, sortie du fournisseur, rétention des preuves et suppression des dépendances.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-115\">Cas limites et limites\u003C\u002Fh2>\n\u003Cp>Une petite entreprise avec un seul cas d'usage d'IA à faible risque peut ne pas avoir besoin d'une fonction formelle d'architecture d'IA d'entreprise. Les mêmes principes peuvent être appliqués légèrement : propriétaire clair, données approuvées, fournisseur explicite, évaluation de base, contrôle d'accès et responsabilité opérationnelle.\u003C\u002Fp>\n\u003Cp>Une organisation hautement réglementée peut avoir besoin d'une séparation plus forte, d'une validation indépendante, de processus de conformité formels, d'un hébergement local ou d'un fonctionnement en air gap. Ces contrôles sont dictés par le cas d'usage et l'environnement réglementaire, et non par le mot « entreprise ».\u003C\u002Fp>\n\u003Cp>Une organisation peut également utiliser principalement des produits d'IA SaaS plutôt que de construire des systèmes d'IA. L'architecture d'entreprise reste importante car l'identité, l'accès aux données, les conditions contractuelles, l'IA fantôme, la rétention, l'audit et la concentration des fournisseurs restent des préoccupations organisationnelles.\u003C\u002Fp>\n\u003Cp>Une plateforme centralisée n'est pas obligatoire. La propriété fédérée de la plateforme peut être valide lorsque les domaines ont des exigences matériellement différentes, à condition que les responsabilités d'identité, de risque, d'inventaire et d'interopérabilité au niveau de l'entreprise restent cohérentes.\u003C\u002Fp>\n\u003Ch2 id=\"section-120\">Qu'est-ce qui changerait cette réponse ?\u003C\u002Fh2>\n\u003Cp>L'architecture change lorsque la tolérance au risque de l'organisation, la classification réglementaire, la sensibilité des données, la portée géographique, la stratégie de fournisseur, les compétences internes ou la criticité métier changent. Un assistant marketing public et un système participant à des décisions en matière d'emploi, de finance, de santé ou d'infrastructure critique ne devraient pas hériter de modèles de contrôle identiques.\u003C\u002Fp>\n\u003Cp>La mise en œuvre change également à mesure que les normes, la réglementation et les plateformes d'IA évoluent. Le NIST AI RMF 1.0 est actuellement en cours de révision, l'EU AI Act a des dates d'application échelonnées, et les capacités des modèles\u002Ffournisseurs continuent de changer rapidement. L'architecture d'entreprise devrait donc préserver des frontières de responsabilité stables tout en traitant les mécanismes des fournisseurs et les détails réglementaires comme des entrées versionnées.\u003C\u002Fp>\n\u003Ch2 id=\"section-123\">Connaissances canoniques associées\u003C\u002Fh2>\n\u003Cp>L'architecture d'IA d'entreprise s'appuie sur l'architecture de solution et de plateforme. La couche solution explique une charge de travail. La couche plateforme explique les capacités d'IA réutilisables. La couche entreprise relie les deux aux données, à l'identité, à la gouvernance, aux risques, aux achats et aux opérations à l'échelle de l'organisation.\u003C\u002Fp>\n\u003Cp>La génération augmentée par récupération n'est qu'un mécanisme au sein de cette architecture. Le RAG peut améliorer l'accès aux connaissances de l'entreprise, mais il ne résout pas à lui seul l'autorité sur les données, les permissions, la gouvernance ou la validité des réponses.\u003C\u002Fp>\n\u003Caside class=\"editorjs-referral my-6\">\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\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\">Qu'est-ce que le RAG ? L'explication la plus simple de son fonctionnement\u003C\u002Fstrong>\u003Cp class=\"mt-2 text-sm text-gray-600 dark:text-gray-300\">Une explication en langage clair de la façon dont la récupération de connaissances externes se connecte au modèle de langage sans faire de la récupération la source de vérité.\u003C\u002Fp>\u003Cspan class=\"mt-3 inline-flex text-sm font-medium text-primary-600 dark:text-primary-400\">Lire les fondements du RAG →\u003C\u002Fspan>\u003C\u002Fdiv>\u003C\u002Fa>\u003C\u002Faside>\n\u003Cp>Pour les cas d'usage d'entreprise à forte densité de preuves, la validité des réponses nécessite également une frontière explicite : une sortie n'est soutenue que dans le cadre des preuves, de la version, de la portée et des hypothèses qui l'ont produite.\u003C\u002Fp>\n\u003Caside class=\"editorjs-referral my-6\">\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\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\">La frontière de validité des réponses : la couche manquante entre pertinence et réponses IA fiables\u003C\u002Fstrong>\u003Cp class=\"mt-2 text-sm text-gray-600 dark:text-gray-300\">Un cadre pour expliciter les conditions dans lesquelles une affirmation IA reste soutenue et quels changements nécessitent une restriction ou un recalcul.\u003C\u002Fp>\u003Cspan class=\"mt-3 inline-flex text-sm font-medium text-primary-600 dark:text-primary-400\">Lire La frontière de validité des réponses →\u003C\u002Fspan>\u003C\u002Fdiv>\u003C\u002Fa>\u003C\u002Faside>\n\u003Cp>Les sujets d'entreprise en aval incluent la gouvernance de l'IA, l'IA privée, l'IA souveraine, l'IA en environnement isolé, l'architecture IA multi-locataires, le RBAC versus l'isolation des locataires, l'abstraction des fournisseurs, le routage des modèles et l'architecture IA de production.\u003C\u002Fp>\n\u003Ch2 id=\"section-130\">Questions fréquentes\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\">FAQ sur l'architecture IA d'entreprise\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\">Qu'est-ce que l'architecture IA d'entreprise ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">L'architecture IA d'entreprise est l'architecture à l'échelle de l'organisation qui définit comment les solutions IA et les capacités IA partagées s'intègrent à la propriété métier, aux données d'entreprise, à l'identité, à la sécurité, aux fournisseurs, à la gouvernance, aux risques, à la conformité, au cycle de vie et aux opérations.\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\">L'architecture IA d'entreprise est-elle identique à une plateforme IA ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Non. Une plateforme IA fournit des capacités techniques réutilisables telles que l'accès aux modèles, la récupération, les environnements d'exécution d'agents et l'observabilité. L'architecture IA d'entreprise définit comment cette plateforme et les solutions IA individuelles s'inscrivent dans l'architecture et le modèle opérationnel plus larges de l'organisation.\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\">L'IA d'entreprise nécessite-t-elle un modèle central unique ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Non. La standardisation peut réduire la complexité, mais différentes charges de travail peuvent nécessiter différents fournisseurs, modèles, régions, niveaux de contrôle ou modalités. L'exigence importante est une politique explicite et une propriété du cycle de vie.\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\">Pourquoi l'autorité des données est-elle importante pour l'IA d'entreprise ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Parce que les informations récupérées ou générées ne sont pas automatiquement faisant autorité. Les systèmes d'entreprise doivent préserver quelle source est le système d'enregistrement, si les données sont à jour, qui peut y accéder et comment une affirmation générée peut être retracée jusqu'aux preuves.\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\">Quelle est la différence entre la gouvernance de l'IA et l'architecture IA d'entreprise ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">La gouvernance de l'IA définit les politiques, la responsabilité et les droits de décision. L'architecture IA d'entreprise définit les limites du système, les interfaces, les flux de données et les mécanismes techniques par lesquels ces politiques peuvent être mises en œuvre et attestées.\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\">Le règlement européen sur l'IA s'applique-t-il de la même manière à tous les systèmes IA d'entreprise ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Non. Les obligations dépendent de facteurs tels que le rôle de l'organisation, le cas d'usage et la classification du système, ainsi que les dispositions pertinentes en vigueur. La classification juridique doit être effectuée pour le système concret en vertu du droit en vigueur.\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\">Un pilote IA réussi suffit-il pour un déploiement en entreprise ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Non. Un pilote démontre une capacité limitée. Le déploiement en entreprise nécessite également l'identité, l'autorité des données, la sécurité, la gouvernance des fournisseurs, l'évaluation, le cycle de vie, la réponse aux incidents, la surveillance, la conformité et une propriété opérationnelle responsable.\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\">Les entreprises doivent-elles auto-héberger l'IA ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Uniquement lorsque l'exigence justifie le contrôle et la responsabilité opérationnelle supplémentaires. Les approches gérées, privées, souveraines, auto-hébergées et hybrides sont des options d'architecture dont l'adéquation dépend des exigences en matière de données, de réglementation, de disponibilité, de coût, de capacité et d'exploitation.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-132\">Glossaire\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\">Termes clés de l'architecture IA d'entreprise\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\">Architecture IA d'entreprise\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Architecture à l'échelle de l'organisation régissant la manière dont les systèmes IA, les plateformes, les données, les identités, les fournisseurs, les contrôles des risques et les opérations s'articulent ensemble.\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\">Système de management de l'IA\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Système de management organisationnel pour établir les politiques, objectifs et processus liés à l'IA ; l'ISO\u002FIEC 42001 spécifie les exigences d'un tel système.\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\">Autorité des données\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">La règle qui identifie quelle source ou quel système fait autorité pour un fait, un enregistrement, un état ou un contexte décisionnel particulier.\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\">Système d'enregistrement\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Le système faisant autorité responsable de l'état officiel actuel d'un enregistrement métier ou d'une entité de domaine.\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\">Inventaire IA\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Un enregistrement structuré des cas d'usage IA, des propriétaires, des modèles\u002Ffournisseurs, des données, des outils, des risques, des preuves d'évaluation, de l'état du cycle de vie et des contrôles associés.\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\">Dépendance au fournisseur\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">La dépendance technique, contractuelle et opérationnelle créée lorsqu'une charge de travail IA dépend d'un modèle externe ou d'une plateforme gérée.\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\">Supervision humaine\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Examen, approbation, intervention ou escalade humains définis, appliqués là où les conséquences du système, l'incertitude ou la réglementation l'exigent.\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\">Pratiques opérationnelles pour les charges de travail d'IA générative couvrant la sélection des modèles, les invites, les données d'ancrage, l'évaluation, le déploiement, la surveillance et la gestion du cycle de vie.\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\">Gestion des risques liés à l'IA\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Le processus organisationnel d'identification, d'évaluation, de traitement, de surveillance et de révision des risques associés aux systèmes IA tout au long de leur cycle de vie.\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\">Décision d'architecture\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Un choix de conception important accompagné de son contexte, de sa justification, des alternatives, des compromis et de son statut dans le cycle de vie.\u003C\u002Fdd>\u003C\u002Fdiv>\u003C\u002Fdl>\u003C\u002Fsection>\n\u003Ch2 id=\"section-134\">Conclusion\u003C\u002Fh2>\n\u003Cp>Lorsque l'IA entre dans une entreprise, celle-ci n'acquiert pas simplement un nouveau composant logiciel. Elle acquiert une nouvelle classe de comportement et de dépendance qui traverse les données, l'identité, les fournisseurs, les décisions métier, la sécurité, les opérations, la gouvernance et la gestion du changement.\u003C\u002Fp>\n\u003Cp>La réponse architecturale n'est pas de tout centraliser. Elle consiste à rendre les responsabilités explicites : quelles données font autorité, quelles identités peuvent agir, quels fournisseurs sont approuvés, quels contrôles sont partagés, quelles décisions restent du ressort du domaine, comment le comportement est évalué, comment les incidents sont traités et comment le système évolue dans le temps.\u003C\u002Fp>\n\u003Cp>C'est la distinction fondamentale de l'architecture IA d'entreprise : elle transforme une capacité IA isolée en un système gouvernable à l'échelle de l'organisation sans prétendre que les modèles, les plateformes, les domaines métier et les contrôles d'entreprise sont la même chose.\u003C\u002Fp>\n\u003Ch2 id=\"section-138\">Sources primaires et orientations actuelles\u003C\u002Fh2>\n\u003Cp>Les normes externes, la réglementation et les orientations actuelles des fournisseurs en matière d'architecture ci-dessous ont été vérifiées le 8 octobre 2026. Les sections spécifiques au projet sont explicitement marquées comme preuves originales du projet et ne doivent pas être lues comme des affirmations de fait général du secteur.\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 — Système de management de l'intelligence artificielle\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Norme internationale spécifiant les exigences pour établir, mettre en œuvre, maintenir et améliorer continuellement un système de management de l'IA au sein des organisations.\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 — Lignes directrices sur la gestion des risques liés à l'IA\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Lignes directrices internationales pour intégrer la gestion des risques spécifiques à l'IA dans les activités et fonctions organisationnelles.\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\">Cadre de gestion des risques liés à l'IA du NIST\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Cadre volontaire du NIST orienté cycle de vie pour gérer les risques liés à l'IA. Le NIST indique que l'AI RMF 1.0 est actuellement en cours de révision.\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 — Profil pour l'IA générative\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Profil complémentaire du NIST décrivant les risques spécifiques à l'IA générative et les actions de gestion des risques alignées sur l'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 — Règlement (UE) 2024\u002F1689, texte consolidé\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Texte consolidé actuel du règlement sur l'IA utilisé pour les dates d'application et la structure réglementaire, tel que vérifié le 8 octobre 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\">Commission européenne — Cadre réglementaire de la loi sur l'IA\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Aperçu actuel de la Commission des phases d'application de la loi sur l'IA, y compris l'applicabilité en 2026 et les dates ultérieures pour certaines dispositions à haut risque.\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 — Charges de travail IA\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Conseils d'architecture actuels sur les charges de travail IA, y compris le comportement non déterministe, les données, la conception des applications et les opérations.\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 et GenAIOps pour les charges de travail IA\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Conseils actuels sur le cycle de vie opérationnel, les données, la maintenance des modèles, le déploiement, la surveillance et l'évolution continue.\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 — IA responsable dans les charges de travail Azure\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Conseils actuels reliant la politique d'IA au contrôle des données, à l'identité, à l'auditabilité des agents, à l'accès basé sur les rôles et aux garanties opérationnelles.\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 — Description de l'architecture\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Norme actuelle de description de l'architecture prenant en charge les préoccupations explicites, les points de vue et les relations à travers l'architecture système.\u003C\u002Fp>\u003C\u002Fa>",{"time":212,"blocks":213,"version":1562},1791478496776,[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,1441,1446,1451,1456,1461,1466,1471,1481,1490,1499,1508,1517,1526,1535,1544,1553],{"id":215,"data":216,"type":218,"tunes":219},"intro",{"text":217},"L'architecture d'IA d'entreprise est l'architecture à l'échelle de l'organisation requise lorsque l'IA fait partie des systèmes, des données, des décisions et des opérations réels d'une entreprise. Le modèle n'est qu'un composant. Une fois que l'IA est connectée aux données d'entreprise, aux identités, aux autorisations, aux processus métier, aux fournisseurs externes et aux systèmes de production, l'architecture doit également définir l'autorité sur les données, les frontières d'accès, la propriété des risques, les dépendances vis-à-vis des fournisseurs, l'auditabilité, l'évaluation, le contrôle du cycle de vie, la conformité et la responsabilité opérationnelle. L'IA d'entreprise diffère donc à la fois d'une solution d'IA unique et d'une plateforme d'IA partagée : elle coordonne la manière dont de nombreux systèmes dotés d'IA s'intègrent dans l'organisation au sens large.","paragraph",{},{"id":221,"data":222,"type":226,"tunes":227},"direct-answer",{"body":223,"title":224,"variant":225},"\u003Cstrong>Qu'est-ce qui change lorsque l'IA entre dans une entreprise ?\u003C\u002Fstrong> Les responsabilités existantes de l'architecture d'entreprise s'étendent pour inclure le comportement probabiliste des modèles, les nouveaux flux de données, la récupération et l'ancrage, les dépendances aux modèles et aux fournisseurs, l'évaluation spécifique à l'IA, l'autorité des agents et des outils, le cycle de vie des modèles et des invites, la gestion des risques liés à l'IA, les obligations de transparence et les nouveaux modes de défaillance opérationnelle. L'architecture doit relier ces préoccupations aux structures existantes de l'entreprise en matière d'identité, de sécurité, de données, d'approvisionnement, de livraison et de gouvernance, au lieu de créer un « univers de l'IA » parallèle.","Réponse directe","info","callout",{},{"id":229,"data":230,"type":226,"tunes":234},"not-bigger-chatbot",{"body":231,"title":232,"variant":233},"Un chatbot peut être une interface utilisateur. L'architecture d'IA d'entreprise est le système de frontières qui se trouve derrière : à quelles données l'IA peut accéder, quelle source fait autorité, qui peut utiliser quelle capacité, si des fournisseurs externes peuvent recevoir les données, quelles actions un agent peut exécuter, comment les sorties sont évaluées, ce qui doit être journalisé, qui est responsable des incidents et comment les changements sont approuvés et annulés.","L'IA d'entreprise n'est pas « un chatbot plus grand »","warning",{},{"id":236,"data":237,"type":226,"tunes":241},"current-date",{"body":238,"title":239,"variant":240},"Les principes architecturaux de cet article sont destinés à être stables. La réglementation, les normes et les capacités des fournisseurs dépendent des versions. L'ISO\u002FIEC 42001:2023 et l'ISO\u002FIEC 23894:2023 sont des normes publiées en vigueur. Le NIST indique que l'AI RMF 1.0 est en cours de révision. Selon le texte consolidé actuel du règlement européen sur l'IA, le règlement s'applique généralement à partir du 2 août 2026, tandis que certaines dispositions relatives aux systèmes à haut risque ont des dates d'application ultérieures. La classification juridique doit toujours être vérifiée par rapport au droit en vigueur et au cas d'usage concret.","Note sur les sources actuelles — 8 octobre 2026","note",{},{"id":243,"data":244,"type":248,"tunes":249},"toc",{"title":245,"maxLevel":246,"minLevel":247},"Sommaire",3,2,"tableOfContents",{},{"id":251,"data":252,"type":42,"tunes":254},"h-meaning",{"text":253,"level":247},"Ce que signifie réellement l'architecture d'IA d'entreprise",{},{"id":256,"data":257,"type":218,"tunes":259},"p-meaning-1",{"text":258},"L'architecture d'IA d'entreprise décrit comment les capacités d'IA sont intégrées dans une organisation existante sans briser les frontières qui rendent déjà les systèmes d'entreprise gouvernables : propriété métier, identité, autorisation, classification des données, responsabilité des systèmes d'enregistrement, gestion des changements, approvisionnement, audit, continuité et opérations.",{},{"id":261,"data":262,"type":218,"tunes":264},"p-meaning-2",{"text":263},"L'architecte d'entreprise ne remplace pas l'architecte de solution d'IA ni l'architecte de plateforme d'IA. La portée d'entreprise pose une question différente : comment de multiples solutions d'IA et capacités d'IA partagées s'intègrent-elles dans l'architecture cible, les politiques, le paysage de données, le modèle de risque et le modèle opérationnel de l'entreprise ?",{},{"id":266,"data":267,"type":218,"tunes":269},"p-meaning-3",{"text":268},"Cela fait de l'architecture d'IA d'entreprise une discipline de coordination entre la technologie et l'organisation. Une intégration de modèle techniquement bonne peut néanmoins constituer un échec d'architecture d'entreprise si elle crée des flux de données fantômes, duplique l'identité, contourne l'approvisionnement, ne peut pas être auditée, n'a pas de propriétaire ou ne peut pas être modifiée en toute sécurité.",{},{"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","Portée principale",[278,278,278],"",{"id":280,"label":281,"values":282},"question","Question principale",[278,278,278],{"id":284,"label":285,"values":286},"ownership","Axe de propriété",[278,278,278],{"id":288,"label":289,"values":290},"success","Condition de succès",[278,278,278],"Les architectures d'IA de solution, de plateforme et d'entreprise sont des portées différentes","table",[294,297,300],{"id":295,"label":296},"solution","Architecture de solution d'IA",{"id":298,"label":299},"platform","Architecture de plateforme d'IA",{"id":301,"label":302},"enterprise","Architecture d'IA d'entreprise","comparison",{},{"id":306,"data":307,"type":42,"tunes":309},"h-simple",{"text":308,"level":247},"L'exemple le plus simple",{},{"id":311,"data":312,"type":218,"tunes":314},"p-simple-1",{"text":313},"Une entreprise commence avec un seul assistant documentaire interne. La première version recherche dans des documents approuvés et envoie le contexte récupéré à un modèle de langage. Au niveau de la solution, cela peut sembler simple.",{},{"id":316,"data":317,"type":218,"tunes":319},"p-simple-2",{"text":318},"Puis une deuxième équipe veut de l'IA pour le support client. Une troisième veut un agent capable de mettre à jour des tickets. La finance veut de l'analyse documentaire. Les RH veulent un assistant interne. Les développeurs veulent des agents de codage. Soudain, l'entreprise a plusieurs fournisseurs, plusieurs classes de données, différents groupes d'utilisateurs, des index de récupération qui se chevauchent, des règles de journalisation différentes, de nouvelles autorisations d'outils, des secrets dupliqués et une propriété floue.",{},{"id":321,"data":322,"type":218,"tunes":324},"p-simple-3",{"text":323},"À ce stade, la question n'est plus « L'assistant fonctionne-t-il ? » La question d'entreprise devient : quelles capacités sont approuvées, qui en est propriétaire, quelles données peuvent franchir quelle frontière, comment les identités et les autorisations sont-elles appliquées, quels fournisseurs sont acceptables, ce qui doit être audité et comment l'organisation peut-elle changer de modèles ou de fournisseurs sans perdre le contrôle ?",{},{"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. Cas d'usage isolé","Une équipe connecte un modèle à un flux de travail et valide la valeur locale.",{"label":333,"description":334},"2. Des dépendances partagées apparaissent","Plusieurs équipes ont besoin de fournisseurs, d'accès aux modèles, de récupération, d'identité, de secrets, d'observabilité et d'évaluation.",{"label":336,"description":337},"3. Les frontières de l'entreprise sont franchies","L'IA touche des données réglementées, des systèmes d'enregistrement, des fournisseurs externes, des actions privilégiées et des décisions métier.",{"label":339,"description":340},"4. La propriété doit devenir explicite","Les métiers, l'architecture, les données, la sécurité, le juridique et la conformité, l'approvisionnement et les opérations doivent avoir des responsabilités définies.",{"label":342,"description":343},"5. Le cycle de vie devient organisationnel","Les changements de modèle, d'invite, de fournisseur et les nouvelles capacités d'agent deviennent des changements gouvernés plutôt que des modifications locales de développeurs.",{"label":345,"description":346},"6. L'architecture devient reproductible","L'organisation établit des modèles réutilisables, des enregistrements de décisions, des contrôles, des exceptions et des points de validation pour les nouvelles charges de travail d'IA.","D'une fonctionnalité d'IA isolée à l'architecture d'entreprise","auto","processFlow",{},{"id":352,"data":353,"type":42,"tunes":355},"h-stop",{"text":354,"level":247},"Où l'exemple simple s'arrête",{},{"id":357,"data":358,"type":218,"tunes":360},"p-stop-1",{"text":359},"L'architecture d'entreprise ne signifie pas que chaque composant d'IA doit être centralisé. Certaines capacités doivent être partagées ; d'autres doivent rester la propriété du domaine. La finance, les RH, l'ingénierie et le support client peuvent légitimement exiger des frontières de données, des fournisseurs, des critères d'évaluation et des règles d'approbation humaine différents.",{},{"id":362,"data":363,"type":218,"tunes":365},"p-stop-2",{"text":364},"L'objectif d'entreprise n'est donc pas un modèle unique, une base de données vectorielle unique ou un assistant universel unique. L'objectif est une architecture cohérente avec une variation explicite : des politiques communes et des capacités réutilisables là où elles réduisent le risque et la duplication, plus des exceptions contrôlées là où les exigences métier ou réglementaires diffèrent.",{},{"id":367,"data":368,"type":42,"tunes":370},"h-layers",{"text":369,"level":247},"Ce qui change dans l'architecture lorsque l'IA entre dans l'entreprise",{},{"id":372,"data":373,"type":42,"tunes":375},"h-business",{"text":374,"level":246},"1. La propriété métier devient partie intégrante de l'architecture technique",{},{"id":377,"data":378,"type":218,"tunes":380},"p-business-1",{"text":379},"Les applications traditionnelles ont déjà besoin de responsables métier. L'IA rend cette exigence plus visible car un comportement acceptable ne peut pas être défini uniquement par la disponibilité et la conformité fonctionnelle. Quelqu'un doit être responsable de l'usage prévu, de l'usage inacceptable, de la qualité des résultats, du chemin d'escalade et des conséquences de résultats erronés ou inappropriés.",{},{"id":382,"data":383,"type":218,"tunes":385},"p-business-2",{"text":384},"Une équipe de modèle ne peut pas décider seule si une réponse est acceptable pour les RH, la finance, le juridique ou un usage orienté client. L'architecture d'IA d'entreprise relie donc la conception technique à une capacité métier explicite, un responsable redevable, un groupe d'utilisateurs et un contexte décisionnel.",{},{"id":387,"data":388,"type":42,"tunes":390},"h-data-authority",{"text":389,"level":246},"2. L'accès aux données ne suffit pas — l'autorité sur les données doit être définie",{},{"id":392,"data":393,"type":218,"tunes":395},"p-data-authority-1",{"text":394},"L'IA d'entreprise combine fréquemment des bases de données opérationnelles, des documents, des index de recherche, des bases vectorielles, des entrepôts de données, des systèmes SaaS et des connaissances externes. L'architecture doit distinguer où l'information est stockée de quelle source fait autorité pour une affirmation ou une action donnée.",{},{"id":397,"data":398,"type":218,"tunes":400},"p-data-authority-2",{"text":399},"Un index vectoriel peut améliorer la récupération mais ne devrait pas devenir silencieusement le système d'enregistrement de l'entreprise. Une réponse de modèle peut résumer un enregistrement ERP mais ne devrait pas remplacer l'ERP comme source faisant autorité. Un contexte mis en cache peut améliorer la latence mais devient dangereux lorsque les permissions ou l'état métier sous-jacent changent.",{},{"id":402,"data":403,"type":218,"tunes":405},"p-data-authority-3",{"text":404},"L'IA d'entreprise a donc besoin de provenance, de fraîcheur, de classification des sources, de propagation des autorisations et de règles d'invalidation en plus de l'intégration de données ordinaire.",{},{"id":407,"data":408,"type":226,"tunes":411},"authority-rule",{"body":409,"title":410,"variant":288},"\u003Cstrong>Le système d'IA peut transformer, récupérer et raisonner sur les données d'entreprise sans devenir l'autorité pour ces données.\u003C\u002Fstrong> L'architecture doit préserver un chemin de retour vers la source faisant autorité chaque fois que le cas d'usage nécessite des preuves, une vérification ou une action conséquente.","Règle des données d'entreprise",{},{"id":413,"data":414,"type":42,"tunes":416},"h-identity",{"text":415,"level":246},"3. L'identité devient multicouche",{},{"id":418,"data":419,"type":218,"tunes":421},"p-identity-1",{"text":420},"L'IA d'entreprise a plus d'identités que l'utilisateur humain. Une requête peut impliquer une identité utilisateur, une identité d'application, une identité de service, une identité d'agent, un identifiant de fournisseur, un identifiant d'outil et un contexte de locataire ou d'organisation.",{},{"id":423,"data":424,"type":218,"tunes":426},"p-identity-2",{"text":425},"Ces identités ne doivent pas être fusionnées en une seule clé API partagée. L'autorisation doit rester attribuable au bon principal, et les outils privilégiés ne doivent recevoir que l'autorité requise pour l'opération en cours.",{},{"id":428,"data":429,"type":218,"tunes":431},"p-identity-3",{"text":430},"Pour les systèmes agentiques, cela devient particulièrement important : un modèle peut proposer une action, mais l'environnement d'exécution doit décider si l'identité demandeuse est autorisée à l'exécuter. La capacité du modèle n'est pas une autorisation.",{},{"id":433,"data":434,"type":42,"tunes":436},"h-permissions",{"text":435,"level":246},"4. Les permissions passent de l'accès au contenu à l'autorité d'action",{},{"id":438,"data":439,"type":218,"tunes":441},"p-permissions-1",{"text":440},"Un assistant en lecture seule a principalement besoin d'un accès contrôlé à l'information. Un agent d'entreprise peut créer des tickets, modifier des enregistrements, envoyer des messages, déclencher des workflows ou exploiter des systèmes externes. Cela introduit une classe de risque différente car le système peut changer l'état plutôt que simplement le décrire.",{},{"id":443,"data":444,"type":218,"tunes":446},"p-permissions-2",{"text":445},"L'architecture doit séparer les capacités de lecture, d'écriture, d'approbation et d'administration ; définir les points de validation humaine là où les conséquences le justifient ; et préserver une piste d'audit qui identifie ce qui a été demandé, ce qui a été approuvé et ce qui a réellement changé.",{},{"id":448,"data":449,"type":42,"tunes":451},"h-provider",{"text":450,"level":246},"5. Le fournisseur d'IA devient une dépendance d'entreprise",{},{"id":453,"data":454,"type":218,"tunes":456},"p-provider-1",{"text":455},"Appeler une API de modèle est aussi une relation fournisseur. L'architecture peut dépendre de la disponibilité du fournisseur, des conditions de service, des conditions de traitement des données, des régions prises en charge, du cycle de vie du modèle, des quotas, de la tarification, de la compatibilité API, des contrôles de sécurité et des notifications de changement.",{},{"id":458,"data":459,"type":218,"tunes":461},"p-provider-2",{"text":460},"Cela signifie que la sélection d'un fournisseur n'est pas seulement une décision de benchmark. L'approvisionnement, la sécurité, la confidentialité, l'examen juridique, la planification de la continuité et la stratégie de sortie peuvent tous devenir des entrées d'architecture.",{},{"id":463,"data":464,"type":218,"tunes":466},"p-provider-3",{"text":465},"L'abstraction du fournisseur peut réduire le couplage, mais uniquement là où les capacités sous-jacentes sont véritablement portables. L'utilisation d'outils, la sortie structurée, les limites de contexte, la multimodalité, les contrôles de sécurité, le fine-tuning et les fonctionnalités d'agents hébergés peuvent différer sensiblement entre les fournisseurs.",{},{"id":468,"data":469,"type":42,"tunes":471},"h-risk",{"text":470,"level":246},"6. Le risque lié à l'IA devient un processus de cycle de vie",{},{"id":473,"data":474,"type":218,"tunes":476},"p-risk-1",{"text":475},"Le risque lié à l'IA n'est pas clos par une seule approbation avant le lancement. Le modèle, le prompt, le corpus de récupération, l'ensemble d'outils, le fournisseur, la population d'utilisateurs et le processus métier environnant peuvent tous changer après le déploiement. Le profil de risque change avec eux.",{},{"id":478,"data":479,"type":218,"tunes":481},"p-risk-2",{"text":480},"L'ISO\u002FIEC 23894:2023 traite explicitement de l'intégration de la gestion des risques liés à l'IA dans les activités et fonctions organisationnelles. Le NIST AI RMF encadre de même la gestion des risques tout au long du cycle de vie. L'architecture d'entreprise devrait donc faire de l'examen des risques une partie du changement et des opérations plutôt qu'un document de conformité isolé.",{},{"id":483,"data":484,"type":218,"tunes":486},"p-risk-3",{"text":485},"Le risque doit également être proportionné. Un assistant de synthèse et un système autonome qui modifie des enregistrements de production ne devraient pas recevoir des contrôles identiques simplement parce que tous deux utilisent un LLM.",{},{"id":488,"data":489,"type":42,"tunes":491},"h-management-system",{"text":490,"level":246},"7. La gouvernance devient un système d'exploitation, pas un PDF de politique",{},{"id":493,"data":494,"type":218,"tunes":496},"p-management-system-1",{"text":495},"L'ISO\u002FIEC 42001:2023 définit les exigences pour établir, mettre en œuvre, maintenir et améliorer continuellement un système de management de l'IA. La conséquence architecturale est importante : la gouvernance doit relier la politique à de véritables inventaires, responsabilités, processus, contrôles, preuves, revues et boucles d'amélioration.",{},{"id":498,"data":499,"type":218,"tunes":501},"p-management-system-2",{"text":500},"Une politique d'IA d'entreprise qui n'est pas liée à l'approbation des fournisseurs, à l'identité, à la journalisation, à la gestion des changements, à l'évaluation et à la réponse aux incidents a un effet architectural limité. L'organisation a besoin de mécanismes qui rendent la politique applicable ou du moins observable.",{},{"id":503,"data":504,"type":42,"tunes":506},"h-eval",{"text":505,"level":246},"8. L'évaluation devient un contrôle de production",{},{"id":508,"data":509,"type":218,"tunes":511},"p-eval-1",{"text":510},"Les tests d'acceptation traditionnels supposent que la même entrée produit normalement le même résultat déterministe. L'IA générative peut être non déterministe, sensible au contexte et dépendante de connaissances externes changeantes. L'acceptation en production nécessite donc des évaluations spécifiques aux tâches, des suites de régression et des seuils observables plutôt que de simples tests unitaires.",{},{"id":513,"data":514,"type":218,"tunes":516},"p-eval-2",{"text":515},"La plateforme peut fournir une infrastructure d'évaluation réutilisable, mais l'entreprise doit toujours assumer la responsabilité de la vérité terrain du domaine et des portes de mise en production. Une équipe IA centrale ne peut pas inventer la bonne réponse pour chaque domaine métier.",{},{"id":518,"data":519,"type":218,"tunes":521},"p-eval-3",{"text":520},"Les modifications de modèle, de prompt, de récupération et d'outils devraient être traçables jusqu'aux preuves d'évaluation lorsque le changement peut affecter matériellement le comportement de sortie.",{},{"id":523,"data":524,"type":42,"tunes":526},"h-observability",{"text":525,"level":246},"9. L'observabilité doit inclure le comportement, les données et le contexte du modèle",{},{"id":528,"data":529,"type":218,"tunes":531},"p-observability-1",{"text":530},"Les taux d'erreur CPU, mémoire et HTTP ne suffisent pas pour les charges de travail d'IA. L'observabilité en production peut nécessiter des identifiants de modèle\u002Ffournisseur, la latence, l'utilisation de jetons, le coût, les résultats de récupération, les appels d'outils, le comportement de refus, les scores d'évaluation, les événements de sécurité et les classifications de défaillance.",{},{"id":533,"data":534,"type":218,"tunes":536},"p-observability-2",{"text":535},"En même temps, la télémétrie d'IA peut contenir des données sensibles. Les journaux de prompts et de réponses peuvent devenir un magasin de données fantôme. L'architecture d'entreprise doit donc définir ce qui peut être journalisé, comment il est expurgé, qui peut y accéder, combien de temps il est conservé et quand la traçabilité détaillée doit être désactivée.",{},{"id":538,"data":539,"type":42,"tunes":541},"h-lifecycle",{"text":540,"level":246},"10. Les composants d'IA nécessitent une propriété explicite du cycle de vie",{},{"id":543,"data":544,"type":218,"tunes":546},"p-lifecycle-1",{"text":545},"Les modèles peuvent être renommés, remplacés, retirés ou modifiés par les fournisseurs. Les modèles d'embedding peuvent invalider une stratégie d'index. Les modèles de prompts et les instructions système peuvent modifier le comportement. Les environnements d'exécution et protocoles d'agents peuvent évoluer. Les outils externes peuvent modifier leurs schémas et permissions.",{},{"id":548,"data":549,"type":218,"tunes":551},"p-lifecycle-2",{"text":550},"L'architecture d'entreprise doit décider qui détecte ces changements, qui les teste, qui les approuve, comment les consommateurs sont notifiés, comment le retour arrière fonctionne et quelles preuves sont requises avant qu'une nouvelle version ne devienne la version par défaut.",{},{"id":553,"data":554,"type":42,"tunes":556},"h-operations",{"text":555,"level":246},"11. La réponse aux incidents doit inclure des modes de défaillance spécifiques à l'IA",{},{"id":558,"data":559,"type":218,"tunes":561},"p-operations-1",{"text":560},"Un incident lié à l'IA peut être une panne de fournisseur, une fuite de données, un chemin d'injection de prompt, une défaillance d'autorisation, une contamination de la récupération, un comportement inattendu du modèle, une exécution d'outil non sécurisée, un pic de coûts, des connaissances obsolètes, une régression d'évaluation ou un changement de comportement d'un modèle externe.",{},{"id":563,"data":564,"type":218,"tunes":566},"p-operations-2",{"text":565},"Le runbook d'entreprise doit donc aller au-delà de « redémarrer le service ». Il peut nécessiter de désactiver une route de modèle, de révoquer l'accès à un outil, de geler un corpus, de changer une version de prompt, de désactiver une capacité d'agent, de changer de fournisseur, d'escalader vers un propriétaire de domaine ou de préserver les traces pour l'investigation.",{},{"id":568,"data":569,"type":42,"tunes":571},"h-ownership",{"text":570,"level":247},"L'IA d'entreprise crée une propriété transversale",{},{"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],"Préoccupation","Propriétaire ou contributeur d'entreprise typique","Question d'architecture",[581,582,583],"Usage métier","Propriétaire métier \u002F propriétaire de produit","Quelle décision ou quel flux de travail l'IA est-elle autorisée à soutenir ou à automatiser ?",[585,586,587],"Architecture de solution","Architecte IA \u002F de solution","Comment la charge de travail concrète satisfait-elle ses exigences fonctionnelles et de qualité ?",[589,590,591],"Capacités IA partagées","Plateforme IA \u002F ingénierie de plateforme","Quels services réutilisables de modèle, de récupération, d'agent et d'observabilité sont fournis ?",[593,594,595],"Cohérence d'entreprise","Architecture d'entreprise","Comment les systèmes d'IA s'intègrent-ils à l'architecture cible, aux normes, aux modèles d'intégration et à la propriété organisationnelle ?",[597,598,599],"Autorité des données","Propriétaire des données \u002F propriétaire de domaine","Quelles données font autorité, sont à jour, autorisées et suffisamment gouvernées ?",[601,602,603],"Identité et sécurité","IAM \u002F architecture de sécurité","Quelles identités peuvent accéder à quelles données et exécuter quelles actions ?",[605,606,607],"Risque et conformité","Risque \u002F juridique \u002F conformité \u002F vie privée","Quelles obligations, utilisations interdites, contrôles et preuves s'appliquent à ce cas d'usage ?",[609,610,611],"Dépendance fournisseur","Achats \u002F gestion des fournisseurs \u002F architecture","Quels risques contractuels, opérationnels et de sortie découlent du fournisseur ?",[613,614,615],"Opérations","SRE \u002F opérations \u002F propriétaire de plateforme","Comment le système est-il surveillé, supporté, dégradé, récupéré et modifié ?",[617,618,619],"Acceptation du domaine","Spécialistes métier\u002Fdomaine","Qu'est-ce qui compte comme un résultat correct, sûr ou utile dans ce domaine ?",{},{"id":622,"data":623,"type":226,"tunes":626},"ownership-warning",{"body":624,"title":625,"variant":233},"Les matrices de responsabilité ne sont utiles que lorsqu'elles se connectent à de véritables frontières de système, approbations, propriété des données, interfaces, runbooks et processus de changement. L'IA d'entreprise a besoin d'une propriété responsable qui peut être tracée jusqu'aux contrôles techniques et aux actions opérationnelles.","Une matrice RACI n'est pas une architecture en soi",{},{"id":628,"data":629,"type":42,"tunes":631},"h-model",{"text":630,"level":247},"Un modèle pratique d'architecture d'IA d'entreprise",{},{"id":633,"data":634,"type":226,"tunes":637},"model-note",{"body":635,"title":636,"variant":240},"Le modèle suivant est une synthèse pratique pour raisonner sur l'architecture d'IA d'entreprise. Il n'est pas présenté comme une norme ISO ou NIST. Son objectif est de rendre explicites les frontières inter-organisationnelles.","Modèle en couches proposé",{},{"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],"Couche","Responsabilité principale",[646,647],"Métier et politique","Cas d'usage approuvés, propriétaires responsables, appétit pour le risque, utilisations interdites, responsabilité humaine, acceptation métier.",[649,650],"Identité et autorité","Identités utilisateur\u002Fservice\u002Fagent, rôles, périmètre locataire ou organisationnel, actions privilégiées, chemins d'approbation.",[652,653],"Données d'entreprise","Systèmes d'enregistrement, sources documentaires, produits de données, provenance, classification, rétention, fraîcheur et accès.",[655,656],"Plateforme IA","Accès fournisseur\u002Fmodèle, primitives de récupération, environnements d'exécution d'agents, courtiers d'outils, infrastructure d'évaluation, observabilité, quotas et secrets.",[658,659],"Solutions IA","Flux de travail métier, prompts\u002Finstructions, récupération de domaine, logique métier, critères d'acceptation et expérience utilisateur.",[661,662],"Intégration et outils","API, applications d'entreprise, flux de travail, messagerie, systèmes de fichiers, services externes et exécution d'actions.",[664,665],"Risque et gouvernance","Inventaire, évaluation, preuves de conformité, gestion des exceptions, approbation des modèles\u002Ffournisseurs, revue et audit.",[667,668],"Opérations et cycle de vie","Déploiement, surveillance, incidents, versions, changements de modèle\u002Ffournisseur, dépréciation, retour arrière et continuité.",{},{"id":671,"data":672,"type":218,"tunes":674},"p-model-1",{"text":673},"L'architecture est la plus solide lorsque chaque couche peut énoncer à la fois ses responsabilités et ses non-responsabilités. Par exemple, la plateforme IA peut appliquer la politique du fournisseur et collecter des traces sans devenir la source de vérité pour les données RH. Une solution peut définir des prompts de domaine sans posséder l'IAM d'entreprise. Un propriétaire métier peut approuver un cas d'usage sans qu'on attende de lui qu'il exploite la passerelle d'inférence.",{},{"id":676,"data":677,"type":42,"tunes":679},"h-data-flow",{"text":678,"level":247},"Cartographier l'IA d'entreprise comme des flux de données et d'autorité, pas comme des boîtes",{},{"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. Contexte métier","L'utilisateur demande une tâche dans le cadre d'un cas d'usage approuvé avec un propriétaire métier responsable.",{"label":688,"description":689},"2. Identité et autorisation","Le système résout l'utilisateur, l'application, le service et le périmètre locataire ou organisationnel avant tout accès privilégié.",{"label":691,"description":692},"3. Acquisition de données faisant autorité","La solution lit ou récupère uniquement les sources autorisées pour l'identité et la tâche en cours.",{"label":694,"description":695},"4. Traitement IA","Un modèle\u002Ffournisseur approuvé traite le contexte minimal nécessaire selon des règles définies de routage et de traitement des données.",{"label":697,"description":698},"5. Frontière d'outil ou d'action","Toute action modifiant l'état est autorisée indépendamment et peut nécessiter une approbation humaine selon les conséquences.",{"label":700,"description":701},"6. Validation","Le résultat est vérifié par rapport aux règles d'acceptation, de preuve ou de sécurité spécifiques à la solution.",{"label":703,"description":704},"7. Audit et observabilité","Les métadonnées autorisées, décisions, routes, appels d'outils et résultats sont enregistrés sans créer de journaux non contrôlés de données sensibles.",{"label":706,"description":707},"8. Retour d'information et cycle de vie","Les échecs et les résultats d'évaluation alimentent les changements de modèle, de prompt, de données, de politique et de processus via une gestion contrôlée des changements.","Une requête d'IA d'entreprise à conséquences",{},{"id":711,"data":712,"type":42,"tunes":714},"h-inventory",{"text":713,"level":247},"Une entreprise a besoin d'un inventaire IA avant de pouvoir gouverner l'IA",{},{"id":716,"data":717,"type":218,"tunes":719},"p-inventory-1",{"text":718},"Les organisations ne peuvent pas gérer les systèmes d'IA qu'elles ne peuvent pas identifier. L'architecture d'entreprise doit maintenir un inventaire à un niveau utile pour les décisions, pas simplement une liste de noms de modèles.",{},{"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],"Champ d'inventaire","Pourquoi c'est important",[728,729],"Cas d'usage et propriétaire","Relie la technologie à un objectif métier responsable.",[731,732],"Utilisateurs et parties affectées","Définit qui interagit avec le système ou est affecté par celui-ci.",[734,735],"Modèle\u002Ffournisseur","Identifie la dépendance externe, la capacité et le risque de cycle de vie.",[737,738],"Sources de données","Soutient l'examen de l'autorité, de la vie privée, de la classification et de la provenance.",[740,741],"Emplacement de déploiement\u002Fexécution","Clarifie l'emplacement de traitement, la connectivité et le contrôle opérationnel.",[743,744],"Outils\u002Factions","Montre si l'IA peut modifier l'état externe et à quel niveau de conséquence.",[746,747],"Surveillance humaine","Enregistre où une revue, une approbation ou une escalade est requise.",[749,750],"Risque\u002Fclassification","Relie le système aux contrôles organisationnels et réglementaires.",[752,753],"Preuves d'évaluation","Montre ce qui a été testé et dans quelles conditions de validité.",[755,756],"Version actuelle","Permet de tracer les incidents et régressions jusqu'à l'état réellement déployé.",[758,759],"État du cycle de vie","Proposé, expérimental, approuvé, en production, restreint, déprécié ou retiré.",{},{"id":762,"data":763,"type":42,"tunes":765},"h-governance",{"text":764,"level":247},"La gouvernance de l'IA et l'architecture d'IA d'entreprise sont liées mais pas identiques",{},{"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","Objectif",[278,278],{"id":775,"label":776,"values":777},"example","Exemple",[278,278],{"id":779,"label":780,"values":781},"failure","Échec si isolé",[278,278],"Gouvernance versus architecture",[784,787],{"id":785,"label":786},"governance","Gouvernance de l'IA",{"id":788,"label":302},"architecture",{},{"id":791,"data":792,"type":42,"tunes":794},"h-regulation",{"text":793,"level":247},"La réglementation devient une entrée d'architecture",{},{"id":796,"data":797,"type":218,"tunes":799},"p-regulation-1",{"text":798},"Pour les organisations opérant dans l'Union européenne, l'AI Act peut créer des exigences qui affectent la conception des systèmes, la documentation, la transparence, la gouvernance et les processus opérationnels. L'impact architectural dépend du rôle de l'organisation dans la chaîne de valeur de l'IA et de la classification concrète du système ; tous les systèmes d'IA n'ont pas les mêmes obligations.",{},{"id":801,"data":802,"type":218,"tunes":804},"p-regulation-2",{"text":803},"Depuis le 8 octobre 2026, le texte consolidé actuel indique que le Règlement s'applique généralement à partir du 2 août 2026. Les règles de gouvernance et les obligations pour les modèles d'IA à usage général ont commencé à s'appliquer plus tôt, tandis que certaines dispositions relatives aux systèmes à haut risque ont des dates ultérieures. La Commission a également commencé à faire appliquer de nouvelles exigences de transparence à partir du 2 août 2026 pour les systèmes interactifs et de contenu synthétique concernés.",{},{"id":806,"data":807,"type":218,"tunes":809},"p-regulation-3",{"text":808},"La leçon d'architecture d'entreprise n'est pas de « mettre la conformité dans le modèle ». Elle consiste à rendre la classification, le rôle de fournisseur\u002Fdéployeur, la documentation, la transparence, la supervision, la journalisation et les preuves de changement traçables jusqu'au système qui met réellement en œuvre le cas d'usage.",{},{"id":811,"data":812,"type":226,"tunes":815},"legal-note",{"body":813,"title":814,"variant":240},"Cet article décrit des implications architecturales, et non un avis juridique. L'architecture d'IA d'entreprise doit préserver les informations nécessaires aux spécialistes juridiques et de conformité pour classifier le système réel et associer les obligations à des contrôles concrets. L'architecture ne doit pas figer une interprétation réglementaire comme si chaque charge de travail d'IA avait le même statut.","La portée juridique dépend du cas d'usage",{},{"id":817,"data":818,"type":42,"tunes":820},"h-procurement",{"text":819,"level":247},"Achats et architecture deviennent liés",{},{"id":822,"data":823,"type":218,"tunes":825},"p-procurement-1",{"text":824},"Un modèle externe ou une plateforme d'IA gérée peut devenir une dépendance profonde même lorsque l'intégration ne nécessite que quelques appels d'API. L'architecture d'entreprise doit donc rendre les questions d'achat techniquement concrètes.",{},{"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],"Question d'achat","Conséquence architecturale",[834,835],"Où les données sont-elles traitées ?","Région, chemin réseau, résidence des données et contrôles de transfert.",[837,838],"Les données clients sont-elles conservées ou utilisées pour l'amélioration du fournisseur ?","Minimisation des données, contrôles contractuels et éligibilité du fournisseur.",[840,841],"Comment les modèles sont-ils versionnés ou retirés ?","Tests de régression, compatibilité, repli et planification du cycle de vie.",[843,844],"Quels sont les quotas et les limites de service ?","Architecture de capacité, contrôle d'admission et gestion des défaillances.",[846,847],"Quelle est la portabilité de l'intégration ?","Abstraction du fournisseur, coût de sortie et effort de migration.",[849,850],"Quelles informations sur les incidents sont disponibles ?","Observabilité, capacité d'investigation et escalade du support.",[852,853],"Quels sous-traitants ou services externes sont impliqués ?","Cartographie des dépendances et évaluation des risques.",[855,856],"Qu'est-ce qui change sans approbation explicite du client ?","Détection des changements, portes de release et stratégie d'acceptation.",{},{"id":859,"data":860,"type":42,"tunes":862},"h-control",{"text":861,"level":247},"L'architecture d'entreprise décide du niveau de contrôle de l'IA réellement nécessaire",{},{"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],"Exigence","Réponse architecturale possible",[871,872],"Accès rapide à des modèles gérés","Fournisseur géré avec identité d'entreprise, contrôles de passerelle et revue contractuelle.",[874,875],"Données privées avec orchestration gérée","Plan de contrôle géré plus exécution contrôlée par le client ou plan de données privé lorsque pris en charge.",[877,878],"Localité ou souveraineté stricte","Architecture restreinte à une région, souveraine, privée ou auto-hébergée selon l'exigence réelle.",[880,881],"Environnement isolé (air-gapped)","Modèles hébergés localement, recherche locale, outillage local, mise à jour\u002Fdistribution hors ligne et observabilité isolée.",[883,884],"Portabilité du fournisseur","État de domaine détenu par l'application plus adaptateurs et contrats qui isolent le comportement spécifique au fournisseur lorsque c'est pratique.",[886,887],"Contrôle maximal de la sémantique des agents","Runtime auto-géré ou profondément contrôlé avec propriété explicite des outils, du contexte, de l'état et du cycle de vie.",{},{"id":890,"data":891,"type":218,"tunes":893},"p-control-1",{"text":892},"L'architecture la plus contrôlée n'est pas automatiquement la meilleure architecture d'entreprise. Plus de propriété augmente la responsabilité en matière de correctifs, de capacité, de sécurité, de tests, d'opérations de modèles et de réponse aux incidents. L'architecture d'entreprise ne doit élever le niveau de contrôle que là où l'exigence justifie la charge opérationnelle supplémentaire.",{},{"id":895,"data":896,"type":42,"tunes":898},"h-change-management",{"text":897,"level":247},"L'IA transforme la gestion du changement en problème comportemental",{},{"id":900,"data":901,"type":218,"tunes":903},"p-change-1",{"text":902},"Une mise à jour normale de dépendance peut altérer les performances ou la compatibilité. Un changement d'IA peut aussi altérer le comportement. Remplacer un modèle, modifier un prompt système, changer la recherche, ajouter un outil ou modifier la politique de contexte peut modifier la façon dont le système interprète et répond, même si le code applicatif environnant change à peine.",{},{"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. Changement identifié","Un changement de modèle, de fournisseur, de prompt, de source de recherche, d'outil, de politique ou de runtime est proposé ou détecté.",{"label":912,"description":913},"2. Impact cartographié","Les solutions affectées, classes de données, utilisateurs, contrôles de risque, coûts, contrats et dépendances opérationnelles sont identifiés.",{"label":915,"description":916},"3. Décision d'architecture mise à jour","Les choix importants et les compromis sont consignés ; les décisions remplacées restent traçables historiquement.",{"label":918,"description":919},"4. Évaluation exécutée","Les tests pertinents de régression, de sécurité, de recherche, de latence, de coût et de domaine sont exécutés.",{"label":921,"description":922},"5. Approbation appliquée","Le niveau d'approbation suit les conséquences, le risque et la politique organisationnelle.",{"label":924,"description":925},"6. Déploiement contrôlé","Une release versionnée, un canari ou un déploiement progressif est utilisé lorsque approprié.",{"label":927,"description":928},"7. Preuves de production collectées","La télémétrie, les incidents, les retours et les résultats métier sont surveillés.",{"label":930,"description":931},"8. Retour arrière ou acceptation","Le changement est accepté, restreint, annulé ou remplacé sur la base des preuves.","Un chemin de changement d'IA en production",{},{"id":935,"data":936,"type":42,"tunes":938},"h-nfr-adr",{"text":937,"level":247},"L'IA d'entreprise a toujours besoin d'exigences non fonctionnelles et de décisions d'architecture",{},{"id":940,"data":941,"type":218,"tunes":943},"p-nfr-adr-1",{"text":942},"L'IA ne remplace pas la discipline architecturale ordinaire. Les exigences non fonctionnelles restent les conditions cibles : disponibilité, latence, confidentialité, isolation, auditabilité, récupérabilité, limites de coût, explicabilité ou autres exigences de qualité. Les enregistrements de décisions d'architecture préservent la réponse choisie et ses compromis.",{},{"id":945,"data":946,"type":218,"tunes":948},"p-nfr-adr-2",{"text":947},"La différence propre à l'IA est que certains attributs de qualité doivent être évalués de manière probabiliste ou empirique. « Les réponses doivent être utiles » est trop vague. Une exigence de production doit identifier la tâche, les données, la population d'utilisateurs, les conditions d'échec acceptables, la méthode de mesure et le seuil lorsque c'est pratique.",{},{"id":950,"data":951,"type":226,"tunes":954},"nfr-adr-chain",{"body":952,"title":953,"variant":288},"\u003Cstrong>Besoin métier → exigence \u002F NFR → décision d'architecture → mise en œuvre → évaluation \u002F validation → observation en production → décision de changement.\u003C\u002Fstrong> L'IA ajoute de nouvelles variables à cette chaîne ; elle ne la rend pas inutile.","Chaîne de traçabilité d'entreprise",{},{"id":956,"data":957,"type":42,"tunes":959},"h-delivery",{"text":958,"level":247},"L'architecture IA d'entreprise doit être connectée à la livraison",{},{"id":961,"data":962,"type":218,"tunes":964},"p-delivery-1",{"text":963},"Une architecture qui n'atteint jamais le backlog, l'implémentation, l'acceptation et les opérations reste conceptuelle. L'IA d'entreprise a donc besoin d'une traçabilité depuis les décisions d'architecture vers le travail de livraison et en retour depuis les preuves d'implémentation vers l'architecture.",{},{"id":966,"data":967,"type":218,"tunes":969},"p-delivery-2",{"text":968},"Jira et Confluence sont des exemples d'outils qui peuvent soutenir cette séparation lorsqu'ils sont utilisés délibérément : Confluence peut conserver les exigences, l'architecture, les décisions, les risques et la justification ; Jira peut gérer le travail de livraison actionnable et l'état. Le principe important est la traçabilité, non la marque de l'outil.",{},{"id":971,"data":972,"type":42,"tunes":974},"h-original",{"text":973,"level":247},"Preuve du projet original : 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 est utilisé ici comme preuve de projet original pour une réflexion structurée sur l'architecture d'entreprise et la livraison. Il s'agit d'un contexte de PoC \u002F projet d'entreprise, et non d'une preuve d'adoption massive par les clients, d'utilisation en production à l'échelle de l'entreprise ou de traction commerciale.","Preuve de projet, non affirmation de preuve de marché",{},{"id":982,"data":983,"type":218,"tunes":985},"p-enterprise-aaasaasa-1",{"text":984},"Enterprise Aaasaasa 0.1 combine l'architecture de plateforme, les concepts SaaS\u002FAPI, l'internationalisation, l'intégration de l'IA et la gouvernance structurée de projet. Le projet a été délibérément organisé de sorte que les exigences, l'architecture, la livraison du prototype, la validation et la clôture soient des jalons distincts plutôt qu'une phase d'implémentation indifférenciée.",{},{"id":987,"data":988,"type":218,"tunes":990},"p-enterprise-aaasaasa-2",{"text":989},"L'orientation architecturale inclut des concepts multi-instances \u002F multi-bases de données ainsi que des capacités API, CRUD, i18n et IA. Cela importe pour l'IA d'entreprise car les frontières de locataire ou d'instance, la propriété des bases de données et les services applicatifs doivent rester explicites lorsque des fonctionnalités d'IA sont ajoutées.",{},{"id":992,"data":993,"type":218,"tunes":995},"p-enterprise-aaasaasa-3",{"text":994},"La structure du projet a également traité les retards d'architecture, la dérive du périmètre et les préoccupations liées à l'IA et à la protection des données comme des risques de projet plutôt que de les découvrir seulement lors de l'implémentation. Les parties prenantes incluaient des perspectives techniques, de sécurité, de sponsor\u002Fpilotage et de services externes, ce qui est plus proche de la nature réelle interfonctionnelle de l'IA d'entreprise qu'un prototype uniquement basé sur un modèle.",{},{"id":997,"data":998,"type":218,"tunes":1000},"p-enterprise-aaasaasa-4",{"text":999},"La preuve utile est donc l'intégration de l'architecture et de la livraison : la structure métier et de projet, les jalons, les risques, l'architecture, le backend\u002FAPI, le travail frontend\u002FIA, la validation et la clôture sont traités comme des responsabilités connectées. Ce modèle est réutilisable même si le projet lui-même ne doit pas être présenté comme une preuve d'adoption externe en entreprise.",{},{"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],"Élément du projet","Leçon d'architecture IA d'entreprise",[1009,1010],"Jalon des exigences","La capacité d'IA doit commencer par un besoin défini, un périmètre, une acceptation et des contraintes de qualité.",[1012,1013],"Jalon d'architecture","Les données, l'API, les frontières d'instance\u002Fbase de données et l'intégration de l'IA sont un travail de conception explicite.",[1015,1016],"Jalon de prototype","L'architecture doit devenir suffisamment exécutable pour exposer les risques d'intégration.",[1018,1019],"Jalon de validation","Un prototype fonctionnel n'est pas la même chose qu'une acceptation validée.",[1021,1022],"Registre des risques","Le périmètre, les retards d'architecture et les préoccupations liées à l'IA et à la protection des données sont gérés comme des risques de livraison.",[1024,1025],"Structure des parties prenantes","L'IA d'entreprise couvre le sponsor\u002Fmétier, l'architecture, la sécurité, les fournisseurs externes et la livraison.",[1027,1028],"Clôture du projet","Les décisions, les risques restants et les preuves de validation doivent survivre au-delà du sprint d'implémentation.",{},{"id":1031,"data":1032,"type":42,"tunes":1034},"h-supporting",{"text":1033,"level":247},"Modèles d'implémentation de soutien issus du travail plus large sur la plateforme",{},{"id":1036,"data":1037,"type":218,"tunes":1039},"p-supporting-1",{"text":1038},"Un travail d'implémentation distinct dans la plateforme Aaasaasa plus large fournit des exemples concrets de frontières que l'architecture IA d'entreprise doit préserver : RBAC à portée de locataire dans le CMS, séparation explicite fournisseur\u002Fmodèle\u002Fruntime\u002Fpermission dans Aaasaasa AI Client, et récupération axée sur la provenance dans le Source of Truth Research Engine.",{},{"id":1041,"data":1042,"type":218,"tunes":1044},"p-supporting-2",{"text":1043},"Ces projets ne doivent pas être fusionnés en une seule plateforme de production revendiquée. Leur valeur ici est plus étroite : ils démontrent des modèles implémentés pour la portée d'identité, les frontières de fournisseur, les permissions d'exécution contrôlées, la provenance de récupération et la traçabilité des preuves qui sont directement pertinents pour l'IA d'entreprise.",{},{"id":1046,"data":1047,"type":42,"tunes":1049},"h-standards",{"text":1048,"level":247},"Comment les principales normes s'articulent",{},{"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],"Source","Ce qu'elle apporte à l'architecture IA d'entreprise",[1058,1059],"ISO\u002FIEC 42001:2023","Système de management de l'IA au niveau de l'organisation : politiques, objectifs, processus, responsabilité, surveillance et amélioration continue.",[1061,1062],"ISO\u002FIEC 23894:2023","Lignes directrices pour intégrer la gestion des risques spécifiques à l'IA dans les activités et fonctions organisationnelles.",[1064,1065],"NIST AI RMF 1.0","Cadre volontaire orienté cycle de vie pour gérer les risques liés à l'IA ; organisé autour de Govern, Map, Measure et Manage.",[1067,1068],"NIST AI 600-1","Profil d'IA générative étendant l'AI RMF avec des risques et actions spécifiques à l'IA générative.",[1070,1071],"EU AI Act","Obligations réglementaires contraignantes dans l'UE dont l'applicabilité dépend du rôle, du type de système et de la classification.",[1073,1074],"ISO\u002FIEC\u002FIEEE 42010:2022","Concepts généraux de description d'architecture pour exprimer les préoccupations, points de vue, décisions et relations.",{},{"id":1077,"data":1078,"type":218,"tunes":1080},"p-standards-1",{"text":1079},"Ces sources résolvent des problèmes différents. ISO\u002FIEC 42001 ne remplace pas l'architecture technique. ISO\u002FIEC 23894 et NIST AI RMF ne définissent pas une pile logicielle obligatoire unique. L'EU AI Act est une loi, pas un modèle de conception de plateforme. L'architecture doit traduire les exigences organisationnelles, de risque et légales applicables en frontières système implémentables et en preuves.",{},{"id":1082,"data":1083,"type":42,"tunes":1085},"h-failures",{"text":1084,"level":247},"Modes de défaillance courants de l'IA d'entreprise",{},{"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],"Mode de défaillance","Pourquoi cela échoue",[1094,1095],"Chaque équipe achète l'IA indépendamment","Crée des fournisseurs fantômes, des secrets dupliqués, un traitement des données incohérent et un faible levier sur le risque fournisseur.",[1097,1098],"Une équipe IA centrale possède chaque décision de domaine","Centralise le contrôle technique mais perd la responsabilité du domaine et crée un goulot d'étranglement.",[1100,1101],"La base de données vectorielle devient la source de vérité","L'infrastructure de récupération remplace silencieusement les systèmes faisant autorité et les règles de fraîcheur.",[1103,1104],"Une clé API partagée pour tous les utilisateurs et agents","Détruit l'attribution, le moindre privilège et l'auditabilité significative.",[1106,1107],"Un changement de modèle déployé comme un correctif de bibliothèque mineur","Les régressions comportementales peuvent atteindre la production sans évaluation du domaine.",[1109,1110],"Tous les prompts et sorties sont journalisés pour toujours","L'observabilité crée un référentiel de données sensibles non contrôlé.",[1112,1113],"La gouvernance n'est que de la documentation","Les politiques existent sans points d'application, preuves ou responsabilité opérationnelle.",[1115,1116],"La conformité est déléguée au fournisseur","Le rôle, le cas d'usage, les données et les obligations opérationnelles de l'organisation restent non résolus.",[1118,1119],"L'agent peut appeler des outils parce que le modèle prend en charge l'utilisation d'outils","La capacité est confondue avec l'autorisation.",[1121,1122],"La santé de la plateforme équivaut à l'exactitude métier","La disponibilité des points de terminaison et des modèles ne prouve pas la qualité des réponses du domaine ou des résultats acceptables.",[1124,1125],"Aucune stratégie de sortie pour la dépendance au modèle\u002Ffournisseur","Un changement de prix, de politique, de capacité ou de disponibilité devient une migration d'urgence.",{},{"id":1128,"data":1129,"type":42,"tunes":1131},"h-misconceptions",{"text":1130,"level":247},"Idées fausses courantes",{},{"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],"Idée fausse","Meilleur modèle",[1140,1141],"« L'IA d'entreprise signifie un chatbot à l'échelle de l'entreprise. »","Le chatbot est une interface ; l'architecture d'IA d'entreprise gouverne les données sous-jacentes, l'identité, le fournisseur, l'environnement d'exécution, les risques et les opérations.",[1143,1144],"« Si nous utilisons un fournisseur de modèle réputé, la gouvernance est résolue. »","Les contrôles du fournisseur ne définissent pas votre cas d'usage, l'autorité sur les données, les permissions des utilisateurs, l'acceptation métier ou le rôle juridique.",[1146,1147],"« L'IA privée signifie que tout doit être auto-hébergé. »","Les exigences de confidentialité peuvent conduire à plusieurs architectures ; la frontière de contrôle requise doit être énoncée précisément.",[1149,1150],"« La gouvernance de l'IA relève du juridique, l'architecture relève de l'informatique. »","Les deux disciplines doivent être connectées car les obligations politiques nécessitent des contrôles implémentables et des preuves.",[1152,1153],"« Un modèle d'entreprise unique est plus simple. »","La standardisation peut aider, mais les charges de travail peuvent nécessiter différentes modalités, régions, coûts, niveaux de qualité ou modèles de contrôle.",[1155,1156],"« Le risque lié à l'IA est un risque de modèle. »","Le risque peut provenir des données, des invites, de la récupération, de l'identité, des outils, des interfaces, des opérations, des utilisateurs et des processus organisationnels.",[1158,1159],"« L'humain dans la boucle rend un agent sûr. »","L'approbation humaine n'aide que si le réviseur dispose d'un contexte utile, de l'autorité, du temps et d'un point de décision clair.",[1161,1162],"« Un pilote réussi prouve la préparation à l'échelle de l'entreprise. »","Un pilote prouve une capacité limitée ; la préparation à l'échelle de l'entreprise nécessite également l'intégration, la gouvernance, le cycle de vie, les opérations et des contrôles reproductibles.",{},{"id":1165,"data":1166,"type":42,"tunes":1168},"h-framework",{"text":1167,"level":247},"Une séquence de décision pratique pour l'architecture d'IA d'entreprise",{},{"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. Définir la capacité métier","Énoncer l'utilisateur, la décision ou le flux de travail, la valeur attendue et le propriétaire responsable.",{"label":1177,"description":1178},"2. Classifier les données et l'autorité","Identifier les systèmes de référence, les données personnelles\u002Fconfidentielles, les exigences de rétention, de fraîcheur et de provenance.",{"label":1180,"description":1181},"3. Définir les frontières d'identité et d'action","Déterminer qui peut lire, générer, décider, approuver et modifier les systèmes externes.",{"label":1183,"description":1184},"4. Sélectionner les responsabilités de la solution et de la plateforme","Décider ce qui appartient à la charge de travail, ce qui peut être partagé et ce qui reste la propriété de l'entreprise.",{"label":1186,"description":1187},"5. Évaluer la dépendance au fournisseur et à l'environnement d'exécution","Évaluer les options gérées, auto-hébergées, privées, souveraines ou hybrides par rapport aux exigences réelles.",{"label":1189,"description":1190},"6. Cartographier les risques et les obligations réglementaires","Déterminer le niveau de risque, les contrôles organisationnels et les responsabilités juridiques applicables pour le système concret.",{"label":1192,"description":1193},"7. Définir une acceptation mesurable","Créer des critères d'évaluation pour la qualité, la fiabilité, la sécurité, la récupération, le coût et le comportement opérationnel.",{"label":1195,"description":1196},"8. Enregistrer les décisions d'architecture","Préserver la justification, les alternatives, les compromis, les dépendances et les conditions qui déclencheraient une reconsidération.",{"label":1198,"description":1199},"9. Relier l'architecture à la livraison","Traduire la conception en backlog, jalons, critères d'acceptation, travail technique et propriété.",{"label":1201,"description":1202},"10. Valider dans des conditions réalistes de production","Tester des scénarios réalistes d'identité, de données, de défaillance, de latence, de fournisseur, d'outil et de récupération plutôt que de simples démonstrations propres.",{"label":1204,"description":1205},"11. Établir les opérations et le contrôle des changements","Définir la surveillance, la réponse aux incidents, les mises à jour du modèle\u002Ffournisseur, les tests de régression, le retour arrière et la mise hors service.",{"label":1207,"description":1208},"12. Réinjecter les preuves dans l'architecture","Utiliser les observations de production, les audits, les incidents et les évaluations pour réviser les décisions et les contrôles.","De l'opportunité à une capacité d'entreprise gouvernée",{},{"id":1212,"data":1213,"type":42,"tunes":1215},"h-checklist",{"text":1214,"level":247},"Liste de contrôle de l'architecture d'IA d'entreprise",{},{"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],"Question","Preuve attendue",[1224,1225],"Quelle capacité métier cette IA soutient-elle ?","Propriétaire nommé, groupe d'utilisateurs, décision\u002Fflux de travail prévu et objectif d'acceptation.",[1227,1228],"Quelle source fait autorité pour chaque fait important ?","Systèmes de référence, autorité documentaire, règles de provenance et de fraîcheur.",[1230,1231],"Quelles identités existent ?","Les identités humaines, applicatives, de service, d'agent, de locataire\u002Forganisation et de fournisseur sont distinguables.",[1233,1234],"Que peut lire l'IA ?","Sources de données limitées par autorisation et règles explicites sur les données sensibles.",[1236,1237],"Que peut modifier l'IA ?","Inventaire des outils\u002Factions, modèle de permissions, approbation et chemin de retour arrière.",[1239,1240],"Quel fournisseur\u002Fmodèle est utilisé et pourquoi ?","Décision d'architecture incluant la qualité, la sécurité, le coût, la région, le cycle de vie et les considérations de sortie.",[1242,1243],"Que se passe-t-il si le fournisseur est indisponible ?","Mode dégradé, solution de repli, refus ou plan de continuité.",[1245,1246],"Comment la qualité est-elle évaluée ?","Jeux de données spécifiques à la tâche, évaluateurs, seuils, critères de régression et conditions de validité.",[1248,1249],"Qu'est-ce qui est journalisé ?","Schéma de télémétrie, rédaction, accès, rétention et objectif d'audit.",[1251,1252],"Qui est responsable du risque lié à l'IA ?","Responsabilité organisationnelle nommée liée au système concret.",[1254,1255],"Quelle classification juridique s'applique ?","Évaluation documentée basée sur le droit en vigueur et le cas d'usage réel.",[1257,1258],"Comment les modifications de modèle\u002Finvite\u002Frécupération sont-elles approuvées ?","Versionnage, évaluation, enregistrement d'architecture\u002Fchangement et porte de déploiement.",[1260,1261],"Qui répond à un incident d'IA ?","Procédure, propriétaire technique, escalade métier\u002Fdomaine et escalade fournisseur.",[1263,1264],"Comment le système est-il mis hors service ?","Nettoyage des données, révocation des accès, sortie du fournisseur, rétention des preuves et suppression des dépendances.",{},{"id":1267,"data":1268,"type":42,"tunes":1270},"h-edge",{"text":1269,"level":247},"Cas limites et limites",{},{"id":1272,"data":1273,"type":218,"tunes":1275},"p-edge-1",{"text":1274},"Une petite entreprise avec un seul cas d'usage d'IA à faible risque peut ne pas avoir besoin d'une fonction formelle d'architecture d'IA d'entreprise. Les mêmes principes peuvent être appliqués légèrement : propriétaire clair, données approuvées, fournisseur explicite, évaluation de base, contrôle d'accès et responsabilité opérationnelle.",{},{"id":1277,"data":1278,"type":218,"tunes":1280},"p-edge-2",{"text":1279},"Une organisation hautement réglementée peut avoir besoin d'une séparation plus forte, d'une validation indépendante, de processus de conformité formels, d'un hébergement local ou d'un fonctionnement en air gap. Ces contrôles sont dictés par le cas d'usage et l'environnement réglementaire, et non par le mot « entreprise ».",{},{"id":1282,"data":1283,"type":218,"tunes":1285},"p-edge-3",{"text":1284},"Une organisation peut également utiliser principalement des produits d'IA SaaS plutôt que de construire des systèmes d'IA. L'architecture d'entreprise reste importante car l'identité, l'accès aux données, les conditions contractuelles, l'IA fantôme, la rétention, l'audit et la concentration des fournisseurs restent des préoccupations organisationnelles.",{},{"id":1287,"data":1288,"type":218,"tunes":1290},"p-edge-4",{"text":1289},"Une plateforme centralisée n'est pas obligatoire. La propriété fédérée de la plateforme peut être valide lorsque les domaines ont des exigences matériellement différentes, à condition que les responsabilités d'identité, de risque, d'inventaire et d'interopérabilité au niveau de l'entreprise restent cohérentes.",{},{"id":1292,"data":1293,"type":42,"tunes":1295},"h-change-answer",{"text":1294,"level":247},"Qu'est-ce qui changerait cette réponse ?",{},{"id":1297,"data":1298,"type":218,"tunes":1300},"p-change-answer-1",{"text":1299},"L'architecture change lorsque la tolérance au risque de l'organisation, la classification réglementaire, la sensibilité des données, la portée géographique, la stratégie de fournisseur, les compétences internes ou la criticité métier changent. Un assistant marketing public et un système participant à des décisions en matière d'emploi, de finance, de santé ou d'infrastructure critique ne devraient pas hériter de modèles de contrôle identiques.",{},{"id":1302,"data":1303,"type":218,"tunes":1305},"p-change-answer-2",{"text":1304},"La mise en œuvre change également à mesure que les normes, la réglementation et les plateformes d'IA évoluent. Le NIST AI RMF 1.0 est actuellement en cours de révision, l'EU AI Act a des dates d'application échelonnées, et les capacités des modèles\u002Ffournisseurs continuent de changer rapidement. L'architecture d'entreprise devrait donc préserver des frontières de responsabilité stables tout en traitant les mécanismes des fournisseurs et les détails réglementaires comme des entrées versionnées.",{},{"id":1307,"data":1308,"type":42,"tunes":1310},"h-related",{"text":1309,"level":247},"Connaissances canoniques associées",{},{"id":1312,"data":1313,"type":218,"tunes":1315},"p-related-1",{"text":1314},"L'architecture d'IA d'entreprise s'appuie sur l'architecture de solution et de plateforme. La couche solution explique une charge de travail. La couche plateforme explique les capacités d'IA réutilisables. La couche entreprise relie les deux aux données, à l'identité, à la gouvernance, aux risques, aux achats et aux opérations à l'échelle de l'organisation.",{},{"id":1317,"data":1318,"type":218,"tunes":1320},"p-related-2",{"text":1319},"La génération augmentée par récupération n'est qu'un mécanisme au sein de cette architecture. Le RAG peut améliorer l'accès aux connaissances de l'entreprise, mais il ne résout pas à lui seul l'autorité sur les données, les permissions, la gouvernance ou la validité des réponses.",{},{"id":1322,"data":1323,"type":1328,"tunes":1329},"ref-rag",{"url":1324,"title":1325,"excerpt":1326,"ctaLabel":1327},"https:\u002F\u002Fstajic.de\u002Ffr\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works","Qu'est-ce que le RAG ? L'explication la plus simple de son fonctionnement","Une explication en langage clair de la façon dont la récupération de connaissances externes se connecte au modèle de langage sans faire de la récupération la source de vérité.","Lire les fondements du RAG","referralArticle",{},{"id":1331,"data":1332,"type":218,"tunes":1334},"p-related-3",{"text":1333},"Pour les cas d'usage d'entreprise à forte densité de preuves, la validité des réponses nécessite également une frontière explicite : une sortie n'est soutenue que dans le cadre des preuves, de la version, de la portée et des hypothèses qui l'ont produite.",{},{"id":1336,"data":1337,"type":1328,"tunes":1342},"ref-avb",{"url":1338,"title":1339,"excerpt":1340,"ctaLabel":1341},"https:\u002F\u002Fstajic.de\u002Ffr\u002Fblog\u002Fthe-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers","La frontière de validité des réponses : la couche manquante entre pertinence et réponses IA fiables","Un cadre pour expliciter les conditions dans lesquelles une affirmation IA reste soutenue et quels changements nécessitent une restriction ou un recalcul.","Lire La frontière de validité des réponses",{},{"id":1344,"data":1345,"type":218,"tunes":1347},"p-related-4",{"text":1346},"Les sujets d'entreprise en aval incluent la gouvernance de l'IA, l'IA privée, l'IA souveraine, l'IA en environnement isolé, l'architecture IA multi-locataires, le RBAC versus l'isolation des locataires, l'abstraction des fournisseurs, le routage des modèles et l'architecture IA de production.",{},{"id":1349,"data":1350,"type":42,"tunes":1352},"h-faq",{"text":1351,"level":247},"Questions fréquentes",{},{"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","L'architecture IA d'entreprise est l'architecture à l'échelle de l'organisation qui définit comment les solutions IA et les capacités IA partagées s'intègrent à la propriété métier, aux données d'entreprise, à l'identité, à la sécurité, aux fournisseurs, à la gouvernance, aux risques, à la conformité, au cycle de vie et aux opérations.","Qu'est-ce que l'architecture IA d'entreprise ?",{"id":1362,"answer":1363,"question":1364},"faq2","Non. Une plateforme IA fournit des capacités techniques réutilisables telles que l'accès aux modèles, la récupération, les environnements d'exécution d'agents et l'observabilité. L'architecture IA d'entreprise définit comment cette plateforme et les solutions IA individuelles s'inscrivent dans l'architecture et le modèle opérationnel plus larges de l'organisation.","L'architecture IA d'entreprise est-elle identique à une plateforme IA ?",{"id":1366,"answer":1367,"question":1368},"faq3","Non. La standardisation peut réduire la complexité, mais différentes charges de travail peuvent nécessiter différents fournisseurs, modèles, régions, niveaux de contrôle ou modalités. L'exigence importante est une politique explicite et une propriété du cycle de vie.","L'IA d'entreprise nécessite-t-elle un modèle central unique ?",{"id":1370,"answer":1371,"question":1372},"faq4","Parce que les informations récupérées ou générées ne sont pas automatiquement faisant autorité. Les systèmes d'entreprise doivent préserver quelle source est le système d'enregistrement, si les données sont à jour, qui peut y accéder et comment une affirmation générée peut être retracée jusqu'aux preuves.","Pourquoi l'autorité des données est-elle importante pour l'IA d'entreprise ?",{"id":1374,"answer":1375,"question":1376},"faq5","La gouvernance de l'IA définit les politiques, la responsabilité et les droits de décision. L'architecture IA d'entreprise définit les limites du système, les interfaces, les flux de données et les mécanismes techniques par lesquels ces politiques peuvent être mises en œuvre et attestées.","Quelle est la différence entre la gouvernance de l'IA et l'architecture IA d'entreprise ?",{"id":1378,"answer":1379,"question":1380},"faq6","Non. Les obligations dépendent de facteurs tels que le rôle de l'organisation, le cas d'usage et la classification du système, ainsi que les dispositions pertinentes en vigueur. La classification juridique doit être effectuée pour le système concret en vertu du droit en vigueur.","Le règlement européen sur l'IA s'applique-t-il de la même manière à tous les systèmes IA d'entreprise ?",{"id":1382,"answer":1383,"question":1384},"faq7","Non. Un pilote démontre une capacité limitée. Le déploiement en entreprise nécessite également l'identité, l'autorité des données, la sécurité, la gouvernance des fournisseurs, l'évaluation, le cycle de vie, la réponse aux incidents, la surveillance, la conformité et une propriété opérationnelle responsable.","Un pilote IA réussi suffit-il pour un déploiement en entreprise ?",{"id":1386,"answer":1387,"question":1388},"faq8","Uniquement lorsque l'exigence justifie le contrôle et la responsabilité opérationnelle supplémentaires. Les approches gérées, privées, souveraines, auto-hébergées et hybrides sont des options d'architecture dont l'adéquation dépend des exigences en matière de données, de réglementation, de disponibilité, de coût, de capacité et d'exploitation.","Les entreprises doivent-elles auto-héberger l'IA ?","FAQ sur l'architecture IA d'entreprise",{},{"id":1392,"data":1393,"type":42,"tunes":1395},"h-glossary",{"text":1394,"level":247},"Glossaire",{},{"id":1397,"data":1398,"type":1397,"tunes":1440},"glossary",{"title":1399,"entries":1400},"Termes clés de l'architecture IA d'entreprise",[1401,1405,1409,1412,1416,1420,1424,1428,1432,1436],{"term":1402,"anchor":1403,"definition":1404},"Architecture IA d'entreprise","enterprise-ai-architecture","Architecture à l'échelle de l'organisation régissant la manière dont les systèmes IA, les plateformes, les données, les identités, les fournisseurs, les contrôles des risques et les opérations s'articulent ensemble.",{"term":1406,"anchor":1407,"definition":1408},"Système de management de l'IA","ai-management-system","Système de management organisationnel pour établir les politiques, objectifs et processus liés à l'IA ; l'ISO\u002FIEC 42001 spécifie les exigences d'un tel système.",{"term":597,"anchor":1410,"definition":1411},"data-authority","La règle qui identifie quelle source ou quel système fait autorité pour un fait, un enregistrement, un état ou un contexte décisionnel particulier.",{"term":1413,"anchor":1414,"definition":1415},"Système d'enregistrement","system-of-record","Le système faisant autorité responsable de l'état officiel actuel d'un enregistrement métier ou d'une entité de domaine.",{"term":1417,"anchor":1418,"definition":1419},"Inventaire IA","ai-inventory","Un enregistrement structuré des cas d'usage IA, des propriétaires, des modèles\u002Ffournisseurs, des données, des outils, des risques, des preuves d'évaluation, de l'état du cycle de vie et des contrôles associés.",{"term":1421,"anchor":1422,"definition":1423},"Dépendance au fournisseur","provider-dependency","La dépendance technique, contractuelle et opérationnelle créée lorsqu'une charge de travail IA dépend d'un modèle externe ou d'une plateforme gérée.",{"term":1425,"anchor":1426,"definition":1427},"Supervision humaine","human-oversight","Examen, approbation, intervention ou escalade humains définis, appliqués là où les conséquences du système, l'incertitude ou la réglementation l'exigent.",{"term":1429,"anchor":1430,"definition":1431},"GenAIOps","genaiops","Pratiques opérationnelles pour les charges de travail d'IA générative couvrant la sélection des modèles, les invites, les données d'ancrage, l'évaluation, le déploiement, la surveillance et la gestion du cycle de vie.",{"term":1433,"anchor":1434,"definition":1435},"Gestion des risques liés à l'IA","ai-risk-management","Le processus organisationnel d'identification, d'évaluation, de traitement, de surveillance et de révision des risques associés aux systèmes IA tout au long de leur cycle de vie.",{"term":1437,"anchor":1438,"definition":1439},"Décision d'architecture","architecture-decision","Un choix de conception important accompagné de son contexte, de sa justification, des alternatives, des compromis et de son statut dans le cycle de vie.",{},{"id":1442,"data":1443,"type":42,"tunes":1445},"h-conclusion",{"text":1444,"level":247},"Conclusion",{},{"id":1447,"data":1448,"type":218,"tunes":1450},"p-conclusion-1",{"text":1449},"Lorsque l'IA entre dans une entreprise, celle-ci n'acquiert pas simplement un nouveau composant logiciel. Elle acquiert une nouvelle classe de comportement et de dépendance qui traverse les données, l'identité, les fournisseurs, les décisions métier, la sécurité, les opérations, la gouvernance et la gestion du changement.",{},{"id":1452,"data":1453,"type":218,"tunes":1455},"p-conclusion-2",{"text":1454},"La réponse architecturale n'est pas de tout centraliser. Elle consiste à rendre les responsabilités explicites : quelles données font autorité, quelles identités peuvent agir, quels fournisseurs sont approuvés, quels contrôles sont partagés, quelles décisions restent du ressort du domaine, comment le comportement est évalué, comment les incidents sont traités et comment le système évolue dans le temps.",{},{"id":1457,"data":1458,"type":218,"tunes":1460},"p-conclusion-3",{"text":1459},"C'est la distinction fondamentale de l'architecture IA d'entreprise : elle transforme une capacité IA isolée en un système gouvernable à l'échelle de l'organisation sans prétendre que les modèles, les plateformes, les domaines métier et les contrôles d'entreprise sont la même chose.",{},{"id":1462,"data":1463,"type":42,"tunes":1465},"h-sources",{"text":1464,"level":247},"Sources primaires et orientations actuelles",{},{"id":1467,"data":1468,"type":218,"tunes":1470},"p-sources-note",{"text":1469},"Les normes externes, la réglementation et les orientations actuelles des fournisseurs en matière d'architecture ci-dessous ont été vérifiées le 8 octobre 2026. Les sections spécifiques au projet sont explicitement marquées comme preuves originales du projet et ne doivent pas être lues comme des affirmations de fait général du secteur.",{},{"id":1472,"data":1473,"type":1479,"tunes":1480},"src-iso-42001",{"link":1474,"meta":1475},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F42001",{"image":1476,"title":1477,"description":1478},{"url":278},"ISO\u002FIEC 42001:2023 — Système de management de l'intelligence artificielle","Norme internationale spécifiant les exigences pour établir, mettre en œuvre, maintenir et améliorer continuellement un système de management de l'IA au sein des organisations.","linkTool",{},{"id":1482,"data":1483,"type":1479,"tunes":1489},"src-iso-23894",{"link":1484,"meta":1485},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F77304.html",{"image":1486,"title":1487,"description":1488},{"url":278},"ISO\u002FIEC 23894:2023 — Lignes directrices sur la gestion des risques liés à l'IA","Lignes directrices internationales pour intégrer la gestion des risques spécifiques à l'IA dans les activités et fonctions organisationnelles.",{},{"id":1491,"data":1492,"type":1479,"tunes":1498},"src-nist-rmf",{"link":1493,"meta":1494},"https:\u002F\u002Fwww.nist.gov\u002Fitl\u002Fai-risk-management-framework",{"image":1495,"title":1496,"description":1497},{"url":278},"Cadre de gestion des risques liés à l'IA du NIST","Cadre volontaire du NIST orienté cycle de vie pour gérer les risques liés à l'IA. Le NIST indique que l'AI RMF 1.0 est actuellement en cours de révision.",{},{"id":1500,"data":1501,"type":1479,"tunes":1507},"src-nist-genai",{"link":1502,"meta":1503},"https:\u002F\u002Fwww.nist.gov\u002Fpublications\u002Fartificial-intelligence-risk-management-framework-generative-artificial-intelligence",{"image":1504,"title":1505,"description":1506},{"url":278},"NIST AI 600-1 — Profil pour l'IA générative","Profil complémentaire du NIST décrivant les risques spécifiques à l'IA générative et les actions de gestion des risques alignées sur l'AI RMF.",{},{"id":1509,"data":1510,"type":1479,"tunes":1516},"src-eu-consolidated",{"link":1511,"meta":1512},"https:\u002F\u002Feur-lex.europa.eu\u002Feli\u002Freg\u002F2024\u002F1689\u002F2026-07-27\u002Feng",{"image":1513,"title":1514,"description":1515},{"url":278},"EUR-Lex — Règlement (UE) 2024\u002F1689, texte consolidé","Texte consolidé actuel du règlement sur l'IA utilisé pour les dates d'application et la structure réglementaire, tel que vérifié le 8 octobre 2026.",{},{"id":1518,"data":1519,"type":1479,"tunes":1525},"src-eu-timeline",{"link":1520,"meta":1521},"https:\u002F\u002Fdigital-strategy.ec.europa.eu\u002Fen\u002Fpolicies\u002Fregulatory-framework-ai",{"image":1522,"title":1523,"description":1524},{"url":278},"Commission européenne — Cadre réglementaire de la loi sur l'IA","Aperçu actuel de la Commission des phases d'application de la loi sur l'IA, y compris l'applicabilité en 2026 et les dates ultérieures pour certaines dispositions à haut risque.",{},{"id":1527,"data":1528,"type":1479,"tunes":1534},"src-ms-ai",{"link":1529,"meta":1530},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fget-started",{"image":1531,"title":1532,"description":1533},{"url":278},"Microsoft Azure Well-Architected — Charges de travail IA","Conseils d'architecture actuels sur les charges de travail IA, y compris le comportement non déterministe, les données, la conception des applications et les opérations.",{},{"id":1536,"data":1537,"type":1479,"tunes":1543},"src-ms-ops",{"link":1538,"meta":1539},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fmlops-genaiops",{"image":1540,"title":1541,"description":1542},{"url":278},"Microsoft — MLOps et GenAIOps pour les charges de travail IA","Conseils actuels sur le cycle de vie opérationnel, les données, la maintenance des modèles, le déploiement, la surveillance et l'évolution continue.",{},{"id":1545,"data":1546,"type":1479,"tunes":1552},"src-ms-responsible",{"link":1547,"meta":1548},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fresponsible-ai",{"image":1549,"title":1550,"description":1551},{"url":278},"Microsoft — IA responsable dans les charges de travail Azure","Conseils actuels reliant la politique d'IA au contrôle des données, à l'identité, à l'auditabilité des agents, à l'accès basé sur les rôles et aux garanties opérationnelles.",{},{"id":1554,"data":1555,"type":1479,"tunes":1561},"src-iso-42010",{"link":1556,"meta":1557},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html",{"image":1558,"title":1559,"description":1560},{"url":278},"ISO\u002FIEC\u002FIEEE 42010:2022 — Description de l'architecture","Norme actuelle de description de l'architecture prenant en charge les préoccupations explicites, les points de vue et les relations à travers l'architecture système.",{},"2.31","L'architecture de l'IA en entreprise explique comment l'IA transforme les systèmes d'entreprise à travers l'autorité des données, l'identité, les autorisations, les fournisseurs, les risques, la gouvernance, l'évaluation, la conformité et les opérations.","\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":1571,"de":1572,"sr":1573,"es":1574,"fr":1575,"it":1576,"ru":1577,"zh":1578},"\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",[1580,1583,1587,1591],{"id":1581,"name":1582,"slug":785},59,"Gouvernance et audit",{"id":1584,"name":1585,"slug":1586},57,"Limites des données","data-boundaries",{"id":1588,"name":1589,"slug":1590},80,"Accès et identité","access-and-identity",{"id":1592,"name":1593,"slug":1594},84,"Politique et limites des données","policy-and-data",{"id":1596,"login":1597,"email":1598,"displayName":1599},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[1601,2742],{"lang":1602,"title":1603,"content":1604,"contentJson":1605,"excerpt":2741},"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":1606,"blocks":1607,"version":2740},1791478189041,[1608,1612,1617,1622,1627,1631,1635,1639,1643,1647,1671,1675,1679,1683,1687,1710,1714,1718,1722,1726,1730,1734,1738,1742,1746,1750,1754,1759,1763,1767,1771,1775,1779,1783,1787,1791,1795,1799,1803,1807,1811,1815,1819,1823,1827,1831,1835,1839,1843,1847,1851,1855,1859,1863,1867,1871,1875,1879,1883,1887,1935,1940,1944,1949,1980,1984,1988,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,2332,2336,2340,2380,2384,2415,2419,2460,2464,2512,2516,2520,2524,2528,2532,2536,2540,2544,2548,2552,2556,2563,2567,2574,2578,2582,2611,2615,2647,2650,2654,2658,2662,2666,2670,2677,2684,2691,2698,2705,2712,2719,2726,2733],{"id":215,"data":1609,"type":218,"tunes":1611},{"text":1610},"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":1613,"type":226,"tunes":1616},{"body":1614,"title":1615,"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":1618,"type":226,"tunes":1621},{"body":1619,"title":1620,"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":1623,"type":226,"tunes":1626},{"body":1624,"title":1625,"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":1628,"type":248,"tunes":1630},{"title":1629,"maxLevel":246,"minLevel":247},"Contents",{},{"id":251,"data":1632,"type":42,"tunes":1634},{"text":1633,"level":247},"What enterprise AI architecture really means",{},{"id":256,"data":1636,"type":218,"tunes":1638},{"text":1637},"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":1640,"type":218,"tunes":1642},{"text":1641},"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":1644,"type":218,"tunes":1646},{"text":1645},"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":1648,"type":303,"tunes":1670},{"rows":1649,"title":1662,"layout":292,"columns":1663},[1650,1653,1656,1659],{"id":275,"label":1651,"values":1652},"Primary scope",[278,278,278],{"id":280,"label":1654,"values":1655},"Primary question",[278,278,278],{"id":284,"label":1657,"values":1658},"Ownership focus",[278,278,278],{"id":288,"label":1660,"values":1661},"Success condition",[278,278,278],"Solution, platform and enterprise AI architecture are different scopes",[1664,1666,1668],{"id":295,"label":1665},"AI Solution Architecture",{"id":298,"label":1667},"AI Platform Architecture",{"id":301,"label":1669},"Enterprise AI Architecture",{},{"id":306,"data":1672,"type":42,"tunes":1674},{"text":1673,"level":247},"The simplest example",{},{"id":311,"data":1676,"type":218,"tunes":1678},{"text":1677},"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":1680,"type":218,"tunes":1682},{"text":1681},"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":1684,"type":218,"tunes":1686},{"text":1685},"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":1688,"type":349,"tunes":1709},{"steps":1689,"title":1708,"orientation":348},[1690,1693,1696,1699,1702,1705],{"label":1691,"description":1692},"1. Isolated use case","One team connects one model to one workflow and validates local value.",{"label":1694,"description":1695},"2. Shared dependencies appear","Multiple teams need providers, model access, retrieval, identity, secrets, observability and evaluation.",{"label":1697,"description":1698},"3. Enterprise boundaries are crossed","AI touches regulated data, systems of record, external vendors, privileged actions and business decisions.",{"label":1700,"description":1701},"4. Ownership must become explicit","Business, architecture, data, security, legal\u002Fcompliance, procurement and operations need defined responsibilities.",{"label":1703,"description":1704},"5. Lifecycle becomes organizational","Model changes, prompt changes, provider changes and new agent capabilities become governed changes rather than local developer edits.",{"label":1706,"description":1707},"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":1711,"type":42,"tunes":1713},{"text":1712,"level":247},"Where the simple example stops",{},{"id":357,"data":1715,"type":218,"tunes":1717},{"text":1716},"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":1719,"type":218,"tunes":1721},{"text":1720},"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":1723,"type":42,"tunes":1725},{"text":1724,"level":247},"What changes in the architecture when AI enters the enterprise",{},{"id":372,"data":1727,"type":42,"tunes":1729},{"text":1728,"level":246},"1. Business ownership becomes part of the technical architecture",{},{"id":377,"data":1731,"type":218,"tunes":1733},{"text":1732},"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":1735,"type":218,"tunes":1737},{"text":1736},"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":1739,"type":42,"tunes":1741},{"text":1740,"level":246},"2. Data access is not enough — data authority must be defined",{},{"id":392,"data":1743,"type":218,"tunes":1745},{"text":1744},"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":1747,"type":218,"tunes":1749},{"text":1748},"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":1751,"type":218,"tunes":1753},{"text":1752},"Enterprise AI therefore needs provenance, freshness, source classification, authorization propagation and invalidation rules in addition to ordinary data integration.",{},{"id":407,"data":1755,"type":226,"tunes":1758},{"body":1756,"title":1757,"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":1760,"type":42,"tunes":1762},{"text":1761,"level":246},"3. Identity becomes multi-layered",{},{"id":418,"data":1764,"type":218,"tunes":1766},{"text":1765},"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":1768,"type":218,"tunes":1770},{"text":1769},"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":1772,"type":218,"tunes":1774},{"text":1773},"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":1776,"type":42,"tunes":1778},{"text":1777,"level":246},"4. Permissions move from content access to action authority",{},{"id":438,"data":1780,"type":218,"tunes":1782},{"text":1781},"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":1784,"type":218,"tunes":1786},{"text":1785},"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":1788,"type":42,"tunes":1790},{"text":1789,"level":246},"5. The AI provider becomes an enterprise dependency",{},{"id":453,"data":1792,"type":218,"tunes":1794},{"text":1793},"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":1796,"type":218,"tunes":1798},{"text":1797},"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":1800,"type":218,"tunes":1802},{"text":1801},"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":1804,"type":42,"tunes":1806},{"text":1805,"level":246},"6. AI risk becomes a lifecycle process",{},{"id":473,"data":1808,"type":218,"tunes":1810},{"text":1809},"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":1812,"type":218,"tunes":1814},{"text":1813},"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":1816,"type":218,"tunes":1818},{"text":1817},"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":1820,"type":42,"tunes":1822},{"text":1821,"level":246},"7. Governance becomes an operating system, not a policy PDF",{},{"id":493,"data":1824,"type":218,"tunes":1826},{"text":1825},"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":1828,"type":218,"tunes":1830},{"text":1829},"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":1832,"type":42,"tunes":1834},{"text":1833,"level":246},"8. Evaluation becomes a production control",{},{"id":508,"data":1836,"type":218,"tunes":1838},{"text":1837},"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":1840,"type":218,"tunes":1842},{"text":1841},"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":1844,"type":218,"tunes":1846},{"text":1845},"Model, prompt, retrieval and tool changes should be traceable to evaluation evidence where the change can materially affect output behavior.",{},{"id":523,"data":1848,"type":42,"tunes":1850},{"text":1849,"level":246},"9. Observability must include behavior, data and model context",{},{"id":528,"data":1852,"type":218,"tunes":1854},{"text":1853},"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":1856,"type":218,"tunes":1858},{"text":1857},"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":1860,"type":42,"tunes":1862},{"text":1861,"level":246},"10. AI components need explicit lifecycle ownership",{},{"id":543,"data":1864,"type":218,"tunes":1866},{"text":1865},"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":1868,"type":218,"tunes":1870},{"text":1869},"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":1872,"type":42,"tunes":1874},{"text":1873,"level":246},"11. Incident response must include AI-specific failure modes",{},{"id":558,"data":1876,"type":218,"tunes":1878},{"text":1877},"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":1880,"type":218,"tunes":1882},{"text":1881},"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":1884,"type":42,"tunes":1886},{"text":1885,"level":247},"Enterprise AI creates cross-functional ownership",{},{"id":573,"data":1888,"type":292,"tunes":1934},{"content":1889,"stretched":43,"withHeadings":14},[1890,1894,1898,1902,1906,1910,1914,1918,1922,1926,1930],[1891,1892,1893],"Concern","Typical enterprise owner or contributor","Architecture question",[1895,1896,1897],"Business use","Business owner \u002F product owner","What decision or workflow is AI allowed to support or automate?",[1899,1900,1901],"Solution architecture","AI \u002F solution architect","How does the concrete workload meet its functional and quality requirements?",[1903,1904,1905],"Shared AI capabilities","AI platform \u002F platform engineering","Which reusable model, retrieval, agent and observability services are provided?",[1907,1908,1909],"Enterprise coherence","Enterprise architecture","How do AI systems fit target architecture, standards, integration patterns and organizational ownership?",[1911,1912,1913],"Data authority","Data owner \u002F domain owner","Which data is authoritative, current, permitted and sufficiently governed?",[1915,1916,1917],"Identity and security","IAM \u002F security architecture","Which identities can access which data and execute which actions?",[1919,1920,1921],"Risk and compliance","Risk \u002F legal \u002F compliance \u002F privacy","Which obligations, prohibited uses, controls and evidence apply to this use case?",[1923,1924,1925],"Supplier dependency","Procurement \u002F vendor management \u002F architecture","What contractual, operational and exit risks arise from the provider?",[1927,1928,1929],"Operations","SRE \u002F operations \u002F platform owner","How is the system monitored, supported, degraded, recovered and changed?",[1931,1932,1933],"Domain acceptance","Business\u002Fdomain specialists","What counts as a correct, safe or useful result in this domain?",{},{"id":622,"data":1936,"type":226,"tunes":1939},{"body":1937,"title":1938,"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":1941,"type":42,"tunes":1943},{"text":1942,"level":247},"A practical enterprise AI architecture model",{},{"id":633,"data":1945,"type":226,"tunes":1948},{"body":1946,"title":1947,"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":1950,"type":292,"tunes":1979},{"content":1951,"stretched":43,"withHeadings":14},[1952,1955,1958,1961,1964,1967,1970,1973,1976],[1953,1954],"Layer","Primary responsibility",[1956,1957],"Business and policy","Approved use cases, accountable owners, risk appetite, prohibited uses, human accountability, business acceptance.",[1959,1960],"Identity and authority","User\u002Fservice\u002Fagent identities, roles, tenant or organizational scope, privileged actions, approval paths.",[1962,1963],"Enterprise data","Systems of record, document sources, data products, provenance, classification, retention, freshness and access.",[1965,1966],"AI platform","Provider\u002Fmodel access, retrieval primitives, agent runtimes, tool brokers, evaluation infrastructure, observability, quotas and secrets.",[1968,1969],"AI solutions","Domain workflows, prompts\u002Finstructions, domain retrieval, business logic, acceptance criteria and user experience.",[1971,1972],"Integration and tools","APIs, enterprise applications, workflows, messaging, file systems, external services and action execution.",[1974,1975],"Risk and governance","Inventory, assessment, compliance evidence, exception management, model\u002Fprovider approval, review and audit.",[1977,1978],"Operations and lifecycle","Deployment, monitoring, incidents, releases, model\u002Fprovider changes, deprecation, rollback and continuity.",{},{"id":671,"data":1981,"type":218,"tunes":1983},{"text":1982},"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":1985,"type":42,"tunes":1987},{"text":1986,"level":247},"Map enterprise AI as data and authority flows, not boxes",{},{"id":681,"data":1989,"type":349,"tunes":2015},{"steps":1990,"title":2014,"orientation":348},[1991,1994,1997,2000,2003,2006,2008,2011],{"label":1992,"description":1993},"1. Business context","The user requests a task under an approved use case with an accountable business owner.",{"label":1995,"description":1996},"2. Identity and authorization","The system resolves user, application, service and tenant or organizational scope before privileged access.",{"label":1998,"description":1999},"3. Authoritative data acquisition","The solution reads or retrieves only sources permitted for the current identity and task.",{"label":2001,"description":2002},"4. AI processing","An approved model\u002Fprovider processes the minimum necessary context under defined routing and data-handling rules.",{"label":2004,"description":2005},"5. Tool or action boundary","Any state-changing action is independently authorized and may require human approval according to consequence.",{"label":700,"description":2007},"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":1669},{},{"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":2331},{"content":2316,"stretched":43,"withHeadings":14},[2317,2319,2321,2323,2325,2327,2329],[1055,2318],"What it contributes to enterprise AI architecture",[1058,2320],"Organization-level AI management system: policies, objectives, processes, responsibility, monitoring and continual improvement.",[1061,2322],"Guidance for integrating AI-specific risk management into organizational activities and functions.",[1064,2324],"Voluntary lifecycle-oriented framework for managing AI risks; organized around Govern, Map, Measure and Manage.",[1067,2326],"Generative AI profile extending AI RMF with generative-AI-specific risks and actions.",[1070,2328],"Binding regulatory obligations in the EU whose applicability depends on role, system type and classification.",[1073,2330],"General architecture-description concepts for expressing concerns, viewpoints, decisions and relationships.",{},{"id":1077,"data":2333,"type":218,"tunes":2335},{"text":2334},"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":2337,"type":42,"tunes":2339},{"text":2338,"level":247},"Common enterprise AI failure modes",{},{"id":1087,"data":2341,"type":292,"tunes":2379},{"content":2342,"stretched":43,"withHeadings":14},[2343,2346,2349,2352,2355,2358,2361,2364,2367,2370,2373,2376],[2344,2345],"Failure mode","Why it fails",[2347,2348],"Every team buys AI independently","Creates shadow providers, duplicated secrets, inconsistent data handling and weak leverage over supplier risk.",[2350,2351],"One central AI team owns every domain decision","Centralizes technical control but loses domain accountability and creates a bottleneck.",[2353,2354],"Vector database becomes the source of truth","Retrieval infrastructure silently replaces authoritative systems and freshness rules.",[2356,2357],"One shared API key for all users and agents","Destroys attribution, least privilege and meaningful auditability.",[2359,2360],"Model change deployed like a minor library patch","Behavioral regressions can reach production without domain evaluation.",[2362,2363],"All prompts and outputs are logged forever","Observability creates an uncontrolled sensitive-data repository.",[2365,2366],"Governance is only documentation","Policies exist without enforcement points, evidence or operational ownership.",[2368,2369],"Compliance is delegated to the provider","The organization's own role, use case, data and operational obligations remain unresolved.",[2371,2372],"Agent can call tools because the model supports tool use","Capability is mistaken for authorization.",[2374,2375],"Platform health equals business correctness","Endpoint uptime and model availability do not prove domain answer quality or acceptable outcomes.",[2377,2378],"No exit strategy for model\u002Fprovider dependency","A pricing, policy, capability or availability change becomes an emergency migration.",{},{"id":1128,"data":2381,"type":42,"tunes":2383},{"text":2382,"level":247},"Common misconceptions",{},{"id":1133,"data":2385,"type":292,"tunes":2414},{"content":2386,"stretched":43,"withHeadings":14},[2387,2390,2393,2396,2399,2402,2405,2408,2411],[2388,2389],"Misconception","Better model",[2391,2392],"“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.",[2394,2395],"“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.",[2397,2398],"“Private AI means everything must be self-hosted.”","Privacy requirements can lead to several architectures; the required control boundary must be stated precisely.",[2400,2401],"“AI governance belongs to legal, architecture belongs to IT.”","The two disciplines must connect because policy obligations need implementable controls and evidence.",[2403,2404],"“One enterprise model is simpler.”","Standardization can help, but workloads can require different modalities, regions, costs, quality levels or control models.",[2406,2407],"“AI risk is model risk.”","Risk can originate in data, prompts, retrieval, identity, tools, interfaces, operations, users and organizational process.",[2409,2410],"“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.",[2412,2413],"“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":2416,"type":42,"tunes":2418},{"text":2417,"level":247},"A practical enterprise AI architecture decision sequence",{},{"id":1170,"data":2420,"type":349,"tunes":2459},{"steps":2421,"title":2458,"orientation":348},[2422,2425,2428,2431,2434,2437,2440,2443,2446,2449,2452,2455],{"label":2423,"description":2424},"1. Define the business capability","State the user, decision or workflow, expected value and accountable owner.",{"label":2426,"description":2427},"2. Classify data and authority","Identify systems of record, personal\u002Fconfidential data, retention, freshness and provenance requirements.",{"label":2429,"description":2430},"3. Define identity and action boundaries","Determine who may read, generate, decide, approve and change external systems.",{"label":2432,"description":2433},"4. Select solution and platform responsibilities","Decide what belongs to the workload, what can be shared and what remains enterprise-owned.",{"label":2435,"description":2436},"5. Assess provider and runtime dependency","Evaluate managed, self-hosted, private, sovereign or hybrid options against real requirements.",{"label":2438,"description":2439},"6. Map risk and regulatory obligations","Determine risk level, organizational controls and applicable legal responsibilities for the concrete system.",{"label":2441,"description":2442},"7. Define measurable acceptance","Create evaluation criteria for quality, reliability, safety, retrieval, cost and operational behavior.",{"label":2444,"description":2445},"8. Record architecture decisions","Preserve rationale, alternatives, trade-offs, dependencies and conditions that would trigger reconsideration.",{"label":2447,"description":2448},"9. Connect architecture to delivery","Translate the design into backlog, milestones, acceptance criteria, technical work and ownership.",{"label":2450,"description":2451},"10. Validate in production-shaped conditions","Test realistic identity, data, failure, latency, provider, tool and recovery scenarios rather than only clean demos.",{"label":2453,"description":2454},"11. Establish operations and change control","Define monitoring, incident response, model\u002Fprovider updates, regression testing, rollback and retirement.",{"label":2456,"description":2457},"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":2461,"type":42,"tunes":2463},{"text":2462,"level":247},"Enterprise AI architecture checklist",{},{"id":1217,"data":2465,"type":292,"tunes":2511},{"content":2466,"stretched":43,"withHeadings":14},[2467,2469,2472,2475,2478,2481,2484,2487,2490,2493,2496,2499,2502,2505,2508],[1221,2468],"Expected evidence",[2470,2471],"What business capability does this AI support?","Named owner, user group, intended decision\u002Fworkflow and acceptance objective.",[2473,2474],"Which source is authoritative for each important fact?","Systems of record, document authority, provenance and freshness rules.",[2476,2477],"Which identities exist?","Human, application, service, agent, tenant\u002Forg and provider identities are distinguishable.",[2479,2480],"What can the AI read?","Authorization-scoped data sources and explicit sensitive-data rules.",[2482,2483],"What can the AI change?","Tool\u002Faction inventory, permission model, approval and rollback path.",[2485,2486],"Which provider\u002Fmodel is used and why?","Architecture decision including quality, security, cost, region, lifecycle and exit considerations.",[2488,2489],"What happens if the provider is unavailable?","Degraded mode, fallback, refusal or continuity plan.",[2491,2492],"How is quality evaluated?","Task-specific datasets, graders, thresholds, regression criteria and validity conditions.",[2494,2495],"What is logged?","Telemetry schema, redaction, access, retention and audit purpose.",[2497,2498],"Who owns AI risk?","Named organizational responsibility connected to the concrete system.",[2500,2501],"What legal classification applies?","Documented assessment based on the current law and the actual use case.",[2503,2504],"How are model\u002Fprompt\u002Fretrieval changes approved?","Versioning, evaluation, architecture\u002Fchange record and rollout gate.",[2506,2507],"Who responds to an AI incident?","Runbook, technical owner, business\u002Fdomain escalation and provider escalation.",[2509,2510],"How is the system retired?","Data cleanup, access revocation, provider exit, evidence retention and dependency removal.",{},{"id":1267,"data":2513,"type":42,"tunes":2515},{"text":2514,"level":247},"Edge cases and limits",{},{"id":1272,"data":2517,"type":218,"tunes":2519},{"text":2518},"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":2521,"type":218,"tunes":2523},{"text":2522},"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":2525,"type":218,"tunes":2527},{"text":2526},"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":2529,"type":218,"tunes":2531},{"text":2530},"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":2533,"type":42,"tunes":2535},{"text":2534,"level":247},"What would change this answer?",{},{"id":1297,"data":2537,"type":218,"tunes":2539},{"text":2538},"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":2541,"type":218,"tunes":2543},{"text":2542},"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":2545,"type":42,"tunes":2547},{"text":2546,"level":247},"Related canonical knowledge",{},{"id":1312,"data":2549,"type":218,"tunes":2551},{"text":2550},"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":2553,"type":218,"tunes":2555},{"text":2554},"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":2557,"type":1328,"tunes":2562},{"url":2558,"title":2559,"excerpt":2560,"ctaLabel":2561},"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":2564,"type":218,"tunes":2566},{"text":2565},"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":2568,"type":1328,"tunes":2573},{"url":2569,"title":2570,"excerpt":2571,"ctaLabel":2572},"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":2575,"type":218,"tunes":2577},{"text":2576},"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":2579,"type":42,"tunes":2581},{"text":2580,"level":247},"Frequently asked questions",{},{"id":1354,"data":2583,"type":1354,"tunes":2610},{"items":2584,"title":2609},[2585,2588,2591,2594,2597,2600,2603,2606],{"id":1358,"answer":2586,"question":2587},"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":2589,"question":2590},"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":2592,"question":2593},"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":2595,"question":2596},"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":2598,"question":2599},"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":2601,"question":2602},"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":2604,"question":2605},"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":2607,"question":2608},"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":2612,"type":42,"tunes":2614},{"text":2613,"level":247},"Glossary",{},{"id":1397,"data":2616,"type":1397,"tunes":2646},{"title":2617,"entries":2618},"Key enterprise AI architecture terms",[2619,2622,2625,2627,2630,2633,2636,2638,2640,2643],{"term":2620,"anchor":1403,"definition":2621},"Enterprise AI architecture","Organization-wide architecture governing how AI systems, platforms, data, identities, providers, risk controls and operations fit together.",{"term":2623,"anchor":1407,"definition":2624},"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":1911,"anchor":1410,"definition":2626},"The rule that identifies which source or system is authoritative for a particular fact, record, state or decision context.",{"term":2628,"anchor":1414,"definition":2629},"System of record","The authoritative system responsible for the official current state of a business record or domain entity.",{"term":2631,"anchor":1418,"definition":2632},"AI inventory","A structured record of AI use cases, owners, models\u002Fproviders, data, tools, risk, evaluation evidence, lifecycle state and related controls.",{"term":2634,"anchor":1422,"definition":2635},"Provider dependency","The technical, contractual and operational reliance created when an AI workload depends on an external model or managed platform.",{"term":2049,"anchor":1426,"definition":2637},"Defined human review, approval, intervention or escalation applied where system consequence, uncertainty or regulation requires it.",{"term":1429,"anchor":1430,"definition":2639},"Operational practices for generative-AI workloads covering model selection, prompts, grounding data, evaluation, deployment, monitoring and lifecycle management.",{"term":2641,"anchor":1434,"definition":2642},"AI risk management","The organizational process of identifying, assessing, treating, monitoring and revising risks associated with AI systems across their lifecycle.",{"term":2644,"anchor":1438,"definition":2645},"Architecture decision","A material design choice together with its context, rationale, alternatives, trade-offs and lifecycle status.",{},{"id":1442,"data":2648,"type":42,"tunes":2649},{"text":1444,"level":247},{},{"id":1447,"data":2651,"type":218,"tunes":2653},{"text":2652},"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":1452,"data":2655,"type":218,"tunes":2657},{"text":2656},"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":1457,"data":2659,"type":218,"tunes":2661},{"text":2660},"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":1462,"data":2663,"type":42,"tunes":2665},{"text":2664,"level":247},"Primary sources and current guidance",{},{"id":1467,"data":2667,"type":218,"tunes":2669},{"text":2668},"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":1472,"data":2671,"type":1479,"tunes":2676},{"link":1474,"meta":2672},{"image":2673,"title":2674,"description":2675},{"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":1482,"data":2678,"type":1479,"tunes":2683},{"link":1484,"meta":2679},{"image":2680,"title":2681,"description":2682},{"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":1491,"data":2685,"type":1479,"tunes":2690},{"link":1493,"meta":2686},{"image":2687,"title":2688,"description":2689},{"url":278},"NIST AI Risk Management Framework","NIST's voluntary lifecycle-oriented framework for managing AI risk. NIST states that AI RMF 1.0 is currently being revised.",{},{"id":1500,"data":2692,"type":1479,"tunes":2697},{"link":1502,"meta":2693},{"image":2694,"title":2695,"description":2696},{"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":1509,"data":2699,"type":1479,"tunes":2704},{"link":1511,"meta":2700},{"image":2701,"title":2702,"description":2703},{"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":1518,"data":2706,"type":1479,"tunes":2711},{"link":1520,"meta":2707},{"image":2708,"title":2709,"description":2710},{"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":1527,"data":2713,"type":1479,"tunes":2718},{"link":1529,"meta":2714},{"image":2715,"title":2716,"description":2717},{"url":278},"Microsoft Azure Well-Architected — AI workloads","Current architecture guidance on AI workloads, including nondeterministic behavior, data, application design and operations.",{},{"id":1536,"data":2720,"type":1479,"tunes":2725},{"link":1538,"meta":2721},{"image":2722,"title":2723,"description":2724},{"url":278},"Microsoft — MLOps and GenAIOps for AI workloads","Current guidance on operational lifecycle, data, model maintenance, deployment, monitoring and continuous evolution.",{},{"id":1545,"data":2727,"type":1479,"tunes":2732},{"link":1547,"meta":2728},{"image":2729,"title":2730,"description":2731},{"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":1554,"data":2734,"type":1479,"tunes":2739},{"link":1556,"meta":2735},{"image":2736,"title":2737,"description":2738},{"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":2743,"excerpt":1563},{"time":212,"blocks":2744,"version":1562},[2745,2748,2751,2754,2757,2760,2763,2766,2769,2772,2788,2791,2794,2797,2800,2810,2813,2816,2819,2822,2825,2828,2831,2834,2837,2840,2843,2846,2849,2852,2855,2858,2861,2864,2867,2870,2873,2876,2879,2882,2885,2888,2891,2894,2897,2900,2903,2906,2909,2912,2915,2918,2921,2924,2927,2930,2933,2936,2939,2942,2957,2960,2963,2966,2979,2982,2985,2997,3000,3003,3019,3022,3035,3038,3041,3044,3047,3050,3053,3056,3069,3072,3083,3086,3089,3092,3104,3107,3110,3113,3116,3119,3122,3125,3128,3131,3134,3137,3140,3143,3155,3158,3161,3164,3167,3178,3181,3184,3200,3203,3216,3219,3235,3238,3257,3260,3263,3266,3269,3272,3275,3278,3281,3284,3287,3290,3293,3296,3299,3302,3305,3317,3320,3334,3337,3340,3343,3346,3349,3352,3357,3362,3367,3372,3377,3382,3387,3392,3397],{"id":215,"data":2746,"type":218,"tunes":2747},{"text":217},{},{"id":221,"data":2749,"type":226,"tunes":2750},{"body":223,"title":224,"variant":225},{},{"id":229,"data":2752,"type":226,"tunes":2753},{"body":231,"title":232,"variant":233},{},{"id":236,"data":2755,"type":226,"tunes":2756},{"body":238,"title":239,"variant":240},{},{"id":243,"data":2758,"type":248,"tunes":2759},{"title":245,"maxLevel":246,"minLevel":247},{},{"id":251,"data":2761,"type":42,"tunes":2762},{"text":253,"level":247},{},{"id":256,"data":2764,"type":218,"tunes":2765},{"text":258},{},{"id":261,"data":2767,"type":218,"tunes":2768},{"text":263},{},{"id":266,"data":2770,"type":218,"tunes":2771},{"text":268},{},{"id":271,"data":2773,"type":303,"tunes":2787},{"rows":2774,"title":291,"layout":292,"columns":2783},[2775,2777,2779,2781],{"id":275,"label":276,"values":2776},[278,278,278],{"id":280,"label":281,"values":2778},[278,278,278],{"id":284,"label":285,"values":2780},[278,278,278],{"id":288,"label":289,"values":2782},[278,278,278],[2784,2785,2786],{"id":295,"label":296},{"id":298,"label":299},{"id":301,"label":302},{},{"id":306,"data":2789,"type":42,"tunes":2790},{"text":308,"level":247},{},{"id":311,"data":2792,"type":218,"tunes":2793},{"text":313},{},{"id":316,"data":2795,"type":218,"tunes":2796},{"text":318},{},{"id":321,"data":2798,"type":218,"tunes":2799},{"text":323},{},{"id":326,"data":2801,"type":349,"tunes":2809},{"steps":2802,"title":347,"orientation":348},[2803,2804,2805,2806,2807,2808],{"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":2811,"type":42,"tunes":2812},{"text":354,"level":247},{},{"id":357,"data":2814,"type":218,"tunes":2815},{"text":359},{},{"id":362,"data":2817,"type":218,"tunes":2818},{"text":364},{},{"id":367,"data":2820,"type":42,"tunes":2821},{"text":369,"level":247},{},{"id":372,"data":2823,"type":42,"tunes":2824},{"text":374,"level":246},{},{"id":377,"data":2826,"type":218,"tunes":2827},{"text":379},{},{"id":382,"data":2829,"type":218,"tunes":2830},{"text":384},{},{"id":387,"data":2832,"type":42,"tunes":2833},{"text":389,"level":246},{},{"id":392,"data":2835,"type":218,"tunes":2836},{"text":394},{},{"id":397,"data":2838,"type":218,"tunes":2839},{"text":399},{},{"id":402,"data":2841,"type":218,"tunes":2842},{"text":404},{},{"id":407,"data":2844,"type":226,"tunes":2845},{"body":409,"title":410,"variant":288},{},{"id":413,"data":2847,"type":42,"tunes":2848},{"text":415,"level":246},{},{"id":418,"data":2850,"type":218,"tunes":2851},{"text":420},{},{"id":423,"data":2853,"type":218,"tunes":2854},{"text":425},{},{"id":428,"data":2856,"type":218,"tunes":2857},{"text":430},{},{"id":433,"data":2859,"type":42,"tunes":2860},{"text":435,"level":246},{},{"id":438,"data":2862,"type":218,"tunes":2863},{"text":440},{},{"id":443,"data":2865,"type":218,"tunes":2866},{"text":445},{},{"id":448,"data":2868,"type":42,"tunes":2869},{"text":450,"level":246},{},{"id":453,"data":2871,"type":218,"tunes":2872},{"text":455},{},{"id":458,"data":2874,"type":218,"tunes":2875},{"text":460},{},{"id":463,"data":2877,"type":218,"tunes":2878},{"text":465},{},{"id":468,"data":2880,"type":42,"tunes":2881},{"text":470,"level":246},{},{"id":473,"data":2883,"type":218,"tunes":2884},{"text":475},{},{"id":478,"data":2886,"type":218,"tunes":2887},{"text":480},{},{"id":483,"data":2889,"type":218,"tunes":2890},{"text":485},{},{"id":488,"data":2892,"type":42,"tunes":2893},{"text":490,"level":246},{},{"id":493,"data":2895,"type":218,"tunes":2896},{"text":495},{},{"id":498,"data":2898,"type":218,"tunes":2899},{"text":500},{},{"id":503,"data":2901,"type":42,"tunes":2902},{"text":505,"level":246},{},{"id":508,"data":2904,"type":218,"tunes":2905},{"text":510},{},{"id":513,"data":2907,"type":218,"tunes":2908},{"text":515},{},{"id":518,"data":2910,"type":218,"tunes":2911},{"text":520},{},{"id":523,"data":2913,"type":42,"tunes":2914},{"text":525,"level":246},{},{"id":528,"data":2916,"type":218,"tunes":2917},{"text":530},{},{"id":533,"data":2919,"type":218,"tunes":2920},{"text":535},{},{"id":538,"data":2922,"type":42,"tunes":2923},{"text":540,"level":246},{},{"id":543,"data":2925,"type":218,"tunes":2926},{"text":545},{},{"id":548,"data":2928,"type":218,"tunes":2929},{"text":550},{},{"id":553,"data":2931,"type":42,"tunes":2932},{"text":555,"level":246},{},{"id":558,"data":2934,"type":218,"tunes":2935},{"text":560},{},{"id":563,"data":2937,"type":218,"tunes":2938},{"text":565},{},{"id":568,"data":2940,"type":42,"tunes":2941},{"text":570,"level":247},{},{"id":573,"data":2943,"type":292,"tunes":2956},{"content":2944,"stretched":43,"withHeadings":14},[2945,2946,2947,2948,2949,2950,2951,2952,2953,2954,2955],[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":2958,"type":226,"tunes":2959},{"body":624,"title":625,"variant":233},{},{"id":628,"data":2961,"type":42,"tunes":2962},{"text":630,"level":247},{},{"id":633,"data":2964,"type":226,"tunes":2965},{"body":635,"title":636,"variant":240},{},{"id":639,"data":2967,"type":292,"tunes":2978},{"content":2968,"stretched":43,"withHeadings":14},[2969,2970,2971,2972,2973,2974,2975,2976,2977],[643,644],[646,647],[649,650],[652,653],[655,656],[658,659],[661,662],[664,665],[667,668],{},{"id":671,"data":2980,"type":218,"tunes":2981},{"text":673},{},{"id":676,"data":2983,"type":42,"tunes":2984},{"text":678,"level":247},{},{"id":681,"data":2986,"type":349,"tunes":2996},{"steps":2987,"title":708,"orientation":348},[2988,2989,2990,2991,2992,2993,2994,2995],{"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":2998,"type":42,"tunes":2999},{"text":713,"level":247},{},{"id":716,"data":3001,"type":218,"tunes":3002},{"text":718},{},{"id":721,"data":3004,"type":292,"tunes":3018},{"content":3005,"stretched":43,"withHeadings":14},[3006,3007,3008,3009,3010,3011,3012,3013,3014,3015,3016,3017],[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":3020,"type":42,"tunes":3021},{"text":764,"level":247},{},{"id":767,"data":3023,"type":303,"tunes":3034},{"rows":3024,"title":782,"layout":292,"columns":3031},[3025,3027,3029],{"id":771,"label":772,"values":3026},[278,278],{"id":775,"label":776,"values":3028},[278,278],{"id":779,"label":780,"values":3030},[278,278],[3032,3033],{"id":785,"label":786},{"id":788,"label":302},{},{"id":791,"data":3036,"type":42,"tunes":3037},{"text":793,"level":247},{},{"id":796,"data":3039,"type":218,"tunes":3040},{"text":798},{},{"id":801,"data":3042,"type":218,"tunes":3043},{"text":803},{},{"id":806,"data":3045,"type":218,"tunes":3046},{"text":808},{},{"id":811,"data":3048,"type":226,"tunes":3049},{"body":813,"title":814,"variant":240},{},{"id":817,"data":3051,"type":42,"tunes":3052},{"text":819,"level":247},{},{"id":822,"data":3054,"type":218,"tunes":3055},{"text":824},{},{"id":827,"data":3057,"type":292,"tunes":3068},{"content":3058,"stretched":43,"withHeadings":14},[3059,3060,3061,3062,3063,3064,3065,3066,3067],[831,832],[834,835],[837,838],[840,841],[843,844],[846,847],[849,850],[852,853],[855,856],{},{"id":859,"data":3070,"type":42,"tunes":3071},{"text":861,"level":247},{},{"id":864,"data":3073,"type":292,"tunes":3082},{"content":3074,"stretched":43,"withHeadings":14},[3075,3076,3077,3078,3079,3080,3081],[868,869],[871,872],[874,875],[877,878],[880,881],[883,884],[886,887],{},{"id":890,"data":3084,"type":218,"tunes":3085},{"text":892},{},{"id":895,"data":3087,"type":42,"tunes":3088},{"text":897,"level":247},{},{"id":900,"data":3090,"type":218,"tunes":3091},{"text":902},{},{"id":905,"data":3093,"type":349,"tunes":3103},{"steps":3094,"title":932,"orientation":348},[3095,3096,3097,3098,3099,3100,3101,3102],{"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":3105,"type":42,"tunes":3106},{"text":937,"level":247},{},{"id":940,"data":3108,"type":218,"tunes":3109},{"text":942},{},{"id":945,"data":3111,"type":218,"tunes":3112},{"text":947},{},{"id":950,"data":3114,"type":226,"tunes":3115},{"body":952,"title":953,"variant":288},{},{"id":956,"data":3117,"type":42,"tunes":3118},{"text":958,"level":247},{},{"id":961,"data":3120,"type":218,"tunes":3121},{"text":963},{},{"id":966,"data":3123,"type":218,"tunes":3124},{"text":968},{},{"id":971,"data":3126,"type":42,"tunes":3127},{"text":973,"level":247},{},{"id":976,"data":3129,"type":226,"tunes":3130},{"body":978,"title":979,"variant":240},{},{"id":982,"data":3132,"type":218,"tunes":3133},{"text":984},{},{"id":987,"data":3135,"type":218,"tunes":3136},{"text":989},{},{"id":992,"data":3138,"type":218,"tunes":3139},{"text":994},{},{"id":997,"data":3141,"type":218,"tunes":3142},{"text":999},{},{"id":1002,"data":3144,"type":292,"tunes":3154},{"content":3145,"stretched":43,"withHeadings":14},[3146,3147,3148,3149,3150,3151,3152,3153],[1006,1007],[1009,1010],[1012,1013],[1015,1016],[1018,1019],[1021,1022],[1024,1025],[1027,1028],{},{"id":1031,"data":3156,"type":42,"tunes":3157},{"text":1033,"level":247},{},{"id":1036,"data":3159,"type":218,"tunes":3160},{"text":1038},{},{"id":1041,"data":3162,"type":218,"tunes":3163},{"text":1043},{},{"id":1046,"data":3165,"type":42,"tunes":3166},{"text":1048,"level":247},{},{"id":1051,"data":3168,"type":292,"tunes":3177},{"content":3169,"stretched":43,"withHeadings":14},[3170,3171,3172,3173,3174,3175,3176],[1055,1056],[1058,1059],[1061,1062],[1064,1065],[1067,1068],[1070,1071],[1073,1074],{},{"id":1077,"data":3179,"type":218,"tunes":3180},{"text":1079},{},{"id":1082,"data":3182,"type":42,"tunes":3183},{"text":1084,"level":247},{},{"id":1087,"data":3185,"type":292,"tunes":3199},{"content":3186,"stretched":43,"withHeadings":14},[3187,3188,3189,3190,3191,3192,3193,3194,3195,3196,3197,3198],[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":3201,"type":42,"tunes":3202},{"text":1130,"level":247},{},{"id":1133,"data":3204,"type":292,"tunes":3215},{"content":3205,"stretched":43,"withHeadings":14},[3206,3207,3208,3209,3210,3211,3212,3213,3214],[1137,1138],[1140,1141],[1143,1144],[1146,1147],[1149,1150],[1152,1153],[1155,1156],[1158,1159],[1161,1162],{},{"id":1165,"data":3217,"type":42,"tunes":3218},{"text":1167,"level":247},{},{"id":1170,"data":3220,"type":349,"tunes":3234},{"steps":3221,"title":1209,"orientation":348},[3222,3223,3224,3225,3226,3227,3228,3229,3230,3231,3232,3233],{"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":3236,"type":42,"tunes":3237},{"text":1214,"level":247},{},{"id":1217,"data":3239,"type":292,"tunes":3256},{"content":3240,"stretched":43,"withHeadings":14},[3241,3242,3243,3244,3245,3246,3247,3248,3249,3250,3251,3252,3253,3254,3255],[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":3258,"type":42,"tunes":3259},{"text":1269,"level":247},{},{"id":1272,"data":3261,"type":218,"tunes":3262},{"text":1274},{},{"id":1277,"data":3264,"type":218,"tunes":3265},{"text":1279},{},{"id":1282,"data":3267,"type":218,"tunes":3268},{"text":1284},{},{"id":1287,"data":3270,"type":218,"tunes":3271},{"text":1289},{},{"id":1292,"data":3273,"type":42,"tunes":3274},{"text":1294,"level":247},{},{"id":1297,"data":3276,"type":218,"tunes":3277},{"text":1299},{},{"id":1302,"data":3279,"type":218,"tunes":3280},{"text":1304},{},{"id":1307,"data":3282,"type":42,"tunes":3283},{"text":1309,"level":247},{},{"id":1312,"data":3285,"type":218,"tunes":3286},{"text":1314},{},{"id":1317,"data":3288,"type":218,"tunes":3289},{"text":1319},{},{"id":1322,"data":3291,"type":1328,"tunes":3292},{"url":1324,"title":1325,"excerpt":1326,"ctaLabel":1327},{},{"id":1331,"data":3294,"type":218,"tunes":3295},{"text":1333},{},{"id":1336,"data":3297,"type":1328,"tunes":3298},{"url":1338,"title":1339,"excerpt":1340,"ctaLabel":1341},{},{"id":1344,"data":3300,"type":218,"tunes":3301},{"text":1346},{},{"id":1349,"data":3303,"type":42,"tunes":3304},{"text":1351,"level":247},{},{"id":1354,"data":3306,"type":1354,"tunes":3316},{"items":3307,"title":1389},[3308,3309,3310,3311,3312,3313,3314,3315],{"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":3318,"type":42,"tunes":3319},{"text":1394,"level":247},{},{"id":1397,"data":3321,"type":1397,"tunes":3333},{"title":1399,"entries":3322},[3323,3324,3325,3326,3327,3328,3329,3330,3331,3332],{"term":1402,"anchor":1403,"definition":1404},{"term":1406,"anchor":1407,"definition":1408},{"term":597,"anchor":1410,"definition":1411},{"term":1413,"anchor":1414,"definition":1415},{"term":1417,"anchor":1418,"definition":1419},{"term":1421,"anchor":1422,"definition":1423},{"term":1425,"anchor":1426,"definition":1427},{"term":1429,"anchor":1430,"definition":1431},{"term":1433,"anchor":1434,"definition":1435},{"term":1437,"anchor":1438,"definition":1439},{},{"id":1442,"data":3335,"type":42,"tunes":3336},{"text":1444,"level":247},{},{"id":1447,"data":3338,"type":218,"tunes":3339},{"text":1449},{},{"id":1452,"data":3341,"type":218,"tunes":3342},{"text":1454},{},{"id":1457,"data":3344,"type":218,"tunes":3345},{"text":1459},{},{"id":1462,"data":3347,"type":42,"tunes":3348},{"text":1464,"level":247},{},{"id":1467,"data":3350,"type":218,"tunes":3351},{"text":1469},{},{"id":1472,"data":3353,"type":1479,"tunes":3356},{"link":1474,"meta":3354},{"image":3355,"title":1477,"description":1478},{"url":278},{},{"id":1482,"data":3358,"type":1479,"tunes":3361},{"link":1484,"meta":3359},{"image":3360,"title":1487,"description":1488},{"url":278},{},{"id":1491,"data":3363,"type":1479,"tunes":3366},{"link":1493,"meta":3364},{"image":3365,"title":1496,"description":1497},{"url":278},{},{"id":1500,"data":3368,"type":1479,"tunes":3371},{"link":1502,"meta":3369},{"image":3370,"title":1505,"description":1506},{"url":278},{},{"id":1509,"data":3373,"type":1479,"tunes":3376},{"link":1511,"meta":3374},{"image":3375,"title":1514,"description":1515},{"url":278},{},{"id":1518,"data":3378,"type":1479,"tunes":3381},{"link":1520,"meta":3379},{"image":3380,"title":1523,"description":1524},{"url":278},{},{"id":1527,"data":3383,"type":1479,"tunes":3386},{"link":1529,"meta":3384},{"image":3385,"title":1532,"description":1533},{"url":278},{},{"id":1536,"data":3388,"type":1479,"tunes":3391},{"link":1538,"meta":3389},{"image":3390,"title":1541,"description":1542},{"url":278},{},{"id":1545,"data":3393,"type":1479,"tunes":3396},{"link":1547,"meta":3394},{"image":3395,"title":1550,"description":1551},{"url":278},{},{"id":1554,"data":3398,"type":1479,"tunes":3401},{"link":1556,"meta":3399},{"image":3400,"title":1559,"description":1560},{"url":278},{},"Post erfolgreich abgerufen",{"items":3404,"source":3489,"manualIds":3490,"manualMatchedIds":3491},[3405,3412,3419,3426,3433,3440,3447,3454,3461,3468,3475,3482],{"id":3406,"slug":3407,"title":3408,"excerpt":3409,"featuredImage":3410,"publishedAt":3411},"476","mcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained","MCP vs A2A vs UCP vs AP2 vs A2UI : La pile de protocoles d'agent expliquée","MCP, A2A, UCP, AP2 et A2UI sont souvent présentés comme des standards d'agents concurrents. Ils résolvent principalement des problèmes d'interopérabilité différents. Ce guide associe chaque protocole à la frontière qu'il standardise réellement—et montre comment ils peuvent fonctionner ensemble dans un seul système de production.","\u002Fuploads\u002F2026\u002F09\u002Fmcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained-1790352625869-2ezle0.webp","2026-09-25T12:09:00.000Z",{"id":3413,"slug":3414,"title":3415,"excerpt":3416,"featuredImage":3417,"publishedAt":3418},"494","air-gapped-ai-how-ai-systems-work-without-internet-or-cloud-access","IA en environnement isolé : comment les systèmes d’IA fonctionnent sans accès à Internet ni au cloud","L'IA en environnement isolé exécute des modèles, du RAG et des applications d'IA à l'intérieur d'un domaine de sécurité isolé, sans dépendance à Internet ni au cloud. Découvrez comment les modèles, les données, les mises à jour et les outils fonctionnent hors ligne.","\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":3420,"slug":3421,"title":3422,"excerpt":3423,"featuredImage":3424,"publishedAt":3425},"487","vector-databases-embeddings-and-reranking-three-different-parts-of-retrieval","Bases de données vectorielles, plongements et reclassement : trois parties distinctes de la recherche","Les embeddings représentent le sens, les bases de données vectorielles récupèrent des candidats, et les rerankers affinent les résultats. Découvrez comment ces trois couches de récupération diffèrent et fonctionnent ensemble dans le RAG.","\u002Fuploads\u002F2026\u002F10\u002Fvector-databases-embeddings-and-reranking-three-different-parts-of-retrieval-1791480129884-9dtasz.webp","2026-10-08T11:21:00.000Z",{"id":3427,"slug":3428,"title":3429,"excerpt":3430,"featuredImage":3431,"publishedAt":3432},"479","where-does-an-llm-get-its-data-rag-data-sources-in-python","D'où un LLM tire-t-il ses données ? Sources de données RAG en Python","Un LLM ne connaît pas magiquement vos fichiers, bases de données ou API. Cette suite pratique de la série sur le RAG montre, avec du Python simple, comment des données externes deviennent des preuves récupérables : des fichiers texte et du SQL à la recherche en texte intégral, aux embeddings, à l'assemblage du contexte et à l'appel final au LLM.","\u002Fuploads\u002F2026\u002F09\u002Fwhere-does-an-llm-get-its-data-rag-data-sources-in-python-1790517200521-nfsi5i.webp","2026-09-27T05:51:00.000Z",{"id":3434,"slug":3435,"title":3436,"excerpt":3437,"featuredImage":3438,"publishedAt":3439},"470","what-should-an-ai-agent-remember-forget-recompute-or-retrieve-again","Que devrait mémoriser, oublier, recalculer ou récupérer à nouveau un agent IA ?","Les agents à exécution longue ne devraient pas tout retenir. Cet article propose un modèle de cycle de vie pratique pour décider de ce qui a sa place dans la mémoire durable, de ce qui devrait être récupéré à nouveau, de ce qu'il est plus sûr de recalculer et de ce qui devrait expirer ou être remplacé.","\u002Fuploads\u002F2026\u002F09\u002Fwhat-should-an-ai-agent-remember-forget-recompute-or-retrieve-again-1790351131087-iehz28.webp","2026-09-25T09:43:00.000Z",{"id":3441,"slug":3442,"title":3443,"excerpt":3444,"featuredImage":3445,"publishedAt":3446},"467","the-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers","La frontière de validité des réponses : la couche manquante entre la pertinence et les réponses fiables de l'IA","Une source peut être pertinente, faisant autorité et pourtant être erronée pour la question posée. La couche manquante est l'applicabilité : les conditions dans lesquelles une réponse est valable, et les changements qui obligent à la reconsidérer. Cet article présente la Frontière de Validité de la Réponse comme un modèle de conception de source pour les humains, la recherche par IA et les systèmes RAG.","\u002Fuploads\u002F2026\u002F09\u002Fthe-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers-1790272901306-1g5jly.webp","2026-09-24T11:59:00.000Z",{"id":3448,"slug":3449,"title":3450,"excerpt":3451,"featuredImage":3452,"publishedAt":3453},"490","rbac-vs-tenant-isolation-two-different-security-boundaries","RBAC vs isolation des locataires : deux frontières de sécurité différentes","Le RBAC contrôle ce qu’un utilisateur peut faire ; l’isolation des locataires contrôle à quelles ressources de locataire cette action peut accéder. Découvrez pourquoi la sécurité SaaS multi-locataires nécessite ces deux frontières.","\u002Fuploads\u002F2026\u002F10\u002Frbac-vs-tenant-isolation-two-different-security-boundaries-1791485111528-qqtzby.webp","2026-10-08T14:43:00.000Z",{"id":3455,"slug":3456,"title":3457,"excerpt":3458,"featuredImage":3459,"publishedAt":3460},"468","ai-agent-memory-is-not-rag-how-to-separate-memory-retrieval-state-and-context","La mémoire des agents IA n'est pas le RAG : comment séparer la mémoire, la récupération, l'état et le contexte","La mémoire des agents, le RAG, l'état et le contexte sont souvent utilisés comme s'ils étaient interchangeables. Ils ne le sont pas. Ce modèle d'architecture pratique sépare les quatre couches, montre où chacune se situe et explique ce qui dysfonctionne lorsque les systèmes les fusionnent en une seule.","\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":3462,"slug":3463,"title":3464,"excerpt":3465,"featuredImage":3466,"publishedAt":3467},"489","agentic-ai-explained-when-an-ai-system-can-plan-use-tools-and-act","L'IA agentique expliquée : quand un système d'IA peut planifier, utiliser des outils et agir","L'IA agentique utilise des modèles au sein de boucles d'exécution multi-étapes où ils peuvent choisir des outils, observer les résultats, mettre à jour l'état et adapter leur action suivante dans des limites explicites d'exécution et de permissions.","\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":3469,"slug":3470,"title":3471,"excerpt":3472,"featuredImage":3473,"publishedAt":3474},"483","what-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","Qu'est-ce qu'un architecte de solutions IA ? Limites du système, responsabilités et compromis","Un architecte de solutions d'IA transforme les exigences métier en un système d'IA prêt pour la production, couvrant les données, les modèles, les outils, la sécurité, l'exécution, l'évaluation et les opérations.","\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":3476,"slug":3477,"title":3478,"excerpt":3479,"featuredImage":3480,"publishedAt":3481},"492","mcp-explained-what-it-connects-what-it-does-not-do-and-where-it-fits","MCP expliqué : ce qu'il connecte, ce qu'il ne fait pas et où il s'intègre","Le protocole de contexte de modèle connecte les applications d’IA à des outils, des ressources et des invites externes par le biais d’une frontière standard client-serveur. Découvrez ce que fait le MCP, ce qu’il ne fait pas et où il s’intègre dans l’architecture des agents.","\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",{"id":3483,"slug":3484,"title":3485,"excerpt":3486,"featuredImage":3487,"publishedAt":3488},"486","source-of-truth-in-ai-systems-where-reliable-knowledge-actually-comes-from","Source de vérité dans les systèmes d’IA : d’où provient réellement une connaissance fiable","Une source de vérité définit quelle source fait autorité pour un fait ou un état spécifique. Découvrez en quoi elle diffère du RAG, de la provenance, de la mémoire, du contexte, des bases de données vectorielles et des systèmes d'enregistrement.","\u002Fuploads\u002F2026\u002F10\u002Fsource-of-truth-in-ai-systems-where-reliable-knowledge-actually-comes-from-1791479103235-6bq9em.webp","2026-10-08T13:02:00.000Z","fallback",[],[]]