← Alle Beiträge
Modelle & Autonomie

KI schreibt KI: Was das bedeutet

Veröffentlicht am 07. November 2026 · 6 Min. Lesezeit · Daniel Ostner

Zwei Meldungen dieser Woche haben mich länger beschäftigt als geplant. Nicht weil sie spektakulär klingen, sondern weil sie zusammen eine Frage aufwerfen, die in keinem Architektur-Review auftaucht: Wer kontrolliert eigentlich das Modell, das andere Modelle verändert?

Zwei Meldungen, eine unbequeme Frage

Letzte Woche saß ich in einem Architektur-Review und jemand fragte, ob wir unser bestehendes Modell einfach 'ein bisschen optimieren' könnten, ohne neu zu trainieren. Die Antwort war damals noch: Nein, nicht wirklich.

Dann kam die Meldung von The Decoder: OpenAIs GPT-6 Astra soll die Gewichte anderer KI-Modelle wie lesbaren Code interpretieren und gezielt umschreiben können. Kein klassisches Training, keine GPU-Cluster über Wochen. Das klingt nach einem technischen Detail. Es ist keines.

Was GPT-6 Astra architektonisch verschiebt

Bisher war die Grenze zwischen Modell und Trainingsprozess klar. Ein Modell entsteht durch Training, es wird deployed, es bleibt, was es ist — bis man es neu trainiert. Diese Trennung ist auch die Grundlage für viele Governance-Annahmen: Welche Daten gingen rein, wann, unter welcher Aufsicht?

Wenn ein Modell die Gewichte eines anderen Modells wie Quellcode lesen und umschreiben kann, fällt diese Grenze weg. Laut The Decoder ermöglicht GPT-6 Astra eine gezielte Leistungssteigerung ohne klassisches Training. Das ist effizient. Es bedeutet aber auch: Eine Änderung am Modell hinterlässt möglicherweise keinen klassischen Audit-Trail mehr. Kein Trainings-Log, kein Datensatz, kein Zeitstempel im gewohnten Sinn.

Für Unternehmen, die unter dem EU AI Act als Betreiber eines Hochrisiko-Systems eingestuft sind, ist das keine akademische Frage. Artikel 9 und 12 des AI Acts verlangen Risikomanagementsysteme und Protokollierungspflichten. Wenn Modellveränderungen außerhalb klassischer Trainingsprozesse stattfinden, müssen Governance-Frameworks das explizit abdecken — oder sie decken es schlicht nicht ab.

Governance

Wer Modelle betreibt, die durch andere Modelle verändert werden können, braucht eine eigene Protokollierungslogik — der klassische Trainings-Log reicht nicht mehr.

DeepSeeks Coding-Agent: Autonomie ohne Aufseher

Parallel dazu hat DeepSeek laut AI Agents Directory einen Open-Source-Super-Agent für Coding-Aufgaben veröffentlicht. Der Agent identifiziert Probleme eigenständig und generiert Lösungen — vollständig autonome Workflows, direkte Konkurrenz zu Anthropic Claude.

Open Source bedeutet hier: Jedes Unternehmen kann diesen Agent selbst betreiben, anpassen, in bestehende Pipelines einbinden. Das ist der Vorteil. Der Nachteil ist die Kehrseite desselben Arguments. Wer einen autonomen Coding-Agent intern betreibt, ist Betreiber im Sinne des AI Acts — mit allen Pflichten, die daran hängen.

Autonome Agents, die Code schreiben, sind keine Assistenzwerkzeuge mehr. Sie treffen Entscheidungen über Systemarchitektur, Sicherheitslogik, Datenbankabfragen. Wenn ein solcher Agent einen Fehler einbaut, ist die Frage nicht nur technisch. Die Frage ist: Wer hat diesen Output freigegeben? Wer war zuständig? Und — klassische Stille in jedem Review, das ich kenne — wer hat das überhaupt mitbekommen?

Praxis

Autonome Coding-Agents brauchen eine explizite Freigabe-Logik — nicht weil der Code schlecht ist, sondern weil Verantwortung sonst nirgendwo landet.

Was das für Ihre Architektur bedeutet

Beide Entwicklungen laufen auf dasselbe Muster hinaus: KI-Systeme werden selbstständiger, schneller anpassbar und schwerer zu beobachten. Das ist kein Argument gegen den Einsatz. Es ist ein Argument dafür, die Architektur-Entscheidungen jetzt zu treffen, nicht nach dem ersten Vorfall.

