Noch vor ein paar Jahren war die Antwort auf die Frage „Wer hat diesen Code geschrieben?“ relativ einfach. Man konnte den Programmierer, das Team oder das Softwarehaus benennen, das für ein konkretes Modul verantwortlich war.
Heute sieht die Situation ganz anders aus.
Ein Teil des Codes kann manuell entstehen. Ein Teil kann von Copilot generiert werden. Ein weiterer Abschnitt wird von einem Programmieragenten erstellt. Ein anderer wird aus einer Open-Source-Bibliothek übernommen. Wieder ein anderer ist eine externe Abhängigkeit eines Pakets. Dazu kommen APIs, Cloud-Dienste, fertige Komponenten, Frameworks und Werkzeuge, die von weiteren Unternehmen bereitgestellt werden.
Das System funktioniert. Aber weißt du wirklich, woraus es gebaut wurde?
Von KI generierter Code entsteht nicht im luftleeren Raum
Die Entwicklung von KI-Werkzeugen für die Programmierung verändert nicht nur die Art und Weise, wie Software geschrieben wird. Sie verändert auch die Struktur der Verantwortung für den Code.
Ein Programmierer kann heute einer Agentin oder einem Agenten eine Aufgabe beschreiben und anschließend eine fertige Funktion, ein Modul, Tests, Konfigurationen oder sogar Vorschläge für architektonische Änderungen erhalten. Das ist ein enormer Produktivitätsschub.
Das Problem beginnt dann, wenn wir generierten Code als „Code aus dem Nichts“ betrachten.
KI erzeugt nämlich keinen Code losgelöst vom gesamten Software-Ökosystem. Die Modelle werden auf riesigen Datenmengen trainiert, und der generierte Ausschnitt kann bestehenden Lösungen, Mustern oder öffentlich verfügbarem Code ähneln. Genau deshalb werden Herkunft des Codes, Lizenzen und Verantwortung immer wichtiger.
Das bedeutet nicht automatisch, dass jeder von KI generierte Codeausschnitt gegen eine Lizenz verstößt. Es bedeutet jedoch, dass eine Organisation, die KI im Softwareentwicklungsprozess einsetzt, Herkunft und Prüfung des Codes als Teil des technischen Prozesses und nicht als juristische Kuriosität behandeln sollte.
Das ist längst nicht mehr nur Theorie
Am 16. September 2026 entschied das Berufungsgericht des 9. Bezirks einen Teil des Falls Doe v. GitHub, in dem Programmierer GitHub, Microsoft und OpenAI-Unternehmen unter anderem vorwarfen, öffentlich verfügbaren Code von GitHub bei der Entwicklung und dem Training von Werkzeugen wie Copilot und Codex verwendet zu haben.
Einer der Ansprüche betraf den DMCA und Urheberrechtsinformationen. Das Gericht bestätigte die Abweisung dieses konkreten Vorwurfs. Gleichzeitig umfasst der Fall auch andere Fragen im Zusammenhang mit Urheberrechten und Open-Source-Lizenzen.
Das ist nicht deshalb wichtig, weil ein einzelnes Urteil eine einfache Antwort auf die Frage liefert: „Darf man Code aus KI verwenden?“
Das liefert es nicht.
Wichtiger ist, dass der Streit ein breiteres Problem zeigt: In der KI-Welt wird die Grenze zwischen von Menschen geschriebenem Code, von einem Modell generiertem Code und Code aus einem bestehenden Software-Ökosystem immer schwerer nachzuvollziehen.
Für Unternehmen, die Software entwickeln, bedeutet das die Notwendigkeit, diesen Prozess besser zu steuern.
Software Supply Chain, also hat dein System deutlich mehr „Autoren“
In der Softwaresicherheit gibt es seit Jahren den Begriff Software Supply Chain – die Lieferkette der Software.
Das sind alle Komponenten, Werkzeuge, Bibliotheken, Abhängigkeiten und Prozesse, die an der Entstehung des Endprodukts beteiligt sind.
NIST weist in diesem Zusammenhang unter anderem auf die Notwendigkeit hin, die Herkunft von Komponenten zu verwalten, Open-Source-Abhängigkeiten zu kontrollieren, Schwachstellen zu überwachen und SBOM einzusetzen, also ein Software Bill of Materials.
SBOM kann man vereinfacht mit einer Liste der Inhaltsstoffe eines Produkts vergleichen.
Es sagt nicht nur: „Wir haben eine Anwendung“. Es zeigt, welche Komponenten sich darin befinden.
Zum Beispiel:
- Anwendungsframework,
- externe Bibliotheken,
- Versionen einzelner Pakete,
- Open-Source-Komponenten,
- indirekte Abhängigkeiten,
- von externen Anbietern bereitgestellte Elemente.
So lässt sich bei einer Schwachstelle in einer bestimmten Bibliothek schneller prüfen, welche Systeme sie verwenden.
NIST weist außerdem auf Provenance hin, also die Möglichkeit, die Herkunft von Softwareelementen nachzuvollziehen.
Und genau hier bringt KI eine neue Ebene der Komplexität mit sich.
Denn zur bestehenden Lieferkette kommt eine weitere Art der Codeentstehung hinzu.
Stell dir ein typisches Geschäftssystem vor
40 % des Codes hat das Team geschrieben.
20 % entstanden mit Unterstützung von KI.
Weitere Ausschnitte wurden von einem Agenten generiert.
Einige Bibliotheken stammen aus Open Source.
Ein Teil der Abhängigkeiten wurde durch das Framework hinzugefügt.
Das System nutzt eine API eines externen Anbieters.
Eine Komponente stammt aus einem Paket, das seit zwei Jahren niemand aktualisiert hat.
Und die Dokumentation der Abhängigkeiten?
Die liegt irgendwo im Repository.
Oder sie existiert nicht.
Das System funktioniert...
Und genau deshalb bleibt das Problem unsichtbar. Bis etwas passiert.
Und dann taucht eine Schwachstelle auf
Nehmen wir an, in einer der Bibliotheken wird eine gravierende Sicherheitslücke entdeckt.
Die Frage lautet: Weißt du, ob dein System sie verwendet?
Wenn du ein geordnetes Verzeichnis der Abhängigkeiten hast, kann die Antwort eine Sache von Minuten sein.
Wenn nicht, beginnt die manuelle Durchsuchung der Repositories, die Kontaktaufnahme mit den Programmierern sowie das Prüfen von Umgebungen, Paketversionen und indirekten Abhängigkeiten.
Und jetzt fügen wir noch den von KI generierten Code hinzu.
Ist bekannt, welcher Ausschnitt mit welchem Werkzeug erstellt wurde?
Wurde ein Code Review durchgeführt?
Wurde der Code durch Tests abgedeckt?
Wurden die Abhängigkeiten geprüft?
Hat jemand die Lizenz der Komponente überprüft?
Lässt sich der Prozess nachvollziehen, durch den ein konkreter Ausschnitt entstanden ist?
Das sind nicht mehr nur Fragen für den Programmierer.
Das sind Fragen zum technologischen Risikomanagement des Unternehmens.
Das größte Problem ist nicht die KI. Es ist der fehlende Prozess
Es wäre leicht, aus diesem Artikel eine Warnung vor künstlicher Intelligenz zu machen.
Das wäre jedoch ein zu einfacher Schluss.
KI kann die Produktivität eines Entwicklerteams sehr stark verbessern.
Das Problem entsteht dann, wenn ein Unternehmen das Tempo der Codeproduktion erhöht, aber gleichzeitig die Kontrolle über diesen Code nicht ausbaut.
Es ist ein bisschen so, als würde eine Fabrik plötzlich zehnmal so viele Teile produzieren, ohne die Qualitätskontrolle, die Materialerfassung oder die Lieferantenkontrolle zu verstärken.
In einem Softwarehaus bestehen die Entsprechungen eines solchen Kontrollsystems unter anderem aus:
- Code Review
- automatisierten Tests
- Abhängigkeits-Scans
- SBOM
- Schwachstellenüberwachung
- Kontrolle von Open-Source-Lizenzen
- CI/CD mit Sicherheitskontrollen
- Verwaltung von Repositories
- Dokumentation der Architektur
- Nachverfolgung der Herkunft von Komponenten
- klare Regeln für den Einsatz von KI in der Entwicklung
Das NIST weist außerdem auf die Möglichkeit hin, Mechanismen zur Sicherheit der Lieferkette direkt in CI/CD-Pipelines zu integrieren.
Das ist ein wichtiger Wandel in der Denkweise.
Sicherheit sollte keine Kontrolle sein, die erst vor dem Deployment durchgeführt wird.
Sie sollte Teil des Softwareentwicklungsprozesses sein.
"Wer hat diesen Code geschrieben?" ist nicht mehr die richtige Frage
In der Welt der traditionellen Entwicklung konnte man nach dem Autor fragen.
In der Welt der AI-assisted Development werden ganz andere Fragen viel wichtiger:
- Woher stammt diese Komponente?
- Unter welcher Lizenz steht sie?
- Wer hat sie verifiziert?
- Welche Version verwenden wir?
- Welche Abhängigkeiten hat sie?
- Wird sie noch gepflegt?
- Kennen wir ihre Schwachstellen?
- Können wir die Änderungshistorie nachvollziehen?
- Wissen wir, wo KI an ihrer Entstehung beteiligt war?
Und vor allem:
- Ist das Unternehmen in der Lage zu beweisen, dass es all dies unter Kontrolle hat?
Denn der Kunde kauft schließlich nicht „KI-Code“. Er kauft ein funktionierendes System. Und die Verantwortung für dieses System trägt weiterhin die Organisation, die es liefert und betreibt.
Der Code kann automatisch sein. Die Verantwortung nicht
Das ist wahrscheinlich eine der wichtigsten Veränderungen, die KI in Softwarehäuser bringt.
Der Entwickler verschwindet nicht. Seine Rolle verändert sich.
Immer häufiger geht es nicht nur darum, eine bestimmte Anzahl von Codezeilen zu schreiben. Es geht um das Entwerfen der Lösung, die Kontrolle der generierten Bestandteile, die Risikobewertung, das Testen, die Integration, die Sicherheit und die Wartung des gesamten Systems.
Ebenso kann sich das Unternehmen nicht darauf beschränken zu fragen, ob seine Entwickler KI nutzen.
Es sollte wissen, wie sie sie nutzen, in welchem Prozess, mit welchen Kontrollen und wie sich das auf den gesamten Software-Lebenszyklus auswirkt.
Denn in ein paar Jahren könnte die Frage nicht mehr lauten: "Wer hat dieses System geschrieben?"
sondern: "Kannst du nachvollziehen, woraus und auf welche Weise es aufgebaut wurde?"
Wenn die Antwort "nicht ganz" lautet, ist das Problem nicht das Fehlen eines weiteren KI-Tools.
Das Problem ist der Mangel an Kontrolle über die Software Supply Chain.
