Integration von KI mit ERP und Unternehmenssystemen

Finanzcontroller verbringen täglich zwei Stunden damit, Daten aus Rechnungen manuell in das ERP-System einzugeben. Die Vertriebsabteilung wartet 24 Stunden auf eine Antwort aus der Logistik, weil die Anfrage zur Verfügbarkeit die Durchsuchung von drei Systemen erfordert. Der Helpdesk löst dieselben Konfigurationsprobleme, weil das Wissen im Kopf eines Seniors steckt, nicht im System. Das sind keine Technologieprobleme. Es sind Probleme inkonsistenter Integration zwischen den Systemen, die Sie bereits haben. KI ersetzt weder ERP noch CRM — sie wird an diese angeschlossen und füllt Lücken, die bisher manuelle Eingriffe auf jedem Schritt erforderten.

Die erste Sorge, die uns in Gesprächen mit Kunden begegnet: „Müssen wir das ERP umbauen?“ Nein. Das KI-Modell fungiert als Zwischenschicht — es liest Daten aus dem System über die API, verarbeitet sie und schreibt das Ergebnis zurück. SAP, Microsoft Dynamics, Comarch ERP, Optima, Symfonia — jedes dieser Systeme verfügt über eine API oder zumindest einen Datenexport, der die Integration ermöglicht, ohne die Grundkonfiguration zu berühren.

Praktische Unterschiede zwischen den Ansätzen:

Für die überwiegende Mehrheit der Unternehmen ist die erste Zeile der Einstiegspunkt. Ein Pilotprojekt erfordert weder eine Vertragsänderung mit dem ERP-Anbieter noch die Einstellung von Entwicklern, die sich mit den internen Systemdetails auskennen.

Ein guter Kandidat für die KI-Integration weist drei Merkmale auf: hohe Wiederholungsrate, strukturierte Eingabedaten und messbare manuelle Bearbeitungszeit. Fünf Prozesse, die wir in Projekten am häufigsten antreffen:

Buchung und Rechnungsbearbeitung. OCR extrahiert Felder aus dem PDF-Dokument (Steuernummer, Betrag, Datum, Positionen), das Modell ordnet sie gemäß dem Kontenplan den Buchungskonten zu und speichert sie im ERP als Buchungsvorschlag zur Freigabe. Fehlerhafte Rechnungen werden mit einer Beschreibung der Abweichungen in eine Ausnahmewarteschlange geleitet.

Klassifizierung und Routing von Aufträgen. Ein neuer Auftrag aus dem E-Commerce oder EDI gelangt zum Agenten, der die Verfügbarkeit prüft, die Zahlungsbedingungen des Kunden verifiziert und den Auftrag dem richtigen Erfüllungspfad zuweist. Ausnahmen (fehlende Ware, überschrittener Kredit) werden automatisch mit vollem Kontext eskaliert.

Triage von Serviceanfragen. Ein Ticket aus dem Helpdesk beschreibt das Problem; das Modell kategorisiert es, weist eine Priorität zu und schlägt eine Antwort basierend auf einer Datenbank gelöster Fälle vor (RAG über die Ticket-Historie). Der Berater bestätigt oder korrigiert — er beginnt nicht bei Null.

Berichterstattung und Datennarrative. Daten aus dem ERP (Verkauf, Lagerbestand, Forderungen) werden an das Modell gesendet, das eine Narrative über Abweichungen vom Plan erstellt. Statt eines Zahlenrasters erhält der Manager einen Satz: „Die Marge in Kategorie X ist im Vergleich zum Vormonat um 4 Prozentpunkte gesunken, hauptsächlich aufgrund gestiegener Lieferkosten.“

Vervollständigung von Stammdaten. Ein neuer Geschäftspartner im System hat einen unvollständigen Datensatz — es fehlen der PKD-Code, die Rechtsform, Kontaktdaten. Das Modell verifiziert die Daten aus verfügbaren Quellen und präsentiert den Ergänzungsvorschlag zur Freigabe durch einen Operator.

Jede Integration von KI mit einem Betriebssystem sollte vier Schichten umfassen. Das Fehlen einer davon zeigt sich meist nach einigen Wochen im Produktivbetrieb als Sicherheitsvorfall oder als Fehler, der schwer zu erklären ist.

Datenextraktionsschicht. Das Quellsystem (ERP, CRM) exportiert Daten über eine API oder einen zyklischen Export. In dieser Phase wird PII maskiert oder pseudonymisiert. Personenbezogene Daten von Kunden, PESEL-Nummern, Finanzdaten natürlicher Personen — diese werden herausgeschnitten oder pseudonymisiert, bevor sie weitergegeben werden. Das Modell in der Cloud sieht niemals identifizierende Daten natürlicher Personen. Mehr zu diesem Muster im Artikel über Anonymisierung von PII vor KI.

