KI-Systemarchitektur: Erst Schnittstellen, dann Modelle

Das Modell ist der auffälligste Teil eines KI-Systems. Im Betrieb entscheidet aber die Architektur, ob sich ein Fehler eingrenzen, ein Anbieter wechseln und eine Antwort nachvollziehen lässt. Wer zuerst ein Modell auswählt und danach den Prozess darum baut, koppelt Geschäftslogik gerne mal an eine API, die sich schneller verändert als der eigene Betrieb.

Ich beginne deshalb mit den Schnittstellen. Welche Eingabe kommt an? Welches Ergebnis braucht der nächste Schritt? Welche Fehlerfälle muss der Ablauf unterscheiden? Erst wenn diese Verträge stehen, wird entschieden, ob ein Modell, eine klassische Regel oder eine Kombination daraus die Aufgabe übernimmt.

Das Modell ist ein austauschbares Bauteil

Ein Modell verarbeitet Sprache und trifft Wahrscheinlichkeitsentscheidungen. Es sollte weder die einzige Quelle für Unternehmenswissen sein noch selbst über alle Folgen seiner Ausgabe entscheiden. Diese Trennung macht einen Anbieterwechsel möglich und begrenzt Fehler.

In einem einfachen Beratungssystem können vier Bereiche unabhängig voneinander bleiben:

Geschäftslogik kennt Produkte, Freigaben und erlaubte Aktionen.
Wissen liefert freigegebene Inhalte mit stabilen IDs und Herkunft.
Modellzugriff übersetzt eine Aufgabe in das Format des jeweiligen Anbieters.
Auslieferung zeigt Text, Quellen, Status und Fehler an.

Diese Grenze ist wichtiger als die Frage, welches Modell aktuell in einem Benchmark vorne liegt. Ein Modellwechsel darf keine Produktpreise, Berechtigungen oder URL-Struktur verändern. Wenn er das doch tut, sitzt zu viel Geschäftslogik im Prompt.

Anthropic beschreibt in Building effective agents, warum einfache, kombinierbare Muster oft besser funktionieren als komplexe Agenten-Frameworks. Das deckt sich mit meiner Arbeit: Ein kleiner Router mit klaren Ein- und Ausgaben lässt sich testen. Ein großer Agent, der Retrieval, Regeln, Aktionen und Fehlerbehandlung zugleich kontrolliert, ist deutlich schwerer zu prüfen.

Verträge vor Komponenten

Eine brauchbare Schnittstelle beschreibt mehr als ein JSON-Beispiel. Sie legt mindestens fest:

erlaubte Felder und maximale Größen
erwartete Antworttypen
bekannte Fehlerkategorien
Timeout- und Wiederholungsverhalten
Daten, die geloggt oder ausdrücklich nicht geloggt werden
verantwortliche Stelle für Freigaben

Beim Chatbot dieser Website enthält eine Anfrage Nachricht, begrenzten Verlauf und Sprache. Die Wissenssuche liefert passende Einträge sowie einen klaren Match-Status. Die Antwort läuft als Ereignisstrom zum Browser. Quellen, Wissenslücken und Fehler bleiben eigene Ereignistypen. So muss die Oberfläche keine Textfragmente erraten.

Das klingt nach mehr Arbeit als ein direkter API-Aufruf. Es spart Arbeit, sobald der erste Anbieter ausfällt oder eine Antwort nicht zum Schema passt. Der Fehler landet dann an einer benannten Grenze und verteilt sich nicht unbemerkt im gesamten Ablauf.

Wissen gehört außerhalb des Prompts verwaltet

Ein langer Systemprompt ist keine Wissensarchitektur. Inhalte ändern sich, Preise brauchen einen Gültigkeitsstand und manche Fakten gelten nur für eine Sprache oder ein Angebot. Deshalb verwalte ich das Wissen für meinen Assistenten als kleine Markdown-Einträge mit stabiler ID, Kategorie, Sprache und Suchbegriffen.

Vor jeder Antwort wählt Retrieval nur die passenden Einträge aus. Das hält den Kontext kleiner und macht sichtbar, welche Quelle eine Aussage stützt. Ein deterministischer Citation Gate prüft anschließend, ob eine vom Modell genannte Quellen-ID wirklich vorhanden war. Dabei ist "deterministisch" wichtig: Normale Programmlogik trifft die Freigabeentscheidung, kein zweites Modell.

