KI-Agenten: Architektur für den produktiven Einsatz

Die Architektur für KI-Agenten beginnt am besten mit einem einzelnen Agenten, der einen Fall untersuchen, eine Maßnahme vorschlagen und vor der Ausführung eine Freigabe abwarten kann. Modell und Standardinfrastruktur lassen sich zukaufen. Geschäftsregeln, Berechtigungsgrenzen und der Nachweis, dass eine Aufgabe korrekt erledigt wurde, gehören in die eigene Anwendung.

Ein Support-Agent wird nützlich, sobald er eine Kundenanfrage mit dem richtigen Konto, der passenden Richtlinie und einer geeigneten Maßnahme verknüpfen kann. Verlässlich wird er, wenn die Anwendung um ihn herum seine Zugriffe nachvollziehbar macht, unbefugte Änderungen verhindert und nach einem Tool-Fehler wieder handlungsfähig ist.

Das System lässt sich als Verkehrsnetz verstehen: Das Modell wählt die Route, Tools erschließen die Ziele, das Gedächtnis hält den bisherigen Weg fest, und die Orchestrierung steuert den Ablauf. Schutzregeln und Freigabepunkte kontrollieren den Zugang. Evaluation und Protokolle zeigen, ob die Fahrgäste am richtigen Ort angekommen sind.

Die folgenden Komponentenbeschreibungen wurden am 25. Oktober 2026 anhand der Dokumentation von Anthropic, OpenAI und Google Cloud sowie der Spezifikation des Model Context Protocol überprüft. Der Support-Ablauf dient als Entwurfsbeispiel; er beschreibt kein bei einem Kunden eingesetztes System.

KI-Agenten: Welche Verantwortung trägt die Anwendung?

Die Architektur legt fest, was das Modell entscheiden darf und was die Anwendung verbindlich durchsetzen muss. Diese Grenze ist wichtiger als der Name des Frameworks.

Ein sinnvoller Ausgangspunkt ist Anthropics augmented LLM: ein Sprachmodell, das um Informationsabruf, Tools und Gedächtnis erweitert wird. Anthropic unterscheidet zwischen einem Workflow, dessen Ablauf im Code vorgegeben ist, und einem Agenten, der seine nächsten Schritte dynamisch wählt. Die Empfehlung lautet, zusätzliche Komplexität erst einzuführen, wenn die Aufgabe sie erfordert. Anthropics Leitfaden für Agenten

Bei der Einordnung einer Support-Anfrage könnte das Modell entscheiden, ob es eine Anleitung zur Fehlerbehebung durchsucht oder eine Bestellung prüft. Der Anwendungscode muss weiterhin festlegen, auf wessen Kundendaten der Agent zugreifen darf, ob eine vorgeschlagene Erstattung zulässig ist und was passiert, wenn der Lauf mittendrin abbricht.

Vorhersehbare Aufgaben sollten vorhersehbar bleiben. Ein Konto zu authentifizieren, eine Zugangsberechtigung zu prüfen und eine ausgeführte Aktion zu protokollieren, erfordert keine Improvisation durch einen Agenten. Das Modell übernimmt den Teil, der Urteilsvermögen verlangt: die Nachricht verstehen, passende Belege auswählen und einen sinnvollen nächsten Schritt vorschlagen.

Die Architektur im Schaubild: Schichten und Verbindungen

Ein Agent braucht einen kontrollierten Ablaufzyklus mit dauerhaft gespeichertem Zustand und begleitenden Prüfungen. Die folgenden Schichten beschreiben Verantwortlichkeiten. Dafür ist nicht jeweils ein eigener Dienst oder ein separates Abonnement nötig.

Die Verbindungen bilden einen Kreislauf: Die Anwendung stellt Kontext zusammen, das Modell fordert eine Aktion an, die Laufzeitumgebung prüft sie und führt sie aus. Das Ergebnis fließt als Kontext in die nächste Entscheidung ein. Der Leitfaden zum Agentenzyklus erläutert diesen Ablauf und seine Abbruchbedingungen im Detail.

