KI-Architektur für Produktionsagenten: Ausfallmöglichkeiten und Kontrollschichten

Warum Prototypen scheitern

Produktions-KI-Systeme fallen selten wegen schwacher Modelle zusammen. Sie scheitern, weil die Architektur um das Modell Nichtbestimmtheit niemals als Gestaltungsbeschränkung akzeptiert hat. Drei Spannungen prägen nahezu jede anschließende Entscheidung: Leistungsfähigkeit gegenüber Steuerbarkeit, Latenz gegenüber Genauigkeit sowie Autonomie gegenüber Überprüfbarkeit.

Gute Architekten fragen zuerst warum, bevor sie etwas tun. Ohne eine Gestaltungsphilosophie ist eine Liste von Komponenten lediglich eine Checkliste. Mit einer solchen wird sie zu einem Rahmenwerk, das auch Probleme abdeckt, mit denen noch niemand konfrontiert wurde.

Diese Philosophie kehrt eine gängige Annahme um. Die traditionelle Architektur erwartet, dass Komponenten genau das tun, was in ihren Spezifikationen festgelegt ist, wodurch dem Architekten nur noch die Aufgaben der Routenplanung, Skalierung und Fehlertoleranz bleiben. Hier ist die Komponente selbst die Quelle der Unsicherheit, weshalb das umgebende System diese auf jeder Ebene absorbieren, messen und begrenzen muss.

Wie KI-Systeme tatsächlich versagen

Die meisten Ausfälle in der Produktion entstehen dadurch, dass ein probabilistisches System wie eine deterministische API behandelt wird. Im Folgenden findet sich eine grobe Klassifizierung der Fehlerquellen.

Halluzinationen als Suchproblem

Menschen ordnen Halluzinationen in der Regel der Modellqualität zu. Aus architektonischer Sicht handelt es sich dabei um eine Lücke bei der Informationsabrufung, einen Fehler bei der Verwaltung des Kontextfensters oder ein Versagen bei der Kalibrierung des Vertrauensniveaus. Wenn man ein Modell bittet, über ein 200-seitiges Dokument nachzudenken, obwohl nur 4.000 Token Platz haben, kann es nicht erkennen, was ihm fehlt, und erfindet daher den Rest. Die Lösung liegt im System: präziser Informationsabruf, eine Begrenzung des Kontextumfangs sowie die explizite Darstellung von Unsicherheiten durch den Systemprompt und das Ausgabeschema.

Drei Arten von Drift

Teams fassen oft drei verschiedene Dinge zusammen. Modell-Drift tritt auf, wenn der Anbieter das Grundmodell aktualisiert und sich das Verhalten ändert, obwohl auf Ihrer Seite nichts bereitgestellt wurde. Daten-Drift tritt auf, wenn sich die Eingaben ändern – beispielsweise, wenn ein Support-Mitarbeiter, der sich auf Anfragemuster vor 2024 eingestellt hat, bei Fragen zu neuen Produkten ins Stocken gerät. Wissens-Drift tritt auf, wenn sich die Welt weiterentwickelt und das von dem Modell Gelernte veraltet. Jeder dieser Phänomene erfordert eigene Methoden zur Erkennung und Behebung.

Fehler, die Grenzen zwischen Agenten überschreiten

Mehre-Agenten-Systeme stellen ein noch subtileres Problem dar. Agent A erzeugt ein leicht fehlerhaftes Ergebnis, Agent B nimmt dieses als Tatsache hin, und Agent C führt aufgrund von Bs fehlerhafter Schlussfolgerungen eine irreversible Aktion durch. Sobald der Fehler auftaucht, ist es nahezu unmöglich, seinen Ursprung zu ermitteln. Drei Schutzmaßnahmen helfen dabei: Die Agenten tauschen Vertrauenswerte aus, Übergaben unter einer bestimmten Vertrauensgrenze aktivieren einen Sicherheitsmechanismus, und jede Agentengrenze schreibt in ein nur zum Hinzufügen geeignetes Prüfprotokoll.

