WISSEN / KI-AGENTEN

KI-Agent Architektur: Modell, Kontext und Schutzschichten

Eine tragfähige KI-Agent Architektur verteilt Aufgaben auf klar abgegrenzte Komponenten. So bleiben Datenzugriff, Aktionen und menschliche Freigaben kontrollierbar.

THEMENFELDTechnik & IntegrationAlle Beiträge im KI-Agenten-Hub
KURZ GESAGT

Eine produktive KI-Agent Architektur trennt Sprachmodell, Ablaufsteuerung, Wissenssuche, Werkzeuge und Berechtigungen. So können Sie Verhalten begrenzen, Aktionen prüfen und Fehler besser nachvollziehen. Welche Schutzschichten nötig sind, hängt von Aufgabe, Daten und möglichen Folgen einer Aktion ab.

Schaubild zum Thema: KI-Agent Architektur: Modell, Kontext und Schutzschichten
JUT JEMACHT / WISSENTechnik & Integration

Das Wichtigste in Kürze

  • Das Sprachmodell interpretiert Eingaben und schlägt nächste Schritte vor. Es sollte nicht allein über Datenzugriff oder Aktionen entscheiden.
  • Eine separate Anwendung steuert den Ablauf, ruft bei Bedarf Wissensquellen ab und prüft, ob ein Werkzeug genutzt werden darf.
  • Jede Schnittstelle braucht begrenzte Rechte, klare Eingaben und einen definierten Fehlerpfad.
  • Menschliche Freigaben sind besonders wichtig, wenn eine Aktion externe Folgen hat oder Fehler schwer rückgängig zu machen sind.
  • Versionen, Protokolle und Messgrößen helfen, Änderungen zu prüfen und Fehler einer Komponente zuzuordnen.

Worum es geht

Die Architektur eines KI-Agenten beschreibt, wie verschiedene technische Bausteine zusammenarbeiten. Das Sprachmodell verarbeitet Sprache und erzeugt Vorschläge. Es kann etwa eine Anfrage einordnen, Informationen zusammenfassen oder eine mögliche Aktion benennen. Die Ablaufsteuerung der Anwendung entscheidet, welcher Schritt als Nächstes ausgeführt wird.

Weitere Komponenten übernehmen andere Aufgaben. Eine Wissenssuche liefert passende Inhalte aus freigegebenen Quellen. Werkzeuge können zum Beispiel Daten abfragen oder einen vorbereiteten Vorgang an ein anderes System übergeben. Eine zusätzliche Prüfschicht kontrolliert Eingaben, Berechtigungen und Ergebnisse. Dadurch wird nicht vorausgesetzt, dass das Modell selbst jede Grenze zuverlässig erkennt.

Diese Trennung ist ein technisches Gestaltungsprinzip, keine Garantie gegen Fehler. Sie macht aber sichtbar, an welcher Stelle Daten fließen, Entscheidungen getroffen und Aktionen ausgeführt werden. Das erleichtert Kontrolle und Fehlersuche.

Typische Ausgangslage

Stellen Sie sich ein Unternehmen vor, das einen internen Agenten für Fragen zu Arbeitsanweisungen und zur Vorbereitung von Vorgängen einführen möchte. Mitarbeitende stellen eine Frage in natürlicher Sprache. Der Agent soll relevante interne Dokumente finden, eine Antwort vorbereiten und bei Bedarf einen Vorgang in einer Geschäftsanwendung anlegen.

In einer ersten, zu einfachen Umsetzung könnte das Modell Dokumente suchen, selbst entscheiden, welche Daten es verwenden darf, und direkt Aktionen auslösen. Dann wären Zuständigkeiten vermischt: Ein Sprachmodell würde zugleich Inhalte interpretieren, Rechte ableiten und technische Schritte anstoßen. Bei einer unerwarteten Eingabe wäre schwer zu erkennen, welche Komponente den Fehler verursacht hat.

