Dokumente auslesen und Daten kontrolliert übernehmen

Ein gefundener Text ist noch kein freigegebener Datensatz

Dokumente automatisch auszulesen kann wiederkehrende Erfassung erleichtern. Verlässliche Übernahme braucht jedoch mehr als erkannten Text: klare Feldbedeutung, nachvollziehbare Quellen, fachliche Regeln und eine ausdrücklich zuständige Entscheidung. Eine im Dokument gedruckte Freigabe ist nicht automatisch eine Berechtigung für das Zielsystem. Ebenso darf ein plausibel formulierter Datenvorschlag keine fehlende oder widersprüchliche Quelle verdecken.

Unser eigenes Beispiel ist ein fiktives Projektbriefing. Es nennt Projektkennung, Dokumentdatum, Projektname, Freigabestatus, geplanten Seitenumfang und Sprache. Drei tatsächliche PDFs werden erzeugt und ausgelesen: ein eindeutiges Briefing, eine Variante mit zwei Statusangaben und eine reine Bildfassung ohne Textebene. Der Python-Code wird mit diesen Dateien und weiteren Feldfällen ausgeführt. Es werden keine echten Kundendaten übernommen.

Die Aufgabe bleibt bewusst begrenzt. Für das bekannte kleine Briefformular entwickeln wir einen deterministischen Parser und eine getrennte Prüfschranke für den Importvorschlag. Eine beliebige Rechnung, ein mehrspaltiges Gutachten oder ein unbekanntes eingescanntes Formular braucht andere Regeln. Gerade die erkennbare Grenze macht das Beispiel brauchbar: Es zeigt, wo Textgewinnung aufhört und kontrollierte fachliche Verarbeitung beginnt.

Den Eingang nach seinem tatsächlichen Aufbau behandeln

Ein digital erzeugtes PDF kann eine auslesbare Textebene besitzen. Ein reines Bild-PDF zeigt dagegen möglicherweise denselben Inhalt, liefert dem Textparser aber keinen solchen Text. Im tatsächlichen Bildbeispiel bleibt das Extraktionsergebnis leer. Der Code erfindet deshalb keine Felder. Der Vorgang wird für einen anderen Erkennungs- oder Prüfweg zurückgestellt. Eine OCR-Verarbeitung wurde in diesem Beispiel nicht ausgeführt.

Auch eine vorhandene Textebene ist kein vollständiges Inhaltsmodell. Spalten, Tabellen, Kopfbereiche und Reihenfolgen können die Zuordnung erschweren. Die pypdf-Dokumentation erläutert diese Grenzen der Textextraktion. Unser Briefing verwendet einen bewusst eindeutigen bekannten Aufbau. In einem echten Bestand werden repräsentative Varianten zunächst gesichtet, bevor die passende Extraktionsstrategie für einen Dokumenttyp festgelegt wird.

Die Datei wird außerdem als konkrete Version festgehalten. Ein später neu eingesandtes Dokument darf nicht unbemerkt unter derselben schon geprüften Vorschlagsansicht weiterlaufen. Dafür verwendet das Beispiel einen SHA-256-Wert der Quellbytes. Er identifiziert die konkrete Quelle des Vorschlags. Der Hash beweist keine inhaltliche Wahrheit, unterstützt aber eine klare Zuordnung zwischen Datei, Prüfung und vorbereitetem Datenpaket.

pypdf: Text extraction

Feldbedeutungen vor dem Auslesen festlegen

Die Projektkennung folgt im Beispiel genau dem Muster DEMO mit drei Ziffern. Das Dokumentdatum wird als konkretes ISO-Datum interpretiert. Der Seitenumfang bedeutet die geplante Zahl von Projektseiten und nicht die Anzahl der PDF-Seiten. Das ist eine wichtige semantische Trennung: Unser Briefing hat eine PDF-Seite und enthält den geplanten Umfang acht. Ein technisch gut erkannter Zahlenwert wäre im falschen Zielfeld trotzdem falsch.