Kontextverschmutzung

Lange Gespräche sowie große Mengen an Historie zu Toolaufrufen füllen das Kontextfenster mit Material, das die Leistung beeinträchtigt. Die Aufmerksamkeit verteilt sich auf immer größere Mengen an Informationen, wodurch wichtige Anweisungen in die Mitte rutschen, wo die Aufmerksamkeit am schwächsten ist. Architekten benötigen einen bewusst gestalteten Kontextlebenszyklus: Auslöser für Zusammenfassungen, Strategien zur Komprimierung sowie eine klare Trennung zwischen Arbeitsgedächtnis und Langzeitgedächtnis.

Wiederholungszyklen

Agenten mit Tools neigen dazu, pathologische Wiederholungsversuche zu starten. Eine Suche liefert unklare Ergebnisse, der Agent formuliert die Anfrage neu – doch auch die neue Anfrage ist genauso unklar. Der Kreislauf setzt sich fort, bis der Kontext erschöpft ist oder eine Geschwindigkeitsbeschränkung erreicht wird. Sofern die Orchestrierungsschicht keine Zykluserkennung, Schrittbudgets sowie Beendigungsbedingungen besitzt, verschwenden agentbasierte Systeme regelmäßig Token, Zeit und Geld an Unteraufgaben, die nicht gelöst werden können.

Injektion durch externe Inhalte

Ein Agent, der E-Mails liest, Dokumente verarbeitet oder im Internet surft, kann auf Inhalte stoßen, die feindliche Anweisungen enthalten, um ihn zu übernehmen. Das ist keine Frage zur Sicherheit des Modells. Es handelt sich um einen klassischen Injektionsangriff an der Grenze zwischen vertrauenswürdigen und unvertrauenswürdigen Daten. Die Abwehrmaßnahmen sind strukturell: ausgeführte Prozesse in Sandboxes, eine strenge Trennung zwischen der Anweisungs- und der Datenebene sowie die Überprüfung der Ausgaben anhand eines eingeschränkten Schemas vor jeder weiteren Aktion.

Keine kontinuierliche Bewertung

Der häufigste Grund dafür, dass Systeme allmählich versagen, ist das Fehlen einer Schicht zur kontinuierlichen Bewertung. Ein Team bringt ein Modell heraus, feiert die Demo und behandelt es anschließend als statische API. Jede Aktualisierung des Anbieters, jede Änderung im Schema des RAG-Korpus sowie jeder Wandel in der Nutzerbasis kann etwas kaputt machen – und ohne Bewertungen ist das erste Anzeichen ein Kundenbeschwerde.

Die Plattform als Konstellation

Eine Unternehmens-KI-Plattform ist kein Monolith. Es handelt sich um einen Cluster von Systemen, von denen jedes eigene Verantwortlichkeiten, Schnittstellenvereinbarungen und Ausfallmöglichkeiten hat. Die Architektur muss den gesamten Lebenszyklus einer Anfrage abdecken – von der Aufnahme, der Zusammenstellung des Kontexts, der Aufrufung des Modells, der Ausführung von Tools über die Validierung der Antwort bis hin zur Überwachbarkeit – und dabei davon ausgehen, dass jede Schicht ausfallen kann.

Die Datenerfassung ist ein Pipeline-Prozess

Retrieval-augmented Generation ist komplexer, als der Name vermuten lässt. Ein Produktionsystem besteht nicht nur aus dem Einbetten von Dokumenten, dem Abfragen von Vektoren und dem Einfügen von Kontext. Es handelt sich um einen Prozessfluss mit mindestens fünf Phasen, bei denen jede für Probleme sorgen kann: Eingabe und Aufteilung in Blöcke, Auswahl des Embedding-Modells sowie Versionierung, Erstellung des Indexes und Frequenz der Aktualisierung, Rangfolgebestimmung bei der Suche mithilfe einer Kombination aus dichten und spärlichen Methoden sowie Zusammenstellung des Kontexts unter Berücksichtigung relevanter Schwellenwerte. Jede Phase benötigt eigene Metriken, und eine Veränderung in einer kann die anderen beeinträchtigen, ohne dass es jemand bemerkt.