Eine sauberere Architektur weist jeder Aufgabe einen klaren Platz zu. Die Suche greift nur auf freigegebene Quellen zu. Die Anwendung prüft, ob die Anfrage die Voraussetzungen für den nächsten Schritt erfüllt. Ein Werkzeug erhält nur die Berechtigungen, die es für genau diese Aufgabe benötigt. Eine Person bestätigt den Vorgang, bevor er mit Außenwirkung ausgeführt wird.

So gehen Sie vor

  1. Aufgabe und Folgen beschreiben. Legen Sie fest, was der Agent leisten soll und was ausdrücklich außerhalb seines Auftrags liegt. Unterscheiden Sie zwischen einer unverbindlichen Antwort, einem vorbereiteten Entwurf und einer ausgeführten Aktion.

  2. Datenwege skizzieren. Notieren Sie, welche Eingaben an das Modell gehen, welche Informationen die Suche bezieht und welche Daten an verbundene Systeme übermittelt werden. Markieren Sie Vertrauensgrenzen: etwa den Übergang von einer Nutzereingabe zu internen Daten oder von einem Vorschlag zu einer Aktion.

  3. Komponenten und Verantwortlichkeiten festlegen. Bestimmen Sie, welche Anwendungsschicht den Ablauf steuert, welche Quelle Kontext liefert und welche Schnittstelle eine Aktion ausführt. Die Zuständigkeit für Berechtigungen und Prüfungen sollte außerhalb des Modells liegen.

  4. Werkzeuge eng begrenzen. Definieren Sie erlaubte Aktionen, zulässige Eingaben und die erforderlichen Rechte je Werkzeug. Prüfen Sie Parameter vor der Ausführung. Ein Werkzeug sollte nicht mehr lesen oder verändern können, als für seine konkrete Aufgabe erforderlich ist.

  5. Freigaben und Abbrüche entwerfen. Legen Sie fest, wann eine Person den nächsten Schritt bestätigen muss und wann der Agent bei fehlenden Informationen stoppt. Zeitlimits, Wiederholungsregeln und verständliche Fehlermeldungen verhindern, dass ein unklarer Zustand unbemerkt weiterläuft.

  6. Protokollierung und Versionierung einrichten. Halten Sie nachvollziehbar fest, welche Komponente aufgerufen wurde und ob eine Aktion freigegeben, abgelehnt oder abgebrochen wurde. Versionieren Sie Prompt, Modell, Werkzeuge und relevante Wissensstände, damit Änderungen später eingeordnet werden können.

  7. Mit einem begrenzten Piloten prüfen. Beginnen Sie mit einem klar umrissenen Anwendungsfall und kontrollierten Daten. Testen Sie typische Anfragen, unvollständige Eingaben und Fälle, in denen der Agent nicht weiterarbeiten soll. Erweitern Sie den Einsatz erst, wenn die Ergebnisse überprüfbar sind.

Entscheidungskriterien und typische Fehler

Wie viel Architektur nötig ist, richtet sich vor allem nach den Folgen möglicher Fehler. Ein Agent, der interne Inhalte auffindbar macht, hat andere Anforderungen als ein Agent, der Einträge in einem führenden System verändert. Fragen Sie deshalb nicht nur, welches Modell eingesetzt wird. Prüfen Sie auch, welche Daten es sehen darf, wer Aktionen freigibt und wie ein fehlerhafter Schritt erkannt oder zurückgenommen werden kann.

Typische Fehler sind:

  • Modell, Ablaufsteuerung und Berechtigungsprüfung als eine einzige Funktion zu behandeln.
  • Werkzeuge mit breiten Rechten auszustatten, obwohl nur ein eng begrenzter Zugriff nötig ist.
  • Suchergebnisse ungeprüft als verlässliche Grundlage für eine Aktion zu verwenden.
  • Fehlerfälle, Zeitüberschreitungen und fehlende Daten nicht vorab zu beschreiben.
  • Änderungen an Prompts, Modellen oder Wissensbeständen vorzunehmen, ohne die Versionen festzuhalten.
  • Protokolle so zu gestalten, dass sie entweder für die Fehlersuche zu wenig enthalten oder unnötig sensible Inhalte speichern.

