Vibe Coding im Konzern: Gründe ein SWAT-Team, kein Komitee

TL;DR: Vibe Coding im Konzern ist kein App-Problem, sondern ein Org-Problem. Deine Fachabteilungen bauen längst Schatten-IT mit KI — 98 % der Unternehmen haben das, und die Führungskräfte sind die Haupttreiber. Du verhinderst das nicht; du entscheidest nur, ob daraus eine gesteuerte Capability wird oder ein 670.000-Dollar-Risiko. Die organisatorische Antwort ist nicht neu: ein zentrales Vibe-Coding Competency Center, das Stack, Standards und Guardrails besitzt — als Hub, nicht als Gatekeeper — plus kleine SWAT-Teams aus drei bis fünf Leuten, die in den Fachabteilungen bauen, schnell produktiv machen und an die zentrale IT übergeben. Genau dieses Muster haben Konzerne vor zehn Jahren für Analytics und ML benutzt. Jetzt ist Vibe Coding dran.

---

Eine Zahl, die viele CIOs unangenehm trifft: 69 % der befragten Führungskräfte auf C-Level sagen, dass Geschwindigkeit wichtiger ist als Sicherheit oder Datenschutz. Nicht die Praktikanten. Nicht die „Rebellen" in der Fachabteilung. Die Leute oben.

Das ist der eigentliche Befund hinter dem ganzen Schatten-KI-Diskurs. Wir reden über nicht genehmigte Tools so, als wären sie ein Disziplinproblem an der Basis. Tatsächlich modellieren die Führungskräfte das Verhalten, das sie offiziell verbieten. Und genau deshalb ist die übliche Reaktion — eine Policy schreiben, ein Tool sperren, eine Mail mit „bitte nur freigegebene Software" verschicken — eine Antwort auf die falsche Frage.

Vibe Coding im Konzern ist kein App-Problem. Es ist ein Org-Problem. Und Org-Probleme löst man mit Organisation, nicht mit einer Richtlinie.

Schatten-KI lässt sich nicht verbieten, nur steuern

Die Verbreitung ist nicht mehr diskutabel. Branchenübergreifende Erhebungen aus 2026 zeigen: 98 % der Organisationen haben Mitarbeitende, die nicht genehmigte KI-Tools nutzen. Eine BlackFog-Studie unter 2.000 Beschäftigten (Unternehmen ab 500 Mitarbeitenden) wird konkreter: knapp die Hälfte greift regelmäßig zu Shadow-AI, und 60 % sagen offen, dass es das Sicherheitsrisiko wert sei, wenn sie damit schneller arbeiten oder eine Deadline halten. Das ist keine Randerscheinung. Das ist der Normalfall.

Nichts zu tun ist die teuerste Option. Laut IBMs Cost of a Data Breach 2025 zahlen Organisationen mit viel Schatten-KI pro Datenpanne im Schnitt rund 670.000 Dollar mehr als die mit wenig oder keiner — bei einem globalen Durchschnitt von 4,44 Millionen. Jede fünfte untersuchte Organisation hatte bereits einen Breach, der mit unkontrollierter KI zusammenhing, und 97 % der betroffenen Unternehmen hatten keine sauberen Zugriffskontrollen für KI. Das Risiko entsteht nicht durch die Nutzung, sondern durch die ungesteuerte Nutzung.

Damit ist die Entscheidung nicht „ob", sondern „mit oder ohne Governance". Du verhinderst nicht, dass deine Leute mit KI bauen. Du entscheidest nur, ob das Ergebnis ein Asset in deiner Bilanz wird oder eine Zeile im nächsten Incident-Report.

Diese Form haben wir schon einmal gelöst

Das Muster ist nicht neu. Konzerne standen schon zweimal vor genau dieser Situation: Eine neue Fähigkeit verbreitet sich bottom-up schneller, als die zentrale IT sie kontrollieren kann.

