AI Readiness Audit: Business Cases validieren, bevor Code entsteht

Ein AI Readiness Audit ist eine Bewertung mit festem Umfang, die einen KI-Business-Case validiert, bevor die Entwicklung beginnt. Es beantwortet vier Fragen auf dem Papier (sind die Daten gut genug, ist der Anwendungsfall technisch machbar, rechtfertigt der Ertrag die Kosten, und welches regulatorische Risiko bringt er mit) und liefert eine priorisierte Roadmap dessen, was zuerst gebaut werden sollte. Es dauert typischerweise ein bis drei Wochen. Die Alternative ist, dieselben Antworten sechs Monate nach Projektstart zu finden, wenn das Budget bereits ausgegeben ist.

Die meisten gescheiterten KI-Projekte scheitern nicht an der Technik. Das Modell funktioniert. Die Pipeline läuft. Die Demo beeindruckt den Lenkungsausschuss. Das Projekt stirbt trotzdem, weil es auf einen Prozess zielte, den niemand verändert haben wollte, oder weil es von Daten abhing, die sich als unbrauchbar erwiesen, oder weil sich der Ertrag von Anfang an kleiner darstellte als die Wartungskosten. Nichts davon findet man, indem man mehr Code schreibt. Man findet es, indem man vor dem ersten Commit die härteren Fragen stellt, und genau dafür ist ein AI Readiness Audit da.

Was ist ein AI Readiness Audit?

Ein AI Readiness Audit ist eine strukturierte Bewertung der Daten, Systeme, Prozesse, Teams und regulatorischen Exposition einer Organisation, die in einer priorisierten Liste von KI-Anwendungsfällen mündet, sortiert nach Wirkung, Machbarkeit, Risiko und Aufwand. Es ist diagnostisch, nicht werblich. Sein wertvollstes Ergebnis ist oft die Liste der Dinge, die man nicht bauen sollte.

Es lohnt sich, es von drei Dingen abzugrenzen, mit denen es häufig verwechselt wird:

• Es ist kein Proof of Concept. Ein PoC prüft, ob ein Modell einen Genauigkeitswert erreicht. Ein Audit prüft, ob das Erreichen dieses Werts etwas verändern würde, das für das Geschäft zählt. Man kann einen PoC bestehen und am Business Case scheitern.
• Es ist keine Anbieterbewertung. Die Toolauswahl kommt danach. Eine Plattform zu wählen, bevor der Anwendungsfall feststeht, führt dazu, dass Organisationen Lizenzen für Funktionen besitzen, die sie nie in Betrieb nehmen.
• Es ist kein KI-Strategiepapier. Ein Strategiedokument beschreibt Ambitionen. Ein Audit erzeugt eine Entscheidung: dieses bauen, jenes kaufen, beim dritten warten, und hier sind die Belege für jede Festlegung.

Warum den Business Case validieren, bevor Code geschrieben wird?

Weil Code der teuerste Weg ist, etwas zu lernen, das man aus einer Tabelle und vier Interviews hätte lernen können. Jedes KI-Projekt trägt zwei Arten von Unsicherheit: die Unsicherheit, ob die Technologie funktioniert, und die Unsicherheit, ob sie etwas bewirkt. Entwicklung löst die erste Art auf. Nur eine Bewertung löst die zweite auf, und an der zweiten scheitern die meisten Projekte tatsächlich.

Die Asymmetrie ist deutlich. Ein Readiness Audit kostet wenige Wochen und liefert in jedem Fall eine Entscheidung: ein klares Go mit einem definierten ersten Ziel, oder ein dokumentiertes Nein, das ein Quartal Entwicklungszeit spart. Ein gescheitertes Projekt kostet die Entwicklung, die Opportunitätskosten dessen, was diese Entwickler nicht getan haben, die organisatorische Glaubwürdigkeit des KI-Programms selbst und die politische Schwierigkeit, das nächste Projekt vorzuschlagen, nachdem das letzte still verschwunden ist. Diesen letzten Punkt unterschätzen Teams. Ein einziger sichtbarer KI-Fehlschlag kann den Appetit einer Organisation für zwei Jahre einfrieren.

Es gibt auch ein Argument der Reihenfolge. Fast alles, was ein Audit erzeugt (die Dateninventur, die Prozess-Baseline, die Risikoklassifizierung, die Erfolgskennzahlen), ist Arbeit, die das Projekt ohnehin leisten müsste, nur später, unter Termindruck und mit einem Team, das sich bereits auf eine Richtung festgelegt hat. Sie zuerst zu erledigen ist kein Zusatzaufwand. Es ist dieselbe Arbeit, erledigt zu einem Zeitpunkt, an dem sie die Entscheidung noch verändern kann.

