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, wurde 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.

Ein AI Readiness Assessment ist die Bewertung, 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 unter dem Modell.

Die meisten Bewertungen enden bei einer Reifegrad-Klassifizierung. Dieser Leitfaden führt die Bewertung als einen sich verengenden Entscheidungspfad durch: Grenzen Sie einen Workflow ein, räumen Sie mit den Illusionen der Scorecard 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 die Entwicklung, den Kauf, die Konfiguration, das Pilotprojekt oder das Abwarten für einen konkreten Workflow sowie einen 30-60-90-Tage-Plan, um eventuelle 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 bringen. — 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 im Bereich der KI-Einführung als ausgereift bezeichneten. Diese Zahl aus McKinseys Studie „Superagency in the Workplace“ definierte die KI-Einführung neu – als ein Führungsproblem und nicht als eine Kompetenzlücke.

Bereitschaft versus Reife, in einem Satz

Reife beschreibt die Organisation. Bereitschaft entscheidet darüber, ob ein bestimmter Workflow jetzt sicher automatisiert werden kann. Der Rest dieses Leitfadens erarbeitet dieses Urteil, Blocker für Blocker. 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 Rendite in der Regel konzentriert.

Schritt 2: Warum Sie einen einzelnen 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 eine pauschale Einstufung. Wer seine Kräfte überall verteilt, hat am Ende nirgends Wirkung. Die operative Einheit ist ein einzelner Workflow, ein konkretes Geschäftsziel, eine klare Risikogrenze, der nächste 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 nur ein Label. Die Eingrenzung auf Workflow-Ebene liefert handlungsrelevante Ergebnisse.

Microsofts eigener Readiness-Ansatz warnt davor, dies als einmalige Übung zu betrachten. Das Team von Copilot Studio beschreibt die Bereitschaft für Agenten als eine kontinuierliche Abstimmung von Menschen, Prozessen und Technologie, die bei jeder Änderung der Rahmenbedingungen eine Neubewertung erfordert. Das ist der pragmatische 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 Antwort von einem Menschen freigegeben wird“ ist ein Workflow. Die zweite Version setzt das, womit der Agent arbeitet (Input und Datenbestand), in Bezug 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 angelegten Bewertung

McKinsey fand heraus, dass High Performer etwa dreimal häufiger spezifische Workflows um KI herum neu gestalten, anstatt sie direkt über alle Bereiche hinweg zu implementieren. Ein enger Fokus erzwingt die Diskussion über die Neugestaltung – ein breiter Fokus lässt Sie dieser ausweichen.

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 wegrechnen, beseitigen sie nicht, sondern manifestieren sie. Durchschnitte kaschieren den einen kritischen 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. In der Produktion 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 Workflows, nicht in der reinen Leistungsfähigkeit der Modelle. Der Hauptautor brachte den Mechanismus auf den Punkt.

Generische Tools wie ChatGPT sind für Einzelpersonen aufgrund ihrer Flexibilität hervorragend geeignet, scheitern jedoch im Unternehmenseinsatz, da sie nicht aus Workflows 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 zeigte, dass sich nur etwa 13 % der Unternehmen als voll vorbereitete „Pacesetter“ qualifizieren. Die Unterschiede zeigen sich in spezifischen Säulen wie Leitplanken und Change Management, nicht in der Gesamtnote.
• „Weitverbreitete KI-Nutzung beweist Bereitschaft.“ Eine Einführung ohne Governance ist Schatten-KI. Die Forschung von UpGuard aus dem Jahr 2025 fand heraus, dass mehr als 80 % der Beschäftigten nicht genehmigte KI-Tools nutzen. Führungskräfte gehören dabei zu den aktivsten Nutzern nicht freigegebener Tools, und weniger als 20 % der Beschäftigten beschränken sich auf die vom Unternehmen genehmigten 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 auf Tom Taullis Handbuch aus dem Jahr 2020 zurückgeht, warnt davor, dass das Codieren von manuellen Zwischenschritten („Swivel-Chair-Arbeit“) 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 führt 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 Kapazitäten messbar zu skalieren. — G2, AI Maturity Model: How to Assess and Scale

Ein Reifegradmodell ist ein legitimes Governance-Werkzeug. Es wird erst dann zur Farce, wenn sein gemittelter Output die eigentliche Workflow-Entscheidung ersetzt. Nutzen Sie die Scorecard, um Fortschritte 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 interpretieren. 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-Entscheidern in 13 Ländern kam mit einer anderen Stichprobe zum selben Ergebnis.

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

