Ein Passfoto ist die sensibelste Datei, die die meisten Apps je erhalten. Es zeigt ein Gesicht, einen vollständigen Namen, ein Geburtsdatum und eine Dokumentnummer, und es reicht aus, um anderswo ein Konto zu eröffnen. Trotzdem wird das Bild in vielen Upload-Abläufen fünf- oder sechsmal kopiert, bevor überhaupt jemand fragt, ob es existieren muss.

Dieser Beitrag betrachtet die Frage von der technischen Seite. Er zitiert, was die DSGVO über das Aufbewahren von Daten sagt, geht die Stellen durch, an denen sich ein Passbild unbemerkt anhäuft, und beschreibt ein Muster, das wir Lesen, zurückgeben, vergessen nennen: Das Bild wird gelesen, das Ergebnis wird zurückgegeben, und vom Bild wird nichts behalten. Am Ende steht der Teil, der Ihre Aufgabe bleibt, denn manche Unternehmen sind verpflichtet, eine Kopie aufzubewahren, und ab Juli 2027 schreibt die EU das in einem neuen Gesetz ausdrücklich fest.

Dies ist der Blog von doc.cheap, einer OCR-API für Reisepässe und Ausweise, die Ausweisdokumente liest und das Ergebnis als JSON zurückgibt. Lesen Sie die Produktteile mit diesem Wissen.

Was die DSGVO tatsächlich verlangt

Die DSGVO sagt nicht „Speichern Sie nie ein Passbild“. Sie sagt etwas Nützlicheres: Behalten Sie, was Sie brauchen, so lange Sie es brauchen, und nicht länger. Art. 5 Abs. 1 der Reg. (EU) 2016/679 legt die Grundsätze fest. Zwei davon entscheiden den größten Teil des Designs.

Grundsatz Text von Art. 5 Abs. 1 (englische Fassung) Was er für ein Bild bedeutet
Datenminimierung, Buchstabe c "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed" Wenn Ihr Prozess den Namen, das Geburtsdatum und die Dokumentnummer braucht, ist das Bild selbst womöglich nicht mehr notwendig, sobald diese gelesen sind.
Speicherbegrenzung, Buchstabe e "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed" Jede Kopie braucht ein Enddatum, und „wir sind nie dazu gekommen, sie zu löschen“ ist keines.

Art. 5 Abs. 2 ergänzt die Rechenschaftspflicht: Sie müssen nachweisen können, dass Sie diese Grundsätze einhalten. Und Art. 25 Abs. 1, Datenschutz durch Technikgestaltung, verlangt "appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner", also geeignete technische und organisatorische Maßnahmen, etwa Pseudonymisierung, mit denen sich Grundsätze wie die Datenminimierung wirksam umsetzen lassen.

Zusammen gelesen machen sie aus einer rechtlichen Frage eine technische. Je weniger Kopien eines Bildes existieren, desto weniger Stellen müssen Sie beschreiben, absichern, sichern und irgendwann leeren. Eine Kopie, die nie geschrieben wurde, ist die einzige, die nichts von dieser Arbeit braucht.

Wo Passbilder landen

Die meisten Teams speichern das Bild bewusst an einer Stelle. Das Problem sind die Stellen, die niemand gewählt hat. Hier ist eine Liste, die Sie mit Ihrem eigenen Ablauf abgleichen können.

Stelle Wie das Bild dorthin gelangt
Upload-Bucket Der Client lädt zuerst in einen Object Storage hoch, und das Backend liest es von dort. Das Objekt überdauert den Request.
Request-Logs Eine Logging-Middleware schreibt Request-Bodys mit, und ein base64-Bild ist ein Request-Body.
Fehlerberichte Ein Exception-Tracker hängt die Nutzdaten des fehlgeschlagenen Requests an.
Queues und Wiederholungen Eine Job-Nachricht trägt das Bild, und eine Dead-Letter-Queue hält die fehlgeschlagenen wochenlang fest.
Backups und Snapshots Ein Datenbank- oder Disk-Snapshot von diesem Tag enthält jedes vorher geschriebene Bild, noch lange nachdem die Zeile gelöscht wurde.
Support-Tickets Ein Nutzer schickt das Foto noch einmal per E-Mail, „weil der Upload nicht geklappt hat“.
Analytics und Session Replay Ein Tool zeichnet die Seite auf, einschließlich der Vorschau der ausgewählten Datei.
Der OCR-Anbieter Der Dienst, der das Dokument liest, behält eine eigene Kopie, nach seinen eigenen Aufbewahrungsregeln.

