Grenzen in der KI-Architektur: probabilistische Modelle in deterministischen Systemen

Nehmen wir einen Layout-Planer aus drei modellartigen Teilen. Ein LLM liest die Anfrage des Nutzers, RAG holt die passenden Normen, und ein Graph-Attention-Netz schlägt vor, wo jedes Teil hinkommt. Keiner davon hat das letzte Wort. Eine deterministische Engine aus Regeln und Platzierungsprüfungen entscheidet, was im Layout landet, und sie legt ständig ihr Veto gegen die Vorschläge des Modells ein.

Diese Aufteilung war kein vorab gewähltes Designprinzip. Sie entstand nach einem Layout, das das Modell mit voller Überzeugung zurückgab: vier Komponenten, miteinander verbunden und übereinanderliegend – eine Geometrie, die auf einem echten Spielplatz nicht existieren kann. Kein Fehler wurde ausgelöst. Die Antwort war sauber formatiert, die Begründung las sich gut, und das Ergebnis war physikalisch unmöglich.

Beginnen wir mit dem Vertrauten

Nehmen wir ein gewöhnliches E-Commerce-Backend:

User → API Gateway → Backend Services → Database

Produktionssysteme haben Extras wie Caches, Queues, Authentifizierung, Observability und externe APIs, doch das Grundbild bleibt, und sein prägendes Merkmal ist Kontrolle. Die Anwendung bestimmt, welche Operationen laufen, welche Daten berührt werden, welche Geschäftsregeln gelten, wie mit Fehlern umgegangen wird und was Erfolg bedeutet. Wenn eine Bestellung bezahlt ist, bittet niemand einen Dienst zu interpretieren, ob das stimmt:

if order.status == "PAID":
    ship_order()

Das Programm entscheidet.

Jetzt kommt ein Modell dazu

Angenommen, ein KI-Supportassistent kommt ins System. Am ersten Tag sieht die Architektur so aus:

User → Backend → LLM API → Response

Er geht live. Bald fragt ein Kunde nach dem Status einer Bestellung, und das Modell braucht Daten, die nicht im Prompt stehen:

User → Backend → Fetch order data → Build context → LLM → Response

Dann bittet ein anderer Kunde den Assistenten, eine Bestellung zu stornieren. Jetzt muss das Modell etwas tun und nicht nur etwas sagen:

User → LLM → Decide → Call cancellation API → DB → LLM → Response

Dann kommt eine Frage, die drei getrennte Operationen braucht, und das Bild ist überhaupt keine Linie mehr.

Das Modell ist nicht mehr nur eine Abhängigkeit. Es ist Teil des Kontrollflusses geworden, und genau hier verschiebt sich die Architektur wirklich.

Probabilistische Berechnung ist der eigentliche Unterschied

Klassische Software hat diese Form:

Input → Program → Output

KI-Software sieht so aus:

Input → Context → Model → Probabilistic Output

Eine Funktion, die sich direkt testen lässt, zeigt den Kontrast:

def calculate_discount(price):
    return price * 0.9

Der Aufruf calculate_discount(100) liefert 90, und niemand braucht einen Schiedsrichter, der beurteilt, ob 90 ungefähr stimmt.

Nehmen wir eine Anfrage wie die Zusammenfassung eines Vertrags. Es gibt keinen einzig richtigen String zum Vergleichen. Stattdessen geht es bei den Prüfungen um Verhalten. Wurden alle wichtigen Klauseln abgedeckt? Wurde etwas erfunden? Ist eine Kündigungsbedingung verschwunden? Wurde ein juristischer Begriff falsch gelesen? Hilft das Ergebnis überhaupt jemandem?

Die Architektur braucht also etwas, das den meisten Systemen fehlt: Bewertung von Verhalten, nicht nur Ausführung von Code.

Auch ein 200 kann ein Fehler sein

Darüber stolpern viele Teams.

Klassisches Monitoring beginnt mit einer einfachen Regel: 200 ist gesund, 500 ist kaputt. KI-Systeme können ein 200 mit einer falschen Antwort liefern. Oder ein 200 auf Basis veralteten Kontexts. Oder ein 200, bei dem etwas Sensibles abgeflossen ist. Oder ein 200, bei dem der Agent neunzehnmal im Kreis lief und eine Rechnung angehäuft hat.

Jeder einzelne Aufruf war erfolgreich, und die Anwendung ist trotzdem gescheitert.

