Use-Cases sind der Anfang, nicht das Ziel

Wie konkrete KI-Projekte schrittweise organisatorische Fähigkeiten aufbauen können.

Warum konkrete KI-Use-Cases ein sinnvoller Ausgangspunkt sind und wie Unternehmen daraus wiederverwendbare organisatorische Fähigkeiten entwickeln können.

Warum Unternehmen mit Use-Cases beginnen

Das Muster ist inzwischen vertraut. Ein Unternehmen lädt zu einem KI-Workshop ein. Auf den Tischen liegen digitale Haftnotizen, in den Arbeitsgruppen entstehen Longlists, danach werden die Ideen in einer Matrix nach Nutzen und Machbarkeit sortiert. Zusammenfassungen, Wissenssuche, Prognosen, Dokumentenprüfung, Kundenkommunikation. Am Ende stehen vielleicht 40 Use-Cases, fünf Favoriten und der Auftrag, schnell einen Pilot zu bauen.

Anlass für diesen Text war auch ein Beitrag ehemaliger Kolleginnen und Kollegen bei McKinsey. In Capturing Central Europe’s AI opportunity argumentieren Czímer, Van der Veken, und Zetek (2026), dass Unternehmen KI nicht als Nebeninitiative behandeln sollten, sondern Geschäftsbereiche und Arbeitsabläufe um KI herum neu gestalten müssen. Neuere McKinsey-Veröffentlichungen führen denselben Gedanken weiter: Wert entsteht demnach weniger durch zusätzliche Werkzeuge als durch veränderte Arbeitsabläufe, Organisationsmodelle, Verantwortlichkeiten und Fähigkeiten (Schmitz u. a. 2026; De Smet u. a. 2026; Weddle 2026). Ich teile den Kern dieser Beobachtung, würde sie aber weniger als Aufforderung zu einem umfassenden Transformationsprogramm lesen. Interessant ist aus meiner Sicht vor allem die Frage, wie Unternehmen von konkreten Anwendungsfällen zu verlässlichen organisatorischen Fähigkeiten kommen.

Dieser Einstieg ist zunächst vernünftig. Die Frage „Wo können wir KI einsetzen?“ übersetzt eine abstrakte Technologie in einen betrieblichen Zusammenhang. Sie schafft Gesprächsanlässe zwischen Fachbereichen, IT, Data Science und Führung. Zudem führt sie schneller zu überprüfbaren Annahmen als eine KI-Strategie, die vor allem aus Zielbildern und Reifegradmodellen besteht.

Dabei beobachte ich ein wiederkehrendes Problem. Manche Unternehmen behandeln die Use-Case-Liste bereits als Strategie. Sie sammeln Ideen und bauen Prototypen, ohne zu klären, wie sich Prozesse, Rollen, Datenzugänge, Kontrollen und Betriebsverantwortung verändern müssen. In solchen Fällen wächst die Zahl der Piloten, während die Fähigkeit zum dauerhaften Einsatz von KI weitgehend unverändert bleibt.

Aus meiner Sicht sollten Unternehmen deshalb mit konkreten KI-Use-Cases beginnen, diesen Einstieg aber als Teil eines längeren Lernprozesses verstehen. Gut gewählte Anwendungsfälle können schrittweise Veränderungen an Prozessen, Zuständigkeiten und Infrastruktur auslösen. Transformation entsteht dann aus der Bearbeitung konkreter Probleme und nicht unabhängig von ihnen.

Warum der Einstieg richtig ist

KI wird erst in einer konkreten Arbeitssituation beurteilbar. „Wir nutzen ein Large Language Model“ sagt wenig. „Wir verkürzen die Prüfung eingehender Vertragsentwürfe, markieren unsichere Passagen und lassen sie durch eine Juristin freigeben“ beschreibt dagegen einen Prozess, Nutzende, eine erwartete Wirkung und eine Grenze der Automatisierung.