Vier Ebenen der Agentenerinnerung

Die Agentenerinnerung sollte in vier Ebenen unterteilt werden:

• Die Arbeitsgedächtnis ist das Kontextfenster innerhalb einer Sitzung.
• Das episodische Gedächtnis enthält Zusammenfassungen früherer Gespräche, die innerhalb derselben Sitzung abgerufen werden können.
• Das semantische Gedächtnis umfasst das Unternehmenswissen, welches die RAG-Schicht darstellt.

Die prozedurale Erinnerung speichert gelernte Muster des Werkzeuggebrauchs sowie Heuristiken für bestimmte Bereiche.

Die Verschmelzung dieser Ebenen ist eine häufige Ursache für Kontextverunreinigungen sowie für ein inkonsistentes Verhalten der Agenten von einer Sitzung zur nächsten.

Mehr-Agentensysteme und Übergaben

In moderatem Maßstab ist ein einzelner Agent bereits eine gelöste Aufgabe. Das Design von Mehr-Agentensystemen stellt hingegen eine schwierige Herausforderung dar, da Probleme durch Koordinationsaufwände, Konsistenz gemeinsamer Zustände, Fehlerverbreitung sowie emergentes Verhalten entstehen, das kein einzelner Agent zeigen würde.

Der am meisten vernachlässigte Bestandteil ist das Übertragungsprotokoll, die Vereinbarung darüber, was ein Agent an einen anderen weitergibt. Ein minimales Format umfasst den Zustand der Aufgabe, eine Zuverlässigkeitsbewertung, die zur Doppelungsbeseitigung durchgeführten Schritte, Verweise auf relevanten Kontext (nicht den gesamten Kontext, da dieser die Speicherkapazität überlasten würde) sowie alle auf dem Weg gefundenen Einschränkungen. Ohne ein strukturiertes Schema übergeben die Agenten Texte in freier Natursprache, wodurch der Empfänger den Zweck erneut interpretieren muss – was eine Hauptursache für Abweichungen und verstärkte Fehler ist.

Teams müssen außerdem entscheiden, wie die Agenten das Gedächtnis teilen. Das Verwahren von privatem Gedächtnis pro Agent erleichtert das Verständnis und die Überprüfung des Verhaltens, führt aber zur Doppelung der Abrufvorgänge und kann dazu führen, dass sich der Zustand zwischen den Agenten unterscheidet. Ein gemeinsames Blackboard unterstützt die Koordination, erfordert jedoch Konkurrenzkontrolle, Versionierung sowie Logik zur Invalidation. Der vorgeschlagene Standard ist privates Gedächtnis, wobei explizite Veröffentlichungsereignisse in versionierter Form die Ergebnisse nach Abschluss einer Aufgabe in einen gemeinsamen Speicher schreiben.

Schutzmechanismen sind Struktur

Schutzmechanismen sind keine Funktion, die einfach zu einem produktiven KI-System hinzugefügt wird. Sie sind eine strukturelle Eigenschaft. Ein System ohne schichtweise Schutzmechanismen ist nicht nur ein KI-System ohne Sicherheitsfunktionen – es handelt sich dabei um eine andere Art von System, das in einem Unternehmen keinen Platz hat.

Stufenweise Notstopp-Funktionen

Jedes Produktionsystem benötigt mehr als nur einen einzigen Abschaltknopf. Es braucht ein Spektrum an Reaktionen:

