Das Formular sieht gut aus. Der Datenvertrag ist falsch.

Die Frage ist nicht, ob ein von KI erstelltes Formular produktionsreif aussehen kann. Sie lautet, ob das System, das seine Daten empfängt, zustimmt.

Ein Datumsauswahlfeld kann einwandfrei angezeigt werden und dennoch eine lokalisierungsabhängige Zeichenkette übermitteln, wenn die API ein ISO‑Datum erwartet. Ein Kontrollkästchen kann ja oder nein anzeigen, während die Datenbank einen Booleschen Wert erwartet. Die Demo besteht, der Screenshot sieht sauber aus, und der Fehler wartet weiter unten.

Was verspricht das Formular eigentlich?

Formulargestaltung wird meist als ein Interface‑Problem betrachtet. Können die Nutzer die Beschriftungen verstehen? Macht die Tab‑Reihenfolge Sinn? Funktioniert die Seite auf einem Telefon? Diese Fragen sind wichtig, beschreiben aber nicht die gesamte Aufgabe.

Ein Formular verspricht zudem, strukturierte Daten in einer Form zu liefern, die ein anderes System interpretieren kann. Dieses Versprechen umfasst Feldnamen, Datentypen, Pflichtwerte, zulässige Optionen, Vorgabewerte, Kennungen und Zielzuordnungen. Ändert man eines davon, ohne das empfangende System anzupassen, kann eine polierte Oberfläche zu einer unzuverlässigen Integration werden.

Diese Grenze wird schwerer zu erkennen, wenn generative KI-Dokumentenautomatisierung über das Verfassen von Texten hinausgeht und beginnt, strukturierte Dokumente und interaktive Komponenten zu erzeugen. Die Generierung ist schnell, weil ein Modell aus einer kurzen Beschreibung ein plausibles Layout ableiten kann. Plausibel ist jedoch nicht dasselbe wie kompatibel.

Der IETF JSON Schema Arbeitsgruppe aktiver Internet-Entwurf, zuletzt aktualisiert am 26. August 2026, beschreibt ein Schema als eine Menge von Regeln, die festlegen, welche JSON‑Werte akzeptiert werden. Er behandelt auch generative Anwendungsfälle wie UI‑Renderer. Diese Kombination trifft den Kern des Problems: Das gleiche Schema kann beim Erstellen einer Oberfläche helfen, aber die Validierung muss dennoch entscheiden, ob die resultierende Eingabe in den akzeptierten Satz gehört.

Warum driftet der Vertrag?

KI muss nicht offensichtlich fehlerhaften Code erzeugen, um einen schlechten Vertrag zu erzeugen. Sie muss lediglich eine vernünftige Annahme treffen, die das restliche System nicht teilt.

Stellen Sie sich ein Onboarding-Formular mit einem Feld namens “Customer ID” vor. Das Modell benennt das Feld customer_id, was sinnvoll erscheint. Die bestehende API erwartet jedoch weiterhin account_number. Jeder Testnutzer kann das Feld ausfüllen, aber wenn die Integration die unerwartete Eigenschaft nicht ablehnt oder übersetzt, erreicht die Kennung möglicherweise nie den richtigen Datensatz.

Typen erzeugen dieselbe Art von Fehlanpassung. Ein leeres Feld kann als leere Zeichenkette, null oder überhaupt keine Eigenschaft ankommen. Eine Zahl kann als Text übermittelt werden. Ein Dropdown kann benutzerfreundliche Beschriftungen anzeigen, während das empfangende System stabile Codes erwartet. OpenAPI 3.2.0 verwendet Schema-Objekte zur Definition von Eingabe- und Ausgabetypen, wodurch Teams eine maschinenlesbare Beschreibung erhalten, um sie mit dem Formular zu vergleichen, anstatt sich darauf zu verlassen, was der Bildschirm zu sammeln scheint.

Abhängigkeiten sind leichter zu übersehen, weil sie hinter Benutzerentscheidungen verborgen sind. Die Auswahl eines Landes kann ein Pflichtfeld für Bundesland, Provinz oder Region auslösen. Die Wahl von “company” statt “individual” kann eine Registrierungsnummer erfordern. Die bedingte Validierung von JSON Schema kann diese Beziehungen durch abhängige Anforderungen und bedingte Unterschemata ausdrücken, aber ein generiertes Formular muss dieselben Regeln dennoch umsetzen.

Entwicklerwerkzeuge, die Feldnamen, Typen, Werte und Eigenschaften offenlegen, machen die PDF-Formularfeldvalidierung zum Teil des Build‑Prozesses statt zu einer visuellen Prüfung am Ende. Das ersetzt keinen Schema‑Validator oder einen API‑Vertragstest. Es gibt Entwicklern die Kontrolle über die formularseitigen Objekte, die diese Tests inspizieren müssen.

Eine weitere Ursache für Drift ist: Das Formular und der Vertrag können zu Beginn übereinstimmen, dann aber nach unterschiedlichen Zeitplänen geändert werden. Ein Prompt wird überarbeitet. Eine Feldbeschriftung wird umbenannt. Die API entfernt eine Option oder führt eine neue Pflicht‑Eigenschaft ein. Niemand sieht ein fehlerhaftes Layout, sodass die Änderung harmlos erscheint.

Das ist es nicht.

Wie testen Sie mehr als den Happy‑Path?

Eine erfolgreiche Übermittlung beweist, dass eine Kombination von Werten einmal funktioniert hat. Produktionsformulare benötigen eine gründlichere Prüfung.

