Unternehmenskontext gehört nicht in den Prompt.

Vor ein paar Wochen hat mir ein Kollege aus einem laufenden Versicherungsprojekt erzählt, was ihn an der aktuellen Agenten-Demo gestört hat. Nicht die Latenz. Nicht die UI. Sondern der Moment, in dem der Agent zu einem abgelehnten Leistungsantrag eine flüssige Begründung lieferte – und intern niemand sagen konnte, welche Regel, welche Police und welcher Gültigkeitszeitraum dafür verbindlich waren.

Der Agent hatte passende Dokumentabschnitte gefunden. Er hatte sogar den richtigen Ton. Was fehlte, war nicht Intelligenz. Es war ein Ort ausserhalb des Prompts, an dem Unternehmenskontext verbindlich liegt.

Genau das ist die These dieses Beitrags: Unternehmenskontext gehört nicht in den Prompt. Er gehört in ein explizites, versioniertes, prüfbares Modell – und erst danach darf ein LLM formulieren oder ein Agent eine Aktion vorschlagen.

Was im Prompt landet, ist kein Kontext. Es ist Absicht.

In vielen Enterprise-Setups sieht der System Prompt ungefähr so aus:

Premiumkunden dürfen unter Umständen …
Für Produktgruppe A gilt …
In der Region CH muss …
Claims über 100'000 brauchen manuelle Prüfung …

Das klingt nach Governance. Es ist zunächst nur Text, den ein Modell möglicherweise beachtet.

Sobald die Frage operativ wird – Warum wurde dieser Antrag abgelehnt, und darf er erneut eingereicht werden? – braucht das System unterschiedliche Wissensarten gleichzeitig:

• Der Claim gehört zu einer Police.
• Die Police deckt bestimmte Leistungen.
• Der Kunde hat einen bestimmten Status.
• Eine Leistung ist nur unter Bedingungen erstattungsfähig.
• Interne Richtlinien verbieten bestimmte Kombinationen.
• Ausnahmen gelten nur für bestimmte Regionen.
• Die Antwort muss auf den zum Entscheidungszeitpunkt gültigen Regeln beruhen.

Ein klassisches RAG-System kann passende Passagen finden. Es garantiert nicht, dass alle relevanten Beziehungen gefunden wurden, Widersprüche erkannt werden, Gültigkeitszeiträume greifen oder die vorgeschlagene Aktion zulässig ist. Unvollständiges Retrieval erzeugt unvollständigen Kontext. Daraus entstehen Halluzinationen, nichtdeterministisches Verhalten und Agentenentscheidungen, die niemand verteidigen kann.

Das ist dieselbe Diagnose wie bei Evidence-first AI: Das LLM darf formulieren. Es darf nicht allein entscheiden, was wahr, sichtbar und zulässig ist.

Das mentale Modell: sechs Fragen statt einer Suche

Bevor Techniknamen kommen, hilft eine einfache Unterscheidung:

Kontrollfrage: Ein Agent findet per Vector Search einen Policy-Abschnitt, der Claims über 100'000 manuell prüft. Was fehlt noch, bevor das System eine automatische Genehmigung zuverlässig blockieren kann?

Nicht mehr Retrieval. Nicht MCP. Sondern: die Regel als formale Constraint – und die Prüfung vor der Aktion.

Ontologie und Knowledge Graph sind nicht dasselbe

Diese beiden Begriffe werden häufig vermischt – auch in Agenten-Demos.

Die Ontologie ist das Modell der möglichen Welt: Claim ist eine Klasse. MedicalClaim ist eine Unterklasse. Ein Claim darf eine Policy referenzieren. Jeder Claim muss genau eine Policy referenzieren.

Der Knowledge Graph enthält die konkreten Fakten: Claim 4711 ist ein MedicalClaim, bezieht sich auf Policy 815, die den Status Active hat.

Eine brauchbare Analogie: Ontologie ≈ Grammatik und Begriffsmodell; Knowledge Graph ≈ konkrete Aussagen in dieser Grammatik. Oder aus Softwareperspektive: Ontologie ≈ Typensystem plus Regeln; Knowledge Graph ≈ Laufzeitinstanzen.

Ein Property Graph mit Knoten und Kanten allein ist deshalb noch keine starke semantische Lösung. Ohne formale Bedeutung, Constraints und nachvollziehbare Ownership bleibt er eine weitere Datenstruktur – und das LLM füllt die Lücken wieder aus dem Prompt. Genau dort setzt der Beitrag Knowledge Graph im Unternehmen an: Beziehungen modellieren und verantworten, nicht aus dem Prompt raten.

Vier technische Schichten – und der Kontextlayer

AWS Prescriptive Guidance beschreibt für den Context Ontology Accelerator vier Schichten:

Die Trennung ist der eigentliche Punkt. Ein klassischer Agent vermischt oft alles:

Frage → LLM → Vector Search → LLM → Antwort

Hier wird Verantwortung verteilt: Intent bestimmen, Wissenszugang wählen, Query erzeugen und kontrollieren, Fakten abrufen, Regeln anwenden, Ergebnis erklären, Aktion zulassen oder verweigern. Das LLM bleibt wichtig. Es ist nicht mehr alleinige Entscheidungsinstanz.

Das mappt direkt auf den Kontextlayer:

