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

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, sondern darin, dass der erzeugte Code fast immer sauber formatiert, gut kommentiert und auf den ersten Blick funktionsfähig aussieht – 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 und richtet sich an Geschäftsführung, Operations, IT und Fachbereich in kleinen und mittleren Unternehmen, 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

Drei 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-generiertem Code reicht keine dieser drei Prüfungen allein. Ein Review erkennt schlechte Architektur, aber nicht zuverlässig eine unsichere Verschlüsselungsfunktion. Ein Test bestätigt das erwartete Verhalten für die geprüften Fälle, sagt aber nichts über unbekannte Angriffsvektoren. Ein Sicherheits-Audit findet Schwachstellenmuster, aber keine fachlichen Denkfehler. Deshalb braucht freigabefähiger KI-Code alle drei Ebenen – dazu kommt bei KI-generiertem Code eine vierte, spezifische Prüfung: die Kontrolle, ob referenzierte Abhängigkeiten überhaupt 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 vier Prüfungen sind deshalb Pflicht und nicht optional, weil KI-generierter Code laut BSI bekannte oder unbekannte Sicherheitslücken enthalten oder veraltete Bibliotheken verwenden kann, ohne dass das an der Oberfläche erkennbar ist. Die Verantwortung für die Prüfung verschiebt sich dabei nicht auf das Modell: Google stellt in seinen Richtlinien zu KI-generierten Inhalten klar, dass die Verantwortung für Genauigkeit und Qualität veröffentlichter Inhalte beim Publisher liegt – unabhängig von der Erstellungsmethode. Übertragen auf Software heißt das: Wer KI-generierten Code in Produktion bringt, haftet für die Konsequenzen, nicht das Modell.

Wie kontrolliert man Abhängigkeiten?

Diese Prüfung wird am häufigsten übersprungen, weil neu vorgeschlagene Pakete unauffällig wirken. Genau hier liegt ein dokumentiertes, konkretes Risiko: Das BSI beschreibt in seiner Publikation zu generativen KI-Modellen ein Angriffsmuster, bei dem Sprachmodelle Namen von Programmbibliotheken halluzinieren – also Paketnamen empfehlen, die gar nicht existieren. Angreifende beobachten, welche Namen ein bestimmtes Modell in welchem Kontext wiederholt „erfindet”, und veröffentlichen unter genau diesem Namen 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 Dokument illustriert das am Beispiel eines fiktiven Python-Pakets, das ein Modell wiederholt vorschlägt, obwohl es ursprünglich nicht existierte, bis eine angreifende Person es genau dafür anlegt.

Daraus ergibt sich ein klares Vorgehen:

• Jede von der KI vorgeschlagene Bibliothek einzeln im offiziellen Paket-Repository (z. B. 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. Drei 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, dass Tests bei Systemen mit Sprachmodell-Anteil nicht nur das erzeugte Codestück isoliert betrachten sollten, sondern das gesamte System inklusive aller Schnittstellen – gerade weil Risiken oft erst im Zusammenspiel mehrerer Komponenten sichtbar werden. Wird das Modell selbst zur Laufzeit eingebunden (etwa um dynamisch Code zu generieren oder auszuführen), kommen laut BSI zusätzlich Prüfungen auf Manipulationsversuche wie Prompt Injections hinzu, die über klassische Softwaretests hinausgehen.

Wie prüft man Sicherheit?

Ein Sicherheitscheck für KI-generierten Code sollte mindestens folgende 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-gestützte Anwendungen: Das BSI empfiehlt, die Zugriffs- und Ausführungsrechte von Anwendungen, die auf Sprachmodellen basieren, konsequent auf das notwendige Minimum zu beschränken und klare Vertrauensgrenzen zwischen Modell, Anwendung und externen Ressourcen festzulegen. Konkret heißt das: Kann die KI-Komponente potenziell kritische Aktionen auslösen (Datei schreiben, externe Anfrage senden, Datensatz löschen), sollte dafür 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 – etwa durch Manipulation der Eingaben – überhaupt auffällt.

Wie dokumentiert man Entscheidungen?

Dokumentation ist keine Formalie, sondern 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 an der Erstellung beteiligt war (relevant für spätere Nachvollziehbarkeit und mögliche Modell-Updates, die das Verhalten ändern).
• Welche der vier 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

Vier Prüfungen einzuführen bringt wenig, wenn sie in der Praxis übersprungen werden, sobald es eilig wird. Aus meiner Projektpraxis funktionieren folgende 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 Datenauswertung braucht eine schlankere Prüfung als eine Komponente, die Kundendaten verarbeitet oder öffentlich erreichbar ist. Die vier Pflichtprüfungen bleiben, ihre Tiefe variiert mit dem Risiko.

Wenn ihr unsicher seid, ob eure bestehende Architektur oder ein konkretes KI-generiertes Modul diesen Anforderungen standhält, lässt sich das 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 vier 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.