KI-gestützte Webdatenextraktion (intelligentes Scraping)

Klassische Scraper brechen, sobald eine Website ihr Layout ändert, und jede Website braucht eigene Selektoren. Bei der KI-Extraktion liest ein Modell die gerenderte Seite (Text, DOM oder Screenshot) und liefert die gewünschten Felder als validiertes JSON, sodass eine Pipeline Hunderte Websites abdeckt. Typische Einsatzfelder: Preis- und Sortimentsbeobachtung, Lead- und Unternehmensdaten, Ausschreibungs- und Regulierungsbeobachtung, Forschungs- korpora. Die Haupteinschränkungen sind nicht technischer, sondern rechtlicher Art: Urheberrecht, Datenbankrechte, Nutzungsbedingungen der Seiten, robots.txt und DSGVO.

Problem & Nutzen

• Heute: Analysten kopieren Daten von Hand, oder Entwickler schreiben und pflegen Skripte je Website (Scrapy, Playwright, XPath-/CSS-Selektoren). Die Wartung ist der dominierende Kostenfaktor: Jeder Relaunch bricht einen Scraper, und Websites aus dem „Long Tail“ lohnen den Aufwand nie.
• KI-Nutzen: schemagesteuerte Extraktion („gib mir Produktname, Preis, Währung, Verfügbarkeit“), die Layoutänderungen toleriert, unstrukturierte Detailseiten bewältigt und die Ausgabe vereinheitlicht (Einheiten, Währungen, Sprachen). Modelle wandeln Seiten außerdem in sauberes Markdown für nachgelagertes RAG um (siehe DOC-014).
• Kostenabwägung: LLM-Extraktion ist je Seite langsamer und teurer als Selektoren. Hybride Entwürfe sind üblich: Ein Modell erzeugt oder repariert Selektoren einmalig, danach läuft günstige deterministische Extraktion, und das Modell wird nur bei Fehlern oder neuen Layouts aufgerufen. Eine allgemeingültige Einsparungszahl gibt es nicht; messen Sie an Ihren eigenen Websites.
• Zuerst APIs und lizenzierte Daten bevorzugen: Bietet eine Website eine API, einen Open-Data-Feed, eine Sitemap mit strukturierten Daten (schema.org JSON-LD) oder eine Datenlizenz, nutzen Sie diese statt zu scrapen.

Varianten

• E-Commerce / Handel: Beobachtung von Wettbewerberpreisen und -sortiment, Gewinnung von Produktattributen (speist DATA-010).
• Vertrieb & Marketing: Entdeckung von Unternehmen und Kontakten auf öffentlichen Websites (siehe AGENT-007, AGENT-011); höchstes DSGVO-Risiko, wenn natürliche Personen betroffen sind.
• Öffentlicher Sektor & Forschung: Ausschreibungsportale, Gesetzgebung, Seiten der offenen Verwaltung, Webarchive für Text- und Data-Mining (TDM).
• Finanzen / Risiko: Beobachtung von Nachrichten, Meldungen und ESG-Veröffentlichungen.
• Entwickler-/KI-Teams: Crawling für RAG-Wissensbasen und Webzugriff von Agenten.
• Private Nutzung: persönliche Preisbeobachter oder Rechercheausschnitte; die Haushaltsausnahme der DSGVO ist eng.

So funktioniert es

1. URL-Entdeckung (Sitemap, Such-API, Startliste)
2. Regelprüfung (robots.txt, Prüfung von Bedingungen/Lizenz, Ratenbegrenzung, Regeln für personenbezogene Daten)
3. Abruf (HTTP oder Headless-Browser für JavaScript-Seiten)
4. Bereinigung (Entfernen von Standardbausteinen
5. Markdown / bereinigtes DOM / Screenshot)
6. Extraktion (LLM oder VLM gegen JSON-Schema, strukturierte Ausgaben)
7. Validierung (Typen, Wertebereiche, Gegenprüfungen, Verankerung im Quelltext, Deduplizierung)
8. Laden (Data Warehouse / PIM / CRM) + Überwachung (Drift, Fehlerquote)
9. menschliche Prüfung von Datensätzen mit geringer Sicherheit und von Schemaänderungen

