Auch auf Englisch: Englischer Artikel · Englisches Whitepaper lesen
Meine Empfehlung: Baue Enterprise Architecture für agentische KI als ein gemeinsames Wissens-, Entscheidungs- und Ausführungssystem. Nicht als Sammlung aus Wikis, Architekturdiagrammen und KI-Agenten.
Die entscheidende Frage lautet:
Wie kann ein Unternehmen Wissen so beschreiben, dass Menschen es verstehen, KI-Agenten damit arbeiten und klassische Software daraus zuverlässige, überprüfbare Entscheidungen und Aktionen ableiten kann?
Dafür brauchst du drei Dinge:
- Ein gemeinsames Verständnis der Unternehmenswelt: Was sind Kunden, Verträge, Systeme, Prozesse, Risiken und ihre Beziehungen?
- Eine Entscheidungsarchitektur: Was muss exakt berechnet werden? Wo sind Regeln notwendig? Wo darf KI interpretieren, planen oder Vorschläge entwickeln?
- Eine kontrollierte Ausführungsarchitektur: Wer darf was tun, über welches System, unter welchen Bedingungen und mit welchem Nachweis?
Das verbindet Enterprise Architecture, Business Ontologies, Knowledge Graphs, Glossare, Wikis, deterministische Software und LLM-Agenten.
1. Die Begriffe erklärt: Stell dir dein Unternehmen als Stadt vor
| Baustein | Einfach erklärt | Beispiel |
|---|---|---|
| Enterprise Architecture (EA) | Der Stadtplan: Welche Gebäude, Straßen und Versorgungsnetze gibt es und wie hängen sie zusammen? | Welche Geschäftsprozesse laufen über welche IT-Systeme? |
| Wiki | Das Schulbuch der Stadt. | Wie funktioniert die Schadenbearbeitung? |
| Business Glossary | Das Wörterbuch. | Was bedeutet „Großschaden“? |
| Taxonomie | Die geordnete Schubladensammlung. | Schaden → Naturschaden → Sturm |
| Business Ontology | Die gemeinsamen Spielregeln, welche Dinge existieren und wie sie zusammenhängen. | Ein Vertrag deckt Risiken ab. Ein Schaden betrifft einen Vertrag. |
| Knowledge Graph | Das Netz mit den tatsächlich bekannten Dingen und ihren Verbindungen. | Sturm X betrifft Vertrag Y und Kunde Z. |
| Decision Model | Das Regelbuch für Entscheidungen. | Welche Bedingungen müssen für eine Auszahlung erfüllt sein? |
| KI-Agent | Ein intelligenter Mitarbeiter, der Informationen interpretiert und nächste Schritte plant. | Prüfe einen komplizierten Schadenfall. |
| Deterministischer Code | Die zuverlässige Rechenmaschine: Gleiche Eingaben und gleicher Zustand ergeben dasselbe Ergebnis. | Berechne Selbstbehalt und Auszahlung. |
Wichtig: Eine Ontologie ist mehr als ein Glossar. Sie beschreibt nicht nur Wörter, sondern auch Beziehungen und Bedeutungen, die von Maschinen verarbeitet werden können. Dafür gibt es etablierte Standards mit unterschiedlichen Aufgaben: SKOS für strukturierte Begriffssysteme, OWL für formale Ontologien und SHACL für die Prüfung von RDF-Daten gegen definierte Bedingungen.
2. Warum die Ontologie der Schlüssel sein kann
Nehmen wir ein vereinfachtes Beispiel aus der Rückversicherung.
Beispiel einer Business Ontology
Vereinfachtes, illustratives Fachmodell. Die beschrifteten Verbindungen sind genauso wichtig wie die Objekte.
| Objekt | Beziehung | Objekt |
|---|---|---|
| Ereignis | verursacht | Schaden |
| Schaden | betrifft | Vertrag |
| Vertrag | enthält | Deckung |
| Deckung | bezieht sich auf | Risiko |
Das ist eine vereinfachte Sicht auf fachliche Beziehungen, kein vollständiges Rückversicherungsmodell.
Damit können Mensch und Maschine dieselbe Frage beantworten:
„Welche offenen Schäden betreffen Verträge, die ein besonders hohes Naturkatastrophenrisiko tragen?“
Ein LLM müsste nicht erst fünf Systeme und 100 Dokumente interpretieren, um zu verstehen, was ein Vertrag oder ein Risiko ist. Es könnte über die Ontologie die relevanten Objekte und Verknüpfungen gezielt abrufen.
Aber: Die Ontologie enthält zunächst das Modell, nicht automatisch korrekte Echtzeitdaten. Dafür braucht sie Verbindungen zu den führenden Systemen, Datenqualität, Zeitbezug und Zugriffsrechte.
3. Die drei unterschiedlichen Entscheidungsmechanismen
Das ist für agentische Infrastrukturen besonders wichtig.
A. Deterministische Logik
Wenn eine Antwort eindeutig berechnet werden kann, nimm klassische Software: SQL, Python, Java, Rules Engines oder DMN.
Beispiel: „Berechne die maximal zulässige Entschädigung anhand von Vertrag, Deckung und Selbstbehalt.“
B. LLM-basierte Interpretation
Wenn eine Aufgabe Sprache, unscharfe Informationen oder flexible Planung benötigt, kann ein Agent helfen.
Beispiel: „Lies diesen Schadenbericht, finde widersprüchliche Angaben und schlage Untersuchungen vor.“
Das Ergebnis ist zunächst eine Hypothese, keine geprüfte Tatsache.
C. Kontrollierte Entscheidungen und Aktionen
Hier geht es darum, ob eine vorgeschlagene Handlung tatsächlich erlaubt ist.
Beispiel: „Darf dieser Agent eine Auszahlung auslösen oder muss ein Mensch freigeben?“
Eine Policy Engine überprüft Befugnisse und Bedingungen. Die tatsächliche Aktion erfolgt über einen kontrollierten Dienst.
DMN ist ein etablierter Standard für formale Geschäftsentscheidungen; Open Policy Agent (OPA) ist beispielsweise eine Engine zur Auswertung ausführbarer Policies. Die Durchsetzung übernimmt das aufrufende System.
Und was sind Type-1-Entscheidungen nach Jeff Bezos?
Jeff Bezos unterscheidet in seinem Aktionärsbrief von 2015 zwischen schwer umkehrbaren Type-1-Entscheidungen und gut reversiblen Type-2-Entscheidungen.
Das ist eine andere Dimension als die Frage, ob eine Entscheidung von KI oder klassischem Code vorbereitet wird.
| Type 2: Reversibel | Type 1: Schwer umkehrbar | |
|---|---|---|
| LLM | Berichtsentwurf erstellen | Kritische Entscheidung vorbereiten, aber nicht eigenmächtig ausführen |
| Deterministisch | Berechnung wiederholen | Berechnung und verbindliche Kontrollen durchführen |
| Freigabe | Unter definierten Grenzen automatisierbar | Formale Autorisierung entsprechend Tragweite und Risiko |
Ein Agent kann also durchaus bei Type-1-Entscheidungen mitarbeiten. Er sollte aber nicht automatisch die Entscheidungsbefugnis besitzen.
4. Wie die komplette Hybridarchitektur zusammenarbeitet
Referenzarchitektur · vereinfacht
Die folgende Übersicht zeigt logische Verantwortlichkeiten, keine festgelegte technische Deployment-Struktur.
| Ebene | Bausteine | Leitfrage oder Aufgabe |
|---|---|---|
| Menschen, Business-Prozesse, Anwendungen und Events | Ziele und Auslöser | Was soll erreicht werden? |
| Enterprise Knowledge Fabric | EA-Modelle, Business Glossaries, Wikis, Ontologien, Knowledge Graphs, Datenkataloge | Was wissen wir? Was bedeutet es? Woher kommt es? |
| Decision & Orchestration Layer | Auswahl und Koordination der Entscheidungsmechanismen | Welche Entscheidung ist nötig? Welche Methode ist geeignet? Wie riskant ist die Aktion? |
| LLM-Agenten · Rules / DMN · Code / APIs | Verstehen, planen, interpretieren · Regeln und Entscheidungen auswerten · Rechnen und definierte Funktionen ausführen | Den geeigneten Mechanismus für die jeweilige Aufgabe einsetzen |
| Runtime Policy & Action Gateway | Identität, Berechtigung, Validierung, Freigabe, Audit | Darf die konkrete Aktion ausgeführt werden? |
| Enterprise Systems | On-Prem, Cloud, Mainframe, Datenbanken, Fachanwendungen, externe Dienste | Autorisierte Aktionen ausführen und Ergebnisse zurückmelden |
Querschnittlich erforderlich: Security, Data Governance, Lineage, Versionierung, Observability und Lifecycle Management.
Diese Kombination aus semantischer Modellierung, Logik, kontrollierten Aktionen und Sicherheit findet sich beispielsweise auch in der Ontologiearchitektur von Palantir. AWS trennt bei agentischen Enterprise-Architekturen ebenfalls Modelle, Tools, Wissensquellen und übergreifende Kontrollen.
MCP gehört hier zur Integrationsschicht, über die Ressourcen und ausführbare Werkzeuge bereitgestellt werden können. MCP definiert aber weder deine Unternehmensontologie noch deine fachlichen Berechtigungsregeln.
5. Ein konkreter Vorgang von Anfang bis Ende
Ein fiktiver Rückversicherer erhält einen komplexen Schadenbericht.
- Ein LLM liest den Bericht und erkennt einen potenziellen Sturm-Großschaden.
- Die Business Ontology hilft, „Schaden“, „Ereignis“, „Vertrag“ und „Deckung“ korrekt miteinander zu verknüpfen.
- Der Knowledge Graph liefert die zugehörigen Verträge, Risiken und bestehenden Schadenfälle.
- Deterministischer Code berechnet Deckungsgrenzen und Selbstbehalte. Fachliche Regeln prüfen die Voraussetzungen.
- Der Agent bewertet unklare Sachverhalte, sammelt Belege und erstellt einen begründeten Vorschlag.
- Die Entscheidungsarchitektur prüft, ob eine Freigabe erforderlich ist. Das Action Gateway erlaubt nur autorisierte Aktionen.
- Jede Entscheidung erhält einen überprüfbaren Nachweis: verwendete Fakten, Quellen, Modellversion, Regelversion, Freigabe und Ergebnis.
Der große Vorteil: Die KI muss nicht alles selbst entscheiden. Sie nutzt verlässliche Komponenten und konzentriert sich auf die Teile, bei denen flexible Interpretation tatsächlich einen Mehrwert liefert.
6. Die drei wichtigsten Architekturentscheidungen
Erstens: Nicht eine riesige Ontologie für das ganze Unternehmen bauen. Besser sind kleinere, verantwortete Ontologien je Business Domain, etwa Vertrag, Schaden, Risiko, Identität und IT-Architektur. Diese verbindet man über gemeinsame Identifikatoren und definierte Beziehungen. Die EA liefert die übergreifende Sicht.
Zweitens: Dokumentiertes Wissen ist nicht automatisch gültiges Wissen. Ein Wiki kann veraltet sein, eine Graph-Beziehung falsch und eine KI-Antwort plausibel, aber unbelegt. Deshalb muss jedes relevante Wissensobjekt eine Quelle, einen Verantwortlichen, einen Gültigkeitszeitraum und gegebenenfalls einen Freigabestatus haben.
Drittens: Ein Agent darf niemals allein deshalb etwas tun, weil er eine Aktion sinnvoll findet. Die Entscheidung über Zulässigkeit muss zur Laufzeit außerhalb des LLM durchgesetzt werden. Auch formal korrekte Daten garantieren nicht, dass eine geschäftliche Entscheidung richtig ist.
7. Was ich als Enterprise Architect zuerst bauen würde
Nicht eine neue große Plattform. Einen kleinen, vollständigen vertikalen Anwendungsfall:
- Eine Business Domain mit 10–20 klar definierten Geschäftsobjekten.
- Eine Ontologie mit Beziehungen zu echten Daten und relevanten Wiki-Inhalten.
- Drei exemplarische Entscheidungen: eine deterministische, eine LLM-gestützte und eine Type-1-Freigabe.
- Einen kontrollierten Ausführungsweg über bestehende APIs.
- Eine lückenlose Entscheidungshistorie einschließlich Quellen, Regeln und Berechtigungen.
So prüfst du gleichzeitig, ob Ontologie, Enterprise Architecture, Wissensmanagement und agentische KI wirklich zusammen funktionieren.
Meine zentrale These: Die Enterprise Architecture der Zukunft beschreibt nicht mehr nur, wie ein Unternehmen aufgebaut ist, sondern zunehmend auch, was seine digitalen und menschlichen Akteure wissen, entscheiden und tun dürfen.
Die Ontologie liefert die gemeinsame Bedeutung. Die Entscheidungsarchitektur ordnet die Verantwortung. Die Hybridinfrastruktur verbindet probabilistische Intelligenz mit deterministischer Verlässlichkeit.
Whitepaper online lesen · PDF herunterladen · Newsletter abonnieren
Die überarbeitete Fassung 4.2 „Agentische KI im Unternehmen gestalten“ umfasst 20 Seiten. Sie erklärt Wissensmodell, Entscheidungsmechanismen und den Entwurf einer agentischen Laufzeit, ergänzt um Schaubilder, drei markierte Praxisanleitungen, erwartete Architekturartefakte und ein Fazit. Die beschriebene Laufzeit ist ein konzeptioneller Referenzentwurf; sie wurde nicht implementiert oder experimentell validiert.