Das LLM darf antworten. Es darf nicht entscheiden, was wahr ist.

Sie sitzen im Steering Committee. Jemand fragt: «Wie hat sich der Deckungsbeitrag im zweiten Quartal entwickelt – und warum?» Das Dashboard zeigt eine Zahl. Der AI-Assistent liefert in acht Sekunden eine Erklärung. Der Raum nickt. Später stellt Controlling fest: Es war DB II, nicht die Managementsicht. Der Scope war zu weit. Die Begründung stammte aus dem Modellwissen, nicht aus einer freigegebenen Beleggrundlage. Die Antwort klang richtig. Der Entscheid war nicht verteidigbar.

Das ist kein Prompt-Problem. Es ist ein Architekturproblem.

Ein Sprachmodell kann eine falsche Zahl überzeugend erklären. Es kann auch eine richtige Zahl mit der falschen Begründung liefern. In beiden Fällen liegt die Ursache selten nur beim Modell. Sie liegt in einer Architektur, die dem Modell zu viele Verantwortlichkeiten überträgt: Bedeutung, Berechnung, Zugriff und Formulierung. Vertrauenswürdige Enterprise AI beginnt deshalb nicht beim besseren Prompt. Sie beginnt bei der Trennung von Mandaten.

Die Managementfrage ist nie nur eine Frage

Die Deckungsbeitragsfrage klingt eindeutig. Sie ist es nicht. Bevor ein System sie zuverlässig beantworten kann, muss es unter anderem klären:

• Welche Deckungsbeitragsdefinition ist gemeint?
• Welche Berechnungslogik ist verbindlich?
• Welcher Zeitraum und welche Dimension gelten?
• Welche Daten darf die anfragende Person sehen?
• Welche Quelle liefert den Wert?
• Welche Evidenz stützt die Erklärung?

Ein klassischer AI-Assistent versucht häufig, all das innerhalb eines Modells zu lösen. Das LLM interpretiert den Begriff, sucht Informationen, kombiniert Zahlen, berücksichtigt vermeintlich Berechtigungen und formuliert schliesslich die Antwort. Das Ergebnis kann vollständig plausibel wirken – und trotzdem auf der falschen Definition beruhen, einen unzulässigen Datenumfang verwenden oder eine Begründung ergänzen, für die keine belastbare Quelle existiert.

Sprachliche Plausibilität ist noch keine belastbare Entscheidungsgrundlage.

Unternehmensfragen verbinden mehrere Ebenen: fachliche Bedeutung, Berechnungslogik, Datenzugriff, Entscheidungskontext und Verantwortlichkeit. Finance definiert eine Kennzahl oft anders als Sales. Controlling arbeitet mit einer bereinigten Managementsicht. Das operative System kennt einen aktuellen Status, das Reporting einen abgeschlossenen Periodenstand. Keine dieser Perspektiven muss falsch sein. Sie beantworten nur unterschiedliche Fragen.

Ein LLM kann diese Unterschiede erkennen und zusammenfassen. Es besitzt dadurch aber noch kein Mandat, selbst festzulegen, welche Perspektive für eine konkrete Geschäftsentscheidung verbindlich ist. Genau deshalb gilt:

Bedeutung ist nicht Berechnung. Berechnung ist nicht Zugriff. Zugriff ist nicht Formulierung.

Diese vier Trennungen sind kein abstraktes Manifest. Sie sind derselbe Vertrag, den der Kontextlayer in vier Schichten baut: Glossar, Semantic Layer, Ontologie und Agentenkontext. Das LLM kommt erst danach.

1. Bedeutung muss ausserhalb des Modells definiert werden

Ein Begriff wie «Deckungsbeitrag», «aktiver Kunde» oder «Umsatz» besitzt im Unternehmen selten eine universelle Bedeutung. Seine Bedeutung hängt ab vom Geschäftsprozess, vom Adressaten, vom Zeitpunkt, von der Organisationseinheit und von der konkreten Entscheidung.

Ein Sprachmodell kann mögliche Definitionen vorschlagen oder bestehende vergleichen. Es sollte aber nicht selbst entscheiden, welche davon verbindlich ist. Dafür braucht es einen fachlichen Kontext, in dem sichtbar ist:

• welche Definitionen existieren,
• für welchen Zweck sie gelten,
• wer sie verantwortet,
• welche Ausnahmen bekannt sind,
• wie sie mit anderen Begriffen und Kennzahlen zusammenhängen.

