2.436 Schwachstellen, ein Melder: Ihren VDP-Meldeeingang neu bauen

Eine Massenoffenlegung von Schwachstellen bedeutet: Ein einzelner Melder reicht viele Funde gleichzeitig bei vielen Parteien ein, die nichts miteinander zu tun haben – nach einem Zeitplan, den er selbst vorgibt. Das öffentliche Security Disclosure Ledger von Z.ai verzeichnet 2.436 Funde in 269 Open-Source-Projekten, davon 107 als kritisch und 990 als hoch eingestuft, mit durchschnittlich 26,6 Jahren zwischen dem Schreiben eines Fehlers und seiner Entdeckung. Eine unabhängige Auswertung des Statusfelds in diesem Register ergab: 2.239 dieser Funde stehen weiterhin auf discovered, genau einer auf sent to maintainer. Ein Meldeeingang, der je Meldung denkt – eine Eingangsbestätigung, eine laufende Frist, eine Einstufung des Schweregrads –, hält dieser Form nicht stand.

Dies ist der dritte Artikel einer Reihe, und genau auf diese Abgrenzung kommt es an. Der Beitrag zum KI-Spam handelte von ungültigen Meldungen, die in Masse eintreffen. Der Beitrag zur Ökonomie handelte davon, dass die Kosten für das Finden einer echten Schwachstelle auf etwa den Preis eines Mittagessens gefallen sind. Hier geht es um keines von beidem: Diese Funde sind weitgehend gültig, und niemand hat um sie gebeten. Der Beitrag zur Offenlegung mit mehreren Herstellern behandelte eine Schwachstelle, die bei fünf Herstellern landet. Hier landet ein Melder bei 269 Projekten – dasselbe Governance-Problem, auf den Kopf gestellt – und die Frist liegt in der Hand der Partei, die einen Produktstart vor sich hat.

2.436 Funde, 269 Projekte, ein Melder

Am 14. August 2026 stellte Z.ai GLM-5.3 vor und veröffentlichte noch am selben Tag unter cvd.z.ai ein Security Disclosure Ledger. Nicht der Benchmark-Wert ist das lesenswerte Artefakt, sondern dieses Register.

Zu den namentlich offengelegten Funden zählen der 6lowpan-Stack des Linux-Kernels, WebKit, ptrace in FreeBSD, GStreamer und Suricata. Z.ai gibt für GLM-5.3 84,5 % auf CyberGym an, nach 77,2 % bei GLM-5.2. Der Thread auf Hacker News kam auf 1.170 Punkte und 584 Kommentare; die schärfste Kritik richtete sich nicht gegen das Modell, sondern gegen das Scannen von Open Source in großem Maßstab ohne jede Regelung zu Sperrfristen.

Zwei Einschränkungen, bevor Sie irgendetwas auf diesen Zahlen aufbauen.

Die Kampagne ist nicht das Werk eines einzigen Modells. Z.ai zufolge begann sie noch zu GLM-5.2-Zeiten, verteilt über mehrere Sicherheitsteams und mehrere Harnesses, und die Advisories der Projekte nennen unterschiedliche GLM-Versionen. Schreiben Sie „die Kampagne von Z.ai“, nie „GLM-5.3 hat 2.436 Fehler gefunden“.

Jede Gesamtzahl hier stammt aus Z.ais eigener Veröffentlichung. Niemand außerhalb des Unternehmens kann die 2.383 nicht offengelegten Datensätze prüfen. Das ist kein Seitenhieb gegen Z.ai. Es ist genau die Lage, in der Sie stecken werden, wenn ein Stapel von vierzig Meldungen in Ihrem Postfach landet: Sie können die Angaben eines Massenmelders beim Eingang nicht verifizieren – und ich diese hier ebenso wenig.

Warum das weder die KI-Spam-Geschichte ist noch die Geschichte der billigen Entdeckung

Beim KI-Spam ging es um das Verhältnis von Signal zu Rauschen. Bei der Ökonomie ging es um die Stückkosten. Hier geht es um die Form – und die Form ist das, woran Werkzeuge zerbrechen.

Ein gewöhnliches VDP unterstellt eine Viele-zu-eins-Beziehung: viele unabhängige Forscherinnen und Forscher, die jeweils eine Meldung schicken und mit der Einreichung Ihre Richtlinie anerkennen. Eine Massenkampagne dreht das um. Ein Melder wendet sich gleichzeitig an 269 empfangende Parteien, nach einem Zeitplan, den er selbst vorgibt, und veröffentlicht ein öffentliches Register, bevor die meisten Empfänger überhaupt kontaktiert wurden.