Drei Punkte, die in jede Architektur-Diskussion gehören, sobald solche Systeme ins Spiel kommen:

  • Modell-Identität dokumentieren: Welche Version läuft wo, und wie wird eine Veränderung — ob durch Training oder durch ein übergeordnetes Modell — protokolliert und versioniert?

  • Autonomie-Grenzen definieren: Was darf ein Agent eigenständig entscheiden, was braucht einen menschlichen Freigabeschritt? Das gehört in die Systemspezifikation, nicht ins Handbuch.

  • Betreiber-Rolle klären: Wer im Unternehmen trägt die Verantwortung für den Output eines autonomen Agents? Eine Antwort wie 'das Team' ist keine Antwort.

Governance-Frameworks unter Druck

Die meisten Governance-Frameworks, die ich in DACH-Unternehmen sehe, sind für eine Welt gebaut, in der Modelle stabil sind und Menschen Entscheidungen treffen. Diese Welt existiert noch — aber sie bekommt Risse.

GPT-6 Astra, das Modellgewichte umschreibt, und DeepSeeks autonomer Coding-Agent sind zwei Datenpunkte. Beide zeigen dieselbe Richtung: Die Schicht zwischen Mensch und Entscheidung wird dicker. Das ist nicht per se schlecht. Aber es bedeutet, dass Governance-Dokumente, die vor zwei Jahren geschrieben wurden, heute möglicherweise an den falschen Stellen Kontrolle versprechen.

Der Leitfaden zu den 8 Architekturprinzipien im AI Navigator gibt einen strukturierten Ausgangspunkt, um zu prüfen, welche Prinzipien in der eigenen Architektur noch tragen und wo Lücken entstehen. Der Leitfaden zu AI-Governance aufbauen hilft dabei, die organisatorischen Zuständigkeiten so zu definieren, dass sie auch für autonome Systeme funktionieren — nicht nur für klassische Assistenzwerkzeuge. Und der Governance-Check im AI Navigator ist ein guter erster Schritt, um den aktuellen Stand ehrlich einzuschätzen.

Was ich daraus mitnehme

Ich bin kein Pessimist, was KI-Entwicklung angeht. Modelle, die andere Modelle effizienter machen, und Agents, die Entwickler von Routinearbeit entlasten — das ist genuiner Fortschritt. Ich freue mich darüber, ehrlich gesagt.

Was mich beschäftigt, ist die Governance-Lücke, die sich auftut, wenn Systeme schneller werden als die Frameworks, die sie beaufsichtigen sollen. In den Reviews, die ich führe, taucht die Frage nach Modell-Versionierung und Freigabe-Logik für autonome Agents noch selten auf. Das wird sich ändern müssen — lieber jetzt als nach dem ersten erklärungspflichtigen Vorfall.

Offen bleibt für mich die Frage, wie sich Audit-Anforderungen entwickeln, wenn Modellveränderungen außerhalb klassischer Trainingsprozesse stattfinden. Der regulatorische Rahmen ist da noch nicht, wo die Technologie schon ist. Das ist kein neues Problem. Es ist nur gerade besonders sichtbar.

Quellen

Dieser Entwurf wurde KI-gestützt aus folgenden Meldungen erstellt und ist vor der Veröffentlichung redaktionell zu prüfen.

In die Praxis bringen

Ob ein KI-Use-Case live gehen darf, entscheidet sich an Datenschutz, Transparenz und Risiko — nicht am Modell. Ohne strukturierte Prüfung riskieren Sie Stopp-Schilder erst kurz vor dem Go-Live.

AI Governance Check starten →

Daniel Ostner

Autor des Enterprise-AI-Leitfadens

KI-unterstützt entworfen, redaktionell geprüft am 07. November 2026.

Buch ansehen →

Daniel Ostner bringt 20+ Jahre Erfahrung aus SAP-Landschaften und Enterprise-IT mit — als Chief Architect einer S/4-Greenfield-Transformation im globalen Chemiehandel und rund 7 Jahre als IT-Leiter eines SAP-Beratungshauses. Zertifiziert u.a. im IESE Executive Program Data & AI.

Vertiefung im Leitfaden