Modellaufrufschicht. Der Prompt wird aus einer Vorlage und maskierten Daten erstellt. Der Aufruf erfolgt über einen LLM-Router, der das Modell nach Aufgabe und Kosten auswählt, jeden Aufruf protokolliert und Tagesbudgets überwacht. Strukturierte Ausgabe mit erzwungenem JSON-Schema eliminiert die Hälfte der Parsing-Fehler — statt Text gibt das Modell ein Objekt mit definierten Feldern zurück.

Validierungs- und Guardrails-Schicht. Die Antwort des Modells wird vor dem Speichern validiert: Wir prüfen die Schema-Konformität, Wertebereiche (ob der Rechnungsbetrag im vernünftigen Rahmen liegt) und Guardrails blockieren Operationen außerhalb des definierten Bereichs. Statt stillschweigend eine Anomalie zu speichern, leitet das System sie mit einer Erklärung in eine Ausnahmewarteschlange.

Aktions- und Human-Gate-Schicht. Umkehrbare Aktionen (Buchungsvorschlag, Auftragsklassifizierung) werden als Entwürfe zur Freigabe gespeichert. Nicht umkehrbare Aktionen (Versand des Auftrags an den Lieferanten, Änderung des Rechnungsstatus auf „bezahlt“) warten auf die Bestätigung durch einen Menschen. Das ist keine Frage des Vertrauens in das Modell — es ist die Regel, dass eine nicht umkehrbare Aktion mit einem Fehler um ein Vielfaches mehr kostet als eine Sekunde menschlicher Bestätigung. Das Schema Human-Gate wird ausführlicher im Artikel über die Rolle des Menschen im Loop beschrieben.

ERP und CRM enthalten Daten, deren Leckage rechtlich und reputativ kostspielig ist. Einige Prinzipien, die wir in jedem Projekt umsetzen:

Sensible Daten (personenbezogene Kundendaten, Finanzdaten natürlicher Personen, Personaldaten) gelangen niemals in identifizierender Form in ein Cloud-Modell. Wenn die Anforderungen der RODO oder die Sicherheitsrichtlinien des Unternehmens dies erfordern, läuft der gesamte Stack — Embeddings und Modell — lokal auf der Infrastruktur des Kunden (Self-Hosting). Die Latenz steigt, aber die Daten verlassen das Netzwerk nicht.

Für die Integration mit Hochrisikosystemen (Personaldaten, medizinische Daten, Finanz-Scoring) ist vor dem Produktivstart eine DPIA erforderlich. Der AI Act stellt zusätzliche Anforderungen an Systeme, die natürliche Personen bewerten — Klassifikatoren für ICP, die mit personenbezogenen Daten arbeiten, fallen in die Hochrisikokategorie mit der Pflicht zur Dokumentation und Erklärbarkeit von Entscheidungen. Mehr dazu im Artikel AI Act und DSGVO 2026 — Pflichten für Unternehmen.

Jeder Modellaufruf wird mit einer Operations-ID, einem Zeitstempel und dem Ergebnis protokolliert — ohne personenbezogene Daten. Dieses Log ist keine überflüssige Bürokratie: Es ist der für Audits erforderliche Prüfpfad und die Grundlage für die Qualitätsmessung.

Ein Pilotprojekt zur Integration von KI mit ERP ist ein Projekt mit festem Umfang, das mit einem messbaren Ergebnis endet — nicht mit einer offenen KI-Lizenz. Typischer Ablauf:

Der erste Schritt ist ein Prozess-Audit: Wie viel Zeit nimmt der Prozess heute in Anspruch, welche Eingabe- und Ausgabedaten gibt es, wo treten Ausnahmen auf und wie werden sie behandelt. Ohne diese Messung können Sie nicht bestätigen, dass KI einen Return liefert. Bewerten Sie die Bereitschaft Ihres Prozesses mit dem Bewertungstool.

Der zweite Schritt ist die technische Integration: Anschluss an die API des Quellsystems oder Konfiguration des Exports, Aufbau einer Datenpipeline mit PII-Maskierung, Konfiguration des Routers und der Guardrails, Implementierung im Shadow-Modus (das Modell arbeitet parallel zum Menschen, Ergebnisse werden verglichen, aber nicht automatisch gespeichert).

Der dritte Schritt ist die Kalibrierung: Über 2–4 Wochen sammeln Sie Ergebnisse im Shadow-Modus, messen die Genauigkeit (wie viele Vorschläge des Modells werden von den Operatoren ohne Korrekturen bestätigt), identifizieren Ausnahmekategorien und passen die Guardrails an. Erst nach Erreichen eines festgelegten Genauigkeitsschwellenwerts (meist 85–95 %, abhängig vom Prozess) wechseln Sie zur automatischen Speicherung von Vorschlägen mit menschlicher Stichprobenkontrolle.

Die zeitlichen und finanziellen Rahmenbedingungen hängen vom Umfang und der Komplexität der API des Quellsystems ab. Berechnen Sie die Varianten für Ihren Prozess mit dem ROI-Rechner.