Die fünf Dimensionen einer KI-Reifebewertung

Ein brauchbares Audit untersucht fünf Dimensionen. Ein Anwendungsfall, der bei einer davon deutlich durchfällt, ist nicht bereit, egal wie stark er in den anderen aussieht.

1. Datenreife

Datenreife ist die Frage, ob die vorhandenen Daten die Entscheidung tragen können, die das Modell treffen soll. Nicht, ob viele Daten vorliegen, sondern ob die richtigen Daten vorliegen: gelabelt, zugänglich und repräsentativ für die Bedingungen, unter denen das System laufen wird.

Das Audit prüft Herkunft (woher stammen sie und dürfen sie rechtlich dafür genutzt werden), Abdeckung (enthalten sie die relevanten Randfälle oder nur den Normalfall), Labeling (existiert eine Ground Truth, und wer hat sie festgelegt), Menge im Verhältnis zur Schwierigkeit der Aufgabe, Drift (beschreiben die Daten des Vorjahres noch den heutigen Prozess) und Zugriff (liegen sie in einem Warehouse oder auf einer Maschine in der Fertigung, die seit 2019 niemand abgefragt hat). Datenreife ist der mit Abstand häufigste Grund, warum ein vielversprechender Anwendungsfall zurückgestuft wird, und zugleich das Günstigste, was sich prüfen lässt.

2. Technische Machbarkeit

Machbarkeit fragt, ob ein Modell die Genauigkeit erreichen kann, die der Anwendungsfall tatsächlich verlangt, und das ist ein anderer Wert als der, der beeindruckend klingt. Ein Modell zur Qualitätsprüfung mit 95% Genauigkeit ist hervorragend oder nutzlos, je nachdem, was die restlichen 5% kosten. Das Audit arbeitet von der Entscheidung rückwärts: Welche Falsch-Positiv-Rate ist tolerierbar, welche Falsch-Negativ-Rate ist tolerierbar, und gibt es Belege (aus der Literatur, aus vergleichbaren Einsätzen, aus einer schnellen Datenstichprobe), dass diese Schwellen mit den verfügbaren Daten erreichbar sind.

3. Business Case und ROI

Die ROI-Dimension übersetzt den Anwendungsfall in Zahlen, die einer Prüfung standhalten. Das bedeutet eine dokumentierte Baseline (was kostet dieser Prozess heute, in Stunden, Fehlern, Verzögerung oder Ausschuss), ein prognostiziertes Delta und ein ehrliches Total Cost of Ownership, also nicht nur den Aufbau, sondern Inference, Monitoring, Retraining, Integrationspflege und die menschliche Prüfschleife, die auf absehbare Zeit bestehen bleibt.

Die Disziplin besteht hier im Abziehen. Nutzen, der voraussetzt, dass eine andere Abteilung ihr Verhalten ändert, ist noch kein Nutzen; er ist eine Abhängigkeit. Eingesparte Stunden, die sich weder in Kapazität noch in Kosten niederschlagen, sind keine Einsparung; sie sind Leerlauf. Ein Audit, das keine belastbare Zahl findet, sagt damit etwas Wichtiges aus.

4. Regulatorisches und Compliance-Risiko

Nach dem EU AI Act folgen die Pflichten der Risikoklassifizierung, und die Klassifizierung folgt der Zweckbestimmung, die zur Entwurfszeit festgelegt wird und nicht beim Start. Ein System, das sich als Hochrisiko-System erweist, bringt Anforderungen an Daten-Governance, technische Dokumentation, Protokollierung, menschliche Aufsicht, Transparenz und Konformitätsbewertung mit sich. Das erst nach dem Einfrieren der Architektur zu entdecken bedeutet Nacharbeit; es während eines Audits zu entdecken bedeutet, von Anfang an dafür zu entwerfen, zu einem Bruchteil der Kosten.

Für KI im Gesundheitswesen können zusätzlich MDR/IVDR gelten, samt klinischer Bewertungspflichten, die den gesamten Projektzeitplan umformen. Überall dort, wo personenbezogene Daten berührt werden, gehören DSGVO-Fragen (Rechtsgrundlage, Zweckbindung, automatisierte Entscheidungsfindung) in die Bewertung und nicht in eine juristische Prüfung drei Wochen vor dem Go-live. Das ist Readiness- und Sensibilisierungsarbeit, keine Rechtsberatung, aber es ist der Unterschied zwischen einem Compliance-Gespräch, das Sie führen, und einem, von dem Sie überrascht werden.

5. Organisatorische und prozessuale Reife

