Vibe Coding im Unternehmen: Wenn aus einem Prototypen Schatten-IT wird
Die neue Schatten-IT wird nicht installiert. Sie wird gepromptet. Mit KI-Baukästen und Coding-Assistenten können Beschäftigte innerhalb weniger Stunden eigene Anwendungen, Datenbanken und Automatisierungen erstellen. Das eröffnet Unternehmen neue Möglichkeiten. Es verkürzt aber nicht automatisch den Weg zu einer sicheren, datenschutzgerechten und dauerhaft betreibbaren Lösung.
Kritisch wird Vibe Coding deshalb nicht schon beim Experimentieren. Kritisch wird es, wenn ein funktionierender Prototyp unbemerkt in den betrieblichen Alltag hineinwächst: mit echten Kunden- oder Mitarbeiterdaten, externen Schnittstellen, Benutzerkonten und einer Aufgabe, von der plötzlich ein Geschäftsprozess abhängt. ( Weiterlesen: Wann Vibe Coding zur Schatten-IT wird und welche Leitplanken KMU benötigen )
➨ Unsere Einordnung: Nicht der schnelle Bau ist das Problem, sondern der ungeregelte Betrieb
Vibe Coding demokratisiert Softwareentwicklung. Menschen mit tiefem Prozesswissen können Ideen umsetzen, ohne zuerst ein klassisches Entwicklungsprojekt aufsetzen zu müssen. Für kleine und mittelständische Unternehmen kann das ein erheblicher Innovationsschub sein.
Die entscheidende Grenze verläuft jedoch nicht zwischen professionellen Entwicklern und fachlichen Anwendern. Sie verläuft zwischen einem begrenzten Experiment und einem System, das reale Daten verarbeitet, Entscheidungen vorbereitet oder Teil eines betrieblichen Ablaufs wird.
Deshalb lautet die zentrale Prüffrage nicht: „Wer hat diese Anwendung programmiert?“ Sondern: „Ist sie für ihren tatsächlichen Einsatz technisch, organisatorisch und datenschutzbezogen beherrscht?“
Die App, von der im Unternehmen niemand wusste
Am Montagmorgen zeigt ein Mitarbeiter aus dem Vertrieb eine neue Anwendung. Sie ordnet Kundenanfragen, erstellt aus Stichpunkten einen Angebotsentwurf und überträgt ausgewählte Angaben automatisch in eine Tabelle. Entwickelt wurde sie am Wochenende mit einem KI-gestützten App-Baukasten.
Die Anwendung funktioniert. Niemand musste dafür ein Budget beantragen, einen Entwicklungsauftrag vergeben oder ein monatelanges IT-Projekt starten. Genau deshalb wird sie sofort verwendet.
Erst später entstehen Fragen:
➨ Wo werden die eingegebenen Kundendaten gespeichert?
➨ Wer kann auf die Datenbank zugreifen?
➨ Welche externen Dienste und Schnittstellen sind eingebunden?
➨ Wo liegen API-Schlüssel, Passwörter und Zugangstoken?
➨ Wer spielt Sicherheitsupdates ein?
➨ Was geschieht, wenn der Ersteller das Unternehmen verlässt?
➨ Kann der Prozess weiterlaufen, wenn die Plattform ausfällt?
Diese Fragen machen aus einer guten Idee noch kein schlechtes Projekt. Sie zeigen aber, dass eine funktionierende Oberfläche nur einen kleinen Teil einer betrieblich einsetzbaren Anwendung darstellt.
Früher bestand Schatten-IT häufig aus privaten Cloud-Speichern, nicht freigegebenen SaaS-Diensten, Excel-Makros oder einer Access-Datenbank unter dem Schreibtisch. Heute kann ein Fachbereich zusätzlich eigene Webanwendungen mit Datenbank, Benutzerverwaltung, KI-Funktionen und öffentlich erreichbaren Schnittstellen erstellen.
Was Vibe Coding im Unternehmensalltag verändert
Beim Vibe Coding beschreibt ein Nutzer in natürlicher Sprache, welche Anwendung entstehen soll. Ein KI-System erzeugt daraus Programmcode, Benutzeroberflächen, Datenstrukturen und teilweise bereits eine veröffentlichbare Anwendung. Änderungen werden nicht ausschließlich durch klassische Programmierung vorgenommen, sondern häufig durch weitere Anweisungen im Dialog.
Der Begriff umfasst dabei unterschiedliche Arbeitsweisen: von KI-Unterstützung in einer professionellen Entwicklungsumgebung bis zu Plattformen, auf denen Menschen ohne klassische Programmierausbildung komplette Anwendungen zusammenstellen und bereitstellen.
Nicht jede mit KI entwickelte Anwendung ist zugleich eine „KI-App“. Eine Anwendung kann vollständig konventionelle Funktionen erfüllen und lediglich mithilfe generativer KI erstellt worden sein. Umgekehrt kann eine professionell entwickelte Anwendung KI-Funktionen enthalten, ohne durch Vibe Coding entstanden zu sein.
Für Unternehmen ist diese begriffliche Trennung wichtig. Entscheidend sind nicht das Etikett oder das verwendete Werkzeug, sondern die tatsächlichen Datenflüsse, Funktionen, Abhängigkeiten und Auswirkungen auf den Betrieb.
Vibe Coding verändert vor allem drei Engpässe:
➨ Ideen lassen sich wesentlich schneller erproben
Fachkundige Mitarbeiter können ihr Prozesswissen unmittelbar in einen Prototypen übersetzen, statt Anforderungen erst über mehrere Rollen weiterzugeben.
➨ Die Schwelle zur Veröffentlichung sinkt
Hosting, Datenbank, Anmeldung und externe Schnittstellen können Bestandteil derselben Plattform sein. Zwischen „gebaut“ und „online“ liegt dann mitunter nur noch ein Klick.
➨ Die Verantwortung verlagert sich
Wenn der technische Bau einfacher wird, gewinnen Architektur, Datenkontrolle, Rechte, Prüfung, Wartung und Betriebsverantwortung an Bedeutung.
Was aktuelle Plattform- und Sicherheitsdaten tatsächlich zeigen
Die öffentliche Diskussion über Vibe Coding wird derzeit von eindrucksvollen Zahlen geprägt. Sie belegen, wie schnell sich die Softwareerstellung verändert. Sie müssen aber methodisch sauber eingeordnet werden.
➨ Lovable: eine Million neue Projekte pro Woche
Der Plattformanbieter Lovable berichtet in seiner Studie „The Build Economy 2026“ von insgesamt 50 Millionen erstellten Projekten und rund einer Million neuen Projekten pro Woche. Vier von fünf befragten Nutzern ordnen sich nach Angaben des Unternehmens einem nichttechnischen beruflichen Hintergrund zu. Lediglich 5,8 Prozent nennen Engineering als ihre primäre Rolle.
Die zugrunde liegenden Erkenntnisse stammen aus anonymisierten Plattformdaten von Januar 2025 bis Mai 2026 sowie aus einer Befragung von mehr als 14.300 Nutzern.
Diese Zahlen zeigen die Größenordnung der Entwicklung. Sie bedeuten jedoch nicht, dass jede Woche eine Million fertige, öffentlich erreichbare Produktivsysteme entstehen. Ein „Projekt“ kann ebenso ein Entwurf, eine Testanwendung, eine Website, ein abgebrochener Versuch oder ein intern genutztes Werkzeug sein. Zudem handelt es sich um Angaben des Plattformanbieters selbst.
➨ Escape: mehr als 5.600 öffentlich erreichbare Anwendungen untersucht
Das Sicherheitsunternehmen Escape untersuchte im Herbst 2025 mehr als 5.600 öffentlich verfügbare Anwendungen, die mit Vibe-Coding-Plattformen erstellt worden waren. Die Forscher meldeten mehr als 2.000 als besonders relevant eingestufte Schwachstellen, über 400 offengelegte Secrets und 175 Funde personenbezogener Informationen.
Die Untersuchung ist ein ernst zu nehmendes Warnsignal. Sie ist aber keine repräsentative Messung sämtlicher Vibe-Coding-Anwendungen. Die Apps wurden unter anderem über öffentliche Verzeichnisse, Suchdienste, Community-Beiträge und typische Plattform-Domains gefunden. Öffentlich beworbene oder leicht auffindbare Anwendungen waren dadurch zwangsläufig stärker vertreten. Ein Teil der automatisierten Ergebnisse wurde manuell überprüft, jedoch nicht jede Anwendung vollständig wie in einem individuellen Penetrationstest.
➨ Veracode: unsichere Ergebnisse in sicherheitsrelevanten Aufgaben
Veracode testete für den GenAI Code Security Report 2025 mehr als 100 Sprachmodelle mit 80 gezielt konstruierten Programmieraufgaben in Java, Python, C# und JavaScript. Untersucht wurden unter anderem SQL Injection, Cross-Site Scripting, Log Injection und unsichere kryptografische Verfahren.
In 45 Prozent der bewerteten Fälle erzeugten die Modelle eine Variante, die den Sicherheitstest nicht bestand. Diese Zahl lässt sich nicht pauschal auf 45 Prozent jedes beliebigen KI-generierten Codes übertragen. Sie zeigt aber: Ein Ergebnis kann syntaktisch korrekt sein, die gewünschte Funktion erfüllen und trotzdem eine bekannte Schwachstelle enthalten.
Nicht jede selbst entwickelte Anwendung ist Schatten-IT
Eine Fachabteilung darf Ideen entwickeln. Ein Mitarbeiter darf einen Prototypen bauen. Und ein Unternehmen kann Citizen Development, No-Code, Low-Code oder Vibe Coding gezielt als Innovationsinstrument einsetzen.
Entscheidend ist, ob die Anwendung innerhalb eines geklärten Rahmens entsteht und betrieben wird.
Eine selbst entwickelte Anwendung wird zur Schatten-IT, wenn sie außerhalb der vorgesehenen Verantwortungs-, Freigabe- und Betriebsprozesse eingesetzt wird. Typische Merkmale sind:
➨ Die Anwendung ist nicht inventarisiert
Geschäftsführung, IT, Datenschutz oder Informationssicherheit wissen nicht, dass das System existiert oder wofür es verwendet wird.
➨ Es gibt keinen benannten Verantwortlichen
Niemand trägt verbindlich die fachliche, technische und organisatorische Verantwortung über die Experimentierphase hinaus.
➨ Echte Daten werden ohne Freigabe verarbeitet
Kunden-, Beschäftigten-, Lieferanten- oder Unternehmensdaten gelangen in eine Plattform, deren Datenverarbeitung und Vertragslage nicht geprüft wurden.
➨ Zugriffe und Schnittstellen bleiben unklar
Rollen, Berechtigungen, Freigabelinks, Datenbankregeln oder API-Verbindungen wurden nicht systematisch bewertet.
➨ Der Betrieb hängt an einer einzelnen Person
Nur der Ersteller kennt Aufbau, Konten, Zugangsdaten, Prompts, Datenmodell und Wiederherstellungswege.
➨ Es existiert kein geregelter Lebenszyklus
Updates, Monitoring, Datensicherung, Fehlerbehandlung, Dokumentation, Ãœbergabe und Abschaltung sind nicht vorgesehen.
Schatten-IT beginnt nicht mit dem Bau einer Anwendung. Sie beginnt mit ihrem ungeregelten Betrieb.
Diese Unterscheidung ist wichtig, weil ein pauschales Urteil die eigentliche organisatorische Aufgabe verdeckt. Das Problem ist nicht, dass Mitarbeiter Ideen umsetzen. Das Problem ist, wenn das Unternehmen nicht erkennt, wann aus einer Idee ein zu verantwortendes System geworden ist.
Der unsichtbare Ãœbergang vom Prototyp zum Produktivsystem
In klassischen IT-Projekten gibt es zumindest formal getrennte Phasen: Anforderung, Entwicklung, Test, Abnahme, Veröffentlichung und Betrieb.
Beim Vibe Coding kann diese Grenze verschwimmen. Ein typischer Verlauf sieht anders aus:
➨ 1. Eine Person löst ein eigenes Arbeitsproblem
Zunächst wird mit Testdaten eine kleine Anwendung für eine begrenzte Aufgabe gebaut.
➨ 2. Kollegen erkennen den Nutzen
Aus einem persönlichen Werkzeug wird ein Hilfsmittel für ein Team.
➨ 3. Echte Daten werden eingetragen
Der Prototyp verarbeitet plötzlich reale Kunden-, Projekt- oder Beschäftigtendaten.
➨ 4. Schnittstellen werden ergänzt
E-Mail, Tabellen, Datenbanken, CRM, Zahlungsdienste oder KI-Modelle werden angebunden.
➨ 5. Der Arbeitsablauf richtet sich nach der Anwendung
Mitarbeiter erwarten, dass Daten verfügbar sind, Erinnerungen ausgelöst oder Vorgänge korrekt verarbeitet werden.
➨ 6. Der Prototyp ist produktiv, ohne je abgenommen worden zu sein
Niemand hat bewusst beschlossen, daraus ein Produktivsystem zu machen. Im betrieblichen Alltag ist es dennoch eines geworden.
Das Risiko entsteht gerade deshalb, weil die Anwendung funktioniert. Ein offensichtlicher Fehlschlag würde beendet. Ein nützlicher Prototyp wird dagegen weitergereicht, erweitert und mit immer wichtigeren Aufgaben betraut.
Den technischen Unterschied zwischen einem schnellen Prototypen und einem belastbaren Produktivsystem haben wir bereits in einem eigenen Praxisbeitrag eingeordnet: Vibe Coding vs. Produktivsystem: ein anonymisierter Praxisblick .
Fünf Risikofelder, die KMU prüfen sollten
Bei selbst entwickelten Anwendungen wird häufig zuerst nach einer technischen Schwachstelle gefragt. Das ist notwendig, greift aber zu kurz. Unternehmen müssen mehrere Ebenen gemeinsam betrachten.
➨ 1. Daten und Datenschutz
Welche personenbezogenen, vertraulichen oder geschäftskritischen Informationen verarbeitet die Anwendung? Wo werden sie gespeichert? Welche Anbieter, Unterauftragnehmer und KI-Dienste erhalten Zugriff? Werden Daten zu Trainings-, Analyse- oder Supportzwecken weiterverwendet?
Zusätzlich ist zu klären, ob der ursprüngliche Zweck der Anwendung mit dem tatsächlichen Einsatz noch übereinstimmt. Ein Werkzeug, das mit Testdaten begonnen hat, kann durch reale Kunden- oder Beschäftigtendaten eine völlig andere Risikoklasse erreichen.
➨ 2. Identitäten, Rollen und Berechtigungen
Eine sichtbare Anmeldung beweist noch keine sichere Zugriffskontrolle. Entscheidend ist, ob Berechtigungen auch im Backend, in Datenbankregeln und an Schnittstellen durchgesetzt werden.
Unternehmen sollten prüfen: Wer darf welche Datensätze sehen, verändern, exportieren oder löschen? Wie werden neue Nutzer angelegt? Was geschieht beim Rollenwechsel oder beim Ausscheiden eines Mitarbeiters? Existieren öffentlich erreichbare Freigabelinks oder Standardkonten?
➨ 3. Secrets, Schnittstellen und Abhängigkeiten
API-Schlüssel, Zugangstoken, Datenbankverbindungen und Webhooks verbinden eine Anwendung mit weiteren Systemen. Werden solche Secrets im Frontend, im Quelltext oder in öffentlich erreichbaren Konfigurationsdateien abgelegt, können Unbefugte sie auslesen und missbrauchen.
Ebenso wichtig ist die Frage, welche Rechte eine Schnittstelle besitzt. Ein Token, das nur einen einzelnen Datensatz lesen müsste, darf nicht automatisch Schreib- oder Administrationsrechte für das gesamte System erhalten.
➨ 4. Betrieb, Wartung und Wiederherstellung
Software bleibt nach ihrer Veröffentlichung nicht unverändert. Abhängigkeiten erhalten Updates, Plattformen ändern Funktionen, Schnittstellen werden angepasst und Sicherheitslücken werden bekannt.
Deshalb benötigt auch eine kleine Anwendung Antworten auf:
Wer überwacht Fehler und Ausfälle?
Wer bewertet und installiert Updates?
Welche Daten werden gesichert?
Wie wird eine Wiederherstellung getestet?
Welche Protokolle stehen für die Fehlersuche zur Verfügung?
Was geschieht bei einem Sicherheits- oder Datenschutzvorfall?
➨ 5. Verantwortlichkeit, Dokumentation und Ausstieg
Ein Unternehmen muss nachvollziehen können, wofür die Anwendung eingesetzt wird, wer Entscheidungen über Änderungen trifft und wie sie übernommen werden kann.
Dazu gehören mindestens eine verständliche Funktionsbeschreibung, die eingesetzten Plattformen und Konten, relevante Datenflüsse, Rollen, Schnittstellen, Abhängigkeiten und ein Weg, die Daten kontrolliert zu exportieren oder die Anwendung abzuschalten.
Eine vertiefte Einordnung speziell für Anwendungen mit Kunden- und personenbezogenen Daten finden Sie in unserem Beitrag KI-App mit Kundendaten: Datenschutz und Sicherheit richtig planen .
Warum ein Sicherheitsscan allein nicht genügt
Automatisierte Scans sind wertvoll. Sie können bekannte Schwachstellen, unsichere Konfigurationen, offengelegte Secrets oder veraltete Komponenten sichtbar machen. Sie sind ein wichtiger Teil einer technischen Prüfung.
Sie beantworten aber nicht alle Fragen, die für einen betrieblichen Einsatz entscheidend sind.
➨ Ein Scanner kennt den fachlichen Zweck nicht
Er kann nicht beurteilen, ob eine Anwendung mehr Daten verarbeitet, als für ihre Aufgabe erforderlich sind.
➨ Ein Scanner ersetzt kein Berechtigungskonzept
Technisch funktionierende Rollen können fachlich dennoch falsch zugeschnitten sein.
➨ Ein Scanner klärt keine Verträge und Verantwortlichkeiten
Er zeigt nicht, ob Auftragsverarbeitung, Unterauftragnehmer, Speicherorte oder interne Freigaben ausreichend geklärt wurden.
➨ Ein Scanner schafft keine Wartbarkeit
Auch eine zum Prüfzeitpunkt fehlerfreie Anwendung kann ohne Updates, Monitoring, Backup und dokumentierte Zuständigkeit schnell zum Betriebsrisiko werden.
➨ Ein Scanner beurteilt keine Prozessfolgen
Er erkennt nicht, ob ein Fehler nur einen Entwurf betrifft oder Bestellungen, Zahlungen, Personalentscheidungen oder Kundenkommunikation beeinflusst.
Die angemessene Prüftiefe hängt deshalb vom tatsächlichen Einsatz ab. Eine kleine interne Testanwendung mit künstlichen Daten benötigt einen anderen Rahmen als ein öffentliches Kundenportal, eine Personal-Anwendung oder ein System, das eigenständig Aktionen in Drittsystemen ausführt.
Technische Funktionsfähigkeit ist nicht gleich betriebliche Einsatzfähigkeit.
Unternehmen brauchen Leitplanken statt pauschaler Verbote
Ein vollständiges Verbot von Vibe Coding klingt zunächst einfach. In der Praxis kann es jedoch dazu führen, dass sinnvolle Experimente noch weiter aus dem Blickfeld der Verantwortlichen verschwinden.
Mitarbeiter bauen solche Werkzeuge meist nicht, um Regeln zu umgehen. Sie tun es, weil sie einen konkreten Engpass kennen und heute erstmals selbst eine Lösung erproben können.
Unternehmen sollten diesen Impuls nicht ersticken, sondern in einen sichtbaren und sicheren Handlungsraum überführen. Dazu gehören:
➨ Eine einfache Melde- und Anlaufstelle
Beschäftigte sollten wissen, wo sie eine Idee, einen Prototypen oder eine bereits genutzte Anwendung ohne unnötige Hürden melden können.
➨ Klare Regeln für Experimente
Testdaten, erlaubte Plattformen, öffentliche Veröffentlichung, Schnittstellen und der Einsatz realer Daten müssen verständlich geregelt sein.
➨ Risikobasierte Prüfungen
Nicht jede kleine Anwendung benötigt denselben Aufwand. Je sensibler die Daten, je größer der Nutzerkreis und je wichtiger der Prozess, desto tiefer muss geprüft werden.
➨ Einen benannten menschlichen Eigentümer
Jede Anwendung benötigt eine Person, die fachlich versteht, wofür sie eingesetzt wird, und Verantwortung für Änderungen und Betrieb übernimmt.
➨ Einen geregelten Weg in den Produktivbetrieb
Ein erfolgreicher Prototyp darf weiterentwickelt werden. Vor dem produktiven Einsatz benötigt er jedoch eine bewusste Entscheidung, Prüfung und Übergabe.
➨ Einen geregelten Weg zur Abschaltung
Nicht jeder Prototyp muss dauerhaft bestehen. Datenexport, Löschung, Kontenschließung und Entfernung von Zugängen sollten ebenso vorgesehen sein wie die Freigabe.
Auch OWASP empfiehlt für KI-generierten Code eine klar zugeordnete menschliche Verantwortung, unabhängige Code-Prüfung, Sicherheitstests und die Einbindung in einen geregelten Software-Lebenszyklus. Der Satz „Die KI hat es geschrieben“ ersetzt weder fachliche Verantwortung noch sichere Entwicklungs- und Betriebsprozesse.
Drei Stufen vom Experiment zum geregelten Betrieb
Ein praxistauglicher Rahmen muss für KMU verständlich und handhabbar bleiben. Statt eines überladenen Freigabeprozesses bietet sich ein dreistufiges Modell an.
➨ Stufe 1: Experiment
Ziel: Eine Idee schnell prüfen, ohne ein betriebliches Risiko aufzubauen.
Geeigneter Rahmen:
nur künstliche oder ausdrücklich freigegebene Testdaten,
keine vertraulichen Informationen,
keine Verbindung zu Produktivsystemen,
keine öffentliche Veröffentlichung,
klar begrenzter Zeitraum,
dokumentierte Plattform und verantwortliche Person.
Ergebnis: Das Unternehmen entscheidet, ob die Idee beendet, weiter erprobt oder in einen kontrollierten Prototypen überführt wird.
➨ Stufe 2: Interner Prototyp
Ziel: Den Nutzen mit einem begrenzten Nutzerkreis und kontrollierten Daten testen.
Zusätzlicher Rahmen:
benannter fachlicher Eigentümer,
dokumentierte Datenflüsse und Schnittstellen,
festgelegter Nutzerkreis,
erste Bewertung von Datenschutz und Informationssicherheit,
grundlegende Rollen und Berechtigungen,
Protokollierung wichtiger Vorgänge,
festgelegte Erfolgskriterien und Abbruchbedingungen.
Ergebnis: Der Prototyp liefert nicht nur eine überzeugende Demonstration, sondern belastbare Erkenntnisse zu Nutzen, Fehlern, Daten, Aufwand und Risiken.
➨ Stufe 3: Produktiver Einsatz
Ziel: Die Anwendung als verlässlichen Bestandteil eines betrieblichen Prozesses betreiben.
Notwendiger Rahmen:
bewusste Freigabe,
technische Sicherheitsprüfung,
geprüftes Rollen- und Berechtigungskonzept,
geklärte Verträge und Datenverarbeitung,
Schutz von Secrets und Schnittstellen,
Datensicherung und Wiederherstellung,
Monitoring und Fehlerbehandlung,
Update- und Wartungsverantwortung,
Dokumentation und Vertretungsregelung,
geregelter Export und Abschaltung.
Ergebnis: Aus einem schnellen Prototypen wird eine bewusst verantwortete Unternehmensanwendung.
Der Vibe-Coding- und Schatten-IT-Check für KMU
Bevor ein Unternehmen neue Regeln formuliert, sollte es zunächst wissen, welche selbst entwickelten Anwendungen und KI-gestützten Automatisierungen bereits existieren.
Eine solche Bestandsaufnahme sollte nicht als Fahndung nach Regelverstößen gestaltet werden. Sonst bleiben genau jene Anwendungen unsichtbar, die bewertet werden müssen. Sinnvoller ist die Botschaft:
Gute Ideen sind willkommen. Sobald eine Anwendung echte Daten oder Prozesse berührt, helfen wir dabei, sie verantwortbar weiterzuentwickeln.
Für eine erste Einordnung genügen zehn strukturierte Fragen:
➨ 1. Welches konkrete Problem löst die Anwendung?
Ist der Nutzen nachvollziehbar, und gehört die Anwendung bereits zu einem wiederkehrenden Arbeitsablauf?
➨ 2. Wer ist fachlich und technisch verantwortlich?
Gibt es einen benannten Eigentümer, einen Ansprechpartner und eine Vertretung?
➨ 3. Wer verwendet die Anwendung?
Handelt es sich um einen persönlichen Test, ein Teamwerkzeug, eine unternehmensweite Anwendung oder einen öffentlich erreichbaren Dienst?
➨ 4. Welche Daten werden verarbeitet?
Werden Testdaten, personenbezogene Informationen, vertrauliche Dokumente, Geschäftsgeheimnisse oder Zahlungsdaten verwendet?
➨ 5. Wo befinden sich Daten und Systeme?
Welche Plattform, Datenbank, Hosting-Umgebung und Unterauftragnehmer sind beteiligt?
➨ 6. Welche Rollen und Zugriffswege existieren?
Sind Anmeldung, Freigabelinks, Administratorrechte, Datenbankregeln und Austrittsprozesse geklärt?
➨ 7. Welche Schnittstellen und Secrets werden verwendet?
Welche APIs, Webhooks, Schlüssel, Tokens und externen Systeme sind angebunden?
➨ 8. Wie wurde die Anwendung geprüft?
Gab es Code-Review, Sicherheitsscan, Berechtigungstests, Datenschutzbewertung und fachliche Abnahmetests?
➨ 9. Wie wird der Betrieb sichergestellt?
Sind Updates, Monitoring, Backup, Wiederherstellung, Support und Vorfallbehandlung geregelt?
➨ 10. Wie kann die Anwendung übernommen oder beendet werden?
Sind Dokumentation, Datenexport, Konten, Abhängigkeiten und Abschaltung nachvollziehbar?
Aus den Antworten lässt sich eine erste Risikoklasse ableiten:
Niedriges Risiko:
begrenzter Test,
künstliche Daten,
keine Schnittstellen,
keine betriebliche Abhängigkeit.
Mittleres Risiko:
interner Nutzerkreis,
reale Daten,
wiederkehrender Prozess,
begrenzte externe Dienste.
Hohes Risiko:
sensible Daten,
öffentliche Erreichbarkeit,
Kunden- oder Beschäftigtenzugang,
Zahlungsfunktionen,
umfangreiche Berechtigungen
oder geschäftskritische Automatisierung.
Diese Einstufung ersetzt keine tiefergehende technische oder datenschutzrechtliche Prüfung. Sie hilft aber, die richtigen Anwendungen zuerst zu betrachten und den Aufwand risikobasiert zu planen.
Einordnung aus der Praxis der Internetagentur Scherer
Die Internetagentur Scherer begleitet Unternehmen seit 1998 bei digitalen Projekten, individueller Webentwicklung, technischer Infrastruktur, Datenschutz und der Einführung KI-gestützter Anwendungen.
Vibe Coding bestätigt eine Entwicklung, die wir in vielen Digitalprojekten seit Jahren beobachten: Der technische Bau einer ersten Lösung ist nur ein Teil der Aufgabe. Entscheidend ist, ob Technik, Daten, Prozesse, Rechte, Verträge und Betriebsverantwortung zusammenpassen.
Mit generativer KI wird der erste Teil wesentlich schneller. Dadurch verschwinden die übrigen Aufgaben nicht. Sie werden sichtbarer, weil Prototypen früher einen Reifegrad erreichen, der bereits wie ein fertiges System wirkt.
Unser Ansatz besteht deshalb nicht darin, Vibe Coding grundsätzlich abzulehnen. Wir unterscheiden vielmehr zwischen:
einem sinnvollen Experiment,
einem fachlich wertvollen Prototypen,
einer technisch zu überführenden Anwendung,
und einem dauerhaft verantwortbaren Produktivsystem.
Ein strukturierter Vibe-Coding- und Schatten-IT-Check kann für KMU ein pragmatischer Einstieg sein. Dabei werden vorhandene Anwendungen und Automatisierungen erfasst, nach Risiko priorisiert und hinsichtlich Daten, Zugängen, Schnittstellen, Verantwortlichkeit und Betriebsfähigkeit eingeordnet.
Abhängig vom Ergebnis kann der nächste Schritt unterschiedlich aussehen:
eine klare Begrenzung als Experiment,
eine technische Nachbesserung,
eine Überführung auf geeignete Infrastruktur,
eine Datenschutz- und Berechtigungsprüfung,
eine dokumentierte Freigabe,
oder die kontrollierte Abschaltung einer nicht tragfähigen Anwendung.
Größere KI- und Automatisierungsvorhaben ordnen wir zusätzlich im Rahmen von Digitaler Strategie & KI ein. Für Datenverarbeitung, Verträge, Verantwortlichkeiten und organisatorische Schutzmaßnahmen ergänzt sich dieser Ansatz mit Datenschutz & Compliance .
Fazit: Vibe Coding beschleunigt Entwicklung, nicht Verantwortung
Vibe Coding eröffnet Fachabteilungen, Gründern und mittelständischen Unternehmen einen neuen Zugang zur Softwareentwicklung. Menschen, die einen betrieblichen Prozess genau kennen, können ihre Idee schneller sichtbar und testbar machen.
Das ist kein vorübergehender Nebentrend. Wenn Plattformen von Millionen neuer Projekte berichten und Menschen ohne klassische Entwicklerrolle vollständige Anwendungen erstellen, verändert sich die betriebliche Realität.
Unternehmen sollten darauf weder mit blinder Begeisterung noch mit pauschalem Verbot reagieren. Sie benötigen einen Rahmen, der Experimente ermöglicht und den Übergang zum Produktivbetrieb bewusst macht.
Die entscheidende Frage lautet nicht:
Dürfen unsere Mitarbeiter selbst Anwendungen bauen?
Die bessere Frage lautet:
Wer diese Grenze sichtbar macht, muss Innovation nicht abbremsen. Im Gegenteil: Gute Ideen können schneller erprobt und erfolgreiche Prototypen gezielter in belastbare Systeme überführt werden.
Vibe Coding beschleunigt die Entwicklung. Verantwortung lässt sich nicht automatisieren.
Quellen und weiterführende Informationen
Lovable: The Build Economy – A Data Study by Lovable, 2026
Lovable: A first look at the build economy
Escape: The State of Security of Vibe-Coded Applications
Escape: Methodology – How we discovered vulnerabilities in apps built with Vibe Coding
Veracode: Insights from the 2025 GenAI Code Security Report
OWASP Top 10:2025 – Inappropriate Trust in AI Generated Code („Vibe Coding“)
OWASP Cheat Sheet Series: Secure Coding with AI
OWASP Citizen Development Top 10 Security Risks
Hinweis: Die genannten Plattform- und Sicherheitsberichte verwenden unterschiedliche Datenquellen und Methoden. Lovable wertet eigene Plattformaktivitäten und Nutzerbefragungen aus. Escape untersuchte eine gezielt aufgefundene Auswahl öffentlich erreichbarer Anwendungen. Veracode nutzte kontrollierte Programmieraufgaben zur Prüfung ausgewählter Schwachstellenklassen. Die Ergebnisse sind wichtige Warnsignale, aber keine repräsentative Fehlerquote für sämtliche Vibe-Coding-Anwendungen.
FAQ: Vibe Coding, Schatten-IT und sichere Anwendungen im Unternehmen
Was bedeutet Vibe Coding?
Vibe Coding bezeichnet eine Arbeitsweise, bei der Nutzer einer generativen KI in natürlicher Sprache beschreiben, welche Software oder Funktion entstehen soll. Die KI erzeugt oder verändert daraufhin Programmcode, Benutzeroberflächen, Datenstrukturen und teilweise vollständige Anwendungen. Der Begriff reicht von KI-unterstützter professioneller Entwicklung bis zum Bau kompletter Apps durch Menschen ohne klassische Programmierausbildung.
Ist jede mit KI erstellte Anwendung automatisch Schatten-IT?
Nein. Eine selbst entwickelte Anwendung ist nicht automatisch Schatten-IT. Kritisch wird sie, wenn sie ohne Kenntnis, Freigabe oder geregelte Verantwortung im betrieblichen Alltag eingesetzt wird. Entscheidend sind der tatsächliche Nutzerkreis, die verarbeiteten Daten, die angebundenen Systeme und die Bedeutung für den Geschäftsprozess.
Was ist der Unterschied zwischen Vibe Coding, No-Code und Citizen Development?
No-Code und Low-Code stellen überwiegend visuelle Bausteine für Anwendungen und Prozesse bereit. Citizen Development beschreibt, dass Fachanwender außerhalb klassischer IT-Abteilungen selbst digitale Lösungen entwickeln. Vibe Coding ergänzt oder verändert diesen Ansatz, weil generative KI Programmcode, Datenmodelle und technische Funktionen aus natürlichsprachlichen Anweisungen erzeugen kann. In der Praxis überschneiden sich die Begriffe.
Wann wird ein Vibe-Coding-Prototyp zum Produktivsystem?
Nicht die offizielle Bezeichnung ist entscheidend. Ein Prototyp wird faktisch zum Produktivsystem, sobald reale Nutzer, personenbezogene oder vertrauliche Daten oder ein wiederkehrender Geschäftsprozess verlässlich von ihm abhängen. Spätestens dann benötigt er eine bewusste Freigabe, technische Prüfung, geklärte Verantwortung und ein Betriebskonzept.
Dürfen Mitarbeiter in Vibe-Coding-Tools echte Unternehmensdaten verwenden?
Das sollte nur innerhalb eines ausdrücklich geklärten Rahmens geschehen. Vorher müssen unter anderem Zweck, Datenarten, Plattform, Speicherorte, Zugriffsrechte, Verträge, Unterauftragnehmer und technische Schutzmaßnahmen bewertet werden. Für erste Experimente sind künstliche oder freigegebene Testdaten der deutlich sicherere Ausgangspunkt.
Reicht der integrierte Sicherheitsscan einer Plattform aus?
Nein. Ein automatisierter Scan kann bekannte technische Schwachstellen, unsichere Konfigurationen oder offengelegte Secrets erkennen. Er ersetzt aber kein fachliches Berechtigungskonzept, keine Datenschutzbewertung, keine Vertragsprüfung, keine Betriebsplanung und keine unabhängige menschliche Verantwortung.
Sollten Unternehmen Vibe Coding grundsätzlich verbieten?
Ein pauschales Verbot kann bei besonders sensiblen Einsatzfeldern oder ungeeigneten Plattformen notwendig sein. Als alleinige Strategie reicht es jedoch selten aus. Sinnvoller sind sichtbare Experimentierräume, klare Datenregeln, einfache Meldewege, risikobasierte Prüfungen und ein geregelter Übergang vom Prototyp zum Produktivsystem.
Welche Anwendungen sollten Unternehmen zuerst prüfen?
Vorrang haben öffentlich erreichbare Anwendungen, Systeme mit Kunden- oder Beschäftigtendaten, Anwendungen mit Zahlungsfunktionen, umfangreichen Schnittstellen, weitreichenden Zugriffsrechten oder einer hohen Bedeutung für den Geschäftsbetrieb. Kleine Tests mit künstlichen Daten und ohne Produktivanbindung besitzen in der Regel eine niedrigere Priorität.
Was umfasst ein Vibe-Coding- und Schatten-IT-Check?
Ein erster Check erfasst vorhandene Anwendungen, ihren Zweck, Nutzerkreis, Daten, Plattformen, Konten, Schnittstellen, Berechtigungen und Verantwortlichen. Anschließend werden Risiken priorisiert und nächste Schritte festgelegt: begrenzen, technisch nachbessern, kontrolliert überführen, dokumentiert freigeben oder sicher abschalten.
Wie unterstützt die Internetagentur Scherer bei selbst entwickelten Anwendungen?
Wir unterstützen bei der Bestandsaufnahme und Risikoeinordnung, bei Datenflüssen, Rollen- und Berechtigungskonzepten, technischer Architektur, Hosting, Schnittstellen, Datenschutz und der Überführung eines geeigneten Prototypen in einen verlässlich betriebenen Prozess. Dabei wird transparent unterschieden, ob eine organisatorische Bewertung, technische Weiterentwicklung oder eine vertiefte Sicherheitsprüfung erforderlich ist.