Fehlender Try-Modus vor der Produktion. Die Aktivierung der automatischen Speicherung im ERP ohne Shadow-Phase bedeutet, dass die ersten Fehler des Modells direkt ins System gelangen. Einige Wochen Shadow-Modus und das Sammeln von Daten über Ausnahmen sind günstiger als zwei Stunden manuelles Bereinigen von Anomalien in der Datenbank.

Auslassen der Schema-Validierung bei der Ausgabe. Das Modell gibt in 98 % der Fälle gültiges JSON zurück. Diese 2 % gelangen als null, leerer String oder veralteter Wert ins System — stillschweigend. Erzwungenes JSON-Schema und Validierung vor dem Speichern verwandeln diese 2 % in eine sichtbare Ausnahme im Dashboard, nicht in einen versteckten Fehler in den Daten.

Integration ohne Qualitätsmonitoring. Die Genauigkeit des Modells nimmt mit der Zeit ab: Die Daten im ERP ändern sich, Dokumenttypen entwickeln sich weiter, neue Ausnahmen treten auf. Ohne Messung der Genauigkeit (wie viele Vorschläge werden von den Operatoren ohne Änderungen bestätigt, wie viele landen in Ausnahmen) wissen Sie nicht, wann das Modell eine Neukalibrierung benötigt.

Ein Modellaufruf pro Datensatz. Bei der Verarbeitung von Hunderten Rechnungen pro Tag können die Token-Kosten überraschen. Optimierung der Token-Kosten durch Prompt-Caching, Batching und Routing auf ein günstigeres Modell für einfache Aufgaben kann die Betriebskosten um 40–70 % senken.

Beschreiben Sie den Prozess, den Sie automatisieren möchten, und die Quelldaten — das Modell zeigt, wie die Integrationspipeline, die PII-Maskierung und das Guardrail-Schema entworfen werden. Dies ist der Ausgangspunkt, kein fertiges Projekt (Playground: PII maskiert, keine Speicherung):

In der überwiegenden Mehrheit der Fälle ja. Die Integration basiert auf der API des Systems (REST, SOAP, EDI) oder dem Datenexport (CSV, XML). Sie benötigen keinen Zugang zum Quellcode oder eine Konfigurationsänderung beim Anbieter. Die meisten polnischen ERP-Systeme (Comarch, Symfonia, Sage, Microsoft Dynamics) verfügen über eine dokumentierte API oder zumindest die Möglichkeit des Exports, die für ein Pilotprojekt ausreicht.

Das Hauptrisiko besteht in einer fehlerhaften automatischen Speicherung, die schwer rückgängig zu machen ist. Daher gilt das Prinzip: Das Modell schlägt vor, der Mensch bestätigt für nicht umkehrbare Aktionen. In den ersten Wochen arbeitet das Modell im Shadow-Modus — die Ergebnisse werden mit manuellen Entscheidungen verglichen, aber nicht automatisch gespeichert. Erst nach Messung der Genauigkeit (meist über 90 % der Vorschläge werden ohne Änderungen bestätigt) wird zur automatischen Speicherung mit Stichprobenkontrolle übergegangen.

Das hängt von der Art der Daten ab. Nicht-personenbezogene Daten (Produktcodes, aggregierte Beträge, Auftragskategorien) unterliegen keinen DSGVO-Beschränkungen. Personenbezogene Daten (Steuernummer einer natürlichen Person, Kontaktdaten von Privatkunden, Personaldaten) erfordern entweder eine Maskierung vor dem Versand oder ein lokales Modell. Im Audit klassifizieren wir die Prozessdaten und wählen die passende Architektur — Cloud mit Maskierung oder vollständig lokal.

Ein Pilotprojekt für einen einzelnen Prozess (z. B. Rechnungsbuchung) dauert in der Regel 3 bis 8 Wochen vom Festlegen des Umfangs bis zum messbaren Ergebnis. Die größte Variable ist die Verfügbarkeit der API des Quellsystems und die Qualität der Eingabedaten. Wenn Rechnungen als Scans niedriger Qualität ohne Textschicht eingehen, erfordert die OCR-Kalibrierung zusätzlichen Aufwand, was das Projekt verlängert. Ein detaillierter Zeitplan und die Kosten hängen vom Umfang ab — kontaktieren Sie uns, um mit konkreten Zahlen zu beginnen.

Nein, im wörtlichen Sinne nicht. KI eliminiert repetitive mechanische Tätigkeiten (manuelle Dateneingabe, Suche nach Daten in mehreren Systemen, Erstellen von Berichten aus Daten), nicht Entscheidungen, die geschäftlichen Kontext erfordern. Mitarbeiter, die heute Rechnungen eingeben, können sich stattdessen mit der Überprüfung von Ausnahmen, der Analyse von Abweichungen und der Verbesserung der Datenqualität beschäftigen — was einen höheren Wert schafft und weniger monoton ist. Der häufigste Effekt eines Pilotprojekts ist nicht der Abbau von Arbeitsplätzen, sondern die Umverteilung von Zeit auf höherwertige Tätigkeiten.