Im Kontextlayer ist das die erste Schicht: das Glossar. Eine vom Modell erzeugte Interpretation ist zunächst eine Hypothese. Sie wird nicht dadurch zur Geschäftsregel, dass sie überzeugend formuliert wurde.

2. Berechnung braucht eine verbindliche Logik

Definition und Wert sind nicht dasselbe. Selbst wenn geklärt ist, welche Kennzahl gemeint ist, bleibt offen: Welche Formel gilt? Welche Daten fliessen ein? Welche Aggregation und welche Periode? Welche Korrekturen oder Ausschlüsse?

Ein LLM sollte diese Berechnung nicht spontan rekonstruieren. Auch frei generiertes SQL löst das Grundproblem nicht. Es verlagert die Interpretation lediglich in eine technische Abfrage, deren Logik möglicherweise weder freigegeben noch reproduzierbar ist.

Entscheidungsrelevante Kennzahlen brauchen eine definierte und kontrollierte Berechnungsebene – im Kontextlayer der Semantic Layer. Das Modell darf den ermittelten Wert erklären. Es sollte ihn nicht selbst erfinden.

3. Zugriff muss technisch erzwungen werden

Viele AI-Anwendungen behandeln Berechtigungen wie eine Anweisung im Prompt: Zeige dieser Person nur Daten aus ihrem Verantwortungsbereich. Das klingt nach Governance. Es ist zunächst nur ein Satz.

Kann das zugrunde liegende System trotzdem auf alle Daten zugreifen, hängt die Sicherheit davon ab, dass das Modell die Anweisung korrekt interpretiert und konsequent befolgt. Das ist keine belastbare Zugriffskontrolle.

Der erlaubte Datenumfang muss bestimmt werden, bevor Informationen in die Antwortpipeline gelangen. Ein Advisor, ein Bereichsleiter und ein Mitglied der Geschäftsleitung können dieselbe Frage stellen und berechtigterweise unterschiedliche Ergebnisse erhalten. Der Unterschied darf nicht durch die Höflichkeit des Modells entstehen. Er muss durch die Daten- und Berechtigungsarchitektur erzwungen werden – im Kontextlayer durch den Agentenkontext.

4. Das LLM sollte formulieren, nicht Wahrheit erzeugen

Damit bleibt für das Sprachmodell eine wichtige, aber klar begrenzte Aufgabe: Es formuliert eine verständliche Antwort aus einer kontrollierten Beleggrundlage.

Das ist keine geringe Rolle. Ein gutes Modell kann komplexe Zusammenhänge erklären, relevante Unterschiede hervorheben, Zahlen in einen geschäftlichen Kontext setzen, Unsicherheiten sichtbar machen und die Antwort an den Wissensstand des Lesers anpassen. Aber es sollte dabei nur Aussagen verwenden dürfen, für die eine zulässige Grundlage vorliegt.

In der Praxis arbeiten wir deshalb mit einem Evidence-first-Prinzip:

Evidence first. Compose second. Critic last.

Zuerst wird bestimmt, welche Definitionen, Werte, Abhängigkeiten und Zugriffsinformationen für die Frage zulässig sind. Erst danach wird eine Antwort formuliert. Anschliessend prüft ein separates Gate, ob die Aussagen tatsächlich auf der vorhandenen Evidenz beruhen und ob bekannte Einschränkungen korrekt behandelt wurden.

Die Beleggrundlage wird zum Vertrag

Der entscheidende Unterschied zu einem freien Chatbot liegt nicht nur in der Qualität der Daten. Er liegt im Übergang zwischen Daten und Antwort.

Für jede Anfrage entsteht eine kontrollierte Beleggrundlage – ein Evidence Pack. Darin können beispielsweise enthalten sein:

• die aufgelöste fachliche Bedeutung,
• die verbindliche Kennzahlendefinition samt Version,
• der berechnete Wert,
• relevante Abhängigkeiten,
• der erlaubte Datenumfang,
• bekannte Lücken oder Konflikte,
• der fachliche Owner der zugrunde liegenden Regel.

