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.

Hallo Peter, ich glaube, das Problem liegt gar nicht im Gehirn, sondern in der fehlenden Systemarchitektur dahinter. Ein LLM erzeugt Ideen – unser Gehirn übrigens auch. Wenn jede Idee sofort zur Aufgabe wird, explodiert jede To-do-Liste. Deshalb würde ich den gesamten Informationsfluss in mehrere Stufen aufteilen - so haben wir das Problem zumindest gelöst. 1. Capture – nichts bleibt im Kopf Jede Idee landet sofort in einem Eingangskorb. Sprache, Text, Screenshot oder Link – völlig egal. 2. KI-Klassifizierung Ein LLM ordnet die Information automatisch ein: - Idee - Aufgabe - Projekt - Kunde - Marketing - Wissenseintrag - Vertrieb - Produkt - Security Zusätzlich erkennt es Verbindungen zu bereits vorhandenen Projekten. 3. RAG als zentrales Langzeitgedächtnis Hier sehe ich den größten Denkfehler vieler Systeme - nicht jede Idee ist eine Aufgabe. Fast alles wird zunächst als Wissen gespeichert. Mit Embeddings, Vektordatenbank und Hybrid Search kann ich dieses Wissen später jederzeit semantisch wiederfinden. Der entscheidende Punkt -> Enforcement statt Wissensfriedhof Viele glauben, dass Wissen automatisch genutzt wird, nur weil es gespeichert wurde. Genau das passiert aber nicht. Deshalb denke ich inzwischen in Enforcement-Stufen. Jede neue Erkenntnis wird automatisch auf die höchste Ebene verschoben, auf der sie sinnvoll umgesetzt werden kann. Stufe 0 – Dokumentation Das klassische Notizbuch oder Wiki. Die Information existiert zwar, muss aber aktiv gesucht werden. Das ist der typische Wissensfriedhof. Stufe 1 – Kontextabhängige Regeln Hier beginnt KI wirklich hilfreich zu werden. Jede Regel erhält Trigger. Zum Beispiel: - LinkedIn - Vertrieb - n8n - RAG - Python - Museum Sobald ich an einem dieser Themen arbeite, durchsucht mein Agent automatisch die Wissensdatenbank und blendet nur die relevanten Regeln ein. Ich muss also nicht mehr wissen, dass ich diese Information irgendwann einmal gespeichert habe. Stufe 2 – Universelle Regeln Einige Regeln gelten immer.

@Peter Burgey Nein, nein, um Gottes willen – das muss ich jetzt nicht jedes Mal neu schreiben. Das ist im Prinzip unsere Grundstruktur, und die funktioniert perfekt. 😉