[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:de":3,"public-menus:all":37,"post:what-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs:de":204,"related:post:what-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs:de:1":2124},{"statusCode":4,"data":5,"message":36},200,{"tenantId":6,"lang":7,"defaultLang":7,"siteUrl":8,"contactEmail":9,"brandName":10,"logoUrl":11,"siteName":10,"siteDescription":12,"ogImage":9,"robotsIndex":13,"socialLinks":9,"reservedSlugs":9,"seoPolicy":14},"stajic","de","https:\u002F\u002Fstajic.de",null,"Stajic Platform","\u002FLogo_Planet.svg","Stajic Portal",true,{"branding":15,"relatedContent":16,"crossDomainLinks":17},{"logoUrl":11},{"enabled":13},[18,21,24,27,30,33],{"url":19,"label":20,"isActive":13,"showInFooter":13,"includeInSameAs":13},"https:\u002F\u002Ffigure.rocks","figure.rocks",{"url":22,"label":23,"isActive":13,"showInFooter":13,"includeInSameAs":13},"https:\u002F\u002Floving.rocks","loving.rocks",{"url":25,"label":26,"isActive":13,"showInFooter":13,"includeInSameAs":13},"https:\u002F\u002Fbazify.com","bazify.com",{"url":28,"label":29,"isActive":13,"showInFooter":13,"includeInSameAs":13},"https:\u002F\u002Fbazify.de","bazify.de",{"url":31,"label":32,"isActive":13,"showInFooter":13,"includeInSameAs":13},"https:\u002F\u002Fbazify.at","bazify.at",{"url":34,"label":35,"isActive":13,"showInFooter":13,"includeInSameAs":13},"https:\u002F\u002Fbazify.ba","bazify.ba","Portal settings resolved",[38,44],{"id":39,"name":40,"location":41,"isActive":13,"isDefault":42,"items":43},1,"main-navigation","header",false,[],{"id":45,"name":46,"location":47,"isActive":13,"isDefault":13,"items":48},4,"main-menu","sidebar",[49,65,78,92,102,117,132],{"id":50,"title":51,"url":59,"target":60,"icon":61,"isActive":13,"type":62,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":63,"portfolioId":9,"children":64},"item-18",{"de":52,"en":53,"es":54,"fr":55,"it":53,"ru":56,"sr":57,"zh":58},"Startseite","Home","Inicio","Accueil","Главная","Почетна","首页","\u002Ffull-stack-web-developer-munich-performance-seo-and-maintainable-builds","_self","i-lucide-home","page",111,[],{"id":66,"title":67,"url":74,"target":60,"icon":75,"isActive":13,"type":62,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":76,"portfolioId":9,"children":77},"item-22",{"de":68,"en":68,"es":69,"fr":68,"it":70,"ru":71,"sr":72,"zh":73},"Vision","Visión","Visione","Видение","Визија","想象","\u002Fueber-uns-webdesign-muenchen-webaplikation","i-lucide-eye",113,[],{"id":79,"title":80,"url":88,"target":60,"icon":89,"isActive":13,"type":62,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":90,"portfolioId":9,"children":91},"item-19",{"de":81,"en":82,"es":83,"fr":82,"it":84,"ru":85,"sr":86,"zh":87},"Leistungen","Services","Servicios","Servizi","Услуги","Услуге","服务","\u002Fservices-dienstleistungen-muenchen","i-lucide-wrench",116,[],{"id":93,"title":94,"url":98,"target":60,"icon":99,"isActive":13,"type":62,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":100,"portfolioId":9,"children":101},"item-23",{"de":95,"en":95,"es":95,"fr":95,"it":95,"ru":96,"sr":96,"zh":97},"Blog","Блог","博客","\u002Fblog","i-lucide-book-open",112,[],{"id":103,"title":104,"url":113,"target":60,"icon":114,"isActive":13,"type":62,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":115,"portfolioId":9,"children":116},"item-32",{"de":105,"en":106,"es":107,"fr":108,"it":109,"ru":110,"sr":111,"zh":112},"Neue Technologien","New Technologies","Nuevas tecnologías","Nouvelles technologies","Nuove tecnologie","Новые технологии","Нове технологије","新技术！","\u002Fneue-webtechnologien","i-lucide-sparkles",122,[],{"id":118,"title":119,"url":128,"target":60,"icon":129,"isActive":13,"type":62,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":130,"portfolioId":9,"children":131},"item-20",{"de":120,"en":121,"es":122,"fr":123,"it":124,"ru":125,"sr":126,"zh":127},"Kontakt","Contact us!","Contacto","Contact","Contatto","Контакт","Контактирајте нас","联系我们！","\u002Fcontact","i-lucide-mail",115,[],{"id":133,"title":134,"url":143,"target":60,"icon":144,"isActive":13,"type":62,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":145,"portfolioId":9,"children":146},"item-21",{"de":135,"en":136,"es":137,"fr":138,"it":139,"ru":140,"sr":141,"zh":142},"Unsere Arbeit","Our Work","Nuestro trabajo","Nos réalisations","I nostri lavori","Наши работы","Наши радови","文件夹","\u002Fportfolio","i-lucide-briefcase",114,[147,160,174,180,192],{"id":148,"title":149,"url":143,"target":60,"icon":158,"isActive":13,"type":62,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":145,"portfolioId":9,"children":159},"item-24",{"de":150,"en":151,"es":152,"fr":153,"it":154,"ru":155,"sr":156,"zh":157},"Alle Projekte","All Projects","Todos los proyectos","Tous les projets","Tutti i progetti","Все проекты","Сви пројекти","所有项目","i-lucide-grid-3x3",[],{"id":161,"title":162,"url":170,"target":60,"icon":171,"isActive":13,"type":172,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":9,"portfolioId":9,"children":173},"item-29",{"de":163,"en":164,"es":165,"fr":166,"it":167,"ru":168,"sr":169,"zh":142},"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":175,"title":176,"url":178,"target":60,"icon":171,"isActive":13,"type":172,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":9,"portfolioId":9,"children":179},"item-28",{"de":177,"en":177,"es":177,"fr":177,"it":177,"ru":177,"sr":177,"zh":177},"Solr Suggester","\u002Fportfolio\u002Fsolr-fuzzy-suggester-und-solr-infix-suggester-abfrage-ueber-ajax-und-filterung",[],{"id":181,"title":182,"url":190,"target":60,"icon":171,"isActive":13,"type":172,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":9,"portfolioId":9,"children":191},"item-27",{"de":183,"en":184,"es":185,"fr":186,"it":187,"ru":188,"sr":189,"zh":184},"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":193,"title":194,"url":202,"target":60,"icon":171,"isActive":13,"type":172,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":9,"portfolioId":9,"children":203},"item-31",{"de":195,"en":196,"es":197,"fr":198,"it":199,"ru":200,"sr":201,"zh":196},"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":205,"message":2123},{"id":206,"title":207,"slug":208,"content":209,"contentJson":210,"excerpt":1068,"featuredImage":1069,"featuredImageAlt":1070,"featuredImageCaption":9,"featuredImageTitle":9,"featuredImageCopyright":9,"featuredImageAuthor":9,"featuredImageSourceUrl":9,"featuredImageLicense":9,"featuredImageIsAiGenerated":42,"status":1071,"publishedAt":1072,"createdAt":1073,"updatedAt":1074,"seoLocalePaths":1075,"categories":1084,"author":1101,"translations":1106},"483","Was ist ein KI-Lösungsarchitekt? Systemgrenzen, Verantwortlichkeiten und Kompromisse","what-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","\u003Cp>Ein \u003Cstrong>AI Solution Architect\u003C\u002Fstrong> übersetzt einen Geschäfts- oder Produktbedarf in die Architektur einer konkreten KI-fähigen Lösung. Die Rolle definiert Systemgrenzen und die wesentlichen Entscheidungen über Anwendungslogik, autoritative Daten, Retrieval und Kontext, Modelle und Anbieter, Tools oder Agenten, Identität und Berechtigungen, Sicherheit, Laufzeit und Deployment, Observability, Evaluierung, Kosten und operatives Verhalten. Es geht nicht einfach um Modellauswahl oder Prompt Engineering: Die architektonische Verantwortung besteht darin, die gesamte Lösung implementierbar, governbar, testbar und betreibbar zu machen.\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\">Direkte Antwort\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>Ein AI Solution Architect entwirft die vollständige KI-fähige Lösung, nicht nur das KI-Modell.\u003C\u002Fstrong> Die Rolle verbindet Anforderungen und nicht-funktionale Anforderungen mit Architekturentscheidungen, setzt die notwendigen Anwendungs-, Daten-, Modell-, Tool- und Laufzeitschichten zusammen, macht Vertrauens- und Fehlergrenzen explizit und definiert, wie das implementierte System validiert und betrieben wird.\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\">Hinweis zur Terminologie\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>AI Solution Architect ist eine praktische Rollenbezeichnung, kein universell standardisierter Jobtitel.\u003C\u002Fstrong> ISO\u002FIEC\u002FIEEE 42010:2022 standardisiert Konzepte für Architekturbeschreibungen; es definiert diese Jobrolle nicht. Organisationen können die Verantwortlichkeiten auf mehrere Personen verteilen. In diesem Artikel bezeichnet der Begriff die Architekturverantwortung für eine konkrete KI-fähige Lösung oder Workload.\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\">Hinweis zu aktuellen Quellen — 8. Oktober 2026\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Die Architekturprinzipien hier sind bewusst anbieterneutral, während aktuelle Anbieterempfehlungen als Implementierungsnachweis verwendet werden. NIST AI RMF 1.0 wird derzeit überarbeitet; NIST AI 600-1 bleibt das veröffentlichte Generative AI Profile. Die unten zitierten Empfehlungen von Microsoft und AWS spiegeln aktuelle Produktionsanliegen wie Identität, Datengrenzen, Modellabstraktion, Sicherheit, Observability, Evaluierung, Zuverlässigkeit und Kosten wider.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cnav class=\"editorjs-toc\" data-editorjs-toc=\"true\" aria-label=\"Inhalt\">\u003Cstrong class=\"editorjs-toc__title\">Inhalt\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\">Was architektiert ein AI Solution Architect tatsächlich?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-10\" class=\"editorjs-toc__link\">Das einfachste Beispiel\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-14\" class=\"editorjs-toc__link\">Wo das einfache Beispiel endet\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-17\" class=\"editorjs-toc__link\">Karte der Architekturverantwortlichkeiten\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. Produktbedarf in Architekturanforderungen übersetzen\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-23\" class=\"editorjs-toc__link\">2. Autoritative Daten, Abruf und Kontext entwerfen\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-26\" class=\"editorjs-toc__link\">3. Modelle und Anbieter als Abhängigkeiten behandeln, nicht als das gesamte System\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-29\" class=\"editorjs-toc__link\">4. Werkzeuge, Aktionen und Agentengrenzen architektonisch gestalten\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-32\" class=\"editorjs-toc__link\">5. Vertrauensgrenzen und Berechtigungen explizit machen\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-35\" class=\"editorjs-toc__link\">6. Entscheiden, wo das System tatsächlich läuft\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-38\" class=\"editorjs-toc__link\">7. Evaluation, Observability und operative Abnahme definieren\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-41\" class=\"editorjs-toc__link\">Was sollte die Rolle produzieren?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-44\" class=\"editorjs-toc__link\">Die Arbeit besteht überwiegend aus Trade-offs, nicht aus der Auswahl von „Best Practices“\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-47\" class=\"editorjs-toc__link\">Wie unterscheidet sich dies von angrenzenden Rollen?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-51\" class=\"editorjs-toc__link\">Implementierungsnachweise: Wie diese Grenzen in meiner eigenen Arbeit erscheinen\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: Bedarf → Anforderungen → Architektur → Validierung\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-57\" class=\"editorjs-toc__link\">Aaasaasa AI Client: Konzepte trennen, bevor sie integriert werden\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-61\" class=\"editorjs-toc__link\">Wie aktuelle Architektur-Frameworks diesen breiteren Umfang unterstützen\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-65\" class=\"editorjs-toc__link\">Häufige Missverständnisse\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-67\" class=\"editorjs-toc__link\">Fehlermodi, die ein AI Solution Architect verhindern sollte\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-69\" class=\"editorjs-toc__link\">Eine praktische Entscheidungssequenz\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-71\" class=\"editorjs-toc__link\">Randfälle und Grenzen der Rolle\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-75\" class=\"editorjs-toc__link\">Was würde diese Antwort ändern?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-78\" class=\"editorjs-toc__link\">Checkliste für AI Solution Architects\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-80\" class=\"editorjs-toc__link\">Fazit\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-85\" class=\"editorjs-toc__link\">Verwandtes kanonisches Wissen\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-88\" class=\"editorjs-toc__link\">Primärquellen und aktuelle Architekturanleitung\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fnav>\n\u003Ch2 id=\"section-6\">Was architektiert ein AI Solution Architect tatsächlich?\u003C\u002Fh2>\n\u003Cp>Der Gegenstand der Arbeit ist die \u003Cstrong>Lösung\u003C\u002Fstrong>: das vollständige soziotechnische System, das einen Bedarf in nützliches, kontrolliertes Verhalten umsetzt. Ein Modell kann zentral für dieses System sein, ist aber dennoch nur eine Abhängigkeit. Dasselbe Modell kann an einem sicheren internen Suchassistenten, einem unsicheren überprivilegierten Agenten, einem kundenorientierten Feature mit niedriger Latenz oder einem teuren Prototyp beteiligt sein, der nicht wirtschaftlich betrieben werden kann. Die Architektur bestimmt diese Unterschiede.\u003C\u002Fp>\n\u003Cp>Eine nützliche Grenze ist daher: \u003Cstrong>Geschäftsergebnis → Anforderungen → Systemverantwortlichkeiten → Architekturentscheidungen → Implementierung → Validierung → Betrieb\u003C\u002Fstrong>. Der AI Solution Architect arbeitet über diese Kette hinweg und kollaboriert mit Produkt-, Engineering-, Daten-, Sicherheits-, Infrastruktur-, Governance- und Domänenspezialisten.\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Die Lösung ist weiter als das Modell\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\">Modellzentrierte Frage\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\">Lösungsarchitektur-Frage\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\">Fähigkeit\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\">Daten\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\">Sicherheit\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\">Betrieb\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\">Änderung\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\">Das einfachste Beispiel\u003C\u002Fh2>\n\u003Cp>Stellen Sie sich vor, ein Unternehmen möchte einen internen Assistenten, der Fragen von Technikern anhand von Wartungshandbüchern und Betriebsverfahren beantwortet. Das sichtbare Feature klingt einfach: eine Frage eingeben und eine Antwort mit Quellen erhalten.\u003C\u002Fp>\n\u003Cp>Die Architekturfrage ist viel größer. Welche Dokumente sind autoritativ? Wie werden Benutzer authentifiziert? Muss das Retrieval Abteilungs- oder Standortberechtigungen respektieren? Darf die Antwort nur abgerufene Belege verwenden? Welches Modell ist für die Datenklassifizierung akzeptabel? Kann ein Cloud-Anbieter die Inhalte erhalten? Was passiert, wenn das Retrieval nichts findet? Wie werden Zitate erzeugt? Wie wird die Antwortqualität bewertet? Welche Latenz und welche Kosten sind akzeptabel? Wer kann Logs einsehen, und was darf darin gespeichert werden?\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Vom Bedarf zu einer betreibbaren KI-Lösung\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. Ergebnis definieren\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Klären Sie Benutzer, Geschäftswert, Aufgabengrenze und was eine erfolgreiche Antwort oder Aktion bedeutet.\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. Anforderungen erfassen\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Machen Sie funktionale Anforderungen, NFRs, Einschränkungen, Datenregeln, Risikotoleranz und Abnahmekriterien explizit.\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. Grenzen festlegen\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Identifizieren Sie Benutzer, Identitäten, Anwendungen, autoritative Daten, Modell-\u002FAnbieterabhängigkeiten, Tools, externe Systeme und Vertrauenszonen.\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. Architektur entwerfen\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Wählen Sie Muster für Daten\u002FRetrieval, Modell, Orchestrierung, Tools, Berechtigungen, Laufzeit, Deployment, Fallback und Observability.\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. Wesentliche Entscheidungen dokumentieren\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Bewahren Sie architektonische Entscheidungen, Alternativen, Trade-offs und Konsequenzen auf, damit spätere Änderungen nachvollziehbar bleiben.\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. Implementieren und integrieren\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Überführen Sie die Architektur in Anwendungscode, APIs, Richtlinien, Infrastruktur, Workflows und operative Kontrollen.\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. Validieren und betreiben\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Testen Sie Qualität, Sicherheit, Zuverlässigkeit, Kosten und Benutzerergebnisse; überwachen Sie den realen Workload und führen Sie Erkenntnisse zurück in Entscheidungen.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-14\">Wo das einfache Beispiel endet\u003C\u002Fh2>\n\u003Cp>Ein Proof of Concept kann oft Architektur überspringen, was in der Produktion nicht möglich ist. Ein Entwickler kann einen Anbieter fest codieren, einen gemeinsamen API-Schlüssel verwenden, alle Dokumente in einen Index legen, Retrieval ohne Filterung nach Benutzerkontext ausführen, Prompts wörtlich protokollieren und Qualität manuell beurteilen. Das kann Machbarkeit demonstrieren, aber es begründet keine Produktionsarchitektur.\u003C\u002Fp>\n\u003Cp>Die Produktion führt Einschränkungen ein, die interagieren: Mandanten- oder Benutzerisolation, Datenschutz, Datenresidenz, Durchsatz, Latenz, Kosten, Anbieterquoten, Fallback-Verhalten, Auditierbarkeit, Änderungen der Modellversion, Retrieval-Qualität, Tool-Berechtigungen, Incident Response und Deployment-Lebenszyklus. Die Aufgabe des Architekten ist nicht, jede Qualität gleichzeitig zu maximieren; sie besteht darin, die Trade-offs explizit zu machen und eine Lösung zu entwerfen, die die tatsächliche Prioritätenmenge erfüllt.\u003C\u002Fp>\n\u003Ch2 id=\"section-17\">Karte der Architekturverantwortlichkeiten\u003C\u002Fh2>\n\u003Cp>Die genaue Aufteilung variiert je nach Organisation, aber die folgende Karte erfasst die wiederkehrenden Verantwortlichkeiten der KI-Architektur auf Lösungsebene. Der Architekt implementiert möglicherweise nicht jede Schicht persönlich; die Verantwortung besteht darin, die Schichten kohärent zusammenfügen zu lassen und die kritischen Entscheidungen nachvollziehbar zu halten.\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\">Architekturbereich\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Fragen, die der KI-Lösungsarchitekt klären muss\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Typische Ergebnisse\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ergebnis und Umfang\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Wer ist der Benutzer? Welche Aufgabe liegt im Geltungsbereich? Was darf das System nicht tun? Was gilt als Erfolg?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Lösungskontext, Fähigkeitsgrenze, Abnahmekriterien\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Anforderungen und NFRs\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Welche Qualitäts-, Sicherheits-, Verfügbarkeits-, Latenz-, Kosten-, Standort- und Compliance-Einschränkungen gelten?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Anforderungsübersicht, NFRs, Einschränkungen, Validierungskriterien\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Anwendung und Orchestrierung\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Wo endet deterministische Anwendungslogik und wo beginnt KI-Verhalten? Wie werden Workflows koordiniert?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Komponentenmodell, APIs, Orchestrierungsgrenzen, Fehlerpfade\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Autoritative Daten und Abruf\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Was ist die Single Source of Truth? Wie werden Daten aufgenommen, autorisiert, abgerufen, gefiltert, gerankt und zitiert?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Datenflüsse, Abrufarchitektur, Metadaten- und Autorisierungsregeln\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modell- und Anbieterschicht\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Welche Fähigkeiten sind erforderlich? Welche Anbieter-\u002FLaufzeitbeschränkungen sind relevant? Was sollte abstrahiert werden?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modell-\u002FAnbieterentscheidung, Routing-\u002FFallback-Richtlinie, Abstraktionsgrenze\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Tools und Agenten\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Welche Aktionen kann das System ausführen? Welche Aktionen erfordern eine Genehmigung? Wie werden Tool-Identitäten und Berechtigungen durchgesetzt?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Tool-Verträge, Agentengrenzen, Genehmigungs- und Least-Privilege-Regeln\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Identität und Sicherheit\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Welche menschlichen und maschinellen Identitäten existieren? Wo werden Geheimnisse aufbewahrt? Welche Vertrauensgrenzen werden überschritten?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Bedrohungs-\u002FVertrauensgrenzenmodell, Identitätsweitergabe, Geheimnis- und Autorisierungsdesign\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Laufzeit und Bereitstellung\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Wo werden Komponenten ausgeführt? Was ist lokal, Cloud, Edge oder hybrid? Welche Netzwerk- und Verfügbarkeitsannahmen bestehen?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Bereitstellungsansicht, Laufzeittopologie, Umgebungs- und Konnektivitätsentscheidungen\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Evaluierung und Observability\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Wie wird die Qualität vor und nach der Veröffentlichung gemessen? Welche Traces, Metriken, Logs und Nachweise sind erforderlich?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Evaluierungsplan, Telemetrie, Audit-Trail, Release-Gates\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Betrieb und Änderung\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Wie werden Modelle\u002FPrompts\u002FKonfiguration\u002FDatenversionen geändert, zurückgerollt und unterstützt?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Betriebsmodell, Lifecycle-Kontrollen, ADRs, Runbooks, Änderungsregeln\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch3 id=\"section-20\">1. Produktbedarf in Architekturanforderungen übersetzen\u003C\u002Fh3>\n\u003Cp>KI-Architektur beginnt vor der Modellauswahl. Der Architekt bestimmt zunächst, was die Lösung erreichen soll und unter welchen Einschränkungen. Dies umfasst funktionales Verhalten, aber auch die NFRs und Richtlinien, die den Designraum einschränken: Sicherheit, Zuverlässigkeit, Latenz, Datenschutz, Standort, Wartbarkeit, Kosten und betriebliche Unterstützung.\u003C\u002Fp>\n\u003Cp>Hier ist die Unterscheidung von A02 wichtig: Eine Anforderung wie „unautorisierte Benutzer dürfen keine eingeschränkten Dokumente abrufen“ ist keine Architekturentscheidung. Sie ist ein Treiber. Entscheidungen über Identitätsweitergabe, Indexpartitionierung, Metadatenfilterung, API-Grenzen und Autorisierungsdurchsetzung sind architektonische Antworten, die später validiert werden müssen.\u003C\u002Fp>\n\u003Ch3 id=\"section-23\">2. Autoritative Daten, Abruf und Kontext entwerfen\u003C\u002Fh3>\n\u003Cp>KI-Systeme scheitern oft an der Grenze zwischen Modellverhalten und Unternehmenswahrheit. Ein Architekt muss definieren, welche Quellen autoritativ sind, was Aktualität und Herkunft bedeuten, wie Zugriffskontrolle den Abruf erreicht und wie abgerufene Evidenz zum Modellkontext wird. Eine Vektordatenbank, ein Embedding-Modell oder eine RAG-Bibliothek ist nicht die Architektur an sich.\u003C\u002Fp>\n\u003Cp>Die aktuelle KI-Workload-Anleitung von Microsoft macht dieselbe Trennung explizit: Anwendungscode sollte Datenzugriffsgrenzen nicht umgehen; Benutzer- oder Mandantenkontext sollte sich in Abruf und Filterung fortsetzen; Grounding-Daten müssen für Durchsuchbarkeit ausgelegt sein und gleichzeitig Sicherheits- und Compliance-Anforderungen erfüllen.\u003C\u002Fp>\n\u003Ch3 id=\"section-26\">3. Modelle und Anbieter als Abhängigkeiten behandeln, nicht als das gesamte System\u003C\u002Fh3>\n\u003Cp>Die Modellauswahl ist wichtig, sollte aber von der erforderlichen Fähigkeit und den Einschränkungen getrieben sein. Der Architekt berücksichtigt Reasoning- oder Generierungsqualität, Modalität, Kontextgrenzen, Latenz, Datenhandhabung, Bereitstellungsort, Anbieterverfügbarkeit, Kosten, Observability und Ersetzungsrisiko.\u003C\u002Fp>\n\u003Cp>Die Anbieterabstraktion ist nicht automatisch eine „bessere Architektur“. Sie verursacht Engineering-Kosten und kann anbieterspezifische Fähigkeiten verbergen. Sie ist gerechtfertigt, wenn Portabilität, Fallback, Richtlinientrennung oder Multi-Provider-Routing eine explizite Anforderung sind. Andernfalls kann eine direkte Integration die bessere Entscheidung sein. Der Punkt ist, den Kompromiss bewusst zu treffen.\u003C\u002Fp>\n\u003Ch3 id=\"section-29\">4. Werkzeuge, Aktionen und Agentengrenzen architektonisch gestalten\u003C\u002Fh3>\n\u003Cp>Wenn ein KI-System Werkzeuge aufrufen, Daten ändern, Nachrichten senden, Code ausführen oder Geschäftssysteme bedienen kann, ändert sich das architektonische Risiko. Werkzeugzugriff benötigt ein eigenes Identitäts- und Autorisierungsmodell. Die Fähigkeit des Modells, eine Aktion anzufordern, ist nicht dasselbe wie die Berechtigung, sie auszuführen.\u003C\u002Fp>\n\u003Cp>Für agentische Workloads betont die aktuelle AWS-Richtlinie zusätzliche Dimensionen wie Agentenidentitäten, Werkzeugzugriff, Orchestrierung, menschliche Aufsicht, Tracing, Fehlerbehandlung und Kosten iterativer Reasoning-Schleifen. Dies sind Lösungsbelange, selbst wenn ein Framework einige der Implementierungsmechanismen verbirgt.\u003C\u002Fp>\n\u003Ch3 id=\"section-32\">5. Vertrauensgrenzen und Berechtigungen explizit machen\u003C\u002Fh3>\n\u003Cp>Eine Produktions-KI-Lösung hat mehrere Vertrauensgrenzen: Browser oder Client, Anwendungs-Backend, KI-Orchestrierung, Retrieval-\u002FDatendienste, Modellanbieter, Werkzeug-APIs, lokale Laufzeitumgebungen und externe Systeme. Jede Grenze sollte beantworten: Wer ruft an, in wessen Namen, mit welcher Berechtigung, für welche Ressource, mit welchem Audit-Trail und mit welcher Fehlereingrenzung?\u003C\u002Fp>\n\u003Cp>Sicherheit kann nicht auf eine „Guardrail“ um das Modell herum verschoben werden. Die KI-Workload-Richtlinie von Microsoft verortet Sicherheit ausdrücklich über alle Architekturschichten hinweg und fordert Identitäts-\u002FZugriffsmanagement, Datenschutz, Inhaltskontrollen und Lebenszyklussicherheit. NIST behandelt Governance und Risikomanagement ebenfalls als kontinuierlich über den gesamten KI-Lebenszyklus.\u003C\u002Fp>\n\u003Ch3 id=\"section-35\">6. Entscheiden, wo das System tatsächlich läuft\u003C\u002Fh3>\n\u003Cp>„Lokale KI“, „Cloud-KI“ und „hybride KI“ sind nur dann architektonische Aussagen, wenn die Ausführungs- und Datenpfade präzise sind. Ein lokaler Desktop-Prozess kann dennoch ein Cloud-Modell aufrufen. Eine in der Cloud gehostete Anwendung kann aus einer lokalen Datenquelle abrufen. Eine air-gapped Lösung hat völlig andere Einschränkungen bei Updates, Modellverteilung und Observability.\u003C\u002Fp>\n\u003Cp>Der Architekt trennt daher \u003Cstrong>Laufzeitort\u003C\u002Fstrong>, \u003Cstrong>Inferenzort\u003C\u002Fstrong>, \u003Cstrong>Datenort\u003C\u002Fstrong> und \u003Cstrong>Control Plane\u003C\u002Fstrong>. Deren Vermischung erzeugt falsche Sicherheits- und Deployment-Annahmen.\u003C\u002Fp>\n\u003Ch3 id=\"section-38\">7. Evaluation, Observability und operative Abnahme definieren\u003C\u002Fh3>\n\u003Cp>KI-Verhalten ist teilweise nichtdeterministisch, daher kann sich die Release-Definition nicht nur auf konventionelle Unit-Tests stützen. Die Architektur benötigt messbare Abnahmekriterien: Aufgabenerfolg, Groundedness oder Zitatkorrektheit wo relevant, Verweigerungsverhalten, Tool-Sicherheit, Latenz, Kosten, Zuverlässigkeit und Sicherheitstests. Die genauen Metriken hängen vom Anwendungsfall ab.\u003C\u002Fp>\n\u003Cp>Die aktuelle Well-Architected-KI-Richtlinie von Microsoft behandelt Monitoring als kontinuierlich und wendet es auf Modellverhalten, Prompts\u002FCompletions, Anomalien, Sicherheit und Produktions-Qualitätsgates an. AWS behandelt Observability, Lifecycle-Management und Modell-\u002FPrompt-Nachverfolgbarkeit ebenfalls als operative Architekturanliegen.\u003C\u002Fp>\n\u003Ch2 id=\"section-41\">Was sollte die Rolle produzieren?\u003C\u002Fh2>\n\u003Cp>Architektur ist nicht die Präsentationsfolie. Die nützlichen Ergebnisse sind die Artefakte, die es Engineering, Sicherheit, Produkt und Betrieb ermöglichen, konsistente Entscheidungen zu treffen und später zu verstehen, warum das System in seiner aktuellen Form existiert.\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\">Artefakt\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Zweck\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Lösungskontext und -grenze\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Zeigt Benutzer, externe Systeme, Hauptverantwortlichkeiten und was außerhalb des Geltungsbereichs liegt\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Anforderungs-\u002FNFR-Zuordnung\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Verbindet Produktbedarf und Einschränkungen mit Architekturarbeit und Validierung\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Komponenten- und Datenflussansichten\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Zeigt Anwendung, Daten\u002FRetrieval, Modell, Tools, Identität und Laufzeitinteraktionen\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Vertrauens- und Berechtigungsmodell\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Macht Identitäten, Secrets, Autorisierung, sensible Daten und risikoreiche Aktionen explizit\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Architecture Decision Records\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Bewahrt bedeutende Entscheidungen, Alternativen, Trade-offs, Status und Konsequenzen\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Evaluations- und Abnahmeplan\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Definiert den Nachweis, der erforderlich ist, um zu behaupten, dass die Lösung Qualitäts- und Sicherheitserwartungen erfüllt\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Deployment- und Betriebsansicht\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Definiert Umgebungen, Laufzeitorte, Observability, Rollback, Incident- und Lifecycle-Verantwortlichkeiten\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Traceability-Links\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Verbindet Anforderungen, Entscheidungen, Implementierungsarbeit, Tests und operative Nachweise\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-44\">Die Arbeit besteht überwiegend aus Trade-offs, nicht aus der Auswahl von „Best Practices“\u003C\u002Fh2>\n\u003Cp>Architektur existiert, weil wünschenswerte Qualitäten miteinander in Konflikt stehen. Ein kostengünstigeres Modell kann die Qualität verringern. Ein leistungsfähigeres Modell kann die Latenz oder Data-Governance-Einschränkungen erhöhen. Aggressives Caching kann Kosten und Geschwindigkeit verbessern, während es die Aktualität verkompliziert. Autonomere Agenten können menschlichen Aufwand reduzieren, während sie den Blast Radius und die Audit-Anforderungen erhöhen.\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\">Entscheidung\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Potenzieller Nutzen\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Potenzielle Kosten \u002F Risiko\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Architekturfrage\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Managed-Cloud-Modell\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Schnelle Einführung, starke Managed-Fähigkeiten\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Externe Abhängigkeit, Daten- und Kosteneinschränkungen\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Erlaubt die Workload den Anbieter-\u002FDatenpfad und erfüllt sie die Resilienzanforderungen?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Lokale\u002Fself-hosted Inferenz\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Kontrolle, Offline-\u002FPrivate-Optionen\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Hardware-, Betriebs- und Modell-Lifecycle-Aufwand\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ist der Kontrollnutzen die operative Verantwortung wert?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Integration eines einzelnen Anbieters\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Einfachere Implementierung, volle Anbieterfunktionen\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Höhere Wechsel-\u002FAusfallkonzentration\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sind Portabilität oder Fallback tatsächlich erforderlich?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Anbieterabstraktion\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Portabilität, Routing- und Richtlinientrennung\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Risiko des kleinsten gemeinsamen Nenners, mehr Code\u002FTests\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Welche Unterschiede müssen sichtbar bleiben statt abstrahiert zu werden?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Großer Kontext\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Mehr Informationen pro Anfrage\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Latenz, Kosten, Aufmerksamkeitsverwässerung, Leckage-Oberfläche\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sollten Daten abgerufen\u002Fgefiltert werden, statt immer injiziert zu werden?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Leistungsstarke Tools \u002F Autonomie\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Mehr End-to-End-Automatisierung\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Höhere Privilegien und Blast Radius bei Fehlern\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Welche Aktionen erfordern Least Privilege, Bestätigung oder menschliche Genehmigung?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Strikte Validierung und Protokollierung\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Bessere Nachweise und Betrieb\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Latenz-, Speicher-, Datenschutz- und Komplexitätskosten\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Welche Nachweise sind für dieses Risikoniveau erforderlich?\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-47\">Wie unterscheidet sich dies von angrenzenden Rollen?\u003C\u002Fh2>\n\u003Cp>Titel überschneiden sich stark zwischen Unternehmen. Die nützliche Unterscheidung ist der \u003Cstrong>Umfang der Architekturverantwortung\u003C\u002Fstrong>, nicht das HR-Label.\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Angrenzende Rollen beantworten unterschiedliche primäre Fragen\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\">Rolle\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\">Primärer Architekturfokus\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\">AI Solution Architect\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\">AI Platform Architect\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\">Enterprise AI Architect\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\">AI \u002F ML Engineer\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\">Security Architect\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\">Product \u002F Delivery Lead\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>In einem kleinen Produktteam kann eine Person mehrere dieser Bereiche abdecken. In einem großen Unternehmen können es separate Rollen mit formellen Review-Boards sein. Die Architekturverantwortung verschwindet nicht, wenn sich der Titel ändert.\u003C\u002Fp>\n\u003Ch2 id=\"section-51\">Implementierungsnachweise: Wie diese Grenzen in meiner eigenen Arbeit erscheinen\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\">Implementierungsnachweise, keine universelle Regel\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Die folgenden Beispiele sind \u003Cstrong>originäre Implementierungs-\u002FProjektnachweise\u003C\u002Fstrong>. Sie zeigen, wie ich in realer Projektarbeit Produktbedarf, Anforderungen, Architektur, Laufzeit, Modell\u002FAnbieter, Berechtigungen und Validierung getrennt habe. Sie sind keine Behauptungen, dass jede Organisation dieselbe Struktur verwenden muss, und sie implizieren keine Kundenakzeptanz oder Bereitstellung im Unternehmensmaßstab.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch3 id=\"section-53\">SenseFlow: Bedarf → Anforderungen → Architektur → Validierung\u003C\u002Fh3>\n\u003Cp>Im SenseFlow-Projekt Source of Truth ist Technologie ausdrücklich der Product Vision untergeordnet. Die Entwicklungsstruktur bewegt sich von Problem und Produktvision über Benutzerbedürfnisse, Wert, Umfang, Epics, Stories und Abnahmekriterien hin zu Architektur, Implementierung, Validierung und Iteration.\u003C\u002Fp>\n\u003Cp>Anforderungen sind so gestaltet, dass sie vom Produktziel → Fähigkeit → Epic → User Story → Akzeptanzkriterien → Technische Aufgaben nachvollziehbar sind. Wo praktikabel, enthalten sie funktionale Anforderungen, NFRs, Abhängigkeiten, Risiken, Annahmen, Akzeptanzkriterien und Validierungsmethoden. Wesentliche Entscheidungen bewahren die Entscheidung, den Grund, Alternativen, Abwägungen, Status und Datum\u002FVersion.\u003C\u002Fp>\n\u003Cp>Das ist architektonische Arbeit, bevor ein bestimmtes KI-Framework oder Modell gewählt wird: Sie schützt die Verbindung zwischen Produktabsicht und technischen Entscheidungen und macht spätere Änderungen überprüfbar statt implizit.\u003C\u002Fp>\n\u003Ch3 id=\"section-57\">Aaasaasa AI Client: Konzepte trennen, bevor sie integriert werden\u003C\u002Fh3>\n\u003Cp>Aaasaasa AI Client bietet ein eher implementierungsnahes Beispiel. Sein AI Hub trennt bewusst \u003Cstrong>Agent\u002FClient\u003C\u002Fstrong>, \u003Cstrong>Anbieter\u003C\u002Fstrong>, \u003Cstrong>Modell\u003C\u002Fstrong>, \u003Cstrong>Verbindungs-\u002FLaufzeitort\u003C\u002Fstrong>, \u003Cstrong>Berechtigungen\u003C\u002Fstrong> und \u003Cstrong>Web-Client\u003C\u002Fstrong>. Eine lokale Laufzeit bedeutet nicht automatisch lokale Inferenz, und Berechtigungen werden als Laufzeit-\u002FTool-Richtlinie behandelt, nicht als Eigenschaft des Modells.\u003C\u002Fp>\n\u003Cp>Die Desktop-Architektur definiert außerdem eine Vertrauensgrenze: Der Nuxt-Renderer ist im Verhältnis zum Electron-Main-Prozess nicht vertrauenswürdig. Ein schmaler Preload und validiertes IPC vermitteln den Zugriff auf KI-Dienste, Einstellungen, verschlüsselte Geheimnisse, Workspace-\u002FDatendienste und Laufzeiten. Cloud-Anmeldeinformationen verbleiben im privilegierten Main-Prozess; Renderer-Code erhält normalisierten Zustand statt roher Geheimnisse oder uneingeschränkten Betriebssystemzugriff.\u003C\u002Fp>\n\u003Cp>Routing-Entscheidungen sind ebenfalls architektonisch. Die Implementierung fällt nicht stillschweigend von einer lokalen Route auf kostenpflichtige Cloud-Inferenz zurück; eine Cloud-Route erfordert ausdrückliche Bestätigung. Direct Chat hat standardmäßig keine Dateisystem- oder Shell-Tools, während die Agent-Ausführung ein ausgewähltes Workspace- und Berechtigungsprofil anwendet. Dies sind lösungsbezogene Entscheidungen über Vertrauen, Kosten, Ausführung und Benutzererwartung – keine Modellfunktionen.\u003C\u002Fp>\n\u003Ch2 id=\"section-61\">Wie aktuelle Architektur-Frameworks diesen breiteren Umfang unterstützen\u003C\u002Fh2>\n\u003Cp>ISO\u002FIEC\u002FIEEE 42010:2022 bietet eine allgemeine Disziplin für Architekturbeschreibungen über Software, Systeme und Unternehmen hinweg. Es ist bewusst breiter als KI und schreibt keine einzelne Architekturmethode oder Berufsbezeichnung vor. Das macht es hier als Abgrenzung nützlich: KI-Lösungsarchitektur ist immer noch Architektur, mit Stakeholder-Anliegen, mehreren Sichten und wesentlichen Beziehungen, die klar ausgedrückt werden müssen.\u003C\u002Fp>\n\u003Cp>NIST AI RMF 1.0 rahmt KI-Risikomanagement durch \u003Cstrong>Govern, Map, Measure und Manage\u003C\u002Fstrong> und betont, dass Risikomanagement über den gesamten Lebenszyklus des KI-Systems kontinuierlich sein sollte. Das Generative AI Profile (NIST AI 600-1) passt dieses Framework an GAI-Risiken und organisatorische Prioritäten an. Dies unterstreicht, dass Architektur nicht bei der funktionalen Modellleistung stehen bleiben kann.\u003C\u002Fp>\n\u003Cp>Die aktuelle Azure Well-Architected AI-Anleitung von Microsoft trennt Anwendungsdesign, Anwendungsplattform, Trainingsdaten, Grounding-Daten und Datenplattform-Anliegen und verbindet sie wiederholt mit Zuverlässigkeit, Sicherheit, operativer Exzellenz, Leistung und Kosten. Die Generative AI- und Agentic AI-Lenses von AWS behandeln Beobachtbarkeit, Sicherheit, Zuverlässigkeit, Modell-\u002FTool-Lebenszyklus, Kosten und menschliche Aufsicht ebenfalls als Architekturanliegen.\u003C\u002Fp>\n\u003Ch2 id=\"section-65\">Häufige Missverständnisse\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\">Missverständnis\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Korrektur\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">„Der Architekt wählt das LLM.“\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Die Modellwahl ist eine Entscheidung innerhalb einer größeren Lösungsarchitektur.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">„Prompt Engineering ist die Architektur.“\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Prompts beeinflussen das Verhalten, aber sie definieren nicht Identität, Datenzugriff, Vertrauensgrenzen, Bereitstellung, Tool-Berechtigungen oder Betrieb.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">„RAG löst Unternehmenswissen.“\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Retrieval ist nur ein Subsystem; Autorisierung, Herkunft, Aktualität, Evidenz, Indexierung, Evaluierung und Quellen-Governance müssen noch entworfen werden.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">„Lokale Laufzeit bedeutet private\u002Flokale KI.“\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Laufzeit-, Inferenz-, Daten- und Control-Plane-Orte sind separate architektonische Eigenschaften.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">„Wenn ein Anbieter Guardrails bietet, ist Sicherheit abgedeckt.“\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sicherheit umfasst Identität, Autorisierung, Geheimnisse, Datenflüsse, Tools, Protokollierung, Bereitstellung, menschliche Genehmigung und Anbietergrenzen.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">„Der Architekt muss jede Komponente schreiben.“\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Praktische Implementierung kann die architektonische Qualität verbessern, aber die Rolle ist durch integrierte Entscheidungsverantwortung definiert, nicht dadurch, jede Schicht selbst zu codieren.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">„Ein Architekturdiagramm beweist Produktionsreife.“\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Reife erfordert implementierte Kontrollen und Validierungsnachweise über Qualität, Sicherheit, Betrieb und geschäftliche Abnahme hinweg.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-67\">Fehlermodi, die ein AI Solution Architect verhindern sollte\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\">Fehlermodus\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Warum es passiert\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Architektonische Korrektur\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modell-zuerst-Design\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Eine vielversprechende Modell-Demo wird zum Systembauplan\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Mit Ergebnis, Einschränkungen und Validierung beginnen; das Modell innerhalb dieses Rahmens auswählen\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Prototyp-Berechtigungen in Produktion\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Gemeinsame Anmeldeinformationen und breiter Zugriff überleben den PoC\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Identitätsweitergabe, geringste Rechte, Tool-Geltungsbereiche und Genehmigungsgrenzen früh definieren\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Retrieval ohne Autorisierung\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Suchqualität wird vor Datenzugriffsregeln entworfen\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Benutzer-\u002FMandantenkontext in Retrieval übernehmen und Autorisierung an Datenzugriffsgrenzen durchsetzen\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Stillschweigende Anbieter-\u002FLaufzeitannahmen\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">„Lokal“, „Cloud“ und „Offline“ werden unpräzise verwendet\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Laufzeit-, Inferenz-, Daten- und Control-Plane-Ort separat dokumentieren\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Kein Fehlervertrag\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Der Happy Path wird entworfen, aber Ablehnungs-\u002FFallback-\u002FFehlerverhalten nicht\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Verhalten bei leerem Retrieval, nicht verfügbarem Modell, Tool-Fehler und Richtlinienverweigerung spezifizieren\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Evaluierung nach der Implementierung\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Qualität wird kurz vor dem Start manuell beurteilt\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Messbare Abnahmekriterien und repräsentative Evaluierungssets definieren, bevor die Architektur eingefroren wird\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Nicht nachvollziehbare Änderung\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modelle, Prompts, Retrieval oder Berechtigungen ändern sich ohne Architekturhistorie\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Kritische Konfiguration versionieren und wesentliche Entscheidungen\u002FValidierungsnachweise aufzeichnen\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Betrieb nur als Infrastruktur behandelt\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">KI-Verhalten ist nach der Bereitstellung nicht beobachtbar\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Traces, Qualitätsmetriken, Sicherheitsereignisse, Kostentelemetrie und Rollback zusammen entwerfen\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-69\">Eine praktische Entscheidungssequenz\u003C\u002Fh2>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Entscheidungssequenz für KI-Lösungsarchitektur\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\">Ergebnis\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Das Benutzer-\u002FGeschäftsergebnis und explizite Nicht-Ziele definieren.\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\">Evidenz und Einschränkungen\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Autoritative Daten, Richtlinien, NFRs, Risiken und Abnahmebedingungen identifizieren.\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\">Systemgrenze\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Benutzer, Identitäten, Anwendungen, Daten, Modelle\u002FAnbieter, Tools und externe Systeme abbilden.\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\">Architekturoptionen\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Muster für Retrieval, Modellzugriff, Orchestrierung, Bereitstellung, Berechtigungen, Evaluierung und Beobachtbarkeit vergleichen.\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\">Abwägungsentscheidungen\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Wesentliche Optionen auswählen und Begründung, Alternativen und Konsequenzen bewahren.\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\">Implementierungsverträge\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Entscheidungen in APIs, Schemas, Berechtigungsregeln, Bereitstellungsdefinitionen und Engineering-Aufgaben umsetzen.\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\">Validierung\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Das implementierte System gegen die ursprünglichen funktionalen und nicht-funktionalen Anforderungen testen.\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\">Operatives Feedback\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Produktionsnachweise, Vorfälle, Qualitätsmetriken und Kosten-\u002FSicherheitssignale nutzen, um kontrollierte Änderungen auszulösen.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-71\">Randfälle und Grenzen der Rolle\u003C\u002Fh2>\n\u003Cp>Einige KI-Produkte werden von Modelltraining, wissenschaftlicher Experimentierung oder spezialisierter Hardware dominiert. In diesen Fällen können Modell-\u002FData-Science- und ML-Systemarchitektur viel tiefer gehen als die hier gezeigte lösungsbezogene Karte. Der AI Solution Architect benötigt weiterhin Integrations- und Betriebsgrenzen, aber die Trainingsplattform selbst kann von einer spezialisierten Architektur verantwortet werden.\u003C\u002Fp>\n\u003Cp>Am anderen Extrem rechtfertigt eine einfache SaaS-Integration möglicherweise keinen dedizierten Architekten. Ein Senior Engineer oder technischer Produktverantwortlicher kann dieselbe Architekturverantwortung tragen. Der nützliche Test ist nicht der Titel, sondern ob bedeutende schichtübergreifende Entscheidungen bewusst getroffen und validiert werden.\u003C\u002Fp>\n\u003Cp>Regulierte, souveräne, air-gapped, sicherheitskritische, hochautonome oder mandantenfähige Systeme verschieben ebenfalls den Schwerpunkt. Identität, Isolation, Datenresidenz, Assurance, Update-Mechanismen, menschliche Aufsicht und Auditierbarkeit können die Modellqualität in der Architektur dominieren.\u003C\u002Fp>\n\u003Ch2 id=\"section-75\">Was würde diese Antwort ändern?\u003C\u002Fh2>\n\u003Cp>Die genaue Verantwortungsgrenze ändert sich, wenn die Architektur von einer Anwendung zu einer wiederverwendbaren Plattform oder zu einer unternehmensweiten Zielarchitektur übergeht. Deshalb verdienen \u003Cstrong>AI Platform Architect\u003C\u002Fstrong> und \u003Cstrong>Enterprise AI Architecture\u003C\u002Fstrong> eine separate kanonische Behandlung, anstatt in diese Rolle integriert zu werden.\u003C\u002Fp>\n\u003Cp>Technologieänderungen sind ebenfalls wichtig. Neue Modellfähigkeiten, Protokolle, lokale Runtimes und Managed Services können einige Implementierungsarbeiten eliminieren, während sie neue Vertrauens- oder Betriebsgrenzen schaffen. Die stabile Verantwortung besteht darin, diese Änderungen als Systemänderungen zu verstehen – nicht ein neues Framework als Ersatz für Architektur zu behandeln.\u003C\u002Fp>\n\u003Ch2 id=\"section-78\">Checkliste für AI Solution Architects\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Prüfung\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Frage\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ergebnis\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sind das Nutzer-\u002FGeschäftsergebnis und die Nicht-Ziel-Grenze explizit?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Anforderungen\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sind funktionale Anforderungen, NFRs, Einschränkungen und Akzeptanzkriterien nachverfolgbar?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Daten\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sind autoritative Quellen, Provenienz, Aktualität, Aufbewahrung und Zugriffsregeln definiert?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Retrieval\u002FKontext\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Reicht die Autorisierung bis zum Retrieval und zur Kontextkonstruktion?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modell\u002FAnbieter\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ist die Modell-\u002FAnbieterauswahl an Fähigkeiten und Einschränkungen gebunden statt an Präferenzen?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Tools\u002FAgenten\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sind Aktionsgrenzen, Berechtigungen, Genehmigungen und Fehlerverhalten explizit?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Identität\u002FSicherheit\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sind menschliche\u002Fmaschinelle Identitäten, Geheimnisse und Vertrauensgrenzen definiert?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Runtime\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sind Runtime-, Inferenz-, Daten- und Control-Plane-Standorte unterschieden?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Evaluierung\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Gibt es messbare Belege für Qualität, Sicherheit und Akzeptanz?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Observability\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Können Produktionsverhalten, Fehler, Kosten und Sicherheitsereignisse untersucht werden?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Änderung\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sind bedeutende Architekturentscheidungen und Ersetzungen nachverfolgbar?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Betrieb\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ist die Verantwortung für Deployment, Rollback, Vorfälle und Lebenszyklus klar?\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-80\">Fazit\u003C\u002Fh2>\n\u003Cp>Ein AI Solution Architect ist die Person oder Architekturfunktion, die eine AI-Chance in ein kohärentes technisches System verwandelt. Die Schlüsselkompetenz ist nicht, die meisten Modellnamen zu kennen; es geht darum, Produktbedarf, Anforderungen, Daten, Anwendungsarchitektur, AI-Fähigkeiten, Sicherheit, Runtime, Bereitstellung und Validierung zu verbinden, ohne die Grenzen zwischen ihnen zu verlieren.\u003C\u002Fp>\n\u003Cp>Eine starke AI-Lösungsarchitektur lässt sich daher wie folgt zusammenfassen: \u003Cstrong>Ziel definieren → Anforderungen und Einschränkungen festlegen → Systemgrenzen entwerfen → bedeutende Trade-offs explizit machen → durch klare Verträge implementieren → gegen Belege validieren → bewusst betreiben und weiterentwickeln.\u003C\u002Fstrong> Das Modell ist wichtig. Die Lösung ist das Produkt.\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\">Was ist ein AI Solution Architect?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Ein AI Solution Architect übersetzt einen Geschäfts- oder Produktbedarf in die Architektur einer konkreten AI-fähigen Lösung und definiert, wie Anwendungslogik, Daten\u002FRetrieval, Modelle, Tools, Identität, Sicherheit, Runtime, Evaluierung und Betrieb zusammenwirken.\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\">Ist ein AI Solution Architect dasselbe wie ein AI Engineer?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Nein. Die Rollen können sich überschneiden, besonders in kleinen Teams, aber ein AI Engineer ist primär eine Implementierungsrolle, während der Solution Architect schichtübergreifende Architekturentscheidungen und Trade-offs für die gesamte Workload besitzt oder koordiniert.\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\">Muss ein AI Solution Architect programmieren können?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Nicht per Definition, aber praktische Implementierungskenntnisse sind sehr wertvoll, weil AI-Architektur APIs, Daten, Retrieval, Sicherheit, Runtimes und Betriebsverhalten überschreitet. Die Rolle ist durch Architekturverantwortung definiert, nicht dadurch, jede Komponente selbst zu schreiben.\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\">Ist die Auswahl eines LLM die Hauptaufgabe?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Nein. Die Modellauswahl ist eine Entscheidung. Produktionsarchitektur benötigt auch Daten- und Retrieval-Grenzen, Berechtigungen, Tools, Anbieter-\u002FRuntime-Entscheidungen, Observability, Evaluierung, Zuverlässigkeit, Kosten und Lebenszyklus-Design.\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\">Was ist der Unterschied zwischen einem AI Solution Architect und einem AI Platform Architect?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Ein AI Solution Architect konzentriert sich auf eine konkrete Lösung oder Workload. Ein AI Platform Architect konzentriert sich auf wiederverwendbare AI-Fähigkeiten und Guardrails, die mehrere Lösungen unterstützen.\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\">Was ist der Unterschied zwischen einem AI Solution Architect und einem Enterprise AI Architect?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Der Solution Architect arbeitet im Anwendungs-\u002FWorkload-Umfang. Enterprise AI Architecture arbeitet über das organisatorische Portfolio, die Zielarchitektur, Governance, gemeinsame Fähigkeiten, Integrationsprinzipien und strategische Einschränkungen.\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\">Wo passen RAG und Agenten hinein?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Sie sind Architekturmuster oder Subsysteme innerhalb einer Lösung, wenn die Anforderungen sie rechtfertigen. RAG adressiert retrieval-gestützten Kontext; Agenten fügen Planung\u002FTool-Ausführung hinzu und damit zusätzliche Identitäts-, Berechtigungs-, Orchestrierungs- und Betriebsbelange.\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\">Was beweist, dass die Architektur funktioniert?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Implementierung plus Validierungsbelege: Funktionstests, Evaluierungsergebnisse, Sicherheits-\u002FAutorisierungstests, Leistungs- und Zuverlässigkeitsmessungen, Observability, Betriebsproben und Abnahme gegen die ursprünglichen Anforderungen.\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\">Kernbegriffe\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\">Architekturverantwortung für eine konkrete AI-fähige Lösung oder Workload, die Produktanforderungen mit Anwendungs-, Daten-, Modell-, Tool-, Sicherheits-, Runtime- und Betriebsdesign integriert.\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\">Systemgrenze\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Die explizite Trennung zwischen dem, was zur Lösung gehört, und den Nutzern, Systemen, Anbietern, Datenquellen und Umgebungen, mit denen sie interagiert.\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\">Vertrauensgrenze\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Ein Punkt, an dem Daten, Identitäten oder Steuerung zwischen Komponenten mit unterschiedlichen Vertrauensannahmen wechseln und daher explizite Sicherheitskontrollen erfordern.\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\">Grounding\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Die Versorgung eines AI-Modells mit relevanten externen Informationen oder Belegen, damit seine Antwort auf Quellen jenseits der Modellparameter basieren kann.\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\">Anbieterabstraktion\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Eine Anwendungsgrenze, die Teile der Lösung von einer Modell-\u002FAnbieterschnittstelle entkoppelt. Nützlich, wenn durch Routing-, Portabilitäts- oder Richtlinienanforderungen gerechtfertigt, aber nicht frei von Trade-offs.\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\">Evaluierung\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Strukturierte Messung des Verhaltens einer AI-Workload gegen definierte Akzeptanzkriterien, einschließlich Aufgabenqualität und relevanter Sicherheits-, Leistungs- und Betriebseigenschaften.\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\">Architekturrolle, die sich auf wiederverwendbare AI-Plattformfähigkeiten konzentriert, die von mehreren Lösungen genutzt werden, statt auf die Architektur einer Workload.\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\">Architektur auf Organisationsebene, die AI-Fähigkeiten, Plattformen, Governance, Integration und strategische Einschränkungen über ein Portfolio hinweg koordiniert.\u003C\u002Fdd>\u003C\u002Fdiv>\u003C\u002Fdl>\u003C\u002Fsection>\n\u003Ch2 id=\"section-85\">Verwandtes kanonisches Wissen\u003C\u002Fh2>\n\u003Cp>Dieser Artikel gehört zum Cluster AI Architecture Foundations. Seine direkten Grundlagen sind \u003Cstrong>Generative AI Explained: Models, Retrieval, Tools and Applications Are Not the Same Thing\u003C\u002Fstrong> und \u003Cstrong>ADR vs NFR: Architecture Decisions and System Quality Are Not the Same Thing\u003C\u002Fstrong>. Benachbarte kanonische Knoten umfassen \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> und \u003Cstrong>AI Governance\u003C\u002Fstrong>. URLs werden bewusst nicht erfunden, wo diese Knoten noch nicht veröffentlicht sind.\u003C\u002Fp>\n\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fde\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\">Bestehende kanonische Erklärung von stajic.de zu retrieval-augmented generation, nützlich für den Retrieval-\u002FGrounding-Teil der AI-Lösungsarchitektur.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ch2 id=\"section-88\">Primärquellen und aktuelle Architekturanleitung\u003C\u002Fh2>\n\u003Cp>Die folgenden externen Quellen stützen die allgemeinen Architekturbehauptungen; die Abschnitte zu SenseFlow und Aaasaasa AI Client sind ausdrücklich originäre Projekt-\u002FImplementierungsbelege. Referenzen zum aktuellen Stand wurden am 8. Oktober 2026 geprüft. NIST weist darauf hin, dass AI RMF 1.0 überarbeitet wird, sodass versionssensitive Governance-Referenzen bei Veröffentlichung eines Nachfolgers erneut geprüft werden sollten.\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\">Aktueller internationaler Standard für die Struktur und Ausdrucksweise von Architekturbeschreibungen. Er unterscheidet Architektur von ihrer Beschreibung und schreibt keine einzelne Architekturmethode, kein Werkzeug und kein Aufzeichnungsformat vor.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.nist.gov\u002Fitl\u002Fai-risk-management-framework\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">NIST AI Risk Management Framework\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">NISTs AI RMF-Ressourcenseite. Stand Oktober 2026 wird dort angegeben, dass AI RMF 1.0 überarbeitet wird, und es werden das Generative AI Profile und verwandte Ressourcen verlinkt.\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 — Govern, Map, Measure, Manage\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Offizielle NIST AIRC-Präsentation des AI RMF 1.0 Core, einschließlich der vier Funktionen und der lebenszyklusorientierten Risikomanagement-Rahmung.\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 — Generative AI Profile\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Sektorübergreifendes Generative-AI-Profil für AI RMF 1.0, veröffentlicht am 26. Juli 2024 und 2026 von NIST aktualisiert.\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 — AI Workloads\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Aktuelle Architekturleitlinien auf Workload-Ebene, die KI-Anwendungsdesign, Anwendungsplattform, Trainingsdaten, Grounding-Daten, Datenplattform und Produktionsreife abdecken.\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 — Application Design for AI Workloads\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Leitlinien zu Modell-\u002FTool-Abstraktion, Datenzugriffsgrenzen, Identitätsweitergabe, Autorisierung und Trennung von Client-, Intelligenz-, Wissens- und Tool-Schichten.\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 — Design Principles for AI Workloads\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Aktuelle Designprinzipien für KI-Workloads in den Bereichen Zuverlässigkeit, Sicherheit, Kosten, operative Exzellenz und Leistung, einschließlich Identitäts- und Datenschutzverantwortlichkeiten.\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 and GenAIOps for AI Workloads\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Leitlinien zum Produktionslebenszyklus, die Monitoring, Qualitätsgates, Modell-\u002FPrompt-Verhalten, Sicherheit und operative Messung abdecken.\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\">AWS-Architekturleitlinien für generative KI-Workloads in den Bereichen operative Exzellenz, Sicherheit, Zuverlässigkeit, Leistungseffizienz, Kostenoptimierung und Nachhaltigkeit.\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\">2026 veröffentlicht, behandelt agentische architekturspezifische Belange einschließlich Identitäten, Tools, Orchestrierung, menschliche Aufsicht, Zuverlässigkeit, Tracing und Kosten von Reasoning-Schleifen.\u003C\u002Fp>\u003C\u002Fa>",{"time":211,"blocks":212,"version":1067},1791476753604,[213,218,225,231,236,243,247,251,255,299,303,307,311,339,343,347,351,355,359,407,411,415,419,423,427,431,435,439,443,447,451,455,459,463,467,471,475,479,483,487,491,495,499,530,534,538,582,586,590,638,642,646,652,656,660,664,668,672,676,680,684,688,692,696,700,704,732,736,776,780,809,813,817,821,825,829,833,837,841,880,884,888,892,929,961,965,969,979,983,987,995,1003,1011,1019,1027,1035,1043,1051,1059],{"id":214,"data":215,"type":217},"intro",{"text":216},"Ein \u003Cstrong>AI Solution Architect\u003C\u002Fstrong> übersetzt einen Geschäfts- oder Produktbedarf in die Architektur einer konkreten KI-fähigen Lösung. Die Rolle definiert Systemgrenzen und die wesentlichen Entscheidungen über Anwendungslogik, autoritative Daten, Retrieval und Kontext, Modelle und Anbieter, Tools oder Agenten, Identität und Berechtigungen, Sicherheit, Laufzeit und Deployment, Observability, Evaluierung, Kosten und operatives Verhalten. Es geht nicht einfach um Modellauswahl oder Prompt Engineering: Die architektonische Verantwortung besteht darin, die gesamte Lösung implementierbar, governbar, testbar und betreibbar zu machen.","paragraph",{"id":219,"data":220,"type":224},"direct",{"body":221,"title":222,"variant":223},"\u003Cstrong>Ein AI Solution Architect entwirft die vollständige KI-fähige Lösung, nicht nur das KI-Modell.\u003C\u002Fstrong> Die Rolle verbindet Anforderungen und nicht-funktionale Anforderungen mit Architekturentscheidungen, setzt die notwendigen Anwendungs-, Daten-, Modell-, Tool- und Laufzeitschichten zusammen, macht Vertrauens- und Fehlergrenzen explizit und definiert, wie das implementierte System validiert und betrieben wird.","Direkte Antwort","info","callout",{"id":226,"data":227,"type":224},"role-note",{"body":228,"title":229,"variant":230},"\u003Cstrong>AI Solution Architect ist eine praktische Rollenbezeichnung, kein universell standardisierter Jobtitel.\u003C\u002Fstrong> ISO\u002FIEC\u002FIEEE 42010:2022 standardisiert Konzepte für Architekturbeschreibungen; es definiert diese Jobrolle nicht. Organisationen können die Verantwortlichkeiten auf mehrere Personen verteilen. In diesem Artikel bezeichnet der Begriff die Architekturverantwortung für eine konkrete KI-fähige Lösung oder Workload.","Hinweis zur Terminologie","note",{"id":232,"data":233,"type":224},"version-note",{"body":234,"title":235,"variant":230},"Die Architekturprinzipien hier sind bewusst anbieterneutral, während aktuelle Anbieterempfehlungen als Implementierungsnachweis verwendet werden. NIST AI RMF 1.0 wird derzeit überarbeitet; NIST AI 600-1 bleibt das veröffentlichte Generative AI Profile. Die unten zitierten Empfehlungen von Microsoft und AWS spiegeln aktuelle Produktionsanliegen wie Identität, Datengrenzen, Modellabstraktion, Sicherheit, Observability, Evaluierung, Zuverlässigkeit und Kosten wider.","Hinweis zu aktuellen Quellen — 8. Oktober 2026",{"id":237,"data":238,"type":242},"toc",{"title":239,"maxLevel":240,"minLevel":241},"Inhalt",3,2,"tableOfContents",{"id":244,"data":245,"type":41},"h-meaning",{"text":246,"level":241},"Was architektiert ein AI Solution Architect tatsächlich?",{"id":248,"data":249,"type":217},"p-meaning-1",{"text":250},"Der Gegenstand der Arbeit ist die \u003Cstrong>Lösung\u003C\u002Fstrong>: das vollständige soziotechnische System, das einen Bedarf in nützliches, kontrolliertes Verhalten umsetzt. Ein Modell kann zentral für dieses System sein, ist aber dennoch nur eine Abhängigkeit. Dasselbe Modell kann an einem sicheren internen Suchassistenten, einem unsicheren überprivilegierten Agenten, einem kundenorientierten Feature mit niedriger Latenz oder einem teuren Prototyp beteiligt sein, der nicht wirtschaftlich betrieben werden kann. Die Architektur bestimmt diese Unterschiede.",{"id":252,"data":253,"type":217},"p-meaning-2",{"text":254},"Eine nützliche Grenze ist daher: \u003Cstrong>Geschäftsergebnis → Anforderungen → Systemverantwortlichkeiten → Architekturentscheidungen → Implementierung → Validierung → Betrieb\u003C\u002Fstrong>. Der AI Solution Architect arbeitet über diese Kette hinweg und kollaboriert mit Produkt-, Engineering-, Daten-, Sicherheits-, Infrastruktur-, Governance- und Domänenspezialisten.",{"id":256,"data":257,"type":298},"solution-vs-model",{"rows":258,"title":289,"layout":290,"columns":291},[259,265,271,277,283],{"id":260,"label":261,"values":262},"m1","Fähigkeit",{"model":263,"solution":264},"Which model can generate or reason well enough?","Which combination of model, data, application logic, retrieval, tools and controls produces the required behavior?",{"id":266,"label":267,"values":268},"m2","Daten",{"model":269,"solution":270},"What context can fit in the prompt?","What is authoritative, who may access it, how is it retrieved, versioned, filtered and cited?",{"id":272,"label":273,"values":274},"m3","Sicherheit",{"model":275,"solution":276},"Does the provider offer security features?","What are the trust boundaries, identities, permissions, secrets, data flows and failure containment mechanisms?",{"id":278,"label":279,"values":280},"m4","Betrieb",{"model":281,"solution":282},"What is the token latency?","How is the complete workload deployed, observed, evaluated, recovered, versioned and cost-controlled?",{"id":284,"label":285,"values":286},"m5","Änderung",{"model":287,"solution":288},"Can we switch models?","Which dependencies are abstracted, what changes require an ADR, and how do we validate that a replacement still meets requirements?","Die Lösung ist weiter als das Modell","table",[292,295],{"id":293,"label":294},"model","Modellzentrierte Frage",{"id":296,"label":297},"solution","Lösungsarchitektur-Frage","comparison",{"id":300,"data":301,"type":41},"h-simple",{"text":302,"level":241},"Das einfachste Beispiel",{"id":304,"data":305,"type":217},"p-simple-1",{"text":306},"Stellen Sie sich vor, ein Unternehmen möchte einen internen Assistenten, der Fragen von Technikern anhand von Wartungshandbüchern und Betriebsverfahren beantwortet. Das sichtbare Feature klingt einfach: eine Frage eingeben und eine Antwort mit Quellen erhalten.",{"id":308,"data":309,"type":217},"p-simple-2",{"text":310},"Die Architekturfrage ist viel größer. Welche Dokumente sind autoritativ? Wie werden Benutzer authentifiziert? Muss das Retrieval Abteilungs- oder Standortberechtigungen respektieren? Darf die Antwort nur abgerufene Belege verwenden? Welches Modell ist für die Datenklassifizierung akzeptabel? Kann ein Cloud-Anbieter die Inhalte erhalten? Was passiert, wenn das Retrieval nichts findet? Wie werden Zitate erzeugt? Wie wird die Antwortqualität bewertet? Welche Latenz und welche Kosten sind akzeptabel? Wer kann Logs einsehen, und was darf darin gespeichert werden?",{"id":312,"data":313,"type":338},"simple-flow",{"steps":314,"title":336,"orientation":337},[315,318,321,324,327,330,333],{"label":316,"description":317},"1. Ergebnis definieren","Klären Sie Benutzer, Geschäftswert, Aufgabengrenze und was eine erfolgreiche Antwort oder Aktion bedeutet.",{"label":319,"description":320},"2. Anforderungen erfassen","Machen Sie funktionale Anforderungen, NFRs, Einschränkungen, Datenregeln, Risikotoleranz und Abnahmekriterien explizit.",{"label":322,"description":323},"3. Grenzen festlegen","Identifizieren Sie Benutzer, Identitäten, Anwendungen, autoritative Daten, Modell-\u002FAnbieterabhängigkeiten, Tools, externe Systeme und Vertrauenszonen.",{"label":325,"description":326},"4. Architektur entwerfen","Wählen Sie Muster für Daten\u002FRetrieval, Modell, Orchestrierung, Tools, Berechtigungen, Laufzeit, Deployment, Fallback und Observability.",{"label":328,"description":329},"5. Wesentliche Entscheidungen dokumentieren","Bewahren Sie architektonische Entscheidungen, Alternativen, Trade-offs und Konsequenzen auf, damit spätere Änderungen nachvollziehbar bleiben.",{"label":331,"description":332},"6. Implementieren und integrieren","Überführen Sie die Architektur in Anwendungscode, APIs, Richtlinien, Infrastruktur, Workflows und operative Kontrollen.",{"label":334,"description":335},"7. Validieren und betreiben","Testen Sie Qualität, Sicherheit, Zuverlässigkeit, Kosten und Benutzerergebnisse; überwachen Sie den realen Workload und führen Sie Erkenntnisse zurück in Entscheidungen.","Vom Bedarf zu einer betreibbaren KI-Lösung","auto","processFlow",{"id":340,"data":341,"type":41},"h-where-simple-stops",{"text":342,"level":241},"Wo das einfache Beispiel endet",{"id":344,"data":345,"type":217},"p-stop-1",{"text":346},"Ein Proof of Concept kann oft Architektur überspringen, was in der Produktion nicht möglich ist. Ein Entwickler kann einen Anbieter fest codieren, einen gemeinsamen API-Schlüssel verwenden, alle Dokumente in einen Index legen, Retrieval ohne Filterung nach Benutzerkontext ausführen, Prompts wörtlich protokollieren und Qualität manuell beurteilen. Das kann Machbarkeit demonstrieren, aber es begründet keine Produktionsarchitektur.",{"id":348,"data":349,"type":217},"p-stop-2",{"text":350},"Die Produktion führt Einschränkungen ein, die interagieren: Mandanten- oder Benutzerisolation, Datenschutz, Datenresidenz, Durchsatz, Latenz, Kosten, Anbieterquoten, Fallback-Verhalten, Auditierbarkeit, Änderungen der Modellversion, Retrieval-Qualität, Tool-Berechtigungen, Incident Response und Deployment-Lebenszyklus. Die Aufgabe des Architekten ist nicht, jede Qualität gleichzeitig zu maximieren; sie besteht darin, die Trade-offs explizit zu machen und eine Lösung zu entwerfen, die die tatsächliche Prioritätenmenge erfüllt.",{"id":352,"data":353,"type":41},"h-responsibility-map",{"text":354,"level":241},"Karte der Architekturverantwortlichkeiten",{"id":356,"data":357,"type":217},"p-resp-intro",{"text":358},"Die genaue Aufteilung variiert je nach Organisation, aber die folgende Karte erfasst die wiederkehrenden Verantwortlichkeiten der KI-Architektur auf Lösungsebene. Der Architekt implementiert möglicherweise nicht jede Schicht persönlich; die Verantwortung besteht darin, die Schichten kohärent zusammenfügen zu lassen und die kritischen Entscheidungen nachvollziehbar zu halten.",{"id":360,"data":361,"type":290},"responsibility-table",{"content":362,"stretched":42,"withHeadings":13},[363,367,371,375,379,383,387,391,395,399,403],[364,365,366],"Architekturbereich","Fragen, die der KI-Lösungsarchitekt klären muss","Typische Ergebnisse",[368,369,370],"Ergebnis und Umfang","Wer ist der Benutzer? Welche Aufgabe liegt im Geltungsbereich? Was darf das System nicht tun? Was gilt als Erfolg?","Lösungskontext, Fähigkeitsgrenze, Abnahmekriterien",[372,373,374],"Anforderungen und NFRs","Welche Qualitäts-, Sicherheits-, Verfügbarkeits-, Latenz-, Kosten-, Standort- und Compliance-Einschränkungen gelten?","Anforderungsübersicht, NFRs, Einschränkungen, Validierungskriterien",[376,377,378],"Anwendung und Orchestrierung","Wo endet deterministische Anwendungslogik und wo beginnt KI-Verhalten? Wie werden Workflows koordiniert?","Komponentenmodell, APIs, Orchestrierungsgrenzen, Fehlerpfade",[380,381,382],"Autoritative Daten und Abruf","Was ist die Single Source of Truth? Wie werden Daten aufgenommen, autorisiert, abgerufen, gefiltert, gerankt und zitiert?","Datenflüsse, Abrufarchitektur, Metadaten- und Autorisierungsregeln",[384,385,386],"Modell- und Anbieterschicht","Welche Fähigkeiten sind erforderlich? Welche Anbieter-\u002FLaufzeitbeschränkungen sind relevant? Was sollte abstrahiert werden?","Modell-\u002FAnbieterentscheidung, Routing-\u002FFallback-Richtlinie, Abstraktionsgrenze",[388,389,390],"Tools und Agenten","Welche Aktionen kann das System ausführen? Welche Aktionen erfordern eine Genehmigung? Wie werden Tool-Identitäten und Berechtigungen durchgesetzt?","Tool-Verträge, Agentengrenzen, Genehmigungs- und Least-Privilege-Regeln",[392,393,394],"Identität und Sicherheit","Welche menschlichen und maschinellen Identitäten existieren? Wo werden Geheimnisse aufbewahrt? Welche Vertrauensgrenzen werden überschritten?","Bedrohungs-\u002FVertrauensgrenzenmodell, Identitätsweitergabe, Geheimnis- und Autorisierungsdesign",[396,397,398],"Laufzeit und Bereitstellung","Wo werden Komponenten ausgeführt? Was ist lokal, Cloud, Edge oder hybrid? Welche Netzwerk- und Verfügbarkeitsannahmen bestehen?","Bereitstellungsansicht, Laufzeittopologie, Umgebungs- und Konnektivitätsentscheidungen",[400,401,402],"Evaluierung und Observability","Wie wird die Qualität vor und nach der Veröffentlichung gemessen? Welche Traces, Metriken, Logs und Nachweise sind erforderlich?","Evaluierungsplan, Telemetrie, Audit-Trail, Release-Gates",[404,405,406],"Betrieb und Änderung","Wie werden Modelle\u002FPrompts\u002FKonfiguration\u002FDatenversionen geändert, zurückgerollt und unterstützt?","Betriebsmodell, Lifecycle-Kontrollen, ADRs, Runbooks, Änderungsregeln",{"id":408,"data":409,"type":41},"h-requirements",{"text":410,"level":240},"1. Produktbedarf in Architekturanforderungen übersetzen",{"id":412,"data":413,"type":217},"p-requirements-1",{"text":414},"KI-Architektur beginnt vor der Modellauswahl. Der Architekt bestimmt zunächst, was die Lösung erreichen soll und unter welchen Einschränkungen. Dies umfasst funktionales Verhalten, aber auch die NFRs und Richtlinien, die den Designraum einschränken: Sicherheit, Zuverlässigkeit, Latenz, Datenschutz, Standort, Wartbarkeit, Kosten und betriebliche Unterstützung.",{"id":416,"data":417,"type":217},"p-requirements-2",{"text":418},"Hier ist die Unterscheidung von A02 wichtig: Eine Anforderung wie „unautorisierte Benutzer dürfen keine eingeschränkten Dokumente abrufen“ ist keine Architekturentscheidung. Sie ist ein Treiber. Entscheidungen über Identitätsweitergabe, Indexpartitionierung, Metadatenfilterung, API-Grenzen und Autorisierungsdurchsetzung sind architektonische Antworten, die später validiert werden müssen.",{"id":420,"data":421,"type":41},"h-data",{"text":422,"level":240},"2. Autoritative Daten, Abruf und Kontext entwerfen",{"id":424,"data":425,"type":217},"p-data-1",{"text":426},"KI-Systeme scheitern oft an der Grenze zwischen Modellverhalten und Unternehmenswahrheit. Ein Architekt muss definieren, welche Quellen autoritativ sind, was Aktualität und Herkunft bedeuten, wie Zugriffskontrolle den Abruf erreicht und wie abgerufene Evidenz zum Modellkontext wird. Eine Vektordatenbank, ein Embedding-Modell oder eine RAG-Bibliothek ist nicht die Architektur an sich.",{"id":428,"data":429,"type":217},"p-data-2",{"text":430},"Die aktuelle KI-Workload-Anleitung von Microsoft macht dieselbe Trennung explizit: Anwendungscode sollte Datenzugriffsgrenzen nicht umgehen; Benutzer- oder Mandantenkontext sollte sich in Abruf und Filterung fortsetzen; Grounding-Daten müssen für Durchsuchbarkeit ausgelegt sein und gleichzeitig Sicherheits- und Compliance-Anforderungen erfüllen.",{"id":432,"data":433,"type":41},"h-model",{"text":434,"level":240},"3. Modelle und Anbieter als Abhängigkeiten behandeln, nicht als das gesamte System",{"id":436,"data":437,"type":217},"p-model-1",{"text":438},"Die Modellauswahl ist wichtig, sollte aber von der erforderlichen Fähigkeit und den Einschränkungen getrieben sein. Der Architekt berücksichtigt Reasoning- oder Generierungsqualität, Modalität, Kontextgrenzen, Latenz, Datenhandhabung, Bereitstellungsort, Anbieterverfügbarkeit, Kosten, Observability und Ersetzungsrisiko.",{"id":440,"data":441,"type":217},"p-model-2",{"text":442},"Die Anbieterabstraktion ist nicht automatisch eine „bessere Architektur“. Sie verursacht Engineering-Kosten und kann anbieterspezifische Fähigkeiten verbergen. Sie ist gerechtfertigt, wenn Portabilität, Fallback, Richtlinientrennung oder Multi-Provider-Routing eine explizite Anforderung sind. Andernfalls kann eine direkte Integration die bessere Entscheidung sein. Der Punkt ist, den Kompromiss bewusst zu treffen.",{"id":444,"data":445,"type":41},"h-tools",{"text":446,"level":240},"4. Werkzeuge, Aktionen und Agentengrenzen architektonisch gestalten",{"id":448,"data":449,"type":217},"p-tools-1",{"text":450},"Wenn ein KI-System Werkzeuge aufrufen, Daten ändern, Nachrichten senden, Code ausführen oder Geschäftssysteme bedienen kann, ändert sich das architektonische Risiko. Werkzeugzugriff benötigt ein eigenes Identitäts- und Autorisierungsmodell. Die Fähigkeit des Modells, eine Aktion anzufordern, ist nicht dasselbe wie die Berechtigung, sie auszuführen.",{"id":452,"data":453,"type":217},"p-tools-2",{"text":454},"Für agentische Workloads betont die aktuelle AWS-Richtlinie zusätzliche Dimensionen wie Agentenidentitäten, Werkzeugzugriff, Orchestrierung, menschliche Aufsicht, Tracing, Fehlerbehandlung und Kosten iterativer Reasoning-Schleifen. Dies sind Lösungsbelange, selbst wenn ein Framework einige der Implementierungsmechanismen verbirgt.",{"id":456,"data":457,"type":41},"h-security",{"text":458,"level":240},"5. Vertrauensgrenzen und Berechtigungen explizit machen",{"id":460,"data":461,"type":217},"p-security-1",{"text":462},"Eine Produktions-KI-Lösung hat mehrere Vertrauensgrenzen: Browser oder Client, Anwendungs-Backend, KI-Orchestrierung, Retrieval-\u002FDatendienste, Modellanbieter, Werkzeug-APIs, lokale Laufzeitumgebungen und externe Systeme. Jede Grenze sollte beantworten: Wer ruft an, in wessen Namen, mit welcher Berechtigung, für welche Ressource, mit welchem Audit-Trail und mit welcher Fehlereingrenzung?",{"id":464,"data":465,"type":217},"p-security-2",{"text":466},"Sicherheit kann nicht auf eine „Guardrail“ um das Modell herum verschoben werden. Die KI-Workload-Richtlinie von Microsoft verortet Sicherheit ausdrücklich über alle Architekturschichten hinweg und fordert Identitäts-\u002FZugriffsmanagement, Datenschutz, Inhaltskontrollen und Lebenszyklussicherheit. NIST behandelt Governance und Risikomanagement ebenfalls als kontinuierlich über den gesamten KI-Lebenszyklus.",{"id":468,"data":469,"type":41},"h-runtime",{"text":470,"level":240},"6. Entscheiden, wo das System tatsächlich läuft",{"id":472,"data":473,"type":217},"p-runtime-1",{"text":474},"„Lokale KI“, „Cloud-KI“ und „hybride KI“ sind nur dann architektonische Aussagen, wenn die Ausführungs- und Datenpfade präzise sind. Ein lokaler Desktop-Prozess kann dennoch ein Cloud-Modell aufrufen. Eine in der Cloud gehostete Anwendung kann aus einer lokalen Datenquelle abrufen. Eine air-gapped Lösung hat völlig andere Einschränkungen bei Updates, Modellverteilung und Observability.",{"id":476,"data":477,"type":217},"p-runtime-2",{"text":478},"Der Architekt trennt daher \u003Cstrong>Laufzeitort\u003C\u002Fstrong>, \u003Cstrong>Inferenzort\u003C\u002Fstrong>, \u003Cstrong>Datenort\u003C\u002Fstrong> und \u003Cstrong>Control Plane\u003C\u002Fstrong>. Deren Vermischung erzeugt falsche Sicherheits- und Deployment-Annahmen.",{"id":480,"data":481,"type":41},"h-eval",{"text":482,"level":240},"7. Evaluation, Observability und operative Abnahme definieren",{"id":484,"data":485,"type":217},"p-eval-1",{"text":486},"KI-Verhalten ist teilweise nichtdeterministisch, daher kann sich die Release-Definition nicht nur auf konventionelle Unit-Tests stützen. Die Architektur benötigt messbare Abnahmekriterien: Aufgabenerfolg, Groundedness oder Zitatkorrektheit wo relevant, Verweigerungsverhalten, Tool-Sicherheit, Latenz, Kosten, Zuverlässigkeit und Sicherheitstests. Die genauen Metriken hängen vom Anwendungsfall ab.",{"id":488,"data":489,"type":217},"p-eval-2",{"text":490},"Die aktuelle Well-Architected-KI-Richtlinie von Microsoft behandelt Monitoring als kontinuierlich und wendet es auf Modellverhalten, Prompts\u002FCompletions, Anomalien, Sicherheit und Produktions-Qualitätsgates an. AWS behandelt Observability, Lifecycle-Management und Modell-\u002FPrompt-Nachverfolgbarkeit ebenfalls als operative Architekturanliegen.",{"id":492,"data":493,"type":41},"h-artifacts",{"text":494,"level":241},"Was sollte die Rolle produzieren?",{"id":496,"data":497,"type":217},"p-artifacts-1",{"text":498},"Architektur ist nicht die Präsentationsfolie. Die nützlichen Ergebnisse sind die Artefakte, die es Engineering, Sicherheit, Produkt und Betrieb ermöglichen, konsistente Entscheidungen zu treffen und später zu verstehen, warum das System in seiner aktuellen Form existiert.",{"id":500,"data":501,"type":290},"artifacts-table",{"content":502,"stretched":42,"withHeadings":13},[503,506,509,512,515,518,521,524,527],[504,505],"Artefakt","Zweck",[507,508],"Lösungskontext und -grenze","Zeigt Benutzer, externe Systeme, Hauptverantwortlichkeiten und was außerhalb des Geltungsbereichs liegt",[510,511],"Anforderungs-\u002FNFR-Zuordnung","Verbindet Produktbedarf und Einschränkungen mit Architekturarbeit und Validierung",[513,514],"Komponenten- und Datenflussansichten","Zeigt Anwendung, Daten\u002FRetrieval, Modell, Tools, Identität und Laufzeitinteraktionen",[516,517],"Vertrauens- und Berechtigungsmodell","Macht Identitäten, Secrets, Autorisierung, sensible Daten und risikoreiche Aktionen explizit",[519,520],"Architecture Decision Records","Bewahrt bedeutende Entscheidungen, Alternativen, Trade-offs, Status und Konsequenzen",[522,523],"Evaluations- und Abnahmeplan","Definiert den Nachweis, der erforderlich ist, um zu behaupten, dass die Lösung Qualitäts- und Sicherheitserwartungen erfüllt",[525,526],"Deployment- und Betriebsansicht","Definiert Umgebungen, Laufzeitorte, Observability, Rollback, Incident- und Lifecycle-Verantwortlichkeiten",[528,529],"Traceability-Links","Verbindet Anforderungen, Entscheidungen, Implementierungsarbeit, Tests und operative Nachweise",{"id":531,"data":532,"type":41},"h-tradeoffs",{"text":533,"level":241},"Die Arbeit besteht überwiegend aus Trade-offs, nicht aus der Auswahl von „Best Practices“",{"id":535,"data":536,"type":217},"p-tradeoffs-1",{"text":537},"Architektur existiert, weil wünschenswerte Qualitäten miteinander in Konflikt stehen. Ein kostengünstigeres Modell kann die Qualität verringern. Ein leistungsfähigeres Modell kann die Latenz oder Data-Governance-Einschränkungen erhöhen. Aggressives Caching kann Kosten und Geschwindigkeit verbessern, während es die Aktualität verkompliziert. Autonomere Agenten können menschlichen Aufwand reduzieren, während sie den Blast Radius und die Audit-Anforderungen erhöhen.",{"id":539,"data":540,"type":290},"tradeoff-table",{"content":541,"stretched":42,"withHeadings":13},[542,547,552,557,562,567,572,577],[543,544,545,546],"Entscheidung","Potenzieller Nutzen","Potenzielle Kosten \u002F Risiko","Architekturfrage",[548,549,550,551],"Managed-Cloud-Modell","Schnelle Einführung, starke Managed-Fähigkeiten","Externe Abhängigkeit, Daten- und Kosteneinschränkungen","Erlaubt die Workload den Anbieter-\u002FDatenpfad und erfüllt sie die Resilienzanforderungen?",[553,554,555,556],"Lokale\u002Fself-hosted Inferenz","Kontrolle, Offline-\u002FPrivate-Optionen","Hardware-, Betriebs- und Modell-Lifecycle-Aufwand","Ist der Kontrollnutzen die operative Verantwortung wert?",[558,559,560,561],"Integration eines einzelnen Anbieters","Einfachere Implementierung, volle Anbieterfunktionen","Höhere Wechsel-\u002FAusfallkonzentration","Sind Portabilität oder Fallback tatsächlich erforderlich?",[563,564,565,566],"Anbieterabstraktion","Portabilität, Routing- und Richtlinientrennung","Risiko des kleinsten gemeinsamen Nenners, mehr Code\u002FTests","Welche Unterschiede müssen sichtbar bleiben statt abstrahiert zu werden?",[568,569,570,571],"Großer Kontext","Mehr Informationen pro Anfrage","Latenz, Kosten, Aufmerksamkeitsverwässerung, Leckage-Oberfläche","Sollten Daten abgerufen\u002Fgefiltert werden, statt immer injiziert zu werden?",[573,574,575,576],"Leistungsstarke Tools \u002F Autonomie","Mehr End-to-End-Automatisierung","Höhere Privilegien und Blast Radius bei Fehlern","Welche Aktionen erfordern Least Privilege, Bestätigung oder menschliche Genehmigung?",[578,579,580,581],"Strikte Validierung und Protokollierung","Bessere Nachweise und Betrieb","Latenz-, Speicher-, Datenschutz- und Komplexitätskosten","Welche Nachweise sind für dieses Risikoniveau erforderlich?",{"id":583,"data":584,"type":41},"h-adjacent",{"text":585,"level":241},"Wie unterscheidet sich dies von angrenzenden Rollen?",{"id":587,"data":588,"type":217},"p-adjacent-intro",{"text":589},"Titel überschneiden sich stark zwischen Unternehmen. Die nützliche Unterscheidung ist der \u003Cstrong>Umfang der Architekturverantwortung\u003C\u002Fstrong>, nicht das HR-Label.",{"id":591,"data":592,"type":298},"role-comparison",{"rows":593,"title":630,"layout":290,"columns":631},[594,600,606,612,618,624],{"id":595,"label":596,"values":597},"r1","AI Solution Architect",{"role":598,"focus":599},"One concrete AI-enabled solution\u002Fworkload","How requirements, data, models, tools, security, runtime and operations fit together to deliver the target outcome",{"id":601,"label":602,"values":603},"r2","AI Platform Architect",{"role":604,"focus":605},"Reusable AI platform capabilities across many solutions","Shared provider gateways, model access, identity, evaluation, retrieval services, observability, deployment patterns and developer experience",{"id":607,"label":608,"values":609},"r3","Enterprise AI Architect",{"role":610,"focus":611},"Organization\u002Fportfolio-level target architecture","Capability landscape, governance, integration principles, shared platforms, standards, sourcing and strategic constraints across domains",{"id":613,"label":614,"values":615},"r4","AI \u002F ML Engineer",{"role":616,"focus":617},"Implementation of AI\u002FML behavior and pipelines","Models, data, inference, evaluation, application logic and engineering tasks within the architecture",{"id":619,"label":620,"values":621},"r5","Security Architect",{"role":622,"focus":623},"Security architecture across systems","Threats, identity, authorization, data protection, controls, assurance and compliance boundaries",{"id":625,"label":626,"values":627},"r6","Product \u002F Delivery Lead",{"role":628,"focus":629},"Outcome, scope, prioritization and delivery system","Why\u002Fwhat to build, sequencing, stakeholders, milestones, acceptance and value realization","Angrenzende Rollen beantworten unterschiedliche primäre Fragen",[632,635],{"id":633,"label":634},"role","Rolle",{"id":636,"label":637},"focus","Primärer Architekturfokus",{"id":639,"data":640,"type":217},"p-adjacent-2",{"text":641},"In einem kleinen Produktteam kann eine Person mehrere dieser Bereiche abdecken. In einem großen Unternehmen können es separate Rollen mit formellen Review-Boards sein. Die Architekturverantwortung verschwindet nicht, wenn sich der Titel ändert.",{"id":643,"data":644,"type":41},"h-implementation",{"text":645,"level":241},"Implementierungsnachweise: Wie diese Grenzen in meiner eigenen Arbeit erscheinen",{"id":647,"data":648,"type":224},"implementation-boundary",{"body":649,"title":650,"variant":651},"Die folgenden Beispiele sind \u003Cstrong>originäre Implementierungs-\u002FProjektnachweise\u003C\u002Fstrong>. Sie zeigen, wie ich in realer Projektarbeit Produktbedarf, Anforderungen, Architektur, Laufzeit, Modell\u002FAnbieter, Berechtigungen und Validierung getrennt habe. Sie sind keine Behauptungen, dass jede Organisation dieselbe Struktur verwenden muss, und sie implizieren keine Kundenakzeptanz oder Bereitstellung im Unternehmensmaßstab.","Implementierungsnachweise, keine universelle Regel","success",{"id":653,"data":654,"type":41},"h-senseflow",{"text":655,"level":240},"SenseFlow: Bedarf → Anforderungen → Architektur → Validierung",{"id":657,"data":658,"type":217},"p-senseflow-1",{"text":659},"Im SenseFlow-Projekt Source of Truth ist Technologie ausdrücklich der Product Vision untergeordnet. Die Entwicklungsstruktur bewegt sich von Problem und Produktvision über Benutzerbedürfnisse, Wert, Umfang, Epics, Stories und Abnahmekriterien hin zu Architektur, Implementierung, Validierung und Iteration.",{"id":661,"data":662,"type":217},"p-senseflow-2",{"text":663},"Anforderungen sind so gestaltet, dass sie vom Produktziel → Fähigkeit → Epic → User Story → Akzeptanzkriterien → Technische Aufgaben nachvollziehbar sind. Wo praktikabel, enthalten sie funktionale Anforderungen, NFRs, Abhängigkeiten, Risiken, Annahmen, Akzeptanzkriterien und Validierungsmethoden. Wesentliche Entscheidungen bewahren die Entscheidung, den Grund, Alternativen, Abwägungen, Status und Datum\u002FVersion.",{"id":665,"data":666,"type":217},"p-senseflow-3",{"text":667},"Das ist architektonische Arbeit, bevor ein bestimmtes KI-Framework oder Modell gewählt wird: Sie schützt die Verbindung zwischen Produktabsicht und technischen Entscheidungen und macht spätere Änderungen überprüfbar statt implizit.",{"id":669,"data":670,"type":41},"h-client",{"text":671,"level":240},"Aaasaasa AI Client: Konzepte trennen, bevor sie integriert werden",{"id":673,"data":674,"type":217},"p-client-1",{"text":675},"Aaasaasa AI Client bietet ein eher implementierungsnahes Beispiel. Sein AI Hub trennt bewusst \u003Cstrong>Agent\u002FClient\u003C\u002Fstrong>, \u003Cstrong>Anbieter\u003C\u002Fstrong>, \u003Cstrong>Modell\u003C\u002Fstrong>, \u003Cstrong>Verbindungs-\u002FLaufzeitort\u003C\u002Fstrong>, \u003Cstrong>Berechtigungen\u003C\u002Fstrong> und \u003Cstrong>Web-Client\u003C\u002Fstrong>. Eine lokale Laufzeit bedeutet nicht automatisch lokale Inferenz, und Berechtigungen werden als Laufzeit-\u002FTool-Richtlinie behandelt, nicht als Eigenschaft des Modells.",{"id":677,"data":678,"type":217},"p-client-2",{"text":679},"Die Desktop-Architektur definiert außerdem eine Vertrauensgrenze: Der Nuxt-Renderer ist im Verhältnis zum Electron-Main-Prozess nicht vertrauenswürdig. Ein schmaler Preload und validiertes IPC vermitteln den Zugriff auf KI-Dienste, Einstellungen, verschlüsselte Geheimnisse, Workspace-\u002FDatendienste und Laufzeiten. Cloud-Anmeldeinformationen verbleiben im privilegierten Main-Prozess; Renderer-Code erhält normalisierten Zustand statt roher Geheimnisse oder uneingeschränkten Betriebssystemzugriff.",{"id":681,"data":682,"type":217},"p-client-3",{"text":683},"Routing-Entscheidungen sind ebenfalls architektonisch. Die Implementierung fällt nicht stillschweigend von einer lokalen Route auf kostenpflichtige Cloud-Inferenz zurück; eine Cloud-Route erfordert ausdrückliche Bestätigung. Direct Chat hat standardmäßig keine Dateisystem- oder Shell-Tools, während die Agent-Ausführung ein ausgewähltes Workspace- und Berechtigungsprofil anwendet. Dies sind lösungsbezogene Entscheidungen über Vertrauen, Kosten, Ausführung und Benutzererwartung – keine Modellfunktionen.",{"id":685,"data":686,"type":41},"h-current-frameworks",{"text":687,"level":241},"Wie aktuelle Architektur-Frameworks diesen breiteren Umfang unterstützen",{"id":689,"data":690,"type":217},"p-frameworks-1",{"text":691},"ISO\u002FIEC\u002FIEEE 42010:2022 bietet eine allgemeine Disziplin für Architekturbeschreibungen über Software, Systeme und Unternehmen hinweg. Es ist bewusst breiter als KI und schreibt keine einzelne Architekturmethode oder Berufsbezeichnung vor. Das macht es hier als Abgrenzung nützlich: KI-Lösungsarchitektur ist immer noch Architektur, mit Stakeholder-Anliegen, mehreren Sichten und wesentlichen Beziehungen, die klar ausgedrückt werden müssen.",{"id":693,"data":694,"type":217},"p-frameworks-2",{"text":695},"NIST AI RMF 1.0 rahmt KI-Risikomanagement durch \u003Cstrong>Govern, Map, Measure und Manage\u003C\u002Fstrong> und betont, dass Risikomanagement über den gesamten Lebenszyklus des KI-Systems kontinuierlich sein sollte. Das Generative AI Profile (NIST AI 600-1) passt dieses Framework an GAI-Risiken und organisatorische Prioritäten an. Dies unterstreicht, dass Architektur nicht bei der funktionalen Modellleistung stehen bleiben kann.",{"id":697,"data":698,"type":217},"p-frameworks-3",{"text":699},"Die aktuelle Azure Well-Architected AI-Anleitung von Microsoft trennt Anwendungsdesign, Anwendungsplattform, Trainingsdaten, Grounding-Daten und Datenplattform-Anliegen und verbindet sie wiederholt mit Zuverlässigkeit, Sicherheit, operativer Exzellenz, Leistung und Kosten. Die Generative AI- und Agentic AI-Lenses von AWS behandeln Beobachtbarkeit, Sicherheit, Zuverlässigkeit, Modell-\u002FTool-Lebenszyklus, Kosten und menschliche Aufsicht ebenfalls als Architekturanliegen.",{"id":701,"data":702,"type":41},"h-misconceptions",{"text":703,"level":241},"Häufige Missverständnisse",{"id":705,"data":706,"type":290},"misconceptions-table",{"content":707,"stretched":42,"withHeadings":13},[708,711,714,717,720,723,726,729],[709,710],"Missverständnis","Korrektur",[712,713],"„Der Architekt wählt das LLM.“","Die Modellwahl ist eine Entscheidung innerhalb einer größeren Lösungsarchitektur.",[715,716],"„Prompt Engineering ist die Architektur.“","Prompts beeinflussen das Verhalten, aber sie definieren nicht Identität, Datenzugriff, Vertrauensgrenzen, Bereitstellung, Tool-Berechtigungen oder Betrieb.",[718,719],"„RAG löst Unternehmenswissen.“","Retrieval ist nur ein Subsystem; Autorisierung, Herkunft, Aktualität, Evidenz, Indexierung, Evaluierung und Quellen-Governance müssen noch entworfen werden.",[721,722],"„Lokale Laufzeit bedeutet private\u002Flokale KI.“","Laufzeit-, Inferenz-, Daten- und Control-Plane-Orte sind separate architektonische Eigenschaften.",[724,725],"„Wenn ein Anbieter Guardrails bietet, ist Sicherheit abgedeckt.“","Sicherheit umfasst Identität, Autorisierung, Geheimnisse, Datenflüsse, Tools, Protokollierung, Bereitstellung, menschliche Genehmigung und Anbietergrenzen.",[727,728],"„Der Architekt muss jede Komponente schreiben.“","Praktische Implementierung kann die architektonische Qualität verbessern, aber die Rolle ist durch integrierte Entscheidungsverantwortung definiert, nicht dadurch, jede Schicht selbst zu codieren.",[730,731],"„Ein Architekturdiagramm beweist Produktionsreife.“","Reife erfordert implementierte Kontrollen und Validierungsnachweise über Qualität, Sicherheit, Betrieb und geschäftliche Abnahme hinweg.",{"id":733,"data":734,"type":41},"h-failures",{"text":735,"level":241},"Fehlermodi, die ein AI Solution Architect verhindern sollte",{"id":737,"data":738,"type":290},"failures-table",{"content":739,"stretched":42,"withHeadings":13},[740,744,748,752,756,760,764,768,772],[741,742,743],"Fehlermodus","Warum es passiert","Architektonische Korrektur",[745,746,747],"Modell-zuerst-Design","Eine vielversprechende Modell-Demo wird zum Systembauplan","Mit Ergebnis, Einschränkungen und Validierung beginnen; das Modell innerhalb dieses Rahmens auswählen",[749,750,751],"Prototyp-Berechtigungen in Produktion","Gemeinsame Anmeldeinformationen und breiter Zugriff überleben den PoC","Identitätsweitergabe, geringste Rechte, Tool-Geltungsbereiche und Genehmigungsgrenzen früh definieren",[753,754,755],"Retrieval ohne Autorisierung","Suchqualität wird vor Datenzugriffsregeln entworfen","Benutzer-\u002FMandantenkontext in Retrieval übernehmen und Autorisierung an Datenzugriffsgrenzen durchsetzen",[757,758,759],"Stillschweigende Anbieter-\u002FLaufzeitannahmen","„Lokal“, „Cloud“ und „Offline“ werden unpräzise verwendet","Laufzeit-, Inferenz-, Daten- und Control-Plane-Ort separat dokumentieren",[761,762,763],"Kein Fehlervertrag","Der Happy Path wird entworfen, aber Ablehnungs-\u002FFallback-\u002FFehlerverhalten nicht","Verhalten bei leerem Retrieval, nicht verfügbarem Modell, Tool-Fehler und Richtlinienverweigerung spezifizieren",[765,766,767],"Evaluierung nach der Implementierung","Qualität wird kurz vor dem Start manuell beurteilt","Messbare Abnahmekriterien und repräsentative Evaluierungssets definieren, bevor die Architektur eingefroren wird",[769,770,771],"Nicht nachvollziehbare Änderung","Modelle, Prompts, Retrieval oder Berechtigungen ändern sich ohne Architekturhistorie","Kritische Konfiguration versionieren und wesentliche Entscheidungen\u002FValidierungsnachweise aufzeichnen",[773,774,775],"Betrieb nur als Infrastruktur behandelt","KI-Verhalten ist nach der Bereitstellung nicht beobachtbar","Traces, Qualitätsmetriken, Sicherheitsereignisse, Kostentelemetrie und Rollback zusammen entwerfen",{"id":777,"data":778,"type":41},"h-decision-framework",{"text":779,"level":241},"Eine praktische Entscheidungssequenz",{"id":781,"data":782,"type":338},"decision-flow",{"steps":783,"title":808,"orientation":337},[784,787,790,793,796,799,802,805],{"label":785,"description":786},"Ergebnis","Das Benutzer-\u002FGeschäftsergebnis und explizite Nicht-Ziele definieren.",{"label":788,"description":789},"Evidenz und Einschränkungen","Autoritative Daten, Richtlinien, NFRs, Risiken und Abnahmebedingungen identifizieren.",{"label":791,"description":792},"Systemgrenze","Benutzer, Identitäten, Anwendungen, Daten, Modelle\u002FAnbieter, Tools und externe Systeme abbilden.",{"label":794,"description":795},"Architekturoptionen","Muster für Retrieval, Modellzugriff, Orchestrierung, Bereitstellung, Berechtigungen, Evaluierung und Beobachtbarkeit vergleichen.",{"label":797,"description":798},"Abwägungsentscheidungen","Wesentliche Optionen auswählen und Begründung, Alternativen und Konsequenzen bewahren.",{"label":800,"description":801},"Implementierungsverträge","Entscheidungen in APIs, Schemas, Berechtigungsregeln, Bereitstellungsdefinitionen und Engineering-Aufgaben umsetzen.",{"label":803,"description":804},"Validierung","Das implementierte System gegen die ursprünglichen funktionalen und nicht-funktionalen Anforderungen testen.",{"label":806,"description":807},"Operatives Feedback","Produktionsnachweise, Vorfälle, Qualitätsmetriken und Kosten-\u002FSicherheitssignale nutzen, um kontrollierte Änderungen auszulösen.","Entscheidungssequenz für KI-Lösungsarchitektur",{"id":810,"data":811,"type":41},"h-edge",{"text":812,"level":241},"Randfälle und Grenzen der Rolle",{"id":814,"data":815,"type":217},"p-edge-1",{"text":816},"Einige KI-Produkte werden von Modelltraining, wissenschaftlicher Experimentierung oder spezialisierter Hardware dominiert. In diesen Fällen können Modell-\u002FData-Science- und ML-Systemarchitektur viel tiefer gehen als die hier gezeigte lösungsbezogene Karte. Der AI Solution Architect benötigt weiterhin Integrations- und Betriebsgrenzen, aber die Trainingsplattform selbst kann von einer spezialisierten Architektur verantwortet werden.",{"id":818,"data":819,"type":217},"p-edge-2",{"text":820},"Am anderen Extrem rechtfertigt eine einfache SaaS-Integration möglicherweise keinen dedizierten Architekten. Ein Senior Engineer oder technischer Produktverantwortlicher kann dieselbe Architekturverantwortung tragen. Der nützliche Test ist nicht der Titel, sondern ob bedeutende schichtübergreifende Entscheidungen bewusst getroffen und validiert werden.",{"id":822,"data":823,"type":217},"p-edge-3",{"text":824},"Regulierte, souveräne, air-gapped, sicherheitskritische, hochautonome oder mandantenfähige Systeme verschieben ebenfalls den Schwerpunkt. Identität, Isolation, Datenresidenz, Assurance, Update-Mechanismen, menschliche Aufsicht und Auditierbarkeit können die Modellqualität in der Architektur dominieren.",{"id":826,"data":827,"type":41},"h-change-answer",{"text":828,"level":241},"Was würde diese Antwort ändern?",{"id":830,"data":831,"type":217},"p-change-1",{"text":832},"Die genaue Verantwortungsgrenze ändert sich, wenn die Architektur von einer Anwendung zu einer wiederverwendbaren Plattform oder zu einer unternehmensweiten Zielarchitektur übergeht. Deshalb verdienen \u003Cstrong>AI Platform Architect\u003C\u002Fstrong> und \u003Cstrong>Enterprise AI Architecture\u003C\u002Fstrong> eine separate kanonische Behandlung, anstatt in diese Rolle integriert zu werden.",{"id":834,"data":835,"type":217},"p-change-2",{"text":836},"Technologieänderungen sind ebenfalls wichtig. Neue Modellfähigkeiten, Protokolle, lokale Runtimes und Managed Services können einige Implementierungsarbeiten eliminieren, während sie neue Vertrauens- oder Betriebsgrenzen schaffen. Die stabile Verantwortung besteht darin, diese Änderungen als Systemänderungen zu verstehen – nicht ein neues Framework als Ersatz für Architektur zu behandeln.",{"id":838,"data":839,"type":41},"h-checklist",{"text":840,"level":241},"Checkliste für AI Solution Architects",{"id":842,"data":843,"type":290},"checklist-table",{"content":844,"stretched":42,"withHeadings":13},[845,848,850,853,855,858,861,864,867,870,873,876,878],[846,847],"Prüfung","Frage",[785,849],"Sind das Nutzer-\u002FGeschäftsergebnis und die Nicht-Ziel-Grenze explizit?",[851,852],"Anforderungen","Sind funktionale Anforderungen, NFRs, Einschränkungen und Akzeptanzkriterien nachverfolgbar?",[267,854],"Sind autoritative Quellen, Provenienz, Aktualität, Aufbewahrung und Zugriffsregeln definiert?",[856,857],"Retrieval\u002FKontext","Reicht die Autorisierung bis zum Retrieval und zur Kontextkonstruktion?",[859,860],"Modell\u002FAnbieter","Ist die Modell-\u002FAnbieterauswahl an Fähigkeiten und Einschränkungen gebunden statt an Präferenzen?",[862,863],"Tools\u002FAgenten","Sind Aktionsgrenzen, Berechtigungen, Genehmigungen und Fehlerverhalten explizit?",[865,866],"Identität\u002FSicherheit","Sind menschliche\u002Fmaschinelle Identitäten, Geheimnisse und Vertrauensgrenzen definiert?",[868,869],"Runtime","Sind Runtime-, Inferenz-, Daten- und Control-Plane-Standorte unterschieden?",[871,872],"Evaluierung","Gibt es messbare Belege für Qualität, Sicherheit und Akzeptanz?",[874,875],"Observability","Können Produktionsverhalten, Fehler, Kosten und Sicherheitsereignisse untersucht werden?",[285,877],"Sind bedeutende Architekturentscheidungen und Ersetzungen nachverfolgbar?",[279,879],"Ist die Verantwortung für Deployment, Rollback, Vorfälle und Lebenszyklus klar?",{"id":881,"data":882,"type":41},"h-conclusion",{"text":883,"level":241},"Fazit",{"id":885,"data":886,"type":217},"p-conclusion-1",{"text":887},"Ein AI Solution Architect ist die Person oder Architekturfunktion, die eine AI-Chance in ein kohärentes technisches System verwandelt. Die Schlüsselkompetenz ist nicht, die meisten Modellnamen zu kennen; es geht darum, Produktbedarf, Anforderungen, Daten, Anwendungsarchitektur, AI-Fähigkeiten, Sicherheit, Runtime, Bereitstellung und Validierung zu verbinden, ohne die Grenzen zwischen ihnen zu verlieren.",{"id":889,"data":890,"type":217},"p-conclusion-2",{"text":891},"Eine starke AI-Lösungsarchitektur lässt sich daher wie folgt zusammenfassen: \u003Cstrong>Ziel definieren → Anforderungen und Einschränkungen festlegen → Systemgrenzen entwerfen → bedeutende Trade-offs explizit machen → durch klare Verträge implementieren → gegen Belege validieren → bewusst betreiben und weiterentwickeln.\u003C\u002Fstrong> Das Modell ist wichtig. Die Lösung ist das Produkt.",{"id":893,"data":894,"type":893},"faq",{"items":895,"title":928},[896,900,904,908,912,916,920,924],{"id":897,"answer":898,"question":899},"faq1","Ein AI Solution Architect übersetzt einen Geschäfts- oder Produktbedarf in die Architektur einer konkreten AI-fähigen Lösung und definiert, wie Anwendungslogik, Daten\u002FRetrieval, Modelle, Tools, Identität, Sicherheit, Runtime, Evaluierung und Betrieb zusammenwirken.","Was ist ein AI Solution Architect?",{"id":901,"answer":902,"question":903},"faq2","Nein. Die Rollen können sich überschneiden, besonders in kleinen Teams, aber ein AI Engineer ist primär eine Implementierungsrolle, während der Solution Architect schichtübergreifende Architekturentscheidungen und Trade-offs für die gesamte Workload besitzt oder koordiniert.","Ist ein AI Solution Architect dasselbe wie ein AI Engineer?",{"id":905,"answer":906,"question":907},"faq3","Nicht per Definition, aber praktische Implementierungskenntnisse sind sehr wertvoll, weil AI-Architektur APIs, Daten, Retrieval, Sicherheit, Runtimes und Betriebsverhalten überschreitet. Die Rolle ist durch Architekturverantwortung definiert, nicht dadurch, jede Komponente selbst zu schreiben.","Muss ein AI Solution Architect programmieren können?",{"id":909,"answer":910,"question":911},"faq4","Nein. Die Modellauswahl ist eine Entscheidung. Produktionsarchitektur benötigt auch Daten- und Retrieval-Grenzen, Berechtigungen, Tools, Anbieter-\u002FRuntime-Entscheidungen, Observability, Evaluierung, Zuverlässigkeit, Kosten und Lebenszyklus-Design.","Ist die Auswahl eines LLM die Hauptaufgabe?",{"id":913,"answer":914,"question":915},"faq5","Ein AI Solution Architect konzentriert sich auf eine konkrete Lösung oder Workload. Ein AI Platform Architect konzentriert sich auf wiederverwendbare AI-Fähigkeiten und Guardrails, die mehrere Lösungen unterstützen.","Was ist der Unterschied zwischen einem AI Solution Architect und einem AI Platform Architect?",{"id":917,"answer":918,"question":919},"faq6","Der Solution Architect arbeitet im Anwendungs-\u002FWorkload-Umfang. Enterprise AI Architecture arbeitet über das organisatorische Portfolio, die Zielarchitektur, Governance, gemeinsame Fähigkeiten, Integrationsprinzipien und strategische Einschränkungen.","Was ist der Unterschied zwischen einem AI Solution Architect und einem Enterprise AI Architect?",{"id":921,"answer":922,"question":923},"faq7","Sie sind Architekturmuster oder Subsysteme innerhalb einer Lösung, wenn die Anforderungen sie rechtfertigen. RAG adressiert retrieval-gestützten Kontext; Agenten fügen Planung\u002FTool-Ausführung hinzu und damit zusätzliche Identitäts-, Berechtigungs-, Orchestrierungs- und Betriebsbelange.","Wo passen RAG und Agenten hinein?",{"id":925,"answer":926,"question":927},"faq8","Implementierung plus Validierungsbelege: Funktionstests, Evaluierungsergebnisse, Sicherheits-\u002FAutorisierungstests, Leistungs- und Zuverlässigkeitsmessungen, Observability, Betriebsproben und Abnahme gegen die ursprünglichen Anforderungen.","Was beweist, dass die Architektur funktioniert?","AI Solution Architect — FAQ",{"id":930,"data":931,"type":930},"glossary",{"title":932,"entries":933},"Kernbegriffe",[934,937,940,944,948,951,954,957],{"term":596,"anchor":935,"definition":936},"ai-solution-architect","Architekturverantwortung für eine konkrete AI-fähige Lösung oder Workload, die Produktanforderungen mit Anwendungs-, Daten-, Modell-, Tool-, Sicherheits-, Runtime- und Betriebsdesign integriert.",{"term":791,"anchor":938,"definition":939},"system-boundary","Die explizite Trennung zwischen dem, was zur Lösung gehört, und den Nutzern, Systemen, Anbietern, Datenquellen und Umgebungen, mit denen sie interagiert.",{"term":941,"anchor":942,"definition":943},"Vertrauensgrenze","trust-boundary","Ein Punkt, an dem Daten, Identitäten oder Steuerung zwischen Komponenten mit unterschiedlichen Vertrauensannahmen wechseln und daher explizite Sicherheitskontrollen erfordern.",{"term":945,"anchor":946,"definition":947},"Grounding","grounding","Die Versorgung eines AI-Modells mit relevanten externen Informationen oder Belegen, damit seine Antwort auf Quellen jenseits der Modellparameter basieren kann.",{"term":563,"anchor":949,"definition":950},"provider-abstraction","Eine Anwendungsgrenze, die Teile der Lösung von einer Modell-\u002FAnbieterschnittstelle entkoppelt. Nützlich, wenn durch Routing-, Portabilitäts- oder Richtlinienanforderungen gerechtfertigt, aber nicht frei von Trade-offs.",{"term":871,"anchor":952,"definition":953},"evaluation","Strukturierte Messung des Verhaltens einer AI-Workload gegen definierte Akzeptanzkriterien, einschließlich Aufgabenqualität und relevanter Sicherheits-, Leistungs- und Betriebseigenschaften.",{"term":602,"anchor":955,"definition":956},"ai-platform-architect","Architekturrolle, die sich auf wiederverwendbare AI-Plattformfähigkeiten konzentriert, die von mehreren Lösungen genutzt werden, statt auf die Architektur einer Workload.",{"term":958,"anchor":959,"definition":960},"Enterprise AI Architecture","enterprise-ai-architecture","Architektur auf Organisationsebene, die AI-Fähigkeiten, Plattformen, Governance, Integration und strategische Einschränkungen über ein Portfolio hinweg koordiniert.",{"id":962,"data":963,"type":41},"h-related",{"text":964,"level":241},"Verwandtes kanonisches Wissen",{"id":966,"data":967,"type":217},"p-related-1",{"text":968},"Dieser Artikel gehört zum Cluster AI Architecture Foundations. Seine direkten Grundlagen sind \u003Cstrong>Generative AI Explained: Models, Retrieval, Tools and Applications Are Not the Same Thing\u003C\u002Fstrong> und \u003Cstrong>ADR vs NFR: Architecture Decisions and System Quality Are Not the Same Thing\u003C\u002Fstrong>. Benachbarte kanonische Knoten umfassen \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> und \u003Cstrong>AI Governance\u003C\u002Fstrong>. URLs werden bewusst nicht erfunden, wo diese Knoten noch nicht veröffentlicht sind.",{"id":970,"data":971,"type":978},"related-rag",{"link":972,"meta":973},"https:\u002F\u002Fstajic.de\u002Fde\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works",{"image":974,"title":976,"description":977},{"url":975},"","What Is RAG? The Simplest Explanation of How It Works","Bestehende kanonische Erklärung von stajic.de zu retrieval-augmented generation, nützlich für den Retrieval-\u002FGrounding-Teil der AI-Lösungsarchitektur.","linkTool",{"id":980,"data":981,"type":41},"h-sources",{"text":982,"level":241},"Primärquellen und aktuelle Architekturanleitung",{"id":984,"data":985,"type":217},"p-sources-note",{"text":986},"Die folgenden externen Quellen stützen die allgemeinen Architekturbehauptungen; die Abschnitte zu SenseFlow und Aaasaasa AI Client sind ausdrücklich originäre Projekt-\u002FImplementierungsbelege. Referenzen zum aktuellen Stand wurden am 8. Oktober 2026 geprüft. NIST weist darauf hin, dass AI RMF 1.0 überarbeitet wird, sodass versionssensitive Governance-Referenzen bei Veröffentlichung eines Nachfolgers erneut geprüft werden sollten.",{"id":988,"data":989,"type":978},"src-iso-42010",{"link":990,"meta":991},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html",{"image":992,"title":993,"description":994},{"url":975},"ISO\u002FIEC\u002FIEEE 42010:2022 — Architecture Description","Aktueller internationaler Standard für die Struktur und Ausdrucksweise von Architekturbeschreibungen. Er unterscheidet Architektur von ihrer Beschreibung und schreibt keine einzelne Architekturmethode, kein Werkzeug und kein Aufzeichnungsformat vor.",{"id":996,"data":997,"type":978},"src-nist-rmf",{"link":998,"meta":999},"https:\u002F\u002Fwww.nist.gov\u002Fitl\u002Fai-risk-management-framework",{"image":1000,"title":1001,"description":1002},{"url":975},"NIST AI Risk Management Framework","NISTs AI RMF-Ressourcenseite. Stand Oktober 2026 wird dort angegeben, dass AI RMF 1.0 überarbeitet wird, und es werden das Generative AI Profile und verwandte Ressourcen verlinkt.",{"id":1004,"data":1005,"type":978},"src-nist-core",{"link":1006,"meta":1007},"https:\u002F\u002Fairc.nist.gov\u002Fairmf-resources\u002Fairmf\u002F5-sec-core\u002F",{"image":1008,"title":1009,"description":1010},{"url":975},"NIST AI RMF Core — Govern, Map, Measure, Manage","Offizielle NIST AIRC-Präsentation des AI RMF 1.0 Core, einschließlich der vier Funktionen und der lebenszyklusorientierten Risikomanagement-Rahmung.",{"id":1012,"data":1013,"type":978},"src-nist-gai",{"link":1014,"meta":1015},"https:\u002F\u002Fwww.nist.gov\u002Fpublications\u002Fartificial-intelligence-risk-management-framework-generative-artificial-intelligence",{"image":1016,"title":1017,"description":1018},{"url":975},"NIST AI 600-1 — Generative AI Profile","Sektorübergreifendes Generative-AI-Profil für AI RMF 1.0, veröffentlicht am 26. Juli 2024 und 2026 von NIST aktualisiert.",{"id":1020,"data":1021,"type":978},"src-ms-start",{"link":1022,"meta":1023},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fget-started",{"image":1024,"title":1025,"description":1026},{"url":975},"Microsoft Azure Well-Architected — AI Workloads","Aktuelle Architekturleitlinien auf Workload-Ebene, die KI-Anwendungsdesign, Anwendungsplattform, Trainingsdaten, Grounding-Daten, Datenplattform und Produktionsreife abdecken.",{"id":1028,"data":1029,"type":978},"src-ms-app",{"link":1030,"meta":1031},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fapplication-design",{"image":1032,"title":1033,"description":1034},{"url":975},"Microsoft — Application Design for AI Workloads","Leitlinien zu Modell-\u002FTool-Abstraktion, Datenzugriffsgrenzen, Identitätsweitergabe, Autorisierung und Trennung von Client-, Intelligenz-, Wissens- und Tool-Schichten.",{"id":1036,"data":1037,"type":978},"src-ms-security",{"link":1038,"meta":1039},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fdesign-principles",{"image":1040,"title":1041,"description":1042},{"url":975},"Microsoft — Design Principles for AI Workloads","Aktuelle Designprinzipien für KI-Workloads in den Bereichen Zuverlässigkeit, Sicherheit, Kosten, operative Exzellenz und Leistung, einschließlich Identitäts- und Datenschutzverantwortlichkeiten.",{"id":1044,"data":1045,"type":978},"src-ms-ops",{"link":1046,"meta":1047},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fwell-architected\u002Fai\u002Fmlops-genaiops",{"image":1048,"title":1049,"description":1050},{"url":975},"Microsoft — MLOps and GenAIOps for AI Workloads","Leitlinien zum Produktionslebenszyklus, die Monitoring, Qualitätsgates, Modell-\u002FPrompt-Verhalten, Sicherheit und operative Messung abdecken.",{"id":1052,"data":1053,"type":978},"src-aws-genai",{"link":1054,"meta":1055},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fgenerative-ai-lens\u002F",{"image":1056,"title":1057,"description":1058},{"url":975},"AWS Well-Architected Generative AI Lens","AWS-Architekturleitlinien für generative KI-Workloads in den Bereichen operative Exzellenz, Sicherheit, Zuverlässigkeit, Leistungseffizienz, Kostenoptimierung und Nachhaltigkeit.",{"id":1060,"data":1061,"type":978},"src-aws-agentic",{"link":1062,"meta":1063},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwellarchitected\u002Flatest\u002Fagentic-ai-lens\u002F",{"image":1064,"title":1065,"description":1066},{"url":975},"AWS Well-Architected Agentic AI Lens","2026 veröffentlicht, behandelt agentische architekturspezifische Belange einschließlich Identitäten, Tools, Orchestrierung, menschliche Aufsicht, Zuverlässigkeit, Tracing und Kosten von Reasoning-Schleifen.","2.31","Ein KI-Lösungsarchitekt verwandelt Geschäftsanforderungen in ein produktionsreifes KI-System über Daten, Modelle, Tools, Sicherheit, Laufzeit, Evaluierung und Betrieb hinweg.","\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":1076,"de":1077,"sr":1078,"es":1079,"fr":1080,"it":1081,"ru":1082,"zh":1083},"\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",[1085,1089,1093,1097],{"id":1086,"name":1087,"slug":1088},57,"Daten-Grenzen","data-boundaries",{"id":1090,"name":1091,"slug":1092},84,"Policy & Datengrenzen","policy-and-data",{"id":1094,"name":1095,"slug":1096},80,"Zugriff & Identität","access-and-identity",{"id":1098,"name":1099,"slug":1100},54,"Bedrohungsmodell","threat-model",{"id":1102,"login":1103,"email":1104,"displayName":1105},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[1107,1459],{"lang":7,"title":207,"content":209,"contentJson":1108,"excerpt":1068},{"time":211,"blocks":1109,"version":1067},[1110,1112,1114,1116,1118,1120,1122,1124,1126,1142,1144,1146,1148,1158,1160,1162,1164,1166,1168,1182,1184,1186,1188,1190,1192,1194,1196,1198,1200,1202,1204,1206,1208,1210,1212,1214,1216,1218,1220,1222,1224,1226,1228,1240,1242,1244,1255,1257,1259,1277,1279,1281,1283,1285,1287,1289,1291,1293,1295,1297,1299,1301,1303,1305,1307,1309,1320,1322,1334,1336,1347,1349,1351,1353,1355,1357,1359,1361,1363,1379,1381,1383,1385,1396,1407,1409,1411,1415,1417,1419,1423,1427,1431,1435,1439,1443,1447,1451,1455],{"id":214,"data":1111,"type":217},{"text":216},{"id":219,"data":1113,"type":224},{"body":221,"title":222,"variant":223},{"id":226,"data":1115,"type":224},{"body":228,"title":229,"variant":230},{"id":232,"data":1117,"type":224},{"body":234,"title":235,"variant":230},{"id":237,"data":1119,"type":242},{"title":239,"maxLevel":240,"minLevel":241},{"id":244,"data":1121,"type":41},{"text":246,"level":241},{"id":248,"data":1123,"type":217},{"text":250},{"id":252,"data":1125,"type":217},{"text":254},{"id":256,"data":1127,"type":298},{"rows":1128,"title":289,"layout":290,"columns":1139},[1129,1131,1133,1135,1137],{"id":260,"label":261,"values":1130},{"model":263,"solution":264},{"id":266,"label":267,"values":1132},{"model":269,"solution":270},{"id":272,"label":273,"values":1134},{"model":275,"solution":276},{"id":278,"label":279,"values":1136},{"model":281,"solution":282},{"id":284,"label":285,"values":1138},{"model":287,"solution":288},[1140,1141],{"id":293,"label":294},{"id":296,"label":297},{"id":300,"data":1143,"type":41},{"text":302,"level":241},{"id":304,"data":1145,"type":217},{"text":306},{"id":308,"data":1147,"type":217},{"text":310},{"id":312,"data":1149,"type":338},{"steps":1150,"title":336,"orientation":337},[1151,1152,1153,1154,1155,1156,1157],{"label":316,"description":317},{"label":319,"description":320},{"label":322,"description":323},{"label":325,"description":326},{"label":328,"description":329},{"label":331,"description":332},{"label":334,"description":335},{"id":340,"data":1159,"type":41},{"text":342,"level":241},{"id":344,"data":1161,"type":217},{"text":346},{"id":348,"data":1163,"type":217},{"text":350},{"id":352,"data":1165,"type":41},{"text":354,"level":241},{"id":356,"data":1167,"type":217},{"text":358},{"id":360,"data":1169,"type":290},{"content":1170,"stretched":42,"withHeadings":13},[1171,1172,1173,1174,1175,1176,1177,1178,1179,1180,1181],[364,365,366],[368,369,370],[372,373,374],[376,377,378],[380,381,382],[384,385,386],[388,389,390],[392,393,394],[396,397,398],[400,401,402],[404,405,406],{"id":408,"data":1183,"type":41},{"text":410,"level":240},{"id":412,"data":1185,"type":217},{"text":414},{"id":416,"data":1187,"type":217},{"text":418},{"id":420,"data":1189,"type":41},{"text":422,"level":240},{"id":424,"data":1191,"type":217},{"text":426},{"id":428,"data":1193,"type":217},{"text":430},{"id":432,"data":1195,"type":41},{"text":434,"level":240},{"id":436,"data":1197,"type":217},{"text":438},{"id":440,"data":1199,"type":217},{"text":442},{"id":444,"data":1201,"type":41},{"text":446,"level":240},{"id":448,"data":1203,"type":217},{"text":450},{"id":452,"data":1205,"type":217},{"text":454},{"id":456,"data":1207,"type":41},{"text":458,"level":240},{"id":460,"data":1209,"type":217},{"text":462},{"id":464,"data":1211,"type":217},{"text":466},{"id":468,"data":1213,"type":41},{"text":470,"level":240},{"id":472,"data":1215,"type":217},{"text":474},{"id":476,"data":1217,"type":217},{"text":478},{"id":480,"data":1219,"type":41},{"text":482,"level":240},{"id":484,"data":1221,"type":217},{"text":486},{"id":488,"data":1223,"type":217},{"text":490},{"id":492,"data":1225,"type":41},{"text":494,"level":241},{"id":496,"data":1227,"type":217},{"text":498},{"id":500,"data":1229,"type":290},{"content":1230,"stretched":42,"withHeadings":13},[1231,1232,1233,1234,1235,1236,1237,1238,1239],[504,505],[507,508],[510,511],[513,514],[516,517],[519,520],[522,523],[525,526],[528,529],{"id":531,"data":1241,"type":41},{"text":533,"level":241},{"id":535,"data":1243,"type":217},{"text":537},{"id":539,"data":1245,"type":290},{"content":1246,"stretched":42,"withHeadings":13},[1247,1248,1249,1250,1251,1252,1253,1254],[543,544,545,546],[548,549,550,551],[553,554,555,556],[558,559,560,561],[563,564,565,566],[568,569,570,571],[573,574,575,576],[578,579,580,581],{"id":583,"data":1256,"type":41},{"text":585,"level":241},{"id":587,"data":1258,"type":217},{"text":589},{"id":591,"data":1260,"type":298},{"rows":1261,"title":630,"layout":290,"columns":1274},[1262,1264,1266,1268,1270,1272],{"id":595,"label":596,"values":1263},{"role":598,"focus":599},{"id":601,"label":602,"values":1265},{"role":604,"focus":605},{"id":607,"label":608,"values":1267},{"role":610,"focus":611},{"id":613,"label":614,"values":1269},{"role":616,"focus":617},{"id":619,"label":620,"values":1271},{"role":622,"focus":623},{"id":625,"label":626,"values":1273},{"role":628,"focus":629},[1275,1276],{"id":633,"label":634},{"id":636,"label":637},{"id":639,"data":1278,"type":217},{"text":641},{"id":643,"data":1280,"type":41},{"text":645,"level":241},{"id":647,"data":1282,"type":224},{"body":649,"title":650,"variant":651},{"id":653,"data":1284,"type":41},{"text":655,"level":240},{"id":657,"data":1286,"type":217},{"text":659},{"id":661,"data":1288,"type":217},{"text":663},{"id":665,"data":1290,"type":217},{"text":667},{"id":669,"data":1292,"type":41},{"text":671,"level":240},{"id":673,"data":1294,"type":217},{"text":675},{"id":677,"data":1296,"type":217},{"text":679},{"id":681,"data":1298,"type":217},{"text":683},{"id":685,"data":1300,"type":41},{"text":687,"level":241},{"id":689,"data":1302,"type":217},{"text":691},{"id":693,"data":1304,"type":217},{"text":695},{"id":697,"data":1306,"type":217},{"text":699},{"id":701,"data":1308,"type":41},{"text":703,"level":241},{"id":705,"data":1310,"type":290},{"content":1311,"stretched":42,"withHeadings":13},[1312,1313,1314,1315,1316,1317,1318,1319],[709,710],[712,713],[715,716],[718,719],[721,722],[724,725],[727,728],[730,731],{"id":733,"data":1321,"type":41},{"text":735,"level":241},{"id":737,"data":1323,"type":290},{"content":1324,"stretched":42,"withHeadings":13},[1325,1326,1327,1328,1329,1330,1331,1332,1333],[741,742,743],[745,746,747],[749,750,751],[753,754,755],[757,758,759],[761,762,763],[765,766,767],[769,770,771],[773,774,775],{"id":777,"data":1335,"type":41},{"text":779,"level":241},{"id":781,"data":1337,"type":338},{"steps":1338,"title":808,"orientation":337},[1339,1340,1341,1342,1343,1344,1345,1346],{"label":785,"description":786},{"label":788,"description":789},{"label":791,"description":792},{"label":794,"description":795},{"label":797,"description":798},{"label":800,"description":801},{"label":803,"description":804},{"label":806,"description":807},{"id":810,"data":1348,"type":41},{"text":812,"level":241},{"id":814,"data":1350,"type":217},{"text":816},{"id":818,"data":1352,"type":217},{"text":820},{"id":822,"data":1354,"type":217},{"text":824},{"id":826,"data":1356,"type":41},{"text":828,"level":241},{"id":830,"data":1358,"type":217},{"text":832},{"id":834,"data":1360,"type":217},{"text":836},{"id":838,"data":1362,"type":41},{"text":840,"level":241},{"id":842,"data":1364,"type":290},{"content":1365,"stretched":42,"withHeadings":13},[1366,1367,1368,1369,1370,1371,1372,1373,1374,1375,1376,1377,1378],[846,847],[785,849],[851,852],[267,854],[856,857],[859,860],[862,863],[865,866],[868,869],[871,872],[874,875],[285,877],[279,879],{"id":881,"data":1380,"type":41},{"text":883,"level":241},{"id":885,"data":1382,"type":217},{"text":887},{"id":889,"data":1384,"type":217},{"text":891},{"id":893,"data":1386,"type":893},{"items":1387,"title":928},[1388,1389,1390,1391,1392,1393,1394,1395],{"id":897,"answer":898,"question":899},{"id":901,"answer":902,"question":903},{"id":905,"answer":906,"question":907},{"id":909,"answer":910,"question":911},{"id":913,"answer":914,"question":915},{"id":917,"answer":918,"question":919},{"id":921,"answer":922,"question":923},{"id":925,"answer":926,"question":927},{"id":930,"data":1397,"type":930},{"title":932,"entries":1398},[1399,1400,1401,1402,1403,1404,1405,1406],{"term":596,"anchor":935,"definition":936},{"term":791,"anchor":938,"definition":939},{"term":941,"anchor":942,"definition":943},{"term":945,"anchor":946,"definition":947},{"term":563,"anchor":949,"definition":950},{"term":871,"anchor":952,"definition":953},{"term":602,"anchor":955,"definition":956},{"term":958,"anchor":959,"definition":960},{"id":962,"data":1408,"type":41},{"text":964,"level":241},{"id":966,"data":1410,"type":217},{"text":968},{"id":970,"data":1412,"type":978},{"link":972,"meta":1413},{"image":1414,"title":976,"description":977},{"url":975},{"id":980,"data":1416,"type":41},{"text":982,"level":241},{"id":984,"data":1418,"type":217},{"text":986},{"id":988,"data":1420,"type":978},{"link":990,"meta":1421},{"image":1422,"title":993,"description":994},{"url":975},{"id":996,"data":1424,"type":978},{"link":998,"meta":1425},{"image":1426,"title":1001,"description":1002},{"url":975},{"id":1004,"data":1428,"type":978},{"link":1006,"meta":1429},{"image":1430,"title":1009,"description":1010},{"url":975},{"id":1012,"data":1432,"type":978},{"link":1014,"meta":1433},{"image":1434,"title":1017,"description":1018},{"url":975},{"id":1020,"data":1436,"type":978},{"link":1022,"meta":1437},{"image":1438,"title":1025,"description":1026},{"url":975},{"id":1028,"data":1440,"type":978},{"link":1030,"meta":1441},{"image":1442,"title":1033,"description":1034},{"url":975},{"id":1036,"data":1444,"type":978},{"link":1038,"meta":1445},{"image":1446,"title":1041,"description":1042},{"url":975},{"id":1044,"data":1448,"type":978},{"link":1046,"meta":1449},{"image":1450,"title":1049,"description":1050},{"url":975},{"id":1052,"data":1452,"type":978},{"link":1054,"meta":1453},{"image":1454,"title":1057,"description":1058},{"url":975},{"id":1060,"data":1456,"type":978},{"link":1062,"meta":1457},{"image":1458,"title":1065,"description":1066},{"url":975},{"lang":1460,"title":1461,"content":1462,"contentJson":1463,"excerpt":2122},"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":1464,"blocks":1465,"version":2121},1791476244367,[1466,1469,1473,1477,1481,1484,1487,1490,1493,1517,1520,1523,1526,1551,1554,1557,1560,1563,1566,1613,1616,1619,1622,1625,1628,1631,1634,1637,1640,1643,1646,1649,1652,1655,1658,1661,1664,1667,1670,1673,1676,1679,1682,1711,1714,1717,1760,1763,1766,1787,1790,1793,1797,1800,1803,1806,1809,1812,1815,1818,1821,1824,1827,1830,1833,1836,1863,1866,1905,1908,1936,1939,1942,1945,1948,1951,1954,1957,1960,1996,1999,2002,2005,2032,2053,2056,2059,2065,2068,2071,2076,2081,2086,2091,2096,2101,2106,2111,2116],{"id":214,"data":1467,"type":217},{"text":1468},"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":219,"data":1470,"type":224},{"body":1471,"title":1472,"variant":223},"\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":226,"data":1474,"type":224},{"body":1475,"title":1476,"variant":230},"\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":232,"data":1478,"type":224},{"body":1479,"title":1480,"variant":230},"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":237,"data":1482,"type":242},{"title":1483,"maxLevel":240,"minLevel":241},"Contents",{"id":244,"data":1485,"type":41},{"text":1486,"level":241},"What does an AI Solution Architect actually architect?",{"id":248,"data":1488,"type":217},{"text":1489},"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":252,"data":1491,"type":217},{"text":1492},"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":256,"data":1494,"type":298},{"rows":1495,"title":1511,"layout":290,"columns":1512},[1496,1499,1502,1505,1508],{"id":260,"label":1497,"values":1498},"Capability",{"model":263,"solution":264},{"id":266,"label":1500,"values":1501},"Data",{"model":269,"solution":270},{"id":272,"label":1503,"values":1504},"Security",{"model":275,"solution":276},{"id":278,"label":1506,"values":1507},"Operations",{"model":281,"solution":282},{"id":284,"label":1509,"values":1510},"Change",{"model":287,"solution":288},"The solution is wider than the model",[1513,1515],{"id":293,"label":1514},"Model-centric question",{"id":296,"label":1516},"Solution-architecture question",{"id":300,"data":1518,"type":41},{"text":1519,"level":241},"The simplest example",{"id":304,"data":1521,"type":217},{"text":1522},"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":308,"data":1524,"type":217},{"text":1525},"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":312,"data":1527,"type":338},{"steps":1528,"title":1550,"orientation":337},[1529,1532,1535,1538,1541,1544,1547],{"label":1530,"description":1531},"1. Define the outcome","Clarify the user, business value, task boundary and what a successful answer or action means.",{"label":1533,"description":1534},"2. Capture requirements","Make functional requirements, NFRs, constraints, data rules, risk tolerance and acceptance criteria explicit.",{"label":1536,"description":1537},"3. Establish boundaries","Identify users, identities, applications, authoritative data, model\u002Fprovider dependencies, tools, external systems and trust zones.",{"label":1539,"description":1540},"4. Design the architecture","Choose data\u002Fretrieval, model, orchestration, tool, permission, runtime, deployment, fallback and observability patterns.",{"label":1542,"description":1543},"5. Record significant decisions","Preserve architectural choices, alternatives, trade-offs and consequences so later changes remain understandable.",{"label":1545,"description":1546},"6. Implement and integrate","Turn the architecture into application code, APIs, policies, infrastructure, workflows and operational controls.",{"label":1548,"description":1549},"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":340,"data":1552,"type":41},{"text":1553,"level":241},"Where the simple example stops",{"id":344,"data":1555,"type":217},{"text":1556},"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":348,"data":1558,"type":217},{"text":1559},"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":352,"data":1561,"type":41},{"text":1562,"level":241},"Architecture responsibility map",{"id":356,"data":1564,"type":217},{"text":1565},"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":360,"data":1567,"type":290},{"content":1568,"stretched":42,"withHeadings":13},[1569,1573,1577,1581,1585,1589,1593,1597,1601,1605,1609],[1570,1571,1572],"Architecture area","Questions the AI Solution Architect must resolve","Typical outputs",[1574,1575,1576],"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",[1578,1579,1580],"Requirements and NFRs","What quality, security, availability, latency, cost, residency and compliance constraints apply?","Requirement map, NFRs, constraints, validation criteria",[1582,1583,1584],"Application and orchestration","Where does deterministic application logic end and AI behavior begin? How are workflows coordinated?","Component model, APIs, orchestration boundaries, failure paths",[1586,1587,1588],"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",[1590,1591,1592],"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",[1594,1595,1596],"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",[1598,1599,1600],"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",[1602,1603,1604],"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",[1606,1607,1608],"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",[1610,1611,1612],"Operations and change","How are models\u002Fprompts\u002Fconfiguration\u002Fdata versions changed, rolled back and supported?","Operational model, lifecycle controls, ADRs, runbooks, change rules",{"id":408,"data":1614,"type":41},{"text":1615,"level":240},"1. Turn product need into architectural requirements",{"id":412,"data":1617,"type":217},{"text":1618},"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":416,"data":1620,"type":217},{"text":1621},"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":420,"data":1623,"type":41},{"text":1624,"level":240},"2. Design authoritative data, retrieval and context",{"id":424,"data":1626,"type":217},{"text":1627},"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":428,"data":1629,"type":217},{"text":1630},"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":432,"data":1632,"type":41},{"text":1633,"level":240},"3. Treat models and providers as dependencies, not the whole system",{"id":436,"data":1635,"type":217},{"text":1636},"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":440,"data":1638,"type":217},{"text":1639},"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":444,"data":1641,"type":41},{"text":1642,"level":240},"4. Architect tools, actions and agent boundaries",{"id":448,"data":1644,"type":217},{"text":1645},"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":452,"data":1647,"type":217},{"text":1648},"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":456,"data":1650,"type":41},{"text":1651,"level":240},"5. Make trust boundaries and permissions explicit",{"id":460,"data":1653,"type":217},{"text":1654},"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":464,"data":1656,"type":217},{"text":1657},"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":468,"data":1659,"type":41},{"text":1660,"level":240},"6. Decide where the system actually runs",{"id":472,"data":1662,"type":217},{"text":1663},"“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":476,"data":1665,"type":217},{"text":1666},"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":480,"data":1668,"type":41},{"text":1669,"level":240},"7. Define evaluation, observability and operational acceptance",{"id":484,"data":1671,"type":217},{"text":1672},"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":488,"data":1674,"type":217},{"text":1675},"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":492,"data":1677,"type":41},{"text":1678,"level":241},"What should the role produce?",{"id":496,"data":1680,"type":217},{"text":1681},"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":500,"data":1683,"type":290},{"content":1684,"stretched":42,"withHeadings":13},[1685,1688,1691,1694,1697,1700,1702,1705,1708],[1686,1687],"Artifact","Purpose",[1689,1690],"Solution context and boundary","Shows users, external systems, major responsibilities and what is outside scope",[1692,1693],"Requirement\u002FNFR map","Connects product need and constraints to architecture work and validation",[1695,1696],"Component and data-flow views","Shows application, data\u002Fretrieval, model, tools, identity and runtime interactions",[1698,1699],"Trust and permission model","Makes identities, secrets, authorization, sensitive data and high-risk actions explicit",[519,1701],"Preserves significant choices, alternatives, trade-offs, status and consequences",[1703,1704],"Evaluation and acceptance plan","Defines evidence required to claim that the solution meets quality and safety expectations",[1706,1707],"Deployment and operational view","Defines environments, runtime locations, observability, rollback, incident and lifecycle responsibilities",[1709,1710],"Traceability links","Connects requirements, decisions, implementation work, tests and operational evidence",{"id":531,"data":1712,"type":41},{"text":1713,"level":241},"The work is mostly trade-offs, not “best practice” selection",{"id":535,"data":1715,"type":217},{"text":1716},"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":539,"data":1718,"type":290},{"content":1719,"stretched":42,"withHeadings":13},[1720,1725,1730,1735,1740,1745,1750,1755],[1721,1722,1723,1724],"Decision","Potential benefit","Potential cost \u002F risk","Architectural question",[1726,1727,1728,1729],"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?",[1731,1732,1733,1734],"Local\u002Fself-hosted inference","Control, offline\u002Fprivate options","Hardware, operations, model lifecycle burden","Is the control benefit worth the operational responsibility?",[1736,1737,1738,1739],"Single provider integration","Simpler implementation, full provider features","Higher switching\u002Ffailure concentration","Is portability or fallback actually required?",[1741,1742,1743,1744],"Provider abstraction","Portability, routing and policy separation","Lowest-common-denominator risk, more code\u002Ftests","Which differences must remain visible rather than abstracted?",[1746,1747,1748,1749],"Large context","More information per request","Latency, cost, attention dilution, leakage surface","Should data be retrieved\u002Ffiltered instead of always injected?",[1751,1752,1753,1754],"Powerful tools \u002F autonomy","More end-to-end automation","Higher privilege and failure blast radius","Which actions require least privilege, confirmation or human approval?",[1756,1757,1758,1759],"Strict validation and logging","Better evidence and operations","Latency, storage, privacy and complexity cost","What evidence is required for this risk level?",{"id":583,"data":1761,"type":41},{"text":1762,"level":241},"How is this different from adjacent roles?",{"id":587,"data":1764,"type":217},{"text":1765},"Titles overlap heavily across companies. The useful distinction is the \u003Cstrong>scope of architecture responsibility\u003C\u002Fstrong>, not the HR label.",{"id":591,"data":1767,"type":298},{"rows":1768,"title":1781,"layout":290,"columns":1782},[1769,1771,1773,1775,1777,1779],{"id":595,"label":596,"values":1770},{"role":598,"focus":599},{"id":601,"label":602,"values":1772},{"role":604,"focus":605},{"id":607,"label":608,"values":1774},{"role":610,"focus":611},{"id":613,"label":614,"values":1776},{"role":616,"focus":617},{"id":619,"label":620,"values":1778},{"role":622,"focus":623},{"id":625,"label":626,"values":1780},{"role":628,"focus":629},"Adjacent roles answer different primary questions",[1783,1785],{"id":633,"label":1784},"Role",{"id":636,"label":1786},"Primary architecture focus",{"id":639,"data":1788,"type":217},{"text":1789},"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":643,"data":1791,"type":41},{"text":1792,"level":241},"Implementation evidence: how these boundaries appear in my own work",{"id":647,"data":1794,"type":224},{"body":1795,"title":1796,"variant":651},"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":653,"data":1798,"type":41},{"text":1799,"level":240},"SenseFlow: need → requirements → architecture → validation",{"id":657,"data":1801,"type":217},{"text":1802},"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":661,"data":1804,"type":217},{"text":1805},"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":665,"data":1807,"type":217},{"text":1808},"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":669,"data":1810,"type":41},{"text":1811,"level":240},"Aaasaasa AI Client: separate concepts before integrating them",{"id":673,"data":1813,"type":217},{"text":1814},"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":677,"data":1816,"type":217},{"text":1817},"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":681,"data":1819,"type":217},{"text":1820},"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":685,"data":1822,"type":41},{"text":1823,"level":241},"How current architecture frameworks support this broader scope",{"id":689,"data":1825,"type":217},{"text":1826},"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":693,"data":1828,"type":217},{"text":1829},"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":697,"data":1831,"type":217},{"text":1832},"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":701,"data":1834,"type":41},{"text":1835,"level":241},"Common misconceptions",{"id":705,"data":1837,"type":290},{"content":1838,"stretched":42,"withHeadings":13},[1839,1842,1845,1848,1851,1854,1857,1860],[1840,1841],"Misconception","Correction",[1843,1844],"“The architect chooses the LLM.”","Model choice is one decision inside a larger solution architecture.",[1846,1847],"“Prompt engineering is the architecture.”","Prompts affect behavior, but they do not define identity, data access, trust boundaries, deployment, tool permissions or operations.",[1849,1850],"“RAG solves enterprise knowledge.”","Retrieval is only one subsystem; authorization, provenance, freshness, evidence, indexing, evaluation and source governance still need design.",[1852,1853],"“Local runtime means private\u002Flocal AI.”","Runtime, inference, data and control-plane locations are separate architectural properties.",[1855,1856],"“If a vendor offers guardrails, security is covered.”","Security spans identity, authorization, secrets, data flows, tools, logging, deployment, human approval and provider boundaries.",[1858,1859],"“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.",[1861,1862],"“An architecture diagram proves production readiness.”","Readiness requires implemented controls and validation evidence across quality, security, operations and business acceptance.",{"id":733,"data":1864,"type":41},{"text":1865,"level":241},"Failure modes an AI Solution Architect should prevent",{"id":737,"data":1867,"type":290},{"content":1868,"stretched":42,"withHeadings":13},[1869,1873,1877,1881,1885,1889,1893,1897,1901],[1870,1871,1872],"Failure mode","Why it happens","Architectural correction",[1874,1875,1876],"Model-first design","A promising model demo becomes the system blueprint","Start from outcome, constraints and validation; select the model inside that frame",[1878,1879,1880],"Prototype permissions in production","Shared credentials and broad access survive the PoC","Define identity propagation, least privilege, tool scopes and approval boundaries early",[1882,1883,1884],"Retrieval without authorization","Search quality is designed before data-access rules","Carry user\u002Ftenant context into retrieval and enforce authorization at data-access boundaries",[1886,1887,1888],"Silent provider\u002Fruntime assumptions","“Local”, “cloud” and “offline” are used imprecisely","Document runtime, inference, data and control-plane location separately",[1890,1891,1892],"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",[1894,1895,1896],"Evaluation after implementation","Quality is judged manually near launch","Define measurable acceptance and representative evaluation sets before architecture freezes",[1898,1899,1900],"Untraceable change","Models, prompts, retrieval or permissions change without architectural history","Version critical configuration and record significant decisions\u002Fvalidation evidence",[1902,1903,1904],"Operations treated as infrastructure only","AI behavior is not observable after deployment","Design traces, quality metrics, security events, cost telemetry and rollback together",{"id":777,"data":1906,"type":41},{"text":1907,"level":241},"A practical decision sequence",{"id":781,"data":1909,"type":338},{"steps":1910,"title":1935,"orientation":337},[1911,1914,1917,1920,1923,1926,1929,1932],{"label":1912,"description":1913},"Outcome","Define the user\u002Fbusiness result and explicit non-goals.",{"label":1915,"description":1916},"Evidence and constraints","Identify authoritative data, policies, NFRs, risks and acceptance conditions.",{"label":1918,"description":1919},"System boundary","Map users, identities, applications, data, models\u002Fproviders, tools and external systems.",{"label":1921,"description":1922},"Architecture options","Compare patterns for retrieval, model access, orchestration, deployment, permissions, evaluation and observability.",{"label":1924,"description":1925},"Trade-off decisions","Select significant options and preserve the rationale, alternatives and consequences.",{"label":1927,"description":1928},"Implementation contracts","Turn decisions into APIs, schemas, permission rules, deployment definitions and engineering tasks.",{"label":1930,"description":1931},"Validation","Test the implemented system against the original functional and non-functional requirements.",{"label":1933,"description":1934},"Operational feedback","Use production evidence, incidents, quality metrics and cost\u002Fsecurity signals to trigger controlled change.","AI solution architecture decision sequence",{"id":810,"data":1937,"type":41},{"text":1938,"level":241},"Edge cases and limits of the role",{"id":814,"data":1940,"type":217},{"text":1941},"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":818,"data":1943,"type":217},{"text":1944},"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":822,"data":1946,"type":217},{"text":1947},"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":826,"data":1949,"type":41},{"text":1950,"level":241},"What would change this answer?",{"id":830,"data":1952,"type":217},{"text":1953},"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":834,"data":1955,"type":217},{"text":1956},"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":838,"data":1958,"type":41},{"text":1959,"level":241},"AI Solution Architect checklist",{"id":842,"data":1961,"type":290},{"content":1962,"stretched":42,"withHeadings":13},[1963,1966,1968,1971,1973,1976,1979,1982,1985,1987,1990,1992,1994],[1964,1965],"Check","Question",[1912,1967],"Is the user\u002Fbusiness result and non-goal boundary explicit?",[1969,1970],"Requirements","Are functional requirements, NFRs, constraints and acceptance criteria traceable?",[1500,1972],"Are authoritative sources, provenance, freshness, retention and access rules defined?",[1974,1975],"Retrieval\u002Fcontext","Does authorization reach retrieval and context construction?",[1977,1978],"Model\u002Fprovider","Is model\u002Fprovider selection tied to capabilities and constraints rather than preference?",[1980,1981],"Tools\u002Fagents","Are action boundaries, permissions, approvals and failure behavior explicit?",[1983,1984],"Identity\u002Fsecurity","Are human\u002Fmachine identities, secrets and trust boundaries defined?",[868,1986],"Are runtime, inference, data and control-plane locations distinguished?",[1988,1989],"Evaluation","Is there measurable evidence for quality, security and acceptance?",[874,1991],"Can production behavior, failures, cost and security events be investigated?",[1509,1993],"Are significant architecture decisions and replacements traceable?",[1506,1995],"Is ownership for deployment, rollback, incidents and lifecycle clear?",{"id":881,"data":1997,"type":41},{"text":1998,"level":241},"Conclusion",{"id":885,"data":2000,"type":217},{"text":2001},"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":889,"data":2003,"type":217},{"text":2004},"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":893,"data":2006,"type":893},{"items":2007,"title":928},[2008,2011,2014,2017,2020,2023,2026,2029],{"id":897,"answer":2009,"question":2010},"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":901,"answer":2012,"question":2013},"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":905,"answer":2015,"question":2016},"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":909,"answer":2018,"question":2019},"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":913,"answer":2021,"question":2022},"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":917,"answer":2024,"question":2025},"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":921,"answer":2027,"question":2028},"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":925,"answer":2030,"question":2031},"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":930,"data":2033,"type":930},{"title":2034,"entries":2035},"Core terms",[2036,2038,2040,2043,2045,2047,2049,2051],{"term":596,"anchor":935,"definition":2037},"Architecture responsibility for one concrete AI-enabled solution or workload, integrating product requirements with application, data, model, tool, security, runtime and operational design.",{"term":1918,"anchor":938,"definition":2039},"The explicit separation between what belongs to the solution and the users, systems, providers, data sources and environments it interacts with.",{"term":2041,"anchor":942,"definition":2042},"Trust boundary","A point where data, identities or control cross between components with different trust assumptions and therefore require explicit security controls.",{"term":945,"anchor":946,"definition":2044},"Supplying an AI model with relevant external information or evidence so its response can be based on sources beyond model parameters.",{"term":1741,"anchor":949,"definition":2046},"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":1988,"anchor":952,"definition":2048},"Structured measurement of AI workload behavior against defined acceptance criteria, including task quality and relevant safety, security, performance and operational properties.",{"term":602,"anchor":955,"definition":2050},"Architectural role focused on reusable AI platform capabilities used by multiple solutions rather than the architecture of one workload.",{"term":958,"anchor":959,"definition":2052},"Organization-level architecture that coordinates AI capabilities, platforms, governance, integration and strategic constraints across a portfolio.",{"id":962,"data":2054,"type":41},{"text":2055,"level":241},"Related canonical knowledge",{"id":966,"data":2057,"type":217},{"text":2058},"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":970,"data":2060,"type":978},{"link":2061,"meta":2062},"https:\u002F\u002Fstajic.de\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works",{"image":2063,"title":976,"description":2064},{"url":975},"Existing stajic.de canonical explanation of retrieval-augmented generation, useful for the retrieval\u002Fgrounding part of AI solution architecture.",{"id":980,"data":2066,"type":41},{"text":2067,"level":241},"Primary sources and current architecture guidance",{"id":984,"data":2069,"type":217},{"text":2070},"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":988,"data":2072,"type":978},{"link":990,"meta":2073},{"image":2074,"title":993,"description":2075},{"url":975},"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":996,"data":2077,"type":978},{"link":998,"meta":2078},{"image":2079,"title":1001,"description":2080},{"url":975},"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":1004,"data":2082,"type":978},{"link":1006,"meta":2083},{"image":2084,"title":1009,"description":2085},{"url":975},"Official NIST AIRC presentation of the AI RMF 1.0 Core, including the four functions and lifecycle-oriented risk-management framing.",{"id":1012,"data":2087,"type":978},{"link":1014,"meta":2088},{"image":2089,"title":1017,"description":2090},{"url":975},"Cross-sectoral Generative AI profile for AI RMF 1.0, published 26 July 2024 and updated by NIST in 2026.",{"id":1020,"data":2092,"type":978},{"link":1022,"meta":2093},{"image":2094,"title":1025,"description":2095},{"url":975},"Current workload-level architecture guidance covering AI application design, application platform, training data, grounding data, data platform and production-readiness concerns.",{"id":1028,"data":2097,"type":978},{"link":1030,"meta":2098},{"image":2099,"title":1033,"description":2100},{"url":975},"Guidance on model\u002Ftool abstraction, data-access boundaries, identity propagation, authorization and separation of client, intelligence, knowledge and tool layers.",{"id":1036,"data":2102,"type":978},{"link":1038,"meta":2103},{"image":2104,"title":1041,"description":2105},{"url":975},"Current AI workload design principles across reliability, security, cost, operational excellence and performance, including identity and data-protection responsibilities.",{"id":1044,"data":2107,"type":978},{"link":1046,"meta":2108},{"image":2109,"title":1049,"description":2110},{"url":975},"Production lifecycle guidance covering monitoring, quality gates, model\u002Fprompt behavior, security and operational measurement.",{"id":1052,"data":2112,"type":978},{"link":1054,"meta":2113},{"image":2114,"title":1057,"description":2115},{"url":975},"AWS architectural guidance for generative AI workloads across operational excellence, security, reliability, performance efficiency, cost optimization and sustainability.",{"id":1060,"data":2117,"type":978},{"link":1062,"meta":2118},{"image":2119,"title":1065,"description":2120},{"url":975},"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.","Post erfolgreich abgerufen",{"items":2125,"source":2210,"manualIds":2211,"manualMatchedIds":2212},[2126,2133,2140,2147,2154,2161,2168,2175,2182,2189,2196,2203],{"id":2127,"slug":2128,"title":2129,"excerpt":2130,"featuredImage":2131,"publishedAt":2132},"495","sovereign-ai-control-of-models-data-infrastructure-and-dependencies","Souveräne KI: Kontrolle über Modelle, Daten, Infrastruktur und Abhängigkeiten","Souveräne KI bedeutet wirksame Kontrolle über Modelle, Daten, Infrastruktur, Software, Betrieb und strategische Abhängigkeiten – nicht einfach, wo ein KI-Modell gehostet wird.","\u002Fuploads\u002F2026\u002F10\u002Fsovereign-ai-control-of-models-data-infrastructure-and-dependencies-1791488833132-niy85x.webp","2026-10-08T15:45:00.000Z",{"id":2134,"slug":2135,"title":2136,"excerpt":2137,"featuredImage":2138,"publishedAt":2139},"381","enterprise-grade-multi-tenant-architecture-for-an-international-platform","Unternehmensfähige mandantenfähige Architektur für eine internationale Plattform","Loving Rocks ist eine Hochzeitsplattform auf Unternehmensniveau, konzipiert mit einer echten Mehrmandantenarchitektur, isolierten Datenbanken pro Mandant und integrierter Internationalisierung für globale Skalierbarkeit, Sicherheit und langfristige Betriebsstabilität.","\u002Fuploads\u002F2026\u002F01\u002Fenterprise-grade-multi-tenant-architecture-for-an-international-platform-1769789121298-b6v7ak.webp","2026-01-30T12:04:00.000Z",{"id":2141,"slug":2142,"title":2143,"excerpt":2144,"featuredImage":2145,"publishedAt":2146},"486","source-of-truth-in-ai-systems-where-reliable-knowledge-actually-comes-from","Wahrheitsquelle in KI-Systemen: Woher verlässliches Wissen tatsächlich stammt","Eine Quelle der Wahrheit definiert, welche Quelle für einen bestimmten Fakt oder Zustand maßgeblich ist. Erfahren Sie, wie sie sich von RAG, Provenienz, Gedächtnis, Kontext, Vektordatenbanken und Systemen of Record unterscheidet.","\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":2148,"slug":2149,"title":2150,"excerpt":2151,"featuredImage":2152,"publishedAt":2153},"471","how-to-know-whether-an-ai-agent-actually-used-the-right-evidence","Wie man erkennt, ob ein KI-Agent tatsächlich die richtigen Belege verwendet hat","Ein KI-Agent kann Quellen zitieren und trotzdem die falschen Belege verwenden. Dieser Artikel stellt eine praktische Methode zur Überprüfung der Belegung von Behauptungen, der Quellenautorität, der Anwendbarkeit, der Herkunft sowie der Frage vor, ob die Belege die Antwort tatsächlich beeinflusst haben.","\u002Fuploads\u002F2026\u002F09\u002Fhow-to-know-whether-an-ai-agent-actually-used-the-right-evidence-1790351317188-o5z9ve.webp","2026-09-25T11:47:00.000Z",{"id":2155,"slug":2156,"title":2157,"excerpt":2158,"featuredImage":2159,"publishedAt":2160},"494","air-gapped-ai-how-ai-systems-work-without-internet-or-cloud-access","Luftgetrennte KI: Wie KI-Systeme ohne Internet- oder Cloud-Zugriff funktionieren","Air-gapped AI führt Modelle, RAG und KI-Anwendungen innerhalb einer isolierten Sicherheitsdomäne ohne Internet- oder Cloud-Abhängigkeiten aus. Erfahren Sie, wie Modelle, Daten, Updates und Tools offline funktionieren.","\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":2162,"slug":2163,"title":2164,"excerpt":2165,"featuredImage":2166,"publishedAt":2167},"487","vector-databases-embeddings-and-reranking-three-different-parts-of-retrieval","Vektordatenbanken, Embeddings und Reranking: Drei verschiedene Teile des Retrievals","Embeddings repräsentieren Bedeutung, Vektordatenbanken rufen Kandidaten ab und Reranker verfeinern Ergebnisse. Erfahren Sie, wie sich diese drei Retrieval-Ebenen unterscheiden und in RAG zusammenwirken.","\u002Fuploads\u002F2026\u002F10\u002Fvector-databases-embeddings-and-reranking-three-different-parts-of-retrieval-1791480129884-9dtasz.webp","2026-10-08T11:21:00.000Z",{"id":2169,"slug":2170,"title":2171,"excerpt":2172,"featuredImage":2173,"publishedAt":2174},"484","what-is-an-ai-platform-architect-models-data-runtime-security-and-operations","Was ist ein KI-Plattform-Architekt? Modelle, Daten, Laufzeitumgebung, Sicherheit und Betrieb","Ein KI-Plattform-Architekt entwirft wiederverwendbare KI-Grundlagen über Modelle, Anbieter, Retrieval, Agenten, Identität, Sicherheit, Evaluierung, Observability und Betrieb hinweg.","\u002Fuploads\u002F2026\u002F10\u002Fwhat-is-an-ai-platform-architect-models-data-runtime-security-and-operations-1791477229171-ou3zcc.webp","2026-10-08T12:32:00.000Z",{"id":2176,"slug":2177,"title":2178,"excerpt":2179,"featuredImage":2180,"publishedAt":2181},"489","agentic-ai-explained-when-an-ai-system-can-plan-use-tools-and-act","Agentische KI erklärt: Wenn ein KI-System planen, Werkzeuge nutzen und handeln kann","Agentische KI verwendet Modelle innerhalb mehrstufiger Ausführungsschleifen, in denen sie Werkzeuge auswählen, Ergebnisse beobachten, den Zustand aktualisieren und ihre nächste Aktion innerhalb expliziter Laufzeit- und Berechtigungsgrenzen anpassen können.","\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":2183,"slug":2184,"title":2185,"excerpt":2186,"featuredImage":2187,"publishedAt":2188},"485","enterprise-ai-architecture-what-changes-when-ai-enters-a-company","Enterprise-KI-Architektur: Was ändert sich, wenn KI in ein Unternehmen eintritt","Enterprise-KI-Architektur erklärt, wie KI Unternehmenssysteme über Datenhoheit, Identität, Berechtigungen, Anbieter, Risiko, Governance, Evaluierung, Compliance und Betrieb hinweg verändert.","\u002Fuploads\u002F2026\u002F10\u002Fenterprise-ai-architecture-what-changes-when-ai-enters-a-company-1791478161363-czrwaq.webp","2026-10-08T10:48:00.000Z",{"id":2190,"slug":2191,"title":2192,"excerpt":2193,"featuredImage":2194,"publishedAt":2195},"467","the-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers","Die Antwortgültigkeitsgrenze: Die fehlende Schicht zwischen Relevanz und zuverlässigen KI-Antworten","Eine Quelle kann relevant und maßgeblich sein und dennoch falsch für die gestellte Frage. Die fehlende Ebene ist die Anwendbarkeit: die Bedingungen, unter denen eine Antwort gilt, und die Veränderungen, die erzwingen, dass sie überdacht werden muss. Dieser Artikel führt die Answer Validity Boundary als ein Quellendesign-Muster für Menschen, KI-Suche und RAG-Systeme ein.","\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":2197,"slug":2198,"title":2199,"excerpt":2200,"featuredImage":2201,"publishedAt":2202},"476","mcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained","MCP vs A2A vs UCP vs AP2 vs A2UI: Der Agenten-Protokoll-Stack erklärt","MCP, A2A, UCP, AP2 und A2UI werden oft als konkurrierende Agentenstandards dargestellt. Sie lösen größtenteils unterschiedliche Interoperabilitätsprobleme. Dieser Leitfaden ordnet jedes Protokoll der Grenze zu, die es tatsächlich standardisiert—und zeigt, wie sie in einem Produktionssystem zusammenarbeiten können.","\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":2204,"slug":2205,"title":2206,"excerpt":2207,"featuredImage":2208,"publishedAt":2209},"468","ai-agent-memory-is-not-rag-how-to-separate-memory-retrieval-state-and-context","KI-Agenten-Gedächtnis ist kein RAG: Wie man Gedächtnis, Retrieval, Zustand und Kontext voneinander trennt","Agentengedächtnis, RAG, Zustand und Kontext werden oft so verwendet, als wären sie austauschbar. Das sind sie nicht. Dieses praktische Architekturmodell trennt die vier Schichten, zeigt, wohin jede gehört, und erklärt, was kaputtgeht, wenn Systeme sie zu einer einzigen zusammenfassen.","\u002Fuploads\u002F2026\u002F09\u002Fai-agent-memory-is-not-rag-how-to-separate-memory-retrieval-state-and-context-1790350560308-np0xy6.webp","2026-09-25T11:34:00.000Z","fallback",[],[]]