Die empfangende Partei hat sich weder dafür entschieden noch einem Zeitplan zugestimmt, und in den meisten Fällen weiß sie nichts davon. Das ist keine Bug-Bounty-Einreichung. Es kommt einer massenhaften Schwachstellenbenachrichtigung näher – einem Vorgehen, das die Sicherheitsforschung seit einem Jahrzehnt untersucht und dessen Rücklaufquote sie als niederschmetternd kennt.

Der Engpass ist die Benachrichtigung, nicht der Patch

Die nützlichste Angabe im Register ist nicht die 2.436, sondern die Stelle, an der diese Funde liegen bleiben.

Eine Auswertung des Statusfelds vom 14. August ergab: 2.239 discovered, 84 reported, 53 revealed, 29 acknowledged, 30 patched und 1 sent to maintainer. Rund 92 % der Funde liegen also weiterhin beim Melder.

Anthropic ist zwei Monate zuvor nach demselben Drehbuch vorgegangen – und wurde dafür durchleuchtet. VulnChecks Analyse vom 9. Juni 2026 zum Mythos-Register von Anthropic fand 23.019 Schwachstellenkandidaten; davon waren 467 verifiziert und gemeldet, weitere 1.129 ohne Verifikation gemeldet. Das sind 1.596 Funde, also 6,9 %, die binnen 60 Tagen bei Maintainern ankamen – ein Tempo, bei dem VulnCheck rund 2,4 Jahre veranschlagt, um den Rückstand abzuarbeiten. Dieselbe Analyse fand zehn Funde, die Anthropics eigene 90-Tage-Frist bereits überschritten hatten, ohne dass eine Veröffentlichung folgte; bei 168 weiteren lief sie binnen 30 Tagen ab.

Zwei Anbieter, zwei Register, ein strukturelles Ergebnis: Das Finden skaliert, das Benachrichtigen nicht. Ein Modell findet einen Heap-Overflow in einer Codebasis von 1994 in Minuten. Den Maintainer zu finden, eine Meldung zu schreiben, mit der ein Mensch etwas anfangen kann, und sie bis zum Patch zu begleiten, bleibt unveränderte menschliche Arbeit.

Für die Empfängerseite ist das eine gute Nachricht mit Verfallsdatum. Die Welle hat Sie noch nicht erreicht; wenn sie es tut, kommt sie als Stapel – denn der Melder arbeitet eine Warteschlange ab, statt einen Fehler zu melden.

Was zerbricht, wenn 40 Meldungen von einem Absender eintreffen

Drei mechanische Fehlfunktionen, keine davon eine Ermessensfrage. In allen drei Fällen arbeitet Ihre bestehende Automatisierung exakt so, wie sie entworfen wurde.

Die Eingangsbestätigung vervielfacht sich. Eine automatische Antwort je Meldung ist bei einer Meldung richtig und bei vierzig eine Zumutung. Der Absender bekommt vierzig E-Mails, die niemand wollte, Ihre Domain schickt vierzig fast identische Nachrichten an eine einzige Adresse – und danach weiß der Absender immer noch nicht, wer den Stapel verantwortet und wann ein Mensch hineinschaut.

Die SLA-Fristen summieren sich. Vierzig Bestätigungsfristen beginnen gleichzeitig, jede für sich in 72 Stunden erfüllbar, zusammen eine Sichtungslast, für die niemand die Bereitschaft dimensioniert hat. Ihre Warteschlange steht je Meldung auf Grün und in der Summe auf aussichtslos. Dasselbe Versagensmuster hat der Artikel zur Offenlegung mit mehreren Herstellern beschrieben, nur umgekehrt: Dort hatte ein Fall viele Fristen, hier teilen sich viele Fälle eine Kapazitätsgrenze.

Schweregrad vor Ursache. Die Sichtung je Meldung fragt zuerst: „Wie schlimm ist diese eine?“ Bei einer Kampagne ist das die zweite Frage. Die erste lautet: „Taugt die Methode dieses Melders, und teilen sich diese Funde eine gemeinsame Ursache?“ Vierzig Funde aus einem Harness gegen einen einzigen Parser sind häufig eine Fehlerklasse mit vierzig Aufrufstellen. Sie einzeln zu sichten kostet das Vierzigfache und liefert die schlechtere Antwort, weil das Muster erst in der Summe sichtbar wird.

