KI-Lösungsarchitektur: Der vollständige Leitfaden für Enterprise-KI-Projekte

Wichtigste Erkenntnisse
KI-Lösungsarchitektur erfordert einen Documentation-first-Ansatz – undokumentierte KI-Systeme scheitern bei Übergabe, Audit und Skalierung
Das arc42-Framework ist die praktischste Vorlage zur Dokumentation von KI-Systemen, weil es Aspekte trennt, die für verschiedene Stakeholder relevant sind: Ziele, Bausteine, Laufzeitverhalten und Deployment
Multi-Agenten-Systeme benötigen explizite Orchestrierungsmuster (sequenziell, parallel, Handoff), die vor der Implementierung dokumentiert werden
Die drei folgenreichsten Architekturentscheidungen in jedem KI-Projekt sind: Model-Serving-Strategie, Vektorspeicher-Auswahl und Identity-/UID-Design
Die meisten KI-Architektur-Fehler entstehen nicht in der Modellschicht, sondern in der Integrationsschicht – Authentifizierung, Async-Jobs und Datenpipelines

Wenn ein CTO einem neuen Ingenieur ein KI-System übergibt, das vor sechs Monaten gebaut wurde, passiert eines von zwei Dingen: Entweder öffnet dieser ein klares Architekturdokument und versteht das System innerhalb eines Nachmittags, oder er verbringt zwei Wochen damit, Entscheidungen zu rekonstruieren, die in einem Sprint getroffen und nie aufgeschrieben wurden. Der Unterschied liegt nicht in der Codequalität. Er liegt in der Qualität der Architekturdokumentation.

KI-Projekte sind besonders anfällig für Dokumentationsschulden. Die Modellexperimente gehen schnell voran, die Integrationen sind maßgeschneidert, und das Deployment ist oft ein Flickenteppich aus Cloud-Ressourcen, Containern und API-Aufrufen, der um 2 Uhr nachts während eines Hackathons sinnvoll erschien. Wenn dieses System gewartet, skaliert oder auditiert werden muss, wird das Fehlen strukturierter Dokumentation zu einem ernsthaften Geschäftsrisiko.

Dieser Leitfaden erklärt, wie man KI-Systeme entwirft, die von Anfang an gut dokumentiert sind – mit Mustern, die sich in echten Beratungsprojekten bewährt haben: von GPU-Trainingsclustern über Multi-Agenten-Chatbots bis hin zu medizinischen Datenerfassungsplattformen.

Das arc42-Framework für KI-Systeme

arc42 ist eine Open-Source-Vorlage für Software- und Systemarchitekturdokumentation, entwickelt von Dr. Peter Hruschka und Dr. Gernot Starke. Version 8.2 ist der aktuelle Standard. Es organisiert Architekturdokumentation in 12 Abschnitte, von denen jeder eine spezifische Frage beantwortet, die Stakeholder beantwortet haben wollen.

Für KI-Projekte ist arc42 besonders wertvoll, weil es explizite Entscheidungen auf jeder Abstraktionsebene erzwingt – von Geschäftszielen bis hin zur Deployment-Infrastruktur – bevor diese Entscheidungen im Implementierungslärm vergraben werden.

Die 12 arc42-Abschnitte angewendet auf KI-Projekte

1. Einführung und Ziele Definieren Sie die Geschäftsziele, die das KI-System unterstützen muss, die wesentlichen Features und die Qualitätsziele zur Beurteilung der Architektur. Für KI-Systeme umfassen Qualitätsziele typischerweise: Inferenzlatenz, Verfügbarkeit, Modell-Update-Frequenz und Compliance-Anforderungen (DSGVO, Medizinprodukteverordnung usw.).

2. Randbedingungen Dokumentieren Sie, was nicht verhandelbar ist: regulatorische Einschränkungen, Anforderungen an den Datenspeicherort, bestehende Technologievorgaben und organisatorische Entscheidungen. Ein KI-System für einen Gesundheitsanbieter hat grundlegend andere Randbedingungen als eines für ein Startup – und diese Randbedingungen müssen Architekturentscheidungen treiben, nicht spät in der Umsetzung entdeckt werden.

3. Kontextabgrenzung Zeichnen Sie die Systemgrenze. Zeigen Sie jedes externe System, mit dem die KI-Lösung kommuniziert: Modellanbieter (OpenAI, lokales LLM über LM Studio, Ollama), Datenquellen, nachgelagerte Konsumenten und Monitoring-Systeme. Dies ist die C1-Ebene im C4-Modell – das wichtigste Diagramm, das Sie zeichnen werden.

