UnternehmenskI-Architektur: RAG findet, LLMs denken, Entscheidungsmodelle wählen

Die Suche nach Fakten und das logische Arbeiten mit ihnen ist nicht mehr eine seltene Fähigkeit. Das Problem des offenen Designs besteht darin, schnelle, begrenzte Entscheidungen bereitzustellen, denen Business-Software vertrauen kann – ohne jeden Mikro-Schritt in eine freie Textgenerierung umzuwandeln.

In der Branche folgte man einer bekannten Abfolge: Grundmodellien, Retrieval-Augmentation, graph-basierte Retrieval-Methoden und schließlich Agenten. Jeder Schritt schloss eine andere Lücke. Ein Bereich blieb jedoch weiterhin unzureichend entwickelt: Entscheidungsfindung – weder eine konversationelle Abwägung noch wiederum nur Textausgaben, sondern ein eingegebener, begrenzter Ausgangspunkt, den eine Anwendung ausführen kann.

Entscheidungshilfen im Stil von System 1 wie Jev (TypeSafe AI) machen diese Ebene greifbar. Sie deuten darauf hin, dass Produktionsumgebungen möglicherweise einen eigenen Entscheidungsweg neben Retrieval- und Sprachverarbeitungsfunktionen benötigen.

Die Entwicklung der UnternehmenskI

Eine vereinfachte Zeitlinie hilft, das fehlende Glied zu verstehen.

1. LLMs: „Welchen Text kann erzeugt werden?“

Foundation-Modelle haben Maschinen in der Lage gemacht, natürliche Sprache zu lesen und zu schreiben. Was sie „wissen“, hängt weiterhin vom Vortraining sowie vom bei der Inferenz bereitgestellten Kontextfenster ab.

In Unternehmen zeigt sich diese Lücke sofort. Wichtige Fachkenntnisse befinden sich selten in den Modellgewichten – sie existieren in Dokumenten, Repositorien, APIs, Datenbanken, Richtlinien, Runbooks, Tickets, E-Mails, Geschäftsregeln, Wikis und Anwendungen.

Der Druck hat dazu geführt, dass die Technologie auf eine höhere Ebene entwickelt wurde.

2. RAG: „Wo befindet sich das Material?“

Retrieval-Augmented Generation ermöglicht es Modellen, auf interne Unternehmensdaten zuzugreifen. Anstatt eine vollständige Wiedergabe aus den Modellgewichten zu verlangen, holen Pipelines relevante Materialien ab und fügen sie als Arbeitskontext hinzu.

Der Ablauf verläuft nun wie folgt:

Unternehmensdaten → Abruf → Arbeitskontext → Sprachmodell → Antwort

Der Sprung hat sehr geholfen. RAG stößt immer noch auf eine strukturelle Grenze: Die Suche nach ähnlichen Dokumenten ist nicht dasselbe wie das Verständnis dafür, wie sich Unternehmensfakten zueinander verhalten.

Betrachten wir einen Streit bezüglich der Versicherung abdeckung:

„Was hat zur Ablehnung dieser Anspruch geführt, und verdient er eine Eskalation?“

Zur Beantwortung ist es möglicherweise notwendig, folgende Schritte zu durchlaufen:

Kunde → Police → Produkt → Versicherung abdeckung → Anspruch → Diagnose → Ausschluss → Police-Klausel → Regulierungsregel

Das ist nicht nur ein Problem der Schlüsselwortsuche. Es handelt sich um ein Problem der Beziehungen und des logischen Schließens.

3. GraphRAG: „Wie sind diese Dinge miteinander verbunden?“

Dann kamen Graphen und GraphRAG. Anstelle isolierter Textabschnitte modellieren Plattformen Entitäten und Verbindungen. Zum Beispiel:

Customer
   │
   ├── owns → Policy
   │              │
   │              ├── covers → Product
   │              │
   │              └── governed by → Rule
   │
   └── submitted → Claim
                       │
                       ├── relates to → Diagnosis
                       │
                       └── evaluated against → Coverage

Traversal ersetzt die Suche nach dem „nächsten Absatz“. Das ist die Unternehmenswissensschicht hinter strukturiertem Wissen, OKF-ähnlicher Arbeit sowie GraphRAG-Experimenten.

Auch dann bleibt eine weitere Frage bestehen: Sobald der Kontext verstanden und durchdacht wurde – was sollte das System eigentlich tun?

4. Agenten: „Was sollte als Nächstes geschehen?“

Durch die Agentenkonzepte wird das Sprachmodell als Dirigent eingesetzt. Es kann abwägen, Werkzeuge auswählen, APIs aufrufen, Ergebnisse prüfen, den nächsten Schritt bestimmen, ein anderes Werkzeug aufrufen und so weitermachen, bis die Aufgabe abgeschlossen ist.

