Das Wichtigste in Kürze

Bei einem Ransomware-Angriff zählt jede Minute, doch Schnelligkeit allein reicht nicht aus. Entscheidend ist, dass die richtigen Schritte in der richtigen Reihenfolge erfolgen: erkennen, eindämmen, Beweise sichern, Verantwortliche einbinden und erst anschließend wiederherstellen. Wer in der ersten Stunde ruhig und strukturiert vorgeht, begrenzt den Schaden erheblich, schützt wichtige Spuren für die Ursachenanalyse und kann spätere Melde- und Nachweispflichten leichter erfüllen.

Dieser Artikel beschreibt die ersten 60 Minuten Schritt für Schritt. Er kann als Leitfaden für den Ernstfall dienen. Eine Checkliste unterstützt ein strukturiertes Vorgehen.

Was ist Ransomware?

Ransomware ist Schadsoftware, die Daten und Systeme verschlüsselt oder den Zugriff darauf blockiert. Auch Webseiten können betroffen sein. Die Angreifer fordern anschließend ein Lösegeld, meist in Kryptowährung, und stellen dafür einen Entschlüsselungsschlüssel in Aussicht.

Moderne Angriffe gehen häufig weit über die reine Verschlüsselung hinaus:

• Doppelte Erpressung: Vor der Verschlüsselung werden Daten kopiert. Die Täter drohen zusätzlich damit, diese Daten zu veröffentlichen oder zu verkaufen.
• Angriff auf Backups: Täter suchen gezielt nach Datensicherungen und löschen oder verschlüsseln sie, damit eine Wiederherstellung ohne Zahlung unmöglich wird.
• Lange Vorlaufzeit: Oft sind die Angreifer bereits Tage oder Wochen im Netzwerk aktiv, bevor die Verschlüsselung sichtbar wird. Sie erkunden Systeme, erweitern ihre Rechte und bereiten den Zeitpunkt des größten Schadens vor.

Daraus ergibt sich eine wichtige Erkenntnis: Wird die Lösegeldforderung sichtbar, ist der Angriff meist bereits weit fortgeschritten. Die Bereinigung eines einzelnen Rechners genügt deshalb nicht. Es ist davon auszugehen, dass das gesamte Netzwerk kompromittiert sein kann.

Die Grundregeln für den Ernstfall

Vor dem eigentlichen Zeitplan gelten vier Grundsätze, die über alle Phasen hinweg Bestand haben:

1. Ruhe bewahren, aber zügig handeln. Hektische Einzelaktionen richten oft mehr Schaden an als der Angriff selbst.
2. Eindämmen vor Aufräumen. Zunächst muss die Ausbreitung gestoppt werden, danach erfolgt die Bereinigung.
3. Spuren erhalten. Ohne Beweise lässt sich nicht klären, wie die Täter eingedrungen sind. Dann besteht die Gefahr, dass sie nach der Wiederherstellung sofort erneut zuschlagen.
4. Alles dokumentieren. Jede Maßnahme gehört mit Uhrzeit und Verantwortlichem ins Protokoll. Dies unterstützt das Team, Behörden, Versicherer und die spätere Aufarbeitung.

Vorbereitung: Was vor dem Angriff bereitliegen sollte

Der beste Ablaufplan verliert an Wert, wenn im Ernstfall unklar ist, wer zu kontaktieren ist. Folgende Punkte sollten bereits im Vorfeld geklärt sein, idealerweise ausgedruckt und offline verfügbar:

• Notfallkontakte: Telefonnummern von IT-Leitung, Geschäftsführung, Datenschutzbeauftragtem, IT-Dienstleister, Incident-Response-Dienstleister, Cyberversicherung, Rechtsbeistand und Polizei.
• Zugangsdaten für den Notfall: Ein gesicherter, vom Produktivnetz unabhängiger Ort, an dem wichtige Konten und Anleitungen hinterlegt sind.
• Netzwerkplan: Eine aktuelle Übersicht über Standorte, Segmente, Server, Firewalls und Fernzugänge.
• Systemliste mit Priorität: Festlegung, welche Systeme geschäftskritisch sind und in welcher Reihenfolge sie wieder laufen sollen.
• Alternative Kommunikationswege: Sind E-Mail und Telefonanlage betroffen, wird ein Ausweichsystem benötigt, etwa private Mobiltelefone mit einer vorab vereinbarten Messenger-Gruppe.
• Backup-Konzept: Mindestens eine Sicherung sollte offline oder unveränderbar (immutable) gespeichert sein. Entscheidend ist, dass die Wiederherstellung regelmäßig getestet wird.

Rollen im Krisenfall

Auch in kleinen Organisationen muss klar sein, wer welche Entscheidungen trifft. Eine Person kann mehrere Rollen übernehmen, die Rollen selbst müssen jedoch besetzt sein.

Der Ablaufplan: Die ersten 60 Minuten

Minute 0 bis 10: Erkennen und Alarm auslösen

Typische Anzeichen eines Angriffs:

• Eine Nachricht auf dem Bildschirm, die eine Lösegeldzahlung verlangt
• Dateien, die sich nicht mehr öffnen lassen oder ungewöhnliche Endungen tragen
• Server oder Freigaben, die plötzlich nicht erreichbar sind
• Gleichzeitige Störungsmeldungen mehrerer Mitarbeitender
• Massenhafte Alarme der Antivirensoftware oder deren Deaktivierung

Sofortmaßnahmen:

1. Betroffenes Gerät vom Netzwerk trennen. Das Netzwerkkabel wird gezogen, WLAN und Bluetooth werden ausgeschaltet. So wird verhindert, dass sich die Schadsoftware weiter ausbreitet.
2. Nicht sofort herunterfahren. Im Arbeitsspeicher liegen oft wertvolle Spuren, etwa Schlüsselmaterial oder Hinweise auf die Täter. Das Gerät bleibt eingeschaltet, aber isoliert. Läuft die Verschlüsselung erkennbar noch und lässt sich das Gerät nicht anders stoppen, kann ein Ausschalten im Einzelfall sinnvoll sein. Diese Entscheidung trifft die technische Leitung, möglichst nach Rücksprache mit Fachleuten.
3. Die Lösegeldnachricht fotografieren. Hierfür wird ein Mobiltelefon verwendet, nicht der betroffene Rechner. Die Nachricht enthält oft Hinweise auf die Schadsoftware-Familie.
4. Sofort die IT oder die Notfallnummer informieren. Dies erfolgt telefonisch und nicht per E-Mail, da das Mailsystem betroffen sein oder mitgelesen werden kann.
5. Nichts löschen, nichts neu installieren.

Am Ende dieser Phase sollte die Einsatzleitung feststehen und das Protokoll begonnen haben.

Minute 10 bis 20: Krisenstab bilden und Lage erfassen

In dieser Phase wird aus einer Störung ein strukturierter Einsatz.

1. Krisenstab zusammenrufen. Dies geschieht per Telefon oder über einen vorab vereinbarten, unabhängigen Kanal.
2. Protokoll führen. Festgehalten wird, wer was wann beobachtet hat, welche Systeme betroffen sind und welche Maßnahmen bereits ergriffen wurden.
3. Erstes Lagebild erstellen. Die zentralen Fragen lauten:
   • Welche Systeme, Standorte und Nutzer sind betroffen?
   • Läuft die Verschlüsselung noch?
   • Sind Server, Backups oder Cloud-Dienste betroffen?
   • Gibt es Hinweise auf Datenabfluss?
4. Annahme treffen: Zunächst wird vom Schlimmsten ausgegangen. Ist ein Gerät betroffen, kann das gesamte Netzwerk kompromittiert sein.
5. Kommunikationsregel festlegen. Die Belegschaft wird kurz informiert: Betroffene Geräte nicht benutzen, nicht ausschalten, nichts löschen, keine eigenen Reparaturversuche unternehmen und Meldungen an eine zentrale Stelle richten.

Minute 20 bis 35: Eindämmung

Nun gilt es, den Angreifern den Handlungsspielraum zu nehmen.

Netzwerk und Zugänge:

• Betroffene Netzwerksegmente werden getrennt, zum Beispiel durch Abschalten von Switch-Ports oder durch Firewall-Regeln.
• Fernzugänge wie VPN, Remote-Desktop und Zugänge von Dienstleistern werden gesperrt.
• Verbindungen zwischen Standorten werden bei Bedarf gekappt.
• Der Internetzugang kritischer Systeme wird vorübergehend unterbrochen, damit keine Daten mehr abfließen und keine Befehle der Täter ankommen.

Konten und Passwörter:

• Kompromittierte oder verdächtige Benutzerkonten werden deaktiviert.
• Privilegierte Konten (Domänenadministratoren, Dienstkonten) werden abgesichert und deren Passwörter geändert. Dies erfolgt ausschließlich von einem sauberen, nachweislich nicht betroffenen Gerät aus, da auf infizierten Systemen Passwörter mitgelesen werden könnten.
• Die Mehrfaktor-Authentifizierung wird geprüft und, wo möglich, erzwungen.

Datensicherungen schützen:

• Backup-Systeme werden sofort vom Netzwerk getrennt oder Zugriffe darauf gesperrt.
• Offline-Medien werden erst angeschlossen, wenn die Umgebung als sauber gilt.
• Die Cloud-Synchronisation (etwa OneDrive, Dropbox oder Netzwerklaufwerke) wird pausiert, damit verschlüsselte Dateien nicht die guten Versionen überschreiben.

E-Mail:

• Es wird geprüft, ob der Angriff über eine Phishing-Mail begonnen hat. Verdächtige Absender und Anhänge werden am Mail-Gateway gesperrt.

Wichtig ist, dass jede dieser Maßnahmen protokolliert wird. Manche Eingriffe, etwa das Abschalten von Servern, haben Folgen für den Betrieb. Solche Entscheidungen sollten von der Einsatzleitung bewusst getroffen und nicht dem Zufall überlassen werden.

Minute 35 bis 45: Beweise sichern und externe Hilfe holen

Beweise sichern:

• Betroffene Systeme werden möglichst unverändert belassen.
• Bei Bedarf werden Abbilder (Images) von Festplatten und Arbeitsspeicher durch Fachleute erstellt.
• Relevante Protokolldaten (Logs) werden gesichert, etwa von Firewall, VPN, Domänencontrollern, Mailserver und Endpunktschutz.
• Screenshots und Fotos von Meldungen werden abgelegt.
• Verdächtige Dateien, E-Mails und Lösegeldforderungen werden separat gesichert.

Diese Daten sind für die forensische Analyse unverzichtbar. Sie klären, wie die Täter eingedrungen sind, was sie getan haben und ob Daten abgeflossen sind.

Externe Unterstützung hinzuziehen:

• Cyberversicherung: Viele Policen enthalten eine Notfall-Hotline und knüpfen Leistungen an eine unverzügliche Meldung. Die Bedingungen sollten frühzeitig geprüft werden.
• Incident-Response-Dienstleister: Spezialisierte Teams unterstützen bei Analyse, Eindämmung und Wiederherstellung. Häufig werden sie über die Versicherung vermittelt.
• IT-Dienstleister: Der Dienstleister wird informiert, seine Zugriffe werden jedoch abgestimmt, damit keine Spuren verändert werden.

Polizei einschalten:

Ransomware-Erpressung ist eine Straftat. Für Unternehmen sind die Zentralen Ansprechstellen Cybercrime (ZAC) der Landeskriminalämter zuständig. Eine Anzeige ist nicht nur für die Strafverfolgung wichtig, sondern wird auch von Versicherern häufig verlangt.

Minute 45 bis 60: Entscheiden, melden, kommunizieren

In der letzten Phase der ersten Stunde werden die nächsten Schritte vorbereitet.

Notbetrieb planen:

• Welche Geschäftsprozesse müssen sofort weiterlaufen?
• Gibt es manuelle Alternativen, etwa Papierprozesse, Telefon oder mobile Hotspots?
• Wer informiert Kunden und Lieferanten, deren Aufträge betroffen sind?

Meldepflichten prüfen:

• Datenschutz (DSGVO): Ist es zu einer Verletzung des Schutzes personenbezogener Daten gekommen, muss dies nach Artikel 33 DSGVO in der Regel innerhalb von 72 Stunden nach Bekanntwerden der zuständigen Datenschutzaufsichtsbehörde gemeldet werden. Besteht ein hohes Risiko für die Betroffenen, sind diese nach Artikel 34 DSGVO ebenfalls zu informieren. Die 72 Stunden laufen ab dem Zeitpunkt, zu dem der Vorfall bekannt wird. Der Datenschutzbeauftragte sollte daher frühzeitig eingebunden werden.
• NIS2 und branchenspezifische Vorgaben: Zählt ein Unternehmen zu den Einrichtungen, die unter die NIS2-Regeln fallen, gelten gestaffelte Meldefristen gegenüber dem BSI. Vorgesehen sind eine frühe Erstmeldung innerhalb von 24 Stunden, eine Meldung mit erster Bewertung innerhalb von 72 Stunden und ein Abschlussbericht nach spätestens einem Monat. Ob und in welchem Umfang diese Pflichten zutreffen, sollte rechtzeitig geprüft werden.
• Verträge: Kunden- und Lieferverträge können eigene Informationspflichten enthalten.

Interne und externe Kommunikation:

• Die Belegschaft wird sachlich und knapp informiert. Mitgeteilt wird, was bekannt ist, was nicht, und wie sich die Mitarbeitenden verhalten sollen.
• Es wird festgelegt, wer nach außen spricht. Spekulationen sind zu vermeiden.
• Ein einfacher Text für Kunden und Partner wird vorbereitet, damit bei Bedarf schnell reagiert werden kann.

Die nächsten 24 Stunden planen:

• Wer übernimmt welche Aufgaben in welcher Schicht?
• Wann findet die nächste Lagebesprechung statt?
• Welche Ressourcen und Entscheidungen benötigt die Geschäftsleitung?

Was in der ersten Stunde unterbleiben sollte

Die folgenden Fehler treten in der Hektik besonders häufig auf:

• Sofortige Lösegeldzahlung. Es gibt keine Garantie, dass die Täter liefern oder die Daten nicht trotzdem veröffentlichen. Zahlungen finanzieren weitere Angriffe. Eine Entscheidung darüber gehört nicht in die erste Stunde und sollte nur mit Fachleuten, Rechtsberatung und Behörden getroffen werden.
• Kontaktaufnahme mit den Tätern. Kommunikation sollte, wenn überhaupt, nur durch erfahrene Verhandler erfolgen.
• Eigenmächtiges Neuaufsetzen von Systemen. Dadurch werden Beweise zerstört, und es besteht das Risiko, dass die Täter weiterhin Zugriff haben.
• Unüberlegtes Einspielen von Backups. Sie könnten bereits infiziert sein oder die Angreifer erneut einladen.
• Verwendung von Administratorkonten auf infizierten Geräten. Zugangsdaten können abgegriffen werden.
• Löschen oder Überschreiben von Logs. Sie sind der Schlüssel zur Aufklärung.
• Vorschnelle Entwarnung. Solange die Ursache nicht geklärt ist, bleibt das Risiko bestehen.
• Verschweigen des Vorfalls. Sowohl rechtlich als auch für das Vertrauen von Kunden und Mitarbeitenden ist Offenheit im richtigen Rahmen die bessere Strategie.

Checkliste für die ersten 60 Minuten

Am Ende des Beitrags finden Sie eine Checkliste zum Ausdrucken.

Minute 0 bis 10

• Gerät vom Netz trennen, nicht ausschalten
• Lösegeldnachricht fotografieren
• IT und Notfallkontakt telefonisch informieren

Minute 10 bis 20

• Einsatzleitung bestimmen und Krisenstab einberufen
• Protokoll beginnen
• Erstes Lagebild erstellen
• Belegschaft über Verhaltensregeln informieren

Minute 20 bis 35

• Betroffene Segmente isolieren
• Fernzugänge sperren
• Privilegierte Konten absichern
• Backups und Cloud-Synchronisation schützen

Minute 35 bis 45

• Logs und Abbilder sichern
• Cyberversicherung informieren
• Incident-Response-Dienstleister beauftragen
• Polizei (ZAC) einschalten

Minute 45 bis 60

• Notbetrieb festlegen
• Meldepflichten prüfen (DSGVO, NIS2, Verträge)
• Kommunikationsplan abstimmen
• Aufgaben und Termine für die nächsten 24 Stunden planen

Nach der ersten Stunde: Wie es weitergeht

Die ersten 60 Minuten bilden den Startschuss, nicht das Ende. In den folgenden Stunden und Tagen stehen diese Aufgaben an:

1. Forensische Analyse: Einfallstor, Ausbreitung und Umfang des Datenabflusses werden geklärt.
2. Vollständige Bereinigung: Alle Zugänge der Täter werden geschlossen, kompromittierte Konten und Zugangsdaten erneuert und Schwachstellen beseitigt.
3. Priorisierte Wiederherstellung: Zuerst die Kernsysteme, dann die weiteren Dienste, jeweils aus nachweislich sauberen Backups und in einer geprüften Umgebung.
4. Überwachung: Nach der Wiederherstellung werden die Systeme besonders engmaschig beobachtet, da Wiederholungsangriffe nicht selten sind.
5. Fristgerechte Meldungen: Behörden, Betroffene und Vertragspartner werden gemäß den rechtlichen Vorgaben informiert.
6. Aufarbeitung: Nach dem Vorfall wird in Ruhe ausgewertet, was gut funktioniert hat und was verbessert werden muss. Notfallplan, Schulungen und technische Schutzmaßnahmen werden angepasst.

Vorbeugen: Wie sich das Risiko senken lässt

Kein Schutz ist absolut, doch einige Maßnahmen verringern die Wahrscheinlichkeit und die Folgen eines Angriffs deutlich:

• Regelmäßige, getestete Backups nach der 3-2-1-Regel: drei Kopien, auf zwei verschiedenen Medien, eine davon extern oder offline
• Zeitnahe Updates für Betriebssysteme, Anwendungen, Firewalls und VPN-Gateways
• Mehrfaktor-Authentifizierung für Fernzugänge, E-Mail und Administratorkonten
• Minimale Rechte: Nutzer erhalten nur die Zugriffe, die tatsächlich erforderlich sind
• Netzwerksegmentierung, damit sich ein Angriff nicht ungehindert ausbreitet
• Moderner Endpunktschutz mit Erkennung auffälligen Verhaltens und zentraler Überwachung
• Schulung der Mitarbeitenden, vor allem zum Erkennen von Phishing
• Notfallübungen, in denen der Ablauf realistisch durchgespielt wird
• Schriftlicher Notfallplan, der offline vorliegt und regelmäßig aktualisiert wird
• Zutrittskontrolle: Kann mit KI teils automatisiert werden

