76 Prozent der Datenverantwortlichen aus deutschen Unternehmen haben im vergangenen Jahr geschäftliche Probleme oder Krisen durch KI-Halluzinationen oder ungenaue KI-Antworten erlebt. Dabei haben 56 Prozent ein gekauftes KI-Agenten-System wegen mangelhafter Performance aufgegeben. 78 Prozent glauben sogar, dass die Chefetage im Unternehmen die Genauigkeit der KI-Systeme überschätzen würde. In allen drei Bereichen liegen deutsche Unternehmen damit deutlich über dem internationalen Durchschnitt – der liegt bei 59 Prozent bei den Geschäftsproblemen, bei 45 Prozent bei den mangelhaften Systemen und 68 Prozent bei der CEO-Einschätzung der Genauigkeit.

Das geht aus einer Umfrage unter dem Titel Global AI Confessions des US-amerikanischen Marktforschungsunternehmens The Harris Poll hervor. Auftraggeber der Befragung ist Dataiku, ein Anbieter einer Plattform für KI- und ML-Dienste. In 812 Online-Interviews beantworteten 203 Datenverantwortliche aus den USA, 103 aus Deutschland, 103 aus Japan, 102 aus Großbritannien, 101 aus Frankreich, 100 aus den Vereinigten Arabischen Emiraten, 50 aus Singapur und 50 aus Südkorea die Fragen der Marktforscher. Alle Teilnehmer arbeiten für große Unternehmen mit einem Jahresumsatz von mehr als 1 Milliarde US-Dollar oder den regionalen Äquivalenten. Die Umfrageteilnehmer sind auf Vice-President-, Director-, Managing Director- oder C-Suite-Ebene in Daten-, Analytics- oder KI-relevanten Funktionen tätig.

Deutsche nehmen es nicht so genau

Von den deutschen Befragten verlangten nur vier Prozent eine Genauigkeit der Systeme von 95 bis 100 Prozent, international waren es 15 Prozent. 53 Prozent der Deutschen gaben sich mit weniger als 80 Prozent Genauigkeit bei KI-gestützten Entscheidungen zufrieden, bei einem internationalen Durchschnitt von 38 Prozent. Die Marktforscher sehen hier eine Verbindung zur deutschen Höchstrate der Projekte, die an geringer Qualität scheitern.

Knapp 60 Prozent der Befragten gaben weiterhin an, nur auf eine Katastrophe durch KI-Halluzinationen in geschäftskritischen Workflows zu warten. Ebenso viele fürchten finanzielle Risiken durch unkontrollierte API- und Service-Kosten durch KI-Agenten. Dabei verlangen nur 17 Prozent der deutschen Datenverantwortlichen eine vollständige End-to-End-Nachvollziehbarkeit von Multi-Agent-Workflows (global: 20 Prozent). 34 Prozent der Teilnehmer aus Deutschland gaben an, dass ihre Teams weniger als die Hälfte der KI-Entscheidungen im Sinne aktueller regulatorischer Auflagen nachverfolgen könnte. 58 Prozent hätten sogar KI-Agenten-Deployments wegen mangelnder Erklärbarkeit verzögert oder blockiert. Nur fünf Prozent der Gesamtzahl der international Befragten gab an, die Entscheidungen ihrer KI-Systeme zu 100 Prozent erfassen zu können.

Von den Deutschen befürchten 63 Prozent, dass Kunden Schäden durch ihre KI-Agenten entstehen könnten, während sogar 69 Prozent glauben, dass KI-Systeme ihren Mitarbeitern schaden könnten. Mögliche Security-Bedenken bespricht die Umfrage nicht weiter im Detail – erst kürzlich kam heraus, dass selbst der Branchenführer OpenAI nicht imstande ist, persönliche Daten aus E-Mails seiner Nutzer vor Angreifern zu schützen und die Kenntnis eines entsprechenden Exploits monatelang verschwieg.

Die Geschäftsführung überschätzt die Technik

In der Pressemitteilung zur Umfrage spricht Dataiku von einer „Kluft zwischen C-Suite-Erwartungen und technischer Realität“. Diese sei in Deutschland besonders ausgeprägt: Fast 80 Prozent der Datenverantwortlichen sei überzeugt, dass ihre Chefetage die Genauigkeit der KI-Systeme überschätzen würde. International lag dieser Eindruck bei 68 Prozent. 82 Prozent der Deutschen gaben an, dass die Geschäftsführung die Zeit und Schwierigkeiten, KI-Systeme zur Produktionsreife zu bringen, unterschätzt. Von den Befragten erwarten etwa 70 Prozent, dass ein CEO bis Ende 2026 aufgrund einer gescheiterten KI-Strategie oder einer KI-induzierten Krise entlassen wird. Im globalen Durchschnitt erwarten dies 56 Prozent der Befragten.

