AI Systems Architecture

• Sie liest Eingaben in beliebiger Form: Freitext, PDF, Foto, Transkript.
• Sie beschafft Kontext, klassifiziert Fälle und bereitet Entscheidungen vor.
• Sie löst über Werkzeuge Aktionen aus und verändert damit den Zustand angrenzender Systeme.
• An dieser Stelle wird Modelloutput Teil der Produktlogik.

Diese Verschiebung ist der Anlass für die ganze Disziplin. In der Langfassung in den Kapiteln 1 und 5 beschrieben.

• Klassische Software ist eine Funktion: gleiche Eingabe, gleiche Ausgabe, wiederholbar.
• Ein LLM antwortet auf dieselbe Anfrage je nach Zustand und Kontext unterschiedlich.
• Was es ausgibt, klingt plausibel; ob es in der Domäne richtig war, fällt oft erst spät auf.

Diese Eigenschaft ist nicht reparierbar, sondern Teil der Architektur, mit der wir umgehen.

• Ein JSON validiert sauber gegen das Schema, die Entscheidung dahinter ist in der Domäne nicht haltbar.
• Eine Aktion läuft erfolgreich durch, hätte unter den geltenden Regeln nie ausgelöst werden dürfen.
• Ein Modell bleibt erreichbar, sein Verhalten driftet über die Zeit.
• Halluzinationen sind nur die sichtbare Spitze dieser Klasse, nicht ihr ganzer Umfang.

Genau wegen dieser Fehlerklasse reichen klassische Tests und Reviews nicht aus; dafür gibt es die folgenden Sektionen.

• Ein Chatbot, der falsch antwortet, erzeugt ein Kommunikationsproblem, das ein Mensch noch einfangen kann.
• Ein Agent, der falsch klassifiziert oder schreibt, verändert den Zustand des Unternehmens.
• Viele Organisationen bleiben deshalb beim Chatbot stehen, obwohl die Modelle inzwischen mehr könnten.
• Was fehlt, sind selten stärkere Modelle. Es fehlt eine Disziplin, die Verhalten mess- und begrenzbar macht.

• Fünf Teile bestimmen gemeinsam das Verhalten: Prompt, Schema, Werkzeuge, Modell- und Provider-Wahl, Eval-Set.
• Jeder dieser Teile verschiebt das Verhalten der anderen.
• Wer eines davon allein verändert, verändert das Ganze, ohne es aus dem Code allein sehen zu können.
• Wir versionieren das Paket als Ganzes und nennen es Agent Contract.

Eine neue Contract-Version umfasst immer alle fünf Bestandteile und durchläuft die Eval-Pipeline, bevor sie produktiv geht.

• Welche Kategorien ein Fall annehmen darf, ist eine fachliche Entscheidung.
• Welche Eingaben eine Eskalation auslösen, ist eine fachliche Entscheidung.
• In welcher Tonalität geantwortet wird, ist eine fachliche Entscheidung.
• Engineering bringt die Form (Schema, Werkzeuge, Pipeline), Fachexperten bringen den Inhalt (Beispiele, Labels, Regeln).
• Beide Seiten halten das Artefakt gemeinsam.

• Im Chat ausprobieren zeigt, dass es einmal funktioniert hat, nicht, dass es im Betrieb trägt.
• Ein Eval-Set besteht aus echten Sources (Anfragen, Dokumenten, Transkripten) und den dazu fachlich gesetzten Labels.
• Es läuft automatisiert in der Pipeline bei jeder Änderung an Prompt, Schema, Modell oder Werkzeugen.
• Da dasselbe Modell auf dieselbe Eingabe nicht immer identisch antwortet, sind Mehrfachläufe nötig.
• Eine neue Contract-Version geht erst dann live, wenn das Eval-Set sie freigibt.

• Stille Modell-Updates, Drift in den Eingaben und veränderte Tool-Antworten verschieben das Verhalten unbemerkt.
• Beobachtbar sein müssen mindestens Modellversion, Schema-Fehlerrate, Korrekturquote, Latenz und Token-Kosten.
• Alarme reagieren auf statistische Auffälligkeiten in diesen Werten, nicht auf einzelne Fehlanfragen.
• Ohne diese Beobachtung gibt es kein verlässliches Bild davon, ob ein Feature noch in Spezifikation arbeitet.