• Rate Limiting verlangsamt die Abläufe, ohne sie vollständig zum Stillstand zu bringen.
• Durch die Reduzierung der Funktionalitäten wird der Zugriff auf Werkzeuge deaktiviert und es wird auf einen rein informierenden Modus umgestellt.
• Durch menschliche Verarbeitung werden alle Anfragen an menschliche Mitarbeiter weitergeleitet.
• Durch die Beendigung der Sitzung werden aktive Mitarbeiter-Sitzungen sauber beendet, wobei der Prüfzustand erhalten bleibt.
• Ein vollständiger Stillstand schaltet alles unveränderlich ab und sichert den forensischen Zustand.

Jeder dieser Mechanismen muss in der Produktion testbar sein, denn ein Notstopp, der noch nie getestet wurde, ist keiner.

Reversibilität ist am wichtigsten

Der Inhaltsschutz zieht die meiste Aufmerksamkeit auf sich, doch die wichtigere Frage ist, ob eine Aktion rückgängig gemacht werden kann. Wenn ein Agent einen falschen E-Mail-Text sendet, eine Zeile in einer Datenbank löscht, einen Zahlungsvorgang durchführt oder Infrastruktur bereitstellt, gibt es keine Möglichkeit, dies rückgängig zu machen. Jedes Werkzeug muss auf einer Skala der Rückerstattbarkeit eingestuft werden, wobei die Zuverlässigkeitsanzeige mit zunehmender Schwierigkeit, eine Aktion rückgängig zu machen, steigt: Je dauerhafter die Aktion ist, desto sicherer muss das System sein, bevor es ohne menschliche Überwachung weitermacht.

Die Bewertungsschicht

Viele Unternehmensprojekte erfüllen auf dem Papier die „Best Practices“, leisten in der Praxis jedoch nichts. Eine vierteljährliche manuelle Überprüfung von 50 ausgewählten Ergebnissen ist reine Show und kein echtes Bewertungssystem. Ein wirkliches Bewertungssystem läuft kontinuierlich, automatisch und ist mit dem Überwachungsprozess verbunden.

Verwendung eines Modells als Richter

Derzeit ist es der am besten skalierbare Weg zu kontinuierlichen Qualitätskontrollen, wenn ein zweites Sprachmodell die Ausgaben des ersten bewertet – es kann offene Antworten beurteilen, was eine Zeichenkettenvergleichsmethode nicht kann. Gleichzeitig bringt dies auch eigene Fehlermöglichkeiten mit sich. Die Bewertenden zeigen positionale Voreingenommenheit, indem sie längere oder frühere Antworten bevorzugen. Zudem weisen sie Selbstaffinität auf, beispielsweise bewertet Claude Ausgaben im eigenen Stil höher. Außerdem können Halluzinationen in einer Kaskade entstehen, wodurch eine Ausgabe fälschlicherweise als faktisch deklariert wird. Solide Implementierungen verwenden adversarische Testmengen, kalibrieren sich regelmäßig anhand menschlicher Beurteilungen und fügen den eigenen Urteilen Unsicherheitswerte hinzu.

Bewertungen innerhalb des Deployment-Pipelines

Die Bewertung sollte kein gelegentlicher Nebenaspekt sein. Jede Aktualisierung des Modells, jede Änderung der Anfragesprache, jedes Auffrischen des Korpus sowie jede Änderung am Schema der Tools sollte einen automatisierten Bewertungssatz in Gang setzen, und Rückfälle bei wichtigen Metriken sollten die Veröffentlichung verhindern. Das bedeutet Mindestschwelle für jede Metrik, die als Teil des Servicevertrags gilt. Ein Microservice, der seine Unit-Tests nicht besteht, wird nicht veröffentlicht, genauso wenig wie ein KI-System, das seine Bewertungen nicht bestehen kann.

Beobachtbarkeit bei einem offenen Zustandsraum

