Drei-Stufen-KI-Architektur

Für produktive KI-Features habe ich einen Drei-Stufen-Ansatz entwickelt, der Zuverlässigkeit und Intelligenz in Balance bringt. Zu viele Teams springen direkt zu LLMs für alles, obwohl einfachere und vorhersagbarere Ansätze besser funktionieren würden. Umgekehrt verpassen Teams, die KI komplett vermeiden, enorme Chancen. Der Schlüssel ist zu wissen, welche Stufe wo einzusetzen ist.

Nach dem Aufbau KI-gestützter Features in mehreren Produkten — von Enterprise-SaaS-Plattformen bis Health Tech — hat dieses Framework konsistent gute Architekturentscheidungen geleitet.

Stufe 1: Deterministische Regeln

Wann einsetzen: Geschäftslogik, die exakt, auditierbar und 100 % vorhersagbar sein muss.

Compliance-Prüfungen, Validierungsregeln, regulatorische Berechnungen, Datentransformationen mit bekannten Schemata, schwellwertbasierte Alerts. Diese sollten niemals an probabilistische Modelle delegiert werden. Sie sind schnell, testbar, auditierbar und vorhersagbar. Wenn ein Prüfer fragt “Warum haben Sie X getan?”, muss die Antwort eine klare Regel sein, nicht “das Modell dachte so.”

Eigenschaften:

Null Mehrdeutigkeit bei Ein- und Ausgaben
Muss Prüfern und Regulatoren erklärbar sein
Performance-kritisch (Sub-Millisekunde)
Verhalten muss über alle Durchläufe identisch sein
Änderungen erfordern explizite menschliche Freigabe

Reale Beispiele (Enterprise-SaaS):

Preisberechnung: Auftragsmenge * Stückpreis = erwarteter Gesamtbetrag. Keine KI nötig, keine KI gewünscht.
Duplikaterkennung (exakter Abgleich): Gleiche Dokumentnummer + gleicher Kunde + gleicher Betrag = als Duplikat markieren. Deterministischer Hash-Vergleich.
Validierungsregeln: Erwarteter Wert = tatsächlicher Wert innerhalb der konfigurierten Konfidenz-Schwellwerte. Reine Arithmetik.
Compliance-Prüfungen: Steht dieser Kunde auf der Sanktionsliste? Liegt die Transaktion innerhalb der genehmigten Schwelle für diesen Genehmiger? Binäre Lookups.
Formatvalidierung: Hat dieses Dokument alle Pflichtfelder? Ist das Datum parsebar? Ist der Währungscode gültig?

Implementierung:

Standard-Geschäftslogik im Anwendungscode
Rule Engines (Drools, Custom DSL) für komplexe Regelwerke, die Business-Nutzer konfigurieren
Datenbank-Constraints und Trigger für Datenintegrität
Konfigurationsgesteuert (nicht code-deployt), wenn Business-Nutzer Schwellwerte anpassen müssen

Kosten: Im Wesentlichen null pro Transaktion. Entwicklungskosten sind die Regellogik selbst.

Stufe 2: Trainierte ML-Modelle

Wann einsetzen: Mustererkennung auf strukturierten Daten, bei denen historische Ground Truth vorliegt und das Problem ein messbares, begrenztes Ergebnis hat.

Klassifikation, Scoring, Anomalieerkennung, Empfehlung, Forecasting. Diese Modelle werden auf den eigenen Daten trainiert, mit Standard-ML-Metriken evaluiert und mit Monitoring deployed. Sie sind leistungsfähiger als Regeln, aber weiterhin begrenzt und messbar.

Eigenschaften:

Es gibt gelabelte Trainingsdaten (oder man kann sie generieren)
Der Output ist eine Klassifikation, ein Score oder eine Vorhersage — kein Freitext
Man kann Accuracy, Precision und Recall definieren und messen
Das Modell muss sich über die Zeit verbessern, wenn es mehr Daten sieht
Latenzanforderungen sind moderat (Millisekunden bis niedrige Sekunden)

Reale Beispiele (Enterprise-SaaS):

Fraud Scoring: Diese Transaktion hat eine 94 %-Wahrscheinlichkeit, betrügerisch zu sein, basierend auf 47 Features (Betragsanomalie, Änderung des Kundenverhaltens, Timing-Muster, Formatunregelmäßigkeiten). Trainiert auf historisch bestätigten Betrugsfällen.
Dokumentenklassifikation: Ist dies ein Auftrag, eine Gutschrift, ein Kontoauszug oder eine Erinnerung? Trainierter Klassifikator auf Dokumentstruktur und Inhaltsfeatures.
Kunden-Risiko-Scoring: Zusammengesetzter Score basierend auf Transaktionshistorie, Häufigkeit von Kontodatenänderungen, geografischen Risikofaktoren. Gradient-Boosted-Modell auf strukturierten Kundenstammdaten.
Betragsanomalie-Erkennung: Dieser Auftragsbetrag liegt 3,7 Standardabweichungen vom historischen Mittelwert des Kunden entfernt. Statistisches Modell, kein LLM.
Demand Forecasting: Prognostiziertes Auftragsvolumen nach Kategorie für die nächsten 30 Tage. Zeitreihenmodell für Kapazitätsplanung.

