Vendorokratie: Substantiv, f.
Wenn der Lieferant erklärt, was sinnvoll ist.
Und die Entscheider es nicht mehr selbst beurteilen können.

Die Entscheidung ist gefallen. Das System ist ausgewählt, der Vertrag steht kurz vor Abschluss oder ist bereits unterschrieben. Was noch fehlt, wird später geklärt.

Die Lösung wirkt schlüssig. Sie ist klar erklärt, durchdacht, anschlussfähig. Es gibt wenig Anlass, sie zu hinterfragen – nicht, weil sie sicher passt, sondern weil sie überzeugend präsentiert wurde.

Von diesem Moment an verschiebt sich etwas.

Es wird nicht mehr gefragt, was gebraucht wird, sondern wie sich das, was gebraucht wird, in das übersetzen lässt, was bereits vorgesehen ist.

Eine Frage taucht dabei fast zwangsläufig auf: Passt sich Software hier den Prozessen an oder die Prozesse der Software?

Entscheidend ist nicht, ob das stimmt.
Sondern wann entschieden wurde, dass es stimmen muss.

Das Problem ist nicht das Tool

Die Tools sind selten das Problem. Es ist die Wahl des Werkzeugs.

Kein Bäckermeister würde sich einen Vulkanisierofen andrehen lassen, nur weil der Anbieter überzeugt aufgetreten ist und das Gerät technisch einwandfrei funktioniert, und Ofen ist Ofen, der lässt sich anpassen.

Die Frage ist nicht, ob das Werkzeug gut ist. Die Frage ist, ob es die Lösung für das eigentliche Problem ist.

In der IT passiert genau das regelmäßig – doch es fällt seltener auf, weil das Wort „Tool" etwas Abstraktes suggeriert.

Wir dürfen nicht vergessen: Dabei geht es um sehr konkrete Werkzeuge der eigenen Wertschöpfung, die Abläufe prägen, Entscheidungen strukturieren und Menschen in ihrer Arbeit formen. Ein falsch gewähltes Tool ist kein kleines Missgeschick. Es ist eine Weichenstellung mit Nachwirkungen.

Das Problem entsteht nicht, weil Anbieter schlechte Lösungen liefern. Sie liefern meist gute. Das Problem entsteht dort, wo eine Lösung für ein unverstandenes Problem eingesetzt wird, und Angebote eine Richtung setzen.

Warum es passiert

Das hat wenig mit fehlender Kompetenz zu tun.
Die Muster sind bekannt, und sie entstehen unter echtem Druck.

Budgets werden freigegeben. Entscheidungen müssen getroffen werden. Zeit fehlt, Komplexität soll reduziert werden, Sicherheit wird gesucht.

Anbieter liefern exakt das:
klare Antworten,
klare Strukturen,
klare Versprechen.

Auf der anderen Seite steht die eigene Organisation – verteilt auf Rollen, Abteilungen, Verantwortlichkeiten, mit Wissen, das vorhanden ist, aber selten zusammenkommt.

Die, die entscheiden, tragen das Risiko. Die, die es betrifft, sitzen oft nicht mit am Tisch. Und zwischen beidem entsteht eine Lücke, die sich leicht füllen lässt – mit dem, was bereits da ist.

Vendokratie fühlt sich dabei nicht falsch an. Die Richtung ist da, bevor sie erarbeitet werden muss. Die Struktur steht, bevor sie verstanden ist. Man greift zu, weil es passt. Oder zumindest so wirkt. Was folgt, ist Umsetzung – und mit ihr die Gewissheit, dass man vorankommt. Bis sichtbar wird, dass man sich nur bewegt hat.

Was dann entsteht

Nach außen wirkt alles schlüssig. Die Entscheidung ist getroffen, das System steht, die Umsetzung läuft.

Und doch beginnt Friktion. Nicht sofort und selten laut.
Ein zusätzlicher Schritt hier, eine Tabelle dort, Absprachen, die nicht im System existieren.

Dinge, die funktionieren müssen, funktionieren neben dem System. Informationen werden doppelt gepflegt, weil sie an der vorgesehenen Stelle nicht passen. Teams organisieren sich selbst, weil das System ihre Realität nicht abbildet.

Es entsteht, was auf den ersten Blick wie Umsetzungsprobleme aussieht – in Wahrheit aber Erkenntnisse sind. Erkenntnisse darüber, dass der Problemraum übersprungen wurde. Dass die Entscheidung stattfand, bevor das Problem verstanden war. Dass aus einem Lösungsangebot eine Richtung wurde, ohne dass jemand explizit Ja gesagt hat.

Viel Bewegung.
Aber kein Fortschritt.

Was das bedeutet

Diese Friktion zeigt sich selten in Präsentationen. Sie zeigt sich im Alltag. In Gesprächen, in denen etwas nicht aufgeht. In Rückmeldungen, die sich nicht sauber einordnen lassen.

Bei Menschen, die mit den Systemen arbeiten und ihre Auswirkungen spüren, lange bevor sie messbar werden.

Sie haben oft kein vollständiges Bild. Aber ein klares Gefühl dafür, dass etwas nicht stimmt.
Was ihnen fehlt, ist nicht Verständnis.
Sondern Einfluss.

Oft werde ich genau in diesem Moment dazu geholt – nicht um zu verstehen, sondern um umzusetzen. Wo es möglich ist, gehe ich einen Schritt zurück. Nicht weit. Nur genug, um zu sehen, was hier eigentlich passiert. Und was diese Menschen längst wissen.

Die Entscheidung zurückholen

Der Ausweg liegt nicht darin, Tools abzulehnen oder Anbieter zu misstrauen.
Er liegt darin, die richtige Reihenfolge wiederherzustellen.

Anbieter tun genau das, wofür sie da sind: Sie liefern Antworten, strukturieren Komplexität, reduzieren Unsicherheit. Das ist ihre Aufgabe, und sie erfüllen sie oft gut.

Die Fähigkeit zu entscheiden, welches Problem gelöst werden soll – und ob das vorgeschlagene Werkzeug dazu passt – liegt im Unternehmen. Wenn sie nicht genutzt wird, passiert die Entscheidung eben woanders.

Das bedeutet konkret: Wer ist nicht im Raum, obwohl er die Auswirkungen trägt? Wo entsteht Reibung, bevor sie messbar wird? Was wird gerade als gegeben angenommen, ohne es zu hinterfragen? Und vor allem: Wird hier ein Problem gelöst – oder eine Lösung angewendet?

Vendokratie erkennt man selten im Moment der Entscheidung. Sondern danach.
Wenn Systeme stehen, Prozesse laufen und die ersten Reibungen sichtbar werden.
Wenn sich zeigt, dass viel entschieden wurde, nur nicht das Richtige.

Die Frage ist nicht, welches System eingeführt wird und wer entschieden hat, dass es das Richtige ist.
Entscheidend ist, ob dieser Moment überhaupt stattgefunden hat.

Die Frage, ob Entwickler Design lernen sollten oder Designer programmieren, geistert seit Jahren durch die Branche.
Sie verschwindet, taucht wieder auf und verändert sich.
Aber sie geht nie wirklich weg.

Und immer wieder stellt sich dieselbe Frage: Sollten Designer Code verstehen? Sollten Entwickler wie Designer denken? Es ist eines dieser Themen, die nicht deshalb bestehen bleiben, weil sie besonders hilfreich sind, sondern weil sie nie wirklich gelöst werden.

