EDPB-Richtlinien zu Web-Scraping: Gezielte Scraper gewinnen

Der EDSA hat gerade eine Spezifikation für Scraper verfasst

Europas Datenschutzbehörden haben viel über KI-Modelle gesagt. Bis zu diesem Sommer erklärte nichts davon einem Entwickler, was ein Scraper tun sollte, bevor er die erste Seite abruft.

Guidelines 03/2026 on web scraping in the context of generative AI haben das geändert. Der Europäische Datenschutzausschuss hat den Entwurf am 7. Juli 2026 angenommen, und seine öffentliche Konsultation endet am 30. Oktober 2026. Auf dem Papier ist der Geltungsbereich eng: private Unternehmen, die personenbezogene Daten scrapen, um generative KI zu trainieren oder zu optimieren. In der Praxis ist es die detaillierteste Beschreibung, die eine Regulierungsbehörde je dazu veröffentlicht hat, wie ein vertretbarer Scraping-Job aufgebaut ist, von den Kriterien, die du vor dem ersten Request definierst, bis zum Zeitstempel des letzten Datensatzes.

Unsere Einschätzung, nachdem wir alle 23 Seiten durchgearbeitet haben: Dem Entwurf ist egal, welche Tools du nutzt. Wichtig ist, ob du sagen kannst, was du gesammelt hast, woher und wann. Scraper, die das mit einer einzigen Abfrage beantworten können, werden kein Problem haben. Bei offenen Crawls wird fast jeder Absatz Schwierigkeiten machen.

(Haftungsausschluss: Dies ist keine Rechtsberatung. Erstens beziehen wir uns auf einen Entwurf, und wir sind Entwickler, die ihn im Hinblick auf seine Bedeutung für den Code lesen.)

Gezielt oder ungezieht ist die entscheidende Grenze

Absatz 8 unterteilt Scraping in zwei Arten danach, wie spezifisch und restriktiv die Erfassung ist, "und nicht nach den verwendeten technischen Werkzeugen". Gezieltes Scraping folgt Erfassungskriterien: einer Domain, einer Sprache, einem Thema. Ungezähltes Scraping ist ein Crawler, der jedem Link folgt, den er findet. Die Sorge des Ausschusses ist konkret: Wenn die Warteschlange wächst, hat der Verantwortliche "nur begrenzte Kenntnis darüber, welche personenbezogenen Daten erhoben und verarbeitet werden".

Diese Trennung zieht sich durch den Rest des Textes. Datenminimierung verlangt von dir, vor Beginn der Erfassung "präzise Erfassungskriterien zu definieren" und einen "Datenkartierungs- und Inventarisierungsprozess" durchzuführen (Absatz 37). Die Erforderlichkeitsprüfung im Rahmen des berechtigten Interesses besagt, dass die Eingrenzung der Kriterien, "anstatt einen großen Teil des Internets zu scrapen", möglicherweise genau das ist, was die Verarbeitung überhaupt erst erforderlich macht (Absatz 52). Transparenz verlangt eine veröffentlichte Liste von Quellen, idealerweise mit Domainnamen, URLs und Erfassungsdaten (Absätze 30 und 31).

Ein Preis-Tracker mit einer festen Liste von Produktseiten auf einem Dutzend Handels-Domains kann jedes einzelne dieser Artefakte aus seiner Konfigurationsdatei erzeugen. Ein Breadth-First-Crawl kann das nicht. Die Kritik von Privacy World am Entwurf bringt das Spannungsfeld gut auf den Punkt: Die Pflichten sind für einen Verantwortlichen geschrieben, der weiß, was er erfasst, direkt nachdem der Ausschuss einräumt, dass ein ungezielter Crawl personenbezogene Daten enthalten kann, die er nicht inventarisieren kann.

Was das bedeutet: Wenn du Daten scrapest, die Personen betreffen (Bewertungen mit Nutzernamen, Inserate mit Namen und Telefonnummer eines Maklers, Foren-Threads), sind deine Kriterien zur Datenerfassung ab sofort ein Compliance-Artefakt. Behalte sie in der Versionsverwaltung direkt neben dem Scraper, nicht im Kopf einzelner Personen.

Ein „Nein“ der Website wiegt jetzt gegen dich