Diese Macht erzeugt einen architektonischen Druck: Derselbe allgemeine Zweckmodell soll jede Phase übernehmen:

Understand
   ↓
Reason
   ↓
Choose
   ↓
Route
   ↓
Decide
   ↓
Call API
   ↓
Inspect result
   ↓
Decide again
   ↓
Call another API

Daraus ergeben sich unangenehme Fragen: Benötigt jede mikroökonomische Entscheidung eines Agenten ein großes Reasoning-Modell? Sollte ein sprachbasiertes Modell Entscheidungen wie folgende treffen:

„Soll dieses Ticket an Team A oder Team B weitergeleitet werden? Soll dieser Workflow fortgesetzt werden? Muss ein Mensch eingreifen? Welche der fünf vordefinierten Aktionen gilt? Läuft diese Transaktion über die Eskalationsgrenze hinaus?“

Das sind oft Entscheidungsprobleme, keine Probleme der Sprachgenerierung.

Einsatz von Entscheidungsmodellen vom Typ System 1

Hier spielt Jev eine Rolle. TypeSafe AI betrachtet dies als ein System 1-Modell. Konzeptionell ist die Unterscheidung einfach:

• Eine große Sprachmodell wird in erster Linie darauf optimiert, Sprache zu erzeugen („Welche Formulierung passt?“).
• Ein Entscheidungsmodell nutzt strukturierte Zustände und beantwortet vordefinierte Fragen mit strukturierten Ausgaben („Welche Softwareentscheidung gilt?“).

Offizielle Materialien beschreiben Jev als ein System, das typierte Antworten sowie Sicherheit aus dem gemeinsam genutzten Anwendungsstatus bereitstellt und dabei Geschwindigkeit vor ausführlichen Texten priorisiert. Diese Trennung ermöglicht eine sauberere Architektur.

Die fehlende Schicht

UnternehmenskI muss nicht unbedingt so aussehen:

Enterprise Data
      ↓
     RAG
      ↓
     LLM
      ↓
    Agent
      ↓
   Actions

Ein besser getrenntes Design sieht so aus:

Enterprise Systems
        ↓
Knowledge Engineering
        ↓
Enterprise Knowledge Layer
        ↓
Context Engineering
        ↓
 ┌──────────────┬──────────────┐
 │              │              │
 ▼              ▼              ▼
Reasoning    Decision       Rules
 LLM          Model          Engine
 │              │              │
 └──────────────┴──────────────┘
                ↓
          Agent Control
                ↓
        Deterministic Code
                ↓
        APIs / Workflows

Dadurch werden die Verantwortlichkeiten klarer.

LLMs müssen nicht alles erledigen

Betrachten wir einen Ablauf in einem Versicherungsdienstleistungsunternehmen. Ein Kunde schreibt:

„Diese Krankenhausaufenthaltsanspruch wurde abgelehnt, scheint aber eine Absicherung zu verdienen.“

Die Plattform muss zunächst den Kontext klären. Dazu können Kundendaten, Policendetails, Produktkonfigurationen, Versicherungsumfänge, Anspruchsinformationen, Krankenhausdaten, Ausschlüsse, Policaklauseln sowie gesetzliche Vorschriften herangezogen werden. Genau hier kommen eine Unternehmenswissensschicht und GraphRAG zum Tragen.

Das LLM kann anschließend schlussfolgern:

„Die Ablehnung scheint mit der Ausschlussregel X verbunden zu sein. Klausel Y könnte unter Bedingung Z eine Ausnahme schaffen.“

Danach folgen begrenzte Auswahlmöglichkeiten:

Does this require human review?
        → YES

Which workflow?
        → Claims InvestigationPriority?
        → HighAdditional evidence required?
        → YESCustomer communication template?
        → Coverage Review

Das sind strukturierte Entscheidungen, keine offenen Generierungsprozesse – genau dort passt ein Entscheidungsmodell wie Jev.

Die Architektur sieht allmählich anders aus

UnternehmenskI kann als unterschiedliche kognitive Aufgaben betrachtet werden.

Wissensschicht

Welche Fakten kennt das Unternehmen?

OKF – Wissensgraphen – Dokumente – Quellcode – APIs – Datenbanken.

Kontextschicht

Welche Informationen sind für dieses Problem relevant?

RAG, GraphRAG, Kontextengineering.

Slussfolgerungsschicht

Was bedeuten diese Informationen?

LLMs und Schlussfolgerungsmodelle.

Entscheidungsschicht

Angesichts dieses Zustands: Was sollte die Plattform tun?

Entscheidungsmodelle wie Jev.

Ausführungsschicht

Wie sollte diese Entscheidung umgesetzt werden?

APIs, Workflows, Geschäftsregeln, deterministische Software.