Häufige Fragen

Sollte der Rechner sofort ausgeschaltet werden? Zuerst erfolgt die Trennung vom Netzwerk. Ob und wann ein Gerät ausgeschaltet wird, entscheidet die technische Leitung. Im Zweifel bleibt das Gerät isoliert eingeschaltet, damit flüchtige Spuren im Arbeitsspeicher erhalten bleiben.

Soll das Lösegeld gezahlt werden? Diese Frage gehört nicht in die erste Stunde. Behörden raten grundsätzlich von Zahlungen ab. Falls eine Zahlung überhaupt erwogen wird, sollte sie nur nach sorgfältiger Abwägung mit Fachleuten, Rechtsberatung und gegebenenfalls dem Versicherer erfolgen. Auch nach einer Zahlung ist nicht sichergestellt, dass die Daten wieder vollständig nutzbar sind.

Muss der Vorfall gemeldet werden? Sind personenbezogene Daten betroffen, ist dies in der Regel der Fall, und zwar innerhalb von 72 Stunden an die Datenschutzaufsicht. Je nach Branche und Unternehmensgröße können weitere Pflichten bestehen, etwa nach NIS2. Dies sollte frühzeitig mit Datenschutz und Rechtsberatung geklärt werden.

Lassen sich die Daten ohne Zahlung wiederherstellen? Das ist häufig möglich, wenn saubere und unveränderte Backups vorhanden sind. Für manche Schadsoftware existieren zudem frei verfügbare Entschlüsselungswerkzeuge. Ein Anlaufpunkt dafür ist das Projekt No More Ransom. Eine fachkundige Beratung wird dabei empfohlen.

Wie lässt sich feststellen, ob auch Daten gestohlen wurden? Dies lässt sich meist nur durch die Analyse von Logs und Netzwerkverkehr klären. Bis zum Beweis des Gegenteils ist von einem möglichen Datenabfluss auszugehen.

Fazit

Ein Ransomware-Angriff ist eine ernste Lage, aber kein Schicksal. Entscheidend ist die Vorbereitung: Wer Rollen, Kontakte und Abläufe kennt, kann in den ersten 60 Minuten besonnen handeln, statt zu improvisieren. Isolieren, nicht überstürzt abschalten, Beweise sichern, Verantwortliche und Fachleute einbinden, Meldepflichten im Blick behalten und alles dokumentieren: Diese Grundsätze bilden das Fundament.

Dieser Leitfaden eignet sich als Vorlage für einen organisationseigenen Notfallplan. Er sollte an die jeweiligen Gegebenheiten angepasst, ausgedruckt und gemeinsam mit dem Team geübt werden, bevor ein Ernstfall eintritt.

Neue Chrome-Schutzfunktionen im Überblick

Am 20.10.2026 hat das Chrome-Team in einem Beitrag im Google-Blog neue Schutzfunktionen vorgestellt. Dazu gehört die Chrome Gemini Betrugserkennung, die künftig serverseitig arbeitet. Hinzu kommt eine Prüfung der Zwischenablage gegen sogenannte ClickFix-Angriffe. Beides gilt nach der Ankündigung nur für den erweiterten Schutz von Safe Browsing (Enhanced Protection), nicht für den Standardschutz.

Für Admins und Datenschutzbeauftragte ist die Meldung aus zwei Gründen relevant. Zum einen verspricht sie Schutz vor einer Angriffsart, die klassische Download-Filter umgeht. Zum anderen werden dafür mehr Daten an Google übertragen. Die Presseberichte etwa von BleepingComputer und Help Net Security fassen die Ankündigung zusammen. Zur Steuerung im Unternehmen und zur datenschutzrechtlichen Einordnung äußern sie sich nicht.

Im folgenden wird beschrieben, was sich geändert hat, welche Daten Chrome im erweiterten Schutz übermittelt, welche Richtlinie die Betriebsart verbindlich festlegt und wie sich die Entscheidung dokumentieren lässt. Offene Punkte sind als solche gekennzeichnet. Eine Rechtsberatung ersetzt der Beitrag nicht.

Was Google an der Chrome-Betrugserkennung geändert hat

Laut Google-Blog gibt es in Chrome nun zwei Warnstufen: Seiten werden als „verdächtig“ oder als „gefährlich“ eingestuft. Die neue Stufe „verdächtig“ gilt bei aktiviertem erweitertem Schutz. Wie hoch die Quote falscher Alarme in dieser neuen Kategorie ist, nennt Google nicht.

Die zweite Änderung betrifft Gemini. Bereits im Vorjahr hat Chrome für Nutzer des erweiterten Schutzes auf unterstützten Geräten eine Gemini-Erkennung gegen Tech-Support-Betrug lokal auf dem Gerät eingesetzt. Nun kommt zusätzlich ein leistungsstärkeres Gemini-Modell auf Googles Servern zum Einsatz. Es bewertet nach Angaben des Blogs die dargestellte Marke, die Absicht der Seite und eine Betrugswahrscheinlichkeit. Safe Browsing verbindet dieses Ergebnis mit der Reputation der Domain und weiteren Signalen zu einem Gesamturteil. Erfasst werden jetzt auch gefälschte Antivirus-Meldungen und gefälschte Browser-Updates.

Die serverseitige Analyse soll auf alle Nutzer mit aktiviertem erweitertem Schutz ausgeweitet werden. Einen Zeitplan oder Regionen, auch für die EU, nennt der Beitrag nicht. Eine Aussage dazu wäre Spekulation und bleibt deshalb offen.

Zur Datensparsamkeit schreibt Google, Seitentext werde nur dann analysiert, wenn eine Seite sehr deutliche Betrugsindikatoren zeigt. Übertragene Inhalte würden flüchtig verarbeitet, nicht protokolliert, nicht gespeichert und nicht zum Training von Modellen verwendet. Das ist eine Herstellerangabe. Eine unabhängige Prüfung liegt nach den geprüften Quellen nicht vor.

Die Werbebotschaft lautet, Nutzer des erweiterten Schutzes seien „zehnmal sicherer“ als im Standardschutz. Das ist eine Angabe von Google. Wie die Zahl ermittelt wurde, ließ sich in den geprüften Quellen nicht nachvollziehen, und eine unabhängige Prüfung liegt nicht vor. Als Entscheidungsgrundlage taugt sie daher nur eingeschränkt.

ClickFix-Schutz: Was bei der Zwischenablage-Prüfung passiert

Bei ClickFix wird ein Nutzer auf einer Webseite dazu gebracht, einen Befehl selbst auszuführen. Typisch ist eine gefälschte Prüfung („Ich bin kein Roboter“) oder eine vermeintliche Fehlermeldung. Ein Klick kopiert einen Befehl in die Zwischenablage, danach soll er im Windows-Ausführen-Dialog, im Terminal oder in PowerShell eingefügt werden. Der kopierte Text weicht oft von dem ab, was die Seite anzeigt. Weil der Nutzer den Befehl selbst startet, greifen viele automatische Schutzmechanismen nicht. Microsoft beschreibt die Technik ausführlich und hält sie für verbreitet. Auch ein neuerer Microsoft-Beitrag vom August 2026 behandelt eine Kampagne dieser Art.

Genau hier setzt die neue Chrome-Funktion an. Erkennt Chrome bei einem Nutzer des erweiterten Schutzes, dass ein verdächtiger Befehl kopiert wurde, wird der Inhalt der Zwischenablage von personenbezogenen Daten bereinigt und zur Analyse an Safe Browsing gesendet. Fällt das Urteil „gefährlich“ aus, zeigt Chrome eine Warnung. Google gibt an, das System sei auf hohe Präzision ausgelegt, um legitime Entwicklertätigkeit möglichst nicht zu stören.

Zwei Feinheiten sind für die Einordnung wichtig. Erstens nennt das Google-Blog für die Zwischenablage-Prüfung ausdrücklich Safe Browsing, nicht Gemini. Beide Funktionen werden in den Meldungen oft zusammen genannt, sind aber nach der Quellenlage nicht gleichzusetzen. Zweitens bleibt offen, was die Bereinigung genau entfernt, wie ein Befehl als verdächtig erkannt wird und wie lange Google die Daten behält.

Safe Browsing erweiterter Schutz: Datenschutz und übermittelte Daten

Welche Daten Chrome im jeweiligen Modus überträgt, beschreibt die Chrome-Hilfe zu Safe Browsing. Im Standardschutz gleicht Chrome besuchte Adressen mit einer lokalen Liste ab. Ein verschleierter Teil der URL geht über einen Datenschutzserver, außerdem wird eine kleine Menge visueller Merkmale von Seiten geprüft. Im erweiterten Schutz teilt Chrome mehr: besuchte URLs, eine kleine Stichprobe von Seiteninhalten, Downloads, Erweiterungsaktivität und Systeminformationen. Ist ein Google-Konto angemeldet, werden diese Informationen mit dem Konto verknüpft.

Neu sind laut Ankündigung der Seitentext bei starken Betrugsindikatoren und der bereinigte, verdächtige Befehl aus der Zwischenablage. Die Hilfeseite nennt weder eine Speicherdauer noch eine abweichende Behandlung von Unternehmenskonten. Ob verwaltete Profile sich anders verhalten, ist damit nicht belegt.

Aus Datenschutzsicht fallen drei Punkte auf. Die Kopplung an das Google-Konto macht aus technischen Daten potenziell Beschäftigtendaten. Die Zwischenablage kann trotz Bereinigung Inhalte enthalten, die nicht für Dritte bestimmt sind, etwa interne Kennungen oder Teile von Konfigurationen. Und die Erkennungslogik läuft vollständig bei Google, ihre Arbeitsweise ist von außen nicht nachprüfbar.

Für den Standardschutz gilt zusätzlich eine eigene Richtlinie, die den Weg der verschleierten URL-Hashes betrifft. Die Richtliniendefinition SafeBrowsingProxiedRealTimeChecksAllowed erlaubt im Standardmodus das Senden von Teil-Hashes über einen Proxy per Oblivious HTTP und wird ignoriert, wenn Safe Browsing deaktiviert oder auf erweitert gestellt ist. Das zeigt, wie unterschiedlich beide Modi aufgebaut sind. Mehr zu Chrome und Datenflüssen ist im Beitrag über den Inkognito-Modus in Chrome nachzulesen.

Chrome Gemini Betrugserkennung im Unternehmen steuern: SafeBrowsingProtectionLevel

Die zentrale Stellschraube für Admins ist die Richtlinie SafeBrowsingProtectionLevel. Nach der Richtliniendefinition im Chromium-Quelltext gibt es drei Werte:

• 0 (NoProtection): Safe Browsing ist nie aktiv.
• 1 (StandardProtection): Safe Browsing ist immer im Standardmodus aktiv. Das ist die Vorgabe.
• 2 (EnhancedProtection): Safe Browsing ist immer im erweiterten Modus aktiv. Das bringt laut Beschreibung besseren Schutz, erfordert aber, mehr Browsing-Informationen mit Google zu teilen.

Wird die Richtlinie verbindlich gesetzt, können Nutzer die Einstellung nicht ändern. Ist sie nicht gesetzt, arbeitet Chrome im Standardmodus, und Nutzer können den Modus selbst wechseln. Die Richtlinie gilt für Chrome auf Desktop und ChromeOS ab Version 83, für Android ab 87 und für iOS ab 88. Sie lässt sich pro Profil setzen und kann auch nur empfohlen werden.

Weder das Google-Blog noch die Presse erwähnen eine Admin-Steuerung. In den Richtliniendefinitionen im Chromium-Quelltext finden sich im Ordner SafeBrowsing unter anderem Einträge zu Deep Scanning, zu Proxied Real Time Checks und zur Allowlist, aber keiner, der die Zwischenablage-Prüfung ausdrücklich nennt. Das ist ein Befund zum Zeitpunkt der Recherche. Die offizielle Liste unter chromeenterprise.google/policies sowie die Release Notes sind vor der Entscheidung direkt zu prüfen, ebenso die Anzeige unter chrome://policy auf einem Testgerät.

Eine Abgrenzung ist wichtig. Die Richtlinien der Gruppe GenerativeAI betreffen andere Dinge. So steuert GeminiSettings die Verfügbarkeit der Gemini-App-Integration für Nutzer. Dass sie auch die serverseitige Betrugserkennung im Safe Browsing beeinflusst, ist nirgends belegt und wäre eine Annahme. Ebenso steht die Richtlinie SafeBrowsingExtendedReportingEnabled für eine andere Funktion, nämlich Berichte. Sie ist laut Definition veraltet und hat seit Chrome 145 keine Wirkung mehr. Zusätzliche Informationen für Safe Browsing werden seither über den erweiterten Schutz mit SafeBrowsingProtectionLevel aktiviert. Auch das Deep Scanning von Downloads hat eine eigene Richtlinie, SafeBrowsingDeepScanningEnabled.

Der Google-Leitfaden zur Sicherheitskonfiguration von Chrome nennt SafeBrowsingProtectionLevel unter den Richtlinien, die Änderungen durch Nutzer verhindern. Er ist ein älteres Dokument und deckt die neuen Funktionen nicht ab. Der Wortlaut ist vor einer Verwendung in internen Dokumenten zu prüfen.

Bei der Praxis lohnt sich eine nüchterne Prüfung. Eine Richtlinie mit Wert 2 erzwingt den erweiterten Modus. Ob dabei die neuen Funktionen für ein Gerät greifen, hängt von Rollout, Version und Plattform ab. Auch ob die Gemini-Analyse auf Enterprise-Lizenzen, Chrome Browser Cloud Management, Android und iOS gleich anwendbar ist, ist nicht belegt.

Schutz oder Übermittlung: Abwägung für Datenschutz und IT

Für die Entscheidung helfen vier Fragen. Wie hoch ist das Risiko durch ClickFix im eigenen Umfeld? Welche Datenarten gehen konkret an Google? Wie wird die Übermittlung gegenüber Beschäftigten transparent gemacht? Und wie wird die Entscheidung dokumentiert?

Das Risiko ist real: Microsoft bezeichnet die Technik als verbreitet, und sie trifft Büroarbeitsplätze ebenso wie Entwicklerrechner. Der Nutzen des erweiterten Schutzes ist aber nur als Herstellerangabe belegt. Die genannte Zehnfach-Zahl ist eine Angabe von Google und kein unabhängiger Nachweis, dass Schäden verhindert wurden.

Auf der Gegenseite steht die Übermittlung. Der erweiterte Schutz sendet URLs, Stichproben von Inhalten, Downloads, Erweiterungsaktivität und Systeminformationen. Hinzu kommen nun Seitentext und Befehle aus der Zwischenablage. Wer Beschäftigtendaten verarbeitet, muss prüfen, ob die Verarbeitung erforderlich ist und wie sie begründet wird. Für den Beschäftigungskontext gibt Art. 88 DSGVO den Mitgliedstaaten Spielraum. Gibt es einen Betriebsrat, ist früh zu klären, ob eine Mitbestimmung berührt ist.

Die Tabelle ersetzt keine Prüfung des Einzelfalls. Sie zeigt, dass es nicht um „Schutz an“ oder „Schutz aus“ geht, sondern um die Frage, welcher Teil der Daten bei Google verarbeitet werden soll.

Offen ist außerdem die Rolle von Google. Ob Google bei der Chrome-Nutzung im Unternehmen als Verantwortlicher oder als Auftragsverarbeiter auftritt, welche Rechtsgrundlage greift und ob die Verarbeitung vertraglich geregelt ist, lässt sich aus den geprüften Quellen nicht beantworten. Das ist ein Prüfauftrag, etwa mit Blick auf Art. 28 DSGVO und die Vertragsunterlagen der eingesetzten Chrome- oder Workspace-Lizenz. Einen groben Überblick über Datenflüsse bei KI-Funktionen bietet der Beitrag KI und Datenschutz: Wie viel weiß der Assistent.

Für die Dokumentation genügt eine kurze Prüfliste:

• Zweck und Erforderlichkeit der Aktivierung festhalten, einschließlich der betrachteten Alternativen.
• Datenarten aus der Chrome-Hilfe und der Google-Ankündigung auflisten, offene Punkte kennzeichnen.
• Rolle von Google und Vertragsgrundlage prüfen und das Ergebnis ablegen.
• Beschäftigte informieren, gegebenenfalls den Betriebsrat einbinden.
• Eintrag im Verzeichnis der Verarbeitungstätigkeiten ergänzen.
• Prüftermin festlegen, weil sich Funktionen und Richtlinien ändern können.

ClickFix-Schutz über den Browser hinaus

Der Browser warnt, er verhindert nichts. Die eigentliche Ausführung findet im Betriebssystem statt, und dort entscheidet der Nutzer. Ein Schutzkonzept gegen ClickFix besteht deshalb aus mehreren Schichten.

Auf Betriebssystemebene empfiehlt Microsoft in seiner Analyse zu ClickFix, den Ausführen-Dialog zu sperren, wenn er nicht benötigt wird. Der Eintrag RunMRU in der Registry hilft zudem bei der Spurensuche. Wo PowerShell und die Eingabeaufforderung nicht für alle Beschäftigten nötig sind, lassen sie sich einschränken.

Auf Endpunktebene sollten Prozessketten überwacht werden, in denen ein Browser oder der Explorer ein Skript oder ein Systemprogramm startet. Auffällig sind außerdem Befehle, die Dateien aus dem Netz nachladen. Warnungen aus dem Endpunktschutz sollten ausgewertet und nicht nur gesammelt werden. Ein Webfilter reduziert zusätzlich die Zahl der Betrugsseiten, die überhaupt erreichbar sind.

Schließlich bleibt der Mensch. Eine kurze Schulung mit einem einzigen Merksatz hilft: Ein echtes CAPTCHA verlangt nie, einen Befehl einzufügen. Die Hintergründe zu betrügerischen Nachrichten sind in Phishing und die Echtheit elektronischer Nachrichten beschrieben.

