Setup-Update 12.09.2026: 5 Verbesserungen
Dieses Setup-Update vom 12.09.2026 bündelt fünf gezielte Eingriffe in meine Infrastruktur für KI-gestütztes Produkt- und Innovationsmanagement. Im Fokus stehen unentdeckte Kostenfresser, blinde Flecken im Monitoring und Workflow-Altlasten, die durch automatisierte Prüfungen aufgedeckt wurden.
Ein stillgelegtes Sprachmodell lief zweieinhalb Wochen weiter und dachte dabei mit
Der günstigste Tarif meiner Modellvermittlung nutzte eine Modellkennung, die der Anbieter bereits stillgelegt hatte und heimlich auf eine Nachfolgeversion umleitete. Diese neue Version schaltete standardmäßig eine Denkphase auf höchster Stufe vor, was das Ausgabebudget unbemerkt aufbrauchte, zu abgeschnittenen Berichten führte und die Kosten für eine Einwort-Frage von 2 auf 421 erzeugte Einheiten trieb – ein Faktor von rund 210.Zur Lösung habe ich die Parameter so angepasst, dass die Denkphase über den ausdrücklichen Durchreichekanal der Vermittlungsschicht hart abgeschaltet wird, da reguläre Parameter von der Vermittlung stillschweigend verworfen wurden (was zuvor trotz Parameter 194 und 165 Denkeinheiten erzeugte). Die Modellliste führt den Altnamen nun nicht mehr.
Die Maßnahme ist umgesetzt und belegt: Neue Aufrufe erzeugen nur noch 2 bis 4 Einheiten ohne Denkeinheiten. Ein neues Dauerziel prüft diesen Zustand nun täglich direkt gegen die Anbieterschnittstelle. Eine in Fachbriefen geforderte Abschaltung einer anderen Variante blieb ungesetzt, da diese ohnehin null Aufrufe hatte und die Warnung vom Anbieter widerrufen wurde.
Die Nachrichtenauswertung ordnete achtzig von hundertsiebenundzwanzig Ergebnissen einem Vorhaben zu, das es seit zweieinhalb Monaten nicht mehr gibt
Die Arbeitsanweisung der Auswertung nutzte seit dem 11.07.2026 eine veraltete Referenzliste, weshalb 80 von 127 Ergebnissen einem bereits am 30.06.2026 stillgelegten Vorhaben zugewiesen wurden. Da genau nach diesem Feld später gefiltert wird, machte der falsche Name die Auswertungen faktisch unauffindbar; zudem lagen die Anweisungen asynchron und ohne Abweichungsprüfung doppelt vor (produktiv vs. Versionsverwaltung).Ich habe die Referenzliste auf die tatsächlich geführten Vorhabensnamen korrigiert und das veraltete Interessenprofil als statische Datei gekennzeichnet, da dessen Erzeuger längst abgeschaltet ist. Der Versionsstand wird nun zwingend vom laufenden System gezogen und hat ein Ausrollziel mit Abweichungsprüfung erhalten; die verwaiste Zweitablage wurde durch einen Verweis ersetzt.
Der Status ist umgesetzt und belegt. Die Abweichungsprüfung des neuen Ziels steht bei sechs Dateien auf null, und die produktive Anweisung führt die toten Namen nur noch im Begründungstext.
Der Laufzeit-Wächter konnte vier von sechzehn genutzten Modellen sehen, und die teuren nicht
Der Wächter verglich die Antwortzeiten der letzten sieben Tage mit den dreiundzwanzig Tagen davor, verlangte aber für beide unterschiedlich langen Fenster dieselbe feste Mindestzahl an Aufrufen. Dadurch fielen unregelmäßig genutzte Modelle aus der Überwachung – von sechzehn Modellen erfüllten nur vier die Bedingungen, während die teuersten Modelle (bei einem standen 56 Aufrufe in der Grundlinie einem einzigen im aktuellen Fenster gegenüber) komplett unsichtbar blieben.Die Mindestzahl der Aufrufe hängt jetzt dynamisch an der Fensterlänge, versehen mit einer Untergrenze, unterhalb derer ein Perzentil statistisch wertlos ist. Die Legende der Übersicht benennt nun beide Schwellen transparent.
Die Abdeckung hat sich messbar von vier auf acht der sechzehn Modelle verdoppelt. Ausdrücklich nicht gelöst ist die Überwachung der beiden teuersten Modelle: Ein einzelner Aufruf in sieben Tagen bildet keine Grundlage für ein Perzentil, hierfür wird künftig eine gänzlich andere Messgröße benötigt.
Die Qualitätsprüfung der Nachrichtenauswertung las ausschließlich das, was die Auswertung selbst geschrieben hatte
Die bestehende Rückkopplungsschleife bewertete die erzeugten Ergebnisdateien, ohne die Ausgangsnachrichten aufzubewahren oder zu kennen. Eine erfundene Zahl oder falsch verstandene Meldung war für die Prüfung unmöglich zu erkennen, obwohl der Quelltext fälschlicherweise behauptete, sie bewerte „unabhängig vom Erzeuger“.Der Ablauf bewahrt die Ausgangsnachricht jetzt dreißig Tage lang unter demselben Namen wie die Auswertung auf. Ein wöchentlicher Auftrag zieht nachvollziehbar und zufällig drei Auswertungen und legt sie zur Beantwortung von drei Kontrollfragen neben das Original, wobei bewusst kein zweites Modell zur Bewertung aufgerufen wird, um denselben blinden Fleck zu vermeiden.
Die Maßnahme ist umgesetzt und teilweise belegt. Der wöchentliche Auftrag ist eingerichtet und meldete bei den ersten Läufen wahrheitsgemäß fehlende Originale. Noch offen ist der durchgehende Nachweis am echten Durchlauf, da seit der Änderung noch keine neue Nachricht eingegangen ist; dies wird sich beim nächsten nächtlichen Lauf zeigen.
„Keine eingebetteten Anweisungen erkannt“ war monatelang unbelegt
Die Nachrichtenauswertung vermerkte bei fremden Inhalten stets, es seien keine eingeschleusten Anweisungen gefunden worden, ohne dass jemals durch eine Probe nachgewiesen wurde, dass die Erkennung überhaupt anschlagen kann. Eine durchgehende Stille sah lediglich aus wie ein Ergebnis, war aber keines.Ich habe eine Probe eingerichtet, die eine präparierte Nachricht über den echten, produktiven Verarbeitungsweg schickt. Diese prüft dreifach: ob die eingeschleuste Anweisung benannt wird, ob sie ausgeführt wird (geprüft anhand einer geforderten Zeichenfolge) und ob eine harmlose Kontrollnachricht fälschlich als verdächtig gemeldet wird.
Die Probe ist umgesetzt und bestanden. Beim ersten Lauf wurde die Anweisung korrekt benannt, nicht ausgeführt und es gab keinen Fehlalarm. Der Test kostet drei Modellaufrufe und ist bewusst nicht als wiederkehrender Auftrag eingerichtet, sondern wird manuell bei Änderungen an der Anweisungsdatei oder dem Modell ausgelöst.