KI-generierten Code prüfen: Review, Tests und Architektur

Das Wichtigste in Kürze: KI-generierten Code prüfen: Pflichtprüfungen, Abhängigkeiten, Tests, Sicherheit und Dokumentation, mit eigener Review-Checkliste für KMU.

KI-Assistenten schreiben heute in Minuten Code, für den ein Team früher Tage gebraucht hätte. Das Problem liegt nicht in der Geschwindigkeit. Es liegt daran, dass der erzeugte Code fast immer sauber formatiert und gut kommentiert ist. Er wirkt auf den ersten Blick funktionsfähig, unabhängig davon, ob er es tatsächlich ist. Genau diese Plausibilität ist das Risiko: Sicherheitslücken, veraltete oder gar nicht existierende Bibliotheken und schwache Architekturentscheidungen fallen bei einem flüchtigen Blick nicht auf.

Dieser Artikel gehört zu unserem Themen-Cluster KI-Softwareentwicklung. Er richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die KI-gestützt entwickeln lassen oder selbst entwickeln und wissen wollen, welche Prüfungen vor einer Freigabe stehen müssen.

Begriffe und Abgrenzung: Review, Test und Audit sind nicht dasselbe

3 Begriffe werden in der Praxis oft vermischt, obwohl sie unterschiedliche Fragen beantworten:

• Code-Review prüft, ob der Code die Anforderung korrekt, verständlich und wartbar umsetzt, meist durch eine zweite Person, die den Code liest, ohne ihn auszuführen.
• Test prüft, ob der Code sich bei definierten Eingaben so verhält wie erwartet, automatisiert und wiederholbar, im Gegensatz zum einmaligen Review.
• Sicherheits-Audit prüft gezielt auf bekannte Schwachstellenklassen und Angriffsflächen, meist mit spezialisierten Werkzeugen oder Checklisten, unabhängig von der fachlichen Korrektheit.

Bei KI-Code reicht keine dieser 3 Prüfungen allein. Ein Review findet schlechte Architektur, aber nicht zuverlässig eine unsichere Verschlüsselung. Ein Test bestätigt das erwartete Verhalten für die geprüften Fälle. Er sagt aber nichts über unbekannte Angriffswege. Ein Sicherheits-Audit findet Schwachstellenmuster, aber keine fachlichen Denkfehler. Deshalb braucht freigabefähiger KI-Code alle 3 Ebenen, dazu eine vierte, eigene Prüfung: die Kontrolle, ob Abhängigkeiten real und vertrauenswürdig sind.

Welche Prüfungen sind Pflicht?

Vier Prüfungen sind aus meiner Sicht nicht verhandelbar, bevor KI-generierter Code in einen produktiven Zweig gelangt:

1. Fachliches Review gegen die eigentliche Anforderung. Löst der Code das gestellte Problem, oder eine plausibel klingende Variante davon? KI-Modelle interpretieren unklare Anforderungen manchmal kreativ.

2. Abhängigkeitsprüfung. Existieren alle referenzierten Bibliotheken tatsächlich, stammen sie aus vertrauenswürdiger Quelle und sind sie aktuell?

3. Sicherheitscheck. Sind bekannte Schwachstellenklassen ausgeschlossen, und sind Rechte und Ausführungsspielraum auf das Nötige begrenzt?

4. Automatisierte Tests inklusive Randfälle. Verhält sich der Code auch bei fehlerhaften, unerwarteten oder böswilligen Eingaben kontrolliert?

Diese 4 Prüfungen sind Pflicht, nicht optional. Der Grund: KI-Code kann laut BSI bekannte oder unbekannte Lücken enthalten oder alte Bibliotheken nutzen, ohne dass das auffällt. Die Verantwortung verschiebt sich dabei nicht auf das Modell. Google stellt in seinen Richtlinien klar: Die Verantwortung für Qualität liegt beim Publisher, egal wie der Inhalt entstand. Übertragen auf Software heißt das: Wer KI-Code in Produktion bringt, haftet für die Folgen, nicht das Modell.

Wie kontrolliert man Abhängigkeiten?

Von den 4 Pflichtprüfungen wird diese am häufigsten übersprungen. Der Grund: Neu vorgeschlagene Pakete wirken unauffällig. Genau hier liegt ein dokumentiertes, konkretes Risiko. Das BSI beschreibt ein Angriffsmuster: Sprachmodelle halluzinieren Namen von Programmbibliotheken, empfehlen also Paketnamen, die gar nicht existieren. Angreifende beobachten, welche Namen ein Modell wiederholt „erfindet“. Unter genau diesem Namen veröffentlichen sie dann ein schadhaftes Paket in einem öffentlichen Repository.

Installiert eine Entwicklerin oder ein Entwickler das vom Modell empfohlene Paket ungeprüft, gelangt Schadsoftware ins Projekt. Das BSI-Dokument illustriert das am Beispiel eines fiktiven Python-Pakets, das ein Modell wiederholt vorschlug, bis eine angreifende Person es genau dafür anlegte.

Daraus ergibt sich ein klares Vorgehen:

• Jede von der KI vorgeschlagene Bibliothek einzeln im offiziellen Paket-Repository (etwa PyPI, npm) nachschlagen, bevor sie installiert wird, nicht blind dem vorgeschlagenen Installationsbefehl folgen.
• Autor, Downloadzahlen, Alter des Pakets und Datum der letzten Aktualisierung prüfen. Ein sehr neues Paket mit wenigen Downloads, das exakt zum gesuchten Namen passt, ist ein Warnsignal.
• Automatisierte Abhängigkeits- und Schwachstellenscanner (Software Composition Analysis) in die CI-Pipeline einbinden, statt sich auf manuelle Stichproben zu verlassen.
• Bereits genutzte Bibliotheken regelmäßig auf bekannte Sicherheitslücken prüfen, nicht nur bei der Erstinstallation, auch bewährte Abhängigkeiten veralten.

Welche Tests braucht man?

KI-generierter Code besteht Beispieleingaben oft überraschend gut, weil Trainingsdaten typische Fälle gut abdecken. Schwächer wird es regelmäßig bei Randfällen, die im Prompt nicht explizit genannt wurden. 3 Testebenen gehören deshalb dazu:

• Unit-Tests für die einzelne Funktion: erwartetes Verhalten bei gültigen Eingaben, klar definierte Rückgabewerte.
• Integrationstests für das Zusammenspiel mit bestehenden Systemen, Datenbanken und Schnittstellen, gerade hier zeigt sich, ob generierter Code zur vorhandenen Architektur passt oder Annahmen trifft, die im übrigen System nicht gelten.
• Gezielte Randfalltests: leere Eingaben, überlange Eingaben, falsche Datentypen, gleichzeitige Zugriffe, Netzwerkfehler.

Das BSI weist zusätzlich darauf hin: Tests bei Systemen mit Sprachmodell-Anteil sollten nicht nur das erzeugte Codestück isoliert betrachten, sondern das gesamte System inklusive aller Schnittstellen. Der Grund: Risiken werden oft erst im Zusammenspiel mehrerer Komponenten sichtbar. Wird das Modell selbst zur Laufzeit eingebunden, etwa um dynamisch Code zu generieren, kommen laut BSI zusätzlich Prüfungen auf Manipulationsversuche wie Prompt Injections hinzu.

Wie prüft man Sicherheit?

Ein Sicherheitscheck für KI-generierten Code sollte mindestens diese 4 Punkte gezielt abfragen, statt auf einen allgemeinen Eindruck „sieht sicher aus“ zu vertrauen:

• Eingabevalidierung: Werden alle externen Eingaben geprüft und bereinigt, bevor sie verarbeitet werden?
• Geheimnisverwaltung: Sind API-Schlüssel, Passwörter oder Zugangsdaten fest im Code verankert (ein häufiger Fehler bei generiertem Code) oder korrekt ausgelagert?
• Rechte- und Zugriffskontrolle: Läuft die Komponente mit minimal notwendigen Rechten, oder wurden Berechtigungen „vorsichtshalber“ großzügig vergeben?
• Bekannte Schwachstellenklassen: Injection-Angriffe, unsichere Deserialisierung, fehlende Verschlüsselung sensibler Daten.

Besonders relevant für KI-Anwendungen: Das BSI empfiehlt, Zugriffs- und Ausführungsrechte von Sprachmodell-Anwendungen auf das nötige Minimum zu beschränken. Dazu gehören klare Grenzen zwischen Modell, Anwendung und externen Ressourcen. Konkret heißt das: Kann die KI-Komponente kritische Aktionen auslösen, etwa eine Datei schreiben oder einen Datensatz löschen? Dafür sollte eine explizite Bestätigung vorgesehen sein, statt der Komponente diese Rechte pauschal zu geben. Ergänzend rät das BSI zu Logging und Monitoring, damit unerwartetes Verhalten überhaupt auffällt.

Wie dokumentiert man Entscheidungen?

Dokumentation ist keine Formalie. Sie ist die Grundlage dafür, dass ein Team später nachvollziehen kann, warum eine Komponente so aussieht, wie sie aussieht. Und wer sie wann freigegeben hat. Für jede KI-generierte Komponente empfiehlt sich mindestens:

• Welches Modell oder Werkzeug beteiligt war. Das ist relevant für spätere Nachvollziehbarkeit und für Modell-Updates, die das Verhalten ändern.
• Welche der 4 Pflichtprüfungen mit welchem Ergebnis stattfanden.
• Wer die fachliche und die sicherheitstechnische Freigabe erteilt hat.
• Bekannte Einschränkungen oder bewusst akzeptierte Restrisiken.

Diese Dokumentation muss nicht aufwendig sein, ein kurzer Eintrag im Pull-Request oder Ticket reicht meist aus. Entscheidend ist, dass sie überhaupt existiert, denn ohne sie lässt sich im Nachhinein nicht unterscheiden, ob eine Komponente geprüft und bewusst freigegeben wurde oder unbemerkt durchgerutscht ist.

Umsetzung: So verankerst du die Prüfungen im Alltag

