Vom KI-Entwurf zum ERP-Eintrag: Wo die Freigabegrenze liegt

Die Freigabegrenze vor einem ERP-Eintrag liegt zwischen einem geprüften Datenentwurf und einer konkret erlaubten Schreibaktion. Eine allgemeine Zustimmung zur KI-Nutzung reicht dafür nicht. Die Freigabe muss auf den tatsächlichen Datensatz, die Zielaktion und eine zuständige Person bezogen sein. Nach dem Schreiben folgt die Kontrolle des gespeicherten Ergebnisses.

Dieser Artikel beschreibt einen eigenen Entwurf für eine kontrollierte Übergabe. Das Beispiel eines Bestellvorschlags ist fiktiv und produktneutral. Es ist keine fertige ERP-Schnittstelle und keine rechtliche Bewertung einer Beauftragung. Die technische Einordnung behandelt der Beitrag zur Dokumentenverarbeitung mit ERP-Integration.

Warum ein korrekter Entwurf noch keine Schreibfreigabe ist

Ein Datensatz kann vollständig und rechnerisch korrekt sein, ohne dass seine Anlage erlaubt ist. Vielleicht fehlt die fachliche Entscheidung über den Bedarf. Vielleicht ist der Lieferant noch nicht freigegeben. Vielleicht wurde der Betrag inzwischen geändert. Datenprüfung und Handlungsbefugnis sind deshalb getrennte Kontrollen.

Die OWASP-Beschreibung von Excessive Agency nennt zu weitreichende Funktionen, Berechtigungen und Autonomie als Risikotreiber bei LLM-Systemen. Sie empfiehlt eine Begrenzung von Handlungsmöglichkeiten und geeignete Freigaben. Diese Leitlinie belegt das Sicherheitsprinzip, nicht die Sicherheit einer konkreten ERP-Implementierung.

Für den eigenen Ablauf folgt daraus: Der Dienst, der Inhalte vorbereitet, braucht nicht automatisch dieselben Rechte wie der Dienst, der Daten schreibt. Die Trennung muss technisch umgesetzt und geprüft werden. Eine Anweisung im Prompt allein verhindert keine Aktion, wenn ein uneingeschränktes Werkzeug verfügbar bleibt.

Die genaue Aktion benennen

"Ins ERP übernehmen" kann unterschiedliche Dinge bedeuten. Ein Entwurf wird angelegt, ein bestehender Datensatz geändert oder ein Vorgang verbindlich gebucht. Diese Aktionen haben verschiedene Folgen. Die Freigabe muss daher den konkreten Aktionstyp nennen.

Im fiktiven Beispiel ist ausschliesslich die Anlage eines internen Bestellvorschlags erlaubt. Es wird keine Bestellung an einen Lieferanten versandt und keine Zahlung ausgelöst. Diese Grenze steht in der technischen Schnittstelle, in der Freigabeansicht und im Prüfbericht. Ein späterer Ausbau verlangt eine neue Entscheidung.

Auch das Zielobjekt muss eindeutig sein. Der Vorschlag gehört zu einem bestimmten Mandanten, Lieferanten und Projekt. Eine korrekt erkannte Lieferantenbezeichnung ist noch keine bestätigte Stammdatenkennung. Die Zuordnung wird vor der Freigabe geprüft und danach nicht still verändert.

Ein fiktiver Datenstand zur Freigabe

Der Vorschlag B-58 enthält zwei Positionen: zwei Geräte zu je 250 Euro und eine Einrichtungsleistung zu 100 Euro. Die Nettosumme beträgt 600 Euro. Das Beispiel enthält keine Steuerberechnung. Lieferant L-18 und Projekt P-204 sind bereits fachlich bestätigte Kennungen innerhalb des Beispiels.

Die freigebende Person sieht die Werte und ihre Quellen. Ein blosses Kästchen "KI-Ergebnis geprüft" ist zu allgemein. Es muss klar sein, ob die Person die fachliche Richtigkeit, den Bedarf oder die technische Anlage bestätigt. Eine Rolle darf nur die Entscheidung treffen, für die sie tatsächlich zuständig ist.

Die Freigabe an eine unveränderte Fassung binden

Nach der Bestätigung werden die freigegebenen Daten als eindeutige Fassung festgehalten. Eine technische Prüfsumme oder ein vergleichbarer Versionsbezug hilft, spätere Änderungen zu erkennen. Sie beweist nicht die fachliche Richtigkeit, sondern die Identität des bestätigten Datenstands.

Ändert sich der Betrag von 600 auf 650 Euro, gilt die alte Freigabe nicht für den neuen Betrag. Dasselbe gilt für eine geänderte Lieferantenkennung oder eine andere Aktion. Der Vorgang muss erneut in die passende Prüfung. Eine allgemeine Freigabe des ursprünglichen Dokuments deckt diese Änderungen nicht automatisch ab.

