Nicht in seltenen Ausnahmefällen. Nicht nur bei schlechten Prompts. In fast jedem zweiten Fall. Das Problem ist praktisch relevant, wie die Veracode-Daten und aktuelle Analysen von Entwicklungs-Workflows zeigen, und kein theoretisches Gedankenexperiment.
Ich begutachte seit über 15 Jahren fremden Code: zuerst als Entwickler in Agenturen, dann als selbstständiger Senior-Entwickler bei SERVIT. Seit KI-Coding-Assistenten in Entwicklungsprozesse eingeflossen sind, sehe ich täglich, was ohne strukturiertes Review in produktiven Systemen landet. Die Muster wiederholen sich. Die Konsequenzen auch.
Dieser Artikel zeigt, welche Risiken KI-generierter Code ohne Review konkret mitbringt, wo sie rechtlich und technisch teuer werden, und was ein pragmatischer Prüfprozess leisten muss, bevor Code live geht.
Sicherheitslücken, die kein Entwickler absichtlich einbauen würde
Was aktuelle Studien über KI-generierten Code ohne Review sagen
Die Veracode-Zahlen stehen nicht allein. Analysen von KI-generierten Pull Requests (CodeRabbit, 2025) zeigen, dass diese im Schnitt 1,7-mal mehr Probleme enthalten als menschlich erstellte. Sicherheitsbefunde treten dabei 1,57-mal häufiger auf. Im Schnitt wies ein KI-generierter Pull Request rund 10,83 Mängel auf, ein menschlicher 6,45. Das ist kein Randphänomen, das ist ein systematischer Unterschied.
Hinzu kommt ein Mechanismus, den die Fachwelt als Modell-Halluzination bezeichnet: Sprachmodelle erfinden plausibel klingende Bibliotheken, Funktionsnamen oder Konfigurationsparameter, die schlicht nicht existieren. Der generierte Code sieht konsistent aus, verweist aber auf Abhängigkeiten oder Schnittstellen, die im Produktivsystem fehlen oder, noch kritischer, durch bösartige Pakete besetzt werden könnten. Das Modell optimiert auf Wahrscheinlichkeit, nicht auf Korrektheit. „Laufen“ und „sicher sein“ sind zwei völlig verschiedene Dinge.
Die häufigsten Schwachstellen bei KI-generiertem Code im Überblick
Besonders häufig dokumentiert sind Cross-Site-Scripting durch fehlende Eingabevalidierung, SQL-Injection durch Zeichenkettenverknüpfung statt vorbereiteter Datenbankabfragen, Protokoll-Injektion sowie hartcodierte Zugangsdaten wie API-Schlüssel oder JWT-Geheimnisse. Dazu kommen fehlende Berechtigungsprüfungen, zu offene CORS-Konfigurationen und ein Debugmodus, der in der Produktionsumgebung aktiv bleibt. Letzterer kann im Extremfall vollständige Fehlerprotokolle oder sogar Fernzugriff freigeben.
Bei Java-spezifischen Tests lag die Fehlerquote laut Veracode GenAI Code Security Report 2025 bei rund 70 Prozent. Cross-Site-Scripting trat in relevanten Testfällen in 86 Prozent der Fälle auf, Protokoll-Injektion in 88 Prozent. Diese Zahlen beschreiben keinen Ausreißer, sondern einen Grundzustand.
Stille Logikfehler und technische Schuld, die erst später auffallen
Wenn der Code läuft, aber die Logik falsch ist
Neben den offensichtlichen Sicherheitslücken gibt es ein subtileres Problem: KI-generierter Code kann syntaktisch korrekt und scheinbar sauber sein und trotzdem falsch funktionieren. Dokumentiert sind nicht definierte Variablen, doppelt deklarierte Bezeichner und Zugriffe auf Klassenmitglieder vor deren Definition. Diese Fehler werden in manuellen Durchläufen oft nicht entdeckt, weil der Entwickler den generierten Code als fertig betrachtet und keine kritische Prüfung vornimmt.
Ein konkretes Szenario: Eine Berechnungsfunktion liefert in 95 Prozent der Fälle das richtige Ergebnis. Die restlichen fünf Prozent fallen erst im Produktivbetrieb auf, wenn Kundendaten falsch verarbeitet oder Bestellungen fehlerhaft berechnet werden. Laut CodeRabbit-Analyse (2025) treten Logikfehler in KI-generiertem Code rund 75 Prozent häufiger auf als in menschlich geschriebenem Code. Fehlende Fehlerbehandlung, fehlende Nullprüfungen und unvollständige Ausnahmelogik finden sich dabei fast doppelt so oft.
Wartbarkeit als verstecktes Risiko beim produktiven Einsatz von KI-Code
KI-generiertem Code fehlt oft der Kontext, den ein erfahrener Entwickler instinktiv einbaut: sinnvolle Modularisierung, einheitliche Benennung, nachvollziehbare Fehlerbehandlung. Der Code funktioniert beim ersten Hinschauen. Beim nächsten Feature ist er schwer zu erweitern.
Technische Schuld entsteht leise und summiert sich. Wer drei Monate später an diesem Code arbeitet, investiert nach Erfahrungswerten aus mittelfristig betriebenen Projekten deutlich mehr Zeit, als beim ursprünglichen Schreiben eingespart wurde. Das ist keine abstrakte Warnung, das ist Projektrealität.
Lizenz- und Datenschutzfallen, die rechtlich teuer werden
Copyleft-Risiken durch unerkannte Codeübernahmen
KI-Modelle wurden auf öffentlichem Quellcode trainiert, darunter Code unter GPL- und LGPL-Lizenzen. Wenn das Modell Fragmente daraus reproduziert, ohne das zu kennzeichnen, kann das eigene Projekt unbemerkt unter eine Copyleft-Lizenz fallen. Im Extremfall bedeutet das für Unternehmen, die proprietäre Software entwickeln, die Pflicht zur vollständigen Offenlegung des eigenen Quellcodes.
In Österreich drohen bei Urheberrechtsverstößen Unterlassungsansprüche, Schadenersatz sowie Auskunfts- und Beseitigungsansprüche. Die Nutzungsrechte an betroffenen Codebestandteilen fallen ex nunc weg, jede weitere Nutzung oder Auslieferung ist dann eine Rechtsverletzung, unabhängig davon, ob der Verstoß bewusst war oder nicht.
DSGVO-Risiken und Geheimnisverluste im Entwicklungsprozess
Wer interne Datenbankstrukturen, Kundendaten oder API-Schlüssel in externe KI-Assistenten eingibt, verliert die Kontrolle darüber. Das ist keine Vermutung, das ist Mechanik: Diese Daten verlassen das Unternehmen. Manche Anbieter speichern Eingaben und nutzen sie für das Modelltraining. Personenbezogene Daten in Eingabeaufforderungen oder Quellcode lösen DSGVO-Anforderungen aus, oft ohne dass eine ausreichende Rechtsgrundlage oder ein Auftragsverarbeitungsvertrag vorliegt.
Für österreichische Unternehmen ist das kein Kavaliersdelikt. Und noch ein Punkt: Wenn KI-generierter Code ohne Review eine Sicherheitslücke enthält, die zu einem Datenleck führt, liegt die Haftung nach herrschender Rechtslage und den Nutzungsbedingungen der Anbieter in aller Regel beim Unternehmen, nicht beim KI-Anbieter. Eine abschließende rechtliche Beurteilung hängt vom Einzelfall ab, das Risiko trägt jedoch strukturell derjenige, der den Code produktiv einsetzt.
Was ungeprüfter KI-Code mit Ihrer Produktion macht
Leistungsprobleme und unsichere Konfigurationen in der Praxis
KI-generierter Code neigt zu ineffizienten Datenbankabfragen und fehlenden Zwischenspeicherstrategien, weil das Modell auf Vollständigkeit optimiert, nicht auf Ressourceneffizienz. In Laravel-Applikationen entstehen so N+1-Query-Probleme, die unter Last sichtbar werden. Zu offene CORS-Header, fehlende Anfragebegrenzungen und unsichere Dateizugriffsrechte sind in KI-generiertem Code ebenfalls regelmäßig dokumentiert.
Unsichere Deserialisierung, fehlende Content-Security-Policy-Header und schwache Token-Verarbeitung sind keine exotischen Einzelfälle, sondern wiederkehrende Muster in Benchmark-Studien aus 2025 und 2026. In einer Cobalt-Analyse von sieben verbreiteten KI-Assistenten (Cobalt, 2025) enthielten im Mittel 55,8 Prozent der Ausgaben mindestens eine Schwachstelle.
Governance-Lücken: Wer ist verantwortlich, wenn etwas schiefgeht?
Wenn KI-generierter Code ohne definierten Freigabeprozess produktiv geht, fehlt die klare Antwort auf eine einfache Frage: Wer hat diesen Code freigegeben? Ohne Vier-Augen-Prinzip, ohne CI/CD-Prüfschritt, ohne Protokollierung sicherheitsrelevanter Ereignisse entsteht ein organisatorisches Vakuum. Das ist nicht nur ein technisches Problem, es ist ein Haftungsproblem.
Ein funktionierender Freigabeprozess setzt voraus: klare Rollenverteilung zwischen Entwicklung und Freigabe, Trennung von Zuständigkeiten und manipulationsgeschütztes Protokoll mit definierter Aufbewahrungsfrist. Fehlt dieser Rahmen, werden auch technische Maßnahmen wirkungslos, weil niemand prüft, ob sie tatsächlich greifen.
Risiken beim produktiven Einsatz von KI-generiertem Code: Eine pragmatische Prüfroutine
Technische Kontrollen: Was vor dem Zusammenführen laufen muss
Kein einzelnes Werkzeug reicht aus. Ein sinnvoller Prüfprozess für KI-generierten Code kombiniert mehrere Schichten:
- Statische Codeanalyse mit Semgrep, SonarQube oder für PHP/Laravel-Projekte mit Larastan, Psalm und Enlightn
- Erkennung hartcodierter Zugangsdaten mit gitleaks oder trufflehog, um Geheimnisse vor dem Einpflegen zu finden
- Abhängigkeitsüberprüfung auf bekannte Schwachstellen in eingebundenen Bibliotheken
- Unit- und Integrationstests mit expliziter Abdeckung sicherheitskritischer Pfade
- Dynamische Tests (DAST) gegen die laufende Testumgebung, um Probleme zu finden, die statische Analyse nicht sieht
Diese Werkzeuge ersetzen kein menschliches Review. Aber sie reduzieren den Aufwand erheblich, weil offensichtliche Probleme bereits herausgefiltert sind, bevor ein Mensch den Code liest.
Organisatorische Kontrollen: Prozess schlägt Werkzeug
Technische Maßnahmen entfalten ihre Wirkung nur innerhalb eines klaren organisatorischen Rahmens. Konkret bedeutet das: Vier-Augen-Prinzip für jede produktive Änderung, klare Rollenverteilung zwischen Entwicklung und Freigabe, CI/CD-Prüfschritte, die fehlgeschlagene Sicherheitsprüfungen blockieren statt nur melden, sowie Protokollierung sicherheitsrelevanter Ereignisse mit definierter Aufbewahrungsfrist.
Der entscheidende Punkt: Wer KI-generierten Code ohne diese Kontrollen produktiv einsetzt, spart kurzfristig Zeit und zahlt langfristig mit Ausfällen, Sicherheitsvorfällen oder Compliance-Problemen. Ein Prüfschritt, der einen fehlgeschlagenen Sicherheitscheck meldet, den Bauvorgang aber trotzdem durchlässt, ist kein Prüfschritt, er ist eine Illusion von Kontrolle.
Warum erfahrenes Code-Review bei KI-unterstützter Entwicklung wichtiger wird
Was 15 Jahre Praxis bei der Beurteilung von Code leisten
Mit KI-Assistenten lässt sich Entwicklungsgeschwindigkeit steigern. Das ist real und wäre falsch zu bestreiten. Aber die Fähigkeit, generierten Code zu beurteilen, erfordert Erfahrung, die das Modell selbst nicht hat. Ein Senior-Entwickler erkennt sofort, warum eine bestimmte Datenbankabfrage unter Last problematisch wird, warum eine Authentifizierungslogik eine Lücke hat oder warum eine scheinbar elegante Lösung in drei Monaten unwartbar ist.
Das ist keine Ablehnung von KI als Werkzeug. Es ist die Erkenntnis, dass jedes Werkzeug jemanden braucht, der weiß, wie man es richtig einsetzt. Ein Compilerfehler ist einfach zu finden. Ein Berechtigungsfehler, der in bestimmten Systemzuständen eine Administratorfunktion freigibt, ist es nicht.
SERVIT: KI-gestützte Entwicklung mit professionellem Review
Bei SERVIT wird KI als Beschleuniger eingesetzt, nicht als Ersatz für strukturiertes Denken. Jeder Code, ob menschlich oder KI-generiert, durchläuft denselben Prozess: statische Analyse, Sicherheitsprüfung, manuelle Beurteilung durch einen Senior-Entwickler mit über 15 Jahren Erfahrung in Laravel-, SaaS- und API-Projekten.
Kein Ticketsystem, kein Juniorentwickler als Zwischenstation: Christof Servit liest den Code selbst. Für Unternehmen und Agenturen, die KI-gestützte Entwicklung einsetzen wollen, ohne die Kontrolle über Qualität, Sicherheit und DSGVO-Konformität zu verlieren, ist das der Unterschied zwischen produktivem Fortschritt und einem vermeidbaren Produktionsausfall.
Fazit: Was sind die größten Risiken, wenn man KI-generierten Code ohne Review produktiv einsetzt?
KI-generierter Code ohne Review ist kein kalkuliertes Risiko, er ist ein unkontrolliertes. Die Risiken sind klar benennbar: Sicherheitslücken in fast jedem zweiten Ergebnis, stille Logikfehler und Modell-Halluzinationen, die erst unter Last sichtbar werden, Lizenz- und Datenschutzprobleme mit rechtlichen Konsequenzen, Governance-Lücken, die im Schadensfall niemanden verantwortlich zurücklassen.
Der Ausweg ist kein Verzicht auf KI. Der Ausweg ist ein definierter Review-Prozess, der technische und organisatorische Kontrollen kombiniert und von jemandem verantwortet wird, der die Risiken kennt. Wer diesen Prozess intern nicht abbilden kann oder will, braucht einen verlässlichen Partner.
Wer das für ein Projekt konkret angehen will, kann sich direkt bei SERVIT melden. Kein Formular, kein Ticket: ein Gespräch mit dem Entwickler, der den Code auch wirklich liest.