Gute Use-Cases erfüllen dabei mehrere Funktionen. Sie schaffen zunächst Anschlussfähigkeit, weil ein Fachbereich keine Modellarchitektur verstehen muss, um über Wartezeiten, Fehler oder wiederkehrende manuelle Arbeit zu sprechen. Sie machen den erwarteten Nutzen überprüfbar, indem sich Bearbeitungszeit, Qualität, Durchlaufzeit oder Fehlerrate mit einer Baseline vergleichen lassen. Außerdem legen sie Abhängigkeiten offen: Am konkreten Fall zeigt sich, ob die notwendigen Daten zugänglich, aktuell und rechtmäßig nutzbar sind. Schließlich müssen Zuständigkeiten geklärt werden. Es wird konkret, wer das Ergebnis nutzt, bei Fehlern eingreift und über Änderungen entscheidet. Technische, regulatorische und organisatorische Grenzen werden dadurch während der Arbeit sichtbar.

Diese Konkretheit ist gerade deshalb wichtig, weil die Verbreitung von KI schnell zunimmt, aber keineswegs gleichmäßig erfolgt. Nach OECD (2026) nutzten 2025 in den erfassten Ländern 20,2 Prozent der Unternehmen KI; bei großen Unternehmen waren es 52,0 Prozent, bei kleinen 17,4 Prozent. Hinter dem Durchschnitt verbergen sich also sehr unterschiedliche Voraussetzungen. Ein pauschales Transformationsrezept wäre schon deshalb wenig überzeugend.

Auch Produktivitätseffekte entstehen nicht einfach durch den Zugang zu einem Modell. In einer großen Feldstudie mit 5.172 Beschäftigten im Kundensupport zeigen Brynjolfsson, Li, und Raymond (2025), dass ein generativer KI-Assistent die Zahl gelöster Fälle pro Stunde im Durchschnitt um 15 Prozent erhöhte. Die Effekte waren besonders bei weniger erfahrenen Beschäftigten groß und bei sehr erfahrenen gering. Das ist ein belastbarer Befund für einen spezifischen, in den Arbeitsablauf eingebetteten Einsatz – kein Beleg für eine automatische Produktivitätssteigerung in jedem Unternehmen.

Wo der Use-Case-Ansatz an Grenzen stößt

Ein Prototyp untersucht meist, ob ein Modell eine Aufgabe grundsätzlich bearbeiten kann. Für ein produktives System müssen zusätzlich Datenzugriff, Prozessintegration, Verhalten bei Unsicherheit oder Ausfall, Qualitäts- und Kostenkontrolle sowie die Verantwortung nach dem Projekt geklärt werden.

An diesem Übergang bleiben viele Vorhaben stehen. Erkennbar wird dies beispielsweise an manuellen Datenexporten, individuellen Prompts ohne Versionierung, unklaren Rollen- und Rechtekonzepten oder fehlender Integration in die tatsächlich genutzten Systeme. Häufig fehlen außerdem ein kontinuierliches Monitoring von Qualität und Kosten sowie eine benannte Verantwortung für Betrieb und Weiterentwicklung. Aus einem technisch funktionierenden Proof of Concept wird unter diesen Bedingungen noch keine verlässliche Anwendung.

Eine Demo kann all das ausblenden. Ein kleines Team lädt Beispieldokumente hoch, korrigiert problematische Eingaben von Hand und präsentiert die besten Ergebnisse. Das ist für frühes Lernen legitim. Problematisch wird es, wenn diese kontrollierte Situation mit betrieblicher Reife verwechselt wird.

Eine aktuelle McKinsey-Befragung illustriert diese Lücke: McKinsey & Company (2025) berichten, dass fast zwei Drittel der Befragten angaben, ihre Organisation habe KI noch nicht unternehmensweit skaliert. Das ist eine Beratungsstudie mit Selbstauskünften, keine neutrale Vollerhebung. Sie beweist auch nicht, dass jedes Unternehmen möglichst schnell breit skalieren sollte. Der Befund passt aber zu einem bekannten Muster: Nutzung und Experimentierfreude wachsen schneller als die organisatorische Einbettung.

