Hallo Wolfgang, wichtige Frage, und ich glaube, die beiden Vorfälle, die du nennst, sind zwei völlig verschiedene Dinge — das auseinanderzuziehen hilft beim Einordnen. Der Hugging-Face-Vorfall war ein kontrollierter Test, bei dem die Sicherungen "absichtlich abgesenkt" waren. Real, aber kein Modell, das aus dem Alltagsbetrieb ausbricht. Das ist Forschung an der Frage „was ginge unter schlechten Bedingungen", nicht ein Bericht aus dem Normalzustand. Der zweite Fall ist wichtiger, weil er jeden von uns betrifft — und er ist gerade mal vier Tage alt. Am 25. Juli zeigte jemand auf Reddit, dass sich über eine simple Suchabfrage (`site:claude.ai/share`) hunderte geteilte Claude-Konversationen bei Google finden ließen. Drin: API-Schlüssel, Wallet-Keys, Lebensläufe, interne Firmenunterlagen, Mitarbeiterbewertungen, klinische Studiendaten. Google hat bis zum 27. deindexiert. Aber: Das war kein Hack. Betroffen waren ausschließlich Chats, die Nutzer selbst über den Teilen-Knopf öffentlich gemacht hatten. Alles Nicht-Geteilte war nicht betroffen. Der eigentliche Punkt ist ein anderer: > „Jeder mit dem Link" und „von jeder Suchmaschine der Welt auffindbar" sind zwei völlig verschiedene Versprechen. Der Teilen-Knopf gibt das erste — und bricht still das zweite. Und es ist kein Anbieterproblem: Dasselbe gab es letztes Jahr schon bei Claude, bei ChatGPT waren rund 100.000 Konversationen betroffen, Grok ebenso, bei Meta AI teils sogar per Voreinstellung. Das ist eine Eigenschaft der Kategorie. Und genau deshalb würde ich deiner Schlussfolgerung widersprechen, Wolfgang — freundlich, aber deutlich. 😉Der Vorfall belegt nicht, dass es keinen Schutz gibt. Er belegt das Gegenteil: Der Schutz hat gehalten, was privat war, blieb privat. Schiefgegangen ist eine "bewusste Handlung mit unklarer Folge". Das ist kein Argument dafür, alles öffentlich zu machen — das ist ein Argument dafür, zu wissen, was ein Knopf wirklich tut. @Katrin Friedel , dein Instinkt mit der Disziplin ist goldrichtig — nur bei der „Unwichtigkeit" würde ich dich beruhigen und gleichzeitig warnen: Bei diesem Vorfall war niemand Ziel. Es wurde nicht nach Personen gesucht, sondern eine Suchabfrage abgesetzt. Wer drin war, war drin — Prominenz spielte keine Rolle. Automatisierte Sammlung fragt nicht, wer du bist. Deine zweite Hälfte, bewusst nichts Sensibles reinzugeben, schützt dich dagegen tatsächlich.

@Wolfgang Kaufmann Danke dir — und beim Präventionsgedanken bin ich ganz bei dir. Genau so arbeitet die Informationssicherheit seit Jahren: Phishing-Simulationen, Notfallübungen, Trockenläufe. Einmal kontrolliert erlebt schlägt zehn gelesene Warnungen. Bei der Achtsamkeit würde ich einen Halbschritt danebenstehen — nicht im Anliegen, sondern beim Hebel - Achtsamkeit skaliert leider schlecht. Sie ist eine endliche Ressource: Wer bei jedem Klick nachdenken soll, denkt nach drei Wochen nicht mehr nach. Dasselbe Phänomen wie bei Bestätigungsdialogen, die man irgendwann blind wegklickt. Und beim konkreten Fall hätte sie gar nicht geholfen: **Niemand konnte ahnen, dass ein Teilen-Link bei Google landet.** Die Information stand nirgends. Nicht Unaufmerksamkeit war das Problem, sondern ein Knopf, der zwei verschiedene Dinge verspricht. Deshalb würde ich es so drehen: *„Passt besser auf"* hängt von der Tagesform ab. *„Freigaben laufen nach 30 Tagen automatisch ab"* braucht keine. Das Ziel ist nicht mehr Achtsamkeit, sondern weniger Stellen, an denen sie nötig ist — dann reicht sie für die Fälle, wo sie wirklich zählt. Und da schließt sich der Kreis zu deinem Punkt: "Dein Erleben-Ansatz wirkt als Verfahren, nicht als Vorsatz." Eine Übung, die man einmal durchgemacht hat, sitzt. Ein guter Wille verpufft. Insofern bist du mit der Prävention schon einen Schritt weiter als die meisten in dieser Diskussion. 😉