Die letzte Zeile ist die, die Sie am wenigsten kontrollieren. Ihre eigenen Logs können Sie korrigieren. Für eine Kopie bei einem Anbieter gelten dessen Einstellungen, und Sie müssen fragen, wie sie aussehen.

Das Muster: lesen, zurückgeben, vergessen

Das Muster ist schnell erklärt. Das Bild existiert nur im Arbeitsspeicher, für die Dauer eines Requests. Was den Request verlässt, ist das Gelesene: die extrahierten Werte. Das Bild selbst verlässt ihn gar nicht.

  1. Schicken Sie das Bild direkt in die Erkennung. Kein Upload-Bucket dazwischen. Ist ein Bucket für große Dateien unvermeidlich, geben Sie dem Objekt eine Lebensdauer von Minuten und löschen Sie es, sobald der Aufruf zurückkommt.
  2. Verwenden Sie sofort, was Sie aus der Antwort brauchen. Ausschnitte wie das Foto des Inhabers gibt es nur in dieser Antwort. Wenn Ihr Ablauf ein Selfie mit dem Porträt vergleicht, tun Sie es jetzt.
  3. Behalten Sie das Gelesene, nicht das Bild. Speichern Sie die Felder, die Ihr Prozess braucht, nach Ihrer eigenen Aufbewahrungsregel. Ein Geburtsdatum und eine Dokumentnummer sind weiterhin personenbezogene Daten, also bekommen auch sie ein Enddatum.
  4. Halten Sie das Bild aus Logs und Fehlerberichten heraus. Entfernen Sie Bodys an der Systemgrenze, an einer einzigen Stelle, statt darauf zu vertrauen, dass jeder Aufrufer daran denkt.
  5. Halten Sie das Ergebnis schriftlich fest. Notieren Sie für jede Stelle in der Tabelle oben, ob das Bild sie erreichen kann und warum nicht. Diese Notiz ist die Rechenschaftspflicht, die Art. 5 Abs. 2 verlangt.

Was unsere API mit dem Bild macht

So geht doc.cheap mit derselben Frage um, wie es die Seite zu Datenaufbewahrung und Datenschutz beschreibt.

  • Das Bild wird nie gespeichert. Es liegt für die Dauer des Requests im Arbeitsspeicher, wird an die Erkennungs-Engine übergeben und ist weg, sobald die Antwort geschrieben ist. Keine Festplatte, kein Object Store und kein Log erhält es.
  • Auch die Ausschnitte werden nicht gespeichert. Der Dokumentausschnitt, das Foto des Inhabers und die Unterschrift kommen in der Antwort des Aufrufs zurück, der sie erzeugt hat. Ein Scan, der später über GET /v1/scans/{id} erneut gelesen wird, hat jeden Bild-Slot auf null.
  • Was aufbewahrt werden kann, ist das Gelesene, und nur für den Zeitraum, den Sie anfordern. Die Option retain_hours legt ihn pro Request fest, von 0 bis 8760 Stunden (ein Jahr). Ein ausdrücklich gesetzter Wert hat immer Vorrang vor der Kontoeinstellung.
  • retain_hours: 0 schreibt nichts. Keine Zeile, die sofort abläuft, sondern gar keine Zeile. Es gibt nichts aufzuräumen, nichts in einem Backup und nichts zu exportieren. Der Scan zählt trotzdem als Scan.
  • Der Kontostandard deckt den Rest ab. Nennt ein Request keinen Zeitraum, gilt die Verlaufseinstellung des Kontos selbst: 24 Stunden, 7 Tage, 1 Monat oder 1 Jahr. Neue Konten starten mit 1 Jahr, damit das Dashboard einen Verlauf zeigt. Eine kürzere Einstellung gilt auch für bereits gespeicherte Zeilen, jeweils gemessen ab ihrem eigenen Erstellungszeitpunkt.
  • Eine aufbewahrte Zeile behält ein kleines Bild: ein Vorschaubild von höchstens 96 px an der längsten Seite und höchstens 16 KiB, das im Operationsprotokoll des Dashboards angezeigt wird, damit sich eine Zeile wiedererkennen lässt. Über die API ist es nicht lesbar. Das Vorschaubild verschwindet mit der Zeile.
  • Ein einzelner Scan lässt sich vorzeitig löschen. Ein Live-Key sendet DELETE /v1/scans/{id}, das das Ergebnis, die Verlaufszeile und das Vorschaubild entfernt. Das ist endgültig.