Die im Juni 2026 veröffentlichte Deutschland-Studie Produktivität. Neu gedacht. differenziert diese Zwischenstufen weiter: McKinsey & Company (2026) berichten, dass von 80 befragten CxOs 26 Prozent ihr Unternehmen der Pilotphase zuordneten, 47 Prozent von einer aktiven Skalierung berichteten und 11 Prozent ihre Organisation als „KI-first“ bezeichneten. Die Autoren weisen selbst darauf hin, dass die Befragung nicht repräsentativ ist; 51 Prozent der Teilnehmenden arbeiten in Unternehmen mit mehr als fünf Milliarden Euro Umsatz. Die Zahlen sind daher kein Zustandsbild der deutschen Wirtschaft. Interessant ist vielmehr die begriffliche Lücke zwischen Piloten ausrollen und KI tatsächlich in Kernprozessen und Entscheidungen zu verankern.

Diese Lücke taucht auch in neueren McKinsey-Beiträgen wieder auf. De Smet u. a. (2026) unterscheiden drei Horizonte von Enablement, Automation und Reinvention und berichten aus einer Befragung von 750 Beschäftigten, dass Führungskräfte deutlich häufiger unternehmensweiten Nutzen sehen, wenn Workflows neu gestaltet werden, statt nur Werkzeuge bereitzustellen. Schmitz u. a. (2026) formulieren denselben Punkt organisatorisch: Viele Unternehmen beschleunigen bestehende Tätigkeiten, ohne Entscheidungswege, Governance, Teams und Fähigkeiten anzupassen. Für meinen Punkt ist daran weniger die einzelne Prozentzahl entscheidend als die wiederkehrende Diagnose: Der Engpass liegt häufig nicht beim Modellzugang, sondern bei der Veränderung der Arbeit.

Die Studie fordert zugleich, KI als „neues Betriebssystem“ des Unternehmens zu verstehen. Als Bild macht das die organisatorische Reichweite von KI sichtbar. Als Handlungsanweisung ist es mir zu pauschal. Nicht jedes Unternehmen und nicht jeder Prozess muss „KI-first“ werden. Entscheidend ist, ob ein konkreter Einsatz einen besseren Prozess erzeugt und ob die dabei aufgebauten Fähigkeiten auch anderswo sinnvoll nutzbar sind. Die Transformation darf nicht zum Selbstzweck werden.

Dabei ist zu beachten, dass nicht jeder Pilot in den produktiven Betrieb übergehen muss. Auch ein bewusst beendetes Experiment kann wertvoll sein, wenn es eine überprüfbare Annahme widerlegt, ein Risiko sichtbar macht oder eine wiederverwendbare Erkenntnis erzeugt. Wichtig ist eine nachvollziehbare Entscheidung über die Fortführung, Anpassung oder Beendigung des Vorhabens.

Lehren aus Analytics-Transformationen

Die Spannung zwischen Einzelprojekt und Transformation ist nicht neu. Data Warehouses sollten eine verlässliche Datenbasis schaffen. Business Intelligence sollte Entscheidungen transparenter machen. Data Lakes versprachen flexiblen Zugang, Advanced Analytics bessere Prognosen. Viele Organisationen investierten in Plattformen, Dashboards und zentrale Teams – und stellten trotzdem fest, dass Entscheidungen nicht automatisch datengetriebener wurden.

Eine Erklärung hierfür liegt im Zusammenspiel von Technologie und Organisation. Brynjolfsson und Hitt (2000) zeigen, dass der Wert von IT-Investitionen wesentlich von komplementären Investitionen in Prozesse, Fähigkeiten und Organisationsstrukturen abhängt. Mikalef u. a. (2020) beschreiben Big-Data-Analytics als organisationale Fähigkeit, in der technische, personelle und managementbezogene Ressourcen zusammenwirken.

Auf der anderen Seite waren große Transformationsprogramme ohne konkrete Anwendungen ebenfalls keine Garantie für Veränderung. Eine zentrale Datenplattform kann technisch eindrucksvoll und für die Fachbereiche trotzdem bedeutungslos sein. Ein Center of Excellence kann Standards formulieren, ohne einen einzigen operativen Prozess zu verbessern. Vial (2019) definiert „Digital Transformation“ gerade nicht als bloße Einführung neuer Technologie, sondern als Veränderungen, die durch die Kombination digitaler Technologien ausgelöst werden. Das Ergebnis darf daher nicht mit dem Technologieprojekt verwechselt werden.