Der Freigabestatus wird als Dokumentaussage behandelt. Der Text nicht freigegeben ergibt ausdrücklich false und nicht etwa true, nur weil die Zeichenfolge freigegeben darin vorkommt. offen bleibt ein eigener ungeklärter Wert. Diese Zuordnung wird als zulässige Wertemenge festgelegt und tatsächlich geprüft. Eine bloße Suche nach positiv klingenden Teilwörtern wäre für diesen Fall ungeeignet.

Für jedes Feld dokumentieren wir erwarteten Typ, zulässige Werte und den Umgang mit fehlenden Angaben. Ein Datum benötigt eine Kalenderprüfung, eine Seitenzahl eine sinnvolle Ganzzahlgrenze und eine Sprache einen vereinbarten Code. Die Regeln sind eigene Beispielannahmen, keine universelle Definition aller Projektbriefings. Ein anderes Zielsystem muss seine tatsächliche Bedeutung festlegen, bevor die erste Datei automatisch befüllt wird.

Fundstellen statt bloßer Behauptungen speichern

Zu jedem erkannten Feld hält der Vorschlag Seite, Zeile und tatsächlichen Quelltext fest. Eine prüfende Person kann dadurch nachvollziehen, woher der Wert stammt. Der reine Wert acht wäre weniger hilfreich als die zugehörige Zeile Seitenumfang: 8 auf Seite eins. Diese Herkunft gehört zum Vorschlag und nicht erst in eine spätere allgemeine Protokolldatei, die von der prüfenden Oberfläche getrennt ist.

Die Zeilennummer bezieht sich auf den tatsächlich extrahierten Text, nicht auf eine behauptete exakte Bildkoordinate. Die Darstellung im Beitrag verwendet zusätzlich echte Ausschnitte der gerenderten PDFs. So lassen sich Textquelle und sichtbares Dokument gemeinsam betrachten. Wir behaupten keine pixelgenaue OCR-Markierung. Die gewählte Provenienz ist klein, überprüfbar und zum tatsächlichen Parser passend.

Wenn dieselbe Feldbezeichnung mehrfach vorkommt, bleiben alle Fundstellen erhalten. Auch zwei identische Projektkennungen werden im bewusst strengen Beispiel nicht still zu einer eindeutigen Angabe zusammengezogen. Eine andere Vorlage könnte solche Wiederholungen legitim vorsehen. Dann braucht sie eine ausdrücklich andere geprüfte Regel. Der konservative Ausgangspunkt verhindert, dass ein Parser ohne fachliche Grundlage einfach die erste oder letzte passende Zeile zum Gewinner erklärt.

Widersprüche als eigenen Arbeitszustand behandeln

Das zweite Briefing enthält nicht freigegeben und zusätzlich freigegeben. Beide Zeilen werden tatsächlich gefunden. Für den Status entsteht ein Duplikatblocker und kein ausgewählter verbindlicher Wert. Der Vorschlag bleibt prüfpflichtig. Die Information geht dadurch nicht verloren und die Anwendung tut nicht so, als hätte eine eindeutige Quelle vorgelegen. Genau diese Unterscheidung ist für eine verlässliche Übernahme entscheidend.

Ein Blocker sollte der prüfenden Person eine konkrete Frage geben. Im Beispiel lautet sie, welche Dokumentaussage geklärt werden muss. Eine pauschale Meldung Verarbeitung fehlgeschlagen wäre weniger nützlich. Der Mensch braucht beide Fundstellen und einen nachvollziehbaren nächsten Schritt. Ob ein korrigiertes Dokument oder eine zuständige Rückfrage erforderlich ist, hängt vom realen Arbeitsablauf ab.

