Die kurze Antwort
Fast ein Drittel der Organisationen — 32% — hat auf den Kauf mindestens eines Softwareprodukts oder Features verzichtet, weil es sich intern mit KI-Coding-Agenten bauen ließ, so McKinseys Bericht The State of AI in 2026 vom 25. August 2026. Am ausgeprägtesten ist die Verschiebung unter den High Performern, wo fast die Hälfte einen Kauf ablehnte. Doch dieselbe Berichterstattung nennt eine harte Wahrheit: Intern gebaute Systeme gelangen historisch nur etwa ein Drittel der Zeit zum Erfolg, gegenüber rund zwei Dritteln bei Anbietersoftware. Agentische Coding-Tools senken die Kosten der ersten Version — nicht die Kosten des Betriebs. Die Teams, die diese Verschiebung für sich nutzen, verbinden KI-Tempo mit echter Disziplin in der individuellen Softwareentwicklung.
Was die Umfrage tatsächlich sagt
McKinseys jährliche State of AI-Umfrage, in diesem Jahr mit dem Untertitel On the road to ROI, wurde vom 4. Mai bis 8. Juni 2026 durchgeführt und sammelte 1.719 Antworten aus 97 Ländern. Das Ergebnis, das die Branche aufhorchen ließ: 32% der Befragten gaben an, dass ihre Organisation gegen den Kauf eines oder mehrerer Softwareprodukte oder Features entschied, gerade weil sie die Fähigkeit intern mit agentischen Coding-Tools bauen konnte. Das ist eine strukturelle Veränderung im klassischen Build-vs-Buy-Kalkül, angetrieben von Werkzeugen, die es vor einem Jahr noch nicht in dieser Breite gab.
Der Appetit konzentriert sich unter den Gewinnern. Die rund 6% der Befragten, die McKinsey als High Performer einstuft — Organisationen, die mindestens 5% ihres EBIT der KI zuschreiben —, gehen am forschesten vor: Fast die Hälfte verzichtete auf einen Kauf, verglichen mit 31% aller anderen. Nach Branche führt die Technologie mit 41%, gefolgt von Krankenversicherern und Leistungserbringern im Gesundheitswesen mit 39% sowie professionellen Dienstleistungen und Energie mit jeweils 38%. Auch Großunternehmen lehnen sich hinein: 40% der Firmen mit über 1 Milliarde Dollar Umsatz skalieren KI-Agenten inzwischen in einer oder mehreren Funktionen, deutlich mehr als die 27% ein Jahr zuvor.
Eine Zahl, die sich nicht bewegte, sollte man im Blick behalten. Der Anteil der Organisationen, die überhaupt eine Ergebniswirkung durch KI berichten, blieb mit 37% gegenüber dem Vorjahr unverändert. Die Adoption beschleunigt sich; die gemessenen Erträge halten noch nicht Schritt. Diese Lücke ist die eigentliche Geschichte hinter der Build-vs-Buy-Frage, und sie ist der Grund, warum eine Entscheidung für die Eigenentwicklung dieselbe Sorgfalt braucht wie das Einstellen eines eigenen Entwicklungsteams — denn funktional ist genau das der Besitz von Software.
Warum der Kaufpreis die kleine Zahl ist
Der Kaufpreis eines SaaS-Produkts ist sichtbar, verhandelt und im Budget-Review leicht zu benennen. Genau deshalb ist er ein irreführender Anker. Wenn Sie auf den Kauf verzichten und stattdessen bauen, eliminieren Sie keine Kosten — Sie wandeln eine planbare Abo-Position in einen offenen Betriebskostenblock um, den Ihr eigenes Team nun trägt: Wartung, Security-Patching, Abhängigkeits-Updates, Verfügbarkeit und Bereitschaftsdienst, Infrastruktur und die fortlaufende Engineering-Zeit, um das Ganze am Leben zu halten, während sich Anforderungen und Plattformen darunter verschieben.
Die historische Basisrate ist ernüchternd. Die Berichterstattung zu den McKinsey-Ergebnissen wies darauf hin, dass intern gebaute Systeme nur etwa ein Drittel der Zeit gelangen, gegenüber rund zwei Dritteln bei Anbieterlösungen — und Gartner prognostiziert, dass bis Ende 2027 mehr als 40% der agentischen KI-Projekte abgebrochen werden, vor allem wegen eskalierender Kosten und unklaren Geschäftswerts. Rund 20% der Organisationen spüren bereits den Druck der KI-Betriebskosten. Wie McKinsey-Senior-Partner Lieven Van der Veken die zugrunde liegende Verschiebung fasste, fragen Führungskräfte zunehmend, was ihre Organisationen brauchen, um KI-Tools selbst zu bauen — doch bauen zu wollen und betreiben zu können sind zwei verschiedene Fähigkeiten.
Die praktische Lehre lautet: Betriebskosten müssen von Tag eins an eine Designvorgabe sein, keine Überraschung im zweiten Jahr. Ein Agent kann an einem Nachmittag einen funktionierenden Prototyp erzeugen; er kann diesen Prototyp nicht von selbst beobachtbar, sicher, compliant und kostengünstig im Betrieb machen. Das sind Engineering-Entscheidungen, und dort entscheiden sich die tatsächlichen Gesamtbetriebskosten.
Wann Bauen das Kaufen schlägt
Nichts davon spricht gegen das Bauen. Es spricht für bewusstes Bauen. Die Fälle, in denen eine Eigenentwicklung mit KI-Coding-Agenten wirklich gewinnt, teilen einige Merkmale: Die Fähigkeit ist ein echter Wettbewerbsvorteil statt eines Standardguts; die Anforderungen sind so spezifisch für Ihr Geschäft, dass kein Standardprodukt ohne massive Anpassung passt; die Daten oder der Workflow sind sensibel genug, dass ihr Verbleib in den eigenen Systemen strategischen Wert hat; und Sie haben — oder können aufbauen — die Engineering-Disziplin, das Ergebnis über Jahre zu betreiben, nicht nur eine Demo zu liefern.
Kaufen gewinnt weiterhin bei der großen Fläche der Standardfähigkeiten: Authentifizierung, Abrechnung, Analytics, Ticketing, generisches CRM. Ein reifer Anbieter hat die Randfälle, die Compliance-Zertifizierungen und die Wartungslast bereits absorbiert, und keine Menge an Agenten-Tempo macht deren Nachbau zu einer guten Verwendung erfahrener Engineering-Zeit. Die haltbarste Strategie 2026 ist nicht „alles jetzt bauen, weil wir es können“, sondern ein Portfolio: das Standardgut kaufen, den Differenzierer bauen und ehrlich sein, was wovon ist.
Was das für Teams in DACH und der EU bedeutet
Für Engineering-Verantwortliche in DACH und der EU rahmt der McKinsey-Befund eine vertraute Entscheidung neu, statt sie zu klären. Die erste Implikation: Build-vs-Buy ist für einen weit größeren Teil Ihres Stacks eine offene Frage als noch vor einem Jahr, weil agentische Tools die Kosten der ersten funktionierenden Version zusammengedrückt haben. Das ist eine echte Chance — und ein echter Weg, ungepflegte interne Software anzuhäufen, wenn Entscheidungen aus Begeisterung statt aus Ökonomie fallen.
Was das für den DACH-Markt bedeutet: Im deutschsprachigen Raum trifft der Build-Trend auf zwei starke Kräfte — das Bedürfnis nach digitaler Souveränität und einen Mittelstand, der Software oft als Kernprozess und nicht als Zukauf begreift. Beides macht die Eigenentwicklung attraktiv. Zugleich verschiebt sie Verantwortung: Wer intern baut, wird für DSGVO-konforme Datenverarbeitung, für die Umsetzung von NIS2 und — im FinTech-Umfeld — für BaFin-Anforderungen selbst zum Verantwortlichen. Die Orientierung an den BSI-Grundschutz-Bausteinen gehört dann in den Entwurf und nicht erst in ein Audit. Ein schneller Prototyp, der diese Prüfungen überspringt, ist keine Ersparnis, sondern eine aufgeschobene Haftung.
Die zweite Implikation ist, dass sich der Engpass verlagert hat. Wenn ein KI-Agent schnell eine plausible Implementierung liefert, ist die knappe Ressource nicht mehr, wer Code schreiben kann — es ist, wer ihn überprüfen, absichern und in Produktion verantworten kann. Teams, die die Agentennutzung skalierten, ohne die Senior-Review zu skalieren, landen am ehesten in Gartners Statistik der abgebrochenen Projekte. Die dritte Implikation betrifft die Personalaufstellung: Die Organisationen mit echter EBIT-Wirkung ersetzten Ingenieure nicht durch Agenten; sie stellten erfahrene Ingenieure an die Spitze der Agenten und behandelten Betriebskosten als erstklassiges Designziel. Das ist eine Produkt-Engineering-Kompetenz — und genau die Lücke, die die meisten internen Teams unterschätzen, wenn sie sich fürs Bauen statt Kaufen entscheiden.
Eine Build-vs-Buy-Checkliste für 2026
- Benennen Sie den Differenzierer. Wenn Kunden die Fähigkeit weder bemerken noch dafür zahlen würden, kaufen Sie im Zweifel. Reservieren Sie das Bauen für das, was Sie wirklich abhebt.
- Kalkulieren Sie den Betrieb, nicht den Build. Schätzen Sie drei Jahre Wartung, Security, Infrastruktur und Bereitschaftsdienst, bevor Sie mit einem Abo vergleichen. Die Baukosten sind die kleine Zahl.
- Prüfen Sie die Basisrate. Nehmen Sie an, dass eine Eigenentwicklung eher stockt als ein Anbieter-Rollout, und fragen Sie, was genau Ihre zur Ausnahme macht.
- Besetzen Sie für Review, nicht nur für Generierung. Jede KI-generierte Komponente braucht einen erfahrenen Ingenieur, der sie lesen, testen und verantworten kann. Budgetieren Sie diese Review-Zeit explizit.
- Machen Sie Compliance zum Gate, nicht zur Phase. Bei regulierten Daten gehören Security- und Datenschutzprüfung in den Entwurf, nicht nach den Launch. Ein schneller Build, der ein Audit nicht besteht, ist langsamer als kaufen.
- Setzen Sie ein Abbruchkriterium. Legen Sie vorab fest, wie „funktioniert nicht“ aussieht und wann Sie zu einem Anbieter wechseln würden. Sunk-Cost-Trägheit macht aus einem Build ein abgebrochenes Projekt.
- Prüfen Sie jährlich neu. Eine heute bauenswerte Fähigkeit kann nächstes Jahr ein Standardgut sein, das ein Anbieter besser löst. Behandeln Sie das Portfolio als etwas, das Sie neu ausbalancieren, nicht einmalig festlegen.
Häufig gestellte Fragen
Was hat McKinseys State of AI 2026 zu Build vs Buy ergeben?
Im McKinsey-Bericht The State of AI in 2026, veröffentlicht am 25. August 2026, gaben 32% der Befragten an, dass ihre Organisation gegen den Kauf mindestens eines Softwareprodukts oder Features entschieden hat, weil sie es intern mit agentischen Coding-Tools bauen konnte. Die Umfrage sammelte 1.719 Antworten aus 97 Ländern und wurde vom 4. Mai bis 8. Juni 2026 durchgeführt. Der Trend war am stärksten unter den High Performern — den rund 6% der Befragten, die mindestens 5% ihres EBIT der KI zuschreiben —, wo fast die Hälfte auf einen Softwarekauf verzichtete, gegenüber 31% ihrer Kollegen.
Spart interne Softwareentwicklung mit KI-Agenten wirklich Geld?
Nicht automatisch. Der vermiedene Kaufpreis ist nur der Anschaffungskostenanteil. Intern gebaute Software trägt die vollen Betriebskosten: Wartung, Security-Patching, Bereitschaftsdienst, Infrastruktur und die Engineering-Zeit, um sie aktuell zu halten. Die Berichterstattung zu den McKinsey-Daten wies darauf hin, dass intern gebaute Systeme etwa ein Drittel der Zeit gelingen, verglichen mit etwa zwei Dritteln bei Anbieterlösungen, und Gartner prognostiziert, dass bis Ende 2027 mehr als 40% der agentischen KI-Projekte wegen Kosten und unklarem Nutzen abgebrochen werden. KI-Agenten senken die Kosten der ersten Version, nicht die Kosten des Betriebs.
Welche Branchen bauen am meisten selbst statt zu kaufen?
Laut der McKinsey-Aufschlüsselung führte der Technologiesektor mit 41% der Befragten, die gegen einen Kauf entschieden, gefolgt von Krankenversicherern und Leistungserbringern im Gesundheitswesen mit 39% sowie professionellen Dienstleistungen und Energie mit 38%. Große Unternehmen mit mehr als 1 Milliarde Dollar Umsatz skalierten Agenten ebenfalls, wobei 40% sie nun in einer oder mehreren Funktionen einsetzen, gegenüber 27% im Vorjahr.
Wann sollte ein Team mit KI-Coding-Agenten bauen statt zu kaufen?
Bauen Sie, wenn die Fähigkeit ein echter Differenzierungsfaktor ist, die Anforderungen spezifisch für Ihr Geschäft sind und Sie die Engineering-Disziplin haben, das Ergebnis langfristig zu betreiben. Kaufen Sie, wenn die Fähigkeit ein Standardgut ist, ein reifer Anbieter sie bereits löst und die Zeit Ihres Teams anderswo besser eingesetzt ist. Behandeln Sie Betriebskosten von Tag eins an als Designvorgabe statt als nachträglichen Gedanken und besetzen Sie den Build mit erfahrenen Ingenieuren, die Agenten-Output überprüfen können — denn der Engpass hat sich vom Schreiben von Code hin zum sicheren Überprüfen und Warten verschoben.
Quellen
McKinsey & Company — The State of AI in 2026: On the road to ROI (veröffentlicht am 25. August 2026)
Forkast / Yahoo Finance — The Build-vs-Buy Shift: 32% of Enterprises Bet on Agentic Coding Tools (1. September 2026)