Agenten im Backoffice: CRM, ERP und Tickets über APIs

Beim DATEV-Export für MAFU-SHERPA entscheiden vier unscheinbare Regeln darüber, ob die Buchungsdatei angenommen wird: Soll/Haben-Kennzeichen, deutsches Dezimaltrennzeichen, leere DATEV-Felder und die vorgeschriebene Spaltenreihenfolge. Die von uns gebaute Anwendung übernimmt die Umformung aus Business Central, zeigt eine Vorschau und lässt die Buchhaltung die Datei vor der Übergabe prüfen. Sie schreibt nicht still in das Zielsystem. Dieser veröffentlichte DATEV-Fall ist ein besserer Ausgangspunkt für Backoffice-Agenten als die Vorstellung eines digitalen Universalmitarbeiters. Er trennt Lesen, Umformen, Prüfen und Übergeben. Ein Agent darf einzelne Schritte beschleunigen, doch die fachlichen Regeln und die Freigabe bleiben außerhalb seines eigenen Urteils.

Lesen Sie breit, schreiben Sie schmal

OWASP nennt in LLM03:2026 Excessive Agency drei Ursachen für übermäßige Handlungsfreiheit: zu viele Funktionen, zu breite Berechtigungen und zu viel Autonomie. Die empfohlenen Gegenmittel sind konkret. Werkzeuge sollen klein und zweckgebunden sein, Rechte minimal bleiben, folgenreiche Aktionen eine Freigabe verlangen, und Autorisierung muss im Code statt im Modellurteil liegen. Für den DATEV-Ablauf hieße das: Der Agent darf einen freigegebenen Business-Central-Export lesen, die bekannten Regeln anwenden und eine Vorschau erzeugen. Er braucht weder Zugriff auf alle Buchungen noch ein offenes „führe beliebigen API-Aufruf aus“-Werkzeug. Die Übergabe bleibt ein eigener, protokollierter Schritt.

Die Freigabe folgt der Umkehrbarkeit

Die OpenAI-Anleitung für Agenten bewertet Werkzeuge unter anderem nach Schreibzugriff, Umkehrbarkeit, Kontorechten und finanzieller Wirkung. Übertragen auf CRM, ERP und Tickets ergibt sich kein pauschales „Mensch in der Schleife“. Jede Aktion bekommt ihre eigene Grenze:

• Nur lesen: Kundendaten, Auftragsstatus oder Ticketverlauf dürfen mit einem eigenen Lesezugang abgefragt werden.
• Reversibel schreiben: Eine interne Notiz oder Wiedervorlage kann nach Prüfung im Pilot automatisch laufen, wenn sie eindeutig zurückgenommen wird.
• Kundenwirksam vorbereiten: Angebot, Antwort oder Gutschrift entsteht als Entwurf mit den zugrunde liegenden Daten.
• Finanziell oder rechtlich wirken: Versand, Buchung, Zahlung und Vertragsänderung brauchen eine benannte Freigabe.
• Unklarer Zustand: Nach einer festen Zahl fehlgeschlagener Versuche stoppt der Agent und eskaliert, statt weiterzuprobieren.
• Idempotenz: Ein Schritt, der zweimal ausgeführt wird, darf keinen doppelten Auftrag erzeugen. Das gehört in die API, nicht in die Hoffnung.

Eine agentenfähige Business-App braucht dafür saubere Entitäten, eindeutige IDs, Rollen, Statusmodelle, Audit- und Ereignisprotokolle, Webhooks, Testumgebungen, Rate Limits und sichere Schreibpfade.

Automatisieren Sie im ersten Pilot keine Aktion, die Geld bewegt oder eine Zusage an Kunden auslöst.

Ein schnellerer Entwurf liefert bereits Nutzen und macht die fachlichen Ausnahmen sichtbar.

Die Identität gehört in das Protokoll

Eine Verbindung über MCP beantwortet noch nicht, in wessen Namen der Agent handelt. Die MCP-Sicherheitsvorgaben vom 28. Juli 2026 untersagen es Servern, fremde Tokens einfach durchzureichen. Solches Token-Passthrough umgeht Prüfungen und lässt nachgelagerte Logs so aussehen, als habe eine andere Identität gehandelt. Berechtigungen sollen klein beginnen und schrittweise erweitert werden. Geben Sie dem Agenten daher eine eigene technische Identität pro System und Zweck. Im Protokoll müssen die gelesenen Datensätze, der Werkzeugaufruf, das Ergebnis und die freigebende Person zusammenfinden. Das BSI empfiehlt ebenfalls minimale und getrennte Zugriffe, Freigaben und regelmäßige Log-Prüfung in seiner deutschen Leitlinie zu KI-Agenten.

Prüfen Sie die drei gefährlichen Zutaten

Im Backoffice treffen schnell fremde Inhalte, private Daten und ein Weg nach außen zusammen. Ein Support-Agent liest etwa eine fremde E-Mail, sieht Kundendaten im CRM und kann eine Antwort senden. Genau diese Kombination beschreibt Simon Willisons „lethal trifecta“. Ein Filter allein löst das Problem nicht zuverlässig. Entfernen Sie stattdessen ein Bein: Der lesende Agent darf den Entwurf speichern, aber nicht versenden. Der DATEV-Fall macht die Trennung greifbar. Die Eingabedatei wird gelesen, die Ausgabe nach festen Regeln erzeugt und in einer Vorschau geprüft. Erst danach übergibt ein Mensch sie an DATEV. Dasselbe Muster passt zu einem Angebotsentwurf, einer Ticketantwort oder einer Gutschrift.

Ein Pilot braucht Fälle, keine Demo

Wählen Sie mehrere echte Vorgänge, darunter fehlende Daten, Dubletten, widersprüchliche Preise und einen wiederholten Werkzeugaufruf. Schreiben Sie für jeden Fall vorher auf, welcher Entwurf entstehen darf, welche Warnung erscheinen muss und was keinesfalls ausgeführt wird. Danach prüfen Sie den erzeugten Datensatz im Zielsystem oder in der Vorschau.

Akzeptieren Sie niemals nur die Meldung des Agenten. Eine Studie über Coding-Agenten dokumentierte ungenaue Selbstauskünfte in realen Sitzungen. Für Backoffice-Arbeit ist das keine gemessene Fehlerquote, aber eine klare Prüflogik: „Ticket aktualisiert“ zählt erst, wenn Ticket-ID, neuer Status, Protokolleintrag und gegebenenfalls Freigabe im System sichtbar sind.

Die Oberfläche ist auch im Benchmark die schwache Stelle

Im unabhängigen TheAgentCompany-Benchmark bearbeiteten Agenten 175 Aufgaben in einer simulierten Softwarefirma. Das stärkste getestete System erledigte 33,8 % der Aufgaben auf GitLab vollständig, aber nur 12,9 % in der ownCloud-Weboberfläche. Die Umgebung war synthetisch und nutzte eine Modellgeneration von 2025, weshalb die absoluten Werte altern. Der Unterschied zeigt dennoch, wie stark die Arbeitsoberfläche das Ergebnis prägt.

Der praktische Startpunkt bleibt deshalb klein: ein vorhandener Ablauf, ein eigener Lesezugang, ein enges Werkzeug, ein prüfbarer Entwurf und eine benannte Freigabe. Der Pillar über APIs statt Bildschirme erklärt den technischen Hintergrund. Der DATEV-Fall zeigt, wie wenig Autonomie nötig ist, um echte Arbeit abzunehmen. Wenn Sie einen eigenen Backoffice-Fall eingrenzen wollen: sprechen wir über den konkreten Ablauf.