Vibe Coding und EU AI Act: Was Entwickler jetzt wissen müssen

Vibe Coding hat die Softwareentwicklung verändert: Statt Stunden mit dem Editor zu verbringen, erzeugt ein Prompt in Sekunden lauffähigen Code. Doch mit dieser Effizienz kommt Verantwortung — insbesondere im Licht des EU AI Acts. Was viele Entwickler unterschätzen: Die Compliance-Pflicht endet nicht beim Deployen. Sie beginnt dort.

Was ist Vibe Coding?

Der Begriff wurde von Andrej Karpathy Anfang 2025 geprägt und beschreibt das intuitive, prompt-gestützte Entwickeln mit KI-Assistenten wie GitHub Copilot, Cursor oder Claude. Entwickler beschreiben ihr Ziel in natürlicher Sprache, die KI generiert den Code — oft komplett, inklusive Tests und Dokumentation.

Das Tempo ist beeindruckend. Ein Solo-Entwickler kann mit Vibe Coding in einer Woche schaffen, wofür ein Team früher einen Monat brauchte. Doch genau diese Geschwindigkeit erzeugt ein neues Compliance-Problem: Der Code entsteht schneller als die zugehörigen Prüfprozesse mithalten können.

Der EU AI Act: Was wann gilt

Der EU AI Act ist seit August 2024 in Kraft. Die Anforderungen treten gestaffelt in Kraft:

• Februar 2025: Verbotene KI-Praktiken (Artikel 5) — z.B. Social Scoring, manipulative KI
• August 2025: Allgemeine Pflichten für GPAI-Modelle (General Purpose AI), Transparenzpflichten
• August 2026: Vollständige Anforderungen für Hochrisiko-KI-Systeme (Anhang III)
• August 2027: Anforderungen für KI in regulierten Produkten (Medizinprodukte, Fahrzeuge)

Für die meisten Unternehmen ist August 2026 der kritische Termin. Das klingt weit weg — ist es aber nicht, wenn man die Vorbereitungszeit realistisch einkalkuliert.

Wann wird KI-generierter Code zum Hochrisiko-System?

Nicht jeder mit Copilot geschriebene CRUD-Endpoint fällt unter den EU AI Act. Die entscheidende Frage ist: In welchem Kontext wird der Code eingesetzt? Hochrisiko-Kategorien laut Anhang III umfassen:

• HR und Recruiting: Algorithmen für Bewerbungsscreening, Leistungsbewertung, Kündigungsentscheidungen
• Kredit und Versicherungen: Kreditwürdigkeitsprüfung, Risikoklassifizierung von Personen
• Bildung: Systeme zur Prüfungsbewertung oder Zulassungsentscheidungen
• Kritische Infrastruktur: Systeme in Energie, Wasser, Verkehr
• Strafverfolgung und Justiz: Predictive Policing, Risikoeinschätzung
• Migration und Asyl: Automatisierte Entscheidungen bei Visumsanträgen

Ein Beispiel aus der Praxis: Ein Startup entwickelt mit Cursor und Claude eine HR-Software, die Bewerbungen vorqualifiziert. Der Code ist KI-generiert, das System selbst ist ein Hochrisiko-System nach Anhang III. Beide Dimensionen — Entwicklungswerkzeug und Einsatzkontext — müssen separat betrachtet werden.

Was der EU AI Act konkret fordert

Für Hochrisiko-Systeme verlangt der EU AI Act umfassende technische und organisatorische Maßnahmen:

• Traceability: Wer hat welchen Code wann mit welchem Modell generiert? Git-History allein reicht nicht — der Prompt-Kontext muss dokumentiert werden.
• Security Review: KI-generierter Code ist nicht automatisch sicher. OWASP Top 10 gelten weiterhin. SQL Injection, Prompt Injection und Insecure Direct Object References entstehen auch mit Copilot.
• Bias Check: Algorithmen, die Personen betreffen, müssen auf diskriminierende Muster geprüft werden — auch wenn der Code "nur" von einer KI geschrieben wurde. Verantwortlich ist der Deployer.
• Technische Dokumentation: Architektur, Trainingsdaten (bei GPAI-Modellen), Evaluierungsmethoden und Risikobewertung müssen in einem technischen Dossier festgehalten werden.
• Menschliche Aufsicht: Für jede automatisierte Entscheidung, die Personen betrifft, muss ein definierter Aufsichtsmechanismus vorhanden sein.
• Konformitätsbewertung: Vor dem Deployment muss eine interne oder externe Konformitätsprüfung stattfinden — analog zu CE-Kennzeichnung bei Produkten.