Dieser Teil wird die meisten Pipelines verändern. Der Entwurf listet die technischen Maßnahmen auf, die den Widerspruch einer Website gegen Scraping klar belegen: robots.txt, ai.txt, „Roboter-Authentifizierung zur Anzeige von Inhalten“ sowie Prüfungen, die „eine Handlung verlangen, die nur von einem Menschen ausgeführt werden kann“ (Absatz 37). Für Trainingsdaten lautet die Empfehlung, solche Websites auszuschließen.

Dieselben Signale tauchen in der Interessenabwägung wieder auf. Wenn Nutzer wissen, dass eine Website solche Maßnahmen nutzt, und sie trotzdem gescrapet wird, können sie diese Verarbeitung laut Entwurf weniger erwarten (Absatz 64). Beispiel 5 macht es deutlich: Schließt eine Plattform Crawler per robots.txt aus, nutzt Human-only-Checks und untersagt KI-Training explizit, können Nutzer „vernünftigerweise nicht erwarten“, dass Dritte ihre Daten für diesen Zweck scrapen. Der Umkehrschluss gilt jedoch nicht: Eine fehlende robots.txt ist keine Einwilligung (Absatz 45).

Frankreichs CNIL war schneller. Ihr Themenblatt zu berechtigtem Interesse und Web Scraping, erstmals veröffentlicht im Juni 2025, besagt: Die Verarbeitung „kann nicht im Rahmen der vernünftigen Erwartungen der betroffenen Personen liegen“, wenn der Verantwortliche Websites nicht ausschließt, die per robots.txt oder Human-only-Check widersprechen.

Zwei weniger offensichtliche Punkte finden sich unter den Abhilfemaßnahmen (Absatz 66c). Einer schließt personenbezogene Daten aus, die erst nach einem Login sichtbar sind. Der andere betrifft Websites, die an den User-Agent eines Scrapers andere Inhalte liefern als an einen normalen Browser, „insbesondere dann, wenn der Scraping-Dienst mehr Daten erhält“, als ein Mensch sehen würde. Wenn dein Scraper eine umfangreichere interne API ausliest, als die Seite selbst darstellt, ist genau dieser Fall gemeint.

Wir haben die maschinenlesbare Seite dieses Themas (Erweiterungen für robots.txt, signierte Agents, Content-Signale) in Search, Agent, Training: The Web's New Bot Rules analysiert, und Publisher, die lieber kassieren als ablehnen, in Pay-Per-Crawl Is Splitting the Web in Two betrachtet. Der EDPB-Entwurf ist das erste Mal, dass eine Regulierungsbehörde solche Signale als Beleg für die Erwartungshaltung der Nutzer wertet.

Was das bedeutet: Protokolliere den Status von robots.txt (und ai.txt, falls vorhanden) pro Domain direkt beim Crawlen zusammen mit den Daten. Wenn in einem Jahr jemand fragt, warum eine Quelle im Trainingsdatensatz gelandet ist, zählt „an dem Tag war es erlaubt“ nur dann als Antwort, wenn du es schriftlich festgehalten hast.

Der Scraper kann der Auftragsverarbeiter sein

Abschnitt 3.2.1 ist kurz und wird leicht übersehen. Das sollte er nicht, besonders wenn du Scraper für Kunden entwickelst. Wenn du einen Trainingsdatensatz im Auftrag des Entwicklers "gemäß seinen dokumentierten Weisungen" erstellst, bist du möglicherweise Auftragsverarbeiter und der Entwickler Verantwortlicher (Absatz 18). Wenn du und der Kunde die Kriterien für die Erfassung gemeinsam festlegen, seid ihr möglicherweise gemeinsam Verantwortliche (Absatz 20, Beispiel 1). Wenn du einen Datensatz eigenständig gescrapt hast und jemand anderes ihn weiterverwendet, haftet jeder für seine eigene Verarbeitung (Absatz 19).