Das Problem der Ausnahmepfade

Menschen lösen Ausnahmen mit einem Achselzucken und einer Slack-Nachricht. Ein agentenbasiertes KI-Systemlöst sie durch Raten. Ein Erstattungsprozess hat vielleicht einen dokumentierten Pfad und neun ungeschriebene Ermessensentscheidungen über Kulanz, Betrugssignale und VIP-Konten. In genau diesen neun Fällen erfindet ein KI-Agent stillschweigend eigene Richtlinien. KI-Systeme arbeiten nicht mit Ambition. Sie arbeiten mit 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 funktionieren lässt: 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 sicher überwacht werden können. Eine unternehmensweite Datenperfektion ist ein jahrzehntelanges Projekt. Ein eingegrenztes Pilotprojekt benötigt lediglich lokale Hinlänglichkeit. Bewerten Sie nur den tatsächlich definierten Bereich und sparen Sie den Rest der Datenlandschaft für einen späteren Zyklus auf.

Die Bereitschaftsstudie von Microsoft identifiziert den Datenzugriff als die entscheidende Hürde für die Bereitstellung von Agenten.

80 % berichten von Daten, die 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 Ciscodefiniert zentralisierte Daten als eine der Säulen, die vorbereitete Organisationen vom Rest unterscheidet. Eine für die Überwachung ausreichende Zentralisierung ist die Schwelle für das Pilotprojekt. Eine perfekte Vereinheitlichung ist ein mehrjähriges Programm. Der überwachte Zugriff auf den eingegrenzten Datenbestand ist der Standard, der letztlich über die Freigabe eines Pilotprojekts entscheidet.

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 die Unordnung die Zugriffskontrollen, die Rückverfolgbarkeit oder die Begrenztheit des spezifischen Workflows beeinträchtigt. 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 früheren Hürden oft darüber entscheiden, ob sich der Integrationsaufwand ü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 Studien zur KI-Bereitschaft von Unternehmen wiederholt: Die Demo des Modells überzeugt, doch die Integrationsebene sprengt 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 kann, Berechtigungen auf Datensatzebene respektiert oder eine Änderung der nachgelagerten API übersteht. Seneca warnte, dass wir mehr in der Vorstellung als in der Realität leiden, aber bei technologischen Altschulden verhält es sich umgekehrt. Das Leiden in der Produktionsumgebung übertrifft alles, was die Demo vermuten ließ. Wenn die tatsächliche Logik eines Workflows in veralteten Schnittstellen liegt, legt die Automatisierung des Frontends die Schulden nur schneller offen. 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 das 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 man erstellt. Ein Workflow ist nicht bereit, wenn niemand sensible Aktionen genehmigen, Protokolle einsehen oder das System sicher stoppen kann. Die Kernanforderung ist Rückverfolgbarkeit. Benannte 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 Übergang in die Produktion überstehen. Auditierbarkeit ist eine zwingende Voraussetzung für die Betriebsbereitschaft. Peer-reviewed Forschung im Rechnungswesen betrachtet die Fähigkeit, KI-Aktionen zu prüfen, zu protokollieren und zu überprüfen, als Mindestanforderung, bevor KI in geschäftskritischen Prozessen eingesetzt wird.

Live-Monitoring versus statische Richtlinien

Eine PDF-Richtlinie ist ein Wunsch. Live-Monitoring ist eine Kontrollmaßnahme. Die Richtlinie besagt, dass der Agent riskante Aktionen eskalieren „sollte“. Live-Monitoring bedeutet, dass die Aktionen des Agenten an ein Dashboard gestreamt werden, ein Mensch mitten im Prozess eingreifen kann und jede Entscheidung mitsamt ihren Eingabedaten 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 echten 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 (Kill Switch) 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 der Tragweite 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 dennoch 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 Rollenänderungen, Eskalationspfade und Erfolgskriterien geeinigt haben, gerät das Pilotprojekt nach der Demo ins Stocken. Die Lücke liegt selten an den reinen Fachkenntnissen. Es ist die ungeklärte Zuständigkeit für die neuen Entscheidungen, Ausnahmen und Überprüfungen, die ein KI-Workflow mit sich bringt. Die Fähigkeit, Veränderungen zu verarbeiten, ist ein besserer Indikator für Skalierbarkeit als reiner Enthusiasmus, und sie hängt eng mit der allgemeinen Gesundheit der Innovationskulturzusammen.