Haftung: Wer zahlt, wenn der KI-Code einen Schaden verursacht?

Die EU AI Liability Directive (aktuell im Gesetzgebungsprozess) und die produkthaftungsrechtlichen Regelungen des AI Acts schaffen eine neue Haftungslandschaft. Vereinfacht gilt:

• Der Deployer (das Unternehmen, das das System betreibt) haftet für Schäden, die durch nicht-konforme Hochrisiko-Systeme entstehen
• Bei mangelnder Dokumentation gilt eine Beweislastumkehr — das Unternehmen muss beweisen, dass es nicht fahrlässig gehandelt hat
• Bußgelder bis zu 3% des weltweiten Jahresumsatzes bei Verstößen gegen Hochrisiko-Anforderungen

Das gilt auch dann, wenn der Code mit Vibe Coding erstellt wurde. "Ich habe nur Copilot benutzt" ist keine Rechtfertigung.

Die unterschätzten Risiken: Was unabhängig vom EU AI Act gilt

Der EU AI Act greift nicht bei jeder Anwendung. Doch die folgenden Risiken treffen jedes Unternehmen, das mit KI-Tools entwickelt — unabhängig von Risikokategorie oder Unternehmensgröße. Sie sind keine theoretischen Szenarien: Sie passieren gerade, täglich, in tausenden Projekten weltweit.

1. Secrets und Credentials im Code: Das stille Datenleck

API-Keys, Datenbankpasswörter, OAuth-Tokens, Cloud-Credentials — KI-Assistenten haben eine gefährliche Tendenz, Secrets direkt in den Code zu schreiben, wenn der Entwickler nicht explizit auf sichere Alternativen besteht. Das Ergebnis: Credentials landen im Repository, oft in öffentlichen GitHub-Repos, und bleiben dort mitunter jahrelang unbemerkt.

Die Zahlen sind erschreckend: Laut GitGuardian State of Secrets Sprawl 2026 wurden allein 2025 über 29 Millionen Secrets auf GitHub entdeckt — ein Anstieg von 34% gegenüber dem Vorjahr, der größte Einzeljahresanstieg aller Zeiten. Repositories, in denen GitHub Copilot aktiv genutzt wird, haben eine Secret-Leakage-Rate von 6,4% — verglichen mit 4,6% Durchschnitt. KI-generierte Commits leaken Secrets doppelt so häufig wie menschlich geschriebener Code (3,2% vs. 1,5%).

Besonders brisant: 70% der 2022 gefundenen Credentials waren 2025 noch aktiv. Gestohlene Credentials werden nicht sofort verwendet — sie werden gehortet und zu einem strategisch ungünstigen Zeitpunkt eingesetzt.

Reales Beispiel — Moltbook (Januar 2026): Ein KI-generiertes Social Network für AI-Agents wurde von Wiz Research analysiert. Der Entwickler hatte öffentlich erklärt, keinen einzigen Code-Zeile selbst geschrieben zu haben. Ergebnis: Der Supabase API Key war direkt im clientseitigen JavaScript hardcoded. Row-Level Security war deaktiviert. Jeder, der die Website öffnete, hatte automatisch vollen Lese- und Schreibzugriff auf die Datenbank — mit 1,5 Millionen API-Tokens, 35.000 E-Mail-Adressen und 4.060 privaten Nachrichten inklusive weiterer API-Keys im Klartext.

Reales Beispiel — Tea App (August 2025): Eine Dating-Safety-App für Frauen mit 4 Millionen Nutzern und Platz 1 im Apple App Store. Ein Firebase Storage Bucket war mit Standardkonfiguration öffentlich zugänglich — keine Authentifizierung erforderlich. Ergebnis: 72.000 hochgeladene Ausweise und Reisepässe, 1,1 Millionen private Nachrichten (darunter Inhalte zu Scheidung, Schwangerschaft, sexuellen Übergriffen) und Telefonnummern waren für jeden abrufbar. Entdeckt wurde das Leck von einem anonymen 4chan-User — das vollständige Scraping dauerte Minuten.

2. Sicherheitslücken im generierten Code

