Projekt

Serviceanfragen vom PDF zu geprüften Geschäftsdaten

Eine Serviceanfrage kommt als PDF. Das eigene Demonstrationsprojekt zeigt, wie KI daraus Felder für die weitere Bearbeitung vorbereitet – mit synthetischen Daten, festen Prüfregeln und menschlicher Freigabe vor der Übergabe.

Eigenes Demonstrationsprojekt mit synthetischen Daten.

Reifegrad: reproduzierte Demo. Keine Kundendaten, kein produktives CRM/ERP. Die Übergabe erfolgt an ein lokal kontrolliertes Mock-Zielsystem. Nachweisstand: 01.10.2026.

Vom PDF zum bearbeitbaren Vorgang

Eine Serviceanfrage im PDF muss gelesen, in bearbeitbare Felder übertragen und an ein System übergeben werden. Bei manueller Übertragung können Informationen fehlen, widersprüchliche Angaben übersehen oder Vorgänge doppelt angelegt werden. Der Demonstrator untersucht genau diesen Übergang für eine synthetische B2B-Serviceanfrage.

Ausgangslage und Ziel

Das textbasierte PDF enthält sieben fachliche Felder: Anfrage-ID, Unternehmen, Kontakt, E-Mail, Leistungsart, Wunschtermin und Beschreibung. Ziel ist ein geprüfter Vorgang mit nachvollziehbarer Freigabe und Übergabestatus.

AI schlägt strukturierte Felder vor. Deterministische Software prüft Schema, Pflichtfelder, erlaubte Werte, Plausibilität und Quellenkonflikte. Ein Mensch prüft die konkrete Fassung und autorisiert erst danach die Übergabe an ein lokales Mock-Ziel.

Ein Ablauf mit klaren Zuständigkeiten

Schematische Darstellung des begrenzten Demonstrators, kein Messergebnis. Nur die menschliche Freigabe der aktuellen Revision erlaubt die Übergabe. Eine Änderung führt zurück in den Review.

PDF → Text extrahieren: Die Eingangsinformation bleibt als Quelle erhalten.
AI → Feldvorschläge: Das Modell strukturiert die Information und liefert Belege und Unsicherheiten.
Deterministische Prüfung → REVIEW_REQUIRED: Schema und Fachregeln prüfen die Vorschläge. Ein bestandener Test ist noch keine Freigabe.
Human Review → APPROVED: Ein Mensch vergleicht PDF, Vorschläge und Quellen und gibt die konkrete Revision ausdrücklich frei.
Kontrollierte Übergabe → Receipt und Status: Erst die gültige Freigabe erlaubt den Handoff an die lokale Mock-API. Fehler und ungewisse Zustände bleiben sichtbar.

Warum AI nur einen Teil übernimmt

AI hilft beim Übergang von Dokumenttext zu strukturierten Informationen. Sie bestimmt weder die fachliche Wahrheit noch die Validierungsregeln und besitzt keine Berechtigung, APPROVED zu setzen. Auch formal gültige Feldvorschläge müssen zu ihren Quellen passen.

Python führt die Verarbeitung und deterministischen Regeln aus. JSON Schema begrenzt die erlaubte Struktur; SQLite hält Revisionen, Freigaben und Übergabestatus lokal fest. Der LLM-Schritt verwendet die Responses API. Die lokale HTTP-Mock-API macht die Übergabe tatsächlich ausführbar, ohne ein Kundensystem anzusprechen.

Human Review gilt für eine konkrete Fassung

Der Reviewer sieht das PDF, alle vorgeschlagenen Werte, die Quellen, Unsicherheiten und die Prüfergebnisse. Die ausdrückliche Freigabe bindet die Revision und ihren Inhaltsdigest. Vor jeder Übergabe muss diese Freigabe zur aktuellen Fassung passen.

Änderung nach Freigabe → neue Revision → REVIEW_REQUIRED → erneuter Human Review. Die alte Freigabe bleibt historisch erhalten und autorisiert die geänderten Daten nicht.

Fehlerfälle gehören zum Prozess

Fehlende Information: Ein fehlendes Pflichtfeld wird nicht durch einen erfundenen Ersatzwert gefüllt; die Freigabe bleibt gesperrt.
Widerspruch: Unterschiedliche Termine bleiben als Konflikt sichtbar. Erst eine begründete menschliche Korrektur und neue Prüfung können den Fall weiterführen.
Duplikat: Byteidentische Eingaben werden im geprüften Korpus demselben Fall zugeordnet. Verschiedene PDFs mit inhaltlich ähnlichen Angaben werden nicht semantisch dedupliziert.
Manipulative Anweisung im Dokument: Der Inhalt bleibt nicht vertrauenswürdige Eingabe. Er erhält keine Berechtigung, Status, Freigaben oder Netzwerkaktionen zu bestimmen.
Zielsystemfehler: Geeignete temporäre Fehler können erneut versucht werden. Permanente Fehler und Konflikte stoppen den automatischen Retry.
Timeout nach möglichem Commit: Zuerst das Receipt am gebundenen Ziel abgleichen. Bei ungeklärtem Zielzustand bleibt die Übergabe ungewiss; kein blinder erneuter Schreibversuch.
Änderung nach Freigabe: Die neue Revision bleibt bis zu ihrem eigenen Review gesperrt, auch bei einer Rückänderung auf frühere Werte.

Was tatsächlich geprüft wurde