Alle drei Fehlfunktionen entspringen einer einzigen Modellierungsentscheidung: Die Meldung ist die Arbeitseinheit. Für eine Kampagne ist sie das nicht.

Eine Kampagne ist keine Meldung: Was Ihr Meldeeingang abbilden muss

Die Lösung ist ein Stapel-Objekt oberhalb der Meldung. Fünf Felder tragen den größten Teil des Nutzens.

1. Ein Stapel, eine Eingangsbestätigung. Eine Antwort, die den Stapel benennt, die Zahl der eingegangenen Funde nennt und ein Datum für die erste inhaltliche Rückmeldung zusagt. Unterdrücken Sie die Mail je Meldung, sobald eine Stapel-ID vorliegt.
2. Ein Verantwortlicher. Ein namentlich benannter Mensch, der für den Stapel geradesteht – nicht vierzig Zuweisungen reihum.
3. Eine gemeinsame Frist für den Stapel, darunter Fristen je Fund. Die Bestätigung schuldet man dem Stapel, die Behebung dem einzelnen Fund.
4. Eine einmal erfasste Methodenbewertung. Ist das Harness solide? Lassen sich die PoCs ausführen? Beantworten Sie das für den Stapel, vererben Sie die Antwort und korrigieren Sie nur dort, wo ein Fund ihr widerspricht.
5. Gruppierung nach Ursache vor der Einstufung des Schweregrads. Erst clustern, dann die Cluster bewerten – nicht die einzelnen Zeilen.

Kit liefert das noch nicht. Die Csirt::-Vertikale behandelt Csirt::Report als oberste Ebene: kein Kampagnenobjekt, kein Einreichungsstapel. Vierzig Meldungen sind vierzig Zeilen, vierzig Bestätigungsmails, vierzig SLA-Fristen, vierzig Meldungen an die Bereitschaft. Das ist das zentrale Argument dieses Artikels, und es beschreibt eine Lücke in unserem eigenen Produkt, keine Funktion darin. Die fünf Felder oben sind die Form, die wir für richtig halten.

Wem gehört die Offenlegungsfrist, wenn der Melder ein Modellanbieter ist?

Niemandem – es sei denn, Sie schreiben sie auf.

Kein Gesetz legt koordinierte Offenlegung auf 90 Tage fest. Es gibt Konventionen – 90+30 bei Project Zero, 90+14 bei ZDI für kooperierende Hersteller – und es gibt denjenigen, der zuerst veröffentlicht. Ist der Melder ein Modellanbieter, verschränkt sich die Frist mit dem Marketing zum Produktstart, denn das Register ist ebenso sehr ein Fähigkeitsnachweis wie ein Offenlegungsartefakt.

Z.ai hat zum Register keine Regelung zu Sperrfristen veröffentlicht: keine Richtlinienseite, keine Frist je Fund, keinen Countdown. Nur Status, Schweregrad und Kennungen. Das ist transparenter als stilles Scannen – und lässt Sie trotzdem ohne genanntes Datum zurück.

Anthropic hat sehr wohl eine 90-Tage-Frist veröffentlicht, und VulnCheck fand zehn Funde, die diese Frist gerissen hatten und trotzdem unveröffentlicht blieben. Die Wahl steht also nicht zwischen einem Anbieter mit Richtlinie und einem ohne. Sie steht zwischen einem Datum in Ihrem Datensatz und einem Datum in der Veröffentlichungsplanung eines anderen.

Drei Felder schließen diese Lücke: requested_embargo_at (was der Melder verlangt hat), agreed_embargo_at (was Sie ausgehandelt haben) und published_at (was tatsächlich geschah). Kit hat sie nicht und sagt das auf der eigenen Vergleichsseite: „Kit bildet überhaupt keine Offenlegungsfristen oder Sperrdaten ab. Ein Feld für ein Sperrdatum ist ein berechtigter Wunsch; heute verfolgt Kit die Bestätigung, nicht die Offenlegung.“ Die einzige 90-Tage-Konstante im Code ist der Ablauf eines Empfangstokens, keine Offenlegungsfrist.

Ratenbegrenzungen sind das falsche Mittel: Was Apples Obergrenze wirklich gebracht hat

Der erste Reflex nach all dem ist, den Absender zu drosseln. Apple hat dieses Experiment in aller Öffentlichkeit durchgeführt, und das Ergebnis ist interessanter als die Schlagzeile.

