Ist KI-geschriebene Software sicher? Die Fragen, die ein Käufer stellen sollte

Woran erkenne ich, ob eine KI die Software geschrieben hat?

„Hat eine KI diesen Code geschrieben?“ hat keine prüfbare Antwort. Fast jedes Team benutzt heute einen Assistenten, und ein Lieferant, der das Gegenteil behauptet, kann es nicht belegen; „KI wird nicht eingesetzt“ in einen Vertrag zu schreiben heißt, eine Klausel zu schreiben, die sich nicht durchsetzen lässt.

Die prüfbare Frage lautet: Was hat dieser Code vor der Produktion durchlaufen? Gibt es automatisierte Tests, wurden die Abhängigkeiten gescannt, hat ein Mensch ihn Zeile für Zeile geprüft, ist diese Prüfung protokolliert? Sind diese vier vorhanden, ist die Herkunft des Codes eine Nebeninformation; fehlen sie, schützt Sie auch ein menschlicher Autor nicht.

Warum schreibt KI unsicheren Code?

Beim Schreiben von Code erzeugt ein Sprachmodell die wahrscheinlichste Fortsetzung, nicht die richtige. Je häufiger ein Muster in seinen Quellen vorkam, desto bereitwilliger schlägt es das vor — und die meisten Beispiele, die seit einem Jahrzehnt im Netz kursieren, sind Muster, über die die heutige Sicherheitspraxis hinaus ist. Das Modell ist nicht bösartig; es wiederholt, was verbreitet ist, und was verbreitet ist, ist nicht immer richtig.

Fehler mit Modellursprung häufen sich deshalb vorhersehbar statt zufällig: veraltete Kryptografieaufrufe, von Hand zusammengesetzte Datenbankabfragen, lockere Zugriffskontrolle und im Code eingebettete Geheimnisse. All das fängt automatisiertes Werkzeug ab — vorausgesetzt, dieses Werkzeug steht in der Pipeline.

Welche Risiken birgt KI-geschriebener Code?

Neben den klassischen Fehlern bringt generative KI drei eigene Risiken mit, und genau das sind die Fragen, die man als Käufer stellt.

Kann KI eine Bibliothek vorschlagen, die es nicht gibt?

Beim Vorschlagen von Code kann ein Sprachmodell einen Paketnamen erfinden, den es nicht gibt. Für sich genommen ist das nur ein Fehler; die Installation schlägt fehl und die Entwicklerin behebt ihn. Das Problem ist, dass Angreifer dieses Verhalten bemerkt haben: Sie ermitteln die Namen, die Modelle am häufigsten erfinden, und veröffentlichen unter diesen Namen echte Pakete. Dieses Paket lässt sich nun installieren, und was immer sie hineingelegt haben, gelangt in Ihr System.

Die Abwehr ist einfach und vollständig automatisch: Abhängigkeiten festnageln, Signaturen und Integrität prüfen und bei jeder Veröffentlichung auf bekannte Schwachstellen scannen. Das gehört ohnehin zu einer guten Deployment-Pipeline — dieses Risiko verlangt also keine neue Disziplin, sondern dass die bestehende tatsächlich angewandt wird.

Wie schreibt man eine KI-Klausel in einen Vertrag?

• Aller gelieferte Code durchläuft automatisierte Tests und eine menschliche Prüfung; das Prüfprotokoll wird auf Anfrage geteilt.
• Abhängigkeiten werden festgenagelt und bei jeder Veröffentlichung gegen bekannte Schwachstellen gescannt; ein kritischer Fund stoppt die Veröffentlichung.
• Code und Daten des Kunden werden in einer Umgebung verarbeitet, die nicht für Modelltraining genutzt wird; Anbieter und Region werden schriftlich benannt.
• Jeder Ablauf, in dem das Modell eine echte Transaktion ausführen kann, trägt eine menschliche Freigabe, und die Freigabe wird protokolliert.
• Quellcode, Abhängigkeitsliste und Deployment-Konfiguration gehen bei der Lieferung gemeinsam über — fehlt eines davon, ist keine Prüfung möglich.

