B5. Zielbild-Architektur für KI
Ein Zielbild für die KI-Architektur schafft ein gemeinsames Verständnis, wie Daten, Modelle, Plattformen und Prozesse zusammenspielen. Ohne Referenzbild entstehen Insellösungen, Doppelaufwände und Sicherheitslücken. Die Architektur zeigt die nötigen Bausteine, ihre Verbindungen und die geltenden Prinzipien und legt Sicherheits- und Datenschutzleitplanken fest. Sie ist Grundlage für technische Entscheidungen, Budgetverteilung und Priorisierung.
Was dieses Kapitel liefert: die Antwort auf die Frage, welche technischen Bausteine ein Unternehmen braucht, damit KI-Anwendungsfälle nicht als Insellösungen entstehen, und wie diese Bausteine zusammenhängen. Die Leserin oder der Leser (typischerweise CTO oder Architekt) nutzt die Referenzbausteine als Soll-Liste: Für jeden Baustein wird in der Architektur-Bestandsaufnahme geprüft, ob er im eigenen Unternehmen vorhanden, im Aufbau oder bewusst nicht nötig ist. Das Ergebnis ist das eigene Zielbild samt Lückenliste für die Roadmap (Kapitel C2). Je Anwendungsfall konkretisiert die Architektur-Entscheidungs-Checkliste die Wahl. Das Kapitel schreibt bewusst keine Produkte vor: Es beschreibt Bausteine und Prinzipien; die Produkt- und Anbieterauswahl folgt in Kapitel B3.
Die folgende Abbildung zeigt die Referenzbausteine im Überblick. Sie beantwortet die Frage: Aus welchen Ebenen besteht eine KI-fähige Architektur? Die sechs Ebenen sind entlang des Wegs der Daten angeordnet, von der obersten (Rohdaten kommen an) bis zur untersten (Ergebnisse erreichen die Geschäftsprozesse).
Die orangen Pfeile zeigen diesen Datenweg, und er ist nicht für jeden Anwendungsfall gleich. Prädiktive Anwendungsfälle sagen einen Wert oder eine Klasse voraus, etwa Betrugserkennung (verdächtig oder nicht) oder Absatzprognose (wie viele Stück im nächsten Monat). Sie laufen über die Merkmalsebene, weil sie aufbereitete Merkmale brauchen, etwa den Durchschnittsumsatz der letzten 30 Tage. Generative Anwendungsfälle erzeugen dagegen neue Inhalte, etwa ein Assistent, der Fragen aus den eigenen Dokumenten beantwortet. Sie überspringen die Merkmalsebene und greifen über die RAG-Pipeline direkt auf die Daten zu.
Der gestrichelte Pfeil läuft in die Gegenrichtung, von unten zurück nach oben. Er steht für Drift: Die Daten im laufenden Betrieb entfernen sich mit der Zeit von denen, mit denen das Modell trainiert wurde, und die Ergebnisse werden unbemerkt schlechter. Auffallen kann das nur im Betrieb, beheben lässt es sich nur bei den Daten, deshalb führt der Pfeil dorthin zurück.
Die Sicherheitsebene liegt quer, weil sie für alle Ebenen zugleich gilt. Jede Ebene nennt im Folgenden, was sie von der vorigen bekommt und was sie an die nächste liefert; die Abschnitte erklären jeden Baustein im Einzelnen.
Referenzbausteine
Jede Ebene beginnt mit ihrer Zielsetzung und einer Zeile Bekommt/Liefert, die zeigt, woher ihre Eingaben stammen und wohin ihre Ergebnisse gehen. Die Tabelle je Ebene nennt zu jedem Baustein, was konkret aufzubauen ist und welchen Mehrwert er stiftet.
Datenebene
Fundament der Architektur, denn alle Modelle bauen auf verlässlichen Daten auf. Ziel der Ebene: Daten aus den Quellsystemen geprüft, klassifiziert und auffindbar bereitstellen, sodass jedes Projekt auf denselben Bestand zugreift, statt eigene Kopien anzulegen. Die Datenstrategie dahinter wird in Kapitel B4 erarbeitet; hier stehen die technischen Bausteine, die sie umsetzen.
Bekommt Rohdaten aus den Quellsystemen (ERP, CRM, Sensoren, Dokumente). Liefert geprüfte und klassifizierte Daten an die Merkmalsebene (prädiktiver Pfad) und direkt an die RAG-Pipeline der generativen Ebene (generativer Pfad).
| Baustein | Was konkret zu tun ist | Mehrwert, was ohne ihn fehlt |
|---|---|---|
| Datenquellen-Katalog | Ein zentrales Verzeichnis aufbauen, das je Quelle zwei Sichten dokumentiert: die technische (Format, Schnittstelle, Aktualität) und die fachliche (Verantwortliche, Zweck, Nutzungserlaubnis). | Jedes Projekt sieht sofort, welche Daten es gibt und wen es fragt. Ohne Katalog beginnt jedes Vorhaben mit wochenlanger Suche. |
| Datenaufnahme | Einen kontrollierten Aufnahmeweg einrichten, der bei jedem Import automatisch prüft (Qualität), einstuft (Sensitivität) und protokolliert (Herkunft). | Fehler und ungeprüfte Kopien werden am Eingang abgefangen. Ohne ihn wandern schlechte Daten ungebremst in jedes Modell. |
| Datenplattform | Einen gemeinsamen Speicher- und Verarbeitungsort für strukturierte und unstrukturierte Daten bereitstellen, nach Fachdomänen getrennt, aber domänenübergreifend auswertbar. | Daten liegen an einer Stelle statt in verstreuten Kopien. Ohne sie legt jede Anwendung eigene, bald abweichende Bestände an. |
| Governance | Die Regeln aus der Datenstrategie technisch durchsetzen: benannte Data Owner, Freigabeprozesse, Zugriff nach minimalen Rechten, DSGVO-konforme Protokollierung. | Zugriff ist geregelt und nachweisbar. Ohne Durchsetzung bleiben die Governance-Regeln folgenlos. |
Merkmalsebene
Bereitet Rohdaten zu wiederverwendbaren Merkmalen auf, etwa „Alter" aus dem Geburtsdatum oder „Durchschnittstemperatur der letzten Stunde" aus Sensordaten. Ziel der Ebene: einmal berechnete Merkmale projektübergreifend verfügbar machen, statt sie in jedem Projekt neu zu bauen.
Bekommt geprüfte Daten aus der Datenebene. Liefert wiederverwendbare Merkmale an die Entwicklungsebene. Diese Ebene gehört nur zum prädiktiven Pfad; generative Anwendungsfälle nutzen sie nicht und greifen über die RAG-Pipeline direkt auf die Datenebene zu.
| Baustein | Was konkret zu tun ist | Mehrwert, was ohne ihn fehlt |
|---|---|---|
| Feature Store | Ein zentrales Verzeichnis wiederverwendbarer Merkmale mit Versionierung, Verantwortlichen und Qualitätstests aufbauen. | Einmal berechnete Merkmale werden projektübergreifend genutzt. Ohne ihn baut jedes Projekt dasselbe Merkmal neu und leicht abweichend. |
| Richtlinien | Verbindliche Regeln für Benennung, Dokumentation und Wiederverwendung festlegen. | Der Merkmalsbestand bleibt durchsuchbar. Ohne Regeln wuchert er zu einem unübersichtlichen Bestand. |
Entwicklungsebene
Entwurf, Training, Test und Dokumentation von Modellen, mit Nachvollziehbarkeit als Kernanforderung. Ziel der Ebene: Modelle so bauen und verpacken, dass ihre Entstehung reproduzierbar und prüfbar bleibt.
Bekommt Merkmale aus der Merkmalsebene (prädiktiv) sowie Daten und generative Bausteine für generative Modelle. Liefert paketierte, dokumentierte Modelle an die Betriebsebene und geprüfte generative Bausteine an die generative Ebene.
| Baustein | Was konkret zu tun ist | Mehrwert, was ohne ihn fehlt |
|---|---|---|
| Reproduzierbare, isolierte Umgebungen | Jedes Experiment und jedes Training in einer definierten Umgebung laufen lassen (Container, virtuelle Umgebungen). | Ergebnisse sind wiederholbar, Experimente stören sich nicht. Ohne sie lässt sich ein Ergebnis später nicht reproduzieren. |
| Paketierung von Artefakten | Fertige Modelle mit allem verpacken, was zu ihnen gehört: Modell- und Datenkarte sowie Trainingsprotokolle. | Für Audits bleibt nachvollziehbar, womit und wie ein Modell entstand. Ohne sie ist die Herkunft eines Modells nicht belegbar. |
| Generative Bausteine | Geprüfte Prompt-Vorlagen, Retrieval-Bausteine und Evaluationssuites bereitstellen. | Generative Anwendungen entstehen aus erprobten Teilen. Ohne sie baut jedes Team seine Prompts neu. |
Generative und agentische Ebene
Eigene Schicht für LLMs, RAG und Agenten. Sie wird bewusst getrennt geführt, weil sie eigene Bausteine, Risiken und Kosten hat. Ziel der Ebene: den Zugang zu Sprachmodellen kontrollieren und mehrschrittige Agenten sicher steuern.
Bekommt Dokumente direkt aus der Datenebene (für die RAG-Pipeline) sowie Modelle und Prompt-Bausteine aus der Entwicklungsebene. Liefert kontrollierten Modellzugang und geprüfte Agenten-Abläufe an die Betriebsebene.
| Baustein | Was konkret zu tun ist | Mehrwert, was ohne ihn fehlt |
|---|---|---|
| Modell-Gateway | Allen Modellzugriff über eine kontrollierte Stelle leiten, die protokolliert, Quoten durchsetzt und Kosten dem Verursacher zuordnet, gleich ob proprietäres Modell über API oder offenes Modell im Selbstbetrieb. | Der Modellzugang bleibt steuerbar und abrechenbar. Ohne Gateway entsteht Wildwuchs aus verteilten API-Schlüsseln, den niemand mehr steuert. |
| RAG-Pipeline | Die Kette aufbauen, die eigene Dokumente nutzbar macht: aufbereiten, in Embeddings umwandeln, indexieren, zur Laufzeit passende Passagen mit Quellenangabe zurückgeben (Begriffe in Kapitel A2). | Modelle antworten auf Basis eigener, belegter Dokumente. Ohne sie bleibt nur das Allgemeinwissen des Modells, ohne Quelle. |
| Prompt- und Kontextverwaltung | Prompts wie Code behandeln: versionieren, testen, freigeben. | Prompts sind nachvollziehbar und testbar. Ohne sie liegen sie verstreut in Anwendungen und Notizen. |
| Orchestrierung von Agenten | Werkzeugregister (welche Werkzeuge ein Agent aufrufen darf), Handlungsketten und Eingriffspunkte mit menschlicher Bestätigung (Human-in-the-Loop) festlegen. Für die Anbindung von Werkzeugen und Kontext setzt sich mit dem Model Context Protocol (MCP) ein offener Standard durch; er entkoppelt Agenten von einzelnen Anbietern, ersetzt aber die Zugriffskontrolle nicht (siehe Kapitel B9). | Mehrschrittige Agenten handeln kontrolliert. Ohne sie ruft ein Agent unkontrolliert Werkzeuge auf. |
| Schutzschicht | Eingabe- und Ausgabefilter gegen Prompt Injection und Datenabfluss einziehen; warum Filter allein nicht genügen, erklärt Kapitel B9. | Angriffe und Abflüsse über Prompts werden abgefangen. Ohne sie steht die generative Ebene offen. |
Betriebsebene
Stabiler, skalierbarer und zuverlässiger Betrieb produktiver Modelle. Ziel der Ebene: Modelle als verlässliche Dienste bereitstellen und ihren Zustand laufend überwachen.
Bekommt fertige Modelle aus der Entwicklungsebene und Dienste aus der generativen Ebene. Liefert stabil betriebene Dienste an die Integrationsebene und meldet erkannte Drift zurück an die Datenebene, damit Daten und Modelle nachgezogen werden.
| Baustein | Was konkret zu tun ist | Mehrwert, was ohne ihn fehlt |
|---|---|---|
| Bereitstellung als Dienst | Modelle über klare Schnittstellen anbieten, synchron für interaktive Anwendungen und asynchron für Massenverarbeitung. | Modelle sind wiederverwendbar statt fest eingebaut. Ohne sie hängt jedes Modell in genau einer Anwendung fest. |
| Warteschlangen und Auftragssteuerung | Rechenintensive Aufträge wie Training oder Massenauswertung einreihen und gesteuert abarbeiten. | Die interaktive Nutzung bleibt schnell. Ohne sie verdrängen Großaufträge den laufenden Betrieb. |
| Beobachtbarkeit | Metriken, Protokolle und Traces erheben und eine Drift-Erkennung einrichten (Kennzahlen in Kapitel D1). | Störungen und nachlassende Güte fallen früh auf. Ohne sie zeigt sich der Verfall erst an Beschwerden. |
Integrationsebene
Bindet KI in bestehende Geschäftsprozesse und Systeme ein, statt Insellösungen zu schaffen. Ziel der Ebene: KI-Ergebnisse dort ankommen lassen, wo gearbeitet wird. Hier endet der Datenweg.
Bekommt stabil betriebene Dienste aus der Betriebsebene. Liefert KI-Ergebnisse in die Geschäftsprozesse und an alle Nutzerkanäle.
| Baustein | Was konkret zu tun ist | Mehrwert, was ohne ihn fehlt |
|---|---|---|
| Anbindung an Kernsysteme | KI-Dienste mit ERP, CRM, DWH und Kollaborationswerkzeugen verbinden. | Ergebnisse erscheinen im Arbeitsprozess. Ohne sie landen sie in einer separaten Oberfläche, die niemand öffnet. |
| Ereignisorientierte Verarbeitung | Systeme über definierte Verträge koppeln (APIs mit zugesicherten Service Levels). | Änderungen auf einer Seite brechen die andere nicht. Ohne sie reißt jede Systemänderung die Kette. |
| Zugriff aus Produkten, Portalen und mobilen Anwendungen | Dieselben KI-Dienste allen Kanälen bereitstellen, statt sie je Kanal neu zu bauen. | Jeder Kanal nutzt denselben Dienst. Ohne diesen Baustein entsteht je Kanal Doppelarbeit. |
Sicherheitsebene
Querschnitt über alle Ebenen, von der Datenaufnahme bis zur Integration, vertieft in Kapitel B9. Ziel der Ebene: jede andere Ebene absichern, statt Sicherheit nachträglich aufzusetzen.
Gilt für alle Ebenen zugleich; deshalb liegt sie in der Abbildung quer und nicht als eigener Schritt im Datenweg.
| Baustein | Was konkret zu tun ist | Mehrwert, was ohne ihn fehlt |
|---|---|---|
| Schlüssel-, Geheimnis- und Zertifikatsverwaltung | Zugänge zentral verwalten und regelmäßig rotieren. | Kompromittierte Zugänge lassen sich schnell und vollständig austauschen. Ohne sie bleibt ein geleakter Schlüssel unbemerkt gültig. |
| Schutz vor Datenabfluss | Eingabefilter und Inhaltskontrollen einziehen, besonders vor Prompts an externe Modelle. | Vertrauliche Daten verlassen das Haus nicht unbemerkt. Ohne ihn fließen sie über Prompts ab. |
| Trennung von Entwicklungs-, Test- und Produktionsumgebung | Keine echten Kundendaten in der Entwicklung verwenden; Testläufe von Produktivdaten trennen. | Tests können produktive Daten nicht versehentlich beschädigen. Ohne Trennung gefährdet jeder Test echte Daten. |
Vorlage: Architektur-Bestandsaufnahme
Die Bestandsaufnahme führt alle Referenzbausteine in einer Liste zusammen und macht daraus das eigene Zielbild. So wird sie genutzt: Jeden Baustein einmal einstufen als vorhanden, im Aufbau oder bewusst nicht nötig; bei einer Lücke den nächsten Schritt und eine Priorität notieren. Beispiel: Fehlt das Modell-Gateway, sind aber mehrere generative Anwendungsfälle geplant, lautet der Eintrag „im Aufbau" mit Priorität hoch. Das Ergebnis ist eine Lückenliste, die direkt in die Roadmap einfließt.
| Ebene | Baustein | Status (vorhanden / im Aufbau / nicht nötig) | Lücke bzw. nächster Schritt | Priorität |
|---|---|---|---|---|
| Datenebene | Datenquellen-Katalog | |||
| Datenebene | Datenaufnahme | |||
| Datenebene | Datenplattform | |||
| Datenebene | Governance | |||
| Merkmalsebene | Feature Store | |||
| Merkmalsebene | Richtlinien | |||
| Entwicklungsebene | Reproduzierbare, isolierte Umgebungen | |||
| Entwicklungsebene | Paketierung von Artefakten | |||
| Entwicklungsebene | Generative Bausteine | |||
| Generative und agentische Ebene | Modell-Gateway | |||
| Generative und agentische Ebene | RAG-Pipeline | |||
| Generative und agentische Ebene | Prompt- und Kontextverwaltung | |||
| Generative und agentische Ebene | Orchestrierung von Agenten | |||
| Generative und agentische Ebene | Schutzschicht | |||
| Betriebsebene | Bereitstellung als Dienst | |||
| Betriebsebene | Warteschlangen und Auftragssteuerung | |||
| Betriebsebene | Beobachtbarkeit | |||
| Integrationsebene | Anbindung an Kernsysteme | |||
| Integrationsebene | Ereignisorientierte Verarbeitung | |||
| Integrationsebene | Zugriff aus Produkten, Portalen und mobilen Anwendungen | |||
| Sicherheitsebene | Schlüssel-, Geheimnis- und Zertifikatsverwaltung | |||
| Sicherheitsebene | Schutz vor Datenabfluss | |||
| Sicherheitsebene | Trennung von Entwicklungs-, Test- und Produktionsumgebung |
Bereitstellungsmodell: Cloud, On-Premises oder hybrid
Quer zu allen Ebenen steht die Frage, wo die Bausteine laufen. Sie wird je Arbeitslast entschieden, nicht pauschal für das ganze Unternehmen, und hängt von Datensensitivität, Regulatorik, Kosten und vorhandener Betriebskompetenz ab.
| Modell | Stärken | Grenzen | Typischer Einsatz |
|---|---|---|---|
| Public Cloud | Schneller Zugriff auf aktuelle Modelle und GPU-Kapazität, kein Hardware-Invest, elastische Skalierung | Laufende Kosten wachsen mit der Nutzung; Datenstandort- und Übermittlungsfragen (DSGVO, Sektoraufsicht); Anbieterabhängigkeit | Standardfall für Pilotierung und die meisten GenAI-Arbeitslasten mit unkritischen bis vertraulichen Daten |
| On-Premises / private Infrastruktur | Volle Datenhoheit, planbare Kosten bei hoher Dauerlast, keine externen Übermittlungen | Hoher Invest (GPU-Hardware), eigener Betriebs- und Sicherheitsaufwand, langsamerer Zugang zu Modellfortschritt | Streng vertrauliche Daten, Souveränitätsanforderungen, sehr hohe konstante Volumina |
| Hybrid | Arbeitslast läuft dort, wo sie hingehört: sensible Inferenz intern, Skalierungslast in der Cloud | Zwei Betriebswelten, konsistente Sicherheit und Governance über beide nötig | Regulierte Unternehmen mit gemischtem Portfolio; der häufigste Zielzustand |
Drei Praxisregeln:
- Entscheidung je Arbeitslast, nicht je Glaubensrichtung: Ein Unternehmen kann den internen Assistenten aus der Cloud beziehen und das Preismodell auf eigener Infrastruktur rechnen. Das Modell-Gateway (oben) hält diesen Mix steuerbar, weil alle Zugriffe über eine kontrollierte Stelle laufen.
- Ausstieg mitdenken: Cloud-Dienste so anbinden, dass ein Modell- oder Anbieterwechsel die Anwendung nicht neu erfindet (offene Schnittstellen, austauschbare Modellanbindung, eigene Prompts und Evaluationsdaten versioniert im Haus).
- Regulatorik früh einbeziehen: Für Finanz- und Versicherungsunternehmen gelten Auslagerungs- und Drittparteianforderungen (siehe Kapitel B8); der Datenstandort inklusive Sub-Dienstleistern gehört in die Anbieterprüfung.
Vorlage: Architektur-Entscheidungs-Checkliste
Für jeden Anwendungsfall vor dem Bau. Jeder Punkt verhindert einen typischen, teuren Umbau im Nachhinein:
- Prädiktiv oder generativ/agentisch? Bestimmt die genutzten Ebenen; eine falsche Einordnung führt zu unpassenden Metriken und fehlenden Schutzmaßnahmen.
- Wissensweg geklärt: Prompting, RAG oder Fine-Tuning? (siehe Kapitel A2) Verhindert das teuerste Missverständnis: trainieren, wo Prompting genügt hätte.
- Modellbezug entschieden: proprietär über API oder offen im Selbstbetrieb? Bestimmt Kostenmodell, Datenschutz und Abhängigkeit.
- Datenhoheit und Datenschutz geklärt, kein ungewollter Datenabfluss.
- Wiederverwendbare Bausteine genutzt (Feature Store, Prompt-Vorlagen) statt Neubau.
- Integration in Kernsysteme von Anfang an geplant, nicht nachgelagert.
- Beobachtbarkeit von Anfang an vorgesehen, inklusive Drift.
- Schutzschicht gegen Prompt Injection und Datenabfluss eingeplant.
- Kostenzuordnung je Anwendungsfall möglich (siehe Kapitel D2).
Architekturprinzipien (Leitplanken)
Über einzelne Anwendungsfälle hinweg hält eine Handvoll Prinzipien die Architektur konsistent. Sie sind die Leitplanken für jede Bau- und Kaufentscheidung:
- Wiederverwendung vor Neubau: Gemeinsame Plattformbausteine reduzieren Doppelarbeit.
- Nachvollziehbarkeit by Design: Modell- und Datenkarten sowie Protokolle sind Pflicht, nicht Kür.
- Datenhoheit zuerst: Differenzierende Anwendungsfälle werden nicht über fremde Modelle exponiert.
- Sicherheit als Querschnitt: nicht als nachgelagerte Ebene, sondern in jeder Schicht mitgedacht.
Checkliste: Zielbild-Architektur steht
Während die Architektur-Entscheidungs-Checkliste oben je Anwendungsfall geführt wird, prüft diese Liste einmalig das Zielbild des Unternehmens:
- Architektur-Bestandsaufnahme über alle Referenzbausteine ausgefüllt, je Baustein vorhanden, im Aufbau oder bewusst nicht nötig
- Lückenliste priorisiert und in die Roadmap überführt (siehe Kapitel C2)
- Bereitstellungsmodell je Arbeitslast entschieden, nicht pauschal für das ganze Unternehmen
- Ausstieg mitgedacht: offene Schnittstellen, austauschbare Modellanbindung, eigene Prompts und Evaluationsdaten versioniert im Haus
- Auslagerungs- und Drittparteianforderungen geprüft, Datenstandort inklusive Sub-Dienstleistern geklärt
- Architekturprinzipien verabschiedet und für Bau- und Kaufentscheidungen verbindlich gemacht