• Extraktion: Ein LLM erhält bereinigtes Markdown oder DOM plus ein Schema und liefert JSON; schema- eingeschränkte Dekodierung vermeidet fehlerhafte Ausgaben. Ein VLM liest Screenshots, wenn das DOM verschleiert, per Canvas gerendert oder tabellenlastig ist.
• Selektor-Induktion: Das Modell schlägt CSS-/XPath-Regeln aus Beispielseiten vor; die Regeln laufen ohne Modell, bis die Validierung fehlschlägt („selbstheilende“ Scraper).
• Browser-Agenten: Für Anmeldungen, Seitenumbrüche und Formulare steuert ein Agent den Browser (siehe AGENT-003). Anmeldungen bei Diensten Dritter sind meist vertraglich untersagt; umgehen Sie keine Zugriffskontrollen.
• Mensch-in-der-Schleife (Human-in-the-Loop): stichprobenbasierte Prüfung, Kontrolle von Feldern mit geringer Sicherheit, Freigabe neuer Quellen durch jemanden, der Bedingungen und Rechtsgrundlage geprüft hat.

Datenaufbereitung

Die Daten stammen hier von öffentlichen Websites, nicht aus internen Systemen; die Aufbereitung besteht daher überwiegend darin, Ziel und Ablageort zu definieren. Typische Lücken sind ein fehlendes klares Schema (welche Felder, welche Einheiten), ungeklärter rechtlicher Status der Quellen, uneinheitliche Produktbenennung, die den Abgleich mit dem eigenen Katalog blockiert, und kein Ort, um Ergebnisse mit Quell-URL und Zeitstempel zu speichern.

Schritte der Aufbereitung: (1) Zielwebsites auflisten und mit der Rechtsabteilung deren Bedingungen, robots.txt, Urheberrecht und Datenbankrechte prüfen, siehe GUIDE-014 für den regulatorischen Rahmen; (2) ein JSON-Schema mit Feldtypen, Einheiten und zulässigen Werten schreiben, siehe PREP-019; (3) die internen Referenzdaten vorbereiten, mit denen die Ergebnisse abgeglichen werden, etwa eigene Artikellisten, siehe PREP-005 und PREP-011; (4) 20–50 Seiten mit korrekten extrahierten Werten als Evaluierungssatz sammeln, siehe PREP-018; (5) Ergebnisse anschließend mit DATA-003 bereinigen und deduplizieren; (6) personenbezogene Daten aus dem Schema ausschließen, sofern keine Rechtsgrundlage besteht, siehe PREP-025.

Werkzeuge: Playwright oder Crawl4AI zum Rendern, ein kleines LLM für die Extraktion, eine Datenbank oder Tabellenkalkulation als Ziel und DOC-014 für unterwegs gefundene PDF-Dokumente. Grober Aufwandsanteil: etwa 30 Prozent, überwiegend Schemaentwurf, Abgleich mit den eigenen Daten und Beobachtung von Änderungen. Prüfen Sie die Bereitschaft mit GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• smb: Weg B, weil ein kleines Skript oder ein n8n-Ablauf mit einer LLM-API besser zu den konkreten Websites und Feldern passt als ein generisches Produkt und es nur wenige ausgereifte, in der EU gehostete Produkte gibt.
• enterprise: Weg B, weil das Scraping eigene Preis-, Vertriebs- oder Forschungssysteme speist und Umfang sowie rechtliche Kontrolle eine interne Pipeline auf Cloud-APIs rechtfertigen.
• developer: Weg C, weil quelloffene Crawler mit einem kleinen lokalen Modell API-Kosten je Seite entfallen lassen und die volle Kontrolle über Ratenbegrenzung und Compliance erhalten.

Weg A — Kaufen (Standardsoftware)

• KI-Scraping-/Extraktionsdienste: Firecrawl, Apify (Actors-Marktplatz; tschechisches Unternehmen, EU-basiert), Zyte (irischer Ursprung; KI-gestützte Extraktions-API), Bright Data, Diffbot (Extraktion im Stil eines Wissensgraphen), Browse AI und Octoparse (No-Code), Jina Reader (URL-zu-Markdown).
• Prüfen: Verarbeitungsort in der EU, ob die Proxy-/Datenbeschaffung des Anbieters ethisch regelkonform ist, Unterstützung von robots.txt, Auftragsverarbeitungsvertrag, wer die rechtliche Verantwortung für die Ziele trägt (Sie).
• A wählen, wenn: wenige Dutzend Quellen, keine Entwickler, Ergebnisse werden schnell benötigt.

