KI-Architektur
Wie Systeme im KI-Zeitalter zusammenspielen
KI-Systeme verbinden sich, rufen Tools auf, handeln. Die Frage ist nicht nur, welche Daten fließen — sondern wie ihr Systeme zusammenbringt, ohne die Kontrolle zu verlieren.
Diese Seite zeigt das Set der Möglichkeiten: vier Ebenen, auf denen ihr entscheidet — und wo die Entscheidungen konkret anstehen. Wer zuerst die Datenfragen klären will, startet bei der AI Data Strategy.
Warum Architektur hier anders ist
Klassische Systemarchitektur reicht nicht mehr
Bisher plante man Systeme für Menschen: Screens, Workflows, Berechtigungen. KI-Systeme handeln selbstständig — sie lesen, entscheiden und lösen aus. Damit wird die Architekturfrage zur Kontrollfrage: Wer verbindet was womit, wer steuert die Abläufe, wo läuft es, und was ist technisch durchgesetzt?
Die Antwort ist selten eine Plattform. Sie ist ein Set von Entscheidungen auf vier Ebenen — Verbindung, Steuerung, Plattform und Kontrolle. Die folgenden Abschnitte zeigen die Optionen, nicht die eine richtige Lösung.
Ebene 1 · Verbindung
Wie kommen Systeme aneinander?
Die Basis jeder KI-Architektur: über welche Schnittstelle sprechen Modelle, Agenten und Tools mit euren Systemen?
Punkt-zu-Punkt-Integrationen
Jedes System spricht direkt mit jedem anderen. Bei wenigen Systemen mit stabilen Schnittstellen die einfachste Lösung.
- Passt, wenn
- Wenige Systeme, stabile Schnittstellen, kein Skalierungsziel für Agenten.
- Eher nicht, wenn
- Jede neue Anbindung ist Eigenbau — aus kleinen Inseln wird ein M×N-Geflecht.
Protokoll-basiert (MCP)
Ein gemeinsames Protokoll statt vieler Direktverbindungen. Tools werden als natürliche Sprache beschrieben, Agenten laden die Definitionen bei Bedarf.
- Passt, wenn
- Sobald Agenten auf bestehende Systeme zugreifen sollen — heute der de-facto-Standard.
- Eher nicht, wenn
- Kaum relevant, solange nur ein System angebunden werden muss.
API-First für Agenten
Systeme werden agentenlesbar gebaut: saubere, dokumentierte APIs statt Websites und UIs als Schnittstelle.
- Passt, wenn
- Neue Systeme, oder wenn Agenten vollständig autonom arbeiten sollen.
- Eher nicht, wenn
- Für Systeme, die nur von Menschen bedient werden — dort reicht eine UI.
Natürliche Sprache als Integrationsschicht
Sprache wird die neue API: Systeme werden über natürliche Sprache angesprochen statt über formale Schnittstellen.
- Passt, wenn
- Als Ergänzung für offene, unstrukturierte Interaktion.
- Eher nicht, wenn
- Wo es auf Präzision ankommt — Sprache ist bekannt unpräzise und braucht Governance-Grenzen.
Ebene 2 · Steuerung
Wer koordiniert die Abläufe?
Sobald mehrere Systeme zusammenarbeiten, entscheidet sich, wer wann was anstößt — eine Engine, wenige Agenten, oder Menschen dazwischen.
Zentraler Orchestrator
Eine Engine steuert mehrstufige, fokussierte Prozesse. Die Orchestrierung ist der Werttreiber — nicht die Modellwahl.
- Passt, wenn
- Klar definierte Geschäftsprozesse über Systemgrenzen. Für die meisten Enterprise-Use-Cases.
- Eher nicht, wenn
- Offene, explorative Aufgaben ohne festen Ablauf.
Wenige, gut gemanagte Agenten
Zwei bis drei Agenten mit tiefer menschlicher Beteiligung statt vieler paralleler Agenten.
- Passt, wenn
- Wenn Qualität und Kontrolle wichtiger sind als Durchsatz.
- Eher nicht, wenn
- Vieler-Agenten-Demos ohne Test-Harness — das ist meist Theater, keine Architektur.
Parallel oder seriell
Parallel maximiert den Durchsatz, seriell minimiert die Gesamtarbeit. Eine bewusste Wahl nach Zeit- und Kostenpriorität.
- Passt, wenn
- Parallel bei unabhängigen Teilaufgaben, seriell bei abhängigen Schritten.
- Eher nicht, wenn
- Parallel ohne Merge- und Test-Strategie — Konflikte und Kontrollverlust.
Mensch-in-der-Schleife
Menschen steuern Agenten-Teams wie Mitarbeiter-Teams: Grenzen und Kontrollpunkte definieren, Ergebnisse synthetisieren.
- Passt, wenn
- Immer dort, wo Entscheidungen Konsequenzen haben — Orchestrierung wird Führungsaufgabe.
- Eher nicht, wenn
- Reine Massenaufgaben, bei denen Autonomie sicher beherrschbar ist.
Ebene 3 · Plattform
Wo läuft das Zusammenspiel?
Die Plattformfrage ist nicht „welches Tool“ — sondern wie zentral oder offen ihr Betrieb, Lizenzen, Sicherheit und Kontext organisiert.
Zentral, dezentrale Anwendung
Die Plattform stellt Tools, Lizenzen und Sicherheit zentral; Teams bleiben experimentierfreudig.
- Passt, wenn
- Sicherheit und Governance zentral, ohne Kreativität zu ersticken.
- Eher nicht, wenn
- Wenn die Plattform zum Flaschenhals wird und Delivery ausbremst.
Hybride Agenten-Architektur
Modellagnostisch, wahlweise Cloud-Service oder selbst gehostet, mit Community-getriebener Skill-Bibliothek.
- Passt, wenn
- Wenn Flexibilität und Wahlfreiheit bei Modellen wichtig sind.
- Eher nicht, wenn
- Wenn ein einheitlicher, kontrollierter Betrieb Vorrang hat.
Ökosystem-Ansatz
Protokolle allein reichen nicht: Discovery, Identität und Governance werden als Ökosystem-Standards gedacht.
- Passt, wenn
- Wenn Agenten über Organisationsgrenzen hinweg zusammenarbeiten sollen.
- Eher nicht, wenn
- Für den ersten internen Piloten — zu viel Standardisierungsaufwand.
Plattform mit Kontext-Ebene
Agenten brauchen Unternehmenskontext, Berechtigungen und kontinuierliche Evaluation — die Plattform liefert das.
- Passt, wenn
- Wenn Kontextlücken der Flaschenhals sind (und nicht die Modelle).
- Eher nicht, wenn
- Wenn Kontext noch gar nicht erschlossen ist — dann zuerst die Datenfragen klären.
Ebene 4 · Kontrolle
Wie bleibt es sicher und geordnet?
Kontrolle ist die Ebene, die entscheidet, ob Skalierung gelingt. Drei Grundmuster — und drei Instrumente, die Kontrolle konkret machen.
Sandbox-Ausführung
KI-Logik und Tool-Ausführung sind getrennt; sensible Operationen laufen in kontrollierter Umgebung, standardisiert protokolliert.
Datenzonen
Klare Trennung: sensible Daten lokal oder in der EU, nicht-sensible in der Cloud; Pseudonymisierung als Brücke.
Automatisierte Kontrollen
Datenzugriff mit durchgesetzten Regeln — wer darf ein Agent womit — und Kontrollen als Teil des Systems, nicht als nachgelagerter Review.
AI Solution Catalog
Der Katalog ist der Kontrollpunkt für AI Assets: Er macht sichtbar, was läuft, wer es besitzt, welche Daten es nutzt, welches Risiko es trägt und ob es weiter betrieben werden darf. Ein Katalog ist mehr als eine Toolliste.
Wichtig zur Einordnung: Die AI Registry trägt Business-Kontext, Risiko und Governance über alle AI-Systeme. Die Model Registry versioniert Modelle. Der Data Catalog beschreibt Datenbestände und Lineage — drei verschiedene Werkzeuge, drei verschiedene Fragen.
Lifecycle und Runtime Governance
AI-Systeme verändern sich im Betrieb: Daten driften, Nutzung wandelt sich, Modelle und Agenten handeln in neuen Kontexten. Deshalb endet Governance nicht beim Go-live.
01
Assess
02
Select
03
Build
04
Validate
05
Deploy
06
Monitor
07
Change
08
Retire
Runtime Governance heißt: Policies werden nicht nur dokumentiert, sondern zur Laufzeit geprüft. Bei Agents bedeutet das — Input, Kontext, Tool Calls, Output, Human Escalation, Logging und Audit Evidence müssen zusammen gedacht werden.
Wo Entscheidungen anstehen
Fünf Fragen, die jede Organisation beantworten muss
Die Ebenen zeigen Optionen. Diese Fragen machen sie konkret — und sie sind die Grundlage für jede Tool-Entscheidung danach.
- Welche Verbindungsform für welche Systeme?
- Wer steuert: Mensch, Engine oder beides?
- Wie viel Autonomie erlauben wir — und wo?
- Zentral, hybrid oder Ökosystem?
- Was muss technisch kontrolliert sein, bevor der nächste Agent dazukommt?
Typische Lücken
Vier Warnbilder, die Skalierung verhindern
Diese Muster wiederholen sich in Organisationen, die an der Architektur scheitern — nicht an den Modellen.
Isolierte Inseln
Gute Demos, keine Skalierung: Jede Lösung ist eigenständig entstanden, ohne gemeinsame Foundations.
M×N-Geflecht
Jede Integration ist Eigenbau: Ohne Protokoll-Standard wächst die Verbindungsanzahl mit jedem System.
Theater-Skalierung
Viele Agenten nebeneinander ohne Test-Harness: Sieht nach Fortschritt aus, erzeugt aber Kontrollverlust.
Nachgelagerte Kontrolle
Governance als Bürokratie statt Architektur-Prinzip: Regeln sind erbeten, nicht technisch durchgesetzt.
Vertiefende Spezialgebiete
Wo ihr weiter eintauchen könnt
Diese Seite ist die Landkarte. Jede Ebene hat ein Spezialgebiet, das sie im Detail ausleuchtet.
MCP und Datenwege
Wie GenAI mit Daten arbeitet — die fünf Wege von LLM-Aufrufen bis Agenten.
Weiterlesen →Agentic AI
Warum handelnde KI-Systeme Zugriff, Kontext, Tools und Runtime-Governance brauchen.
Weiterlesen →AI Data Platforms
Databricks, Snowflake und Fabric als unterschiedliche Antworten auf Betrieb und Governance.
Weiterlesen →Security & Sandbox
Wie KI-Systeme sicher betrieben werden — von Zugriffskontrolle bis Monitoring.
Weiterlesen →Data Governance & KI
Welche Governance-Fragen entstehen, wenn Daten Training, Kontext, Feedback und Risiko werden.
Weiterlesen →Hören, ansehen, weiterlesen
Quellen, die die Kontroll-Ebene vertiefen
Jede Quelle beantwortet eine andere Frage: Katalog, Runtime Governance und Lifecycle.
From AI Governance to AI Enablement
DataFramed · 53 minGovernance & Enablement
The New Paradigm for Enterprise AI Governance
DataFramed · 59 minEnterprise Governance
Atlan: What Is an AI Registry?
Konkretisiert, welche Felder ein AI Registry braucht und warum Spreadsheet-Inventare nicht reichen.
Quelle öffnen →Microsoft: Agent Control Specification
Zeigt, wie Runtime Governance für Agents über Interception Points, Policy Inputs und Enforcement funktionieren kann.
Quelle öffnen →ISACA: Governing AI Across its Lifecycle
Macht Lifecycle Governance als Stufenmodell von Strategie bis Retirement greifbar.
Quelle öffnen →Zurück zur Orientierung
Erst die Datenfragen, dann die Architektur
Bevor über Verbindungsformen und Plattformen entschieden wird, lohnt der Check auf der Datenseite: Können KI-Systeme eure Daten erreichen? Verstehen sie, was sie bedeuten? Ist der Stand aktuell? Und wer darf was — durchgesetzt statt erbeten?
Zum Daten-Hub: die vier Datenfragen →