In vielen Unternehmen ist die erste Reaktion auf KI-gestützte Entwicklung eine Untersagung. Das Motiv ist berechtigt, denn die Risiken bei geistigem Eigentum, Datenschutz und Qualität sind real. Die Wirkung ist allerdings selten die beabsichtigte. Ein Verbot beendet nicht die Nutzung, sondern ihre Sichtbarkeit. Entwickler arbeiten mit privaten Zugängen weiter, Fachbereiche beschaffen Werkzeuge über die Kreditkarte, und die Organisation verliert genau die Kontrolle, die sie sichern wollte.
Warum Verbote das Risiko erhöhen
Der entscheidende Unterschied zwischen erlaubter und verbotener Nutzung liegt nicht im Umfang, sondern in der Nachvollziehbarkeit. Wird ein Werkzeug offiziell eingesetzt, laufen Verträge, Datenflüsse und Protokollierung über die Organisation. Wird es inoffiziell eingesetzt, existiert nichts davon. Im Schadensfall fehlt dann nicht nur die Absicherung, sondern auch die Fähigkeit, überhaupt zu rekonstruieren, was passiert ist. Ein Verbot verwandelt ein steuerbares Risiko in ein unsichtbares.
Hinzu kommt ein Effekt auf die Belegschaft, der oft unterschätzt wird. Entwicklerinnen und Entwickler, die produktiver arbeiten könnten, es aber nicht dürfen, treffen mittelfristig eine Entscheidung über ihren Arbeitgeber. In einem Markt, in dem Werkzeugausstattung Teil der Attraktivität ist, wirkt ein pauschales Verbot als Abwanderungsgrund. Die Kosten dieser Wirkung tauchen in keiner Risikobetrachtung auf, sind aber real.
Die vier Fragen, die geregelt sein müssen
Statt eines Verbots braucht es vier Festlegungen, die sich in wenigen Wochen treffen lassen. Erstens: Welche Modelle und Werkzeuge sind zugelassen, und unter welchem Vertrag? Entscheidend ist dabei nicht die Marke, sondern ob eine belastbare Zusage besteht, dass Eingaben nicht als Trainingsmaterial verwendet werden. Zweitens: Welche Datenklassen dürfen in Prompts erscheinen? Diese Regel muss so konkret sein, dass sie im Arbeitsalltag ohne Rückfrage anwendbar ist, sonst wird sie ignoriert.
Drittens: Welche Codeklassen erfordern welche Prüftiefe? Eine interne Auswertung und ein Zahlungsprozess brauchen nicht dieselbe Kontrolle. Viertens: Wie wird maschinell erzeugter Code gekennzeichnet und im Audit-Trail dokumentiert? Diese vierte Frage wird am häufigsten übersehen und ist bei späteren Prüfungen die teuerste Lücke, weil sich Herkunft im Nachhinein kaum noch feststellen lässt.
Prüftiefe nach Risikoklasse statt pauschaler Review-Pflicht
Eine verbreitete Übergangsregel lautet, dass jeder KI-generierte Code ein Vier-Augen-Review durchlaufen muss. Das klingt vorsichtig, hebt aber den Produktivitätsgewinn vollständig auf und erzeugt zusätzlich einen Rückstau bei den erfahrenen Entwicklern, die ohnehin der Engpass sind. Nach kurzer Zeit wird die Regel dann unterlaufen oder formal abgehakt, was schlechter ist als keine Regel, weil sie Sicherheit vortäuscht.
Tragfähig ist eine Staffelung nach Wirkung. Code ohne Zugriff auf produktive Daten und ohne Außenwirkung läuft im normalen Verfahren. Code, der personenbezogene Daten verarbeitet, Zahlungen auslöst oder Kundenschnittstellen berührt, erhält eine erweiterte Prüfung unabhängig davon, wie er entstanden ist. Diese Trennung ist nicht neu, sie existiert in den meisten Organisationen bereits für andere Zwecke und muss lediglich angewendet werden.
Verantwortung benennen
Regeln ohne benannte Verantwortung bleiben Absichtserklärungen. Für Vibe Coding braucht es drei Rollen, die nicht neu geschaffen, aber explizit zugewiesen werden müssen. Eine Person verantwortet die Werkzeugfreigabe und deren regelmäßige Überprüfung, weil sich Anbieterbedingungen ändern. Eine Person verantwortet die Datenklassifizierung und die Frage, was in Prompts erscheinen darf. Eine Person verantwortet die Prüftiefen und deren Anpassung, wenn sich die Nutzung verschiebt.
Diese Zuordnung ist der eigentliche Unterschied zwischen einer Richtlinie und einer wirksamen Regelung. Sie sorgt außerdem dafür, dass die Regeln mit der Technologie mitwachsen. Wer die Überprüfung nicht terminiert, arbeitet nach zwölf Monaten mit Vorgaben, die auf einen Markt gemünzt waren, den es so nicht mehr gibt.
Fazit und Empfehlung
Vibe Coding lässt sich nicht sinnvoll verbieten, sondern nur ungesteuert oder gesteuert betreiben. Für die nächsten neunzig Tage empfehlen wir drei Schritte. Erstens eine ehrliche Bestandsaufnahme, welche Werkzeuge bereits im Einsatz sind, ausdrücklich ohne Sanktionen, weil sonst niemand antwortet. Zweitens die vier Festlegungen zu Werkzeugen, Datenklassen, Prüftiefen und Kennzeichnung treffen und in einer Seite dokumentieren, die jeder versteht. Drittens die drei Verantwortlichkeiten benennen und einen Überprüfungstermin setzen.
ECODYNAMICS begleitet Unternehmen bei der Einführung genau dieser Guardrails. Im Rahmen von Enterprise Vibe Coding befähigen wir IT- und DevOps-Teams für den Einsatz von Claude Code, Cursor und vergleichbaren Assistenten und verbinden das mit einer Governance, die Geschwindigkeit erlaubt statt sie zu bremsen. Wenn bei Ihnen gerade über ein Verbot diskutiert wird, sprechen Sie vorher mit uns.