KI-Readiness-Check: Was Sie vor dem Kauf von KI prüfen sollten

Ein KI-Readiness-Check sollte klären, ob sich ein konkreter Prozess überhaupt zu verändern lohnt, ob die benötigten Daten zugänglich und verlässlich sind, aus welchen Systemen die KI lesen und in welche sie schreiben muss, was schiefgehen kann und wer für das Ergebnis verantwortlich ist. Modell- und Anbieterwahl kommen erst nach diesen Antworten.

Die meisten Bewertungen scheitern in eine von zwei Richtungen. Manche sind generische Reifegrad-Umfragen, die ein Unternehmen nach Kultur und Strategie bewerten, ohne einen einzigen Prozess zu benennen. Andere sind Verkaufsgespräche für ein bestimmtes Tool. Keine der beiden Varianten sagt Ihnen, was Sie bauen, was Sie kaufen und was Sie besser lassen sollten. Diese Checkliste liegt bewusst dazwischen.

Warum sich KI-Reife von außen schwer beurteilen lässt

KI-Projekte scheitern selten daran, dass das Modell zu schwach ist. Sie scheitern, weil das umgebende System nicht bereit war. Die Daten liegen in Exporten, die niemand aktualisiert. Der Prozess hat undokumentierte Ausnahmen, die nur eine Person beherrscht. Das Ergebnis muss in einem Tool landen, das keine brauchbare Schnittstelle bietet. Oder niemand hat festgelegt, wie eine richtige Antwort aussieht.

Diese Probleme sind in einer Demo unsichtbar. Eine Demo arbeitet mit sauberen Beispieldaten, überspringt Berechtigungen und endet, sobald die Antwort auf dem Bildschirm erscheint. Der Produktivbetrieb beginnt genau dort: Die Antwort muss geprüft, gespeichert, weiterverarbeitet, korrigiert und nachvollziehbar dokumentiert werden. Ein KI-Readiness-Check soll die Lücken zwischen diesen beiden Welten finden, solange sie noch günstig zu schließen sind.

Hinzu kommt ein Timing-Problem. Teams fragen meist erst nach einer Bewertung, wenn sie bereits ein Tool ausgewählt oder eine Funktion zugesagt haben. Dann wird die Bewertung zur nachträglichen Rechtfertigung. Am nützlichsten ist sie vor der Budgetfreigabe, solange die Antwort auch Nein lauten darf.

Typische Fehler

Der erste Fehler besteht darin, das Unternehmen statt des Prozesses zu bewerten. KI-Reife ist keine einzelne Kennzahl. Ein Unternehmen kann bereit sein, die Triage eingehender Anfragen zu automatisieren, und gleichzeitig weit davon entfernt, Erstattungsentscheidungen zu automatisieren. Bewerten Sie Kandidatenprozesse einzeln.

Der zweite Fehler ist, Datenverfügbarkeit als Ja-oder-Nein-Frage zu behandeln. Daten irgendwo zu haben ist etwas anderes, als sie programmatisch, mit den richtigen Berechtigungen und genau dann lesen zu können, wenn der Prozess läuft. Veraltete Tabellen und PDF-Archive sind durchaus Daten, bringen aber Extraktions- und Aktualisierungsaufwand mit sich, der in die Schätzung gehört.

Der dritte Fehler ist, nicht festzulegen, was „gut“ bedeutet. Wenn das Team für zwanzig echte Beispiele nicht beschreiben kann, wie eine korrekte Ausgabe aussieht, kann niemand beurteilen, ob ein KI-System funktioniert. Das ist kein Modellproblem, sondern eine fehlende Spezifikation.

Der vierte Fehler ist, den Schreibpfad zu ignorieren. Daten lesen und Text erzeugen ist die leichte Hälfte. Ein CRM aktualisieren, eine Nachricht versenden oder einen Datensatz ändern: Dort werden Fehler für Kunden sichtbar, und dort zählen Berechtigungen, Freigaben und Audit-Trails.

Eine praxistaugliche Struktur für die Bewertung

Ein sinnvoller KI-Readiness-Check geht für jeden Kandidatenprozess sechs Bereiche durch. Jeder Bereich endet mit einer kurzen schriftlichen Feststellung, nicht mit einer Punktzahl.

1. Passung des Prozesses

• Wie sieht der Prozess Schritt für Schritt aus, einschließlich der Ausnahmen, die manuell bearbeitet werden?
• Wie oft läuft er, und was passiert heute, wenn er langsam oder fehlerhaft ist?
• Welche Schritte erfordern Urteilsvermögen, und welche sind wiederkehrende Umformung von Informationen?
• Geht es darum, Zeit zu sparen, Fehler zu reduzieren, schneller zu reagieren oder etwas möglich zu machen, das heute gar nicht stattfindet?

2. Daten und Kontext