Modell: Den Fall verstehen und den nächsten Schritt vorschlagen

Das OpenAI Agents SDK, eine Bibliothek zum Aufbau von Agenten-Workflows, bündelt Modell, Anweisungen und Tools in einem Agent. Das Modell interpretiert das Ticket und schlägt das weitere Vorgehen vor. In diesem Entwurf erhält es eine Meldung über ein Zugangsproblem und fordert den zugehörigen Berechtigungsdatensatz an, bevor es eine Antwort formuliert. Die Modellauswahl sollte auf der Evaluation repräsentativer Support-Fälle beruhen: Eine gewandte Formulierung beweist weder die richtige Tool-Auswahl noch die Befugnis, eine Aktion auszuführen. Agentendefinitionen bei OpenAI

Tools und MCP: Auf Geschäftssysteme zugreifen

Das Model Context Protocol (MCP) ist eine standardisierte Schnittstelle zwischen KI-Anwendungen und externen Funktionen. Es definiert benannte Tools mit einem inputSchema, ihre Ermittlung über tools/list und ihren Aufruf über tools/call. Eine Kontoabfrage lässt sich über MCP oder über eine gewöhnliche Funktion bereitstellen, die eine Geschäfts-API aufruft. In beiden Fällen muss der dahinterliegende Dienst die Argumente validieren und den Zugriff auf das richtige Konto beschränken. MCP vereinheitlicht die Anbindung; der MCP-Erklärartikel erläutert das Protokoll und seine Vertrauensgrenzen. MCP-Spezifikation für Tools

Gedächtnis: Den passenden Kontext bewahren

Googles Agent Development Kit (ADK), ein Framework zum Entwickeln von Agenten, nutzt Session und state für Informationen innerhalb einer Interaktion. Komponenten wie Memory Bank ermöglichen ein sitzungsübergreifendes Gedächtnis. Im Support sollten der aktuelle Fall und eine ausstehende Freigabe im Anwendungsspeicher liegen. Aktuelle Kontodaten werden aus dem Quellsystem abgerufen; Kundenpräferenzen werden nur gespeichert, wenn das angemessen ist. Diese Aufgaben gehören getrennt betrachtet. Der Leitfaden zum Agentengedächtnis erklärt Kontext, Sitzungsspeicher und längerfristiges Gedächtnis. Architekturleitfaden von Google Cloud

Orchestrierung: Fortschritt, Pausen und Wiederaufnahme steuern

Laut OpenAIs Leitfaden zur Agentenentwicklung übernimmt das Agents SDK den Tool-Zyklus, Übergaben und Schutzprüfungen. Damit erhält die Anwendung eine Ausführungskomponente für modellgesteuerte Arbeit. Um diese Komponente herum muss dauerhaft festgehalten werden, ob sich ein Ticket in Untersuchung befindet, auf Prüfung wartet, gerade bearbeitet wird oder abgeschlossen ist. So kann ein neu gestarteter Prozess den Fall wieder aufnehmen. Der Leitfaden zur Orchestrierung beschreibt, wie Agentenläufe in einen längeren Geschäftsprozess eingebettet werden. OpenAIs Agentenleitfaden

Schutzregeln und menschliche Freigabe: Auswirkungen kontrollieren

Das OpenAI Agents SDK trennt automatische Schutzprüfungen von Freigabeunterbrechungen, die einen Tool-Aufruf pausieren und einen fortsetzbaren Zustand zurückgeben. Beim Support-Agenten werden Kontozugriff und vorgeschlagene Argumente automatisch geprüft. Vor einer sensiblen Änderung muss anschließend eine befugte Person zustimmen. Die Durchsetzung dieser Regeln gehört direkt an das Tool, das die Aktion ausführt. Der Leitfaden zu Schutzregeln behandelt die Prüfungen ausführlich. Schutzregeln und menschliche Prüfung bei OpenAI