Die Anleitung zum Steuern der Verlaufsaufbewahrung erklärt die Einstellungen Schritt für Schritt, und unsere Seite dazu, wie wir Daten verarbeiten, gibt die Zusammenfassung.

Hier ist ein Aufruf ohne Aufbewahrung in Python mit requests. Der öffentliche Sandbox-Key sk_sandbox_public steht in der Dokumentation und braucht keine Registrierung: Er gibt insgesamt 10 kostenlos erkannte Dokumente pro Adresse und höchstens 10 Requests pro Stunde. Null Aufbewahrung ist eine Einstellung Ihres eigenen Kontos und braucht deshalb Ihren Live-Key. Die öffentliche Sandbox ist kein Konto: Sie hält jeden Scan samt seinem kleinen Bild im eigenen Protokoll des Dienstes fest. Schicken Sie ihr deshalb ein Testbild, nie ein echtes Dokument.

import base64
import uuid

import requests

API = "https://api.doc.cheap/v1/scans"
KEY = "sk_sandbox_public"  # im Produktivbetrieb Ihr eigener Live-Key


def read_and_forget(path):
    with open(path, "rb") as f:
        image = base64.b64encode(f.read()).decode("ascii")
    response = requests.post(
        API,
        headers={
            "Authorization": f"Bearer {KEY}",
            "Idempotency-Key": str(uuid.uuid4()),
        },
        json={
            "image": image,
            # 0: Mit einem Live-Key wird auf API-Seite zu diesem Scan nichts festgehalten.
            # False: kein Porträtausschnitt, weil dieser Ablauf keinen nutzt.
            "options": {"retain_hours": 0, "return_portrait": False},
        },
        timeout=30,
    )
    response.raise_for_status()
    scan = response.json()
    del image  # die lokale Kopie verschwindet, sobald der Aufruf zurückkommt
    if scan["meta"]["status"] != "recognized":
        return None
    # Behalten Sie das Gelesene, das Ihr Prozess braucht, nach Ihrer eigenen Aufbewahrungsregel.
    return {
        "scan_id": scan["meta"]["id"],
        "document_number": scan["document"]["number"],
        "expiry_date": scan["document"]["expiry_date"],
        "birth_date": scan["holder"]["birth_date"],
        "mrz_status": scan["mrz"]["status"],
    }

Null Aufbewahrung hat einen Preis, den Sie kennen sollten, bevor er Sie überrascht. Normalerweise sorgt ein Idempotency-Key dafür, dass eine Wiederholung das erste Ergebnis zurückgibt. Mit retain_hours: 0 gibt es kein gespeichertes Ergebnis, das zurückgegeben werden könnte, also wird eine Wiederholung unter demselben Key 24 Stunden lang mit HTTP 409 und dem Code idempotency_replay_unavailable abgewiesen, statt doppelt beantwortet zu werden. Werten Sie diese Antwort als „der erste Aufruf ist durchgegangen“ und verwenden Sie das Ergebnis, das Sie bereits haben.

Das erneute Lesen des Scans zeigt die andere Seite des Designs. Ein Sandbox-Key liest überhaupt nichts zurück, egal welche ID. Wir haben diesen Request am 5. Oktober 2026 mit sk_sandbox_public gesendet:

curl https://api.doc.cheap/v1/scans/<SCAN_ID> \
  -H "Authorization: Bearer sk_sandbox_public"

Er kam mit HTTP 404 zurück (die Meldung ist gekürzt):

{
  "error": {
    "code": "not_found",
    "message": "No scan with id …",
    "docs_url": "https://doc.cheap/docs/errors/not_found"
  }
}

Ein Live-Key bekommt dasselbe 404 für einen Scan mit retain_hours: 0 und für jeden Scan, dessen Zeitraum abgelaufen ist. Wenn Sie Dienste in diesem Punkt vergleichen, ist der Vergleich von Reisepass-OCR-APIs ein guter Ausgangspunkt; fragen Sie jeden, wohin das Bild geht, nicht nur, was er zurückgibt.