Ein ungeklärter Datensatz wird nicht automatisch dadurch besser, dass ein Sprachmodell eine der Varianten überzeugend zusammenfasst. Wenn die Quelle widersprüchlich ist, muss der Vorschlag diesen Zustand erhalten. Ein Modell kann bei der Einordnung helfen, darf aber keine fehlende fachliche Autorität durch einen selbstbewussten Satz ersetzen. Die eigentliche Entscheidung bleibt außerhalb der Extraktion ausdrücklich geregelt.

Dokumentanweisungen von Arbeitsregeln trennen

Die widersprüchliche Beispielvariante enthält außerdem die Aufforderung, Prüfungen zu überspringen und die Freigabe auf ja zu setzen. Dieser Satz ist Quellinhalt. Er ändert weder Parserregeln noch Berechtigungen. Der tatsächlich ausgeführte Test bestätigt, dass eine solche Notiz den bekannten negativen Status nicht in eine positive Aussage umwandelt. Das Beispiel verwendet dafür feste Feldzuordnung und eine getrennte Importentscheidung.

Bei einer KI-gestützten Verarbeitung ist dieselbe Grenze besonders wichtig. Externe Dokumente können Anweisungen enthalten, die wie Arbeitsaufträge klingen. OWASP beschreibt solche indirekten Prompt-Injection-Situationen. Ein bloßes Etikett untrusted ist allein noch keine Durchsetzung. Ausführende Funktionen brauchen eigene begrenzte Rechte und prüfen ihre Argumente unabhängig davon, wie überzeugend ein Modellvorschlag formuliert wurde.

Unser deterministischer Briefingparser ist kein allgemeiner Erkennungsfilter für jede mögliche bösartige Anweisung. Er zeigt eine enge funktionale Grenze: Nur die vereinbarten Feldzeilen liefern Werte und die Berechtigung zum Vorbereiten eines Imports kommt aus einem getrennten vertrauenswürdigen Prüfablauf. Andere Texte werden nicht als ausführbare Regeln behandelt. Diese Zuständigkeit bleibt auch dann erhalten, wenn später ein Modell zusätzliche Kandidaten vorschlägt.

OWASP: LLM Prompt Injection Prevention

Den ausgeführten Python-Baustein nachvollziehen

Der folgende Code wurde mit Python 3.12.14 und pypdf 6.10.0 ausgeführt. Er liest das bekannte Briefingformat, prüft seine Felder und erzeugt einen Vorschlag mit Herkunft und Blockern. Die Beispieldateien sind selbst erstellt und fiktiv. Der Parser ist nicht als allgemeine Vorlage für jedes beliebige PDF zu verstehen. Seine erlaubten Bezeichnungen und Werte sind bewusst eng und nachvollziehbar.

Die Datei- und Seitenbegrenzung hilft beim begrenzten Ablauf, ist aber keine vollständige Ressourcenisolation für fremde PDFs. Eine produktive Eingangsstrecke benötigt zusätzlich passende Ausführungs-, Zeit- und Speichergrenzen sowie einen gepflegten Parser. Der Code führt keine OCR durch und schreibt nichts in ein produktives Zielsystem. Er bereitet nach einer passenden simulierten Prüfentscheidung nur ein Datenpaket vor.

from pathlib import Path
from datetime import date
from hashlib import sha256
import json
import re
from pypdf import PdfReader

FIELDS={
    'Projekt-ID':'project_id', 'Dokumentdatum':'document_date',
    'Projektname':'project_name', 'Freigabestatus':'document_release_assertion',
    'Seitenumfang':'planned_pages', 'Sprache':'language'
}

def values_hash(values):
    raw=json.dumps(values,ensure_ascii=False,sort_keys=True,separators=(',',':'))
    return sha256(raw.encode('utf-8')).hexdigest()