Evaluation und Beobachtbarkeit: Ablauf und Qualität nachvollziehen

Das Tracing im OpenAI Agents SDK erfasst Modellaufrufe, Tool-Aufrufe, Übergaben und Schutzprüfungen. OpenAIs Anleitung zur Trace-Bewertung erklärt, wie sich das Verhalten eines Workflows anhand ausdrücklicher Kriterien bewerten lässt. Beobachtbarkeit macht den Verlauf eines Support-Tickets sichtbar. Die Evaluation prüft, ob der Agent das richtige Konto gewählt, die Richtlinie eingehalten und eine belegte Antwort geliefert hat. Welche Daten erfasst und wie lange sie aufbewahrt werden, sollte vor dem Vergleich von Tools für LLM-Beobachtbarkeit feststehen. Tracing im SDK, Evaluation von Agenten

Die Referenzarchitektur von Google Cloud verbindet ADK, Cloud Run, Modellzugriff, MCP-Anbindungen, Model Armor und Beobachtbarkeit zu einer konkreten Bereitstellung. Das dokumentierte Beispiel lässt Gedächtnis und Sitzungsspeicher im Schaubild ausdrücklich aus. Ein dauerhaft gespeicherter Fallzustand bleibt damit eine eigene Entwurfsentscheidung und darf nicht als bereits enthalten vorausgesetzt werden. Referenzarchitektur

Vom eingehenden Ticket zur abschließenden Antwort

Der Agent braucht einen klar abgegrenzten Fall, dessen Abschluss sich überprüfen lässt. In diesem Beispiel meldet ein Kunde, dass er für den Zugang bezahlt hat, den Dienst aber weiterhin nicht nutzen kann. Der Agent darf den Fall untersuchen und eine Korrektur vorbereiten. Während der ersten Einführungsphase gibt eine Support-Leitung sowohl Kontoänderungen als auch die ausgehende Antwort frei.

Die folgenden Tool-Namen bezeichnen selbst zu implementierende Anwendungsfunktionen, keine fertige Support-Integration eines Anbieters.

1. 1

   Den Fall annehmen und zuordnen

   Der Ticket-Webhook, ein vom Support-System gesendetes Ereignis, legt anhand der externen Ticket-Kennung einen Fall an oder nimmt ihn wieder auf. Die Authentifizierung des Kunden erfolgt über den bestehenden Kontoablauf. Eine in die Nachricht geschriebene E-Mail-Adresse darf keinen Zugriff auf ein Konto begründen. Die eingehende Nachricht wird als nicht vertrauenswürdiger Kundeninhalt gespeichert.

2. 2

   Belege mit eng begrenzten Tools abrufen

   Der Agent erhält Funktionen wie get_account_entitlement und search_support_policy. Im Anwendungscode wird der Kontozugriff an die authentifizierte Identität gebunden; zurückgegeben werden der relevante Datensatz und ein Verweis auf die Richtlinie. Das Modell kann entscheiden, welche Belege es anfordert, ohne uneingeschränkten Datenbankzugriff zu erhalten.

3. 3

   Einen belegten Vorschlag vorbereiten

   Das Modell gleicht die Kundenmeldung mit dem Kontodatensatz und der geltenden Richtlinie ab. Rechtfertigen die Belege eine Berechtigungskorrektur, entwirft es die Änderung und die Antwort. Fehlen Belege oder widersprechen sie einander, fragt es nach oder eskaliert den Fall. Die Belegverweise werden zusammen mit dem Vorschlag gespeichert, damit die prüfende Person dessen Grundlage nachvollziehen kann.