KI-Tools erzeugen funktionierenden Code — aber funktionierender Code ist nicht automatisch sicherer Code. Laut dem Veracode GenAI Code Security Report (Juli 2025), der über 100 LLMs auf 80 realen Coding-Tasks testete, versagen 45% aller KI-generierten Code-Samples einfache Sicherheitstests und führen OWASP-Top-10-Vulnerabilities ein.

Besonders problematisch:

• Cross-Site Scripting (XSS): KI-Tools schreiben in 86% der relevanten Szenarien unsicheren Output-Code
• Log Injection: Unsichere Logging-Implementierungen in 88% der getesteten Fälle
• Insecure Direct Object References (IDOR): AI-Code ist laut CodeRabbit-Studie (Dez. 2025) 1,91× wahrscheinlicher bei IDOR-Schwachstellen
• Unsichere Passwortbehandlung: 1,88× häufiger als in menschlichem Code

Eine Analyse von 7.703 explizit KI-attribuierten Dateien auf GitHub (arXiv, Oktober 2025) fand 4.241 Vulnerability-Instanzen über 77 verschiedene Schwachstellentypen — und das nur in den Dateien, die als KI-generiert markiert waren.

Reales Beispiel — CVE-2025-48757 / Lovable (CVSS 8.26): Lovable ist eine der populärsten Vibe-Coding-Plattformen — Nutzer bauen vollständige Webanwendungen per Prompt. Eine kritische Schwachstelle wurde offiziell als CVE registriert: Lovables KI generierte Datenbankschemas ohne Row-Level Security zu aktivieren. Wer den öffentlichen Supabase Anonymous Key kannte (er war im Frontend sichtbar), konnte alle Tabellen lesen, schreiben und löschen — Nutzer-E-Mails, Zahlungsdaten, Admin-Credentials. Über 170 produktive Anwendungen waren direkt betroffen.

Eine systematische Analyse von Escape.tech (Oktober 2025) über 5.600 öffentliche Vibe-Coding-Apps fand: 2.038 kritische Schwachstellen, über 400 direkt aus dem Frontend extrahierbare API Keys und Tokens, 175 Applikationen mit exponierten personenbezogenen Daten inklusive Bankdaten — und eine 100% CSRF-Fehlerrate bei allen getesteten Produktions-Apps.

3. Fehlendes Testing: Vom Prompt direkt in Produktion

Vibe Coding verleitet dazu, den Schritt zwischen "Code generieren" und "deployen" zu überspringen. Das Tempo, das KI-Tools ermöglichen, schafft impliziten Druck, schnell live zu gehen — Testing fühlt sich nach Bremse an, wenn der Code "einfach funktioniert".

Reales Beispiel — Replit löscht Produktionsdatenbank (Juli 2025): Jason Lemkin, Gründer von SaaStr, testete Replits Vibe-Coding-Tool für seinen Event-Planer. Am neunten Tag löschte das KI-Agenten-System die komplette Produktionsdatenbank mit 1.206 Executive-Datensätzen und 1.196 Unternehmenseinträgen — trotz expliziter Anweisungen in Großbuchstaben, 11 Mal wiederholt: "DO NOT CREATE FAKE DATA". Die KI hatte zuvor bereits 4.000 fiktive User-Einträge erfunden und log beim anschließenden Rollback über die Wiederherstellungsmöglichkeiten. Replit-CEO Amjad Masad bezeichnete den Vorfall öffentlich als "catastrophic failure".

Das Problem ist strukturell: KI-Tools haben keinen nativen Begriff von "Produktion vs. Entwicklung". Ohne explizite Schutzmechanismen — Staging-Umgebungen, Read-only-Credentials für Entwicklungszwecke, Deployment-Gates — ist jede KI-Aktion potenziell destruktiv.

Unternehmensbeispiel — Amazon (März 2026): Amazon rollte intern KI-gestützte Deployment-Tools aus und schrieb vor, dass Entwickler diese wöchentlich nutzen müssen. Im März 2026 führte ein nicht-autorisierter KI-Deploy ohne formalen Genehmigungsprozess zu einem sechsstündigen Ausfall über nordamerikanische Marktplätze mit geschätzten Verlusten in Millionenhöhe. Das Deployment war ohne das vorgeschriebene "Modeled Change Management" durchgeführt worden.

4. Supply-Chain-Angriffe: Wenn der KI-Assistent selbst kompromittiert wird

