[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:fr":3,"public-menus:all":38,"post:what-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs:fr":205,"related:post:what-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs:fr:1":2141},{"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":2140},{"id":207,"title":208,"slug":209,"content":210,"contentJson":211,"excerpt":1074,"featuredImage":1075,"featuredImageAlt":1076,"featuredImageCaption":10,"featuredImageTitle":10,"featuredImageCopyright":10,"featuredImageAuthor":10,"featuredImageSourceUrl":10,"featuredImageLicense":10,"featuredImageIsAiGenerated":43,"status":1077,"publishedAt":1078,"createdAt":1079,"updatedAt":1080,"seoLocalePaths":1081,"categories":1090,"author":1107,"translations":1112},"483","Qu'est-ce qu'un architecte de solutions IA ? Limites du système, responsabilités et compromis","what-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","\u003Cp>Un \u003Cstrong>architecte de solutions IA\u003C\u002Fstrong> traduit un besoin métier ou produit en l'architecture d'une solution concrète activée par l'IA. Le rôle définit les frontières du système et les choix significatifs concernant la logique applicative, les données faisant autorité, la récupération et le contexte, les modèles et fournisseurs, les outils ou agents, l'identité et les permissions, la sécurité, l'exécution et le déploiement, l'observabilité, l'évaluation, le coût et le comportement opérationnel. Il ne s'agit pas simplement de sélection de modèle ou d'ingénierie de prompt : la responsabilité architecturale consiste à rendre l'ensemble de la solution implémentable, gouvernable, testable et exploitable.\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>Un architecte de solutions IA conçoit la solution complète activée par l'IA, pas seulement le modèle d'IA.\u003C\u002Fstrong> Le rôle relie les exigences et les exigences non fonctionnelles aux décisions d'architecture, compose les couches applicatives\u002Fdonnées\u002Fmodèles\u002Foutils\u002Fexécution nécessaires, rend explicites les frontières de confiance et de défaillance, et définit comment le système implémenté sera validé et exploité.\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 terminologique\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>Architecte de solutions IA est un libellé de rôle pratique, pas un titre de poste universellement normalisé.\u003C\u002Fstrong> ISO\u002FIEC\u002FIEEE 42010:2022 normalise les concepts pour les descriptions d'architecture ; il ne définit pas ce rôle professionnel. Les organisations peuvent répartir les responsabilités entre plusieurs personnes. Dans cet article, le terme désigne la responsabilité architecturale pour une solution ou une charge de travail concrète activée par l'IA.\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 d'architecture présentés ici sont intentionnellement neutres vis-à-vis des fournisseurs, tandis que les recommandations actuelles des fournisseurs sont utilisées comme preuves de mise en œuvre. NIST AI RMF 1.0 est actuellement en cours de révision ; NIST AI 600-1 reste le profil publié pour l'IA générative. Les recommandations de Microsoft et AWS citées ci-dessous reflètent les préoccupations actuelles de production telles que l'identité, les frontières des données, l'abstraction des modèles, la sécurité, l'observabilité, l'évaluation, la fiabilité et le coût.\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\">Que conçoit réellement un architecte de solutions IA ?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-10\" class=\"editorjs-toc__link\">L'exemple le plus simple\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-14\" class=\"editorjs-toc__link\">Là où l'exemple simple s'arrête\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-17\" class=\"editorjs-toc__link\">Carte des responsabilités architecturales\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. Transformer le besoin produit en exigences architecturales\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-23\" class=\"editorjs-toc__link\">2. Concevoir des données faisant autorité, la récupération et le contexte\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-26\" class=\"editorjs-toc__link\">3. Traiter les modèles et les fournisseurs comme des dépendances, pas comme l'ensemble du système\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-29\" class=\"editorjs-toc__link\">4. Architecturer les outils, les actions et les frontières des agents\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-32\" class=\"editorjs-toc__link\">5. Rendre explicites les frontières de confiance et les permissions\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-35\" class=\"editorjs-toc__link\">6. Décider où le système s'exécute réellement\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-38\" class=\"editorjs-toc__link\">7. Définir l'évaluation, l'observabilité et l'acceptation opérationnelle\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-41\" class=\"editorjs-toc__link\">Que devrait produire le rôle ?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-44\" class=\"editorjs-toc__link\">Le travail consiste principalement en compromis, pas en sélection de « meilleures pratiques »\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-47\" class=\"editorjs-toc__link\">En quoi cela diffère-t-il des rôles adjacents ?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-51\" class=\"editorjs-toc__link\">Preuves de mise en œuvre : comment ces frontières apparaissent dans mon propre travail\u003C\u002Fa>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-1\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-53\" class=\"editorjs-toc__link\">SenseFlow : besoin → exigences → architecture → validation\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-57\" class=\"editorjs-toc__link\">Aaasaasa AI Client : séparer les concepts avant de les intégrer\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-61\" class=\"editorjs-toc__link\">Comment les frameworks d'architecture actuels soutiennent ce périmètre élargi\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-65\" class=\"editorjs-toc__link\">Idées fausses courantes\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-67\" class=\"editorjs-toc__link\">Modes de défaillance qu'un Architecte de Solution IA doit prévenir\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-69\" class=\"editorjs-toc__link\">Une séquence de décision pratique\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-71\" class=\"editorjs-toc__link\">Cas limites et limites du rôle\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-75\" class=\"editorjs-toc__link\">Qu'est-ce qui changerait cette réponse ?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-78\" class=\"editorjs-toc__link\">Liste de contrôle de l'AI Solution Architect\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-80\" class=\"editorjs-toc__link\">Conclusion\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-85\" class=\"editorjs-toc__link\">Connaissances canoniques associées\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-88\" class=\"editorjs-toc__link\">Sources primaires et recommandations d'architecture actuelles\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fnav>\n\u003Ch2 id=\"section-6\">Que conçoit réellement un architecte de solutions IA ?\u003C\u002Fh2>\n\u003Cp>L'objet du travail est la \u003Cstrong>solution\u003C\u002Fstrong> : le système socio-technique complet qui transforme un besoin en un comportement utile et maîtrisé. Un modèle peut être central pour ce système, mais il ne reste qu'une dépendance parmi d'autres. Le même modèle peut participer à un assistant de recherche interne sûr, à un agent dangereusement sur-privilégié, à une fonctionnalité client à faible latence ou à un prototype coûteux qui ne peut pas être exploité économiquement. L'architecture détermine ces différences.\u003C\u002Fp>\n\u003Cp>Une frontière utile est donc : \u003Cstrong>résultat métier → exigences → responsabilités du système → décisions d'architecture → mise en œuvre → validation → exploitation\u003C\u002Fstrong>. L'architecte de solutions IA travaille sur toute cette chaîne en collaborant avec les spécialistes produit, ingénierie, données, sécurité, infrastructure, gouvernance et domaine.\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">La solution est plus large que le modèle\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\">Question centrée sur le modèle\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\">Question d'architecture de solution\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\">Capacité\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Which model can generate or reason well enough?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Which combination of model, data, application logic, retrieval, tools and controls produces the required behavior?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Données\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">What context can fit in the prompt?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">What is authoritative, who may access it, how is it retrieved, versioned, filtered and cited?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Sécurité\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Does the provider offer security features?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">What are the trust boundaries, identities, permissions, secrets, data flows and failure containment mechanisms?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Exploitation\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">What is the token latency?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">How is the complete workload deployed, observed, evaluated, recovered, versioned and cost-controlled?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Changement\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Can we switch models?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Which dependencies are abstracted, what changes require an ADR, and how do we validate that a replacement still meets requirements?\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-10\">L'exemple le plus simple\u003C\u002Fh2>\n\u003Cp>Imaginez qu'une entreprise souhaite un assistant interne qui réponde aux questions des techniciens à partir de manuels de maintenance et de procédures d'exploitation. La fonctionnalité visible semble simple : saisir une question et recevoir une réponse avec des sources.\u003C\u002Fp>\n\u003Cp>La question d'architecture est bien plus vaste. Quels documents font autorité ? Comment les utilisateurs sont-ils authentifiés ? La récupération doit-elle respecter les permissions de département ou de site ? La réponse est-elle autorisée à utiliser uniquement les preuves récupérées ? Quel modèle est acceptable pour la classification des données ? Un fournisseur cloud peut-il recevoir le contenu ? Que se passe-t-il lorsque la récupération ne trouve rien ? Comment les citations sont-elles produites ? Comment la qualité des réponses est-elle évaluée ? Quelles latence et coût sont acceptables ? Qui peut voir les journaux, et que peut-on y stocker ?\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Du besoin à une solution IA exploitable\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 le résultat\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Clarifier l'utilisateur, la valeur métier, la frontière de la tâche et ce que signifie une réponse ou une action réussie.\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. Recueillir les exigences\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Rendre explicites les exigences fonctionnelles, les exigences non fonctionnelles, les contraintes, les règles de données, la tolérance au risque et les critères d'acceptation.\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. Établir les frontières\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Identifier les utilisateurs, les identités, les applications, les données faisant autorité, les dépendances aux modèles\u002Ffournisseurs, les outils, les systèmes externes et les zones de confiance.\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. Concevoir l'architecture\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Choisir les patrons de données\u002Frécupération, de modèle, d'orchestration, d'outils, de permissions, d'exécution, de déploiement, de repli et d'observabilité.\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. Consigner les décisions significatives\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Préserver les choix architecturaux, les alternatives, les compromis et les conséquences afin que les changements ultérieurs restent compréhensibles.\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. Mettre en œuvre et intégrer\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Transformer l'architecture en code applicatif, API, politiques, infrastructure, flux de travail et contrôles opérationnels.\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. Valider et exploiter\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Tester la qualité, la sécurité, la fiabilité, le coût et les résultats utilisateur ; surveiller la charge de travail réelle et réinjecter les preuves dans les décisions.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-14\">Là où l'exemple simple s'arrête\u003C\u002Fh2>\n\u003Cp>Une preuve de concept peut souvent se passer d'une architecture dont la production ne peut pas se passer. Un développeur peut coder en dur un seul fournisseur, utiliser une clé API partagée, placer tous les documents dans un seul index, exécuter la récupération sans filtrage par contexte utilisateur, journaliser les prompts mot pour mot et juger la qualité manuellement. Cela peut démontrer la faisabilité, mais cela n'établit pas une architecture de production.\u003C\u002Fp>\n\u003Cp>La production introduit des contraintes qui interagissent : isolation des locataires ou des utilisateurs, confidentialité, résidence des données, débit, latence, coût, quotas des fournisseurs, comportement de repli, auditabilité, changements de version des modèles, qualité de la récupération, permissions des outils, réponse aux incidents et cycle de vie du déploiement. Le travail de l'architecte n'est pas de maximiser toutes les qualités à la fois ; il est de rendre les compromis explicites et de concevoir une solution qui satisfait l'ensemble réel des priorités.\u003C\u002Fp>\n\u003Ch2 id=\"section-17\">Carte des responsabilités architecturales\u003C\u002Fh2>\n\u003Cp>La répartition exacte varie selon l'organisation, mais la carte suivante capture les responsabilités récurrentes de l'architecture IA au niveau de la solution. L'architecte n'implémente pas nécessairement lui-même chaque couche ; la responsabilité consiste à faire en sorte que les couches s'articulent de manière cohérente et à maintenir la traçabilité des décisions critiques.\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\">Domaine d'architecture\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Questions que l'architecte de solutions IA doit résoudre\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Livrables typiques\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Résultat et périmètre\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Qui est l'utilisateur ? Quelle tâche est dans le périmètre ? Que ne doit pas faire le système ? Qu'est-ce qui constitue un succès ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Contexte de la solution, périmètre des capacités, critères d'acceptation\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Exigences et ENF\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quelles contraintes de qualité, de sécurité, de disponibilité, de latence, de coût, de résidence et de conformité s'appliquent ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Cartographie des exigences, ENF, contraintes, critères de validation\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Application et orchestration\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Où se termine la logique applicative déterministe et où commence le comportement de l'IA ? Comment les flux de travail sont-ils coordonnés ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modèle de composants, API, frontières d'orchestration, chemins de défaillance\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Données faisant autorité et récupération\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quelle est la source de vérité ? Comment les données sont-elles ingérées, autorisées, récupérées, filtrées, classées et citées ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Flux de données, architecture de récupération, métadonnées et règles d'autorisation\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Couche modèle et fournisseur\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quelles capacités sont requises ? Quelles contraintes de fournisseur ou d'exécution importent ? Que faut-il abstraire ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Décision de modèle ou de fournisseur, politique de routage et de repli, frontière d'abstraction\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Outils et agents\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quelles actions le système peut-il entreprendre ? Quelles actions nécessitent une approbation ? Comment les identités et les permissions des outils sont-elles appliquées ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Contrats d'outils, frontières d'agents, règles d'approbation et de moindre privilège\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\">Quelles identités humaines et machine existent ? Où sont conservés les secrets ? Quelles frontières de confiance sont franchies ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modèle de menaces et de frontières de confiance, propagation d'identité, conception des secrets et de l'autorisation\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Exécution et déploiement\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Où les composants s'exécutent-ils ? Qu'est-ce qui est local, cloud, edge ou hybride ? Quelles hypothèses de réseau et de disponibilité existent ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Vue de déploiement, topologie d'exécution, décisions d'environnement et de connectivité\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Évaluation et observabilité\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Comment la qualité est-elle mesurée avant et après la mise en production ? Quelles traces, métriques, journaux et preuves sont nécessaires ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Plan d'évaluation, télémétrie, piste d'audit, portes de mise en production\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Exploitation et changement\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Comment les versions de modèles, de prompts, de configuration et de données sont-elles modifiées, annulées et prises en charge ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modèle opérationnel, contrôles de cycle de vie, ADR, runbooks, règles de changement\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch3 id=\"section-20\">1. Transformer le besoin produit en exigences architecturales\u003C\u002Fh3>\n\u003Cp>L'architecture IA commence avant la sélection du modèle. L'architecte détermine d'abord ce que la solution est censée accomplir et sous quelles contraintes. Cela inclut le comportement fonctionnel, mais aussi les ENF et les politiques qui réduisent l'espace de conception : sécurité, fiabilité, latence, confidentialité, résidence, maintenabilité, coût et support opérationnel.\u003C\u002Fp>\n\u003Cp>C'est ici que la distinction de A02 importe : une exigence telle que « les utilisateurs non autorisés ne doivent pas récupérer de documents restreints » n'est pas une décision d'architecture. C'est un moteur. Les décisions concernant la propagation d'identité, le partitionnement d'index, le filtrage des métadonnées, les frontières d'API et l'application de l'autorisation sont des réponses architecturales qui devront ensuite être validées.\u003C\u002Fp>\n\u003Ch3 id=\"section-23\">2. Concevoir des données faisant autorité, la récupération et le contexte\u003C\u002Fh3>\n\u003Cp>Les systèmes IA échouent souvent à la frontière entre le comportement du modèle et la vérité de l'entreprise. Un architecte doit définir quelles sources font autorité, ce que signifient la fraîcheur et la provenance, comment le contrôle d'accès atteint la récupération, et comment les preuves récupérées deviennent le contexte du modèle. Une base de données vectorielle, un modèle d'embedding ou une bibliothèque RAG ne constitue pas l'architecture à lui seul.\u003C\u002Fp>\n\u003Cp>Les recommandations actuelles de Microsoft sur les charges de travail IA rendent la même séparation explicite : le code applicatif ne doit pas contourner les frontières d'accès aux données ; le contexte utilisateur ou locataire doit se propager dans la récupération et le filtrage ; les données d'ancrage doivent être conçues pour être recherchables tout en respectant les exigences de sécurité et de conformité.\u003C\u002Fp>\n\u003Ch3 id=\"section-26\">3. Traiter les modèles et les fournisseurs comme des dépendances, pas comme l'ensemble du système\u003C\u002Fh3>\n\u003Cp>La sélection du modèle compte, mais elle doit être guidée par la capacité requise et les contraintes. L'architecte considère la qualité de raisonnement ou de génération, la modalité, les limites de contexte, la latence, le traitement des données, l'emplacement de déploiement, la disponibilité du fournisseur, le coût, l'observabilité et le risque de remplacement.\u003C\u002Fp>\n\u003Cp>L'abstraction du fournisseur n'est pas automatiquement une « meilleure architecture ». Elle ajoute un coût d'ingénierie et peut masquer des capacités spécifiques au fournisseur. Elle est justifiée lorsque la portabilité, le repli, la séparation des politiques ou le routage multi-fournisseur est une exigence explicite. Sinon, une intégration directe peut être la meilleure décision. L'essentiel est de rendre le compromis intentionnel.\u003C\u002Fp>\n\u003Ch3 id=\"section-29\">4. Architecturer les outils, les actions et les frontières des agents\u003C\u002Fh3>\n\u003Cp>Lorsqu'un système IA peut appeler des outils, modifier des données, envoyer des messages, exécuter du code ou exploiter des systèmes métier, le risque architectural change. L'accès aux outils nécessite son propre modèle d'identité et d'autorisation. La capacité du modèle à demander une action n'est pas la même chose que la permission de l'exécuter.\u003C\u002Fp>\n\u003Cp>Pour les charges de travail agentiques, les recommandations actuelles d'AWS mettent l'accent sur des dimensions supplémentaires telles que les identités d'agents, l'accès aux outils, l'orchestration, la supervision humaine, le traçage, la gestion des défaillances et le coût des boucles de raisonnement itératives. Ce sont des préoccupations de solution même lorsqu'un framework masque une partie de la mécanique d'implémentation.\u003C\u002Fp>\n\u003Ch3 id=\"section-32\">5. Rendre explicites les frontières de confiance et les permissions\u003C\u002Fh3>\n\u003Cp>Une solution IA en production comporte plusieurs frontières de confiance : navigateur ou client, backend applicatif, orchestration IA, services de récupération et de données, fournisseurs de modèles, API d'outils, exécutions locales et systèmes externes. Chaque frontière doit répondre : qui appelle, au nom de qui, avec quel identifiant, pour quelle ressource, avec quelle piste d'audit et avec quel confinement des défaillances ?\u003C\u002Fp>\n\u003Cp>La sécurité ne peut pas être reportée à un « garde-fou » autour du modèle. Les recommandations de Microsoft sur les charges de travail IA placent explicitement la sécurité sur toutes les couches d'architecture et appellent à la gestion des identités et des accès, à la protection des données, aux contrôles de contenu et à la sécurité du cycle de vie. Le NIST traite également la gouvernance et la gestion des risques comme continues tout au long du cycle de vie de l'IA.\u003C\u002Fp>\n\u003Ch3 id=\"section-35\">6. Décider où le système s'exécute réellement\u003C\u002Fh3>\n\u003Cp>« IA locale », « IA cloud » et « IA hybride » ne sont des affirmations architecturales que lorsque les chemins d'exécution et de données sont précis. Un processus local de bureau peut toujours appeler un modèle cloud. Une application hébergée dans le cloud peut récupérer des données depuis une source sur site. Une solution isolée du réseau a des contraintes entièrement différentes en matière de mise à jour, de distribution des modèles et d'observabilité.\u003C\u002Fp>\n\u003Cp>L'architecte sépare donc \u003Cstrong>l'emplacement d'exécution\u003C\u002Fstrong>, \u003Cstrong>l'emplacement d'inférence\u003C\u002Fstrong>, \u003Cstrong>l'emplacement des données\u003C\u002Fstrong> et \u003Cstrong>le plan de contrôle\u003C\u002Fstrong>. Les confondre crée de fausses hypothèses de sécurité et de déploiement.\u003C\u002Fp>\n\u003Ch3 id=\"section-38\">7. Définir l'évaluation, l'observabilité et l'acceptation opérationnelle\u003C\u002Fh3>\n\u003Cp>Le comportement de l'IA est partiellement non déterministe, la définition de version ne peut donc pas reposer uniquement sur des tests unitaires conventionnels. L'architecture nécessite une acceptation mesurable : succès de la tâche, ancrage ou exactitude des citations le cas échéant, comportement de refus, sécurité des outils, latence, coût, fiabilité et tests de sécurité. Les métriques exactes dépendent du cas d'usage.\u003C\u002Fp>\n\u003Cp>Les recommandations actuelles Well-Architected AI de Microsoft considèrent la surveillance comme continue et l'appliquent au comportement du modèle, aux prompts\u002Fcomplétions, aux anomalies, à la sécurité et aux portes de qualité de production. AWS considère de même l'observabilité, la gestion du cycle de vie et la traçabilité des modèles\u002Fprompts comme des préoccupations d'architecture opérationnelle.\u003C\u002Fp>\n\u003Ch2 id=\"section-41\">Que devrait produire le rôle ?\u003C\u002Fh2>\n\u003Cp>L'architecture n'est pas le diaporama. Les résultats utiles sont les artefacts qui permettent à l'ingénierie, à la sécurité, au produit et aux opérations de prendre des décisions cohérentes et de comprendre plus tard pourquoi le système existe sous sa forme actuelle.\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\">Artefact\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Objectif\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Contexte et périmètre de la solution\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Montre les utilisateurs, les systèmes externes, les responsabilités majeures et ce qui est hors périmètre\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Cartographie des exigences\u002FNFR\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Relie les besoins produit et les contraintes au travail d'architecture et à la validation\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Vues des composants et des flux de données\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Montre les interactions entre application, données\u002Frécupération, modèle, outils, identité et exécution\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modèle de confiance et de permissions\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Rend explicites les identités, les secrets, l'autorisation, les données sensibles et les actions à haut risque\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Enregistrements de décisions d'architecture\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Préserve les choix significatifs, les alternatives, les compromis, le statut et les conséquences\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Plan d'évaluation et d'acceptation\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Définit les preuves requises pour affirmer que la solution répond aux attentes de qualité et de sécurité\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Vue de déploiement et d'exploitation\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Définit les environnements, les emplacements d'exécution, l'observabilité, le retour arrière, les incidents et les responsabilités du cycle de vie\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Liens de traçabilité\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Relie les exigences, les décisions, le travail d'implémentation, les tests et les preuves opérationnelles\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-44\">Le travail consiste principalement en compromis, pas en sélection de « meilleures pratiques »\u003C\u002Fh2>\n\u003Cp>L'architecture existe parce que les qualités souhaitables entrent en conflit. Un modèle moins coûteux peut réduire la qualité. Un modèle plus performant peut augmenter la latence ou les contraintes de gouvernance des données. Une mise en cache agressive peut améliorer le coût et la vitesse tout en compliquant la fraîcheur. Des agents plus autonomes peuvent réduire l'effort humain tout en augmentant le rayon d'impact et les exigences d'audit.\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\">Décision\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Bénéfice potentiel\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Coût \u002F risque potentiel\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Question architecturale\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modèle cloud managé\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Adoption rapide, capacités managées solides\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Dépendance externe, contraintes de données et de coût\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La charge de travail permet-elle le chemin fournisseur\u002Fdonnées et répond-elle aux besoins de résilience ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Inférence locale\u002Fauto-hébergée\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Contrôle, options hors ligne\u002Fprivées\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Charge matérielle, opérationnelle et de cycle de vie du modèle\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le bénéfice de contrôle vaut-il la responsabilité opérationnelle ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Intégration à un fournisseur unique\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Implémentation plus simple, fonctionnalités complètes du fournisseur\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Concentration plus élevée de changement\u002Fpanne\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La portabilité ou le repli sont-ils réellement requis ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Abstraction du fournisseur\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Portabilité, routage et séparation des politiques\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Risque de plus petit dénominateur commun, plus de code\u002Ftests\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quelles différences doivent rester visibles plutôt qu'abstraites ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Grand contexte\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Plus d'informations par requête\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Latence, coût, dilution de l'attention, surface de fuite\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les données devraient-elles être récupérées\u002Ffiltrées plutôt que toujours injectées ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Outils puissants \u002F autonomie\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Plus d'automatisation de bout en bout\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Privilèges plus élevés et rayon d'impact des pannes\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quelles actions nécessitent le moindre privilège, une confirmation ou une approbation humaine ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Validation et journalisation strictes\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Meilleures preuves et opérations\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Coût de latence, de stockage, de confidentialité et de complexité\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quelles preuves sont requises pour ce niveau de risque ?\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-47\">En quoi cela diffère-t-il des rôles adjacents ?\u003C\u002Fh2>\n\u003Cp>Les intitulés se chevauchent fortement d'une entreprise à l'autre. La distinction utile est le \u003Cstrong>périmètre de responsabilité architecturale\u003C\u002Fstrong>, pas le libellé RH.\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Les rôles adjacents répondent à différentes questions principales\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\">Rôle\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\">Focus architectural principal\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\">Architecte de solutions IA\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">One concrete AI-enabled solution\u002Fworkload\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">How requirements, data, models, tools, security, runtime and operations fit together to deliver the target outcome\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Architecte de plateforme IA\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Reusable AI platform capabilities across many solutions\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Shared provider gateways, model access, identity, evaluation, retrieval services, observability, deployment patterns and developer experience\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Architecte IA d'entreprise\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Organization\u002Fportfolio-level target architecture\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Capability landscape, governance, integration principles, shared platforms, standards, sourcing and strategic constraints across domains\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Ingénieur IA \u002F ML\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Implementation of AI\u002FML behavior and pipelines\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Models, data, inference, evaluation, application logic and engineering tasks within the architecture\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Architecte sécurité\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Security architecture across systems\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Threats, identity, authorization, data protection, controls, assurance and compliance boundaries\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Responsable produit \u002F livraison\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Outcome, scope, prioritization and delivery system\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Why\u002Fwhat to build, sequencing, stakeholders, milestones, acceptance and value realization\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Cp>Dans une petite équipe produit, une personne peut couvrir plusieurs de ces périmètres. Dans une grande entreprise, ils peuvent être des rôles distincts avec des comités de revue formels. La responsabilité architecturale ne disparaît pas lorsque l'intitulé change.\u003C\u002Fp>\n\u003Ch2 id=\"section-51\">Preuves de mise en œuvre : comment ces frontières apparaissent dans mon propre travail\u003C\u002Fh2>\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\">Preuves de mise en œuvre, pas une règle universelle\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Les exemples ci-dessous sont des \u003Cstrong>preuves originales de mise en œuvre\u002Fprojet\u003C\u002Fstrong>. Ils montrent comment j'ai séparé le besoin produit, les exigences, l'architecture, l'exécution, le modèle\u002Ffournisseur, les permissions et la validation dans un travail de projet réel. Ils ne prétendent pas que chaque organisation doit utiliser la même structure, et ils n'impliquent pas d'adoption client ni de déploiement à l'échelle de l'entreprise.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch3 id=\"section-53\">SenseFlow : besoin → exigences → architecture → validation\u003C\u002Fh3>\n\u003Cp>Dans le projet SenseFlow Source of Truth, la technologie est explicitement subordonnée à la vision produit. La structure de développement passe du problème et de la vision produit aux besoins utilisateur, à la valeur, au périmètre, aux épopées, aux histoires et aux critères d'acceptation, puis à l'architecture, à l'implémentation, à la validation et à l'itération.\u003C\u002Fp>\n\u003Cp>Les exigences sont conçues pour être traçables depuis l'Objectif Produit → Capacité → Épopée → Récit Utilisateur → Critères d'Acceptation → Tâches Techniques. Lorsque cela est pratique, elles incluent des exigences fonctionnelles, des exigences non fonctionnelles, des dépendances, des risques, des hypothèses, des critères d'acceptation et des méthodes de validation. Les décisions significatives conservent la décision, la raison, les alternatives, les compromis, le statut et la date\u002Fversion.\u003C\u002Fp>\n\u003Cp>C'est un travail architectural avant qu'un framework ou modèle d'IA spécifique ne soit choisi : cela protège le lien entre l'intention produit et les décisions techniques et rend les changements ultérieurs vérifiables plutôt qu'implicites.\u003C\u002Fp>\n\u003Ch3 id=\"section-57\">Aaasaasa AI Client : séparer les concepts avant de les intégrer\u003C\u002Fh3>\n\u003Cp>Aaasaasa AI Client fournit un exemple plus proche de l'implémentation. Son AI Hub sépare délibérément \u003Cstrong>agent\u002Fclient\u003C\u002Fstrong>, \u003Cstrong>fournisseur\u003C\u002Fstrong>, \u003Cstrong>modèle\u003C\u002Fstrong>, \u003Cstrong>emplacement d'exécution\u002Fconnexion\u003C\u002Fstrong>, \u003Cstrong>permissions\u003C\u002Fstrong> et \u003Cstrong>client web\u003C\u002Fstrong>. Un runtime local n'est pas supposé signifier une inférence locale, et les permissions sont traitées comme une politique de runtime\u002Foutil plutôt que comme une propriété du modèle.\u003C\u002Fp>\n\u003Cp>L'architecture de bureau définit également une frontière de confiance : le renderer Nuxt n'est pas fiable par rapport au processus principal Electron. Un preload étroit et un IPC validé médiatisent l'accès aux services d'IA, aux paramètres, aux secrets chiffrés, aux services d'espace de travail\u002Fdonnées et aux runtimes. Les identifiants cloud restent dans le processus principal privilégié ; le code du renderer reçoit un état normalisé au lieu de secrets bruts ou d'un accès non restreint au système d'exploitation.\u003C\u002Fp>\n\u003Cp>Les décisions de routage sont également architecturales. L'implémentation ne bascule pas silencieusement d'une route locale vers une inférence cloud payante ; une route cloud nécessite une confirmation explicite. Le Chat Direct n'a pas d'outils de système de fichiers ou de shell par défaut, tandis que l'exécution d'agent applique un espace de travail et un profil de permissions sélectionnés. Ce sont des décisions au niveau de la solution concernant la confiance, le coût, l'exécution et les attentes des utilisateurs—pas des fonctionnalités du modèle.\u003C\u002Fp>\n\u003Ch2 id=\"section-61\">Comment les frameworks d'architecture actuels soutiennent ce périmètre élargi\u003C\u002Fh2>\n\u003Cp>ISO\u002FIEC\u002FIEEE 42010:2022 fournit une discipline générale pour les descriptions d'architecture à travers les logiciels, les systèmes et les entreprises. Il est délibérément plus large que l'IA et ne prescrit pas une méthode d'architecture ou un titre de poste unique. Cela le rend utile ici comme frontière : l'architecture de solution d'IA est toujours de l'architecture, avec des préoccupations des parties prenantes, des vues multiples et des relations significatives qui doivent être exprimées clairement.\u003C\u002Fp>\n\u003Cp>NIST AI RMF 1.0 encadre la gestion des risques d'IA à travers \u003Cstrong>Gouverner, Cartographier, Mesurer et Gérer\u003C\u002Fstrong> et souligne que la gestion des risques doit être continue tout au long du cycle de vie du système d'IA. Le Profil d'IA Générative (NIST AI 600-1) adapte ce cadre aux risques de l'IAG et aux priorités organisationnelles. Cela renforce que l'architecture ne peut pas s'arrêter à la performance fonctionnelle du modèle.\u003C\u002Fp>\n\u003Cp>Les directives actuelles Azure Well-Architected AI de Microsoft séparent la conception d'application, la plateforme d'application, les données d'entraînement, les données de fondation et les préoccupations de plateforme de données et les relient systématiquement à la fiabilité, la sécurité, l'excellence opérationnelle, la performance et le coût. Les lentilles Generative AI et Agentic AI d'AWS traitent de même l'observabilité, la sécurité, la fiabilité, le cycle de vie des modèles\u002Foutils, le coût et la supervision humaine comme des préoccupations architecturales.\u003C\u002Fp>\n\u003Ch2 id=\"section-65\">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\">Correction\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« L'architecte choisit le LLM. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le choix du modèle est une décision parmi d'autres dans une architecture de solution plus large.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« L'ingénierie de prompt est l'architecture. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les prompts influencent le comportement, mais ils ne définissent pas l'identité, l'accès aux données, les frontières de confiance, le déploiement, les permissions des outils ou les opérations.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« Le RAG résout la connaissance d'entreprise. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La récupération n'est qu'un sous-système ; l'autorisation, la provenance, la fraîcheur, les preuves, l'indexation, l'évaluation et la gouvernance des sources doivent encore être conçues.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« Runtime local signifie IA privée\u002Flocale. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les emplacements du runtime, de l'inférence, des données et du plan de contrôle sont des propriétés architecturales distinctes.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« Si un fournisseur propose des garde-fous, la sécurité est couverte. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La sécurité couvre l'identité, l'autorisation, les secrets, les flux de données, les outils, la journalisation, le déploiement, l'approbation humaine et les frontières des fournisseurs.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« L'architecte doit écrire chaque composant. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Une implémentation pratique peut améliorer la qualité architecturale, mais le rôle est défini par la responsabilité de décision intégrée, pas par le codage personnel de chaque couche.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« Un diagramme d'architecture prouve la préparation à la production. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La préparation nécessite des contrôles implémentés et des preuves de validation à travers la qualité, la sécurité, les opérations et l'acceptation métier.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-67\">Modes de défaillance qu'un Architecte de Solution IA doit prévenir\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 arrive\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Correction architecturale\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Conception axée sur le modèle\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Une démo de modèle prometteuse devient le plan du système\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Commencer par le résultat, les contraintes et la validation ; sélectionner le modèle dans ce cadre\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Permissions de prototype en production\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les identifiants partagés et l'accès large survivent au PoC\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Définir tôt la propagation d'identité, le moindre privilège, les portées des outils et les frontières d'approbation\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Récupération sans autorisation\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La qualité de recherche est conçue avant les règles d'accès aux données\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Transporter le contexte utilisateur\u002Flocataire dans la récupération et appliquer l'autorisation aux frontières d'accès aux données\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Hypothèses silencieuses sur le fournisseur\u002Fruntime\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« Local », « cloud » et « hors ligne » sont utilisés de manière imprécise\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Documenter séparément l'emplacement du runtime, de l'inférence, des données et du plan de contrôle\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Pas de contrat de défaillance\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le chemin heureux est conçu mais le comportement de refus\u002Frepli\u002Ferreur ne l'est pas\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Spécifier le comportement en cas de récupération vide, modèle indisponible, échec d'outil et refus de politique\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Évaluation après implémentation\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La qualité est jugée manuellement près du lancement\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Définir des critères d'acceptation mesurables et des ensembles d'évaluation représentatifs avant que l'architecture ne soit figée\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Changement non traçable\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les modèles, prompts, récupérations ou permissions changent sans historique architectural\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Versionner la configuration critique et enregistrer les décisions significatives\u002Fpreuves de validation\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Opérations traitées uniquement comme infrastructure\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le comportement de l'IA n'est pas observable après déploiement\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Concevoir ensemble les traces, métriques de qualité, événements de sécurité, télémétrie de coût et rollback\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-69\">Une séquence de décision pratique\u003C\u002Fh2>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Séquence de décision d'architecture de solution IA\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\">Résultat\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Définir le résultat utilisateur\u002Fmétier et les non-objectifs explicites.\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\">Preuves et contraintes\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Identifier les données faisant autorité, les politiques, les exigences non fonctionnelles, les risques et les conditions d'acceptation.\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\">Frontière du système\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Cartographier les utilisateurs, identités, applications, données, modèles\u002Ffournisseurs, outils et 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\">Options d'architecture\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Comparer les modèles pour la récupération, l'accès aux modèles, l'orchestration, le déploiement, les permissions, l'évaluation et l'observabilité.\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\">Décisions de compromis\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Sélectionner les options significatives et préserver la justification, les alternatives et 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\">Contrats d'implémentation\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Transformer les décisions en API, schémas, règles de permission, définitions de déploiement et tâches d'ingénierie.\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\">Validation\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Tester le système implémenté par rapport aux exigences fonctionnelles et non fonctionnelles originales.\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\">Retour opérationnel\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Utiliser les preuves de production, les incidents, les métriques de qualité et les signaux de coût\u002Fsécurité pour déclencher un changement contrôlé.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-71\">Cas limites et limites du rôle\u003C\u002Fh2>\n\u003Cp>Certains produits d'IA sont dominés par l'entraînement de modèles, l'expérimentation scientifique ou le matériel spécialisé. Dans ces cas, la science des données\u002Fmodèles et l'architecture des systèmes ML peuvent devenir beaucoup plus profondes que la carte au niveau de la solution présentée ici. L'Architecte de Solution IA a toujours besoin de frontières d'intégration et d'exploitation, mais l'architecture spécialisée peut posséder la plateforme d'entraînement elle-même.\u003C\u002Fp>\n\u003Cp>À l'autre extrême, une simple intégration SaaS peut ne pas justifier un architecte dédié. Un ingénieur senior ou un responsable technique produit peut assumer la même responsabilité d'architecture. Le test utile n'est pas le titre, mais de savoir si des décisions significatives entre couches sont prises délibérément et validées.\u003C\u002Fp>\n\u003Cp>Les systèmes réglementés, souverains, en air gap, critiques pour la sécurité, hautement autonomes ou multi-locataires déplacent également le centre de gravité. L'identité, l'isolation, la résidence, l'assurance, les mécanismes de mise à jour, la supervision humaine et l'auditabilité peuvent dominer la qualité du modèle dans l'architecture.\u003C\u002Fp>\n\u003Ch2 id=\"section-75\">Qu'est-ce qui changerait cette réponse ?\u003C\u002Fh2>\n\u003Cp>La frontière exacte des responsabilités change lorsque l'architecture passe d'une application à une plateforme réutilisable ou à une architecture cible à l'échelle de l'entreprise. C'est pourquoi \u003Cstrong>AI Platform Architect\u003C\u002Fstrong> et \u003Cstrong>Enterprise AI Architecture\u003C\u002Fstrong> méritent un traitement canonique distinct plutôt que d'être fusionnés dans ce rôle.\u003C\u002Fp>\n\u003Cp>Les changements technologiques comptent aussi. De nouvelles capacités de modèles, protocoles, environnements d'exécution locaux et services managés peuvent supprimer une partie du travail d'implémentation tout en créant de nouvelles frontières de confiance ou opérationnelles. La responsabilité stable consiste à comprendre ces changements comme des changements de système, et non à traiter un nouveau framework comme un remplacement de l'architecture.\u003C\u002Fp>\n\u003Ch2 id=\"section-78\">Liste de contrôle de l'AI Solution Architect\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\">Vérification\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Question\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Résultat\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le résultat utilisateur\u002Fmétier et la frontière des non-objectifs sont-ils explicites ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Exigences\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les exigences fonctionnelles, les NFR, les contraintes et les critères d'acceptation sont-ils traçables ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Données\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les sources faisant autorité, la provenance, la fraîcheur, la rétention et les règles d'accès sont-elles définies ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Récupération\u002Fcontexte\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'autorisation s'étend-elle à la récupération et à la construction du contexte ?\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\">La sélection du modèle\u002Ffournisseur est-elle liée aux capacités et aux contraintes plutôt qu'à une préférence ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Outils\u002Fagents\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les frontières d'action, les permissions, les approbations et le comportement en cas d'échec sont-ils explicites ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Identité\u002Fsécurité\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les identités humaines\u002Fmachine, les secrets et les frontières de confiance sont-ils définis ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Exécution\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les emplacements d'exécution, d'inférence, de données et de plan de contrôle sont-ils distingués ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Évaluation\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Existe-t-il des preuves mesurables de la qualité, de la sécurité et de l'acceptation ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Observabilité\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le comportement en production, les défaillances, les coûts et les événements de sécurité peuvent-ils être investigués ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Changement\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les décisions d'architecture significatives et les remplacements sont-ils traçables ?\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\">La responsabilité du déploiement, du retour arrière, des incidents et du cycle de vie est-elle claire ?\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-80\">Conclusion\u003C\u002Fh2>\n\u003Cp>Un AI Solution Architect est la personne ou la fonction d'architecture qui transforme une opportunité d'IA en un système technique cohérent. La compétence clé n'est pas de connaître le plus de noms de modèles ; c'est de relier le besoin produit, les exigences, les données, l'architecture applicative, les capacités d'IA, la sécurité, l'exécution, la livraison et la validation sans perdre les frontières entre eux.\u003C\u002Fp>\n\u003Cp>Une architecture de solution d'IA solide peut donc se résumer ainsi : \u003Cstrong>définir la cible → établir les exigences et les contraintes → concevoir les frontières du système → rendre explicites les compromis significatifs → implémenter via des contrats clairs → valider par des preuves → exploiter et faire évoluer délibérément.\u003C\u002Fstrong> Le modèle est important. La solution est le produit.\u003C\u002Fp>\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\">AI Solution Architect — FAQ\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 qu'un AI Solution Architect ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Un AI Solution Architect traduit un besoin métier ou produit en architecture d'une solution concrète activée par l'IA, en définissant comment la logique applicative, les données\u002Fla récupération, les modèles, les outils, l'identité, la sécurité, l'exécution, l'évaluation et les opérations fonctionnent ensemble.\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\">Un AI Solution Architect est-il identique à un ingénieur IA ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Non. Les rôles peuvent se chevaucher, surtout dans les petites équipes, mais un ingénieur IA est principalement un rôle d'implémentation tandis que l'architecte de solution possède ou coordonne les décisions d'architecture et les compromis entre couches pour la charge de travail complète.\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\">Un AI Solution Architect doit-il coder ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Pas par définition, mais une connaissance pratique de l'implémentation est très précieuse car l'architecture d'IA traverse les API, les données, la récupération, la sécurité, les environnements d'exécution et le comportement opérationnel. Le rôle est défini par la responsabilité d'architecture, et non par l'écriture personnelle de chaque composant.\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\">Le choix d'un LLM est-il le travail principal ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Non. La sélection du modèle est une décision parmi d'autres. L'architecture de production nécessite aussi des frontières de données et de récupération, des permissions, des outils, des choix de fournisseur\u002Fd'exécution, de l'observabilité, de l'évaluation, de la fiabilité, des coûts et une conception du cycle de vie.\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 un AI Solution Architect et un AI Platform Architect ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Un AI Solution Architect se concentre sur une solution ou une charge de travail concrète. Un AI Platform Architect se concentre sur des capacités d'IA réutilisables et des garde-fous qui prennent en charge plusieurs solutions.\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\">Quelle est la différence entre un AI Solution Architect et un Enterprise AI Architect ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">L'architecte de solution travaille à l'échelle de l'application\u002Fde la charge de travail. L'architecture d'IA d'entreprise travaille à l'échelle du portefeuille organisationnel, de l'architecture cible, de la gouvernance, des capacités partagées, des principes d'intégration et des contraintes stratégiques.\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\">Où se situent le RAG et les agents ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Ce sont des patrons architecturaux ou des sous-systèmes à l'intérieur d'une solution lorsque les exigences le justifient. Le RAG traite du contexte ancré dans la récupération ; les agents ajoutent la planification\u002Fl'exécution d'outils et donc des préoccupations supplémentaires d'identité, de permission, d'orchestration et d'exploitation.\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\">Qu'est-ce qui prouve que l'architecture fonctionne ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">L'implémentation plus des preuves de validation : tests fonctionnels, résultats d'évaluation, tests de sécurité\u002Fd'autorisation, mesures de performance et de fiabilité, observabilité, répétition opérationnelle et acceptation par rapport aux exigences initiales.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\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\u003C\u002Fh3>\u003Cdl>\u003Cdiv id=\"ai-solution-architect\" 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\">AI Solution Architect\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Responsabilité d'architecture pour une solution ou une charge de travail concrète activée par l'IA, intégrant les exigences produit avec la conception applicative, les données, le modèle, les outils, la sécurité, l'exécution et l'exploitation.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"system-boundary\" 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\">Frontière de système\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">La séparation explicite entre ce qui appartient à la solution et les utilisateurs, systèmes, fournisseurs, sources de données et environnements avec lesquels elle interagit.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"trust-boundary\" 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\">Frontière de confiance\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Un point où des données, des identités ou le contrôle traversent des composants ayant des hypothèses de confiance différentes et nécessitent donc des contrôles de sécurité explicites.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"grounding\" 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\">Ancrage\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Fournir à un modèle d'IA des informations ou des preuves externes pertinentes afin que sa réponse puisse être fondée sur des sources au-delà des paramètres du modèle.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"provider-abstraction\" 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\">Abstraction de fournisseur\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Une frontière applicative qui découple certaines parties de la solution d'une interface de modèle\u002Ffournisseur. Utile lorsqu'elle est justifiée par des besoins de routage, de portabilité ou de politique, mais non exempte de compromis.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"evaluation\" 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\">Évaluation\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Mesure structurée du comportement d'une charge de travail d'IA par rapport à des critères d'acceptation définis, incluant la qualité des tâches et les propriétés pertinentes de sûreté, de sécurité, de performance et d'exploitation.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"ai-platform-architect\" 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\">AI Platform Architect\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Rôle d'architecture axé sur les capacités de plateforme d'IA réutilisables utilisées par plusieurs solutions plutôt que sur l'architecture d'une seule charge de travail.\u003C\u002Fdd>\u003C\u002Fdiv>\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\">Enterprise AI Architecture\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Architecture au niveau de l'organisation qui coordonne les capacités d'IA, les plateformes, la gouvernance, l'intégration et les contraintes stratégiques à travers un portefeuille.\u003C\u002Fdd>\u003C\u002Fdiv>\u003C\u002Fdl>\u003C\u002Fsection>\n\u003Ch2 id=\"section-85\">Connaissances canoniques associées\u003C\u002Fh2>\n\u003Cp>Cet article s'inscrit dans le cluster AI Architecture Foundations. Ses fondations directes sont \u003Cstrong>Generative AI Explained: Models, Retrieval, Tools and Applications Are Not the Same Thing\u003C\u002Fstrong> et \u003Cstrong>ADR vs NFR: Architecture Decisions and System Quality Are Not the Same Thing\u003C\u002Fstrong>. Les nœuds canoniques adjacents incluent \u003Cstrong>Agentic AI Explained\u003C\u002Fstrong>, \u003Cstrong>Source of Truth in AI Systems\u003C\u002Fstrong>, \u003Cstrong>Vector Databases, Embeddings and Reranking\u003C\u002Fstrong>, \u003Cstrong>What Is Context Engineering?\u003C\u002Fstrong>, \u003Cstrong>RBAC vs Tenant Isolation\u003C\u002Fstrong>, \u003Cstrong>AI Platform Architect\u003C\u002Fstrong>, \u003Cstrong>Enterprise AI Architecture\u003C\u002Fstrong> et \u003Cstrong>AI Governance\u003C\u002Fstrong>. Les URL ne sont intentionnellement pas fabriquées là où ces nœuds ne sont pas encore publiés.\u003C\u002Fp>\n\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works\" 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\">What Is RAG? The Simplest Explanation of How It Works\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Explication canonique existante sur stajic.de de la génération augmentée par récupération, utile pour la partie récupération\u002Fancrage de l'architecture de solution d'IA.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ch2 id=\"section-88\">Sources primaires et recommandations d'architecture actuelles\u003C\u002Fh2>\n\u003Cp>Les sources externes ci-dessous étayent les affirmations générales sur l'architecture ; les sections SenseFlow et Aaasaasa AI Client constituent explicitement des preuves originales de projet\u002Fd'implémentation. Les références à l'état actuel ont été vérifiées le 8 octobre 2026. Le NIST indique que l'AI RMF 1.0 est en cours de révision, de sorte que les références de gouvernance sensibles à la version doivent être revérifiées lorsqu'un successeur sera publié.\u003C\u002Fp>\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 — Architecture Description\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Norme internationale actuelle pour la structure et l'expression des descriptions d'architecture. Elle distingue l'architecture de sa description et ne prescrit ni méthode d'architecturation, ni outil, ni format d'enregistrement.\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\">Page de ressources du NIST sur l'AI RMF. En octobre 2026, elle indique que l'AI RMF 1.0 est en cours de révision et renvoie au profil d'IA générative et aux ressources associées.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fairc.nist.gov\u002Fairmf-resources\u002Fairmf\u002F5-sec-core\u002F\" 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 RMF Core — Gouverner, Cartographier, Mesurer, Gérer\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Présentation officielle du NIST AIRC du Core de l'AI RMF 1.0, incluant les quatre fonctions et le cadrage de gestion des risques orienté cycle de vie.\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 d'IA générative\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Profil intersectoriel d'IA générative pour l'AI RMF 1.0, publié le 26 juillet 2024 et mis à jour par le NIST en 2026.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fget-started\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Microsoft Azure Well-Architected — Charges de travail IA\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Recommandations d'architecture actuelles au niveau des charges de travail couvrant la conception d'applications IA, la plateforme applicative, les données d'entraînement, les données d'ancrage, la plateforme de données et les préoccupations de mise en production.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fapplication-design\" 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 — Conception d'applications pour les charges de travail IA\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Recommandations sur l'abstraction des modèles et des outils, les frontières d'accès aux données, la propagation des identités, l'autorisation et la séparation des couches client, intelligence, connaissances et outils.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fdesign-principles\" 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 — Principes de conception pour les charges de travail IA\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Principes de conception actuels des charges de travail IA couvrant la fiabilité, la sécurité, les coûts, l'excellence opérationnelle et les performances, y compris les responsabilités en matière d'identité et de protection des données.\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\">Recommandations sur le cycle de vie en production couvrant la surveillance, les barrières de qualité, le comportement des modèles et des invites, la sécurité et la mesure opérationnelle.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fgenerative-ai-lens\u002F\" 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\">AWS Well-Architected Generative AI Lens\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Recommandations architecturales AWS pour les charges de travail d'IA générative couvrant l'excellence opérationnelle, la sécurité, la fiabilité, l'efficacité des performances, l'optimisation des coûts et la durabilité.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fagentic-ai-lens\u002F\" 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\">AWS Well-Architected Agentic AI Lens\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Publié en 2026, couvrant les préoccupations architecturales spécifiques aux agents, notamment les identités, les outils, l'orchestration, la supervision humaine, la fiabilité, la traçabilité et le coût des boucles de raisonnement.\u003C\u002Fp>\u003C\u002Fa>",{"time":212,"blocks":213,"version":1073},1791476923534,[214,219,226,232,237,244,248,252,256,300,304,308,312,340,344,348,352,356,360,408,412,416,420,424,428,432,436,440,444,448,452,456,460,464,468,472,476,480,484,488,492,496,500,531,535,539,583,587,591,639,643,647,653,657,661,665,669,673,677,681,685,689,693,697,701,705,733,737,777,781,810,814,818,822,826,830,834,838,842,882,886,890,894,931,967,971,975,985,989,993,1001,1009,1017,1025,1033,1041,1049,1057,1065],{"id":215,"data":216,"type":218},"intro",{"text":217},"Un \u003Cstrong>architecte de solutions IA\u003C\u002Fstrong> traduit un besoin métier ou produit en l'architecture d'une solution concrète activée par l'IA. Le rôle définit les frontières du système et les choix significatifs concernant la logique applicative, les données faisant autorité, la récupération et le contexte, les modèles et fournisseurs, les outils ou agents, l'identité et les permissions, la sécurité, l'exécution et le déploiement, l'observabilité, l'évaluation, le coût et le comportement opérationnel. Il ne s'agit pas simplement de sélection de modèle ou d'ingénierie de prompt : la responsabilité architecturale consiste à rendre l'ensemble de la solution implémentable, gouvernable, testable et exploitable.","paragraph",{"id":220,"data":221,"type":225},"direct",{"body":222,"title":223,"variant":224},"\u003Cstrong>Un architecte de solutions IA conçoit la solution complète activée par l'IA, pas seulement le modèle d'IA.\u003C\u002Fstrong> Le rôle relie les exigences et les exigences non fonctionnelles aux décisions d'architecture, compose les couches applicatives\u002Fdonnées\u002Fmodèles\u002Foutils\u002Fexécution nécessaires, rend explicites les frontières de confiance et de défaillance, et définit comment le système implémenté sera validé et exploité.","Réponse directe","info","callout",{"id":227,"data":228,"type":225},"role-note",{"body":229,"title":230,"variant":231},"\u003Cstrong>Architecte de solutions IA est un libellé de rôle pratique, pas un titre de poste universellement normalisé.\u003C\u002Fstrong> ISO\u002FIEC\u002FIEEE 42010:2022 normalise les concepts pour les descriptions d'architecture ; il ne définit pas ce rôle professionnel. Les organisations peuvent répartir les responsabilités entre plusieurs personnes. Dans cet article, le terme désigne la responsabilité architecturale pour une solution ou une charge de travail concrète activée par l'IA.","Note terminologique","note",{"id":233,"data":234,"type":225},"version-note",{"body":235,"title":236,"variant":231},"Les principes d'architecture présentés ici sont intentionnellement neutres vis-à-vis des fournisseurs, tandis que les recommandations actuelles des fournisseurs sont utilisées comme preuves de mise en œuvre. NIST AI RMF 1.0 est actuellement en cours de révision ; NIST AI 600-1 reste le profil publié pour l'IA générative. Les recommandations de Microsoft et AWS citées ci-dessous reflètent les préoccupations actuelles de production telles que l'identité, les frontières des données, l'abstraction des modèles, la sécurité, l'observabilité, l'évaluation, la fiabilité et le coût.","Note sur les sources actuelles — 8 octobre 2026",{"id":238,"data":239,"type":243},"toc",{"title":240,"maxLevel":241,"minLevel":242},"Sommaire",3,2,"tableOfContents",{"id":245,"data":246,"type":42},"h-meaning",{"text":247,"level":242},"Que conçoit réellement un architecte de solutions IA ?",{"id":249,"data":250,"type":218},"p-meaning-1",{"text":251},"L'objet du travail est la \u003Cstrong>solution\u003C\u002Fstrong> : le système socio-technique complet qui transforme un besoin en un comportement utile et maîtrisé. Un modèle peut être central pour ce système, mais il ne reste qu'une dépendance parmi d'autres. Le même modèle peut participer à un assistant de recherche interne sûr, à un agent dangereusement sur-privilégié, à une fonctionnalité client à faible latence ou à un prototype coûteux qui ne peut pas être exploité économiquement. L'architecture détermine ces différences.",{"id":253,"data":254,"type":218},"p-meaning-2",{"text":255},"Une frontière utile est donc : \u003Cstrong>résultat métier → exigences → responsabilités du système → décisions d'architecture → mise en œuvre → validation → exploitation\u003C\u002Fstrong>. L'architecte de solutions IA travaille sur toute cette chaîne en collaborant avec les spécialistes produit, ingénierie, données, sécurité, infrastructure, gouvernance et domaine.",{"id":257,"data":258,"type":299},"solution-vs-model",{"rows":259,"title":290,"layout":291,"columns":292},[260,266,272,278,284],{"id":261,"label":262,"values":263},"m1","Capacité",{"model":264,"solution":265},"Which model can generate or reason well enough?","Which combination of model, data, application logic, retrieval, tools and controls produces the required behavior?",{"id":267,"label":268,"values":269},"m2","Données",{"model":270,"solution":271},"What context can fit in the prompt?","What is authoritative, who may access it, how is it retrieved, versioned, filtered and cited?",{"id":273,"label":274,"values":275},"m3","Sécurité",{"model":276,"solution":277},"Does the provider offer security features?","What are the trust boundaries, identities, permissions, secrets, data flows and failure containment mechanisms?",{"id":279,"label":280,"values":281},"m4","Exploitation",{"model":282,"solution":283},"What is the token latency?","How is the complete workload deployed, observed, evaluated, recovered, versioned and cost-controlled?",{"id":285,"label":286,"values":287},"m5","Changement",{"model":288,"solution":289},"Can we switch models?","Which dependencies are abstracted, what changes require an ADR, and how do we validate that a replacement still meets requirements?","La solution est plus large que le modèle","table",[293,296],{"id":294,"label":295},"model","Question centrée sur le modèle",{"id":297,"label":298},"solution","Question d'architecture de solution","comparison",{"id":301,"data":302,"type":42},"h-simple",{"text":303,"level":242},"L'exemple le plus simple",{"id":305,"data":306,"type":218},"p-simple-1",{"text":307},"Imaginez qu'une entreprise souhaite un assistant interne qui réponde aux questions des techniciens à partir de manuels de maintenance et de procédures d'exploitation. La fonctionnalité visible semble simple : saisir une question et recevoir une réponse avec des sources.",{"id":309,"data":310,"type":218},"p-simple-2",{"text":311},"La question d'architecture est bien plus vaste. Quels documents font autorité ? Comment les utilisateurs sont-ils authentifiés ? La récupération doit-elle respecter les permissions de département ou de site ? La réponse est-elle autorisée à utiliser uniquement les preuves récupérées ? Quel modèle est acceptable pour la classification des données ? Un fournisseur cloud peut-il recevoir le contenu ? Que se passe-t-il lorsque la récupération ne trouve rien ? Comment les citations sont-elles produites ? Comment la qualité des réponses est-elle évaluée ? Quelles latence et coût sont acceptables ? Qui peut voir les journaux, et que peut-on y stocker ?",{"id":313,"data":314,"type":339},"simple-flow",{"steps":315,"title":337,"orientation":338},[316,319,322,325,328,331,334],{"label":317,"description":318},"1. Définir le résultat","Clarifier l'utilisateur, la valeur métier, la frontière de la tâche et ce que signifie une réponse ou une action réussie.",{"label":320,"description":321},"2. Recueillir les exigences","Rendre explicites les exigences fonctionnelles, les exigences non fonctionnelles, les contraintes, les règles de données, la tolérance au risque et les critères d'acceptation.",{"label":323,"description":324},"3. Établir les frontières","Identifier les utilisateurs, les identités, les applications, les données faisant autorité, les dépendances aux modèles\u002Ffournisseurs, les outils, les systèmes externes et les zones de confiance.",{"label":326,"description":327},"4. Concevoir l'architecture","Choisir les patrons de données\u002Frécupération, de modèle, d'orchestration, d'outils, de permissions, d'exécution, de déploiement, de repli et d'observabilité.",{"label":329,"description":330},"5. Consigner les décisions significatives","Préserver les choix architecturaux, les alternatives, les compromis et les conséquences afin que les changements ultérieurs restent compréhensibles.",{"label":332,"description":333},"6. Mettre en œuvre et intégrer","Transformer l'architecture en code applicatif, API, politiques, infrastructure, flux de travail et contrôles opérationnels.",{"label":335,"description":336},"7. Valider et exploiter","Tester la qualité, la sécurité, la fiabilité, le coût et les résultats utilisateur ; surveiller la charge de travail réelle et réinjecter les preuves dans les décisions.","Du besoin à une solution IA exploitable","auto","processFlow",{"id":341,"data":342,"type":42},"h-where-simple-stops",{"text":343,"level":242},"Là où l'exemple simple s'arrête",{"id":345,"data":346,"type":218},"p-stop-1",{"text":347},"Une preuve de concept peut souvent se passer d'une architecture dont la production ne peut pas se passer. Un développeur peut coder en dur un seul fournisseur, utiliser une clé API partagée, placer tous les documents dans un seul index, exécuter la récupération sans filtrage par contexte utilisateur, journaliser les prompts mot pour mot et juger la qualité manuellement. Cela peut démontrer la faisabilité, mais cela n'établit pas une architecture de production.",{"id":349,"data":350,"type":218},"p-stop-2",{"text":351},"La production introduit des contraintes qui interagissent : isolation des locataires ou des utilisateurs, confidentialité, résidence des données, débit, latence, coût, quotas des fournisseurs, comportement de repli, auditabilité, changements de version des modèles, qualité de la récupération, permissions des outils, réponse aux incidents et cycle de vie du déploiement. Le travail de l'architecte n'est pas de maximiser toutes les qualités à la fois ; il est de rendre les compromis explicites et de concevoir une solution qui satisfait l'ensemble réel des priorités.",{"id":353,"data":354,"type":42},"h-responsibility-map",{"text":355,"level":242},"Carte des responsabilités architecturales",{"id":357,"data":358,"type":218},"p-resp-intro",{"text":359},"La répartition exacte varie selon l'organisation, mais la carte suivante capture les responsabilités récurrentes de l'architecture IA au niveau de la solution. L'architecte n'implémente pas nécessairement lui-même chaque couche ; la responsabilité consiste à faire en sorte que les couches s'articulent de manière cohérente et à maintenir la traçabilité des décisions critiques.",{"id":361,"data":362,"type":291},"responsibility-table",{"content":363,"stretched":43,"withHeadings":14},[364,368,372,376,380,384,388,392,396,400,404],[365,366,367],"Domaine d'architecture","Questions que l'architecte de solutions IA doit résoudre","Livrables typiques",[369,370,371],"Résultat et périmètre","Qui est l'utilisateur ? Quelle tâche est dans le périmètre ? Que ne doit pas faire le système ? Qu'est-ce qui constitue un succès ?","Contexte de la solution, périmètre des capacités, critères d'acceptation",[373,374,375],"Exigences et ENF","Quelles contraintes de qualité, de sécurité, de disponibilité, de latence, de coût, de résidence et de conformité s'appliquent ?","Cartographie des exigences, ENF, contraintes, critères de validation",[377,378,379],"Application et orchestration","Où se termine la logique applicative déterministe et où commence le comportement de l'IA ? Comment les flux de travail sont-ils coordonnés ?","Modèle de composants, API, frontières d'orchestration, chemins de défaillance",[381,382,383],"Données faisant autorité et récupération","Quelle est la source de vérité ? Comment les données sont-elles ingérées, autorisées, récupérées, filtrées, classées et citées ?","Flux de données, architecture de récupération, métadonnées et règles d'autorisation",[385,386,387],"Couche modèle et fournisseur","Quelles capacités sont requises ? Quelles contraintes de fournisseur ou d'exécution importent ? Que faut-il abstraire ?","Décision de modèle ou de fournisseur, politique de routage et de repli, frontière d'abstraction",[389,390,391],"Outils et agents","Quelles actions le système peut-il entreprendre ? Quelles actions nécessitent une approbation ? Comment les identités et les permissions des outils sont-elles appliquées ?","Contrats d'outils, frontières d'agents, règles d'approbation et de moindre privilège",[393,394,395],"Identité et sécurité","Quelles identités humaines et machine existent ? Où sont conservés les secrets ? Quelles frontières de confiance sont franchies ?","Modèle de menaces et de frontières de confiance, propagation d'identité, conception des secrets et de l'autorisation",[397,398,399],"Exécution et déploiement","Où les composants s'exécutent-ils ? Qu'est-ce qui est local, cloud, edge ou hybride ? Quelles hypothèses de réseau et de disponibilité existent ?","Vue de déploiement, topologie d'exécution, décisions d'environnement et de connectivité",[401,402,403],"Évaluation et observabilité","Comment la qualité est-elle mesurée avant et après la mise en production ? Quelles traces, métriques, journaux et preuves sont nécessaires ?","Plan d'évaluation, télémétrie, piste d'audit, portes de mise en production",[405,406,407],"Exploitation et changement","Comment les versions de modèles, de prompts, de configuration et de données sont-elles modifiées, annulées et prises en charge ?","Modèle opérationnel, contrôles de cycle de vie, ADR, runbooks, règles de changement",{"id":409,"data":410,"type":42},"h-requirements",{"text":411,"level":241},"1. Transformer le besoin produit en exigences architecturales",{"id":413,"data":414,"type":218},"p-requirements-1",{"text":415},"L'architecture IA commence avant la sélection du modèle. L'architecte détermine d'abord ce que la solution est censée accomplir et sous quelles contraintes. Cela inclut le comportement fonctionnel, mais aussi les ENF et les politiques qui réduisent l'espace de conception : sécurité, fiabilité, latence, confidentialité, résidence, maintenabilité, coût et support opérationnel.",{"id":417,"data":418,"type":218},"p-requirements-2",{"text":419},"C'est ici que la distinction de A02 importe : une exigence telle que « les utilisateurs non autorisés ne doivent pas récupérer de documents restreints » n'est pas une décision d'architecture. C'est un moteur. Les décisions concernant la propagation d'identité, le partitionnement d'index, le filtrage des métadonnées, les frontières d'API et l'application de l'autorisation sont des réponses architecturales qui devront ensuite être validées.",{"id":421,"data":422,"type":42},"h-data",{"text":423,"level":241},"2. Concevoir des données faisant autorité, la récupération et le contexte",{"id":425,"data":426,"type":218},"p-data-1",{"text":427},"Les systèmes IA échouent souvent à la frontière entre le comportement du modèle et la vérité de l'entreprise. Un architecte doit définir quelles sources font autorité, ce que signifient la fraîcheur et la provenance, comment le contrôle d'accès atteint la récupération, et comment les preuves récupérées deviennent le contexte du modèle. Une base de données vectorielle, un modèle d'embedding ou une bibliothèque RAG ne constitue pas l'architecture à lui seul.",{"id":429,"data":430,"type":218},"p-data-2",{"text":431},"Les recommandations actuelles de Microsoft sur les charges de travail IA rendent la même séparation explicite : le code applicatif ne doit pas contourner les frontières d'accès aux données ; le contexte utilisateur ou locataire doit se propager dans la récupération et le filtrage ; les données d'ancrage doivent être conçues pour être recherchables tout en respectant les exigences de sécurité et de conformité.",{"id":433,"data":434,"type":42},"h-model",{"text":435,"level":241},"3. Traiter les modèles et les fournisseurs comme des dépendances, pas comme l'ensemble du système",{"id":437,"data":438,"type":218},"p-model-1",{"text":439},"La sélection du modèle compte, mais elle doit être guidée par la capacité requise et les contraintes. L'architecte considère la qualité de raisonnement ou de génération, la modalité, les limites de contexte, la latence, le traitement des données, l'emplacement de déploiement, la disponibilité du fournisseur, le coût, l'observabilité et le risque de remplacement.",{"id":441,"data":442,"type":218},"p-model-2",{"text":443},"L'abstraction du fournisseur n'est pas automatiquement une « meilleure architecture ». Elle ajoute un coût d'ingénierie et peut masquer des capacités spécifiques au fournisseur. Elle est justifiée lorsque la portabilité, le repli, la séparation des politiques ou le routage multi-fournisseur est une exigence explicite. Sinon, une intégration directe peut être la meilleure décision. L'essentiel est de rendre le compromis intentionnel.",{"id":445,"data":446,"type":42},"h-tools",{"text":447,"level":241},"4. Architecturer les outils, les actions et les frontières des agents",{"id":449,"data":450,"type":218},"p-tools-1",{"text":451},"Lorsqu'un système IA peut appeler des outils, modifier des données, envoyer des messages, exécuter du code ou exploiter des systèmes métier, le risque architectural change. L'accès aux outils nécessite son propre modèle d'identité et d'autorisation. La capacité du modèle à demander une action n'est pas la même chose que la permission de l'exécuter.",{"id":453,"data":454,"type":218},"p-tools-2",{"text":455},"Pour les charges de travail agentiques, les recommandations actuelles d'AWS mettent l'accent sur des dimensions supplémentaires telles que les identités d'agents, l'accès aux outils, l'orchestration, la supervision humaine, le traçage, la gestion des défaillances et le coût des boucles de raisonnement itératives. Ce sont des préoccupations de solution même lorsqu'un framework masque une partie de la mécanique d'implémentation.",{"id":457,"data":458,"type":42},"h-security",{"text":459,"level":241},"5. Rendre explicites les frontières de confiance et les permissions",{"id":461,"data":462,"type":218},"p-security-1",{"text":463},"Une solution IA en production comporte plusieurs frontières de confiance : navigateur ou client, backend applicatif, orchestration IA, services de récupération et de données, fournisseurs de modèles, API d'outils, exécutions locales et systèmes externes. Chaque frontière doit répondre : qui appelle, au nom de qui, avec quel identifiant, pour quelle ressource, avec quelle piste d'audit et avec quel confinement des défaillances ?",{"id":465,"data":466,"type":218},"p-security-2",{"text":467},"La sécurité ne peut pas être reportée à un « garde-fou » autour du modèle. Les recommandations de Microsoft sur les charges de travail IA placent explicitement la sécurité sur toutes les couches d'architecture et appellent à la gestion des identités et des accès, à la protection des données, aux contrôles de contenu et à la sécurité du cycle de vie. Le NIST traite également la gouvernance et la gestion des risques comme continues tout au long du cycle de vie de l'IA.",{"id":469,"data":470,"type":42},"h-runtime",{"text":471,"level":241},"6. Décider où le système s'exécute réellement",{"id":473,"data":474,"type":218},"p-runtime-1",{"text":475},"« IA locale », « IA cloud » et « IA hybride » ne sont des affirmations architecturales que lorsque les chemins d'exécution et de données sont précis. Un processus local de bureau peut toujours appeler un modèle cloud. Une application hébergée dans le cloud peut récupérer des données depuis une source sur site. Une solution isolée du réseau a des contraintes entièrement différentes en matière de mise à jour, de distribution des modèles et d'observabilité.",{"id":477,"data":478,"type":218},"p-runtime-2",{"text":479},"L'architecte sépare donc \u003Cstrong>l'emplacement d'exécution\u003C\u002Fstrong>, \u003Cstrong>l'emplacement d'inférence\u003C\u002Fstrong>, \u003Cstrong>l'emplacement des données\u003C\u002Fstrong> et \u003Cstrong>le plan de contrôle\u003C\u002Fstrong>. Les confondre crée de fausses hypothèses de sécurité et de déploiement.",{"id":481,"data":482,"type":42},"h-eval",{"text":483,"level":241},"7. Définir l'évaluation, l'observabilité et l'acceptation opérationnelle",{"id":485,"data":486,"type":218},"p-eval-1",{"text":487},"Le comportement de l'IA est partiellement non déterministe, la définition de version ne peut donc pas reposer uniquement sur des tests unitaires conventionnels. L'architecture nécessite une acceptation mesurable : succès de la tâche, ancrage ou exactitude des citations le cas échéant, comportement de refus, sécurité des outils, latence, coût, fiabilité et tests de sécurité. Les métriques exactes dépendent du cas d'usage.",{"id":489,"data":490,"type":218},"p-eval-2",{"text":491},"Les recommandations actuelles Well-Architected AI de Microsoft considèrent la surveillance comme continue et l'appliquent au comportement du modèle, aux prompts\u002Fcomplétions, aux anomalies, à la sécurité et aux portes de qualité de production. AWS considère de même l'observabilité, la gestion du cycle de vie et la traçabilité des modèles\u002Fprompts comme des préoccupations d'architecture opérationnelle.",{"id":493,"data":494,"type":42},"h-artifacts",{"text":495,"level":242},"Que devrait produire le rôle ?",{"id":497,"data":498,"type":218},"p-artifacts-1",{"text":499},"L'architecture n'est pas le diaporama. Les résultats utiles sont les artefacts qui permettent à l'ingénierie, à la sécurité, au produit et aux opérations de prendre des décisions cohérentes et de comprendre plus tard pourquoi le système existe sous sa forme actuelle.",{"id":501,"data":502,"type":291},"artifacts-table",{"content":503,"stretched":43,"withHeadings":14},[504,507,510,513,516,519,522,525,528],[505,506],"Artefact","Objectif",[508,509],"Contexte et périmètre de la solution","Montre les utilisateurs, les systèmes externes, les responsabilités majeures et ce qui est hors périmètre",[511,512],"Cartographie des exigences\u002FNFR","Relie les besoins produit et les contraintes au travail d'architecture et à la validation",[514,515],"Vues des composants et des flux de données","Montre les interactions entre application, données\u002Frécupération, modèle, outils, identité et exécution",[517,518],"Modèle de confiance et de permissions","Rend explicites les identités, les secrets, l'autorisation, les données sensibles et les actions à haut risque",[520,521],"Enregistrements de décisions d'architecture","Préserve les choix significatifs, les alternatives, les compromis, le statut et les conséquences",[523,524],"Plan d'évaluation et d'acceptation","Définit les preuves requises pour affirmer que la solution répond aux attentes de qualité et de sécurité",[526,527],"Vue de déploiement et d'exploitation","Définit les environnements, les emplacements d'exécution, l'observabilité, le retour arrière, les incidents et les responsabilités du cycle de vie",[529,530],"Liens de traçabilité","Relie les exigences, les décisions, le travail d'implémentation, les tests et les preuves opérationnelles",{"id":532,"data":533,"type":42},"h-tradeoffs",{"text":534,"level":242},"Le travail consiste principalement en compromis, pas en sélection de « meilleures pratiques »",{"id":536,"data":537,"type":218},"p-tradeoffs-1",{"text":538},"L'architecture existe parce que les qualités souhaitables entrent en conflit. Un modèle moins coûteux peut réduire la qualité. Un modèle plus performant peut augmenter la latence ou les contraintes de gouvernance des données. Une mise en cache agressive peut améliorer le coût et la vitesse tout en compliquant la fraîcheur. Des agents plus autonomes peuvent réduire l'effort humain tout en augmentant le rayon d'impact et les exigences d'audit.",{"id":540,"data":541,"type":291},"tradeoff-table",{"content":542,"stretched":43,"withHeadings":14},[543,548,553,558,563,568,573,578],[544,545,546,547],"Décision","Bénéfice potentiel","Coût \u002F risque potentiel","Question architecturale",[549,550,551,552],"Modèle cloud managé","Adoption rapide, capacités managées solides","Dépendance externe, contraintes de données et de coût","La charge de travail permet-elle le chemin fournisseur\u002Fdonnées et répond-elle aux besoins de résilience ?",[554,555,556,557],"Inférence locale\u002Fauto-hébergée","Contrôle, options hors ligne\u002Fprivées","Charge matérielle, opérationnelle et de cycle de vie du modèle","Le bénéfice de contrôle vaut-il la responsabilité opérationnelle ?",[559,560,561,562],"Intégration à un fournisseur unique","Implémentation plus simple, fonctionnalités complètes du fournisseur","Concentration plus élevée de changement\u002Fpanne","La portabilité ou le repli sont-ils réellement requis ?",[564,565,566,567],"Abstraction du fournisseur","Portabilité, routage et séparation des politiques","Risque de plus petit dénominateur commun, plus de code\u002Ftests","Quelles différences doivent rester visibles plutôt qu'abstraites ?",[569,570,571,572],"Grand contexte","Plus d'informations par requête","Latence, coût, dilution de l'attention, surface de fuite","Les données devraient-elles être récupérées\u002Ffiltrées plutôt que toujours injectées ?",[574,575,576,577],"Outils puissants \u002F autonomie","Plus d'automatisation de bout en bout","Privilèges plus élevés et rayon d'impact des pannes","Quelles actions nécessitent le moindre privilège, une confirmation ou une approbation humaine ?",[579,580,581,582],"Validation et journalisation strictes","Meilleures preuves et opérations","Coût de latence, de stockage, de confidentialité et de complexité","Quelles preuves sont requises pour ce niveau de risque ?",{"id":584,"data":585,"type":42},"h-adjacent",{"text":586,"level":242},"En quoi cela diffère-t-il des rôles adjacents ?",{"id":588,"data":589,"type":218},"p-adjacent-intro",{"text":590},"Les intitulés se chevauchent fortement d'une entreprise à l'autre. La distinction utile est le \u003Cstrong>périmètre de responsabilité architecturale\u003C\u002Fstrong>, pas le libellé RH.",{"id":592,"data":593,"type":299},"role-comparison",{"rows":594,"title":631,"layout":291,"columns":632},[595,601,607,613,619,625],{"id":596,"label":597,"values":598},"r1","Architecte de solutions IA",{"role":599,"focus":600},"One concrete AI-enabled solution\u002Fworkload","How requirements, data, models, tools, security, runtime and operations fit together to deliver the target outcome",{"id":602,"label":603,"values":604},"r2","Architecte de plateforme IA",{"role":605,"focus":606},"Reusable AI platform capabilities across many solutions","Shared provider gateways, model access, identity, evaluation, retrieval services, observability, deployment patterns and developer experience",{"id":608,"label":609,"values":610},"r3","Architecte IA d'entreprise",{"role":611,"focus":612},"Organization\u002Fportfolio-level target architecture","Capability landscape, governance, integration principles, shared platforms, standards, sourcing and strategic constraints across domains",{"id":614,"label":615,"values":616},"r4","Ingénieur IA \u002F ML",{"role":617,"focus":618},"Implementation of AI\u002FML behavior and pipelines","Models, data, inference, evaluation, application logic and engineering tasks within the architecture",{"id":620,"label":621,"values":622},"r5","Architecte sécurité",{"role":623,"focus":624},"Security architecture across systems","Threats, identity, authorization, data protection, controls, assurance and compliance boundaries",{"id":626,"label":627,"values":628},"r6","Responsable produit \u002F livraison",{"role":629,"focus":630},"Outcome, scope, prioritization and delivery system","Why\u002Fwhat to build, sequencing, stakeholders, milestones, acceptance and value realization","Les rôles adjacents répondent à différentes questions principales",[633,636],{"id":634,"label":635},"role","Rôle",{"id":637,"label":638},"focus","Focus architectural principal",{"id":640,"data":641,"type":218},"p-adjacent-2",{"text":642},"Dans une petite équipe produit, une personne peut couvrir plusieurs de ces périmètres. Dans une grande entreprise, ils peuvent être des rôles distincts avec des comités de revue formels. La responsabilité architecturale ne disparaît pas lorsque l'intitulé change.",{"id":644,"data":645,"type":42},"h-implementation",{"text":646,"level":242},"Preuves de mise en œuvre : comment ces frontières apparaissent dans mon propre travail",{"id":648,"data":649,"type":225},"implementation-boundary",{"body":650,"title":651,"variant":652},"Les exemples ci-dessous sont des \u003Cstrong>preuves originales de mise en œuvre\u002Fprojet\u003C\u002Fstrong>. Ils montrent comment j'ai séparé le besoin produit, les exigences, l'architecture, l'exécution, le modèle\u002Ffournisseur, les permissions et la validation dans un travail de projet réel. Ils ne prétendent pas que chaque organisation doit utiliser la même structure, et ils n'impliquent pas d'adoption client ni de déploiement à l'échelle de l'entreprise.","Preuves de mise en œuvre, pas une règle universelle","success",{"id":654,"data":655,"type":42},"h-senseflow",{"text":656,"level":241},"SenseFlow : besoin → exigences → architecture → validation",{"id":658,"data":659,"type":218},"p-senseflow-1",{"text":660},"Dans le projet SenseFlow Source of Truth, la technologie est explicitement subordonnée à la vision produit. La structure de développement passe du problème et de la vision produit aux besoins utilisateur, à la valeur, au périmètre, aux épopées, aux histoires et aux critères d'acceptation, puis à l'architecture, à l'implémentation, à la validation et à l'itération.",{"id":662,"data":663,"type":218},"p-senseflow-2",{"text":664},"Les exigences sont conçues pour être traçables depuis l'Objectif Produit → Capacité → Épopée → Récit Utilisateur → Critères d'Acceptation → Tâches Techniques. Lorsque cela est pratique, elles incluent des exigences fonctionnelles, des exigences non fonctionnelles, des dépendances, des risques, des hypothèses, des critères d'acceptation et des méthodes de validation. Les décisions significatives conservent la décision, la raison, les alternatives, les compromis, le statut et la date\u002Fversion.",{"id":666,"data":667,"type":218},"p-senseflow-3",{"text":668},"C'est un travail architectural avant qu'un framework ou modèle d'IA spécifique ne soit choisi : cela protège le lien entre l'intention produit et les décisions techniques et rend les changements ultérieurs vérifiables plutôt qu'implicites.",{"id":670,"data":671,"type":42},"h-client",{"text":672,"level":241},"Aaasaasa AI Client : séparer les concepts avant de les intégrer",{"id":674,"data":675,"type":218},"p-client-1",{"text":676},"Aaasaasa AI Client fournit un exemple plus proche de l'implémentation. Son AI Hub sépare délibérément \u003Cstrong>agent\u002Fclient\u003C\u002Fstrong>, \u003Cstrong>fournisseur\u003C\u002Fstrong>, \u003Cstrong>modèle\u003C\u002Fstrong>, \u003Cstrong>emplacement d'exécution\u002Fconnexion\u003C\u002Fstrong>, \u003Cstrong>permissions\u003C\u002Fstrong> et \u003Cstrong>client web\u003C\u002Fstrong>. Un runtime local n'est pas supposé signifier une inférence locale, et les permissions sont traitées comme une politique de runtime\u002Foutil plutôt que comme une propriété du modèle.",{"id":678,"data":679,"type":218},"p-client-2",{"text":680},"L'architecture de bureau définit également une frontière de confiance : le renderer Nuxt n'est pas fiable par rapport au processus principal Electron. Un preload étroit et un IPC validé médiatisent l'accès aux services d'IA, aux paramètres, aux secrets chiffrés, aux services d'espace de travail\u002Fdonnées et aux runtimes. Les identifiants cloud restent dans le processus principal privilégié ; le code du renderer reçoit un état normalisé au lieu de secrets bruts ou d'un accès non restreint au système d'exploitation.",{"id":682,"data":683,"type":218},"p-client-3",{"text":684},"Les décisions de routage sont également architecturales. L'implémentation ne bascule pas silencieusement d'une route locale vers une inférence cloud payante ; une route cloud nécessite une confirmation explicite. Le Chat Direct n'a pas d'outils de système de fichiers ou de shell par défaut, tandis que l'exécution d'agent applique un espace de travail et un profil de permissions sélectionnés. Ce sont des décisions au niveau de la solution concernant la confiance, le coût, l'exécution et les attentes des utilisateurs—pas des fonctionnalités du modèle.",{"id":686,"data":687,"type":42},"h-current-frameworks",{"text":688,"level":242},"Comment les frameworks d'architecture actuels soutiennent ce périmètre élargi",{"id":690,"data":691,"type":218},"p-frameworks-1",{"text":692},"ISO\u002FIEC\u002FIEEE 42010:2022 fournit une discipline générale pour les descriptions d'architecture à travers les logiciels, les systèmes et les entreprises. Il est délibérément plus large que l'IA et ne prescrit pas une méthode d'architecture ou un titre de poste unique. Cela le rend utile ici comme frontière : l'architecture de solution d'IA est toujours de l'architecture, avec des préoccupations des parties prenantes, des vues multiples et des relations significatives qui doivent être exprimées clairement.",{"id":694,"data":695,"type":218},"p-frameworks-2",{"text":696},"NIST AI RMF 1.0 encadre la gestion des risques d'IA à travers \u003Cstrong>Gouverner, Cartographier, Mesurer et Gérer\u003C\u002Fstrong> et souligne que la gestion des risques doit être continue tout au long du cycle de vie du système d'IA. Le Profil d'IA Générative (NIST AI 600-1) adapte ce cadre aux risques de l'IAG et aux priorités organisationnelles. Cela renforce que l'architecture ne peut pas s'arrêter à la performance fonctionnelle du modèle.",{"id":698,"data":699,"type":218},"p-frameworks-3",{"text":700},"Les directives actuelles Azure Well-Architected AI de Microsoft séparent la conception d'application, la plateforme d'application, les données d'entraînement, les données de fondation et les préoccupations de plateforme de données et les relient systématiquement à la fiabilité, la sécurité, l'excellence opérationnelle, la performance et le coût. Les lentilles Generative AI et Agentic AI d'AWS traitent de même l'observabilité, la sécurité, la fiabilité, le cycle de vie des modèles\u002Foutils, le coût et la supervision humaine comme des préoccupations architecturales.",{"id":702,"data":703,"type":42},"h-misconceptions",{"text":704,"level":242},"Idées fausses courantes",{"id":706,"data":707,"type":291},"misconceptions-table",{"content":708,"stretched":43,"withHeadings":14},[709,712,715,718,721,724,727,730],[710,711],"Idée fausse","Correction",[713,714],"« L'architecte choisit le LLM. »","Le choix du modèle est une décision parmi d'autres dans une architecture de solution plus large.",[716,717],"« L'ingénierie de prompt est l'architecture. »","Les prompts influencent le comportement, mais ils ne définissent pas l'identité, l'accès aux données, les frontières de confiance, le déploiement, les permissions des outils ou les opérations.",[719,720],"« Le RAG résout la connaissance d'entreprise. »","La récupération n'est qu'un sous-système ; l'autorisation, la provenance, la fraîcheur, les preuves, l'indexation, l'évaluation et la gouvernance des sources doivent encore être conçues.",[722,723],"« Runtime local signifie IA privée\u002Flocale. »","Les emplacements du runtime, de l'inférence, des données et du plan de contrôle sont des propriétés architecturales distinctes.",[725,726],"« Si un fournisseur propose des garde-fous, la sécurité est couverte. »","La sécurité couvre l'identité, l'autorisation, les secrets, les flux de données, les outils, la journalisation, le déploiement, l'approbation humaine et les frontières des fournisseurs.",[728,729],"« L'architecte doit écrire chaque composant. »","Une implémentation pratique peut améliorer la qualité architecturale, mais le rôle est défini par la responsabilité de décision intégrée, pas par le codage personnel de chaque couche.",[731,732],"« Un diagramme d'architecture prouve la préparation à la production. »","La préparation nécessite des contrôles implémentés et des preuves de validation à travers la qualité, la sécurité, les opérations et l'acceptation métier.",{"id":734,"data":735,"type":42},"h-failures",{"text":736,"level":242},"Modes de défaillance qu'un Architecte de Solution IA doit prévenir",{"id":738,"data":739,"type":291},"failures-table",{"content":740,"stretched":43,"withHeadings":14},[741,745,749,753,757,761,765,769,773],[742,743,744],"Mode de défaillance","Pourquoi cela arrive","Correction architecturale",[746,747,748],"Conception axée sur le modèle","Une démo de modèle prometteuse devient le plan du système","Commencer par le résultat, les contraintes et la validation ; sélectionner le modèle dans ce cadre",[750,751,752],"Permissions de prototype en production","Les identifiants partagés et l'accès large survivent au PoC","Définir tôt la propagation d'identité, le moindre privilège, les portées des outils et les frontières d'approbation",[754,755,756],"Récupération sans autorisation","La qualité de recherche est conçue avant les règles d'accès aux données","Transporter le contexte utilisateur\u002Flocataire dans la récupération et appliquer l'autorisation aux frontières d'accès aux données",[758,759,760],"Hypothèses silencieuses sur le fournisseur\u002Fruntime","« Local », « cloud » et « hors ligne » sont utilisés de manière imprécise","Documenter séparément l'emplacement du runtime, de l'inférence, des données et du plan de contrôle",[762,763,764],"Pas de contrat de défaillance","Le chemin heureux est conçu mais le comportement de refus\u002Frepli\u002Ferreur ne l'est pas","Spécifier le comportement en cas de récupération vide, modèle indisponible, échec d'outil et refus de politique",[766,767,768],"Évaluation après implémentation","La qualité est jugée manuellement près du lancement","Définir des critères d'acceptation mesurables et des ensembles d'évaluation représentatifs avant que l'architecture ne soit figée",[770,771,772],"Changement non traçable","Les modèles, prompts, récupérations ou permissions changent sans historique architectural","Versionner la configuration critique et enregistrer les décisions significatives\u002Fpreuves de validation",[774,775,776],"Opérations traitées uniquement comme infrastructure","Le comportement de l'IA n'est pas observable après déploiement","Concevoir ensemble les traces, métriques de qualité, événements de sécurité, télémétrie de coût et rollback",{"id":778,"data":779,"type":42},"h-decision-framework",{"text":780,"level":242},"Une séquence de décision pratique",{"id":782,"data":783,"type":339},"decision-flow",{"steps":784,"title":809,"orientation":338},[785,788,791,794,797,800,803,806],{"label":786,"description":787},"Résultat","Définir le résultat utilisateur\u002Fmétier et les non-objectifs explicites.",{"label":789,"description":790},"Preuves et contraintes","Identifier les données faisant autorité, les politiques, les exigences non fonctionnelles, les risques et les conditions d'acceptation.",{"label":792,"description":793},"Frontière du système","Cartographier les utilisateurs, identités, applications, données, modèles\u002Ffournisseurs, outils et systèmes externes.",{"label":795,"description":796},"Options d'architecture","Comparer les modèles pour la récupération, l'accès aux modèles, l'orchestration, le déploiement, les permissions, l'évaluation et l'observabilité.",{"label":798,"description":799},"Décisions de compromis","Sélectionner les options significatives et préserver la justification, les alternatives et les conséquences.",{"label":801,"description":802},"Contrats d'implémentation","Transformer les décisions en API, schémas, règles de permission, définitions de déploiement et tâches d'ingénierie.",{"label":804,"description":805},"Validation","Tester le système implémenté par rapport aux exigences fonctionnelles et non fonctionnelles originales.",{"label":807,"description":808},"Retour opérationnel","Utiliser les preuves de production, les incidents, les métriques de qualité et les signaux de coût\u002Fsécurité pour déclencher un changement contrôlé.","Séquence de décision d'architecture de solution IA",{"id":811,"data":812,"type":42},"h-edge",{"text":813,"level":242},"Cas limites et limites du rôle",{"id":815,"data":816,"type":218},"p-edge-1",{"text":817},"Certains produits d'IA sont dominés par l'entraînement de modèles, l'expérimentation scientifique ou le matériel spécialisé. Dans ces cas, la science des données\u002Fmodèles et l'architecture des systèmes ML peuvent devenir beaucoup plus profondes que la carte au niveau de la solution présentée ici. L'Architecte de Solution IA a toujours besoin de frontières d'intégration et d'exploitation, mais l'architecture spécialisée peut posséder la plateforme d'entraînement elle-même.",{"id":819,"data":820,"type":218},"p-edge-2",{"text":821},"À l'autre extrême, une simple intégration SaaS peut ne pas justifier un architecte dédié. Un ingénieur senior ou un responsable technique produit peut assumer la même responsabilité d'architecture. Le test utile n'est pas le titre, mais de savoir si des décisions significatives entre couches sont prises délibérément et validées.",{"id":823,"data":824,"type":218},"p-edge-3",{"text":825},"Les systèmes réglementés, souverains, en air gap, critiques pour la sécurité, hautement autonomes ou multi-locataires déplacent également le centre de gravité. L'identité, l'isolation, la résidence, l'assurance, les mécanismes de mise à jour, la supervision humaine et l'auditabilité peuvent dominer la qualité du modèle dans l'architecture.",{"id":827,"data":828,"type":42},"h-change-answer",{"text":829,"level":242},"Qu'est-ce qui changerait cette réponse ?",{"id":831,"data":832,"type":218},"p-change-1",{"text":833},"La frontière exacte des responsabilités change lorsque l'architecture passe d'une application à une plateforme réutilisable ou à une architecture cible à l'échelle de l'entreprise. C'est pourquoi \u003Cstrong>AI Platform Architect\u003C\u002Fstrong> et \u003Cstrong>Enterprise AI Architecture\u003C\u002Fstrong> méritent un traitement canonique distinct plutôt que d'être fusionnés dans ce rôle.",{"id":835,"data":836,"type":218},"p-change-2",{"text":837},"Les changements technologiques comptent aussi. De nouvelles capacités de modèles, protocoles, environnements d'exécution locaux et services managés peuvent supprimer une partie du travail d'implémentation tout en créant de nouvelles frontières de confiance ou opérationnelles. La responsabilité stable consiste à comprendre ces changements comme des changements de système, et non à traiter un nouveau framework comme un remplacement de l'architecture.",{"id":839,"data":840,"type":42},"h-checklist",{"text":841,"level":242},"Liste de contrôle de l'AI Solution Architect",{"id":843,"data":844,"type":291},"checklist-table",{"content":845,"stretched":43,"withHeadings":14},[846,849,851,854,856,859,862,865,868,871,874,877,879],[847,848],"Vérification","Question",[786,850],"Le résultat utilisateur\u002Fmétier et la frontière des non-objectifs sont-ils explicites ?",[852,853],"Exigences","Les exigences fonctionnelles, les NFR, les contraintes et les critères d'acceptation sont-ils traçables ?",[268,855],"Les sources faisant autorité, la provenance, la fraîcheur, la rétention et les règles d'accès sont-elles définies ?",[857,858],"Récupération\u002Fcontexte","L'autorisation s'étend-elle à la récupération et à la construction du contexte ?",[860,861],"Modèle\u002Ffournisseur","La sélection du modèle\u002Ffournisseur est-elle liée aux capacités et aux contraintes plutôt qu'à une préférence ?",[863,864],"Outils\u002Fagents","Les frontières d'action, les permissions, les approbations et le comportement en cas d'échec sont-ils explicites ?",[866,867],"Identité\u002Fsécurité","Les identités humaines\u002Fmachine, les secrets et les frontières de confiance sont-ils définis ?",[869,870],"Exécution","Les emplacements d'exécution, d'inférence, de données et de plan de contrôle sont-ils distingués ?",[872,873],"Évaluation","Existe-t-il des preuves mesurables de la qualité, de la sécurité et de l'acceptation ?",[875,876],"Observabilité","Le comportement en production, les défaillances, les coûts et les événements de sécurité peuvent-ils être investigués ?",[286,878],"Les décisions d'architecture significatives et les remplacements sont-ils traçables ?",[880,881],"Opérations","La responsabilité du déploiement, du retour arrière, des incidents et du cycle de vie est-elle claire ?",{"id":883,"data":884,"type":42},"h-conclusion",{"text":885,"level":242},"Conclusion",{"id":887,"data":888,"type":218},"p-conclusion-1",{"text":889},"Un AI Solution Architect est la personne ou la fonction d'architecture qui transforme une opportunité d'IA en un système technique cohérent. La compétence clé n'est pas de connaître le plus de noms de modèles ; c'est de relier le besoin produit, les exigences, les données, l'architecture applicative, les capacités d'IA, la sécurité, l'exécution, la livraison et la validation sans perdre les frontières entre eux.",{"id":891,"data":892,"type":218},"p-conclusion-2",{"text":893},"Une architecture de solution d'IA solide peut donc se résumer ainsi : \u003Cstrong>définir la cible → établir les exigences et les contraintes → concevoir les frontières du système → rendre explicites les compromis significatifs → implémenter via des contrats clairs → valider par des preuves → exploiter et faire évoluer délibérément.\u003C\u002Fstrong> Le modèle est important. La solution est le produit.",{"id":895,"data":896,"type":895},"faq",{"items":897,"title":930},[898,902,906,910,914,918,922,926],{"id":899,"answer":900,"question":901},"faq1","Un AI Solution Architect traduit un besoin métier ou produit en architecture d'une solution concrète activée par l'IA, en définissant comment la logique applicative, les données\u002Fla récupération, les modèles, les outils, l'identité, la sécurité, l'exécution, l'évaluation et les opérations fonctionnent ensemble.","Qu'est-ce qu'un AI Solution Architect ?",{"id":903,"answer":904,"question":905},"faq2","Non. Les rôles peuvent se chevaucher, surtout dans les petites équipes, mais un ingénieur IA est principalement un rôle d'implémentation tandis que l'architecte de solution possède ou coordonne les décisions d'architecture et les compromis entre couches pour la charge de travail complète.","Un AI Solution Architect est-il identique à un ingénieur IA ?",{"id":907,"answer":908,"question":909},"faq3","Pas par définition, mais une connaissance pratique de l'implémentation est très précieuse car l'architecture d'IA traverse les API, les données, la récupération, la sécurité, les environnements d'exécution et le comportement opérationnel. Le rôle est défini par la responsabilité d'architecture, et non par l'écriture personnelle de chaque composant.","Un AI Solution Architect doit-il coder ?",{"id":911,"answer":912,"question":913},"faq4","Non. La sélection du modèle est une décision parmi d'autres. L'architecture de production nécessite aussi des frontières de données et de récupération, des permissions, des outils, des choix de fournisseur\u002Fd'exécution, de l'observabilité, de l'évaluation, de la fiabilité, des coûts et une conception du cycle de vie.","Le choix d'un LLM est-il le travail principal ?",{"id":915,"answer":916,"question":917},"faq5","Un AI Solution Architect se concentre sur une solution ou une charge de travail concrète. Un AI Platform Architect se concentre sur des capacités d'IA réutilisables et des garde-fous qui prennent en charge plusieurs solutions.","Quelle est la différence entre un AI Solution Architect et un AI Platform Architect ?",{"id":919,"answer":920,"question":921},"faq6","L'architecte de solution travaille à l'échelle de l'application\u002Fde la charge de travail. L'architecture d'IA d'entreprise travaille à l'échelle du portefeuille organisationnel, de l'architecture cible, de la gouvernance, des capacités partagées, des principes d'intégration et des contraintes stratégiques.","Quelle est la différence entre un AI Solution Architect et un Enterprise AI Architect ?",{"id":923,"answer":924,"question":925},"faq7","Ce sont des patrons architecturaux ou des sous-systèmes à l'intérieur d'une solution lorsque les exigences le justifient. Le RAG traite du contexte ancré dans la récupération ; les agents ajoutent la planification\u002Fl'exécution d'outils et donc des préoccupations supplémentaires d'identité, de permission, d'orchestration et d'exploitation.","Où se situent le RAG et les agents ?",{"id":927,"answer":928,"question":929},"faq8","L'implémentation plus des preuves de validation : tests fonctionnels, résultats d'évaluation, tests de sécurité\u002Fd'autorisation, mesures de performance et de fiabilité, observabilité, répétition opérationnelle et acceptation par rapport aux exigences initiales.","Qu'est-ce qui prouve que l'architecture fonctionne ?","AI Solution Architect — FAQ",{"id":932,"data":933,"type":932},"glossary",{"title":934,"entries":935},"Termes clés",[936,940,944,948,952,956,959,963],{"term":937,"anchor":938,"definition":939},"AI Solution Architect","ai-solution-architect","Responsabilité d'architecture pour une solution ou une charge de travail concrète activée par l'IA, intégrant les exigences produit avec la conception applicative, les données, le modèle, les outils, la sécurité, l'exécution et l'exploitation.",{"term":941,"anchor":942,"definition":943},"Frontière de système","system-boundary","La séparation explicite entre ce qui appartient à la solution et les utilisateurs, systèmes, fournisseurs, sources de données et environnements avec lesquels elle interagit.",{"term":945,"anchor":946,"definition":947},"Frontière de confiance","trust-boundary","Un point où des données, des identités ou le contrôle traversent des composants ayant des hypothèses de confiance différentes et nécessitent donc des contrôles de sécurité explicites.",{"term":949,"anchor":950,"definition":951},"Ancrage","grounding","Fournir à un modèle d'IA des informations ou des preuves externes pertinentes afin que sa réponse puisse être fondée sur des sources au-delà des paramètres du modèle.",{"term":953,"anchor":954,"definition":955},"Abstraction de fournisseur","provider-abstraction","Une frontière applicative qui découple certaines parties de la solution d'une interface de modèle\u002Ffournisseur. Utile lorsqu'elle est justifiée par des besoins de routage, de portabilité ou de politique, mais non exempte de compromis.",{"term":872,"anchor":957,"definition":958},"evaluation","Mesure structurée du comportement d'une charge de travail d'IA par rapport à des critères d'acceptation définis, incluant la qualité des tâches et les propriétés pertinentes de sûreté, de sécurité, de performance et d'exploitation.",{"term":960,"anchor":961,"definition":962},"AI Platform Architect","ai-platform-architect","Rôle d'architecture axé sur les capacités de plateforme d'IA réutilisables utilisées par plusieurs solutions plutôt que sur l'architecture d'une seule charge de travail.",{"term":964,"anchor":965,"definition":966},"Enterprise AI Architecture","enterprise-ai-architecture","Architecture au niveau de l'organisation qui coordonne les capacités d'IA, les plateformes, la gouvernance, l'intégration et les contraintes stratégiques à travers un portefeuille.",{"id":968,"data":969,"type":42},"h-related",{"text":970,"level":242},"Connaissances canoniques associées",{"id":972,"data":973,"type":218},"p-related-1",{"text":974},"Cet article s'inscrit dans le cluster AI Architecture Foundations. Ses fondations directes sont \u003Cstrong>Generative AI Explained: Models, Retrieval, Tools and Applications Are Not the Same Thing\u003C\u002Fstrong> et \u003Cstrong>ADR vs NFR: Architecture Decisions and System Quality Are Not the Same Thing\u003C\u002Fstrong>. Les nœuds canoniques adjacents incluent \u003Cstrong>Agentic AI Explained\u003C\u002Fstrong>, \u003Cstrong>Source of Truth in AI Systems\u003C\u002Fstrong>, \u003Cstrong>Vector Databases, Embeddings and Reranking\u003C\u002Fstrong>, \u003Cstrong>What Is Context Engineering?\u003C\u002Fstrong>, \u003Cstrong>RBAC vs Tenant Isolation\u003C\u002Fstrong>, \u003Cstrong>AI Platform Architect\u003C\u002Fstrong>, \u003Cstrong>Enterprise AI Architecture\u003C\u002Fstrong> et \u003Cstrong>AI Governance\u003C\u002Fstrong>. Les URL ne sont intentionnellement pas fabriquées là où ces nœuds ne sont pas encore publiés.",{"id":976,"data":977,"type":984},"related-rag",{"link":978,"meta":979},"https:\u002F\u002Fstajic.de\u002Ffr\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works",{"image":980,"title":982,"description":983},{"url":981},"","What Is RAG? The Simplest Explanation of How It Works","Explication canonique existante sur stajic.de de la génération augmentée par récupération, utile pour la partie récupération\u002Fancrage de l'architecture de solution d'IA.","linkTool",{"id":986,"data":987,"type":42},"h-sources",{"text":988,"level":242},"Sources primaires et recommandations d'architecture actuelles",{"id":990,"data":991,"type":218},"p-sources-note",{"text":992},"Les sources externes ci-dessous étayent les affirmations générales sur l'architecture ; les sections SenseFlow et Aaasaasa AI Client constituent explicitement des preuves originales de projet\u002Fd'implémentation. Les références à l'état actuel ont été vérifiées le 8 octobre 2026. Le NIST indique que l'AI RMF 1.0 est en cours de révision, de sorte que les références de gouvernance sensibles à la version doivent être revérifiées lorsqu'un successeur sera publié.",{"id":994,"data":995,"type":984},"src-iso-42010",{"link":996,"meta":997},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html",{"image":998,"title":999,"description":1000},{"url":981},"ISO\u002FIEC\u002FIEEE 42010:2022 — Architecture Description","Norme internationale actuelle pour la structure et l'expression des descriptions d'architecture. Elle distingue l'architecture de sa description et ne prescrit ni méthode d'architecturation, ni outil, ni format d'enregistrement.",{"id":1002,"data":1003,"type":984},"src-nist-rmf",{"link":1004,"meta":1005},"https:\u002F\u002Fwww.nist.gov\u002Fitl\u002Fai-risk-management-framework",{"image":1006,"title":1007,"description":1008},{"url":981},"Cadre de gestion des risques liés à l'IA du NIST","Page de ressources du NIST sur l'AI RMF. En octobre 2026, elle indique que l'AI RMF 1.0 est en cours de révision et renvoie au profil d'IA générative et aux ressources associées.",{"id":1010,"data":1011,"type":984},"src-nist-core",{"link":1012,"meta":1013},"https:\u002F\u002Fairc.nist.gov\u002Fairmf-resources\u002Fairmf\u002F5-sec-core\u002F",{"image":1014,"title":1015,"description":1016},{"url":981},"NIST AI RMF Core — Gouverner, Cartographier, Mesurer, Gérer","Présentation officielle du NIST AIRC du Core de l'AI RMF 1.0, incluant les quatre fonctions et le cadrage de gestion des risques orienté cycle de vie.",{"id":1018,"data":1019,"type":984},"src-nist-gai",{"link":1020,"meta":1021},"https:\u002F\u002Fwww.nist.gov\u002Fpublications\u002Fartificial-intelligence-risk-management-framework-generative-artificial-intelligence",{"image":1022,"title":1023,"description":1024},{"url":981},"NIST AI 600-1 — Profil d'IA générative","Profil intersectoriel d'IA générative pour l'AI RMF 1.0, publié le 26 juillet 2024 et mis à jour par le NIST en 2026.",{"id":1026,"data":1027,"type":984},"src-ms-start",{"link":1028,"meta":1029},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fget-started",{"image":1030,"title":1031,"description":1032},{"url":981},"Microsoft Azure Well-Architected — Charges de travail IA","Recommandations d'architecture actuelles au niveau des charges de travail couvrant la conception d'applications IA, la plateforme applicative, les données d'entraînement, les données d'ancrage, la plateforme de données et les préoccupations de mise en production.",{"id":1034,"data":1035,"type":984},"src-ms-app",{"link":1036,"meta":1037},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fapplication-design",{"image":1038,"title":1039,"description":1040},{"url":981},"Microsoft — Conception d'applications pour les charges de travail IA","Recommandations sur l'abstraction des modèles et des outils, les frontières d'accès aux données, la propagation des identités, l'autorisation et la séparation des couches client, intelligence, connaissances et outils.",{"id":1042,"data":1043,"type":984},"src-ms-security",{"link":1044,"meta":1045},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fdesign-principles",{"image":1046,"title":1047,"description":1048},{"url":981},"Microsoft — Principes de conception pour les charges de travail IA","Principes de conception actuels des charges de travail IA couvrant la fiabilité, la sécurité, les coûts, l'excellence opérationnelle et les performances, y compris les responsabilités en matière d'identité et de protection des données.",{"id":1050,"data":1051,"type":984},"src-ms-ops",{"link":1052,"meta":1053},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fmlops-genaiops",{"image":1054,"title":1055,"description":1056},{"url":981},"Microsoft — MLOps et GenAIOps pour les charges de travail IA","Recommandations sur le cycle de vie en production couvrant la surveillance, les barrières de qualité, le comportement des modèles et des invites, la sécurité et la mesure opérationnelle.",{"id":1058,"data":1059,"type":984},"src-aws-genai",{"link":1060,"meta":1061},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fgenerative-ai-lens\u002F",{"image":1062,"title":1063,"description":1064},{"url":981},"AWS Well-Architected Generative AI Lens","Recommandations architecturales AWS pour les charges de travail d'IA générative couvrant l'excellence opérationnelle, la sécurité, la fiabilité, l'efficacité des performances, l'optimisation des coûts et la durabilité.",{"id":1066,"data":1067,"type":984},"src-aws-agentic",{"link":1068,"meta":1069},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fagentic-ai-lens\u002F",{"image":1070,"title":1071,"description":1072},{"url":981},"AWS Well-Architected Agentic AI Lens","Publié en 2026, couvrant les préoccupations architecturales spécifiques aux agents, notamment les identités, les outils, l'orchestration, la supervision humaine, la fiabilité, la traçabilité et le coût des boucles de raisonnement.","2.31","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","what-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs-1791476643267-1st5xz","PUBLISHED","2026-10-08T12:23:00.000Z","2026-10-08T16:23:08.916Z","2026-10-08T16:31:54.093Z",{"en":1082,"de":1083,"sr":1084,"es":1085,"fr":1086,"it":1087,"ru":1088,"zh":1089},"\u002Fblog\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","\u002Fde\u002Fblog\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","\u002Fsr\u002Fblog\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","\u002Fes\u002Fblog\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","\u002Ffr\u002Fblog\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","\u002Fit\u002Fblog\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","\u002Fru\u002Fblog\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","\u002Fzh\u002Fblog\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs",[1091,1095,1099,1103],{"id":1092,"name":1093,"slug":1094},57,"Limites des données","data-boundaries",{"id":1096,"name":1097,"slug":1098},84,"Politique et limites des données","policy-and-data",{"id":1100,"name":1101,"slug":1102},80,"Accès et identité","access-and-identity",{"id":1104,"name":1105,"slug":1106},54,"Modèle de menaces","threat-model",{"id":1108,"login":1109,"email":1110,"displayName":1111},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[1113,1788],{"lang":1114,"title":1115,"content":1116,"contentJson":1117,"excerpt":1787},"en","What Is an AI Solution Architect? System Boundaries, Responsibilities and Trade-offs","{\"time\":1791476244367,\"blocks\":[{\"id\":\"intro\",\"type\":\"paragraph\",\"data\":{\"text\":\"An \u003Cstrong>AI Solution Architect\u003C\u002Fstrong> translates a business or product need into the architecture of a concrete AI-enabled solution. The role defines system boundaries and the significant choices across application logic, authoritative data, retrieval and context, models and providers, tools or agents, identity and permissions, security, runtime and deployment, observability, evaluation, cost and operational behavior. It is not simply model selection or prompt engineering: the architectural responsibility is to make the whole solution implementable, governable, testable and operable.\"}},{\"id\":\"direct\",\"type\":\"callout\",\"data\":{\"variant\":\"info\",\"title\":\"Direct answer\",\"body\":\"\u003Cstrong>An AI Solution Architect designs the complete AI-enabled solution, not just the AI model.\u003C\u002Fstrong> The role connects requirements and non-functional requirements to architecture decisions, composes the necessary application\u002Fdata\u002Fmodel\u002Ftool\u002Fruntime layers, makes trust and failure boundaries explicit, and defines how the implemented system will be validated and operated.\"}},{\"id\":\"role-note\",\"type\":\"callout\",\"data\":{\"variant\":\"note\",\"title\":\"Terminology note\",\"body\":\"\u003Cstrong>AI Solution Architect is a practical role label, not a universally standardized job title.\u003C\u002Fstrong> ISO\u002FIEC\u002FIEEE 42010:2022 standardizes concepts for architecture descriptions; it does not define this job role. Organizations can distribute the responsibilities across several people. In this article, the term means the architecture responsibility for one concrete AI-enabled solution or workload.\"}},{\"id\":\"version-note\",\"type\":\"callout\",\"data\":{\"variant\":\"note\",\"title\":\"Current-source note — 8 October 2026\",\"body\":\"The architecture principles here are intentionally vendor-neutral, while current vendor guidance is used as implementation evidence. NIST AI RMF 1.0 is currently under revision; NIST AI 600-1 remains the published Generative AI Profile. Microsoft and AWS guidance cited below reflects current production concerns such as identity, data boundaries, model abstraction, security, observability, evaluation, reliability and cost.\"}},{\"id\":\"toc\",\"type\":\"tableOfContents\",\"data\":{\"title\":\"Contents\",\"minLevel\":2,\"maxLevel\":3}},{\"id\":\"h-meaning\",\"type\":\"header\",\"data\":{\"text\":\"What does an AI Solution Architect actually architect?\",\"level\":2}},{\"id\":\"p-meaning-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"The object of the work is the \u003Cstrong>solution\u003C\u002Fstrong>: the complete socio-technical system that turns a need into useful, controlled behavior. A model may be central to that system, but it is still only one dependency. The same model can participate in a safe internal search assistant, an unsafe over-privileged agent, a low-latency customer feature, or a high-cost prototype that cannot be operated economically. Architecture determines those differences.\"}},{\"id\":\"p-meaning-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"A useful boundary is therefore: \u003Cstrong>business outcome → requirements → system responsibilities → architecture decisions → implementation → validation → operation\u003C\u002Fstrong>. The AI Solution Architect works across this chain while collaborating with product, engineering, data, security, infrastructure, governance and domain specialists.\"}},{\"id\":\"solution-vs-model\",\"type\":\"comparison\",\"data\":{\"title\":\"The solution is wider than the model\",\"layout\":\"table\",\"columns\":[{\"id\":\"model\",\"label\":\"Model-centric question\"},{\"id\":\"solution\",\"label\":\"Solution-architecture question\"}],\"rows\":[{\"id\":\"m1\",\"label\":\"Capability\",\"values\":{\"model\":\"Which model can generate or reason well enough?\",\"solution\":\"Which combination of model, data, application logic, retrieval, tools and controls produces the required behavior?\"}},{\"id\":\"m2\",\"label\":\"Data\",\"values\":{\"model\":\"What context can fit in the prompt?\",\"solution\":\"What is authoritative, who may access it, how is it retrieved, versioned, filtered and cited?\"}},{\"id\":\"m3\",\"label\":\"Security\",\"values\":{\"model\":\"Does the provider offer security features?\",\"solution\":\"What are the trust boundaries, identities, permissions, secrets, data flows and failure containment mechanisms?\"}},{\"id\":\"m4\",\"label\":\"Operations\",\"values\":{\"model\":\"What is the token latency?\",\"solution\":\"How is the complete workload deployed, observed, evaluated, recovered, versioned and cost-controlled?\"}},{\"id\":\"m5\",\"label\":\"Change\",\"values\":{\"model\":\"Can we switch models?\",\"solution\":\"Which dependencies are abstracted, what changes require an ADR, and how do we validate that a replacement still meets requirements?\"}}]}},{\"id\":\"h-simple\",\"type\":\"header\",\"data\":{\"text\":\"The simplest example\",\"level\":2}},{\"id\":\"p-simple-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Imagine a company wants an internal assistant that answers technicians’ questions from maintenance manuals and operating procedures. The visible feature sounds simple: type a question and receive an answer with sources.\"}},{\"id\":\"p-simple-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The architecture question is much larger. Which documents are authoritative? How are users authenticated? Must retrieval respect department or site permissions? Is the answer allowed to use only retrieved evidence? Which model is acceptable for the data classification? Can a cloud provider receive the content? What happens when retrieval finds nothing? How are citations produced? How is answer quality evaluated? What latency and cost are acceptable? Who can see logs, and what may be stored in them?\"}},{\"id\":\"simple-flow\",\"type\":\"processFlow\",\"data\":{\"title\":\"From need to an operable AI solution\",\"orientation\":\"auto\",\"steps\":[{\"label\":\"1. Define the outcome\",\"description\":\"Clarify the user, business value, task boundary and what a successful answer or action means.\"},{\"label\":\"2. Capture requirements\",\"description\":\"Make functional requirements, NFRs, constraints, data rules, risk tolerance and acceptance criteria explicit.\"},{\"label\":\"3. Establish boundaries\",\"description\":\"Identify users, identities, applications, authoritative data, model\u002Fprovider dependencies, tools, external systems and trust zones.\"},{\"label\":\"4. Design the architecture\",\"description\":\"Choose data\u002Fretrieval, model, orchestration, tool, permission, runtime, deployment, fallback and observability patterns.\"},{\"label\":\"5. Record significant decisions\",\"description\":\"Preserve architectural choices, alternatives, trade-offs and consequences so later changes remain understandable.\"},{\"label\":\"6. Implement and integrate\",\"description\":\"Turn the architecture into application code, APIs, policies, infrastructure, workflows and operational controls.\"},{\"label\":\"7. Validate and operate\",\"description\":\"Test quality, security, reliability, cost and user outcomes; monitor the real workload and feed evidence back into decisions.\"}]}},{\"id\":\"h-where-simple-stops\",\"type\":\"header\",\"data\":{\"text\":\"Where the simple example stops\",\"level\":2}},{\"id\":\"p-stop-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"A proof of concept can often skip architecture that production cannot. A developer may hard-code one provider, use a shared API key, place all documents in one index, run retrieval without user-context filtering, log prompts verbatim and judge quality manually. That can demonstrate feasibility, but it does not establish a production architecture.\"}},{\"id\":\"p-stop-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Production introduces constraints that interact: tenant or user isolation, privacy, data residency, throughput, latency, cost, provider quotas, fallback behavior, auditability, model version changes, retrieval quality, tool permissions, incident response and deployment lifecycle. The architect’s job is not to maximize every quality at once; it is to make the trade-offs explicit and design a solution that satisfies the actual priority set.\"}},{\"id\":\"h-responsibility-map\",\"type\":\"header\",\"data\":{\"text\":\"Architecture responsibility map\",\"level\":2}},{\"id\":\"p-resp-intro\",\"type\":\"paragraph\",\"data\":{\"text\":\"The exact split varies by organization, but the following map captures the recurring responsibilities of solution-level AI architecture. The architect may not personally implement every layer; the responsibility is to make the layers fit together coherently and to keep the critical decisions traceable.\"}},{\"id\":\"responsibility-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Architecture area\",\"Questions the AI Solution Architect must resolve\",\"Typical outputs\"],[\"Outcome and scope\",\"Who is the user? What task is in scope? What must the system not do? What constitutes success?\",\"Solution context, capability boundary, acceptance criteria\"],[\"Requirements and NFRs\",\"What quality, security, availability, latency, cost, residency and compliance constraints apply?\",\"Requirement map, NFRs, constraints, validation criteria\"],[\"Application and orchestration\",\"Where does deterministic application logic end and AI behavior begin? How are workflows coordinated?\",\"Component model, APIs, orchestration boundaries, failure paths\"],[\"Authoritative data and retrieval\",\"What is the Source of Truth? How is data ingested, authorized, retrieved, filtered, ranked and cited?\",\"Data flows, retrieval architecture, metadata and authorization rules\"],[\"Model and provider layer\",\"Which capabilities are required? Which provider\u002Fruntime constraints matter? What should be abstracted?\",\"Model\u002Fprovider decision, routing\u002Ffallback policy, abstraction boundary\"],[\"Tools and agents\",\"What actions can the system take? Which actions require approval? How are tool identities and permissions enforced?\",\"Tool contracts, agent boundaries, approval and least-privilege rules\"],[\"Identity and security\",\"Which human and machine identities exist? Where are secrets held? Which trust boundaries are crossed?\",\"Threat\u002Ftrust boundary model, identity propagation, secrets and authorization design\"],[\"Runtime and deployment\",\"Where do components execute? What is local, cloud, edge or hybrid? What network and availability assumptions exist?\",\"Deployment view, runtime topology, environment and connectivity decisions\"],[\"Evaluation and observability\",\"How is quality measured before and after release? What traces, metrics, logs and evidence are needed?\",\"Evaluation plan, telemetry, audit trail, release gates\"],[\"Operations and change\",\"How are models\u002Fprompts\u002Fconfiguration\u002Fdata versions changed, rolled back and supported?\",\"Operational model, lifecycle controls, ADRs, runbooks, change rules\"]]}},{\"id\":\"h-requirements\",\"type\":\"header\",\"data\":{\"text\":\"1. Turn product need into architectural requirements\",\"level\":3}},{\"id\":\"p-requirements-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"AI architecture begins before model selection. The architect first determines what the solution is expected to achieve and under which constraints. This includes functional behavior, but also the NFRs and policies that narrow the design space: security, reliability, latency, privacy, residency, maintainability, cost and operational support.\"}},{\"id\":\"p-requirements-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"This is where A02’s distinction matters: a requirement such as “unauthorized users must not retrieve restricted documents” is not an architecture decision. It is a driver. Decisions about identity propagation, index partitioning, metadata filtering, API boundaries and authorization enforcement are architectural responses that must later be validated.\"}},{\"id\":\"h-data\",\"type\":\"header\",\"data\":{\"text\":\"2. Design authoritative data, retrieval and context\",\"level\":3}},{\"id\":\"p-data-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"AI systems often fail at the boundary between model behavior and enterprise truth. An architect must define which sources are authoritative, what freshness and provenance mean, how access control reaches retrieval, and how retrieved evidence becomes model context. A vector database, embedding model or RAG library is not the architecture by itself.\"}},{\"id\":\"p-data-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Microsoft’s current AI workload guidance makes the same separation explicit: application code should not bypass data-access boundaries; user or tenant context should propagate into retrieval and filtering; grounding data must be designed for searchability while still meeting security and compliance requirements.\"}},{\"id\":\"h-model\",\"type\":\"header\",\"data\":{\"text\":\"3. Treat models and providers as dependencies, not the whole system\",\"level\":3}},{\"id\":\"p-model-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Model selection matters, but it should be driven by required capability and constraints. The architect considers reasoning or generation quality, modality, context limits, latency, data handling, deployment location, provider availability, cost, observability and replacement risk.\"}},{\"id\":\"p-model-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Provider abstraction is not automatically “better architecture.” It adds engineering cost and can hide provider-specific capabilities. It is justified when portability, fallback, policy separation or multi-provider routing is an explicit requirement. Otherwise a direct integration can be the better decision. The point is to make the trade-off intentional.\"}},{\"id\":\"h-tools\",\"type\":\"header\",\"data\":{\"text\":\"4. Architect tools, actions and agent boundaries\",\"level\":3}},{\"id\":\"p-tools-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"When an AI system can call tools, modify data, send messages, run code or operate business systems, the architectural risk changes. Tool access needs its own identity and authorization model. The model’s ability to request an action is not the same as permission to execute it.\"}},{\"id\":\"p-tools-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"For agentic workloads, current AWS guidance emphasizes additional dimensions such as agent identities, tool access, orchestration, human oversight, tracing, failure handling and cost of iterative reasoning loops. These are solution concerns even when a framework hides some of the implementation mechanics.\"}},{\"id\":\"h-security\",\"type\":\"header\",\"data\":{\"text\":\"5. Make trust boundaries and permissions explicit\",\"level\":3}},{\"id\":\"p-security-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"A production AI solution has multiple trust boundaries: browser or client, application backend, AI orchestration, retrieval\u002Fdata services, model providers, tool APIs, local runtimes and external systems. Each boundary should answer: who is calling, on whose behalf, with what credential, for which resource, with what audit trail, and with what failure containment?\"}},{\"id\":\"p-security-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Security cannot be deferred to a “guardrail” around the model. Microsoft’s AI workload guidance explicitly places security across all architecture layers and calls for identity\u002Faccess management, data protection, content controls and lifecycle security. NIST likewise treats governance and risk management as continuous across the AI lifecycle.\"}},{\"id\":\"h-runtime\",\"type\":\"header\",\"data\":{\"text\":\"6. Decide where the system actually runs\",\"level\":3}},{\"id\":\"p-runtime-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"“Local AI,” “cloud AI,” and “hybrid AI” are architectural statements only when the execution and data paths are precise. A local desktop process can still call a cloud model. A cloud-hosted application can retrieve from an on-premises data source. An air-gapped solution has entirely different update, model-distribution and observability constraints.\"}},{\"id\":\"p-runtime-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The architect therefore separates \u003Cstrong>runtime location\u003C\u002Fstrong>, \u003Cstrong>inference location\u003C\u002Fstrong>, \u003Cstrong>data location\u003C\u002Fstrong> and \u003Cstrong>control plane\u003C\u002Fstrong>. Conflating them creates false security and deployment assumptions.\"}},{\"id\":\"h-eval\",\"type\":\"header\",\"data\":{\"text\":\"7. Define evaluation, observability and operational acceptance\",\"level\":3}},{\"id\":\"p-eval-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"AI behavior is partly nondeterministic, so the release definition cannot rely only on conventional unit tests. The architecture needs measurable acceptance: task success, groundedness or citation correctness where relevant, refusal behavior, tool safety, latency, cost, reliability and security tests. The exact metrics depend on the use case.\"}},{\"id\":\"p-eval-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Microsoft’s current Well-Architected AI guidance treats monitoring as continuous and applies it across model behavior, prompts\u002Fcompletions, anomalies, security and production quality gates. AWS similarly treats observability, lifecycle management and model\u002Fprompt traceability as operational architecture concerns.\"}},{\"id\":\"h-artifacts\",\"type\":\"header\",\"data\":{\"text\":\"What should the role produce?\",\"level\":2}},{\"id\":\"p-artifacts-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Architecture is not the slide deck. The useful outputs are the artifacts that let engineering, security, product and operations make consistent decisions and later understand why the system exists in its current form.\"}},{\"id\":\"artifacts-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Artifact\",\"Purpose\"],[\"Solution context and boundary\",\"Shows users, external systems, major responsibilities and what is outside scope\"],[\"Requirement\u002FNFR map\",\"Connects product need and constraints to architecture work and validation\"],[\"Component and data-flow views\",\"Shows application, data\u002Fretrieval, model, tools, identity and runtime interactions\"],[\"Trust and permission model\",\"Makes identities, secrets, authorization, sensitive data and high-risk actions explicit\"],[\"Architecture Decision Records\",\"Preserves significant choices, alternatives, trade-offs, status and consequences\"],[\"Evaluation and acceptance plan\",\"Defines evidence required to claim that the solution meets quality and safety expectations\"],[\"Deployment and operational view\",\"Defines environments, runtime locations, observability, rollback, incident and lifecycle responsibilities\"],[\"Traceability links\",\"Connects requirements, decisions, implementation work, tests and operational evidence\"]]}},{\"id\":\"h-tradeoffs\",\"type\":\"header\",\"data\":{\"text\":\"The work is mostly trade-offs, not “best practice” selection\",\"level\":2}},{\"id\":\"p-tradeoffs-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Architecture exists because desirable qualities conflict. A lower-cost model may reduce quality. A more capable model may increase latency or data-governance constraints. Aggressive caching can improve cost and speed while complicating freshness. More autonomous agents can reduce human effort while increasing blast radius and audit requirements.\"}},{\"id\":\"tradeoff-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Decision\",\"Potential benefit\",\"Potential cost \u002F risk\",\"Architectural question\"],[\"Managed cloud model\",\"Fast adoption, strong managed capabilities\",\"External dependency, data and cost constraints\",\"Does the workload permit the provider\u002Fdata path and meet resilience needs?\"],[\"Local\u002Fself-hosted inference\",\"Control, offline\u002Fprivate options\",\"Hardware, operations, model lifecycle burden\",\"Is the control benefit worth the operational responsibility?\"],[\"Single provider integration\",\"Simpler implementation, full provider features\",\"Higher switching\u002Ffailure concentration\",\"Is portability or fallback actually required?\"],[\"Provider abstraction\",\"Portability, routing and policy separation\",\"Lowest-common-denominator risk, more code\u002Ftests\",\"Which differences must remain visible rather than abstracted?\"],[\"Large context\",\"More information per request\",\"Latency, cost, attention dilution, leakage surface\",\"Should data be retrieved\u002Ffiltered instead of always injected?\"],[\"Powerful tools \u002F autonomy\",\"More end-to-end automation\",\"Higher privilege and failure blast radius\",\"Which actions require least privilege, confirmation or human approval?\"],[\"Strict validation and logging\",\"Better evidence and operations\",\"Latency, storage, privacy and complexity cost\",\"What evidence is required for this risk level?\"]]}},{\"id\":\"h-adjacent\",\"type\":\"header\",\"data\":{\"text\":\"How is this different from adjacent roles?\",\"level\":2}},{\"id\":\"p-adjacent-intro\",\"type\":\"paragraph\",\"data\":{\"text\":\"Titles overlap heavily across companies. The useful distinction is the \u003Cstrong>scope of architecture responsibility\u003C\u002Fstrong>, not the HR label.\"}},{\"id\":\"role-comparison\",\"type\":\"comparison\",\"data\":{\"title\":\"Adjacent roles answer different primary questions\",\"layout\":\"table\",\"columns\":[{\"id\":\"role\",\"label\":\"Role\"},{\"id\":\"focus\",\"label\":\"Primary architecture focus\"}],\"rows\":[{\"id\":\"r1\",\"label\":\"AI Solution Architect\",\"values\":{\"role\":\"One concrete AI-enabled solution\u002Fworkload\",\"focus\":\"How requirements, data, models, tools, security, runtime and operations fit together to deliver the target outcome\"}},{\"id\":\"r2\",\"label\":\"AI Platform Architect\",\"values\":{\"role\":\"Reusable AI platform capabilities across many solutions\",\"focus\":\"Shared provider gateways, model access, identity, evaluation, retrieval services, observability, deployment patterns and developer experience\"}},{\"id\":\"r3\",\"label\":\"Enterprise AI Architect\",\"values\":{\"role\":\"Organization\u002Fportfolio-level target architecture\",\"focus\":\"Capability landscape, governance, integration principles, shared platforms, standards, sourcing and strategic constraints across domains\"}},{\"id\":\"r4\",\"label\":\"AI \u002F ML Engineer\",\"values\":{\"role\":\"Implementation of AI\u002FML behavior and pipelines\",\"focus\":\"Models, data, inference, evaluation, application logic and engineering tasks within the architecture\"}},{\"id\":\"r5\",\"label\":\"Security Architect\",\"values\":{\"role\":\"Security architecture across systems\",\"focus\":\"Threats, identity, authorization, data protection, controls, assurance and compliance boundaries\"}},{\"id\":\"r6\",\"label\":\"Product \u002F Delivery Lead\",\"values\":{\"role\":\"Outcome, scope, prioritization and delivery system\",\"focus\":\"Why\u002Fwhat to build, sequencing, stakeholders, milestones, acceptance and value realization\"}}]}},{\"id\":\"p-adjacent-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"In a small product team, one person may cover several of these scopes. In a large enterprise, they may be separate roles with formal review boards. The architecture responsibility does not disappear when the title changes.\"}},{\"id\":\"h-implementation\",\"type\":\"header\",\"data\":{\"text\":\"Implementation evidence: how these boundaries appear in my own work\",\"level\":2}},{\"id\":\"implementation-boundary\",\"type\":\"callout\",\"data\":{\"variant\":\"success\",\"title\":\"Implementation evidence, not a universal rule\",\"body\":\"The examples below are \u003Cstrong>original implementation\u002Fproject evidence\u003C\u002Fstrong>. They show how I have separated product need, requirements, architecture, runtime, model\u002Fprovider, permissions and validation in real project work. They are not claims that every organization must use the same structure, and they do not imply customer adoption or enterprise-scale deployment.\"}},{\"id\":\"h-senseflow\",\"type\":\"header\",\"data\":{\"text\":\"SenseFlow: need → requirements → architecture → validation\",\"level\":3}},{\"id\":\"p-senseflow-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"In the SenseFlow project Source of Truth, technology is explicitly subordinate to Product Vision. The development structure moves from problem and product vision through user needs, value, scope, epics, stories and acceptance criteria into architecture, implementation, validation and iteration.\"}},{\"id\":\"p-senseflow-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Requirements are designed to be traceable from Product Goal → Capability → Epic → User Story → Acceptance Criteria → Technical Tasks. Where practical, they include functional requirements, NFRs, dependencies, risks, assumptions, acceptance criteria and validation methods. Significant decisions preserve the decision, reason, alternatives, trade-offs, status and date\u002Fversion.\"}},{\"id\":\"p-senseflow-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"That is architectural work before a specific AI framework or model is chosen: it protects the connection between product intent and technical decisions and makes later change reviewable rather than implicit.\"}},{\"id\":\"h-client\",\"type\":\"header\",\"data\":{\"text\":\"Aaasaasa AI Client: separate concepts before integrating them\",\"level\":3}},{\"id\":\"p-client-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Aaasaasa AI Client provides a more implementation-level example. Its AI Hub deliberately separates \u003Cstrong>agent\u002Fclient\u003C\u002Fstrong>, \u003Cstrong>provider\u003C\u002Fstrong>, \u003Cstrong>model\u003C\u002Fstrong>, \u003Cstrong>connection\u002Fruntime location\u003C\u002Fstrong>, \u003Cstrong>permissions\u003C\u002Fstrong> and \u003Cstrong>web client\u003C\u002Fstrong>. A local runtime is not assumed to mean local inference, and permissions are treated as runtime\u002Ftool policy rather than as a property of the model.\"}},{\"id\":\"p-client-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The desktop architecture also defines a trust boundary: the Nuxt renderer is untrusted relative to Electron main. A narrow preload and validated IPC mediate access to AI services, settings, encrypted secrets, workspace\u002Fdata services and runtimes. Cloud credentials remain in the privileged main process; renderer code receives normalized state instead of raw secrets or unrestricted operating-system access.\"}},{\"id\":\"p-client-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Routing decisions are similarly architectural. The implementation does not silently fall back from a local route to paid cloud inference; a cloud route requires explicit confirmation. Direct Chat has no filesystem or shell tools by default, while agent execution applies a selected workspace and permission profile. These are solution-level decisions about trust, cost, execution and user expectation—not model features.\"}},{\"id\":\"h-current-frameworks\",\"type\":\"header\",\"data\":{\"text\":\"How current architecture frameworks support this broader scope\",\"level\":2}},{\"id\":\"p-frameworks-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"ISO\u002FIEC\u002FIEEE 42010:2022 provides a general discipline for architecture descriptions across software, systems and enterprises. It is deliberately broader than AI and does not prescribe one architecting method or job title. That makes it useful here as a boundary: AI solution architecture is still architecture, with stakeholder concerns, multiple views and significant relationships that must be expressed clearly.\"}},{\"id\":\"p-frameworks-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"NIST AI RMF 1.0 frames AI risk management through \u003Cstrong>Govern, Map, Measure and Manage\u003C\u002Fstrong> and emphasizes that risk management should be continuous across the AI system lifecycle. The Generative AI Profile (NIST AI 600-1) adapts that framework to GAI risks and organizational priorities. This reinforces that architecture cannot stop at functional model performance.\"}},{\"id\":\"p-frameworks-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Microsoft’s current Azure Well-Architected AI guidance separates application design, application platform, training data, grounding data and data platform concerns and repeatedly connects them to reliability, security, operational excellence, performance and cost. AWS’s Generative AI and Agentic AI lenses similarly treat observability, security, reliability, model\u002Ftool lifecycle, cost and human oversight as architecture concerns.\"}},{\"id\":\"h-misconceptions\",\"type\":\"header\",\"data\":{\"text\":\"Common misconceptions\",\"level\":2}},{\"id\":\"misconceptions-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Misconception\",\"Correction\"],[\"“The architect chooses the LLM.”\",\"Model choice is one decision inside a larger solution architecture.\"],[\"“Prompt engineering is the architecture.”\",\"Prompts affect behavior, but they do not define identity, data access, trust boundaries, deployment, tool permissions or operations.\"],[\"“RAG solves enterprise knowledge.”\",\"Retrieval is only one subsystem; authorization, provenance, freshness, evidence, indexing, evaluation and source governance still need design.\"],[\"“Local runtime means private\u002Flocal AI.”\",\"Runtime, inference, data and control-plane locations are separate architectural properties.\"],[\"“If a vendor offers guardrails, security is covered.”\",\"Security spans identity, authorization, secrets, data flows, tools, logging, deployment, human approval and provider boundaries.\"],[\"“The architect must write every component.”\",\"Hands-on implementation can improve architectural quality, but the role is defined by integrated decision responsibility, not by personally coding every layer.\"],[\"“An architecture diagram proves production readiness.”\",\"Readiness requires implemented controls and validation evidence across quality, security, operations and business acceptance.\"]]}},{\"id\":\"h-failures\",\"type\":\"header\",\"data\":{\"text\":\"Failure modes an AI Solution Architect should prevent\",\"level\":2}},{\"id\":\"failures-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Failure mode\",\"Why it happens\",\"Architectural correction\"],[\"Model-first design\",\"A promising model demo becomes the system blueprint\",\"Start from outcome, constraints and validation; select the model inside that frame\"],[\"Prototype permissions in production\",\"Shared credentials and broad access survive the PoC\",\"Define identity propagation, least privilege, tool scopes and approval boundaries early\"],[\"Retrieval without authorization\",\"Search quality is designed before data-access rules\",\"Carry user\u002Ftenant context into retrieval and enforce authorization at data-access boundaries\"],[\"Silent provider\u002Fruntime assumptions\",\"“Local”, “cloud” and “offline” are used imprecisely\",\"Document runtime, inference, data and control-plane location separately\"],[\"No failure contract\",\"The happy path is designed but refusal\u002Ffallback\u002Ferror behavior is not\",\"Specify retrieval-empty, model-unavailable, tool-failure and policy-denied behavior\"],[\"Evaluation after implementation\",\"Quality is judged manually near launch\",\"Define measurable acceptance and representative evaluation sets before architecture freezes\"],[\"Untraceable change\",\"Models, prompts, retrieval or permissions change without architectural history\",\"Version critical configuration and record significant decisions\u002Fvalidation evidence\"],[\"Operations treated as infrastructure only\",\"AI behavior is not observable after deployment\",\"Design traces, quality metrics, security events, cost telemetry and rollback together\"]]}},{\"id\":\"h-decision-framework\",\"type\":\"header\",\"data\":{\"text\":\"A practical decision sequence\",\"level\":2}},{\"id\":\"decision-flow\",\"type\":\"processFlow\",\"data\":{\"title\":\"AI solution architecture decision sequence\",\"orientation\":\"auto\",\"steps\":[{\"label\":\"Outcome\",\"description\":\"Define the user\u002Fbusiness result and explicit non-goals.\"},{\"label\":\"Evidence and constraints\",\"description\":\"Identify authoritative data, policies, NFRs, risks and acceptance conditions.\"},{\"label\":\"System boundary\",\"description\":\"Map users, identities, applications, data, models\u002Fproviders, tools and external systems.\"},{\"label\":\"Architecture options\",\"description\":\"Compare patterns for retrieval, model access, orchestration, deployment, permissions, evaluation and observability.\"},{\"label\":\"Trade-off decisions\",\"description\":\"Select significant options and preserve the rationale, alternatives and consequences.\"},{\"label\":\"Implementation contracts\",\"description\":\"Turn decisions into APIs, schemas, permission rules, deployment definitions and engineering tasks.\"},{\"label\":\"Validation\",\"description\":\"Test the implemented system against the original functional and non-functional requirements.\"},{\"label\":\"Operational feedback\",\"description\":\"Use production evidence, incidents, quality metrics and cost\u002Fsecurity signals to trigger controlled change.\"}]}},{\"id\":\"h-edge\",\"type\":\"header\",\"data\":{\"text\":\"Edge cases and limits of the role\",\"level\":2}},{\"id\":\"p-edge-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Some AI products are dominated by model training, scientific experimentation or specialized hardware. In those cases, model\u002Fdata science and ML systems architecture can become much deeper than the solution-level map shown here. The AI Solution Architect still needs integration and operational boundaries, but specialist architecture may own the training platform itself.\"}},{\"id\":\"p-edge-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"At the other extreme, a simple SaaS integration may not justify a dedicated architect. A senior engineer or technical product lead can carry the same architecture responsibility. The useful test is not the title but whether significant cross-layer decisions are being made deliberately and validated.\"}},{\"id\":\"p-edge-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Regulated, sovereign, air-gapped, safety-critical, highly autonomous or multi-tenant systems also shift the center of gravity. Identity, isolation, residency, assurance, update mechanisms, human oversight and auditability may dominate model quality in the architecture.\"}},{\"id\":\"h-change-answer\",\"type\":\"header\",\"data\":{\"text\":\"What would change this answer?\",\"level\":2}},{\"id\":\"p-change-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"The exact responsibility boundary changes when architecture moves from one application to a reusable platform or to enterprise-wide target architecture. That is why \u003Cstrong>AI Platform Architect\u003C\u002Fstrong> and \u003Cstrong>Enterprise AI Architecture\u003C\u002Fstrong> deserve separate canonical treatment rather than being merged into this role.\"}},{\"id\":\"p-change-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Technology changes also matter. New model capabilities, protocols, local runtimes and managed services can remove some implementation work while creating new trust or operational boundaries. The stable responsibility is to understand those changes as system changes—not to treat a new framework as a replacement for architecture.\"}},{\"id\":\"h-checklist\",\"type\":\"header\",\"data\":{\"text\":\"AI Solution Architect checklist\",\"level\":2}},{\"id\":\"checklist-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Check\",\"Question\"],[\"Outcome\",\"Is the user\u002Fbusiness result and non-goal boundary explicit?\"],[\"Requirements\",\"Are functional requirements, NFRs, constraints and acceptance criteria traceable?\"],[\"Data\",\"Are authoritative sources, provenance, freshness, retention and access rules defined?\"],[\"Retrieval\u002Fcontext\",\"Does authorization reach retrieval and context construction?\"],[\"Model\u002Fprovider\",\"Is model\u002Fprovider selection tied to capabilities and constraints rather than preference?\"],[\"Tools\u002Fagents\",\"Are action boundaries, permissions, approvals and failure behavior explicit?\"],[\"Identity\u002Fsecurity\",\"Are human\u002Fmachine identities, secrets and trust boundaries defined?\"],[\"Runtime\",\"Are runtime, inference, data and control-plane locations distinguished?\"],[\"Evaluation\",\"Is there measurable evidence for quality, security and acceptance?\"],[\"Observability\",\"Can production behavior, failures, cost and security events be investigated?\"],[\"Change\",\"Are significant architecture decisions and replacements traceable?\"],[\"Operations\",\"Is ownership for deployment, rollback, incidents and lifecycle clear?\"]]}},{\"id\":\"h-conclusion\",\"type\":\"header\",\"data\":{\"text\":\"Conclusion\",\"level\":2}},{\"id\":\"p-conclusion-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"An AI Solution Architect is the person or architecture function that turns an AI opportunity into a coherent technical system. The key skill is not knowing the most model names; it is connecting product need, requirements, data, application architecture, AI capabilities, security, runtime, delivery and validation without losing the boundaries between them.\"}},{\"id\":\"p-conclusion-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"A strong AI solution architecture can therefore be summarized as: \u003Cstrong>define the target → establish requirements and constraints → design the system boundaries → make significant trade-offs explicit → implement through clear contracts → validate against evidence → operate and evolve deliberately.\u003C\u002Fstrong> The model is important. The solution is the product.\"}},{\"id\":\"faq\",\"type\":\"faq\",\"data\":{\"title\":\"AI Solution Architect — FAQ\",\"items\":[{\"id\":\"faq1\",\"question\":\"What is an AI Solution Architect?\",\"answer\":\"An AI Solution Architect translates a business or product need into the architecture of a concrete AI-enabled solution, defining how application logic, data\u002Fretrieval, models, tools, identity, security, runtime, evaluation and operations work together.\"},{\"id\":\"faq2\",\"question\":\"Is an AI Solution Architect the same as an AI engineer?\",\"answer\":\"No. The roles can overlap, especially in small teams, but an AI engineer is primarily an implementation role while the solution architect owns or coordinates cross-layer architecture decisions and trade-offs for the complete workload.\"},{\"id\":\"faq3\",\"question\":\"Does an AI Solution Architect need to code?\",\"answer\":\"Not by definition, but hands-on implementation knowledge is highly valuable because AI architecture crosses APIs, data, retrieval, security, runtimes and operational behavior. The role is defined by architecture responsibility, not by writing every component personally.\"},{\"id\":\"faq4\",\"question\":\"Is choosing an LLM the main job?\",\"answer\":\"No. Model selection is one decision. Production architecture also needs data and retrieval boundaries, permissions, tools, provider\u002Fruntime choices, observability, evaluation, reliability, cost and lifecycle design.\"},{\"id\":\"faq5\",\"question\":\"What is the difference between an AI Solution Architect and an AI Platform Architect?\",\"answer\":\"An AI Solution Architect focuses on one concrete solution or workload. An AI Platform Architect focuses on reusable AI capabilities and guardrails that support multiple solutions.\"},{\"id\":\"faq6\",\"question\":\"What is the difference between an AI Solution Architect and an Enterprise AI Architect?\",\"answer\":\"The solution architect works at application\u002Fworkload scope. Enterprise AI architecture works across the organizational portfolio, target architecture, governance, shared capabilities, integration principles and strategic constraints.\"},{\"id\":\"faq7\",\"question\":\"Where do RAG and agents fit?\",\"answer\":\"They are architectural patterns or subsystems inside a solution when the requirements justify them. RAG addresses retrieval-grounded context; agents add planning\u002Ftool execution and therefore additional identity, permission, orchestration and operational concerns.\"},{\"id\":\"faq8\",\"question\":\"What proves that the architecture works?\",\"answer\":\"Implementation plus validation evidence: functional tests, evaluation results, security\u002Fauthorization tests, performance and reliability measurements, observability, operational rehearsal and acceptance against the original requirements.\"}]}},{\"id\":\"glossary\",\"type\":\"glossary\",\"data\":{\"title\":\"Core terms\",\"entries\":[{\"term\":\"AI Solution Architect\",\"definition\":\"Architecture responsibility for one concrete AI-enabled solution or workload, integrating product requirements with application, data, model, tool, security, runtime and operational design.\",\"anchor\":\"ai-solution-architect\"},{\"term\":\"System boundary\",\"definition\":\"The explicit separation between what belongs to the solution and the users, systems, providers, data sources and environments it interacts with.\",\"anchor\":\"system-boundary\"},{\"term\":\"Trust boundary\",\"definition\":\"A point where data, identities or control cross between components with different trust assumptions and therefore require explicit security controls.\",\"anchor\":\"trust-boundary\"},{\"term\":\"Grounding\",\"definition\":\"Supplying an AI model with relevant external information or evidence so its response can be based on sources beyond model parameters.\",\"anchor\":\"grounding\"},{\"term\":\"Provider abstraction\",\"definition\":\"An application boundary that decouples parts of the solution from one model\u002Fprovider interface. Useful when justified by routing, portability or policy needs, but not free of trade-offs.\",\"anchor\":\"provider-abstraction\"},{\"term\":\"Evaluation\",\"definition\":\"Structured measurement of AI workload behavior against defined acceptance criteria, including task quality and relevant safety, security, performance and operational properties.\",\"anchor\":\"evaluation\"},{\"term\":\"AI Platform Architect\",\"definition\":\"Architectural role focused on reusable AI platform capabilities used by multiple solutions rather than the architecture of one workload.\",\"anchor\":\"ai-platform-architect\"},{\"term\":\"Enterprise AI Architecture\",\"definition\":\"Organization-level architecture that coordinates AI capabilities, platforms, governance, integration and strategic constraints across a portfolio.\",\"anchor\":\"enterprise-ai-architecture\"}]}},{\"id\":\"h-related\",\"type\":\"header\",\"data\":{\"text\":\"Related canonical knowledge\",\"level\":2}},{\"id\":\"p-related-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"This article sits in the AI Architecture Foundations cluster. Its direct foundations are \u003Cstrong>Generative AI Explained: Models, Retrieval, Tools and Applications Are Not the Same Thing\u003C\u002Fstrong> and \u003Cstrong>ADR vs NFR: Architecture Decisions and System Quality Are Not the Same Thing\u003C\u002Fstrong>. Adjacent canonical nodes include \u003Cstrong>Agentic AI Explained\u003C\u002Fstrong>, \u003Cstrong>Source of Truth in AI Systems\u003C\u002Fstrong>, \u003Cstrong>Vector Databases, Embeddings and Reranking\u003C\u002Fstrong>, \u003Cstrong>What Is Context Engineering?\u003C\u002Fstrong>, \u003Cstrong>RBAC vs Tenant Isolation\u003C\u002Fstrong>, \u003Cstrong>AI Platform Architect\u003C\u002Fstrong>, \u003Cstrong>Enterprise AI Architecture\u003C\u002Fstrong> and \u003Cstrong>AI Governance\u003C\u002Fstrong>. URLs are intentionally not fabricated where those nodes are not yet published.\"}},{\"id\":\"related-rag\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fstajic.de\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works\",\"meta\":{\"title\":\"What Is RAG? The Simplest Explanation of How It Works\",\"description\":\"Existing stajic.de canonical explanation of retrieval-augmented generation, useful for the retrieval\u002Fgrounding part of AI solution architecture.\",\"image\":{\"url\":\"\"}}}},{\"id\":\"h-sources\",\"type\":\"header\",\"data\":{\"text\":\"Primary sources and current architecture guidance\",\"level\":2}},{\"id\":\"p-sources-note\",\"type\":\"paragraph\",\"data\":{\"text\":\"External sources below support the general architecture claims; the SenseFlow and Aaasaasa AI Client sections are explicitly original project\u002Fimplementation evidence. Current-state references were checked on 8 October 2026. NIST notes that AI RMF 1.0 is being revised, so version-sensitive governance references should be rechecked when a successor is published.\"}},{\"id\":\"src-iso-42010\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html\",\"meta\":{\"title\":\"ISO\u002FIEC\u002FIEEE 42010:2022 — Architecture Description\",\"description\":\"Current international standard for the structure and expression of architecture descriptions. It distinguishes architecture from its description and does not prescribe one architecting method, tool or recording format.\",\"image\":{\"url\":\"\"}}}},{\"id\":\"src-nist-rmf\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.nist.gov\u002Fitl\u002Fai-risk-management-framework\",\"meta\":{\"title\":\"NIST AI Risk Management Framework\",\"description\":\"NIST’s AI RMF resource page. As of October 2026 it states that AI RMF 1.0 is being revised and links the Generative AI Profile and related resources.\",\"image\":{\"url\":\"\"}}}},{\"id\":\"src-nist-core\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fairc.nist.gov\u002Fairmf-resources\u002Fairmf\u002F5-sec-core\u002F\",\"meta\":{\"title\":\"NIST AI RMF Core — Govern, Map, Measure, Manage\",\"description\":\"Official NIST AIRC presentation of the AI RMF 1.0 Core, including the four functions and lifecycle-oriented risk-management framing.\",\"image\":{\"url\":\"\"}}}},{\"id\":\"src-nist-gai\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.nist.gov\u002Fpublications\u002Fartificial-intelligence-risk-management-framework-generative-artificial-intelligence\",\"meta\":{\"title\":\"NIST AI 600-1 — Generative AI Profile\",\"description\":\"Cross-sectoral Generative AI profile for AI RMF 1.0, published 26 July 2024 and updated by NIST in 2026.\",\"image\":{\"url\":\"\"}}}},{\"id\":\"src-ms-start\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fget-started\",\"meta\":{\"title\":\"Microsoft Azure Well-Architected — AI Workloads\",\"description\":\"Current workload-level architecture guidance covering AI application design, application platform, training data, grounding data, data platform and production-readiness concerns.\",\"image\":{\"url\":\"\"}}}},{\"id\":\"src-ms-app\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fapplication-design\",\"meta\":{\"title\":\"Microsoft — Application Design for AI Workloads\",\"description\":\"Guidance on model\u002Ftool abstraction, data-access boundaries, identity propagation, authorization and separation of client, intelligence, knowledge and tool layers.\",\"image\":{\"url\":\"\"}}}},{\"id\":\"src-ms-security\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fdesign-principles\",\"meta\":{\"title\":\"Microsoft — Design Principles for AI Workloads\",\"description\":\"Current AI workload design principles across reliability, security, cost, operational excellence and performance, including identity and data-protection responsibilities.\",\"image\":{\"url\":\"\"}}}},{\"id\":\"src-ms-ops\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fmlops-genaiops\",\"meta\":{\"title\":\"Microsoft — MLOps and GenAIOps for AI Workloads\",\"description\":\"Production lifecycle guidance covering monitoring, quality gates, model\u002Fprompt behavior, security and operational measurement.\",\"image\":{\"url\":\"\"}}}},{\"id\":\"src-aws-genai\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fgenerative-ai-lens\u002F\",\"meta\":{\"title\":\"AWS Well-Architected Generative AI Lens\",\"description\":\"AWS architectural guidance for generative AI workloads across operational excellence, security, reliability, performance efficiency, cost optimization and sustainability.\",\"image\":{\"url\":\"\"}}}},{\"id\":\"src-aws-agentic\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fagentic-ai-lens\u002F\",\"meta\":{\"title\":\"AWS Well-Architected Agentic AI Lens\",\"description\":\"Published in 2026, covering agentic-specific architecture concerns including identities, tools, orchestration, human oversight, reliability, tracing and reasoning-loop cost.\",\"image\":{\"url\":\"\"}}}}],\"version\":\"2.31.0\"}",{"time":1118,"blocks":1119,"version":1786},1791476244367,[1120,1123,1127,1131,1135,1138,1141,1144,1147,1171,1174,1177,1180,1205,1208,1211,1214,1217,1220,1267,1270,1273,1276,1279,1282,1285,1288,1291,1294,1297,1300,1303,1306,1309,1312,1315,1318,1321,1324,1327,1330,1333,1336,1366,1369,1372,1415,1418,1421,1446,1449,1452,1456,1459,1462,1465,1468,1471,1474,1477,1480,1483,1486,1489,1492,1495,1521,1524,1563,1566,1593,1596,1599,1602,1605,1608,1611,1614,1617,1654,1656,1659,1662,1689,1711,1714,1717,1723,1726,1729,1734,1740,1746,1752,1758,1764,1770,1776,1781],{"id":215,"data":1121,"type":218},{"text":1122},"An \u003Cstrong>AI Solution Architect\u003C\u002Fstrong> translates a business or product need into the architecture of a concrete AI-enabled solution. The role defines system boundaries and the significant choices across application logic, authoritative data, retrieval and context, models and providers, tools or agents, identity and permissions, security, runtime and deployment, observability, evaluation, cost and operational behavior. It is not simply model selection or prompt engineering: the architectural responsibility is to make the whole solution implementable, governable, testable and operable.",{"id":220,"data":1124,"type":225},{"body":1125,"title":1126,"variant":224},"\u003Cstrong>An AI Solution Architect designs the complete AI-enabled solution, not just the AI model.\u003C\u002Fstrong> The role connects requirements and non-functional requirements to architecture decisions, composes the necessary application\u002Fdata\u002Fmodel\u002Ftool\u002Fruntime layers, makes trust and failure boundaries explicit, and defines how the implemented system will be validated and operated.","Direct answer",{"id":227,"data":1128,"type":225},{"body":1129,"title":1130,"variant":231},"\u003Cstrong>AI Solution Architect is a practical role label, not a universally standardized job title.\u003C\u002Fstrong> ISO\u002FIEC\u002FIEEE 42010:2022 standardizes concepts for architecture descriptions; it does not define this job role. Organizations can distribute the responsibilities across several people. In this article, the term means the architecture responsibility for one concrete AI-enabled solution or workload.","Terminology note",{"id":233,"data":1132,"type":225},{"body":1133,"title":1134,"variant":231},"The architecture principles here are intentionally vendor-neutral, while current vendor guidance is used as implementation evidence. NIST AI RMF 1.0 is currently under revision; NIST AI 600-1 remains the published Generative AI Profile. Microsoft and AWS guidance cited below reflects current production concerns such as identity, data boundaries, model abstraction, security, observability, evaluation, reliability and cost.","Current-source note — 8 October 2026",{"id":238,"data":1136,"type":243},{"title":1137,"maxLevel":241,"minLevel":242},"Contents",{"id":245,"data":1139,"type":42},{"text":1140,"level":242},"What does an AI Solution Architect actually architect?",{"id":249,"data":1142,"type":218},{"text":1143},"The object of the work is the \u003Cstrong>solution\u003C\u002Fstrong>: the complete socio-technical system that turns a need into useful, controlled behavior. A model may be central to that system, but it is still only one dependency. The same model can participate in a safe internal search assistant, an unsafe over-privileged agent, a low-latency customer feature, or a high-cost prototype that cannot be operated economically. Architecture determines those differences.",{"id":253,"data":1145,"type":218},{"text":1146},"A useful boundary is therefore: \u003Cstrong>business outcome → requirements → system responsibilities → architecture decisions → implementation → validation → operation\u003C\u002Fstrong>. The AI Solution Architect works across this chain while collaborating with product, engineering, data, security, infrastructure, governance and domain specialists.",{"id":257,"data":1148,"type":299},{"rows":1149,"title":1165,"layout":291,"columns":1166},[1150,1153,1156,1159,1162],{"id":261,"label":1151,"values":1152},"Capability",{"model":264,"solution":265},{"id":267,"label":1154,"values":1155},"Data",{"model":270,"solution":271},{"id":273,"label":1157,"values":1158},"Security",{"model":276,"solution":277},{"id":279,"label":1160,"values":1161},"Operations",{"model":282,"solution":283},{"id":285,"label":1163,"values":1164},"Change",{"model":288,"solution":289},"The solution is wider than the model",[1167,1169],{"id":294,"label":1168},"Model-centric question",{"id":297,"label":1170},"Solution-architecture question",{"id":301,"data":1172,"type":42},{"text":1173,"level":242},"The simplest example",{"id":305,"data":1175,"type":218},{"text":1176},"Imagine a company wants an internal assistant that answers technicians’ questions from maintenance manuals and operating procedures. The visible feature sounds simple: type a question and receive an answer with sources.",{"id":309,"data":1178,"type":218},{"text":1179},"The architecture question is much larger. Which documents are authoritative? How are users authenticated? Must retrieval respect department or site permissions? Is the answer allowed to use only retrieved evidence? Which model is acceptable for the data classification? Can a cloud provider receive the content? What happens when retrieval finds nothing? How are citations produced? How is answer quality evaluated? What latency and cost are acceptable? Who can see logs, and what may be stored in them?",{"id":313,"data":1181,"type":339},{"steps":1182,"title":1204,"orientation":338},[1183,1186,1189,1192,1195,1198,1201],{"label":1184,"description":1185},"1. Define the outcome","Clarify the user, business value, task boundary and what a successful answer or action means.",{"label":1187,"description":1188},"2. Capture requirements","Make functional requirements, NFRs, constraints, data rules, risk tolerance and acceptance criteria explicit.",{"label":1190,"description":1191},"3. Establish boundaries","Identify users, identities, applications, authoritative data, model\u002Fprovider dependencies, tools, external systems and trust zones.",{"label":1193,"description":1194},"4. Design the architecture","Choose data\u002Fretrieval, model, orchestration, tool, permission, runtime, deployment, fallback and observability patterns.",{"label":1196,"description":1197},"5. Record significant decisions","Preserve architectural choices, alternatives, trade-offs and consequences so later changes remain understandable.",{"label":1199,"description":1200},"6. Implement and integrate","Turn the architecture into application code, APIs, policies, infrastructure, workflows and operational controls.",{"label":1202,"description":1203},"7. Validate and operate","Test quality, security, reliability, cost and user outcomes; monitor the real workload and feed evidence back into decisions.","From need to an operable AI solution",{"id":341,"data":1206,"type":42},{"text":1207,"level":242},"Where the simple example stops",{"id":345,"data":1209,"type":218},{"text":1210},"A proof of concept can often skip architecture that production cannot. A developer may hard-code one provider, use a shared API key, place all documents in one index, run retrieval without user-context filtering, log prompts verbatim and judge quality manually. That can demonstrate feasibility, but it does not establish a production architecture.",{"id":349,"data":1212,"type":218},{"text":1213},"Production introduces constraints that interact: tenant or user isolation, privacy, data residency, throughput, latency, cost, provider quotas, fallback behavior, auditability, model version changes, retrieval quality, tool permissions, incident response and deployment lifecycle. The architect’s job is not to maximize every quality at once; it is to make the trade-offs explicit and design a solution that satisfies the actual priority set.",{"id":353,"data":1215,"type":42},{"text":1216,"level":242},"Architecture responsibility map",{"id":357,"data":1218,"type":218},{"text":1219},"The exact split varies by organization, but the following map captures the recurring responsibilities of solution-level AI architecture. The architect may not personally implement every layer; the responsibility is to make the layers fit together coherently and to keep the critical decisions traceable.",{"id":361,"data":1221,"type":291},{"content":1222,"stretched":43,"withHeadings":14},[1223,1227,1231,1235,1239,1243,1247,1251,1255,1259,1263],[1224,1225,1226],"Architecture area","Questions the AI Solution Architect must resolve","Typical outputs",[1228,1229,1230],"Outcome and scope","Who is the user? What task is in scope? What must the system not do? What constitutes success?","Solution context, capability boundary, acceptance criteria",[1232,1233,1234],"Requirements and NFRs","What quality, security, availability, latency, cost, residency and compliance constraints apply?","Requirement map, NFRs, constraints, validation criteria",[1236,1237,1238],"Application and orchestration","Where does deterministic application logic end and AI behavior begin? How are workflows coordinated?","Component model, APIs, orchestration boundaries, failure paths",[1240,1241,1242],"Authoritative data and retrieval","What is the Source of Truth? How is data ingested, authorized, retrieved, filtered, ranked and cited?","Data flows, retrieval architecture, metadata and authorization rules",[1244,1245,1246],"Model and provider layer","Which capabilities are required? Which provider\u002Fruntime constraints matter? What should be abstracted?","Model\u002Fprovider decision, routing\u002Ffallback policy, abstraction boundary",[1248,1249,1250],"Tools and agents","What actions can the system take? Which actions require approval? How are tool identities and permissions enforced?","Tool contracts, agent boundaries, approval and least-privilege rules",[1252,1253,1254],"Identity and security","Which human and machine identities exist? Where are secrets held? Which trust boundaries are crossed?","Threat\u002Ftrust boundary model, identity propagation, secrets and authorization design",[1256,1257,1258],"Runtime and deployment","Where do components execute? What is local, cloud, edge or hybrid? What network and availability assumptions exist?","Deployment view, runtime topology, environment and connectivity decisions",[1260,1261,1262],"Evaluation and observability","How is quality measured before and after release? What traces, metrics, logs and evidence are needed?","Evaluation plan, telemetry, audit trail, release gates",[1264,1265,1266],"Operations and change","How are models\u002Fprompts\u002Fconfiguration\u002Fdata versions changed, rolled back and supported?","Operational model, lifecycle controls, ADRs, runbooks, change rules",{"id":409,"data":1268,"type":42},{"text":1269,"level":241},"1. Turn product need into architectural requirements",{"id":413,"data":1271,"type":218},{"text":1272},"AI architecture begins before model selection. The architect first determines what the solution is expected to achieve and under which constraints. This includes functional behavior, but also the NFRs and policies that narrow the design space: security, reliability, latency, privacy, residency, maintainability, cost and operational support.",{"id":417,"data":1274,"type":218},{"text":1275},"This is where A02’s distinction matters: a requirement such as “unauthorized users must not retrieve restricted documents” is not an architecture decision. It is a driver. Decisions about identity propagation, index partitioning, metadata filtering, API boundaries and authorization enforcement are architectural responses that must later be validated.",{"id":421,"data":1277,"type":42},{"text":1278,"level":241},"2. Design authoritative data, retrieval and context",{"id":425,"data":1280,"type":218},{"text":1281},"AI systems often fail at the boundary between model behavior and enterprise truth. An architect must define which sources are authoritative, what freshness and provenance mean, how access control reaches retrieval, and how retrieved evidence becomes model context. A vector database, embedding model or RAG library is not the architecture by itself.",{"id":429,"data":1283,"type":218},{"text":1284},"Microsoft’s current AI workload guidance makes the same separation explicit: application code should not bypass data-access boundaries; user or tenant context should propagate into retrieval and filtering; grounding data must be designed for searchability while still meeting security and compliance requirements.",{"id":433,"data":1286,"type":42},{"text":1287,"level":241},"3. Treat models and providers as dependencies, not the whole system",{"id":437,"data":1289,"type":218},{"text":1290},"Model selection matters, but it should be driven by required capability and constraints. The architect considers reasoning or generation quality, modality, context limits, latency, data handling, deployment location, provider availability, cost, observability and replacement risk.",{"id":441,"data":1292,"type":218},{"text":1293},"Provider abstraction is not automatically “better architecture.” It adds engineering cost and can hide provider-specific capabilities. It is justified when portability, fallback, policy separation or multi-provider routing is an explicit requirement. Otherwise a direct integration can be the better decision. The point is to make the trade-off intentional.",{"id":445,"data":1295,"type":42},{"text":1296,"level":241},"4. Architect tools, actions and agent boundaries",{"id":449,"data":1298,"type":218},{"text":1299},"When an AI system can call tools, modify data, send messages, run code or operate business systems, the architectural risk changes. Tool access needs its own identity and authorization model. The model’s ability to request an action is not the same as permission to execute it.",{"id":453,"data":1301,"type":218},{"text":1302},"For agentic workloads, current AWS guidance emphasizes additional dimensions such as agent identities, tool access, orchestration, human oversight, tracing, failure handling and cost of iterative reasoning loops. These are solution concerns even when a framework hides some of the implementation mechanics.",{"id":457,"data":1304,"type":42},{"text":1305,"level":241},"5. Make trust boundaries and permissions explicit",{"id":461,"data":1307,"type":218},{"text":1308},"A production AI solution has multiple trust boundaries: browser or client, application backend, AI orchestration, retrieval\u002Fdata services, model providers, tool APIs, local runtimes and external systems. Each boundary should answer: who is calling, on whose behalf, with what credential, for which resource, with what audit trail, and with what failure containment?",{"id":465,"data":1310,"type":218},{"text":1311},"Security cannot be deferred to a “guardrail” around the model. Microsoft’s AI workload guidance explicitly places security across all architecture layers and calls for identity\u002Faccess management, data protection, content controls and lifecycle security. NIST likewise treats governance and risk management as continuous across the AI lifecycle.",{"id":469,"data":1313,"type":42},{"text":1314,"level":241},"6. Decide where the system actually runs",{"id":473,"data":1316,"type":218},{"text":1317},"“Local AI,” “cloud AI,” and “hybrid AI” are architectural statements only when the execution and data paths are precise. A local desktop process can still call a cloud model. A cloud-hosted application can retrieve from an on-premises data source. An air-gapped solution has entirely different update, model-distribution and observability constraints.",{"id":477,"data":1319,"type":218},{"text":1320},"The architect therefore separates \u003Cstrong>runtime location\u003C\u002Fstrong>, \u003Cstrong>inference location\u003C\u002Fstrong>, \u003Cstrong>data location\u003C\u002Fstrong> and \u003Cstrong>control plane\u003C\u002Fstrong>. Conflating them creates false security and deployment assumptions.",{"id":481,"data":1322,"type":42},{"text":1323,"level":241},"7. Define evaluation, observability and operational acceptance",{"id":485,"data":1325,"type":218},{"text":1326},"AI behavior is partly nondeterministic, so the release definition cannot rely only on conventional unit tests. The architecture needs measurable acceptance: task success, groundedness or citation correctness where relevant, refusal behavior, tool safety, latency, cost, reliability and security tests. The exact metrics depend on the use case.",{"id":489,"data":1328,"type":218},{"text":1329},"Microsoft’s current Well-Architected AI guidance treats monitoring as continuous and applies it across model behavior, prompts\u002Fcompletions, anomalies, security and production quality gates. AWS similarly treats observability, lifecycle management and model\u002Fprompt traceability as operational architecture concerns.",{"id":493,"data":1331,"type":42},{"text":1332,"level":242},"What should the role produce?",{"id":497,"data":1334,"type":218},{"text":1335},"Architecture is not the slide deck. The useful outputs are the artifacts that let engineering, security, product and operations make consistent decisions and later understand why the system exists in its current form.",{"id":501,"data":1337,"type":291},{"content":1338,"stretched":43,"withHeadings":14},[1339,1342,1345,1348,1351,1354,1357,1360,1363],[1340,1341],"Artifact","Purpose",[1343,1344],"Solution context and boundary","Shows users, external systems, major responsibilities and what is outside scope",[1346,1347],"Requirement\u002FNFR map","Connects product need and constraints to architecture work and validation",[1349,1350],"Component and data-flow views","Shows application, data\u002Fretrieval, model, tools, identity and runtime interactions",[1352,1353],"Trust and permission model","Makes identities, secrets, authorization, sensitive data and high-risk actions explicit",[1355,1356],"Architecture Decision Records","Preserves significant choices, alternatives, trade-offs, status and consequences",[1358,1359],"Evaluation and acceptance plan","Defines evidence required to claim that the solution meets quality and safety expectations",[1361,1362],"Deployment and operational view","Defines environments, runtime locations, observability, rollback, incident and lifecycle responsibilities",[1364,1365],"Traceability links","Connects requirements, decisions, implementation work, tests and operational evidence",{"id":532,"data":1367,"type":42},{"text":1368,"level":242},"The work is mostly trade-offs, not “best practice” selection",{"id":536,"data":1370,"type":218},{"text":1371},"Architecture exists because desirable qualities conflict. A lower-cost model may reduce quality. A more capable model may increase latency or data-governance constraints. Aggressive caching can improve cost and speed while complicating freshness. More autonomous agents can reduce human effort while increasing blast radius and audit requirements.",{"id":540,"data":1373,"type":291},{"content":1374,"stretched":43,"withHeadings":14},[1375,1380,1385,1390,1395,1400,1405,1410],[1376,1377,1378,1379],"Decision","Potential benefit","Potential cost \u002F risk","Architectural question",[1381,1382,1383,1384],"Managed cloud model","Fast adoption, strong managed capabilities","External dependency, data and cost constraints","Does the workload permit the provider\u002Fdata path and meet resilience needs?",[1386,1387,1388,1389],"Local\u002Fself-hosted inference","Control, offline\u002Fprivate options","Hardware, operations, model lifecycle burden","Is the control benefit worth the operational responsibility?",[1391,1392,1393,1394],"Single provider integration","Simpler implementation, full provider features","Higher switching\u002Ffailure concentration","Is portability or fallback actually required?",[1396,1397,1398,1399],"Provider abstraction","Portability, routing and policy separation","Lowest-common-denominator risk, more code\u002Ftests","Which differences must remain visible rather than abstracted?",[1401,1402,1403,1404],"Large context","More information per request","Latency, cost, attention dilution, leakage surface","Should data be retrieved\u002Ffiltered instead of always injected?",[1406,1407,1408,1409],"Powerful tools \u002F autonomy","More end-to-end automation","Higher privilege and failure blast radius","Which actions require least privilege, confirmation or human approval?",[1411,1412,1413,1414],"Strict validation and logging","Better evidence and operations","Latency, storage, privacy and complexity cost","What evidence is required for this risk level?",{"id":584,"data":1416,"type":42},{"text":1417,"level":242},"How is this different from adjacent roles?",{"id":588,"data":1419,"type":218},{"text":1420},"Titles overlap heavily across companies. The useful distinction is the \u003Cstrong>scope of architecture responsibility\u003C\u002Fstrong>, not the HR label.",{"id":592,"data":1422,"type":299},{"rows":1423,"title":1440,"layout":291,"columns":1441},[1424,1426,1428,1431,1434,1437],{"id":596,"label":937,"values":1425},{"role":599,"focus":600},{"id":602,"label":960,"values":1427},{"role":605,"focus":606},{"id":608,"label":1429,"values":1430},"Enterprise AI Architect",{"role":611,"focus":612},{"id":614,"label":1432,"values":1433},"AI \u002F ML Engineer",{"role":617,"focus":618},{"id":620,"label":1435,"values":1436},"Security Architect",{"role":623,"focus":624},{"id":626,"label":1438,"values":1439},"Product \u002F Delivery Lead",{"role":629,"focus":630},"Adjacent roles answer different primary questions",[1442,1444],{"id":634,"label":1443},"Role",{"id":637,"label":1445},"Primary architecture focus",{"id":640,"data":1447,"type":218},{"text":1448},"In a small product team, one person may cover several of these scopes. In a large enterprise, they may be separate roles with formal review boards. The architecture responsibility does not disappear when the title changes.",{"id":644,"data":1450,"type":42},{"text":1451,"level":242},"Implementation evidence: how these boundaries appear in my own work",{"id":648,"data":1453,"type":225},{"body":1454,"title":1455,"variant":652},"The examples below are \u003Cstrong>original implementation\u002Fproject evidence\u003C\u002Fstrong>. They show how I have separated product need, requirements, architecture, runtime, model\u002Fprovider, permissions and validation in real project work. They are not claims that every organization must use the same structure, and they do not imply customer adoption or enterprise-scale deployment.","Implementation evidence, not a universal rule",{"id":654,"data":1457,"type":42},{"text":1458,"level":241},"SenseFlow: need → requirements → architecture → validation",{"id":658,"data":1460,"type":218},{"text":1461},"In the SenseFlow project Source of Truth, technology is explicitly subordinate to Product Vision. The development structure moves from problem and product vision through user needs, value, scope, epics, stories and acceptance criteria into architecture, implementation, validation and iteration.",{"id":662,"data":1463,"type":218},{"text":1464},"Requirements are designed to be traceable from Product Goal → Capability → Epic → User Story → Acceptance Criteria → Technical Tasks. Where practical, they include functional requirements, NFRs, dependencies, risks, assumptions, acceptance criteria and validation methods. Significant decisions preserve the decision, reason, alternatives, trade-offs, status and date\u002Fversion.",{"id":666,"data":1466,"type":218},{"text":1467},"That is architectural work before a specific AI framework or model is chosen: it protects the connection between product intent and technical decisions and makes later change reviewable rather than implicit.",{"id":670,"data":1469,"type":42},{"text":1470,"level":241},"Aaasaasa AI Client: separate concepts before integrating them",{"id":674,"data":1472,"type":218},{"text":1473},"Aaasaasa AI Client provides a more implementation-level example. Its AI Hub deliberately separates \u003Cstrong>agent\u002Fclient\u003C\u002Fstrong>, \u003Cstrong>provider\u003C\u002Fstrong>, \u003Cstrong>model\u003C\u002Fstrong>, \u003Cstrong>connection\u002Fruntime location\u003C\u002Fstrong>, \u003Cstrong>permissions\u003C\u002Fstrong> and \u003Cstrong>web client\u003C\u002Fstrong>. A local runtime is not assumed to mean local inference, and permissions are treated as runtime\u002Ftool policy rather than as a property of the model.",{"id":678,"data":1475,"type":218},{"text":1476},"The desktop architecture also defines a trust boundary: the Nuxt renderer is untrusted relative to Electron main. A narrow preload and validated IPC mediate access to AI services, settings, encrypted secrets, workspace\u002Fdata services and runtimes. Cloud credentials remain in the privileged main process; renderer code receives normalized state instead of raw secrets or unrestricted operating-system access.",{"id":682,"data":1478,"type":218},{"text":1479},"Routing decisions are similarly architectural. The implementation does not silently fall back from a local route to paid cloud inference; a cloud route requires explicit confirmation. Direct Chat has no filesystem or shell tools by default, while agent execution applies a selected workspace and permission profile. These are solution-level decisions about trust, cost, execution and user expectation—not model features.",{"id":686,"data":1481,"type":42},{"text":1482,"level":242},"How current architecture frameworks support this broader scope",{"id":690,"data":1484,"type":218},{"text":1485},"ISO\u002FIEC\u002FIEEE 42010:2022 provides a general discipline for architecture descriptions across software, systems and enterprises. It is deliberately broader than AI and does not prescribe one architecting method or job title. That makes it useful here as a boundary: AI solution architecture is still architecture, with stakeholder concerns, multiple views and significant relationships that must be expressed clearly.",{"id":694,"data":1487,"type":218},{"text":1488},"NIST AI RMF 1.0 frames AI risk management through \u003Cstrong>Govern, Map, Measure and Manage\u003C\u002Fstrong> and emphasizes that risk management should be continuous across the AI system lifecycle. The Generative AI Profile (NIST AI 600-1) adapts that framework to GAI risks and organizational priorities. This reinforces that architecture cannot stop at functional model performance.",{"id":698,"data":1490,"type":218},{"text":1491},"Microsoft’s current Azure Well-Architected AI guidance separates application design, application platform, training data, grounding data and data platform concerns and repeatedly connects them to reliability, security, operational excellence, performance and cost. AWS’s Generative AI and Agentic AI lenses similarly treat observability, security, reliability, model\u002Ftool lifecycle, cost and human oversight as architecture concerns.",{"id":702,"data":1493,"type":42},{"text":1494,"level":242},"Common misconceptions",{"id":706,"data":1496,"type":291},{"content":1497,"stretched":43,"withHeadings":14},[1498,1500,1503,1506,1509,1512,1515,1518],[1499,711],"Misconception",[1501,1502],"“The architect chooses the LLM.”","Model choice is one decision inside a larger solution architecture.",[1504,1505],"“Prompt engineering is the architecture.”","Prompts affect behavior, but they do not define identity, data access, trust boundaries, deployment, tool permissions or operations.",[1507,1508],"“RAG solves enterprise knowledge.”","Retrieval is only one subsystem; authorization, provenance, freshness, evidence, indexing, evaluation and source governance still need design.",[1510,1511],"“Local runtime means private\u002Flocal AI.”","Runtime, inference, data and control-plane locations are separate architectural properties.",[1513,1514],"“If a vendor offers guardrails, security is covered.”","Security spans identity, authorization, secrets, data flows, tools, logging, deployment, human approval and provider boundaries.",[1516,1517],"“The architect must write every component.”","Hands-on implementation can improve architectural quality, but the role is defined by integrated decision responsibility, not by personally coding every layer.",[1519,1520],"“An architecture diagram proves production readiness.”","Readiness requires implemented controls and validation evidence across quality, security, operations and business acceptance.",{"id":734,"data":1522,"type":42},{"text":1523,"level":242},"Failure modes an AI Solution Architect should prevent",{"id":738,"data":1525,"type":291},{"content":1526,"stretched":43,"withHeadings":14},[1527,1531,1535,1539,1543,1547,1551,1555,1559],[1528,1529,1530],"Failure mode","Why it happens","Architectural correction",[1532,1533,1534],"Model-first design","A promising model demo becomes the system blueprint","Start from outcome, constraints and validation; select the model inside that frame",[1536,1537,1538],"Prototype permissions in production","Shared credentials and broad access survive the PoC","Define identity propagation, least privilege, tool scopes and approval boundaries early",[1540,1541,1542],"Retrieval without authorization","Search quality is designed before data-access rules","Carry user\u002Ftenant context into retrieval and enforce authorization at data-access boundaries",[1544,1545,1546],"Silent provider\u002Fruntime assumptions","“Local”, “cloud” and “offline” are used imprecisely","Document runtime, inference, data and control-plane location separately",[1548,1549,1550],"No failure contract","The happy path is designed but refusal\u002Ffallback\u002Ferror behavior is not","Specify retrieval-empty, model-unavailable, tool-failure and policy-denied behavior",[1552,1553,1554],"Evaluation after implementation","Quality is judged manually near launch","Define measurable acceptance and representative evaluation sets before architecture freezes",[1556,1557,1558],"Untraceable change","Models, prompts, retrieval or permissions change without architectural history","Version critical configuration and record significant decisions\u002Fvalidation evidence",[1560,1561,1562],"Operations treated as infrastructure only","AI behavior is not observable after deployment","Design traces, quality metrics, security events, cost telemetry and rollback together",{"id":778,"data":1564,"type":42},{"text":1565,"level":242},"A practical decision sequence",{"id":782,"data":1567,"type":339},{"steps":1568,"title":1592,"orientation":338},[1569,1572,1575,1578,1581,1584,1587,1589],{"label":1570,"description":1571},"Outcome","Define the user\u002Fbusiness result and explicit non-goals.",{"label":1573,"description":1574},"Evidence and constraints","Identify authoritative data, policies, NFRs, risks and acceptance conditions.",{"label":1576,"description":1577},"System boundary","Map users, identities, applications, data, models\u002Fproviders, tools and external systems.",{"label":1579,"description":1580},"Architecture options","Compare patterns for retrieval, model access, orchestration, deployment, permissions, evaluation and observability.",{"label":1582,"description":1583},"Trade-off decisions","Select significant options and preserve the rationale, alternatives and consequences.",{"label":1585,"description":1586},"Implementation contracts","Turn decisions into APIs, schemas, permission rules, deployment definitions and engineering tasks.",{"label":804,"description":1588},"Test the implemented system against the original functional and non-functional requirements.",{"label":1590,"description":1591},"Operational feedback","Use production evidence, incidents, quality metrics and cost\u002Fsecurity signals to trigger controlled change.","AI solution architecture decision sequence",{"id":811,"data":1594,"type":42},{"text":1595,"level":242},"Edge cases and limits of the role",{"id":815,"data":1597,"type":218},{"text":1598},"Some AI products are dominated by model training, scientific experimentation or specialized hardware. In those cases, model\u002Fdata science and ML systems architecture can become much deeper than the solution-level map shown here. The AI Solution Architect still needs integration and operational boundaries, but specialist architecture may own the training platform itself.",{"id":819,"data":1600,"type":218},{"text":1601},"At the other extreme, a simple SaaS integration may not justify a dedicated architect. A senior engineer or technical product lead can carry the same architecture responsibility. The useful test is not the title but whether significant cross-layer decisions are being made deliberately and validated.",{"id":823,"data":1603,"type":218},{"text":1604},"Regulated, sovereign, air-gapped, safety-critical, highly autonomous or multi-tenant systems also shift the center of gravity. Identity, isolation, residency, assurance, update mechanisms, human oversight and auditability may dominate model quality in the architecture.",{"id":827,"data":1606,"type":42},{"text":1607,"level":242},"What would change this answer?",{"id":831,"data":1609,"type":218},{"text":1610},"The exact responsibility boundary changes when architecture moves from one application to a reusable platform or to enterprise-wide target architecture. That is why \u003Cstrong>AI Platform Architect\u003C\u002Fstrong> and \u003Cstrong>Enterprise AI Architecture\u003C\u002Fstrong> deserve separate canonical treatment rather than being merged into this role.",{"id":835,"data":1612,"type":218},{"text":1613},"Technology changes also matter. New model capabilities, protocols, local runtimes and managed services can remove some implementation work while creating new trust or operational boundaries. The stable responsibility is to understand those changes as system changes—not to treat a new framework as a replacement for architecture.",{"id":839,"data":1615,"type":42},{"text":1616,"level":242},"AI Solution Architect checklist",{"id":843,"data":1618,"type":291},{"content":1619,"stretched":43,"withHeadings":14},[1620,1622,1624,1627,1629,1632,1635,1638,1641,1644,1647,1650,1652],[1621,848],"Check",[1570,1623],"Is the user\u002Fbusiness result and non-goal boundary explicit?",[1625,1626],"Requirements","Are functional requirements, NFRs, constraints and acceptance criteria traceable?",[1154,1628],"Are authoritative sources, provenance, freshness, retention and access rules defined?",[1630,1631],"Retrieval\u002Fcontext","Does authorization reach retrieval and context construction?",[1633,1634],"Model\u002Fprovider","Is model\u002Fprovider selection tied to capabilities and constraints rather than preference?",[1636,1637],"Tools\u002Fagents","Are action boundaries, permissions, approvals and failure behavior explicit?",[1639,1640],"Identity\u002Fsecurity","Are human\u002Fmachine identities, secrets and trust boundaries defined?",[1642,1643],"Runtime","Are runtime, inference, data and control-plane locations distinguished?",[1645,1646],"Evaluation","Is there measurable evidence for quality, security and acceptance?",[1648,1649],"Observability","Can production behavior, failures, cost and security events be investigated?",[1163,1651],"Are significant architecture decisions and replacements traceable?",[1160,1653],"Is ownership for deployment, rollback, incidents and lifecycle clear?",{"id":883,"data":1655,"type":42},{"text":885,"level":242},{"id":887,"data":1657,"type":218},{"text":1658},"An AI Solution Architect is the person or architecture function that turns an AI opportunity into a coherent technical system. The key skill is not knowing the most model names; it is connecting product need, requirements, data, application architecture, AI capabilities, security, runtime, delivery and validation without losing the boundaries between them.",{"id":891,"data":1660,"type":218},{"text":1661},"A strong AI solution architecture can therefore be summarized as: \u003Cstrong>define the target → establish requirements and constraints → design the system boundaries → make significant trade-offs explicit → implement through clear contracts → validate against evidence → operate and evolve deliberately.\u003C\u002Fstrong> The model is important. The solution is the product.",{"id":895,"data":1663,"type":895},{"items":1664,"title":930},[1665,1668,1671,1674,1677,1680,1683,1686],{"id":899,"answer":1666,"question":1667},"An AI Solution Architect translates a business or product need into the architecture of a concrete AI-enabled solution, defining how application logic, data\u002Fretrieval, models, tools, identity, security, runtime, evaluation and operations work together.","What is an AI Solution Architect?",{"id":903,"answer":1669,"question":1670},"No. The roles can overlap, especially in small teams, but an AI engineer is primarily an implementation role while the solution architect owns or coordinates cross-layer architecture decisions and trade-offs for the complete workload.","Is an AI Solution Architect the same as an AI engineer?",{"id":907,"answer":1672,"question":1673},"Not by definition, but hands-on implementation knowledge is highly valuable because AI architecture crosses APIs, data, retrieval, security, runtimes and operational behavior. The role is defined by architecture responsibility, not by writing every component personally.","Does an AI Solution Architect need to code?",{"id":911,"answer":1675,"question":1676},"No. Model selection is one decision. Production architecture also needs data and retrieval boundaries, permissions, tools, provider\u002Fruntime choices, observability, evaluation, reliability, cost and lifecycle design.","Is choosing an LLM the main job?",{"id":915,"answer":1678,"question":1679},"An AI Solution Architect focuses on one concrete solution or workload. An AI Platform Architect focuses on reusable AI capabilities and guardrails that support multiple solutions.","What is the difference between an AI Solution Architect and an AI Platform Architect?",{"id":919,"answer":1681,"question":1682},"The solution architect works at application\u002Fworkload scope. Enterprise AI architecture works across the organizational portfolio, target architecture, governance, shared capabilities, integration principles and strategic constraints.","What is the difference between an AI Solution Architect and an Enterprise AI Architect?",{"id":923,"answer":1684,"question":1685},"They are architectural patterns or subsystems inside a solution when the requirements justify them. RAG addresses retrieval-grounded context; agents add planning\u002Ftool execution and therefore additional identity, permission, orchestration and operational concerns.","Where do RAG and agents fit?",{"id":927,"answer":1687,"question":1688},"Implementation plus validation evidence: functional tests, evaluation results, security\u002Fauthorization tests, performance and reliability measurements, observability, operational rehearsal and acceptance against the original requirements.","What proves that the architecture works?",{"id":932,"data":1690,"type":932},{"title":1691,"entries":1692},"Core terms",[1693,1695,1697,1700,1703,1705,1707,1709],{"term":937,"anchor":938,"definition":1694},"Architecture responsibility for one concrete AI-enabled solution or workload, integrating product requirements with application, data, model, tool, security, runtime and operational design.",{"term":1576,"anchor":942,"definition":1696},"The explicit separation between what belongs to the solution and the users, systems, providers, data sources and environments it interacts with.",{"term":1698,"anchor":946,"definition":1699},"Trust boundary","A point where data, identities or control cross between components with different trust assumptions and therefore require explicit security controls.",{"term":1701,"anchor":950,"definition":1702},"Grounding","Supplying an AI model with relevant external information or evidence so its response can be based on sources beyond model parameters.",{"term":1396,"anchor":954,"definition":1704},"An application boundary that decouples parts of the solution from one model\u002Fprovider interface. Useful when justified by routing, portability or policy needs, but not free of trade-offs.",{"term":1645,"anchor":957,"definition":1706},"Structured measurement of AI workload behavior against defined acceptance criteria, including task quality and relevant safety, security, performance and operational properties.",{"term":960,"anchor":961,"definition":1708},"Architectural role focused on reusable AI platform capabilities used by multiple solutions rather than the architecture of one workload.",{"term":964,"anchor":965,"definition":1710},"Organization-level architecture that coordinates AI capabilities, platforms, governance, integration and strategic constraints across a portfolio.",{"id":968,"data":1712,"type":42},{"text":1713,"level":242},"Related canonical knowledge",{"id":972,"data":1715,"type":218},{"text":1716},"This article sits in the AI Architecture Foundations cluster. Its direct foundations are \u003Cstrong>Generative AI Explained: Models, Retrieval, Tools and Applications Are Not the Same Thing\u003C\u002Fstrong> and \u003Cstrong>ADR vs NFR: Architecture Decisions and System Quality Are Not the Same Thing\u003C\u002Fstrong>. Adjacent canonical nodes include \u003Cstrong>Agentic AI Explained\u003C\u002Fstrong>, \u003Cstrong>Source of Truth in AI Systems\u003C\u002Fstrong>, \u003Cstrong>Vector Databases, Embeddings and Reranking\u003C\u002Fstrong>, \u003Cstrong>What Is Context Engineering?\u003C\u002Fstrong>, \u003Cstrong>RBAC vs Tenant Isolation\u003C\u002Fstrong>, \u003Cstrong>AI Platform Architect\u003C\u002Fstrong>, \u003Cstrong>Enterprise AI Architecture\u003C\u002Fstrong> and \u003Cstrong>AI Governance\u003C\u002Fstrong>. URLs are intentionally not fabricated where those nodes are not yet published.",{"id":976,"data":1718,"type":984},{"link":1719,"meta":1720},"https:\u002F\u002Fstajic.de\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works",{"image":1721,"title":982,"description":1722},{"url":981},"Existing stajic.de canonical explanation of retrieval-augmented generation, useful for the retrieval\u002Fgrounding part of AI solution architecture.",{"id":986,"data":1724,"type":42},{"text":1725,"level":242},"Primary sources and current architecture guidance",{"id":990,"data":1727,"type":218},{"text":1728},"External sources below support the general architecture claims; the SenseFlow and Aaasaasa AI Client sections are explicitly original project\u002Fimplementation evidence. Current-state references were checked on 8 October 2026. NIST notes that AI RMF 1.0 is being revised, so version-sensitive governance references should be rechecked when a successor is published.",{"id":994,"data":1730,"type":984},{"link":996,"meta":1731},{"image":1732,"title":999,"description":1733},{"url":981},"Current international standard for the structure and expression of architecture descriptions. It distinguishes architecture from its description and does not prescribe one architecting method, tool or recording format.",{"id":1002,"data":1735,"type":984},{"link":1004,"meta":1736},{"image":1737,"title":1738,"description":1739},{"url":981},"NIST AI Risk Management Framework","NIST’s AI RMF resource page. As of October 2026 it states that AI RMF 1.0 is being revised and links the Generative AI Profile and related resources.",{"id":1010,"data":1741,"type":984},{"link":1012,"meta":1742},{"image":1743,"title":1744,"description":1745},{"url":981},"NIST AI RMF Core — Govern, Map, Measure, Manage","Official NIST AIRC presentation of the AI RMF 1.0 Core, including the four functions and lifecycle-oriented risk-management framing.",{"id":1018,"data":1747,"type":984},{"link":1020,"meta":1748},{"image":1749,"title":1750,"description":1751},{"url":981},"NIST AI 600-1 — Generative AI Profile","Cross-sectoral Generative AI profile for AI RMF 1.0, published 26 July 2024 and updated by NIST in 2026.",{"id":1026,"data":1753,"type":984},{"link":1028,"meta":1754},{"image":1755,"title":1756,"description":1757},{"url":981},"Microsoft Azure Well-Architected — AI Workloads","Current workload-level architecture guidance covering AI application design, application platform, training data, grounding data, data platform and production-readiness concerns.",{"id":1034,"data":1759,"type":984},{"link":1036,"meta":1760},{"image":1761,"title":1762,"description":1763},{"url":981},"Microsoft — Application Design for AI Workloads","Guidance on model\u002Ftool abstraction, data-access boundaries, identity propagation, authorization and separation of client, intelligence, knowledge and tool layers.",{"id":1042,"data":1765,"type":984},{"link":1044,"meta":1766},{"image":1767,"title":1768,"description":1769},{"url":981},"Microsoft — Design Principles for AI Workloads","Current AI workload design principles across reliability, security, cost, operational excellence and performance, including identity and data-protection responsibilities.",{"id":1050,"data":1771,"type":984},{"link":1052,"meta":1772},{"image":1773,"title":1774,"description":1775},{"url":981},"Microsoft — MLOps and GenAIOps for AI Workloads","Production lifecycle guidance covering monitoring, quality gates, model\u002Fprompt behavior, security and operational measurement.",{"id":1058,"data":1777,"type":984},{"link":1060,"meta":1778},{"image":1779,"title":1063,"description":1780},{"url":981},"AWS architectural guidance for generative AI workloads across operational excellence, security, reliability, performance efficiency, cost optimization and sustainability.",{"id":1066,"data":1782,"type":984},{"link":1068,"meta":1783},{"image":1784,"title":1071,"description":1785},{"url":981},"Published in 2026, covering agentic-specific architecture concerns including identities, tools, orchestration, human oversight, reliability, tracing and reasoning-loop cost.","2.31.0","An AI Solution Architect turns business requirements into a production-ready AI system across data, models, tools, security, runtime, evaluation and operations.",{"lang":7,"title":208,"content":210,"contentJson":1789,"excerpt":1074},{"time":212,"blocks":1790,"version":1073},[1791,1793,1795,1797,1799,1801,1803,1805,1807,1823,1825,1827,1829,1839,1841,1843,1845,1847,1849,1863,1865,1867,1869,1871,1873,1875,1877,1879,1881,1883,1885,1887,1889,1891,1893,1895,1897,1899,1901,1903,1905,1907,1909,1921,1923,1925,1936,1938,1940,1958,1960,1962,1964,1966,1968,1970,1972,1974,1976,1978,1980,1982,1984,1986,1988,1990,2001,2003,2015,2017,2028,2030,2032,2034,2036,2038,2040,2042,2044,2060,2062,2064,2066,2077,2088,2090,2092,2096,2098,2100,2104,2108,2112,2116,2120,2124,2128,2132,2136],{"id":215,"data":1792,"type":218},{"text":217},{"id":220,"data":1794,"type":225},{"body":222,"title":223,"variant":224},{"id":227,"data":1796,"type":225},{"body":229,"title":230,"variant":231},{"id":233,"data":1798,"type":225},{"body":235,"title":236,"variant":231},{"id":238,"data":1800,"type":243},{"title":240,"maxLevel":241,"minLevel":242},{"id":245,"data":1802,"type":42},{"text":247,"level":242},{"id":249,"data":1804,"type":218},{"text":251},{"id":253,"data":1806,"type":218},{"text":255},{"id":257,"data":1808,"type":299},{"rows":1809,"title":290,"layout":291,"columns":1820},[1810,1812,1814,1816,1818],{"id":261,"label":262,"values":1811},{"model":264,"solution":265},{"id":267,"label":268,"values":1813},{"model":270,"solution":271},{"id":273,"label":274,"values":1815},{"model":276,"solution":277},{"id":279,"label":280,"values":1817},{"model":282,"solution":283},{"id":285,"label":286,"values":1819},{"model":288,"solution":289},[1821,1822],{"id":294,"label":295},{"id":297,"label":298},{"id":301,"data":1824,"type":42},{"text":303,"level":242},{"id":305,"data":1826,"type":218},{"text":307},{"id":309,"data":1828,"type":218},{"text":311},{"id":313,"data":1830,"type":339},{"steps":1831,"title":337,"orientation":338},[1832,1833,1834,1835,1836,1837,1838],{"label":317,"description":318},{"label":320,"description":321},{"label":323,"description":324},{"label":326,"description":327},{"label":329,"description":330},{"label":332,"description":333},{"label":335,"description":336},{"id":341,"data":1840,"type":42},{"text":343,"level":242},{"id":345,"data":1842,"type":218},{"text":347},{"id":349,"data":1844,"type":218},{"text":351},{"id":353,"data":1846,"type":42},{"text":355,"level":242},{"id":357,"data":1848,"type":218},{"text":359},{"id":361,"data":1850,"type":291},{"content":1851,"stretched":43,"withHeadings":14},[1852,1853,1854,1855,1856,1857,1858,1859,1860,1861,1862],[365,366,367],[369,370,371],[373,374,375],[377,378,379],[381,382,383],[385,386,387],[389,390,391],[393,394,395],[397,398,399],[401,402,403],[405,406,407],{"id":409,"data":1864,"type":42},{"text":411,"level":241},{"id":413,"data":1866,"type":218},{"text":415},{"id":417,"data":1868,"type":218},{"text":419},{"id":421,"data":1870,"type":42},{"text":423,"level":241},{"id":425,"data":1872,"type":218},{"text":427},{"id":429,"data":1874,"type":218},{"text":431},{"id":433,"data":1876,"type":42},{"text":435,"level":241},{"id":437,"data":1878,"type":218},{"text":439},{"id":441,"data":1880,"type":218},{"text":443},{"id":445,"data":1882,"type":42},{"text":447,"level":241},{"id":449,"data":1884,"type":218},{"text":451},{"id":453,"data":1886,"type":218},{"text":455},{"id":457,"data":1888,"type":42},{"text":459,"level":241},{"id":461,"data":1890,"type":218},{"text":463},{"id":465,"data":1892,"type":218},{"text":467},{"id":469,"data":1894,"type":42},{"text":471,"level":241},{"id":473,"data":1896,"type":218},{"text":475},{"id":477,"data":1898,"type":218},{"text":479},{"id":481,"data":1900,"type":42},{"text":483,"level":241},{"id":485,"data":1902,"type":218},{"text":487},{"id":489,"data":1904,"type":218},{"text":491},{"id":493,"data":1906,"type":42},{"text":495,"level":242},{"id":497,"data":1908,"type":218},{"text":499},{"id":501,"data":1910,"type":291},{"content":1911,"stretched":43,"withHeadings":14},[1912,1913,1914,1915,1916,1917,1918,1919,1920],[505,506],[508,509],[511,512],[514,515],[517,518],[520,521],[523,524],[526,527],[529,530],{"id":532,"data":1922,"type":42},{"text":534,"level":242},{"id":536,"data":1924,"type":218},{"text":538},{"id":540,"data":1926,"type":291},{"content":1927,"stretched":43,"withHeadings":14},[1928,1929,1930,1931,1932,1933,1934,1935],[544,545,546,547],[549,550,551,552],[554,555,556,557],[559,560,561,562],[564,565,566,567],[569,570,571,572],[574,575,576,577],[579,580,581,582],{"id":584,"data":1937,"type":42},{"text":586,"level":242},{"id":588,"data":1939,"type":218},{"text":590},{"id":592,"data":1941,"type":299},{"rows":1942,"title":631,"layout":291,"columns":1955},[1943,1945,1947,1949,1951,1953],{"id":596,"label":597,"values":1944},{"role":599,"focus":600},{"id":602,"label":603,"values":1946},{"role":605,"focus":606},{"id":608,"label":609,"values":1948},{"role":611,"focus":612},{"id":614,"label":615,"values":1950},{"role":617,"focus":618},{"id":620,"label":621,"values":1952},{"role":623,"focus":624},{"id":626,"label":627,"values":1954},{"role":629,"focus":630},[1956,1957],{"id":634,"label":635},{"id":637,"label":638},{"id":640,"data":1959,"type":218},{"text":642},{"id":644,"data":1961,"type":42},{"text":646,"level":242},{"id":648,"data":1963,"type":225},{"body":650,"title":651,"variant":652},{"id":654,"data":1965,"type":42},{"text":656,"level":241},{"id":658,"data":1967,"type":218},{"text":660},{"id":662,"data":1969,"type":218},{"text":664},{"id":666,"data":1971,"type":218},{"text":668},{"id":670,"data":1973,"type":42},{"text":672,"level":241},{"id":674,"data":1975,"type":218},{"text":676},{"id":678,"data":1977,"type":218},{"text":680},{"id":682,"data":1979,"type":218},{"text":684},{"id":686,"data":1981,"type":42},{"text":688,"level":242},{"id":690,"data":1983,"type":218},{"text":692},{"id":694,"data":1985,"type":218},{"text":696},{"id":698,"data":1987,"type":218},{"text":700},{"id":702,"data":1989,"type":42},{"text":704,"level":242},{"id":706,"data":1991,"type":291},{"content":1992,"stretched":43,"withHeadings":14},[1993,1994,1995,1996,1997,1998,1999,2000],[710,711],[713,714],[716,717],[719,720],[722,723],[725,726],[728,729],[731,732],{"id":734,"data":2002,"type":42},{"text":736,"level":242},{"id":738,"data":2004,"type":291},{"content":2005,"stretched":43,"withHeadings":14},[2006,2007,2008,2009,2010,2011,2012,2013,2014],[742,743,744],[746,747,748],[750,751,752],[754,755,756],[758,759,760],[762,763,764],[766,767,768],[770,771,772],[774,775,776],{"id":778,"data":2016,"type":42},{"text":780,"level":242},{"id":782,"data":2018,"type":339},{"steps":2019,"title":809,"orientation":338},[2020,2021,2022,2023,2024,2025,2026,2027],{"label":786,"description":787},{"label":789,"description":790},{"label":792,"description":793},{"label":795,"description":796},{"label":798,"description":799},{"label":801,"description":802},{"label":804,"description":805},{"label":807,"description":808},{"id":811,"data":2029,"type":42},{"text":813,"level":242},{"id":815,"data":2031,"type":218},{"text":817},{"id":819,"data":2033,"type":218},{"text":821},{"id":823,"data":2035,"type":218},{"text":825},{"id":827,"data":2037,"type":42},{"text":829,"level":242},{"id":831,"data":2039,"type":218},{"text":833},{"id":835,"data":2041,"type":218},{"text":837},{"id":839,"data":2043,"type":42},{"text":841,"level":242},{"id":843,"data":2045,"type":291},{"content":2046,"stretched":43,"withHeadings":14},[2047,2048,2049,2050,2051,2052,2053,2054,2055,2056,2057,2058,2059],[847,848],[786,850],[852,853],[268,855],[857,858],[860,861],[863,864],[866,867],[869,870],[872,873],[875,876],[286,878],[880,881],{"id":883,"data":2061,"type":42},{"text":885,"level":242},{"id":887,"data":2063,"type":218},{"text":889},{"id":891,"data":2065,"type":218},{"text":893},{"id":895,"data":2067,"type":895},{"items":2068,"title":930},[2069,2070,2071,2072,2073,2074,2075,2076],{"id":899,"answer":900,"question":901},{"id":903,"answer":904,"question":905},{"id":907,"answer":908,"question":909},{"id":911,"answer":912,"question":913},{"id":915,"answer":916,"question":917},{"id":919,"answer":920,"question":921},{"id":923,"answer":924,"question":925},{"id":927,"answer":928,"question":929},{"id":932,"data":2078,"type":932},{"title":934,"entries":2079},[2080,2081,2082,2083,2084,2085,2086,2087],{"term":937,"anchor":938,"definition":939},{"term":941,"anchor":942,"definition":943},{"term":945,"anchor":946,"definition":947},{"term":949,"anchor":950,"definition":951},{"term":953,"anchor":954,"definition":955},{"term":872,"anchor":957,"definition":958},{"term":960,"anchor":961,"definition":962},{"term":964,"anchor":965,"definition":966},{"id":968,"data":2089,"type":42},{"text":970,"level":242},{"id":972,"data":2091,"type":218},{"text":974},{"id":976,"data":2093,"type":984},{"link":978,"meta":2094},{"image":2095,"title":982,"description":983},{"url":981},{"id":986,"data":2097,"type":42},{"text":988,"level":242},{"id":990,"data":2099,"type":218},{"text":992},{"id":994,"data":2101,"type":984},{"link":996,"meta":2102},{"image":2103,"title":999,"description":1000},{"url":981},{"id":1002,"data":2105,"type":984},{"link":1004,"meta":2106},{"image":2107,"title":1007,"description":1008},{"url":981},{"id":1010,"data":2109,"type":984},{"link":1012,"meta":2110},{"image":2111,"title":1015,"description":1016},{"url":981},{"id":1018,"data":2113,"type":984},{"link":1020,"meta":2114},{"image":2115,"title":1023,"description":1024},{"url":981},{"id":1026,"data":2117,"type":984},{"link":1028,"meta":2118},{"image":2119,"title":1031,"description":1032},{"url":981},{"id":1034,"data":2121,"type":984},{"link":1036,"meta":2122},{"image":2123,"title":1039,"description":1040},{"url":981},{"id":1042,"data":2125,"type":984},{"link":1044,"meta":2126},{"image":2127,"title":1047,"description":1048},{"url":981},{"id":1050,"data":2129,"type":984},{"link":1052,"meta":2130},{"image":2131,"title":1055,"description":1056},{"url":981},{"id":1058,"data":2133,"type":984},{"link":1060,"meta":2134},{"image":2135,"title":1063,"description":1064},{"url":981},{"id":1066,"data":2137,"type":984},{"link":1068,"meta":2138},{"image":2139,"title":1071,"description":1072},{"url":981},"Post erfolgreich abgerufen",{"items":2142,"source":2227,"manualIds":2228,"manualMatchedIds":2229},[2143,2150,2157,2164,2171,2178,2185,2192,2199,2206,2213,2220],{"id":2144,"slug":2145,"title":2146,"excerpt":2147,"featuredImage":2148,"publishedAt":2149},"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":2151,"slug":2152,"title":2153,"excerpt":2154,"featuredImage":2155,"publishedAt":2156},"485","enterprise-ai-architecture-what-changes-when-ai-enters-a-company","Architecture de l’IA en entreprise : ce qui change lorsque l’IA entre dans une entreprise","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","2026-10-08T10:48:00.000Z",{"id":2158,"slug":2159,"title":2160,"excerpt":2161,"featuredImage":2162,"publishedAt":2163},"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":2165,"slug":2166,"title":2167,"excerpt":2168,"featuredImage":2169,"publishedAt":2170},"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":2172,"slug":2173,"title":2174,"excerpt":2175,"featuredImage":2176,"publishedAt":2177},"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":2179,"slug":2180,"title":2181,"excerpt":2182,"featuredImage":2183,"publishedAt":2184},"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":2186,"slug":2187,"title":2188,"excerpt":2189,"featuredImage":2190,"publishedAt":2191},"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":2193,"slug":2194,"title":2195,"excerpt":2196,"featuredImage":2197,"publishedAt":2198},"480","when-should-an-ai-stop-trusting-its-own-knowledge-the-retrieval-trigger","Quand une IA devrait-elle cesser de faire confiance à ses propres connaissances ? — Le déclencheur de récupération","Un modèle d'IA n'a pas besoin de récupération pour chaque question. Le problème important est de savoir quand ses connaissances internes ne suffisent plus. Le Déclencheur de Récupération est une frontière de décision pratique qui détermine quand un système d'IA devrait cesser de se fier uniquement aux connaissances du modèle et obtenir des preuves externes avant de répondre.","\u002Fuploads\u002F2026\u002F09\u002Fwhen-should-an-ai-stop-trusting-its-own-knowledge-the-retrieval-trigger-1790574991244-f4rpyg.webp","2026-09-28T01:49:00.000Z",{"id":2200,"slug":2201,"title":2202,"excerpt":2203,"featuredImage":2204,"publishedAt":2205},"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":2207,"slug":2208,"title":2209,"excerpt":2210,"featuredImage":2211,"publishedAt":2212},"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",{"id":2214,"slug":2215,"title":2216,"excerpt":2217,"featuredImage":2218,"publishedAt":2219},"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":2221,"slug":2222,"title":2223,"excerpt":2224,"featuredImage":2225,"publishedAt":2226},"495","sovereign-ai-control-of-models-data-infrastructure-and-dependencies","IA souveraine : contrôle des modèles, des données, des infrastructures et des dépendances","L'IA souveraine concerne le contrôle effectif sur les modèles, les données, l'infrastructure, les logiciels, les opérations et les dépendances stratégiques — et non simplement l'endroit où un modèle d'IA est hébergé.","\u002Fuploads\u002F2026\u002F10\u002Fsovereign-ai-control-of-models-data-infrastructure-and-dependencies-1791488833132-niy85x.webp","2026-10-08T15:45:00.000Z","fallback",[],[]]