4. 4

   Vor dem Eingriff eine Freigabe abwarten

   Die vorgeschlagene Operation wird anhand der Richtlinie validiert. Anschließend werden die ausstehende Aktion und ihr Freigabestatus gespeichert. Die Support-Leitung sieht das betroffene Konto, die genaue Änderung, die zugehörigen Belege und die vorgesehene Kundenantwort. Bei einer Ablehnung bleibt der Schreibzugriff gesperrt; der Fall geht zur Überarbeitung oder manuellen Bearbeitung zurück.

5. 5

   Die Aktion ausführen und das Ergebnis prüfen

   Nach der Freigabe wird erneut geprüft, ob Konto und Vorschlag noch dem geprüften Stand entsprechen. Erst dann wird das Korrektur-Tool aufgerufen. Sofern der dahinterliegende Dienst es unterstützt, kommt ein Idempotenzschlüssel zum Einsatz: eine Kennung, die verhindert, dass dieselbe Operation bei einem Wiederholungsversuch erneut angewendet wird. Bevor eine Antwort die Wiederherstellung des Zugangs bestätigt, muss die resultierende Berechtigung geprüft werden. Das Versandergebnis wird protokolliert, bevor der Fall als abgeschlossen gilt.

6. 6

   Das Ergebnis für die Evaluation nutzbar machen

   Ausführungsergebnis, freigegebene Antwort und endgültiger Fallstatus werden mit dem Trace verknüpft. Unklare Ergebnisse gehen an eine Person zur Prüfung. Ein Timeout wird weder als Erfolg noch als Fehlschlag gewertet. Findet die Prüfung einen Fehler, wird ein entsprechend bereinigtes Beispiel in den Evaluationsdatensatz aufgenommen.

Besonders kritisch ist ein Schreibvorgang mit unklarem Ausgang: Der Kontodienst könnte die Änderung bereits übernommen haben, obwohl die Anwendung keine Antwort erhalten hat. Vor einem erneuten Versuch muss deshalb ein Abgleich mit dem Quellsystem erfolgen. Der Satz „Ich werde den Zugang wiederherstellen“ in einem Gesprächsprotokoll belegt eine Absicht, aber keine geänderte Zugangsberechtigung.

Architekturmuster: Wann lohnt sich ein weiterer Agent?

Solange eine Aufgabe mit einer einheitlichen Richtlinie, einem gemeinsamen Tool-Satz und einer klaren Zuständigkeit auskommt, genügt ein einzelner Agent. Ein Spezialist lohnt sich, wenn er ein nachweisbares Problem bei der Aufgabentrennung löst. Anschließend muss geprüft werden, ob der Nutzen den zusätzlichen Koordinationsaufwand übersteht.

OpenAI unterscheidet zwischen Handoffs, bei denen ein Spezialist das Gespräch übernimmt, und Agenten als Tools, bei denen der Hauptagent einen Spezialisten aufruft, die Verantwortung für die Antwort aber behält. Der Leitfaden empfiehlt eine Aufteilung, wenn sich Anweisungen, Fähigkeiten oder Richtlinien wesentlich unterscheiden. Orchestrierung und Übergaben

Im Support-Fall rechtfertigen die Suche nach einem Hilfeartikel und der Entwurf einer Antwort nicht automatisch getrennte Agenten. Ein Abrechnungsstreit kann das durchaus: Er benötigt möglicherweise eine andere Richtlinie, Finanz-Tools mit beschränktem Zugriff und eine andere prüfende Person. Der Spezialist kann eine abgegrenzte Einschätzung liefern, während der Support-Agent für den Fall verantwortlich bleibt. Soll der Abrechnungsprozess die Führung übernehmen, wird die Zuständigkeit ausdrücklich übergeben.

Multi-Agenten-Systeme im Schaubild: Nach Verantwortung aufteilen

Eine abweichende Richtlinie ist ein sinnvoller Anlass für eine Aufteilung, aber keine allgemeine Voraussetzung. Auch voneinander getrennte Rechercheaufgaben können parallele Agenten rechtfertigen. Dafür muss die abschließend verantwortliche Instanz widersprüchliche Ergebnisse zusammenführen können, und der beobachtete Nutzen muss die zusätzliche Modellarbeit rechtfertigen.

