KI-Agenten mit ERP und CRM: drei sichere Muster

Warum die Integration der schwierige Teil ist

Ein Modell, das eine gute Antwort entwirft oder eine Rechnung einordnet, ist die leichte Hälfte. Die schwere Hälfte ist, wohin das Ergebnis geht. Ihr ERP und Ihr CRM enthalten die Datensätze, von denen das Geschäft lebt, und ein Agent, der dort schreiben darf, kann sie auch schnell und in großer Menge beschädigen. Die Reflexantwort lautet, das alte System durch etwas für KI Gebautes zu ersetzen. Das ist langsam, teuer und selten nötig. Die bessere Frage ist, wie wenig Zugriff der Agent braucht, um nützlich zu sein, und wie Sie ihn sicher erweitern. Die drei Muster unten beantworten sie in aufsteigender Reihenfolge des Zugriffs. Sie sind Ingenieurpraxis aus unserer eigenen Projektarbeit. Sie sind kein Standard, und wir behaupten hier nichts darüber, was ein bestimmtes ERP- oder CRM-Produkt kann oder nicht kann: Das prüfen Sie an Ihrem System und dessen Dokumentation.

Drei Muster im Überblick

Die Tabelle vergleicht sie danach, was der Agent braucht, wie sie scheitern und wie man sie zurücknimmt. Jedes Muster baut auf dem vorigen auf, und ein Arbeitsablauf kann so lange beim ersten oder zweiten bleiben, wie er will.

Muster 1: der schreibgeschützte Spiegel

Der Agent berührt das Livesystem nie. Ein geplanter Export oder ein Konto mit Lesezugriff kopiert die benötigten Datensätze in einen getrennten Speicher, und der Agent liest nur von dort. Das ist der risikoärmste Einstieg. Der Agent kann offene Aufträge zusammenfassen, doppelte Kontakte finden, Fragen zu einem Kunden beantworten oder einen Bericht vorbereiten, und das schlimmste Ergebnis ist eine falsche Antwort, die ein Mensch liest. Zwei Dinge verdienen Sorgfalt. Erstens: Kopieren Sie nur die Felder, die die Aufgabe braucht, damit personenbezogene Daten nicht ohne Grund verdoppelt werden. Zweitens: Zeigen Sie zu jeder Antwort das Alter der Daten, denn ein Spiegel hinkt immer etwas hinterher.

Muster 2: die Vorschlagswarteschlange

Hier darf der Agent eine Änderung vorschlagen, aber nicht ausführen. Er schreibt jeden Vorschlag in eine Warteschlange, mit dem betroffenen Datensatz, der gewünschten Änderung, seinen Gründen und den Daten, auf die er sich stützt. Ein Mensch prüft den Vorschlag und führt ihn aus oder lehnt ihn mit Begründung ab. So erhalten Sie einen Agenten, der die Vorbereitung erledigt, während die Entscheidung beim Menschen bleibt. Zugleich entsteht der nützlichste Beleg, den Sie haben werden: Jede Genehmigung und Ablehnung zeigt, wie oft der Agent richtig liegt. Das typische Versagen ist das Durchwinken, bei dem Prüfer nur klicken. Dagegen helfen die Begründung neben der vorgeschlagenen Änderung, Stichproben unter den genehmigten Fällen und die Beobachtung der Ablehnungsquote über die Zeit. Unser Artikel zu Mustern der menschlichen Freigabe beschreibt die Varianten.

Muster 3: begrenztes Zurückschreiben

Manche Vorschläge sind so routiniert und so umkehrbar, dass die Freigabe jedes einzelnen durch einen Menschen wenig bringt. Dort können Sie dem Agenten das direkte Schreiben erlauben, aber nur innerhalb einer Grenze, die Sie festlegen. Geben Sie ihm ein eigenes Dienstkonto, niemals die Anmeldung einer Person. Beschränken Sie das Konto auf benannte Datensatztypen, benannte Felder und benannte Aktionen und setzen Sie eine Obergrenze für Schreibvorgänge pro Stunde. Protokollieren Sie jede Änderung mit Werten vor und nach der Änderung und einem Verweis auf Vorschlag oder Auslöser. Halten Sie einen Pausenschalter bereit, der den Schreibpfad stoppt, ohne den Rest des Systems anzutasten. Das Fehlerbild, auf das man auslegen muss, ist ein gültiger, aber falscher Schreibvorgang, der sich über viele Datensätze wiederholt. Obergrenze und Protokoll sorgen dafür, dass er klein und auffindbar bleibt.

