Künstliche Intelligenz
Aus Softwarefehlern lernen Teil 10: Software für eine bessere digitale Zukunft
Die Softwarebranche liebt es, von „neuen Herausforderungen“ zu sprechen. Seien es Cloud-native Architekturen, Microservices, Machine Learning oder Edge Computing: Jede Technologiewelle bringt ihre eigenen Buzzwords und vermeintlich einzigartige Probleme mit sich. Doch wer die großen Softwarekatastrophen der letzten Jahrzehnte studiert, erkennt schnell: Deren Muster sind zeitlos.
Weiterlesen nach der Anzeige

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.
Die Teile der Serie „Aus Softwarefehlern lernen“:
Teil 10: Von Wiederholungstätern zu lernenden Organisationen: Wie die Softwarebranche ihre Lektion lernt
Der Mars Climate Orbiter verglühte 1999, weil Einheiten verwechselt wurden. Die Ariane 5 explodierte 1996 wegen eines Überlaufs. Knight Capital verlor 2012 440 Millionen Dollar durch einen fehlerhaften Deployment-Prozess. Der Therac-25 tötete in den 1980er-Jahren Menschen durch Race Conditions. Diese Vorfälle liegen Jahrzehnte auseinander, stammen aus völlig unterschiedlichen Domänen und basieren doch auf denselben fundamentalen Fehlern.
Das wirft eine unbequeme Frage auf: Wenn wir die Ursachen kennen, die Lösungen dokumentiert sind und die Werkzeuge existieren, warum passieren diese Fehler dann immer noch? Die Antwort ist ernüchternd: Weil technisches Wissen allein nicht ausreicht. Die Wiederholung bekannter Fehler ist kein technisches, sondern ein organisatorisches und kulturelles Problem.
Die Illusion der technischen Lösung
Nach jedem spektakulären Softwarevorfall folgt dasselbe Ritual: Analysen werden geschrieben, Lessons-Learned dokumentiert, neue Tools entwickelt. Nach Heartbleed gab es bessere Fuzzing-Tools. Nach Knight Capital wurde über Deployment-Automatisierung diskutiert. Nach dem Mars Climate Orbiter sprach man über Typsysteme und Einheiten-Bibliotheken. All diese technischen Verbesserungen sind wertvoll und notwendig. Doch sie fokussieren stets nur auf die Symptome, behandeln allerdings nicht die Ursache:
- Die Ariane 5 hatte Tests, sie deckten nur nicht die relevanten Szenarien ab.
- Knight Capital hatte Deployment-Prozesse, sie wurden unter Zeitdruck nur nicht befolgt.
- Der Therac-25 galt als modernes, softwaregesteuertes System, und genau das wurde zum Problem, weil Hardware-Interlocks eingespart wurden.
Weiterlesen nach der Anzeige
Die technische Ebene ist zweifellos die einfachste. Moderne Programmiersprachen bieten starke Typsysteme, die Einheitenfehler zur Compile-Zeit erkennen. Linter und statische Analysetools finden potenzielle Null-Pointer-Exceptions, bevor der Code läuft. Property-based-Testing deckt Grenzwertprobleme auf. Fuzzing findet Memory-Corruption-Bugs. All diese Werkzeuge sind mächtig – aber nur, wenn sie auch eingesetzt werden. Und genau hier beginnt das eigentliche Problem: die organisatorische Ebene.
Jedes Softwareteam kennt die gut gemeinten Prozesse. Code-Reviews, bei denen mindestens zwei Entwicklerinnen oder Entwickler draufschauen. Pair-Programming für kritische Codepfade. Ausführliche Testabdeckung, Blameless-Postmortems nach jedem Vorfall, Feature-Flags mit dokumentiertem Lifecycle, Deployment-Pipelines mit automatischen Rollback-Mechanismen und so weiter. All das sind bewährte Praktiken: Sie stehen in unzähligen Best-Practice-Guides, werden auf Konferenzen besprochen und in zahlreichen Stellenausschreibungen gefordert. Doch wenn der Termin näherrückt, der Kunde drängt oder der Wettbewerber schneller ist, sind genau diese Prozesse das erste Opfer.
„Wir reviewen das später“ wird zu „Wir haben es nie reviewed“. „Das testen wir noch ausführlich“ wird zu „Hat im Happy-Path funktioniert“. „Wir dokumentieren das Feature-Flag“ wird zu „Irgendwo steht bestimmt was dazu“. Dieser Mechanismus ist so vorhersagbar, dass er fast schon ein Naturgesetz der Softwareentwicklung ist: Nicht technisch erzwungene Prozesse erodieren unter Zeitdruck. Das Knight-Capital-Desaster ist dafür ein Paradebeispiel. Das Unternehmen hatte Prozesse für Deployments. Doch als es das neue Release ausrollte, blieb ein Server zurück. Ein einzelner vergessener Server mit einem alten Feature-Flag – und 45 Minuten später waren 440 Millionen Dollar vernichtet. Die Ursache war nicht fehlendes Wissen, sondern fehlende Disziplin in der Ausführung.
Hier zeigt sich ein grundlegendes Muster: Organisationen, die Qualitätssicherung als nice to have behandeln, weil sie vermeintlich zu teuer ist, bezahlen den Preis dennoch – nur später und dafür meist deutlich teurer. Um dem entgegenzuwirken, ist Automatisierung der Schlüssel. Was technisch erzwungen wird, kann nicht vergessen werden. Was hingegen von Hand geprüft werden muss, wird früher oder später übersehen oder vergessen. Das bedeutet zum Beispiel:
- Atomare Deployments, bei denen entweder alle Server aktualisiert werden oder keiner.
- Compiler, die Code ohne explizite Null-Behandlung ablehnen.
- CI/CD-Pipelines, die bei fehlenden Tests den Build abbrechen.
- Typsysteme, die Einheiten überprüfen.
Diese Mechanismen sind keine Schikane, sondern Lebensversicherungen für Software. Doch selbst die beste Automatisierung hilft nichts, wenn die dritte Ebene fehlt: die kulturelle – also die Art, wie eine Organisation mit Fehlern umgeht.
Die unterschätzte Dimension: Fehlerkultur und psychologische Sicherheit
Die technische und prozessuale Ebene lässt sich vergleichsweise einfach messen und verbessern. Doch die kulturelle Ebene ist subtiler und gleichzeitig entscheidender. In vielen Organisationen herrscht noch immer eine Kultur der Schuldzuweisung. Wenn etwas schiefgeht, wird nach dem Schuldigen gesucht. „Wer hat das deployed?“, „Wer hat das reviewed?“ oder „Wer hätte das sehen müssen?“. Diese Fragen sind menschlich verständlich, aber nicht zielführend, sondern kontraproduktiv.
Der Grund dafür ist einfach: Wenn Fehler mit Konsequenzen für Einzelne verbunden sind, werden sie verschleiert statt offen besprochen. Entwicklerinnen und Entwickler trauen sich nicht mehr, Bedenken zu äußern. Code-Reviews werden oberflächlicher, weil niemand als Bremser gelten will. Probleme werden vertuscht, bis sie eskalieren. Die Alternative sind Blameless Postmortems: Eine Praxis, die aus der Kultur des Site-Reliability-Engineering kommt. Die Grundidee ist, dass nach einem Vorfall nicht nach Schuldigen gesucht wird, sondern nach Systemschwächen. Also nicht „Wer hat den Fehler gemacht?“, sondern „Welche Umstände haben dazu geführt, dass dieser Fehler möglich war?“
Diese Haltung klingt weich, ist aber knallhart pragmatisch. Denn die Wahrheit ist: Fast jeder schwerwiegende Softwarefehler ist ein System- und kein individuelles Versagen. Wenn ein einzelner Developer einen Bug einbaut, ein Reviewer ihn übersehen, ein Test ihn nicht finden und ein Deployment ihn in Produktion bringen kann, dann ist das Problem das System, nicht der Mensch. Der Therac-25 ist dafür ein erschütterndes Beispiel. Die Race Condition, die Menschen tötete, war subtil und schwer zu reproduzieren. Sie trat nur auf, wenn Anwender sehr schnell Eingaben tätigten. Wäre es fair, den Entwicklern vorzuwerfen, sie hätten diesen Spezialfall testen müssen? Oder ist es nicht vielmehr ein Versagen des Designs, das sicherheitskritische Hardware-Interlocks durch Software-Checks ersetzt, ohne formale Verifikation, ohne unabhängiges Audit, ohne redundante Sicherungsebene?
Organisationen mit guter Fehlerkultur dokumentieren ihre Vorfälle detailliert, machen sie dem gesamten Team zugänglich und leiten konkrete Verbesserungen ab. Sie feiern es, wenn jemand einen potenziellen Fehler frühzeitig meldet. Sie reservieren explizit Zeit für technische Schulden und Refactoring. Sie nehmen Warnungen von Expertinnen und Experten ernst, auch wenn diese unbequem sind. In der griechischen Mythologie gab es Kassandra, die stets die Wahrheit sah, der aber niemand glaubte. Jede Organisation hat ihre Kassandras: Entwicklerinnen und Entwickler, die vor Risiken warnen, die auf technische Schulden hinweisen, die sagen „Das wird irgendwann schiefgehen“. Ob die Organisation diese Warnungen ernst nimmt, ist ein Gradmesser für ihre Reife.
Diese kulturelle Dimension wirkt sich direkt auf die Kosten aus. Die spektakulären Fälle zeigen drastisch, was es kostet, nicht aus Fehlern zu lernen. Diese Zahlen sind eindrücklich, aber sie zeigen dennoch nur die Spitze des Eisbergs. Die meisten Softwarefehler führen nicht zu spektakulären Katastrophen, sondern zu schleichendem Schaden: ständiges Feuerlöschen statt planvoller Entwicklung, frustrierte Teams mit hoher Fluktuation, Vertrauensverlust bei Kundinnen und Kunden, verpasste Marktchancen, technische Schulden, die sich exponentiell aufbauen. Zahlreiche Studien beziffern die Kosten schlechter Softwarequalität auf Hunderte Milliarden bis Billionen Dollar jährlich. Das ist keine abstrakte Zahl, sondern die Summe aus Millionen kleiner und großer Fehler, die täglich auftreten.
Künstliche Intelligenz
Studie: Rechenzentren rund um Frankfurt kurbeln Wirtschaft an
Frankfurt und das umliegende Rhein-Main-Gebiet haben sich zu einem der wichtigsten digitalen Hubs Europas entwickelt. Eine neue Studie des Instituts der deutschen Wirtschaft (IW Consult) und des Beratungshauses Detecon für den eco-Verband der deutschen Internetwirtschaft unterstreicht die enorme ökonomische Bedeutung der dort ansässigen Rechenzentrumsbranche. Im Gegensatz zur Gesamtwirtschaft, die in Frankfurt und der Region Rhein-Main in den vergangenen fünf Jahren um rund 16 Prozent wuchs, verdoppelte sich dort gleichzeitig das Bruttoinlandsprodukt (BIP) im Sektor der Betreiber von Rechenzentren.
Weiterlesen nach der Anzeige
Die Prognosen sehen laut der Analyse ein ungebremstes Wachstum voraus, schreibt der eco: Das Branchen-BIP soll in den kommenden fünf Jahren in der hessischen Gegend voraussichtlich um weitere 175 Prozent steigen.
Die Wertschöpfung beschränke sich dabei nicht nur auf die Betreiber selbst, heißt es: Jeder in Rechenzentren erwirtschaftete Euro soll weitere 51 Cent an wirtschaftlicher Leistung anstoßen – 24 Cent davon direkt in der Region. Zudem generierte die Branche 2023 ein Steueraufkommen von 405 Millionen Euro. Davon sollen 287 Millionen Euro direkt auf die Betreiber und weitere 117 Millionen Euro auf Zulieferer entfallen sein. Geschätzt blieben etwa zehn Prozent des Steueraufkommens in den Standortkommunen, größtenteils aufgrund von Gewerbesteuern.
Noch bedeutender sind die „Spillover-Effekte“ für Anwenderindustrien: Unternehmen, die Rechenzentrumsinfrastruktur nutzen, sind laut der IW-Studie wesentlich innovativer. Sie konnten rund 18 Prozent ihrer Umsätze mit neuen Produkten oder Dienstleistungen erzielen, während Unternehmen ohne die Inanspruchnahme von Rechenzentren nur knapp 8 Prozent erreichten. Dieser Effekt wird durch den gegenwärtigen KI-Hype verstärkt, da entsprechende Anwendungen einen massiven Bedarf an Rechenleistung und schnellen Netzen haben.
Diese Sogwirkung wird auch durch den in Frankfurt angesiedelten De-Cix verdeutlicht, den weltweit größten Internetknoten. Die dort herrschende Infrastrukturdichte zieht heimische wie internationale Unternehmen an, die jährlich mindestens zwei Milliarden Euro in die digitale Infrastruktur der Mainmetropole investieren.
Regionale Risiken: Der Kampf um den Strom
Trotz der hervorstechenden Wachstumszahlen stehen Betreiber in Frankfurt und ganz Deutschland zunehmend vor großen Herausforderungen. Die IW-Studie benennt die kritischen Standortfaktoren: hohe Energiekosten, lange Genehmigungsverfahren, regulatorische Unsicherheit und Flächenknappheit.
Ein akutes Problem ist dabei die Stromversorgung. Hier droht der digitale Boom, die Netze der Region an ihre Grenzen zu bringen, wie jüngst auch eine Analyse von AlgorithmWatch ergab. Der rapide steigende Energiehunger – insbesondere durch den Einsatz von KI – führt laut Branchenbeobachtern zu Engpässen bei der Energieversorgung und gefährdet die Netzstabilität. Ein modernes Rechenzentrum kann so viel Strom verbrauchen wie eine Großstadt. Künftige, rein KI-getriebene Rechenzentren dürften einen noch deutlich höheren Bedarf haben.
Weiterlesen nach der Anzeige
Diese Entwicklung birgt das Risiko, dass die dringend benötigten kurzfristig verfügbaren zusätzlichen Stromkapazitäten in großem Maßstab in der Region nicht mehr gewährleistet werden können. Dies verschlechtert die Rahmenbedingungen für die Betreiber massiv.
Skandinavien lockt mal wieder
Béla Waldhauser, Sprecher der unter dem Dach des eco gegründeten Allianz zur Stärkung digitaler Infrastrukturen, warnt daher eindringlich vor einer Abwanderung in andere europäische Länder. Er schielt dabei etwa auf Skandinavien, wo attraktivere Konditionen in Form günstigerer Energiepreise und eines einfacheren sowie leistungsfähigeren Netzzugangs herrschten.
Waldhausers Forderung an Politik und Kommunen: Es braucht ein eindeutiges politisches Engagement für die digitale Infrastruktur. Bezahlbarer Strom müsste sichergestellt sowie beschleunigte und verlässliche Genehmigungsverfahren eingeführt werden, um Frankfurt und die gesamte Region als digitales Zentrum langfristig zu bewahren. Dieses Standbein der digitalen Wirtschaft dürfe nicht gekappt werden.
(nie)
Künstliche Intelligenz
Studie: Bundesverwaltung soll bei generativer KI auf Eigenentwicklungen setzen
Die dynamische Entwicklung generativer Künstlicher Intelligenz (KI), die vor allem die großen Sprachmodelle (LLMs) hinter ChatGPT, Gemini oder Claude verdeutlichen, stellt Staaten und Verwaltungen weltweit vor eine wichtige strategische Frage: Wie lassen sich solche Instrumente zur Textgenerierung, Wissenserschließung und Prozessunterstützung gezielt verwenden, ohne dabei die digitale Souveränität zu opfern?
Weiterlesen nach der Anzeige
Leistungsfähige moderne LLMs benötigen riesige Datenmengen, teure Hardware und viel Energie – Ressourcen, die heute primär von wenigen, zumeist außereuropäischen Tech-Giganten kontrolliert werden. Für den Staat ist es deshalb laut Experten entscheidend, sich Handlungsfähigkeit, Transparenz und Kontrolle über diese Schlüsseltechnologie zu verschaffen.
Das Kompetenzzentrum Öffentliche IT (Öfit) am Fraunhofer-Institut Fokus hat in einer jetzt veröffentlichten, vom Bundesinnenministerium geförderten Studie die LLM-basierten Systeme der Bundesverwaltung daraufhin untersucht, wie unabhängig sie aufgestellt sind. Digitale Souveränität bedeutet demnach, dass Deutschland zusammen mit Europa zentrale digitale Infrastrukturen, Daten und Rechnerinfrastrukturen eigenständig, sicher und nach individuellen Regeln gestalten und betreiben kann.
Die Analyse der LLM-Projekte erfolgte entlang von drei strategischen Zielen, die sich aus der Digitalpolitik des Bundes ableiten lassen: die Wechselmöglichkeit, also die faktische Verfügbarkeit alternativer Lösungen und die Austauschbarkeit von Systemkomponenten. Die Forscher blickten ferner auf die Gestaltungsfähigkeit, die etwa die eigenen technischen und organisatorischen Kompetenzen zur Bewertung, zum Betrieb und zur Weiterentwicklung von Systemen umfasst. Zudem fokussierten sie sich auf den Einfluss auf Anbieter, der durch Markt- und Verhandlungsmacht, etwa bei der Beschaffung, gewährleistet wird.
Eigenentwicklungen reduzieren Abhängigkeit
Die gute Nachricht der Studie lautet: Im Bereich der LLMs konnte im Gegensatz zu früher festgestellten „Schmerzpunkten“ bei Bürosoftware oder Datenbankprodukten keine kritische singuläre Abhängigkeit von einem einzelnen Großkonzern festgestellt werden. Die Bundesverwaltung hat es demnach geschafft, für viele typische Anwendungsfälle LLM-basierter Systeme Eigenentwicklungen aufzubauen. Dadurch muss für einen Großteil der alltäglichen Aufgaben nicht zwingend auf die Produkte großer, oft nicht-europäischer Konzerne zurückgegriffen werden. Das mindert das Risiko von vornherein, in neue Interdependenzen gegenüber Dritten zu geraten.
Die Risiken für die staatliche Handlungsfähigkeit sind den Wissenschaftlern zufolge aus heutiger Sicht überschaubar, da die entwickelten Lösungen derzeit ausschließlich der Arbeitsunterstützung für Verwaltungsmitarbeitende dienen. Ein Ausfall würde die staatliche Handlungsfähigkeit nicht unmittelbar gefährden. Technisch gesehen trägt zur Souveränität bei, dass die LLMs meist auf eigener Hardware laufen und bei Bedarf mit geringem bis mittlerem Aufwand ausgetauscht werden können.
Open Source als europäische Chance
Weiterlesen nach der Anzeige
Auf der Ebene der Sprachmodelle selbst setzt die Bundesverwaltung mehrheitlich auf nicht-europäische Open-Source-Modelle, die in verwaltungsinterner Infrastruktur betrieben werden. Das stärkt laut der Untersuchung zwar die Wechselmöglichkeit, da die LLMs auf eigener Infrastruktur gehostet und bei Bedarf ersetzt werden können. Es verbleibe jedoch eine strategische Lücke: Angesichts des sich wandelnden Open-Source-Verständnisses im KI-Kontext empfehlen die Autoren dringend zu prüfen, ob die Entwicklung eines eigenen, offen bereitgestellten europäischen LLMs anzustreben sei. Ziel müsse es sein, eine dauerhafte Unabhängigkeit von marktbeherrschenden LLM-Anbietern zu erreichen und die Modelle auf einer eigenständigen europäischen Werte- und Normenbasis zu verankern.
Einschlägige LLM-Projekte bei Behörden sehen sich zudem mit Hürden konfrontiert, die weiteres Wachstum und Nachnutzbarkeit behindern. Dazu gehören laut der Studie als zu kompliziert wahrgenommene rechtliche KI-Vorschriften, die Entwicklungen verzögern und umfassende juristische Kompetenzen in den Ämtern erfordern. Diese Unsicherheiten und die teils als gering eingestufte rechtliche Kompetenz schränkten die Veröffentlichung der Entwicklungen als Open Source ein, heißt es. Ferner äußerten befragte Projektverantwortliche mehrfach den Wunsch nach einer KI-spezifischen Cloud-Infrastruktur, die mit entsprechend geschultem Personal ausgestattet ist, um den Betrieb zu vereinfachen.
Die Studie enthält diverse Handlungsempfehlungen, um die digitale Souveränität nachhaltig zu sichern. Dazu zählen der Ausbau gemeinsamer LLM-Infrastrukturen über Ressortgrenzen hinweg und die Stärkung von Open-Source-Ansätzen. Zudem sollen einheitliche rechtliche Leitplanken etabliert werden etwa durch einen verpflichtenden „Souveränitätscheck“ für kritische LLM-Projekte. Die Beschaffung sei über föderale Ebenen hinweg zu bündeln um Kriterien zur digitalen Souveränität durchzusetzen und die Verhandlungsmacht gegenüber großen Anbietern zu stärken. Bundesdigitalminister Karsten Wildberger (CDU) wertet die Ergebnisse als Bestätigung, „dass wir bereits auf dem richtigen Weg sind, ein solides Fundament für unabhängige KI‑Lösungen in der Bundesverwaltung“ zu schaffen.
Lesen Sie auch
(nie)
Künstliche Intelligenz
Radioaktives Radon: Warum es ein unterschätztes Risiko ist
Auf der Maker Faire 2024 sprach mich Make-Chefredakteur Daniel Bachfeld über einen Ergänzungsartikel zum Taupunktlüfter an. Dieser sollte beschreiben, wie man dem Edelgas Radon auf die Spur kommt und wie ein Taupunktlüfter es aus dem Haus entfernen kann. Aus dieser einfachen Frage ist eines meiner umfangreichsten Projekte entstanden, für das ich auch Informationen bei Fachfirmen, Universitäten und dem Bundesamt für Strahlenschutz einholen musste. Und, ohne zu übertreiben: Es geht bei diesem Thema um Leben und Tod!
Meine Erkenntnisse sind in einem weiteren Artikel aufsplittet.
- Was ist Radon?
- Welche Gefahr geht davon aus?
- Wie können wir es mit Maker-Mitteln detektieren?
Checkliste
Zeitaufwand:
4 Stunden (Ballonexperiment)
Kosten:
etwa 60 Euro (Geigerzähler für Ballonexperiment)
Material
Werkzeug
- Geigerzähler etwa Bosean FS-5000 (50 Euro)
Radon
Bei Radon handelt es sich um ein radioaktives Edelgas, das in der Erdkruste natürlicherweise vorkommt. Es entsteht durch den Zerfall von Uran und Thorium, die in sehr vielen Gesteinen und Böden vorkommen. Radon selbst ist farb-, geruchs- und geschmackslos, was bedeutet, dass es weder mit bloßem Auge noch mit anderen Sinnen wahrgenommen werden kann. Zudem ist es schwerer als Luft, was später noch eine wichtige Rolle spielen wird.
Das war die Leseprobe unseres heise-Plus-Artikels „Radioaktives Radon: Warum es ein unterschätztes Risiko ist“.
Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.
-
UX/UI & Webdesignvor 2 MonatenIllustrierte Reise nach New York City › PAGE online
-
Datenschutz & Sicherheitvor 3 MonatenJetzt patchen! Erneut Attacken auf SonicWall-Firewalls beobachtet
-
Künstliche Intelligenzvor 2 MonatenAus Softwarefehlern lernen – Teil 3: Eine Marssonde gerät außer Kontrolle
-
Künstliche Intelligenzvor 2 Monaten
Top 10: Die beste kabellose Überwachungskamera im Test
-
UX/UI & Webdesignvor 3 MonatenFake It Untlil You Make It? Trifft diese Kampagne den Nerv der Zeit? › PAGE online
-
Entwicklung & Codevor 3 WochenKommandozeile adé: Praktische, grafische Git-Verwaltung für den Mac
-
UX/UI & Webdesignvor 2 MonatenSK Rapid Wien erneuert visuelle Identität
-
Social Mediavor 3 MonatenSchluss mit FOMO im Social Media Marketing – Welche Trends und Features sind für Social Media Manager*innen wirklich relevant?
