Die KI schreibt den Code. Wer haftet dafür?

Künstliche Intelligenz schreibt 2026 einen wachsenden Teil des Unternehmenscodes, Branchenerhebungen sprechen von bis zu 40 Prozent. Bricht dieser Code in Produktion oder reißt eine Sicherheitslücke auf, beginnt im Vorstand ein unangenehmes Spiel: Wer war das eigentlich? Die Antwort fällt erstaunlich oft aus.

Verwandt:Vier Stolpersteine: Warum KI-Projekte den Regelbetrieb verfehlen  /  Wenn ein KI-Modell über Nacht verschwindet

Wie viel Code die KI wirklich schreibt

Die Zahlen schwanken je nach Quelle, die Richtung ist eindeutig. Branchenerhebungen schätzen den KI-Anteil am neu geschriebenen Code für 2026 auf einen Wert nahe 40 Prozent, mit weiter steigender Tendenz. In vielen Entwicklungsteams ist der KI-Assistent kein Experiment mehr, sondern Teil des Tagesgeschäfts.

Was ist KI-generierter Code? Gemeint ist Quellcode, den ein KI-Assistent wie Copilot, Cursor oder ein agentisches Tool auf Basis einer Anweisung erzeugt, und den ein Mensch übernimmt, anpasst oder unverändert in die Anwendung gibt. Die Verantwortung für das Ergebnis bleibt formal beim Unternehmen, die Urheberschaft im Detail wird unscharf.

Mit dem Anteil wächst eine zweite Zahl mit, über die seltener gesprochen wird. Erhebungen aus der Softwarebranche berichten, dass KI-gestützt entstandener Code spürbar mehr Schwachstellen enthält und ohne saubere Kontrolle die technische Schuld deutlich anwachsen lässt. Geschwindigkeit erzeugt Volumen, und Volumen ohne Prüfung erzeugt Risiko.

Das Haftungs-Vakuum: Wenn niemand zuständig ist

Der eigentliche Sprengstoff liegt nicht in der Fehlerquote, sondern in der Zuständigkeit. Fragt man in Unternehmen, wer für einen durch KI-Code verursachten Schaden geradesteht, verteilen sich die Antworten auf drei Lager. Die Entwicklung verweist auf das Tool, die Security auf die Entwicklung, und beide schielen zum Anbieter, dessen Vertrag die Gewähr meist stark begrenzt.

Für ein C-Level ist das ein bekanntes Muster in neuem Gewand. Eine Verantwortung, die alle teilen, trägt am Ende niemand. Solange unklar bleibt, wer einen KI-Commit freigibt und für seine Folgen einsteht, fehlt die Haftungskette. Es bleibt eine Lücke, und im Schadensfall füllt sie der Vorstand, ob er will oder nicht.

Dazu kommt ein praktisches Problem, das erfahrene IT-Leiter aus jedem gewachsenen System kennen. KI-Code ist oft schwerer zu warten als handgeschriebener, weil das implizite Verständnis fehlt, das beim Selberschreiben entsteht. Wenn der ursprüngliche Prompt vergessen und der Entwickler weitergezogen ist, bleibt ein Stück Software, das funktioniert, bis es das nicht mehr tut.

Ein typisches Szenario macht das greifbar. Ein KI-Assistent schlägt eine Bibliotheksfunktion vor, ein Entwickler übernimmt sie unter Zeitdruck, der Review winkt sie als Standardcode durch. Wochen später reißt genau diese Funktion eine Lücke auf, weil die KI eine veraltete, verwundbare Version vorgeschlagen hat. Im Post-Mortem zeigt jeder auf den anderen, und der CIO erklärt dem Aufsichtsrat einen Vorfall, den niemand bewusst verursacht hat. Dieses Muster wiederholt sich, solange die Freigabe kein Gesicht hat.

Was ohne Governance auf dem Spiel steht

Ohne Kontrollregeln summieren sich drei Risiken, die einzeln beherrschbar wären und zusammen teuer werden. Eine einfache Gegenüberstellung zeigt, wo der Unterschied zwischen geprüftem und ungeprüftem KI-Code liegt.

Die Tabelle wirkt simpel, der Unterschied ist es nicht. Ein Gate verlangt eine organisatorische Entscheidung, kein neues Werkzeug. Genau daran scheitern viele Vorhaben, weil sie das Thema an die Toolauswahl delegieren, obwohl es eine Führungsentscheidung ist.

Die Gates, die ein CIO jetzt setzen muss

Der Weg aus dem Vakuum führt über wenige, harte Regeln, die im Entwicklungsprozess verankert sind. Vier davon lohnen sofortige Aufmerksamkeit.

1. Review-Pflicht für KI-Code. Jeder KI-generierte Commit durchläuft denselben menschlichen Review wie handgeschriebener Code, plus einen automatisierten Security-Scan vor dem Merge.
2. Ein Owner pro Commit. Wer KI-Code übernimmt, übernimmt die Verantwortung dafür. Die Freigabe trägt einen Namen, kein Tool-Logo.
3. Herkunft nachvollziehbar halten. Welcher Teil stammt von welchem Assistenten, mit welcher Anweisung? Diese Spur entscheidet im Schadensfall über Stunden statt Wochen Fehlersuche.
4. Vertragslage mit dem Anbieter klären. Bevor ein Tool flächendeckend ausrollt, prüft die Rechtsabteilung, was der Anbieter zusichert. Die Zusagen sind oft begrenzt und gehören in jedem Einzelfall gelesen.

Keiner dieser vier Punkte verlangt zusätzliches Budget, alle verlangen eine Entscheidung. Genau hier trennt sich Absicht von Umsetzung. Ein Gate, das direkt in der Build-Pipeline steht, wirkt. Ein Gate, das nur in einer Richtlinie steht, die niemand liest, kostet das Papier und sonst nichts. Erfahrene IT-Leiter verankern die Pflicht deshalb technisch, damit sie auch um drei Uhr nachts greift, wenn der Termindruck am größten ist und die Versuchung, schnell durchzuwinken, am höchsten.

Wer im Unternehmen die Verantwortung trägt

Regeln ohne Eigentümer verpuffen. Deshalb gehört zu jeder Gate-Entscheidung eine Rolle, die sie durchsetzt. In der Praxis bewährt sich eine schlanke Aufteilung: eine Person mit KI-Gesamtverantwortung auf Leitungsebene, benannte Owner pro Tool mit Ergebnisverantwortung, Security-Vertreter für die Risikobewertung und Engineering-Manager für die tägliche Aufsicht.

Wichtig ist, dass diese Rollen vor dem nächsten Vorfall stehen, nicht danach. Ein Vorstand, der KI-Code zulässt, ohne die Verantwortung zu verteilen, verschiebt das Problem nur auf den Tag des ersten ernsten Vorfalls. Die Unternehmen, die jetzt eine Haftungskette ziehen, kaufen sich damit die Fähigkeit, KI im Code überhaupt verantworten zu können. Wer darauf verzichtet, verschiebt das Problem nur auf den nächsten Vorfall.

Häufig gestellte Fragen

Mehr aus dem MBF Media Netzwerk

Bildquelle: KI-generiert (Juni 2026)