KI-Agenten an bestehende Unternehmenssysteme anbinden: Architektur, Abläufe und Sicherheitspraxis

Zunächst klären, was „Anbindung“ bedeutet: Das Modell sollte keine direkten Systemberechtigungen besitzen

Wenn Unternehmen AI Agents an ERP-, CRM-, Büroautomatisierungs-, Ticket- oder Wissensmanagementsysteme anbinden, geht es im Kern nicht darum, das Modell mit einer Datenbank zu verbinden. Vielmehr soll es im Rahmen klarer Berechtigungen über kontrollierte Werkzeuge Abfragen, Bewertungen oder begrenzte Aktionen durchführen. Das Modell versteht die Anforderungen und schlägt den nächsten Schritt vor; die Werkzeugschicht definiert und validiert die Aktionen. Die Unternehmenssysteme bleiben die maßgebliche Quelle für Geschäftsdaten und Regeln.

Ein Vorschlag des Agents bedeutet nicht, dass das System ihn bereits ausgeführt hat. Ebenso bedeutet ein erfolgreicher Werkzeugaufruf nicht, dass das Geschäftsergebnis korrekt ist. Beides muss überprüft werden. Informationen zur Funktionsweise von Werkzeugaufrufen finden Sie in der OpenAI-Dokumentation zu Funktionsaufrufen: Das Modell erzeugt anhand der Definitionen die Angaben für den Werkzeugaufruf; die eigentliche Ausführung übernimmt weiterhin die Anwendung.

Erst die Aufgaben erfassen, dann das anzubindende System wählen

Beginnen Sie bei den Geschäftsprozessen, nicht bei technischen Begriffen. Erfassen Sie die zu erledigenden Aufgaben, beteiligten Systeme, Ein- und Ausgabedaten, bisherigen manuellen Schritte, Folgen von Fehlern und Aktionen, die Mitarbeitende genehmigen müssen. Wählen Sie anschließend den ersten Anwendungsfall anhand von Geschäftswert, Datensensibilität, Schnittstellenreife, Fehlerauswirkungen und Freigabeanforderungen aus.

Prüfen Sie beispielsweise zunächst die „Zuordnung von Kundenservice-Tickets“: Der Agent liest neue Tickets und internes Wissen und schlägt eine Kategorie sowie die zuständige Gruppe vor. Die Werkzeugschicht prüft, ob Ticketnummer, Kategorie und Gruppe gültig sind. Für einen risikoarmen Einstieg werden zunächst nur Vorschläge erstellt; erst nach Bestätigung durch den Kundenservice wird das Ticket aktualisiert. Dieses Beispiel setzt keine bestimmten Systemfunktionen voraus. Vor der Umsetzung müssen die tatsächlich verfügbaren Schnittstellen und Berechtigungen geprüft werden.

API, Webhook, Funktionsaufrufe oder RPA: Was passt wann?

API eignet sich für klar definierte Abfragen und Geschäftsvorgänge. Die Werkzeugschicht kann Systemschnittstellen in eng begrenzte, klar umrissene Aktionen kapseln, etwa „Ticketstatus abfragen“, statt weitreichende allgemeine Abfragemöglichkeiten bereitzustellen. Prüfen Sie das Authentifizierungsverfahren, die Felddefinitionen, die Fehlerantworten und die Testumgebung.

Funktionsaufrufe sind eine Interaktionsform, bei der das Modell vordefinierte Tools auswählt und deren Parameter ausfüllt – keine neue Schnittstelle zu Unternehmenssystemen. Sie sollten mit serverseitiger Validierung kombiniert werden: Nur weil das Modell Parameter liefert, sind diese weder automatisch vertrauenswürdig noch ist die Aktion damit autorisiert. Die Dokumentation zu Funktionsaufrufen von OpenAI erläutert, dass die Anwendung nach einer Tool-Aufrufanfrage des Modells den entsprechenden Code ausführen und das Ergebnis in den Gesprächsablauf zurückgeben muss.

Webhooks eignen sich für Folgeprozesse, die durch Geschäftsereignisse ausgelöst werden, etwa um einen Integrationsdienst zu benachrichtigen, wenn ein System einen offenen Vorgang erzeugt. Bei der Ereigniszustellung sollten Duplikate, Verzögerungen, Reihenfolge und Wiederholungsversuche nach Fehlern berücksichtigt werden; die tatsächliche Semantik hängt vom angebundenen System ab. Die Webhook-Dokumentation von GitHub beschreibt unter anderem den Umgang mit fehlgeschlagenen Zustellungen und erneuten Zustellungen. Sie kann als Beispiel zur Überprüfung des Verhaltens einer konkreten Plattform dienen, ist aber keine allgemeingültige Garantie für alle Dienste.