Im Juni 2026 führte Apple im Portal für Sicherheitsforschung eine Obergrenze für Einreichungen samt 30-tägiger Wartezeit ein; weitere Einreichungen erfordern seither einen gesonderten Antrag. Die Zahl selbst ist unveröffentlicht. Bynario hatte im gesamten Jahr 2025 und Anfang 2026 13 Meldungen eingereicht, baute dann ein KI-Harness und reichte in drei Wochen über 50 macOS-Meldungen ein. Damit stieß Bynario an die Obergrenze und war ausgerechnet in dem Moment aus dem Portal ausgesperrt, in dem ein kritischer Fund vorlag.

Was dabei meist unterschlagen wird: Die Drosselung hat den Fund nicht verhindert. Apple erhielt die Details über einen anderen Kanal und patchte am 27. Juli CVE-2026-43760, einen Confused-Deputy-Fehler im alten VNC-Pfad, über den ein VNC-authentifizierter Betrachter Dateien als root lesen und anlegen konnte. Bynario veröffentlichte die Analyse zwei Tage später, nachdem der Patch ausgeliefert war. Das ist gewöhnliche Forschungsveröffentlichung nach dem Patch, kein frustriert hingeworfener Zero-Day.

Dann kam der Teil, für den die Obergrenze völlig unerheblich war. Bynarios Analyse lenkte die Aufmerksamkeit der Forscherszene auf einen alten Codepfad in Screen Sharing. Binnen 48 Stunden wurde eine separate Schwachstelle vor der Authentifizierung im selben Daemon samt Proof of Concept offengelegt. Vier Tage später kursierte ein einsatzfähiger Exploit, kurz darauf wurde die Lücke in freier Wildbahn für Kryptomining gegen aus dem Internet erreichbare Dienste auf Port 5900 ausgenutzt. Apple lieferte am 6. August einen Notfall-Patch. Die CISA stufte die Lücke am 14. August von 7,1 auf 9,8 hoch und nahm sie am 18. August in den Katalog der bekannten ausgenutzten Schwachstellen (KEV) auf – mit einer Behebungsfrist für US-Bundesbehörden zum 21. August 2026.

Zehn Tage von einem Rechteproblem nach der Authentifizierung zu einer KEV-gelisteten RCE vor der Authentifizierung, in derselben Komponente.

Die Lehre lautet nicht, dass Drosselung Zero-Days verursacht; das überdehnt die Belege. Sie ist enger und nützlicher: Eine Obergrenze für Einreichungen steuert nur, wie schnell Meldungen in Ihre Warteschlange gelangen, und nicht im Geringsten, wie schnell die Welt davon erfährt. Die Kapazität Ihres Meldeeingangs ist die einzige Größe, die Sie auf dieser Zeitachse in der Hand haben, und die Obergrenze hat sie kein bisschen erhöht.

GitHubs bessere Antwort: vier Einreichungen und eine Tür nach draußen

GitHub stieß an dieselbe Wand und entschied sich für Stufen statt für Drosselung. Für Meldungen ab dem 27. Juli 2026 gibt es eine öffentliche Stufe mit festen Auszahlungen von 250 $ / 2.000 $ / 5.000 $ / 10.000 $ für niedrig bis kritisch und eine VIP-Stufe nur auf Einladung mit 1.000 $ / 7.500 $ / 20.000 $ / 30.000 $ und mehr.

Interessant ist die Eintrittstür. Forscherinnen und Forscher unterhalb der Signalschwelle der Plattform erhalten bis zu vier erste Einreichungen, um sich zu beweisen, und die VIP-Tür öffnet sich bei einem gültigen kritischen Fund, zwei hohen, vier mittleren oder sieben niedrigen.

Das ist eine Ratenbegrenzung mit Ausgang. Bynarios Harness hätte vier Einreichungen verbraucht und sich dann mit jedem einzelnen der später gemeldeten kritischen Funde die Überholspur verdient. Apples Obergrenze hat keine Tür: Sie zählt Einreichungen, hört auf zu zählen, und der einzige Weg hindurch ist ein Kalender.

Der Unterschied im Entwurf lässt sich nüchtern benennen: Eine Durchsatzgrenze ist nur dann vertretbar, wenn man sie überwindet, indem man recht behält – und nicht, indem man 30 Tage wartet. GitHubs eigene Zusammenfassung des Umbaus ist der Satz zum Mitnehmen: „Sie verdienen nicht mehr, indem Sie mehr einreichen. Sie verdienen mehr, indem Sie besser einreichen.“