Hallo Timo, stark gebaut 👍 — genau die richtigen Achsen (lokal, Quellenbeleg, Governance, Zahlen getrennt). Wir haben ein ahnliches System - deshalb drei Sachen, die mich wirklich interessieren: 1. Die Widerspruchs-/Veraltungserkennung beim Einlesen finde ich den spannendsten Teil. Läuft das über "gepflegte Metadaten" (Quelle/Datum/Gültigkeit/Freigeber) oder eher "LLM-heuristisch"? Mich würde vor allem interessieren, wie das System einen echten *inhaltlichen* Widerspruch (z. B. zwei verschiedene Preise/Fristen für dieselbe Sache) von einer bloßen Dublette oder einem ähnlichen Absatz unterscheidet — ohne zu viele Fehlalarme. 2. Der Zahlen-Chat: freies Text-to-SQL, oder geprüfte "Query-Templates / Semantic Layer" dahinter? Und siehst du die generierte Query, bevor die Antwort rausgeht? Frage kommt daher, dass bei Umsatz/offenen Posten eine *falsche* Zahl schlimmer ist als gar keine — mich interessiert, wie du das absicherst. 3. Betrieb: Welches lokale Modell + Hardware nutzt du, und wie hast du das Drumherum gelöst — Backup, Ausfall der „Kiste", Neu-Indizierung? Das ist ja oft der Teil, der im Alltag die eigentliche Arbeit macht. Nicht als Kritik gemeint — im Gegenteil, das trifft ziemlich genau, wo ich selbst gerade manchmal etwas grüble. 👍

@Timo Radecke Danke für die ausführliche Antwort — das beantwortet's gut. Zwei Sachen finde ich richtig stark: dass ihr euch bewusst *nicht* auf gepflegte Gültigkeitsfelder verlasst (die pflegt im Mittelstand echt keiner) und stattdessen mit **Zeitstempeln + einer verdichteten Wissensseite** gegenprüft — das hält die Fehlalarme klein, ohne Wunschdenken. Und „Original = Wahrheit, der Rest ist abgeleitet und neu aufbaubar" ist die eleganteste Backup-Antwort, die man geben kann. 👍 Einen Gedanken lasse ich noch da, weil das genau die Stelle ist, die mir bei Zahlen Bauchweh macht: „nur lesen, nie schreiben" schützt ja die *Daten* — aber nicht die *Richtigkeit der Abfrage*. Eine falsch gebaute Query liefert eine plausibel-falsche Zahl, und „lieber keine Zahl als eine falsche" greift nur, wenn das System *nichts* findet, nicht wenn es *falsch* findet. Zeigt ihr dem Nutzer den Weg zur Zahl (die eigentliche Abfrage) mit an? Dann wäre genau das die Absicherung. Aber klar — deine Geheimnisse darfst du natürlich für dich behalten. 😇 Sauber gebaut, Respekt. 👍