Die konkrete Technik hängt vom System ab. Wichtig ist die überprüfbare Eigenschaft: Zwischen Freigabe und Schreibaktion darf kein relevanter Wert unbemerkt wechseln. Der Test muss eine solche Änderung gezielt einbauen und zeigen, dass der Schreibvorgang gesperrt bleibt.

Eine überschaubare Zustandsfolge

Für das Beispiel lautet die Folge: vorbereitet, fachlich geprüft, freigegeben, Übertragung läuft, gespeichert und zurückgelesen. Daneben existieren abgelehnt, Freigabe veraltet und Ausgang unklar. Diese Zustände beschreiben unterschiedliche Situationen und dürfen nicht unter "Fehler" zusammenfallen.

"Gespeichert" bedeutet zunächst, dass eine Anlage gemeldet oder erkannt wurde. "Zurückgelesen" bedeutet, dass die benötigten Felder im Zielsystem überprüft wurden. Erst der zweite Zustand erfüllt hier den vorgesehenen Abschluss. Ein Datensatz kann erfolgreich angelegt und trotzdem dem falschen Projekt zugeordnet sein.

Der Beitrag zu Freigaben in KI-Workflows ergänzt die Rollenfrage. Für die ERP-Grenze muss zusätzlich feststehen, welcher technische Dienst den Zustandswechsel ausführen darf und welche Daten er dabei prüft. Der Modelltext darf keine beliebigen Zustandswechsel bestimmen.

Schreibrechte möglichst eng begrenzen

Der ausführende Dienst erhält nur die für die freigegebene Aktion benötigten Rechte. Wenn er interne Vorschläge anlegt, braucht er nicht automatisch Rechte für Löschung, Versand oder Zahlungsfreigabe. Die tatsächlichen Möglichkeiten müssen anhand des verwendeten Kontos und der Schnittstelle geprüft werden.

Eine vorgelagerte Validierung kontrolliert Pflichtfelder, erlaubte Zielobjekte und den Freigabebezug. Ungültige Daten werden vor dem Aufruf abgefangen. Diese Prüfung erfolgt ausserhalb der freien Modellantwort, damit ein anders formulierter Text die Regel nicht umgeht.

Auch das Quellmaterial ist keine Befehlsquelle. Ein PDF mit der Anweisung "sofort buchen" verändert die erlaubte Aktion nicht. Der Beitrag zu Prompt Injection im Arbeitsalltag erklärt diese Trennung zwischen zu verarbeitendem Inhalt und autorisierten Anweisungen.

Doppelte Schreibversuche beherrschen

Ein Verbindungsabbruch kann eintreten, nachdem das Zielsystem den Datensatz bereits gespeichert hat. Ein sofortiger zweiter Aufruf erzeugt dann möglicherweise eine Dublette. Deshalb braucht die Integration eine nachvollziehbare Strategie für wiederholte Anfragen und unklare Ausgänge.

Die Stripe-Dokumentation zu idempotenten Anfragen zeigt ein konkretes API-Beispiel für Wiederholungsbehandlung mit einem Schlüssel. Die beschriebenen Garantien sind produktspezifisch und teilweise zeitlich begrenzt. Daraus folgt keine entsprechende Garantie für ein beliebiges ERP.

Prüfe daher die tatsächlichen Möglichkeiten des Zielsystems. Existiert ein geeigneter Idempotenzmechanismus, muss seine Semantik verstanden und getestet werden. Fehlt er, braucht der Ablauf eine andere kontrollierte Zuordnung, etwa eine eindeutige externe Vorgangsreferenz mit Rückprüfung. Ein selbst erfundener Schlüssel wirkt nicht automatisch als technische Dublettensperre.

Bei unklarem Ausgang zuerst den Zustand feststellen

Wenn die Antwort ausbleibt, lautet der Status "Ausgang unklar". Das ist weder ein bestätigter Fehler noch ein bestätigter Erfolg. Der Prozess liest den Zielzustand anhand der geeigneten Referenz zurück, bevor er über eine Wiederholung entscheidet.

Findet er den Vorschlag B-58 mit den erwarteten Daten, wird der Vorgang entsprechend abgeschlossen. Findet er einen abweichenden Datensatz, geht der Fall in die Prüfung. Findet er nichts, muss die tatsächliche Konsistenz und Suchmöglichkeit des Zielsystems berücksichtigt werden, bevor erneut geschrieben wird.

Dieser Ablauf braucht ein Zeit- und Eskalationskonzept, das zum System passt. Eine pauschale Wartezeit aus einer Vorlage ist dafür kein belastbarer Ersatz. Die zuständige technische Person dokumentiert, welche Zustandsabfrage verlässlich ist und wie verbleibende Unsicherheit behandelt wird.

Den gespeicherten Datensatz fachlich zurücklesen

Der Readback vergleicht die neue Kennung, den Lieferanten, das Projekt, die Positionen und den Status. Bei Beträgen werden auch Einheit und Währung geprüft. Ein Vergleich nur des Gesamtbetrags übersieht beispielsweise vertauschte Positionen oder eine falsche Zuordnung.