Kit setzt die Vertrauenshälfte dieser Idee um und muss die Drosselungshälfte nachbessern. Csirt::Researcher#karma_tier teilt Forscher nach gesammeltem Karma in Stufen ein und erreicht trusted bei 200 Punkten, gespeist aus vorzeichenbehafteten Csirt::KarmaEvent-Werten: report_validated +5, bounty_awarded +10, dagegen spam_dismissed -10, ai_slop_confirmed -15, policy_violation -25. Karma gilt bewusst je Konto, damit das Urteil eines Programms einem Forscher nicht durchs ganze Internet folgt.

Kits Voreinstellungen hätten einen Fall Bynario trotzdem ausgesperrt. SpamConfig blockiert nach 5 Meldungen in 300 Sekunden, und die Ratenbegrenzung deckelt CSIRT-Einreichungen bei 10 pro Stunde und IP. Ein Melder mit vierzig verifizierten Funden überschreitet beide Grenzen. Das ist Apples Versagensmuster, eingebaut in unsere eigenen Voreinstellungen, und die Lösung ist keine größere Zahl. Sie besteht darin, den Stapel zu zählen statt der einzelnen Anfrage, und karma_tier die Obergrenze anheben zu lassen, wenn ein Melder sich das verdient hat.

Reproduzierbarkeit zuerst: fünf Felder, die Ihre Richtlinie verlangen muss

Ross McKerchar, CISO von Sophos, und Ryan Westman bringen den Standard auf den Punkt: „Programme brauchen klare PoCs, Logs, Traces, betroffene Versionen und reproduzierbare Schritte. Was sich nicht reproduzieren lässt, gehört nicht in die Pipeline.“

Machen Sie daraus Pflichtfelder im Formular, keine Prosa in der Richtlinie. Verlangen Sie:

1. Einen funktionierenden Proof of Concept. Ein Skript, eine Anfrage oder ein Trace. Ein in Prosa beschriebener Exploit ist kein Exploit.
2. Betroffene Versionen, exakt. Ein Commit-SHA oder ein Release-Tag. Niemals „latest“.
3. Reproduktionsschritte, die ein Fremder ausführen kann – vom sauberen Zustand bis zur beobachteten Auswirkung.
4. War ein Teil dieses Fundes modellgeneriert? Ja oder nein, plus welches System. Nicht um zu bestrafen, sondern um die Meldung richtig zu leiten.
5. Hat ein Mensch diesen Fund durchgehend überprüft? Ja oder nein, plus wer.

Feld 5 leistet die eigentliche Arbeit. Es ist der Unterschied zwischen dem Fall Bynario – KI-Ausgabe, von Menschen verifiziert, Ergebnis ein kritischer Fund – und KI-Spam. Kaum jemand fragt heute danach, dabei kostet es zwei Booleans und ein Textfeld.

Sobald Sie Kampagnen annehmen, kommen zwei weitere Felder hinzu: Stapel-ID oder Kampagnenname und gewünschtes Offenlegungsdatum – damit der Melder seine Frist in Ihrem Datensatz nennt und nicht in seinem Blog.

Ab dem 11. September 2026 läuft die Frist der Aufsichtsbehörde

Wenn Sie vernetzte Produkte in die EU verkaufen, kann eine einzige eingehende Meldung eine gesetzliche Frist auslösen, die mit Ihrer Warteschlange nichts zu tun hat. Ab dem 11. September 2026 verlangt der Cyber Resilience Act eine Frühwarnung binnen 24 Stunden, eine vollständige Meldung binnen 72 Stunden und einen abschließenden Schwachstellenbericht binnen 14 Tagen nach einer Korrekturmaßnahme – eingereicht bei Ihrem nationalen CSIRT über die zentrale Meldeplattform des CRA und zeitgleich an die ENISA übermittelt.

Maßgeblich ist Ihre Kenntnis einer aktiven Ausnutzung. Der Frist ist es gleichgültig, ob die Meldung als Position 23 von 40 eintraf, ob überhaupt ein Mensch sie gelesen hat oder ob ein Modell sie geschrieben hat. Ein Stapel, der vier Tage ungelesen liegen bleibt, ist ein Compliance-Risiko und nicht bloß ein Rückstand. Unser Leitfaden zum EU Cyber Resilience Act behandelt die Pflicht in ganzer Breite.

