Begeisterung garantiert, Governance leider nicht: Was durch Vibe Coding auf Unternehmen zukommt

Früher brauchte man für neue Unternehmenssoftware ein Projekt, ein Budget und Geduld. Heute reichen manchmal ein guter Prompt, ein freier Abend und ein Fachbereich, der sagt: „Sieht doch schon fast fertig aus.“

Genau darin liegt die eigentliche Veränderung. Das Grundproblem ist nicht neu: Mitarbeiter konnten schon immer Software entwickeln, privat entstandene Lösungen mitbringen oder Fremdsoftware einkaufen. Neu ist durch Vibe Coding nicht die Existenz des Problems, sondern seine Dynamik, weil generative KI die Hürde zwischen Idee, Prototyp und nutzbarer Anwendung massiv senkt.


Dadurch wird aus einzelnen Sonderfällen ein dauerhafter Zufluss von Software aus sehr unterschiedlichen Quellen. Viele Unternehmen steuern Software aber noch immer so, als entstünde sie langsam, sichtbar und fast nur in formalen Projektstrukturen, obwohl KI‑gestützte Entwicklung in der Praxis oft schneller wächst als Governance und Transparenz.

Genau deshalb sollte man Vibe Coding nicht als einheitliches Phänomen behandeln. Für Unternehmen sind mindestens drei Blickrichtungen relevant, und jede stellt eine andere Managementfrage.

Erstens: intern entstandene Software

Wenn Mitarbeiter mit KI auf Unternehmenshardware, mit Unternehmenskonten und innerhalb der eigenen Infrastruktur Anwendungen bauen, wirkt das zunächst wie der einfachste Fall. Tatsächlich ist es vor allem ein Zulassungsproblem: Anwendungen entstehen schneller außerhalb klassischer Projektstrukturen, als Sicherheitsprüfung, Architekturvorgaben und Betriebsverantwortung nachziehen.

Die falsche Reaktion wäre ein pauschales Verbot. Die zweitfalsche wäre das klassische „Wir beobachten das erstmal“. Sinnvoller ist ein interner Zulassungsweg nach dem Prinzip eines App Stores: klare Einreichungsregeln, Pflichtangaben, automatisierte Prüfungen, definierte Freigabestufen und ein isolierter Betrieb für alles, was noch nicht in den Kernbetrieb gehört. Apples App‑Review‑Modell folgt genau dieser Logik aus Regeln, Metadaten, Review und zentral durchgesetzten Qualitätsanforderungen.

Beispiel: Ein Mitarbeiter im Controlling baut mit KI ein kleines Tool, das Monatsberichte konsolidiert, Excel‑Dateien verarbeitet und automatisch E‑Mails mit Berichten verschickt. Fachlich ist das stark, technisch aber in dem Moment keine harmlose Spielerei mehr, in dem personenbezogene Daten verarbeitet werden, Berechtigungen relevant werden und das Tool produktionsnah arbeitet. Dann braucht es nicht nur Applaus, sondern einen klaren Pfad in Richtung Governance und Betrieb.

Zweitens: privat entstandene Software

Heikler wird es, wenn Mitarbeiter in ihrer Freizeit auf eigener Hardware und mit selbst gebuchten KI‑Diensten etwas entwickeln und diese Lösung später in das Unternehmen einbringen wollen. Dann reicht eine technische Qualitätsprüfung gerade nicht mehr aus, weil zuerst geklärt werden muss, wem die Software rechtlich zuzurechnen ist, welche Nutzungsrechte bestehen, welche Drittkomponenten eingeflossen sind und unter welchen Bedingungen eine Übernahme überhaupt möglich ist.

Gerade bei Computerprogrammen ist das keine Nebensache. § 69b UrhG knüpft die vermögensrechtlichen Befugnisse des Arbeitgebers daran, dass ein Programm in Wahrnehmung der Aufgaben des Arbeitnehmers oder nach Anweisung des Arbeitgebers geschaffen wurde; bei Freizeitsoftware ist diese Zuordnung also nicht automatisch gegeben.

Und selbst wenn die Rechtefrage lösbar ist, bleibt die betriebliche Realität: Wer wartet die Anwendung, wer dokumentiert sie, wer übernimmt die Verantwortung, wenn der ursprüngliche Entwickler das Unternehmen verlässt oder seine Tool‑Ketten nicht mehr verfügbar sind? Eine Anwendung ist im Unternehmen nicht deshalb wertvoll, weil sie einmal funktioniert. Wertvoll ist sie dann, wenn sie auch ohne ihren Erfinder weiterbetrieben werden kann.

