Zum Inhalt springen

Digitalisierung einer Notarkanzlei — Beratung & Tech Lead

Technische Leitung für ein maßgeschneidertes System zur Aktenbearbeitung in einer Notarkanzlei — Ausweis-OCR mit Regula sowie eine unabhängige Prüfung von Sicherheit, Datenschutz, Zuverlässigkeit und Wartbarkeit.

2026 – heute
Python Regula Document Reader Podman uvicorn Pillow Grafana Loki Alertmanager

Ausgangslage

Eine Notarkanzlei hatte sich ein eigenes System bauen lassen, das die Daten aus den Online-Checklisten der Mandantschaft weitgehend automatisch in die Kanzleisoftware überträgt — Akten anlegen, Beteiligte erfassen, Ausweisdokumente ablegen, Fristen vorbereiten. Entwickelt hatte es eine einzelne Person, und es war bereits in einer frühen Betriebsphase im Einsatz.

Zwei Dinge waren nötig. Ausweisdokumente — Pässe und Personalausweise — mussten so zuverlässig gelesen werden, dass man ihnen in einer Akte vertrauen kann. Und die Kanzlei wünschte sich eine unabhängige Einschätzung, ob ein System, das inzwischen vertrauliche Mandantendaten verarbeitet, sicher, korrekt und wartbar genug ist, um es weiterzubetreiben und später zu übergeben.

Ich kam als Berater und technischer Leiter dazu. Die tägliche Umsetzung liegt beim Entwickler; ich gebe die Richtung vor, prüfe die Arbeit und übernehme die Teile, die einen zweiten Blick brauchen.

Umsetzung

Ausweisdokumente lesen. Ich habe Regula Document Reader als OCR-Grundlage eingeführt und den Spike gebaut, aus dem der produktive Integrationsweg wurde. Eingaben aus HEIC, JPEG und PDF werden vereinheitlicht, und eine Bildqualitätsprüfung fängt unbrauchbare Scans ab, bevor sie in die Extraktion gelangen — ein verwackeltes Foto soll früh und sichtbar scheitern, statt still einen plausibel aussehenden falschen Namen zu liefern.

Auf Unsicherheit hin entworfen. Die maschinenlesbare Zone eines Ausweises führt nur für einen Teil der Felder Prüfziffern mit. Ein Lesegerät kann bestimmte Werte also rechnerisch bestätigen und andere lediglich übernehmen. Genau um diese Unterscheidung herum habe ich die Extraktionslogik gebaut: Nicht überprüfbare Felder werden als nicht bestätigt gekennzeichnet statt als gesichert ausgegeben, Vergleiche, die gar nicht stattfinden konnten, werden konservativ markiert, und Ergebnisse aus mehreren Quellen werden je Quelle zusammengeführt statt gegenseitig überschrieben. Bei Dokumenten, die in einer Akte landen, ist eine gemeldete Unsicherheit nützlicher als ein gut geratener Wert.

Die Prüfung. Eine strukturierte Bewertung entlang von vier Dimensionen — Datenrichtigkeit, Sicherheit und Zugriff, Zuverlässigkeit sowie Tempo und Wartbarkeit — in Form eines schriftlichen Berichts. Jede Quelldatei, jede Nachricht und jedes Transkript wurde in einer Checkliste je Objekt über das Hauptrepository und alle Submodule nachgehalten, sodass die Abdeckung belegbar und nicht bloß behauptet ist. Interne Arbeitsbelege blieben vom Bericht für die Kanzlei getrennt; alles, was sich beim genauen Hinsehen als unkritisch oder bereits behoben herausstellte, kam gar nicht erst hinein.

Technische Schwerpunkte

Für zwei Zielgruppen gleichzeitig schreiben. Der Bericht musste die Kanzleileitung erreichen — fachkundig im Notariat, nicht in Softwaretechnik — und zugleich den Entwickler, der die Anpassungen umsetzt. Statt zu vereinfachen und dabei an Genauigkeit zu verlieren, hat jeder Punkt zwei Ebenen: eine allgemeinverständliche Erklärung mit einem konkreten Beispiel, was das für eine Mandantenakte bedeutet, und einen klar gekennzeichneten technischen Abschnitt mit Mechanismus und Lösungsansatz. Ein Dokument, zwei Einstiege, kein Übersetzungsschritt dazwischen.

In Folgen denken statt in Schweregraden. Befunde wurden danach eingeordnet, was sie für eine Akte, für die Haftung und für die Arbeitszeit im Büro bedeuten — also in den Kategorien, in denen die Kanzlei tatsächlich entscheidet — und nicht als abstrakte Schweregrad-Skala.

Ergebnis

Die Kanzlei erhielt eine entscheidungsreife Einschätzung: was bereits solide funktioniert, was Aufmerksamkeit verdient und ein Vorgehen in Phasen, das sich auch ohne Softwarehintergrund umsetzen lässt. Die OCR-Integration folgt dem Grundsatz, dass ein System, das Ausweisdokumente verarbeitet, sichtbar machen sollte, was es nicht bestätigen kann — die richtige Haltung sowohl gegenüber der beruflichen Verschwiegenheitspflicht als auch gegenüber den DSGVO-Regeln zu besonderen Kategorien personenbezogener Daten.

Aus Rücksicht auf die Verschwiegenheitspflicht der Kanzlei werden hier keine konkreten Befunde, Systeme oder identifizierenden Angaben genannt.

Highlights

  • Technische Leitung und Code-Review für den umsetzenden Entwickler
  • Regula-OCR-Integration für Pässe und Personalausweise
  • Extraktionslogik, die Ungeprüftes kennzeichnet statt zu raten
  • Unabhängige Prüfung von Sicherheit, Datenschutz und Wartbarkeit
  • Belegbare Abdeckung durch Review-Tracking je Objekt
  • Befunde für Leitung und Entwicklung in einem Dokument