RPA kann als Übergangslösung dienen, wenn keine geeigneten Schnittstellen verfügbar sind, indem Altsysteme über ihre Benutzeroberfläche bedient werden. Änderungen an der Oberfläche, der Anmeldestatus und unerwartete Dialogfenster können den Ablauf jedoch beeinträchtigen. Daher müssen Stabilität, Betriebsüberwachung und Wartungskosten bewertet und für kritische Schreibvorgänge Kontrollmechanismen vorgesehen werden. Die Erläuterungen in der UiPath-Dokumentation zu Selektoren und zur Erkennung von Oberflächenelementen verdeutlichen, dass auch die Lokalisierung von Elementen in der Zielanwendung überprüft und gepflegt werden muss.

Orchestrierung über eine Zwischenschicht eignet sich für Szenarien, in denen mehrere Systeme verbunden sowie Identitäten und Regeln vereinheitlicht werden müssen. Sie ermöglicht eine zentrale Verarbeitung von Transformationen, Validierungen und Audit-Protokollen, bringt aber zusätzliche Komponenten und Betriebsverantwortung mit sich. Bei der Auswahl zählt nicht nur die Geschwindigkeit der Anbindung, sondern auch die Fehlerlokalisierung, die Trennung von Berechtigungen und die langfristige Wartung.

Empfohlene Architektur: Planung, Ausführung und Governance trennen

1. Agentenebene: Versteht Anfragen, stellt den Kontext zusammen und schlägt einen Plan für Tool-Aufrufe vor; verfügt über keine Datenbankzugangsdaten.
2. Tool-Ebene: Definiert für jede Aktion Zweck, Parametertypen, Pflichtfelder, zulässige Wertebereiche und Rückgabestruktur; die Validierung erfolgt erneut auf dem Server.
3. Integrationsebene: Verbindet Systeme wie ERP, CRM und Büroautomatisierungssysteme und übernimmt Authentifizierung, Protokollanpassung, Zeitüberschreitungen und Fehlerzuordnung.
4. Berechtigungs- und Freigabeebene: Verknüpft Mitarbeiteridentitäten, Dienstidentitäten und Aktionsberechtigungen; verlangt bei Aktionen mit erheblichen Auswirkungen eine Bestätigung.
5. Protokollierungs- und Bewertungsebene: Erfasst aufrufende Identität, Tool, erforderliche Zusammenfassungen der Anfragen, Ergebnisse und Ausnahmen und ermöglicht nachträgliche Analysen sowie die Auswertung von Kennzahlen.

Die Zuständigkeiten müssen klar sein: Das Modell schlägt vor, „was getan werden soll“, der Tool-Dienst prüft, „ob es erlaubt ist und die Parameter gültig sind“, und das Geschäftssystem bestimmt, „wie der endgültige Zustand aussieht“. Das Modell darf die Tool-Ebene nicht umgehen und selbst über Zugangsdaten für die Produktionsdatenbank verfügen. Die Schichtenarchitektur ist eine Empfehlung für die Implementierung; die konkreten Komponentengrenzen sollten sich nach den Fähigkeiten der Systeme und den Kontrollanforderungen der Organisation richten. Der Beitrag Einführung in die Arbeitsidentität von Gemini-Agenten für Unternehmen kann helfen, die Rolle von Identitäten und Berechtigungen bei Unternehmensagenten zu verstehen. Diese Seite ist eine Produktvorstellung und ersetzt keine Bewertung der eigenen Architektur.

Vom Pilotprojekt zum Produktivbetrieb: risikoorientiert schrittweise erweitern

Schritt 1: Ein klar begrenztes Szenario wählen. Legen Sie Auslösebedingungen, Abschlusskriterien und den Umgang mit Fehlern fest. Die bloße Möglichkeit, ein System anzubinden, ersetzt kein Geschäftsziel.

Schritt 2: Tool-Verträge definieren. Beschreiben Sie für jedes Tool Zweck, Parameter, Berechtigungen, mögliche Nebenwirkungen, Fehlertypen und Verfahren zur Ergebnisprüfung. Teilen Sie die Funktionen möglichst in einzelne Aktionen auf, statt ein Tool gleichzeitig Abfragen, Änderungen und Löschungen ausführen zu lassen.

Schritt 3: Zuerst eine Testumgebung anbinden. Testen Sie mit repräsentativen Eingaben, Grenzwerten, fehlenden Feldern und unerwarteten Antworten. Prüfen Sie, ob der Agent bei unzureichenden Informationen nachfragt, statt Parameter zu erraten.