Implementierung:

XGBoost/LightGBM für tabellarische Daten (immer noch die beste Wahl 2026 für strukturierte Features)
PyTorch für komplexe Muster (bildbasierte Dokumentenklassifikation, Sequenzmodelle)
Feature Stores (Feast, Tecton) für konsistentes Feature Serving
MLFlow oder W&B für Experiment-Tracking und Model Registry
Monitoring: Evidently AI oder Custom Dashboards für Drift-Erkennung

Kosten: Training-Compute (periodisch), Inferenz-Compute (niedrig pro Vorhersage) und laufendes Data Labeling.

Stufe 3: LLM-Agenten

Wann einsetzen: Natürliche Sprachverarbeitung, komplexes Reasoning, mehrstufige Workflows und Probleme, bei denen der Eingaberaum zu breit oder unstrukturiert für die ersten beiden Stufen ist.

LLMs glänzen, wenn Flexibilität, Kreativität oder die Fähigkeit gebraucht wird, neuartige Eingaben elegant zu behandeln. Aber sie erfordern Guardrails, Evaluierungs-Frameworks und Human-in-the-Loop-Fallbacks.

Eigenschaften:

Eingaben sind unstrukturiert (natürliche Sprache, variierende Dokumentformate)
Die Aufgabe erfordert Reasoning, nicht nur Mustererkennung
Neuartige Eingaben werden erwartet und müssen elegant behandelt werden
Qualität kann evaluiert, aber nicht auf eine einfache Metrik reduziert werden
Kosten- und Latenztoleranz ist höher

Reale Beispiele (Enterprise-SaaS):

Dokumentdatenextraktion: Ein unstrukturiertes PDF-Dokument lesen und Kundenname, Dokumentnummer, Datum, Positionen, Beträge, Steuer, Währung extrahieren. Die Variation in Dokumentformaten macht das mit Regeln oder traditionellem ML unpraktisch. LLMs handhaben neue Formate Zero-Shot.
Unterstützung bei der Ausnahmeklärung: “Dieser Auftrag von Acme Corp hat eine 15 % Preisabweichung auf Position 3. Hier sind der Originalvertrag, die Bestätigung und die Preisliste des Kunden. Was ist die wahrscheinliche Erklärung und empfohlene Aktion?” Multi-Dokument-Reasoning.
Kundenkommunikation: Eine E-Mail an einen Kunden entwerfen, die ein korrigiertes Dokument anfordert, unter Bezugnahme auf die spezifische Diskrepanz und relevante Auftragsnummern. Natürliche Sprachgenerierung mit Domain-Kontext.
Kostenzuordnung für Ad-hoc-Aufträge: “Dies ist ein Auftrag einer Beratungsfirma für ‘strategische Beratungsleistungen Q4 2025.’ Basierend auf historischen Zuordnungsmustern und der Kostenstruktur, empfehle die Kostenstelle und Kategorie.” Erfordert Verständnis sowohl des Auftragsinhalts als auch der Organisationsstruktur.
Helpdesk-Anfragen-Bearbeitung: “Warum wurde mein Auftrag abgelehnt?” Erfordert Verständnis der spezifischen Auftragshistorie, der geltenden Geschäftsregeln und Erklärung in einfacher Sprache.

Implementierung:

Claude Opus/Sonnet via API für komplexe Reasoning-Aufgaben
GPT-4o oder Gemini 2.5 Flash für hochvolumige Aufgaben niedrigerer Komplexität
MCP-Server für Tool-Integration (Datenbank-Lookups, Backend-System-Abfragen, E-Mail-Versand)
Structured Output (JSON Schema) für zuverlässige Datenextraktion
RAG-Pipeline zur Verankerung von Antworten in Organisationsdaten
Guardrails: Output-Validierung, Konfidenzschwellen, Human-in-the-Loop für risikohohe Entscheidungen
Evaluierung: Automatisierte Test-Suites, LLM-as-Judge, menschliches Sampling

Kosten: Deutlich höher pro Transaktion als Stufe 1 und 2. Token-Kosten, Latenz (Sekunden statt Millisekunden) und Evaluierungsinfrastruktur.