• Wo liegt jede Eingabe, wer hat Zugriff, und wie erfolgt der Zugriff: über eine Oberfläche, eine Datenbank, einen Export oder eine Person?
• Wie aktuell müssen die Daten sein, und wie aktuell sind sie tatsächlich?
• Enthalten Eingaben oder Ausgaben sensible, personenbezogene oder regulierte Informationen?
• Gibt es genügend echte, gelabelte Beispiele zum Testen?

3. Systeme und Integration

• Aus welchen Systemen muss die KI lesen, und in welche muss sie schreiben?
• Haben diese Systeme stabile Schnittstellen, dokumentierte Ratenlimits oder Webhook-Unterstützung?
• Wo werden Ergebnisse gespeichert, damit man sie später prüfen kann?

4. Risiko und Prüfung

• Was ist die schlimmste realistische Folge einer falschen Antwort, und wer bemerkt sie?
• Welche Aktionen brauchen eine menschliche Freigabe, bevor sie wirksam werden?
• Was muss protokolliert werden, um nachzuvollziehen, warum das System etwas getan hat?

5. Verantwortung

• Wer verantwortet den Prozess nach dem Go-live, einschließlich Änderungen an Prompts, Daten und Integrationen?
• Wer prüft Fehlschläge, und wie fließen sie in Korrekturen ein?

6. Evaluierung

• Wie sieht eine korrekte Ausgabe aus, schriftlich festgehalten für echte Beispiele?
• Wie vergleicht das Team Versionen, bevor eine Änderung ausgerollt wird?
• Welches Signal würde Ihnen sagen, dass Sie stoppen, vereinfachen oder zurückrollen sollten?

Hinweise zur Umsetzung

Führen Sie den Check mit den Menschen durch, die die Arbeit tatsächlich machen, nicht nur mit denen, die das Budget freigeben. Die Ausnahmen, an denen Automatisierung scheitert, kennt meist eine einzelne Sachbearbeiterin, und in keiner Prozessdokumentation tauchen sie auf.

Sammeln Sie Artefakte, keine Meinungen. Fragen Sie nach einem Beispielexport, einem Screenshot des Tools, in dem die Ergebnisse landen sollen, den aktuellen Antwortvorlagen und einer Handvoll echter Fälle, auch der unangenehmen. Eine Bewertung ohne echte Beispiele kann keine belastbare Schätzung liefern.

Regeln Sie den Umgang mit sensiblen Daten von Anfang an ausdrücklich. Legen Sie fest, welche Eingaben an einen externen Modellanbieter gehen dürfen, welche pseudonymisiert werden müssen und welche Ihre Systeme nie verlassen sollen. Sobald personenbezogene Daten betroffen sind, greift die DSGVO: Beziehen Sie Ihre Datenschutzbeauftragte oder Rechts- und Compliance-Abteilung ein, bevor ein Prototyp diese Daten verarbeitet. Das ist keine Rechtsberatung, sondern ein Hinweis, die Prüfung früh einzuplanen.

Machen Sie das Ergebnis entscheidungsreif. Ein guter KI-Readiness-Check endet mit einer priorisierten Liste von Prozessen, dem empfohlenen Vorgehen für den wichtigsten, den Hauptrisiken, den Voraussetzungen für den nächsten Schritt und einem groben Umfang, beschrieben über Aufwandstreiber statt über ein Angebot.

Abwägungen

Ein kurzer Check ist günstig und schnell, übersieht aber möglicherweise Integrationsgrenzen, die erst auftauchen, wenn jemand eine echte Schnittstelle aufruft. Ein längerer Check mit einem kleinen technischen Spike kostet mehr, ersetzt aber Annahmen durch Belege. Bei Prozessen, die in kundennahe Systeme schreiben, lohnt sich der Spike in der Regel.

Ein breiter Check über viele Abteilungen liefert eine nützliche Landkarte, aber selten eine Umsetzungsentscheidung. Ein enger Check von zwei oder drei Prozessen liefert eine Entscheidung, übersieht aber womöglich eine bessere Chance an anderer Stelle. Viele Teams machen zuerst einen breiten Durchgang und dann einen engen, tieferen für den besten Kandidaten.

Eine interne Bewertung hat mehr Kontext; eine externe hat weniger blinde Flecken dabei, was technisch leicht oder schwer ist. Beides zu kombinieren, mit internen Fachleuten und einem externen Engineer in derselben Sitzung, bringt oft die nützlichsten Meinungsverschiedenheiten ans Licht.

Erkenntnisse aus der Arbeit von ImadDhin

Das Eingangsformular des kostenlosen AI Readiness Scan auf dem Portal selbst ist ein kleines Beispiel für diese Denkweise. Der erste Punkt unten ist eine Beobachtung auf Code-Ebene zu diesem Formular; die beiden anderen beschreiben Muster, die Reviews solcher Eingangsprozesse häufig zutage fördern. Keiner davon ist eine Aussage über Ergebnisse.