Eine ähnliche Umfrage unter CEOs aus dem März 2025 ergab, dass unter 100 deutschen CEOs ebenfalls knapp 70 Prozent mit Entlassungen wegen KI-Projekten rechnet. Aus der CEO-Umfrage ging außerdem hervor, dass 95 Prozent der deutschen Geschäftsführer den Eindruck haben, KI-Agenten könnten bei Geschäftsentscheidungen einen gleichwertigen oder besseren Rat geben als ein menschliches Vorstandsmitglied. 76 Prozent der Datenverantwortlichen teilen die Auffassung, dass KI-generierten Geschäftsempfehlungen in ihren Unternehmen mehr Gewicht zukommt als denen von menschlichen Mitarbeitenden. Auch hier ist Deutschland Umfrageführer, wobei der Durchschnitt bei 69 Prozent liegt.

Die Umfragen unter den CEOs und den Datenverantwortlichen finden sich hier und hier. Der Zugriff erfordert die Angabe einer E-Mail-Adresse.

(pst)

Uno Platform 6.3 ist mit Preview-Support für .NET 10.0 erschienen. Das quelloffene Cross-Platform-GUI-Framework für .NET bereitet sich nicht nur auf das für November geplante .NET-Release vor, sondern bietet auch schon Kompatibilität mit Visual Studio 2026.

Neues Zielframework .NET 10.0

In Uno Platform besteht nun neben dem Support für die aktuelle, stabile Version .NET 9.0 auch Preview-Support für .NET 10.0 Release Candidate 1. Am 11. November 2025 soll laut Microsoft das finale Release mit Long-Term Support erscheinen. Im Wizard der Uno Platform lässt sich .NET 10.0 direkt als Zielframework auswählen:

Dabei ist zu beachten, dass das Zusammenspiel mit .NET 10.0 als Ziel derzeit nicht für die Produktion geeignet ist. Stabile Produktionsapps sollen bis zum offiziellen .NET-10.0-Release bei .NET 9.0 verbleiben. Für die Migration auf Version 10.0 bietet das Uno-Platform-Team einen Migrationsguide an.

Der Support für .NET 8.0 ist unterdessen entfallen. Dabei handelt es sich um das derzeit aktuelle LTS-Release mit Support bis November 2026. Jedoch hat .NET MAUI 8.0 bereits im Mai 2025 sein End-of-Life-Datum erreicht, weshalb Uno Platform sich von dieser .NET-Version abwendet.

Bereit für Visual Studio 2026

Visual Studio 2026, die nächste Hauptversion von Microsofts Entwicklungsumgebung, ist in einem Insider-Programm verfügbar. Auch Uno Platform bereitet sich auf die neue Version vor und ist mit ihren Updates kompatibel, darunter das neue .slnx-Format als verständlicherem Ersatz für .sln-Dateien. Dabei ist Uno Platform 6.3 auch weiterhin mit Visual Studio 2022 kompatibel, sodass Uno-Platform-User beide Versionen im Einsatz haben können. Ebenso wie der Support für .NET 10.0 ist auch jener für Visual Studio 2026 als Preview gekennzeichnet.

Weitere neue Features in Uno Platform 6.3 gibt es unter anderem für den visuellen Designer Hot Design, der im kostenpflichtigen Uno Platform Studio enthalten ist. Auch sollen grafiklastige Apps mit WebAssembly nun glatter funktionieren und die TabView über verschiedene Zielplattformen hinweg konsistenter und verlässlicher sein.

Alle weiteren Details zu Uno Platform 6.3 hält der Blogeintrag zur Ankündigung bereit.

(mai)

In der modernen Softwareentwicklung ist Nebenläufigkeit allgegenwärtig. Selbst kleine Anwendungen laufen oft auf Systemen mit mehreren Kernen, interagieren mit Datenbanken, warten auf Netzwerkantworten oder teilen sich Ressourcen wie Dateien und Speicherbereiche. In verteilten Systemen und Embedded-Software kommt noch hinzu, dass verschiedene Prozesse aufeinander reagieren müssen, oft unter Echtzeitbedingungen. Die Praxis zeigt: Sobald mehrere Dinge gleichzeitig passieren können, entstehen neue Fehlerklassen, die sich in seriellen Programmen nie gezeigt hätten.

Muster 3: Concurrency und Scheduling: Wenn sich Prozesse gegenseitig blockieren

Ein berühmtes Beispiel ist der Mars Pathfinder, eine NASA-Mission aus dem Jahr 1997. Die Landung selbst war ein spektakulärer Erfolg – die Sonde setzte sanft auf dem Mars auf und begann, Daten zu senden. Doch kurz darauf kam es zu sporadischen Systemabstürzen und automatischen Resets, die das Team am Boden in Alarmbereitschaft versetzten.

