Kurz gesagt: Rekursive Selbstverbesserung ist keine Enterprise-Funktion, die Sie einfach aktivieren. Sie ist ein Change-Management-Problem. KI übernimmt bereits mehr Engineering-Arbeit bei der Entwicklung von KI, doch die Belege rechtfertigen nicht die Annahme, heutige Systeme würden sich nach dem Deployment autonom und sicher selbst aktualisieren. Beschaffung und Betrieb brauchen deshalb ein Release-Gate, einen Evaluierungsnachweis und eine verantwortliche Person für jede wesentliche Modell- oder Agentenänderung.
Was sich tatsächlich verändert
Die jüngste Everyday-AI-Episode verknüpft unter dem Begriff „Recursive Self-Improvement“ Modellökonomie, Coding Agents und Sicherheit. Die dort genannten Modellvarianten und Preisbehauptungen ließen sich nicht durch Primärquellen bestätigen; sie werden hier daher nicht wiederholt. Die zugrundeliegende Entwicklung ist real, aber enger gefasst: Frontier-Labs übertragen KI-Agenten mehr Arbeit beim Entwickeln und Testen von KI, während Menschen Ziele setzen und Ergebnisse prüfen.
Anthropic beschreibt dies konkret: Claude habe im Mai mehr als 80 Prozent des in die eigene Codebasis übernommenen Codes erstellt; Ingenieurinnen und Ingenieure steuerten und prüften diese Arbeit. Anthropic schreibt zugleich, KI könne gut spezifizierte Experimente ausführen, während bei Zielwahl und Urteilsvermögen deutliche Lücken blieben. Dieser Unterschied ist entscheidend. KI-gestützte Forschung und Entwicklung ist nicht dasselbe wie ein ausgerolltes Modell, das ohne wirksame menschliche Kontrolle seinen Nachfolger auswählt, trainiert und freigibt.
Quelle: Anthropic, „When AI builds itself“ — https://www.anthropic.com/institute/recursive-self-improvement
Warum dieser Unterschied für europäische Unternehmen zählt
Ein schnellerer Entwicklungszyklus bei Modellen kann den Betrieb dennoch direkt verändern. Anbieter können Modellverhalten, Zuverlässigkeit der Tool-Nutzung, Latenz, Preise oder Sicherheitsmaßnahmen häufiger ändern. Ein Agent, der für interne Dokumentationsentwürfe akzeptabel war, kann nach einem Modellupdate oder einer geänderten Tool-Policy für Bestellungen, Produktionsplanung oder die Priorisierung von Servicefällen ungeeignet sein.
Das operative Risiko ist keine abstrakte „Intelligenzexplosion“, sondern stiller Verhaltensdrift: Ein überarbeitetes Modell kann einen allgemeinen Benchmark bestehen und dennoch Anweisungen in Ihrer Sprache anders befolgen, andere Belege abrufen, ein Tool an der falschen Grenze aufrufen oder ein anderes Vertrauensmuster zeigen. Release Notes des Anbieters sind nützliche Evidenz, aber kein Abnahmetest für Ihren Prozess.
Für Hochrisiko-KI verlangt Artikel 9 des EU AI Act ein kontinuierliches, iteratives Risikomanagement über den gesamten Lebenszyklus, einschließlich regelmäßiger Überprüfung und Aktualisierung, Tests anhand vorab definierter Metriken sowie angemessener Kontrollen. Das ist keine Rechtsberatung; die Einstufung erfordert eine Einzelfallprüfung. Als Engineering-Muster ist es jedoch auch außerhalb des formalen Hochrisiko-Regimes sinnvoll.
Quelle: AI Act Service Desk der Europäischen Kommission, Artikel 9 — https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-9
Bauen Sie ein Release-Gate, bevor Updates zur Routine werden
Behandeln Sie jede wesentliche Änderung an Modell, Prompt, Retrieval, Tool-Berechtigung oder Agenten-Policy als versioniertes Release. Halten Sie die Produktionsbasis fest. Prüfen Sie Kandidaten in einer Staging-Umgebung mit einem festen Evaluierungssatz aus echten, zulässigen Fällen. Messen Sie Aufgabenerfolg, schädliche Fehlverhalten, Latenz, Kosten, Retrieval-Qualität und Tool-Call-Verhalten; verlassen Sie sich nicht auf einen einzelnen Gesamtwert. Dokumentieren Sie Modellkennung, Anbieterregion, Konfiguration, System-Prompt, Tools, Testergebnisse, Freigabe und Rollback-Entscheidung.
Das Gate braucht eine eindeutig verantwortliche Person. Bei Copilots mit niedriger Auswirkung kann der Service Owner eine klar begrenzte Änderung nach automatisierten Regressionstests freigeben. Bei Abläufen mit Auswirkungen auf Beschäftigte, Kundschaft, Finanzen, Sicherheit oder regulierte Entscheidungen sollten Fachbereich, Informationssicherheit und die zuständige Risiko- oder Compliance-Funktion gemeinsam freigeben. Wenn Änderungen Mitarbeiterüberwachung, Leistungsbewertung oder Arbeitsgestaltung berühren, kann auch der Betriebsrat relevant sein. Binden Sie ihn früh ein, statt den Rollout als vollendete technische Tatsache zu behandeln.
Machen Sie Rollback praktisch umsetzbar. Bewahren Sie die vorherige Modellkonfiguration auf, nutzen Sie wo möglich Canary Traffic, definieren Sie Abbruchkriterien vor dem Release und sorgen Sie dafür, dass Logs Ausgabe oder Tool-Aktion mit der exakten erzeugenden Version verbinden. Ein „Human in the Loop“-Button ohne Befugnis, Zeit und Evidenz ist keine Kontrolle.
Was Sie in diesem Monat tun sollten
Erstens: Inventarisieren Sie Produktionsabläufe, die sich durch Anbieterupdates oder durch Änderungen an Prompts, Tools und Retrieval verändern können. Zweitens: Stufen Sie die Auswirkung jeder Änderung ein und benennen Sie einen verantwortlichen Release Owner. Drittens: Erstellen Sie eine kleine Evaluierungssuite aus Ihren teuersten Fehlermodi, nicht aus einer Anbieter-Demo. Viertens: Verhandeln Sie Release-Hinweise, Versionskennungen, regionale Verarbeitung und Rollback-Unterstützung in der Beschaffung. Fünftens: Proben Sie ein Rollback. Wenn Sie weder die Freigabe der aktuellen Konfiguration noch ihren Rückweg nachweisen können, fehlt Ihnen noch eine produktive Kontrolle.
RSI beschreibt sinnvoll eine Entwicklungsrichtung, ist aber kein Grund, Engineering-Disziplin aufzugeben. Wenn KI Teile der KI-Entwicklung beschleunigt, liegt der dauerhafte Vorteil im Unternehmen darin, nützliche Verbesserungen zügig zu übernehmen und zugleich nachweisen zu können, welche Änderung in Produktion ging, warum sie akzeptiert wurde und wie sie gestoppt werden kann.