[Cisco's 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) beziffert diese Kluft: 91 % der vorbereiteten Unternehmen verfügen über einen Change-Management-Plan, im Vergleich zu nur 35 % aller anderen. Peer-Review-Studienbestätigen zudem, dass die Barrieren ebenso psychologischer und organisatorischer wie technischer Natur sind. Aus diesem Grund reicht reine Schulung 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 Entscheidungsbefugnisse nicht zugewiesen sind – 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 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 Bereitschaft. Wenden Sie Risiken und Dokumentationslücken anschließend als Abzüge statt als Durchschnittswerte an. Die Vorlage für die Priorisierungsmatrix von InitializeAI gewichtet den Geschäftswert mit 35 bis 45 % und die Machbarkeit mit 25 bis 35 %, wobei Risiko und Datenbereitschaft 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 langweiligem, begrenztem Risiko. Dies ist dieselbe Logik, die auch hinter einem guten Marktvalidierungstest steht: kostengünstig, eingegrenzt und aufschlussreich, bevor Sie echtes Budget binden.

Ein konkretes Ranking-Beispiel

Betrachten wir drei potenzielle Workflows. Autonome Preisänderungen erzielen ein sehr hohes Potenzial und eine hohe Komplexität, aber das Risiko ist gravierend: direkte finanzielle Auswirkungen bei schwachen Sicherheitsvorkehrungen – genau das Profil, vor dem Schritt 7 warnt. Trotz des höchsten theoretischen Potenzials lautet das Urteil: abwarten. Die Extraktion von Vertragsklauseln erzielt ein mittleres Potenzial und eine mittlere 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 erzielen ein mittleres Potenzial und eine geringe Komplexität, mit einem Risiko nahe Null, da ein Mensch jeden Entwurf vor dem Versenden auf Basis 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 ausschließen, selbst wenn der reine Wertschöpfungswert hoch erscheint. Dieses Risiko wegzurechnen ist der Grund, warum Unternehmen sich 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 lediglich mit einer Reifegradbewertung statt einer Workflow-Entscheidung endet, ist reine Show: Das Unternehmen hat sich selbst benotet, aber immer noch keine Entscheidung getroffen.

Die Kontrollmechanismen und die Datenreife des Unternehmens bestimmen, welcher Beschaffungsweg überhaupt realisierbar ist.Untersuchungen zur institutionellen Reife definieren die Wahl zwischen einem Standard-Basismodell 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 Zahlen prognostizieren das Scheitern eines Pilotprojekts?

Organisationen überschätzen ihre Bereitschaft systematisch in vier Dimensionen: Dokumentationsqualität, Governance-Tiefe, 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 Ergebnis, da jeder einen Blocker benennt, den ein durchschnittlicher Reifegrad tendenziell verschleiert.

Lesen Sie die Tabelle als Reifegradfilter. 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 % zeigt 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 Rollout bei Morgan Stanley. Menschen überprüften und korrigierten die Ergebnisse, 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 die Prüfung auf Begrenztheit aus Schritt 5 nicht bestehen. Autonomes Handeln ohne menschliche Freigabe würde die Governance-Prüfung 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 liegt einem funktionierenden digitalen zweiten Gehirn zugrunde, 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 an ihre Grenzen?

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 „abwarten“. In diesen Fällen dominiert eine einzige Dimension das Gesamtergebnis, und die Mittelwertbildung mit anderen Faktoren führt zu einer gefährlich optimistischen Bewertung. Benennen Sie den dominierenden Blocker und entscheiden Sie auf dieser Basis.

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 fordert, dass Einreichungen den Mensch-KI-Workflow dokumentieren und erfassen, wie Mensch und Modell an jedem Entscheidungspunkt interagieren. Das macht die Readiness-Entscheidung zu einer Kontrollfrage: Können Sie die Aufsicht bei jedem einzelnen 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 am Kaltstart-Problem (der Zeitraum, bevor das System genügend Interaktionsdaten gesammelt hat, um verlässliche, kalibrierte Vorhersagen zu treffen) – bevorzugen Sie hier einen regelbasierten oder menschlich unterstützten Piloten. Unklare crossfunktionale Zuständigkeiten scheitern daran, dass es keinen eindeutigen 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 Verantwortliche gibt es keinen Fortschritt. Die Bewertung sollte mit einer priorisierten Behebung und einem festen Termin für die erneute Überprüfung des Workflows abschließen. Die Reihenfolge richtet sich nach der Schwere der Blocker aus den Schritten 4 bis 8, anstatt alles auf einmal 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 genannte Verantwortliche für jeden Punkt ist das Ergebnis lediglich Reifegrad-Theater.

Das 30-60-90-Schema

• Tag 0 bis 30: Beseitigen Sie Dokumentations- und Zugriffshindernisse. Kartieren Sie die Entscheidungslogik und Ausnahmen des definierten Workflows. Stellen Sie sicher, dass der Datenkorpus erreichbar, autorisiert und rückverfolgbar ist. Weisen Sie einen Prozesseigentümer 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 gegen einen 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 basierend auf harten Ergebnissen, nicht auf Bauchgefühl.

Formulieren Sie den Plan so konkret, dass man darüber diskutieren kann. „Dokumentation verbessern“ ist kein Meilenstein. „Prozessverantwortliche Priya kartiert die Ausnahmepfade des Erstattungsworkflows bis Tag 21, geprüft durch die Betriebsleitung“ hingegen schon. Jede durch die Bewertung aufgedeckte Lücke erhält genau 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, durch die er entstanden ist.Microsoft versteht Bereitschaft als kontinuierlichen Prozess und nicht als einmalig erworbenen Nachweis. Dies macht die Überprüfung zu einer wiederkehrenden Disziplin und nicht zu einem einmaligen Ereignis – 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)