Beim ersten Mal hieß die Fähigkeit Analytics. Plötzlich saßen in jeder Fachabteilung Leute mit Excel, dann mit R und Python, und bauten Reportings und Modelle, die niemand freigegeben hatte. Beim zweiten Mal war es Machine Learning. Beide Male war die Antwort, die funktioniert hat, dieselbe: ein Competency Center. Ein zentraler Hub, der den Stack, die Standards und die Guardrails besitzt — und der die Fähigkeit in die Breite trägt, statt sie zu monopolisieren.

Ich habe einen Teil meiner Forschungsjahre damit verbracht, genau diese Gebilde auseinanderzunehmen. Für ein Paper auf der ECIS 2017 haben wir neun Analytics Competency Centers globaler Konzerne analysiert und beschrieben, wie sie Analytics-Fähigkeit über drei Hebel verbreiten: Leadership, Expertise und Infrastruktur (Schüritz, Brand, Satzger & von Bischhoffshausen, How to Cultivate Analytics Capabilities Within an Organization?). Die Erkenntnis von damals trägt auch für Vibe Coding — mit dem Unterschied, dass lauffähige Software härtere Security- und Betriebsrisiken mitbringt als ein Analytics-Report. Das Center, das gewinnt, ist trotzdem dasselbe: das, das Befähigung über Kontrolle stellt.

Das passiert gerade wieder, nur unter neuem Namen. EY hat seine GenAI-Plattform EYQ an über 300.000 Mitarbeitende ausgerollt und skaliert sie Richtung 400.000 — über 80 % der Mitarbeitenden nutzen sie, ein KI-Grundlagentraining ist Pflicht. PwC baut gemeinsam mit Google Cloud ein AI Center of Excellence für agentische KI. Die großen Beratungen verkaufen das Modell natürlich auch, weil sie daran verdienen — aber die Shadow-AI-Zahlen zeigen, dass die Bottom-up-Realität ohnehin passiert. Die Frage ist nicht, ob ein CoE entsteht. Die Frage ist, ob du es absichtlich baust oder ob es als Wildwuchs über dich kommt.

Für Vibe Coding heißt dieser Hub: Vibe-Coding Competency Center. Er besitzt die Toolchain (welche Agenten, welche Modelle, welche IDEs sind freigegeben und auf welcher Datenbasis), die Standards (wie sieht ein produktionsreifes Artefakt aus, was muss reviewt sein) und die Guardrails (Security, Datenzugriff, Compliance). Was er nicht besitzt, ist die Delivery.

Hub, nicht Gatekeeper

Wer die BI-Ära mitgemacht hat, liest „Competency Center" und denkt sofort an den Bottleneck, der Analytics damals ausgebremst hat: ein zentrales Gremium, durch das jedes Dashboard musste. Sechs Wochen Wartezeit, ein Ticket-System — und am Ende baut die Fachabteilung ihr Excel-Makro doch wieder selbst.

Der Einwand ist berechtigt — und er beschreibt präzise den Fehlermodus, den man vermeidet. Competency Center wurden bürokratisch, wenn sie zu Gatekeepern wurden, die Delivery an sich zogen. Das 2026er-Modell macht das explizit anders: Der Hub besitzt Strategie, Enablement und Governance. Die Business-Units besitzen Delivery, Budget und Outcomes. Der Hub gibt frei, was alle nutzen dürfen — er baut nicht selbst jedes Feature.

Die Daten sind eindeutig, wo der Unterschied liegt. Gartner findet, dass nur 48 % der Digital-Initiativen ihre Business-Ziele erreichen — meist wegen Silos und fehlender Abstimmung zwischen IT und Fachbereich. Die Gruppe, die Gartner „Digital Vanguards" nennt, kommt dagegen auf 71 %. Ein zentraler Unterschied: Bei den Vanguards teilen sich IT und Fachbereich die Verantwortung für die Auslieferung. Nicht „IT baut für den Fachbereich". Sondern „beide sind gleichzeitig accountable". Genau das ist die Trennlinie zwischen Hub und Gatekeeper.

