Ist Web Scraping für Ihr KI-Produkt legal? Was Gründer vor dem Bau abwägen sollten

Web Scraping ist nicht per se illegal, aber auch kein Freifahrtschein. Die rechtliche Angreifbarkeit eines KI-Produkts, das auf gescrapten Daten aufbaut, hängt von drei Dingen ab: ob die Daten öffentlich oder hinter einem Login liegen, ob sie personenbezogene Daten enthalten, und ob Sie sie veröffentlichen oder nur intern nutzen. Wenn Sie diese drei Punkte beim Design richtig angehen, löst sich der Großteil des Risikos auf, bevor ein Anwalt das Produkt überhaupt zu Gesicht bekommt.

Dies ist ein Leitfaden für Gründer, keine Rechtsberatung. Es geht darum, Ihnen zu helfen, die richtigen Fragen zu stellen, bevor Sie Budget in ein Feature investieren, das Compliance Sie möglicherweise zwingt, wieder herauszureißen.

Wo das Risiko tatsächlich liegt

Gründer sorgen sich tendenziell um das Falsche. Die Angst gilt einer Haftung im Stil von „Hacking“. In der Praxis landen Scraping-Streitfälle in vier Kategorien.

1. Vertragsrecht: die Nutzungsbedingungen der Website

Die meisten kommerziellen Websites verbieten automatisierten Zugriff in ihren Nutzungsbedingungen (Terms of Service). Ob diese Bedingungen Sie binden, hängt stark davon ab, ob Sie ihnen zugestimmt haben. Browse-Wrap-Bedingungen (ein Footer-Link, den niemand anklickt) sind schwächer als Click-Wrap-Bedingungen, denen Sie bei der Kontoerstellung zugestimmt haben. Die praktische Regel: Scraping hinter einem Login, den Sie selbst angelegt haben, bedeutet, dass Sie den Bedingungen zugestimmt haben, und Sie befinden sich nun im Bereich der Vertragsverletzung. Das Scrapen öffentlicher Seiten ohne Konto ist ein deutlich schwächerer Anspruch gegen Sie.

2. Gesetze gegen Computermissbrauch

Gesetze wie der US Computer Fraud and Abuse Act (18 U.S.C. § 1030) betreffen unbefugten Zugriff. Jüngere US-Rechtsprechung hat dies für öffentlich zugängliche Seiten eingeschränkt, aber das Umgehen von Authentifizierung, IP-Sperren oder technischen Blockaden bringt Sie wieder in den Anwendungsbereich. Wenn Sie eine Blockade überwinden müssen, um weiter zu scrapen, sollten Sie das als Stoppsignal behandeln, nicht als technische Herausforderung.

3. Personenbezogene Daten: DSGVO und ihre Verwandten

Diese Kategorie trifft KI-Produkte am härtesten. Wenn Sie Namen, E-Mail-Adressen, Jobtitel oder irgendetwas scrapen, das eine Person identifiziert, verarbeiten Sie personenbezogene Daten und benötigen eine Rechtsgrundlage nach Art. 6 DSGVO, zusätzlich zu Transparenz- und Löschpflichten. „Es war öffentlich“ ist für sich allein keine Rechtsgrundlage. Das Scrapen personenbezogener Daten in großem Umfang und die anschließende Anreicherung mit einem LLM verschärfen das Problem, weil Sie damit nun profilieren.

4. Urheberrecht und Datenbankrechte

Faktische Daten (Preise, Öffnungszeiten, Produktspezifikationen) sind nur schwach geschützt. Artikel, Bilder, Beschreibungen und kuratierte Datensätze sind es nicht. In der EU fügt die Datenbankrichtlinie 96/9/EG ein eigenes Recht gegen die substantielle Entnahme aus strukturierten Sammlungen hinzu. Die DSM-Richtlinie von 2019 hat eine Ausnahme für Text- und Data-Mining zur kommerziellen Nutzung geschaffen, allerdings können Rechteinhaber über maschinenlesbare Mittel widersprechen (Opt-out). Deshalb sind robots.txt und ähnliche Signale in Europa bedeutsamer, als ihr informeller Status vermuten lässt.

Die Risikoleiter, von sicher bis Stopp

Nutzen Sie dies, um Ihr Feature einzuordnen, bevor Sie es scopen:

• Geringes Risiko: öffentliche Seiten, kein Login, faktische oder unternehmensbezogene Daten, intern genutzt, um eigenen Output zu erzeugen (eine Zusammenfassung, einen Score, einen Entwurf). Rate-limitiert, respektiert robots.txt.
• Mittleres Risiko: öffentliche Seiten, aber Sie speichern und zeigen Nutzern Auszüge des Originalinhalts, oder Sie bauen einen durchsuchbaren Index des Katalogs eines Mitbewerbers.
• Hohes Risiko: personenbezogene Daten in großem Umfang (Profile, Kontaktdaten), Daten hinter irgendeiner Authentifizierung, oder die Veröffentlichung urheberrechtlich geschützter Inhalte als Ihr Produkt.
• Stopp: das Umgehen von Blockaden, das Scrapen von Gesundheits- oder Finanzdaten über Einzelpersonen, oder das Scrapen von Plattformen, deren Bedingungen Sie akzeptiert haben und die dies ausdrücklich verbieten.

Wenn Ihr Feature „mittel“ oder höher ist, ist das kein automatisches Nein. Es bedeutet, dass die rechtliche Prüfung und das Datendesign vor dem Sprint stattfinden müssen, und die Kostenschätzung in Ihrem Scraping-Pipeline-Budget sollte sie einschließen.

Design-Entscheidungen, die das Risiko senken

Rechtliches Risiko beim Scraping ist größtenteils eine Architekturentscheidung. Ein paar Muster verschieben ein Feature auf der Leiter nach unten, ohne es zu töten.

Fakten extrahieren, die Quelle verwerfen

Der größte Hebel ist die Aufbewahrung (Retention). Wenn Sie eine Seite abrufen, die paar Fakten extrahieren, die Sie benötigen, und das rohe HTML verwerfen, halten Sie fast kein urheberrechtlich geschütztes Material und einen minimalen Fußabdruck an allem Personenbezogenen. Wenn Sie vollständige Seitenkopien „für den Fall, dass wir sie später brauchen“ speichern, haben Sie eine Kopie der Website eines anderen angelegt.

Wir fahren dieses Muster in unserer eigenen Outreach-Engine. Sie ruft die öffentliche Website jedes Prospects mit einer selbst gehosteten Firecrawl-Instanz ab und übergibt den Inhalt an ein lokales LLM in einem einzigen Aufruf, der sowohl extrahiert, was das Unternehmen macht, als auch eine maßgeschneiderte E-Mail entwirft. Der rohe Seiteninhalt wird nach dem Aufruf verworfen. Wir hatten ursprünglich eine mehrstufige Kette (Crawl, Zusammenfassung, Klassifizierung, Entwurf) versucht, und die Single-Call-Version war sowohl günstiger als auch produzierte bessere E-Mails – eine nützliche Erinnerung daran, dass einfachere Pipelines oft auch bei Compliance gewinnen, weil es weniger Stellen gibt, an denen Daten verweilen.

Das Unternehmen scrapen, nicht die Menschen

Für Sales- und Marktintelligenz-Anwendungsfälle ist fast alles, was Sie benötigen, auf Unternehmensebene: was sie verkaufen, an wen sie verkaufen, welchen Tech-Stack sie bewerben, was sie zuletzt gelauncht haben. Begrenzen Sie Ihren Extraktionsprompt darauf und weisen Sie das Modell explizit an, Personennamen und Kontaktdaten zu ignorieren. In unserer Outreach-Engine fragt der Extraktionsprompt nach genau einer Sache – was das Unternehmen macht –, und das einzige personenbezogene Feld in der gesamten Pipeline ist die eine einzelne Adresse, an die die E-Mail geht. Diese eine Adresse benötigt weiterhin eine Rechtsgrundlage, aber es gibt keine Schattendatenbank von Einzelpersonen zu verteidigen, weil die Pipeline nie einen Platz dafür hatte.

Die Signale respektieren, protokollieren, dass Sie es getan haben

Beachten Sie robots.txt, identifizieren Sie Ihren Crawler mit einem echten User-Agent und einer Kontakt-URL, limitieren Sie die Rate pro Domain, und führen Sie ein Protokoll darüber, welche Seiten wann abgerufen wurden. Nichts davon ist überall strikt vorgeschrieben, aber wenn sich ein Websitebetreiber beschwert, ist „wir haben Ihre robots.txt beachtet und mit einer Anfrage alle paar Sekunden gecrawlt“ ein ganz anderes Gespräch als „wir haben Residential-Proxies rotiert, um Ihre Blockade zu umgehen“.