Brian Hengesbaughs IAPP-Kolumne über den Entwurf bringt den kommerziellen Aspekt auf den Punkt. Wenn ein Vertrag den Dienstleister als Auftragsverarbeiter benennt, trägt der Kunde den in den Leitlinien beschriebenen Compliance-Aufwand, und die eigenen direkten Pflichten des Dienstleisters "sind möglicherweise enger gefasst und weniger beruhigend als zuvor gedacht". Das gilt in beide Richtungen. Ein Kunde kann die Compliance nicht einfach an den Freelancer abwälzen, der den Scraper geschrieben hat. Und ein Freelancer, der die Quellenliste spontan improvisiert, wird am Ende vielleicht unbeabsichtigt zum Verantwortlichen.

Was Datenteams jetzt ändern sollten

Die meisten kommerziellen Scraping-Projekte sind davon nicht betroffen. Preise, Lagerbestände, Produktspezifikationen und Fahrpläne sind in der Regel keine personenbezogenen Daten, daher greift die DSGVO hier nicht. Der Entwurf stellt klar, dass sie bei einem "gemischten" Datensatz für den personenbezogenen Teil gilt (Absatz 13). Ein Angebot mit dem Namen eines Verkäufers oder eine Bewertung mit einem Nutzernamen fällt also genau in diesen Geltungsbereich.

Für Jobs, die personenbezogene Daten erfassen, bedeuten die Anforderungen des Entwurfs Folgendes für deine Pipeline:

Zwei dieser Zeilen verdienen mehr als eine Tabellenzelle.

Filtere direkt beim Parsen, nicht in einem Bereinigungslauf Wochen später. Absatz 38 nennt reguläre Ausdrücke für Formate wie Sozialversicherungs- und Telefonnummern, die direkt während der Erfassung angewendet werden. Daten, die du nie gespeichert hast, musst du auch nie rechtfertigen. Absatz 60 erklärt unmissverständlich, warum das für KI wichtig ist: Sobald ein Modell trainiert ist, können personenbezogene Daten daraus "nicht ohne Weiteres gelöscht werden".

Speichere die Quell-URL und die Abrufzeit bei jedem Datensatz. Absatz 42 fordert Zeitstempel aus Gründen der Genauigkeit, aber dieselben zwei Felder beantworten auch jede spätere Frage zur Herkunft eines Datums. Die Vorgaben für Trainingsdaten wurden durch den AI Act ohnehin schon strenger (wir haben im April darüber berichtet), und sie verlangen immer wieder die Antwort auf genau diese Frage.

Wenn du für Kunden entwickelst, musst du die Vorgaben schriftlich festhalten: Quellen, Felder, Ausschlüsse. Laut Entwurf machen dich erst dokumentierte Weisungen zum Auftragsverarbeiter statt zum gemeinsam Verantwortlichen. Eine einseitige Spezifikation verhindert spätere Diskussionen über Rollen.

Was nach dem 30. Oktober passiert

Der endgültige Text wird sich noch ändern, und die größere Verschiebung dürfte eher aus Brüssel als vom Ausschuss kommen. Am 21. Oktober 2026 hat der Rat seine Verhandlungsposition zum Digital Omnibus festgelegt, dem Paket zur Änderung der DSGVO. Laut dem Bericht der IAPP über das Mandat ergänzten die Mitgliedstaaten "Klarstellungen zur Rechtsgrundlage für die Verarbeitung personenbezogener Daten und zur Notwendigkeit angemessener Sicherheitsvorkehrungen" für KI-Trainingsdaten. Als Nächstes folgen die Verhandlungen mit dem Europäischen Parlament. Unabhängig vom genauen Wortlaut wollen die Mitgliedstaaten diese Schutzmaßnahmen beibehalten, was auf eine ähnliche Interessenabwägung wie in diesem Entwurf hindeutet.

Wir gehen davon aus, dass die Unterscheidung zwischen zielgerichteter und nicht zielgerichteter Erfassung beide Prozesse übersteht, da dieser Teil des Entwurfs eher technischer als juristischer Natur ist. Eine Aufsichtsbehörde liest nicht den Code deines Crawlers. Sie kann nach deinen Kriterien für die Erfassung, deiner Quellenliste und deinen Zeitstempeln fragen. Ein Team, das diese Daten noch am selben Nachmittag vorlegen kann, hat kaum noch Diskussionsbedarf.

Die nächste Frage, die eine Datenschutzbehörde zu einem Scraper stellt, lautet also nicht: "Wie funktioniert er?", sondern: "Was sollte er erfassen?"