Schritt 4: Schutzmaßnahmen einrichten und schrittweise ausrollen. Beginnen Sie im Nur-Lese- oder Empfehlungsmodus und erlauben Sie erst danach genehmigte Schreibaktionen mit geringem Risiko. Legen Sie Aufruflimits, Zeitüberschreitungen und Warnmeldungen fest. Definieren Sie klar, wann bei Fehlern abgebrochen, ein erneuter Versuch gestartet oder an einen Menschen übergeben werden soll.

Schritt 5: Auswerten und anschließend den Umfang erweitern. Erfassen Sie Fehlklassifizierungen, ungültige Parameter, doppelte Aufrufe und Gründe für die Übernahme durch Mitarbeitende. Erwägen Sie eine Erweiterung des Aktionsumfangs erst dann, wenn die Ergebnisse überprüfbar, die Berechtigungsgrenzen klar und die Verfahren zur Behandlung von Ausnahmefällen festgelegt sind.

Die Ticket-Zuordnung lässt sich beispielsweise schrittweise einführen: Zunächst werden Tickets nur gelesen und Klassifizierungen vorgeschlagen. Anschließend wird die Klassifizierung nach Bestätigung durch Mitarbeitende gespeichert. Erst danach wird geprüft, ob Tickets mit eindeutigen Regeln und rückgängig zu machender Zuweisung automatisch zugewiesen werden können. Legen Sie für jede Phase Abbruchkriterien fest. Nehmen Fehlzuweisungen zu oder ist keine Auditierung möglich, kehren Sie zur manuellen Bestätigung zurück. Zur Bewertung des Risikos, dass Agenten ihre Befugnisse überschreiten, können Sie den Beitrag auf dieser Website zur Diskussion über Sicherheitsvorfälle mit Agenten heranziehen. Maßgeblich sollten jedoch Tests im tatsächlichen System sein.

Sicherheit und Governance: Kontrollen in konkrete Prüfpunkte überführen

• Minimale Berechtigungen und eigene Identität: Gewähren Sie der Dienstidentität des Agenten nur Zugriff auf die Systeme und Aktionen, die zur Aufgabenerfüllung erforderlich sind. Prüfen Sie vor der Inbetriebnahme, ob die Zugangsdaten ausschließlich dafür vorgesehen sind, regelmäßig gewechselt werden können und keine sachfremden Schreibrechte umfassen.
• Kontrolle sensibler Felder: Stellen Sie dem Modell nur die Informationen bereit, die es zur Aufgabenerfüllung benötigt. Prüfen Sie Eingabe-, Ausgabe- und Protokollfelder einzeln und verifizieren Sie, ob die Regeln zur Maskierung sensibler Daten greifen.
• Schutz vor Prompt-Injection und Berechtigungsüberschreitungen: Behandeln Sie externe Texte wie E-Mails, Tickets und Webseiten als Daten, nicht als autorisierte Anweisungen. Prüfen Sie mit Testinhalten, die zu zusätzlichen Aufrufen oder Datenexporten verleiten sollen, ob die Berechtigungsregeln solche Aktionen weiterhin ablehnen oder eine Bestätigung verlangen. Die OWASP-Sicherheitsmaterialien für LLM-Anwendungen führen Prompt-Injection als eine zu berücksichtigende Risikokategorie auf.
• Schutz bei Schreibzugriffen: Richten Sie für Änderungen an Produktivsystemen Parameterprüfungen, eine Vorschau der Auswirkungen, Freigaben und das anschließende Auslesen der Ergebnisse ein. Prüfen Sie, ob die freigegebenen Inhalte mit den tatsächlich übermittelten Inhalten übereinstimmen.
• Idempotenz und Fehlerbehandlung: Sehen Sie für Aktionen, die möglicherweise mehrfach übermittelt werden, Deduplizierungsschlüssel oder Statusprüfungen vor. Testen Sie Zeitüberschreitungen, Wiederholungsversuche und Teilerfolge jeweils separat und stellen Sie sicher, dass sich nach einem Fehler der tatsächliche Systemzustand ermitteln lässt.
• Auditierung und Verantwortlichkeit: Protokollieren Sie die erforderlichen Angaben zu Identität, Aktion, Zeitpunkt, Ergebnis und Freigabe und beschränken Sie den Zugriff auf die Protokolle. Prüfen Sie stichprobenartig, ob sich eine Änderung im Geschäftsprozess bis zum Aufruf und zur zugrunde liegenden Autorisierung zurückverfolgen lässt.

Minimale Berechtigungen, Autorisierung und Auditierbarkeit lassen sich auch anhand der OWASP-Materialien zu Bedrohungen und Gegenmaßnahmen bei agentischer KI überprüfen und anschließend im Einklang mit den Vorgaben der Organisation für Identitätsmanagement und Auditierung umsetzen. Diese Materialien ersetzen keine Sicherheitsbewertung des konkreten Systems.

So messen Sie die Wirksamkeit der Integration