Und vielleicht liegt genau darin das Problem: Diese Diskussion basiert auf einer falschen Annahme – nämlich, dass bessere Zusammenarbeit durch gemeinsame Skillsets entsteht. Das ist eine verlockende Idee und wird meist von zwei Gruppen vertreten.

Zum einen von den Hybriden – jenen seltenen Menschen, die beides gut können und glauben, ihre Erfahrung ließe sich mit genug Bootcamps oder Tutorials reproduzieren.

Zum anderen von den Frustrierten, denen, die sich wünschen, „die andere Seite“ würde endlich verstehen, womit sie täglich zu kämpfen haben.

Beide meinen es gut. Aber sie lösen das falsche Problem.

Echte Expertise in Design und Entwicklung entsteht nicht in ein paar Wochen. Sie ist das Ergebnis jahrelanger Erfahrung im Umgang mit Ambiguität – im Erkennen von Mustern, die anderen entgehen. Vor allem, wenn es darum geht, Probleme zu identifizieren, nicht nur zu lösen: Erfahrung ist entscheidend.

Zusammenarbeit scheitert nicht daran, dass Menschen zu wenig vom jeweils anderen Bereich wissen. Sie scheitert daran, dass unsere Rollen auf Übergaben statt auf Verständnis ausgelegt sind.

Und genau das ist das eigentliche Problem.

Das Problem

Das Problem vieler Rollenbilder in Produktteams ist, dass sie auf Lieferung optimiert sind – nicht auf Verständnis. Verantwortung wird entlang von Übergaben organisiert, nicht entlang von Gesprächen. Stakeholder übergeben an „UX/UI“. UX/UI übergibt an Frontend. Frontend übergibt an Backend. Jede Rolle wird zu einer Station in einer Pipeline: linear, getrennt und voneinander entkoppelt.

Diese Struktur setzt voraus, dass Probleme zu Beginn klar definiert sind und jede Übergabe lediglich zusätzliche Präzision bringt. Doch so funktioniert Produktentwicklung nicht. Erkenntnisse entstehen mitten im Prozess. Prioritäten verschieben sich.

Was gebraucht wird, sind nicht reibungslosere Übergaben, sondern Rollen, die auf Interpretation ausgelegt sind, nicht nur auf Ausführung.

Und hier liegt das eigentliche Problem: Zwischen diesen Stationen fehlt etwas Entscheidendes. Spezialisierungen, die verbinden, statt nur weiterzureichen.

Die Trennlinien

Viele Teams kämpfen mit Lücken in Qualität, Klarheit oder Zusammenarbeit. Nicht, weil Menschen unqualifiziert sind, sondern weil ihre Rollen zu breit angelegt sind.

Stellenausschreibungen suchen nach „UX/UI“ und bekommen schwaches UX oder schwaches UI.

Sie suchen nach „Frontend“ und bekommen Entwickler, die APIs anbinden können, aber ein Designsystem nicht umsetzen, ohne es zu zerbrechen.

Das Problem ist nicht Talent. Es ist Struktur.

Was fehlt, ist eine klarere Aufteilung von Verantwortlichkeiten. Die meisten Teams übersehen zwei zentrale Trennlinien, obwohl sie täglich mit ihnen arbeiten:
eine in der Entwicklung, zwischen Model/Controller und View,
und eine im Design, zwischen UX und UI.

Das sind keine theoretischen Kategorien. Es sind unterschiedliche Denkweisen.

Wenn wir diese Unterschiede nicht explizit machen, erwarten wir weiterhin, dass Menschen Lücken schließen, für die sie nie ausgebildet wurden.

Früher war diese Trennung offensichtlich. Als PHP die Logik übernahm und HTML/CSS das Layout, war die Aufteilung im Stack verankert. Heute laufen moderne Frameworks vollständig im Browser. Die Grenzen sind in einer Rolle namens „Frontend“ verschwunden.

Doch das Denken hat sich nicht angepasst.

Wir schreiben View-Code mit einem Model-Denken.

Das ist eine Rückkehr zu etwas, von dem wir dachten, wir hätten es längst hinter uns gelassen: Full Stack.

Zwei Arten von Frontend

Moderne Frontend-Entwicklung bewegt sich in zwei Welten. Aber wir haben nur eine Rollenbezeichnung dafür.

Auf der einen Seite steht die Welt der Logik: Datenmodelle, State Management, APIs, Architektur, Performance.
Auf der anderen Seite die Welt der visuellen Systeme: Layout, Abstände, Interaktion, Barrierefreiheit, Hierarchie.

Beides findet in denselben Dateien statt, verlangt aber völlig unterschiedliche Denkweisen.

Die eine denkt in Abläufen, die andere in Bildern.
Diese Perspektiven unterscheiden sich grundlegend.

Für Entwickler ist eine Basiskomponente ein abstrakter Typ, der viele Varianten unterstützt.
Für Designer ist die Basis der zentrale Anwendungsfall, der sichtbare.

Dieser Unterschied prägt, wie Komponenten aufgebaut werden, wie Tokens benannt sind und wie Defaults gesetzt werden. Fehlende Abstimmung führt zu Reibung. Reibung zu Workarounds. Und Workarounds zu Verschwendung.

Wenn Teams diese Trennung nicht erkennen, versuchen sie, sie mit Tools zu überbrücken: vorgefertigte UI-Kits, Designsysteme „out of the box“, Component Frameworks.

Diese Werkzeuge sind nicht schlecht, werden aber oft genutzt, um Kompetenzlücken zu kaschieren, statt eine Designstrategie zu unterstützen.

Das Ergebnis ist Abhängigkeit statt Klarheit. Komponenten stapeln sich, überschreiben sich gegenseitig, entfernen sich schrittweise von der Marke. Designsysteme werden zu Implementierungshüllen, nicht zu kohärenten, lebendigen Werkzeugen.

Wir brauchen keine Menschen, die beide Welten vollständig beherrschen.
Wir brauchen Rollen, die der tatsächlichen Arbeit entsprechen.

Application Developer sollten sich auf Logik konzentrieren: Modelle, Orchestrierung, Verhalten.
UI Developer auf die Darstellung: Abstände, Tokens, Motion, Systemdenken.

Beides ist Frontend.
Aber es ist nicht dasselbe.

Keine Disziplin, sondern zwei

Der Begriff „UX/UI“ ist so verbreitet, dass er wie ein einzelner Beruf klingt. In der Praxis ist er jedoch meist nur ein anderes Wort für UI.

Die meisten sogenannten UX/UI-Rollen beschäftigen sich mit Screens, Abständen und Interaktionen. Nutzerforschung, Flows und Produktlogik fehlen oft oder werden auf Stakeholder-Input reduziert.

Das Ergebnis: Design ohne Erkenntnis.
Malen nach Zahlen.

UX ist Teil von Design. Aber es funktioniert nicht wie UI.
Während UI sich auf visuelle Systeme konzentriert, arbeitet UX mit Methoden aus Forschung, Analyse und Produktstrategie. UX fragt nach dem eigentlichen Problem, nicht nur danach, wie man das vermeintliche löst.

In diesem Sinne ist UX das, was Design Thinking zu sein vorgibt: ein strukturierter Weg, Bedürfnisse zu verstehen, bevor Lösungen gestaltet werden.

UX bewegt sich näher an Business-Analyse, Requirements Engineering und Systemarchitektur als an visueller Gestaltung. Alle vier beschäftigen sich mit dem, was gebraucht wird.

