Folgekosten von Eigenentwicklung und KI-Code: Wartung, Sicherheit und Pflichten

Total Cost of Ownership (TCO) heißt: nicht nur der Kaufpreis oder die Entwicklungskosten zählen, sondern alles, was über die Nutzungsdauer anfällt. Bei Software ist das vor allem der Betrieb.

Eine Schätzung des Branchenverbands CISQ beziffert die Kosten schlechter Softwarequalität in den USA 2022 auf mindestens 2,41 Billionen US-Dollar, davon rund 1,52 Billionen aufgelaufene technische Schulden. Die Methodik haben wir nicht gelesen, der Verband wird auch von Anbietern von Qualitätswerkzeugen gesponsert. Als Hinweis auf die Größenordnung taugt die Zahl, als Planungsgrundlage für einen Kleinbetrieb nicht.

Vier Quellen werden oft angeführt. Alle messen Modelle aus den Jahren 2021 bis 2025, keine ist eine Aussage über das Werkzeug, das Sie heute nutzen.

Gelesen haben wir die Zusammenfassungen und Teile der Volltexte, bei Veracode nur die Zusammenfassung. Die Prozentwerte der Studien sind nicht direkt vergleichbar, weil sie Unterschiedliches zählen.

Als Risiko für die Lieferkette ist die Paket-Halluzination bemerkenswert: Ein Modell schlägt eine Bibliothek vor, die es nicht gibt. Wer den Namen blind installiert und ihn hat jemand mit Schadcode registriert, holt sich den Angriff selbst ins Haus. Die Autoren der Studie gehen davon aus, dass sich solche Namen für Angriffe nutzen lassen.

Hier sind die Aussagen vorsichtiger zu lesen, als sie oft zitiert werden.

• GitClear (2025): Analyse von 211 Millionen geänderten Codezeilen aus 2020 bis 2024. Der Anteil verschobener, also umgebauter Zeilen sank von 25 % (2021) auf unter 10 % (2024), der Anteil kopierter Zeilen stieg von 8,3 % auf 12,3 %. Das ist ein zeitlicher Trend, kein Nachweis, dass KI die Ursache ist. Der Herausgeber verkauft Entwickler-Analysen, die Methodik zur Erkennung von KI-Code steht auf der gelesenen Seite nicht.
• DORA 2024 (Google Cloud): Laut Zusammenfassung steigert KI-Nutzung die individuelle Produktivität, wirkt sich aber negativ auf Stabilität und Durchsatz der Auslieferung aus. Zahlen und Methodik konnten wir nicht prüfen, weil der Volltext nicht abrufbar war. Der Bericht von 2025 beschreibt KI als Verstärker bestehender Stärken und Schwächen.
• METR (2025): Randomisierter Versuch mit 16 erfahrenen Entwicklern an ihren eigenen Open-Source-Projekten. Mit KI dauerten Aufgaben im Schnitt 19 % länger, obwohl die Beteiligten das Gegenteil erwarteten. METR selbst stuft die Ergebnisse inzwischen als veraltet ein, ein Folgeversuch (2026) liefert wegen Auswahleffekten nur schwache Hinweise auf eine Zeitersparnis. Gemessen wurde Tempo, nicht Wartbarkeit.

Google und Mandiant haben die Zeit bis zur Ausnutzung („Time-to-Exploit“) für 138 im Jahr 2023 ausgenutzte Schwachstellen ausgewertet. Sie sank im Durchschnitt von 63 Tagen (2018 bis 2019) auf 5 Tage (2023). Die Autoren entfernten dabei 15 Ausreißer, ohne diese Bereinigung läge der Durchschnitt für 2023 bei 47 Tagen. Gemessen wird ab Patch, nicht ab Bekanntgabe der Lücke. Bei Schwachstellen, die erst nach Veröffentlichung eines Patches ausgenutzt wurden, geschah das laut dem Bericht bei 12 % innerhalb eines Tages und bei 29 % innerhalb einer Woche.

Eine spätere Mandiant-Analyse (30.09.2026) zählt 127 ausgenutzte Schwachstellen für 2025 und 141 für Januar bis August 2026. Von den 2026 veröffentlichten Schwachstellen wurden demnach nur 0,23 % ausgenutzt, 62 % der ausgenutzten waren Zero-Days. Die Zahlen sagen etwas über die Dringlichkeit, nicht über die Rolle von KI: Eine Ursache haben wir dort nicht gefunden.

Die US-Behörde CISA führt einen Katalog bekannter ausgenutzter Schwachstellen mit Fristen zur Behebung. Aufgenommen wird nur, was verlässlich als ausgenutzt belegt ist, der Katalog bildet also eine Untergrenze. Für Ihren Betrieb heißt das: Wer eine Anwendung betreibt, braucht einen Weg, Hinweise auf betroffene Bestandteile zu erfahren und schnell zu reagieren.