• Lesende und schreibende Werkzeuge gehören bewusst getrennt; ihr Schadenspotenzial ist ein anderes.
• Jedes Werkzeug ist ein Vertrag mit Owner, Risikoklasse und Abschaltweg.
• Neue Contract-Versionen laufen Sandbox, dann Shadow, dann produktiv.
• Mutierende Aktionen mit hohem Risiko brauchen menschliche Freigabe und Audit-Trail.
• Das Modell selbst ist keine Sicherheitsgrenze; Rechteprüfungen und Filter sitzen außerhalb.

Welche Entscheidungen ein Agent allein treffen darf und welche eine menschliche Prüfung brauchen, ist eine Architektur- und UX-Frage, keine Optimismusfrage.

• Was die Organisation verlässt, welche Anteile beim Anbieter bleiben und wer Zugriff hat, gehört dokumentiert.
• Personenbezogene Daten dürfen nicht ungefiltert in einen Prompt; Filter oder Pseudonymisierung sitzen im Code vor dem Modell-Aufruf.
• Anbieter sitzen in unterschiedlichen Rechtsräumen (EU, USA, On-Prem), und die Wahl ist Teil der Architekturentscheidung.

Der EU AI Act macht diese Transparenz für viele AI-Systeme verbindlich, unabhängig vom genauen Stichtag.

• Jeder Aufruf, jeder Tool-Call und jeder zusätzliche Kontext schlägt sich in Eingangs- und Ausgangs-Tokens nieder.
• Größere Modelle erhöhen Qualität, Latenz und Preis selten linear.
• Die nutzbringende Frage lautet meist nicht „welches ist das beste Modell“, sondern „welches reicht für diesen Fall“.
• Agenten in Schleifen können in kurzer Zeit hohe Rechnungen erzeugen; Budget-Limits gehören zur Grundausstattung.
• Kosten werden pro Feature sichtbar gemacht, damit Teams Routing, Caching und Modellwahl bewusst gestalten können.

• Ohne zentrale Sichtbarkeit entsteht Shadow AI: Features, die niemand inventarisiert und im Notfall niemand stoppen kann.
• Ein Register listet aktive Features mit Owner, Provider, Eval-Stand und Datenflüssen, gepflegt von den Teams selbst.
• Risikoklassen entscheiden, welche Freigabewege ein Feature durchläuft.
• Ein interner Summarizer ist nicht dasselbe wie ein Agent mit Schreibzugriff auf das CRM.
• Für Vorfälle existiert ein dokumentierter Pfad mit Rollback, Kommunikation und Verantwortlichen, bevor der erste Vorfall eintritt.

Governance ist so geschnitten, dass dezentrale Teams in der Breite arbeiten können. Wo sie als Bremse erlebt wird, sind die Prozesse zu schwer.

• Fachbereich wird Co-Owner des Verhaltens, nicht nachgelagerter Tester.
• Engineering versioniert, testet und betreibt Modellverhalten mit derselben Sorgfalt wie übrige Produktionssysteme.
• Führung sieht Risiko, Kosten und Wertbeitrag entlang der Features, bevor sie zur Eskalation werden.
• Betrieb hat Pfade für Fehler, Drift und Vorfälle und ist nicht auf zufällige Beschwerden angewiesen.

• Prompt Engineering optimiert einzelne Anfragen. AI Systems Architecture bindet ein System, dessen Verhalten messbar bleibt.
• Agentic Software Engineering nutzt KI als Werkzeug beim Bauen klassischer Software; hier wird KI selbst Teil der Produktlogik.
• Wir ergänzen klassische Softwarearchitektur dort, wo Verhalten nicht mehr vollständig durch deterministischen Code entsteht, und ersetzen sie nicht.

Modelle, Provider und Tooling verändern sich weiter. Die Architekturprinzipien wachsen mit, sind aber nicht beliebig.