def propose(pages, source_hash):
    found={key:[] for key in FIELDS.values()}
    for page_number,text in enumerate(pages,1):
        for line_number,line in enumerate(text.splitlines(),1):
            raw=line.strip()
            for label,key in FIELDS.items():
                if raw.startswith(label+':'):
                    found[key].append({'page':page_number,'line':line_number,
                        'raw':raw,'value':raw[len(label)+1:].strip()})
    values={}; blockers=[]
    if not any(text.strip() for text in pages): blockers.append('no_text_layer')
    for key,items in found.items():
        if len(items)!=1:
            blockers.append(('missing:' if not items else 'duplicate:')+key)
            continue
        value=items[0]['value']
        try:
            if key=='project_id':
                if not re.fullmatch(r'DEMO-[0-9]{3}',value): raise ValueError()
            elif key=='document_date':
                if not re.fullmatch(r'[0-9]{4}-[0-9]{2}-[0-9]{2}',value): raise ValueError()
                value=date.fromisoformat(value).isoformat()
            elif key=='project_name':
                if not 1<=len(value)<=120 or any(ord(c)<32 for c in value): raise ValueError()
            elif key=='document_release_assertion':
                allowed={'freigegeben':True,'nicht freigegeben':False,'offen':None}
                if value not in allowed: raise ValueError()
                value=allowed[value]
            elif key=='planned_pages':
                if not re.fullmatch(r'[0-9]{1,3}',value): raise ValueError()
                value=int(value)
                if not 1<=value<=500: raise ValueError()
            elif key=='language':
                if value not in {'de','en'}: raise ValueError()
            values[key]=value
        except ValueError:
            blockers.append('invalid:'+key)
    return {'source_sha256':source_hash,'values':values,'sources':found,
        'blockers':sorted(blockers),'proposal_sha256':values_hash(values),
        'review_required':True}

def extract_proposal(path):
    path=Path(path)
    if path.stat().st_size>1_000_000: raise ValueError('File limit exceeded')
    source_hash=sha256(path.read_bytes()).hexdigest()
    reader=PdfReader(path)
    if reader.is_encrypted: raise ValueError('Encrypted document requires separate handling')
    if len(reader.pages)>5: raise ValueError('Page limit exceeded')
    pages=[page.extract_text() or '' for page in reader.pages]
    return propose(pages,source_hash),pages

def prepare_import(candidate,current_source_hash,decision):
    # decision comes from a trusted review workflow, never from document text.
    if candidate['blockers']: raise ValueError('Blocked proposal')
    if decision.get('approved') is not True: raise ValueError('Review required')
    if decision.get('role')!='data_reviewer': raise ValueError('Review permission required')
    reviewer=decision.get('reviewer_id')
    if not isinstance(reviewer,str) or not re.fullmatch(r'reviewer-[a-z0-9-]+',reviewer):
        raise ValueError('Reviewer reference required')
    if not current_source_hash==candidate['source_sha256']==decision.get('source_sha256'):
        raise ValueError('Source changed')
    actual=values_hash(candidate['values'])
    if not actual==candidate['proposal_sha256']==decision.get('proposal_sha256'):
        raise ValueError('Proposal changed')
    return {'data':dict(candidate['values']),'source_sha256':current_source_hash,
        'proposal_sha256':actual,'reviewer_id':reviewer}

Syntax und fachliche Bedeutung getrennt prüfen

Ein Datum mit dem Muster vier Ziffern, Bindestrich, zwei Ziffern, Bindestrich, zwei Ziffern kann trotzdem ein unmöglicher Kalendertag sein. Unser Beispiel verlangt zuerst die konkrete Schreibweise und prüft anschließend das Datum. Der 29. Februar 2024 ist zulässig, der 29. Februar 2025 nicht. Diese Fälle wurden tatsächlich ausgeführt. Ein passender regulärer Ausdruck allein würde diesen Unterschied nicht vollständig erklären.