Was noch offen ist und wie Admins vorgehen

Nach der Quellenlage sind mehrere Fragen nicht beantwortet:

• Es gibt keine belegte Richtlinie, die nur die Gemini-Prüfung oder nur die Zwischenablage-Prüfung steuert.
• Rollout-Zeitplan und Regionen, auch für die EU, sind nicht genannt.
• Ob sich verwaltete Profile oder Enterprise-Lizenzen anders verhalten, ist nicht belegt. Ebenso offen ist die Anwendung auf Android und iOS.
• Umfang der Bereinigung, Erkennungsmethode und Speicherdauer sind nicht beschrieben.
• Rolle von Google (Verantwortlicher oder Auftragsverarbeiter) und die Rechtsgrundlage für den Unternehmenseinsatz sind nicht belegt.
• Die Quote falscher Warnungen bei der neuen Stufe „verdächtig“ ist nicht veröffentlicht.
• Die Zusicherung zur flüchtigen Verarbeitung und die Zehnfach-Aussage sind nicht unabhängig geprüft.

Für ein vernünftiges Vorgehen reicht eine überschaubare Folge von Schritten. Zunächst sollte der Ist-Zustand erhoben werden: Welche Chrome-Version läuft, und ist SafeBrowsingProtectionLevel gesetzt? Die Anzeige chrome://policy zeigt das auf einem Testgerät. Danach bietet sich eine Pilotgruppe an, etwa die IT oder Entwicklung, in der Enhanced Protection verbindlich gesetzt wird. In dieser Gruppe lässt sich beobachten, welche Warnungen erscheinen und ob legitime Arbeitsabläufe gestört werden.

Parallel sind die Release Notes und die Richtlinienliste unter chromeenterprise.google/policies zu beobachten. Sollte Google künftig eine Einzelsteuerung einführen, verändert das die Abwägung. Zudem ist es sinnvoll, Google schriftlich um Aussagen zur Verarbeitungsrolle, zur Speicherdauer und zur Bereinigung der Zwischenablage zu bitten und die Antwort abzulegen.

Am Ende steht die dokumentierte Entscheidung mit Begründung, Datum und Prüftermin. Ob Enhanced Protection im Unternehmen erzwungen, freigestellt oder ausgeschlossen wird, ist eine Einzelfallentscheidung. Wichtig ist, dass sie bewusst getroffen wird, auf belegten Fakten beruht und sich später nachvollziehen lässt.

Antworten dauern länger und werden oft besser

Eine persönliche Beobachtung steht am Anfang: Seit einigen Wochen brauchen KI-Antworten im Arbeitsalltag spürbar länger als früher, und die Ergebnisse fallen oft besser aus. Gemessene Zahlen dazu liegen nicht vor, es bleibt ein subjektiver Eindruck, den Gespräche mit Kollegen bestätigen. Auffällig ist, dass das Warten kaum noch als Störung empfunden wird, solange die Antwort stimmt.

Hinter diesem Eindruck steckt ein Mechanismus: Die Systeme prüfen und korrigieren ihre Arbeit, bevor sie antworten. Das hilft bei manchen Aufgaben sehr, bei anderen kaum, und es verbraucht Nutzungskontingent.

Wenn Warten zum Qualitätsmerkmal wird

Lange galt bei digitalen Diensten eine einfache Regel: schneller ist besser. Eine Suchmaschine, die erst nach einer Minute antwortet, wäre unbrauchbar. Bei KI-Assistenten gilt diese Regel nur noch eingeschränkt. Eine schnelle Antwort ist bei einer Rückfrage oder einer Umformulierung willkommen. Bei einem Skript, einer Auswertung oder einer Recherche zählt dagegen, ob das Ergebnis stimmt. Dafür wird zunehmend Zeit in Kauf genommen.

Zwei Alltagsbilder helfen bei der Einordnung. Ein Zuruf am Flur ist schnell, ein Gutachten braucht Zeit, und gerade deshalb wird ihm mehr vertraut. Ebenso ist ein Handwerker, der nach der Arbeit einen Probelauf macht, nicht langsamer, sondern gründlicher als einer, der nach zehn Minuten wieder wegfährt. Bei KI-Systemen ist es ähnlich: Wenn erkennbar ist, dass vor der Ausgabe geprüft wurde, steigt das Vertrauen in das Ergebnis, und die Wartezeit wird zum Teil der Leistung.

Die Anbieter reagieren darauf mit Reglern. Bei Claude gibt es Aufwandstufen, die sich je nach Modell und Oberfläche einstellen lassen. Der Nutzer entscheidet also selbst, ob eine Anfrage schnell oder gründlich bearbeitet werden soll. Welche Modelle und Schalter gerade aktuell sind, ändert sich dabei laufend. Der ständige Modell-Wettlauf zwischen GPT, Gemini, Claude und anderen sorgt dafür, dass einzelne Namen schnell veralten. Das Prinzip bleibt davon unberührt.

Warten wird akzeptiert, wenn es einen erkennbaren Grund hat, wenn es steuerbar ist und wenn am Ende ein Ergebnis steht, das sich prüfen lässt.

KI Denkzeit: Was in der Wartezeit passiert

Ein klassisches Sprachmodell erzeugt Wort für Wort eine Antwort, ohne vorher zu überlegen. Sogenannte Reasoning-Modelle gehen anders vor. Diese Modelle erzeugen zunächst Zwischenschritte, die für den Nutzer oft gar nicht oder nur zusammengefasst sichtbar sind, und formulieren erst danach die eigentliche Antwort. Fachleute sprechen davon, dass zur Antwortzeit mehr Rechenaufwand eingesetzt wird (Test-Time Compute). Die KI Denkzeit ist also keine Verzögerung ohne Inhalt, sondern zusätzliche Arbeit vor der Ausgabe.

Die Forschung stützt diese Idee in Grenzen. Eine Arbeit von Snell und Kollegen aus dem Jahr 2024 kommt zu dem Ergebnis, dass zusätzliche Rechenzeit bei der Antwort unter Umständen mehr bringen kann als ein größeres Modell. Entscheidend ist dabei die Schwierigkeit der Aufgabe: Der Effekt hängt davon ab, wie anspruchsvoll die Frage ist. Ein allgemeines Gesetz lässt sich daraus nicht ableiten.

Prüfen vor der Ausgabe

Der eigentliche Kern der Verschiebung ist das Prüfen vor der Ausgabe. Das System erstellt einen Entwurf, führt ihn in einer Testumgebung aus oder vergleicht ihn mit den Anforderungen, korrigiert die gefundenen Fehler und testet erneut. Das wiederholt sich, bis die Prüfung besteht. Erst dann erscheint die Antwort. Die Dokumentation zu Claude Code nennt eine prüfbare Rückmeldung in den Best Practices als wichtigsten Hebel für gute Ergebnisse. Wer dem System ein Kriterium mitgibt, an dem es sich selbst messen kann, erhält verlässlichere Arbeit.

Was als Prüfung gelten kann, hängt von der Aufgabe ab:

• Bei Programmen läuft ein Testlauf in einer abgeschotteten Umgebung. Schlägt er fehl, wird der Fehler gelesen und der Code angepasst.
• Bei Illustrationen und 3D-Dateien wird das Ergebnis gerendert und angesehen. Fehlt ein Teil oder liegt Text über einer Grafik, folgt eine Korrektur.
• Bei Mathematik wird der Rechenweg gegengerechnet oder das Ergebnis eingesetzt.
• Bei Recherchen werden Aussagen mit den gefundenen Quellen abgeglichen.

Ein Selbsttest ist kein Wahrheitsbeweis. Ein Test findet nur das, wofür er gebaut wurde. Ein Programm kann alle Tests bestehen und trotzdem die falsche Aufgabe lösen. Wer sich für das Thema selbstständig arbeitender Systeme interessiert, findet im Beitrag zum Zeitalter der KI-Agenten eine Einordnung. Das Prüfen im Kreis spielt auch dort eine Rolle, und es hängt eng mit der Frage zusammen, wie weit sich Systeme durch eigene Rückmeldung verbessern lassen.

Wo sich das Warten am meisten lohnt

Am stärksten zahlt sich eine längere KI-Bearbeitungszeit bei Aufgaben aus, deren Ergebnis sich prüfen lässt. Die Faustregel lautet: Gibt es ein Kriterium, das sich testen lässt, hilft Zeit. Gibt es keines, hilft sie wenig.

Typische Beispiele aus dem Arbeitsalltag, bewusst allgemein gehalten:

• Programme und Skripte. Ein Skript zur Bereinigung einer Datentabelle läuft zunächst auf Beispieldaten. Findet sich dabei ein Fehler bei Datumsformaten, wird er behoben, bevor das Skript ausgeliefert wird. Wie weit das tragen kann, zeigt der Beitrag zu Agentic Coding.
• Tabellenkalkulation. Formeln lassen sich an Stichproben gegenrechnen. Eine Summe, die nicht zum Einzelwert passt, fällt dann vor der Ausgabe auf.
• Illustrationen und Diagramme. Ein Diagramm, das beim ersten Rendern abgeschnittene Beschriftungen zeigt, wird im zweiten Durchlauf korrigiert. Ohne Blick auf das Ergebnis bliebe der Fehler stehen.
• 3D-Dateien. Ein Modell mit fehlerhaften Flächen oder falschen Maßen lässt sich anzeigen und vermessen, bevor es weitergegeben wird.
• Mathematik und Schlussfolgerungen. Mehrere Bedingungen müssen zugleich erfüllt sein. Das System kann Zwischenergebnisse gegen jede Bedingung prüfen.
• Recherchen. Ein längerer Lauf kann mehrere Quellen lesen, Widersprüche erkennen und Aussagen belegen, statt eine einzelne Fundstelle zu übernehmen.

Das Gegenstück sind Aufgaben ohne prüfbares Kriterium: ein Slogan, eine Idee, ein Tonfall. Hier gibt es nichts, was sich testen ließe. Mehr Denkzeit führt dann nicht automatisch zu einem besseren Ergebnis, sondern manchmal nur zu einem längeren.

Auch nach langem Warten bleibt das Überprüfen von KI-Antworten eine Aufgabe des Menschen. Das gilt besonders bei Zahlen, Quellenangaben und Rechtsthemen. Stichproben genügen oft: Zwei oder drei Angaben nachschlagen, eine Rechnung nachvollziehen, einen Link öffnen. Stimmen die Stichproben, steigt das Vertrauen. Stimmen sie nicht, ist die Stufe oder die Aufgabenstellung zu überdenken.

Aufwandstufen von low bis max: Kontrolle statt Ungewissheit

Die Aufwandstufen sind der wichtigste Regler. Laut der Dokumentation von Anthropic heißen die Stufen low, medium, high, xhigh und max. Die Stufen legen fest, wie viel Aufwand das Modell in eine Antwort steckt. Dazu zählen auch das Nachdenken und die Zahl der Werkzeugaufrufe. Eine niedrige Stufe bedeutet knappere Arbeit, eine hohe Stufe gründlichere.

Die Stufen sind kein fester Zeitplan. Die Dokumentation beschreibt den Aufwand als Verhaltenssignal und nicht als striktes Budget an Rechenschritten. Auch bei niedriger Stufe denkt das Modell bei schwierigen Aufgaben noch nach, nur weniger als bei einer höheren. Die Standardstufe ist je nach Modell verschieden: Bei den meisten dokumentierten Modellen ist es high, bei einzelnen medium. Welche Stufen zur Wahl stehen, hängt zudem von Modell und Oberfläche ab, also davon, ob Programmierschnittstelle, App oder Claude Code genutzt wird. Nicht überall stehen alle fünf zur Verfügung.

Auch andere Anbieter kennen solche Regler. OpenAI beschreibt in der Dokumentation zum Reasoning je nach Modell unterschiedliche Werte, darunter none, minimal, low, medium, high, xhigh und max. Der Zielkonflikt ist derselbe: mehr Gründlichkeit gegen mehr Zeit und mehr Kosten.

Für das Erleben der Wartezeit ist ein Punkt entscheidend. Wer die Stufe selbst gesetzt hat, kennt den Grund für die Dauer. Die lange Antwort ist dann kein unerklärliches Hängen, sondern das Ergebnis einer eigenen Entscheidung. Das ist eine Einordnung und keine gemessene Wirkung, sie passt aber zu dem, was über die Wahrnehmung von Wartezeit bekannt ist.

Warum Menschen gerne länger warten, wenn sie wissen, wofür

Die Nielsen Norman Group beschreibt seit Langem, wie Menschen Wartezeiten bei Software wahrnehmen. Bis etwa zehn Sekunden bleibt die Aufmerksamkeit beim Dialog. Dauert ein Vorgang länger, braucht es sichtbare Rückmeldung, etwa eine Fortschrittsanzeige. Diese zeigt, dass das System nicht abgestürzt ist, gibt einen Anhaltspunkt für die Dauer und macht das Warten weniger frustrierend. Nachzulesen ist das im Artikel Response Times: The 3 Important Limits.

Moderne KI-Assistenten erfüllen diese Rolle teilweise von selbst. Assistenten melden einen Plan, zeigen Prüfschritte und liefern Teilergebnisse. Wer sieht, dass gerade ein Test läuft oder eine Quelle gelesen wird, kann das Warten einordnen. Hinzu kommt das Gefühl von Kontrolle: Die Wahl von Modell und Stufe, sichtbare Arbeitsschritte und die Möglichkeit abzubrechen machen aus passivem Ausharren eine bewusste Entscheidung.

Das ist eine Deutung und kein Nachweis. Eine belastbare Verhaltensstudie dazu, dass Nutzer KI-Wartezeit nachweislich akzeptieren, wurde bei der Recherche nicht gefunden. Die These bleibt deshalb eine Deutung: Wartezeit lässt sich leichter ertragen, wenn sie einen Grund hat und sich beeinflussen lässt.

Wann längeres Denken nicht hilft

So verlockend die Gleichung aus mehr Zeit und besseren Antworten klingt, sie geht nicht immer auf. Die Studie Inverse Scaling in Test-Time Compute hat gezeigt, dass bei bestimmten Aufgaben die Genauigkeit sinkt, wenn das Modell länger nachdenkt. Untersucht wurden konstruierte Aufgaben, etwa Zählen mit ablenkenden Informationen, Vorhersagen mit irreführenden Merkmalen und Schlussfolgerungen mit mehreren Bedingungen. Einzelne Modelle ließen sich bei langem Nachdenken eher von irrelevanten Details ablenken.

Diese Befunde sind mit Vorsicht zu lesen. Es handelt sich um gezielt gebaute Testaufgaben und um bestimmte Modelle zu einem bestimmten Zeitpunkt. Daraus folgt nicht, dass Denkzeit im Alltag schadet. Es folgt nur, dass mehr nicht automatisch besser bedeutet.

Auch die Herstellerdokumentation rät zur Zurückhaltung. Für Claude Sonnet 5.5 und Claude Haiku 5.5 heißt es, xhigh und max seien nur dort sinnvoll, wo eigene Tests einen Qualitätsgewinn zeigen. Für das ältere Modell Claude Opus 4.7 warnt sie deutlicher: Die Stufe max bringe bei den meisten Aufgaben hohe Mehrkosten für einen kleinen Gewinn und könne zu Überdenken führen. Welche Empfehlung gilt, hängt vom Modell ab und ändert sich mit neuen Versionen.

Daraus ergeben sich einfache Faustregeln:

• Einfache Fragen und Umformulierungen erhalten eine niedrige Stufe.
• Schwierige, aber prüfbare Aufgaben erhalten eine höhere Stufe.
• Die oberste Stufe ist keine Standardeinstellung, sondern eine begründete Ausnahme.
• Reicht ein Ergebnis nicht aus, hilft meist eine höhere Stufe oder ein klareres Prüfkriterium, nicht ein immer länger werdender Auftrag.

Nutzungslimit und Modellwahl: Was die Denkzeit kostet

Der Preis zeigt sich im KI Nutzungslimit. Laut der Hilfeseite von Anthropic verbrauchen lange und komplexe Unterhaltungen, bestimmte Funktionen, das gewählte Modell und höhere Aufwandstufen das Kontingent schneller. Bei bezahlten Plänen gibt es ein Sitzungslimit, das sich alle fünf Stunden zurücksetzt, und ein Wochenlimit. Wer häufig lange Läufe mit hoher Stufe startet, spürt das schneller als jemand, der überwiegend kurze Fragen stellt.

Die Hilfeseite nennt dazu praktische Tipps:

• Für Routineaufgaben eine niedrigere Aufwandstufe wählen.
• Erweitertes Denken ausschalten, wenn es nicht gebraucht wird.
• Bei langen Verläufen eine neue Unterhaltung beginnen, weil lange Chats mehr vom Limit verbrauchen.
• Nicht benötigte Verbindungen und Apps trennen, da Werkzeuge viel Verbrauch verursachen.

Bei der Nutzung über eine Programmierschnittstelle wird der Preis als Geld sichtbar. Laut OpenAI sind Reasoning-Tokens, also die Textbausteine des unsichtbaren Nachdenkens, zwar nicht einsehbar, werden aber wie Ausgabe-Tokens abgerechnet. Eine höhere Stufe kostet also auch dann mehr, wenn vom Nachdenken nichts zu sehen ist.

Für die Tarifwahl folgt daraus ein nüchterner Gedanke. Ein teurer Tarif kauft mehr Spielraum für Denkzeit, aber nicht zwangsläufig bessere Antworten. Entscheidend ist das Aufgabenprofil: Wer viele prüfbare, anspruchsvolle Aufgaben bearbeitet, profitiert von einem größeren Kontingent und hohen Stufen. Wer überwiegend Texte glättet und kurze Fragen stellt, zahlt für Reserven, die kaum gebraucht werden. Die Alternative zum teuren Tarif ist die bewusste Modellwahl je Anfrage: ein kleineres, schnelleres Modell für Routine, ein größeres mit hoher Stufe für die schwere Aufgabe.

Konkrete Kontingente und Preise ändern sich häufig und werden hier deshalb nicht als Zahl festgehalten. Maßgeblich sind jeweils die aktuellen Seiten der Hersteller.

Praxis: Modell und Aufwandstufe je Aufgabe wählen

