Brauche ich einen DPA mit pdftxt.de?

Nein. Ein Auftragsverarbeitungsvertrag (DPA) nach Art. 28 DSGVO ist nur erforderlich, wenn ein Anbieter personenbezogene Daten im Auftrag des Verantwortlichen verarbeitet. Bei client-only Tools wie pdftxt.de bekommt der Anbieter keine Datei-Inhalte zu Gesicht, die Verarbeitung passiert ausschließlich im Browser. Es gibt also keine Auftragsverarbeitung im Sinne der DSGVO und entsprechend keinen DPA-Bedarf.

Was ist mit dem Tessdata-CDN?

Tesseract.js lädt die Sprachmodelle vom Tessdata-CDN (tessdata.projectnaptha.com bzw. cdn.jsdelivr.net). Das ist ein statisches Asset-Load wie das Laden einer JavaScript-Bibliothek von einem CDN. Der CDN sieht ausschließlich, dass eine Modell-Datei abgerufen wurde, nicht aber den PDF-Inhalt. Aus DSGVO-Perspektive ist das ein normaler Asset-Request, vergleichbar mit dem Laden einer Schrift von Google Fonts (dort gibt es Diskussionen wegen IP-Adressen-Uebermittlung, hier ist die Lage ähnlich).

Welche Rechtsgrundlage greift für den Webseiten-Betrieb?

Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse). pdftxt.de hat ein berechtigtes Interesse am Betrieb der Website (Server-Logs, IP-Adresse beim Aufruf). Das ist die Standard-Rechtsgrundlage für den allgemeinen Webseiten-Betrieb. Anders als bei Cloud-Convertern greift NICHT Art. 6 lit. b (Vertragsanbahnung), weil kein Konvertierungs-Service serverseitig erbracht wird.

Was sage ich meiner Datenschutzbehörde?

Wer pdftxt.de für berufliche Use-Cases nutzt (Anwaltskanzlei, Arztpraxis, Behörde), kann der Datenschutzbehörde plausibel darstellen: Datei wird nicht übertragen, Verarbeitung erfolgt ausschließlich im Browser, Tessdata-CDN bekommt nur Asset-Requests ohne Datei-Inhalt. Im Verzeichnis der Verarbeitungstätigkeiten kann pdftxt.de als Tool eingetragen werden mit der Anmerkung client-only, kein Datentransfer zum Anbieter.

Was ist mit besonders sensiblen Daten (Art. 9 DSGVO)?

Gesundheitsdaten, religioese Ueberzeugungen, sexülle Orientierung sind nach Art. 9 DSGVO besonders schützwert. Die Verarbeitung solcher Daten braucht in der Regel eine explizite Einwilligung oder eine spezielle gesetzliche Grundlage. Aber: bei client-only OCR findet aus DSGVO-Perspektive keine Verarbeitung durch den Tool-Anbieter statt, weil keine Daten zum Anbieter gelangen. Der Nutzer selbst verarbeitet die Daten, und das mit der Rechtsgrundlage, die in seinem Kontext gilt (Arzt-Patient-Vertrag, Anwalt-Mandant-Verschwiegenheit, etc.).

DSGVO bei client-only OCR: Art. 6 lit. f und kein DPA

DSGVO: was ist Verarbeitung?

Die Datenschutz-Grundverordnung (DSGVO, EU 2016/679) regelt die Verarbeitung personenbezogener Daten. Verarbeitung ist breit definiert (Art. 4 Nr. 2 DSGVO): jeder Vorgang im Zusammenhang mit personenbezogenen Daten, also Erheben, Speichern, Verändern, Uebermitteln, Löschen, etc.

Wenn ein PDF einen Namen, eine Adresse, eine Steuernummer oder andere personenbezogene Daten enthält, ist jede technische Operation an dem PDF eine Verarbeitung im DSGVO-Sinne. Das gilt für PDFs mit Verträgen (Namen der Vertragsparteien), Arztbriefen (Patientennamen, Diagnosen), Steuerbescheiden (Steuernummern), Gehaltsabrechnungen, etc.

Die entscheidende Frage bei einem Tool wie pdftxt.de ist: WER verarbeitet hier was? Es gibt zwei mögliche Konstellationen:

Server-OCR: Der Nutzer schickt das PDF zum Anbieter, der Anbieter verarbeitet (OCR) und schickt das Ergebnis zurück. Hier verarbeitet der Anbieter personenbezogene Daten im Auftrag des Nutzers. Das ist eine Auftragsverarbeitung nach Art. 28 DSGVO, mit allen Pflichten: DPA, Datenschutz-Folgenabschätzung, ggf. Audit-Rechte.
Client-only OCR: Der Nutzer ladet das PDF im Browser, die OCR-Engine (Tesseract.js als WebAssembly) verarbeitet die Datei lokal. Der Anbieter (pdftxt.de) sieht zu keinem Zeitpunkt den Datei-Inhalt. Hier verarbeitet der Anbieter keine personenbezogenen Daten aus dem PDF, also gibt es auch keine Auftragsverarbeitung.

