AI Systems Architecture.

KI verlässt das Chatfenster. Jetzt wird sie Teil der Produktlogik.

Agentische KI liest Dokumente, versteht Fälle, beschafft Kontext, ruft Werkzeuge auf und stößt Aktionen an. Damit entstehen neue Chancen für Software, aber auch neue Anforderungen an Architektur.

AI Systems Architecture ist die Disziplin für diesen Übergang: von plausiblen Modellantworten zu AI-Features, die messbar, begrenzt und betreibbar sind.

Symbolbild AI-Feature als Systemkarte: Eingaben, Modell, Kontext, Tools, Produktlogik im Rahmen aus Contract, Evals, Observability und Safety.

Software konnte lange nur das verarbeiten, was vorher sauber strukturiert war: Formulare, Datenbankfelder, Regeln, Workflows.

Agentische KI verschiebt diese Grenze. Sie kann Freitext, PDFs, Transkripte, Bilder und unklare Fälle aufnehmen. Sie kann Informationen suchen, Fälle einordnen, Vorschläge machen und Systeme bedienen.

Das ist die Chance: Prozesse, die heute zwischen Postfach, Fachwissen und Fachsystemen stecken, werden plötzlich automatisierbar.

Aber genau hier entsteht der Bruch. Ein Chatbot, der falsch antwortet, ist ein Kommunikationsproblem. Ein Agent, der falsch klassifiziert, falsch schreibt oder eine Freigabe vorbereitet, verändert den Zustand des Unternehmens.

Dann reicht es nicht mehr, ein gutes Modell auszuwählen. Dann braucht es Architektur.

01 Eine neue Klasse von Fehlern

Aus Modelloutput wird Produktverhalten.

Ein Modell kann eine Antwort erzeugen, die formal korrekt ist und trotzdem fachlich falsch. Ein JSON validiert gegen das Schema, aber die Entscheidung dahinter stimmt nicht. Ein Tool-Call läuft erfolgreich durch, hätte aber nie ausgelöst werden dürfen. Ein System bleibt online, während sein Verhalten langsam driftet.

Diese Fehlerklasse ist neu genug, dass klassische Softwarepraktiken allein nicht ausreichen. Sie müssen ergänzt werden.

AI Systems Architecture fragt deshalb nicht nur „Was kann das Modell?“, sondern:

  • 01 Was darf es tun?
  • 02 Woran messen wir richtiges Verhalten?
  • 03 Wer entscheidet bei Unsicherheit?
  • 04 Wie merken wir, dass es schlechter wird?
  • 05 Wie stoppen wir es, wenn es schadet?
Symbolbild Übergang von Modellantwort zu Produktverhalten.
02 Was das Feld zusammenhält

AI Systems Architecture verbindet sechs Praktiken.

Symbolbild Bündel aus Bestandteilen, die gemeinsam Verhalten erzeugen.

No. 01

Verhalten wird explizit gemacht

AI-Features entstehen nicht aus einem Prompt allein. Verhalten entsteht aus Prompt, Schema, Kontext, Tools, Modellwahl und Evals. Wer eines davon ändert, verändert das Ganze.

Darum braucht ein AI-Feature ein Artefakt, das dieses Verhalten zusammenhält.

Symbolbild Agent Contract als Karte mit Prompt, Schema, Tools, Modell und Evals.

No. 02

Der Agent Contract wird zum Kernartefakt

Der Agent Contract beschreibt, was ein AI-Feature darf, erwartet, nutzt und beweisen muss. Er bündelt fünf Bestandteile zu einem Paket.

  • Output-Schema
  • Prompt
  • erlaubte Tools
  • Modell und Provider
  • Eval-Set

Eine neue Contract-Version bedeutet: Das Verhalten des Features hat sich geändert. Also wird sie versioniert, reviewt und gegen Evals geprüft. Der Contract gehört nicht nur ins Engineering. Welche Kategorien ein Fall haben darf, welche Eskalation nötig ist und welche Antwort fachlich richtig ist, entscheidet die Domäne. Engineering liefert die Form. Der Fachbereich liefert die Maßstäbe.

Symbolbild Kontextfluss aus Unternehmensquellen in eine Anfrage.

No. 03

Kontext ersetzt Bauchgefühl

Ein Modell kennt Sprache und Weltwissen. Es kennt nicht automatisch die aktuelle Kundenakte, die interne Richtlinie oder die fachliche Auslegung im Unternehmen.

Grounding bringt den richtigen Kontext zur Anfrage. Damit verschiebt sich die Architekturfrage: Nicht nur das Modell muss gut sein. Auch Suche, Quellen, Aktualität und Berechtigungen entscheiden über Qualität.

Gute AI-Systeme fragen nicht nur „Was könnte plausibel sein?“. Sie fragen: „Welche belegten Informationen darf das Modell für diesen Fall nutzen?“

