KI-generierten Code übernehmen: Welche Regeln Unternehmen zuerst brauchen

Code-Assistenten sind schnell in den Entwicklungsalltag eingebaut. Schwieriger ist die Frage, wer für einen übernommenen Vorschlag einsteht und wie dessen Qualität nachgewiesen wird. Wer KI-generierten Code im Unternehmen einsetzen möchte, sollte deshalb zuerst Zuständigkeiten, erlaubte Eingaben und verbindliche Prüfschritte festlegen – nicht erst nach dem ersten produktiven Fehler.

KI-Ausgaben sind Arbeitsentwürfe, keine geprüften Änderungen. Das gilt auch dann, wenn der Code plausibel aussieht, Tests besteht oder von einem verbreiteten Werkzeug stammt. Die Regeln müssen nicht umfangreich sein. Sie müssen aber konkret genug sein, damit Entwickelnde im Alltag wissen, welches Werkzeug sie wofür und mit welchen Daten verwenden dürfen.

Warum Regeln vor dem produktiven Einsatz nötig sind

Code-Assistenten können Vorschläge für neue Funktionen, Tests, Dokumentation oder Fehlerbehebung liefern. Sie können dabei auch unpassende Annahmen treffen, Sicherheitsprüfungen übersehen oder Code erzeugen, der zwar funktioniert, aber nicht zu Architektur und Wartungsstandards der Anwendung passt. Eine flüssige Erklärung des Werkzeugs ist kein Nachweis für die Richtigkeit des Ergebnisses.

Auch die Eingaben verdienen Aufmerksamkeit. Ein Prompt kann mehr enthalten als eine abstrakte Aufgabenbeschreibung: etwa interne Schnittstellen, Kundendaten, Zugangsdaten oder Ausschnitte aus nicht veröffentlichtem Quellcode. Welche Daten verarbeitet werden dürfen, hängt unter anderem vom verwendeten Werkzeug, dessen Einstellungen und den vereinbarten Betriebsbedingungen ab. Eine pauschale Freigabe für alle Code-Assistenten und alle Daten ist daher keine brauchbare Regel.

Die Debatte um ein mögliches Kennzeichnungsmerkmal für KI-unterstützte Beiträge im Linux-Kernel zeigt eine grundsätzliche Praxisfrage: Wie bleiben Änderungen nachvollziehbar, und wie ist erkennbar, wer sie geprüft hat? Heise berichtet über die Diskussion zum Assisted-by-Tag. Für Unternehmen folgt daraus keine allgemeine Pflicht zur Kennzeichnung jeder KI-Unterstützung. Es ist aber ein guter Anlass, die eigene Änderungs- und Review-Praxis zu klären.

Entscheidend ist nicht, ob KI an einer Codeänderung beteiligt war. Entscheidend ist, ob ein verantwortlicher Mensch die Änderung verstanden, geprüft und freigegeben hat.

Eine kompakte Entscheidungsmatrix für den Einsatz

Eine Richtlinie für KI-Coding-Tools sollte im Kern vier Dinge beantworten: Wer darf welches Werkzeug für welche Aufgabe mit welchen Daten nutzen? Dazu kommt die Frage, welche Prüfung und Freigabe vor dem Zusammenführen oder Ausrollen erforderlich sind.

Die folgende Matrix ist ein Ausgangspunkt. Sie muss an Schutzbedarf, Entwicklungsprozess und eingesetzte Werkzeuge des jeweiligen Unternehmens angepasst werden.

Die Kategorien sind bewusst nach möglicher Auswirkung gestaffelt. Ein automatisch erzeugter Testkommentar hat ein anderes Risikoprofil als eine Änderung an Berechtigungsprüfungen. Unternehmen sollten nicht versuchen, jede denkbare Aufgabe einzeln in einer langen Liste abzubilden. Sinnvoller sind wenige Risikoklassen mit klaren Beispielen und einer Stelle, die Grenzfälle entscheidet.

Zuständigkeiten: Vorschlag, Prüfung und Freigabe trennen

Eine verbreitete Schwäche in Teams ist die unklare Verantwortlichkeit: Der Code wurde von einem Assistenten vorgeschlagen, der Entwickelnde hat ihn übernommen, der Review ging schnell – und später ist nicht mehr ersichtlich, wer die fachlichen Annahmen geprüft hat. Die Regel sollte deshalb nicht lauten, dass die KI verantwortlich ist. Verantwortung bleibt bei den Personen und Rollen, die Änderungen erstellen, prüfen und freigeben.

Für jeden Entwicklungsbereich sollten mindestens diese Aufgaben besetzt sein:

• Anwendende Person: formuliert den Auftrag, prüft den Vorschlag und verantwortet die eingereichte Änderung.
• Code-Reviewer: beurteilt Lesbarkeit, fachliche Korrektheit, Architekturpassung und Risiken unabhängig vom Entstehungsweg.
• Security-Verantwortliche oder benannte Fachrolle: definiert zusätzliche Prüfungen für sensible Komponenten und entscheidet über Ausnahmen.
• Anwendungs- oder Produktverantwortliche: stellt sicher, dass die Änderung zum fachlichen Prozess und zu den betrieblichen Anforderungen passt.

In kleinen Entwicklungsteams müssen das nicht vier verschiedene Personen sein. Wichtig ist, dass die Zuständigkeiten ausdrücklich benannt werden und bei risikoreichen Änderungen eine unabhängige Prüfung stattfindet. Wer Code generiert hat, sollte eine Änderung nicht allein deshalb freigeben, weil das Werkzeug sie überzeugend erklärt.

KI-generierten Code prüfen: Was zum Mindeststandard gehört

KI-generierten Code prüfen heißt nicht, eine zusätzliche Sonderprüfung neben dem gesamten Entwicklungsprozess einzuführen. Die Änderung gehört in denselben kontrollierten Lebenszyklus wie anderer Code – mit gezielten Ergänzungen dort, wo das Werkzeug oder die Eingabe zusätzliche Risiken schafft.

Der NIST-Rahmen Secure Software Development Framework (SSDF), SP 800-218 beschreibt Sicherheitspraktiken für den Softwareentwicklungslebenszyklus. Er ist kein spezieller Leitfaden für KI-generierten Anwendungscode. Als betriebliche Orientierung stützt er aber den sinnvollen Grundsatz, Änderungen zu prüfen, zu testen und in etablierte Entwicklungs- und Sicherheitsprozesse einzubetten.

Für die konkrete Prüfung empfiehlt sich eine kurze, verbindliche Liste:

1. Fachliche Korrektheit: Erfüllt der Code die Anforderung, einschließlich Fehlerfällen und Randbedingungen?
2. Verständnis und Wartbarkeit: Kann das Team erklären, was die Änderung tut und wie sie sich in die bestehende Architektur einfügt?
3. Sicherheit: Sind Eingaben validiert, Berechtigungen korrekt geprüft und Geheimnisse oder sensible Informationen geschützt?
4. Tests und Werkzeuge: Laufen relevante Unit-, Integrations- und Regressionstests sowie die vorhandenen statischen und sicherheitsbezogenen Prüfungen?
5. Abhängigkeiten: Wurden neue Bibliotheken oder Versionen eingeführt, und sind Herkunft, Wartung und Freigabe geprüft?
6. Freigabe: Ist die Änderung von der für diesen Risikotyp vorgesehenen Person geprüft und im üblichen Prozess freigegeben?

Ein bestandener Testlauf genügt nicht als alleiniger Qualitätsnachweis. Tests prüfen nur die Fälle, die sie abdecken. Umgekehrt ist es auch nicht sinnvoll, KI-Änderungen grundsätzlich mit einem zusätzlichen, undifferenzierten Sonderverfahren zu belasten. Prüfaufwand sollte sich nach Funktion, Datenzugriff und möglichem Schaden richten.

Dokumentation, die im Alltag tatsächlich hilft

Dokumentation muss die spätere Prüfung unterstützen, nicht eine zweite Verwaltungsschicht schaffen. Im üblichen Änderungsprozess reichen oft wenige Angaben: betroffene Funktion, Zweck der Änderung, durchgeführte Tests, Reviewer und Freigabe. Bei erhöhtem Risiko kann zusätzlich festgehalten werden, welches Werkzeug eingesetzt wurde, wann die Unterstützung erfolgte und welche Teile der Änderung wesentlich davon geprägt waren.

Nicht jedes Promptdetail muss dauerhaft archiviert werden. Prompts können selbst sensible Informationen enthalten; ihre Speicherung kann deshalb neue Risiken schaffen. Legen Sie fest, welche Informationen im Ticketsystem oder Versionsverwaltungssystem festgehalten werden dürfen und wo vertrauliche Inhalte nicht hingehören. Zugangsdaten, echte Kundendatensätze und andere Geheimnisse sollten grundsätzlich nicht in Prompts eingegeben werden, sofern Werkzeug und Einsatz nicht ausdrücklich dafür freigegeben sind.

Ausnahmen brauchen einen nachvollziehbaren Weg. Dazu gehören Anlass, betroffene Anwendung, erlaubte Daten, kompensierende Prüfungen, entscheidende Person und gegebenenfalls ein Ablaufdatum. Eine Ausnahme ohne Verantwortlichen wird leicht zur stillschweigenden Dauerfreigabe.

So entsteht eine Richtlinie, die Entwickler nutzen

Eine praktikable Richtlinie für KI-Coding-Tools passt auf wenige Seiten und wird mit den Entwicklungsteams erarbeitet. Starten Sie nicht mit einer allgemeinen Verbots- oder Erlaubnisformel, sondern mit realen Arbeitsaufgaben und den Werkzeugen, die im Unternehmen tatsächlich genutzt werden.