Die Beobachtung eines KI-Systems unterscheidet sich von der eines Microservices in einem wesentlichen Punkt: Der Zustandsraum hat keine Grenzen. Ein Microservice hat entweder eine Anfrage korrekt verarbeitet oder nicht. Eine KI-Antwort befindet sich auf einer kontinuierlichen Qualitätsskala, und ob sie gut ist, hängt von Kriterien ab, die nur durch einen weiteren Modellaufruf gemessen werden können. Das erfordert ein grundlegend anderes Design der Beobachtbarkeit.

Für jede Anfrage an ein LLM umfasst das minimale nützliche Protokoll:

• die vollständige Anfrage, nach dem Rendern des Templates und vor der Kürzung
• den abgerufenen Kontext samt seinen Quellen
• die wortgetreue Antwort des Modells, vor der Nachverarbeitung
• eine Aufschlüsselung der Token-Nutzung
• die Latenz pro Phase (Abruf, Modell, Nachverarbeitung)
• Bewertungsscores, sofern synchron berechnet
• jede Tool-Aufrufung und deren Antwort
• Signale zur Zuverlässigkeit oder Unsicherheit, sofern das Modell sie bereitstellt
• pseudonymisierte Sitzungs- und Benutzeridentifikatoren
• Versionen von allen beteiligten Elementen: Modell, Prompt-Template, Index und Tool-Schema

Die Versionen sind am wichtigsten. Ohne sie ist es reines Raten, einen Qualitätsrückgang auf eine bestimmte Änderung zurückzuführen.

Drei Signale für Abweichungen

Das Erkennen von Abweichungen bedeutet, drei Signale gleichzeitig zu beobachten. Bei einer Abweichung in der Eingabeverteilung geht es darum, ob die eingehenden Anfragen statistisch von dem abweichen, worauf das System abgestimmt ist – eine Distanz im Embedding-Raum, wie beispielsweise die Kosinusähnlichkeit gegenüber einem Referenzkorpus, kann dies bereits vor dem Qualitätsabfall aufzeigen. Bei einer Abweichung in der Ausgabequalität geht es darum, ob die Bewertungsscores nach unten tendieren, was eine kontinuierliche Evaluation statt nur periodischer Überprüfungen erfordert. Bei einer Abweichung im Modellverhalten geht es darum, ob der Anbieter das Modell heimlich geändert hat; daher sollte regelmäßig ein deterministischer Gold-Set-Benchmark gegen jedes Modell durchgeführt werden, wobei Alarme ausgelöst werden, wenn der Unterschied einen Schwellenwert überschreitet.

Kosten sind Architektur

Kosten sind das Thema, das in Gesprächen über KI-Architekturen am häufigsten fehlt, und sie sind eines der ersten Faktoren, die bei unternehmensweiter Skalierung versagen. Ein System, das alle technischen Anforderungen erfüllt, aber 4 Dollar pro Anfrage kostet, wird die erste Betriebsprüfung nicht überstehen. Behandeln Sie Kosten als architektonische Einschränkung und nicht als nachträglichen Aspekt der Abrechnung.

Routing zum günstigsten geeigneten Modell

Der wichtigste Hebel hierfür ist das intelligente Modellrouting, bei dem jede Anfrage an das günstigste Modell gesendet wird, das dennoch die Qualitätsanforderungen erfüllt. Dafür ist eine Routing-Funktion erforderlich, die die Komplexität klassifiziert (eine einfache Faktensuche, mehrstufiges Reasoning oder Codegenerierung), jede Klasse einem Modell-Level zuordnet und bei Fehlern ein Ersatzmodell anbietet. Der Router selbst kann ein kleiner, schneller Klassifikator sein, und seine Kosten werden in der Regel bereits beim ersten erfolgreichen Versand einer Anfrage an ein günstigeres Modell wieder eingespielt.

Semantisches Caching

