Was ist ein KI-Lösungsarchitekt? Systemgrenzen, Verantwortlichkeiten und Kompromisse

Ein AI Solution Architect ü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.

Was architektiert ein AI Solution Architect tatsächlich?

Der Gegenstand der Arbeit ist die Lösung: 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.

Eine nützliche Grenze ist daher: Geschäftsergebnis → Anforderungen → Systemverantwortlichkeiten → Architekturentscheidungen → Implementierung → Validierung → Betrieb. Der AI Solution Architect arbeitet über diese Kette hinweg und kollaboriert mit Produkt-, Engineering-, Daten-, Sicherheits-, Infrastruktur-, Governance- und Domänenspezialisten.

Das einfachste Beispiel

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.

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?

Wo das einfache Beispiel endet

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.

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.

Karte der Architekturverantwortlichkeiten

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.

1. Produktbedarf in Architekturanforderungen übersetzen

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.

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.

2. Autoritative Daten, Abruf und Kontext entwerfen

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.

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.

3. Modelle und Anbieter als Abhängigkeiten behandeln, nicht als das gesamte System

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.

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.

4. Werkzeuge, Aktionen und Agentengrenzen architektonisch gestalten

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.

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.

5. Vertrauensgrenzen und Berechtigungen explizit machen

Eine Produktions-KI-Lösung hat mehrere Vertrauensgrenzen: Browser oder Client, Anwendungs-Backend, KI-Orchestrierung, Retrieval-/Datendienste, 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?

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-/Zugriffsmanagement, Datenschutz, Inhaltskontrollen und Lebenszyklussicherheit. NIST behandelt Governance und Risikomanagement ebenfalls als kontinuierlich über den gesamten KI-Lebenszyklus.

6. Entscheiden, wo das System tatsächlich läuft

„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.

Der Architekt trennt daher Laufzeitort, Inferenzort, Datenort und Control Plane. Deren Vermischung erzeugt falsche Sicherheits- und Deployment-Annahmen.

7. Evaluation, Observability und operative Abnahme definieren

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.

Die aktuelle Well-Architected-KI-Richtlinie von Microsoft behandelt Monitoring als kontinuierlich und wendet es auf Modellverhalten, Prompts/Completions, Anomalien, Sicherheit und Produktions-Qualitätsgates an. AWS behandelt Observability, Lifecycle-Management und Modell-/Prompt-Nachverfolgbarkeit ebenfalls als operative Architekturanliegen.

Was sollte die Rolle produzieren?

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.

Die Arbeit besteht überwiegend aus Trade-offs, nicht aus der Auswahl von „Best Practices“

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.

Wie unterscheidet sich dies von angrenzenden Rollen?

Titel überschneiden sich stark zwischen Unternehmen. Die nützliche Unterscheidung ist der Umfang der Architekturverantwortung, nicht das HR-Label.

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.

Implementierungsnachweise: Wie diese Grenzen in meiner eigenen Arbeit erscheinen

SenseFlow: Bedarf → Anforderungen → Architektur → Validierung

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.

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/Version.

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.

Aaasaasa AI Client: Konzepte trennen, bevor sie integriert werden

Aaasaasa AI Client bietet ein eher implementierungsnahes Beispiel. Sein AI Hub trennt bewusst Agent/Client, Anbieter, Modell, Verbindungs-/Laufzeitort, Berechtigungen und Web-Client. Eine lokale Laufzeit bedeutet nicht automatisch lokale Inferenz, und Berechtigungen werden als Laufzeit-/Tool-Richtlinie behandelt, nicht als Eigenschaft des Modells.

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-/Datendienste und Laufzeiten. Cloud-Anmeldeinformationen verbleiben im privilegierten Main-Prozess; Renderer-Code erhält normalisierten Zustand statt roher Geheimnisse oder uneingeschränkten Betriebssystemzugriff.

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.

Wie aktuelle Architektur-Frameworks diesen breiteren Umfang unterstützen

ISO/IEC/IEEE 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.

NIST AI RMF 1.0 rahmt KI-Risikomanagement durch Govern, Map, Measure und Manage 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.

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-/Tool-Lebenszyklus, Kosten und menschliche Aufsicht ebenfalls als Architekturanliegen.

Häufige Missverständnisse

Fehlermodi, die ein AI Solution Architect verhindern sollte

Eine praktische Entscheidungssequenz

Randfälle und Grenzen der Rolle

Einige KI-Produkte werden von Modelltraining, wissenschaftlicher Experimentierung oder spezialisierter Hardware dominiert. In diesen Fällen können Modell-/Data-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.

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.

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.

Was würde diese Antwort ändern?

Die genaue Verantwortungsgrenze ändert sich, wenn die Architektur von einer Anwendung zu einer wiederverwendbaren Plattform oder zu einer unternehmensweiten Zielarchitektur übergeht. Deshalb verdienen AI Platform Architect und Enterprise AI Architecture eine separate kanonische Behandlung, anstatt in diese Rolle integriert zu werden.

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.

Checkliste für AI Solution Architects

Fazit

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.

Eine starke AI-Lösungsarchitektur lässt sich daher wie folgt zusammenfassen: 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. Das Modell ist wichtig. Die Lösung ist das Produkt.

Verwandtes kanonisches Wissen

Dieser Artikel gehört zum Cluster AI Architecture Foundations. Seine direkten Grundlagen sind Generative AI Explained: Models, Retrieval, Tools and Applications Are Not the Same Thing und ADR vs NFR: Architecture Decisions and System Quality Are Not the Same Thing. Benachbarte kanonische Knoten umfassen Agentic AI Explained, Source of Truth in AI Systems, Vector Databases, Embeddings and Reranking, What Is Context Engineering?, RBAC vs Tenant Isolation, AI Platform Architect, Enterprise AI Architecture und AI Governance. URLs werden bewusst nicht erfunden, wo diese Knoten noch nicht veröffentlicht sind.

Primärquellen und aktuelle Architekturanleitung

Die folgenden externen Quellen stützen die allgemeinen Architekturbehauptungen; die Abschnitte zu SenseFlow und Aaasaasa AI Client sind ausdrücklich originäre Projekt-/Implementierungsbelege. 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.