Symbolbild Eval-Set mit wiederholten Messungen.

No. 04

Evals ersetzen Demo-Vertrauen

Im Chat ausprobieren zeigt nur, dass es einmal funktioniert hat.

Produktionsreife braucht Evals: echte Fälle, erwartete Ergebnisse, fachliche Labels und wiederholbare Messung. Bei jeder Änderung an Prompt, Schema, Modell oder Tools läuft das Feature gegen diese Beispiele.

So wird Qualität nicht behauptet, sondern verfolgt. Nicht perfekt, aber sichtbar, vergleichbar, verbesserbar.

Symbolbild Werkzeuge mit Grenzen und Freigabewegen.

No. 05

Aktionen bekommen Grenzen

Sobald ein Modell Werkzeuge nutzt, bekommt es Wirkung. Lesen kann Daten offenlegen. Schreiben kann Schäden erzeugen. Entscheiden kann Verantwortung verschieben.

Darum brauchen Tools klare Grenzen: Owner, Rechte, Risikoklasse, Audit-Trail, Abschaltweg. Manche Aktionen laufen autonom. Manche brauchen Freigabe. Manche gehören gar nicht in die Hände eines Modells.

Das ist keine Bremse. Es ist die Voraussetzung dafür, dass AI-Features mehr dürfen.

Symbolbild Dashboard mit Betriebsmetriken eines AI-Features.

No. 06

Betrieb wird Teil des Designs

Ein AI-Feature kann schlechter werden, ohne dass jemand Code geändert hat. Eingaben verändern sich. Modellversionen ändern sich. Datenquellen altern. Tool-Antworten driften.

Deshalb müssen AI-Features im Betrieb sichtbar bleiben.

  • Welche Modellversion läuft?
  • Wie oft scheitert das Schema?
  • Wie oft korrigieren Menschen?
  • Wie hoch sind Latenz und Kosten?
  • Welche Fälle eskalieren?

Ohne diese Signale ist Betrieb nur Hoffnung.

Symbolbild Übergang von Experiment in produktiven Kernprozess.
03 Warum jetzt

Modelle werden handlungsfähiger. Unternehmen verschieben KI aus Experimenten in Kernprozesse. Teams bauen nicht mehr nur Chatbots, sondern AI-Features mit Zugriff auf Daten, Workflows und Fachsysteme.

Damit entsteht ein neues Feld zwischen Softwarearchitektur, Produktentwicklung, Fachdomäne, Betrieb und Governance.

Nicht als Ersatz für klassische Architektur. Sondern als Erweiterung dort, wo Verhalten nicht mehr vollständig durch deterministischen Code entsteht.

04 Vier Rollen tragen die Disziplin
01

Fachbereich

Ihre Maßstäbe werden Teil des Systems: Labels, Grenzen, Eskalationen, Tonalität, fachliche Korrektheit.

02

Engineering

Modellverhalten wird versioniert, getestet, deployed und beobachtet wie anderer produktiver Code.

03

Führung

AI-Features skalieren nur dann, wenn Risiko, Kosten und Wertbeitrag sichtbar werden.

04

Betrieb und Governance

Aus einzelnen Experimenten wird schnell ein Portfolio mit Ownern, Datenflüssen, Risikoklassen und Incident-Pfaden.

05 Was die Disziplin leistet

AI Systems Architecture macht agentische KI produktfähig.

Sie hilft Teams, AI-Features so zu bauen, dass sie:

  • fachlich gebunden sind,
  • messbar besser werden,
  • sichere Grenzen haben,
  • im Betrieb beobachtbar bleiben,
  • und in der Organisation verantwortet werden können.

Das Ziel ist nicht, KI kleinzuhalten.

Das Ziel ist, ihr mehr Verantwortung geben zu können, ohne blind zu werden.

06 Die Disziplin in zwei Sätzen

AI Systems Architecture ist die Disziplin für Software, in der KI nicht nur antwortet, sondern handelt.

Sie verbindet Modell, Kontext, Prompt, Schema, Tools, Evals, Human-in-the-Loop, Observability und Governance zu AI-Features, deren Verhalten nachvollziehbar, messbar und begrenzbar ist.

07 Das Feld auf einer Karte

Sechs Segmente, ein Feld.

01

Model Behavior

Prompt, Modellwahl, Kontext, strukturierter Output.

02

Agent Contract

Versionierung, Ownership, fachliche Freigabe.

03

Evaluation

Eval-Sets, Labels, Regression, Mehrfachläufe.

04

Action Safety

Tool-Rechte, Approvals, Sandbox, Audit.

05

Operations

Traces, Drift, Kosten, Latenz, Korrekturquote.

06

Portfolio Governance

Register, Risikoklassen, Datenflüsse, Incident-Pfade.