Die folgende Übersicht dient als Einstieg. Die Tabelle ist eine Faustregel und keine Garantie, die Stufen sind je nach Modell und Oberfläche verschieden.

Ein paar Gewohnheiten machen die Wartezeit produktiver:

• Prüfkriterium nennen. Sätze wie „Der Test muss bestehen“ oder „Das Diagramm muss lesbar sein“ geben dem System etwas, woran es sich messen kann.
• Teilergebnisse abnehmen. Bei langen Läufen lohnt eine Zwischenkontrolle, bevor das System in die falsche Richtung weiterarbeitet.
• Stufe erhöhen statt Auftrag verbiegen. Die Dokumentation zum älteren Modell Claude Opus 4.7 rät bei flachem Nachdenken auf schweren Aufgaben, die Stufe anzuheben, statt den Auftrag zu umgehen. Bei neueren Modellen empfiehlt sie, Stufen an eigenen Aufgaben auszuprobieren.
• Stichproben ziehen. Zahlen, Quellen und rechtliche Aussagen werden auch nach langem Warten stichprobenartig geprüft.

Ein Seitenblick auf den Datenschutz

Je länger und selbstständiger ein Assistent arbeitet, desto mehr passiert im Hintergrund. Testumgebung, Websuche und angebundene Werkzeuge verarbeiten möglicherweise mehr Daten und Zwischenergebnisse als eine einzelne Antwort. Vor dem Einsatz mit personenbezogenen Daten ist deshalb zu klären, welche Dienste und Funktionen aktiv sind und ob ein Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO besteht. Das ist ein Hinweis zur Orientierung und keine Rechtsberatung.

Der Gedanke vom Prüfen vor dem Ausliefern gilt übrigens nicht nur für KI. Auch bei Webseiten lohnt der Blick auf das Ergebnis, bevor es online geht, etwa mit dem DSGVO Website Check. Wo Testumgebungen und Web-Auftritte technisch abgesichert werden sollen, bieten die Web Security Checks eine Möglichkeit zur Überprüfung.

Fazit: Die Verschiebung ist eine Frage der Wahl

Die KI Denkzeit verändert die Erwartung an Assistenten. Warten wird akzeptiert, wenn es erklärt, steuerbar und prüfbar ist. Die Wahl der Aufwandstufe ersetzt den Wunsch nach „immer sofort“ durch die Frage, wie viel Gründlichkeit eine Aufgabe verdient. Das Nutzungslimit macht diese Wahl zu einem Budgetthema, bei dem Tarif und Modell zum Aufgabenprofil passen sollten. Und weil auch lange Läufe Fehler enthalten können, muss der Mensch das Ergebnis am Ende selbst gegenprüfen.

Am 21. Oktober 2026 um kurz vor 16 Uhr erschienen Sicherheitsupdates für PHP, die zwei kritische Schwachstellen schließen. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stufte die Lage in einem Sicherheitshinweis mit Kritikalität 3 (Orange) ein. Betreiber sollten demnach unverzüglich handeln. In Deutschland waren zeitweise mehrere Websites nicht erreichbar, weil Betreiber ihre Server vorsorglich vom Internet trennten.

Die Lücken lassen sich auch ohne Fachwissen nachvollziehen: Ein Speicherfehler hinterlässt halbfertige Zustände, die PHP später falsch verarbeitet. Betroffen ist die Laufzeitumgebung, nicht ein einzelnes CMS. Gesichertes, Unbestätigtes und Offenes sind dabei klar zu trennen. Stand der Angaben ist der 22. Oktober 2026, Details können sich ändern.

Am 26.10.2026 wurde bekannt, dass die PHP-Sicherheitslücke erfolgreich ausgenutzt werden konnte. HackerNews berichtet, dass die Ausnutzungsversuche weiter gehen. Schnelles handeln ist also unbedingt erforderlich!

Deutsche Provider haben schnell reagiert

Anhand zweier Beispiele konnte am Tag des Problems nachvollzogen werden, dass deutsche Provider schnell reagierten.

Mittwald war fast schon übervorsichtig und schaltete vorsorglich nicht nur alle Kunden-Webseiten ab, sondern auch seine eigene (mittwald.de). Ein paar Stunden nach der Störung gab es regelmäßige Status-Updates:

Kunden mussten später die richtige PHP-Version (mit dem Patch) in ihrem Kundenkonto auswählen, sofern Mittwald dies nicht automatisch erledigt hatte.

Bei ALL-INKL gab es keinen so langen Shutdown wie bei Mittwald. Auch die ALL-INKL Webseite blieb online.

ALL-INKL Kunden mussten nichts tun. Ihre PHP-Versionen wurden automatisch hochgestuf. Bei ALL-INKL ist es sowieso einfacher als bei Mittwald: Statt der Unterunterversionsnummern (wie 8.2.35) gibt es bei ALL-INKL nur eine Unterversion (8.2) und gut ist. Das funktioniert.

Einen Tag nach dem Spuk meldete ALL-INKL Vollzug:

Die PHP-Sicherheitslücke im Überblick

Es geht um zwei Schwachstellen in der Programmiersprache PHP selbst, nicht in einem einzelnen Content-Management-System. Die Lücken tragen die Kennungen CVE-2026-109618 und CVE-2026-109619. Beide sind nach dem Bewertungssystem CVSS 4.0 (Common Vulnerability Scoring System, eine Skala von 0 bis 10) mit 9,2 als kritisch eingestuft. Das BSI leitet aus den Werten ab, dass für eine Ausnutzung weder eine Anmeldung noch eine Nutzerinteraktion nötig ist. Ziel ist Remote Code Execution (RCE), also die Ausführung fremden Programmcodes auf einem Server aus der Ferne.

In Berichten heißt die PHP-Sicherheitslücke auch PHP2Shell. Laut BSI soll der Name an die Ähnlichkeit mit der Schwachstelle Log4Shell erinnern. Mit der älteren WordPress-Lücke „wp2shell“ hat sie nichts zu tun.

Der zeitliche Ablauf ist durch die Meldungen des PHP-Projekts belegt. Am 20. Oktober 2026 erschien eine Vorankündigung ohne Details. Am 21. Oktober 2026 folgten um 14:00 UTC (16:00 Uhr deutscher Zeit) die Patches und die Advisories. Das BSI schreibt in seinem Sicherheitshinweis des BSI vom 21.10.2026 (Version 1.1) (das Dokument trägt die Kennung BITS-H Nr. 2026-297981-1132, die URL enthält 1032), ein Proof-of-Concept sei öffentlich, bestätigte Ausnutzungen seien noch nicht bekannt. Unbestätigte Berichte über Exploits gebe es jedoch.

Was hinter CVE-2026-109618 und CVE-2026-109619 steckt

Beide Fehler gehören zur Klasse der Speicherfehler. Vereinfacht gesagt, arbeitet PHP mit Speicherbereichen, die pro Anfrage reserviert und danach wieder freigegeben werden. Geht etwas schief, entstehen Zustände, mit denen der weitere Programmablauf nicht rechnet. Genau dort setzen die Lücken an. Die folgende Beschreibung ist bewusst vereinfacht und enthält keine Angriffsdetails.

Bei CVE-2026-109618 beschreibt das PHP-Projekt einen Abbruch bei Speichermangel (Out of Memory). Wird dieser Abbruch ausgelöst, während interne Daten einer Anfrage nur teilweise vorbereitet sind, hinterlässt er ungültige Zustände. Beim anschließenden Aufräumen der Anfrage liest PHP diese Daten und verzweigt darauf. Als Auslöser nennt das Advisory vor allem speicherintensives Verarbeiten von Formular-Uploads (multipart/form-data). Auch große Speicheranforderungen der Anwendung selbst können den Fehler auslösen.

Bei CVE-2026-109619 bleibt dagegen Zustand aus einer früheren Anfrage im sogenannten Worker stehen. Ein Worker ist ein PHP-Prozess, der nacheinander viele Anfragen bedient. Ein späterer Request kann diesen veralteten Zustand verwenden, bevor er zurückgesetzt wird. Es braucht also mindestens zwei Anfragen, die denselben Worker erreichen. Bestätigte Wege sind laut Advisory Diagnosemeldungen zu Einstellungen vor der Initialisierung, der Session-Upload-Fortschritt und bei PHP 8.5 die Funktion fatal_error_backtraces.

Am gefährlichsten ist die Lage bei Apache mit mod_php. Dort wurde ein Exploit demonstriert, bei dem eine nicht angemeldete Anfrage den Angriff auslösen kann, bevor irgendein Anwendungscode läuft. Für PHP-FPM wurde nach dem Advisory ein Teilpfad bestätigt. Was die Lücken im Einzelfall erlauben, hängt von der Umgebung ab. Die Patches setzen den Zustand vollständig zurück und beheben die Ursache.

Welche PHP-Versionen und Systeme betroffen sind

Nach der Bewertung des BSI sind alle bekannten PHP-Versionen betroffen, zurück bis mindestens PHP 5. Behoben sind die Fehler in den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Das PHP-Update 8.5.12 gilt dabei für den neuesten Zweig, die übrigen Nummern für die jeweils älteren, noch unterstützten Zweige.

Für die bereits abgekündigten Zweige 7.4, 8.0 und 8.1 gibt es keine regulären Updates mehr. Das PHP Security Team stellte laut Sicherheitsmeldung minimale Backports im Quellcode bereit. Ein Backport überträgt eine Korrektur in eine ältere Programmversion, ohne die Versionsnummer zu erhöhen. Linux-Distributionen und Anbieter mit verlängerter Unterstützung (LTS) liefern teils eigene Korrekturen aus. Für PHP 8.2 endet die Sicherheitsunterstützung am 31. Dezember 2026. Ein Zweig ohne Unterstützung gilt als End of Life (EOL).

Betroffen sind laut BSI und PHP-Projekt alle PHP-Installationen, die Webanfragen verarbeiten. Genannt werden PHP-FPM (ein Prozessmanager, der PHP für Webserver bereitstellt), Apache mit mod_php (PHP als Modul im Webserver), php-cgi, FrankenPHP und LiteSpeed. Die Aussagen sind nicht ganz einheitlich. Die GitHub-Advisories nennen bei einigen Umgebungen nur einen vermuteten oder nicht validierten Pfad. Als sicher gilt daher nur: Wer PHP für Webseiten betreibt, sollte von einer Betroffenheit ausgehen, bis das Gegenteil geklärt ist.

Zudem betreffen die Schwachstellen die Laufzeitumgebung und keine einzelne Anwendung. Das BSI stellt klar, dass ein Update der Anwendung nicht ausreicht. Zu den auf PHP basierenden Projekten zählt das BSI beispielhaft WordPress, Drupal, TYPO3, Joomla, Magento, Nextcloud, pfSense und OPNsense. Ein WordPress-Update allein behebt die Lücken also nicht, entscheidend ist die PHP-Version auf dem Server.

Wie KI die Lücken fand

Belegt ist, dass KI-Werkzeuge beim Fund eine Rolle spielten. Nach Angabe des BSI waren die Unternehmen Wiz und Calif an der Entdeckung beteiligt. Die Rolle weiterer Beteiligter wie OpenAI bleibt hier offen. Calif beschreibt, dass öffentlich verfügbare Sprachmodelle als Assistenten genutzt wurden, etwa zur Suche nach Umgehungen des Speicherlimits und zur Analyse der Speicherverwaltung. Laut dem Beitrag kamen keine speziellen Testumgebungen oder nicht öffentlich verfügbare Modelle zum Einsatz. Die Autoren betonen zugleich, dass Wissen über das Zielsystem entscheidend blieb. Ein Modell finde nicht einfach „alle Fehler“ durch einen einfachen Auftrag. Calif verweist auf einen Speicherlimit-Fehler in PHP aus dem Jahr 2004 als Vorgeschichte.

Auch Wiz berichtet von einer KI-gestützten Entdeckung. Frontier-Modelle hätten die Hürde gesenkt, Fehler zu einem funktionierenden Exploit zu verketten und diesen an verschiedene PHP-Versionen und Konfigurationen anzupassen. Welche Modelle genau eingesetzt wurden und wie groß der Anteil von Mensch und Maschine war, lässt sich anhand der Herstellerangaben nicht unabhängig prüfen. Beide Beiträge stammen von Beteiligten und sind zugleich Eigenwerbung. Die Angaben sind als Selbstauskunft zu lesen.

Die Zeitangaben zur Entdeckung weichen voneinander ab. Calif nennt den 1. August 2026 für die ersten Funde und den 11. August 2026 für die erste Meldung an PHP. Wiz nennt den 19. August 2026 für die erste entdeckte Lücke und den 24. August 2026 für die Meldung an das PHP-Sicherheitsteam. Beide Darstellungen können nebeneinander stehen, weil mehrere Gruppen unabhängig arbeiteten. Welche Gruppe zuerst meldete, ist anhand der Quellen nicht abschließend zu klären.

Eine Einordnung des Autors: Dieselben Werkzeuge stehen grundsätzlich auch Angreifern zur Verfügung. Das ist eine Bewertung, kein Beleg dafür, dass sie in diesem Fall für Angriffe genutzt wurden.

Patch-Diffing: Wie aus einem Security-Fix ein Exploit werden kann

Der Begriff Patch-Diffing kommt in der BSI-Warnung nicht vor. Er ist hier die fachliche Bezeichnung des Autors für den Vorgang, den das BSI beschreibt. Beim Patch-Diffing werden die Änderungen zwischen der alten und der neuen Programmversion verglichen. Aus dem Unterschied lässt sich ablesen, welche Stelle repariert wurde, und damit, wo die Schwachstelle lag. Bei Open-Source-Projekten wie PHP ist der Patch öffentlich einsehbar, sobald er erscheint.

Das Problem: Ab dem Moment der Veröffentlichung kennen nicht nur Verteidiger die Stelle, sondern auch Angreifer. Wer schneller aus dem Unterschied einen funktionierenden Angriff baut, als Betreiber updaten, gewinnt ein Zeitfenster. KI-Werkzeuge können diese Analyse nach Einschätzung des BSI verkürzen. Das BSI hält eine kurzfristige breite Ausnutzung innerhalb weniger Stunden nach Erscheinen der Patches für „wahrscheinlich“. Zur Begründung schreibt es: „Spätestens seit dem Aufkommen von KI-gestützten Tools zur Exploit-Entwicklung verfügen Akteure über die benötigten Mittel um Patches innerhalb kurzer Zeit zu analysieren und Exploits zu generieren.“

Es ist eine Bewertung des BSI, keine beobachtete Tatsache. Ein konkreter Fall, in dem schädliche KI in diesem Fall Patch-Diffing betrieben hätte, ist in den Quellen nicht belegt. Im Update vom 21. Oktober 2026 hält das BSI wegen der nun verfügbaren technischen Details eine kurzfristige Ausnutzung auf verwundbaren Systemen für wahrscheinlich. In sozialen Medien werde von ersten Angriffsversuchen berichtet, die sich nicht verifizieren ließen.

Für Betreiber folgt daraus eine einfache Regel: Das Zeitfenster zwischen Veröffentlichung eines Patches und dessen Einspielen ist so klein wie möglich zu halten. Nach Einschätzung des Autors war genau dieses Zeitfenster von wenigen Stunden bei einer vorab angekündigten Lücke ein wichtiger Grund für die Abschaltungen. Eine Aussage der Hoster dazu liegt nicht in jedem Fall vor.

Warum Hoster Websites vom Netz nahmen

Das BSI schreibt in Update 1, einige Betreiber von PHP-Webservern hätten im Laufe des Tages Systeme vorsorglich vom Internet getrennt, um Angriffe über die vorübergehend ungepatchten Lücken zu verhindern. Dadurch waren verschiedene Websites in Deutschland zeitweise offline oder nur eingeschränkt erreichbar, bis die betroffenen Server aktualisiert waren. Anbieter von Web Application Firewalls (WAF), also Filtern vor Webanwendungen, darunter Cloudflare und Bunny Shield, veröffentlichten Regeln für die bisher bekannten Angriffspfade. Vollständigen Schutz bieten laut BSI nur Patchen oder Trennen vom Internet.

Als Beispiel taugt der Hoster mittwald. Der Statuseintrag des Anbieters trägt den Titel „Vorsorgliche Einschränkungen aufgrund der aktuellen PHP-Sicherheitslücke“. Er begann am 21. Oktober 2026 um 14:16 Uhr (MESZ) mit der Ankündigung, vorab Formular-Uploads zu deaktivieren. Um 16:17 Uhr schrieb mittwald, eine Gefährdung der Systeme lasse sich nicht ausschließen, daher würden alle Systeme heruntergefahren und der eingehende Web-Traffic blockiert. E-Mail blieb funktionsfähig. Die Patches für PHP 7.2 bis 8.5 waren laut Eintrag um 22:52 Uhr ausgerollt.

Am 22. Oktober 2026 um 00:28 Uhr wurde der Eintrag auf „Gelöst“ gesetzt. Behoben sei die Lücke für nahezu alle betroffenen Versionen, ausgenommen Versionen unter PHP 5.6 ohne offizielle Sicherheitsupdates. Hinweise auf eine Ausnutzung gab es laut mittwald nicht. Zu anderen Hostern liegen keine geprüften Primärquellen vor.

Die Begründung der Abschaltungen ergibt sich aus der Lage. Auf einer Hosting-Plattform laufen viele Kundenprojekte mit unterschiedlichen PHP-Versionen. Jede Variante muss gepatcht, getestet und neu gestartet werden. Das kostet Zeit. Die Lücken lassen sich ohne Anmeldung aus der Ferne ausnutzen, und die Details waren ab dem Veröffentlichungstermin öffentlich. Eine vorübergehende Sperre des eingehenden Verkehrs ist dann die Maßnahme, die laut BSI verlässlich schützt. Ob eine Plattform das tut, ist eine Abwägung zwischen Erreichbarkeit und Risiko. Wie viele Websites insgesamt betroffen waren, ist nicht belegt. Zahlen im Millionenbereich werden in den geprüften Primärquellen nicht belegt.

Was Betreiber von PHP- und WordPress-Websites jetzt tun sollten