Weg B — Auf Cloud-KI-Diensten aufbauen (empfohlener Standard)

• Abruf mit Playwright oder einer verwalteten Browser-/Abruf-API; Bereinigung mit Trafilatura oder Readability; Extraktion mit einem Spitzen- oder mittelgroßen Modell mit strukturierten Ausgaben: Mistral (EU), Claude, Gemini, GPT über Endpunkte in EU-Regionen (Azure OpenAI, Vertex AI, Bedrock Frankfurt). Kleine, günstige Modelle für Massenseiten verwenden und schwierige Seiten an größere eskalieren.
• Orchestrierung mit n8n, Airflow oder Dagster; Rohabzüge (für Prüfung/Neuverarbeitung) getrennt von den extrahierten Datensätzen speichern. Prompt-Caching und Batch-APIs nutzen, um Kosten zu senken.
• Frameworks: ScrapeGraphAI, Loader von LangChain/LlamaIndex, Crawl4AI (auch in Weg C nutzbar).

Weg C — Selbst betreiben (Open Source)

• Crawler: Crawl4AI, Scrapy plus scrapy-playwright, Crawlee, Firecrawl (quelloffener Kern), Link-Entdeckung im Stil von Katana; Bereinigung mit Trafilatura.
• Modelle: Open-Weight-LLMs über vLLM oder Ollama (Qwen3-Familie, Llama, Mistral, Gemma); Qwen-VL-Familie für Screenshots; kleine feingetunte Extraktoren für Massenverarbeitung (z. B. Modelle im Stil von ReaderLM für HTML-zu-Markdown/JSON von Jina).
• Hardware: HW2 (eine GPU mit 24–32 GB) bewältigt ~7–14B-Modelle bei moderatem Crawl-Umfang; ein reiner CPU-Aufbau funktioniert für selektorbasierte Extraktion mit gelegentlichen Modellaufrufen. Betriebsaufwand: Proxys, Browser-Pools, Zeitplanung, Speicher.

Weg D — Eigenes Training

Lohnt sich nur bei sehr großen, einheitlichen Crawls (z. B. Millionen Produktseiten), bei denen ein feingetuntes kleines Modell eine teure API ersetzt. Es braucht Hunderte bis Tausende Seite/JSON-Paare, die die Prüfwarteschlange ganz natürlich erzeugt.

Stand der Technik (2026)

• Standardmuster: Seite-zu-Markdown plus schema-eingeschränkte LLM-Extraktion ist ein etablierter Baustein für Entwickler; das hybride „Modell schreibt den Scraper, Regeln führen ihn aus“ ist die kosteneffiziente Weiterentwicklung.
• Agentisches Browsen: Browser-Agenten und Werkzeugprotokolle (MCP-basierte Webwerkzeuge) lassen Assistenten live navigieren und extrahieren, sind aber langsamer, weniger deterministisch und teurer als Crawler.
• Eskalation bei Bot-Abwehr: Websites blockieren zunehmend KI-Crawler (robots.txt-Regeln für benannte KI-User- Agents, Bot-Management, Bezahlmodelle pro Crawl und Lizenzmodelle). Werkzeuge zur Umgehung existieren, sind aber rechtlich und ethisch bedenklich; dieser Katalog empfiehlt sie nicht.
• Grenzen und Fehlerbilder: halluzinierte oder „hilfreich ergänzte“ Felder, falsche Preis-/Variantenauswahl auf Seiten mit mehreren Angeboten, abgeschnittene lange Seiten, nach Relaunches stillschweigend fehlende Daten, Prompt-Injection durch Seiteninhalte, die auf das Extraktions- oder Agentenmodell zielt, und Kostenexplosion bei großen Crawls. Gegenmaßnahmen: Prüfungen der Verankerung in der Quelle (extrahierter Wert muss im Seitentext vorkommen), Schemavalidierung, Anomaliewarnungen bei Füllquoten der Felder und Behandlung von Seiteninhalt als nicht vertrauenswürdige Eingabe.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (llm-general, vlm, web-scraping): DOC-014 (Parsen von PDFs/Seiten für RAG), DATA-022 (Partnerdaten-/Schema-Mapping), AGENT-003 (Browser-Agenten), DATA-003 (Bereinigung und Deduplizierung gescrapter Datensätze).
• Nachgelagert: DATA-010 (Produktanreicherung & Klassifikation), DATA-001 (dialogbasierte BI auf den gesammelten Daten), AGENT-011 (CRM-Anreicherung), AGENT-007 (Akquise).
• Ein gemeinsamer Browser-Pool, eine Proxy-/Egress-Richtlinie und ein vLLM-Server (HW2/HW3) können mehrere davon bedienen.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen; Preis pro Seite/Credit oder pro Rechenlauf.
• Weg B: 1–2 Monate für eine überwachte Pipeline; die Modellkosten wachsen mit Seiten und Tokens, daher hybride Wiederverwendung von Selektoren und Caching nutzen.
• Weg C: 2–4 Monate inkl. Betrieb von Browsern/Proxys und GPU-Hosting.
• Kennzahlen: Genauigkeit auf Feldebene gegenüber einer gekennzeichneten Stichprobe, Abdeckung (Anteil der Zielseiten, die vollständige Datensätze liefern), Kosten pro 1.000 Seiten, Zeit bis zur Reparatur nach einer Layoutänderung, Blockier-/Fehlerquote, Aktualität, Anteil der Quellen mit dokumentierter rechtlicher Prüfung.