Die Ursache war eine Priority Inversion, ein klassisches Concurrency-Problem. In einem Echtzeitbetriebssystem gibt es Aufgaben mit unterschiedlicher Priorität. Hohe Priorität bedeutet: Diese Aufgabe soll möglichst sofort laufen, sobald sie bereit ist. Niedrige Priorität darf sie nicht blockieren.

Auf dem Pathfinder lief eine solche hochpriorisierte Aufgabe, die Daten vom Wettersensor verarbeitete. Sie benötigte jedoch Zugriff auf eine gemeinsame Ressource – in diesem Fall einen Mutex, der von einer niedrig priorisierten Aufgabe gehalten wurde. Diese niedrig priorisierte Aufgabe wurde wiederum von einer mittel priorisierten Aufgabe ständig verdrängt. Das Ergebnis: Die hochpriorisierte Aufgabe wartete indirekt auf eine niedrige, die nie zum Zuge kam.

Dieses Phänomen der „Umkehrung der Prioritäten“ führte dazu, dass das System in bestimmten Lastsituationen hängen blieb und schließlich neu startete. Die Lösung war im Prinzip einfach: Die Entwicklerinnen und Entwickler aktivierten Priority-Inheritance im Echtzeitbetriebssystem VxWorks. Dadurch erbte die blockierende, niedrig priorisierte Aufgabe vorübergehend die hohe Priorität, sobald eine höherwertige Aufgabe auf sie wartete. Der Knoten löste sich, und die Abstürze verschwanden.

Dieses Beispiel ist lehrreich, weil es gleich mehrere typische Muster verdeutlicht:

• Nebenläufigkeitsfehler sind schwer zu reproduzieren: Sie treten oft nur unter bestimmten Lastprofilen auf.
• Redundanz oder Wiederholungen helfen nicht automatisch: Wenn der Fehler im Design liegt, trifft er alle Instanzen gleichermaßen.
• Kleinste Details im Scheduling können den Unterschied machen: Die Software kann tausendmal korrekt laufen und beim tausend-und-ersten Mal ausfallen.

In modernen Anwendungen können ähnliche Probleme in Form von Deadlocks, Race Conditions oder Livelocks auftreten. Diese zeigen sich meist nicht im lokalen Testlauf, sondern erst in der Produktion, wenn reale Last und reale Parallelität wirken. Doch wie lassen sich solche Fehler vermeiden?

1. Klare Lock-Hierarchien: Wenn mehrere Ressourcen gesperrt werden, sollte immer in derselben Reihenfolge gelockt werden.
2. Prioritätsprotokolle nutzen: Mechanismen wie Priority Inheritance oder Priority Ceiling sind in vielen Echtzeitbetriebssystemen und sogar in modernen Frameworks verfügbar.
3. Nebenläufigkeit entkoppeln: Statt gemeinsame Zustände direkt zu sperren, können Architekturen mit Message Passing oder Actor-Modellen Race Conditions vermeiden.
4. Deterministische Tests und Simulationen: Spezielle Testframeworks können Prozesse gezielt verzögern oder Scheduler manipulieren, um seltene Konflikte reproduzierbar zu machen.
5. Telemetrie und Monitoring: Auch im Betrieb sollte sichtbar sein, wenn Locks ungewöhnlich lange gehalten werden.

Für Teams, die Web-Backends oder Cloud-Services entwickeln, zeigt sich übrigens dieselbe Gefahr, nur in geringfügig anderer Form: Datenbanktransaktionen, verteilte Caches oder konkurrierende API-Requests können ähnliche Effekte haben. Ein langsamer Hintergrundprozess blockiert einen Lock, während eine Flut von parallelen Requests diesen Zustand eskalieren lässt.

Die Lehre aus dem Pathfinder-Vorfall ist daher zeitlos: Nebenläufigkeit ist kein kostenloser Performance-Booster, sondern ein komplexes System, das Entwicklerinnen und Entwickler explizit entwerfen und überwachen müssen. Wer Concurrency als Randthema behandelt, wird früher oder später auf schwer reproduzierbare und potenziell katastrophale Fehler stoßen.

Aus Softwarefehlern lernen – die Serie

Diese Artikelserie stellt neun typische Fehlerklassen vor, die in der Praxis immer wieder auftauchen – unabhängig von Branche oder Technologie. In jeder Kategorie wird die Serie ein konkretes Beispiel vorstellen, dessen Ursachen analysieren und daraus ableiten, was Softwareentwicklerinnen und Softwareentwickler langfristig lernen können.

Im nächsten Teil lesen Sie: Zeit, Kalender und Geografie: Wenn die Uhr nicht das misst, was man denkt.

(who)