Vor dem Einsatz eines Spezialisten sollte feststehen, welchen Fehler er beheben soll: die Wahl des falschen Tools, widersprüchliche Anweisungen, einen überladenen Kontext oder fehlendes Fachwissen. Der neue Entwurf wird an denselben Fällen geprüft, einschließlich der Fehlerfälle. Er bleibt nur dann bestehen, wenn die Verbesserung zusätzliche Latenz, zusätzlichen Verbrauch und mehr Aufwand für Fehlersuche und Prüfung rechtfertigt. Das ist eine Entscheidungsregel, kein Leistungsversprechen.

Die Rollenbezeichnungen „Rechercheur“, „Kritiker“ und „Manager“ schaffen noch kein unabhängiges Urteil. Stützen sich alle Agenten auf dieselben falschen Belege, kann ihre Einigkeit lediglich denselben Fehler wiederholen. Eine breitere Einordnung bietet die Übersicht der KI-Agententypen.

Zukaufen oder selbst entwickeln: Wer trägt welche Verantwortung?

Austauschbare Technik lässt sich zukaufen; die fachlichen Anforderungen und Zusagen bleiben in eigener Verantwortung. Bei einem ersten Agenten im produktiven Einsatz ist eine Eigenentwicklung vor allem dann sinnvoll, wenn der Workflow ein Verhalten verlangt, das eine verfügbare Komponente weder abbilden noch zugänglich machen kann.

Für Gründer: Ein verwaltetes Agentenprodukt ist sinnvoll, wenn es den tatsächlichen Workflow, die erforderlichen Freigabegrenzen und den Export von Belegen unterstützt. Standardkomponenten bilden die Grundlage für eine eigene Lösung, wenn kontospezifische Richtlinien oder das Integrationsverhalten den entscheidenden Unterschied ausmachen. Eine überzeugende Vorführung reicht nicht aus, wenn sich ein pausierter Fall nicht wieder aufnehmen oder eine fehlgeschlagene Aktion nicht untersuchen lässt.

Für CTOs und Entwickler: Geschäfts-Tools sollten eng begrenzt und unabhängig vom Modell testbar sein. Eine verwaltete Laufzeitumgebung kann die Anwendung betreiben. Den Unterschied zwischen einem Kunden, der eine Erstattung verlangt, und einem Mitarbeiter, der sie ausstellen darf, kann sie nicht selbst herleiten. Diese Unterscheidung gehört in den Dienst, der die Operation ausführt.

Für Betriebsverantwortliche: Die Verantwortung umfasst die Warteschlange für Ausnahmefälle und die Definition eines gelösten Falls. Es muss feststehen, wer einen ungelösten Fall übernimmt, welche Belege diese Person erhält und wann ein Ticket geschlossen werden darf. Eine unbeaufsichtigte Freigabewarteschlange ist ein unvollständiger Workflow.

Codeausführung ist für diesen Support-Agenten optional. Muss eine spätere Aufgabe generierten Code ausführen, ist die Isolation dafür gesondert zu planen. Dabei hilft der Leitfaden zu Code-Sandboxes für Agenten. Für eine bloße Kontoabfrage braucht es keine allgemeine Shell.

Wo Menschen freigeben und was von Anfang an ins Protokoll gehört

Die Freigabe gehört unmittelbar vor die Aktion, für die eine übertragene Befugnis erforderlich ist. Wird die Formulierung des Agenten erst geprüft, nachdem das Konto bereits geändert wurde, kann diese Prüfung die Änderung nicht mehr verhindern.

OpenAIs Freigabemechanismus liefert einen pausierten Lauf und einen fortsetzbaren Zustand zurück. Die Anwendung klärt die ausstehende Entscheidung und setzt den Lauf fort. Dieselbe Dokumentation weist darauf hin, dass Eingabe- und Ausgabeprüfungen auf Agentenebene nicht jeden dazwischenliegenden Tool-Aufruf abdecken. Deshalb braucht die Grenze zur Aktionsausführung eine eigene Validierung. Freigabeablauf und Grenzen der Workflow-Prüfung