Statuscodes allein taugen nicht als Gesundheitssignal. Teams brauchen Latenz, Fehlerraten, Tokenverbrauch, Kosten, Retrieval-Qualität, Ausgabequalität, Tool-Aufrufe und Nutzerfeedback, verknüpft durch einen einzigen Trace.

Kontext ist eine eigene Komponente

Eine klassische App fragt, welche Daten das Programm braucht. Eine KI-App stellt eine zweite Frage: Was soll das Modell sehen?

Eine Frage zur Rückerstattungsrichtlinie braucht vielleicht die Frage selbst, die Unternehmensrichtlinie, das Kundenkonto und die letzten vier Gesprächsbeiträge.

Eine Vektordatenbank hinzuzufügen ist der einfache Teil. Schwerer ist zu entscheiden, was ins Fenster gehört, denn die Anwendung muss abwägen, wie relevant und aktuell jedes Element ist, wer es sehen darf, wie viel Platz es braucht, was die Historie sagt, was bei widersprüchlichen Quellen passiert und wie Mandanten getrennt bleiben. Kontext ist dann keine Verrohrung mehr, sondern Architektur.

Geschäftsregeln gehören nicht dem Modell

Angenommen, ein Nutzer bittet darum, sein Konto zu löschen. Eine Möglichkeit wäre, in den Prompt zu schreiben: Lösche es, wenn danach gefragt wird. Damit liegt die Grenze an der falschen Stelle. Ein besserer Ablauf:

User → Model → Intent: DELETE_ACCOUNT → Validation
     → Authorization → Business rules → Delete

Das Modell ermittelt, was der Nutzer will. Deterministischer Code entscheidet, ob das erlaubt ist.

Das Modell kümmert sich um Mehrdeutigkeit. Die Software kümmert sich um Befugnisse.

Eine neue Vertrauensgrenze

Die klassische Version hat eine Linie:

Untrusted user → Validation → Trusted application

Sobald ein Modell im Ablauf sitzt, muss auch seine Ausgabe als nicht vertrauenswürdig gelten:

User → Application → Model → Model output → Validation → Real systems

Vieles kann diese Ausgabe steuern: Nutzereingaben, abgerufene Dokumente, externe Daten, Tool-Antworten, eingeschleuste Anweisungen oder Kontext, den niemand eingeplant hat.

Wer die Modellausgabe vor der Ausführung validiert und autorisiert, bekommt ein völlig anderes System als jemand, der sie direkt ausführt.

Tools machen aus einer Anfrage einen verteilten Workflow

Ein Chat-Beitrag ist ein einzelner Modellaufruf. Ein agentischer Schritt kann eine Kette sein: Modell, Suche, Modell, API-Aufruf, Modell, noch eine Suche, Modell, Antwort.

Der Nutzer sieht eine Anfrage, das Backend führt zehn Operationen aus.

Daraus entsteht ein Observability-Problem, das einfache Request-Logs nicht lösen. Durchgehende Traces sind nötig, und nicht nur fürs Debugging. Sie beantworten, warum eine Anfrage 3 $ gekostet hat, warum der Agent dieselbe API fünfmal aufgerufen hat, welcher abgerufene Chunk zur falschen Antwort geführt hat und wohin die Latenz tatsächlich ging.

Kosten werden zur Laufzeitgrenze

Backend-Teams budgetieren bereits CPU, Speicher, Verbindungen und Bandbreite. KI bringt neue Posten: Tokens, Modellaufrufe, Kontextgröße, Tool-Aufrufe und Inferenzkosten.

Ein einzelner Agentenlauf könnte sich so aufschlüsseln:

Model    $0.02
Search
Model    $0.04
API call
Model    $0.03
Search
Model    $0.05
─────────────
Total    $0.14

Dieser Lauf kostet vierzehn Cent. Multipliziert mit Tausenden Nutzern pro Tag ist die Zahl keine Buchhaltung mehr, sondern eine Designgrenze. Deshalb bekommen Produktionssysteme Modell-Routing, Prompt-Caching, Kostenzuordnung und Budgets pro Anfrage.

Verteilte Systeme sind schon immer so mit Prozessor- und Speichergrenzen umgegangen. Hier sind Dollar, Tokens und Sekunden die Ressourcen, die jede Anfrage verbraucht.

Wiederholungen werden riskanter

Retries sind gängige Praxis. Stellen Sie sich jetzt vor, die Anfrage lautet, dem Kunden eine Rechnung zu schicken.