Der geplante Seitenumfang wird als begrenzte positive Ganzzahl gelesen. Null, negative Angaben, Bruchteile und ein Wert außerhalb der Beispielgrenze werden abgewiesen. Die Grenze muss in einem echten Projekt fachlich passend sein. Der Testwert acht beweist keine allgemeine Erwartung an reale Relaunchprojekte. Er macht nur die gewählte Datentypentscheidung und ihre Gegenfälle überprüfbar.

Auch ein technisch gültiger Datensatz kann fachlich falsch zugeordnet sein. Eine Projektkennung darf nicht ungeprüft zu einem zufällig gleich benannten echten Kunden führen. Die Zielanwendung muss Gegenstand, Zuständigkeit und zulässige Änderung bestimmen. Unser Parser erzeugt eine fiktive Projektkennung und übernimmt keine realen Kundenzuordnungen. Diese Grenze ist ein eigener Teil des kontrollierten Imports.

Python: datetime · OWASP: Input Validation

Prüfentscheidung an Quelle und Vorschlag binden

Der Importvorbereitung genügt im Beispiel kein allgemeiner Haken am Dokument. Die Entscheidung nennt den konkreten Quellhash, den Hash der geordneten Vorschlagswerte und eine Referenz der prüfenden Person. Ändert sich die Quelle oder wird ein Wert nach der Prüfung verändert, passt die Entscheidung nicht mehr. Der Code weist diese Fälle zurück. Dadurch wird eine alte Zustimmung nicht automatisch auf einen neuen Inhalt übertragen.

Die Rolle data_reviewer stammt im Beispiel aus dem vertrauenswürdigen Prüfablauf. Sie darf nicht aus dem PDF oder einem frei gesetzten Browserfeld übernommen werden. Der kleine Baustein ist keine vollständige Authentifizierung. Eine reale Anwendung muss die Identität und die erlaubte Aufgabe vorher festlegen. Die reine Funktionsprüfung untersucht anschließend, ob der konkrete Entscheidungsvertrag eingehalten wird.

Ein erfolgreich vorbereitetes Paket enthält weiterhin nur Daten und ihre Herkunft. Die Dokumentaussage nicht freigegeben bleibt false. Sie wird nicht in eine Anwendungserlaubnis umgedeutet. Die spätere Speicherung braucht einen eigenen kontrollierten Zielweg einschließlich sinnvoller Transaktion und Wiederholungsentscheidung. Diese Zuständigkeit wird nicht durch einen Dateihash ersetzt und auch nicht als bereits ausgeführter Kundendatenimport ausgegeben.

KI nur dort ergänzen, wo sie eine konkrete Lücke schließt

Bei wechselnden freien Beschreibungen kann ein Modell helfen, mögliche Felder oder eine Dokumentklasse vorzuschlagen. Für die sechs eindeutigen Beschriftungen unseres Beispiels ist dafür kein Modellaufruf nötig. Das spart zusätzliche Abhängigkeit und hält den Nachweis einfach. Die Entscheidung folgt dem Inhalt: Eine feste Zeile und eine semantisch unklare Freitextbeschreibung sind unterschiedliche Aufgaben.

Ein KI-Kandidat benötigt dieselben belegbaren Quellstellen und zulässigen Zielwerte. Eine allgemeine Zuversichtszahl ersetzt keine eindeutige Projektkennung und keinen geklärten Widerspruch. Für nicht gefundene Werte sollte das Modell einen erkennbaren fehlenden Zustand liefern dürfen. Ein immer vollständig ausgefülltes JSON kann sonst nur äußerlich gut aussehen, während es unbelegte Inhalte als Tatsachen in den nächsten Schritt schiebt.

Die Ausführung bleibt außerhalb des Modells begrenzt. Ein Vorschlag erteilt sich nicht selbst Rechte und startet keine beliebige Folgeaktion. Das Beispiel demonstriert diese Grenze mit seiner getrennten Prüfschranke, führt aber keinen KI-Aufruf und keinen allgemeinen Prompt-Injection-Sicherheitstest aus. Eine spätere KI-Erweiterung erhält eigene repräsentative Fälle und passende Nachweise statt sich ungeprüft auf den deterministischen Briefingtest zu berufen.

