.png)
Im Mai 2026 lieferte das National Bureau of Economic Research (NBER) den bislang fundiertesten Beleg zum Thema KI und Software: Die Programmieraktivität stieg durch den Einsatz von KI-Agenten um bis zu 180 %, während die tatsächlichen Software-Veröffentlichungen lediglich um 30 % zunahmen. Es verfassen somit mehr Menschen schneller als je zuvor Quellcode – darunter viele, die dazu vor zwei Jahren noch nicht in der Lage gewesen wären. Beschleunigt wurde jedoch keiner der umliegenden Prozesse: Code-Prüfung, Qualitätssicherung, Abstimmung und Verantwortung. Künstliche Intelligenz hat den Preis für die Erstellung von Software verändert. Den Preis für deren Bereitstellung und Betrieb hingegen nicht. Und erst recht nicht die Sorgfalt, mit der die Aufsicht Ihre nachhaltigen Finanzlösungen prüft.
Falls Sie nur Zeit für einen einzigen Abschnitt haben, lesen Sie diesen!
Die folgende Tabelle fasst alle Anforderungen an ein erfolgreiches Softwareprodukt im Finanzsektor zusammen. Durch Vibe-Coding wirken die ersten beiden Zeilen dieser Tabelle nahezu kostenlos. Für Subject Matter Experts (SME), die direkt selbst entwickeln, mag das für Zeile 1 sogar stimmen. Wer sich jedoch für die Eigenentwicklung im eigenen Haus entscheidet, gezeichnet für alle zehn Punkte verantwortlich und trägt das Gesamtrisiko. Eine Verantwortung, die eine Leitung im Bereich Responsible Investing in der Regel nicht übernehmen kann.
Eine Team8-Studie aus dem Jahr 2026 zeigt, dass 81 % der nordamerikanischen Banken ihre Build-versus-Buy-Strategie aufgrund von KI überdacht haben. Zudem gaben in einer Mercer-Befragung unter 131 Asset Managern vom Februar 2026 91 % an, den Einsatz von KI in diesem Jahr ausweiten zu wollen. Dahinter steckt eine handfeste Erfahrung aus der Prototypenphase: Forschungsergebnisse der Stanford University beziffern den Produktivitätsgewinn durch KI bei einfachen Aufgaben auf der „grünen Wiese“ auf 35 bis 40 %. Bei komplexem Legacy-Code schrumpft dieser Vorteil jedoch auf 10 % oder weniger. Software im Bereich Sustainable Finance gehört heute meist genau zu dieser gewachsenen Legacy-Basis.
Wir haben dies bei WeeFin selbst erlebt. Wir haben KI-Entwicklungstools bewusst dem gesamten Unternehmen zugänglich gemacht, und die Programmieraktivität stieg exakt so an, wie es die NBER-Daten beschreiben. Der Großteil davon stammte von Mitarbeitenden, die zuvor keinen solchen Code hätten schreiben können. Produktmanager liefern heute funktionsfähige Mock-ups statt reiner Spezifikationen; Frontend-Entwickler wagen sich an Backend-Code und umgekehrt; Vertriebs- und Client-Teams bauen ihre eigenen Assistenten und Automatisierungen. Manche dieser Entwicklungen hätten vor fünf Jahren noch ein ganzes Quartal der Roadmap gekostet. Und wir möchten heute keinen einzigen dieser Schritte mehr rückgängig machen. Gleichzeitig haben wir jedoch auch erfahren, wie viel einfacher der Neuaufbau auf der „grünen Wiese“ ist, und wie schwer sich KI-Tools tun, wenn sie auf einem bereits komplexen System aufbauen sollen. Ein Aspekt, der zu Beginn eines Projekts nur zu oft übersehen wird.
Doch die Grenzen zeigten sich schnell: Erste Tools fielen aus, ohne dass ihre Ersteller die Ursache diagnostizieren konnten. Prototypen blieben weit über ihren eigentlichen Zweck hinaus im Einsatz, jedes wirklich relevante Tool landete am Ende doch beim Engineering-Team zur Prüfung, bei Änderungen am Datenmodell brach unbemerkt etwas weg, und Sicherheitsfragen hatte beim Bauen niemand gestellt. Wir haben diese Schwachstellen frühzeitig erkannt und behoben. Wer hier nicht gegensteuert, behält ein unkontrolliertes Risiko im Unternehmen. Erwartungsgemäß ist die Lösung allerdings nicht günstig, und der Druck landet am Ende wieder bei den Expert*innen im Entwicklungsteam.
Auf lange Sicht zeigen sich noch tiefgreifendere Probleme: Schon 1975 beschrieb Fred Brooks in seinem Klassiker „The Mythical Man-Month“ das fundamentale Prinzip der Systemintegrität: Ein kleines Team mit einem nahtlos ineinandergreifenden System schafft schlicht mehr Wert als eine riesige Mannschaft. Genau an diesem Punkt geraten Vibe-Coding-Lösungen heute ins Straucheln. Jeder einzelne Baustein mag für sich genommen stark sein, berücksichtigt das Gesamtgefüge aber nicht in dem Maße, wie es ein menschlicher Entwickler oder Architekt tun würde. Besonders in komplexen Domänen wie Sustainable Finance wird dies zu einer gravierenden Einschränkung und erzeugt ein mittelfristiges Risiko, das sich kaum noch beherrschen lässt.
Das reine Schreiben von Code war noch nie der teure Teil
Die Softwarepflege macht 60 bis 80 % der Lebenszykluskosten eines Systems aus (IEEE-Analysen; Robert Glass’ „60/60-Regel“), und rund drei Viertel der Gesamtkosten (Total Cost of Ownership) entstehen erst nach dem Go-live. Banken geben bis zu 70 Cent jedes IT-Dollars allein dafür aus, bestehende Alt-Systeme am Leben zu halten (McKinsey, 2024). Wenn Finanzinstitute Eigenentwicklungen wagen, sprengen sie zudem regelmäßig den Rahmen: Im Schnitt liegen sie 45 % über dem Budget und liefern 56 % weniger Mehrwert als versprochen (McKinsey–Oxford, über 5.400 Projekte). KI-generierter Code macht die Pflege dabei keineswegs günstiger, sondern teurer: Seit 2023 ist die Code-Duplizierung um 81 % gestiegen, während aktives Refactoring um 70 % eingebrochen ist (GitClear). Hinzu kommt, dass 25 bis 45 % des KI-erzeugten Codes Sicherheitslücken aus den OWASP Top 10 enthalten (Veracode und AppSecSanta). Gartner prognostiziert daher, dass bis 2027 40 % aller KI-gestützten Programmierprojekte vorzeitig abgebrochen werden.
Unsere eigene Produktentwicklung bestätigt das täglich. Bei einem komplexen Produkt wird der Weg von der ersten Idee bis zum fertigen Feature vor allem von Spezifikation, Priorisierung, Testing und Validierung geprägt. Das eigentliche Coden war schon immer nur der letzte Baustein. KI hat genau dieses Teilstück drastisch verkürzt, den gesamten Rest aber weitgehend unberührt gelassen. Wir experimentieren intensiv mit verschiedenen Modellen. Unsere Erfahrung zeigt, ein SME kann heute per Vibe Coding ein Tool komplett von Grund auf bauen, ohne erst Spezifikationen zu verfassen. Das liegt schlicht daran, dass er die fachlichen Anforderungen im Detail kennt. Sobald ein solches Tool allerdings marktreif werden soll, insbesondere in datenintensiven Umfeldern, führt kein Weg an einem professionellen Entwicklerteam vorbei. Und selbst wenn das reine Coden in diesem Industrialisierungsschritt heute viel schneller abläuft, bleiben Code-Reviews, Qualitätssicherung und nachgelagerte Prozesse unverzichtbar, um den hohen Qualitätsstandards des Finanzsektors gerecht zu werden.
In einer Retool-Umfrage unter 307 Tech-Entscheidern gab fast die Hälfte (44 %) an, dass es bei Vorfällen durch KI-entwickelte Tools keine klare Verantwortlichkeit gibt. Zudem bezeichneten nur 8 % ihre Governance für interne Anwendungen als stark. In der Finanzbranche ist diese Dynamik nicht neu. Mehr als 90 % aller Spreadsheets enthalten Fehler. Man denke an das VaR-Modell, das die JPMorgan-Verluste in Höhe von 6,2 Milliarden Dollar im „London Whale“-Skandal begrenzen sollte. Es basierte auf kopierten Excel-Formeln, die die Volatilität fälschlicherweise halbierten (wie der interne Bericht der Bank von 2013 aufdeckte), was zu einer falschen Einschätzung des zugrundeliegenden Risikos führte. m KI-Zeitalter zeichnen sich diese Muster bereits ab: Ein KI-Agent löscht trotz eines aktiven Code-Freezes eine Produktivdatenbank (Replit, 2025), fehlerhafte Standardberechtigungen bei Low-Code-Systemen führten zur Offenlegung von 38 Millionen Datensätzen, und Sicherheitsvorfälle im Kontext unregulierter ‘shadow AI’ verursachen laut IBM (2025) durchschnittlich 670.000 US-Dollar an Zusatzkosten.
Die Frage nach der Zuständigkeit erübrigt sich im Finanzsektor, denn die Aufsicht stellt hier klare Regeln auf. Die technischen Standards von DORA schreiben Entwicklungs-, Test- und Code-Review-Pflichten auch für Systeme vor, die von Nutzern außerhalb der IKT-Funktion entwickelt oder verwaltet werden. Die KI-generierte Anwendung eines SME fällt damit direkt in den Regulierungsbereich und unterliegt vollen Governance-Pflichten. Dabei entsteht ein Skalierungseffekt, der bislang viel zu wenig Beachtung findet: Jedes interne Tool erzeugt ein neues IKT-Asset, das identifiziert, klassifiziert und dokumentiert, mit Testnachweisen belegt und jährlich überprüft werden muss. Wenn KI die Anzahl interner Anwendungen vervielfacht, vergrößert sie im selben Maße die DORA-Compliance-Fläche. Solche Tools sind günstig in der Erstellung, aber teuer im laufenden Betrieb. In Großbritannien erfasst die PRA-Richtlinie SS1/23 sämtliche Modelle, egal ob intern oder extern entwickelt, und nimmt benannte Führungskräfte persönlich in die Pflicht. Der Zukauf einer Lösung überträgt zwar nicht diese Verantwortung, verteilt den Compliance-Aufwand aber über hunderte von Kunden. Wer hingegen selbst baut, trägt den gesamten Compliance-Stack in Eigenregie, für jedes einzelne Tool dauerhaft.
Ergänzend zum reinen Gesetzestext spielt der Faktor Vertrauen eine Schlüsselrolle. Aufsichtsbehörden können unmöglich jede einzelne Eigenentwicklung im Detail überprüfen. Zu spezialisierten Anbietern wächst jedoch mit der Zeit ein natürliches Vertrauen. Gerade in stark regulierten Bereichen wie Sustainable Finance, wo sich Rahmenbedingungen ständig ändern, wird dieses Vertrauen zum entscheidenden Kriterium bei jeder Make-or-Buy-Entscheidung. Da Vorschriften hier oft politisch getrieben und auslegungsbedürftig sind, braucht es weiterhin menschliche Fachexpertise, um die nötigen Ermessensentscheidungen sauber abzuwägen.
Bei WeeFin gilt deshalb der klare Grundsatz, dass auch jede von SME initiierte Anwendung die vollen Qualitätsstandards erfüllen muss. Das bedeutet, dass jedes Tool zwingend an ein Team übergeben werden muss, das den geschriebenen Code in der Tiefe versteht. Ohne diesen konsequenten Transfer der Verantwortlichkeit hält kein Modell einer strengen Prüfung nach DORA- oder PRA-Regeln stand.
Am Ende läuft alles auf die Make-or-Buy-Entscheidung hinaus und auf die Frage, welcher Weg in jedem konkreten Fall der sinnvollste ist.
In Bereichen, die weniger datenintensiv sind und in denen eine Lösung lediglich ergänzend eingesetzt wird, kann der Einstieg über ein per „Vibe Coding“ erstelltes Tool durchaus funktionieren. Dieser Ansatz schärft das Verständnis dafür, welche Funktionen tatsächlich benötigt werden und welche überflüssig sind. Allerdings bringt er auch das Risiko mit sich, Features zu entwickeln, die dem echten Betrieb niemals standhalten.
In komplexen, stark regulierten Feldern wie Sustainable Finance stoßen solche Ansätze jedoch schnell an ihre Grenzen. Eine komplette Eigenentwicklung droht hier rasch zu einem jahrelangen Projekt zu werden. Ob das Ergebnis der nächsten Aufsichtsprüfung standhält, bleibt dabei ungewiss. Als Spezialist für Sustainable Finance wissen wir genau, welche Ansätze technisch funktionieren, und bewahren Sie vor teuren Fehlentscheidungen.
Vor diesem Hintergrund verändert auch KI die grundlegende Entscheidung nicht. Es gilt weiterhin das Prinzip, dort selbst zu entwickeln, wo eigene Daten und Abläufe einen unkopierbaren Wettbewerbsvorteil schaffen. Der Zukauf ist hingegen dort überlegen, wo ein spezialisierter Anbieter mehr Transaktionen, Sonderfälle und regulatorische Anpassungen sieht, als es ein einzelnes Unternehmen je könnte. Eigenentwicklungen machen nur dort Sinn, wo ein Institut selbst mehr Spezialfälle überblickt als der Markt. Ein Zukauf lohnt sich genau dann, wenn die eigenen Teams auf den Ergebnissen dieser externen Lösung intern weiteraufbauen können.
Bei WeeFin entwickeln unsere Teams auf der Prototypenebene völlig frei. Sobald eine Anwendung jedoch Kundendaten oder regulierte Prozesse berührt, übernimmt die zentrale Softwareentwicklung. Alles, was nicht zu unserer eigenen Kernkompetenz gehört, kaufen wir extern zu.Bevor auch nur ein einziger Prompt geschrieben wird, sollten sechs Fragen geklärt sein.
Aus unserer eigenen Praxis erfordert eine weit verbreitete Sichtweise eine Korrektur. KI senkt die Kosten der Code-Erstellung tatsächlich für jede neue Version und nicht nur für den ersten Prototyp. Was KI jedoch nicht erzeugt, ist Kontinuität. Erfolgreiche Softwareprodukte leben von Stringenz, von einem einheitlichen Datenmodell, einer klaren Roadmap und eindeutigen Verantwortlichkeiten für jede Entscheidung. KI steigert zwar die Produktivität, vervielfacht aber gleichzeitig die Zahl der Initiativen, die genau diese Stringenz gefährden. Der eigentliche Kostentreiber war nämlich noch nie die reine Programmierarbeit, sondern der Aufwand, die Organisation bei jeder Änderung erneut einzubinden. Qualitätsprüfung, Testing, Schulungen, Dokumentation, Support und regulatorische Nachweise verlangen allen Beteiligten enorm viel ab. Dieser Integrationsaufwand sinkt durch KI kaum, wächst aber mit der Zahl der Anpassungen direkt mit. Wer doppelt so viele Versionen veröffentlicht, zahlt diesen Preis schlicht doppelt. Das NBER-Phänomen, wonach die Programmieraktivität zwar um 180 % steigt, die tatsächlichen Software-Releases aber nur um 30 %, macht genau diesen Stau in der organisatorischen Verarbeitung sichtbar. Ein spezialisierter Anbieter wird am Ende für eine einzige zentrale Leistung bezahlt. Er hält das Produkt in sich stimmig, damit Ihre eigene Organisation diesen Integrationsprozess nur ein einziges Mal durchlaufen muss.
Ein Finanzinstitut muss sich heute dieselbe Make-or-Buy-Frage stellen wie noch vor wenigen Jahren. Doch die zugrunde liegenden Annahmen haben sich verändert. Das bedeutet keineswegs automatisch, dass jede Eigenentwicklung heute einfacher geworden ist. Im Gegenteil, es entstehen völlig neue Anforderungen an Governance und Risikomanagement sowie neuartige Herausforderungen.
KI hat das Schreiben jeder einzelnen Version günstiger gemacht. Sie hat jedoch die Kohärenz, also ein einheitliches Produkt, eine klare Verantwortlichkeit und eine durchgängige Roadmap, zum teuersten Faktor in der Softwareentwicklung gemacht. Genau das ist es, was man mit einer Lizenz in Wirklichkeit kauft.