Die Trennung ist wichtig: Intelligenz erfordert nicht ein einziges riesiges Modell, das alles übernimmt.

Dies verändert unsere Sicht auf Unternehmenswissen

Die Wissensinfrastruktur eines Unternehmens ist mehr als nur eine Verbesserung bei der Suche. Sie kann zum Zustandssubstrat für maschinelles Entscheiden werden.

Stellen Sie sich ein Graphen vor, der folgendes enthält:

Customer
Policy
Product
Claim
Agent
Branch
API
Business Rule
Regulation
Risk
Transaction

mit Beziehungen wie:

Customer → owns → Policy

Policy → belongs to → ProductPolicy → covers → BenefitClaim → relates to → PolicyClaim → triggered by → EventProduct → governed by → RuleRule → derived from → Regulation

Das System sucht nicht mehr nur nach „Dokumenten zu Ansprüchen“. Es erstellt eine strukturierte Darstellung des Geschäftszustands, die verschiedene Intelligenzprimitiven nutzen können:

• LLM zur Logikverarbeitung
• Entscheidungsmodell für begrenzte Auswahlmöglichkeiten
• Regeln für deterministische Einschränkungen
• Code zur Ausführung

Diese Kombination ist wartbarer als ein einziger Mega-Prompt.

Der interessante Aspekt: Das Vertrauensniveau wird zu einer architektonischen Grundlage

Entscheidungsmodelle zeigen auch das Vertrauensniveau an. Viele KI-Apps beschränken sich auf die Aussage „Das Modell liefert X.“ Doch Betreiber benötigen außerdem Informationen dazu: Wie sicher ist der Ausgang, und was geschieht, wenn das Vertrauensniveau zu niedrig ist?

Stellen Sie sich vor:

Decision
   ↓
Confidence
   ↓
 ┌───────────────┐
 │               │
High           Low
 │               │
 ▼               ▼
Auto           Human
execute       review

Die Schwellenwerte müssen je nach Anwendungsfall angepasst werden, doch das Muster ist äußerst wirkungsvoll. Behandeln Sie die KI-Ausgabe als Entscheidung mit Unsicherheit und kodieren Sie anschließend eine Autonomiepolitik:

High confidence
        ↓
Autonomous execution

Medium confidence
        ↓
Secondary validationLow confidence
        ↓
Human intervention

Besonders regulierte Branchen benötigen diese Struktur dringend.

Dies könnte auch die Wirtschaft der KI verändern

Falls jede mikroökonomische Entscheidung eines Agenten einen leistungsstarken Entscheider belastet, führt dies bei großen Flotten – also Tausenden oder Millionen von Anfragen – zu höheren Kosten und Verzögerungen. Wenn viele Entscheidungen eng gefasst und repetitiv sind, kann ein spezialisierter Entscheider die Kurve der Kosten und Verzögerungen verändern.

Das führt zu einer weiteren Routing-Ebene:

Complex reasoning
        ↓
       LLM

Bounded decision
        ↓
   Decision ModelDeterministic rule
        ↓
     Rule EngineExecution
        ↓
       Code

Ziel ist es nicht, LLMs zu ersetzen. Vielmehr geht es darum, ihre Nutzung für Aufgaben einzustellen, die sie nicht ausführen müssen.

Außerdem ändert sich dadurch, wie wir KI messen

Heutige Dashboards erfassen oft Nutzer, Anfragen, Tokens, Modellnutzung, Verzögerungen, Adoption und Kosten. Diese bleiben weiterhin nützlich. Sobald KI operative Entscheidungen trifft, entsteht eine weitere Metrik-Ebene.

Metriken für Entscheidungsintelligenz

Wie viele Entscheidungen trifft die KI Entscheidungsverzögerung Wie schnell Entscheidungen getroffen werden Vertrauensverteilung Wie sicher sich das System ist Automatische Lösungsrate Wie oft auf menschliches Eingreifen verzichtet wird Escalationsrate Wie oft menschliches Eingreifen erforderlich ist Entscheidungsgenauigkeit Ob die Wahl richtig war Falsche-Entscheidungsrate Wie oft die Wahl falsch war Kosten pro Entscheidung Wirtschaftliche Aspekte der KI-Entscheidungsfindung Menschliche Überprüfungsarbeit Operative Belastung Unternehmensergebnis Tatsächlich geschaffter Wert

Dadurch verschiebt sich das Gespräch von der Einführung von KI hin zur Wirtschaftlichkeit künstlicher Intelligenz.

Und es gibt eine wichtige Einschränkung

Jev ist völlig neu. Insbesondere: Die offizielle Einführung findet erst im September 2026 statt – daher gibt es bisher nur begrenzte unabhängige Belege. Es wäre voreilig, Jev oder irgendein anderes neuartiges Entscheidungssystem als bewährten Ersatz für ein LLM zu betrachten.