Reines Caching funktioniert bei LLM-Anwendungen nur unzureichend, da Anfragen mit identischem Inhalt selten als Zeichenketten übereinstimmen. Semantisches Caching indiziert Antworten anhand der Nähe im Embedding-Raum und nicht anhand des exakten Textes, wodurch bei hohem Datenvolumen Hit-Raten von 30 bis 60 Prozent erreicht werden können, ohne dass die Anwendungslogik davon beeinflusst wird. Dafür ist ein schneller, annähernder Näherungsindex erforderlich, ein Ähnlichkeitsschwellenwert, ab dem ein Miss erfolgt, sowie eine TTL-Politik, die der Geschwindigkeit angepasst ist, mit der Wissen veraltet.

Token-Budgets

In der Produktion stammt in der Regel etwa 60 bis 80 Prozent des Tokenverbrauchs von Systemanfragen, Tool-Schemata und abgerufenem Kontext – nicht von Benutzernachrichten oder Modellantworten. Die Budgetverwaltung muss daher auf der Konstruktionsseite erfolgen: Kürzen Sie die Systemanfragen dynamisch, sodass nur die dem Anfragetyp relevanten Abschnitte enthalten sind; laden Sie Tool-Schemata verzögert, damit nur die vom Planer ausgewählten eingefügt werden; und strukturieren Sie das Kontextfenster so, dass hochrelevante Teile im primären Kontext bleiben, während weniger relevante als komprimierte Zusammenfassungen angezeigt werden.

Zero Trust für Agenten

Zero Trust wurde ursprünglich für menschliche Benutzer und statische Dienste entwickelt. Seine Anwendung auf Agenten bedeutet, es so zu erweitern, dass es dynamische Funktionsmöglichkeiten, unterschiedliche Zuverlässigkeitsgrade sowie die Befugnis umfasst, für Benutzer ohne explizite Genehmigung pro Aktion zu handeln.

Identität für jeden Agenten

Jeder Agent in einem Produktionsworkflow benötigt eine eigene kryptografische Identität, die sich von dem Benutzer unterscheidet, für den er arbeitet, sowie von anderen Agenten. Anmeldeinformationen sollten an die Sitzung gebunden sein und bei deren Beendigung ablaufen. Sie sollten durch Berechtigungen eingeschränkt werden, sodass die Anmeldeinformationen angeben, was der Agent tun darf, und nicht nur, wer er ist. Zudem sollten jede Ausstellung und jeder Widerruf unveränderlich protokolliert werden. Dadurch kann die Auditspur beantworten, welcher Agent unter welcher Anmeldeinformation welche Aktion für welchen Benutzer und zu welchem Zeitpunkt durchgeführt hat – eine Frage, die bei der Untersuchung von Vorfällen von entscheidender Bedeutung ist.

Trennung von Anweisungen und Daten

Das wichtigste Sicherheitsprinzip in agiler KI besteht darin, Anweisungen und Daten auf getrennten Ebenen zu halten. Unzuverlässige Quellen dürfen die Systemanfragen auf keinen Fall verunreinigen. Konkret werden externe Daten vor dem Erreichen des Kontexts durch eine Sanitierungsschicht geleitet, das abgerufene Inhalte erhalten ein Vertrauenslabel, und dem Modell wird mitgeteilt, Texte mit geringem Vertrauensgrad als Material zur Analyse und niemals als Befehle zu behandeln. Dies entspricht parametrisierten SQL-Abfragen: derselbe Grundsatz, unterschiedliche Umsetzung.

In die Architektur integrierte Governance

KI-Governance ist keine reine Compliance-Checkliste. Es handelt sich um eine anhaltende betriebliche Disziplin, die architektonische Unterstützung benötigt. Eine Organisation kann kein System verwalten, das sie nicht beobachten kann, keinen Prozess auditen, der keine Protokolle anlegt, und keine Richtlinien durchsetzen, wenn das System nicht dafür konzipiert ist. Governance muss von Anfang an in die Architektur integriert werden und nicht später hinzugefügt.

Richtlinien als Code