Das Modell ruft send_invoice() auf, und es klappt. Das Netzwerk verliert die Antwort, also wird der Aufruf wiederholt, und er klappt erneut. Der Kunde bekommt zwei Rechnungen.

Die Konzepte dahinter sind alt: Idempotenz, Timeouts, Transaktionsgrenzen, Teilausfälle und Kompensation. KI hat sie nicht erfunden. Sie hat sie zurück in die Mitte von Anwendungen geholt, die es geschafft hatten, sie zu ignorieren.

Auch das Testen ändert sich

Eine klassische Pipeline führt vom Code über Unit-Tests und Integrationstests zum Deployment. KI-Arbeit braucht daneben eine weitere Ebene, auf der Unit-Tests, Evaluierungen und Sicherheitsprüfungen den KI-Workflow vor dem Release durchspielen.

Das Verhalten kann sich verschieben, sobald sich irgendetwas davon ändert: Code, Prompt, Modell, Kontext, Retrieval oder eine Tool-Definition. Es kann null Zeilen Anwendungscode ausgeliefert werden, ein Anbieter aktualisiert ein Modell, und am Montag ist das Produkt ein anderes.

Wie die Architektur aussieht

Stellen Sie sich einen Ablauf vor, der vom Eingang durch Anwendungslogik, Kontextaufbau und Modellschicht läuft, dann durch Validierung und Richtlinien und schließlich hinaus zu den Tools. Darunter liegt ein Querschnittsband für Evaluierung, Observability, Kosten, Sicherheit, Feedback und Governance.

Das Wichtigste an diesem Bild ist einfach: Das LLM ist nicht die Architektur. Es ist eine Komponente darin.

Ist KI-Architektur wirklich anders?

Teilweise. Alles Bisherige wird weiter gebraucht: APIs, Datenbanken, Authentifizierung, Caching, Queues, Load Balancing, Retries, Transaktionen, Monitoring und Sicherheit. Nichts davon ist verschwunden.

Geändert hat sich der Typ einer Komponente:

Traditional:  deterministic → deterministic → deterministic
AI:           deterministic → PROBABILISTIC → deterministic

Dieser eine Tausch verändert alles drumherum.

Das Prinzip

Das ganze Argument lässt sich in einer Zeile zusammenfassen:

Probabilistische Intelligenz gehört in deterministische Grenzen.

Das Modell kann schließen, dass der Nutzer wahrscheinlich eine Bestellung stornieren will. Die Anwendung entscheidet, ob dieser Nutzer sie stornieren darf.

Das Modell kann behaupten, die Erstattung betrage 42 $. Der Betrag selbst sollte aus deterministischem Code kommen, etwa refund = order.amount - fees.

Das Modell kann entscheiden, dass die Erstattungs-API aufgerufen werden soll. Deterministische Software entscheidet, ob die Anfrage die Berechtigung dazu hat.

Das ist die Grenze.

Der größere Rahmen

Jahrzehntelang haben Ingenieure gelernt, Systeme vorhersehbar, testbar, beobachtbar, sicher, wiederherstellbar und skalierbar zu machen. KI macht diese Arbeit nicht zunichte. Sie fügt einen Teil hinzu, dem diese Eigenschaften von Natur aus fehlen, und der Rest des Systems muss sie liefern.

Fragen, die eine Demo nie stellt

Der bequemste Fehler ist zu glauben, es reiche, ein LLM aufzurufen. Für eine Demo reicht das, für ein Produkt nicht.

Sobald KI in einem echten System sitzt, brauchen mehrere Fragen eine Antwort, die die deterministische Version gratis beantwortet hat:

• Was soll das Modell wissen?
• Kann man seiner Ausgabe trauen?
• Was passiert, wenn es sich irrt?
• Wer darf seine Entscheidungen ausführen?
• Wie testet man Verhalten, das sich unter einem verändert?
• Wie erkennt man einen Fehler, wenn der Aufruf 200 zurückgegeben hat?
• Wie viel darf eine Anfrage kosten?
• Was passiert, wenn der Anbieter ausfällt?
• Wie stellt man einen halb fertigen Workflow wieder her?

Mehr Logik im Prompt ist nicht die Antwort. Bessere Grenzen um das Modell herum sind es.

Die KI soll sich um Mehrdeutigkeit kümmern, die Software um Gewissheit. Die Grenze dazwischen verdient sorgfältigen Bau.

Das Modell hat verstanden, was der Nutzer wollte, aber nicht, ob das Ergebnis existieren kann. Nur das Erste ist seine Aufgabe.