Aus meiner Sicht folgt daraus, dass Unternehmen nicht zuerst eine möglichst umfassende KI-Plattform aufbauen sollten. Ein konkreter Use-Case kann vielmehr als praktischer Prüfstand dienen. An ihm zeigt sich, ob Daten verfügbar sind, Entscheidungen verändert werden, Mitarbeitende das System sinnvoll nutzen und die Organisation den Betrieb tragen kann. Gleichzeitig sollte ein erfolgreich bearbeiteter Fall Komponenten, Standards oder Erfahrungen hinterlassen, die bei weiteren Anwendungen wiederverwendet werden können.

Zusätzliche Anforderungen durch generative KI

Klassische Analytics-Systeme lieferten häufig Informationen oder Prognosen. Generative KI greift breiter in Wissensarbeit ein: Sie formuliert Texte, verdichtet Dokumente, bereitet Entscheidungen vor, erzeugt Code und kommuniziert mit Nutzenden. KI-Agenten gehen einen Schritt weiter. Sie können Werkzeuge aufrufen, Daten abfragen, Vorgänge anlegen oder mehrstufige Abläufe koordinieren.

In einem Beitrag für The European Business Review haben Niessing, Feldmann, und Bücker (2026) diesen Übergang als Verschiebung von Piloten zu Pipelines beschrieben. Der Begriff Pipeline ist dabei nicht nur technisch gemeint. Er bezeichnet einen gestalteten Ablauf mit Rollen, Eingaben, Prüfungen, Übergaben und messbaren Ergebnissen. Für den vorliegenden Text ist daran vor allem wichtig, dass agentische KI nicht als zusätzlicher Chatbot neben dem Prozess verstanden werden sollte, sondern als Teil eines bewusst entworfenen Arbeitsablaufs.

Damit wächst die organisatorische Reichweite. Ein isolierter Chatbot verarbeitet Eingaben und erzeugt Antworten. Ein Agent, der Kundendaten liest, eine Kulanzentscheidung vorbereitet und eine Buchung im operativen System auslöst, benötigt dagegen Identitäten, Berechtigungen, Protokollierung, Grenzwerte und einen definierten Eskalationsweg. Fehler können sich in diesem Fall über mehrere verbundene Systeme fortsetzen.

Der häufig verwendete Begriff „Human in the loop“ bezeichnet die Einbindung eines Menschen in einen automatisierten Ablauf. Für ein Betriebskonzept reicht diese Bezeichnung allein nicht aus. Es muss festgelegt werden, welche Person welche Ergebnisse anhand welcher Informationen und innerhalb welcher Zeit prüft. Ebenso sind der Entscheidungsspielraum, die Erkennung systematischer Fehler und die Untersuchung von Vorfällen zu definieren. Menschliche Kontrolle ist damit ein gestalteter Prozess.

Das von Tabassi (2023) veröffentlichte NIST-Rahmenwerk ordnet KI-Risikomanagement in die vier Funktionen govern, map, measure und manage ein und behandelt Governance als fortlaufende Querschnittsaufgabe. Diese Logik ist auch jenseits formaler Compliance nützlich: Risiken müssen einem Kontext zugeordnet, messbar gemacht, behandelt und organisatorisch verantwortet werden. Das lässt sich nicht nachträglich an ein fertiges Modell ankleben.

Kriterien für einen tragfähigen KI-Use-Case

Viele Priorisierungsmatrizen bewerten nur erwarteten Nutzen und technische Machbarkeit. Das reicht für eine erste Sortierung, bevorzugt aber leicht demonstrierbare Ideen. Ein guter KI-Use-Case sollte aus meiner Sicht elf Fragen beantworten:

1. Problem: Welches konkrete Problem wird gelöst – und für wen?
2. Prozess: Welche Entscheidung oder welcher Arbeitsschritt verändert sich?
3. Baseline: Wie gut, schnell oder teuer ist der heutige Ablauf?
4. Nutzen: Wie häufig tritt der Prozess auf, wie viel Zeit oder Geld bindet er heute, und welche Verbesserung würde den Use-Case wirtschaftlich oder organisatorisch rechtfertigen?
5. Daten: Welche Daten werden benötigt, und darf das System sie nutzen?
6. Qualität: Mit welchen Tests und Kennzahlen wird die Leistung beurteilt?
7. Risiko: Welche Fehler sind wahrscheinlich, und welche wären besonders folgenreich?
8. Kontrolle: Wo entscheiden Menschen, wo automatisiert das System, und wie wird eskaliert?
9. Betrieb: Wer verantwortet Kosten, Monitoring, Vorfälle und Weiterentwicklung?
10. Integration: Wie gelangt das Ergebnis ohne Medienbruch in den realen Workflow?
11. Wiederverwendung: Welche Datenzugänge, Komponenten, Standards oder Fähigkeiten bleiben für weitere Fälle erhalten?

Ein Demo-Use-Case ist auf den Nachweis einer technischen Möglichkeit ausgerichtet. Er arbeitet häufig mit ausgewählten Beispieldaten und endet an der Modellantwort. Das kann in einer frühen Erkundungsphase sinnvoll sein. Für einen tragfähigen Use-Case muss zusätzlich geklärt werden, wie das Ergebnis in eine reale Entscheidung einfließt, wie es gegenüber einer Baseline bewertet wird und wer die fachliche Verantwortung übernimmt.

Der englische Begriff Ownership bezeichnet in diesem Zusammenhang die dauerhafte fachliche Verantwortung. Diese geht über das Sponsoring und die Bereitstellung eines Budgets hinaus. Die IT kann ein System betreiben und Data Science kann es evaluieren. Die Verantwortung dafür, ob es fachlich sinnvoll arbeitet und welche Folgen seine Ausgabe haben darf, muss jedoch im jeweiligen Prozess verankert sein.

Use-Cases als Ausgangspunkt für den Fähigkeitsaufbau

Mit Use-Case-first meine ich ein Vorgehen, bei dem die Arbeit an wenigen konkreten Anwendungsfällen beginnt. Dabei sollte bereits berücksichtigt werden, welche gemeinsamen technischen und organisatorischen Fähigkeiten später benötigt werden. Dieses Vorgehen vermeidet lange Vorlaufzeiten für eine umfassende Zielarchitektur, ohne die einzelnen Projekte voneinander zu isolieren. Sinnvoll ist aus meiner Sicht ein kleines Portfolio unterschiedlich gelagerter Fälle, die einen überprüfbaren Nutzen versprechen und zugleich gemeinsame Fähigkeiten aufbauen.

Die folgende Abbildung fasst diese Logik zusammen. Ein Use-Case beginnt mit einem konkreten Problem, wird über Evaluation und Integration in eine produktive Anwendung überführt und hinterlässt im besten Fall eine wiederverwendbare Fähigkeit. Diese Fähigkeit fließt anschließend in weitere Fälle zurück.

Abbildung 1: Vom einzelnen Use-Case zur wiederverwendbaren organisatorischen Fähigkeit

Hilfreich ist dabei der Begriff der Domain, also eines fachlich zusammenhängenden Verantwortungsbereichs wie Vertrieb, Kundenservice, Supply Chain, Engineering oder Schadenbearbeitung. Czímer, Van der Veken, und Zetek (2026) argumentieren, dass solche Domänen groß genug sind, um finanziell relevant zu sein, zugleich aber überschaubar genug, um Arbeitsabläufe Ende zu Ende neu zu gestalten. Das passt gut zum Use-Case-first-Gedanken: Der einzelne Use-Case sollte nicht isoliert optimiert werden, sondern innerhalb einer Domäne zeigen, welche Daten, Rollen, Schnittstellen und Kontrollmechanismen dauerhaft benötigt werden.

Ein Beispiel hierfür ist eine Folge von drei Anwendungsfällen. Der erste produktive Fall etabliert einen geregelten Zugriff auf interne Dokumente. Der zweite nutzt dieselbe Identitäts- und Rechtearchitektur und ergänzt eine systematische Evaluation. Der dritte verbindet das Modell über eine Programmierschnittstelle mit einem operativen System und führt Audit-Logs ein. Auf diese Weise entsteht schrittweise eine Plattformfähigkeit als verallgemeinerte Lösung bereits bearbeiteter Probleme. Diese Logik passt auch zum Argument von Singla u. a. (2026) und Czímer, Van der Veken, und Zetek (2026), dass erfolgreiche Unternehmen nicht viele beliebige Use-Cases parallel ausrollen, sondern wenige wirtschaftlich relevante Domänen auswählen und dort wiederverwendbare Fähigkeiten aufbauen.