In der beispielhaften Einführungsphase sieht die prüfende Person die genaue Kontoänderung zusammen mit der Antwort. Ändern sich nach der Prüfung die Aktion, der Empfänger oder die Beleglage, ist eine neue Entscheidung erforderlich. Gespeichert wird, wer was freigegeben hat, welche Richtlinie galt und ob die Ausführung der Freigabe entsprach.

Die folgende Liste dient als Ausgangspunkt für verbindliche Protokollanforderungen. Ein Trace verknüpft die Ereignisse eines Falls; ein Span erfasst eine einzelne Operation darin.

• Fallzuordnung: Fallkennung, Trace-Kennung, auslösendes Ereignis und Referenz auf das authentifizierte Konto. Referenzen vermeiden, dass Kundendaten an jeder Stelle erneut gespeichert werden.
• Konfiguration: vom Anbieter zurückgegebene Modellkennung, Anweisungsversion, Tool-Schemaversion und Richtlinienversion. Sie zeigen, welche Verhaltensvorgaben zu diesem Zeitpunkt galten.
• Belege: Kennungen abgerufener Dokumente, relevante Versionsstände und Zugriffsumfang. Festgehalten wird die Entscheidungsgrundlage, ohne wahllos private Datensätze zu kopieren.
• Aktionen: Tool-Name, um sensible Inhalte bereinigte Argumente, Zeitstempel, Dauer, Ergebnisstatus sowie Wiederholungs- oder Idempotenzkennung. Die Informationen müssen ausreichen, um eine vorgeschlagene von einer abgeschlossenen Aktion zu unterscheiden.
• Entscheidungen: Validierungsergebnisse, Eskalationsgrund, Freigabestatus, Referenz auf die prüfende Person und der freigegebene Vorschlag.
• Ergebnis und Verbrauch: endgültiger Ticketstatus, bestätigte Auswirkungen, Zustellergebnis, vom Anbieter gemeldeter Verbrauch und Evaluationskennzeichnungen. Korrekturen durch Kunden oder wieder geöffnete Fälle werden erfasst, sofern das Support-System sie bereitstellt.

Das ist ein empfohlenes Anwendungsschema, keine Zusage, dass ein SDK jedes Feld automatisch erfasst. Zugriffe müssen beschränkt, Aufbewahrungsfristen festgelegt und Geheimnisse vor dem Export entfernt werden. Verborgene interne Modellüberlegungen gehören nicht zu den Protokollanforderungen. Der Prüfpfad muss sich auf beobachtbare Eingaben, Ausgaben, Aktionen und Belege stützen.

Welche Grenzen zählen und welche Erwartungen überzogen sind

Die wichtigste Grenze ist die übertragene Befugnis. Für Laufdauer, Tool-Aktivität und Ressourcenverbrauch braucht es ausdrückliche Obergrenzen sowie einen klaren Eskalationsweg. Die Werte ergeben sich aus der Arbeitslast und den Anforderungen an den Dienst, nicht aus einer beliebigen Demo-Vorgabe.

Das Gedächtnis ist keine maßgebliche Datenquelle. Steht in einem gespeicherten Gespräch, dass der Kunde Zugang hat, während das Kontosystem etwas anderes meldet, muss der Widerspruch anhand aktueller, verbindlicher Datensätze untersucht werden. Mehr gespeicherter Text macht veraltete Belege nicht aktueller.

MCP erteilt keine Berechtigungen. Die Tool-Spezifikation verlangt weiterhin Zugriffskontrollen und Eingabevalidierung. Ein Konnektor mit weitreichenden Operationen erfordert dieselbe Prüfung der fachlichen Berechtigungen wie eine eigene API. MCP-Sicherheitsanforderungen