Das Entscheidungs-Framework

Die Hierarchie ist bewusst gewählt: Immer bei Stufe 1 beginnen und nur hochgehen, wenn das Problem es wirklich erfordert. Jede Stufe bringt mehr Fähigkeit, aber auch mehr Komplexität, Kosten, Latenz und Unvorhersagbarkeit.

Kann das Problem mit deterministischen Regeln gelöst werden?
├── JA → Stufe 1. Hier stoppen. Nicht over-engineeren.
└── NEIN → Gibt es strukturierte Daten mit gelabelten Ergebnissen?
    ├── JA → Stufe 2. Ein Modell trainieren. Überwachen.
    └── NEIN → Erfordert es Sprachverständnis oder Reasoning?
        ├── JA → Stufe 3. Ein LLM mit Guardrails einsetzen.
        └── NEIN → Das Problem überdenken. Vielleicht braucht es keine KI.

Häufige Fehler

Over-Tiering: Ein LLM für etwas nutzen, das ein Regex könnte. Ich habe Teams gesehen, die GPT-4 zur Validierung von E-Mail-Formaten nutzen. Nicht machen.

Under-Tiering: 5.000 Regeln schreiben für etwas, das von Natur aus ein Mustererkennungsproblem ist. Wenn das Regelwerk auf hunderte von if/else-Verzweigungen mit abnehmender Genauigkeit angewachsen ist, ist es Zeit für Stufe 2.

Stufe 2 überspringen: Direkt von Regeln zu LLMs gehen, weil ML “schwieriger scheint.” Trainierte Modelle sind dramatisch günstiger, schneller und vorhersagbarer als LLMs für Klassifikations- und Scoring-Aufgaben. Die Investition in Trainingsdaten und MLOps zahlt sich schnell aus.

Keine Fallback-Kette: Die besten produktiven Systeme nutzen die Stufen als Fallback-Kette. Stufe 1 bearbeitet die einfachen Fälle (60 % des Volumens). Stufe 2 bearbeitet die mustererkennbaren Fälle (30 %). Stufe 3 bearbeitet den komplexen Rest (10 %). Das LLM sieht nur die Fälle, die wirklich seine Fähigkeiten brauchen, was Kosten überschaubar und Qualität hoch hält.

Stufen-Interaktion in der Praxis

Die Stufen arbeiten nicht isoliert. In einem realen System:

Dokument trifft ein → Stufe 1 validiert Format, prüft auf Exakt-Match-Duplikate
Datenextraktion → Stufe 3 (LLM) extrahiert strukturierte Daten aus unstrukturiertem Dokument
Fraud Scoring → Stufe 2 (ML-Modell) bewertet die extrahierten Daten gegen historische Muster
Validierung → Stufe 1 führt regelbasierte Validierung mit deterministischen Regeln durch
Ausnahme-Routing → Stufe 1 (Regeln) routet basierend auf Ausnahmetyp und konfigurierten Workflows
Ausnahme-Klärung → Stufe 3 (LLM) unterstützt menschliche Prüfer mit Analysen und Empfehlungen
Genehmigung → Stufe 1 (Regeln) setzt Genehmigungsmatrix basierend auf Betrag und Entität durch

Jede Stufe macht, was sie am besten kann. Die Orchestrierungsschicht ist deterministisch (Stufe 1) — man will immer vorhersagbaren Kontrollfluss, auch wenn einzelne Schritte ML oder LLMs nutzen.

Kosten- und Performance-Vergleich

	Stufe 1: Regeln	Stufe 2: ML	Stufe 3: LLM
Latenz	<1 ms	1-100 ms	1-30 s
Kosten/Transaktion	~0 $	~0,001 $	0,01-0,50 $
Genauigkeit	100 % (für definierte Fälle)	90-99 % (messbar)	85-98 % (schwerer zu messen)
Umgang mit neuartigen Eingaben	Scheitert bei undefinierten Fällen	Degradiert elegant	Behandelt neuartige Eingaben gut
Erklärbarkeit	Perfekt	Moderat (SHAP, LIME)	Niedrig (kann erklären, aber kann konfabulieren)
Setup-Kosten	Niedrig	Mittel (Daten + Training)	Niedrig (API-Aufruf)
Wartung	Regel-Updates	Retraining, Monitoring	Prompt-Versionierung, Eval

Die besten produktiven KI-Systeme nutzen alle drei Stufen im Zusammenspiel, mit klaren Grenzen und Übergabepunkten zwischen ihnen. Einfach beginnen, Intelligenz nur dort hinzufügen, wo sie gebraucht wird, und immer einen deterministischen Fallback haben.