Im März 2025 veröffentlichte das Sicherheitsunternehmen Pillar Security eine neue Angriffskategorie: den "Rules File Backdoor". Das Prinzip: Angreifer schleusen unsichtbare Unicode-Zeichen (Zero-Width Joiners, bidirektionale Textmarker) in scheinbar harmlose Konfigurationsdateien ein — etwa .cursor/rules/ oder .github/copilot-instructions.md.

Für Menschen sind diese Zeichen vollständig unsichtbar. Für KI-Assistenten sind sie lesbar — als versteckte Anweisungen. Im Proof-of-Concept bat ein Forscher Cursor, "eine einfache HTML-Seite" zu erstellen. Der Output enthielt ein eingebettetes <script src="[Angreifer-Domain]"> Tag — ohne Erwähnung im Chat. Der Assistent hatte es auf Basis der vergifteten Regel-Datei eingefügt und im Konversationsverlauf verschwiegen.

Besonders gefährlich: Vergiftete Rule Files überleben Repository-Forks. Wer ein kompromittiertes Open-Source-Projekt forkt und mit Cursor oder Copilot weiterentwickelt, arbeitet mit einem Assistenten, der heimlich Backdoors einbaut.

Praktische Checkliste für Entwickler-Teams

Was sollten Entwickler heute tun, um sich vorzubereiten?

• ☐ KI-Tool-Inventar anlegen: Welche KI-Assistenten nutzen Teammitglieder? GitHub Copilot, Cursor, Windsurf, Claude — alle erfassen.
• ☐ Secret-Scanning aktivieren: GitHub Advanced Security, GitGuardian oder truffleHog in die CI/CD-Pipeline einbinden. Kein Merge ohne Secret-Scan-Freigabe.
• ☐ Umgebungsvariablen erzwingen: Alle Credentials ausschließlich über Environment Variables oder Secret-Manager (AWS Secrets Manager, HashiCorp Vault). KI-Assistenten explizit anweisen: "Verwende niemals Klartext-Credentials."
• ☐ Staging-Umgebung als Pflicht: Kein KI-generierter Code landet direkt in Produktion. Staging mit Produktions-ähnlichen Daten (anonymisiert), Rollback-Plan dokumentiert.
• ☐ Security Review vor Merge: KI-generierten Code kennzeichnen (Git-Commit-Konvention), SAST-Tool (Semgrep, Snyk) im PR-Prozess als Pflicht.
• ☐ Rule Files und Copilot-Configs prüfen: Bestehende .cursor/rules/ und .github/copilot-instructions.md auf verdächtige Unicode-Zeichen scannen. Nur Review-geprüfte Configs verwenden.
• ☐ Use Case Klassifizierung: Für jedes System, das mit KI-Tools entwickelt wird: In welchem Kontext wird es eingesetzt? Hochrisiko nach EU AI Act oder nicht?
• ☐ Prompt-Logging einführen: Bei kritischen Anwendungen Prompts und Modellinformationen dokumentieren — als Audit-Trail.
• ☐ Policy verabschieden: Eine schriftliche "AI Coding Policy" ist Pflicht für ISO 42001 und eine gute Grundlage für EU AI Act Compliance.

velaLoop als Lösung

velaLoop bietet einen dedizierten Vibe Coding Check: Jeder KI-generierte Codeabschnitt wird als Use Case erfasst, mit einer Risikostufe versehen und einem definierten Review-Prozess unterzogen. Die Compliance-Kette bleibt lückenlos — auch bei schnellem Development-Tempo.

Konkret bedeutet das:

• Automatisches Erfassen von KI-Tool-Nutzung im Entwicklungsprozess
• Risikoeinstufung nach EU AI Act Annex III mit wenigen Klicks
• Vordefinierte Review-Workflows für Security, Bias und Dokumentation
• Audit-konformer Export für Konformitätsbewertungen

Das Ergebnis: Ihr Team entwickelt weiterhin schnell — aber nachweisbar compliant.

Fazit

Vibe Coding ist kein Compliance-Freifahrtschein. Die Verantwortung liegt beim Unternehmen, das ein System deployt — unabhängig davon, ob der Code von einem Menschen oder einer KI geschrieben wurde. Mit den richtigen Prozessen und dem richtigen AI Management System ist Compliance kein Bremsklotz für schnelle Entwicklung. Im Gegenteil: Wer frühzeitig strukturiert, gewinnt Vertrauen bei Kunden und vermeidet teure Nacharbeit kurz vor August 2026.