Shadow IT durch Vibe Coding: das neue Governance-Risiko

Vibe Coding hat das Spielfeld verschoben. Wer früher eine SaaS-Lizenz besorgt hat, baut sich heute mit Cursor oder Claude an einem Nachmittag eine eigene App und deployed sie auf Vercel. Die IT erfährt davon, wenn das erste Datenleck auftaucht. Genau hier entsteht eine neue Form von Shadow IT durch Vibe Coding und sie verhält sich anders als alles, was Plattform-Teams bisher kannten.

Was Vibe Coding wirklich bedeutet

Der Begriff stammt von Andrej Karpathy. Sein Punkt: Mit aktuellen Coding-Assistenten beschreibt man Software auf einer höheren Ebene und prüft am Ende vor allem das Verhalten, nicht jede Zeile Code. Man entwickelt im Flow, im Vibe, daher der Name.

In der Praxis bedeutet das: Tools wie Cursor, Claude Code, v0, Lovable, Bolt oder Replit Agents nehmen einen Prompt entgegen und liefern eine lauffähige Anwendung, oft mit Frontend, Backend, Datenbankschema und Deployment-Konfiguration. Wer ein bisschen Tech-Verständnis hat, kommt von der Idee zum laufenden Produkt in wenigen Stunden.

Das ist keine Spielerei. Produktmanager bauen Auswertungs-Tools, die das BI-Team in drei Sprints liefern würde. Marketing baut Landingpages mit Lead-Capture und Datenbank dahinter. HR baut ein kleines Onboarding-Portal. Und Entwickler in der Fachabteilung bauen ohnehin alles, was sie sonst beim Plattform-Team beantragen müssten. Wie ihr diese Citizen Developer sicher deployen lasst, statt sie auszubremsen, behandeln wir separat.

Warum daraus eine neue Klasse Shadow IT wird

Klassische Shadow IT bestand aus SaaS-Tools, die jemand mit Kreditkarte gekauft hat. Das war handhabbar: Man konnte SSO erzwingen, mit dem Anbieter einen DPA abschließen, das Tool über einen Reverse Proxy laufen lassen oder es im Notfall blockieren.

Vibe-Coding-Shadow-IT funktioniert anders. Hier gibt es keinen Anbieter, mit dem man verhandelt. Es gibt eine Anwendung, die jemand selbst geschrieben hat — auf Basis von generiertem Code, in einem GitHub-Account, der vielleicht der Firma gehört, vielleicht aber auch privat ist. Die Datenbank liegt bei Supabase oder Neon. Das Frontend läuft auf Vercel. Authentifizierung passiert über Clerk oder Auth0, häufig mit einem persönlichen Account.

Strukturell verschiebt sich damit die Verantwortung. Bei einem SaaS-Tool trägt der Anbieter einen Teil der Sicherheits- und Wartungslast. Bei einer selbst gevibten App trägt sie niemand. Der Code existiert, läuft, verarbeitet Daten, aber es gibt keinen Maintainer, kein On-Call, kein Patch-Management.

Die konkreten Risiken im Detail

Datenschutz und DSGVO

Wenn ein Mitarbeiter eine App baut, die Kundendaten verarbeitet, und diese auf einer US-Plattform hostet, sind sehr schnell mehrere DSGVO-Pflichten verletzt. Es fehlt typischerweise ein DPA mit dem Hoster, eine Aufnahme ins Verarbeitungsverzeichnis, eine Datenschutz-Folgenabschätzung und eine technische Absicherung des Datentransfers. Die Fachabteilung weiß das oft nicht und der Datenschutzbeauftragte erfährt von der Anwendung erst, wenn etwas schiefgeht.

Generierter Code macht es schlimmer. AI-Tools setzen Defaults, die in einem typischen US-Startup-Kontext sinnvoll sind: Logging zu einem externen Service, Telemetrie an OpenAI, Drittanbieter-Skripte im Frontend. In einem deutschen Mittelstand mit Auftragsdaten ist das eine Reihe an Pflichtverletzungen.

Sicherheitslücken durch ungeprüften Code

