Ist so eine Prüfung wirklich kostenlos?

Ja. Du bekommst das Dokument mit den gefundenen Risiken, auch wenn danach kein weiterer Auftrag entsteht.

Wie lange dauert es, wenn nur der KI-generierte Teil geprüft werden soll?

Meist wenige Tage, oft schneller als ein vollständiges Architektur-Review, weil sich die Prüfung auf den neuen, ungeprüften Code konzentriert. Den genauen Umfang klären wir im ersten Gespräch.

Muss ich euch danach beauftragen?

Nein. Das Dokument gehört dir und ist auch ohne uns nutzbar.

Eignet sich das auch für einen Prototyp, den ich mit KI-Tools gebaut habe?

Ja, gerade dann. Je schneller ein Prototyp entstanden ist, desto wahrscheinlicher fehlt die Zeit, jede Zeile selbst zu prüfen, bevor er echten Traffic bekommt.

KI-generierter Code: 5 Dinge, die vor dem Launch geprüft werden müssen

Der Code sieht fertig aus, ist er aber nicht

KI-Tools schreiben heute Code, der auf den ersten Blick funktioniert. Er kompiliert, die Tests laufen durch, die Oberfläche sieht aus wie geplant. Genau das macht die eigentliche Gefahr aus: Code, der funktioniert, ist nicht dasselbe wie Code, der sicher ist. Ein KI-Tool optimiert für den Fall, den du gerade testest, nicht für den Fall, den ein Angreifer oder ein echter Nutzer in drei Monaten produziert.

Bevor so ein Code echten Traffic sieht, lohnt sich ein konkreter Blick auf fünf Stellen, an denen sich Probleme am häufigsten verstecken.

1. Prüft die Berechtigungslogik wirklich, oder sieht sie nur so aus?

KI-generierter Code enthält fast immer eine Prüfung, ob jemand eingeloggt ist. Ob diese Person auch berechtigt ist, genau diese Aktion auf genau dieser Ressource auszuführen, ist eine andere Frage, die oft übersehen wird. Ein typisches Muster: Ein Endpunkt prüft, dass ein Token gültig ist, aber nicht, ob der zugehörige Nutzer der Eigentümer des angefragten Datensatzes ist. Jeder eingeloggte Nutzer kann dann fremde Bestellungen, Profile oder Dokumente über die ID in der URL abrufen.

Gut sieht das aus, wenn jede Route, die auf einen konkreten Datensatz zugreift, explizit prüft, ob der anfragende Nutzer diesen Datensatz überhaupt sehen darf, nicht nur, ob er irgendwie angemeldet ist.

KI-Tools schreiben Funktionen, die für den Beispielinput im Prompt funktionieren. Was passiert, wenn ein Feld leer bleibt, ein String statt einer Zahl kommt oder jemand absichtlich SQL-Syntax in ein Formularfeld tippt, wird selten mitgedacht, weil es im Beispiel nie vorkam. Genau das ist der klassische Weg zu Injection-Schwachstellen: Eingaben landen ungeprüft in einer Datenbankabfrage oder werden direkt ausgeführt.

Gut sieht das aus, wenn jede Eingabe, die von außen kommt, also aus Formularen, URLs oder APIs, gegen einen erwarteten Typ und Wertebereich geprüft wird, bevor sie irgendwo weiterverarbeitet wird, und wenn Datenbankzugriffe ausschließlich über parametrisierte Abfragen laufen.

3. Scheitert der Code laut, oder schluckt er Fehler leise?

Ein Muster, das in KI-generiertem Code auffällig oft vorkommt: ein leerer catch-Block oder ein except, das den Fehler einfach verschluckt, damit der Ablauf nicht unterbrochen wird. Aus Sicht des Tools ist das eine saubere Lösung, der Code läuft ohne Absturz durch. Aus Sicht des Betriebs ist es das Gegenteil: Ein fehlgeschlagener Zahlungsvorgang, eine nicht gespeicherte Bestellung oder ein gescheiterter Login werden nirgends sichtbar, weder im Log noch für den Nutzer.

Gut sieht das aus, wenn jeder Fehlerfall entweder sichtbar geloggt wird, dem Nutzer eine verständliche Rückmeldung gibt, oder beides, und wenn nirgends ein catch-Block existiert, der nichts weiter tut, als den Fehler zu ignorieren.

4. Wohin gehen sensible Daten wirklich?

KI-Tools loggen gerne großzügig, weil Logging beim Debuggen hilft und im Prompt niemand explizit ausgeschlossen hat, was nicht geloggt werden soll. Das Ergebnis: Passwörter, Tokens, E-Mail-Adressen oder ganze Request-Bodies landen unverschlüsselt in Log-Dateien, die weniger streng geschützt sind als die eigentliche Datenbank. Ähnlich häufig: API-Antworten geben mehr Felder zurück, als die Oberfläche tatsächlich braucht, weil es einfacher war, das ganze Datenbankobjekt zu serialisieren als die Antwort gezielt zusammenzustellen.

Gut sieht das aus, wenn du eine kurze Liste hast, welche Felder als sensibel gelten, und wenn Logging-Statements und API-Antworten gezielt danach durchsucht wurden, statt sich darauf zu verlassen, dass schon nichts Wichtiges dabei ist.

5. Welche Pakete hat das Tool im Hintergrund installiert?

Wenn ein KI-Tool eine Funktion braucht, greift es oft zur ersten passenden Bibliothek, die es kennt, nicht zur aktuell gepflegten. Das kann ein Paket sein, das seit Jahren kein Update mehr bekommen hat, eine Version mit einer bekannten Sicherheitslücke, oder schlicht eine Abhängigkeit, die für die Aufgabe unnötig groß und komplex ist. Niemand hat diese Entscheidung bewusst getroffen, sie ist einfach im generierten Code gelandet.

Gut sieht das aus, wenn die package.json oder requirements.txt tatsächlich durchgegangen wurde, jedes neue Paket eine erkennbare Daseinsberechtigung hat und ein Audit-Tool keine bekannten Schwachstellen in den verwendeten Versionen meldet.

Ein zweites Paar Augen sieht, was du selbst übersiehst

Diese fünf Punkte lassen sich mit Disziplin selbst abarbeiten. Das eigentliche Problem ist selten fehlendes Wissen, sondern fehlender Abstand: Wer ein Feature in einem Nachmittag mit KI-Unterstützung gebaut hat, sieht den eigenen Code als fertig an, weil er im Kopf schon zum nächsten Schritt weitergezogen ist. Genau die Stellen, die am meisten wehtun, wenn sie in Produktion auffallen, sind die, die man im eigenen Tempo am leichtesten übersieht.

Ein Architektur-Review ist dafür da: ein Blick von außen auf genau die Stellen, an denen schnell gebauter Code am ehesten nachgibt, bevor er es in Produktion tut.

Frag dich also, bevor der nächste KI-generierte Code live geht: Hast du diese fünf Punkte selbst geprüft, oder nur angenommen, dass sie schon passen?