Politiken, die in Prose-Dokumenten gespeichert sind, können nicht auf großem Scale verwaltet werden. Was benötigt wird, ist Policy as Code: Regeln, die maschinenlesbar sind, im Versionssystem aufbewahrt werden, getestet werden können und zur Laufzeit vom AI-Gateway bewertet werden. Open Policy Agent mit seiner Rego-Sprache ist eine ausgereifte Option. Es kann Regeln wie „Keine kundenorientierten Entscheidungen in der EU durch dieses Modell, es sei denn, die Ausgabe trägt ein Flag für menschliche Überprüfung“ oder „Dieser Agent darf das Zahlungstool nicht auf als PII klassifizierten Daten verwenden“ kodieren. Die Bewertung am Gateway schafft einen einzigen Durchsetzungspunkt sowie ein vollständiges Audit-Log, was die derzeit typischen, verstreuten, inkonsistenten und undurchgesetzten Politiken in Unternehmens-KI ersetzt.

Das Recht auf Erklärung

Vorschriften wie das EU AI Act sowie unternehmensinterne Risikomanagement-Strategien fordern zunehmend, dass folgenreiche KI-Beschlüsse für die betroffenen Personen erklärbar sind. Das ist eine Anforderung an die Architektur und keine Frage zur Fähigkeit des Modells. Selbst ein Modell, das seine eigenen Überlegungen nicht erklären kann, kann an einem erklärbaren System teilnehmen, sofern die Architektur festhält, welche Informationen das Modell erhalten hat, welche Tools es verwendet hat, welche Optionen es abgewogen hat und wie zuversichtlich es in Bezug auf das Ergebnis war. Die Auditspur muss so gestaltet sein, dass sie bei einer Prüfung eine Erklärung liefern kann, anstatt später aus den vorhandenen Protokollen rekonstruiert zu werden.

Die Architektur ist das Produkt

Ein für die Produktion bereites KI-System wird nicht durch die Qualität seines Sprachmodells definiert. Es wird vielmehr durch die Komplexität der Architektur bestimmt, die das Modell umgibt. Das Modell ist ein Komponente – leistungsstark, wertvoll und schwer zu ersetzen – bleibt aber dennoch nur eine Komponente.

Die KI-Architektur ist das Handwerk des Aufbaus von Systemen, die zuverlässig, steuerbar und verbessert werden können, an der Stelle, an der der Nichtdeterminismus von KI auf die deterministischen Anforderungen von Unternehmenssoftware trifft. Jede Schicht beantwortet eine Frage:

• Wie verhindern wir schlechte Ausgaben? Mit Schutzmechanismen.
• Wie erkennen wir einen Rückgang der Qualität? Durch Bewertungen sowie Überwachungsmöglichkeiten.
• Wie koordinieren wir mehrere KI-Komponenten? Mit Multi-Agenten-Topologien und Übergabeprotokollen.
• Wie verhindern wir steigende Kosten? Durch Token-Budgets und Modell-Routing.

Wie stellen wir sicher, dass nur autorisierte Aktionen ausgeführt werden? Durch Zero Trust und Berechtigungen für Tools.

Wie befriedigen wir Aufsichtsbehörden und Prüfer? Mit einer Governance-Architektur.

Jeder, der neu in diesem Bereich ist, sollte verstehen, dass KI-Architektur nicht einfach nur ein Teilbereich der Softwarearchitektur ist. Sie ist eine eigenständige Disziplin mit eigenen Grundprinzipien und Denkmustern, die Unsicherheit als zentrale Gestaltungsbeschränkung und nicht als Randfall betrachtet. Entwerfen Sie für Abweichungen und nicht für das erwartete Ergebnis. Schauen Sie sich die Verteilung an, nicht den Durchschnitt. Ein System, das gut mit den schlechtesten 5 Prozent der Fälle umgehen kann, verdient es, auch die anderen 95 Prozent in der Produktion zu bedienen.