Vibe Coding ist ein Org-Problem, kein App-Problem: das Betriebsmodell im Detail

TL;DR: Der letzte Artikel hat das Prinzip gesetzt: Hub plus SWAT-Teams statt Verbot oder Freifahrtschein. Dieser Artikel ist das Betriebsmodell dahinter — im Detail. Du brauchst keine hundert vibe-gecodeten Apps, du brauchst eine schlanke Baseline für alle plus rund drei SWAT-Teams als Lernportfolio. Jede App durchläuft denselben Lebenszyklus: Intake, Build-Sprint, Readiness-Review mit einem von fünf Urteilen — und was die Review übersteht, geht mit einem Accountability-Vertrag an die IT, den die IT ablehnen darf.

---

Drei Teams governen kein Unternehmen. Das ist der Einwand, der im letzten Artikel unausgesprochen blieb, und er ist berechtigt. Wenn SWAT-Teams die Antwort auf Schatten-KI sind, wie verhindern drei bis fünf Leute pro Team, dass der Rest der Organisation trotzdem unkontrolliert weiterbaut?

Die Antwort hat zwei Hälften, und beide müssen gleichzeitig stehen.

Zwei Hälften, die nur zusammen funktionieren

Die erste Hälfte ist die Baseline für alle: die schlanke zentrale Funktion aus dem letzten Artikel, die entscheidet, welche Tools, Modelle und Datenklassen freigegeben sind, und die Identity, Logging und den Procurement-Pfad setzt. Das verkleinert die unsichtbare Angriffsfläche — aber nur, wenn der freigegebene Pfad schneller ist als der Schatten-Weg. Menschen umgehen Governance in dem Moment, in dem Governance langsamer ist als der Workaround. Genau hier setzt auch die Zahl an, auf die GitLab in seiner 2026er-Studie stößt: 92 % der Organisationen berichten von Governance-Herausforderungen bei KI-generiertem Code, und die eigentliche Arbeit hat sich von „Code schreiben" zu „Code reviewen und validieren" verschoben.

Die zweite Hälfte ist ein kleines Lernportfolio: rund drei SWAT-Teams, die echte interne Apps bauen, damit die Organisation lernt, was „produktionsreif" tatsächlich bedeutet, bevor sie die Regeln dafür aufschreibt. Die Baseline verkleinert die Angriffsfläche, die Teams erzeugen die Evidenz. Keine Hälfte wirkt allein — eine Baseline ohne Lernportfolio bleibt Theorie, ein Lernportfolio ohne Baseline ist nur kontrolliertes Schatten-IT.

Warum genau drei, nicht zehn Piloten

Ein Team gibt dir eine Fallstudie. Drei Teams geben dir Varianz. Zehn Teams geben dir Chaos, bevor dein Governance-Modell irgendetwas gelernt hat.

Drei ist das Ziel, nicht die Startlinie — eine Faustregel, kein Naturgesetz. (Wie du dorthin kommst, indem du zuerst ein einzelnes Team laufen lässt, steht weiter unten.) Jedes der drei Teams bekommt einen anderen Use-Case-Typ, damit die Lernkurve breiter wird als bei drei ähnlichen Projekten:

Team	Use-Case-Typ	Was es lehrt
Team 1	Interne Workflow-App	Prozess-Fit, Adoption, Rollen-Ownership
Team 2	Sales-/kundennaher interner Tool	Datengrenzen, Freigabe-Prozess, Business-Impact
Team 3	Reporting-/Entscheidungs-App	Datenqualität, Auditierbarkeit, Risiko-Einstufung

Konkret: Team 1 baut einen Rechnungsausnahme-Workflow für die Finanzabteilung. Team 2 baut einen Angebots-Checker für die Account-Teams. Team 3 baut ein wöchentliches Margin-Risiko-Dashboard fürs Management. Nichts davon ist am ersten Tag Kernbanking-Software — aber jedes ist real genug, um die Fragen nach Daten, Workflow, Review und Ownership tatsächlich aufzuwerfen.

Laufen alle drei über dieselbe Toolchain, denselben Review-Pfad und dieselbe Handoff-Vorlage, zeigen sich wiederverwendbare Muster. Brechen alle drei unterschiedlich — noch besser: dann weißt du genau, wo das Betriebsmodell schwach ist.

Wer im Team sitzt

Wer im Team sitzt, ist wichtiger als das Tool, das es benutzt. Ein funktionierendes SWAT-Team ist gemischt besetzt:

• Eine Produktverantwortliche, die Workflow, Abnahmekriterien und Adoptions-Signal besitzt
• Ein Domain Lead aus der Fachabteilung, der den Prozess und seine Edge Cases kennt
• Ein:e IT- oder Plattform-Engineer für Identity, Integrationen, Deployment, Monitoring
• Ein:e Security- oder Compliance-Reviewer:in, der/die Daten und Risiko früh einstuft
• Ein AI-Builder, der den Tool-Loop, Code-Review, Tests und Doku treibt