Das SWAT-Team: drei bis fünf Leute, die in der Fachabteilung shippen

Wenn der Hub nicht baut — wer dann? Das ist die zweite Hälfte des Modells, und sie ist der Teil, der sich 2026 wirklich verändert hat.

Ein SWAT-Team ist eine kleine Einheit aus drei bis fünf Leuten, eingebettet in der Fachabteilung, nicht in der zentralen IT. Es nimmt die Cases, die in dieser Abteilung anfallen, priorisiert sie — zunehmend KI-gestützt nach Potenzial statt nach Bauchgefühl — und baut die Lösung dort, wo das Problem sitzt. Schnell produktiv, dann Übergabe an die zentrale IT für den Dauerbetrieb. Das Team bleibt klein und nah am Geschäft; die zentrale IT übernimmt, was Bestand haben muss.

Wer in diesen Teams sitzt, ist wichtiger als die Tools, die sie nutzen. Walmart hat dedizierte „Agent Builder"-Rollen geschaffen — und alle intern besetzt, mit technischen wie nicht-technischen Mitarbeitenden. Nicht von außen eingekauft. Von innen befördert. Die knappe Kompetenz war nicht ML-Forschung oder Prompt Engineering. Es war Domänenkontext: das operative Verständnis dafür, welcher Workflow sich zu automatisieren lohnt und woran man merkt, dass die Lösung wirklich trägt. Die Leute, die am nächsten am Problem saßen, waren die besten Builder. LinkedIn fährt mit seinem „Full Stack Builder"-Programm dieselbe Logik: Mitarbeitende — unabhängig vom Jobtitel — befähigen, mehr vom Loop allein zu spannen.

Und ja — Low-Code und „Citizen Development" haben fast dasselbe versprochen und Spielzeug geliefert: interne Tools, die bei der ersten echten Anforderung umkippten. Der Unterschied heute ist nicht die Folie, es ist der Hebel. Drei bis fünf Leute mit KI-Agenten shippen kein Klick-Dummy, sondern Produktion — was vor wenigen Jahren ein Team und ein Quartal kostete, schafft heute oft eine Person in Tagen. Aber Hebel ohne Disziplin kippt zurück ins Spielzeug. Genau das meint Vibe-coding as Leverage: nicht „die KI schreibt meinen Code", sondern Constraints, Architektur-Grenzen und Iteration als Handwerk. Steht die Governance nicht, verschiebt sich das Spielzeug-Problem nur von „funktioniert nicht" zu „funktioniert, bis es in Produktion bricht".

Die Übergabe ist der eigentliche Punkt

Das Bindeglied zwischen Hub und SWAT-Team ist die Übergabe — und sie ist kein Detail, sondern der Mechanismus, der das ganze Modell zusammenhält.

Wenn die SWAT-Teams nah am Geschäft schnell bauen und die zentrale IT übernimmt, was bleiben soll, verschiebt sich die Rolle der zentralen IT fundamental: weg von „wir bauen alles" hin zu „wir besitzen Plattform, Standards und Integration". Die zentrale IT wird vom Engpass zum Enabler. Sie schreibt nicht mehr jedes Feature; sie stellt sicher, dass die Features, die aus den Fachabteilungen kommen, sauber andocken, überwacht sind und nicht in drei Jahren zu Wartungslast werden, die niemand mehr versteht.

Dieses Splitting löst beide Fehlermodi gleichzeitig. Lässt du die Fachabteilungen ungesteuert bauen, bekommst du Schatten-Chaos: hundert kleine Apps ohne Security, ohne Owner, ohne Pfad in den Betrieb. Ziehst du alles in die zentrale IT, bekommst du den Bottleneck: 48 % Erfolgsquote und eine Roadmap, die das Geschäft nicht abbildet. Der Hub plus die SWAT-Teams plus die definierte Übergabe ist der Weg dazwischen — dezentrale Geschwindigkeit, zentrale Kohärenz.

Wo es kaputtgeht

