Im Mai 2026 lieferte eine Studie des National Bureau of Economic Research (NBER) unter mehr als 100.000 Entwicklerinnen und Entwicklern die bislang belastbarste Zahl 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 % stiegen. Noch nie wurde von so vielen Menschen so schnell Code geschrieben und darunter sind auch viele, die vor zwei Jahren noch gar nicht programmieren konnten. Was sich allerdings nicht im gleichen Tempo beschleunigt hat, ist das Umfeld rund um die Entwicklung: Code-Reviews, Qualitätssicherung, Abstimmungen und Verantwortlichkeiten. KI hat die Kosten für die Erstellung von Software verändert, aber nicht den Aufwand für ihre Bereitstellung und ihren Betrieb. Und schon gar nicht die Sorgfalt, mit der Aufsichtsbehörden Ihre nachhaltigen Finanzlösungen prüfen.
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 Fachexperten, die direkt selbst entwickeln, mag das für Zeile 1 sogar stimmen. Wenn Sie sich jedoch für die Eigenentwicklung entscheiden, sind Sie für alle zehn Punkte verantwortlich und tragen das Gesamtrisiko. Eine Verantwortung, die eine Abteilung im Bereich Responsible Investing in der Regel nicht tragen kann.
| Kostenblock | Leistungsumfang | Empirische Befunde |
|---|---|---|
| 1. Anforderungsphase & Planung | Das Problem verstehen, spezifizieren, priorisieren, Stakeholder aufeinander abstimmen. | Wer als Fachexperte selbst Lösungen baut, spart sich die Spezifikation. Wer als Entwickler*in vibe-coded, spart hier gar nichts: Anforderungen müssen trotzdem entstehen und geteilt werden. |
| 2. Der Bau selbst | Entwicklungszeit (mit oder ohne KI), eingesetzte Tools und der Aufwand für die Überarbeitung nach der ersten funktionierenden Version. | Große IT-Projekte liegen im Schnitt 45 % über dem Budget (McKinsey/Oxford, über 5.400 Projekte). Asset Manager fangen an, KI-Budgets zu kürzen, weil sie explodieren (Mercer). |
| 3. Prüfung und QA | Technische Prüfung von KI-generiertem Code, Tests und Freigabeprozesse. | 45 % des KI-Codes tragen Schwachstellen aus den OWASP Top 10 (Veracode). Code-Reviews und Qualitätssicherung sind dabei die am wenigsten automatisierten Schritte. |
| 4. Wartung und Sicherheit | Bugfixes, Aktualisierung von Abhängigkeiten, Sicherheitsupdates und laufendes Monitoring. | 60 bis 80 % der Lebenszykluskosten entstehen erst nach dem Launch (IEEE, Glass’sche 60/60-Regel). KI kann diesen Anteil zwar senken, die Verantwortung dafür kann der Fachexperte jedoch nicht tragen. |
| 5. Weiterentwicklung und Parität | Regulatorische Änderungen, Integrationen und Nutzeranforderungen und gleichzeitig mit der Geschwindigkeit eines spezialisierten Anbieters Schritt zu halten. So bleibt man technologisch nicht zurück. | Was nach dem Launch dazukommt, kostet typischerweise das Drei- bis Vierfache des ursprünglichen Baus. In einer Branche wie Sustainable Finance, die sich ständig bewegt, wird es noch teurer. |
| 6. Ownership und Kontinuität | Eine klar benannte verantwortliche Person, vollständige Dokumentation, eine geregelte Übergabe bei einem Wechsel im Entwicklungsteam und die Möglichkeit, das System bei Bedarf neu aufzubauen. | 44 % der Tech-Verantwortlichen haben keine klar definierte Zuständigkeit für KI-generierte Tools (Retool); Gartner prognostiziert, dass bis 2027 40 % der KI-Coding-Projekte eingestellt werden. |
| 7. Regulatorische Angriffsfläche | DORA-Assetklassifizierung, Testnachweise, Code-Review, jährliche Prüfungen, Modellvalidierung nach SS1/23. | Gilt pro Tool und auch für Tools, die außerhalb der IT entstehen (DORA RTS Art. 16 Abs. 9). |
| 8. Incident-Risiko | Zugriffskontrolle, Datenlecks und das zusätzliche Risiko von Sicherheitsverletzungen bei nicht ausreichend kontrollierten Tools. | Sicherheitsverletzungen im Finanzsektor verursachen durchschnittlich Kosten von 5,56 Mio. US-Dollar (IBM, 2025); ‘Shadow AI’ erhöht diese Kosten um weitere 670.000 US-Dollar. Verstöße gegen Datenlizenzen können zu Anbieterprüfungen und nachträglichen Nachzahlungen führen (Bloomberg v. UBS, 2020). |
| 9. Organisatorischer Integrationsaufwand | Schulungen, Support, Dokumentation und Change Management für jedes Release. | Der Aufwand sinkt durch KI kaum und kann mit zunehmender Anzahl an Änderungen sogar steigen. Ein Tool für den eigenen Bedarf zu entwickeln, ist das eine. Ein Tool mit einem strukturierten Roll-out und einem CSM als Trainingspartner für die Nutzer einzuführen, ist eine ganz andere Aufgabe. |
| 10. Opportunitätskosten | Was Ihre Entwickler und Fachexperten nicht bauen konnten, während sie für dieses Tool verantwortlich waren. | Beim Vibe Coding fühlen sich erst einmal alle befähigt. Häufig entstehen dabei aber nur Halblösungen. Das Ergebnis: verschwendete Zeit und Opportunitätskosten, die aus dem Ruder laufen. |
Eine Team8-Studie aus dem Jahr 2026 zeigt, dass 81 % der nordamerikanischen Banken ihre Build-versus-Buy-Strategie aufgrund von KI überdacht haben. In einer Mercer-Umfrage unter 131 Asset Managern gaben im Februar 2026 zudem 91 % an, dass sie den Einsatz von KI in diesem Jahr ausweiten wollen. Dahinter stehen konkrete Erfahrungen aus der Praxis: Stanford zufolge kann KI die Produktivität bei Projekten, die von Grund auf neu entwickelt werden, um 35-40 % steigern. Bei komplexem Legacy-Code fällt der Produktivitätsgewinn dagegen auf 10 % oder weniger. Software für nachhaltige Finanzlösungen gehört heute meist genau zu dieser bestehenden Legacy-Landschaft.
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 selbst erlebt, wie viel einfacher es ist, etwas von Grund auf neu zu entwickeln und wie schwierig es für KI-Tools sein kann, auf einem bereits komplexen System aufzubauen. Ein Aspekt, der zu Beginn eines Projekts häufig unterschätzt wird.
Gleichzeitig zeigten sich mit der Zeit weitere, übergreifende Grenzen: Erste Tools fielen aus, ohne dass ihre Entwickler*innen die Ursache diagnostizieren konnten. Prototypen blieben länger im Einsatz, als ursprünglich vorgesehen und jedes Tool, das tatsächlich relevant wurde, landete zur Prüfung auf dem Tisch des Engineering-Teams. Änderungen an den Datenmodellen führten teilweise dazu, dass Funktionen unbemerkt ausfielen und bei der Entwicklung waren Sicherheitsaspekte nicht immer von Anfang an berücksichtigt worden. Wir haben diese Probleme früh erkannt und konnten sie lösen, aber 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 Entwicklungsteam 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 Software-Baustein mag für sich genommen stark sein, berücksichtigt das Gesamtgefüge aber nicht in dem Maße, wie es durch menschliche Expertise in Entwicklung und Architektur geschehen würde. Gerade in komplexen Bereichen wie Sustainable Finance wird das zu einer erheblichen Einschränkung und zu einem mittelfristigen Risiko, das nur schwer zu beherrschen ist.
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 selbst entwickeln, werden Projekte zudem häufig teurer als geplant: Im Durchschnitt liegen sie 45 % über dem Budget und liefern 56 % weniger Wert als ursprünglich versprochen (McKinsey–Oxford, über 5.400 Projekte). Auch KI-generierter Code ist langfristig nicht günstiger im Betrieb – im Gegenteil: Der Anteil an dupliziertem Code ist seit 2023 um 81 % gestiegen, während Refactoring um 70 % zurückgegangen ist (GitClear). Gleichzeitig enthalten 25-45 % des KI-generierten Codes Schwachstellen aus den OWASP Top 10 (Veracode und AppSecSanta). Gartner prognostiziert zudem, dass bis 2027 rund 40 % der KI-gestützten Coding-Projekte eingestellt 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 Schreiben des Codes war schon immer nur der letzte Teil des Prozesses. KI hat diesen Teil deutlich beschleunigt, die übrigen Schritte jedoch weitgehend unverändert gelassen. Wir experimentieren intensiv mit verschiedenen Modellen. Dabei sehen wir, dass ein Fachexperte heute ein Vibe-Coding-Tool von Grund auf entwickeln kann, ohne dafür zunächst detaillierte Spezifikationen zu verfassen. Das funktioniert, weil der Fachexperte selbst genau weiß, was benötigt wird. Sobald es jedoch darum geht, dieses Tool produktions- und marktreif zu machen, insbesondere bei datenintensiven Anforderungen, braucht es ein Entwicklungsteam. Und auch wenn das Schreiben des Codes in diesem Prozess heute deutlich schneller geht, sind weiterhin Code-Reviews, Qualitätssicherung und alle nachgelagerten Prozesse notwendig, um eine Qualität sicherzustellen, die den Anforderungen der Finanzbranche gerecht wird.
In einer Retool-Umfrage unter 307 Technologie-Verantwortlichen gab fast die Hälfte (44 %) an, dass es bei Vorfällen durch KI-entwickelte Tools keine klare Verantwortlichkeit gibt. Zudem bewerteten nur 8 % ihre Governance für interne Tools als gut aufgestellt. In der Finanzbranche ist diese Dynamik nicht neu. Mehr als 90 % aller Spreadsheets enthalten Fehler. Man denke an das VaR-Modell, das eigentlich den 6,2-Milliarden-Dollar-Verlust der „London Whale"-Affäre bei JPMorgan erkennen sollte. Das Modell basierte auf kopiertem Excel-Code und enthielt eine Formel, die die gemeldete Volatilität halbierte (wie der interne Bericht der Bank von 2013 aufdeckte). Dadurch wurde das zugrundeliegende Risiko falsch eingeschätzt. Auch in Zeiten von KI zeichnen sich diese Muster bereits ab: Ein KI-Agent löschte trotz eines bestehenden Code-Freeze eine Produktionsdatenbank (Replit, 2025), 38 Millionen Datensätze wurden aufgrund von Standardberechtigungen in einer Low-Code-Umgebung offengelegt, und Sicherheitsverletzungen im Zusammenhang mit „Shadow AI" verursachen im Durchschnitt 670.000 US-Dollar zusätzliche Kosten (IBM, 2025).
In der Finanzbranche nimmt der Regulator einem die Frage nach der Verantwortlichkeit ab. Die technischen Standards von DORA sehen für Systeme, die „von Nutzern außerhalb der ICT-Funktion entwickelt oder verwaltet werden", Anforderungen an Entwicklung, Testing und Source-Code-Reviews vor. Die vom Fachexperten mit KI entwickelte Anwendung fällt damit ausdrücklich in den Anwendungsbereich und muss den entsprechenden Governance-Vorgaben folgen. Dabei entsteht ein Skalierungseffekt, der bislang viel zu wenig Beachtung findet: Jedes interne Tool bedeutet ein zusätzliches Softwareprogramm, das identifiziert, klassifiziert und dokumentiert werden muss. Hinzu kommen Testnachweise, die erstellt, und jährliche Überprüfungen, die durchgeführt werden müssen. Wenn KI die Anzahl interner Tools vervielfacht, vervielfacht sie damit auch die DORA-relevante Angriffs- und Governance-Fläche. Sie sind günstig zu entwickeln, aber teuer im laufenden Betrieb. Für Großbritannien gilt mit PRA SS1/23 ein ähnlicher Grundsatz. Die Vorgaben gelten für alle Modelle, unabhängig davon, ob sie intern oder extern entwickelt wurden und verlangen eine namentlich benannte Führungskraft, die persönlich dafür verantwortlich ist. Der Kauf einer Lösung überträgt diese Verantwortung nicht. Er verlagert jedoch den Aufwand für Nachweise und Dokumentation auf den Anbieter, der ihn über hunderte Kunden verteilen kann. Wer selbst entwickelt, trägt dagegen den gesamten Aufwand, für jedes einzelne Tool und dauerhaft.
Ein wichtiger Aspekt neben den eigentlichen regulatorischen Anforderungen ist das Thema Vertrauen. Aufsichtsbehörden können unmöglich jede einzelne intern entwickelte Lösung im Detail überprüfen. Über die Zeit bauen sie jedoch Vertrauen zu bestimmten Anbietern und deren Lösungen auf. Gerade in einem stark regulierten Bereich wie Sustainable Finance, in dem sich regulatorische Anforderungen sehr häufig ändern, kann dieses Vertrauen ein entscheidender Faktor bei der Frage „Make-or-Buy-Entscheidung" sein. Da die Regulierung in diesem Bereich häufig politisch geprägt und nicht immer eindeutig ist, spielt menschliche Expertise eine wichtige Rolle, um die relevanten Entscheidungskriterien richtig einzuordnen und abzuwägen.
Bei WeeFin gilt deshalb der klare Grundsatz, dass auch jede von Fachexperten 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 eine solche Übergabe der Verantwortung können selbst entwickelte Modelle und Tools den Anforderungen einer Prüfung nach PRA- oder DORA-Vorgaben langfristig nicht standhalten.
Am Ende läuft alles auf die Make-or-Buy-Entscheidung hinaus und auf die Frage, wie sich einschätzen lässt, welcher Ansatz im jeweiligen Fall sinnvoller ist.
In Bereichen, die weniger datenintensiv sind und in denen eine Lösung lediglich ergänzend eingesetzt wird, kann es sinnvoll sein, zunächst mit einer Vibe-Coding-Lösung zu starten. Dieser Ansatz schärft das Verständnis dafür, welche Funktionen tatsächlich benötigt werden und welche überflüssig sind. Gleichzeitig besteht das Risiko, Features und Lösungen zu entwickeln, die sich in der Praxis letztlich nicht sinnvoll einsetzen lassen.
In komplexen, stark regulierten Feldern wie Sustainable Finance stoßen solche Ansätze jedoch schnell an ihre Grenzen und können zu einem Projekt werden, das sich über mehrere Jahre zieht. Ob das Ergebnis am Ende den Anforderungen des Regulators genügt, bleibt dabei ungewiss. Unsere Spezialisierung auf Sustainable Finance gibt uns dabei einen klaren Einblick, was technisch funktioniert und wie sich kostspielige und zeitaufwendige Fehlentwicklungen von Anfang an vermeiden lassen.
Vor diesem Hintergrund verändert KI die grundsätzliche Entscheidung nicht. Die zentrale Logik bleibt bestehen: Eigenentwicklung dort, wo proprietäre Daten und individuelle Workflows einen Vorteil schaffen, den kein anderer Anbieter einfach nachbilden kann. Kauf dort, wo ein Anbieter mehr Transaktionen, Sonderfälle und regulatorische Veränderungen erlebt als ein einzelnes Unternehmen jemals könnte. Entwickeln Sie selbst, wenn Sie mehr Sonderfälle sehen als jeder andere. Und kaufen Sie nur dann, wenn Sie intern auf den Ergebnissen der gekauften Lösung aufbauen können.
Bei WeeFin können unsere Teams auf der Prototyp-Ebene frei experimentieren. Sobald jedoch Kundendaten oder regulatorisch relevante Prozesse betroffen sind, übernimmt das Engineering-Team. Alles, was nicht zu unserer eigenen Kernkompetenz gehört, kaufen wir extern zu. Bevor der erste Prompt geschrieben wird, sollten Sie sich sechs Fragen stellen:
Eine wichtige Ergänzung zu dieser aktuell verbreiteten Sichtweise und eine Erkenntnis aus unserer eigenen Erfahrung: KI senkt tatsächlich die Kosten für das Schreiben von Code, und zwar bei jeder Version, nicht nur bei der ersten. Was KI jedoch nicht schafft, ist Kontinuität und Produkte leben von Stringenz: ein Datenmodell, eine Roadmap, eine klare Verantwortung für jede Entscheidung. KI steigert die Produktivität, führt aber gleichzeitig dazu, dass immer mehr Initiativen um diese Stringenz konkurrieren. Der eigentliche Kostentreiber war nämlich noch nie die reine Programmierarbeit, sondern der Aufwand, die Organisation bei jeder Änderung erneut darauf auszurichten. Code-Review, 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 Anbieter wird letztlich für genau eine Sache bezahlt: ein Produkt konsistent und funktionsfähig zu halten, sodass Ihre eigene Organisation die Änderungen nicht jedes Mal aufs Neue auffangen muss.
Ein Finanzinstitut muss sich heute dieselbe Make-or-Buy-Frage stellen wie schon vor einigen Jahren. Die Rahmenbedingungen haben sich jedoch verändert. Das bedeutet nicht automatisch, dass jede Eigenentwicklung heute einfacher ist. Im Gegenteil: KI bringt völlig neue Anforderungen an Governance und Risikomanagement mit sich, und damit auch neue Herausforderungen.
KI hat jede Version günstiger in der Entwicklung gemacht. Gleichzeitig ist Stringenz – ein Produkt, ein Verantwortlicher, eine Roadmap – zum wertvollsten und aufwändigsten Gut in der Softwareentwicklung geworden. Genau dafür zahlt man bei einer Softwarelizenz.