Aber nur UX stellt die Frage, ob eine Anforderung auf Symptomen oder auf Ursachen basiert.

Das ist kein kreativer Akt.
Es ist ein diagnostischer.

UI dagegen ist expressiv und synthetisch. Es nimmt Rahmenbedingungen und bringt sie in Form. Es arbeitet mit visuellen Systemen, Konsistenz, Mustern und Erfahrung über Zeit.

UX und UI formen zusammen ein Produkt, aber aus entgegengesetzten Richtungen.
Das eine definiert den Problemraum.
Das andere gestaltet seine Oberfläche.

Manche Menschen beherrschen beides. Das macht die Trennung nicht weniger relevant, im Gegenteil. Wenn eine Person beide Seiten verantwortet, verschwinden Konflikte nicht. Sie werden nur unsichtbar.

Strategische Spannungen werden zu inneren Dilemmata.
Und Designentscheidungen entstehen ohne Dialog.

Verständnis statt Verschmelzung

Die Idee, dass Entwickler Design lernen sollten und Designer programmieren, hat nach wie vor ihren Wert.

Aber nicht, weil wir mehr Hybride brauchen.

Es geht nicht darum, Rollen zu wechseln. Es geht darum, gegenseitiges Verständnis aufzubauen.

Die Grundlagen einer anderen Disziplin zu kennen, hilft bei der Zusammenarbeit – nicht dabei, einander zu ersetzen.

Gute Zusammenarbeit entsteht nicht, indem man Rollen in einer Person zusammenführt.
Sie entsteht durch Klarheit.

Menschen brauchen Tiefe im eigenen Handwerk und ein funktionales Verständnis der angrenzenden Disziplin. So entsteht eine gemeinsame Sprache.

Nicht durch identische Fähigkeiten, sondern durch Kontextbewusstsein.

Wenn Teams verstehen, wie ihre Arbeit zusammenhängt, hören sie auf, Dinge über den Zaun zu werfen und beginnen, am selben Produkt zu bauen.

Rollen zu verschmelzen wirkt oft effizient.
In der Praxis erzeugt es Unsicherheit.

Niemand weiß mehr genau, was erwartet wird. Arbeit wird doppelt gemacht oder bleibt liegen. Lücken werden ad hoc gefüllt. Und am Ende fühlt sich niemand wirklich verantwortlich.

Verständnis macht Zusammenarbeit möglich.
Aber Klarheit macht sie produktiv.

Gegenseitiges Verständnis verbessert nicht nur Übergaben. Es verändert auch den Umgang mit schwierigen Aufgaben.

Wenn Entwickler wissen, dass Designer die Komplexität ihrer Anforderungen verstehen, sind sie eher bereit, sich darauf einzulassen.

Respekt macht Anforderungen anschlussfähig.
Was sich wie Reibung anfühlt, entsteht oft nicht aus Faulheit oder Ego, sondern aus fehlendem Kontext.

Von der Pipeline zum Netzwerk

Produktentwicklung verläuft nicht in eine Richtung.
Sie pulsiert, macht Schleifen, verdichtet sich und verzweigt sich wieder.

Die alte Vorstellung eines Prozesses, der von Research über Design zu Entwicklung und schließlich zur Auslieferung führt, passt nicht mehr zu der Art, wie Teams heute arbeiten sollten. Erkenntnisse entstehen spät. Abhängigkeiten verschieben sich.

Was wie eine gerade Linie aussieht, ist in Wirklichkeit ein Geflecht aus überlappenden Entscheidungen, Feedbackschleifen und Iterationen.

Rollen sollten sich nicht aneinanderreihen. Sie sollten miteinander in Beziehung stehen.

UX und Systemarchitektur prägen gleichermaßen, was gebaut wird – und warum.
UI-Design und UI-Entwicklung arbeiten Seite an Seite, um Produkte zum Leben zu bringen.
Application Developer und Backend Engineers stimmen sich über Datenstrukturen und Nutzerlogik ab.

Jede Rolle ist mit anderen verbunden.
Nicht als Schritt in einem Ablauf, sondern als Knoten in einem Netzwerk.

Das Ziel ist nicht länger die effiziente Übergabe, sondern ein gemeinsames Verständnis in einem vernetzten System.

Jede Rolle braucht Tiefe in ihrer eigenen Perspektive und ein Bewusstsein für die angrenzenden. So entsteht Qualität.

Nicht dadurch, dass alle alles machen.
Und nicht durch perfekte Dokumentation.
Sondern durch eine Struktur, in der Menschen in Netzwerken denken, nicht in Pipelines.

Verbundene Rollen, bessere Produkte

Die Spannung zwischen Design und Entwicklung war nie das eigentliche Problem.

Das Problem ist strukturell.

Rollen wurden verwischt, überdehnt oder zusammengelegt. Auf eine Weise, die Kommunikation erschwert und Verantwortung verwässert.

Teams brauchen keine zusätzlichen Hybrid-Skills.
Sie brauchen klarere Rollen und bessere Verbindungen zwischen ihnen.

Das ist kein Rückschritt.
Es ist ein Schritt hin zu der Art, wie moderne Produktteams tatsächlich arbeiten.

Agile Methoden zielten nie darauf ab, alle zu Generalisten zu machen. Es ging um Zusammenarbeit, Iteration und gemeinsame Verantwortung.

All das wird einfacher, wenn Rollen so gestaltet sind, dass sie miteinander interagieren – nicht, dass sie einander ersetzen.

Das fehlende Bindeglied in vielen Teams ist der UI Developer.

Kein Unicorn.
Kein Luxus.

Sondern ein Spezialist, der visuelle Systeme und Code gleichermaßen versteht.

Jemand, der Designentscheidungen in Produktrealität übersetzt.

Fehlt diese Rolle, beginnen Designsysteme zu driften, Component Libraries zu fragmentieren – und Teams lösen Probleme, die sich mit der richtigen Verbindung von Anfang an hätten vermeiden lassen.

Auf den ersten Blick wirkt eine stärkere Rollentrennung teuer: mehr Menschen, mehr Titel, mehr Abstimmung.
Doch der Gewinn ist real.

Weniger Nacharbeit. Schnellere Umsetzung. Weniger Übergaben, die auf dem Weg verloren gehen.

Klare Rollen schaffen Geschwindigkeit durch Fokus und Qualität durch Abstimmung.

Das ist kein Overhead.
Das ist ein Hebel.

Schon mal einer KI eine einfache Frage gestellt und statt einer Antwort legt sie plötzlich los, als müsste sie die Welt retten?

Mir ist das kürzlich mit Cursor AI passiert. Ich wollte nur eine zweite Meinung zu einem Stück Code. Stattdessen fing der Agent an zu programmieren und hatte bereits drei Dateien in die falsche Richtung geändert, bevor ich auf Stopp drücken konnte.

Mein erster Gedanke: Bist du dumm?

Aber dann wurde mir klar: die treffendere Beschreibung war dumm und fleißig.

Und diese Kategorie ist lange bekannt. In Managementkreisen gibt es ein verbreitetes Zitat des Generals Kurt von Hammerstein-Equord.