4. Lösungsstrategie Dokumentieren Sie die Schlüsselentscheidungen, die den Gesamtansatz definieren: Build vs. Buy, Cloud vs. On-Premise, welche Model-Serving-Strategie, welches Orchestrierungs-Framework. Dies sind die Entscheidungen, die teuer zu revidieren sind.

5. Bausteinsicht (C3) Zerlegen Sie das System in seine Hauptkomponenten und ihre Verantwortlichkeiten. Für ein KI-System umfasst dies typischerweise: API-Gateway, KI/ML-Backend, Vektorspeicher und RAG-Pipeline, Modellregistry, Monitoring-Schicht und Datenschicht.

6. Laufzeitsicht (C4-Sequenzdiagramme) Dokumentieren Sie die wichtigsten Laufzeitszenarien – besonders für KI-Systeme, bei denen der Ausführungspfad nicht offensichtlich ist. Ein RAG-Query-Flow, ein Training-Pipeline-Trigger, eine Agenten-Handoff-Sequenz – diese müssen explizit dokumentiert werden, weil sie mehrere Komponenten umfassen und asynchrones Verhalten beinhalten, das leicht missverstanden wird.

7. Verteilungssicht Zeigen Sie, wie die Software auf die Infrastruktur abgebildet wird: welche Container, welche Kubernetes-Namespaces, welche Cloud-Ressourcen, wie die Netzwerktopologie aussieht. Für KI-Systeme auf GPU-Clustern ist diese Sicht entscheidend für Kostenmanagement und Skalierungsentscheidungen.

8. Querschnittliche Konzepte Dokumentieren Sie die konsistent eingesetzten Muster: Authentifizierungsansatz, Logging- und Observability-Strategie, Fehlerbehandlungsmuster, Datensicherungsrichtlinie, CI/CD-Workflow. Dies sind die „Wie machen wir das hier"-Entscheidungen.

9. Architekturentscheidungen (ADRs) Halten Sie wesentliche Architekturentscheidungen als Architecture Decision Records fest – einen pro Entscheidung. Ein ADR dokumentiert: den Entscheidungskontext, die betrachteten Optionen, die getroffene Entscheidung und die Begründung. Für KI-Systeme sind wichtige ADRs: UID-/Identitätsstrategie, Model-Serving-Wahl und Datenbankauswahl.

10. Qualitätsanforderungen Spezifizieren Sie Qualitätsszenarien: „Das System muss innerhalb von 500 ms für 95 % der Anfragen unter Normallast eine Inferenzantwort zurückgeben." Diese sind testbar, konkret und an die Qualitätsziele in Abschnitt 1 gebunden.

11. Risiken und technische Schulden Dokumentieren Sie bekannte Risiken und Gegenmaßnahmen. Für KI-Systeme: Modellverfall, Kosten-Overruns bei Anbieter-APIs, Datenpipeline-Ausfälle, Cold-Start-Latenz für containerisierte Services.

12. Glossar Definieren Sie Domänenbegriffe einheitlich. Für KI-Systeme: RAG, Vektoreinbettung, Agenten-Handoff, Fine-Tuning vs. Inferenz, Modellregistry vs. Model Serving.

Das Drei-Schichten-KI-Architekturmuster

In mehreren KI-Beratungsprojekten taucht dasselbe Drei-Schichten-Muster als stabile Grundlage für Enterprise-KI-Systeme auf:

Schicht 1: Zugang und Orchestrierung

API-Gateway (Traefik, Kong oder Nginx) mit TLS-Terminierung, Rate-Limiting und Routing
Authentifizierung/Autorisierung (RBAC über Keycloak, Auth0 oder OIDC-Integration mit Corporate-Identity-Provider)
Job-Queue / Event-Bus (Redis, RabbitMQ oder Kafka) für asynchrone KI-Workloads – Inferenzanfragen sollten nicht synchron blockieren, wenn die Last unvorhersehbar ist
Feature-Flags und Konfigurationsdienst

Schicht 2: KI/ML-Backend

Model Serving – die Inferenz-Runtime: TGI (Text Generation Inference), vLLM oder Triton abhängig von Modelltyp und Latenzanforderungen
GPU-Job-Scheduler – Kubernetes mit KEDA für autoskalierungsbasierte Queue-Tiefe
Training und Fine-Tuning Services (getrennt vom Serving – diese sind Batch, nicht Echtzeit)
RAG-Pipeline – Embedding-Service + Vektordatenbank (pgvector für einfache Use Cases, Qdrant oder Milvus für hochskalierte Produktion)
Modellregistry – MLflow oder Weights & Biases für Experiment-Tracking und Modellversionierung