Ohne Meldeeingang wird das Register zu Ihrem Offenlegungskanal

Findet ein Melder keinen Weg, Sie zu erreichen, hört er nicht auf zu melden. Er veröffentlicht.

security.txt ist die billigste Maßnahme der gesamten Sicherheitsbranche und zugleich die am wenigsten verbreitete. Eine Erhebung von 2025 unter einer Million der meistbesuchten Domains fand 1,25 % (12.510 Websites) mit einer solchen Datei, nach 0,7 % im April 2024 – und nur 44 % davon entsprachen RFC 9116. Rund 99 % des Webs haben keinen maschinenlesbaren Sicherheitskontakt, und über die Hälfte der Ausnahmen hat einen fehlerhaften.

Kit erzeugt aus Csirt::SecurityTxtConfig eine konforme Datei mit Contact, Policy, Acknowledgments, Encryption und einem rollierenden Expires über 365 Tage. Wenn Sie noch gar kein Programm haben, beginnen Sie mit unserem Leitfaden zum Aufbau eines Vulnerability-Disclosure-Programms, bevor Sie sich über Stapel Gedanken machen.

Wie Kits CSIRT mit einer Kampagne umgeht – und was noch fehlt

Einiges von dem, was dieser Moment verlangt, ist in Kit bereits ausgeliefert. Anderes nicht, und die Trennlinie ist nützlicher als eine Funktionsliste.

Was heute trägt:

• Strukturierter Meldeeingang statt Freitextfeld. Csirt::Report verlangt title, description, vulnerability_type aus einer festen Liste und affected_endpoint, dazu eine eigene Spalte reproduction_steps. Diese Spalte erlaubt NULL – was die Checkliste oben für falsch hält. Sie zur Pflicht zu machen, ist die Konfigurationsänderung, die dieser Moment verlangt.
• KI-Herkunftsprüfung als eigenständiger Datensatz. Csirt::AiScreening bewertet jede eingehende Meldung und liefert einen ai_confidence_score plus Signale aus einer geschlossenen Aufzählung (hallucinated_functions, fabricated_cves, no_specific_poc, vague_reproduction_steps und weitere) mit der Empfehlung pass / review / flag. Das ist der Reproduktionstest von Sophos, umgesetzt als Spalte statt als Absatz.
• Gruppierung nach Ursache gibt es bereits als Baustein. Meldungen tragen ein Embedding mit 3.072 Dimensionen, und die Duplikaterkennung sucht innerhalb eines Programms per Kosinusähnlichkeit den nächsten Nachbarn. Wo vierzig Funde eine Fehlerklasse sind, ist das der Mechanismus, der vierzig Tickets zu einem zusammenführt.
• Reputation statt Drosselung, über karma_tier.
• SLA getrennt nach Bestätigung und Behebung. Csirt::SlaConfig sieht standardmäßig eine Bestätigungsfrist von 72 Stunden vor, dazu Behebungsziele je Schweregrad von 24 Stunden bei super_critical bis 720 bei Niedrig, plus wiederkehrende Fristwarnungen und Eskalation an die Bereitschaft bei kritischen Fällen.

Was fehlt, formuliert als Fahrplan und nicht als Funktion:

1. Kein Kampagnenobjekt. Vierzig Meldungen sind weiterhin vierzig Zeilen mit vierzig Fristen.
2. Keine Felder für die Offenlegungsfrist. Der Lebenszyklus läuft von submitted über resolved bis paid, ohne jedes Vokabular für die Frist des Melders.
3. Keine deklarierten Kennzeichen für „modellgeneriert“ oder „von Menschen geprüft“. Die Prüfung erschließt die KI-Herkunft im Nachhinein; niemand fragt den Einreichenden.
4. Voreinstellungen zur Drosselung, die einen gutgläubigen Massenmelder aussperren würden – genau wie Apples Obergrenze.

Jeder andere Artikel über dieses Register behandelt es als Geschichte über ein Modell. Es ist eine Geschichte über ein Postfach. Die Funde sind überwiegend echt, überwiegend ungemeldet, und sie kommen. Die Änderung, die Sie darauf vorbereitet, ist klein: Machen Sie die Kampagne und nicht die Meldung zu dem, was Ihr Programm bestätigt, verantwortet und mit einer Frist versieht. Und schreiben Sie das Datum des Melders in Ihren Datensatz, bevor er es in seinen Blog schreibt.