Ich habe das Modell oft genug scheitern sehen, um die Anti-Patterns zu kennen. Vier davon kommen immer wieder.

Der Hub wird doch zum Gatekeeper. Sobald das Competency Center anfängt, Delivery an sich zu ziehen — „lass das mal lieber uns bauen" —, ist es der alte BI-Bottleneck in neuen Kleidern. Der Hub gibt frei, befähigt und überwacht. Er baut nicht.

Das SWAT-Team baut ohne Governance. Die Kehrseite. Geschwindigkeit ohne Standards erzeugt nur schneller Schulden. Gartner sagt voraus, dass über 40 % der agentischen KI-Projekte bis Ende 2027 abgebrochen werden — meist nicht wegen fehlender Modell-Fähigkeit, sondern wegen unklaren Werts und unzureichender Kontrollen. Der Engpass ist Governance, nicht Intelligenz. Genau deshalb gibt es den Hub.

MVP wird mit Produktion verwechselt. Derselbe Vibe-Coding-Workflow, der in 45 Minuten einen überzeugenden Prototyp liefert, versteckt genau das, was später bricht: Berechtigungen, Fehlerpfade, Datenqualität, Rollback. „Es funktioniert in der Demo" ist nicht „es ist sicher zu betreiben". Die Übergabe an die zentrale IT existiert genau für diese Lücke.

Und der teuerste Fehler hat mit Technik nichts zu tun: Du besetzt die SWAT-Teams von außen, statt von innen zu befördern. Die knappe Ressource ist Domänenkontext, nicht KI-Skill — den KI-Teil lernt man in Tagen, den Geschäftsteil in Jahren. Wer das Team mit externen „AI-Experten" füllt, die das Geschäft nicht kennen, baut technisch saubere Lösungen für die falschen Probleme.

Wie du anfängst

Das Modell klingt nach großem Programm, ist aber bewusst klein im Start. Du brauchst keine Reorganisation, du brauchst einen ersten Loop.

1. Ein Competency Center für die Toolchain — klein, drei bis vier Leute. Sein erster Job ist nicht Governance-Theater, sondern eine Entscheidung: Welche Tools, welche Modelle, welche Datenbasis sind freigegeben? Das allein nimmt den Großteil des Schatten-Risikos raus, weil die Leute eine legitime Alternative bekommen.

2. Ein SWAT-Team in einer Fachabteilung — die mit dem höchsten Leidensdruck und der besten Datenlage. Drei bis fünf Leute, intern, mit Domänenkontext. Nicht zehn Piloten parallel. Einer, der funktioniert.

3. Die Backlog-Priorisierung KI-gestützt — nicht das lauteste Problem zuerst, sondern das mit dem besten Verhältnis aus Wert und Baubarkeit.

4. Die Übergabe definieren, bevor das erste Feature live geht — woran erkennt die zentrale IT, dass ein Artefakt produktionsreif ist? Was muss reviewt, überwacht, dokumentiert sein? Wenn dieser Vertrag steht, skaliert das Modell. Wenn nicht, baust du Schatten-IT mit Budget.

Die ehrliche Pointe für jeden CIO, Director oder VP, der das liest: Deine Leute vibe-coden schon. Die einzige offene Frage ist, ob du es zu einer Fähigkeit machst, die du besitzt — oder zu einem Risiko, das du irgendwann bezahlst. Steuere die Schatten-IT, oder sie steuert dich.

Wie geht's weiter?

• Vibe Coding für Firmen — Wie wir Teams in zwei Tagen den Builder Loop beibringen, mit dem die SWAT-Teams arbeiten.
• Warum der Builder Loop das Fließband ablöst — Die individuelle Seite derselben Verschiebung: warum mehr Produktarbeit bei einer Person liegen kann und wo Spezialisierung weiter zählt.
• Das Vibe-Coding-Spektrum — Welche Tool-Kategorie für welches Erfahrungslevel — die Grundlage für die Toolchain-Entscheidung deines Competency Centers.