Ein aktuelles Interview mit Ben Sufiani bringt ein Thema auf den Punkt, das viele Unternehmen derzeit beschäftigt: Sufiani kann nach eigener Aussage nicht programmieren und baut dennoch Apps, Websites und einen eigenen KI-Agenten. Er beschreibt, wie er mit Code umgeht, den er selbst nicht prüfen kann – und zieht daraus einen deutlichen Schluss: Vibe-Coder seien ein leichtes Ziel für Angreifer.

Diese Einschätzung ist weniger eine Warnung vor KI-Werkzeugen als vor einer Lücke im Vorgehen. Der Weg von der Idee zur laufenden Anwendung ist kurz geworden. Der Weg zu einem belastbaren Review, zur Absicherung und zum geregelten Betrieb ist gleich lang geblieben.

Was mit Vibe Coding gemeint ist

Vibe Coding bezeichnet eine Arbeitsweise, bei der eine Anwendung überwiegend durch Beschreibungen in natürlicher Sprache entsteht: Man formuliert, was das Programm tun soll, ein KI-Modell erzeugt den Code, und bewertet wird vor allem das sichtbare Ergebnis – funktioniert die Oberfläche, stimmt der Ablauf, sieht es gut aus.

Genau darin liegt die Verschiebung. Beurteilt wird das Verhalten der Anwendung im Normalfall. Nicht beurteilt wird, was im Fehlerfall passiert, wie Daten gespeichert werden, welche Schnittstellen offenstehen und welche Fremdbibliotheken mitgeliefert wurden. Diese Fragen entscheiden über die Sicherheit – und sie sind an der Oberfläche nicht sichtbar.

Warum fehlendes Review ein Betriebsrisiko ist

Solange ein KI-generierter Prototyp lokal läuft und mit erfundenen Daten gefüttert wird, ist der Schaden begrenzt. Problematisch wird es ab dem Moment, in dem die Anwendung öffentlich erreichbar ist, echte Kundendaten verarbeitet oder an interne Systeme angebunden wird.

Dann gelten dieselben Anforderungen wie für jede andere Software im Unternehmen: Zugriffsschutz, Protokollierung, Datenschutz, Updates. Eine Anwendung, deren Aufbau niemand im Haus erklären kann, lässt sich schlecht absichern und noch schlechter warten. Fällt etwas aus oder taucht eine Schwachstelle in einer verwendeten Komponente auf, fehlt der Ansatzpunkt für eine Reaktion.

Hinzu kommt ein organisatorischer Effekt: Lösungen, die an der IT vorbei entstehen, tauchen in keiner Inventarliste auf. Niemand weiß, welche Systeme existieren, wo sie gehostet werden und wer sie betreut, wenn die Person, die sie gebaut hat, das Unternehmen verlässt oder die Abteilung wechselt.

Die falsche Reaktion wäre ein Verbot

Fachabteilungen greifen zu KI-Werkzeugen, weil sie ein konkretes Problem schnell lösen wollen – ein internes Tool, ein Formular, eine kleine Auswertung. Dieser Impuls ist produktiv. Wer ihn pauschal untersagt, bekommt nicht weniger Schatten-IT, sondern nur eine schlechter dokumentierte.

Sinnvoller ist eine klare Trennung zwischen Experiment und Produktion. Prototypen dürfen schnell, unordentlich und KI-generiert sein. Alles, was in den Regelbetrieb geht, durchläuft denselben Weg wie jede andere Anwendung.

Ein praktikables Modell für KI-Prototypen

  • Geschützte Spielwiese: eine abgegrenzte Umgebung für Experimente, ohne Zugriff auf Produktivdaten und ohne öffentliche Erreichbarkeit.
  • Datenregel vorab: klar definieren, welche Daten überhaupt in ein KI-Werkzeug oder einen Prototyp gelangen dürfen – besonders bei personenbezogenen Daten.
  • Schwelle zur Produktion: ein festgelegter Punkt, ab dem ein technisches Review verpflichtend ist, etwa bei externem Zugriff, echten Daten oder Anbindung an Bestandssysteme.
  • Review durch Menschen mit Fachkenntnis: Durchsicht von Authentifizierung, Rechtevergabe, Eingabevalidierung, Umgang mit Zugangsdaten und eingebundenen Abhängigkeiten.
  • Automatisierte Prüfungen: Abhängigkeits- und Sicherheitsscans in der Auslieferungskette, damit bekannte Schwachstellen in Fremdkomponenten auffallen, bevor sie live gehen.
  • Inventar und Zuständigkeit: jede produktive Anwendung mit benannter verantwortlicher Person, Hosting-Ort und Update-Pfad.

Keiner dieser Punkte ist neu. Neu ist nur, dass sie jetzt auch für Anwendungen gelten müssen, die nicht aus der IT-Abteilung stammen.

Was Agenturen und IT-Dienstleister dazu beitragen

Die Rolle verschiebt sich. Früher kam der Auftrag „bauen Sie uns dieses Tool“. Heute kommt häufiger ein fertiger Prototyp mit der Frage, ob man ihn so betreiben kann. Das ist kein Rückschritt, sondern ein brauchbarer Ausgangspunkt: Der fachliche Bedarf ist bereits geklärt, die Abläufe sind durchgespielt, Missverständnisse über Anforderungen fallen weg.

Die Arbeit verlagert sich dafür auf Prüfung, Härtung und Überführung in eine wartbare Struktur. Dazu gehört oft auch die ehrliche Antwort, dass ein Neubau auf solider Basis günstiger ist als die Sanierung eines generierten Entwurfs – besonders dann, wenn die Anwendung über Jahre laufen und weiterentwickelt werden soll.

Wartbarkeit ist Teil der Sicherheit

Sicherheitslücken entstehen selten nur beim ersten Deployment. Sie entstehen über die Zeit, weil Bibliotheken veralten, Abhängigkeiten nicht mehr gepflegt werden und niemand die Updates einspielt. Eine Anwendung ohne klare Struktur, ohne Tests und ohne dokumentierte Entscheidungen lässt sich schwer aktualisieren – und bleibt deshalb unaktualisiert.

Wer KI im Entwicklungsprozess einsetzt, braucht daher nicht nur ein Review beim Start, sondern eine Zuständigkeit für den laufenden Betrieb. Das gilt für generierten Code genauso wie für handgeschriebenen.

Für Web- und Softwareprojekte heißt das: KI-Prototyping gehört in den Werkzeugkasten, weil es Ideen schnell greifbar macht und Abstimmungen verkürzt. Entscheidend ist die Linie zwischen Experiment und Produktivsystem – alles, was echte Daten verarbeitet oder öffentlich erreichbar ist, braucht Review, Härtung und eine benannte Verantwortung. Unternehmen, die diese Linie jetzt definieren, nutzen den Geschwindigkeitsgewinn, ohne das Risiko unbemerkt in den Betrieb zu verschieben.

Quellen