Ein lesbares Datenformat ist nur der Anfang

JSON ist ein verbreitetes Format für strukturierte Daten. Wenn eine KI eine gültige JSON-Antwort liefert, kann eine Anwendung diese grundsätzlich einlesen. Das sagt noch nicht, ob die enthaltene Kundennummer existiert, die Menge zulässig ist oder eine Änderung ausgeführt werden darf.

Auch ein Schema ist nur so aussagekräftig wie seine Regeln. Es kann beispielsweise verlangen, dass eine Menge eine Zahl ist. Ob diese Zahl zur konkreten Bestellung passt, braucht zusätzliche fachliche Prüfung. Ein sauberer Datentyp ersetzt keinen Geschäftsprozess.

OWASP behandelt unzureichend geprüfte Modellantworten als eigenes Risiko für nachgelagerte Systeme. Für eine Agenturbeauftragung sollte deshalb klar sein, welche Prüfung zwischen dem generierten Vorschlag und einer tatsächlichen Aktion liegt.

Vier Fragen vor der Übernahme

Für die Abstimmung mit Ihrem Fachteam empfehlen wir vier getrennte Prüffragen. Erstens: Ist die Ausgabe technisch vollständig und im erwarteten Format? Zweitens: Sind die Werte fachlich zulässig und widerspruchsfrei? Drittens: Passen die referenzierten Objekte zum berechtigten Arbeitskontext? Viertens: Ist der vorgesehene Zustandswechsel jetzt erlaubt?

Der OWASP-Leitfaden zur Eingabevalidierung unterscheidet syntaktische und semantische Prüfung und weist darauf hin, dass Berechtigung zusätzlich geprüft werden muss. Eine Modellantwort wird für das empfangende System zur Eingabe und benötigt entsprechend klare Regeln.

Diese Kontrollen sollten nicht ausschliesslich eine zweite KI übernehmen. Für eindeutige Vorgaben wie erlaubte Statuswerte oder notwendige Pflichtfelder ist deterministische Programmlogik meist die nachvollziehbarere Grundlage. Eine zusätzliche fachliche Bewertung kann daneben sinnvoll bleiben.

Ein fiktiver Bestellvorschlag

Eine künstliche Kundenanfrage nennt zwölf Ersatzteile. Die KI gibt ein technisch gültiges Objekt zurück, das eine existierende Artikelnummer und die Menge 120 enthält. Das Format ist korrekt, aber die Menge stimmt nicht mit der Quelle überein.

Eine weitere Variante enthält die richtige Menge, verweist aber auf die Kundennummer eines anderen Testkunden. Eine dritte schlägt die richtige Bestellung vor, obwohl der zugrunde liegende Auftrag bereits storniert wurde. Alle drei Fälle zeigen unterschiedliche Fehler, die ein einfacher JSON-Parser nicht erkennt.

Im Abnahmetest soll jeder Fall einen passenden Klärungsgrund erhalten. «Ungültig» allein hilft dem Team wenig. «Menge weicht von freigegebener Anfrage ab» oder «Auftrag ist nicht mehr bearbeitbar» macht den nächsten Schritt verständlich.

Eine Regelkarte pro schreibender Aktion

Verlangen Sie für wichtige Aktionen eine kurze Regelkarte, die Fachteam und Entwicklung gemeinsam lesen können. Für die fiktive Bestellung könnte sie folgende Punkte enthalten:

• Pflichtangaben: Kundenreferenz, Artikelreferenz und angefragte Menge.

• erlaubte Werte: passende Datentypen und fachlich festgelegte Grenzen.

• Quellenbezug: entscheidende Angaben müssen aus freigegebenen Informationen stammen.

• Referenzprüfung: Kunde und Artikel sind im richtigen Kontext zugänglich und gültig.

• Zustandsprüfung: der Auftrag ist offen und wurde nicht bereits abschliessend verarbeitet.

• Freigabe: die vorgesehene Person bestätigt den tatsächlichen Vorschlag.

• Fehlerweg: unklare Fälle werden sichtbar zur Bearbeitung übergeben.

Die Karte ist keine vollständige Spezifikation für jedes ERP. Sie macht jedoch deutlich, welche Entscheidung ausserhalb der freien Textgenerierung abgesichert werden muss.

Nach der Freigabe kann sich etwas ändern

Zwischen Prüfung und Speicherung kann ein anderer Mitarbeiter den Auftrag bearbeiten. Deshalb sollte die Integration auch unmittelbar vor der Änderung den relevanten Zustand berücksichtigen. Andernfalls wird möglicherweise eine zuvor gültige Entscheidung auf inzwischen veraltete Daten angewendet.

Dasselbe gilt für wiederholte Übermittlungen. Nach einem Timeout ist zunächst unklar, ob das Zielsystem die Aktion bereits ausgeführt hat. Die Anwendung braucht einen kontrollierten Abgleich oder einen vom Zielsystem unterstützten Schutz gegen doppelte Verarbeitung.

Lassen Sie diese Fälle in einer Testumgebung demonstrieren. Ein Test nur mit frischen, unveränderten Datensätzen deckt die Zusammenarbeit mehrerer Personen und Dienste nicht ausreichend ab. Beobachten Sie dabei das Zielsystem, nicht nur die Erfolgsmeldung im Chat.

Verständliche Fehler statt stiller Korrekturen

Eine Anwendung sollte fehlende Pflichtwerte nicht unbemerkt durch plausible Schätzungen ersetzen. Wenn ein Vorgang blockiert wird, braucht die zuständige Person die betroffene Angabe und einen verständlichen Grund. So lässt sich der Fall gezielt klären.

Vereinbaren Sie zudem, wer Regeln pflegt und nach welchen Änderungen erneut getestet wird. Neue Produktarten oder andere Freigabegrenzen können die bisherige Validierung unvollständig machen. Die Regelkarte bleibt nur nützlich, wenn sie den tatsächlichen Ablauf beschreibt.

Die organisatorische Ergänzung erläutert unser Beitrag zu Freigaben für KI-Agenten. Mit einclick als KI-Umsetzungspartner aus Zürich können Sie Vorschläge, Kontrollen und erlaubte Aktionen zu einem überprüfbaren Lieferumfang verbinden.