Grenzen und Risiken

Auch eine sorgfältig getrennte Architektur kann falsche Antworten, unpassende Vorschläge oder technische Ausfälle nicht vollständig ausschließen. Inhalte aus Dokumenten können unvollständig oder veraltet sein. Schnittstellen können nicht erreichbar sein. Eingaben können mehrdeutig sein. Deshalb braucht jeder wichtige Prozess einen definierten Zustand für Unsicherheit: nachfragen, zur Prüfung vorlegen oder sicher abbrechen.

Berechtigungen dürfen nicht allein davon abhängen, was das Modell in einer Antwort behauptet. Die Anwendung muss Zugriffe und Aktionen unabhängig prüfen. Bei folgenreichen Schritten sollte eine zuständige Person den Inhalt und die Auswirkungen vor der Ausführung kontrollieren können. Welche Datenschutz- und Rechtsanforderungen gelten, ist im jeweiligen Einsatzfall zu prüfen; dieser Beitrag ersetzt keine Rechtsberatung.

Woran Sie den Nutzen erkennen

Bewerten Sie nicht nur, ob Antworten plausibel klingen. Beobachten Sie die Laufzeit des gesamten Ablaufs und einzelner Komponenten, Fehler je Komponente, sichere Abbrüche sowie den Aufwand für die Fehlersuche. Prüfen Sie außerdem, ob Freigaben dort greifen, wo sie vorgesehen sind, und ob sich eine Aktion anhand der verfügbaren Protokolle erklären lässt.

Vor dem Piloten sollten Sie festlegen, welche Veränderung Sie erwarten: etwa weniger manuelle Suchschritte oder besser vorbereitete Vorgänge. Erfassen Sie den Ausgangszustand und vergleichen Sie ihn mit dem Einsatz. So lässt sich entscheiden, ob die Architektur angepasst, der Anwendungsfall eingegrenzt oder der Pilot beendet werden sollte.

Häufige Fragen

Muss ein KI-Agent immer mehrere technische Komponenten haben?

Nicht jeder Anwendungsfall braucht viele Dienste oder Schnittstellen. Entscheidend ist, dass Modell, Datenzugriff, Ablaufsteuerung und Aktionen auch in einer einfachen Lösung klar voneinander abgegrenzt und prüfbar sind.

Warum sollte das Modell Aktionen nicht selbst freigeben?

Das Modell erzeugt Vorschläge auf Grundlage seiner Eingabe und seines Kontexts. Es ist nicht die geeignete Stelle, um verbindliche Systemrechte zu vergeben. Eine separate Anwendung kann Berechtigungen und Eingaben nach festen Regeln prüfen.

Wann ist eine menschliche Freigabe sinnvoll?

Wenn eine Aktion Daten verändert, an andere Personen oder Systeme weitergegeben wird oder nur schwer rückgängig zu machen ist. Bei vorbereitenden, nicht verbindlichen Ergebnissen kann eine andere Kontrollform ausreichen. Das muss der Prozess festlegen.

Was sollte bei einer Änderung versioniert werden?

Mindestens die eingesetzte Modellversion, Prompts, Werkzeugbeschreibungen und relevante Wissensstände. Zusätzlich sollten Änderungen an Ablaufregeln und Prüfungen nachvollziehbar sein. So können Sie Verhalten vor und nach einer Anpassung vergleichen.

Was passiert, wenn eine Komponente nicht erreichbar ist?

Der Ablauf sollte nicht stillschweigend mit unvollständigen Informationen fortfahren. Definieren Sie, ob der Agent nachfragt, einen Hinweis ausgibt, an eine Person übergibt oder sicher abbricht. Die passende Reaktion hängt davon ab, welche Folgen ein falscher nächster Schritt hätte.

VOM WISSEN ZUM EINSATZ

Passt ein Agent zu Ihrem Prozess?

Wir schauen auf Aufgabe, Daten, Rechte und Ausnahmen und klären, welcher erste Schritt sinnvoll ist.

Anwendungsfall besprechen