Jede faktische Aussage muss auf einen Bestandteil dieser Grundlage zurückgeführt werden können. Fehlt die notwendige Evidenz, gibt es nur wenige zulässige Ergebnisse: eine Rückfrage, eine eingeschränkte Antwort, eine transparente Lücke oder eine Blockierung. Nicht zulässig ist die wahrscheinlichste Ergänzung aus dem Modellwissen.

Das ist derselbe Massstab, den eine Entscheidungsvorlage für den Vorstand an die Faktenbasis stellt: Führt dieselbe Frage nächste Woche zu derselben Zahl, und wer im Raum kann die Herleitung erklären?

Wenn Systeme widersprechen

Finance, Sales und Controlling können denselben Begriff verwenden und trotzdem unterschiedliche, jeweils nachvollziehbare Zahlen liefern. Keine davon muss falsch sein. Ein LLM, das still eine Variante wählt und die anderen weglässt, trifft damit eine fachliche Entscheidung ohne Mandat.

Ein belastbares System behandelt solche Konflikte als sichtbare Objekte: konkurrierende Evidenz, Geltungsbereich, Owner, Status. Wo eine freigegebene Vorrangregel existiert, wendet es sie an. Wo nicht, fragt es zurück oder eskaliert. Stille Winner-Picks durch das Modell sind kein Feature. Sie sind ein Architekturfehler.

Das gilt besonders, wenn Beziehungen und Bedeutungen über mehrere Systeme hinweg laufen. Genau dort setzt auch der Knowledge Graph im Unternehmen an: Beziehungen werden modelliert und verantwortet, nicht aus dem Prompt geraten.

«Clarification required» ist kein Fehler

Nehmen wir die Frage: Wie hoch war der Deckungsbeitrag im zweiten Quartal?

Ein System könnte sofort einen Wert liefern. Doch möglicherweise existieren Deckungsbeitrag I, II und III. Vielleicht verwendet ein Bereich zusätzlich eine eigene Managementdefinition. Die schnelle Antwort wäre dann nicht effizient. Sie wäre eine unbemerkte Entscheidung über die Bedeutung der Frage.

Ein belastbares System fragt zurück: Welche Deckungsbeitragsstufe meinen Sie?

Aus Sicht einer Chatbot-Demo wirkt das weniger beeindruckend. Aus Sicht einer realen Unternehmensentscheidung ist es deutlich wertvoller. Ein System, das Mehrdeutigkeit erkennt, ist häufig intelligenter als eines, das sie flüssig überspielt.

Enterprise AI muss daher nicht auf die grösstmögliche Zahl beantworteter Fragen optimiert werden. Sie muss auf die grösstmögliche Zahl verantwortbarer Antworten optimiert werden.

Was sich für Unternehmen dadurch verändert

Die wichtigste Qualitätskennzahl eines Enterprise-AI-Systems ist dann nicht mehr: Wie überzeugend klingt die Antwort? Sondern:

• Welche Definition wurde verwendet?
• Woher stammt der Wert?
• Welcher Zugriffsscope galt?
• Welche Evidenz unterstützt die Aussage?
• Welche Unsicherheiten wurden erkannt?
• Wer verantwortet die zugrunde liegende Regel?
• Kann die Entscheidung später nachvollzogen werden?

Damit verändert sich auch die Entwicklung von AI-Anwendungen. Teams müssen nicht nur Modelle, Prompts und Oberflächen entwerfen. Sie müssen klären:

• welche Systeme für welche Aussagen autoritativ sind,
• wie fachliche Konflikte behandelt werden,
• welche Aussagen automatisch freigegeben werden dürfen,
• wann menschliches Urteil erforderlich ist,
• wie Antworten begrenzt oder widerrufen werden können.

Das ist der Übergang vom AI-Chatbot zum operativen Entscheidungssystem. Weniger Antworten können mehr Vertrauen erzeugen – nicht als unbeabsichtigter Nachteil, sondern als bewusstes Qualitätsmerkmal. Das System kann sagen: Der Begriff ist nicht eindeutig. Der erforderliche Wert liegt nicht vor. Die anfragende Person besitzt nicht den notwendigen Zugriff. Die vorhandene Evidenz reicht nur für eine eingeschränkte Aussage. Der Konflikt benötigt eine fachliche Entscheidung.

Dadurch entsteht möglicherweise weniger AI-Theater. Aber mehr Klarheit darüber, was das Unternehmen tatsächlich weiss, wer darüber entscheiden darf und welche Handlung verantwortbar ist.