Der Rückkopplungseffekt ist hierbei zentral. Neben dem unmittelbaren Ergebnis sollte jeder Use-Case die Organisation in einem abgegrenzten Bereich handlungsfähiger machen. Je nach Fall können verlässliche Daten- und API-Zugänge, Rollen- und Rechtekonzepte, Evaluations- und Freigabestandards oder ein geregeltes Prompt- und Modellmanagement entstehen. Bei stärker integrierten Anwendungen kommen Human-in-the-loop- und Eskalationsprozesse, Monitoring, Audit-Logs und eine klare Betriebsverantwortung hinzu. Auch AI Literacy, also die Fähigkeit, KI-Systeme im jeweiligen Arbeitskontext sachgerecht zu nutzen und zu beurteilen, gehört zu diesen wiederverwendbaren Fähigkeiten.

Nicht jede Fähigkeit muss im ersten Projekt vollständig ausgebaut werden. Aber jedes Projekt sollte explizit benennen, welche davon es benötigt, welche es aufbaut und wer sie anschließend pflegt. Sonst werden dieselben Grundsatzfragen in jedem Pilot neu beantwortet.

Was das für Führung und Organisation bedeutet

Führung sollte den einzelnen Use-Case nicht vollständig zentral bestimmen, ihre Aufgabe aber auch nicht auf die Budgetfreigabe beschränken. Sie setzt die Entscheidungslogik: die Relevanz der bearbeiteten Probleme, die akzeptablen Risiken, die angestrebten wiederverwendbaren Fähigkeiten und die Kriterien für Fortführung oder Beendigung eines Piloten.

Für die Organisation folgt daraus eine geteilte Verantwortung. Fachbereiche besitzen Problem und Prozess. Data- und AI-Teams entwickeln und evaluieren die technische Lösung. IT und Security sichern Integration und Betrieb. Datenschutz, Recht und Mitbestimmung werden früh dort eingebunden, wo der Fall es erfordert. Eine zentrale Governance sollte Mindeststandards und Transparenz schaffen, ohne jede kleine Erprobung in denselben Freigabeprozess wie ein hochriskantes Produktionssystem zu zwingen.

Für Mitarbeitende reicht eine allgemeine Schulung zum Prompten nicht aus. Wer mit KI in einem realen Prozess arbeitet, muss die Aufgabe, die Grenzen des Systems und den eigenen Entscheidungsspielraum verstehen. AI Literacy ist damit rollenspezifisch. Eine Sachbearbeiterin braucht andere Kompetenzen als ein Produktverantwortlicher, eine Entwicklerin oder ein Mitglied des Vorstands.

Auch die Infrastruktur sollte nicht mit einer maximalen Plattformvision beginnen. Standardisierung ist dort sinnvoll, wo mehrere reale Fälle dasselbe Problem haben. Ein gemeinsamer Modellzugang, Identity Management oder ein Evaluationsdienst sollte daher nachweislich die Umsetzung mehrerer Use-Cases erleichtern. Wiederverwendung entsteht durch bewusste Produktentscheidungen und nicht automatisch durch die Zentralisierung von Technik.

Fazit

Konkrete Use-Cases sind ein sinnvoller Einstieg, weil sich Nutzen, Risiken und organisatorische Voraussetzungen am realen Problem untersuchen lassen. Für eine dauerhafte Nutzung von KI reicht es jedoch nicht aus, Anwendungen zu sammeln und technisch zu demonstrieren. Bereits während eines Piloten müssen Prozessintegration, Qualitätssicherung, Zuständigkeiten und ein möglicher Betrieb berücksichtigt werden.

