Vibe Coding für Unternehmen: sicher vom KI-Prototyp zur Firmen-App

«Vibe Coding» heisst: Man beschreibt einer KI in normaler Sprache, was eine Anwendung tun soll, und sie schreibt den Code. Werkzeuge wie Lovable, v0, Bolt oder Claude Code liefern innert Stunden etwas, das man anklicken kann. Laut einer Auswertung von Google-Suchdaten wird in keinem Land pro Kopf so viel nach dem Begriff gesucht wie in der Schweiz.

Für Unternehmen ist das mehr als ein Trend. Zum ersten Mal können die Leute, die einen Ablauf am besten kennen, selbst das Werkzeug dafür bauen: die Disponentin ihr Planungs-Tool, der Verkaufsleiter seinen Offerten-Rechner, die Qualitätsverantwortliche ihre Prüfprotokolle. Kein Pflichtenheft, kein «das haben wir anders gemeint», keine Monate Wartezeit.

Das ist eine gute Entwicklung. Wir sind überzeugt, dass Software am besten passt, wenn sie nah am Betrieb entsteht. Die Frage ist nur, was nach dem ersten funktionierenden Bildschirm passiert.

Ein KI-Prototyp zeigt, dass eine Idee funktioniert. Er zeigt nicht, dass sie sicher, stabil und wartbar funktioniert. Die KI baut, was man ihr beschreibt. Was man nicht beschreibt, fehlt meistens: ein sauberes Rechtekonzept, geschützte Zugangsdaten, Backups, Updates, Protokolle, ein Plan für den Fall, dass etwas schiefgeht.

Die Zahlen dazu sind deutlich. Bei einer Untersuchung von 1'645 Lovable-Apps hatten 170 ihre Datenbank nicht gegen fremde Zugriffe geschützt; Namen, E-Mail-Adressen und API-Schlüssel lagen offen. Im Februar 2026 wurde eine einzelne Lovable-App mit 16 Sicherheitslücken bekannt, über die Daten von mehr als 18'000 Personen einsehbar waren. Und laut dem Veracode-Report 2026 besteht KI-generierter Code eine Sicherheitsprüfung im Schnitt nur in 56 Prozent der Fälle — kaum besser als im Vorjahr.

Das spricht nicht gegen KI-Werkzeuge. Es spricht dagegen, einen Prototyp ungeprüft mit echten Kunden- und Geschäftsdaten zu füllen. Die Plattformen sagen es selbst: Für die Sicherheit der App ist, wer sie baut, verantwortlich.

Erstens: Wer darf was sehen? Jede Firmen-App braucht Rollen und Rechte, die auf dem Server durchgesetzt werden — nicht nur im Browser. Ein Login-Fenster allein schützt keine Daten.

Zweitens: Wo laufen die Anwendung und ihre Daten? Auf der Plattform, auf der der Prototyp entstanden ist, oder bei einem Hosting-Partner, den Sie selbst gewählt haben und auf dessen Konto Sie Zugriff haben?

Drittens: Was passiert, wenn etwas schiefgeht? Gibt es tägliche Backups, und wurde schon einmal ausprobiert, ob sich daraus etwas wiederherstellen lässt? Gibt es eine Test-Umgebung, in der Änderungen geprüft werden, bevor sie live gehen?

Viertens: Wer hält die Anwendung aktuell? Jede App stützt sich auf Dutzende fremde Bausteine, und für diese erscheinen laufend Sicherheits-Updates. Ohne jemanden, der sie einspielt, wird eine sichere App mit der Zeit unsicher.

Fünftens: Wer versteht den Code in einem Jahr? Wenn die Person, die ihn mit der KI gebaut hat, die Firma verlässt oder keine Zeit mehr hat, muss jemand anderes übernehmen können. Das setzt eine nachvollziehbare Struktur voraus, ein Code-Repository mit Historie und Reviews, die das Wissen teilen.

Viele Unternehmen fragen zuerst, ob die KI beim Entwickeln ihre Daten sieht. Bei sauberem Vorgehen tut sie das nicht: Gebaut und getestet wird mit Test- und Beispieldaten, die Entwicklungsumgebung hat keinen Zugriff auf das Live-System. Echte Kunden- und Geschäftsdaten kommen beim Entwickeln gar nicht vor.

Entscheidend für das Datenschutzgesetz sind zwei andere Fragen. Wo läuft das Live-System, und wo liegen die Daten und die Backups? Und: Nutzt die fertige Anwendung selbst KI, etwa zum Zusammenfassen von Dokumenten oder zum Klassieren von Anfragen? Dann fliessen dort echte Daten, und es zählt, wo dieses Modell betrieben wird. Für beides gibt es heute gute Antworten in der Schweiz und in der EU: Hosting-Partner mit Rechenzentren hier, und leistungsfähige KI-Modelle, die in der Schweiz oder in der EU laufen.

Wichtig ist, dass jemand diese Fragen für jede Komponente beantwortet und festhält — bevor die App live geht, nicht danach. Ein pauschales «DSG-konform» auf einer Plattform ersetzt das nicht.

Der erste Weg: Der Prototyp dient als Anschauungsmaterial, und ein Entwicklungspartner baut die Anwendung sauber neu. Das ist richtig, wenn die Anwendung geschäftskritisch und komplex wird oder wenn im Haus niemand Zeit hat, weiterzubauen. Der Prototyp ist dann nicht verloren — er ist die beste Spezifikation, die es gibt.

Der zweite Weg: Der Prototyp wird gehärtet. Eine erfahrene Person prüft Architektur, Sicherheit und Datenschutz, schliesst die Lücken, holt den Code in ein eigenes Repository und bringt die Anwendung auf eine Infrastruktur, die Ihnen gehört. Das lohnt sich, wenn die Grundstruktur trägt.

Der dritte Weg: Ihre Fachleute bauen weiter — aber mit Leitplanken. Sie entwickeln in einer gemeinsamen Umgebung, jede Änderung wird geprüft, bevor sie live geht, und jemand kümmert sich um Server, Updates, Backups und Monitoring. So bleiben Tempo und Fachwissen im Haus, und das Ergebnis hält trotzdem.

Welcher Weg passt, hängt weniger von der Technik ab als von der Frage, wie viel Ihre Leute selbst gestalten wollen.

Für den dritten Weg haben wir die ZNIPP Werkbank aufgebaut. Ihre Fachleute bauen mit Claude Code in einer Entwicklungsumgebung im Browser, und wir arbeiten im selben Projekt mit. Jede Änderung landet in Ihrem privaten GitLab, wir prüfen sie auf Architektur, Sicherheit und Datenschutz, Sie nehmen sie in der Test-Umgebung ab und geben sie für Live frei.

Das Live-System läuft auf Ihrem eigenen Konto bei einem Schweizer oder europäischen Hosting-Partner, zum Beispiel Hosttech, Infomaniak oder Hetzner. Wir hosten nicht selbst, sondern warten die Applikationsserver, spielen Updates ein, sichern täglich und behalten das Monitoring im Blick. Code, Daten und Zugänge gehören Ihnen — von Tag eins.

Und wenn schon ein Prototyp existiert, beginnen wir mit einem Werkbank-Check: Wir sagen Ihnen ehrlich, ob er sich härten lässt oder ob ein Neuaufbau der bessere Weg ist.