Was Ihre Aufgabe bleibt

Lesen, zurückgeben, vergessen beseitigt die Kopien auf API-Seite. Es entscheidet nicht, was Ihr Unternehmen aufbewahren muss. Für manche Unternehmen lautet die Antwort „eine Kopie“, und das Gesetz sagt es so.

Das neue Geldwäschegesetz der EU, die Reg. (EU) 2024/1624, gilt ab dem 10. Juli 2027. Art. 90 sagt: "It shall apply from 10 July 2027, except in relation to obliged entities referred to in Article 3, points (3)(n) and (o), to which it shall apply from 10 July 2029." Das heißt: Sie gilt ab dem 10. Juli 2027, nur für die Verpflichteten aus Art. 3 Nummer 3 Buchstaben n und o erst ab dem 10. Juli 2029. Ihr Art. 77 zur Aufbewahrung von Aufzeichnungen verpflichtet Verpflichtete wie Banken und andere Finanzunternehmen, Folgendes aufzubewahren:

"a copy of the documents and information obtained in the performance of customer due diligence pursuant to Chapter III, including information obtained through electronic identification means;"

Mit anderen Worten: eine Kopie der Dokumente und Informationen aus der Sorgfaltsprüfung der Kunden, auch der Informationen, die über elektronische Identifizierungsmittel eingeholt wurden.

Art. 77 Abs. 3 legt die Dauer fest: Die Aufzeichnungen werden "retained for a period of 5 years commencing on the date of the termination of the business relationship", also fünf Jahre ab dem Ende der Geschäftsbeziehung aufbewahrt, und danach gilt "obliged entities shall delete personal data upon expiry of the five-year period", das heißt, nach den fünf Jahren müssen die personenbezogenen Daten gelöscht werden. Art. 77 Abs. 2 erlaubt unter Bedingungen "a retention of the references to such information" anstelle von Kopien, also nur die Verweise auf diese Informationen aufzubewahren.

Wenn Sie also ein Verpflichteter sind, nimmt Ihnen die Null-Aufbewahrung bei der API die Pflicht zur Aufzeichnung nicht ab. Sie ändert, wo die Aufzeichnung liegt. Ihr eigener Speicher wird zur einzigen Kopie, und der Grundsatz der Speicherbegrenzung von oben gilt weiterhin für ihn: Fünf Jahre nach dem Ende der Geschäftsbeziehung wird sie gelöscht. Die Designarbeit besteht darin, diesen Speicher bewusst anzulegen, mit einem Ort, einem Verantwortlichen, Verschlüsselung, Zugriffskontrolle und einem Löschjob, statt des zufälligen Haufens aus der Tabelle oben.

Wenn Sie kein Verpflichteter sind, stellen Sie zuerst die einfache Frage: Braucht irgendetwas in Ihrem Prozess das Bild noch, nachdem die Felder gelesen sind? Oft lautet die ehrliche Antwort nein.

Eine Checkliste

  • Jede Stelle der Tabelle „Wo Passbilder landen“ ist mit Ihrem Ablauf abgeglichen.
  • Das Bild geht direkt in die Erkennung oder durch einen Bucket mit einer Lebensdauer von Minuten.
  • Ausschnitte werden im Antwort-Handler verwendet und nirgendwo geschrieben.
  • Der OCR-Aufruf setzt seine Aufbewahrung bewusst, retain_hours: 0, wenn nichts zurückgelesen werden muss.
  • Wiederholungen behandeln die Antwort 409 idempotency_replay_unavailable.
  • Logs und Fehlerberichte entfernen Request-Bodys an einer einzigen Grenze.
  • Die Felder, die Sie behalten, haben ein Enddatum, und etwas löscht sie.
  • Wenn ein Gesetz eine Kopie verlangt, liegt sie in einem einzigen, bewusst angelegten Speicher mit eigenem Löschdatum.

Dies ist eine technische Zusammenfassung, keine Rechtsberatung. Wenn Sie eine Stelle finden, an der ein Bild durchsickern kann und die dieser Beitrag übersieht, schreiben Sie an admin@doc.cheap.

Eine Frage an Sie: Wo haben Sie zuletzt die Kopie eines Ausweisdokuments gefunden, die niemand behalten wollte? Erzählen Sie es uns unten in den Kommentaren.