Der finale WP-01-Stand bestand 205 automatisierte Tests: 0 Fehler, 0 fehlgeschlagene Tests, 0 Skips. Die Suite prüfte Erfolgs-, Validierungs-, Review-, Idempotenz-, Recovery- und Fehlerpfade im synthetischen lokalen Korpus. Freigaben in diesen Tests waren Simulationen in isolierten Testdatenbanken.

Davon getrennt führte der Founder den vollständigen Live-Ablauf persönlich aus. Die folgenden Beobachtungen beziehen sich auf diesen einen synthetischen Happy Path und seine anschließende Änderung.

Live-Extraktion: gpt-5.6-sol lieferte die sieben Felder des PDF korrekt. Der Founder verglich Werte und Quellzeilen; im Happy Path wurden keine Unsicherheiten angezeigt. Schema und deterministische Fachprüfung bestanden.
Menschliche Freigabe und Übergabe: Der Founder autorisierte Revision 1 ausdrücklich. Die lokale Mock-API nahm den Vorgang an; der unmittelbare Replay lieferte dasselbe Receipt.
Freigabeinvalidierung: Nach einer bewussten menschlichen Änderung entstand Revision 2 / REVIEW_REQUIRED. Die Übergabe ohne neue Freigabe wurde blockiert.

Die versionierten technischen Reports und das Runbook liegen im privaten Automation-Repository. Die öffentliche Zusammenfassung ist an dessen gemergten WP-01-Stand gebunden. Eine unabhängige Reproduktion oder ein öffentlich zugänglicher Quellcode wird damit nicht behauptet.

Ergebnis

Im persönlichen Founder-Lauf am 01.10.2026 wurden die sieben Felder mit gpt-5.6-sol korrekt aus dem synthetischen PDF extrahiert und mit dem PDF und den Quellen verglichen. Schema und Fachregeln bestanden; Revision 1 wurde ausdrücklich menschlich freigegeben und an die lokale Mock-API übergeben. Der unmittelbare Replay lieferte dasselbe Receipt. Nach einer menschlichen Änderung entstand Revision 2 mit REVIEW_REQUIRED; ihre Übergabe blieb ohne erneute Freigabe blockiert.

Der Nachweis zeigt das Zusammenspiel von AI-Vorschlag, überprüfbaren Regeln und menschlicher Autorisierung in einem ausgeführten, begrenzten Prozess. Er misst keine Zeit- oder Kosteneinsparung.

Grenzen des Demonstrators

Genau eine synthetische, textbasierte PDF-Dokumentfamilie; kein OCR und keine allgemeine Dokumentenklassifikation.
Lokale Mock-API; keine echte Kunden-, CRM- oder ERP-Integration und kein Produktionsbetrieb.
Ein persönlicher Livefall liefert keine allgemeine Extraktionsgenauigkeit oder Genauigkeitsquote für beliebige Dokumente.
Keine Enterprise-Skalierung und keine universelle Exactly-once-Garantie.
Vertrauenswürdiger lokaler Betrieb mit unverändertem Anwendungscode; keine Mehrbenutzer-Sicherheitsplattform oder allgemeine PDF-Parser-Sandbox.
Keine Aussage zur rechtlichen Eignung für beliebige Datenklassen. Ein realer Einsatz braucht eigene Rechte-, Daten-, Integrations- und Freigabeprüfungen.

Den Ablauf nachvollziehen

Das gebundene Runbook beschreibt die folgende Wiederholung. Der Web-Case führt keinen weiteren LLM-Lauf aus. Zugang zum privaten Proof und eine geeignete Live-Berechtigung sind eigene Voraussetzungen; spätere Modellantworten werden nicht als bitidentisch zugesagt.

Den gebundenen WP-01-Stand in einer kontrollierten lokalen Umgebung bereitstellen; die dokumentierte Testumgebung ist Windows 11 mit Python 3.14.0.
Den versionierten synthetischen Korpus erzeugen und die automatisierten Tests ausführen.
Den lokalen Demonstrator mit seinem separaten Zustandsspeicher und der lokalen Mock-API starten.
Die Anfrage mit Live-Extraktion oder dem Fixtureprovider verarbeiten. Ein Fixturelauf ist kein Live-LLM-Nachweis.
PDF, Feldvorschläge, Quellen, Unsicherheiten, Prüfstatus und die konkrete Revision persönlich vergleichen.
Die geprüfte Revision ausdrücklich freigeben; anschließend den Mock-Handoff ausführen und das Receipt prüfen.
Den Handoff wiederholen und das identische Receipt prüfen.
Eine begründete synthetische Änderung durchführen; die neue REVIEW_REQUIRED-Revision und den blockierten Handoff ohne neue Freigabe beobachten.

Mein Beitrag

Ich habe Problem, Scope, Priorisierung, fachliche Regeln und Abnahmekriterien festgelegt. Ich habe die vorgelegten Ergebnisse geprüft und den vollständigen Founder-Lauf einschließlich Vergleich mit dem PDF, Human Review, Freigabe, Übergabe und anschließender Änderung selbst durchgeführt. Die Entscheidung über eine Veröffentlichung bleibt ein eigener Schritt.

AI-Unterstützung

Coding-Agenten unterstützten wesentliche Teile der Implementierung, Tests und Dokumentation. Im Demonstrator strukturiert das Live-LLM die Dokumentinformation zu Feldvorschlägen. Fachliche Prüfung, menschliche Freigabe und Veröffentlichungsentscheidung bleiben davon getrennt.

Methodik lesen

Weitere Projekte