Zweiunddreissig Prozent der Organisationen haben mindestens einmal darauf verzichtet, ein Softwareprodukt oder eine Funktion zu kaufen, weil sie sich mit agentischen Coding-Tools intern bauen liess. Bei den High Performern ist es fast die Hälfte, gegenüber 31 Prozent bei allen anderen. Die Zahlen stammen aus McKinseys State-of-AI-Umfrage, veröffentlicht am 25. August 2026 [1] , mit 1'719 Befragten in 97 Ländern, erhoben zwischen dem 4. Mai und dem 8. Juni. Die meiste Aufmerksamkeit galt der flachen EBIT-Linie daneben. Spannender ist dieser Befund, denn er beschreibt einen Make-or-Buy-Entscheid, der sich verschoben hat, ohne dass jemand die Verschiebung beschlossen hätte.
Make-or-Buy war früher einer der am stärksten geregelten Entscheide in einem Unternehmen. Software zu kaufen bedeutet Beschaffung, Sicherheitsprüfung, Rechtsabteilung, eine Budgetposition, eine verantwortliche Person, ein Verlängerungsdatum und eine Ausstiegsoption. Das ist der Mechanismus, mit dem eine Organisation bewusst entscheidet, was sie über die nächsten Jahre zu tragen bereit ist, und weit mehr als Bürokratie um ihrer selbst willen.
Dieselbe Funktion mit einem Coding-Agenten zu bauen, durchläuft nichts davon. Es passiert innerhalb eines Sprints und innerhalb eines bestehenden Teambudgets, oft ohne dass jemand ausserhalb des Teams davon weiss. Die Einsparung landet in den Zahlen dieses Jahres. Die Verpflichtung landet in den drei Jahren danach, meist auf dem Tisch von jemand anderem.
Ich will klar sagen, wo ich stehe, denn das lässt sich leicht missverstehen. Der Eigenbau an sich ist in Ordnung. Für Abläufe, die Sie im Markt tatsächlich differenzieren, ist Bauen oft die richtige Antwort, und dass es heute auch für Teams machbar ist, die das früher nie gekonnt hätten, ist echter Fortschritt. Das Problem ist, dass der Entscheid seinen Ort verloren hat. In Die KI-Transformation mieten habe ich über Organisationen geschrieben, die ihre KI-Transformation bei den Laboren mieten. Das hier ist dieselbe Frage vom anderen Ende her gestellt, mit derselben Form: Die Fähigkeiten kommen schneller an als die Strukturen, die sie steuern sollen.
Am Willen hat es nie gefehlt
Die Futurum Group befragte im Januar 2026 830 IT-Entscheider und veröffentlichte die Ergebnisse im Juni [2] . Die Präferenz für den Eigenbau lag bei 56,0 Prozent, praktisch unverändert gegenüber 56,6 Prozent sechs Monate zuvor. Unternehmen wollten schon immer selbst bauen. Neu ist, dass sie es jetzt können, und nicht nur in der IT. In derselben Umfrage geben 53,3 Prozent der Organisationen an, dass zwischen 20 und 40 Prozent ihrer Mitarbeitenden ausserhalb der IT bereits Low-Code-, No-Code- oder Sprachwerkzeuge nutzen, um Anwendungen zu erstellen oder zu ändern. Weitere 22,3 Prozent beziffern diesen Anteil auf 40 bis 60 Prozent. Welche Kontrollfunktion die IT bei dieser Frage früher auch hatte, sie liegt nicht mehr bei der IT.
Keith Kirkpatrick, der die Studie leitete, benannte, was Anbieter von Unternehmenssoftware tatsächlich verkaufen, und genau dieser Teil verschwindet still aus dem Business Case. Er verortet ihre «compounding advantages» an vier Stellen: Abläufe, die über Organisationsgrenzen hinweg reichen, der Lebenszyklus der Softwarewartung, eigens gebaute Kontrollen für Sicherheit und Datenschutz sowie das Management von Integrationen mit Drittsystemen. [2] Diese vier Dinge kommen mit einem selbstgebauten Tool nicht mit, und niemand budgetiert sie, wenn die Lizenz gekündigt wird.
Die Vorreiter trifft es zuerst
Der deutlichste Beleg, dass diese Rechnung fällig wird, steckt in denselben McKinsey-Daten. High Performer skalieren Coding-Agenten doppelt so häufig wie andere, und sie sind auch die Gruppe, die am häufigsten auf Softwarekäufe verzichtet hat. 18 Prozent von ihnen sagen, die Kosten hätten ihren Einsatz von Coding-Agenten eingeschränkt, gegenüber 6 Prozent bei allen anderen. [1] Bei allen anderen Kategorien von KI-Tools, von Chatbots über andere Agenten bis zu Spezialwerkzeugen, liegen die beiden Gruppen nur einen oder zwei Punkte auseinander. Der Kostendruck betrifft genau das, was sie selbst gebaut haben.
Zusammen gelesen ergeben die beiden Befunde ein klares Muster. Die Organisationen, die auf dem Weg des Eigenbaus am weitesten sind, stossen einfach als Erste auf die Betriebskosten dessen, was sie gebaut haben, und alle anderen kommen später dort an. Genau das übersieht der Business Case meist: Ein Lizenzpreis enthält bereits Wartung, Sicherheit, Updates und Integrationen, er ist also laufender Aufwand. Eine Eigenbau-Schätzung enthält den Bau. Die Rechnung, nach der Bauen günstiger ist als Kaufen, vergleicht eine wiederkehrende Zahl mit einer einmaligen, und sie stimmt genau bis zu dem Tag, an dem das Ding in Betrieb geht.
In Europa ändert der Eigenbau auch Ihre rechtliche Rolle
Es gibt einen zweiten Kostenfaktor, der fast nie im Business Case auftaucht, und er ist spezifisch für diesen Markt. Nach dem EU AI Act macht Sie der Kauf eines Systems zum Betreiber, mit den vergleichsweise überschaubaren Pflichten nach Artikel 26. Wer es selbst baut und in Betrieb nimmt, wird zum Anbieter, und die Anbieterpflichten nach Artikel 16 [3] haben eine andere Grössenordnung: Konformitätsbewertung, technische Dokumentation, ein Qualitätsmanagementsystem, Registrierung in der EU-Datenbank und Überwachung nach dem Inverkehrbringen.
Das gilt nur für Hochrisiko-Systeme nach Anhang III, und die meisten internen Tools fallen nicht darunter. Anhang III [4] ist aber alles andere als exotisch. Rekrutierung und Vorauswahl von Kandidierenden, Aufgabenzuteilung, Leistungsbeurteilung und Kreditwürdigkeitsprüfung stehen alle auf der Liste. Ein Team, das die CV-Screening-Funktion einer HR-Suite in zwei Sprints nachbaut, hat keine Lizenzgebühr gespart, sondern die Organisation in eine regulatorische Rolle gebracht, die sie vorher nicht hatte, mit Pflichten, die ab dem 2. Dezember 2027 gelten. Das ist Zeit, um sich vorzubereiten, nicht Zeit, um es zu ignorieren.
Was zu tun ist
Wenn Sie Budgetverantwortung tragen, gehört dieser Entscheid Ihnen und nicht der IT, denn die Kosten des Eigenbaus landen in Ihrer Rechnung und die Konsequenz in Ihrem Betriebsmodell. Der nötige Eingriff ist klein.
Das Gremium benennen, das den Entscheid trägt. In den Betriebsmodellen, die wir gestalten, liegt Make-or-Buy oberhalb einer Schwelle bei einer kleinen ständigen Gruppe statt bei einer einzelnen Rolle: Budgetverantwortung, IT und Risiko an einem Tisch, mit einer Sitzungsfrequenz, die nie einen Sprint aufhält. Es ist die Logik des alten Investitionsausschusses, angewandt auf einen Entscheid, der früher mit einem Vertrag daherkam und heute ohne.
Die Schwelle so festlegen, dass sie jede Person ohne Schätzung prüfen kann. Zwei Auslöser erledigen den Grossteil: Der Eigenbau ersetzt eine Lizenz, die Sie haben oder geplant hatten, oder er berührt Kunden- oder Personaldaten oder einen Use Case nach Anhang III. Trifft einer davon zu, geht der Entscheid schriftlich an diese Gruppe und beantwortet drei Fragen.
Differenziert uns dieser Ablauf im Markt, oder ist er Standard? Bei Standardabläufen haben Anbieter jahrzehntelang aufgebauten Vorsprung, und ein Eigenbau kauft Ihnen dort vor allem die Verantwortung für ein Problem, das jemand anderes längst gelöst hat.
Wem gehört das im dritten Jahr, wenn die Person, die es geschrieben hat, gegangen ist? Ist die Antwort ein Name, schreiben Sie ihn auf. Ist die Antwort ein Schulterzucken, haben Sie einen Entscheid vertagt statt getroffen.
Was kostet der Betrieb, im Unterschied zum Bau? Token-Kosten, Wartung, Sicherheitsprüfungen, Pflege der Integrationen, Pikettdienst und die Dokumentation, die niemand geschrieben hat. Die Daten zu den High Performern legen nahe, dass diese dritte Frage systematisch zu spät gestellt wird.
Wo Dreamleap ansetzt
Zwei Teile davon sind unsere tägliche Arbeit. Der erste ist der unglamouröseste Teil eines AI Operating Model: Entscheidungsrechte. Festzulegen, wer Make-or-Buy entscheidet, ab welcher Schwelle und nach welchen Kriterien, braucht einen Workshop und kein Transformationsprogramm, und es ist einer der wenigen Governance-Schritte, die sich im ersten Jahr selbst bezahlen.
Der zweite ist, was nach dem Entscheid passiert, und wir stehen auf beiden Seiten. Wir bauen selbst End-to-End-Workflows mit Agenten, auf einer in der Schweiz gehosteten Plattform, die sich mit den Systemen verbindet, in denen die Arbeit tatsächlich stattfindet. Deshalb wissen wir genau, wie die Betriebskosten eines Eigenbaus aussehen und wo sie sich verstecken. Dasselbe Wissen macht uns nützlich, wenn die ehrliche Antwort Kaufen lautet, weil es zeigt, welche Standardabläufe es nicht wert sind, sie selbst zu besitzen. Wir plädieren nicht für eine Seite dieses Entscheids. Wir plädieren dafür, dass ihn jemand bewusst trifft, mit den betrieblichen Konsequenzen auf dem Tisch. Wenn Sie auf eine Liste gekündigter Softwarelizenzen schauen und nicht sicher sind, was Ihre Organisation jetzt besitzt, lohnt sich das Gespräch.
Ein Drittel der Unternehmen hat auf einen Softwarekauf verzichtet, den es früher getätigt hätte, und fast keines hat dafür eine Sitzung abgehalten. Versagt hat dabei keine einzelne Person. So sieht es aus, wenn ein Entscheid technisch trivial wird, schneller als die Organisation bemerkt, dass es überhaupt ein Entscheid war. Make-or-Buy ist eine Rolle und keine Tool-Frage. Hält in Ihrem Betriebsmodell heute niemand diese Rolle, gibt es die Regel trotzdem noch, sie wurde nur still an das Team mit dem grössten Token-Budget delegiert.
Quellen
Dieser Beitrag erschien erstmals am 14. September 2026 in TransformAI, dem englischsprachigen LinkedIn-Newsletter von Julia Herz zu KI-Strategie, Leadership und Transformation. Für den Blog wurde er überarbeitet und übersetzt.