Menschen & Veränderung

Der fachliche Auftraggeber (Leitung von Vertrieb, Einkauf oder Forschung) legt fest, welche Daten sich zu sammeln lohnen und wer sie nutzt. Recht und Compliance müssen jede Quelle vor dem Pilot freigeben, denn Urheberrecht, Datenbankrechte, Nutzungsbedingungen der Seiten und Wettbewerbsrecht sind die eigentlichen Risiken. Die IT richtet die Crawler-Infrastruktur ein, einschließlich Ratenbegrenzung und Kennzeichnung; Endanwender prüfen Stichproben der Ergebnisse.

Betriebsrat: in der Regel nein, weil das System öffentliche Webdaten sammelt und keine Beschäftigten überwacht; relevant wird er nur, wenn Nutzungsprotokolle pro Person ausgewertet werden (§ 87 Abs. 1 Nr. 6 BetrVG), und § 90 Abs. 1 Nr. 3 verlangt weiterhin rechtzeitige Information, wenn sich Arbeitsabläufe ändern. Öffentliche Stellen informieren in denselben Fällen den Personalrat. Datenschutz: Vermeiden Sie personenbezogene Daten; werden Kontaktdaten von Einzelpersonen gescrapt, beziehen Sie die(den) Datenschutzbeauftragte(n) ein, prüfen Sie die Rechtsgrundlage und führen Sie bei größerem Umfang eine Datenschutz-Folgenabschätzung (DSFA) durch.