Die letzte Dimension ist jene, die die meisten Projekte still zum Scheitern bringt: ob die Organisation das System aufnehmen kann. Gibt es nach der Übergabe einen benannten Verantwortlichen? Werden die Menschen, deren Arbeit sich ändert, vor der Änderung eingebunden oder erst danach informiert? Existiert ein Prozess, um auf die Ausgaben des Modells zu reagieren, oder landet die Ausgabe in einem Postfach, das niemandem gehört? Kann das Team es betreiben, oder wird es ein verwaister Dienst mit einem einzigen Wissensträger?

Ein technisch hervorragendes System, das in einem Prozess landet, der es umgeht, erzeugt exakt null Wert. Reife bedeutet hier nicht Begeisterung für KI; sie bedeutet, ob der Workflow einen Platz hat, den das System tatsächlich einnehmen kann.

Build vs. Buy: die Entscheidung, die das Audit erzwingt

Jeder validierte Anwendungsfall erhält eine Build-versus-Buy-Entscheidung mit Begründung. Die Faustregel ist einfach: bauen, wenn die Fähigkeit wirklich differenzierend ist und von Daten oder Prozesswissen abhängt, über das nur Sie verfügen; kaufen, wenn das Problem verbreitet ist und jemand es bereits besser gelöst hat, als Sie es im ersten Anlauf tun werden; warten, wenn sich die zugrunde liegende Technologie so schnell bewegt, dass die diesjährige Eigenentwicklung im nächsten Jahr eine Standardfunktion ist.

Der Fehlermodus ist in beide Richtungen derselbe: die Entscheidung fällt nebenbei. Teams bauen, weil Bauen sich nach Fortschritt anfühlt, oder kaufen, weil ein Anbieter zuerst mit einer guten Präsentation da war. Ein Audit macht die Entscheidung explizit und hält fest, warum, was zwölf Monate später zählt, wenn jemand danach fragt.

Was liefert ein AI Readiness Audit?

Die ROI-Zahlen, auf die sich ein Audit festlegt, sollten auf realistischen Bandbreiten beruhen statt auf Anbieteroptimismus; was vom Machine-Learning-ROI zu erwarten ist zeigt, wie diese in der Praxis aussehen.

Ein Readiness Audit sollte Ihnen Ergebnisse liefern, mit denen Sie arbeiten und die Sie in einer Budgetsitzung verteidigen können:

• Eine Bestandsaufnahme. Eine ehrliche Einschätzung von Daten, Systemen, Abläufen und Teamfähigkeiten, einschließlich der Stellen, an denen die Grundlagen fehlen.
• Eine priorisierte Chancenlandkarte. Anwendungsfälle bewertet nach Wirkung, Machbarkeit, Risiko und Aufwand, sodass die wertvollste Arbeit mit dem geringsten Risiko aufgrund von Belegen nach oben rückt und nicht aufgrund von Fürsprache.
• Eine Build-versus-Buy-Empfehlung je wesentlichem Anwendungsfall, mit Begründung.
• Compliance- und Risikohinweise. Berührungspunkte zu EU AI Act, DSGVO und, wo relevant, MDR/IVDR, markiert bevor sie zu Nacharbeit werden.
• Eine priorisierte Roadmap mit einem klar benannten ersten Quick Win: das Projekt, dessen Nachweis sich als Nächstes am meisten lohnt, gewählt weil es wertvoll, belegbar und klein genug zum Abschließen ist.
• Definierte Erfolgskennzahlen und eine Baseline, vereinbart vor dem Aufbau, damit der Pilot beurteilt statt diskutiert werden kann.

Die Roadmap zählt mehr als jede einzelne Erkenntnis. Eine priorisierte Liste verwandelt das KI-Gespräch von "welche Idee gefällt uns" in "welche machen wir zuerst, und was würde uns zum Abbruch bewegen", also die beiden Fragen, die ein Programm von einer Reihe von Experimenten unterscheiden.

Wann lohnt sich ein AI Readiness Audit?

Ein Audit rechnet sich, wenn eine echte Entscheidung darauf wartet. Die klarsten Signale:

• Sie haben mehr KI-Ideen als Budget und keine belastbare Möglichkeit, sie zu ordnen.
• Das Angebot eines Anbieters liegt auf dem Tisch und Sie können es nicht unabhängig beurteilen.
• Ein früherer KI-Pilot ist ins Stocken geraten und niemand ist sich einig, woran es lag.
• Sie stehen kurz davor, Entwicklungskapazität oder ein erhebliches Budget für einen Aufbau zu binden.
• Sie vermuten, dass ein Anwendungsfall nach dem EU AI Act ein Hochrisiko-System sein könnte, und wollen es wissen, bevor die Architektur feststeht.
• Die Führung wünscht sich eine KI-Strategie, und die ehrliche Antwort lautet, dass zuerst eine Landkarte nötig ist.