• Ein AI Readiness Assessment liefert eine Bewertung pro Workflow: Jetzt implementieren, zuerst überarbeiten oder abwarten.
• Betrachten Sie zuerst einen einzelnen Workflow. Unternehmensweite Bewertungen liefern nur Labels, keine konkreten Entscheidungen.
• Nur ca. 13 % der Unternehmen sind laut dem Cisco AI Readiness Index vollständig vorbereitet. Weitere 24 % sind in der Lage, Live-Guardrails zur Steuerung von Agenten-Aktionen einzusetzen.
• Nicht dokumentierte Entscheidungslogik ist das größte versteckte Hindernis: 78 % der Großunternehmen berichten von Lücken in der Prozessdokumentation, so das Microsoft Agent Readiness Framework.
• Lassen Sie das Assessment nicht in bloßen Beobachtungen enden. Legen Sie sich fest, ob Sie bauen, kaufen, konfigurieren, pilotieren oder abwarten wollen, und nutzen Sie dann einen 30-60-90-Tage-Plan, um diese Verpflichtung in die Praxis 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 Entscheidung ab. Die fünf Optionen sind: entwickeln, kaufen, konfigurieren, pilotieren oder warten – nicht ein 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 Guardrails sowie benannte Verantwortliche für die neuen Entscheidungen verfügt. Wenn einer dieser Punkte fehlt, lautet die ehrliche Antwort: Zuerst umgestalten oder abwarten, verbunden mit einem konkreten Zeitplan zur Schließung dieser Lücke.

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

Die KI-Reife misst die allgemeine organisatorische Fä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“ 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 ungeordnet sind?

Möglicherweise. Unordnung im gesamten Unternehmen schließt einen klar abgegrenzten Workflow nicht aus. Entscheidend ist, ob der definierte Datenbestand zugänglich, autorisiert, rückverfolgbar und begrenzt ist. Wenn diese Voraussetzungen erfüllt sind, sind ungeordnete Daten an anderer Stelle kein Hindernis. Wenn sich Ergebnisse jedoch nicht auf die Quelldaten zurückführen lassen, sollten Sie das Projekt stoppen, da Sie nichts überwachen können, was Sie nicht rekonstruieren können.

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

Für die meisten klar abgegrenzten 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 Reifelücken bestehen, die unter Beobachtung getestet werden sollten.

Wer muss an einer KI-Bereitschaftsbewertung beteiligt sein?

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

Wie oft sollten wir eine Bewertung der KI-Bereitschaft erneut durchführen?

Führen Sie die Überprüfung auf Workflow-Ebene immer dann erneut durch, wenn sich der Workflow, seine Daten, seine Risikoklasse oder seine Kontrollumgebung wesentlich ändern. Führen Sie sie mindestens einmal pro Behebungszyklus durch.Microsoftbeschreibt die Agenten-Bereitschaft 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.