KI-Bereitschaftsanalyse: Was Sie vor dem KI-Einsatz regeln müssen

Ein Betriebsteam aus dem Mittelstand führt das Anbieter-Quiz durch, erreicht 3,8 von 5 Punkten und bezeichnet sich selbst als KI-bereit. Sechs Wochen später gerät das Pilotprojekt ins Stocken. Der Workflow, der automatisiert werden sollte, war nie schriftlich dokumentiert. Niemand konnte freigeben, was der Agent tat, sobald er mit einem Kundendatensatz in Berührung kam. Die Punktzahl war real. Die Bereitschaft war es nie.

Eine Bewertung der KI-Bereitschaft (AI Readiness Assessment) ist die Evaluierung, die darüber entscheidet, ob ein bestimmter Workflow jetzt sicher KI aufnehmen kann, zuerst neu gestaltet werden muss oder warten sollte. Stand Ende 2025 stellte McKinseys State of AI-Studie fest, dass 88 % der Unternehmen eine regelmäßige KI-Nutzung meldeten, aber nur 39 % einen unternehmensweiten EBIT-Effekt sahen, und bei den meisten blieb dieser Effekt unter 5 %. Die Lücke liegt nicht an der Modellqualität. Sie liegt an den Betriebsbedingungen unterhalb des Modells.

Die meisten Bewertungen enden bei einer Reifegrad-Klassifizierung. Dieser Leitfaden führt die Bewertung als einen sich verengenden Entscheidungspfad aus: Grenzen Sie einen Workflow ein, räumen Sie mit den Illusionen der Scorecards auf und gehen Sie dann die Blocker durch, die über das Urteil entscheiden, und zwar in der Reihenfolge, in der sie Pilotprojekte tatsächlich scheitern lassen. Am Ende haben Sie eine Entscheidung für einen konkreten Workflow – Erstellen, Kaufen, Konfigurieren, Pilotieren oder Warten – sowie einen 30-60-90-Tage-Plan, um die verbleibenden Lücken zu schließen.

Schritt 1: Welche Entscheidung muss ein AI Readiness Assessment tatsächlich treffen?

Ein AI Readiness Assessment ist ein Urteil über die Bereitstellungsfähigkeit auf Workflow-Ebene. Es beantwortet eine Frage für einen bestimmten Anwendungsfall: Kann KI diesen Workflow jetzt sicher ausführen, muss der Workflow zuerst neu gestaltet werden oder sollte man warten? Ein AI Maturity Assessment misst, wie fortgeschritten eine Organisation insgesamt ist. Readiness entscheidet, ob ein bestimmter Prozess bereit für den Produktiveinsatz ist.

Robert Half formuliert das Kernziel der Readiness direkt mit eigenen Worten:

KI-Bereitschaft bezieht sich auf die Fähigkeit eines Unternehmens, KI-Technologien erfolgreich einzuführen, zu implementieren und zu skalieren... und zwar so, dass sie einen messbaren geschäftlichen Nutzen stiften. — Robert Half, AI Readiness Plan for Tech Leaders (2025)

Wissenschaftliche Arbeiten, wie Palade & Carutasus Forschung zur Digitalisierungsbereitschaft, betrachten Readiness als eine Erweiterung der digitalen Reifegradpraxis.

Warum ein Score keine Entscheidung ist

Anfang 2025 stellte McKinsey fest, dass fast jedes Unternehmen in KI investiert, während nur etwa 1 % der Führungskräfte ihre Organisation als ausgereift in der KI-Einführung bezeichneten. Diese Zahl aus McKinseys Superagency in the Workplace-Studie definierte die KI-Einführung eher als Führungsproblem und weniger als Kompetenzlücke.

Bereitschaft versus Reifegrad, in aller Kürze

Der Reifegrad beschreibt die Organisation. Die Bereitschaft entscheidet darüber, ob ein bestimmter Workflow jetzt sicher automatisiert werden kann. Der Rest dieses Leitfadens erarbeitet dieses Urteil, Blockade für Blockade. Für Teams, die bereits in KI-gestützte Arbeit investieren, zeigt der Begleitartikel über die Nutzung von KI für Innovationen, wo sich die Wertschöpfung in der Regel konzentriert.

Schritt 2: Warum Sie erst einen Workflow eingrenzen sollten, bevor Sie das gesamte Unternehmen bewerten

Die Bewertung des gesamten Unternehmens ist zu breit gefasst, um eine konkrete Entscheidung herbeizuführen. Ein so weit gefasster Rahmen liefert lediglich ein Etikett. Wer seine Kräfte überall verteilt, hat nirgends Kraft. Die operative Einheit ist ein einzelner Workflow, ein Geschäftsfeil, eine Risikogrenze, ein nächster Schritt. Grenzen Sie den Bereich so eng ein, dass ein einzelner Prozesseigentümer jeden Schritt, jede Ausnahme und die Kosten eines Fehlers beschreiben kann. Eine unternehmensweite Bewertung liefert ein Label. Die Eingrenzung auf Workflows liefert konkrete Handlungsschritte.

Microsofts eigenes Readiness-Framework warnt davor, dies als einmalige Übung zu betrachten. Das Team von Copilot Studio beschreibt die KI-Bereitschaft als eine kontinuierliche Abstimmung von Menschen, Prozessen und Technologie, die bei jeder Änderung der Rahmenbedingungen eine Neubewertung erfordert. Das ist der praktische Grund für eine enge Eingrenzung: Die Bewertung wird jedes Mal neu durchgeführt, wenn sich der Workflow, seine Daten oder seine Kontrollmechanismen ändern.

Wie ein eingrenzbarer Workflow aussieht

„Den Kundenservice mit KI verbessern“ ist ein Ziel. „Entwürfe für Erstantworten auf Abrechnungsfragen erstellen, basierend auf den gelösten Tickets der letzten 12 Monate, wobei jede Freigabe durch einen Menschen erfolgt“ ist ein Workflow. Die zweite Version setzt das, womit der Agent arbeitet (Input und Datenbasis), in Relation zu den Kosten einer Fehlentscheidung. Nur die zweite Version lässt sich bewerten.