4 Prüfungen einzuführen bringt wenig, wenn sie übersprungen werden, sobald es eilig wird. Aus meiner Praxis funktionieren diese Ansätze:

1. Prüfungen an den Pull-Request-Prozess binden, nicht an die individuelle Disziplin Einzelner. Eine Checkliste im Pull-Request-Template, die vor dem Merge abgehakt werden muss, schlägt jede gute Absicht.

2. Automatisieren, was automatisierbar ist. Abhängigkeitsscanner, Linter und Testläufe gehören in die CI-Pipeline, nicht in den manuellen Prüfschritt, dort bleibt Aufmerksamkeit für das, was Werkzeuge nicht erkennen: fachliche Passung und Architekturentscheidungen.

3. Verantwortung klar zuordnen. Eine Freigabe braucht eine benannte, verantwortliche Person, „das Team hat es geprüft“ ist im Zweifel niemand.

4. Risikoabhängig differenzieren. Ein internes Skript für eine einmalige Auswertung braucht eine schlankere Prüfung als eine Komponente mit Kundendaten. Die 4 Pflichtprüfungen bleiben, nur ihre Tiefe variiert mit dem Risiko.

Seid ihr unsicher, ob eure bestehende Architektur oder ein konkretes KI-generiertes Modul diesen Anforderungen standhält? Das lässt sich im Rahmen eines Code- und Architektur-Reviews einordnen, oder ihr meldet euch direkt für ein Erstgespräch. Für Teams, die den Prüfprozess selbst aufbauen wollen, bieten sich zudem unsere Schulungen an.

Risiken und Grenzen

• Kein Prüfprozess ersetzt fachliches Verständnis. Eine Checkliste hilft, ersetzt aber nicht, dass mindestens eine Person im Team versteht, was der Code eigentlich tun soll.

• Automatisierte Scanner finden nicht alles. Sie erkennen bekannte Schwachstellenmuster, aber keine neuartigen oder sehr spezifischen Fehler in der Fachlogik.

• Vollständige Sicherheit gibt es nicht. Auch von Menschen geschriebener Code enthält Sicherheitslücken; die 4 Prüfungen senken das Risiko, beseitigen es aber nicht vollständig.

• Reproduzierbarkeit ist eingeschränkt. Dieselbe Eingabe an ein Sprachmodell kann zu unterschiedlichen Zeitpunkten unterschiedlichen Code erzeugen. Ein einmal geprüftes Ergebnis sagt nichts über eine erneute Generierung mit demselben Prompt aus.

• Aufwand ist real, nicht symbolisch. Die vier Prüfungen brauchen Zeit und Kompetenz im Team. Wer sie nur pro forma abhakt, gewinnt keine Sicherheit, sondern nur ein falsches Gefühl davon.

Checkliste: Review-Checkliste für Funktion, Sicherheit und Wartbarkeit

Diese Checkliste ist unser eigenes Arbeitswerkzeug aus Projekten mit KI-generiertem Code. Sie ersetzt kein spezialisiertes Sicherheits-Audit bei hochsensiblen Systemen, deckt aber die Prüfungen ab, die vor jeder Freigabe stehen sollten.

Bereich	Prüfpunkt	Erledigt.
Funktion	Löst der Code die tatsächlich gestellte Anforderung, nicht nur eine plausible Interpretation davon?	☐.
Funktion	Wurden Randfälle (leere/fehlerhafte/überlange Eingaben) getestet, nicht nur der Standardfall?	☐.
Abhängigkeiten	Wurde jede neue Bibliothek einzeln im offiziellen Repository nachgeschlagen (Existenz, Autor, Aktualität)?	☐.
Abhängigkeiten	Lief ein automatisierter Abhängigkeits-/Schwachstellenscan?	☐.
Sicherheit	Werden alle externen Eingaben validiert und bereinigt?	☐.
Sicherheit	Sind Zugangsdaten und Geheimnisse ausgelagert statt fest im Code?	☐.
Sicherheit	Läuft die Komponente mit minimal notwendigen Rechten?	☐.
Sicherheit	Ist bei kritischen Aktionen (Löschen, externe Anfragen) eine Bestätigung oder Begrenzung vorgesehen?	☐.
Wartbarkeit	Ist der Code so dokumentiert, dass ihn jemand anderes ohne Rückfrage weiterentwickeln kann?	☐.
Wartbarkeit	Passt die Architektur zum bestehenden System, statt eine isolierte Sonderlösung zu sein?	☐.
Dokumentation	Ist festgehalten, welches Modell beteiligt war und welche Prüfungen stattfanden?	☐.
Freigabe	Ist eine namentlich verantwortliche Person für die Freigabe benannt?	☐.

Eigene Review-Checkliste Philogic Labs, aus Projekten mit KI-gestützter Entwicklung; Risikoeinordnung zu Abhängigkeiten und Rechten gestützt auf BSI-Publikation (siehe Quellen).

Stand: Juli 2026. Risiken und Gegenmaßnahmen zu generativer KI im Softwarekontext ändern sich mit neuen Modellversionen und Angriffsmustern; diese Checkliste sollte entsprechend regelmäßig überprüft werden.