Ein sinnvoller Ablauf:

1. Werkzeuge erfassen: Welche Assistenten werden genutzt, über welche Konten und mit welchen Einstellungen?
2. Datenklassen bestimmen: Welche Informationen sind öffentlich, intern, vertraulich oder besonders schutzbedürftig?
3. Aufgaben und Risiken ordnen: Dokumentation und Testgerüste anders behandeln als Authentifizierung oder produktive Infrastruktur.
4. Prüf- und Freigabepunkte benennen: Festlegen, welche Checks immer gelten und wann zusätzliche Expertise nötig ist.
5. Ausnahmen und Nachweise regeln: Einen schlanken Prozess definieren, der im Teamalltag tatsächlich eingehalten wird.
6. Regelmäßig nachjustieren: Nach einem begrenzten Einsatz prüfen, wo die Vorgaben zu locker, unnötig streng oder unklar sind.

Diese Arbeitsweise passt zu ZILONIS AIs Fokus auf vorbereitete Anwendungsprojekte, nachvollziehbare Dokumentation und Wissenstransfer an Fachverantwortliche. Bei SKUDRA gehören Projektgedächtnis und die Übergabe von Wissen an die Menschen, die Prozesse verantworten, zu den zentralen Überlegungen. Für KI-gestützte Entwicklung gilt derselbe praktische Maßstab: Das Team muss nach Projektende nachvollziehen können, warum eine Änderung entstanden ist und wie sie geprüft wurde.

Wenn Sie parallel den Umgang mit Eingabedaten klären, bietet der Beitrag KI-Lösungen ohne sensible Daten: Datenschutz und Praxis im Mittelstand ergänzende Ansätze. Für Unternehmen, die KI in konkrete Abläufe einordnen möchten, ist auch der Beitrag zu KI-Agenten in Unternehmensprozessen relevant.

Vor der Freigabe: fünf Fragen für die interne Abstimmung

Bevor ein Code-Assistent breit eingesetzt wird, sollten IT-Leitung, Entwicklungsverantwortliche und Informationssicherheit dieselben fünf Fragen beantworten können:

• Welche Werkzeuge sind freigegeben – und welche Konten oder Betriebsvarianten gelten?
• Welche Quellcode- und Geschäftsdaten dürfen als Kontext eingegeben werden?
• Wer prüft fachliche Richtigkeit und wer prüft Sicherheit?
• Welche Änderungen benötigen eine zusätzliche Freigabe?
• Was wird dokumentiert, wie werden Ausnahmen genehmigt und wann wird die Regel überprüft?

Wer diese Punkte klärt, kann KI-generierten Code im Unternehmen einsetzen, ohne die Verantwortung an ein Werkzeug abzugeben. Die passende Regel ist weder ein pauschales Verbot noch eine unkontrollierte Freigabe. Sie macht deutlich, welche Vorschläge übernommen werden dürfen, welche Prüfung dazugehört und wer am Ende dafür einsteht.

FAQ

Muss KI-generierter Code im Unternehmen immer gekennzeichnet werden?

Nicht pauschal. Eine allgemeine Kennzeichnungspflicht lässt sich aus den hier genannten Quellen nicht ableiten. Unternehmen können intern festlegen, wann der Einsatz dokumentiert wird – etwa bei sicherheitskritischen Änderungen oder wenn eine spätere Nachvollziehbarkeit besonders wichtig ist.

Wer ist für KI-generierten Code verantwortlich?

Das Werkzeug übernimmt keine betriebliche Verantwortung. Zuständig bleiben die Personen, die den Vorschlag prüfen, als Änderung einreichen und freigeben. Die Rollen sollten in der internen Richtlinie für die jeweiligen Risikoklassen eindeutig benannt sein.

Welche Daten dürfen in ein KI-Coding-Tool eingegeben werden?

Das hängt vom freigegebenen Werkzeug und seinen Betriebsbedingungen ab. Als vorsichtige Grundregel sollten Zugangsdaten, echte Kundendaten und vertrauliche Quellcodeausschnitte nicht in nicht dafür freigegebene Dienste eingegeben werden. Legen Sie erlaubte Datenklassen ausdrücklich fest.

Reichen automatisierte Tests zur Prüfung aus?

Nein. Tests helfen, ersetzen aber weder die fachliche Prüfung noch das Review des Codes. Sie decken nur definierte Fälle ab. Sicherheits- und Architekturfragen müssen von zuständigen Personen beurteilt werden.

Was sollte eine Richtlinie für KI-Coding-Tools mindestens enthalten?

Sie sollte freigegebene Werkzeuge, erlaubte Aufgaben und Eingabedaten, Zuständigkeiten, Prüf- und Freigabeschritte sowie den Umgang mit Ausnahmen und Dokumentation festlegen. Entscheidend ist, dass die Regeln auf den tatsächlichen Entwicklungsprozess des Unternehmens passen.