KI-Crawler liest Kundendaten: Lehre aus dem Fall uniVersa

Ein Datenschutzvorfall beim Versicherer uniVersa zeigt gerade, wie schnell aus einer ganz normalen IT-Umstellung ein meldepflichtiges Datenleck werden kann, ganz ohne Hackerangriff im klassischen Sinn. Auslöser war ein automatisierter KI-Crawler von OpenAI, der für einige Stunden Zugriff auf einen ungeschützten Server hatte. Wenn du selbst einen Shop, ein Kundenportal oder sonst einen öffentlich erreichbaren Server betreibst, lohnt sich ein Blick auf die Details.

Was ist passiert

Bei einer IT-Umstellung am 7. Juli 2026 fehlte bei den uniVersa-Versicherungen (Lebensversicherung, Krankenversicherung, Allgemeine Versicherung) für mehrere Stunden eine Sicherheitseinstellung auf einem einzelnen Server, der für den automatisierten Datenaustausch mit Vertriebspartnern vorgesehen war. In diesem Zeitfenster griff ein automatisierter Web-Crawler von OpenAI auf die dort liegenden Daten zu, das berichten unter anderem heise online und t-online.de übereinstimmend.

Betroffen waren laut Versicherungsbote Namen, Adressen, Vertragsdaten wie Versicherungsnummern und Tarifinformationen sowie in einigen Fällen Bankdaten. Gesundheitsdaten und Zugangsdaten wie Passwörter waren nach übereinstimmenden Angaben nicht betroffen. uniVersa entdeckte den offenen Zugang über eigene Sicherheitskontrollen, schaltete ihn sofort ab, beauftragte externe IT-Forensiker und informierte die betroffenen Kunden seit dem 20. Juli schriftlich, so Versicherungsmonitor und asscompact.de. Die Bayerische Datenschutzaufsicht (BayLDA) bestätigte auf Anfrage den Eingang einer Meldung, zu Details äußerte sie sich mit Verweis auf laufende Untersuchungen nicht. OpenAI wurde aufgefordert, die abgerufenen Daten zu löschen und nicht für das Training eigener Modelle zu verwenden.

Was das für dich als Unternehmen bedeutet

Wichtig für die Einordnung: Hier hat niemand gezielt gehackt. Ein KI-Crawler arbeitet im Grunde wie ein Suchmaschinen-Bot, er durchsucht systematisch das offene Web und liest mit, was er ohne Zugangssperre findet. Genau das macht den Vorfall für jedes Unternehmen mit eigenem Server relevant, nicht nur für Versicherer: Sobald bei einer Migration, einem Hoster-Wechsel oder einer neuen Testumgebung eine Zugriffsbeschränkung vergessen wird, lesen automatisierte Crawler mit, egal ob dort Kundendaten, Vertragsdetails oder interne Dokumente liegen.

Für Betriebe mit eigenem Shop-Backend, Kundenportal oder Server-Infrastruktur heißt das konkret: IT-Umstellungen sind der Moment mit dem höchsten Risiko für genau diese Art von Fehler, weil Zugriffsrechte in der Hektik einer Migration leicht untergehen.

Was du jetzt tun (oder lassen) solltest

Tun:

1. Leg bei jeder IT-Umstellung eine Checkliste an, die Zugriffsrechte, Firewall-Regeln und Passwortschutz für neue oder umgezogene Server explizit vor dem Livegang prüft, nicht danach.
2. Schütz sensible Bereiche mit echter Zugangskontrolle, also Passwortschutz oder IP-Beschränkung, statt dich auf `robots.txt` zu verlassen. Eine `robots.txt` ist nach den Regeln des Web nur eine Bitte an Bots, kein technischer Schutz, wie unter anderem Phlow erklärt.
3. Kenn die 72-Stunden-Frist. Nach Art. 33 DSGVO muss eine Datenschutzverletzung mit Risiko für Betroffene in der Regel innerhalb von 72 Stunden ab Kenntnis an die zuständige Aufsichtsbehörde gemeldet werden, siehe Art. 33 DSGVO im Volltext. Das gilt für jedes Unternehmen, nicht nur für große Versicherer.
4. Wenn dir die eigene Server-Absicherung zu viel wird, lagere den Betrieb an ein Managed Hosting mit laufender Wartung und Absicherung aus, etwa über die Managed-Hosting-Betreuung für Shop und Betrieb.

Lassen:

• Verfall nicht in Panik vor KI-Crawlern per se. Sie sind kein Angriffswerkzeug, sondern automatisierte Web-Bots, das eigentliche Risiko ist die eigene, ungeprüfte Serverkonfiguration.
• Verwechsle "kein Passwort- oder Gesundheitsdaten-Leck" nicht mit "kein Problem". Auch Namen, Adressen und Vertragsdaten sind personenbezogene Daten mit Meldepflicht, sobald ein Risiko für Betroffene besteht.

Wer Server- und Zugriffskonfiguration nicht dem Zufall überlassen will, sollte das von Anfang an mit einer klaren, wiederkehrenden Kontrolle statt einer einmaligen Einrichtung aufbauen. Wie eine solche Struktur mit menschlicher Kontrolle über automatisierte Abläufe aussehen kann, zeigt der ESD AI-Stack an einem laufenden Beispiel.

Die Einschätzung kommt nicht vom Schreibtisch, sondern von jemandem, der Server- und Shop-Infrastruktur selbst betreibt. Wie das aussah, steht anonymisiert in der Case Study und der Geschichte dahinter. Dieser Artikel ist eine Orientierung, keine Rechts- oder Sicherheitsberatung.