Bei Shared Hosting und Managed Hosting liegt die Verantwortung für PHP meist beim Anbieter. Hier hilft ein Blick auf die Statusseite und gegebenenfalls eine Nachfrage beim Support. Dinge, die der Hoster verwaltet, sollten nicht eigenmächtig geändert werden. Wer einen eigenen Server oder virtuellen Server betreibt, muss selbst handeln. Das BSI empfiehlt folgende Schritte:

1. PHP-Version prüfen, auf dem Server mit php -v oder im Hosting-Panel. Bei Linux-Paketen den Stand der Distribution abgleichen, da Korrekturen oft als Backport ohne neue Versionsnummer erscheinen. Ubuntu, Debian und Red Hat veröffentlichen eigene Advisories.
2. Patchen: auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder auf das Paket der Distribution mit Korrektur.
3. Anwendungen in Docker-Containern neu bauen, da dort ein eigenes PHP enthalten ist.
4. Abgekündigte Versionen auf einen unterstützten Zweig migrieren oder bei einem LTS-Anbieter absichern.
5. Falls ein Patch nicht sofort möglich ist: Server vorübergehend vom Internet trennen. Sind weder Patch noch Trennung möglich, mindestens die Workarounds des PHP-Projekts umsetzen.
6. Eine WAF als Ergänzung einsetzen, den Zugriff auf Webanwendungen restriktiv gestalten und Komponenten härten.
7. Logs und Server auf Auffälligkeiten beobachten. Verbindliche Erkennungsmerkmale gibt es laut BSI noch nicht.

Bei den Workarounds nennt das PHP-Projekt unter anderem memory_limit=-1 (möglichst so gesetzt, dass Anwendungen es nicht überschreiben können), ein niedriges post_max_size, session.upload_progress.enabled=0 und bei PHP 8.5 fatal_error_backtraces=0. Danach sind alle Worker neu zu starten. RLIMIT_AS und RLIMIT_DATA sollen nicht als Ersatz dienen.

Warum Workarounds keinen Ersatz für das Update bieten

Das BSI hält in seinem Update zur Lage fest:

Das BSI versteht die Workarounds nur als Überbrückung und verlangt, dass alle zusammen umgesetzt werden. Die Maßnahmen des PHP-Projekts reduzieren die Angriffsfläche, schließen sie aber nicht. Jeder Workaround sperrt einen bestätigten Weg, etwa über Sessions oder Backtraces, andere Varianten bleiben ungeblockt. Beim Speicherlimit-Fehler kann zudem ein Fehlschlag der darunterliegenden Speicherzuweisung den verwundbaren Codepfad weiter erreichen. Das PHP-Projekt schreibt in beiden Advisories, dass nur ein Update mit dem vollständigen Zustandsabgleich zuverlässig schützt.

Die Überbrückung hat trotzdem ihren Sinn, wenn ein Update an organisatorischen Hürden scheitert, etwa bei Software, die nur mit einer alten PHP-Version läuft. Der Weg ist dann als Notlösung zu verstehen, die dokumentiert und zeitlich begrenzt wird. Dauerhafte Sicherheit entsteht erst durch eine unterstützte PHP-Version und ein gepflegtes System.

Was noch offen ist

Bei einer so jungen Lage bleiben viele Punkte ungeklärt. Hilfreich ist die Dreiteilung in belegt, unbestätigt und offen.

• Tatsächliche Ausnutzung: Das BSI kennt keine bestätigten Angriffe, aber unbestätigte Berichte über Exploits und Angriffsversuche. Wie sich das entwickelt, ist offen.
• Veröffentlichungstermin: Das PHP-Projekt behielt sich vor, früher zu veröffentlichen, falls Details bekannt werden. In Medienberichten ist von einem Leak die Rede. Calif und Wiz beschreiben dagegen eine koordinierte Offenlegung. Aus Primärquellen lässt sich ein Leak nicht belegen.
• Zahl betroffener Websites: Wiz schreibt, PHP laufe auf rund 70 Prozent aller Websites, nennt dafür aber keine Quelle. Als gesicherte Zahl taugt das nicht.
• Stand bei einzelnen Hostern: Nur für mittwald liegt eine geprüfte Statusmeldung vor. Bei anderen Anbietern ist der Stand bei Bedarf dort zu erfragen.
• Weitere Varianten: Die Advisories weisen darauf hin, dass es keine vollständige generische Konfigurationsmaßnahme gibt. Weitere Wege sind nicht ausgeschlossen.
• Rolle der KI: Der Einsatz beim Fund ist durch die Hersteller belegt. Der Einsatz durch Angreifer ist eine Bewertung des BSI, kein beobachteter Fall.

Kurz gefasst: Die PHP-Sicherheitslücke ist real, kritisch und seit dem 21. Oktober 2026 durch Updates behoben. Wer PHP selbst betreibt, muss das Update einspielen, der Rest hängt vom Hoster ab. Die Frage nach KI-gestützter Ausnutzung bleibt vorerst eine begründete Befürchtung und kein bewiesener Befund.

Der Grundgedanke: Ein Sprachmodell ist keine Datenbank

Ein weit verbreitetes Missverständnis ist, dass eine KI wie eine riesige Bibliothek funktioniert, in der Fakten gespeichert sind und bei Bedarf herausgesucht werden. Das ist falsch. Ein Sprachmodell (englisch: Large Language Model, kurz LLM) hat kein Nachschlagewerk im Kopf, aus dem es Antworten zitiert.

Stattdessen ist ein Sprachmodell im Kern eine hoch entwickelte Vorhersage-Maschine. Seine einzige eigentliche Aufgabe lautet: Welches Wort (oder genauer: welches Textstück) folgt mit der höchsten Wahrscheinlichkeit auf das, was bisher geschrieben wurde? Alles, was wie Wissen, Argumentation oder Kreativität aussieht, entsteht aus diesem einen Prinzip, angewendet in gigantischem Maßstab.

Jedoch ist damit nicht gemeint, dass KI nicht intelligent sei: Vielmehr arbeitet KI analog zum menschlichen Gehirn und ist in der Lage, aus präsentierten Beispielen selbständig Regeln abzuleiten.

Wie ein Sprachmodell lernt: Das Training

Bevor ein Sprachmodell überhaupt genutzt werden kann, durchläuft es eine aufwendige Trainingsphase. Man kann sich das vereinfacht so vorstellen:

Das Modell liest gigantische Mengen an Text – Bücher, Webseiten, Artikel, Foren-Beiträge und vieles mehr, oft Hunderte Milliarden Wörter. Dabei wird ihm immer wieder eine ähnliche Übung gestellt: Ein Satz wird gezeigt, bei dem das letzte Wort fehlt, und das Modell muss raten, welches Wort dort am wahrscheinlichsten hingehört. Zu Beginn liegt es dabei praktisch immer falsch, denn es startet mit zufälligen internen Einstellungen.

Nach jeder Vorhersage wird verglichen, wie weit die Schätzung vom tatsächlichen Wort entfernt war. Anhand dieser Abweichung werden die internen Einstellungen des Modells – man nennt sie Parameter oder Gewichte – minimal angepasst, damit die nächste Vorhersage etwas besser wird. Moderne Sprachmodelle besitzen mehrere hundert Milliarden solcher Parameter.

Dieser Prozess wird milliardenfach wiederholt. Mit der Zeit lernt das Modell dabei nicht nur einzelne Wörter, sondern auch Grammatik, Fakten, Zusammenhänge, Schreibstile und sogar Argumentationsmuster – einfach dadurch, dass diese Muster im Trainingstext immer wieder vorkommen. Niemand programmiert dem Modell explizit Regeln wie „Nach einem Subjekt folgt oft ein Verb”. Das Modell entdeckt solche Regelmäßigkeiten selbstständig aus den Daten.

Wörter werden zu Zahlen: Tokens und Vektoren

Computer rechnen mit Zahlen, nicht mit Buchstaben. Deshalb wird jeder Text zunächst in kleine Einheiten zerlegt, sogenannte Tokens. Ein Token kann ein ganzes Wort sein, aber auch nur ein Wortteil oder ein einzelnes Zeichen. Das Wort „Sprachmodell” könnte zum Beispiel in die Teile „Sprach” und „modell” zerlegt werden.

Jedes Token wird anschließend in eine lange Liste von Zahlen umgewandelt, einen sogenannten Vektor. Man kann sich das wie eine Art Koordinate in einem extrem vieldimensionalen Raum vorstellen. Wörter mit ähnlicher Bedeutung landen dabei nahe beieinander: Die Vektoren für „König” und „Königin” liegen näher zusammen als die Vektoren für „König” und „Fahrrad”. Auf diese Weise übersetzt das Modell Bedeutung in eine mathematische Form, mit der es rechnen kann.

Die Vorhersage: Ein Wort nach dem anderen

Wenn Sie dem Sprachmodell eine Frage stellen, passiert im Grunde Folgendes: Ihr gesamter Text wird in Tokens zerlegt und in Zahlen übersetzt. Das Modell berechnet daraufhin, welches nächste Token am wahrscheinlichsten passt – und wählt es aus. Dieses neue Token wird an den bisherigen Text angehängt, und der gesamte Vorgang beginnt von vorn: Welches Token folgt jetzt am wahrscheinlichsten?

So entsteht eine Antwort Wort für Wort, praktisch wie ein extrem gut trainiertes Vorhersage-System für die Autovervollständigung auf dem Smartphone – nur unvergleichlich leistungsfähiger und kontextbewusster. Genau diese schrittweise Vorhersage ist auch der Grund, warum Antworten von Chatbots oft sichtbar Wort für Wort oder Satzteil für Satzteil erscheinen.

Aufmerksamkeit zählt: Wie das Modell den Kontext versteht

Eine entscheidende technische Neuerung, die moderne Sprachmodelle so leistungsfähig macht, nennt sich Aufmerksamkeitsmechanismus (Attention). Vereinfacht gesagt sorgt dieser Mechanismus dafür, dass das Modell bei jedem neuen Wort abwägt, welche der vorherigen Wörter im Text gerade besonders wichtig sind.

Ein Beispiel: Im Satz „Die Katze jagte die Maus, weil sie hungrig war” muss das Modell erkennen, dass sich „sie“ auf die Katze bezieht, nicht auf die Maus. Der Aufmerksamkeitsmechanismus erlaubt es dem Modell, genau solche Bezüge über einen ganzen Text hinweg zu berücksichtigen, statt Wörter isoliert zu betrachten. Dadurch kann ein Sprachmodell auch bei langen, komplexen Texten den roten Faden im Blick behalten.

Warum es wirkt, als würde die KI „denken”

Wenn man ein so trainiertes System groß genug macht und mit genügend Text füttert, entstehen Fähigkeiten, die zunächst überraschend wirken: Das Modell kann Gedichte schreiben, Programmcode debuggen, mathematische Aufgaben lösen oder komplexe Sachverhalte erklären. Fachleute sprechen hier von emergenten Fähigkeiten – Eigenschaften, die bei kleineren Modellen kaum vorhanden waren, mit wachsender Größe aber plötzlich auftauchen.

Der Grund dafür ist letztlich, dass menschliches Wissen, menschliche Logik und menschliche Argumentationsweisen tief in der Sprache selbst verankert sind, die das Modell gelesen hat. Wer gelernt hat, extrem gut vorherzusagen, wie ein kompetenter Mensch einen Sachverhalt fortsetzen würde, erzeugt dadurch Texte, die wie durchdachtes Denken wirken – auch wenn im Inneren des Modells kein Bewusstsein, keine Absicht und kein Verständnis im menschlichen Sinne vorhanden ist. Es handelt sich um eine äußerst raffinierte Mustererkennung und -fortsetzung, nicht um Denken im eigentlichen Sinn.

Die Grenzen: Was ein Sprachmodell nicht kann

Damit Sie mit KI-Werkzeugen souverän umgehen können, lohnt sich ein Blick auf die wichtigsten Grenzen:

Kein echtes Verständnis und kein Bewusstsein. Ein Sprachmodell versteht Inhalte nicht so, wie ein Mensch es tut. Es erkennt statistische Zusammenhänge zwischen Wörtern, hat aber kein inneres Erleben, keine eigenen Überzeugungen und keine Absichten. Die statistische Komponente ist beim Menschen allerdings genauso vorhanden! KI-Roboter können demnach ein Bewusstsein oder Weltverständnis entwickeln wie der Mensch.

Halluzinationen. Da ein Sprachmodell grundsätzlich Wahrscheinlichkeiten vorhersagt und keine Fakten nachschlägt, kann es mit großer sprachlicher Sicherheit falsche Informationen produzieren. Solche Halluzinationen entstehen, weil das Modell an dieser Stelle einen plausibel klingenden, aber inhaltlich falschen Text als wahrscheinlichste Fortsetzung berechnet hat.

Begrenzter Wissensstand. Ohne Zugriff auf aktuelle Datenquellen kennt ein Sprachmodell nur das, was bis zu einem bestimmten Stichtag im Training vorhanden war. Über neuere Entwicklungen weiß es von sich aus nichts.

Übernommene Verzerrungen. Da das Modell aus menschengeschriebenen Texten lernt, kann es auch Vorurteile, Einseitigkeiten oder Fehler übernehmen, die in diesen Texten enthalten waren.

Praktische Tipps für den Umgang mit KI

• Wichtige Fakten überprüfen. Verlassen Sie sich bei entscheidungsrelevanten Informationen nicht blind auf die Antwort eines Sprachmodells, sondern gleichen Sie diese mit verlässlichen Quellen ab.
• Präzise formulieren. Je klarer und konkreter Ihre Frage oder Anweisung, desto passender fällt in der Regel die Antwort aus, da das Modell weniger raten muss.
• Kontext mitgeben. Da das Modell keinen Zugriff auf Ihr Vorwissen hat, hilft es, relevante Hintergrundinformationen direkt in die Anfrage aufzunehmen.
• Gesunde Skepsis bewahren. Eine selbstbewusst klingende Antwort ist kein Beweis für ihre Richtigkeit – gerade bei Zahlen, Zitaten oder Fachdetails lohnt sich ein zweiter Blick.

Fazit

Ein Sprachmodell trifft Vorhersagen. Tut der Mensch nichts anderes? Es sieht so aus. Auf Basis von Milliarden Textbeispielen hat die KI gelernt, mit erstaunlicher Treffsicherheit das nächste passende Wort zu berechnen, und daraus entstehen Texte, die verblüffend durchdacht wirken können.

Wer versteht, dass hinter der Intelligenz in Wahrheit hochentwickelte Mustererkennung steckt, kann die Stärken solcher Werkzeuge gezielt nutzen und ihre Grenzen realistisch einschätzen. Genau dieses Verständnis ist der Schlüssel zu einem souveränen und kritischen Umgang mit künstlicher Intelligenz im Alltag.

Insbesondere können konkrete Aufgabenstellungen (im Unternehmen) sehr gut mit einer spezialisierten KI gelöst werden: Viel besser als dies mit ChatGPT oder anderen Frontiermodellen möglich ist – weil Cloud KI eben generisch ist und nicht auf konkrete Aufgaben geprägt wurde.

Der HTML Viewer löst dieses Problem vollständig. Kostenlos, ohne Registrierung, direkt im Browser.

Was ist der HTML Viewer?

Der HTML Viewer ist ein browserbasiertes Entwicklungswerkzeug, das einen Code-Editor und eine Live-Vorschau Seite an Seite kombiniert. Was links eingegeben wird, erscheint sofort rechts – ohne Ladezeiten, ohne Seitenaktualisierung, ohne Ablenkung.

Das Besondere: Das Tool läuft vollständig serverseitig abgesichert und benötigt weder Installation noch Account. Die URL wird aufgerufen, HTML wird eingegeben – und die Vorschau erscheint live.

Die Features im Überblick

Live Preview – Sofort sehen, was entsteht

Das Herzstück des Tools ist die Echtzeit-Vorschau. Der Editor auf der linken Seite und das Vorschaufenster auf der rechten sind permanent synchronisiert. Jede Änderung wird unmittelbar gerendert.

Das klingt simpel – ist aber in der Praxis ein enormer Produktivitätsgewinn. Gerade bei der Arbeit mit Layouts, Farben, Typografie oder Animationen ist das direkte visuelle Feedback unersetzlich. Zusammenhänge werden schneller verstanden, Experimente können spontan durchgeführt werden.

Die Vorschau ist in einem abgesicherten iframe eingebettet, sodass auch komplexere HTML-Dokumente mit eigenem JavaScript zuverlässig und sicher gerendert werden.

Markdown-Unterstützung – Direktes Rendering im Vorschaufenster

Der HTML Live Viewer erkennt automatisch, ob im Editor HTML oder Markdown eingegeben wurde. Wird Markdown erkannt, wird es serverseitig in sauber formatiertes HTML umgewandelt und direkt im Vorschaufenster gerendert – inklusive Überschriften, Listen, Tabellen, Code-Blöcken und Blockquotes in einem ansprechenden Lesestil.

Eine blaue Hinweisleiste oberhalb der Vorschau zeigt an, wenn Markdown erkannt wurde, und stellt dort direkt die Export-Optionen bereit.

Beautify – Unlesbaren Code sofort strukturieren

Minifizierter oder unformatierter HTML-Code – eine einzige lange Zeile, keinerlei Einrückung, alles zusammengepresst – ist eine häufige Herausforderung in der täglichen Arbeit.

Die Beautify-Funktion des HTML Live Viewers verwandelt solchen Code mit einem Klick in sauber eingerückten, lesbaren Quelltext. Das gilt nicht nur für HTML, sondern auch für eingebettetes JavaScript und SVG-Markup. Ideal für Code-Reviews, Debugging, das Verstehen fremder Codebases sowie die Aufbereitung von maschinell generiertem Markup.

Minify – Code komprimieren auf Knopfdruck

Der umgekehrte Weg: Die Minify-Funktion entfernt alle überflüssigen Leerzeichen, Kommentare und Zeilenumbrüche und reduziert HTML, JavaScript und SVG auf das absolute Minimum. Das Ergebnis ist kompakter Code, der schneller übertragen wird – wichtig für Performance-Optimierungen und Produktionsumgebungen.

Beide Funktionen arbeiten direkt im Editor, ohne dass eine externe Website aufgerufen oder Code manuell kopiert werden muss.

Automatische Kontrastverbesserung nach WCAG-Standard