„Ich unterscheide vier Arten. Es gibt kluge, fleißige, dumme und faule Offiziere. Meist treffen zwei Eigenschaften zusammen. Die einen sind klug und fleißig, die müssen in den Generalstab. Die nächsten sind dumm und faul; sie machen in jeder Armee 90 % aus und sind für Routineaufgaben geeignet. Wer klug ist und gleichzeitig faul, qualifiziert sich für die höchsten Führungsaufgaben, denn er bringt die geistige Klarheit und die Nervenstärke für schwere Entscheidungen mit. Hüten muss man sich vor dem, der gleichzeitig dumm und fleißig ist; dem darf man keine Verantwortung übertragen, denn er wird immer nur Unheil anrichten.“

Meist wird diese kleine Matrix als humorvolle Anekdote aus dem Management erzählt, als eine Möglichkeit für Führungskräfte, über ihren eigenen Stil nachzudenken.

Heute jedoch kann sie einem anderen Zweck dienen: Sie kann uns dabei helfen, strategischer über künstliche Intelligenz nachzudenken.

Die „Dummheit“ der KI

Dummheit ist hier nicht als Beleidigung gemeint, sondern im Sinne Kants, der Dummheit als einen Mangel an Urteilskraft beschreibt. Somit als Unfähigkeit, Wissen sinnvoll anzuwenden.

Große Sprachmodelle sind statistische Maschinen ohne echten Kontext. Sie erzeugen Wörter auf Grundlage von Wahrscheinlichkeitsverteilungen, nicht auf Grundlage von Verständnis. Schon wenige Token genügen, um ganze Handlungsketten auszulösen, doch Zweifel existiert in solchen Systemen nicht. Was wie Intelligenz erscheint, ist in Wirklichkeit unermüdliche Berechnung – ausgeführt ohne Bewusstsein und ohne Zögern. Das kann beeindruckend wirken, doch es als Intelligenz zu bezeichnen, verleiht den Modellen einen Nimbus, den sie nicht verdienen.

Und weil sie statistischen Abkürzungen folgen, wählen sie meist den Weg des geringsten Widerstands. Wenn in den Trainingsdaten Workarounds überwiegen, werden genau diese reproduziert. Strukturelle Ursachen bleiben unangetastet.

Das steht in starkem Gegensatz zu der Art und Weise, wie sich die meisten Unternehmen selbst beschreiben. Mit hochmotivierten Mitarbeitenden und bahnbrechenden Ideen. Beide Eigenschaften gelten als Zeichen von Kreativität und Innovation. In der Natur der KI existieren solche Qualitäten jedoch nicht. Sie hat keine Motivation. Sie erzeugt nichts Originelles. Sie führt Muster mit unermüdlicher Energie aus. Sie ist eine Maschine. Es ist ihr egal.

Das Gegenteil von klug und faul

Der Versuch, diese Dummheit zu überwinden, bringt uns dem idealen Quadranten von klug und faul nicht näher. Er führt uns in die entgegengesetzte Richtung. Jede Erweiterung eines Prompts verstärkt die Scheuklappen des Modells. Jede Iteration stößt auf bestehende Muster in den Trainingsdaten und verstärkt diese. Um den Mangel an Kontext auszugleichen, sind mehr Rechenleistung, mehr Daten und mehr Energie nötig. Das Ergebnis ist keine Eleganz, sondern massiver Aufwand. Statt mit weniger mehr zu erreichen, erreichen wir mit mehr weniger – oder im besten Fall dasselbe.

Angesichts der Tatsache, dass KI-Unternehmen von enormen Kapitalströmen getragen werden, birgt dieses Problem erhebliche Risiken. Die Kosten sind nicht nur heute hoch, sondern auch strukturell unvorhersehbar. Jede neue Modellgeneration erfordert mehr Hardware, mehr Energie und mehr Kühlleistung. Statt sich einer Effizienzgrenze anzunähern, steigt die Kostenkurve weiter an. Ein Ende dieser Richtung ist bisher nicht absehbar.

Das ist kein hypothetisches Szenario, sondern der strukturelle Entwicklungspfad heutiger großer Sprachmodelle. Sie verbessern sich ausschließlich durch statistisches Skalieren: mehr Daten, mehr Parameter, mehr Rechenleistung. Das Ergebnis ist eine Technologie, die umso teurer wird, je mehr man sie nutzt.

Versuche, dieses Problem zu beheben - sei es durch effizientere Architekturen, Retrieval-Augmented Generation oder hybride symbolische Ansätze - bleiben an dasselbe statistische Paradigma gebunden. Sie können die Spirale verlangsamen, ändern aber nicht ihren Verlauf. Die Modelle bleiben fleißig, ohne wirklich klug zu sein. In Hammersteins Worten: Sie verharren im gefährlichsten Quadranten - dumm und fleißig.

Für einzelne Unternehmen entsteht daraus eine strategische Falle. Das Versprechen kurzfristiger Einsparungen kann sich zu einer tiefen Abhängigkeit entwickeln. Sobald Prozesse, Werkzeuge und Fähigkeiten auf KI ausgerichtet sind, können steigende Kosten oder veränderte Rahmenbedingungen diese Abhängigkeit in eine Sackgasse führen. Was heute wie Fortschritt aussieht, kann sich morgen als strategische Belastung erweisen.

Kontrolle rund um die Uhr

Stellen Sie sich vor, Sie hätten eine solche Mitarbeiterin oder einen solchen Mitarbeiter im Team: dumm und fleißig. Sie würden dieser Person niemals die Verantwortung für kritische Projekte überlassen, ohne Kontrolle. Dasselbe gilt für KI. Der Unterschied besteht darin, dass eine KI eventuell weniger Fehler pro Arbeitseinheit macht, aber in einem so großen Umfang produziert, dass die Kontrolle selbst zur Überforderung wird.

Ganz gleich, in welchem Bereich, die Überwachung der Ergebnisse füllt ganze Arbeitstage. Entwicklerinnen bereinigen Code, Journalisten prüfen maschinell erzeugte Fakten. Das erinnert stark an das, was David Graeber in seinem Buch Bullshit Jobs als „Duct-Tapers“ bezeichnet hat – Flickschuster, die an Symptomen statt an Ursachen arbeiten. Für Graeber ist der Begriff Bullshit Job nicht abwertend. Er sorgte sich vielmehr um die Menschen, die in solche Rollen gedrängt werden. Diese Arbeit vergeudet nicht nur vorhandenes Talent, sondern schreckt auch zukünftige Mitarbeitende ab. Wer würde jahrelang studieren, nur um die Arbeit einer Maschine zu korrigieren?

Und dann stellen Sie sich ein Unternehmen vor, dessen verbleibende Belegschaft nur noch weiß, dass etwas funktionieren sollte, aber nicht mehr, wie. Fähigkeiten erodieren, wenn menschliche Arbeit darauf reduziert wird, maschinelle Ergebnisse zu korrigieren oder zu überwachen. Wissen, das einst im Unternehmen fest verankert war, der Ursprung seines Erfolgs, wird schrittweise ausgelagert. Zurück bleibt ein Team, das zwar Knöpfe drücken kann, aber die Grundlagen seiner eigenen Produkte und Dienstleistungen nicht mehr versteht. Was in Schlagzeilen oder sozialen Medien wie Fortschritt wirkt, verdeckt in Wahrheit eine gefährliche Erosion realer Fachkompetenz. Wie sollte sich ein solches Unternehmen weiterentwickeln? Wie könnte es seine Wettbewerber übertreffen, die mit denselben Problemen kämpfen?

Was tun – und was nicht