Wir geben hier die Texte der Verordnung und der Richtlinie wieder, soweit wir sie gelesen haben. Das ist keine Rechtsberatung, und einzelne Auslegungsfragen sind offen.

Cyber Resilience Act (Verordnung (EU) 2024/2847)

• Nur intern genutzte Software: Sie wird nach dem Wortlaut nicht auf dem Markt bereitgestellt. Das ist unsere Lesart, der Text sagt es nicht ausdrücklich.
• Reines SaaS: Der Wortlaut erfasst eindeutig ein Cloud-Backend, ohne das ein Gerät oder eine App eine Funktion nicht erfüllen kann. Reine Online-Dienste verweist ein Erwägungsgrund auf die NIS-2-Richtlinie. Die Kommission hat im Juli 2026 Leitlinien zu Datenfernverarbeitung und Open Source veröffentlicht, die wir nicht gelesen haben.
• KI-Code: Im gelesenen Verordnungstext kommt KI-generierter Code nicht vor. Die Pflichten gelten unabhängig davon, wer oder was den Code geschrieben hat.
• Offen: Ob der Vorschlag der Kommission vom November 2025 („Digital Omnibus“) Fristen ändert, haben wir nicht geprüft.

Neue Produkthaftungsrichtlinie (Richtlinie (EU) 2024/2853)

• Software gilt ausdrücklich als Produkt, auch KI-Systeme und das Software-as-a-Service-Modell werden im Erwägungsgrund 13 genannt. Anbieter von KI-Systemen gelten als Hersteller.
• Die Umsetzung in nationales Recht ist laut Richtlinie bis 9. Dezember 2026 vorgesehen. Den genauen Stichtag für die Anwendung auf Produkte konnten wir nicht am Wortlaut bestätigen.
• Ein Produkt kann auch wegen Sicherheitslücken im Bereich der Cybersicherheit fehlerhaft sein, und Updates unter Herstellerkontrolle sind für die Beurteilung relevant. Die Richtlinie begründet laut unserer Lesart aber keine Pflicht, Updates bereitzustellen.
• Ersatz gibt es nur für natürliche Personen. Daten, die auch nur teilweise beruflich genutzt werden, sind nicht ersatzfähig. Für einen Betrieb als Käufer ist die Richtlinie daher begrenzt hilfreich, für einen Betrieb als Anbieter von Software an Verbraucher dagegen relevant.
• Freie Software, die außerhalb einer Geschäftstätigkeit bereitgestellt wird, ist ausgenommen. Wer sie geschäftlich in ein Produkt einbaut, haftet.

Zur Datensicherheit im Alltag siehe auch DSGVO-konforme Kundenverwaltung und Mail-System.

Die folgenden Punkte sind unsere praktische Einschätzung, keine Ergebnisse der oben genannten Studien. Für jede selbst gebaute oder KI-gebaute Anwendung sollten Sie die Fragen schriftlich beantworten können:

1. Verantwortliche und Vertretung: Wer ist zuständig, wenn eine Lücke gemeldet wird oder der Dienst ausfällt?
2. Abhängigkeiten: Welche Bibliotheken stecken drin, und wer prüft neue Namen, bevor sie installiert werden?
3. Updates: Wie oft wird aktualisiert, und wer testet danach?
4. Überwachung: Welche Alarme gibt es, wer bekommt sie, und was passiert nachts?
5. Sicherheitsprüfung: Wird der Code vor dem Einsatz geprüft, von Menschen oder Werkzeugen, und wer schaut auf Zugangsdaten im Code?
6. Datensicherung: Gibt es Backups, und wurde die Wiederherstellung schon einmal getestet?
7. Wissen: Gibt es eine Beschreibung der Architektur, die jemand anderes lesen kann?
8. Ausstieg: Wie kommen Ihre Daten heraus, wenn die Anwendung ersetzt wird (siehe Daten exportieren beim Anbieterwechsel)?

Ein Eigenbau lohnt sich, wenn der Ablauf wirklich einzigartig ist und Sie jemanden haben, der Betrieb und Sicherheit dauerhaft übernimmt. Für Standardaufgaben wie Mail, Chat, Aufgaben und Kundenverlauf ist eine fertige Lösung meist günstiger über die gesamte Laufzeit (mehr dazu in SaaS-Kosten senken und Open-Source-Workspace selbst betreiben). Auch bei fertiger Software bleibt die Frage nach Support-Zeitraum, Updates und Meldeweg, stellen Sie sie dem Anbieter.