Ein abgeschlossener Lauf ist noch kein erfolgreich gelöster Fall. Geprüft werden muss, ob das richtige Konto geändert, die Richtlinie eingehalten und das Ergebnis in der Antwort korrekt wiedergegeben wurde. OpenAIs Evaluationsleitfaden führt von der Untersuchung einzelner Traces zu wiederholt nutzbaren Datensätzen, mit denen Änderungen anhand einheitlicher Kriterien bewertet werden können. Evaluation von Agenten-Workflows

Mehrere Agenten ersetzen keine klare Zuständigkeit. Jemand muss die Verantwortung für die endgültige Antwort, die gemeinsam genutzten Belege und offene Ausnahmefälle tragen. Ein Spezialist ist dann nützlich, wenn er eine andere Verantwortung übernimmt. Ein aufwendigeres Architekturschaubild allein rechtfertigt ihn nicht.

Häufige Fragen zur Agentenarchitektur

Was gehört zur Architektur eines KI-Agenten?

Die Architektur eines KI-Agenten verbindet Modellentscheidungen, Tools, Gedächtnis, Orchestrierung, Kontrollmechanismen und Evaluation so, dass eine Anwendung eine Aufgabe verfolgen kann. Bei einem Agenten für Geschäftsprozesse legt sie außerdem fest, wer Aktionen autorisieren darf und wie deren Abschluss überprüft wird.

Wie funktioniert ein KI-Agent grundsätzlich?

Ein KI-Agent nutzt ein Modell, um auf ein Ziel ausgerichtete Aktionen auszuwählen. Er beobachtet deren Ergebnisse und entscheidet über das weitere Vorgehen. Seine nutzbare Autonomie wird durch die Tools, Berechtigungen und Abbruchregeln begrenzt, die die Anwendung vorgibt.

Welche Arten von Agentenarchitekturen gibt es?

Praktisch lässt sich zwischen einem vordefinierten Workflow, einem einzelnen Agenten mit Tool-Auswahl und zusammenarbeitenden Spezialisten unterscheiden. Welche Variante passt, hängt von der Vorhersehbarkeit der Aufgabe ab und davon, ob unterschiedliche Verantwortlichkeiten getrennte Tools, Richtlinien oder Zuständigkeiten erfordern. Das sind Umsetzungsmuster, keine allgemeingültige Taxonomie.

Der nächste Schritt: Erst den Fall skizzieren, dann die Technik wählen

Ein Einstieg ist sinnvoll, wenn regelmäßig vergleichbare Support-Anfragen anfallen, die Quelldaten zugänglich sind und eine Person die Verantwortung für Ausnahmefälle trägt. An einem repräsentativen Fall werden das eingehende Ereignis, erlaubte Lesezugriffe, vorgeschlagene Schreibzugriffe, der Freigabepunkt und die für den Abschluss erforderlichen Belege markiert. Der erste Workflow erstellt Entwürfe zur Prüfung. Beobachtete Fehler zeigen anschließend, welche Berechtigungen sich verantwortbar erweitern lassen.

Mit autonomer Ausführung sollte gewartet werden, solange die Kontozuordnung, die Verantwortung für Richtlinien oder der Nachweis des Abschlusses ungeklärt sind. Informationsabruf und Antwortentwürfe lassen sich bereits verbessern, während diese Voraussetzungen geschaffen werden. Folgt der Workflow schon verlässlichen deterministischen Regeln und benötigt kein Modellurteil, sollte diese Automatisierung bestehen bleiben.

Das erste Ergebnis sollte ein Fall sein, dessen Weg vom Eingang bis zum Ausgang nachvollziehbar ist. Dazu gehört auch, was bei einer verweigerten Freigabe oder einem unbekannten Tool-Ergebnis passiert.

Praxisleitfäden zur Entwicklung und zum Betrieb von KI-Systemen gibt es im Newsletter.