AI-generierter Code ist nicht per se schlechter als handgeschriebener, aber er wird seltener gelesen. Wer im Vibe codet, prüft das Verhalten der App, nicht die Implementierung. Genau dort sammeln sich die Probleme: hartcodierte API-Keys im Repository, fehlende Eingabevalidierung, SQL-Statements ohne Prepared Statements, CORS-Konfigurationen, die alles erlauben, JWT-Validierung, die Tokens akzeptiert, sobald sie das richtige Format haben.

Ein handgeschriebenes Beispiel kennt jeder Entwickler. Hier ein typischer Vibe-Code-Auszug für einen API-Endpoint:

app.post("/api/orders", async (req, res) => {
  const order = req.body
  await db.query(`INSERT INTO orders (data) VALUES ('${JSON.stringify(order)}')`)
  res.json({ ok: true })
})

Das läuft. Es bestellt Pizza. Es bestellt auch alles andere, was ein Angreifer in req.body schreibt, ohne Authentifizierung, mit SQL-Injection, ohne Rate Limiting. In einem Code-Review würde das niemals durchgehen. In einer Vibe-Coding-Session geht es durch, weil das Verhalten passt.

Wartung, Personenrisiko und Black Boxes

AI-generierter Code hat eine unangenehme Eigenschaft: Er funktioniert, aber niemand kann ihn schnell ändern. Wer ihn nicht selbst geprompted hat, steht vor einer Codebase ohne klare Architektur, ohne Konventionen, oft mit Bibliotheken in seltsamen Versionen, weil das Modell sie zufällig vorgeschlagen hat.

Wenn die Person, die die App gebaut hat, das Unternehmen verlässt, bleibt eine Black Box zurück. Dependency-Updates, Security-Patches, Anpassungen an neue Anforderungen all das kostet plötzlich mehr, als die App jemals an Wert gebracht hat. Im schlechtesten Fall läuft sie produktiv weiter, weil niemand sich traut, sie abzuschalten.

Lock-in bei externen Hostern

Vibe-Coding-Stacks haben einen Hang zu Plattformen, die in der Demo brillant aussehen. Vercel für Frontend und Edge Functions, Supabase für Datenbank und Auth, Resend für Mail, Upstash für Redis. Jede dieser Plattformen ist für sich gut zusammen ergeben sie einen Strauß an Anbietern, der weder konsolidiertes Logging hat noch ein gemeinsames Identity-Modell noch eine einheitliche Backup-Strategie.

Die Migration zurück in eine kontrollierte Umgebung ist dann teuer. Datenexport, Auth-Migration, Domain-Umzug, Neuaufbau der Edge-Logik. Genau diesen Schritt vermeiden Fachabteilungen, also bleiben die Apps draußen.

Warum Verbote scheitern

Die reflexhafte Antwort vieler IT-Abteilungen ist ein Verbot. Vibe Coding wird zum Policy-Thema, AI-Tools werden auf Firmenrechnern blockiert, Repositories außerhalb der Organisation verboten.

Das Problem: Verbote lösen das ursprüngliche Problem nicht. Die Fachabteilungen haben Vibe Coding nicht aus Spaß angefangen. Sie haben es angefangen, weil ihre IT-Anforderungen sonst zwei Quartale Wartezeit bedeuten. Verbietet man den schnellen Weg, ohne den langsamen Weg schneller zu machen, geht das Vibe Coding einfach in den Schatten auf Privatgeräten, in privaten GitHub-Accounts, mit Daten, die per Copy-Paste herausgetragen werden.

Die ehrlichere Diagnose lautet: Vibe Coding deckt einen echten Engpass auf. Plattform- und IT-Teams liefern Self-Service-Möglichkeiten, die langsamer und unbequemer sind als ein Prompt an Claude. Solange das so bleibt, wird der Schatten wachsen.

Die Plattform-Antwort: Self-Service mit Leitplanken

Der einzige Weg, der mittelfristig trägt, ist ein Internal Developer Platform-Ansatz, der Vibe Coding nicht verbietet, sondern in einen kontrollierten Korridor lenkt. Das Ziel ist einfach: Es muss in der eigenen Plattform genauso schnell gehen wie auf Vercel und der Standard-Pfad muss Sicherheit, Compliance und Wartbarkeit ab Werk mitbringen.