Offizielle Daten bevorzugen, wenn sie existieren

Viele Websites, die Sie scrapen würden, veröffentlichen auch Feeds, Sitemaps, APIs oder strukturierte Daten. Eine API mit Bedingungen, denen Sie zustimmen, ist langsamer zu integrieren, gibt Ihnen aber einen Vertrag, auf den Sie sich berufen können. Wenn ein Datenanbieter bereits lizenziert, was Sie benötigen, vergleichen Sie dessen Preis mit den Kosten, einen Scraper zu bauen und zu verteidigen. Das ist eine echte Build-vs-Buy-Entscheidung, keine ingenieurtechnische Vorliebe.

Selbst hosten oder eine Scraping-API nutzen?

Wenn gescrapte Daten ein zentraler Input für Ihr Produkt sind, ist das Self-Hosting eines Open-Source-Crawlers wie Firecrawl in der Regel die richtige Wahl. Der Grund, warum wir ihn für unsere Outreach-Engine selbst hosten, ist nicht die Kosteneffizienz, sondern dass jede Antwort auf die obigen Prüfungsfragen zu unserer eigenen wird: Das Rate Limit wird in unserer Konfiguration festgelegt, der Umgang mit robots.txt ist unser Code, die abgerufene Seite lebt für einen LLM-Aufruf im Speicher unserer Maschine und ist dann verschwunden, und nichts verlässt unsere Infrastruktur, weil auch das Modell lokal ist. Das ist eine kurze, überprüfbare Geschichte, die man einem Datenschutzbeauftragten erzählen kann. Für ein Feature mit geringem Volumen oder im Experimentierstadium bringt eine gehostete Scraping-API Sie schneller zu einem Signal, und Sie können migrieren, sobald sich das Feature bewährt hat.

In jedem Fall sollten Sie prüfen, was der Anbieter mit dem Inhalt macht, den er für Sie abruft. Manche gehosteten Dienste cachen Seiten oder nutzen sie, um ihre eigenen Systeme zu verbessern, was Ihre Aufbewahrungsrichtlinie nur so gut macht wie die ihrige. Wenn Sie versprochen haben „wir verwerfen die Rohseite nach der Extraktion“ und Ihr Anbieter eine Kopie aufbewahrt, ist dieses Versprechen bereits gebrochen.

Fragen, die vor dem Agentur-Briefing geklärt werden sollten

• Was genau extrahieren wir, und was löschen wir unmittelbar danach?
• Identifiziert irgendetwas davon eine Person? Wenn ja, was ist unsere Rechtsgrundlage und der Löschpfad?
• Werden Nutzer jemals den Originalinhalt sehen, oder nur unseren abgeleiteten Output?
• Liegt irgendetwas hinter einem Login oder einer Blockade, die wir umgehen müssten?
• In welchen Rechtsordnungen befinden sich die Websites und unsere Nutzer?
• Gibt es eine API oder eine lizenzierte Quelle, die das überflüssig macht?

Bringen Sie Antworten darauf zu Ihrem ersten Scoping-Gespräch mit, und die Schätzung, die Sie zurückbekommen, wird weit genauer sein. Wenn das Feature Outreach betrifft, lesen Sie auch unsere Notizen zu Cold-Email-Zustellbarkeit, denn ein technisch sauberer Scraper gepaart mit einer spammigen Sendepipeline endet trotzdem schlecht.

Die Kurzfassung

Das Scrapen öffentlicher, faktischer, unternehmensbezogener Daten und deren Umwandlung in eigenen Output ist ein gut etablierter, vertretbarer Weg. Das Scrapen von Menschen, das Scrapen hinter Logins oder das Veröffentlichen von Gescraptem sind die Stellen, an denen Produkte zurückgezogen werden. Entscheiden Sie, auf welcher Seite dieser Linie Ihr Feature liegt, bevor Sie bauen, gestalten Sie die Pipeline so, dass sie so wenig wie möglich behält, und behandeln Sie Blockaden als Stoppschild.

Wenn Sie ein KI-Produkt erwägen, das von externen Webdaten abhängt, und eine zweite Meinung zur Architektur und zur Risikoleiter möchten, lassen Sie uns sprechen.