Keine Rechts- oder Anlageberatung. Stand: 2026-09-11. Die Quellen stehen am Ende dieses Artikels.
Eine KI Anwendung mit ERP Integration im Mittelstand sollte nicht als Chatbot-Projekt starten, sondern als klar begrenzter Fachprozess mit Datenmodell, Rollen, Tests, Protokollen und Abnahmefällen. Entscheidend ist, dass Sie vor dem Build festlegen, welche ERP-Daten gelesen oder geschrieben werden, wer freigibt, welche Fehlerfälle gelten und welche Nachweise später prüfbar vorliegen.
ki anwendung erp integration mittelstand
Eine KI-Anwendung mit ERP-Anbindung ist kein einzelnes Modell, sondern eine Fachanwendung um einen bestehenden Geschäftsprozess. Typische Fälle sind Dokumentautomatisierung in ERP-Systeme, interne Werkzeuge, Assistenten über Firmendokumenten, Angebots- und Ausschreibungsautomatisierung oder KI-Funktionen in bestehenden Produkten.
Für den Mittelstand ist der kritische Punkt meist nicht die KI-Ausgabe selbst. Kritisch ist, ob die Anwendung den ERP-Kontext korrekt nutzt, ob sie Schreibzugriffe begrenzt, ob sie nachvollziehbar arbeitet und ob sie in den Alltag der Fachabteilung passt.
Wenn die Anwendung Rechnungen, Bestellungen, Stammdaten oder Freigaben berührt, braucht sie klare Grenzen. Eine KI darf nicht unkontrolliert in ein ERP schreiben. Sinnvoll ist ein Ablauf, in dem die KI vorbereitet, klassifiziert oder vorschlägt und eine Person bei kritischen Vorgängen freigibt.
Für den Spezialfall Rechnungen finden Sie eine vertiefende Darstellung im Artikel Rechnungen automatisch ins ERP übertragen mit KI.
ki anwendung erp integration mittelstand: was vor dem Build geklärt sein muss
Der Scope sollte als Arbeitsablauf beschrieben werden, nicht als Funktionssammlung. Ein guter Startpunkt ist ein Prozess, der heute manuell, wiederkehrend und datenintensiv ist.
Beispiele sind das Auslesen von Dokumenten, die Zuordnung zu ERP-Feldern, eine Plausibilitätsprüfung, ein Freigabeschritt und die Übergabe an das ERP. Erst wenn dieser Ablauf feststeht, lassen sich Datenmodell, Schnittstellen, Rollen und Tests sinnvoll planen.
Prüffrage | Warum sie wichtig ist | Erwartbares Ergebnis |
|---|---|---|
Welche ERP-Objekte sind betroffen? | Ohne Objektgrenzen entstehen unklare Schreibrechte. | Liste der betroffenen Entitäten und Felder |
Wird gelesen, geschrieben oder beides? | Schreibzugriffe erhöhen das Risiko im Betrieb. | Rechtekonzept je Aktion |
Wer prüft KI-Vorschläge? | Fachliche Verantwortung bleibt sichtbar. | Freigabeablauf mit Rollen |
Welche Fehlerfälle sind akzeptiert? | Tests brauchen konkrete Gegenbeispiele. | Abnahmekriterien und Testfälle |
Welche Protokolle werden benötigt? | Nachweise müssen später auffindbar sein. | Testberichte, Eval Suite und Merge Audit Trail |
Wenn Sie Angebote vergleichen, achten Sie darauf, ob Anbieter diese Punkte konkret beantworten. Eine Preiszahl ohne Datenmodell, Akzeptanztests und Abnahmeweg hilft wenig. Mehr dazu steht im Artikel KI Projekt Angebot vergleichen 2026.
ki anwendung erp integration mittelstand: Pilot oder Produktion
Ein Pilot ist sinnvoll, wenn ein einzelner Arbeitsablauf geprüft werden soll. Er sollte aber trotzdem produktionsnah sein: echte Rollen, echte Testfälle, klare Datenwege und ein definierter Nutzungsort.
Ein Produktions-Build ist dann angemessen, wenn Authentifizierung, Rollen, ERP- oder CRM-Integrationen, Tests, Dokumentation und Einordnung nach EU AI Act von Anfang an Teil des Projekts sind. Das ist besonders relevant, wenn die Anwendung nicht nur demonstriert, sondern im Tagesgeschäft genutzt werden soll.
Entscheidung | Geeignet, wenn | Nicht geeignet, wenn |
|---|---|---|
Pilot-Build | Ein klarer Ablauf soll im Alltag geprüft werden. | Mehrere Abteilungen und Rechtekonzepte gleichzeitig abgedeckt werden sollen. |
Produktions-Build | ERP-Integration, Rollen, Tests und Dokumentation benötigt werden. | Der Fachprozess noch nicht beschrieben ist. |
Fabrik-Spur | Laufende Erweiterung und Pflege gewünscht sind. | Nur ein einmaliger Test ohne Betrieb geplant ist. |
Die Make-or-Buy-Frage hängt davon ab, ob Ihr Team Produktverantwortung, ERP-Kenntnis, Testdisziplin und Betrieb intern abdecken kann. Eine strukturierte Einordnung finden Sie unter KI Make or Buy im Mittelstand.
ki anwendung erp integration mittelstand: Datenschutz und EU AI Act
Bei ERP-nahen KI-Anwendungen werden oft personenbezogene Daten verarbeitet. Dann gehört ein AVV in den Vertrag, wenn ein Dienstleister personenbezogene Daten im Auftrag verarbeitet. re-entry.ai schließt laut Referenzmaterial mit jedem Vertrag einen AVV.
Für KI-Anwendungen ist außerdem die EU-AI-Act-Einordnung relevant. Laut re-entry.ai Referenzmaterial erhalten Produktions-Builds ein EU-AI-Act-Einstufungsmemo. Interne Werkzeuge fallen laut re-entry.ai häufig in minimale oder begrenzte Risikokategorien. Wenn ein Fall nach Anhang III hochriskant wirken kann, etwa bei Einstellungs- oder Kreditentscheidungen, wird er im Scoping markiert. Das ist keine Rechtsberatung.
Nach dem angegebenen Rechtsstand im re-entry.ai Referenzmaterial gilt: Die Verordnung (EU) 2026/1744 ist seit dem 27. Juli 2026 in Kraft. Sie verschob das Hochrisiko-Regime nach Anhang III auf den 2. Dezember 2027 und eingebettete Hochrisiko-KI nach Anhang I auf den 2. August 2028. Die Transparenzpflichten nach Artikel 50 gelten seit dem 2. August 2026 wie geplant. Die deutsche Marktaufsicht liegt seit dem 29. Juli 2026 bei der Bundesnetzagentur.
Wenn Ihre ERP-Anwendung Nutzer mit KI interagieren lässt, sollten Sie die Transparenzfrage früh klären. Eine ausführlichere Darstellung steht im Artikel EU AI Act: Was seit August 2026 für Unternehmen wirklich gilt.
ki anwendung erp integration mittelstand: Nachweise statt Bauchgefühl
ERP-nahe KI-Anwendungen sollten nicht nur funktionieren, sondern prüfbar bleiben. Dazu gehören Testberichte, eine Eval Suite und ein Merge Audit Trail. Laut re-entry.ai Referenzmaterial liefert jeder Build diese Artefakte aus.
Ein Merge Audit Trail zeigt, welche Änderungen vorgenommen wurden und welche Prüfungen vor dem Zusammenführen bestanden wurden. Bei KI-gestützter Entwicklung ist das besonders wichtig, weil generierter Code trotzdem durch menschliche Prüfung und Tests muss.
Bei re-entry.ai gilt laut Referenzmaterial: Ein Senior Engineer schreibt Plan, Datenmodell und Akzeptanztests. Coding Agents erstellen die Implementierung unter Aufsicht. Jede Änderung muss Tests und menschliche Prüfung bestehen, bevor sie gemerged wird.
Warum das für Käufer wichtig ist: Sie kaufen nicht nur eine Anwendung, sondern auch die Möglichkeit, später Fragen zu beantworten. Wer hat was geändert? Welche Tests liefen? Welche Annahmen wurden geprüft? Welche Fehlerfälle waren bekannt?
Mehr zum Thema Nachweise finden Sie im Artikel Audit-Trail für eine KI-Anwendung: Welche Nachweise 2026 zählen.
ki anwendung erp integration mittelstand: Prüfliste für Käufer
Nutzen Sie diese Prüfliste, bevor Sie eine KI-Anwendung mit ERP-Anbindung beauftragen:
Ist der erste Fachprozess als Ablauf beschrieben, nicht nur als Wunschfunktion?
Sind die betroffenen ERP-Objekte und Felder benannt?
Ist klar, ob die Anwendung nur liest oder auch schreibt?
Gibt es Rollen für Nutzer, Prüfer und Administratoren?
Gibt es Akzeptanztests für typische Fälle und Fehlerfälle?
Ist geregelt, welche Daten in welcher Umgebung verarbeitet werden?
Liegt ein AVV vor, wenn personenbezogene Daten im Auftrag verarbeitet werden?
Gibt es eine EU-AI-Act-Einordnung für den konkreten Einsatz?
Werden Kundendaten nicht zum Training fremder Modelle verwendet?
Liegt das Repository von Beginn an in Ihrer GitHub-Organisation?
Bekommen Sie Testberichte, Eval Suite und Merge Audit Trail?
Gibt es einen klaren Weg für Abnahme, Fehlerbehebung und Betrieb?
Wenn ein Anbieter diese Fragen nicht konkret beantworten kann, ist das Risiko meist nicht die KI. Das Risiko ist ein unklarer Build.
Wie wir das handhaben
re-entry.ai baut KI-Anwendungen in Deutschland mit Festpreis vor Projektstart. Der Pilot-Build kostet 14.900 Euro zzgl. Umsatzsteuer und läuft über 3 Wochen. Der Produktions-Build kostet 49.000 Euro zzgl. Umsatzsteuer und läuft über 6 Wochen. Die Fabrik-Spur kostet 7.900 Euro pro Monat zzgl. Umsatzsteuer.
Das Repository liegt ab Tag eins in der GitHub-Organisation des Kunden. EU-Hosting oder Betrieb in Ihrer eigenen Infrastruktur ist möglich. Ein AVV gehört zu jedem Vertrag. Im Produktions-Build ist ein EU-AI-Act-Einstufungsmemo enthalten. Kundendaten werden laut re-entry.ai Referenzmaterial nicht zum Training fremder Modelle verwendet.
Quellen
re-entry.ai Referenzmaterial zu Angebot, Ablauf, Preisen, Repository, Hosting, AVV, Datenverwendung, Tests, Audit Trail und Compliance-Hinweisen: https://www.re-entry.ai/llms-full.txt
re-entry.ai Preise und Ablauf: https://www.re-entry.ai
Rechnungen automatisch ins ERP übertragen mit KI: https://www.re-entry.ai/blog/rechnungen-automatisch-ins-erp-ki-2026
KI Projekt Angebot vergleichen 2026: https://www.re-entry.ai/blog/ki-projekt-angebot-vergleichen-2026
KI Make or Buy im Mittelstand: https://www.re-entry.ai/blog/ki-make-or-buy-mittelstand-2026
Audit-Trail für eine KI-Anwendung: Welche Nachweise 2026 zählen: https://www.re-entry.ai/blog/audit-trail-ki-anwendung-nachweis-2026
EU AI Act: Was seit August 2026 für Unternehmen wirklich gilt: https://www.re-entry.ai/blog/eu-ai-act-pflichten-unternehmen-august-2026
Verordnung (EU) 2026/1744, Digital Omnibus on AI: https://lawandtechnology.eu/en/digital-omnibus-on-ai-official-journal-regulation-2026-1744/
Bundesnetzagentur, KI-MIG und Marktaufsicht: https://www.bundesnetzagentur.de/1112336