Das sind keine fünf Vollzeitstellen pro Team. Eine Person kann zwei Hüte tragen, und Security lässt sich über alle drei Teams teilen. Der Punkt ist nicht Headcount — es ist Produkt-, Domain-, IT- und Risiko-Urteil im selben Raum, während die App gebaut wird.

Die knappe Fähigkeit in diesem Team ist nicht Prompt Engineering. Es ist Domänenkontext: zu wissen, welcher Workflow sich zu automatisieren lohnt und woran man erkennt, dass die Lösung wirklich trägt. Den KI-Teil lernt man in Wochen, den Business-Teil hat man in Jahren gelernt.

Die App als Lernsonde

Nimm den Rechnungsausnahme-Workflow als Beispiel. Die Finanzabteilung will eine kleine App, die ungewöhnliche Rechnungen routet, fehlenden Kontext nachfragt und eine saubere Freigabe-Queue liefert. Klingt harmlos. Dann kommen die eigentlichen Fragen: Welche ERP-Daten darf sie lesen, wer darf was freigeben, was wird geloggt, wer antwortet, wenn sich eine Regel ändert.

Genau das soll ein SWAT-Team lernen. Jedes Projekt durchläuft denselben Lebenszyklus.

1. Intake. Start beim Business-Pain, nicht beim Tool. Der Case wird gescored nach Workflow-Pain, erwartetem Wert, Datensensibilität, Produktionskritikalität, Integrationstiefe, benanntem Business-Owner und dem Fallback, falls die App ausfällt. Die offensichtlich schlechten Kandidaten fliegen zuerst raus: regulierte Entscheidungen, sensible Kundendaten, Kerntransaktionen, sicherheitskritische Workflows — das sind keine frühen SWAT-Cases, solange die Organisation die Review-Muskeln dafür noch nicht hat.

2. Build-Sprint. Das Team baut eine lauffähige Version in kurzen Zyklen. Das Deliverable ist nicht nur die App. Das Team protokolliert auch, welche AI-Tools genutzt wurden, wo generierter Code menschliches Review brauchte, welche Abhängigkeiten reinkamen, welche Daten die App berührt, welche Tests existieren und wo Modell oder Builder eine unsichere Annahme getroffen haben. Kein Policy-Dokument — Evidenz aus echter Arbeit.

3. Readiness-Review. Jede App bekommt genau eines von fünf Urteilen.

Urteil	Bedeutung
Kill	Nützliche Lernerfahrung, aber nicht betriebswürdig
Lokal	Business-eigenes Kleintool, gedeckelt bei Nutzerzahl, Daten und Integrationen; regelmäßig geprüft; keine Erweiterung ohne IT-Freigabe
Härten	Starker Wert, braucht noch Tests, Security, Monitoring oder Architektur-Arbeit
Neu bauen	Richtiger Workflow, falscher Implementierungsweg
An IT übergeben	Wertvoll, wartbar, bereit für Produktionsverantwortung

Dieser Schritt tötet den Klassiker unter den Citizen-Development-Fehlern: Jemand baut eine nützliche App, Leute fangen an, sich darauf zu verlassen, niemand besitzt sie, und sechs Monate später ist sie business-kritische Schatten-IT.

4. Handoff. Soll eine App überleben, braucht die IT mehr als eine Demo. Das Handoff-Bundle: Repository, Architektur-Notiz, Datenfluss-Map, Abhängigkeitsliste, Secrets-Modell, Tests und bekannte Lücken, Risiko-Einstufung, Owner, Runbook, Monitoring-Bedarf, Nutzer-Feedback und das Entscheidungslog aus dem Build-Sprint. Das ist der Unterschied zwischen „cooler Prototyp" und „etwas, das die Organisation aufnehmen kann". Das Team wirft die App nicht über den Zaun. Es übergibt ein Artefakt, das die IT inspizieren, härten, betreiben oder mit Begründung ablehnen kann.

Wo es zusätzlich kaputtgeht: die Übergabe als Abladeplatz

Der letzte Artikel beschreibt vier Anti-Patterns: Der Hub wird zum Gatekeeper, das SWAT-Team baut ohne Governance, MVP wird mit Produktion verwechselt, das Team wird von außen statt von innen besetzt. Alle vier gelten unverändert. Aber die Readiness-Matrix legt einen fünften frei, den eine skeptische IT-Leitung als erstes benennen wird: Der Handoff wird zur Abladestelle.

Ein Team liefert etwas Nützliches, stempelt es „an IT übergeben", und die zentrale IT erbt eine App, die sie nie gescoped hat, ohne Budgetzeile und ohne dass jemand für den Support eingeplant ist. „Wertvoll" ist nicht dasselbe wie „jemand hat zugestimmt, das zu besitzen." Deshalb braucht der Handoff einen Accountability-Vertrag, nicht nur ein Artefakt:

• Ein benannter Production-Owner auf IT-Seite
• Eine Budgetzeile für Betrieb und Wartung
• Ein Support-Modell, das festlegt, wer antwortet, wenn es um 2 Uhr nachts kracht
• Ein Kill-Switch plus die Bedingungen, die ihn auslösen
• Und der Teil, den die meisten Programme auslassen: das explizite Recht der IT, die Produktionsverantwortung abzulehnen und die App zurück nach Härten, Lokal oder Kill zu schicken