KI-Kompetenz: Unterstützen Sie die Beschäftigten mit einer kurzen Einweisung, welche extrahierten Daten verlässlich sind und welche nicht, siehe GUIDE-006, sowie zur KI-Richtlinie des Unternehmens, siehe GUIDE-007. Starten Sie mit einem Quellentyp als Pilot, zeigen Sie Ergebnisse im direkten Vergleich mit dem manuellen Prozess und halten Sie jede Woche eine menschliche Prüfung einer Zufallsstichprobe vor. Begegnen Sie der Sorge vor rechtlichen Risiken mit einer dokumentierten Quellenliste und einem Stoppschalter je Website. Leitfäden: GUIDE-009, GUIDE-011.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): in der Regel minimales Risiko; KI-Kompetenz (Art. 4) gilt. Vorsicht bei Art. 5: Das Verbot, Datenbanken zur Gesichtserkennung durch ungezieltes Auslesen von Gesichtsbildern aus dem Internet oder von Überwachungsaufnahmen zu erstellen oder zu erweitern (Art. 5 Abs. 1 Buchst. e), bedeutet, dass das Scrapen von Bildern für biometrische Datenbanken verboten ist; dieser Anwendungsfall darf dafür nicht genutzt werden. Werden gescrapte Daten für Hochrisiko-Systeme verwendet (Anhang III, z. B. Personalauswahl oder Kreditscoring), verschiebt das die Einstufung des nachgelagerten Systems. Anbieter von KI-Modellen mit allgemeinem Verwendungszweck haben Pflichten zur Urheberrechtsstrategie (Art. 53), relevant, wenn Sie scrapen, um Modelle zu trainieren.
• DSGVO: Öffentliche Verfügbarkeit hebt den Schutz nicht auf. Eine Rechtsgrundlage (meist berechtigtes Interesse, Art. 6 Abs. 1 Buchst. f, dokumentiert in einer Interessenabwägung), Transparenz gegenüber betroffenen Personen (Art. 14, mit engen Ausnahmen), Datenminimierung, Speicherbegrenzung und der Ausschluss besonderer Kategorien (Art. 9) gelten. Aufsichtsstellen wie die CNIL und der EDSA (Stellungnahme 28/2024 zu KI-Modellen) haben Erwartungen an das berechtigte Interesse beim Web-Scraping formuliert. Extrahieren Sie bevorzugt Unternehmens- oder Produktdaten, keine personenbezogenen Daten; filtern oder pseudonymisieren Sie Namen, E-Mail-Adressen und Profile bereits bei der Aufnahme.
• Urheberrecht und Datenbankrechte: Die DSM-Richtlinie der EU (Art. 3/4) erlaubt Text- und Data-Mining für Forschung und, sofern Rechteinhaber nicht in maschinenlesbarer Form widersprechen (z. B. robots.txt, TDM-Reservation- Protocol), auch für kommerzielle Zwecke; das Datenbankherstellerrecht (Richtlinie 96/9/EG) kann die Entnahme wesentlicher Teile einer Datenbank einschränken. Beachten Sie Widersprüche (Opt-outs).
• Vertrag und unlauterer Wettbewerb: Nutzungsbedingungen der Websites, Zugriffskontrollen (Umgehung kann unzulässig sein) und nationales Recht gegen unlauteren Wettbewerb. Prüfen Sie CFAA-ähnliche lokale Regeln bei Zielen außerhalb der EU.
• Sicherheit: Browser isolieren, Inhalte als nicht vertrauenswürdig behandeln, Extraktionsagenten nie Zugangsdaten oder Schreibzugriff geben.
• Gegenmaßnahmen: Quellenregister mit rechtlicher Bewertung, Einhaltung von robots.txt/Opt-out, rücksichtsvolle Ratenbegrenzung, erkennbarer User-Agent, Herkunftsfelder an jedem Datensatz, Datenschutz-Folgenabschätzung (DSFA), wo personenbezogene Daten in größerem Umfang betroffen sind.

Erste Schritte

1. Definieren Sie die Geschäftsfrage und das Zielschema; prüfen Sie zuerst, ob es eine API, einen Feed oder eine Lizenz gibt.
2. Legen Sie ein Quellenregister an: Verantwortliche, Bedingungen, Status von robots.txt/TDM-Opt-out, Vorhandensein personenbezogener Daten, Rechtsgrundlage.
3. Bauen Sie einen Prototyp mit 20 Seiten je Quelle mit Seite-zu-Markdown plus Extraktion mit strukturierter Ausgabe; kennzeichnen Sie eine Stichprobe und messen Sie die Feldgenauigkeit.
4. Überführen Sie stabile Quellen auf zwischengespeicherte oder erzeugte Selektoren; behalten Sie das Modell für Fehler und neue Layouts.
5. Ergänzen Sie Überwachung (Füllquoten, Drift, Kosten) und eine Prüfwarteschlange, bevor Sie Ergebnisse mit Entscheidungen verbinden.

Quellen

1. Firecrawl documentation — https://docs.firecrawl.dev
2. Crawl4AI (open-source LLM-friendly crawler) — https://github.com/unclecode/crawl4ai
3. ScrapeGraphAI — https://github.com/ScrapeGraphAI/Scrapegraph-ai
4. Scrapy documentation — https://docs.scrapy.org
5. Apify documentation — https://docs.apify.com
6. Trafilatura — https://github.com/adbar/trafilatura
7. Regulation (EU) 2024/1689 (AI Act), Art. 5(1)(e) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. Directive (EU) 2019/790 (DSM), Art. 3-4 TDM — https://eur-lex.europa.eu/eli/dir/2019/790/oj
9. EDPB Opinion 28/2024 on AI models and personal data — https://www.edpb.europa.eu/our-work-tools/our-documents/opinion-board-art-64/opinion-282024-certain-data-protection-aspects_en
10. CNIL — AI and GDPR recommendations (legitimate interest, web scraping) — https://www.cnil.fr/en/ai-and-gdpr-cnil-publishes-new-recommendations-support-responsible-innovation
11. Directive 96/9/EC (database right) — https://eur-lex.europa.eu/eli/dir/1996/9/oj