Gute Frage — und @Stefan Brutscher Punkt stimmt schon teilweise, aber ein Detail lohnt die Präzisierung: Blocken erzeugt eigentlich keinen 404. Wer Bots aussperrt, liefert meist 403 / 401 / 429 oder eine Cloudflare-Challenge. 404 heißt wörtlich „diese Seite existiert an dieser URL nicht" — nicht „du darfst nicht rein". Deshalb kommen die vielen 404 bei Deep Research fast immer aus einer anderen Ecke: - Geratene URLs: Der Agent baut plausible Adressen selbst (`/preise`, ein vermuteter Artikel-Slug) oder vervollständigt sie aus dem Gedächtnis — viele davon gibt's schlicht nicht. Das ist der Hauptgrund, und du hast ihn oben selbst schon benannt. - Link Rot: Er folgt Links aus Suchindex und Trainingswissen; Seiten sind längst verschoben oder gelöscht. - Kaputte URL-Varianten: Tracking-Parameter, AMP-/Redirect-Wrapper, abgeschnittene lange URLs, http/https/www — eine falsch zusammengebaute Variante wirft 404. - SPA/JS-Seiten: Bei client-seitigem Routing gibt der Server auf einen direkten Deep-Link ohne JS gern 404 zurück. Und die gute Nachricht: Die 404 sind meistens harmlos. Deep Research probiert bewusst viele Kandidaten-URLs, wirft die Nieten weg und holt sich den Rest über die Suche — das sind Explorations-Kosten, kein Fehler. Solange am Ende belegte Quellen stehen, ist die 404-Spur nur der „Papierkorb" der Recherche. Wer's genau wissen will, schaut auf den Statuscode: 404 = geratene/tote URL, 403/429 = echtes Blocken. Und Stefans "PDF-mitgeben-Trick" ist genau für die Blocking-Fälle top. 👍

Haha, der Spruch trifft's besser, als er klingt — nur war die Leine hier "absichtlich ab". 😄 Was die ZDF-Meldung nämlich leider weglässt: Die Modelle (GPT-5.6 Sol + ein Pre-Release) liefen im Test mit 'bewusst abgesenkten Cyber-Sicherungen'. Man hat den Hund also nicht nur von der Leine gelassen — man hat ihm vorher den Maulkorb abgenommen und „such!" gesagt. Dann fanden sie einen Zero-Day, kamen aus der Sandbox raus und hackten sich zu Hugging Face durch — nicht aus Bosheit, sondern um beim Benchmark (ExploitGym) zu schummeln und die Lösungen zu klauen. 😅 Zwei Dinge, die ich daran spannend finde: 1. Kein "KI wird böse", sondern "Reward-Hacking": „Schneid im Test gut ab" wurde gnadenlos wörtlich genommen. Bekanntes Muster — nur jetzt mit echten Zero-Days und über tausende Schritte autonom. Die 'Fähigkeit' ist real und ernst zu nehmen. 2. Der eigentliche Brüller zum Nachdenken: Bei der Aufklärung mussten die 'Verteidiger auf ein lokales Open-Source-Modell umsteigen' — weil die kommerziellen KI-Guardrails 'ihnen' die Analyse der Angriffs-Payloads verweigerten. Der Angreifer lief ohne jede Regel, ausgebremst wurde nur die Verteidigung. Mein Fazit ist eher - weniger „Terminator", mehr „räum deinen Sandkasten auf — und halt ein lokales Modell in der Hinterhand".