Ein Handoff, den die IT nicht ablehnen darf, ist nur Schatten-IT mit mehr Papierkram.

Was du wirklich messen solltest

Fang nicht bei App-Anzahl, Trainings-Anzahl, Prompt-Anzahl oder Lizenz-Anzahl an. Die sind leicht zu zählen und leicht zu faken. Miss stattdessen, ob der Loop funktioniert — und wer handeln muss, wenn nicht.

Metrik	Welche Entscheidung sie informiert	Owner	Warnsignal
Tragfähige Workflows pro Quartal	Ist der Intake-Trichter gesund, oder kratzen wir am Boden?	Fachabteilung	Trichter versiegt; Teams bauen Lückenfüller
Zeit von Intake bis lauffähigem Artefakt	Ist die Toolchain wirklich schnell, oder bremst sie das Team?	SWAT-Team	Wochen statt Tage
Von der IT akzeptierte Apps nach 30 Tagen	Produzieren wir aufnahmefähige Software oder Demos?	Zentrale IT	Hohe Baurate, kaum Akzeptanz
Handoff-Lücken pro App	Welche Plattform-Standards fehlen?	Hub	Dieselbe Lücke wiederholt sich über Teams hinweg
Nutzeradoption nach 30 Tagen	Hat die App ein echtes Workflow-Problem gelöst?	Fachabteilungs-Owner	Gebaut, live, ungenutzt
Wiederverwendbare Templates	Macht der Hub aus Evidenz wiederverwendbare Standards?	Hub	Jedes Team fängt bei null an

Das Ziel ist ein wiederholbarer Pfad von Business-Pain zu lauffähiger Software zu einer Produktionsentscheidung.

Wie du den ersten Loop fährst

Der letzte Artikel hat schon die Startliste geliefert: Competency Center, ein erstes SWAT-Team, KI-gestützte Backlog-Priorisierung, die Übergabe definieren, bevor das erste Feature live geht. Die eine Ergänzung, die aus diesem Betriebsmodell folgt: Reihenfolge schlägt Parallelität.

Setz zuerst ein einzelnes Team in die Fachabteilung mit dem größten Leidensdruck und der besten Datenlage. Die Aufgabe hier ist nicht Skalierung — es ist, den kompletten Lebenszyklus einmal durchzuspielen, inklusive Handoff, und herauszufinden, wo dein Betriebsmodell leckt. Definiere den Handoff-Vertrag, bevor das erste Feature live geht: Woran erkennt die zentrale IT, dass ein Artefakt produktionsreif ist, und unter welchen Bedingungen darf sie nein sagen?

Erst wenn dieser eine Loop steht, laufen rund drei Teams parallel — für die Varianz, nicht für die Geschwindigkeit. Den Vertrag richtig hinzubekommen skaliert das Modell. Ihn falsch hinzubekommen finanziert nur die Wildwucherung, statt sie zu steuern.

Die ehrliche Pointe bleibt dieselbe wie im letzten Artikel: Deine Leute vibe-coden schon. Die einzige offene Frage ist, ob daraus eine Fähigkeit wird, die du besitzt, oder ein Preis, den du irgendwann zahlst.

Wie geht's weiter?

• Vibe Coding im Konzern: Gründe ein SWAT-Team, kein Komitee — Das Grundprinzip: Hub statt Gatekeeper, SWAT-Team statt Komitee, und warum sich diese Form aus der Analytics- und ML-Ära bereits einmal bewährt hat.
• Vibe Coding für Firmen — Wie wir Teams in zwei Tagen den Builder Loop beibringen, mit dem SWAT-Teams arbeiten.
• Vier Wege, wie Organisationen mit Vibe Coding umgehen — Vier Operating Models für unterschiedliche Risikozonen, wenn der SWAT-Team-Ansatz nicht überall gleich passt.

Quellen

• BlackFog, 2026 — 86 % wöchentliche KI-Nutzung, 49 % nicht genehmigte KI-Nutzung, 60 % nehmen das Sicherheitsrisiko für eine Deadline in Kauf, 69 % der C-Level-Führungskräfte priorisieren Geschwindigkeit über Sicherheit/Datenschutz (Sapio-Umfrage unter 2.000 Beschäftigten in Unternehmen ab 500 Mitarbeitenden, November 2025).
• GitLab, 2026 — 92 % der Organisationen berichten von Governance-Herausforderungen bei KI-generiertem Code; Review/Validierung ist der neue Engpass.
• Gartner, 2025 — über 40 % der agentischen KI-Projekte werden bis Ende 2027 abgebrochen, wegen steigender Kosten, unklarem Geschäftswert oder unzureichenden Risikokontrollen.
• Schüritz, Brand, Satzger & Kunze von Bischhoffshausen, ECIS 2017 — How to Cultivate Analytics Capabilities Within an Organization?