Die 52 tatsächlich ausgeführten Prüfungen lesen

Die drei echten PDFs werden ausgelesen und ihre Ergebnisse festgehalten. Das eindeutige Dokument liefert sechs geprüfte Werte und bleibt trotzdem prüfpflichtig. Die widersprüchliche Variante hält zwei Statusfundstellen fest und wählt keine davon still aus. Die Bildfassung besitzt keine Textebene und liefert keine erfundenen Felder. Alle drei Dokumente wurden außerdem tatsächlich gerendert und visuell betrachtet.

Weitere Fälle prüfen Kalendergrenzen, Kennungen, Ganzzahlen, Sprachcodes, fehlende und wiederholte Angaben sowie die klare Unterscheidung zwischen nicht freigegeben, freigegeben und offen. Die Herkunft kann auch auf Seite zwei liegen und behält dann diese Seitennummer. Solche Beispiele machen die Regeln nachvollziehbarer als eine pauschale Behauptung hoher Erkennungsgenauigkeit. Eine Genauigkeitsquote wurde hier nicht gemessen.

Die Prüfschranke lehnt fehlende Zustimmung, falsche Rolle, fehlende Prüferreferenz, veränderte Quellen und nachträglich geänderte Vorschläge ab. Ein simulierter passender Prüfentscheid bereitet ein fiktives Paket vor. Insgesamt werden 52 konkrete Fälle ausgeführt. Es handelt sich weder um eine echte menschliche Freigabe noch um eine produktive Übernahme. Der Nachweis betrifft den gezeigten begrenzten Datenvertrag.

Die prüfende Oberfläche an der Entscheidung ausrichten

Eine gute Prüfansicht zeigt Quelle und Vorschlag nebeneinander. Wichtige Fundstellen sind schnell erreichbar und Widersprüche werden als solche benannt. Im Beispiel erklärt die Grafik zusätzlich, warum eine PDF-Seite nicht mit acht geplanten Projektseiten verwechselt werden darf. Solche kleinen Bedeutungsfragen sind oft wichtiger als eine besonders aufwendige Animation des Importvorgangs.

Die prüfende Person muss Werte korrigieren oder den Vorgang zurückstellen können. Eine Korrektur erzeugt einen neuen Vorschlagsstand, der passend bestätigt wird. Der ursprüngliche Fund bleibt nachvollziehbar. Eine Oberfläche, die nur zwei große Aktionen Alle übernehmen und Alles verwerfen anbietet, könnte notwendige fachliche Unterschiede verdecken. Der genaue Bedienumfang folgt der Verantwortung und dem tatsächlichen Dokumentbestand.

Der Status nach der Entscheidung muss wahr bleiben. Datenpaket vorbereitet ist etwas anderes als in der Zielanwendung gespeichert. Eine technische Störung im nächsten Schritt darf nicht durch dieselbe allgemeine Erfolgsmeldung verdeckt werden. Für den späteren Zielweg werden deshalb Abschluss, Wiederholung und Fehler gesondert geprüft. Das Parsing bleibt nur ein Teil des gesamten Verfahrens.

Mit repräsentativen Dokumenten und Gegenfällen abnehmen

Beginnen Sie mit einigen typischen echten Dokumenttypen in einer geeigneten geschützten Testumgebung. Bestimmen Sie für jeden, welche Werte und Herkunft tatsächlich erwartet werden. Ergänzen Sie fehlende Seiten, andere Reihenfolgen, doppelte Feldbezeichnungen und reine Bildfassungen. Ein Parser, der nur sein eigenes sauberes Musterblatt kennt, besitzt noch keinen Nachweis für einen vielfältigen realen Eingang.