Das Formular prüft auf dem Server zuerst die Struktur: eine gültige E-Mail-Adresse, eine Beschreibung des aktuellen Tech-Stacks mit Mindestlänge und eine Beschreibung des Geschäftsmodells mit Mindestlänge. Das ist eine bewusste Readiness-Schwelle. Ein Scan kann nichts Sinnvolles über einen Prozess sagen, den die anfragende Person nicht beschrieben hat. Zu dünne Anfragen werden deshalb mit einer klaren Validierungsmeldung abgelehnt, statt in einen vagen Bericht verwandelt zu werden.

Ein häufiger Befund in Reviews von Eingangsformularen ist eine Nutzungsregel, etwa eine kostenlose Anfrage pro E-Mail-Adresse, die nur im Browser durchgesetzt oder mit einem Lesevorgang und einem getrennten Schreibvorgang geprüft wird. Im ersten Fall lässt sie sich durch eine veränderte Anfrage umgehen; im zweiten können zwei gleichzeitige Anfragen beide durchkommen. Robuster ist es, die Regel atomar dort durchzusetzen, wo der Datensatz angelegt wird, eine konkrete, verständliche Meldung zurückzugeben, wenn sie greift, und jede Vorabprüfung im Browser bei einem Fehler durchlassen zu lassen, damit ein vorübergehendes Problem nie einen legitimen Besucher blockiert.

Ein weiterer häufiger Befund betrifft Arbeit, die nach dem Speichern des Datensatzes startet, etwa die Erstellung eines Berichts. Zuerst zu speichern hält das Absenden schnell und stellt sicher, dass die Anfrage auch dann existiert, wenn die nachgelagerte Verarbeitung scheitert. Der Zielkonflikt ist derselbe wie im Leitfaden zur Zuordnung von Content zu CRM-Anfragen: Eine Übergabe ohne Nachverfolgung ist keine dauerhafte Warteschlange. Muss die Zustellung garantiert sein, braucht der Datensatz einen Verarbeitungsstatus, einen Wiederholungsmechanismus und eine Warnung, die tatsächlich jemand liest.

Häufige Fehler, die Sie testen sollten

• Lassen Sie den Kandidatenprozess gegen echte historische Fälle laufen, auch gegen jene, die das Team als schwierig in Erinnerung hat, nicht nur gegen saubere Beispiele.
• Prüfen Sie, ob die KI mit Produktionsberechtigungen an die Daten kommt, nicht mit einem Administratorkonto aus der Demo.
• Testen Sie Eingaben mit fehlenden Feldern, widersprüchlichen Angaben und einer anderen Sprache als erwartet, etwa Englisch statt Deutsch.
• Stellen Sie sicher, dass ein fehlgeschlagener Schreibvorgang für jemanden sichtbar wird, statt still verloren zu gehen.
• Prüfen Sie, dass sensible Felder geschwärzt oder ausgeschlossen werden, bevor sie einen externen Anbieter erreichen.
• Lassen Sie eine zweite Person die Ausgaben anhand der schriftlichen Definition von „gut“ bewerten, und vergleichen Sie deren Urteile mit denen der ersten.

Wann eine einfachere Lösung besser ist

Manchmal ist die wertvollste Erkenntnis eines KI-Readiness-Checks, dass KI nicht der erste Hebel ist. Scheitert der Prozess, weil er nicht dokumentiert ist, dokumentieren Sie ihn. Scheitert er, weil Daten verstreut sind, führen Sie sie zusammen. Beantwortet eine feste Vorlage die meisten Anfragen korrekt, ist ein regelbasiertes Formular oder eine Textbausteinsammlung womöglich günstiger zu bauen und leichter zu pflegen als ein Modell.

Es kann auch sinnvoll sein, zu kaufen statt zu entwickeln. Deckt ein vorhandenes Tool den Prozess bereits ab und können Ihre Daten dort liegen, sollte der Check das klar sagen. Individuelle Entwicklung lohnt sich, wenn der Prozess spezifisch für Ihr Unternehmen ist, mehrere Systeme berührt oder Kontrollen braucht, die ein Standardtool nicht bietet.

Mit einem Prozess beginnen, nicht mit einer Strategiepräsentation

Wählen Sie den Prozess, der häufig läuft, spürbar schmerzt, wenn er langsam ist, und für den es echte Testbeispiele gibt. Bewerten Sie ihn entlang der sechs Bereiche oben und lassen Sie die Ergebnisse entscheiden, ob Sie entwickeln, kaufen, vereinfachen oder abwarten.

Sie können mit dem kostenlosen AI Readiness Scan starten, sich die Beratung zur KI-Automatisierung für eine tiefere Analyse ansehen oder einen Kandidatenprozess in einem 30-minütigen Gespräch mit uns durchgehen.