Diese Unterscheidung ist DSGVO-rechtlich grundlegend. Sie definiert, ob ein DPA nötig ist und welche Pflichten der Anbieter hat.

pdftxt.de: client-only, also keine Auftragsverarbeitung

pdftxt.de ist ein client-only Tool. Konkret:

Das PDF wird im Browser des Nutzers per Drag-and-Drop in die App geladen.
PDF.js (Mozilla) parst das PDF in einem Web-Worker, der Worker läuft im Browser-Tab.
Bei OCR-Bedarf lädt Tesseract.js die Sprachmodelle vom Tessdata-CDN nach (statisches Asset-Load, ca. 10 MB pro Sprache).
Tesseract.js verarbeitet die PDF-Seite-Bilder in einem WASM-Worker, ebenfalls im Browser-Tab.
Das Ergebnis ist ein TXT-String, der im Browser-Speicher bleibt und über URL.createObjectURL als Download angeboten wird.

In keinem dieser Schritte verlässt die PDF-Datei oder ihr Inhalt den Browser des Nutzers. Das ist im Netzwerk-Tab der Browser-Entwicklertools nachprüfbar: beim Konvertieren entsteht kein ausgehender Request mit dem Datei-Inhalt.

Aus DSGVO-Perspektive bedeutet das:

pdftxt.de verarbeitet keine personenbezogenen Daten aus dem PDF: Es gibt keinen Datentransfer zum Anbieter. Was im Browser des Nutzers passiert, ist Nutzer-eigene Verarbeitung, nicht Anbieter-Verarbeitung.
Keine Auftragsverarbeitung nach Art. 28 DSGVO: Auftragsverarbeitung setzt voraus, dass der Auftragnehmer die Daten erhält. Bei client-only ist das nicht der Fall.
Kein DPA erforderlich: Wenn keine Auftragsverarbeitung vorliegt, braucht es keinen DPA.

Das ist die rechtliche Konsequenz der Client-only-Architektur. Sie macht pdftxt.de für datenschutz-kritische Berufsgruppen geeignet, ohne dass diese einen Vertrag mit AKARA Solutions abschliessen müssen.

Was pdftxt.de DOCH verarbeitet

pdftxt.de ist eine Website, also gibt es einen Webserver, der die Seite ausliefert. Beim Aufruf entstehen Server-Logs (IP-Adresse, Zeitstempel, aufgerufene URL, HTTP-Status, User-Agent). Diese Daten sind aus Sicht des DSGVO personenbezogene Daten (Erw. 30 DSGVO: IP-Adressen können personenbezogen sein).

Die Verarbeitung dieser Server-Logs erfolgt durch Netlify (Hosting-Anbieter) im Auftrag von AKARA Solutions. Hier liegt eine echte Auftragsverarbeitung vor, für die ein DPA mit Netlify abgeschlossen ist (siehe Datenschutzerklärung Abschnitt 2).

Rechtsgrundlage für den Webseiten-Betrieb: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse am Betrieb der Website). Das ist die Standard-Rechtsgrundlage für Webseiten und nicht spezifisch für Conversion-Tools.

Wichtig: Server-Logs enthalten keine Datei-Inhalte, kein extrahiertes TXT, keine Datei-Namen. Sie enthalten nur Zugriffs-Metadaten der Webseite selbst. Eine Verknüpfung zwischen einem Server-Log und einer konkreten PDF-Konvertierung ist technisch ausgeschlossen, weil keine Konvertierungs-Anfrage am Server ankommt.

Tessdata-CDN: statische Asset-Loads

Eine Detail-Frage: Tesseract.js lädt die OCR-Sprachmodelle vom Tessdata-CDN (tessdata.projectnaptha.com, alternativ cdn.jsdelivr.net). Dabei wird eine HTTP-Anfrage an einen Drittanbieter-Server gestellt. Ist das DSGVO-relevant?

Antwort: ja, aber im Umfang vergleichbar mit dem Laden einer Schriftart von Google Fonts. Der CDN sieht:

Die IP-Adresse des Nutzers
Die User-Agent-Information
Den Dateinamen des angeforderten Sprachmodells (z.B. deu.traineddata)

Der CDN sieht NICHT:

Den PDF-Inhalt
Den extrahierten Text
Ob OCR überhaupt erfolgreich war

Aus DSGVO-Perspektive ist das ein normaler Asset-Request mit einer minimalen IP-Adressen-Uebermittlung. Vergleichbar mit dem Laden eines Bootstrap-CSS von einem CDN oder einer Schriftart von Google Fonts. Die Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an einer funktionsfähigen OCR-Engine).

Die Datenschutzerklärung von pdftxt.de erwähnt diesen CDN-Load transparent (siehe Abschnitt 3, “Externe Asset-Loads bei aktiver OCR”). Wer das vermeiden will, kann die OCR-Funktion einfach nicht aktivieren, dann findet kein CDN-Load statt.

Konsequenz für datenschutz-kritische Berufsgruppen