Drei Fragen zur Eingrenzung

Bevor Sie eine Säule bewerten, beantworten Sie drei Fragen für den potenziellen Workflow: Was ist das einzige Ziel und wie wird es gemessen? Was ist das schlimmste Ergebnis, wenn die KI falsch liegt, und wer fängt diesen Fehler auf? Und wie sieht der kleinste testbare Teilbereich in 90 Tagen aus, ohne regulierte oder umsatzkritische Prozesse zu berühren? Vage Antworten bedeuten, dass der Workflow noch nicht ausreichend eingegrenzt ist. Eine Bewertung zum jetzigen Zeitpunkt würde diese Lücke nur kaschieren.

Die Kosten einer zu breit gefächerten Bewertung

McKinsey stellte fest, dass leistungsstarke Unternehmen etwa dreimal häufiger spezifische Arbeitsabläufe um KI herum neu gestalten, anstatt sie direkt über alle Bereiche hinweg zu implementieren. Ein enger Fokus erzwingt die Diskussion über die Neugestaltung, während ein breiter Fokus es ermöglicht, dieser auszuweichen.

Schritt 3: Welche Scorecard-Fehler machen die KI-Bereitschaft zur bloßen Show?

Der häufigste Fehler besteht darin, jede Säule gleich zu gewichten und einen starken Durchschnitt als Freigabe für den Rollout zu interpretieren. Ein einziger ungelöster Blocker macht eine hohe Durchschnittsbewertung hinfällig. Organisationen, die ihre Blocker durch Durchschnittswerte schönrechnen, beseitigen sie nicht, sondern verfestigen sie. Durchschnitte kaschieren den einen No-Go-Blocker, der das Pilotprojekt scheitern lässt. Die drei wiederkehrenden Fallen sind unkontrolliertes Wachstum von Pilotprojekten (Pilot Sprawl), Schatten-KI und die Automatisierung fehlerhafter Prozesse. Jede dieser Fallen sieht auf einer Scorecard nach Fortschritt aus. Im Produktivbetrieb verhalten sie sich jedoch wie technische Schulden.

Die NANDA-Studie des MIT zu Unternehmens-Rollouts ergab, dass rund 95 % der Pilotprojekte im Bereich der generativen KI kaum oder gar keine messbaren Auswirkungen auf den Gewinn hatten. Die Ursache lag dabei in der Integration und der Anpassung an die Arbeitsabläufe, nicht in der reinen Leistungsfähigkeit der Modelle. Der Hauptautor brachte den Mechanismus direkt auf den Punkt.

Generische Tools wie ChatGPT sind für Einzelpersonen aufgrund ihrer Flexibilität hervorragend geeignet, stoßen jedoch im Unternehmenseinsatz an Grenzen, da sie nicht aus Arbeitsabläufen lernen oder sich an diese anpassen. — Aditya Challapally, MIT NANDA, The GenAI Divide (2025)

Häufige Missverständnisse

• „Ein hoher Reifegrad bedeutet, dass wir bereit sind.“ Ein starker Durchschnitt kann eine einzelne, blockierende Lücke maskieren. Ciscos Index für 2025 zeigt, dass sich nur etwa 13 % der Unternehmen als voll vorbereitete „Pacesetter“ qualifizieren. Die Unterschiede zeigen sich in spezifischen Säulen wie Sicherheitsrichtlinien (Guardrails) und Change Management, nicht in der Gesamtnote.
• „Weitverbreitete KI-Nutzung beweist Bereitschaft.“ Eine Einführung ohne Governance ist Schatten-KI. UpGuards Studie für 2025 fand heraus, dass mehr als 80 % der Beschäftigten nicht genehmigte KI-Tools nutzen. Dabei gehören Führungskräfte zu den aktivsten Nutzern nicht freigegebener Anwendungen, und weniger als 20 % der Mitarbeiter beschränken sich auf die vom Unternehmen freigegebenen Optionen.
• „Die Automatisierung eines langsamen Prozesses ist immer ein Gewinn.“ Tatsächlich skaliert die Automatisierung eines undokumentierten, fehlerhaften Prozesses nur das Chaos. Die Fachliteratur zur Automatisierung, die bis auf Tom Taullis Handbuch aus dem Jahr 2020 zurückgeht, warnt davor, dass das Codieren von manueller Übertragungsarbeit („Swivel-Chair Work“) und undokumentierten Ausnahmen Fehler lediglich schneller ablaufen lässt. Diese Formulierung stammt aus Tom Taullis RPA Handbook, dem Standardwerk für Automatisierungspraktiker, auf das sich dieser Leitfaden bei der Analyse von Fehlermustern in der Ausnahmebehandlung stützt.

Steelman: Sind Scorecards wertlos?

OWASP pflegt ein formelles AI Maturity Assessment-Projekt, und strukturierte Modelle erfüllen eine echte Aufgabe.

KI-Reifegradmodelle bieten die Struktur, um gezielt zu wachsen, Risiken zu bewerten und Fähigkeiten messbar zu skalieren. — G2, AI Maturity Model: How to Assess and Scale

Ein Reifegradmodell ist ein legitimes Governance-Werkzeug. Es wird erst dann zum Theater, wenn sein gemittelter Output die Workflow-Entscheidung ersetzt. Nutzen Sie die Scorecard, um den Fortschritt zu verfolgen, aber lassen Sie sie nicht die Frage der Bereitstellung beantworten.

Schritt 4: Wie inventarisieren Sie die impliziten Entscheidungen, die ein KI-Agent erraten müsste?

Die unsichtbare Ebene der KI-Bereitschaft ist dokumentierter Kontext. Wenn ein Workflow auf ungeschriebenen Ermessensentscheidungen, Ausnahmebehandlungen und Erfahrungswissen basiert, muss ein KI-Agent diese ableiten – und er wird einige davon falsch ableiten. Dieser Schritt bildet die tatsächliche Entscheidungslogik des Workflows ab: den Standardpfad, die Ausnahmen, die Eskalationsregeln und das implizite Wissen, das derzeit nur in den Köpfen der Mitarbeitenden existiert.

