IT und Fachbereich
Vibe-Coding im Unternehmen: was die IT wissen muss
Im Vertrieb läuft eine selbst gebaute Angebotsmaske, im Einkauf ein Skript zur Rechnungsprüfung, im Marketing ein kleines Dashboard. Gebaut mit KI, ohne die IT. Verbieten hilft selten. Was die IT wissen muss und wie Regeln aussehen, die nicht bremsen.
Warum Fachbereiche selbst bauen
Die IT hat eine lange Warteschlange, der Fachbereich ein dringendes Problem. Mit Lovable, Bolt oder Replit löst ein Mitarbeiter es an zwei Nachmittagen. Das Ergebnis ist oft gut, weil es genau den Ablauf abbildet, den der Fachbereich kennt. Es ist früher Excel mit Makros gewesen, heute ist es eine Webanwendung.
Der Unterschied zu Excel: Die Webanwendung liegt im Internet, hat eine Datenbank bei einem externen Anbieter und spricht oft mit KI-Diensten. Sie ist damit Teil der IT-Landschaft, auch wenn die IT nichts von ihr weiss.
Die vier Fragen, die die IT stellen muss
Welche Daten liegen darin? Kundendaten, Personaldaten, Preise, Verträge? Davon hängt ab, wie streng alles Weitere sein muss.
Wohin fliessen sie? Zum Datenbankanbieter, zum Hosting, zu jedem eingebundenen KI-Dienst. Jeder davon ist ein Auftragsverarbeiter, für den ein Vertrag bestehen muss. Mehr im Artikel KI-generierter Code und DSGVO.
Wer hat Zugang? Hängt die Anmeldung am Firmenkonto, oder legt jeder ein eigenes Passwort an? Was passiert mit dem Zugang, wenn ein Mitarbeiter das Unternehmen verlässt?
Wer betreibt es? Wenn der Mitarbeiter, der das Tool gebaut hat, in Urlaub ist oder kündigt: Wer kennt die Zugänge, wer behebt Fehler, wer spielt Updates ein?
Typische Risiken in solchen Tools
Die technischen Lücken sind dieselben wie in jeder KI-gebauten Anwendung: offene Datenbanken, Schlüssel im Browser-Code, Rechte nur in der Oberfläche. Dazu kommen Risiken, die erst im Unternehmen entstehen: Firmendaten auf privaten Konten bei KI-Werkzeugen, Zugänge mit den Rechten des Erstellers statt eigener Dienstkonten, keine Sicherung ausser der des Anbieters. Die technischen Punkte stehen im Überblick über die häufigsten Sicherheitslücken.
Regeln, die nicht bremsen
- Eine Liste freigegebener Werkzeuge, mit Firmenkonten statt privaten Konten und geklärter Datenverarbeitung.
- Eine Meldepflicht statt Genehmigungspflicht: Wer ein Tool baut, das mehr als eine Person nutzt, trägt es in eine Liste ein, mit Zweck, Daten und Verantwortlichem.
- Eine Prüfung vor dem breiten Einsatz: Bevor ein Tool personenbezogene Daten verarbeitet oder von aussen erreichbar ist, liest jemand den Code. Das kann die eigene IT sein oder ein externes Review.
- Ein Verantwortlicher pro Tool, der Zugänge, Updates und Backups im Blick hat.
So bleibt der Vorteil erhalten, dass Fachbereiche schnell eigene Lösungen bauen, und die IT behält den Überblick.
Wenn ein Tool wichtig wird
Manche dieser Tools werden geschäftskritisch. Dann reichen eine Liste und eine einmalige Prüfung nicht mehr. Dann braucht es Tests, Quality Gates und einen geregelten Betrieb. Wann dieser Punkt erreicht ist, beschreibt der Artikel Wann ein Review reicht und wann Sie Qualitätssicherung brauchen.
Bevor Sie damit live gehen
Ihre Lösung läuft. Diese Punkte sollten Sie prüfen, bevor echte Daten daran hängen:
- Wissen Sie, welche selbst gebauten Tools in Ihrem Unternehmen laufen?
- Ist für jedes Tool geklärt, welche Daten es verarbeitet und wohin sie fliessen?
- Gibt es für jedes Tool einen Verantwortlichen, der nicht nur der Ersteller ist?
Sie wollen sicher sein? Das Vibe-Code-Review prüft genau diese Grundlagen. Mehr zum Review →
Lieber selbst anfangen? Die kostenlose Schnellprüfung aus dem Vibecode-Testing-Kit zeigt Ihnen, wo Sie stehen. Zur Schnellprüfung →
Sie wollen Qualitätssicherung im Team verankern?
Beschreiben Sie Ihr Anliegen in ein paar Sätzen. Den Rest klären wir im Gespräch.