Für B-58 muss die Rückprüfung zwei Geräte zu je 250 Euro und die Leistung zu 100 Euro bestätigen. Der Datensatz muss als interner Vorschlag bestehen. Ein versehentlich verbindlicher Bestellstatus ist ein Fehler, selbst wenn alle Zahlen stimmen.

Die Rückprüfung erzeugt einen sichtbaren Abschlussnachweis. Er nennt den geprüften Datensatz und den tatsächlichen Zustand, ohne vertrauliche Inhalte unnötig in allgemeine Logs zu kopieren. Der Nachweis gehört zum ursprünglichen Vorgang, damit Fachbereich und Technik denselben Stand sehen.

Änderungen nach der Anlage gesondert behandeln

Eine spätere Korrektur ist eine neue Aktion. Sie benötigt eine passende Berechtigung und gegebenenfalls eine erneute fachliche Freigabe. Der ursprüngliche Anlageauftrag darf nicht als dauerhafte Erlaubnis für beliebige Änderungen interpretiert werden.

Im Beispiel verändert ein nachgereichter Beleg die Einrichtungsleistung. Der bestehende Vorschlag wird nicht still überschrieben. Zuerst wird geklärt, ob der neue Beleg zum selben Vorgang gehört und welche Fassung gilt. Danach folgt die freigegebene Änderungsaktion mit erneutem Readback.

Wenn das Zielsystem bereits Folgeschritte ausgeführt hat, muss der dafür vorgesehene Korrekturprozess greifen. Die KI improvisiert keine Löschung oder Gegenbuchung. Welche Korrektur zulässig ist, hängt von den tatsächlichen fachlichen und technischen Regeln ab.

Die Freigabegrenze gezielt testen

Der Testsatz enthält den korrekten Vorschlag, einen nachträglich geänderten Betrag, einen falschen Lieferanten und einen doppelt gesendeten Auftrag. Dazu kommen ein Verbindungsabbruch nach möglicher Anlage und ein Quelltext mit unerlaubter Handlungsanweisung. Jeder Fall besitzt ein vorher festgelegtes Soll-Ergebnis.

Der korrekte Fall endet nach erfolgreichem Readback. Die geänderte Fassung wird vor dem Schreiben gesperrt. Der unklare Ausgang führt zur Zustandsprüfung. Die unerlaubte Anweisung verändert die zugelassenen Werkzeuge nicht. Diese Eigenschaften müssen tatsächlich beobachtet werden, nicht nur in der Prozessgrafik stehen.

Die Grenze ist einsatzbereit, wenn freigegebene Daten kontrolliert geschrieben werden und alle anderen Zustände einen definierten Weg besitzen. Für den fiktiven Vorschlag B-58 bedeutet das eine belegte Anlage über 600 Euro mit richtigem Zielbezug und bestätigtem Entwurfsstatus. Eine erfolgreiche HTTP-Antwort allein erfüllt diesen Abschluss nicht.

Freigaben bei veränderten Zuständigkeiten prüfen

Eine fachlich passende Person kann zum Zeitpunkt der Ausführung eine andere Rolle besitzen als bei der Vorbereitung. Der Prozess muss deshalb festlegen, wann die Berechtigung geprüft wird und wie lange eine Freigabe verwendet werden darf. Eine unbegrenzt gültige Zustimmung passt nicht automatisch zu jedem Ablauf.

Im fiktiven Beispiel bleibt ein Vorschlag mehrere Tage liegen. Vor der Ausführung wird kontrolliert, ob die Freigabe noch zum Datenstand und zur erlaubten Aktion passt. Wenn der betriebliche Prozess zusätzlich eine zeitliche Gültigkeit vorsieht, wird auch diese geprüft. Eine konkrete Frist muss intern festgelegt werden; sie entsteht nicht aus einer pauschalen KI-Empfehlung.

Eine Vertretung darf die Entscheidung nur im vorgesehenen Zuständigkeitsrahmen übernehmen. Der Name einer Vertretung in einer Abwesenheitsnotiz ist keine technische Berechtigungsvergabe. Fachliche Rollen und Systemrechte müssen zusammenpassen, damit die Freigabe sowohl zulässig als auch ausführbar ist.

Diese Fälle gehören in die Abnahme: abgelaufene Freigabe, geänderte Rolle und unveränderter gültiger Vorschlag. Der erste und zweite Fall werden entsprechend der festgelegten Regeln angehalten. Der gültige Fall läuft weiter. So zeigt der Test, dass die Kontrolle nicht lediglich jede Aktion blockiert, sondern erlaubte und unerlaubte Zustände tatsächlich unterscheidet.

Quellenstand: 23.10.2026. OWASP liefert das Sicherheitsprinzip, Stripe ein begrenztes API-Beispiel. Zustandsfolge, Beträge und ERP-Ablauf sind eigene methodische Vorschläge und keine Aussage über ein bestimmtes ERP-Produkt.