Zwei unabhängige Umfragen aus dem Jahr 2025 kommen zum selben Blocker. Die Lucid-Umfrage von 2025 unter rund 2.200 Wissensarbeitern ergab, dass nur 16 % ihre Workflows als extrem gut dokumentiert beschreiben, und 46 % gaben an, dass Abläufe hauptsächlich von informellem Wissen oder Erfahrungswissen abhängen. Lucids eigene 2025 AI Readiness Survey ist die Quelle. Die Microsoft-Umfrage unter 500 Agent-Entscheidungsträgern in 13 Ländern kam mit einer anderen Stichprobe zum selben Ergebnis.

78 % berichteten von Lücken bei der Erfassung von Geschäftsprozess- und Datenabhängigkeiten, die zur Fertigstellung ihrer Workflows erforderlich sind. Sie können nicht identifizieren, was Sie nicht kartiert haben. — Jack, Microsoft Copilot Studio, Agent Readiness Framework (2025)

Das Problem der Ausnahmepfade

Menschen handhaben Ausnahmen mit einem Achselzucken und einer Slack-Nachricht. Ein agentenbasiertes KI-Systemhandhabt sie durch Raten. Ein Erstattungsprozess hat vielleicht einen dokumentierten Pfad und neun ungeschriebene Ermessensentscheidungen über Kulanz, Betrugssignale und VIP-Konten. In diesen neun Bereichen erfindet ein KI-Agent stillschweigend eigene Regeln. KI-Systeme funktionieren nicht durch Ehrgeiz. Sie funktionieren auf Basis von dokumentiertem Kontext, Berechtigungsgrenzen und Entscheidungslogik.

Was „ausreichend dokumentiert“ tatsächlich bedeutet

Eine brauchbare Workflow-Map benennt den Trigger und die geordneten Schritte und dokumentiert anschließend die Governance-Ebene, die jede Verzweigungsregel, jede Ausnahmebehandlung und jedes Erfolgskriterium abdeckt. Wenn irgendetwas davon nur als implizites Teamwissen existiert, muss der Workflow vor einem Pilotprojekt dokumentiert werden, nicht danach.

Prozessverantwortliche und operative Mitarbeiter decken Dokumentationslücken auf, wenn sie den Workflow gemeinsam durchgehen. Setzen Sie den Prozessverantwortlichen und einen operativen Mitarbeiter in denselben Raum und lassen Sie sie den Workflow von Anfang bis Ende durchgehen, einschließlich jedes „Nun, das kommt darauf an“-Moments. Die Lücken zwischen ihren beiden Schilderungen sind die Ausnahmepfade, die ein Agent selbst erfinden müsste. Dies ist dieselbe Disziplin, die auch Innovations-Feedbackschleifen erfolgreich macht: Zeichnen Sie den Schaltplan auf, bevor Sie irgendetwas daran anschließen.

Schritt 5: Ist Ihre Datenqualität ausreichend oder streben Sie nach perfekter Datenkonsistenz?

Der eingegrenzte Workflow erfordert klar definierte, autorisierte und rückverfolgbare Daten, die für die jeweilige Aufgabe ausreichen und sich sicher überwachen lassen. Eine unternehmensweite Datenbereinigung ist ein Projekt für ein ganzes Jahrzehnt. Ein begrenztes Pilotprojekt benötigt lediglich lokale Datenverfügbarkeit. Bewerten Sie nur den tatsächlich definierten Bereich und klammern Sie den Rest der Datenlandschaft für spätere Phasen aus.

Die Readiness-Studie von Microsoft nennt den Datenzugriff als die entscheidende Hürde für die Bereitstellung von Agenten.

80 % berichten, dass Daten für ihre Teams nicht leicht zugänglich sind... Wenn diese Daten nicht zugänglich sind, bricht die Zahl der realisierbaren Anwendungsfälle zusammen, noch bevor sie überhaupt begonnen hat. — Jack, Microsoft Copilot Studio, Agent Readiness Framework (2025)

Der Index von Cisco definiert zentralisierte Daten als eine der tragenden Säulen, die vorbereitete Unternehmen von den übrigen unterscheidet. Eine für die Überwachung ausreichende Zentralisierung ist die Mindestanforderung für ein Pilotprojekt. Eine lückenlose Zusammenführung ist ein mehrjähriges Unterfangen. Der kontrollierte Zugriff auf den definierten Datenbestand ist das eigentliche Kriterium für den Start eines Pilotprojekts.

Datenzulänglichkeit, Dimension für Dimension

Vier Dimensionen entscheiden darüber, ob der eingegrenzte Korpus die Anforderungen erfüllt: Zugriff (für den Agenten mit klaren Berechtigungen erreichbar, nicht in einem System gesperrt, das niemand programmatisch auslesen kann), Aktualität (aktuell genug, dass eine veraltete Antwort zwar ärgerlich, aber nicht gefährlich ist), Rückverfolgbarkeit (jede Ausgabe lässt sich auf einen Quelldatensatz zurückführen) und Begrenztheit (ein endlicher, kuratierter, auf Berechtigungen beschränkter Korpus, kein offener Data Lake).

Die Datenprüfung schlägt fehl, wenn das Chaos die Zugriffskontrollen, die Rückverfolgbarkeit oder die Begrenztheit des spezifischen Workflows betrifft. Andernfalls steht die eingegrenzte Prüfung für sich selbst. Machen Sie weiter. Wenn die Rückverfolgbarkeit fehlschlägt, brechen Sie ab, da Sie nichts überwachen können, was Sie nicht rekonstruieren können.

Schritt 6: Was kostet Sie technologische Schuld als KI-Steuer?

Integrationsengpässe bringen mehr Pilotprojekte zum Scheitern als mangelnde Modellleistung. Instabile Integrationen, Altsysteme und fehlende APIs machen aus einem plausiblen Pilotprojekt regelmäßig ein langes, teures Redesign. Technologische Schuld ist eine Dimension der KI-Bereitschaft, aber sie wird erst nach Workflow und Daten relevant, da diese vorgelagerten Hürden oft darüber entscheiden, ob sich die Integrationsarbeit überhaupt lohnt. Betrachten Sie technologische Schuld als Steuer auf die Bereitstellungszeit und kalkulieren Sie diese ein, bevor Sie Verpflichtungen eingehen.