Was eine interne Entwicklerplattform leisten muss

Damit eine Plattform Vibe Coding aufnehmen kann, ohne die Vorteile zu verlieren, braucht sie ein paar Dinge wirklich gut:

• Push-to-Deploy ohne Ticket. Ein Repository pushen, automatisch bauen, automatisch deployen. Wenn das mehr als ein Klick und ein Commit kostet, geht der Entwickler zu Vercel zurück.
• Eingebaute Identität. Auth, SSO und User-Management müssen Plattform-Service sein, nicht Eigenbau. Sonst landen wieder Auth-Tokens hartcodiert in der Codebase.
• Datenbank als Service mit Backup, Verschlüsselung im Ruhezustand und Logs als Default. Niemand sollte sich entscheiden müssen, ob Backups laufen.
• Secrets-Management als Plattform-Feature, nicht als Pull-Request-Konvention. AI-Tools schreiben Secrets in .env — die Plattform muss das abfangen.
• Beobachtbarkeit ab Werk. Logs, Metriken, Traces ohne Konfiguration. Sonst entstehen Apps, die niemand debuggen kann.
• Klare Defaults für Compliance. Region, Datenresidenz, Auftragsverarbeitung — alles vorkonfiguriert, sodass eine Vibe-Coding-Session per Default DSGVO-konform deployed.

So sieht ein gesunder Workflow aus

Im Zielbild ändert sich für den vibenden Entwickler kaum etwas an der Geschwindigkeit, sehr viel aber an den Konsequenzen. Ein realistischer Ablauf:

1. Entwicklerin promptet ihre App mit Cursor oder Claude Code. Sie bekommt Frontend, Backend, Datenbankschema.
2. Statt zu Vercel zu deployen, läuft git push gegen ein internes Git, das die Plattform automatisch erkennt.
3. Die Plattform baut den Code, erkennt benötigte Komponenten eine Postgres-Datenbank, ein Object Storage und stellt sie als verwaltete Services bereit.
4. SSO wird automatisch eingebunden. Die App erbt das Identitätsmodell der Organisation; hartcodierte Auth-Tokens fliegen beim Build raus oder werden geblockt.
5. Logs, Metriken und Traces laufen automatisch in die zentrale Beobachtbarkeit. Wer die App geschrieben hat, sieht ihre Fehler. Plattform und Security sehen Anomalien.
6. Eine Policy-Engine prüft beim Deploy auf typische Vibe-Coding-Probleme: offene CORS-Header, fehlende Authentifizierung auf API-Routen, unverschlüsselte Verbindungen, ungewöhnliche externe Aufrufe.
7. Die App bekommt eine interne URL und auf Wunsch eine externe Domain. Datenresidenz und Backup laufen ohne weiteres Zutun.

Für die Entwicklerin ist das immer noch Vibe Coding. Für die IT ist es kein Schatten mehr.

Wo eine PaaS in dieses Bild passt

Genau diesen Workflow zu liefern, ist die Aufgabe einer modernen PaaS. Sie nimmt den Code, den ein AI-Tool ausspuckt, und macht daraus eine Anwendung mit Identität, Datenbank, Logs, Backups und Compliance ohne dass jemand YAML schreiben muss. Wer Vibe Coding in seiner Organisation ernst nimmt, sollte sich anschauen, wie eine solche Plattform aussieht und welche Standards sie für AI-generierten Code mitbringt. Damit verschiebt sich die Frage weg von „Wie verbieten wir das?" hin zu „Wie heben wir das, was unsere Leute ohnehin tun, auf ein tragfähiges Fundament?".

Fazit

Vibe Coding ist gekommen, um zu bleiben. Es hebelt klassische IT-Governance aus, weil es schneller ist als jeder Prozess. Wer mit Verboten antwortet, schiebt das Problem in den Schatten. Wer mit einer Plattform antwortet, die Geschwindigkeit und Standards verbindet, holt es zurück ins Licht. Die Werkzeuge dafür existieren die Frage ist nur, wer sie aufbaut, bevor die nächste vibegecodete App im Datenleck endet.