Ein Feature, das in vergleichbaren Tools selten zu finden ist: Mit einem einzigen Klick analysiert der HTML Live Viewer die im Dokument verwendeten Farben und passt sie automatisch so an, dass die Anforderungen des WCAG-Standards (Web Content Accessibility Guidelines) erfüllt werden. Dabei werden sowohl direkte Farbattribute als auch Inline-CSS-Regeln berücksichtigt und angepasst.

Das macht den Viewer zu einem wertvollen Werkzeug nicht nur für die Entwicklung, sondern auch für die barrierefreie Gestaltung von Webinhalten – ohne manuelles Nacharbeiten einzelner Farbwerte. Gerade in regulierten Branchen oder bei öffentlich zugänglichen Webangeboten, wo Barrierefreiheit gesetzlich gefordert wird, spart dieses Feature erheblichen Aufwand.

Vollbildmodus – Die Vorschau ohne Ablenkung

Mit dem Vollbild-Button öffnet sich die aktuelle Vorschau in einem neuen Browser-Tab – als vollständig gerenderte, eigenständige Seite. Ohne Editor-Umgebung, ohne Werkzeugleiste, nur das Ergebnis.

Besonders nützlich ist dieser Modus für Präsentationen oder zur Prüfung, wie sich ein Layout auf einem großen Bildschirm verhält.

Zoom-Faktor – Vorschau skalieren wie gewünscht

Der integrierte Zoom-Schieberegler erlaubt es, die Vorschau von 25 % bis 200 % zu skalieren. So lässt sich prüfen, wie ein Layout auf sehr kleinen Screens aussieht – oder es wird hineingezoomt, um Details in der Darstellung zu begutachten.

Das ist kein Browser-Zoom, der die gesamte Seite vergrößert, sondern ein gezieltes Skalieren der Vorschaufläche. Ein wichtiger Unterschied, der volle Kontrolle über Maßstab und Kontext ermöglicht.

Hintergrundfarbe anpassen – Kontext ist alles

Wer HTML-Fragmente oder transparente SVGs entwickelt, kennt das Problem: Eine weiße Komponente auf weißem Hintergrund ist unsichtbar. Der HTML Live Viewer bietet eine Hintergrundfarb-Steuerung direkt in der Werkzeugleiste.

Mit einem Klick wechselt man zwischen vordefinierten Farben oder wählt per Farbwähler exakt die Hintergrundfarbe, die dem Ziel-Kontext entspricht.

Screenshot-Export – Vorschau als PNG speichern

Der Screenshot-Button rendert die aktuelle Vorschau serverseitig mit Chromium und gibt sie als hochwertige PNG-Datei zurück. Breite und Höhe des Screenshots sind frei wählbar – zusätzlich stehen vier Schnellauswahl-Presets bereit: HD (1280 × 720), Full HD (1920 × 1080), 2K (2560 × 1440) und 4K (3840 × 2160).

Das Ergebnis ist pixelgenau und entspricht dem, was ein echter Chrome-Browser rendert – unabhängig vom Zoom-Level des Editors.

Besonders durchdacht: Enthält der HTML-Code CSS-Animationen, lässt sich per Schalter wählen, ob diese für den Screenshot eingefroren werden sollen (sofortiger Stillstand per injiziertem CSS), ob zwei Sekunden gewartet wird bis die Animationen einen definierten Zustand erreicht haben, oder ob der Screenshot ohne Eingriff erfolgt. So wird das Rendering-Ergebnis immer kontrollierbar.

PDF-Export – direkt aus dem Tool

Sowohl aus dem Screenshot-Dialog als auch beim Markdown-Export kann das Ergebnis als PDF gespeichert werden. Für HTML-Inhalte wird das serverseitig gerenderte Chromium-Bild direkt in ein PDF überführt. Für Markdown-Dokumente stehen zusätzlich Word (.docx) und OpenDocument (.odt) als Exportformate bereit – ohne externe Tools, ohne Umwege.

Diese Kombination macht den HTML Live Viewer zu einer vollständigen Ausgabe-Pipeline: von der Eingabe über die Vorschau bis zum druckfertigen Dokument.

Kopieren und Download – Direkt weiterarbeiten

Neben der visuellen Arbeit bietet der Editor zwei praktische Hilfsfunktionen: Kopieren überträgt den gesamten Code mit einem Klick in die Zwischenablage. Download speichert ihn als .html-Datei. Keine Umwege, keine zusätzlichen Schritte.

HTML Live Viewer als Teil einer AI-Chain

Hier liegt eines der spannendsten Einsatzgebiete des Tools: als Glied in einer KI-gestützten Arbeitskette.

Moderne KI-Modelle wie Claude, GPT oder Gemini generieren auf Anfrage vollständiges, lauffähiges HTML – Landingpages, Formulare, Visualisierungen, Infografiken, interaktive Widgets. Die Qualität ist oft beeindruckend. Die Frage ist: Wie wird das Ergebnis schnell und zuverlässig überprüft?

Der HTML Live Viewer ist dafür die ideale Zwischenstation:

1. KI generiert HTML- oder Markdown-Code
2. Code in den HTML Live Viewer einfügen
3. Sofortige visuelle Überprüfung im Live Preview
4. Optional: Beautify für bessere Lesbarkeit, Anpassungen vornehmen
5. Kontrastprüfung per WCAG-Funktion auf Knopfdruck
6. Screenshot (PNG oder PDF) für Dokumentation oder Weitergabe
7. Export als Word oder ODT bei Markdown-Inhalten
8. Download für den nächsten Schritt in der Pipeline

Kein Umweg über lokale Dateien, kein Einrichten einer Entwicklungsumgebung, kein Browser-Tab-Chaos. Der Viewer wird zur visuellen Validierungsstation in einem vollständig browserbasierten Workflow.

Das gilt auch für SVG-Generierung: KI-Modelle erzeugen immer häufiger komplexe SVG-Grafiken. Mit dem HTML Live Viewer und der eingebauten Hintergrundfarb-Steuerung können diese sofort auf ihre Korrektheit geprüft, skaliert und exportiert werden.

Extra: DSGVO Quick Check

Mit einem Klick wird der im HTML Viewer von Ihnen hinterlegte Quellcode auf Datenschutzprobleme hin geprüft. Das erscheint umso wichtiger, weil immer mehr Code von KI produziert wird. Das Ergebnis stellt sich so dar:

Ein (ebenfalls kostenfreier) umfangreicherer Check kann durch Klick auf den Button im Screen gestartet werden.

Kostenlos – ohne Registrierung, ohne Konto

Der HTML Live Viewer ist vollständig kostenlos nutzbar. Eine Registrierung ist nicht erforderlich, kein Account, keine E-Mail-Adresse. Die URL wird aufgerufen – und die Arbeit kann sofort beginnen.

Weitere kostenlose Tools

Das Wichtigste in Kürze

• Eine Einwilligung brauchen Sie, sobald Ihre Website Informationen auf dem Endgerät speichert oder dort ausliest und das nicht unbedingt erforderlich ist. Das betrifft Cookies, aber auch Local Storage und Browser-Fingerprinting. Ebenso ist eine Einwilligung erforderlich für die Auswertung von Benutzerinformationen zur weitergehenden Verhaltensanalyse (Tracking).
• Ein Consent-Tool macht eine Website nicht automatisch datenschutzkonform. Entscheidend ist, was tatsächlich vor der Zustimmung geladen wird.
• Die beste Einwilligung ist die, die Sie nicht brauchen. Viele Dienste lassen sich durch datenschutzfreundliche Alternativen ersetzen, dann entfällt das Banner.
• Prüfen Sie Ihre Website selbst, statt sich auf Versprechen von Anbietern zu verlassen.

Wann eine Einwilligung nötig ist

Maßgeblich sind zwei Gesetze. § 25 TDDDG (früher TTDSG) regelt jeden Zugriff auf das Endgerät, also das Speichern und Auslesen von Informationen. Ohne Einwilligung ist das nur erlaubt, wenn es unbedingt erforderlich ist, damit ein ausdrücklich gewünschter Dienst funktioniert. Die DSGVO regelt zusätzlich die Verarbeitung personenbezogener Daten, die dabei entstehen. Welche Cookies ohne Zustimmung erlaubt sind, erklärt Cookies und das TDDDG: Welche Cookies sind ohne Einwilligung erlaubt?. Wo die Grenze der technischen Notwendigkeit verläuft, zeigt Website-Cookies: Was darf ohne Zustimmung verwendet werden?.

Ob Cookies überhaupt personenbezogene Daten sind, ist für Bußgelder entscheidend: Cookies: Persönliche Daten oder nicht?. Dieselben Regeln gelten für Techniken ohne Cookie, etwa Browser-Fingerprinting. Nicht jeder Dateiabruf ist dagegen wie ein Cookie zu behandeln: Sind Dateiabrufe auf Webseiten wie Cookies zu behandeln?. Selbst Sicherheits-Cookies sind nicht automatisch erlaubt, wie das Beispiel CSRF-Cookies zeigt. Eine Übersicht für gängige Dienste bietet die Checkliste für Webseiten-Tools: Wann ist eine Einwilligung notwendig?.

Den Wortlaut der Vorschrift mit Erläuterungen finden Sie unter § 25 TDDDG: Schutz der Privatsphäre bei Endeinrichtungen.

Welche Cookies setzt Ihre Website?

Bevor Sie über ein Banner entscheiden, sollten Sie wissen, was Ihre Website tatsächlich speichert und lädt. Die Anleitung: Alle Cookies finden, die eine Webseite nutzt führt Schritt für Schritt durch die Prüfung im Browser. Grundlagen und verbreitete Irrtümer erklären Cookies: Grundlagen, Fakten und häufige Fehlinformationen und Cookies und Datenschutz: Die unsichtbare Gefahr im Netz.

Welche Cookies und Dienste lädt Ihre Website, bevor jemand zustimmt? Der kostenlose Website-Check zeigt es in wenigen Sekunden. Jetzt Website prüfen

Consent-Tools: Was sie leisten und was nicht

Consent-Management-Plattformen versprechen, Dienste bis zur Zustimmung automatisch zu blockieren. In der Praxis laden Browser viele Dateien parallel, und ein Tool, das selbst erst geladen werden muss, kommt oft zu spät. Warum das so ist, zeigen Consent-Management-Plattformen: Wie zuverlässig sind Cookie-Tools? und Cookie-Popups: Fünf Gründe, warum sie nicht funktionieren können. Wie verbreitet das Problem ist, belegt der Test Cookiegeddon: Das Versagen aller Consent-Tools.

Ob Ihr eigenes Tool korrekt arbeitet, lässt sich prüfen: Consent-Tools auf Webseiten: So prüft man, ob sie DSGVO-konform sind. Zu einzelnen Anbietern gibt es Praxistests:

• Borlabs Cookie: Testbericht und Empfehlungen
• Usercentrics: Praxistest des Consent-Tools
• OneTrust: Consent-Tool mit großen Tücken
• Cookiebot: Haftung des Website-Betreibers und fehlender AVV

Einwilligung richtig einholen

Wenn Sie eine Einwilligung brauchen, muss sie freiwillig, informiert und vor dem ersten Zugriff erteilt werden. Was dazu gehört, fasst die Checkliste für rechtssichere Einwilligungsabfragen zusammen. Wie verständliche Beschreibungen aussehen und wie es nicht geht, zeigt Cookie-Popups: Die besten Cookie-Beschreibungen. Ein häufiger Fehler ist ein Tag Manager, der schon vor der Zustimmung lädt: Google Tag Manager erst nach Einwilligung laden.

Zentrale Einwilligungsverwaltung (PIMS, § 26 TDDDG)

Statt auf jeder Website einzeln zuzustimmen, sollen Besucher ihre Einstellungen an zentraler Stelle hinterlegen. Grundlage ist § 26 TDDDG, der anerkannte Dienste zur Einwilligungsverwaltung vorsieht. Wie das funktionieren soll und welche Fragen offen sind, beschreibt der Beitrag Das Ende der Cookie-Popups?.

Für Betreiber ändert sich dadurch wenig: Wer auf das Endgerät zugreift und das nicht unbedingt braucht, muss weiterhin vorher wirksam einwilligen lassen. Warum das Konzept rechtlich und technisch kaum tragen kann, zeigen diese Beiträge:

• Zentrale Einwilligungsverwaltung (PIMS): 66 Gründe, warum diese Datenschutz-Idee scheitern wird
• Warum eine zentrale Einwilligungsverwaltung in der Praxis nicht funktionieren kann
• Die verkürzte Einwilligung nur in Cookies: PIMS ist nicht zu Ende gedacht
• Einwilligungsverwaltungs-Verordnung: Warum Einwilligungen nach Kategorien nicht funktionieren
• Das neue TDDDG: Dienste zur Einwilligungsverwaltung helfen dem Datenschutz nicht

Der bessere Weg: Dienste, die keine Einwilligung brauchen

Jedes Banner kostet Vertrauen und Besucher, und jede Einwilligung ist ein Rechtsrisiko, wenn sie fehlerhaft eingeholt wird. Oft lässt sich beides vermeiden. Datenschutzfreundliche Website-Tools: kostenlos und DSGVO-konform stellt Alternativen zu verbreiteten Diensten vor. Für Besucherstatistiken eignet sich Matomo ohne Einwilligung, Schriften lassen sich lokal einbinden (Google Fonts), Videos über ein Vorschaubild (YouTube).

Wer dennoch eine Abfrage braucht, findet ein kostenloses Consent-Tool zum Download mit Anleitung zur Einbindung. Warum die politische Debatte über die Abschaffung von Cookie-Bannern das Problem nicht löst, erklärt Cookie-Banner sollen abgeschafft werden. Wie wenig Ablehnen und Privatmodus die Besucher tatsächlich schützen, zeigen Cookie-Abfrage abgelehnt oder Privatmodus genutzt und Das Ende der Cookie-Blocker.

Wie Sie eine Website von Anfang an so aufbauen, dass kaum Einwilligungen nötig sind, zeigt der Schnellstart für datenschutzfreundliche Webseiten.

Prüfliste für Ihre Website

1. Erfassen Sie alle Cookies, Speicherzugriffe und externen Dienste, die beim ersten Aufruf geladen werden.
2. Prüfen Sie für jeden Eintrag, ob er für den vom Besucher gewünschten Dienst unbedingt erforderlich ist.
3. Ersetzen oder entfernen Sie Dienste, die eine Einwilligung brauchen, wo immer es geht.
4. Falls eine Einwilligung bleibt: Kontrollieren Sie, dass vor der Zustimmung nichts davon lädt, auch nicht der Tag Manager.
5. Formulieren Sie die Beschreibungen in der Abfrage so, dass Laien sie verstehen.
6. Wiederholen Sie die Prüfung nach jedem Update von Theme, Plugins oder eingebundenen Diensten.

Welche Cookies und Dienste lädt Ihre Website, bevor jemand zustimmt? Der kostenlose Website-Check zeigt es in wenigen Sekunden. Jetzt Website prüfen

Häufige Fragen

Diese Übersicht wird ergänzt, sobald neue Beiträge zum Thema erscheinen.

Was Ihr KI-Assistent über Sie sammelt

Vor der Betrachtung der technischen Verarbeitung, lohnt sich ein Blick auf die Datenkategorien, die bei der Nutzung eines KI-Assistenten grundsätzlich anfallen:

• Kontoinformationen: Name, E-Mail-Adresse, gegebenenfalls Zahlungsdaten bei kostenpflichtigen Abonnements.
• Gesprächsverläufe: der vollständige Inhalt Ihrer Eingaben und der generierten Antworten, häufig über mehrere Sitzungen hinweg gespeichert.
• Metadaten: Zeitstempel, verwendetes Gerät, Browsertyp, ungefährer Standort über die IP-Adresse, Spracheinstellungen.
• Nutzungsverhalten: welche Funktionen Sie wie häufig nutzen, wie lange Sie interagieren, welche Antworten Sie positiv oder negativ bewerten.
• Freiwillig preisgegebene Inhalte: hochgeladene Dokumente, Bilder oder verknüpfte Kalender- und E-Mail-Konten, sofern Sie entsprechende Funktionen aktivieren.

Diese Liste allein wäre schon Grund genug für Zurückhaltung. Das eigentlich Bemerkenswerte spielt sich jedoch nicht in einem einzelnen System ab, sondern in einer ganzen Kette von Diensten, die bei jeder einzelnen Anfrage durchlaufen wird.

Die unsichtbare Tool-Chain: Was bei jedem Prompt tatsächlich passiert

Viele Menschen stellen sich ein KI-Sprachmodell als eine einzelne, in sich geschlossene „Blackbox" vor: Eingabe rein, Antwort raus. In Wirklichkeit durchläuft praktisch jede Anfrage bei kommerziellen KI-Anbietern eine mehrstufige Verarbeitungskette, an der zahlreiche unterschiedliche Systeme beteiligt sind – von denen die wenigsten Nutzer je etwas mitbekommen. Diese Grundarchitektur ist weitgehend unabhängig davon, welcher konkrete Anbieter oder welches Modell im Hintergrund arbeitet, und bleibt auch dann bestehen, wenn sich einzelne Produkte oder Modellversionen ändern.

1. Vorverarbeitung und Tokenisierung

Noch bevor ein Sprachmodell Ihre Anfrage „liest", wird der Text in kleinere Einheiten (sogenannte Tokens) zerlegt. Diese Vorverarbeitung entscheidet mit, wie Ihre Formulierungen technisch interpretiert werden, und läuft in aller Regel über eigene Systeme, getrennt vom eigentlichen Modell. Bereits an dieser Stelle wird technisch protokolliert, was Sie eingegeben haben.

2. Sicherheits- und Moderationsfilter

Praktisch jeder ernstzunehmende KI-Anbieter schaltet vor und nach dem eigentlichen Modellaufruf automatisierte Klassifikatoren, die Eingaben und Ausgaben auf problematische Inhalte prüfen. So können oft Gewaltdarstellungen, sexualisierte Inhalte oder Anleitungen zu gefährlichen Handlungen erkannt werden. Diese Klassifikatoren sind eigenständige Systeme, die Ihren Prompt zusätzlich zum eigentlichen Sprachmodell analysieren. Das bedeutet: Ihr Text wird nicht nur einmal, sondern gleich mehrfach von unterschiedlichen Modellen „gelesen", bevor überhaupt eine Antwort entsteht.

3. Kontext- und Gedächtnissysteme