Die sinnvolle experimentelle Frage lautet:

In welchen Fällen übertrifft ein speziell dafür entwickeltes Entscheidungssystem ein Sprachmodell, einen klassischen Regelsatz oder eine gemischte Architektur?

Das lohnt es, zu messen – anstatt einfach Voraussetzungen zu treffen.

Das Experiment, das es wert ist, durchgeführt zu werden

Wählen Sie einen begrenzten Unternehmensprozessablauf – als Beispiel Service Request Routing – und geben Sie denselben strukturierten Kontext mehreren Ansätzen ein.

Ansatz 1

LLM → strukturierte Ausgabe → Anwendungslogik

Ansatz 2

Regelsatz → deterministische Entscheidung

Ansatz 3

Entscheidungsmodell → typisierte Entscheidung

Ansatz 4

Hybrid:

Rules
  ↓
Decision Model
  ↓
LLM when ambiguity requires reasoning
  ↓
Human when confidence is insufficient

Dann werden Genauigkeit, Kalibrierung der Sicherheit, Latenzzeit, Kosten, Tokenverbrauch, Eskalationsrate, Erklärbarkeit, Wartbarkeit, Ausfallmöglichkeiten sowie das Geschäftsergebnis gemessen.

Ein solches Experiment ist besser als andere Leistungslisten, die behaupten, ein Modell sei einfach „besser“. Das Ziel ist es nicht, Jev zu krönen. Es geht darum herauszufinden, welche Intelligenzprimitiven wo hingehören.

Von RAG über Reasoning bis zur Entscheidungsfindung

Betrachten wir die Leiter erneut:

RAG fragte:

„Wo befindet sich das Material?“

Wissensgraphen fragten:

„Wie sind diese Elemente miteinander verbunden?“

GraphRAG fragte:

„Welchen Kontextpfad sollte man durchlaufen?“

LLMs fragten:

„Was bedeutet dieser Kontext?“

Agenten fragten:

„Was sollte als Nächstes geschehen?“

Entscheidungsmodelle fügen hinzu:

Decision Intelligence fragt:

„Angesichts dieses Zustands, welche begrenzte Aktion sollte die Plattform wählen?“

Das ist ein bedeutender architektonischer Unterschied.

Der Enterprise AI Stack kann daher kognitiv statt nur technisch werden

Teams zeichnen die AI-Architektur oft als Komponenten:

LLM
Vector DB
Embedding Model
RAG
Orchestrator
API Gateway
Guardrails

Eine kognitiv-verantwortungsbasierte Sichtweise sieht eher so aus:

ENTERPRISE AI
                          │
             ┌────────────┴────────────┐
             │                         │
          KNOWLEDGE                 CONTEXT
             │                         │
       KG / OKF / Data          RAG / GraphRAG
             │                         │
             └────────────┬────────────┘
                          │
                ┌─────────┴─────────┐
                │                   │
            REASONING            DECISION
                │                   │
             LLM/SLM            Jev / similar
                │                   │
                └─────────┬─────────┘
                          │
                     ORCHESTRATION
                          │
                      GUARDRAILS
                          │
                    HUMAN-IN-LOOP
                          │
                     EXECUTION
                          │
                  APIs / Workflows

Das AI-Design von Unternehmen weicht zunehmend vom Konzept eines Modells, das alles steuert ab und bewegt sich in Richtung eines Portfolios an Intelligenz-Primitiven – wobei jede Primitiv für eine andere kognitive Aufgabe optimiert ist.

Das größere Bild

Ein wiederkehrendes Thema im Enterprise AI-Design:

Die Zukunft wird vielleicht nicht davon entschieden, wer das größte Modell besitzt. Vielmehr könnte sie davon abhängen, wer das beste System um diese Modelle herum entwickelt.

Die Differenzierung beruht zunehmend auf der Kombination aus proprietärem Wissen – strukturierten Beziehungen – Kontextengineering – Abwägung – Entscheidungsintelligenz – sowie kontrollierter Ausführung. Bemerkenswerterweise ist das LLM nur ein einzelner Bestandteil.

Die nächste Entwicklung sieht so aus:

Generierungsmodelle weichen zunächst Verständnissystemen, dann Schlussfolgerungssystemen, anschließend Entscheidungssystemen und schließlich Handlungssystemen.

Eine nachhaltige Vorteilhaftigkeit liegt daher weniger in einem einzelnen Meilenstein als vielmehr im Zusammenspiel von Wissen, Kontext, Schlussfolgerungen, Entscheidungen und Handlungen – ein komplexeres Ingenieurproblem als das reine Anstreben nach einer hohen Anzahl an Parametern.