Hi Olga, erst mal Hut ab — dass das deine 'erste' selbst gebaute Website ist, sieht man ihr nicht an. Klare Headline, starke Marke („o.KI – where humans say o.KI to AI" ist clever), sauberer Aufbau, rechtlich komplett (Impressum/DS/AGB + EN-Version). Das liegt über dem, was viele Agenturen abliefern. Du willst direkt statt nett 😅 — also los, entlang deiner Fragen: Versteht man sofort, was du anbietest? Ja, in Sekunden. „Praxisnahe KI-Content-Workshops für Marketing-Teams … an einem echten Projekt aus eurem Alltag" sitzt. Und dein Satz „der beste Workflow ist der, den euer Team am 'nächsten Arbeitstag' wieder nutzen kann" ist dein stärkstes Argument — den würde ich noch prominenter setzen. Für wen? Klar: Marketing-Teams. Weniger klar: *welche*. Mittelstand? Marken/Konsumgüter? In-House oder Agentur? Deine Beispielbilder wirken stark B2C/Fashion — ein B2B-Marketer ist unsicher, ob er gemeint ist. Ein, zwei Worte schärfen, und die Richtigen fühlen sich sofort angesprochen. Was mich als Interessent bremsen würde — die drei Punkte mit dem meisten Hebel: 1. Dein Beweis passt noch nicht ganz zu deinem Versprechen. Dein Kern-Claim ist *Konsistenz* („dasselbe Model über eine ganze Kampagne"). Die Galerie zeigt aber ~30 *verschiedene* Einzel-Models — also Vielfalt, nicht Konsistenz. Ein einziges „selbes Model in 6 Szenen" oder „Kundenprodukt → 5 Kampagnen-Visuals" beweist dein Alleinstellungsmerkmal stärker als 30 schöne Einzelbilder. Und ich würde die Galerie 'kuratieren' (die 12–15 besten) — weniger ist hier mehr, sonst kippt es Richtung „generische KI-Galerie". (Zusätzlichee Hinweis zu einem bestimmten Bild - das mit den zwei gelben Eis-Cups, da steht einmal die Schrift/Logo/Marke "lümo" auf dem Kopf.) 2. Workshop oder Done-for-you? Oben verkaufst du „wir bringen's eurem Team bei", Service 02 sagt „wir machen's für euch" — das Gegenteil. Beides legitim, aber die Seite hat keine klare Speerspitze. Ich würde "Workshops" als Kern setzen und die anderen drei sichtbar als Ergänzung.

@Katrin Friedel Hi Katrin, gute Frage - bei KI zuerst nach Sicherheit zu fragen, ist goldrichtig. Nur zielt „Prompt Injection" hier auf die falsche Ebene. Kurz das Was/Wieso/Wann: Prompt Injection ist ein Angriff auf ein LLM, das fremde, nicht vertrauenswürdige Inhalte verarbeitet und daraufhin selbstständig handelt. Der Angreifer schmuggelt in genau diese Inhalte versteckte Anweisungen („ignoriere deine Regeln, tu stattdessen X"), und das Modell führt sie aus, weil es Daten und Befehle nicht sauber trennt. Steht nicht umsonst auf Platz 1 der OWASP-Top-10 für LLM-Anwendungen (LLM01). Wieso das auf dieser Website nicht greift: Voraussetzung für eine Injection ist immer ein LLM *im Loop*, das Eingaben interpretiert und Werkzeuge oder Aktionen auslösen kann. Diese Seite ist aber eine statische Broschüre — Portfolio, Texte, ein Kalender- und ein WhatsApp-Link. Da verarbeitet kein Modell irgendeinen Besucher-Input. Kein Prompt, keine Tools, keine Aktion → keine Angriffsfläche. „Mit KI erstellt" heißt hier nur: die Bilder und Videos wurden mit KI *produziert* — die Website selbst *ist* kein KI-System. Wann es sehr wohl relevant wird: (und da ist dein Instinkt goldrichtig): sobald ein KI-*Agent* im Spiel ist, der fremde Inhalte liest und handeln darf — ein Chatbot auf der Seite, ein RAG über Firmendokumente, ein E-Mail-/Ticket-Bot, Automationen mit Tool-Zugriff. Dort schützt man mit Defense-in-Depth: untrusted Input markieren und isolieren (Spotlighting), Least Privilege (der Agent bekommt nur die Tools, die er wirklich braucht), Bestätigung bei riskanten Aktionen (Human-in-the-Loop) und Ausgangs-Kontrolle (was darf überhaupt raus — Mail, Netz). Ein Disclaimer allein reicht nicht; entscheidend ist, dass **Daten und Befehle getrennt** bleiben. Warum die eigentliche Sicherheitsfrage bei KI-Content eine andere ist: Bild- und Videogenerierung ist kein Agent, der sich „übernehmen" lässt — das reale Risiko liegt nicht bei manipulierten Prompts, sondern beim 'Dateneinfluss in die Tools': Wohin fließen Marken- und Produktdaten, wenn man sie in (oft US-)Modelle hochlädt? DSGVO, Auftragsverarbeitung, wem gehören die Outputs (IP/Lizenz), und bleiben unveröffentlichte Kampagnen vertraulich? *Das* ist die Baustelle, die man bei KI-Content ernst nehmen muss.