Was das Recht hier von Ihnen verlangt

Zwei Vorschriften betreffen diese Arbeit unmittelbar, und keine ist spezifisch für ERP oder CRM. Laut dem AI Act Service Desk der Europäischen Kommission legt Artikel 26 der KI-Verordnung Pflichten für Betreiber von Hochrisiko-KI-Systemen fest, darunter die Übertragung der menschlichen Aufsicht an kompetente Personen, die Überwachung des Betriebs, die Aussetzung der Nutzung bei auftretendem Risiko und die Aufbewahrung automatisch erzeugter Protokolle für mindestens sechs Monate. Er gilt nur für Hochrisiko-Systeme, klären Sie daher mit Ihrer Beratung, ob Ihr Anwendungsfall dazugehört. Artikel 32 der DSGVO verlangt von Verantwortlichen und Auftragsverarbeitern technische und organisatorische Maßnahmen, die dem Risiko angemessen sind, und nennt im Text Maßnahmen wie Pseudonymisierung, Verschlüsselung, die Fähigkeit zur Wiederherstellung der Verfügbarkeit und regelmäßige Tests. Enger Zugriff, getrennte Konten und Aktionsprotokolle sind Wege, eine solche Pflicht zu erfüllen. Für sich allein beweisen sie keine Konformität. Dies sind allgemeine Informationen eines Ingenieurteams, keine Rechtsberatung.

Eine geordnete Go-live-Checkliste

Arbeiten Sie sie der Reihe nach ab und beginnen Sie einen Schritt erst, wenn der vorige erledigt ist. Jeder ist vor dem Start billig und danach teuer.

1. Benennen Sie den einen Arbeitsablauf, die betroffenen Datensätze und die Person, die für das Ergebnis verantwortlich ist.
2. Listen Sie die genauen Felder auf, die der Agent braucht, und lassen Sie alles andere im Spiegel weg.
3. Richten Sie ein eigenes Konto oder einen Export nur mit Lesezugriff ein und bestätigen Sie per Test, dass es nicht schreiben kann.
4. Lassen Sie den Agenten in einer Testphase nur gegen den Spiegel laufen und Menschen seine Antworten mit den echten Datensätzen vergleichen.
5. Fügen Sie die Vorschlagswarteschlange hinzu, mit der Begründung neben jeder vorgeschlagenen Änderung und einer Pflichtbegründung bei jeder Ablehnung.
6. Schreiben Sie für jedes genutzte Muster die Rücknahme auf und proben Sie sie einmal mit Testdaten.
7. Nur wenn Vorschläge routinemäßig unverändert genehmigt werden, richten Sie das begrenzte Schreibkonto ein, mit Obergrenze pro Stunde, vollständigem Aktionsprotokoll und Pausenschalter.
8. Legen Sie fest, wer die Protokolle liest, wie oft und was einen Stopp auslöst, und setzen Sie einen Termin zur Überprüfung des Zugriffs.

Was dieser Artikel nicht abdeckt

Er beschreibt weder Schnittstelle noch Grenzen oder Berechtigungsmodell eines bestimmten ERP oder CRM, denn diese unterscheiden sich zwischen Produkten und ändern sich zwischen Versionen. Quelle dafür ist die Dokumentation Ihres Anbieters, und ein kurzer technischer Test in einer Testumgebung bestätigt es. Er behauptet keine Ergebnisse aus einem Kundenprojekt und nennt keine Schätzung von Kosten oder Einsparungen. Er kann auch nicht sagen, ob Ihr Anwendungsfall nach der KI-Verordnung hochriskant ist oder eine Datenschutz-Folgenabschätzung braucht. Das sind rechtliche Beurteilungen für Ihren Datenschutzbeauftragten oder Anwalt. Er bietet einen Weg, den Zugriff eines Agenten klein, sichtbar und umkehrbar zu halten, während Sie herausfinden, ob er mehr verdient.