Aus meiner Sicht sollte eine KI-Strategie deshalb überschaubare Probleme mit messbaren Veränderungen im Prozess verbinden. Gleichzeitig ist bei jedem Projekt zu prüfen, welche Komponenten, Standards und Kompetenzen für weitere Anwendungen erhalten bleiben. Aus einem einzelnen Use-Case entsteht noch keine organisatorische Transformation. Eine Folge gut gewählter und produktiv verankerter Use-Cases kann jedoch schrittweise die dafür erforderlichen Fähigkeiten aufbauen.

Literatur

Brynjolfsson, Erik, und Lorin M. Hitt. 2000. „Beyond Computation: Information Technology, Organizational Transformation and Business Performance“. Journal of Economic Perspectives 14 (4): 23–48. https://doi.org/10.1257/jep.14.4.23.

Brynjolfsson, Erik, Danielle Li, und Lindsey R. Raymond. 2025. „Generative AI at Work“. The Quarterly Journal of Economics 140 (2): 889–942. https://doi.org/10.1093/qje/qjae044.

Czímer, Balázs, Lieven Van der Veken, und Matyáš Zetek. 2026. „Capturing Central Europe’s AI Opportunity“. McKinsey & Company. https://www.mckinsey.com/featured-insights/insights-on-europe/capturing-central-europes-ai-opportunity.

De Smet, Aaron, Drew Goldstein, Holly Price, und Tanguy Catlin. 2026. „From Adoption to Impact: Three Horizons of AI Transformation“. McKinsey & Company. 8. Juli 2026. https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/from-adoption-to-impact-three-horizons-of-ai-transformation.

McKinsey & Company. 2025. „The State of AI in 2025: Agents, Innovation, and Transformation“. 5. November 2025. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai.

———. 2026. „Produktivität. Neu gedacht. Mit mutigen Entscheidungen Wachstum für Deutschland neu definieren“. https://www.mckinsey.de/publikationen/produktivitaet-neu-gedacht.

Mikalef, Patrick, John Krogstie, Ilias O. Pappas, und Paul A. Pavlou. 2020. „Exploring the Relationship between Big Data Analytics Capability and Competitive Performance: The Mediating Roles of Dynamic and Operational Capabilities“. Information & Management 57 (2): 103169. https://doi.org/10.1016/j.im.2019.05.004.

Niessing, Joerg, Carsten Feldmann, und Michael Bücker. 2026. „From Pilots to Pipelines: Unlocking Agentic AI’s True Potential“. The European Business Review, Nr. May-June: 32–40. https://www.europeanbusinessreview.com/from-pilots-to-pipelines-unlocking-agentic-ais-true-potential/.

OECD. 2026. „AI Use by Individuals Surges across the OECD as Adoption by Firms Continues to Expand“. 28. Januar 2026. https://www.oecd.org/en/about/news/announcements/2026/01/ai-use-by-individuals-surges-across-the-oecd-as-adoption-by-firms-continues-to-expand.html.

Schmitz, Christoph, Dago Diedrich, Gianmarco Cilento, und Steffen Fuchs. 2026. „The Operating Model Advantage: Why AI Winners Are Rewiring Their Organizations“. McKinsey & Company. 7. Juli 2026. https://www.mckinsey.com/industries/industrials/our-insights/the-operating-model-advantage-why-ai-winners-are-rewiring-their-organizations.

Singla, Alex, Alexander Sukharevsky, Eric Lamarre, Kate Smaje, und Robert Levin. 2026. „The AI Transformation Manifesto“. McKinsey & Company. 7. April 2026. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-ai-transformation-manifesto.

Tabassi, Elham. 2023. „Artificial Intelligence Risk Management Framework (AI RMF 1.0)“. NIST AI 100-1. National Institute of Standards; Technology. https://doi.org/10.6028/NIST.AI.100-1.

Vial, Gregory. 2019. „Understanding Digital Transformation: A Review and a Research Agenda“. The Journal of Strategic Information Systems 28 (2): 118–44. https://doi.org/10.1016/j.jsis.2019.01.003.

Weddle, Brooke. 2026. „Practical People Lessons for Scaling AI Adoption“. McKinsey & Company. 13. Juli 2026. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/rewired-takes-practical-people-lessons-for-scaling-ai-adoption.