Was sollten Führungskräfte also konkret tun? Die Antwort lautet nicht, KI zu verbieten, sondern sie klug zu nutzen. Effizienz entsteht, wenn Technologie Menschen unterstützt. Das bedeutet, die eigene Belegschaft mit ihrer Expertise in jede Einführungsentscheidung einzubeziehen, statt Anbietern blind zu vertrauen. Ehrliche Einschätzungen entstehen nur, wenn der Fortschritt als gemeinsames Ziel verstanden wird. Angst vor Stellenabbau hingegen kann diese Offenheit verzerren.

Dabei helfen einige einfache Grundsätze:

• Steigern Sie Effizienz, indem Sie Menschen unterstützen statt sie zu verdrängen.

• Ziehen Sie klare Grenzen: Entwürfe, Prototypen oder Routinetätigkeiten können Aufgaben für KI sein, zentrale Entscheidungen, Compliance oder geistiges Eigentum gehören nicht in Maschinenhand.

• Bewerten Sie Kosten und Risiken fortlaufend. Nicht nur in Bezug auf ROI, sondern auch auf Energieverbrauch, Abhängigkeiten und rechtliche Unsicherheiten.

• Bewahren und pflegen Sie Wissen im Unternehmen, statt es in eine Blackbox auszulagern. Technische Leitplanken können Risiken mindern, ändern aber nicht die grundlegende Abhängigkeit von statistischer Vorhersage.

• Experimentieren Sie im Kleinen und skalieren Sie nur mit Vorsicht.

Und ebenso gilt:

• Verfolgen Sie keine kurzfristigen Einsparungen auf Kosten langfristiger Stabilität.

• Lassen Sie nicht zu, dass Verkaufsversprechen die Expertise der eigenen Leute übertönen.

• Lagern Sie Ihr Kernwissen nicht an eine statistische Maschine aus. Auch nicht, wenn sie mit Sicherheitsmechanismen versehen oder als „enterprise-ready“ vermarktet ist.

• Unterschätzen Sie nicht die versteckten Kosten von Kontrolle, Abhängigkeit und Talentverlust.

• Beachten Sie, dass Trainingsdaten manipuliert werden können, wodurch verborgene Schwachstellen im Betrieb entstehen.

Das sind keine radikalen Forderungen, sondern Leitplanken, die Unternehmen davor bewahren, massive Rechenleistung mit Intelligenz zu verwechseln.

Zurück zu Hammerstein-Equord

Als letzte Empfehlung möchte ich Sie noch einmal an die fast hundert Jahre alte Matrix von Hammerstein erinnern. Wenn sie Ihnen bisher geschmeichelt hat, lassen Sie sich nun auch von ihr leiten, wenn sie Ihnen den scheinbar einfacheren Weg versperrt. Was einst wie eine amüsante Management-Anekdote klang, kann heute als Kompass für strategische Entscheidungen dienen.

Der Quadrant von dumm und fleißig wird nicht weniger gefährlich, nur weil die Energie aus Prozessoren statt aus menschlicher Anstrengung stammt. Diese Einsicht bedeutet nicht, KI abzulehnen, sondern sich der Illusion zu widersetzen, dass unermüdlicher Output mit Intelligenz gleichzusetzen sei.

Hammersteins Gedanke hat überdauert, weil er außerhalb gewohnter Denkmuster lag.
Wenn ein preußischer General die Faulheit loben konnte, sollten es Ihnen leicht fallen, sich nicht von maschineller Betriebsamkeit täuschen zu lassen.

Ich weiß, was ihr denkt: „Nicht schon wieder ein Rant über Liquid Glass.“

Aber wartet kurz, dieser hier ist anders. Wir haben die Beiträge über Lesbarkeit und Geschmack gelesen, über die Windows-Vista-Witze gelacht und uns längst eine Meinung gebildet.

Dieser Text bringt Design und Technik zusammen. Es geht um Standards und Spezifikationen. Und am Ende liefere ich Ihnen eine Pointe, neben der selbst die Vista-Witze alt aussehen. Wir befinden uns in IE6 Terrain.

Exkurs: Was wisst ihr über Viewports?

Ein Viewport ist der Teil des Bildschirms, den eine Website tatsächlich nutzen kann.
Die entscheidende Frage lautet: Was ist die Funktion eines Viewports?

Im Web bezeichnet er den Bereich, den der Browser einer Seite zur Verfügung stellt. Dieser Bereich ist durch Standards definiert und interaktiv. Alles außerhalb gehört zum Betriebssystem.

Im Laufe der Zeit wurden neue CSS-Einheiten eingeführt, um dynamische Viewports abzubilden:

• vh (viewport height): die klassische Einheit, die volle Höhe des Browserfensters

• svh (small viewport height): Höhe bei sichtbarer Browser-UI

• lvh (large viewport height): Höhe bei ausgeblendeter UI

• dvh (dynamic viewport height): passt sich dynamisch an, wenn UI ein- oder ausgeblendet wird. Sie hat es Entwicklern ermöglicht, Overlays – insbesondere auf mobilen Geräten – besser zu optimieren

• Safe Areas: später eingeführt für Notches und abgerundete Ecken, vor allem unter iOS

All diese Einheiten existieren, um die Antwort auf das Was verlässlich zu machen: Was gilt als sichtbarer, interaktiver Bereich einer Website? Apple hat diese Definitionen maßgeblich mitgeprägt.

Aus gestalterischer Sicht ist der Viewport der Rahmen, den der Browser an Designer und Entwickler übergibt. Alles innerhalb gehört zur Seite und kann gestaltet werden. Alles außerhalb gehört zum System.

Diese klare Trennung ist essenziell. Und sie wäre die richtige Antwort auf die Frage gewesen, die sich Apples Designteam hätte stellen müssen:

„Was gestalten wir hier eigentlich?“

Das Problem: Es hätte mit dem „Was?“ beginnen müssen

Hier hätten die Alarmglocken läuten müssen.

Apples Designteam hat nicht damit begonnen zu klären, was sie eigentlich gestalten. Der Fokus lag auf dem Wie. Diese Verschiebung – von Definition hin zu Darstellung – ist die Wurzel des Problems. Und sie zeigt sich inzwischen quer durch Apples gesamte Betriebssystemlinie, mit hoher Wahrscheinlichkeit auch in zukünftigen Versionen.

Die Browser-UI wurde als transparente Schicht neu gedacht.
Visuell schwebt sie über der Seite und lässt Inhalte durchscheinen.

Technisch gehört sie jedoch nicht zum Viewport. Es entsteht ein Pseudo-Viewport.

Das Ergebnis ist ein Widerspruch: Nutzer sehen Inhalte in Bereichen, auf die Entwickler keinen Zugriff haben und die sie nicht kontrollieren können.

Aus gestalterischer Sicht bricht das den grundlegenden Vertrag.
Der Browser liefert keinen neutralen Rahmen mehr. Die Grenze zwischen System und Website verschwimmt – zwischen dem, was zum Inhalt gehört, und dem, was Teil des Betriebssystems ist.

Es werden Elemente sichtbar, die aussehen, als gehörten sie zur Seite, es aber nicht tun.

Millionen von Websites, die für mobile Nutzung optimiert wurden, laufen plötzlich in Darstellungs- und Interaktionsprobleme. Selbst Apples eigene Seite kämpft mit der GUI des eigenen Browsers. Dialoge auf Produktseiten ändern die Theme-Farbe, nur um sich dem Hintergrund des Overlays anzupassen.

Das Ergebnis: eine grellweiße Lücke am unteren Rand einer eigentlich schwarzen Seite – und ein Layoutfehler im Overlay selbst.

