Mein Setup-Update vom 16.08.2026 fasst sieben konkrete Verbesserungen an meiner Infrastruktur für Wissensmanagement und KI-Prozesse zusammen. Der Fokus lag heute auf Datensicherheit, Kostenkontrolle und der Qualitätssicherung automatisierter Workflows.
Lizenzschlüssel im Klartext aus dem Vault entfernt — samt Suchindex
Eine alte Kaufbestätigungs-Notiz enthielt einen 32-stelligen Lizenzschlüssel im Fließtext, der durch die Volltextindizierung meiner Wissensdatenbank auch für maschinelle Pipelines auslesbar war. Ich habe den Schlüssel in der Datei durch einen Platzhalter ersetzt und einen Warnhinweis ergänzt. Das eigentliche Problem war jedoch der Suchindex: Ein normaler Reindex übersprang die Datei als unverändert, sodass der Schlüssel im Index verblieb. Erst ein erzwungener Neuaufbau des Index über alle 9.306 Notizen entfernte das Secret vollständig. Ein anschließender systematischer Scan der gesamten Wissensdatenbank nach 32-Hex-Ketten lieferte 20 Treffer, wovon 19 Fehlalarme waren. Der einzige weitere echte Treffer in einer Tunnel-Konfiguration enthielt glücklicherweise nur die Token-ID, das eigentliche Secret war bereits ein Platzhalter. Die Datei und der Index sind nun bereinigt, die eigentliche Rotation des Schlüssels beim Anbieter steht noch offen.
Neun Captures mit personenbezogenen Daten aus dem Vault genommen
Der Notiz-Bestand aus dem Februar lief noch über eine alte Pipeline, in der die automatische Erkennung von personenbezogenen Daten fehlte. Bei einer Überprüfung fand ich sensible Daten wie Kontaktdaten, eine GPS-Position, eine eSIM-EID sowie eine komplette Inventarliste des Heimnetzes mit Hostnamen und MAC-Adressen. Ich habe die betroffenen Dateien reversibel in ein internes Verzeichnis verschoben, jeweils mit einer Begründung versehen und den Index neu aufgebaut. Ein systematischer Musterscan über alle 392 Februar-Notizen fand 13 Kandidaten, von denen acht reine Firmen-Impressen waren und bleiben durften. Eine technische Hürde bleibt jedoch ungelöst: Da der Indexer aus einer Datenbank und nicht direkt vom Dateisystem liest, verbleiben bereits gelöschte Dateien teilweise im Index. Ein tiefer Eingriff in die Datenbank-Synchronisation ist mir aktuell zu riskant, weshalb dieser Punkt bewusst offengelassen wurde.
KI-Hinweis in beiden Chat-Demos — EU-KI-VO Art. 50 gilt seit 02.08.2026
Gemäß Artikel 50 der EU-KI-Verordnung müssen Nutzer darüber informiert werden, wenn sie mit einer KI interagieren — eine Frist, die im Gegensatz zu anderen Verordnungs-Teilen nicht verschoben wurde. Meinen beiden öffentlichen Chat-Demos fehlte dieser zwingende Hinweis. Ich habe daher entsprechende Banner ergänzt und in den laufenden Instanzen verifiziert. Der erste Versuch blieb wirkungslos, da die Banner-Konfiguration in der verwendeten Chat-Oberfläche nicht aus der Datenbank, sondern ausschließlich aus den Umgebungsvariablen gelesen wird; erst die Anpassung im Deployment-Setup brachte den Erfolg. Dabei fiel mir auch ein Fehler in einer älteren Dokumentation auf, in der ich fälschlicherweise notiert hatte, dass aktuell kein naher Gesetzes-Trigger ansteht. Die visuelle Kennzeichnung ist nun live, die Implementierung einer maschinenlesbaren Kennzeichnung ist noch offen.
Zwei Wächter für die Headless-Lane + die Kostenannahme präzisiert
Ein Modellanbieter trennt seit Mitte Juni interaktive von programmatischer Nutzung und deckelt letztere mit einem festen Monatsguthaben. Eine Nachmessung an meinem Automatisierungs-Layer zeigte für diesen Pfad 363 Läufe seit Ende Juli ohne Fallback, was hochgerechnet Schattenkosten von 95 bis 120 US-Dollar pro Monat entspricht und damit hart an der Kappungsgrenze kratzt. Um Ausfälle zu vermeiden, habe ich zwei Alarme im Monitoring eingerichtet: Der erste warnt, wenn der 30-Tage-Schattenpreis 95 US-Dollar übersteigt. Die Schwelle liegt bewusst nicht bei 80 Dollar, da der Ist-Stand bereits bei knapp 83 Dollar lag und ein Dauer-Alarm seinen Zweck verfehlt. Der zweite, kritische Alarm feuert, wenn 26 Stunden lang kein erfolgreicher Lauf protokolliert wird. Da das Skript bei leerem Guthaben einfach fehlschlägt, ist das Ausbleiben von Erfolgsmeldungen der zuverlässigste Indikator für ein blockiertes Limit. Das Auslesen des tatsächlichen Guthabenstands über eine API ist noch offen.
Kennzahl „Tokens je Lauf" ins LLM-Controlling-Dashboard
Bei der Auswertung von Übersetzungs-Jobs fiel auf, dass Gemini 3 Flash für das exakt gleiche Ergebnis 2,0- bis 2,6-mal so viele Token benötigte wie DeepSeek V3.2. Die Ursache liegt in der Architektur der Tokenizer, nicht im Modell selbst. Zieht man die Preisunterschiede hinzu, ergibt sich ein Kostenfaktor von 12. Das beweist, dass der reine Vergleich von Sprachmodellen über den Preis pro einer Million Token strukturell falsch ist. Um dies künftig sichtbar zu machen, habe ich zwei neue Metriken in mein Controlling-Dashboard integriert, die die Token je Lauf aufgeschlüsselt nach Modell und Job darstellen. Die Daten dafür wurden aus bereits vorhandenen Metriken abgeleitet, es war keine neue Messung erforderlich.
Subagent-Regel auf die Achse Parallelisierbarkeit umgestellt
Eine Studie zu Multi-Agenten-Systemen zeigte, dass die bisherige Sortierung von Subagenten-Einsätzen nach bloßem Aufgabentyp zu kurz greift. Löst ein einzelner Agent bereits mehr als 45 Prozent einer Aufgabe, bringen weitere Agenten kaum Mehrwert. Gravierender noch: Bei sequenziellen Ketten wird das Ergebnis um 39 bis 70 Prozent schlechter, während parallelisierbare Teilaufgaben um bis zu 80 Prozent besser gelöst werden. In meinem Regelwerk stand bei der Feature-Implementierung fälschlicherweise der Vermerk "parallel", obwohl es sich um den Musterfall einer sequenziellen Kette handelt. Ich habe die entsprechende Zeile korrigiert und eine neue Spalte für die Struktur-Achse ergänzt. Interessant am Rande: Nur eine der sechs erfassten Quellen-Notizen enthielt die entscheidenden Zahlen – eine reine Sortierung nach Titeln hätte diesen wichtigen Befund verschluckt.
Coverage-Check: Trefferwort ausgeben + zweite Negativkontrolle
Ein Skript zur Abdeckungsprüfung meldete 15 von 16 Themen-Kandidaten als erfolgreich abgedeckt. Das Ergebnis war jedoch wertlos, da die Treffer auf generischen Wörtern wie "Token", "Daten" oder "Format" basierten. Die eingebaute Negativkontrolle schlug nicht an, da sie nur prüfte, ob völlig erfundene Themen gefunden werden, nicht aber, ob echte Themen aus den falschen Gründen anschlagen. Ich habe die Stoppwortliste um 20 Füllwörter erweitert und eine zweite Negativkontrolle eingebaut, die gezielt aus Füllwort-Kandidaten besteht und abbricht, wenn diese belegt werden. Zudem gibt das Tool nun das konkrete Trefferwort je Kandidat aus. Zuletzt wurde ein Parser-Fehler behoben, bei dem die Relevanz-Einstufung fälschlicherweise als Suchbegriff gewertet wurde. Nach diesen Anpassungen meldet das Skript nun realistische 10 statt 15 abgedeckte Themen, inklusive transparenter Begründung.