„Bereite die nächste sinnvolle Aktion für Kunde X vor." Eine einfache Anfrage an einen KI-Assistenten. Was passiert damit, hängt davon ab, was das System über das Unternehmen weiß.
Ohne Geschäftskontext durchsucht das Sprachmodell CRM-Notizen und die letzten Datensätze. Es findet Text, fasst ihn zusammen und schlägt etwas vor, das plausibel klingt. Mit einer Ontologie weiß das System, dass Kunde X Teil eines Konzerns ist, dass zwei Opportunities offen sind, ein Angebot seit drei Wochen ohne Antwort ist, eine Rechnung überfällig ist, ein Servicefall eskaliert wurde und wer im eigenen Haus für diesen Kunden verantwortlich ist. Es kann über die Situation nachdenken, statt nur Text abzurufen.
Die meisten Unternehmen haben kein Datenproblem. Sie haben ein Kontextproblem. KI kann auf Datensätze, Dokumente und APIs zugreifen. Sie versteht aber nicht automatisch, was diese Dinge im Unternehmen bedeuten. Genau diese Lücke schließt eine Ontologie.
Das Problem ist nicht der Zugriff, sondern die Bedeutung
In den vergangenen Jahren haben viele Unternehmen erheblich in Datenzugang investiert. APIs wurden gebaut, Integrationsplattformen eingeführt, Data Lakes und Lakehouses befüllt. Ein Sprachmodell kann heute auf fast alles zugreifen, was im Unternehmen digital vorliegt. Das ist die Grundlage, aber nicht die Lösung.
Ein Datensatz im CRM heißt „Account". Ein Datensatz im ERP heißt „Debitor". Ein Datensatz im Ticketsystem heißt „Organisation". Alle drei meinen in vielen Fällen denselben Kunden, in manchen Fällen aber nicht. Der Status „offen" bedeutet im Vertrieb etwas anderes als im Service. Ein „Projekt" ist in der Projektsoftware ein Container für Aufgaben, in der Finanzbuchhaltung ein Kostenträger und im Vertrieb ein gewonnener Deal.
Menschen kennen diese Unterschiede, weil sie das Unternehmen kennen. Ein Modell kennt sie nicht. Es sieht Felder, Tabellen und Texte. Wenn niemand ihm sagt, wie diese Dinge zusammenhängen, rät es. Und in vielen Fällen rät es überzeugend falsch. Wie schnell ein Agent dabei den falschen Kunden erwischt, haben wir an anderer Stelle beschrieben.
Was eine Ontologie ist, und was nicht
Der Begriff klingt akademisch, die Sache ist praktisch. Eine Ontologie ist eine explizite Beschreibung der Dinge, die im Unternehmen eine Rolle spielen, ihrer Beziehungen zueinander und der Regeln, die für sie gelten. Sie beantwortet Fragen, die Menschen im Unternehmen intuitiv beantworten, ein System aber nicht.
| Ebene | Frage, die beantwortet wird | Beispiel |
|---|---|---|
| Geschäftsobjekte | Welche Dinge gibt es, und was bedeuten sie? | Kunde, Konzern, Opportunity, Angebot, Auftrag, Rechnung, Servicefall, Mitarbeiter |
| Beziehungen | Wie hängen diese Dinge zusammen? | Ein Kunde gehört zu einem Konzern. Ein Angebot gehört zu einer Opportunity. Ein Servicefall betrifft einen Auftrag. |
| Zustände und Regeln | Was gilt in welcher Situation? | Eine Rechnung ist überfällig, wenn das Zahlungsziel überschritten ist. Ein Angebot ohne Reaktion nach 14 Tagen gilt als gefährdet. |
| Berechtigungen und Aktionen | Wer darf was sehen und tun? | Ein Vertriebsmitarbeiter sieht Konditionen seines Kunden, nicht die aller Kunden. Ein Rabatt über zehn Prozent braucht eine Freigabe. |
| Herkunft | Wo liegt die Wahrheit für welches Objekt? | Adressen kommen aus dem ERP, Kontakte aus dem CRM, Tickets aus dem Servicesystem. |
Was eine Ontologie nicht ist: Sie ist kein weiteres Data Warehouse, kein Datenkatalog und kein Ersatz für die Integrationsplattform. Sie kopiert keine Daten. Sie beschreibt, was die Daten in den bestehenden Systemen bedeuten und wie sie zusammenhängen. Die Daten bleiben, wo sie sind. Die Bedeutung wird explizit.
Integration verbindet Systeme. Ontologie verbindet Bedeutung.
Eine klassische Integration sorgt dafür, dass ein neuer Kunde aus dem CRM im ERP angelegt wird, dass Rechnungen zurück ins CRM fließen und dass ein Ticket die Kundennummer trägt. Das ist notwendig und wertvoll. Aber es beantwortet nur die Frage, wie Daten von A nach B kommen. Es beantwortet nicht die Frage, was ein Kunde ist.
Für Menschen reicht das, weil sie die Bedeutung mitbringen. Für ein KI-System reicht es nicht. Wenn ein Agent die Frage „Welche Kunden sind gefährdet?" beantworten soll, braucht er eine Definition von „gefährdet", die über Systeme hinweg gilt. Diese Definition steht in keinem der Systeme. Sie steht, wenn überhaupt, in den Köpfen der Mitarbeiter oder in einer Prozessbeschreibung, die niemand mehr liest.
Traditionelle Integration verbindet Systeme. Eine Ontologie verbindet Bedeutung. Beides zusammen macht Unternehmensdaten für KI verwendbar.
Die Ontologie ist damit die Schicht, die über der Integration liegt. Die Integration liefert die Daten. Die Ontologie sagt, was sie bedeuten und wie sie sich zu einem Bild zusammensetzen. Ohne Integration hat die Ontologie nichts zu beschreiben. Ohne Ontologie weiß die KI nicht, was sie mit dem Beschriebenen anfangen soll.
Warum Agenten diese Schicht brauchen
Bei einem Chatbot, der Fragen zu Dokumenten beantwortet, fällt fehlender Kontext kaum auf. Das System sucht relevante Textstellen und formuliert eine Antwort. Bei einem Agenten, der im Unternehmen handeln soll, wird fehlender Kontext zum Risiko.
Ein Agent muss entscheiden, welches Tool er aufruft, mit welchen Parametern, in welcher Reihenfolge und wann er aufhört. Dafür muss er verstehen, in welcher Situation er sich befindet. „Kunde hat eine überfällige Rechnung und einen eskalierten Servicefall" ist eine andere Situation als „Kunde hat eine offene Opportunity und ein unbeantwortetes Angebot". Im ersten Fall ist ein Verkaufsanruf unangebracht. Im zweiten ist er überfällig. Ein Agent, der nur Datensätze sieht, kann diesen Unterschied nicht erkennen. Ein Agent, der die Ontologie kennt, kann es.
Die Ontologie liefert dem Agenten außerdem die Grenzen seines Handelns. Welche Aktionen gibt es überhaupt? Welche davon sind in diesem Zustand erlaubt? Welche brauchen eine Freigabe? Diese Informationen in den Prompt zu schreiben, funktioniert für einen Agenten mit drei Tools. Für ein Unternehmen mit dreißig Agenten, die auf dieselben Systeme zugreifen, braucht es eine gemeinsame Schicht, die diese Regeln einmal beschreibt und für alle verbindlich macht. Der Schritt von RAG zu Agentic RAG ist genau dieser Übergang vom Abrufen zum Handeln, und er funktioniert nur mit Kontext.
Wie eine Ontologie entsteht: nicht als Großprojekt
Der häufigste Grund, warum Ontologie-Vorhaben scheitern, ist der Anspruch, das ganze Unternehmen auf einmal zu modellieren. Das dauert Jahre, und am Ende stimmt das Modell nicht mehr mit dem Unternehmen überein. Der bessere Weg ist der umgekehrte: Man beginnt mit einem Prozess und den Objekten, die dieser Prozess braucht.
| Schritt | Was passiert | Ergebnis |
|---|---|---|
| Prozess auswählen | Ein konkreter Anwendungsfall, etwa Kundenbetreuung im Key-Account-Management | Klarer Rahmen, meist zehn bis zwanzig Objekte |
| Objekte und Beziehungen benennen | Fachbereich und IT definieren gemeinsam, was ein Kunde, ein Angebot, ein Fall ist und wie sie zusammenhängen | Gemeinsames Vokabular, das beide Seiten tragen |
| Quellen zuordnen | Für jedes Objekt wird festgelegt, welches System die Wahrheit hält | Keine Doppeldefinitionen, klare Herkunft |
| Regeln und Zustände ergänzen | Was bedeutet „gefährdet", „überfällig", „strategisch"? | Begriffe, die Agenten auswerten können |
| Berechtigungen abbilden | Wer darf welche Objekte sehen und welche Aktionen auslösen? | Grundlage für sicheren Agentenzugriff |
| Mit dem ersten Agenten testen | Der Agent arbeitet gegen die Ontologie, nicht gegen rohe Tabellen | Sichtbar, wo das Modell noch Lücken hat |
Aus dem ersten Prozess entsteht ein Kern, der mit jedem weiteren Anwendungsfall wächst. Die Objekte „Kunde" und „Auftrag" werden beim zweiten Prozess wiederverwendet, nicht neu erfunden. Nach drei oder vier Prozessen deckt die Ontologie einen großen Teil dessen ab, was Agenten im Unternehmen brauchen. Und sie bleibt aktuell, weil sie an echten Anwendungsfällen hängt.
Wichtig ist die Rollenverteilung. Die Ontologie gehört nicht der IT allein. Was ein strategischer Kunde ist, entscheidet der Vertrieb. Wann ein Fall als eskaliert gilt, entscheidet der Service. Die IT sorgt dafür, dass diese Definitionen technisch abgebildet und mit den Quellsystemen verbunden werden. Eine Ontologie, die nur von einer Seite gepflegt wird, verliert entweder den Bezug zum Geschäft oder zur Technik.
Wo die Ontologie in der Architektur lebt
Technisch ist eine Ontologie eine semantische Schicht, die zwischen den Unternehmenssystemen und den KI-Komponenten sitzt. Sie greift über die Integrationsplattform auf die Quellsysteme zu und stellt Agenten eine einheitliche Sicht zur Verfügung: Objekte statt Tabellen, Beziehungen statt Fremdschlüssel, Zustände statt Statuscodes.
Für die Umsetzung gibt es verschiedene Wege, von Graph-Datenbanken über semantische Schichten auf einer Datenplattform bis zu einer Sammlung gut beschriebener APIs, die Objekte und ihre Beziehungen liefern. Welcher Weg passt, hängt von der bestehenden Landschaft ab. Wer bereits eine API-geführte Integrationsarchitektur betreibt, kann die Ontologie als Schicht darüber aufbauen. Wer auf offene Tabellenformate als Integrationsschicht setzt, kann die semantischen Definitionen dort verankern.
Entscheidend ist weniger die Technologie als drei Eigenschaften. Erstens: Die Ontologie ist maschinenlesbar, sodass Agenten sie zur Laufzeit nutzen können, statt dass jemand sie in Prompts abschreibt. Zweitens: Sie ist für Agenten über standardisierte Schnittstellen erreichbar, etwa als Tools mit klarer Beschreibung, wie es MCP für Enterprise-APIs vorsieht. Drittens: Sie trägt die Berechtigungen mit, sodass ein Agent nicht nur weiß, was ein Objekt ist, sondern auch, ob er es im aktuellen Kontext sehen darf.
Was nicht funktioniert, ist der Versuch, Kontext allein über den Prompt zu liefern. Ein System-Prompt mit zwanzig Seiten Erklärungen zum Unternehmen ist teuer, langsam, schwer zu pflegen und wird vom Modell nicht zuverlässig beachtet. Kontext gehört in die Architektur, nicht in den Text.
Was vor dem Start geklärt sein sollte
Bevor ein Unternehmen mit einer Ontologie beginnt, lohnt es sich, diese Fragen zu beantworten:
| Bereich | Leitfrage |
|---|---|
| Anwendungsfall | Welcher Prozess soll als Erstes von Kontext profitieren, und welche Entscheidung soll ein Agent dort besser treffen? |
| Objekte | Welche zehn bis zwanzig Dinge braucht dieser Prozess, und wie heißen sie in den verschiedenen Systemen? |
| Wahrheit | Welches System ist für welches Objekt führend, und wo gibt es heute Widersprüche? |
| Regeln | Welche Begriffe, die der Fachbereich täglich verwendet, haben keine formale Definition? |
| Verantwortung | Wer pflegt die Definitionen fachlich, und wer setzt sie technisch um? |
| Zugriff | Wie erreichen Agenten die Ontologie, und wie werden Berechtigungen dabei durchgesetzt? |
| Wachstum | Wie werden neue Objekte und Prozesse ergänzt, ohne das Bestehende zu brechen? |
Die Antworten müssen nicht perfekt sein. Sie müssen gut genug sein, um mit dem ersten Prozess zu beginnen. Alles Weitere ergibt sich aus der Nutzung.
Fazit
Die Diskussion über Enterprise AI dreht sich oft um Modelle: Welches ist das beste, welches das günstigste, welches darf im eigenen Rechenzentrum laufen? Diese Fragen sind berechtigt. Aber sie verdecken, woran die meisten Vorhaben tatsächlich scheitern. Nicht am Modell, sondern daran, dass das Modell das Unternehmen nicht versteht. Dass saubere Daten wichtiger sind als das beste Modell, haben wir bereits gezeigt. Kontext ist der nächste Schritt nach sauberen Daten.
Eine Ontologie ist die Schicht, die Daten in Bedeutung übersetzt. Sie macht aus Tabellen Geschäftsobjekte, aus Fremdschlüsseln Beziehungen und aus Statuscodes Situationen, über die ein Agent nachdenken kann. Sie entsteht nicht in einem Großprojekt, sondern Prozess für Prozess, getragen von Fachbereich und IT gemeinsam.
Ihre KI braucht nicht mehr Daten. Sie hat vermutlich bereits mehr, als sie verarbeiten kann. Sie braucht Kontext. Und Kontext ist keine Frage des Modells, sondern der Architektur.