In einer Untersuchung vom April 2025 stellte Robert Half fest, dass 46 % der Technologie-Führungskräfte die Integration von Altsystemen und den Abbau technologischer Schulden als größte Herausforderung nannten, während 63 % die Rekrutierung von KI- und Data-Science-Talenten als kritische Hürde bezeichneten.Die Untersuchung von Robert Half zeigt, dass sich dieses Muster in allen Bereitschaftsstudien von Unternehmen wiederholt: Die Demo des Modells verläuft erfolgreich, doch die Integrationsebene verzögert anschließend den Zeitplan.

Eine Demo beweist die Einsatzbereitschaft des Modells. Mehr nicht. Sie sagt nichts darüber aus, ob der Agent Daten in das CRM zurückschreiben, Berechtigungen auf Datensatzebene einhalten oder eine Änderung der nachgelagerten API überstehen kann. Seneca warnte, dass wir in unserer Vorstellung mehr leiden als in der Realität, aber bei technologischen Altschulden verhält es sich genau umgekehrt. Das Leiden in der Produktionsumgebung übertrifft alles, was die Demo vermuten ließ. Wenn die tatsächliche Logik eines Workflows in veralteten Schnittstellen liegt, deckt die Automatisierung des Frontends die technologische Schuld nur schneller auf. Wenn der Integrationspfad ein mehrmonatiges Plattform-Redesign erfordert, lautet das ehrliche Urteil zur Bereitschaft für dieses Quartal oft „Warten“ – und diese Entscheidung zu treffen, ist die Aufgabe von Schritt 10.

Schritt 7: Welche Kontrollmechanismen müssen vorhanden sein, bevor ein Pilotprojekt live geht?

Das Scheitern beim Übergang vom Pilotprojekt in die Produktion ist meist ein Kontrollproblem. Die Fehlerursache liegt in der Tiefe der Governance. Es ist kein Anbieterproblem, sondern ein Kontrollproblem. Eisenhower hat dies verstanden: Pläne sind wertlos, aber Planung ist alles. Er meinte damit, dass der Prozess des Durchdenkens von Kontrollen (wer genehmigt was, wer kann eingreifen, wer besitzt das Protokoll) wertvoller ist als jedes Dokument, das Sie erstellen. Ein Workflow ist nicht bereit, wenn niemand sensible Aktionen genehmigen, Protokolle einsehen oder das System sicher stoppen kann. Die Kernanforderung ist Rückverfolgbarkeit. Personalisierte Genehmigungspunkte erhalten die meiste Aufmerksamkeit, aber Live-Monitoring, Rollback-Kontrollen und Audit-Protokolle, die jede Entscheidung im Nachhinein rekonstruieren können, machen den Einsatz eines Agenten steuerbar und nicht nur funktional. Statische Richtliniendokumente zählen nicht. Live-Kontrolle tut es.

