Projekt2 Min. Lesezeit
EigenprojektLokale PII-Schwärzung für SAP-Freitext
Eigenständiges Entwicklungsprojekt ohne Kundenauftrag. Die Kennzahlen stammen aus einer Evaluation auf 16 zurückgehaltenen Dokumenten; eine produktive SAP-Integration ist damit nicht nachgewiesen.
Für Entscheider in 20 Sekunden
Problem
Personenbezogene Daten können in Freitext verbleiben, nachdem strukturierte Felder maskiert wurden.
Lösung
Ein lokal ausführbarer Modelladapter erkennt Entitäten und liefert strukturierte Ausgaben mit Prüfsignalen.
Geschäftswert
Technischer Nachweis aus einem kleinen Testsatz. Nutzen und verbleibender Prüfaufwand müssen für eine konkrete Pipeline evaluiert werden.
Rahmen
Eigenprojekt ohne Kundenauftrag. Ein Einsatz beginnt mit einer separat beauftragten Evaluation auf Stundenbasis.
Eigenständige Entwicklung mit begrenzter Evaluation
Ich habe dieses Modell zur Erkennung und Schwärzung personenbezogener Daten als eigenständiges Entwicklungsprojekt ohne Kundenauftrag gebaut. Es untersucht, wie ein kleines, lokal ausführbares Modell personenbezogene Daten in Freitext erkennt, die eine spaltenbasierte Maskierung übersehen kann. Das Projekt ergänzt meine Erfahrung in Modellentwicklung und Evaluation.
Der vorgesehene Einsatzfall ist eine SAP-Datenkopie von Produktion nach Test. Strukturierte Felder werden bereits deterministisch maskiert. Notizen, kundenspezifische Textfelder und extrahierter Dokumenttext brauchen eine zusätzliche Prüfung. Dieses Projekt untersucht diesen Schritt; es dokumentiert keine beim Kunden ausgelieferte Pipeline.
Was ich gebaut habe
Das Modell ist ein LoRA-Adapter auf Qwen2.5-1.5B-Instruct. Es liefert eine strukturierte Antwort mit redacted_text, entities, risk_level und needs_human_review. Eine nachgelagerte Integration kann das Format validieren und unsichere Fälle zur Prüfung weitergeben.
Das Modell zielt auf zwölf deutsche Entitätstypen, darunter Namen, Adressen, Telefonnummern und Identifikationsnummern. Der Adapter ist auf Hugging Face verfügbar. Das Training lief mit PEFT/TRL auf einer RunPod A40. Für die Inferenz ist lokale Hardware vorgesehen.
Für einen Einsatz muss geprüft werden, welche Texte zum Modell gelangen, wie übersehene Entitäten erkannt werden, wie Pseudonyme über Datensätze hinweg konsistent bleiben und was bei ungültigen Ausgaben passiert. Diese Integrationseigenschaften lassen sich aus den Modellwerten allein nicht ableiten.
Was im Experiment gemessen wurde
Das dokumentierte v1-Experiment verwendete 75 synthetische deutsche Geschäftsdokumente zum Training und 16 zurückgehaltene Dokumente zur Evaluation. Die Ergebnisse beziehen sich auf diesen kleinen Testsatz:
| Metrik | Basismodell | Feinabgestimmter Adapter |
|---|---|---|
| Entity F1 | 0,375 | 0,917 |
| JSON-Parse-Validität | 81% | 100% |
| Risk-Level Exact-Match | 0,50 | 0,94 |
Die exakte Übereinstimmung der Entscheidung zur menschlichen Prüfung blieb bei 0,69. Diese Grenze ist relevant: Das System muss zuverlässig erkennen, welche Datensätze noch eine Person prüfen muss. Der nächste Evaluationsschritt braucht vielfältigere Dokumente, konsistente Review-Labels und Tests mit repräsentativen Daten.
100% JSON-Parse-Validität bedeutet, dass alle Ausgaben in dieser Evaluation geparst werden konnten. Daraus folgt keine Garantie für künftige Ausgaben oder vollständige Erkennung personenbezogener Daten. Die Evaluation belegt weder regulatorische Konformität noch die sichere Freigabe einer Produktionsdatenkopie.
Betriebswirtschaftlicher Nutzen als zu prüfende Annahme
Eine Beispielrechnung macht den Prüfaufwand greifbar: vier Kopien jährlich × 2,5 Personentage je Kopie × 600 € pro Tag = 6.000 € manueller Prüfaufwand pro Jahr. Das ist eine Modellrechnung, keine gemessene Kundeneinsparung. Integration, Rechenleistung, laufende Evaluation und verbleibende menschliche Prüfung gehören in eine spätere Wirtschaftlichkeitsrechnung.
Bezug zu meiner heutigen Arbeit
Übertragbar sind die Erfahrung mit lokaler Modellintegration, strukturierten Ausgaben und der Evaluation von Fehlerfällen. Mein aktueller Schwerpunkt für Kunden sind Kontextschichten auf temporalen Wissensgraphen: Quellenbelege, Zugriffsrechte und autorisierte Aktionen. Die Fallstudie zur operativen Kontextschicht zeigt diese Arbeit im Kundeneinsatz. Die öffentliche Demo verwendet fiktive Datensätze.
Häufige Fragen
War das ein Kundenprojekt?
Nein. Es ist ein eigenständiges Entwicklungsprojekt ohne Kundenauftrag.
Worauf beziehen sich die Kennzahlen?
Das dokumentierte v1-Experiment: 75 synthetische Trainingsdokumente und 16 zurückgehaltene Evaluationsdokumente. Die Werte sind keine Produktionsgarantie.
Stack
- Qwen2.5-1.5B-Instruct (Basis)
- LoRA-Adapter (PEFT / TRL)
- Strukturierter JSON-Output (Pydantic-Schema)
- HuggingFace Hub (Apache 2.0)
- RunPod A40 (Training)
Nächster Schritt
Ähnliches Projekt auf dem Tisch?
Am schnellsten klärt das ein Gespräch. Termin direkt hier wählen:
Ihre Agenten antworten aus dem, was die Suche gerade findet, und oft ist das der Stand vom letzten Quartal. Ich baue die Kontextschicht, aus der sie antworten und handeln: einen temporalen Wissensgraphen, der jeden Fakt mit Quelle und Gültigkeitszeitraum hält, mit den Rechten der jeweiligen Person liest und nichts ohne Freigabe einer Person schreibt. Auf Ihrem eigenen Tenant, nach Stunden abgerechnet, Schritt für Schritt.