Mehr zum konkreten Ablauf steht in Agentischer Workflow in der Praxis. Die zugrunde liegenden Systeme und ihr aktueller Stand sind auf der Seite Systeme dokumentiert.

Fehler brauchen Namen

Ein pauschales "Es ist ein Fehler aufgetreten" reicht intern nicht. Das System sollte unterscheiden können, ob eine Eingabe ungültig ist, Wissen fehlt, ein Anbieter nicht antwortet oder ein Sicherheitslimit greift. Diese Kategorien steuern unterschiedliche Reaktionen.

Bei fehlendem Wissen ist die richtige Antwort eine transparente Lücke. Bei einem temporären Provider-Fehler kann ein kontrollierter Fallback sinnvoll sein. Bei einer ungültigen Berechtigung muss der Ablauf stoppen. Wer alle drei Fälle als neuen Prompt an dasselbe Modell zurückschickt, baut eine Schleife statt einer Fehlerbehandlung.

Das NIST Generative AI Profile empfiehlt, Risiken und Tests über den gesamten Lebenszyklus eines KI-Systems zu behandeln. Für die Architektur folgt daraus ein einfacher Grundsatz: Jeder relevante Fehler braucht einen Besitzer, ein Signal und eine sichere Reaktion.

Beobachtbarkeit beginnt am Eingang

Ein System lässt sich nur verbessern, wenn Anfragen über seine Komponenten hinweg nachvollziehbar bleiben. OpenTelemetry beschreibt einen Trace als Weg einer Anfrage durch ein verteiltes System. Spans markieren die einzelnen Arbeitsschritte. Die OpenTelemetry-Dokumentation zu Traces erklärt auch, wie gemeinsamer Kontext diese Schritte verbindet.

Für einen KI-Ablauf würde ich mindestens diese Punkte messen:

Gesamtdauer und Dauer pro Schritt
verwendeter Provider und Modellkennung
Match oder Wissenslücke beim Retrieval
Abbruchgrund und Fehlerkategorie
Zahl der Wiederholungen
Ergebnis eines deterministischen Prüf-Gates

Prompts, personenbezogene Daten und Geheimnisse gehören dabei nicht unkontrolliert ins Log. Beobachtbarkeit heißt, das Verhalten des Systems zu verstehen. Sie ist keine Erlaubnis, alle Inhalte dauerhaft zu speichern.

Der Monolith ist nicht automatisch das Problem

Ich habe frühe Prototypen zu schnell in kleine Services zerlegt. Dadurch entstanden zusätzliche Netzwerkgrenzen, Deployments und Fehlerpfade, obwohl die fachliche Trennung noch gar nicht klar war. Heute trenne ich zuerst im Code und verteile Komponenten erst dann auf mehrere Prozesse, wenn Betrieb oder Skalierung es verlangen.

Ein sauber modularisierter Monolith kann für ein kleines Team die bessere Architektur sein. Entscheidend ist, dass Wissen, Modellzugriff, Regeln und Auslieferung getrennte Verträge haben. Prozessgrenzen lassen sich später ergänzen. Unklare Verantwortung wird durch Microservices nur weiter verteilt.

Eine praktische Reihenfolge

Für einen neuen KI-Prozess arbeite ich in dieser Reihenfolge:

Reales Nutzerziel und erlaubte Daten festhalten.
Ein- und Ausgabe als Schema beschreiben.
Fachliche Regeln ohne Modell implementieren.
Modellzugriff hinter einer austauschbaren Schnittstelle ergänzen.
Fehler, Limits und manuelle Freigaben testen.
Erst danach Routing, weitere Modelle oder autonome Schritte hinzufügen.

Das Ergebnis wirkt von außen weniger spektakulär als eine Agenten-Demo. Dafür lässt es sich betreiben und übergeben. Genau das ist mein Maßstab für KI im Mittelstand.

Wenn ihr einen vorhandenen Prozess technisch einordnen wollt, beginnt mit dem KI-Potenzial-Audit. Dort prüfen wir Nutzen, Datenlage und Architekturgrenzen, bevor eine Modellentscheidung fällt.

Über den Autor

Ich bin Kirk Kleinau, AI Strategist und Creative Technologist sowie IHK-geprüfter KI-Manager. In meinen eigenen Systemen trenne ich Wissensbasis, Retrieval, Provider und Auslieferung, damit jeder Teil einzeln geprüft und ausgetauscht werden kann. Diese technische Arbeit baut auf acht Jahren Erfahrung in Design, Konzeption, Projektleitung, Web und Frontend auf.