Der "Runtime Compiler": Wie wir KI für die "Last-Mile"-Logik nutzen

Das Dashboard-Dilemma

Wer schon einmal ein Enterprise-Dashboard entworfen hat, kennt das fundamentale Problem: Egal wie viele Metriken wir hart codieren, die entscheidende Frage des C-Levels kommt immer nach dem Deployment.

"Wie hoch ist der Umsatz?" ist eine statische Frage. Dafür bauen wir GET /revenue. Das ist solide Ingenieursarbeit. Doch die Realität in Unternehmen ist dynamisch: "Wie korreliert der Umsatz mit dem Wetter in Region Nord im Vergleich zum Vorjahr?"

Hier stoßen wir auf ein strategisches Trade-off. Stabilitäts-fokussierte Architekten haben absolut recht, wenn sie zögern, solche Logiken ad-hoc zu implementieren. Fest verdrahtete Pipelines garantieren Datenintegrität, Compliance und Vorhersehbarkeit. Es ist vernünftig und notwendig, dass Banken und Konzerne ihre Kernsysteme (Core Ledger) gegen externe Einflüsse abschotten.

Doch genau hier entsteht das, was ich als "Efficiency Gap" bezeichne. Um jede neue Business-Frage zu beantworten, müssen wir einen Ticket-Prozess durchlaufen: Anforderung -> SQL-Schema -> API-Endpunkt -> Frontend-Update -> Deployment. Bis das Dashboard live ist, ist die Frage oft schon irrelevant.

Mein Vorschlag ist kein Ersatz der klassischen Architektur, sondern ein hybrides Modell: Der "Runtime Compiler".

Wir behalten den harten Code für Schreibzugriffe und Sicherheit. Aber wir nutzen KI als dynamische Logikschicht für die "letzte Meile" der Datenanalyse – streng isoliert und kontrolliert.

Die Sicherheits-Grenze: Read-Only Analysis

Bevor wir über die Technologie sprechen, müssen wir die Risiko-Grenze definieren (Cover Your Ass). Der größte Einwand gegen KI im Backend ist die Unvorhersehbarkeit. Niemand möchte, dass eine LLM Schreibrechte auf die Produktionsdatenbank hat.

Die Architektur, die ich vorschlage, basiert auf einer strikten Trennung:

1. Core Systems (Write/Critical): Bleiben deterministischer, handgeschriebener Code.
2. Runtime Logic (Read-Only/Insight): Hier agiert die KI. Sie darf lesen, analysieren und Code zur Ausführung in einer Sandbox generieren, aber niemals den Systemzustand verändern.

In diesem Modell fungiert die KI nicht als "Chatbot", sondern als Just-in-Time-Compiler, der Business-Fragen in temporäre, ausführbare Logik übersetzt.

Der Blueprint: Agentic Orchestration Layer

Ich habe dieses Konzept im letzten Jahr in eine Open-Source-Referenzarchitektur gegossen (Agentic Orchestration Layer Model auf GitHub).

Der Ansatz löst sich von der starren "Middleware"-Denkweise. Anstatt für jede denkbare Frage ein "Rohr" zu verlegen, stellen wir dem System Werkzeuge zur Verfügung, um die Verbindung zur Laufzeit selbst zu löten. Dies basiert auf drei Prinzipien, die das Risiko minimieren:

1. CAG statt RAG (Deterministische Exekution)

Klassisches RAG (Retrieval Augmented Generation) ist für Enterprise-Daten oft zu ungenau. Textzusammenfassungen sind "fuzzy". Wir nutzen stattdessen CAG (Code Augmented Generation). Wenn eine komplexe Anfrage reinkommt, rät das Modell nicht das Ergebnis. Es schreibt ein Python-Skript oder eine SQL-Query. Dieser Code wird nicht direkt ausgeführt, sondern in eine isolierte Sandbox (z.B. E2B) geleitet. Das Ergebnis ist Mathematik, keine Halluzination.

2. System 2 Thinking (Die Validierungs-Schicht)

Wir nutzen Modelle wie Gemini 3 Pro mit aktiviertem ThinkingLevel.HIGH. Das System antwortet nicht impulsiv (System 1). Es tritt in einen internen "Reasoning Loop" ein, bevor es eine Zeile Code generiert. In dieser Phase prüft es:

• Darf ich auf diese Daten zugreifen? (Policy Check).
• Ist die generierte SQL-Query syntaktisch korrekt?
• Habe ich die Sicherheitsgrenzen eingehalten?

3. Environments als Konfiguration

Anstatt auf fragile "Personas" ("Du bist ein netter Assistent") zu setzen, definieren wir Environments durch harte Konfigurationsdateien (Markdown/JSON):

• Physik: Verfügbare Tools (SQL-Zugriff: Ja/Nein, Python: Ja/Nein).
• Verfassung: safety_policy.md (z.B. "Keine Ausgabe von PII-Daten").
• Geografie: database_schema.md (Die Karte der Daten).

Dies erlaubt uns, das gleiche "Gehirn" in verschiedenen Sicherheitszonen einzusetzen, indem wir nur die Umgebungsvariablen ändern.

Vertrauen durch Triangulation

Selbst mit den besten Prompts bleibt ein Restrisiko. In der Finanzwelt ist "wahrscheinlich richtig" nicht gut genug. Um dies zu mitigieren, implementieren wir ein Triangulation Protocol (siehe Grafik im Repo). Dies ist vergleichbar mit der doppelten Buchführung.

Wenn das System eine kritische Metrik berechnet, erzwingen wir zwei unabhängige Lösungswege:

1. Pfad A (Datenbank): Generierung einer SQL-Query.
2. Pfad B (Algorithmus): Laden der Rohdaten in die Python-Sandbox und Neuberechnung mittels Pandas/NumPy.

Das System vergleicht beide Ergebnisse. Weichen sie voneinander ab (z.B. > 1%), wird die Antwort verworfen. Diese Redundanz macht das System "Anti-Fragil". Es verlässt sich nicht auf die Annahme, dass das Modell beim ersten Versuch recht hat, sondern beweist die Richtigkeit durch Konsens.

Fazit: Das Ende der "Legacy Habits"

Wir stehen an einem Punkt, an dem wir unsere Rolle als Architekten neu bewerten müssen. Das manuelle Schreiben von CRUD-Endpunkten für Reporting-Zwecke ist eine ineffiziente Nutzung unserer Zeit. Es bindet Ressourcen, die wir für die Härtung der Kernsysteme benötigen.

Der strategische Vorteil liegt nicht darin, KI blindlings alles machen zu lassen, sondern sie dort als "Runtime Compiler" einzusetzen, wo Starrheit ein Wettbewerbsnachteil ist: Bei der Analyse und der Beantwortung von Ad-hoc-Fragen.

Wer dieses Muster ignoriert, schützt zwar seine Architektur vor Veränderung, riskiert aber, dass die Geschäftslogik zu langsam auf den Markt reagiert.

Die Empfehlung für Architekten:

1. Behalten Sie den harten Code für kritische Transaktionen bei.
2. Experimentieren Sie mit einer "Runtime Logic Layer" für Read-Only-Szenarien (siehe Repository).
3. Implementieren Sie Sandboxing und Triangulation als nicht verhandelbare Sicherheitsstandards.

Es geht nicht darum, die Kontrolle abzugeben, sondern die Ebene der Kontrolle zu erhöhen: Weg vom Mikromanagement einzelner Queries, hin zur Orchestrierung eines Systems, das Antworten generiert.