Für unser Beispiel sind die selbst erstellten Briefings genau dieser begrenzte Startpunkt. Die nächste Übernahme eines anderen Formats braucht neue Beispiele und eine bewusste Regelentscheidung. Besonders ein unbekanntes Feld darf nicht einfach in das nächstähnliche Zielfeld geschoben werden. Der Zustand nicht zugeordnet ist oft ehrlicher und leichter zu korrigieren als eine plausibel klingende falsche Verbindung.

Dokumentieren Sie anschließend, wer die Regeln pflegt und welche Änderungen eine erneute Prüfung auslösen. Eine neue Vorlage, ein anderer Parserstand oder ein zusätzliches Zielfeld kann die bisherigen Annahmen verändern. Die konkreten Dateihashes und Prüffälle helfen dabei, die Änderung einzugrenzen. Sie ersetzen jedoch nicht die fachliche Verantwortung für die Bedeutung der übernommenen Daten.

Einen kontrollierten Gesamtweg aufbauen

Der Gesamtweg besteht aus Eingang, Erkennung, Feldvorschlag, Prüfung und begrenzter Übernahme. Für jede Stufe ist festgelegt, was sie behaupten darf und was sie an die nächste weitergibt. Der Dokumentinhalt bleibt Quelle. Der Parser liefert Kandidaten. Die zuständige Prüfung entscheidet über ein konkretes Datenpaket. Die Zielanwendung kontrolliert ihre eigenen Änderungen. Diese Trennung macht Fehler und Zuständigkeiten nachvollziehbar.

Automatisierung lohnt sich dann, wenn wiederkehrende richtige Zuordnungen Zeit sparen und unklare Fälle gezielt zur Klärung gelangen. Das Ziel ist keine möglichst große Zahl ungeprüft gefüllter Felder. Unser tatsächliches PDF-Beispiel zeigt gerade an negativen und widersprüchlichen Angaben, warum ein gut begründeter Stopp wertvoll sein kann. Ein offener Vorgang mit Beleg ist besser bearbeitbar als ein unbemerkt falscher Eintrag.

Die 52 ausgeführten Fälle liefern einen nachvollziehbaren kleinen Kern. Eine reale Umsetzung erweitert ihn um die eigenen Dokumenttypen, Berechtigungen und Zielaktionen. So werden Texterkennung und KI-Vorschläge zu nützlichen Werkzeugen innerhalb eines kontrollierten Arbeitsablaufs. Die Entscheidung über tatsächliche Änderungen bleibt dort, wo die Anwendung sie prüfen, ausführen und belegen kann.

Feldentscheidungen im Beispiel

Checkliste für kontrollierte Übernahme

• Dokumenttyp, konkrete Version und erlaubte Zielfelder bestimmen.
• Textebene, Bildinhalt und tatsächliche Layoutgrenzen unterscheiden.
• Feldbedeutung, Typ und fehlende Werte festlegen.
• Quellseite und tatsächlichen Fundtext erhalten.
• Widersprüche und Mehrfachangaben ohne stillen Gewinner behandeln.
• Dokumentanweisungen von Betriebsregeln und Berechtigungen trennen.
• Prüfung an Quell- und Vorschlagsstand binden.
• Zielaktion, Wiederholung und tatsächlichen Abschluss gesondert prüfen.

Quellen und Prüfstand

Primärquellen am 09.11.2026 geprüft. Drei eigene fiktive PDFs wurden mit pypdf 6.10.0 unter Python 3.12.14 ausgelesen und visuell geprüft. 52 tatsächliche Extraktions-, Regel- und Prüfschrankenfälle bestanden. Kein OCR-Lauf, echter Prüfentscheid oder produktiver Kundenimport.

• pypdf 6.10: Text extraction
• OWASP: Prompt Injection Prevention
• Python 3.12: datetime
• Python 3.12: re
• OWASP: Input Validation
• Python 3.12: hashlib