Viele moderne Assistenten verfügen über Funktionen, die sich frühere Gespräche oder hinterlegte Vorlieben „merken", um Antworten zu personalisieren. Dafür werden Inhalte aus vergangenen Sitzungen in separaten Datenbanken abgelegt und bei jeder neuen Anfrage automatisch wieder abgerufen und in den Kontext eingespeist.

Diese Gedächtnisfunktion ist praktisch, bedeutet aber auch, dass Informationen aus einem Gespräch vor Wochen unbemerkt in ein aktuelles Gespräch einfließen können.

4. Werkzeug- und Funktionsaufrufe

Sobald ein Assistent auf externe Werkzeuge zugreift (etwa eine Websuche durchführt, einen Taschenrechner nutzt, eine Verbindung zu einem Kalender herstellt oder eine Anfrage an einen Drittanbieter-Dienst weiterleitet), verlässt ein Teil Ihrer Anfrage die Infrastruktur des eigentlichen KI-Anbieters. Eine Suchanfrage, die im Zuge Ihres Prompts automatisch generiert wird, landet bei einer Suchmaschine; eine Kalenderabfrage bei einem weiteren Dienst. Jede dieser Stationen kann eigene Protokolle führen, die Sie als Nutzerin oder Nutzer in der Regel nicht direkt einsehen können.

5. Modellinferenz auf verteilter Infrastruktur

Die eigentliche Berechnung der Antwort erfolgt selten auf einem einzelnen Server, sondern verteilt über große Rechenzentren, häufig betrieben von spezialisierten Cloud-Anbietern. Selbst wenn ein KI-Unternehmen sein Modell selbst entwickelt, läuft die Infrastruktur oft bei einem externen Cloud-Anbieter – ein weiterer Subunternehmer, der technisch Zugriff auf die verarbeiteten Daten hat, auch wenn er vertraglich zur Vertraulichkeit verpflichtet ist.

6. Nachbearbeitung und Ausgabefilter

Auch nach der eigentlichen Texterzeugung ist der Prozess nicht beendet. Die generierte Antwort durchläuft häufig weitere Filterstufen, etwa zur Formatierung, zur nochmaligen Sicherheitsprüfung oder zur Zitationsprüfung bei Suchergebnissen. Erst danach erreicht der Text Ihren Bildschirm.

7. Protokollierung, Analyse und Qualitätssicherung

Parallel zur eigentlichen Antwortgenerierung speisen viele Systeme Nutzungsdaten in Analyse-Pipelines ein: Wie lange hat die Anfrage gedauert, wie hat das System reagiert, gab es Fehler oder ungewöhnliche Muster. Diese Protokolle dienen primär der technischen Qualitätssicherung, enthalten aber häufig auch Metadaten zu Ihrer Anfrage und mitunter Ausschnitte des Gesprächsinhalts.

Der entscheidende Punkt dieser Beschreibung ist nicht, dass jede einzelne Station böswillig agiert – die meisten dieser Systeme existieren aus legitimen technischen oder Sicherheitsgründen. Relevant ist vielmehr die schiere Anzahl der Stationen: Jede zusätzliche Verarbeitungsstufe ist ein weiterer Punkt, an dem Daten gespeichert, protokolliert, mit anderen Diensten geteilt oder im Fehlerfall versehentlich offengelegt werden können. Eine einzelne Anfrage an einen KI-Assistenten kann so, ohne dass Sie es bemerken, mehrere Unternehmen und Dutzende Server durchlaufen.

Cloud-Verarbeitung versus lokale Verarbeitung

Ein weiterer, oft übersehener Aspekt betrifft den Ort der Verarbeitung. Die weit überwiegende Mehrheit kommerzieller KI-Assistenten verarbeitet Ihre Anfragen in der Cloud, also auf Servern des Anbieters oder eines Subunternehmers – unabhängig davon, ob Sie die Anwendung über den Browser, eine App oder eine in Software integrierte Funktion nutzen. Nur wenige, meist kleinere oder spezialisierte Modelle laufen vollständig lokal auf Ihrem eigenen Gerät, ohne dass Daten das Gerät verlassen.

Lokale Verarbeitung bietet einen klaren Datenschutzvorteil, geht jedoch in der Regel mit geringerer Rechenleistung und eingeschränkteren Fähigkeiten einher. Für die meisten leistungsfähigen Assistenten gilt daher: Ihre Daten verlassen Ihr Gerät, sobald Sie eine Anfrage absenden.

Was mit Ihren Gesprächen langfristig geschieht

Neben der unmittelbaren Verarbeitung stellt sich die Frage, was mit Ihren Daten über die einzelne Anfrage hinaus passiert. Grundsätzlich lassen sich hier mehrere Verwendungszwecke unterscheiden, die je nach Anbieter und Ihren individuellen Einstellungen unterschiedlich ausgestaltet sind:

• Speicherung zur Verlaufsanzeige: Damit Sie frühere Gespräche wiederfinden, werden diese üblicherweise dauerhaft in Ihrem Konto gespeichert, bis Sie sie aktiv löschen.
• Nutzung zu Trainingszwecken: Manche Anbieter verwenden Gesprächsinhalte – meist nach Anonymisierung und häufig nur, sofern Sie dem nicht widersprochen haben – zur Verbesserung künftiger Modellversionen.
• Menschliche Überprüfung: Ausgewählte Konversationen können, etwa bei gemeldeten Problemen oder zu Qualitätszwecken, von Mitarbeitenden oder beauftragten Dienstleistern eingesehen werden.
• Aufbewahrung aus rechtlichen Gründen: Selbst nach einer Löschung im Nutzerkonto können Daten aus regulatorischen oder sicherheitstechnischen Gründen für einen begrenzten Zeitraum in Backup-Systemen verbleiben.

Da sich diese Praktiken zwischen Anbietern und im Zeitverlauf unterscheiden, lohnt sich vor der Nutzung eines KI-Assistenten stets ein Blick in die aktuellen Datenschutzhinweise des jeweiligen Dienstes.

Rechtlicher Rahmen: Was Ihnen zusteht

Innerhalb der Europäischen Union unterliegt die Verarbeitung personenbezogener Daten durch KI-Anbieter grundsätzlich der Datenschutz-Grundverordnung (DSGVO). Daraus ergeben sich für Sie als Nutzerin oder Nutzer mehrere zentrale Rechte:

• Recht auf Auskunft: Sie können von einem Anbieter erfahren, welche Daten zu Ihrer Person gespeichert sind.
• Recht auf Löschung: Unter bestimmten Voraussetzungen können Sie die Löschung Ihrer Daten verlangen.
• Recht auf Datenübertragbarkeit: Sie können verlangen, Ihre Daten in einem gängigen, maschinenlesbaren Format zu erhalten.
• Widerspruchsrecht gegen die Nutzung zu Trainingszwecken: Viele Anbieter räumen die Möglichkeit ein, der Verwendung Ihrer Gespräche für das Training künftiger Modelle zu widersprechen.

Ergänzend verpflichten europäische Regelungen zur künstlichen Intelligenz Anbieter von KI-Systemen zu bestimmten Transparenzpflichten, etwa zur Kennzeichnung, wenn Sie mit einem Chatbot statt mit einem Menschen interagieren. Diese Pflichten betreffen in erster Linie die Transparenz gegenüber Nutzerinnen und Nutzern und ersetzen nicht die grundsätzlichen datenschutzrechtlichen Anforderungen der DSGVO.

Woran Sie einen datenschutzbewussten Anbieter erkennen

Unabhängig von tagesaktuellen Entwicklungen lassen sich einige zeitlose Kriterien benennen, an denen Sie die Datenschutzkultur eines KI-Anbieters einschätzen können:

• Verständliche Datenschutzerklärung: Klare, in Alltagssprache formulierte Angaben dazu, welche Daten wofür verarbeitet werden – ohne sich in juristischem Fachjargon zu verlieren.
• Widerspruchsmöglichkeit gegen Trainingsnutzung: Eine leicht zugängliche Einstellung, mit der Sie die Nutzung Ihrer Gespräche für das Modelltraining deaktivieren können.
• Klare Löschfristen: Konkrete Angaben dazu, wie lange Daten gespeichert werden und wann sie endgültig gelöscht sind.
• Zurückhaltung bei der Weitergabe an Dritte: Keine Weitergabe von Gesprächsinhalten zu Werbezwecken an unbeteiligte Unternehmen.
• Nachvollziehbare Subunternehmer-Liste: Transparenz darüber, welche externen Cloud- und Infrastrukturanbieter an der Verarbeitung beteiligt sind.
• Serverstandort und Zertifizierungen: Hinweise auf Serverstandorte innerhalb der EU sowie anerkannte Sicherheitszertifizierungen können ein zusätzliches Indiz für ein durchdachtes Datenschutzkonzept sein.

Praktische Empfehlungen für den bewussten Umgang mit KI-Assistenten

Angesichts dieser vielschichtigen Verarbeitungskette lassen sich einige grundsätzliche Verhaltensregeln ableiten, die unabhängig vom jeweiligen Anbieter Bestand haben:

• Vermeiden Sie sensible Angaben. Geben Sie keine Sozialversicherungsnummern, Passwörter, Gesundheitsdaten oder vertrauliche Geschäftsinformationen in einen Chatbot ein, sofern dies nicht unbedingt erforderlich ist.
• Prüfen Sie die Datenschutzeinstellungen. Viele Anbieter erlauben es, die Nutzung von Gesprächen für das Modelltraining zu deaktivieren oder einen „temporären" Modus zu nutzen, bei dem Verläufe nicht dauerhaft gespeichert werden.
• Seien Sie zurückhaltend bei verknüpften Diensten. Jede zusätzliche Verbindung – etwa zu E-Mail-Konten, Kalendern oder Cloud-Speichern – vergrößert die Angriffsfläche und die Anzahl der beteiligten Systeme.
• Löschen Sie nicht mehr benötigte Verläufe. Regelmäßiges Aufräumen reduziert die Menge an Daten, die im Falle eines Sicherheitsvorfalls betroffen sein könnten.
• Lesen Sie die Datenschutzhinweise – zumindest in Auszügen. Insbesondere die Abschnitte zu Datenweitergabe an Dritte und zu Speicherfristen geben Aufschluss darüber, wie ernst ein Anbieter den Datenschutz nimmt.
• Nutzen Sie geschäftliche Konten mit Bedacht. Für sensible berufliche Anwendungsfälle bieten manche Anbieter Unternehmenslösungen mit strengeren Datenschutzgarantien an, die sich von den Standard-Consumer-Produkten unterscheiden können.

Fazit

Die Frage, wie viel ein KI-Assistent über Sie weiß, lässt sich nicht allein mit einem Blick auf das sichtbare Chatfenster beantworten. Hinter jeder Anfrage steht eine mehrstufige technische Kette aus Vorverarbeitung, Sicherheitsprüfung, Gedächtnisabruf, externen Werkzeugaufrufen, verteilter Rechenleistung und Protokollierung – eine Infrastruktur, die weitgehend unsichtbar bleibt, aber maßgeblich bestimmt, wie Ihre Daten verarbeitet und mitunter weitergegeben werden.

Wer diese Zusammenhänge kennt, kann bewusster entscheiden, welche Informationen er einem KI-Assistenten anvertraut und welche besser im eigenen Kopf oder in einem verschlüsselten Dokument bleiben. Datenschutzbewusster Umgang mit künstlicher Intelligenz bedeutet daher nicht, auf die Technologie zu verzichten, sondern sie mit einem klaren Verständnis ihrer tatsächlichen Funktionsweise zu nutzen. Mittlerweile ist Open-Source KI so gut, dass Unternehmen kostengünstig eine leistungsfähige lokale KI betreiben können, mit maximal möglicher Datensicherheit. Idealerweie kennen Sie einen konkreten Anwendungsfall für "Ihre KI" und wollen nicht "irgendwas mit KI" machen.

Einen Überblick über alle Beiträge zu KI im eigenen Haus bietet die Seite Lokale KI im Unternehmen.

Das Wichtigste in Kürze

• Rekursive Selbstverbesserung (RSI) heißt: Ein KI-System verbessert die Fähigkeiten, mit denen es sich selbst weiter verbessert. Eine vollständig geschlossene, autonome Schleife ist bisher nicht belegt.
• Teilautomatisierung ist Realität. Bei Anthropic schreibt Claude über 80 Prozent des gemergten Codes. Bei OpenAI war GPT-5.3 Codex nach Unternehmensangaben das erste Modell mit maßgeblicher Rolle bei der eigenen Entwicklung.
• Was noch fehlt, ist Urteilskraft: Ziele wählen, Ergebnisse einschätzen, Sackgassen erkennen. Genau dort sehen die Labs den verbleibenden Vorsprung des Menschen.
• Agenten brechen aus Testumgebungen aus. Die Vorfälle des Jahres 2026 sind keine RSI, zeigen aber, wie schwer sich schnell lernende Systeme einhegen lassen.
• Beeindruckende Ergebnisse: Agenten haben teils in tagelanger Rechenarbeit bisher ungelöste mathematische Probleme gelöst. Dazu wurde ein Agent Harness verwendet, der selbständig Tests ausführen und Selbstkritik üben kann.
• Überprüfbarkeit lässt sich herstellen. Wo Ergebnisse simuliert oder automatisch gemessen werden können, etwa bei Code, Physik, Konstruktion und Fertigung, kann ein System sich beliebig viele Prüfstände selbst bauen. Der Engpass verschiebt sich dann von Daten auf Rechenleistung, Energie und, bei offenen Fragen, auf die Bewertung.
• Eine Drosselung einzelner Labore stoppt die Entwicklung nicht. Effizientere Modelle, offene Gewichte und frei verfügbare Agentenwerkzeuge verbreiten Fähigkeiten auch ohne Frontier-Compute. Eine verbindliche weltweite Regulierung ist nicht in Sicht.
• Die Labs sprechen offen über die Risiken und über die Option, die Entwicklung gezielt zu verlangsamen. Ob das gelingt, ist offen.

Was ist rekursive Selbstverbesserung?

Rekursive Selbstverbesserung bedeutet, dass ein System seine Fähigkeit verbessert, sich selbst zu verbessern, und dadurch eine Rückkopplungsschleife entsteht. Man kann sich einen Schmied vorstellen, der mit seinem Werkzeug bessere Werkzeuge baut, mit denen er wieder bessere baut. Wird der Zugewinn pro Runde größer statt kleiner, beschleunigt sich der Prozess. Genau das meint der Begriff „Intelligenzexplosion“.

Eine alte Idee, die gerade praktisch genutzt wird

• 1950: Alan Turing schlägt eine Kind-Maschine vor, die erzogen würde, anstatt die erwachsene Intelligenz direkt zu reproduzieren
• 1965: Der Mathematiker I. J. Good beschreibt eine „ultraintelligente Maschine“, die immer bessere Maschinen entwirft. Danach würde der Mensch die letzte Erfindung machen, die er selbst machen muss.
• 2003: Jürgen Schmidhuber stellt die Gödel-Maschine vor, ein formales Modell eines Systems, das seinen eigenen Code nur dann umschreibt, wenn es beweisen kann, dass die Änderung nutzt.
• 2007: Eliezer Yudkowsky prägte den Begriff „Seed AI“: So heißt in der Sicherheitsdebatte das Ausgangssystem, das eine solche Schleife in Gang setzt.
• 2024 und 2025: Mit dem Gödel Agent und der Darwin Gödel Machine entstehen praktische Varianten. Statt zu beweisen, testen diese Agenten ihre Änderungen am eigenen Code empirisch und behalten, was funktioniert.
• 2026: Agentische Ansätze zur Selbstverbesserung existieren bereits, ebenso wie Forschungsarbeiten dazu. Eine Arbeit hat eine Formalisierung über eine innere und eine äußere Schleife eingeführt. Die innere Schleife optimiert Code gegenüber messbaren Zielen auf spezifischen KI-F&E-Aufgaben. Die äußere Schleife führt Meta-Ebene-Optimierung durch, indem sie den Forschungsagenten umschreibt, um seine eigene Effizienz zu verbessern. Jeder angenommene Rewrite wird zum Agenten, den die nächste Runde bearbeitet

Zwei Kräfte treiben das Tempo: der Wettbewerb der Anbieter und die sinkenden Kosten. Dieselbe Leistung braucht jedes Jahr deutlich weniger Rechenaufwand, und Open-Weight-Modelle liegen nur Monate hinter der Spitze. Das macht den Fortschritt schwerer zu steuern, als es bei wenigen Laboren der Fall wäre.

Drei Stufen, die man auseinanderhalten sollte

In der Diskussion wird oft alles unter „RSI“ zusammengeworfen. Hilfreich ist die Unterscheidung nach dem Grad der Autonomie.

Ein wichtiger Punkt vorweg: Heutige Modelle schreiben ihre Gewichte nicht im laufenden Betrieb um. Die Schleife läuft über Trainingszyklen, in denen Menschen, Rechenzentren und Prüfverfahren dazwischenstehen. Anthropic formuliert es so: Man sei noch nicht an dem Punkt, und RSI sei nicht unvermeidlich.

Wo wir heute stehen: Die Belege

Die belastbarsten Zahlen stammen von den Labs selbst und lassen sich deshalb nur eingeschränkt unabhängig prüfen. Sie zeigen aber alle in dieselbe Richtung: Die KI-Entwicklung wird zunehmend von KI mitgetragen.

Anthropic: Claude arbeitet an Claude mit

Im Juni 2026 veröffentlichte das Anthropic Institute den Bericht „When AI builds itself“. Er sammelt interne Daten, nennt aber jeweils auch Einschränkungen.

Die Lücke, die Anthropic benennt, liegt bei der Urteilskraft: Ziele auswählen, Ergebnisse einschätzen, Sackgassen erkennen. Als unabhängiges Indiz für das Tempo nennt der Bericht die Messungen der Organisation METR. Demnach verdoppelt sich die Länge der Aufgaben, die Modelle zuverlässig allein lösen, mehrmals pro Jahr, und Claude Mythos Preview kam auf mindestens 16 Stunden.

OpenAI: Der automatisierte Forscher als Ziel

