Ein Kunde ruft an, weil „die KI falsche Daten liefert”. Das ist der Satz, mit dem ein guter Teil der Nachbesserungsanfragen beginnt, die wir bekommen. Fast immer stellt sich nach kurzer Prüfung heraus: Das Modell hat richtig erkannt, richtig klassifiziert, richtig entschieden. Der Fehler saß eine Etage darunter, an der Stelle, an der das Ergebnis in ein anderes System geschrieben werden sollte.
Das ist kein Einzelfall, sondern das häufigste Muster bei Integrationsprojekten überhaupt. Zwischen ERP, CRM, Fachsystemen und der neuen KI-Komponente laufen Übergabepunkte, und genau dort entstehen die Probleme, die am Ende dem Modell angelastet werden.
Das eigentliche Problem sitzt nicht im Modell, sondern dazwischen
Ein Sprachmodell oder eine Erkennungslogik lässt sich heute vergleichsweise zuverlässig bauen und testen. Was sich viel schwerer testen lässt, ist das, was danach passiert: Wie kommt das Ergebnis in ein System, das vor zehn Jahren nicht für automatisierte Eingaben gebaut wurde? Was passiert, wenn zwei Systeme für dasselbe Feld unterschiedliche Formate erwarten? Wer entscheidet, wenn eine Übertragung nicht eindeutig ist?
Diese Fragen haben mit künstlicher Intelligenz im engeren Sinn nichts zu tun. Sie sind Integrationsarbeit, und sie brauchen einen anderen Blick als die Modellauswahl. In einem anonymisierten Projekt aus unserer Arbeit, der Anbindung von ERP und CRM bei einem B2B-Industrieunternehmen mit rund 350 Mitarbeitenden, lag der überwiegende Teil des Aufwands genau hier, nicht in der KI-Komponente selbst.
Erstens: Ein Übergabepunkt ist mehr als eine Datenleitung
Der erste Fehler entsteht oft schon vor dem ersten Code: Wer eine Integration plant, zählt die Systeme, nicht die Übergabepunkte. Ein ERP, ein CRM und ein Dokumentenarchiv klingen nach drei Anbindungen. In Wirklichkeit tauschen sie an mehreren Stellen unterschiedliche Datenobjekte aus, mit jeweils eigenem Format, eigener Häufigkeit und eigenem Fehlerbild.
In dem genannten Projekt haben wir deshalb zuerst alle Übergabepunkte aufgenommen und danach sortiert, wie oft sie vorkommen und wie teuer ein Fehler an dieser Stelle wird. Angebunden wurde zuerst, was den größten Anteil trägt, nicht alles gleichzeitig. Diese Reihenfolge klingt banal, wird aber regelmäßig übersprungen, weil sie vor dem eigentlichen Bau Zeit kostet, die im Angebot sichtbar wird.
Zweitens: Validierung vor dem Schreiben, nicht danach
Der zweite Fehler ist folgenreicher: Ein Agent, der Daten schnell und zuverlässig von einem System ins andere trägt, ist nur dann ein Fortschritt, wenn die Daten vorher geprüft werden. Ohne Validierung vor dem Schreiben wird aus einem langsamen, manuellen Fehler ein schnelles, automatisiertes Problem, und das Problem betrifft dann jeden Fall, nicht nur den einen, der übersehen wurde.
Praktisch bedeutet das: jedes Datenobjekt bekommt Regeln, gegen die es vor der Übertragung geprüft wird, nicht erst im Zielsystem. Format, Pflichtfelder, Plausibilität, Referenzen auf existierende Datensätze. Wo REST-API, MCP, EDI oder eine einfache CSV-Schnittstelle im Spiel sind, unterscheidet sich die Technik, die Regel bleibt gleich: Geschrieben wird erst, wenn die Prüfung besteht.
Drittens: Die Klärliste statt der stillen Ausnahme
Der dritte Punkt entscheidet über Vertrauen, nicht nur über Fehlerquote. Es gibt drei Wege, mit einem nicht eindeutigen Fall umzugehen: ihn stillschweigend durchlaufen lassen, ihn automatisch ablehnen, oder ihn sichtbar in eine Klärliste stellen. Nur der dritte Weg funktioniert im Betrieb.
Ein stillschweigend falsch übertragener Datensatz fällt oft erst Wochen später auf, wenn ohnehin niemand mehr nachvollziehen kann, woher der Fehler kam. Eine sichtbare Klärliste dagegen macht genau die Fälle greifbar, die eine Person kurz ansehen muss, und lässt alles andere ungestört laufen. In dem Industrieprojekt ist über diesen Weg die Datenqualität um 90 Prozent gestiegen und die Zahl der manuellen Korrekturtickets um 65 Prozent gesunken, bei einer um 70 Prozent kürzeren Durchlaufzeit. Diese Zahlen stammen aus einem einzelnen, anonymisierten Projekt und lassen sich nicht auf jede Systemlandschaft übertragen, sie zeigen aber die Größenordnung, die in einer sauberen Ausnahmebehandlung steckt.
Viertens: Nicht alles auf einmal umschalten
Der letzte Punkt betrifft den Übergang selbst. Auch bei einer technisch sauberen Integration ist es ein Fehler, alle manuellen Strecken an einem Tag abzuschalten. Im genannten Projekt liefen alte und neue Strecke parallel, und die manuelle Übertragung wurde je Übergabepunkt erst abgeschaltet, nachdem er zwei Wochen ohne Abweichung durchgelaufen war, und zwar einzeln statt gesamthaft. Das kostet Zeit im Projektplan, aber es ist die einzige Phase, in der ein übersehener Fehler noch nichts kostet, weil die alte Strecke daneben weiterläuft.
Was Sie vor der nächsten Integration klären sollten
Fragen Sie bei der Planung nicht „welche Systeme werden angebunden”, sondern „an welchen Stellen tauschen sie Daten aus, und was passiert dort, wenn etwas nicht eindeutig ist”. Verlangen Sie eine Antwort auf drei Punkte, bevor der erste Übergabepunkt gebaut wird: welche Prüfregeln vor dem Schreiben gelten, wohin ein nicht eindeutiger Fall geht, und wie lange alte und neue Strecke parallel laufen, bevor umgeschaltet wird. Ein Anbieter, der diese drei Fragen sofort beantworten kann, hat die Integration schon einmal durchdacht. Wer nur über das Modell spricht, hat die eigentliche Arbeit noch vor sich.
Wie wir Integrationen dieser Art aufsetzen, mit Anbindung über REST-API, MCP, EDI oder CSV und Protokoll je Übertrag, steht unter KI-Software & individuelle Lösungen. Geht es vor allem um wiederkehrende Prozesse zwischen bestehenden Systemen, ist Intelligente Prozessautomatisierung der passendere Einstieg.