Was mit einem fehlenden „Was?“ begann, endet in einem ziemlich lauten WTF.

Stay humble

Design und Entwicklung teilen eine gemeinsame Bürde:
Ihre Arbeit wird erst sichtbar, wenn sie scheitert.

Ein gut funktionierendes UI fällt kaum auf.
Aber es fällt auf, wenn sich ein scrollbares Overlay nicht schließen lässt oder Text schwer lesbar ist.

Deshalb ist es entscheidend, die richtigen Fragen zur richtigen Zeit zu stellen.
Nicht nur, wie etwas aussieht – sondern was es ist, was es tut und für wen es gemacht ist.

Es ist leicht zu vergessen, dass die Aufgabe von UI darin besteht zu dienen, nicht zu glänzen. Vor allem in einer Zeit, in der soziale Medien voller Screenshots von „coolen“ Launch-Screen-Konfigurationen sind.

Im Fall von Liquid Glass hat der visuelle Effekt seine Funktion überlagert. Ein Darstellungsstil hat genau die Regeln außer Kraft gesetzt, auf die Designer und Entwickler angewiesen sind.

Das ist kein mutiges Design.
Das ist Nachlässigkeit.

Es macht den Anschein, dass die Glasbausteine auf der Keynote nicht nur eine Metapher waren.
Sie haben gebaut, was sie gezeigt haben. Und genau dort haben sie den Faden verloren.

Demut ist keine ästhetische Zurückhaltung.
Sie ist Respekt vor dem Kontext, in dem die eigene Arbeit erscheint. Vor Standards. Vor Nutzern. Und vor der Grenze zwischen Sichtbarkeit und Kontrolle.

Das kann am Anfang der eigenen Laufbahn frustrierend sein, wenn man seine gestalterischen Fähigkeiten zeigen möchte. Aber mit der Zeit wird klar: Die eigentliche Leistung besteht darin, Design verschwinden zu lassen – weil es einfach funktioniert.

Und ja, das lässt Raum für starke visuelle Ideen.
Es setzt nur zuerst die richtigen Grenzen.

Lösung: Und jetzt?

Das ist nicht nur eine Designkritik. Es ist ein Appell an die Verantwortung aller Beteiligten.

Nutzer
Wenn Websites, die man regelmäßig nutzt, unter Safaris neuer UI anfangen zu brechen, zu glitchten oder sich seltsam verhalten, wechselt den Browser.

Das ist die einzige Botschaft, die bei Apple ankommt.

Entwickler
Ihr habt drei Optionen: Workarounds bauen. Die Probleme ignorieren und Layoutfehler in Kauf nehmen. Oder das tun, was wir früher gemacht haben, als Kunden auf Support für IE6 bestanden haben: extra berechnen.

Keine dieser Optionen ist gut.
Aber sie bilden die Realität ab.

Apple
Nehmt euch einen Moment. Tretet einen Schritt zurück.
Schaut euch an, was ihr ausgeliefert habt.

Dann geht zurück an eure Schreibtische.
Stellt zuerst die richtige Frage. Und fixt es.

Still und heimlich ist okay.
Aber, bitte richtig.

Und: Stay humble.

Viele sprechen derzeit über Künstliche Intelligenz, als würde mit ihr der große Sprung gelingen.
Die Erwartung: Sie werde lösen, was wir uns selbst nicht mehr zutrauen – weil es zu komplex, zu teuer oder zu langsam ist.
Doch echte Innovation beginnt nicht mit Technologie. Sondern mit dem, was fehlt.

Max Reisböck war gelernter Karosseriebauer bei BMW. Was er brauchte, war nichts Großes. Nur ein Auto mit mehr Platz für seine Familie.

Aber es gab keines.
Nicht im Katalog.
Nicht auf der Roadmap.
Nicht im System.

Also nahm er eine Limousine, schnitt das Dach auf, verlängerte die Karosserie und baute eine Heckklappe ein.

In seiner Freizeit. In einer Garage.
So entstand der erste 3er Touring.

Kein Auftrag. Kein Team. Keine Abteilung. Nur ein Mensch mit einem Bedürfnis und der Bereitschaft, etwas zu tun, das offiziell nicht vorgesehen war.[^ „Manchmal muss man Dinge einfach mal tun: Die Geschichte des ersten BMW 3er Touring“, slideslive.com, Vortrag von Max Reisböck, November 2016]

Das Unternehmen war erst skeptisch. Dann überzeugt.
Heute ist der Touring selbstverständlich.

Vielleicht beginnt echter Fortschritt genau so: Nicht mit Strategien, sondern mit einem Problem. Nicht mit Zielmärkten, sondern mit Wirklichkeit.

Und nicht mit großen Versprechen, sondern mit dem Mut, das Falsche einfach nicht so zu lassen, wie es ist.

Fortschritt oder nur Effizienz?

Max Reisböck war ein leiser Systemsprenger. Nicht, weil er das System kritisieren wollte, sondern weil es für sein Problem keinen vorgesehenen Ort gab.

Er handelte nicht gegen Regeln, aber außerhalb ihrer Logik.
Er tat etwas, das gebraucht wurde, ohne gefragt zu haben, ob es erlaubt war.
Und genau das ist heute selten.

Fortschritt beginnt kaum noch mit einem echten Mangel, sondernmit Zahlen, mit Skalierbarkeit, mit Prozessen. Nicht aus einem Bedürfnis heraus, sondern aus der Logik eines Systems, das sich selbst verwaltet.

Was zählt, ist nicht: Was fehlt?
Sondern: Was lässt sich anschlussfähig planen, messen, vermarkten.

In diesem Denken wird Innovation oft zur Effizienzmaßnahme mit neuem Namen.
Was als „Zukunft“ verkauft wird, ist meist nur die beschleunigte Wiederholung des Bekannten. Und je stärker diese Logik wird, desto passender erscheint eine Technologie wie KI.

Wer diese Logik in Aktion sehen will, muss nur auf das schauen, was ich den Touchscreen-Fetisch nenne.

Eine Technologie, die zur vermeintlichen Formel wurde – nicht wegen ihrer Funktion, sondern wegen ihrer Symbolkraft.

Als das Smartphone seinen Siegeszug antrat, hielten viele Unternehmen den Touchscreen für den digitalen Hammer, und jedes Problem wurde zum Nagel. Touchscreens wurden verbaut, wo immer es möglich war. Und oft genau dort, wo es nicht nur sinnlos, sondern schlicht Unsinn war.

In Fast-Food-Ketten gelten sie als Symbol für Effizienz und helfen tatsächlich, Prozesse zu verschlanken: weniger Personal, weniger Fehlbestellungen, weniger unverkaufte Ware.
Der Touchscreen wird zum Hebel, das gesamte System auf „on demand“ umzustellen.
Was als Beschleunigung verkauft wird, entschleunigt vor allem eines: unsere Erfahrung.
Erst stehen wir vor dem Terminal, dann warten wir auf die Ausgabe. Ausgerechnet dort, wo es einmal schnell gehen sollte, wird der Ablauf zur Geduldsprobe. Und dabei haben wir das Thema Hygiene noch nicht mal angerührt.[^ „Poo found on every McDonald’s touchscreen tested“, metro.co.uk, November 2018]

In Fahrzeugen ersetzten Touchscreens Knöpfe, die man blind bedienen konnte, durch flache Flächen, die volle Aufmerksamkeit fordern.