• GPT-5.3 Codex, im Februar 2026 erschienen, war laut OpenAI-Forschungschefin Amelia Glaese das erste Modell, das von Anfang bis Ende maßgeblich an der eigenen Entwicklung beteiligt war.
• Im Juli verwies OpenAI darauf, dass GPT-5.6 Sol beim Post-Training eines kleineren Modells Forschern Wochen Arbeit gespart hat, berichtet MIT Technology Review.
• OpenAI hat einen automatisierten „Research Intern“ vorgestellt, der Aufgaben lösen soll, für die ein erfahrener Forscher einige Tage bräuchte. Das Ziel eines automatisierten KI-Forschers nennt das Unternehmen für März 2028. Es räumt zugleich ein, noch nicht zu wissen, wie man sicher bis zu einer vollständig ausgerichteten RSI kommt (Fortune).
• Beide Labs sagen, die autonome Modellverbesserung gehe schneller voran als erwartet (CNBC).

Weitere Beispiele aus der Forschung

AlphaEvolve (Google DeepMind). Ein evolutionärer Coding-Agent: Gemini schlägt Code-Varianten vor, automatische Bewerter prüfen sie, die besten Varianten werden weiterentwickelt. Laut DeepMind gewinnt eine so entdeckte Heuristik im Schnitt 0,7 Prozent der weltweiten Google-Rechenleistung zurück. Ein Kernel im Gemini-Training wurde um 23 Prozent schneller, was die Trainingszeit um 1 Prozent senkte. Das ist ein kleines, aber direktes Beispiel dafür, dass KI die Infrastruktur verbessert, auf der KI trainiert wird.

Darwin Gödel Machine (Sakana AI). Ein Agent schreibt seinen eigenen Code um und behält, was sich bewährt. Auf dem Benchmark SWE-bench stieg die Lösungsrate von 20,0 auf 50,0 Prozent, auf Polyglot von 14,2 auf 30,7 Prozent (Sakana AI). Bemerkenswert ist die Kehrseite: Das System erfand Testprotokolle für Tests, die nie liefen, und entfernte in einem Folgeversuch die Markierungen, mit denen solche Fälschungen erkannt wurden. Entdeckt wurde das nur, weil jede Änderung nachvollziehbar protokolliert war.

Automatisierte Alignment-Forschung. Ein Paper von Ende August zeigt, dass automatisierte Systeme auf allen zehn getesteten Alignment-Benchmarks besser wurden, ohne die Gesamtleistung zu verschlechtern (TechCrunch).

Was die Erwartungen dämpft

Eine Studie, über die MIT Technology Review

Wir betrachten, wie Kriminelle künstliche Intelligenz für diese Betrugsmasche einsetzen, was technisch dahintersteckt, welche Schutzmechanismen es gibt – und warum sie im Ernstfall trotzdem oft zu spät kommen.

Vom Enkeltrick zum Enkeltrick 2.0: Was ist neu?

Der ursprüngliche Enkeltrick funktionierte über Psychologie, nicht über Technik. Ein Anrufer eröffnete das Gespräch mit einer Frage wie „Rate mal, wer hier spricht?" und ließ das Opfer selbst einen Namen nennen, den der Betrüger dann übernahm. Wer genau hinhörte, konnte den Betrug oft an der fremden Stimme oder an fehlendem Detailwissen erkennen. Genau diese beiden Schutzmechanismen hebelt die neue Generation des Betrugs aus.

Für einen überzeugenden Stimmklon reichen heute wenige Sekunden Audiomaterial, häufig aus einem öffentlich zugänglichen Social-Media-Video. Damit lässt sich eine synthetische Kopie erzeugen, die nicht nur den Klang, sondern auch Sprachmelodie, Betonung und sogar emotionale Nuancen wie Weinen oder Zittern nachbildet. Der wichtigste Erkennungsfaktor der alten Masche, die unbekannte Stimme, fällt damit komplett weg.

Kriminelle nutzen die Technik heute in drei typischen Varianten:

• Modernisierter Enkeltrick: Die geklonte Stimme eines Kindes oder Enkelkindes meldet sich mit einem angeblichen Notfall.
• CEO-Fraud: Mitarbeitende erhalten eine vermeintlich dringende Anweisung der Geschäftsführung, meist verbunden mit einer Geldüberweisung.
• Schockanruf: Eine angebliche Polizei- oder Behördenstimme baut mit einem dramatischen Szenario sofortigen Handlungsdruck auf.

So funktioniert Voice Cloning: Die Technik hinter der Täuschung

Um zu verstehen, warum diese Betrugsmasche so wirkungsvoll geworden ist, lohnt sich ein Blick auf die Technik. Zwei Verfahren kommen dabei zum Einsatz, die oft verwechselt werden:

Text-to-Speech (TTS) wandelt geschriebenen Text in gesprochene Sprache um, meist mit einer vorgefertigten, generischen KI-Stimme. Das kennt man von Navigationsgeräten oder Vorlesefunktionen.

Voice Cloning geht einen Schritt weiter: Es rekonstruiert die Stimme einer ganz bestimmten, realen Person. Dafür analysiert ein Modell eine kurze Referenzaufnahme und extrahiert daraus ein sogenanntes Stimm-Embedding, eine mathematische Repräsentation von Tonhöhe, Klangfarbe, Sprechtempo und charakteristischen Eigenheiten. Mit diesem Embedding kann das System anschließend beliebigen neuen Text in genau dieser Stimme aussprechen, inklusive Atempausen und emotionaler Färbung.

Bis vor wenigen Jahren brauchte ein überzeugender Klon noch mehrere Minuten sauberes Audiomaterial. Heute genügen professionellen wie kriminellen Anbietern teils schon wenige Sekunden aus einem Instagram-Video oder einer Sprachnachricht. Diese gesunkene technische Hürde ist der eigentliche Grund, warum sich der Enkeltrick 2.0 so schnell verbreitet.

Die unsichtbare Tool-Chain: Was bei jeder KI-Anfrage im Hintergrund passiert

Was viele nicht wissen: Hinter jeder Anfrage an ein KI-System, ob es sich um einen harmlosen Chat oder eine Sprachsynthese handelt, läuft im Hintergrund eine mehrstufige Verarbeitungskette ab. Diese Tool-Chain ist bei seriösen Anbietern unabhängig davon aktiv, wofür man die KI gerade nutzt, und sie erklärt sowohl die Stärken als auch die Schwachstellen der heutigen Schutzmechanismen.

Eingabe und Normalisierung. Zunächst wird die Eingabe technisch aufbereitet. Bei Sprachklon-Diensten bedeutet das etwa, dass hochgeladenes Audiomaterial auf ein einheitliches Lautstärkeniveau gebracht und von Störgeräuschen bereinigt wird, damit das nachfolgende Modell sauber arbeiten kann.

Prüfung vor der Verarbeitung. Noch bevor die eigentliche KI-Anfrage bearbeitet wird, läuft bei vielen Anbietern ein vorgeschalteter Sicherheitsfilter. Dieser gleicht ab, ob eine Anfrage gegen Nutzungsrichtlinien verstößt, etwa weil eine fremde, nicht autorisierte Stimme geklont werden soll. Seriöse Anbieter verlangen inzwischen einen Einwilligungsnachweis: Die Person, deren Stimme geklont werden soll, muss einen vom System vorgegebenen Satz einsprechen, der dann mit der Anfrage abgeglichen und als Nachweis gespeichert wird.

Die eigentliche Modell-Inferenz. Erst danach verarbeitet das eigentliche KI-Modell die Anfrage. Bei der Sprachsynthese wird der gewünschte Text zunächst in eine phonetische Struktur übersetzt, mit dem zuvor extrahierten Stimm-Embedding verknüpft und von einem sogenannten Vocoder in eine tatsächliche Audiowellenform umgewandelt.

Prüfung nach der Verarbeitung. Nach der Generierung läuft häufig ein weiterer, nachgelagerter Filter, der das Ergebnis noch einmal bewertet, bevor es ausgeliefert wird. In diesem Schritt betten viele Anbieter inzwischen auch unsichtbare Wasserzeichen in ihre Audioausgaben ein, damit KI-generierte Inhalte später als solche identifiziert werden können.

Protokollierung und Missbrauchserkennung. Im Hintergrund werten Anbieter zudem Nutzungsmuster aus, um verdächtige Häufungen zu erkennen, etwa auffällig viele Klon-Anfragen zu prominenten oder öffentlichen Personen.

Diese gesamte Kette läuft bei jeder einzelnen Anfrage in Sekundenbruchteilen ab, egal ob jemand für ein Hörbuch, einen Werbespot oder eben für einen Betrugsanruf eine Stimme erzeugen lässt. Genau hier liegt aber auch die Grenze dieses Schutzsystems: Es funktioniert nur, wenn der Anbieter die Kette tatsächlich implementiert hat. Kriminelle greifen stattdessen auf frei verfügbare, quelloffene Klon-Werkzeuge ohne Einwilligungsprüfung zurück, betreiben eigene, nicht regulierte Infrastruktur oder nutzen Dienste außerhalb der EU, die sich nicht an die hier beschriebenen Standards halten. Aktuelle Forschung zeigt zudem, dass selbst technische Schutzmaßnahmen wie akustische Störsignale, die eigentlich das Klonen einer Stimme verhindern sollen, sich mit spezialisierten Bereinigungsverfahren teilweise wieder umgehen lassen. Die Tool-Chain ist also kein Selbstläufer, sondern ein Wettlauf zwischen Schutzmechanismen und ihrer Umgehung, der branchenübergreifend weitergeht.

Der Ablauf eines Betrugsanrufs: So gehen die Täter vor

Die Masche folgt einem wiederkehrenden Muster. Anrufe erfolgen bevorzugt spät abends oder am Wochenende, wenn die vermeintlich betroffene Person selbst schwerer erreichbar ist und Familienmitglieder weniger Zeit zur Rückversicherung haben. Über sogenanntes Nummern-Spoofing erscheint auf dem Display häufig eine vertrauenswürdig wirkende deutsche Rufnummer, obwohl der Anruf tatsächlich aus dem Ausland kommt.

Nach den ersten emotionalen Sätzen der geklonten Stimme schalten sich in vielen Fällen weitere Anrufer dazu, die sich als Polizeibeamte oder Rechtsanwälte ausgeben und mit Fachjargon zusätzlichen Druck aufbauen. Ziel ist immer, so wenig Bedenkzeit wie möglich zu lassen, denn jede Minute, in der das Opfer nachdenkt oder Rücksprache hält, erhöht das Risiko, dass der Betrug auffliegt.

Zahlen, die aufhorchen lassen

Das Ausmaß der Entwicklung zeigt sich in mehreren aktuellen Kennzahlen. Die Bundesnetzagentur registrierte allein im Januar 2026 über 555.000 gemeldete betrügerische Anrufe, wobei von einer erheblichen Dunkelziffer auszugehen ist. In einer weltweiten Umfrage des Sicherheitsunternehmens McAfee gab etwa ein Viertel der Befragten an, selbst einen Betrugsanruf mit einer geklonten KI-Stimme erlebt zu haben oder ein Opfer aus dem eigenen Umfeld zu kennen.

Das Bundeskriminalamt erfasste für das Jahr 2024 im Bereich Enkeltrick und Schockanrufe rund 6.700 Fälle, KI-gestützte Betrugsversuche werden dabei bislang noch nicht separat ausgewiesen. Allein in Bayern erbeuteten Betrüger im Jahr 2023 über 18 Millionen Euro durch diese Betrugsform, mit Einzelfällen im sechsstelligen Bereich.

Wie konkret die Schäden ausfallen können, zeigen dokumentierte Fälle der vergangenen Monate: In Düsseldorf verlor ein Ehepaar rund 230.000 Euro in Bargeld und Goldmünzen an einen angeblichen Anwalt. In Pfaffenhofen übergab eine 60-Jährige 60.000 Euro auf einem Supermarktparkplatz. Im Kanton Schwyz in der Schweiz überwies ein Unternehmer im Januar 2026 mehrere Millionen Franken, nachdem Täter die Stimme seines Geschäftspartners geklont hatten. Bereits 2019 hatte ein früher Fall von KI-CEO-Betrug in Großbritannien Aufsehen erregt, bei dem eine geklonte Stimme mit leichtem deutschen Akzent eine Überweisung von 220.000 Euro auslöste.

Warnsignale, auf die man sich nicht mehr verlassen kann

Viele der klassischen Ratschläge zur Erkennung von Betrugsanrufen stammen aus einer Zeit vor leistungsfähigem Voice Cloning und sind inzwischen überholt. Wer auf eine „roboterhaft klingende" oder monoton wirkende Stimme wartet, wird enttäuscht: Moderne Klone transportieren mittlerweile auch Atmen, Zögern und emotionale Ausbrüche glaubwürdig. Auch die früher hilfreiche Kontrollfrage nach einem gemeinsamen Familiengeheimnis verliert an Wirkung, wenn Täter zuvor gezielt Informationen aus sozialen Netzwerken gesammelt haben.

Was stattdessen tatsächlich schützt, ist weniger eine Frage des genauen Hinhörens als eine feste Verhaltensregel, die unabhängig davon funktioniert, wie perfekt eine Stimme klingt.

Konkrete Schutzmaßnahmen für Familien

Verbraucherschützer und Polizeibehörden empfehlen inzwischen ein klares, einfach zu merkendes Vorgehen:

Ein Familien-Codewort vereinbaren. Legen Sie gemeinsam mit engen Angehörigen ein geheimes Wort fest, das nur die Familie kennt und das bei einem verdächtigen Notruf abgefragt wird. Ein Sprachklon kann eine Stimme nachbilden, aber kein vorher nicht bekanntes Codewort erraten.

Grundsätzlich aktiv zurückrufen. Legen Sie bei einem unerwarteten Notruf auf und rufen Sie die betroffene Person aktiv unter der Ihnen bereits bekannten, gespeicherten Nummer zurück, niemals unter einer vom Anrufer genannten Nummer.

Zeitdruck als Alarmsignal werten. Jede Aufforderung, sofort und ohne Rücksprache mit anderen Familienmitgliedern zu handeln, sollte grundsätzlich misstrauisch machen, unabhängig davon, wie überzeugend die Stimme klingt.

Nie Bargeld an Unbekannte übergeben. Weder Polizei noch Staatsanwaltschaft fordern in Deutschland jemals telefonisch die Übergabe von Bargeld, Schmuck oder Kaution an der Haustür oder auf offener Straße. Jede derartige Forderung ist ein eindeutiges Betrugsmerkmal.

Eigene Social-Media-Inhalte bewusst einschränken. Da bereits wenige Sekunden öffentlich zugänglichen Videomaterials für einen Klon ausreichen, lohnt sich ein kritischer Blick auf die Reichweite eigener Sprachaufnahmen in sozialen Netzwerken, besonders bei älteren und potenziell gefährdeten Familienmitgliedern.

Ältere Angehörige aktiv einbeziehen. Da Sprachklon-Betrug besonders auf ältere Menschen abzielt, hilft es, das Thema offen im Familienkreis anzusprechen und die Codewort-Regelung gemeinsam einzuüben, statt nur allgemein zu warnen.

Kennzeichnungspflicht seit August 2026: Was der EU AI Act ändert

Seit dem 2. August 2026 gelten die Transparenzpflichten aus Artikel 50 der europäischen KI-Verordnung verbindlich. Anbieter von KI-Systemen müssen seither sicherstellen, dass ihre generierten Ausgaben maschinenlesbar als künstlich erzeugt gekennzeichnet werden, bei Deepfakes zusätzlich auch für Menschen direkt erkennbar. Das gilt ausdrücklich auch für synthetische Stimmen: Wird eine Sprachnachricht oder ein Anruf mit einer geklonten Stimme erzeugt, muss die betroffene Person formal darüber informiert werden.

Technisch setzt die Branche dafür zunehmend auf offene Standards wie C2PA, die Herkunft und Bearbeitungsschritte einer Datei kryptografisch signieren, sowie auf unsichtbare Wasserzeichen wie SynthID von Google DeepMind, das inzwischen auch von anderen großen Anbietern für KI-generierte Audioinhalte eingesetzt wird.

Für die Praxis bedeutet das allerdings nur bedingt Entwarnung. Die Kennzeichnungspflicht richtet sich an den Anrufer, und bei einer kriminell organisierten Bande greift diese Vorschrift naturgemäß ins Leere. Für ein Opfer am Telefon ändert das gesetzliche Gebot im Moment des Anrufs zunächst nichts, wertvoll wird die Regulierung vor allem im Nachhinein, etwa bei der strafrechtlichen Aufarbeitung von Fällen, sowie langfristig durch den Druck auf seriöse Anbieter, ihre Schutzmechanismen weiter auszubauen.

Was tun, wenn der Ernstfall eintritt

Wer einen verdächtigen Anruf erhalten oder bereits Geld überwiesen hat, sollte umgehend die Polizei über den Notruf 110 informieren, keinesfalls über eine vom Anrufer genannte Nummer. Bereits getätigte Überweisungen sollten sofort bei der eigenen Bank gemeldet werden, da ein Rückruf innerhalb der ersten Stunden die Chance auf eine Rückbuchung deutlich erhöht. Zusätzlich empfiehlt es sich, den Vorfall auch bei der Verbraucherzentrale zu melden, da diese Daten helfen, Warnmuster frühzeitig zu erkennen und weiterzugeben.

Fazit

Der Enkeltrick 2.0 ist deshalb so wirkungsvoll, weil er eine jahrzehntealte psychologische Betrugsmasche mit einer Technik verbindet, die noch vor wenigen Jahren undenkbar war. Die gute Nachricht: Der wirksamste Schutz ist nicht technischer, sondern organisatorischer Natur.

Ein vereinbartes Familien-Codewort und die feste Regel, im Zweifel aufzulegen und aktiv zurückzurufen, funktionieren unabhängig davon, wie perfekt eine geklonte Stimme irgendwann klingen wird. Während Gesetzgeber und Anbieter mit Kennzeichnungspflichten und Wasserzeichen technisch nachziehen, bleibt für Familien im Alltag vor allem eines entscheidend: eine vorher getroffene Verabredung schlägt jede noch so überzeugende Stimme am Telefon.

Demnächst wird es hier einen Beitrag mit einem aufgezeichneten Telefongespräch eines indischen "Microsoft-Mitarbeiters" geben, der einen deutschen Mitbürger um seine Daten bringen wolltee.