Die kurze Antwort: Unternehmen sollten für jeden ERP-Prozess getrennt festlegen, welche Daten ein KI-Agent lesen darf, wo er Entwürfe anlegen kann und wer verbindliche Änderungen oder Bestellungen freigibt. Die Rechte und Kontrollen müssen an den tatsächlichen Schnittstellen und im Zielsystem durchgesetzt werden. Welche Folgen ein Entwurf bereits auslöst, hängt vom jeweiligen ERP und seiner Konfiguration ab.
Ein guter Einstieg ist ein begrenzter Pilot: Der Agent bereitet einen Bestellvorschlag vor, eine zuständige Person prüft ihn, und der freigegebene Vorgang wird über einen dafür vorgesehenen Prozess weiterbearbeitet. Das Beispiel in diesem Artikel ist fiktiv und zeigt eine mögliche Gestaltung.
Was kann ein KI-Agent im ERP übernehmen?
Ein ERP-System verbindet Geschäftsbereiche wie Einkauf, Lager, Vertrieb und Buchhaltung. Ein entsprechend angebundener KI-Agent kann Informationen aus diesen Bereichen für einen definierten Auftrag nutzen. Abhängig von Datenqualität, Schnittstellen und erteilten Rechten kann er beispielsweise:
- einen freigegebenen Lagerbestand oder Bedarf abrufen;
- Produkt- und Lieferantendaten für einen Vorgang zusammenstellen;
- auf fehlende Angaben oder widersprüchliche Daten hinweisen;
- einen Bestellvorschlag vorbereiten;
- den Vorschlag einer zuständigen Person zur Entscheidung vorlegen;
- einen freigegebenen Vorgang über eine dafür eingerichtete Schnittstelle weitergeben.
Die Bandbreite möglicher ERP-Anwendungen reicht von der Beschaffung bis zur Buchhaltung. Der Bitkom-Leitfaden zu Multi-Agenten-Systemen im ERP-Kontext empfiehlt unter anderem, klar abgegrenzte Prozesse mit wiederkehrenden Abläufen zu priorisieren. Welche Systeme und Aktionen tatsächlich angebunden werden, ist im jeweiligen Projekt zu klären.
KI im ERP: Welche Aufgaben lassen sich intelligent automatisieren?
Mit künstlicher Intelligenz können Unternehmen wiederkehrende Aufgaben in ihren Geschäftsprozessen unterstützen. Ein KI-Agent kann etwa Hinweise zu fehlenden Lieferantenangaben sammeln oder einen Bestellbedarf anhand freigegebener Daten einordnen. Ein Sprachmodell (LLM) verarbeitet dabei Informationen und erstellt beispielsweise einen Textentwurf. Welche Daten es erhält und welche Tools es nutzen darf, muss die Anwendung technisch begrenzen.
Für die Automatisierung empfiehlt sich ein schrittweiser Einstieg: Zunächst werden Vorschläge geprüft und manuell weiterbearbeitet. Erst wenn Datenqualität, Zuständigkeiten und Kontrollen im Pilotprojekt verlässlich funktionieren, können Unternehmen entscheiden, ob einzelne Schritte autonom ablaufen sollen. Eine verbindliche Transaktion braucht dafür eine ausdrücklich erteilte Berechtigung und die im Prozess vorgesehene Genehmigung.
Auch mehrere spezialisierte AI Agents können Aufgaben koordinieren: Ein Agent bereitet den Bedarf vor, ein weiterer ergänzt freigegebene Lieferantendaten. Die Übergabe braucht dieselbe Kontrolle wie der ursprüngliche Zugriff. Ein gemeinsamer Workflow gibt keinem Beteiligten automatisch das Recht, sämtliche Daten zu lesen oder im Zielsystem zu schreiben.
Lesen, Entwurf, Freigabe und Ausführung: Was ist der Unterschied?
Diese Schritte wirken im Alltag eng verbunden, haben aber unterschiedliche Folgen:
| Schritt | Beispiel | Was Unternehmen prüfen sollten |
|---|---|---|
| Lesen | Bestand und freigegebene Lieferantendaten abrufen | Welche Daten darf der Agent für diesen Auftrag sehen? |
| Entwurf vorbereiten | Artikel, Menge und Lieferant als Vorschlag zusammenstellen | Wo wird der Vorschlag gespeichert, und welche Abläufe startet das bereits? |
| Freigabe einholen | Eine berechtigte Person prüft den konkreten Vorschlag | Wer darf entscheiden, und auf welche Fassung bezieht sich die Freigabe? |
| Änderung ausführen | Den freigegebenen Vorgang im ERP weiterverarbeiten | Welche Aktion wird ausgelöst, und prüft der tatsächliche Ausführungspfad die Berechtigung? |
| Extern kommunizieren | Eine Bestellung an den Lieferanten übermitteln | Wer darf senden, an welchen Empfänger und mit welchen Daten? |
Eine als lesend vorgesehene Funktion soll die abgefragten fachlichen ERP-Daten nicht verändern. Je nach Schnittstelle und Konfiguration können dennoch technische Protokolle oder andere Nebenwirkungen entstehen. Außerdem können beim Abrufen und Weitergeben vertrauliche Informationen offengelegt werden. Prüfen Sie deshalb die tatsächlichen Rechte und Auswirkungen des konkreten Zugriffs.
Umgekehrt ist ein Entwurf nicht automatisch folgenlos. Ein ERP oder eine angebundene Anwendung kann bereits beim Anlegen eines Datensatzes Benachrichtigungen, Folgeprozesse oder Auswertungen auslösen. Ob das geschieht, muss für den konkreten Status, die Schnittstelle und die Konfiguration geprüft werden.
Praxisbeispiel: Ein KI-Agent bereitet eine Nachbestellung vor
Ein fiktives mittelständisches Unternehmen möchte einen wiederkehrenden Beschaffungsprozess unterstützen. Für einen bestimmten Artikel soll bei niedrigem Bestand ein Vorschlag entstehen. Lieferant, Preis, Menge und Termin müssen vor einer verbindlichen Bestellung geprüft werden.
| Schritt | Möglicher Ablauf | Vorgesehene Kontrolle |
|---|---|---|
| 1. Bedarf erkennen | Der Agent liest den für die Aufgabe freigegebenen Bestand und vorhandene offene Bestellungen | Datenstand, Lagerort und Berechtigung prüfen |
| 2. Vorschlag erstellen | Er schlägt eine Menge und einen zugelassenen Lieferanten vor | Fehlende oder widersprüchliche Angaben kennzeichnen |
| 3. Entwurf ablegen | Der Vorschlag wird in einem vereinbarten Bereich vorbereitet | Prüfen, ob dieser Bereich bereits ERP- oder externe Folgeaktionen auslöst |
| 4. Entscheidung einholen | Eine zuständige Person sieht Artikel, Menge, Lieferant, Preis und Termin | Konkreten Vorschlag prüfen, freigeben, ablehnen oder ändern |
| 5. Bestellung weiterverarbeiten | Der dafür vorgesehene Prozess übernimmt die freigegebene Fassung | Rechte und gültige Freigabe erneut prüfen; Ergebnis dokumentieren |
| 6. Lieferant informieren | Die Bestellung wird über den vorgesehenen Kanal übermittelt | Empfänger, Inhalt und Sendestatus kontrollieren |
Das Unternehmen kann andere Schritte und Zuständigkeiten festlegen. Das Beispiel ist kein dokumentierter Kundenfall, kein durchgeführter Test und keine Behauptung, dass eine bestimmte ERP-Anbindung in AI Cowork bereits vorhanden ist.
Warum sollten offene Bestellungen berücksichtigt werden?
Ein niedriger Lagerbestand allein sagt noch nicht, ob eine weitere Bestellung nötig ist. Bereits ausgelöste Lieferungen, Reservierungen oder abweichende Lagerorte können die Entscheidung beeinflussen. Der Agent sollte deshalb nur auf Grundlage der für den Prozess definierten, aktuellen Daten einen Vorschlag erstellen. Fehlende Informationen gehören als offene Frage in die Prüfung.
Welche Berechtigungen braucht ein KI-Agent im ERP?
Die Antwort richtet sich nach dem tatsächlichen Prozess. Eine mögliche Rechteübersicht für den beschriebenen Einstieg sieht so aus:
| Akteur oder Funktion | Lesen | Entwurf | Freigabe und verbindliche Aktion |
|---|---|---|---|
| KI-Agent für den Vorschlag | Nur benötigte Artikel-, Bestands- und Lieferantendaten | Vorschlag im dafür vorgesehenen Bereich vorbereiten | Keine eigenständige verbindliche Bestellung in diesem Beispiel |
| Einkauf | Für die Prüfung erforderliche Daten | Vorschlag prüfen und bei Bedarf ändern | Entscheidung im Rahmen der zugewiesenen Zuständigkeit |
| Zusätzliche freigebende Rolle | Für die Entscheidung notwendige Informationen | Bei Bedarf Rückfrage oder Ablehnung | Freigabe bei festgelegten Ausnahmen oder Wertgrenzen |
| Ausführender Prozess | Für die Übernahme erforderlicher Status | Abhängig von der Umsetzung | Nur die konkret freigegebene Aktion im vorgesehenen Zielsystem ausführen |
Diese Tabelle ist eine Gestaltungshilfe. Sie beschreibt keine universelle ERP-Vorgabe. Manche Systeme erlauben eine feine Einschränkung auf bestimmte Felder, Lagerorte oder Funktionen; bei anderen ist eine zusätzliche Integrationsschicht nötig. Entscheidend ist, welche Rechte tatsächlich vergeben und an welcher Stelle sie geprüft werden.
Least Privilege bedeutet, einem Akteur nur die für seine Aufgabe erforderlichen Berechtigungen einzuräumen. Dazu gehören neben dem lesbaren Datenbereich auch die erlaubten Aktionen, der Zweck und die beteiligten Systeme. Wer die Rechte verwaltet und entziehen kann, sollte ausdrücklich festgelegt sein.
Für Zugriffe im Auftrag einer angemeldeten Person können – abhängig von der Plattform und Umsetzung – auch deren Rechte relevant sein. Ein automatisch gestarteter Prozess benötigt einen klar definierten technischen Zugriff und eine verantwortliche Stelle. Weitere Grundlagen finden Sie im Artikel KI-Agenten und ihre Identität.
Reicht eine Anweisung im Prompt aus?
Eine Anweisung wie „Erstelle nur Entwürfe“ kann das gewünschte Verhalten beschreiben. Die Berechtigung zur verbindlichen Aktion sollte jedoch unabhängig davon an der ausführenden Schnittstelle oder im Zielsystem geprüft werden.
Das Sicherheitsprojekt OWASP empfiehlt, Funktionen und Rechte zu begrenzen, Anfragen an nachgelagerte Systeme zu prüfen und für folgenreiche Aktionen eine menschliche Freigabe vorzusehen. Das ist eine allgemeine Empfehlung für die Architektur und kein Nachweis einer bestimmten Produktfunktion.
Wo wird der Bestellvorschlag gespeichert?
Für einen Pilotprozess gibt es mehrere Möglichkeiten. Welche davon passt, hängt von den vorhandenen Systemen und ihren Auswirkungen ab.
| Ablageort | Vorteil für die Planung | Vor dem Einsatz zu klären |
|---|---|---|
| Separater Entwurfsbereich | Vorschlag lässt sich vor einer ERP-Änderung prüfen | Zugriff, Aufbewahrung, Übertragung und Löschung des Entwurfs |
| Vorgesehener Entwurfsstatus im ERP | Fachbereich arbeitet näher am gewohnten System | Welche Folgeprozesse, Reservierungen oder Benachrichtigungen der Status auslöst |
| Aufgabe für den Einkauf | Ein Mensch übernimmt die weitere Bearbeitung | Wie Daten, Quelle und aktueller Stand nachvollziehbar übergeben werden |
Ein sichtbares Label „Entwurf“ sagt für sich genommen noch nicht, welche technischen Aktionen im Hintergrund stattfinden. Prüfen Sie gemeinsam mit ERP-Verantwortlichen und Anbieter, was beim Anlegen, Ändern, Freigeben und Übermitteln tatsächlich geschieht.
Beispiel aus der ERP-Dokumentation
Microsoft beschreibt für Dynamics 365 Supply Chain Management: Je nach Konfiguration des Änderungsmanagements und Entstehungsweg kann eine Bestellung bereits bei der Erstellung den Status „Approved“ erhalten oder einen konfigurierten Freigabeprozess durchlaufen. Eine aus einer Planbestellung erzeugte Bestellung erhält laut Microsoft unabhängig von der Einstellung den Status „Approved“. Welche weiteren Schritte folgen, muss im jeweiligen Prozess geprüft werden. Microsoft: Bestellungen genehmigen und bestätigen
Das ist ein herstellerspezifisches Beispiel. Es bedeutet weder, dass jedes ERP so arbeitet, noch dass AI Cowork diesen Dienst automatisch verwendet. Es zeigt, warum die fachliche Bedeutung eines Status im konkreten System geprüft werden muss.
Beispiel SAP: Schnittstelle und Rechte getrennt prüfen
Auch bei SAP hängt die Umsetzung von Produktversion, verfügbaren Schnittstellen und konkreter Konfiguration ab. SAP dokumentiert für eine S/4HANA-On-Premise-Schnittstelle, dass sie Bestellungen anlegen, aktualisieren und löschen kann. Ob ein angebundener Agent diese Aktionen tatsächlich ausführen darf, muss über die jeweilige Zugriffssteuerung und den freigegebenen Prozess begrenzt werden. Eine vorhandene API bedeutet weder automatisch eine geeignete Freigabe noch eine bereits fertige AI-Cowork-Anbindung. SAP: Purchase Order API
Welche Freigabe braucht eine verbindliche ERP-Aktion?
Ein Freigabeprozess sollte die Informationen zeigen, die für die jeweilige Entscheidung relevant sind. Bei einer Nachbestellung können dazu gehören:
- Artikel, Menge, Lagerort und gewünschter Termin;
- Lieferant und vorgesehener Empfänger;
- Preisgrundlage, Betrag und gegebenenfalls Abweichungen von internen Regeln;
- Datenstand, offene Bestellungen und erkennbare Unsicherheiten;
- die konkrete Fassung des Vorschlags und die Aktion, die anschließend erfolgen soll.
Wer freigeben darf, wie Vertretungen geregelt sind und ab wann weitere Personen einbezogen werden, legt das Unternehmen fest. Eine unbeantwortete oder abgelehnte Anfrage sollte in dem geplanten Ablauf keine verbindliche Bestellung auslösen.
Ändern sich entscheidungsrelevante Angaben nach der Freigabe – etwa Lieferant, Menge, Preis oder Empfänger –, sollte der Prozess die alte Freigabe für die neue Fassung nicht mehr verwenden. Für Prüfung und Ausführung sollte dieselbe freigegebene, gegen zwischenzeitliche Änderungen geschützte Fassung herangezogen werden. Wie dies technisch umgesetzt wird, ist im Projekt zu prüfen.
Die fachliche Prüfung einer Bestellung unterscheidet sich von einer Finanzbuchung oder dem Versand an einen Lieferanten. Welche Aktionen zusammenfallen oder getrennt sind, bestimmt das jeweilige ERP und der eingerichtete Workflow. Der Artikel KI-Agenten für Angebote und Freigaben vertieft den vergleichbaren Prüfprozess im Vertrieb.
Was tun bei Fehlern, Zeitüberschreitungen und Doppelbestellungen?
Eine Schnittstelle kann nach einer Anfrage unklar antworten: Wurde die Bestellung angelegt oder ist der Aufruf gescheitert? Ein blindes Wiederholen kann je nach System zu doppelten Vorgängen führen.
Für den Pilot sollten Fachbereich und IT deshalb festlegen:
- Vorgang eindeutig zuordnen: Welcher fachliche Auftrag und welche freigegebene Fassung gehören zusammen?
- Ergebnis prüfen: Wo lässt sich bei unklarer Antwort der tatsächliche Status im Zielsystem feststellen?
- Wiederholung begrenzen: Wann darf erneut gesendet werden, und wann muss eine Person den Fall klären?
- Doppelte Ausführung vermeiden: Unterstützt die Schnittstelle geeignete Verfahren zur Wiedererkennung wiederholter Aufrufe? Wie werden Parallelität und bereits laufende Anfragen behandelt?
- Ausnahme bearbeiten: Wer sieht den Fehler, wie wird der Vorgang gestoppt und wie wird eine notwendige Korrektur dokumentiert?
AWS erläutert das Prinzip der Idempotenz: Ein geeigneter Schlüssel kann einem Dienst helfen, wiederholte Anfragen demselben Vorgang zuzuordnen. AWS: Idempotente Antworten Ob ein konkretes ERP oder eine Schnittstelle dies unterstützt und welche Bedingungen gelten, muss gesondert geprüft werden. Ein Schlüssel allein garantiert keine fehlerfreie Ende-zu-Ende-Verarbeitung.
Datenschutz und vertrauliche ERP-Daten
Im ERP können Namen, Kontaktdaten und Angaben zu einzelnen Vorgängen vorkommen. Daneben enthalten Bestands- und Lieferantendaten oft vertrauliche Informationen wie Einkaufspreise oder Konditionen. Unternehmen sollten den gesamten Datenweg betrachten: ERP-Zugriff, Integrationsschicht, Modellverarbeitung, Entwürfe, Protokolle und gegebenenfalls externe Kommunikation.
Bei AI Cowork werden erkannte personenbezogene Angaben vor der Modellverarbeitung durch Platzhalter ersetzt. Nach der Verarbeitung werden zurückgegebene Platzhalter wieder den Originalangaben zugeordnet. Diese zusätzliche Schutzmaßnahme gilt laut Produktangabe auch bei lokalen KI-Modellen sowie beim Einsatz von Azure oder Amazon Bedrock.
Da eine Rückzuordnung möglich ist, handelt es sich fachlich um Pseudonymisierung. Für Stellen, die Personen mithilfe zusätzlicher Informationen wieder zuordnen können, bleiben diese Daten personenbezogen. Die Erkennung muss für den jeweiligen Einsatz geprüft werden; Kontext und nicht erkannte Angaben müssen ebenfalls betrachtet werden. Der Europäische Datenschutzausschuss erläutert die Abgrenzung zur Anonymisierung.
Für Azure und Amazon Bedrock sieht AI Cowork laut Produktangabe Server in Deutschland vor. Falls diese für den vorgesehenen Einsatz nicht verfügbar sind, wird alternativ ein Standort innerhalb der EU gewählt. Die tatsächlich beteiligten Dienste, Einstellungen und Datenflüsse sind im jeweiligen Projekt zu dokumentieren und zu prüfen.
Pseudonymisierung ersetzt weder ein Rechtekonzept für ERP-Daten noch die Prüfung von Rechtsgrundlage, Verträgen, Aufbewahrung und technischen sowie organisatorischen Maßnahmen. Vertrauliche Geschäftsdaten wie Preise und Lieferkonditionen brauchen ebenfalls passenden Schutz. Mehr dazu: KI-Agenten und personenbezogene Daten.
Abnahmetest: Welche Fälle sollten Unternehmen prüfen?
Die folgende Tabelle enthält Testvorschläge, keine bereits durchgeführten Tests. Dokumentieren Sie für jeden Fall die beteiligten Identitäten, die Konfiguration, das erwartete und das tatsächliche Ergebnis.
| Prüffall | Erwartetes Verhalten im geplanten Prozess |
|---|---|
| Der Agent fragt Daten außerhalb seines Aufgabenbereichs ab | Die Anfrage wird am vorgesehenen Kontrollpunkt abgewiesen; keine unberechtigten Daten gelangen in den Modellkontext |
| Ein ERP-Entwurf wird angelegt | Die vereinbarten Folgen treten ein; unerwarteter Versand oder andere nicht freigegebene Folgeaktionen bleiben aus |
| Eine offene Bestellung existiert bereits | Der Fall wird entsprechend der fachlichen Regel berücksichtigt oder zur Klärung vorgelegt |
| Menge, Preis oder Lieferant ändern sich nach der Freigabe | Die bisherige Freigabe gilt nicht für die geänderte Fassung; erneute Prüfung ist erforderlich |
| Die Freigabe bleibt aus oder wird abgelehnt | Der geplante Prozess führt die verbindliche Aktion nicht aus |
| Die Schnittstelle antwortet nach einer Zeitüberschreitung unklar | Der tatsächliche Status wird geprüft, bevor ein erneuter Versuch erfolgt |
| Zwei Abläufe bearbeiten denselben Bedarf gleichzeitig | Der Prozess erkennt oder behandelt den Konflikt nach der vereinbarten Regel |
| Ein Dokument enthält die Anweisung, die Freigabe zu überspringen | Der Dokumentinhalt erweitert keine Berechtigung; die technische Kontrolle bleibt aktiv |
| Rechte werden während eines laufenden Vorgangs entzogen | Die aktuelle Berechtigung wird am Ausführungspunkt geprüft; Verhalten laufender Sitzungen und möglicher Zwischenspeicher wird gesondert getestet |
Prüfen Sie auch, wer Protokolle einsehen darf und ob darin mehr Daten gespeichert werden als benötigt. Wiederholen Sie die relevanten Tests nach Änderungen an ERP-Version, Rollen, Schnittstellen oder Freigaberegeln.
In vier Schritten zum ERP-Piloten
- Prozess auswählen: Einen wiederkehrenden Vorgang mit klarer fachlicher Verantwortung und überschaubarem Datenbedarf wählen.
- Daten und Aktionen aufnehmen: Quellen, Zugriffswege, Entwurfsorte und mögliche Nebenwirkungen dokumentieren.
- Rechte und Freigaben festlegen: Für jeden Schritt definieren, wer lesen, vorbereiten, entscheiden und ausführen darf.
- Mit Beispieldaten testen: Normale Fälle und Ausnahmen prüfen, Ergebnisse dokumentieren und erst danach über den produktiven Einsatz entscheiden.
Für einen ersten Piloten kann es sinnvoll sein, die verbindliche Aktion zunächst beim Einkauf zu belassen. Wenn der Prozess verlässlich funktioniert und zusätzliche Automatisierung fachlich gewünscht ist, lassen sich weitere Schritte gesondert planen und testen.
Wie messen Unternehmen den Nutzen eines ERP-Piloten?
Vergleichen Sie vor und während des Piloten dieselben Schritte: Wie lange dauert die Vorbereitung eines Vorgangs? Wie viele Vorschläge müssen Mitarbeitende korrigieren, weil Angaben fehlen oder fachlich falsch sind? Wie häufig werden Fälle wegen fehlender Rechte oder unklarer Daten zur Klärung zurückgestellt? Erfassen Sie zusätzlich ungewollte Änderungen und doppelte Ausführungen.
Vereinbaren Sie vorab eine Stichprobe, einen Betrachtungszeitraum und Kriterien für den produktiven Einsatz. Geschwindigkeit allein zeigt noch nicht, ob die KI im Tagesgeschäft zuverlässig arbeitet. Fachbereich und IT sollten die Ergebnisse gemeinsam bewerten und bei Fehlern die Rechte oder den Ablauf anpassen. Diese Governance unterstützt auch die Compliance: Zuständigkeiten, Prüfungen und Änderungen bleiben nachvollziehbar.
Häufige Fragen
Darf ein KI-Agent Daten aus dem ERP lesen?
Das hängt von seinen technischen Berechtigungen, dem Zweck und den Regeln des Unternehmens ab. Auch lesender Zugriff sollte auf die für den Auftrag benötigten Daten begrenzt und datenschutzrechtlich geprüft werden.
Ist das Anlegen eines ERP-Entwurfs bereits eine Änderung?
Ja, wenn dabei ein Datensatz im ERP oder einem anderen System gespeichert wird, entsteht dort eine Änderung. Welche weiteren Folgen sie auslöst, hängt vom Status, den Regeln und den angebundenen Systemen ab.
Darf ein KI-Agent eine Bestellung im ERP auslösen?
Das hängt von den eingerichteten Rechten, dem Prozess und den Unternehmensvorgaben ab. Im hier beschriebenen Pilot wird eine verbindliche Aktion erst nach Prüfung und Freigabe durch eine zuständige Person vorgesehen.
Kann ein KI-Agent das ERP auch ohne direkte Schreibrechte unterstützen?
Ja. Er kann beispielsweise freigegebene Daten lesen und einen Vorschlag in einem separaten Bereich oder als Aufgabe vorbereiten. Ob und wie das möglich ist, hängt von der Anbindung und den vergebenen Rechten ab.
Fazit: ERP-Zugriffe Schritt für Schritt gestalten
Ein KI-Agent kann ERP-Daten nutzen und wiederkehrende Arbeit vorbereiten. Damit Unternehmen den Ablauf kontrollieren können, sollten sie Lesezugriffe, Entwurfsablage, Freigaben und verbindliche Aktionen einzeln betrachten. Ein Pilot mit klaren Zuständigkeiten und überprüften Fehlerfällen schafft dafür eine praktische Grundlage.
Mit AI Cowork lassen sich KI-Agenten und Abläufe auf den jeweiligen Anwendungsfall ausrichten. Welche ERP-Systeme und Schnittstellen angebunden werden und wie Freigaben technisch umgesetzt werden, wird im Projekt geklärt.