Beginnen Sie mit dem Payload, nicht mit dem Screenshot. Senden Sie ein bekanntermaßen korrektes Beispiel und vergleichen Sie die tatsächlich serialisierte Ausgabe mit dem Vertrag. Prüfen Sie Eigenschaftsnamen, Typen, Verschachtelungen und zulässige Werte. Anschließend übermitteln Sie diesen Payload durch die reale Integration und bestätigen, dass dieselben Werte die Hin‑ und Rückreise in das CRM, ERP oder die Datenbank und zurück in irgendeinen Prüfbildschirm überstehen.

Die nächsten Tests sollten darauf ausgelegt sein, zu scheitern. Versuchen Sie einen fehlenden Pflichtwert, eine leere Zeichenkette, wo null erwartet wird, eine Zahl außerhalb ihres Bereichs, eine unerwartete Dropdown‑Option und eine Eigenschaft, die der Vertrag nicht erkennt. Eine nützliche Validierungsschicht blockiert die Anfrage nicht nur, sondern identifiziert das Feld und die Regel, die fehlgeschlagen sind, so klar, dass ein Entwickler, Betreiber oder Benutzer sie beheben kann.

Bedingte Verzweigungen verdienen einen eigenen Durchlauf. Wenn ein Formular fünf Auswahlmöglichkeiten enthält, die unterschiedliche Folge‑felder offenbaren, testen Sie alle fünf. Testen Sie auch das Zurückschalten: Ein verborgenes Feld sollte nach einer Änderung einer früheren Antwort keinen veralteten Wert mehr übermitteln. Hier trifft ein Artikel über Dokumentstruktur und -kontext auf gewöhnliches Software‑Testing. Das Verständnis von Beziehungen im Dokument ist nur dann nützlich, wenn diese Beziehungen die Serialisierung überstehen.

Die Identität eines Feldes ist wichtiger als die Formulierung des Feldes. Beschriftungen ändern sich zur Klarheit, für Übersetzungen und im Markenstil. Stabile interne Kennungen sollten sich nicht mit ihnen ändern. Ein Release‑Check sollte daher das sichtbare Label, den internen Namen, den erwarteten Typ und die Zielzuordnung als separate Eigenschaften vergleichen.

Beachten Sie schließlich, was passiert, wenn das empfangende System nicht verfügbar ist oder die Übermittlung ablehnt. Bewahrt das Formular die Arbeit des Benutzers? Wiederholt es den Vorgang sicher oder erzeugt Duplikate? Kann ein Operator den Fehler nachverfolgen, ohne die Roh‑Logs zu lesen? Daten, die zwischen Dokumentenverarbeitungs‑Workflows und Unternehmenssystemen ausgetauscht werden, benötigen einen nachvollziehbaren Fehlerschritt, nicht eine Erfolgsmeldung, die angezeigt wird, bevor die Übergabe abgeschlossen ist.

Wer besitzt den Vertrag nach dem Start?

Vertragstests können keine einmalige Aufräumaktion sein, die erst kurz vor dem Release durchgeführt wird. Das Formular, das Schema und die nachgelagerte Schnittstelle werden sich ständig ändern.

Ein Team muss eine klare Verantwortung für den Vertrag übernehmen, selbst wenn mehrere Teams Teile des Workflows besitzen. Dieser Verantwortliche muss nicht jede Textänderung genehmigen. Er muss jedoch wissen, welche Änderungen übermittelte Daten beeinflussen können, welche Tests durchgeführt werden müssen und wer reagiert, wenn Validierungsfehler auftreten.

Versionieren Sie das Schema zusammen mit der Formulardefinition. Führen Sie repräsentative Vertragstests in der kontinuierlichen Integration aus, sobald sich Vorlage, Prompt, Formularcode oder API ändern. In der Produktion sollten abgelehnte Einsendungen und Zuordnungsfehler nach Feld und Vertragsversion überwacht werden. Ein Anstieg eines Fehlers nach einem Release lässt sich viel leichter diagnostizieren als ein vager Hinweis, dass „das Formular nicht mehr funktioniert“.

Es gibt Grenzen dessen, was die Schema‑Validierung beweisen kann. Sie kann zeigen, dass ein Wert den deklarierten Vorgaben entspricht. Sie kann jedoch nicht beweisen, dass der Benutzer den richtigen Wert gewählt hat, dass die Geschäftsregel sinnvoll ist oder dass der Workflow alle Sicherheits‑, Datenschutz‑, Barrierefreiheits‑ oder Compliance‑Anforderungen erfüllt. Teams benötigen weiterhin Richtlinien‑Checks und menschliches Urteilsvermögen, wo die Konsequenzen es erfordern.

Diese Einschränkung schwächt das Argument für einen Vertrag nicht. Sie definiert die Aufgabe des Vertrags.

Fazit

KI kann den Weg von einer Beschreibung zu einem funktionierenden Formular verkürzen. Sie kann zudem eine Oberfläche fertig erscheinen lassen, bevor jemand das dahinterstehende Versprechen getestet hat.

Die Release‑Entscheidung sollte auf expliziten Feldsemantiken, Vertragstests, die Fehlerszenarien einschließen, und einer Verantwortung basieren, die spätere Änderungen übersteht. Ein sauberer Bildschirm ist willkommen. Die schwierigere, aber entscheidende Frage lautet: kann jede akzeptierte Eingabe vom empfangenden System korrekt interpretiert werden?