Nur 24 % der Unternehmen können die Aktionen von Agenten mit angemessenen Guardrails und Live-Monitoring kontrollieren, verglichen mit 84 % der vorbereiteten „Pacesetter“, so der [Cisco's AI Readiness Index](https://www.cisco.com/c/dam/m/en_us/solutions/ai/readiness-index/2025-m10/documents/cisco-ai-readiness-index-2025-realizing-the-value-of-ai.pdf). Diese Lücke ist ein direkter Indikator dafür, welche Pilotprojekte den realen Betrieb überstehen. Auditierbarkeit ist eine Grundvoraussetzung für die Betriebsbereitschaft. Peer-Review-Forschung im Rechnungswesen betrachtet die Fähigkeit zur Überprüfung, Protokollierung und Überwachung von KI-Aktionen als Mindestanforderung, bevor KI in geschäftskritischen Bereichen eingesetzt wird.

Live-Monitoring versus statische Richtlinien

Ein Richtlinien-PDF ist ein Wunsch. Live-Monitoring ist eine Kontrollinstanz. Die Richtlinie besagt, dass der Agent risikoreiche Aktionen eskalieren „sollte“. Live-Monitoring bedeutet, dass die Aktionen des Agenten in ein Dashboard gestreamt werden, ein Mensch mitten in der Aufgabe eingreifen kann und jede Entscheidung mitsamt ihren Eingaben protokolliert wird. Regulierte Umgebungen gehen hier noch weiter, was in Schritt 13 mit den Anforderungen der FDA zur menschlichen Interaktion behandelt wird.

Eine Mindest-Governance-Checkliste

Bevor ein Pilotprojekt in einen realen Workflow integriert wird, muss das Vorhandensein von fünf Kontrollmechanismen bestätigt werden. Eine namentlich genannte Person ist für die Freigabe sensibler Aktionen verantwortlich, jede Aktion eines Agenten wird protokolliert und ist rekonstruierbar, und ein Notausschalter kann den Workflow ohne ein Deployment stoppen. Der Zugriff ist auf den Datenbestand des Workflows beschränkt und nicht auf den gesamten Datenbestand des Unternehmens. Eine Person überprüft in einem festen Rhythmus eine Stichprobe der überwachten Ergebnisse.

Wann eine schlanke Governance akzeptabel ist

Die Tiefe der Governance sollte sich nach den Risiken des Workflows richten. Ein Workflow, der interne Besprechungszusammenfassungen entwirft, keine externen Aktionen auslöst und bei dem ein Mensch alles liest, bevor es weitergegeben wird, benötigt nicht dieselbe Kontrollfläche wie ein Workflow, der mit Kundengeldern interagiert. Der Maßstab ist die Reversibilität und der Schadensradius (das Gesamtausmaß des Schadens, wenn das System eine fehlerhafte Ausgabe erzeugt, wer betroffen ist, wie schnell dies geschieht und ob es rückgängig gemacht werden kann). Wenn eine fehlerhafte Ausgabe kostengünstig abzufangen und zu korrigieren ist, ist ein schlankerer Freigabepfad vertretbar. Ist die Aktion unumkehrbar oder kundenorientiert, ist die vollständige Checkliste die Voraussetzung für ein Pilotprojekt. Governance-Muster aus der föderierten Innovation greifen hier: Verteilte Autonomie erfordert weiterhin zentrale Leitplanken.

Schritt 8: Können Ihre Mitarbeiter den Wandel tatsächlich bewältigen?

Wenn Entscheidungsbefugnisse nicht klar zugewiesen sind, scheitern Implementierungen unabhängig von der technischen Reife. Wenn Prozessverantwortliche, Anwender, die IT-Sicherheit und die Führungsebene sich nicht auf neue Rollen, Eskalationspfade und Erfolgskriterien geeinigt haben, gerät das Pilotprojekt nach der Demo ins Stocken. Die Hürde liegt selten an mangelnden Fachkenntnissen. Es ist die ungeklärte Zuständigkeit für neue Entscheidungen, Ausnahmen und Prüfungen, die ein KI-Workflow mit sich bringt. Die Fähigkeit, Veränderungen zu verarbeiten, ist ein besserer Indikator für Skalierbarkeit als bloßer Enthusiasmus – und sie hängt eng mit der allgemeinen Innovationskultur eines Unternehmens zusammen.

[Der Cisco-Index](https://www.cisco.com/c/dam/m/en_us/solutions/ai/readiness-index/2025-m10/documents/cisco-ai-readiness-index-2025-realizing-the-value-of-ai.pdf) belegt diese Kluft: 91 % der vorbereiteten Unternehmen haben einen Change-Management-Plan, im Vergleich zu nur 35 % aller anderen. Wissenschaftliche Untersuchungen bestätigen zudem, dass die Barrieren ebenso psychologischer und organisatorischer wie technischer Natur sind. Deshalb reicht reine Schulung allein nicht aus, um sie zu überwinden.

Qualifikationsdefizit versus Defizit im Betriebsmodell

Schulungen beheben ein Qualifikationsdefizit. Ein Defizit im Betriebsmodell – bei dem niemand für die Ausnahmen des Agenten zuständig ist und die Entscheidungsbefugnis nicht zugewiesen ist – erfordert die Neuzuweisung von Entscheidungen an namentlich genannte Personen. Werden diese beiden Aspekte frühzeitig verwechselt, führt dies dazu, dass die Bewertung auf einen generischen Qualifizierungsplan reduziert wird.

Schritt 9: Wie bewerten und priorisieren Sie Anwendungsfälle nach Nutzen, Komplexität und Risiko?

Sobald die Hindernisse sichtbar sind, wird eine Priorisierung der Anwendungsfälle möglich. Bewerten Sie jeden potenziellen Workflow nach Geschäftswert, technischer Machbarkeit und Reife. Wenden Sie Risiken und Dokumentationslücken anschließend als Abzüge (Penalties) anstatt als Durchschnittswerte an. Die Priorisierungsmatrix-Vorlage von InitializeAI gewichtet den Geschäftswert mit 35 bis 45 % und die Machbarkeit mit 25 to 35 %, während Risiko und Datenreife als Abzüge einfließen. Das richtige erste Pilotprojekt ist selten der Anwendungsfall mit dem höchsten Wert. Es ist der Workflow mit realem Nutzen und einem langweiligen, klar begrenzten Risiko. Dies entspricht der gleichen Logik wie bei einem guten Marktvalidierungs-Test: kostengünstig, eingegrenzt und aufschlussreich, bevor Sie echtes Budget binden.

Ein konkretes Ranking-Beispiel

Betrachten wir drei potenzielle Workflows. Autonome Preisänderungen versprechen ein sehr hohes Potenzial bei hoher Komplexität, aber das Risiko ist gravierend: direkte finanzielle Auswirkungen mit schwachen Sicherheitsvorkehrungen – genau das Profil, vor dem Schritt 7 warnt. Trotz des höchsten theoretischen Potenzials lautet das Urteil: abwarten. Die Extraktion von Vertragsklauseln bietet mittleres Potenzial bei mittlerer Komplexität, mit einem moderaten Risiko aufgrund der erforderlichen rechtlichen Prüfung. Das Urteil lautet: überarbeiten, dann pilotieren. Entwürfe für Erstantworten im Abrechnungssupport bieten mittleres Potenzial bei geringer Komplexität. Das Risiko liegt nahe null, da ein Mensch jede Nachricht vor dem Versenden anhand eines begrenzten Datenbestands freigibt. Das Urteil lautet: jetzt pilotieren, noch vor der Option mit dem höheren Potenzial. Eine einzige fehlende Sicherheitsvorkehrung oder Dokumentationslücke sollte einen Anwendungsfall blockieren, selbst wenn die reine Potenzialbewertung stark aussieht. Dieses Risiko wegzumitteln ist der Grund, warum Unternehmen sich oft für ein spektakuläres Pilotprojekt entscheiden, das dann im zweiten Monat scheitert.

Schritt 10: Wie treffen Sie die Entscheidung zwischen Eigenentwicklung, Kauf, Konfiguration, Pilotprojekt oder Abwarten?

Das Assessment erfüllt seinen Zweck erst dann, wenn es in einer konkreten Workflow-Entscheidung mündet. Es gibt fünf Optionen, die von maßgeschneiderten Eigenentwicklungen und spezialisierten Zukäufen bis hin zu risikoärmeren Schritten wie Konfiguration, Pilotierung oder einem bewussten Abwarten reichen. Ein AI Readiness Assessment, das mit einer Reifegradbewertung statt einer Workflow-Entscheidung endet, ist reine Show: Die Organisation hat sich selbst benotet, aber immer noch nichts entschieden.

Die Kontrollmechanismen und der Datenreifegrad der Organisation bestimmen, welcher Beschaffungsweg überhaupt realisierbar ist.Untersuchungen zur organisatorischen Bereitschaft definieren die Wahl zwischen einem Tool auf Basis eines Foundation-Modells und einem maßgeschneiderten autonomen System als eine Eignungsentscheidung, die von den Kontrollen und Daten der Organisation abhängt. Die Marktlage spricht eher für den Kauf: Daten des MIT zeigen, dass Implementierungen spezialisierter Anbieter in etwa 67 % der Fälle erfolgreich sind, verglichen mit rund 33 % bei internen Eigenentwicklungen.

Die Fünf-Wege-Matrix

Warten ist eine Entscheidung, kein Scheitern. Wenn dem Workflow ein Live-Monitoring oder eine dokumentierte Entscheidungslogik fehlt, ist „Warten“ plus ein 30-60-90-Tage-Plan besser als ein Launch, der jemanden um 2 Uhr morgens alarmiert. Der Ansatz, der den Reifegrad-Score an erste Stelle setzt, kann diese Entscheidung nicht herbeiführen, da eine 3,8 von 5 nichts darüber aussagt, ob speziell der Abrechnungs-Workflow erstellt oder abgewartet werden soll.

Schritt 11: Welche Kennzahlen prognostizieren das Scheitern eines Pilotprojekts?

Organisationen überschätzen ihre Bereitschaft systematisch in vier Dimensionen: Qualität der Dokumentation, Tiefe der Governance, Stärke des Change-Managements und die Fähigkeit zur Skalierung über ein Pilotprojekt hinaus. Betrachten Sie diese als Frühindikatoren, nicht als Dekoration. Jeder einzelne verändert das Gesamtergebnis, da er ein Hindernis aufzeigt, das ein Durchschnittswert der Reife tendenziell verschleiert.

Lesen Sie die Tabelle als Bereitschaftsfilter. Die Lücke von 78 % bei der Prozesskartierung prognostiziert Fehler in Schritt 4. Der Wert von 24 % bei den Sicherheitsvorkehrungen (Guardrails) prognostiziert Fehler in Schritt 7. Die Aufteilung von 67 % zu 33 % ist die Tendenz bei der Beschaffung in Schritt 10. Zusammen erklären sie die Schlagzeile von 95 %: Pilotprojekte scheitern, weil die Betriebsbedingungen nie bewertet wurden, nicht weil die Modelle schwach waren.

Schritt 12: Was lehrt uns der Copilot-Rollout von Morgan Stanley über die Bereitschaft?

Ein starkes KI-Pilotprojekt ist meist deshalb erfolgreich, weil der Workflow eng eingegrenzt ist, der Datenbestand kontrolliert wird, der Mensch in der Schleife bleibt und Berechtigungen explizit geregelt sind. Der Berater-Assistent von Morgan Stanley, der mit OpenAI entwickelt wurde, ist das Paradebeispiel für dieses Profil auf Unternehmensebene. Es lohnt sich, dieses Projekt genau zu analysieren, weil es stark reguliert und klar begrenzt ist, nicht weil es spektakulär ist.

Der Rollout stellte einen Chatbot über einen freigegebenen internen Datenbestand von rund 100.000 Dokumenten. Berater und Prompt-Engineers bewerteten die Antworten vor der breiteren Veröffentlichung auf Genauigkeit und Kohärenz, so die Fallstudie von OpenAI zum Morgan Stanley-Rollout. Menschen überprüften und passten die Ergebnisse an, bevor irgendetwas finalisiert wurde, und die Zero-Data-Retention-Richtlinie von OpenAI löste das Compliance-Problem.Über 98 % der Beraterteams nutzen den Assistenten aktiv, und der Zugriff auf Dokumente stieg von 20 % auf 80 %.

Warum dieser Workflow bereit war

Führen Sie es auf die vorherigen Schritte zurück. Der Workflow war eingegrenzt (Schritt 2): Abrufen und Zusammenfassen aus einer definierten Wissensdatenbank, kein autonomes Handeln. Der Korpus war begrenzt und mit Berechtigungen versehen (Schritt 5). Die Governance war aktiv: Evaluierungen, menschliche Überprüfung und eine Aufbewahrungsrichtlinie (Schritt 7). Die Beteiligten waren konzeptionell eingebunden (Schritt 8). Jedes Hindernis, das der Leitfaden vorgibt, wurde vor der Skalierung beseitigt. Deshalb hat sich die Einführung etabliert, anstatt in einer Demo stecken zu bleiben.

Was hätte dazu geführt, dass es nicht bereit gewesen wäre

Ändert man drei Variablen, kippt das Urteil auf „Warten“. Ein unbegrenzter Korpus, der Daten aus beliebigen internen Systemen zieht, würde den Test auf Begrenztheit aus Schritt 5 nicht bestehen. Autonomes Handeln ohne menschliche Freigabe würde den Governance-Test aus Schritt 7 nicht bestehen. Der Bewertungsschritt war nicht optional. Ohne Berater und Prompt-Engineers, die Antworten auf ihre Genauigkeit hin bewerten, gibt es keine Evidenzbasis, die das Vertrauen in die Ergebnisse im großen Stil rechtfertigt, sondern nur Annahmen. Diese Erkenntnis lässt sich übertragen: Die Einsatzbereitschaft ist eine Eigenschaft der Einschränkungen des Workflows, nicht der Marke des Anbieters. Dieselbe Logik bildet die Grundlage für den erfolgreichen Einsatz eines digitalen zweiten Gehirns, bei dem der Korpus und die Überprüfungsschleife darüber entscheiden, ob das Tool Vertrauen verdient.

Schritt 13: Welche Sonderfälle bringen generische Readiness-Frameworks zum Scheitern?

Einige Workflows scheitern an generischen Readiness-Formeln. Regulierte Arbeit, datenarme Umgebungen und unklare crossfunktionale Zuständigkeiten erfordern einen anderen Schwellenwert für die Entscheidung zwischen „Jetzt pilotieren“, „Zuerst umgestalten“ oder „Warten“. In diesen Fällen dominiert eine einzige Dimension das Urteil, und eine Mittelwertbildung mit anderen Faktoren führt zu einer gefährlich optimistischen Bewertung. Benennen Sie den dominierenden Blocker und entscheiden Sie sich dann dagegen.

In regulierten Arbeitsbereichen wiegen der Genehmigungsaufwand und die nachweisbare Aufsicht schwerer als die Modellqualität.Der Entwurf der FDA-Richtlinie vom Januar 2025 für KI-gestützte Gerätesoftware verlangt, dass in den Einreichungen der Mensch-KI-Workflow dokumentiert wird, um zu erfassen, wie Mensch und Modell an jedem Entscheidungspunkt interagieren. Das macht die Readiness-Entscheidung zu einer Kontrollfrage: Können Sie die Aufsicht bei jedem Schritt nachweisen?

Drei Sonderfälle hängen jeweils von einem dominierenden Blocker ab: Regulierte Workflows im Gesundheits-, Finanz- oder Rechtswesen hängen vom Genehmigungsaufwand und der Auditierbarkeit ab – pilotieren Sie also nur, wenn eine Human-on-the-Loop-Aufsicht durchgängig nachweisbar ist. Datenarme Umgebungen hängen vom Kaltstart-Problem ab (der Zeitraum, bevor das System genügend Interaktionsdaten gesammelt hat, um sichere, kalibrierte Vorhersagen zu treffen) – bevorzugen Sie hier einen regelbasierten oder menschlich unterstützten Piloten. Unklare crossfunktionale Zuständigkeiten scheitern daran, dass es keinen klaren Verantwortlichen für die neuen Entscheidungen gibt – gestalten Sie daher zuerst die Zuständigkeiten neu, anstatt ein Pilotprojekt im luftleeren Raum zu starten.

Die FDA-Richtliniezieht zudem eine nützliche Grenze zwischen „Human-in-the-Loop“ – was ein Eingreifen bei jeder Entscheidung bedeutet – und „Human-on-the-Loop“, was eine kontinuierliche Überwachung mit der Möglichkeit zur Übernahme beschreibt. Eine streng regulierte Branche kann dennoch ein eingegrenztes Pilotprojekt durchführen, wenn der Arbeitsablauf so eng gefasst ist, dass die Aufsicht kostengünstig bleibt. Die Regulierung selbst ist selten das Hindernis. Meist ist es die Unfähigkeit der Organisation, die Kontrolle innerhalb dieser Regulierung nachzuweisen.

Schritt 14: Wie überführen Sie die Ergebnisse in eine 30-60-90-Tage-Roadmap?

Ohne klare Verantwortliche gibt es keinen Fortschritt. Die Bewertung sollte mit einer priorisierten Maßnahmenliste und einem festen Termin für die erneute Überprüfung des Workflows abschließen. Die Reihenfolge richtet sich nach der Schwere der Blockaden aus den Schritten 4 bis 8, anstatt alles gleichzeitig anzugehen. Dokumentations- und Governance-Lücken müssen dabei zuerst behoben werden, da sie jeden nachgelagerten Schritt blockieren. Diese Sequenzierung spiegelt ein Stage-Gate-Modellwider: Jeder 30-Tage-Block ist ein Gate, das der Workflow passieren muss, bevor sich das nächste öffnet. Ohne namentlich zugewiesene Verantwortliche für jeden Punkt bleibt das Ergebnis reine Reifegrad-Kosmetik.

Die 30-60-90-Struktur

• Tag 0 bis 30: Beseitigen Sie Dokumentations- und Zugriffshindernisse. Kartieren Sie die Entscheidungslogik und Ausnahmen des definierten Workflows. Stellen Sie sicher, dass der Datenbestand (Corpus) erreichbar, autorisiert und rückverfolgbar ist. Weisen Sie einen Prozessverantwortlichen und einen Risikoverantwortlichen zu.
• Tag 31 bis 60: Etablieren Sie die Governance vor dem ersten Live-Einsatz. Richten Sie Logging und ein Freigabe-Gate ein. Implementieren Sie eine überwachte Ausgabestichprobe und einen Notausschalter (Kill Switch), sobald der Agent läuft. Führen Sie Evaluierungen mit einem zurückgehaltenen Testdatensatz (Held-out Set) durch.
• Tag 61 bis 90: Starten Sie den eingegrenzten Pilotbetrieb mit einem Human-in-the-Loop. Verfolgen Sie die einzelne Erfolgsmetrik aus Schritt 2. Entscheiden Sie über Eigenentwicklung, Zukauf, Konfiguration, Fortführung oder Abbruch auf Basis von Ergebnissen, nicht von Bauchgefühl.

Machen Sie den Plan so konkret, dass man sachlich darüber diskutieren kann. „Dokumentation verbessern“ ist kein Meilenstein. „Prozessverantwortliche Priya kartiert die Ausnahmepfade des Erstattungs-Workflows bis Tag 21, geprüft durch den Operations-Lead“ hingegen schon. Jede im Assessment aufgedeckte Lücke erhält einen Verantwortlichen, ein Fälligkeitsdatum und eine Definition of Done. Eine Behebung, die alle Lücken mit gleicher Priorität behandelt, ist der Grund, warum aus einem 90-Tage-Plan still und heimlich ein 18-Monats-Projekt wird.

In regelmäßigen Abständen wiederholen

Wiederholen Sie die Bewertung auf Workflow-Ebene, wenn sich der Workflow, seine Daten, seine Risikoklasse oder seine Kontrollumgebung wesentlich ändern. Führen Sie sie mindestens einmal pro Behebungszyklus durch. Weisen Sie jeder durch die Bewertung festgestellten Lücke einen namentlich genannten Verantwortlichen und eine Frist zu. Ohne beides überdauert ein Befund meist die Überprüfung, die ihn hervorgebracht hat.Microsoft definiert Bereitschaft als kontinuierlichen Prozess und nicht als einmalig erworbenen Nachweis. Dies macht die Überprüfung zu einer wiederkehrenden Disziplin und nicht zu einem Einzelereignis – der bereitschaftsspezifische Fall von kontinuierlicher Vorausschau: die Erkennung von Veränderungen als fortlaufende Praxis zu behandeln, nicht als einmaliges Audit. Teams, die diese Gewohnheit im Laufe der Zeit aufbauen, entwickeln auch eine stärkere Absorptionskapazität, also die Fähigkeit, die tatsächlichen Erkenntnisse aus jedem Pilotprojekt zu nutzen, anstatt im nächsten Zyklus dieselben Erfahrungen erneut machen zu müssen.

TL;DR (Entwurf)

• Eine Bewertung der KI-Bereitschaft ist ein Urteil pro Workflow: Jetzt bereitstellen, zuerst neu konzipieren oder warten.
• Betrachten Sie zuerst einen einzelnen Workflow. Unternehmensweite Bewertungen liefern nur Labels, keine Entscheidungen.
• Nur ca. 13 % der Unternehmen sind laut dem Cisco AI Readiness Index vollständig vorbereitet. Weitere 24 % können Live-Leitplanken einsetzen, um die Aktionen von Agenten zu steuern.
• Nicht dokumentierte Entscheidungslogik ist das größte versteckte Hindernis: 78 % der Großunternehmen berichten von Lücken bei der Prozessabbildung, so das Microsoft Agent Readiness Framework.
• Lassen Sie das Assessment nicht in bloßen Beobachtungen enden. Verpflichten Sie sich dazu, eine Lösung zu entwickeln, zu kaufen, zu konfigurieren, zu testen oder abzuwarten, und nutzen Sie anschließend einen 30-60-90-Tage-Plan, um diese Verpflichtung in die Tat umzusetzen.

Häufig gestellte Fragen

Was sollte eine KI-Bereitschaftsbewertung beinhalten?

Eine KI-Bereitschaftsbewertung auf Workflow-Ebene untersucht fünf Aspekte in der Reihenfolge ihrer Dringlichkeit: dokumentierte Entscheidungslogik und Ausnahmepfade, Datensuffizienz für die definierte Aufgabe, technische Schulden und Integrationskosten, Governance mit Live-Monitoring sowie die Verantwortlichkeit für das Change Management. Sie schließt mit einer konkreten Entscheidung ab. Die fünf Optionen sind: selbst entwickeln, kaufen, konfigurieren, pilotieren oder warten – nicht ein bloßer Reifegrad-Score.

Woran erkenne ich, ob mein Unternehmen bereit für KI ist?

Bewerten Sie einen einzelnen Workflow, nicht das gesamte Unternehmen. Bereit bedeutet, dass der eingegrenzte Workflow über eine dokumentierte Entscheidungslogik, autorisierte und rückverfolgbare Daten, einen praktikablen Integrationspfad, aktive Sicherheitsvorkehrungen (Guardrails) und benannte Verantwortliche für die neuen Entscheidungen verfügt. Wenn einer dieser Punkte fehlt, lautet die ehrliche Antwort: Zuerst neu konzipieren oder abwarten, verbunden mit einem konkreten Zeitplan, um die Lücke zu schließen.

Was ist der Unterschied zwischen KI-Bereitschaft (AI Readiness) und KI-Reife (AI Maturity)?

Die KI-Reife misst die allgemeine organisatorische Leistungsfähigkeit als Momentaufnahme auf einer Entwicklungskurve. Die KI-Bereitschaft ist eine Entscheidung über die Einsatzfähigkeit bezogen auf einen spezifischen Workflow.

Anfang 2025 bezeichneten laut McKinseys Studie „Superagency in the Workplace“ nur rund 1 % der Führungskräfte ihr Unternehmen als reif. Diese Einstufung bot, selbst wenn sie verdient war, keine Orientierung darüber, welcher Workflow als nächstes für eine Automatisierung bereit war.

Sind wir bereit für KI, wenn unsere Daten noch unstrukturiert und ungeordnet sind?

Unter Umständen ja. Unordnung im gesamten Unternehmen schließt einen klar abgegrenzten Workflow nicht aus. Entscheidend ist, ob der für das Projekt definierte Datenbestand zugänglich, autorisiert, rückverfolgbar und eingegrenzt ist. Wenn diese Bedingungen erfüllt sind, blockieren ungeordnete Daten an anderer Stelle Ihr Vorhaben nicht. Wenn sich Ergebnisse jedoch nicht bis zu den Quellbänden zurückverfolgen lassen, sollten Sie das Projekt stoppen – denn Sie können nichts überwachen, was Sie nicht rekonstruieren können.

Sollten wir selbst bauen, kaufen oder zuerst ein Pilotprojekt starten?

Für die meisten klar definierten Workflows ist der Kauf oder die Konfiguration eines spezialisierten Tools besser als der Eigenbau – Untersuchungen von MIT NANDAzeigen, dass Implementierungen durch Drittanbieter in etwa 67 % der Fälle erfolgreich sind, verglichen mit 33 % bei internen Entwicklungen. Bauen Sie nur dann selbst, wenn der Workflow ein dauerhaftes Differenzierungsmerkmal darstellt und Ihre Daten- und Integrationsreife hoch ist. Setzen Sie auf ein Pilotprojekt, wenn echtes Potenzial vorhanden ist, aber noch Lücken bei der Einsatzbereitschaft bestehen, die unter Beobachtung getestet werden sollten.

Wer muss an einer Bewertung der KI-Bereitschaft beteiligt sein?

Mindestens: der Prozesseigentümer und ein Mitarbeiter aus dem operativen Bereich. Darüber hinaus benötigen Sie die Risiko- und Governance-Ebene bis hin zum Executive Sponsor. Jede dieser Rollen beantwortet eine andere Frage zur Bereitschaft – von „Ist die Logik dokumentiert?“ bis hin zu „Werden wir die Arbeitsweise der Menschen tatsächlich verändern?“. Wenn der Sicherheitsverantwortliche oder der Sponsor fehlen, führt das dazu, dass Pilotprojekte auf dem Papier erfolgreich sind, aber in der Produktion stagnieren.

Wie oft sollten wir eine Bewertung der KI-Bereitschaft wiederholen?

Wiederholen Sie die Überprüfung auf Workflow-Ebene immer dann, wenn sich der Workflow, seine Daten, seine Risikoklasse oder seine Kontrollumgebung wesentlich ändern. Führen Sie sie mindestens einmal pro Behebungszyklus durch.Microsoftbeschreibt die Bereitschaft von Agenten als kontinuierlichen Prozess und nicht als einmalige Angelegenheit. Betrachten Sie die Bewertung daher als wiederkehrende Routine, die an Veränderungen gekoppelt ist, und nicht als jährliches Zertifikat.