<rect class="box-bad" x="40" y="60" width="300" height="180"/>
<text class="label" x="190" y="84">Server-OCR (Cloud-Convert)</text>
<text class="small" x="190" y="106">Datei wird hochgeladen</text>
<text class="small" x="190" y="124">Anbieter verarbeitet personenbezogene Daten</text>
<text class="small" x="190" y="142">Auftragsverarbeitung nach Art. 28 DSGVO</text>
<text class="small" x="190" y="160">DPA erforderlich</text>
<text class="small" x="190" y="178">Verzeichnis der Verarbeitungstätigkeiten</text>
<text class="small" x="190" y="196">Prüfung auf US-Standort (Schrems-II)</text>
<text class="small" x="190" y="214">Eventüll DSFA nötig</text>

<rect class="box-good" x="380" y="60" width="300" height="180"/>
<text class="label" x="530" y="84">Client-OCR (pdftxt.de)</text>
<text class="small" x="530" y="106">Datei bleibt im Browser</text>
<text class="small" x="530" y="124">Anbieter sieht keine Datei-Inhalte</text>
<text class="small" x="530" y="142">Keine Auftragsverarbeitung</text>
<text class="small" x="530" y="160">Kein DPA nötig</text>
<text class="small" x="530" y="178">Tool im VVT nur als "client-only" eintragen</text>
<text class="small" x="530" y="196">Hosting-DPA mit Netlify reicht</text>
<text class="small" x="530" y="214">DSFA in der Regel nicht erforderlich</text>

DSGVO-Pflichten je nach Tool-Architektur. Server-OCR braucht den vollen DPA-Apparat, Client-OCR ist deutlich entspannter, weil keine Daten zum Anbieter gelangen.

Für datenschutz-kritische Berufsgruppen ist diese Architektur ein praktischer Vorteil:

Anwaltskanzleien müssen die Mandatsverschwiegenheit (§ 43a BRAO) wahren. Eine Cloud-OCR würde Mandantendaten an einen Drittanbieter geben, was ohne explizite Mandanten-Einwilligung problematisch ist. Client-only OCR verlässt das Gerät nicht, also kein Datenfluss zu Dritten.

Arztpraxen unterliegen der ärztlichen Schweigepflicht (§ 203 StGB) und der DSGVO Art. 9 (besondere Kategorien). Patientendaten in Cloud-OCR sind heikel und brauchen sehr genaue Vertragsgestaltung. Client-only OCR löst das technisch: keine Patientendaten werden übertragen.

Behörden unterliegen oft besonderen Verschwiegenheitspflichten (§ 30 AO für Steuerdaten, § 35 SGB I für Sozialdaten). Hier ist Cloud-OCR praktisch ausgeschlossen, weil eine Datenweitergabe an Dritte gesondert legitimiert sein müsste. Client-only OCR ist die saubere technische Lösung.

Hochschulen und Forschung können wissenschaftliche Texte (mit ggf. personenbezogenen Daten in Studien) extrahieren, ohne dass die Texte auf Drittanbieter-Server gelangen. Bei TDM-Projekten (Text and Data Mining) ist das ein wichtiger Vorteil.

Umami und Tracking: was wird gemessen?

pdftxt.de nutzt optional Umami Analytics. Umami ist ein datenschutzfreundliches, cookiefreies Analyse-Tool, das keine personenbezogenen Daten erhebt und keine IP-Adressen speichert. Das ist DSGVO-konform ohne Einwilligungs-Banner, weil keine personenbezogenen Daten verarbeitet werden.

Wichtig: pdftxt.de hat keinen Google AdSense, keine Tracking-Cookies, keine Werbe-Pixel. Die einzige Datenerhebung sind die Server-Logs (Hosting-Standard) und die optionale Umami-Statistik (anonymisiert). Beides ist auf einem Niveau, das für Datenschutzbehörden unproblematisch ist.

Was bleibt von der DSGVO-Analyse

Client-only Tools wie pdftxt.de sind DSGVO-rechtlich einfacher als Cloud-Tools. Der Grund ist konzeptionell simpel: was nicht übertragen wird, kann auch nicht problematisch verarbeitet werden. Diese Architektur ist nicht zufällig gewählt, sondern bewusst, weil sie für datenschutz-kritische Berufsgruppen den Mehrwert bietet, ein PDF-Konvertierungs-Tool nutzen zu können, ohne eine DPA-Beziehung mit dem Anbieter aufzubauen.

Was bleibt: der Nutzer behält die volle Kontrolle über seine Daten. Der Anbieter (AKARA Solutions) verarbeitet nur Hosting-Metadaten (Server-Logs über Netlify mit bestehendem DPA), keine Datei-Inhalte. Das ist die Standard-Verarbeitungs-Konstellation für eine Webseite, nicht für ein Verarbeitungs-Tool.

Wer pdftxt.de für berufliche Use-Cases einsetzt, kann das in seinem Verzeichnis der Verarbeitungstätigkeiten kurz dokumentieren: Tool client-only, kein Datentransfer zum Anbieter, Hosting über Netlify (DPA bei AKARA Solutions verfügbar). Das ist die saubere DSGVO-Erfüllung, ohne dass weitere Verträge mit dem Tool-Anbieter notwendig wären.