Wenn Sie früher dran sind und noch abwägen, ob KI überhaupt auf die Roadmap gehört, sind die Signale in woran Sie erkennen, ob Ihr Unternehmen bereit für KI ist die günstigere erste Lektüre. Ein Audit ist für den Moment, in dem sich die Frage von "sollten wir" zu "welches, und wie" verengt hat.

Es lohnt sich nicht, wenn der Anwendungsfall klein, umkehrbar und bereits gut verstanden ist: ein eng umrissenes internes Werkzeug mit offensichtlichem Nutzen und ohne regulatorische Exposition. Prüfen Sie die Entscheidungen, deren Umkehr teuer ist. Die anderen bauen Sie einfach.

Wie lange dauert ein AI Readiness Audit?

Ein bis drei Wochen ist die richtige Spanne für die meisten Organisationen, abhängig von der Datenkomplexität und der regulatorischen Exposition. Fertigung und mittelständische Kontexte liegen meist am kürzeren Ende; das Gesundheitswesen und andere regulierte Umgebungen brauchen länger, weil die Compliance-Dimension mehr Gewicht hat und die Nachweisanforderungen höher sind. Deutlich Kürzeres ist ein Workshop, und deutlich Längeres ist kein Entscheidungsinstrument mehr, sondern bereits das Projekt.

Der feste Umfang ist Absicht. Eine Bewertung, die sich unbegrenzt ausdehnen kann, wird das auch tun, und der Sinn der Übung ist, schnell genug zu einer Entscheidung zu kommen, dass sie noch eine beeinflusst.

Die ehrliche Zusammenfassung

Einen Business Case zu validieren, bevor Code geschrieben wird, ist keine Vorsicht und kein Verzögerungsmanöver. Es ist die Einsicht, dass die teure Unsicherheit in einem KI-Projekt fast nie technischer Natur ist. Ob das Modell 94% erreicht, ist eine Frage, die die Entwicklung beantworten kann. Ob 94% eine Entscheidung verändern, die irgendjemand trifft, auf Daten, die Sie nutzen dürfen, in einem Prozess, der das Ergebnis tatsächlich aufnimmt, unter einer Regulierung, die Sie korrekt eingeordnet haben. Diese Fragen werden auf dem Papier beantwortet oder durch einen gescheiterten Rollout.

Das Audit ist die günstige Variante, es herauszufinden. Ist es einmal erledigt, verbringt die anschließende KI-Integration ihr Budget damit, echte Unsicherheiten zu testen, statt grundlegende Lücken neu zu entdecken, und das erste Projekt hat ein definiertes Ziel, eine gemessene Baseline und einen Daseinsgrund, der die erste harte Nachfrage übersteht.

Häufige Fragen

Wie unterscheidet sich ein Readiness Audit von einem Anbieter-Proof-of-Concept?

Ein Anbieter-PoC zeigt, dass ein bestimmtes Produkt auf einem günstigen Ausschnitt Ihrer Daten funktioniert. Ein Audit fragt, ob der Anwendungsfall überhaupt lohnt, in welcher Form auch immer, und ob Kaufen das Bauen schlägt. Beide beantworten Verschiedenes, und die zweite Frage kommt zuerst.

Kann ein Audit ergeben, dass wir nichts bauen sollten?

Ja, und das ist ein legitimes und häufiges Ergebnis. Manchmal ist die Beschränkung ein Prozess, der erst definiert werden muss, ein Datenbestand, den es noch nicht gibt, oder ein Problem, das ohne KI besser gelöst wird. Das in Wochen zu erkennen statt nach dem Bau ist der Zweck.

Was müssen wir vor einem Audit vorbereiten?

Eine kurze Liste möglicher Anwendungsfälle, Zugang zu den Datenverantwortlichen und das, was Sie über den betreffenden Prozess ohnehin messen. Nichts muss aufgeräumt sein. Festzustellen, dass die entscheidende Kennzahl gar nicht erhoben wird, ist selbst ein nützlicher Befund.

Bindet uns ein Audit an denselben Partner für die Umsetzung?

Sollte es nicht. Ein brauchbares Audit hinterlässt einen priorisierten Plan, ein dokumentiertes Datenbild und eine Make-or-Buy-Empfehlung, die jedes kompetente Team umsetzen könnte. Ergibt das Ergebnis nur Sinn, wenn der Verfasser es umsetzt, ist das ein Warnsignal über das Audit.