Lange war das eine Prüfungsfrage im Führerscheinunterricht:
Wie weit fährt ein Auto bei 130 km/h in einer Sekunde, wenn man aufs Radio schaut?

Aus der Ausnahme wurde der Standard. Verpackt in Glas, Design, Animation.
Sie heißt: Touchscreen.[^ „Ablenkung durch moderne Technik“ – Allianz Zentrum für Technik, Studie 2023, azt-automotive.com]

Und ausgerechnet dort, wo Unternehmen einst führend waren, sei es bei Sprachinterfaces im Auto oder bei schnellen Bestellprozessen, gaben sie die Optimierung kampflos auf, um dem Bildschirm zu huldigen.

Fortschritt wurde nicht gestaltet, sondern imitiert.
In Pixeln – nicht in Prinzipien.
In Oberfläche – nicht in Orientierung.

Vielleicht passt die KI so gut, weil sie etwas kann, was das System gelernt hat zu bevorzugen:
Sie erkennt, was da ist. Sie sortiert, verdichtet, optimiert.
Sie fragt nicht nach dem Warum und wird dafür umso bereitwilliger eingesetzt.

Aber was heißt das eigentlich?
Was ist das Wesen dieser Technologie, die so mühelos in die Logik unserer heutigen Wirtschaft passt?

Vielleicht beginnt das Verständnis dort, wo die Daten aufhören und die Muster beginnen.

Denkgrenzen der Maschine

Künstliche Intelligenz kann heute Dinge erkennen, die dem menschlichen Blick lange verborgen geblieben sind.
Sie entdeckt Muster, die zu komplex, zu fein oder zu tief vergraben waren, um sie manuell zu finden.

Das ist beeindruckend und oft nützlich.
Manche nennen es sogar „intelligent“.

Aber es bleibt: Mustererkennung.
Immer auf Basis des Bestehenden.
Immer rückgebunden an das, was schon einmal vorgekommen ist.

Was sie erkennt, war da.
Was sie nicht kennt, bleibt unsichtbar.

KI generiert keine neuen Fragen. Sie formuliert keine Hypothesen, die außerhalb des Datensatzes liegen.
Sie schlägt keine Probleme vor, für die es noch keine Antwort gibt.

Und vielleicht liegt hier eine Grenze, die schwer greifbar ist. Weil sie nicht mit Tempo kollidiert, sondern es still begleitet.
Schleichend, über Jahre, Jahrzehnte, vielleicht noch mehr.

Eine Bewegung, die aussieht wie Fortschritt. Aber endet in einer sehr langen Sackgasse.
Denn solange der Mensch noch träumt, speist er das System mit dem, was es nicht kennt.

Aber wenn wir aufhören, neue Fragen zu stellen – weil die Maschine uns so viele Antworten gibt – dann endet irgendwann auch der Fortschritt.

Nicht plötzlich. Nicht sichtbar.
Sondern leise. Als allmähliches Verschwinden des Neuen.

Und genau deshalb ist ihr Fortschritt, ohne den Menschen, endlich.
Nicht, weil sie versagt. Sondern weil wir vergessen könnten, was jenseits des Bestehenden liegt.

Das ist keine Schwäche.
Es ist ihre Natur.

Die menschliche Lücke

Die KI erkennt, was war. Sie findet Muster, ordnet sie, optimiert.
Doch sie weiß nicht, wozu.

Sie kann keine Unterscheidung treffen zwischen dem, was nur effizient ist, und dem, was tatsächlich verändert werden muss.

Sie fragt nicht, ob sie ein Symptom mildert – oder eine Ursache löst.
Weil sie nichts will.

Der Mensch kann das. Zumindest: Er könnte.
Nicht, weil er mehr Daten hat, sondern weil er ein Gefühl für Lücke kennt.

Für das, was fehlt, obwohl es nicht messbar ist.
Für das, was stört, obwohl es nicht erklärbar ist.
Für das, was gebraucht wird, obwohl es noch keinen Namen hat.

Der Mensch kennt Mangel.[^ Mangel als Motor: Nicht die Verfügbarkeit von Ressourcen, sondern die Lücke im Bestehenden erzeugt Innovation – vgl. Ernst Bloch: Das Prinzip Hoffnung.]
Nicht nur als Defizit, sondern als Impuls.

Er leidet, er sehnt sich, er stellt sich vor, wie etwas anders sein könnte.

Und manchmal reicht genau das:
Nicht mehr weiterwissen, aber etwas wollen, das es noch nicht gibt.

Was wir als Fehler erleben – Widerspruch, Irritation, Bruch – ist für die Maschine ein Störsignal. Für den Menschen kann es der Anfang sein.

Nicht jeder Zweifel führt zur Erkenntnis. Aber ohne Zweifel gibt es keine.

Vielleicht ist genau das die Lücke: Die Maschine rechnet, der Mensch träumt.

Aber wenn wir vergessen, dass Träumen eine Fähigkeit ist, dann wird auch sie irgendwann nur noch wie ein Fehler wirken.

Was wir Fortschritt nennen, war selten nur ein einzelner Gedanke.
Es war das, was entsteht, wenn viele ihre eigenen Lücken ernst nehmen und daraus gemeinsam eine neue Wirklichkeit bauen.

Nicht berechnet.
Nicht wahrscheinlich.
Sondern gewollt.

Der Ursprung des Neuen

Benjamin Franklin baute keinen Blitzableiter[^ Franklin veröffentlichte seine Theorie zum Blitz 1750. Die erste öffentliche Ableitung mit Blitzableiter gelang 1752. Seine Experimente verbanden Wissenschaft, Schutz und Politik.], weil er ein Start-up gründen wollte.
Sondern weil Menschen starben und keiner verstand, warum.

Was er schuf, war mehr als ein Werkzeug.
Es war ein Eingriff in das Weltbild:
Der Blitz war nicht länger göttlicher Zorn, sondern ein Phänomen, das sich verstehen und umlenken ließ.

So beginnt echter Fortschritt: Nicht in der Arbeit an einer Lösung, sondern beim verstehen des Problems.

Doch genau dort hält sich wirtschaftliches Denken heute kaum auf, und mit ihm eine Logik, die längst über große Unternehmen hinauswirkt.

Es will Wirkung – ohne Irritation.
Antworten – ohne Unklarheit.

Und so wird auch das Neue oft behandelt wie das Alte: planbar, effizient, anschlussfähig.

Design Thinking sollte einmal lehren, anders zu denken. Eine Methode, die versprach, neue Perspektiven zu öffnen.

Aber was bleibt von ihr, wenn sie auf ein System trifft, das schon vor dem Denken weiß[^ Design Thinking als Methode lebt vom offenen Problemraum, wird aber oft als Mittel zur Absicherung von Entscheidungen missverstanden.], was rauskommen soll?
Ein Hype mit leerem Versprechen.

Heute ist es ein Format – effizient, anschlussfähig, ohne Tiefgang.
Man lädt Coaches ein, inklusive Post-its, Sharpies – manchmal auch Lego-Steine.[^ ‚Serious Play‘: ursprünglich als Kreativtechnik gedacht, heute oft Symbol für simulierte Innovationsbereitschaft.]

Zwei Tage lang denkt man „ganz anders“.
Mit Kollegen, die man sonst nur aus der Kantine kennt.
Es fühlt sich gut an. Als würde man gerade das Unternehmen neu erfinden.