Bewerten Sie nicht nur, wie flüssig die Antworten formuliert sind. Auf technischer Seite können Sie die Aufgabenerfüllungsquote, die Fehlerquote bei der Parameterprüfung, die Aufruffehlerquote, die Antwortlatenz, Mehrfachausführungen und die Quote menschlicher Übernahmen beobachten. Auf operativer Seite sind Bearbeitungszeiten, Veränderungen des Rückstands, der Prüfaufwand und die Aufrufkosten pro Aufgabe relevant. Definieren Sie zunächst eindeutig, wie die Kennzahlen ermittelt werden: Bedeutet „abgeschlossen“ beispielsweise, dass das Werkzeug Erfolg gemeldet hat, oder dass der Zustand im Geschäftssystem durch erneutes Auslesen bestätigt wurde?

Erfassen Sie vor dem Pilotprojekt die Ausgangswerte des bestehenden Prozesses und vergleichen Sie anschließend denselben Aufgabenumfang. Unterscheiden Sie dabei zwischen Fehlentscheidungen des Modells, Schnittstellenstörungen und Änderungen der Geschäftsregeln. Wenn die Automatisierung den manuellen Prüfaufwand erhöht, sollte sie auch bei einer guten Erfolgsquote der Aufrufe nicht pauschal als Verbesserung gelten. Setzen Sie keine prozentualen Vorteile voraus, sondern entscheiden Sie anhand der tatsächlichen Betriebsdaten Ihres Unternehmens, ob der Einsatz ausgeweitet werden soll.

FAQ

Können Agenten auch Altsysteme ohne API anbinden? Eine Anbindung über eine kontrollierte Zwischenschicht, bestehende Integrationsplattformen oder RPA lässt sich prüfen. Zunächst sollten jedoch Betriebsstabilität, Beobachtbarkeit und Wartungsverantwortung geklärt werden. Bei risikoreichen Schreibvorgängen sollte eine menschliche Bestätigung vorgesehen werden. UI-Automatisierung ist nicht mit einer stabilen API gleichzusetzen.

Müssen bestehende Systeme für die Anbindung von Agenten umgebaut werden? Nicht unbedingt. Verfügt das System bereits über nutzbare APIs oder Ereignismechanismen, lässt sich die Werkzeug- und Berechtigungsschicht meist zunächst außerhalb des Systems aufbauen. Reichen die Schnittstellen nicht aus, sollte je nach Aufgabe geprüft werden, ob zusätzliche Leseschnittstellen, Integrationsadapter oder gezielte Anpassungen nötig sind. Validieren Sie den Anwendungsfall mit möglichst wenigen Änderungen.

Wie lassen sich Fehlaktionen oder Berechtigungsüberschreitungen durch Agenten vermeiden? Legen Sie für jedes Werkzeug den Verwendungszweck, die Parameter und die zugänglichen Objekte fest. Nutzen Sie separate Dienstidentitäten und minimale Berechtigungen. Verlangen Sie für Schreibzugriffe auf Produktivsysteme eine Freigabe oder Bestätigung und protokollieren Sie die aufrufende Identität, Eingaben, Ergebnisse und Fehler. Testen Sie außerdem Szenarien, in denen bösartige Anweisungen oder nicht vertrauenswürdige Inhalte Werkzeugaufrufe auslösen sollen.

Welche Aufgaben sollten nicht von Anfang an automatisch ausgeführt werden? Aufgaben mit schwer umkehrbaren Folgen, unklaren Regeln, vielen impliziten Ermessensentscheidungen oder ohne zuverlässige Prüfmöglichkeiten eignen sich nicht für die ersten unbeaufsichtigten Anwendungsfälle. Lassen Sie den Agenten zunächst Vorschläge erstellen, die Mitarbeitende überprüfen. Entscheiden Sie anschließend anhand der Fehlertypen und Geschäftsrisiken, ob die Automatisierung ausgeweitet werden kann.

Fazit: Mit kleinen, überprüfbaren Aktionen beginnen

Bei der Anbindung von KI-Agenten an bestehende Unternehmenssysteme kommt es auf klar definierte Handlungsgrenzen an: Das Modell schlägt einen Plan vor, kontrollierte Werkzeuge prüfen ihn und führen ihn aus, Berechtigungs- und Auditmechanismen begrenzen Risiken, und die Geschäftssysteme bestätigen das Endergebnis. Beginnen Sie mit risikoarmen, überprüfbaren Anwendungsfällen, die nur Lesezugriffe oder Vorschläge umfassen, und führen Sie anschließend schrittweise freigabepflichtige Schreibvorgänge ein. So erkennt das Team Probleme mit Schnittstellen, Berechtigungen und Governance in realen Abläufen, statt risikoreiche Aktionen auf einen Schlag der Automatisierung zu überlassen.