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.
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. Wenn ein Chatbot falsch antwortet, liest ein Mensch die Antwort und kann sie verwerfen. Wenn ein Agent falsch handelt, steht das Ergebnis in den Systemen: der falsch eingeordnete Fall, der falsche Eintrag in der Kundenakte, die Freigabe, die nie hätte vorbereitet werden dürfen.
Dann reicht es nicht mehr, ein gutes Modell auszuwählen.
Dann braucht es Architektur.
Ein KI-Modell kann eine Antwort erzeugen, die formal korrekt ist und trotzdem fachlich falsch. Ob die Form der Antwort stimmt, lässt sich automatisch prüfen. Ob ihr Inhalt fachlich stimmt, nicht. Ein Tool-Aufruf läuft technisch erfolgreich durch, hätte aber nie ausgelöst werden dürfen. Und früher reichte ein Blick ins Monitoring, um zu sehen, ob der Server noch läuft. Dass sich Modellverhalten schleichend verändert, sieht man dort nicht.
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:
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.
Der Agent Contract beschreibt, was ein AI-Feature darf, erwartet, nutzt und beweisen muss. Er bündelt fünf Bestandteile zu einem Paket.
Eine neue Contract-Version bedeutet: Das Verhalten des Features hat sich geändert. Also wird sie versioniert, reviewt und gegen Evals geprüft. Engineering liefert die Form. Der Fachbereich liefert die Maßstäbe.
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?“
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.
Sobald ein Modell Werkzeuge nutzt, bekommt es Wirkung. Lesen kann Daten offenlegen. Schreiben kann Schäden erzeugen. Und entscheidet es selbst, ist plötzlich unklar, wer dafür geradesteht.
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.
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.
Ohne diese Signale ist Betrieb nur Hoffnung.
Modelle werden handlungsfähiger.
Unternehmen verschieben KI aus Experimenten in Kernprozesse.
Damit entsteht ein neues Feld zwischen Softwarearchitektur, Produktentwicklung, Fachdomäne, UX, Betrieb und Governance.
Eine eigene Disziplin, kein Anbau an die Softwarearchitektur: Was Softwarearchitektur für die Softwareentwicklung ist, ist AI Systems Architecture für das AI Engineering.
Ihr Fachwissen, Ihre Erfahrung und Ihre Maßstäbe werden Teil des Systems: Labels, Grenzen, Eskalationen, Tonalität, fachliche Korrektheit.
Modellverhalten wird versioniert, getestet, deployed und beobachtet wie anderer produktiver Code.
AI-Features skalieren nur dann, wenn Risiko, Kosten und Wertbeitrag sichtbar werden.
Aus einzelnen Experimenten wird schnell ein Portfolio mit Ownern, Datenflüssen, Risikoklassen und Incident-Pfaden.
Sie hilft Teams, AI-Features so zu bauen, dass sie:
Das Ziel ist, der KI mehr Verantwortung geben zu können, ohne ihr blind zu vertrauen.
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.
Diese Seite skizziert das Feld. Wer tiefer einsteigen will, findet in den folgenden Texten die einzelnen Praktiken ausführlich diskutiert: mit konkreten Beispielen, offenen Fragen und den Stellen, an denen es schwierig wird.