Darüber liegen bei uns zusätzlich Glossar und Semantic Layer: Bedeutung und Berechnung, bevor Beziehungen und Agentenzugriff greifen. Der Accelerator ist damit keine Parallelwelt. Er ist eine AWS-Lesart derselben Architekturidee – mit formalen Standards dort, wo der Prompt sonst «Compliance» nur behauptet.

Scan → Model → Serve: der Workflow hinter der Idee

Der Accelerator nennt den Ablauf Scan → Model → Serve.

Scan verbindet Quellen und macht sie lesbar: Schemas, Metadaten, Dokumente, Kataloge. Ziel ist noch kein vollständiger Graph, sondern Klarheit: Welche Entitäten gibt es? Welche Beziehungen sind sichtbar? Welche Qualitäts- und Freigabeprobleme bestehen?

Model macht aus technischen Metadaten ein fachliches Modell. Ontology Induction heisst hier: Das LLM schlägt vor – cust_master könnte Customer sein, tier_cd ein CustomerTier. Fachexperten prüfen, ob das fachlich stimmt. Ist es Kunde oder Kundenkonto? Ist tier Vertrag oder Marketing? Gilt country für Wohnsitz oder Vertragsland?

Serve stellt Kontext für Anwendungen und Agenten bereit – und zwar über mehrere Zugangsarten:

• strukturierte Fragen → SPARQL / Virtual Knowledge Graph
• Beziehungs- und Pfadfragen → Graph-Traversierung
• unscharfe semantische Fragen → Vector Search / GraphRAG
• Zulässigkeitsfragen → Reasoning und SHACL/OWL

Das ist der entscheidende Unterschied zu «für jede Frage Vector Search».

Materialisiert, virtuell – oder hybrid

Ein materialisierter Knowledge Graph speichert Fakten physisch (etwa als RDF in Neptune): schnell traversierbar, gut für domänenübergreifendes Reasoning, aber mit Kopie, Sync und Freshness-Kosten.

Ein Virtual Knowledge Graph lässt Daten in der Quelle und mappt sie (z. B. per R2RML) auf die Ontologie. SPARQL wird in SQL übersetzt. Weniger Migration, mehr Abhängigkeit von Mapping-Qualität und Quellperformance.

In der Praxis entsteht eine Hybridarchitektur: operational virtualisieren, materialisieren, was Reasoning und Integration wirklich brauchen. Das ist Ontology-Based Data Access – kein Zwang, «alles in den Graph zu kopieren», bevor der erste Agent sinnvoll arbeitet. Dieselbe Logik steckt hinter einer hybriden Business Analytics Plattform: Quellen verbinden und entscheidungsfähig machen, nicht alles vorher migrieren.

SHACL als Guardrail – stärker als «bitte beachte Compliance»

Für Agenten ist SHACL besonders interessant: nicht nur Datenqualität, sondern Handlungsbedingungen.

Muster:

LLM schlägt Aktion vor → Aktion wird als prüfbarer Zustand modelliert → SHACL validiert → gültig ausführen / ungültig blockieren und Verletzungen erklären.

Das ist derselbe Vertrag wie beim Evidence Pack: Zuerst Beleg und Zulässigkeit, dann Formulierung oder Aktion. Ein Prompt Bitte beachte alle Compliance-Regeln ersetzt das nicht.

MCP ist in diesem Bild nicht die Wissensschicht. Es ist das standardisierte Zugangsprotokoll: Intent klassifizieren, Queries erzeugen und ausführen, GraphRAG, Reasoning. Der Agent muss die Ontologie nicht ins Kontextfenster laden. Er ruft gezielt Fähigkeiten auf – unter den Rechten, die die Control Plane erzwingt (Allowlists, Denylists, Metrikfreigaben). Das ist der Enterprise-Unterschied zu vielen RAG-Demos: Darf die Person die Funktion aufrufen? und Darf diese Query diese Daten lesen? sind zwei verschiedene Fragen.

Was Ontologien nicht heilen

Die Aussage «Ontologien lösen Halluzinationen» ist zu stark.

Sie können Fehlerklassen reduzieren: falsche Begriffszuordnung, inkonsistente Beziehungen, verletzte Regeln, fehlende Pflichtattribute, logisch widersprüchliche Ergebnisse, unzulässige Aktionen.

Sie lösen nicht automatisch: fehlerhafte Extraktion, schlechte Ontologieentwürfe, veraltete Regeln, kaputte Mappings, Entity-Resolution-Fehler, falsche LLM-Query-Generierung, unvollständige Quellen oder alles ausserhalb der modellierten Domäne.

Die realistischere Formulierung:

Ontologien verschieben Teile der Agentenlogik aus probabilistischen Prompts in explizite, testbare und überprüfbare Modelle.

Das ist erheblich. Es ist keine universelle Halluzinationsheilung.

Was das praktisch bedeutet – und was nicht

Ein realistisches Einführungsmodell beginnt nicht mit dem vollständigen Accelerator. Es beginnt mit einer Domänenfrage, deren falsche Automatisierung teuer wäre – etwa die Claim-Frage aus dem Projekt meines Kollegen. Dafür: Begriffe klären, wenige Beziehungen modellieren, eine Constraint-Prüfung vor der Aktion, Human-in-the-Loop bei Ontology Induction, erst dann Agentenwerkzeuge. Genau so priorisieren wir auch KI Use Cases für Entscheidungsbeschleunigung: an den Entscheidungstyp koppeln, nicht als Showcase starten.