Beispiel: Ein privat entwickelter Assistent für Angebotsprüfungen beeindruckt in der Demo und löst sofort Interesse aus. Drei Wochen später stellt sich heraus, dass Teile des Stacks über private Accounts laufen, die Dokumentation dünn ist und niemand sauber sagen kann, welche Komponenten unter welchen Bedingungen verwendet wurden. Dann wird sehr schnell klar: Man übernimmt nicht nur Code, sondern auch Herkunft, Risiken und künftige Abhängigkeiten.

Drittens: fremde Software, bei der Vibe Coding im Ergebnis nicht mehr erkennbar ist

Am schwierigsten zu steuern ist oft nicht die interne oder private Lösung, sondern Fremdsoftware. Weil KI‑gestützte Entwicklung zunehmend in normale Entwicklungsprozesse einfließt, verliert die Frage „Wurde das per Vibe Coding erstellt?“ für Unternehmen an praktischer Aussagekraft, wenn der Anbieter keine belastbaren Nachweise zu Sicherheit, Berechtigungen, Abhängigkeiten, Review‑Prozessen, Geheimnisschutz und Wartbarkeit liefert.

Für die Unternehmenspraxis zählt deshalb nicht die Herkunftserzählung, sondern die Qualität der Nachweise. Unternehmen sollten Fremdsoftware nicht danach bewerten, ob sie klassisch entwickelt aussieht, sondern danach, ob sie sich technisch, organisatorisch und regulatorisch verantwortbar betreiben lässt. Sicherheitsorientierte Empfehlungen für Vibe‑Coding‑Umfelder betonen Human‑in‑the‑Loop‑Reviews, Secrets‑Scanning, Abhängigkeitsanalysen, restriktive Berechtigungen und kontrollierte Ausführung statt blindem Vertrauen in KI‑generierten Code.

Mit anderen Worten: Fremdsoftware wird nicht dadurch vertrauenswürdig, dass sie modern aussieht, einen guten Vertrieb hat und im Pitch dreimal das Wort Governance fällt. Wenn Vibe Coding im Ergebnis nicht mehr sichtbar ist, müssen Prüfpfade auch ohne romantische Entstehungsgeschichte funktionieren.

Governance über die drei Richtungen hinweg

Die Management‑Botschaft ist deshalb relativ simpel: Vibe Coding erfindet das Risiko nicht neu. Es vervielfacht nur Tempo, Reichweite und Unschärfe, mit der Software in das Unternehmen gelangt.

Unternehmen brauchen darum keine Grundsatzdebatte darüber, ob Vibe Coding gut oder schlecht ist. Sie brauchen drei saubere Governance‑Pfade: einen für intern entstandene Software, einen für privat entstandene Software und einen für Fremdsoftware, deren Entstehungsweg nur begrenzt sichtbar ist.

Wer diese Unterscheidung nicht trifft, bekommt entweder Schatten‑IT mit guter Laune oder Freigabeprozesse, die auf Probleme von gestern optimiert sind. Wer sie trifft, schafft etwas viel Wertvolleres: einen Rahmen, in dem Innovation nicht geduldet, sondern verantwortbar gemacht wird.

Vibe Coding ist kein neues Werkzeugproblem. Es ist ein Reifegradtest für die Steuerungsfähigkeit von Unternehmen.



Quellen

- Palo Alto Networks Unit 42 – „Securing Vibe Coding Tools: Scaling Productivity Without Scaling Risk“: https://unit42.paloaltonetworks.com/securing-vibe-coding-tools/

- IAPP – „Vibe coding: Don’t kill the vibe, govern it“: https://iapp.org/news/a/vibe-coding-don-t-kill-the-vibe-govern-it

- Google Cloud – „Vibe Coding Explained: Tools and Guides“: https://cloud.google.com/discover/what-is-vibe-coding

- Google Cloud Blog – „How vibe coding can help leaders move faster“: https://cloud.google.com/transform/how-vibe-coding-can-help-leaders-move-faster

- Databricks – „Passing the Security Vibe Check: The Dangers of Vibe Coding“: https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding

- IT‑Recht Kanzlei – „Problem § 69b UrhG – Vom Arbeitnehmer erstellte Software in der Freizeit“: https://www.it-recht-kanzlei.de/20050909_Problem_69b_UrhG-Vom_Arbeitnehmer_erstellte_Software_in_der_Freizeit-_.html

- Apple Developer – „App Review Guidelines“: https://developer.apple.com/app-store/review/guidelines/


Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Vom Feuerwerk zum Kater - Warum KI-Entwicklung oft wie Silvester endet

Bild
Erinnern Sie sich noch an Silvester als Kind? Die Ungeduld, bis es endlich dunkel wurde. Die Faszination, als die ersten Raketen in den Himmel schossen. Als Jugendlicher fühlte man sich mächtig, wenn es überall krachte und blitzte – alles war schnell, laut und spektakulär. Doch je erwachsener wir wurden, desto nüchterner wurde der Blick. Und nicht selten wachte man am Neujahrsmorgen mit einem ordentlichen Kater auf, rieb sich die Augen und stand vor einem Berg aus Aufräumarbeiten. Genau dieses Bild ging mir durch den Kopf, als ich mir das Ergebnis eines kleinen, privaten Projekts anschaute. In der ruhigen Zeit zwischen den Feiertagen habe ich eine App entwickelt, mit dem Ziel, maximal viele Aufgaben an die KI zu delegieren. Ich wollte gezielt selber erfahren, was es bedeutet, möglichst viele Aufgaben an die künstliche Intelligenz zu übertragen. Phase 1: Das Feuerwerk Als ich mit der Entwicklung meiner App begann, war da wieder diese kindliche Begeisterung. Die KI zündete ein Feuerwerk ...
Mehr anzeigen

Wenn KI Antworten liefert, müssen wir lernen, besser zu fragen

Bild
In der Schule fragen Schüler: „Kommt das in der Prüfung dran?“ und Mitarbeiter sitzen im Meeting und fragen: „Wer muss das freigeben?“ Zwischen diesen beiden Sätzen liegen vielleicht zehn Jahre. Das Problem dabei: Es ist oft dasselbe. Wir bilden noch immer Menschen für eine Welt aus, in der die richtige Antwort wichtiger ist als die richtige Frage. Und wir bauen noch immer Unternehmen, in denen Anpassung an Prozesse oft höher bewertet wird als Urteilsfähigkeit. Genau das wird uns in der KI-Ära auf die Füße fallen. Wir diskutieren über Künstliche Intelligenz meist so, als ginge es vor allem um neue Tools, neue Berufe und neue Effizienzpotenziale. Das greift zu kurz. KI verändert nicht nur Arbeit, sondern auch die viel grundlegendere Frage, wie Menschen künftig überhaupt lernen sollen. In der Schule, im Studium, in der Ausbildung und später im Unternehmen. Warum das alte Lernmodell an Grenzen stößt Denn ein Bildungssystem, das stark auf Frontalunterricht, Reproduktion und das möglichst f...
Mehr anzeigen

Vom Mensch zum Mitspieler

Bild
Kürzlich las ich ein Buch, in dem in einer Szene beschrieben wurde, wie der niederländische Schachmeister Jan Hein Donner am 04. März 1982 gefragt wurde, was er tun würde, wenn er gegen einen Schachcomputer antreten müsste. Seine Antwort:  "Ich würde einen Hammer mitbringen." Eine herrlich menschliche Reaktion, die mich schmunzeln ließ und zu folgender Überlegung führte: Auf die heutige Wirtschaft übertragen, muss die Antwort anders lauten. Unternehmen können ihre neuen, KI-getriebenen Wettbewerber nicht einfach mit einem Hammer zerschlagen. Wenn die Konkurrenz eine Maschine nutzt, bleibt nur eine logische Antwort: Man bringt selbst eine mit. Es war einmal einfach: Wir entwickelten Dinge für Menschen. Daten sollten verständlich, Prozesse nutzbar, Schnittstellen intuitiv sein. Dann kam die KI. Und plötzlich sitzt ein neuer Kollege am Tisch, der weder Kaffeepausen noch Schulungen braucht. Das Paradoxe daran: Wir reden viel darüber, wie wir Menschen mit der KI interagieren solle...
Mehr anzeigen