Schicht 3: Daten und Observability

Objektspeicher (S3, MinIO) für Modell-Artefakte, Trainings-Datensätze und generierte Ausgaben
Relationale Datenbank (PostgreSQL mit pgvector für kombinierte relationale + Vektor-Workloads)
Monitoring-Stack – Prometheus + Grafana + Loki (Metriken, Visualisierung, Log-Aggregation)
Backup – Velero für Kubernetes-Zustand plus Standard-Datenbank-Backup-Richtlinie

→ Verwandt: Der KI-Implementierungsprozess

Multi-Agenten-Architekturmuster

Wenn KI-Systeme komplexer werden, weichen Einzelmodell-Architekturen Multi-Agenten-Systemen, bei denen spezialisierte Agenten gemeinsam an Aufgaben arbeiten. Drei Orchestrierungsmuster decken die Mehrzahl der realen Anwendungsfälle ab:

Muster 1: Sequenzieller Workflow

Jeder Agent verarbeitet eine Nachricht der Reihe nach und gibt angereicherten Kontext an den nächsten weiter. Dies ist das häufigste Muster für Datenextraktions- und Verarbeitungspipelines.

Beispiel aus der Praxis: Ein Onboarding-Chatbot für Kunden verwendet ein sequenzielles Zwei-Agenten-Muster:

DataExtractionAgent verarbeitet jede Benutzernachricht zuerst – extrahiert strukturierte Profilinformationen (Name, Präferenzen, Budget) und speichert sie in der Datenbank
ConversationAgent verarbeitet dieselbe Nachricht danach – aber jetzt mit dem angereicherten Benutzerprofil als Kontext, was personalisierte Antworten ermöglicht

Dieses Muster bietet Agenten-Spezialisierung ohne die Komplexität paralleler Koordination. Jeder Agent hat eine einzige Verantwortung. Die API-Schicht koordiniert die Sequenz und gibt die finale Antwort zurück.

Muster 2: Parallele Verarbeitung

Mehrere Agenten verarbeiten dieselbe Eingabe gleichzeitig, und ein Koordinator aggregiert die Ergebnisse. Verwenden Sie dies, wenn unabhängige Teilaufgaben gleichzeitig ausgeführt werden können und Latenz wichtig ist.

Verwendung: Rechercheaufgaben, bei denen mehrere Informationsquellen gleichzeitig abgefragt werden müssen; Dokumentenanalyse, bei der verschiedene Aspekte unabhängig extrahiert werden können.

Muster 3: Agenten-Handoff

Ein Orchestrierungs-Agent entscheidet, welcher Spezialistenagent eine Anfrage bearbeiten soll, und gibt die Kontrolle ab. Der Spezialist erledigt die Aufgabe und kann an den Orchestrator oder einen anderen Spezialisten zurückgeben.

Verwendung: Komplexe Multi-Domänen-Aufgaben mit nicht-trivialer Routing-Logik; Kundendienst-Systeme, bei denen verschiedene Agenten Abrechnung, technischen Support und Kontoverwaltung übernehmen.

Agenten-Orchestrierung in arc42 dokumentieren

Für Multi-Agenten-Systeme wird die arc42-Laufzeitsicht (Abschnitt 6) besonders wichtig. Dokumentieren Sie jedes Orchestrierungsmuster als Sequenzdiagramm:

Welcher Agent die initiale Anfrage erhält
Welcher Kontext zwischen Agenten übergeben wird
Wie Agenten-Handoffs ausgelöst werden
Wo der Konversationsstatus persistiert wird
Wie Ausfälle eines Agenten behandelt werden

Wichtige Architekturentscheidung: UID- und Identitätsstrategie

Eine Entscheidung, die jedes KI-System, das mit Medien, Dokumenten oder generierten Inhalten arbeitet, früh treffen muss, ist die UID-Strategie (Unique Identifier). Diese Entscheidung hat Architekturimplikationen, die teuer zu revidieren sind.

Es gibt drei Ansätze mit unterschiedlichen Trade-offs:

Zufällige UID

Wird zum Registrierungszeitpunkt generiert, unabhängig vom Inhalt
Ermöglicht einen Registry-getriebenen Flow: Der Datensatz wird erstellt, bevor der Inhalt verarbeitet wird
Einfach zu implementieren, horizontal skalierbar, kollisionsresistent bei jeder Größe
Erfordert einen Registrierungsschritt, bevor Inhalte referenziert werden können
Am besten für: Content-Management-Systeme, Provenance-Tracking, Systeme, bei denen stabile Identität wichtiger ist als zustandslose Suche