Ein schöner Wochenausklang und am Montag darauf sitzt man wieder in denselben Meetings mit denselben PowerPoint-Folien und denselben Erwartungen.

Design Thinking war ein Angebot, den Problemraum zu betreten.
In vielen Unternehmen wird es eingekauft ohne den Sinn zu verstehen.

Denn das Corporate Mindset will nicht denken. Es will rechnen.

Es versteht Ideen nur, wenn sie anschlussfähig sind.
Es versteht Veränderung nur, wenn sie vorher schon geklärt ist.

Verantwortung in unserer Zeit

Ideen gibt es viele.
Auch der Wille, etwas zu verändern, ist nicht selten.
Aber wer entscheidet eigentlich noch?

In vielen Unternehmen wollen alle mitreden, aber kaum jemand will verantwortlich zeichnen.

Entscheidungen werden vorbereitet, verwaltet, vorsortiert – und am Ende bleibt ein Feld aus Ja-oder-Nein-Fragen.[^ In komplexen Systemen tendieren Entscheidungsprozesse zur Binarisierung – aus Steuerbarkeit, nicht aus Klarheit.]

Keine offenen Optionen. Kaum echte Alternativen.
Verantwortung klingt gut. Solange sie niemand tragen muss.
Vor allem nicht dort, wo sie unbequem wird: bei Entscheidungen ohne Gewissheit, mit langfristiger Wirkung, aber kurzfristigem Risiko.

Wer heute Unternehmen führt, entscheidet meist nicht über Richtung.
Sondern über Tempo. Über Formulierungen. Über Takt.
In KPIs, Reports und Märkten, die sofort reagieren, aber selten zuhören.

CEOs sind in der Regel keine Eigentümer. Sie sind angestellt. Bewertet. Austauschbar.
Ihre Aufgabe: oft nicht aufzubrechen, sondern anschlussfähig zu bleiben. Und dabei Ausgleich zu schaffen – zwischen Investoren und Belegschaft, zwischen Innovation und Risiko, zwischen Geschwindigkeit und Substanz.

Vor dem Siegeszug des Neoliberalismus war der Finanzmarkt ein dienender Sektor.
Heute bewegt er ein Vielfaches der realen Wirtschaft.

Kapital war einmal Treibstoff. Heute gibt es den Takt vor und misst Erfolg oft im Quartal, nicht im Jahrzehnt.

Und dieser Takt reicht weiter, als wir denken.
Er formt Entscheidungen, noch bevor sie getroffen werden.
Verantwortung wird nicht mehr verweigert, sie wird strukturell vermieden.

Und genau hier liegt die Gefahr auch im Umgang mit KI.

Wer Entscheidungen nur im Takt der Quartale trifft, wird versucht sein, KI nicht als langfristige Infrastruktur zu begreifen. Sondern als kurzfristigen Hebel. Ein Tool zur Effizienzsteigerung. Ein Sparprogramm in schicker Verpackung.[^ Künstliche Intelligenz wird oft als Innovation verkauft – aber als Kostensenkung implementiert.]

Doch Künstliche Intelligenz ist kein Add-on. Sie ist eine Grundsatzentscheidung.
Ein System, das tief in Prozesse eingreift.
Wer hier nur operativ denkt, riskiert strukturelle Abhängigkeit: von Anbietern, deren Interessen nicht immer offenliegen. Von Modellen , deren Logik nicht nur intransparent ist, sondern potenziell von außen beeinflusst.[^ Als „Data Poisoning“ bezeichnet man gezielte Versuche, die Trainings- oder Nutzungsdaten von KI-Modellen zu manipulieren, um ihr Verhalten zu beeinflussen. Bei Sprachmodellen kann dies durch massenhaft veröffentlichte, strategisch formulierte Texte geschehen, mit dem Ziel, sie in das System einzuschleusen und spätere Antworten zu prägen.]
Von Plattformen, die sich als Helfer präsentieren, aber Infrastruktur ersetzen.

Was wir brauchen, ist nicht nur Technologieeinsatz, sondern Technologiepolitik.

Einen Plan, der über das nächste Release hinausgeht. Eine Idee davon, was KI in fünf oder zehn Jahren für unsere Wirtschaft bedeuten soll. Nicht als Showroom-Projekt. Sondern als strategische Architektur.

KI als Wandel

KI muss uns nicht ersetzen. Sie kann uns stärken.

Nicht im Sinne von: effizienter mit KI arbeiten. Sondern: gemeinsam denken, gestalten, erweitern.
Ko-Kreativität: nicht als Methode, sondern als Haltung.

Denn Sinn entsteht nicht aus Berechnung. Er entsteht dort, wo Menschen Fragen stellen, Zweifel zulassen, neu anfangen.

Wenn das aufhört, bleibt nur Wiederholung.

Gleichzeitig kann KI entlasten.

Nicht durch Convenience, sondern durch Vereinfachung.
Sie kann helfen, das abzutragen, was Arbeit lähmt: Dokumentation, Berichtspflicht, Systempflege – all das, was Pflicht ist, aber nie Kür. Nicht das, wofür Menschen angestellt wurden, aber das, was ihre Zeit frisst.

Wenn diese Schichten dünner werden, entsteht Raum. Für Sinn. Für Orientierung.
Für eine Wirtschaft, die nicht nur skaliert, sondern fragt: Wofür?

Unsere Hoffnung, unser Versprechen

Max Reisböck wollte kein Innovationsprojekt starten.
Er wollte nur ein Auto, das es noch nicht gab.
Er baute es. in seiner Freizeit, in einer Garage.

Und dann brachte er es zu BMW.
Sein direkter Vorgesetzter erkannte sofort, was da entstanden war und setzte alle Hebel in Bewegung.

Am zweiten Tag kam der Vorstandsvorsitzende persönlich in die Werkstatt. Er sah das Auto. Reagierte emotional. Reichte Reisböck die Hand.

Was aus dieser Geste sprach, war mehr als Zustimmung.
Es war Resonanz.
Ein Moment, in dem das System, für einen kurzen Augenblick, offen war für etwas, das es nicht vorhergesehen hatte.

Heute hätte Reisböck vielleicht einen digitalen Assistenten.
Er könnte Skizzen generieren, Material berechnen, Simulationen erstellen.
Sein Möglichkeitsraum wäre größer denn je.

Aber vielleicht hätte er heute auch keinen Ansprechpartner mehr. Keine Abteilung, die zuständig ist für das, was noch keinen Namen hat.

Vielleicht wäre sein Job längst wegrationalisiert worden.
Und vielleicht gäbe es niemanden mehr, der sagt: „Gut gemacht.“

KI wird Wandel bringen. Das ist keine Frage.
Aber ob sie uns weiterbringt, hängt nicht davon ab, wie leistungsfähig sie ist. Sondern davon, wie wir sie einsetzen.

Nicht nur zum Optimieren. Sondern zum Entdecken.
Nicht nur für Effizienz. Sondern für Möglichkeiten.

Wenn wir ernst meinen, was in Leitbildern steht – Verantwortung, Kreativität, mündige Mitarbeitende – dann sollte KI nicht weniger davon verlangen. Sondern mehr davon ermöglichen.

Vielleicht beginnt echter Fortschritt auch morgen nicht mit einem Datensatz. Sondern mit einem Menschen, der etwas sieht, das noch fehlt.
Und einem System, das neugierig genug ist, zuzuhören.

Nicht Systeme, die alles wissen.
Sondern Systeme, die bereit sind, Neues zu lernen.