Was diese Klauseln gemeinsam haben: Keine von ihnen sagt „keine KI verwenden“. Jede beschreibt ein überprüfbares Verhalten und verlangt vom Lieferanten den Nachweis.

Wer haftet, wenn die KI einen Fehler macht?

Kommt es zu einem Sicherheitsvorfall, wird nicht geprüft, wer den Code geschrieben hat, sondern welche Maßnahmen Sie als Verantwortlicher getroffen haben. „Das hat das Modell geschrieben“ ist keine Verteidigung; sind personenbezogene Daten abgeflossen, treffen Sie die Pflichten zur Meldung, zur Dokumentation und zu technischen Maßnahmen unmittelbar. In einer Prüfung hilft deshalb nur, was vor dem Vorfall entstanden ist: Testergebnisse, Scanberichte, Prüfprotokolle.

Auf diesen Aufzeichnungen setzen die Compliance-Pflichten auf, und welches System in welche Kategorie fällt, ist ein eigenes Thema; unser Leitfaden zur Softwareentwicklung mit KI behandelt die Risikoklassifizierung und die daraus folgenden Pflichten im Detail.

Sollte ich mit einer Firma arbeiten, die KI einsetzt?

KI einzusetzen ist für sich genommen kein Ausschlusskriterium — denn die Alternative ist auch nicht risikofrei. Ein Team ohne KI erledigt dieselbe Arbeit langsamer und meist teurer, und dieser Code ist genauso wahrscheinlich ungeprüft. Der richtige Vergleich lautet nicht „Modell oder Mensch“, sondern „geprüft oder ungeprüft“. So gemessen liefert ein Team, das KI auf einer gut gebauten Pipeline einsetzt, spürbar sicherere Arbeit als ein Team ganz ohne Pipeline.

Ist KI-geschriebener Code günstiger zu warten?

Oft das Gegenteil: Die Wartungskosten können steigen. Statt einer durchgehenden Architektur zu folgen, produziert ein Modell Lösungen, die einzeln vernünftig sind, sich aber voneinander unterscheiden, und hinterlässt eine Codebasis, die dieselbe Aufgabe auf fünf Arten erledigt. Was das verhindert, ist nicht das Modell, sondern die menschliche Prüfung und eine schriftliche Architekturentscheidung. Wer die Prüfung auslässt, zahlt die gesparte Zeit im zweiten Jahr mit Zinsen zurück.

Mein Lieferant sagt nicht, ob er KI einsetzt — woran erkenne ich es?

Versuchen Sie es nicht zu erkennen, sondern messen Sie. Es gibt keinen verlässlichen Weg, die Herkunft von Code von außen festzustellen, und es würde auch nicht helfen. Messen Sie die Verifizierung: Verlangen Sie einen Bericht zur Testabdeckung, das Pipeline-Protokoll der letzten zehn Veröffentlichungen und das Prüfprotokoll einer zufällig gewählten Änderung. Mit diesen dreien spielt die Herkunft keine Rolle; ohne sie schützt Sie ein menschlicher Autor nicht.

Sind Open-Source-Komponenten ein Risiko?

Nicht die Komponente selbst, sondern wie sie ausgewählt wurde und wie sie aktualisiert wird. KI-Assistenten empfehlen auch aufgegebene Bibliotheken, weil sie einmal verbreitet waren. Drei Dinge sind zu fragen: Wann wurde diese Abhängigkeit zuletzt aktualisiert, wie viele Menschen pflegen sie, und erlaubt ihre Lizenz, Ihr Produkt geschlossen zu halten? Das Dritte wird am häufigsten übersprungen und hat die schwersten Folgen.

Liefert ein Team, das KI einsetzt, schneller?

Meistens ja, aber der Abstand ist kleiner als behauptet, und es kommt darauf an, wo er liegt. Schneller wird die bekannte Lösung eines bekannten Problems; nicht schneller werden das Abstecken des Umfangs, das Testen von Integrationen und die Fehlersuche. Diese zweite Gruppe bestimmt den Liefertermin, deshalb liegt die Verkürzung des Gesamtzeitplans meist zwischen zehn und zwanzig Prozent.

“Die Herkunft von Code lässt sich nicht prüfen; seine Verifizierung schon. Und das Zweite gehört in den Vertrag.”