Inhaltsbasierte UID

Aus dem Inhalt selbst berechnet (perceptual Hash, kryptografischer Hash oder Kombination)
Ermöglicht zustandslose Suche und Deduplizierung ohne Registry-Roundtrip
Komplexität liegt in der Kanonisierung: Was gilt nach Re-Encoding, Zuschneiden oder Komprimierung als „derselbe Inhalt"?
Kollisionsrisiko im Billionenmaßstab erfordert sorgfältige Hash-Auswahl
Am besten für: Deduplizierungspipelines, Content-Fingerprinting, Systeme, bei denen Sucheffizienz entscheidend ist

Hybrid-UID

Stabile Registry-Identität (zufällig) plus Content-Bindung für Matching und Lifecycle-Management
Flexibelste, aber komplexeste Option: zweischichtiges Identitätsmodell
Am besten für: Medien-Provenance-Systeme, Wasserzeichen-Services, Langzeit-Archivsysteme

Der Entscheidungsdatensatz sollte erfassen:

Zielskalierung (Tausende vs. Millionen vs. Billionen Assets)
Wasserzeichen-/Payload-Budget falls zutreffend
Lookup- und Verifikations-SLOs
Versionierungsmodell: Erhält ein abgeleitetes Asset eine neue UID oder wird es mit dem übergeordneten verknüpft?

DDD mit arc42 integrieren

Domain-Driven Design (DDD) und arc42 ergänzen sich, sie konkurrieren nicht. arc42 liefert die Dokumentationsstruktur; DDD liefert die Designsprache.

Die wichtigste Zuordnung:

Bounded Contexts → Bausteinsicht (Abschnitt 5): jeder Bounded Context ist ein Level-1-Baustein
Domain Events → Laufzeitsicht (Abschnitt 6): Sequenzdiagramme zeigen Event-Flows zwischen Contexts
Aggregates und Entities → Verteilungssicht (Abschnitt 7) und Glossar (Abschnitt 12)
Context Map → Kontextabgrenzung (Abschnitt 3): wie Bounded Contexts miteinander kommunizieren

Für KI-Systeme hilft DDD zu klären, welche KI-Fähigkeiten zu welcher Domäne gehören. Eine Dokumentenverarbeitungs-Domäne besitzt ihre Embedding- und Retrieval-Logik. Eine Konversations-Domäne besitzt ihre Agenten-Orchestrierung. Die Integrationspunkte zwischen Domänen sind die fragilsten Teile eines KI-Systems.

Häufige Architektur-Fallstricke bei KI-Projekten

1. Synchrone Inferenz unter Last LLM-Inferenzaufrufe direkt im synchronen Request-Pfad ohne Job-Queue. Wenn die Last steigt, kaskadieren Request-Timeouts. Lösung: KI-Workloads immer in eine Queue stellen und eine Job-ID mit Polling- oder Webhook-Muster zurückgeben.

2. Keine Modellregistry von Anfang an Modellversionen wie Code-Versionen behandeln – Checkpoints in Git committen, verfolgen nicht, welche Modellversion in Produktion ist. Beginnen Sie mit MLflow oder einer einfachen Modellregistry an Tag eins, nicht nach dem ersten Produktionsvorfall.

3. Undokumentierte Agenten-Prompts System-Prompts sind Architekturentscheidungen. Sie gehören in die Versionskontrolle mit derselben Disziplin wie Code. Undokumentierte Prompts sind eine Wartungs- und Auditierbarkeits-Verbindlichkeit.

4. Keine Trennung zwischen Training- und Inferenz-Infrastruktur Training-Jobs konsumieren GPU-Ressourcen unvorhersehbar und zu hohen Kosten. Training auf derselben Infrastruktur wie Inferenz-Serving zu betreiben erzeugt Latenz-Spitzen und Kosten-Overruns. Trennen Sie diese von Anfang an.

5. Fehlende Verteilungssicht Teams dokumentieren die Software-Architektur, aber nicht die Infrastruktur. Wenn der DevOps-Ingenieur wechselt, weiß niemand, wie das System tatsächlich deployed ist. Die arc42-Verteilungssicht (Abschnitt 7) ist nicht verhandelbar.

6. Kein Kontextdiagramm Jedes KI-System berührt externe Services – Modellanbieter, Authentifizierungssysteme, nachgelagerte Konsumenten. Das Fehlen einer expliziten Systemgrenze führt zu Integrations-Überraschungen und Scope Creep.

Entscheidungs-Checkliste: KI-Architektur-Review

Vor Beginn der Implementierung sollte jedes KI-System klare Antworten auf diese Fragen haben:

Ziele und Randbedingungen

Was sind die Top-3-Qualitätsziele, formuliert als messbare Szenarien?
Welche regulatorischen oder Compliance-Anforderungen gelten (DSGVO, HIPAA, Medizinprodukteverordnung)?
Was ist die Datenspeicherort-Anforderung?
Was ist die Zielskalierung (Nutzer, Anfragen/Sekunde, Datenvolumen)?

Modell und Serving

Welche Modelle werden verwendet? Cloud-API oder selbst-gehostet?
Was ist das Latenz-SLO für Inferenz?
Was ist die Modell-Update-Strategie?
Ist Fine-Tuning geplant? Wenn ja, wann und auf welcher Infrastruktur?

Daten und Identität

Was ist die UID-Strategie für Content/Assets?
Welche Daten werden wo und wie lange gespeichert?
Wird ein Vektorspeicher benötigt? Welcher, und warum?
Was ist die Backup- und Recovery-Richtlinie?

Integration und Betrieb

Wie werden KI-Workloads asynchron in die Queue gestellt und verarbeitet?
Was ist das Authentifizierungs- und Autorisierungsmodell?
Wie wird das System überwacht? Was sind die Alerting-Schwellenwerte?
Ist die Verteilungssicht dokumentiert?

Dokumentation

Gibt es ein arc42-Dokument mit mindestens den Abschnitten 1, 3, 5, 6 und 7?
Sind die wichtigsten Architekturentscheidungen als ADRs festgehalten?
Sind Agenten-System-Prompts versioniert?

Häufig gestellte Fragen

Was ist der Unterschied zwischen KI-Lösungsarchitektur und ML Engineering? ML Engineering konzentriert sich auf Modellentwicklung, Trainingspipelines und Experiment-Tracking. KI-Lösungsarchitektur konzentriert sich darauf, wie das Modell in ein größeres System integriert wird: die API-Verträge, die Datenflüsse, die Infrastruktur, die Observability und die Dokumentation. Ein gut architektiertes KI-System überlebt Modell-Upgrades, Teamwechsel und Skalierungsanforderungen.

Wann sollte man arc42 für KI-Projekte verwenden? Verwenden Sie arc42, wenn das System von mehr als einer Person gewartet wird, wenn es auditiert oder reguliert wird, oder wenn es über seinen ursprünglichen Deployment-Umfang hinaus skalieren muss. Für Hackathon-Prototypen oder Einzelingenieur-Experimente reicht ein leichtgewichtiger Architecture Decision Record. Für alles, was in Produktion geht, bietet arc42 die Struktur, die Wartungs-Albträume verhindert.

Welche Vektordatenbank sollte man verwenden? Für frühe KI-Projekte mit moderater Skalierung: PostgreSQL mit pgvector. Dies eliminiert eine separate Infrastrukturabhängigkeit und ist für die meisten RAG-Anwendungsfälle bis zu Millionen von Dokumenten ausreichend. Für hochskalierte Produktion mit strikten Latenzanforderungen: Qdrant (Open Source, Rust-basiert, schnell) oder Milvus (Enterprise-Skalierung).

Wie lange dauert es, ein arc42-Dokument für ein KI-Projekt zu erstellen? Ein Erstdurchlauf eines arc42-Dokuments, der die Abschnitte 1, 2, 3, 4, 5, 6 und 7 abdeckt, kann für ein bereits verstandenes System in 2–4 Stunden erstellt werden. Der Wert liegt nicht in der aufgewendeten Schreibzeit – sondern in den Entscheidungen, die dabei getroffen und dokumentiert werden.

Fazit: Architektur zuerst, KI danach

Die Organisationen, die den größten Nutzen aus KI ziehen, sind nicht diejenigen mit den ausgefeiltesten Modellen. Es sind diejenigen mit der klarsten Architektur: Systeme, die dokumentiert, beobachtbar und auf Weiterentwicklung ausgelegt sind. Das arc42-Framework, Multi-Agenten-Orchestrierungsmuster und die in diesem Leitfaden beschriebene Schichtenarchitektur sind die Bausteine von KI-Systemen, die ihr erstes Deployment überdauern.

Bereit, Ihr KI-System zu architektieren? Opteria arbeitet mit Engineering-Teams zusammen, um arc42-basierte Lösungsarchitekturen für KI-Projekte zu erstellen, von MVP bis produktionsskalierte Systeme.

→ Verwandt: Der KI-Implementierungsprozess → Verwandt: KI Acceleration Sprint → Verwandt: KI-ROI-Business-Case aufbauen