KI-Use-Cases in HR richtig auswählen: Erst disqualifizieren, dann priorisieren

zuletzt aktualisiert 31. August 2026

Viele Unternehmen starten ihre KI-Strategie mit der Frage: Welche Use Cases sollten wir priorisieren? Doch genau das greift zu kurz. Bevor Nutzen, Aufwand oder Mitarbeiterwert bewertet werden, müssen ungeeignete Anwendungen konsequent aussortiert werden. Der Artikel zeigt ein praxisnahes Entscheidungsmodell für HR: Arbeit verstehen, Risiken und Tragfähigkeit prüfen – und erst dann priorisieren.

Einleitung

In vielen Unternehmen beginnt die KI-Einführung mit einer naheliegenden Frage:

Wo können wir KI einsetzen?

Dann werden Use Cases gesammelt: Texte erstellen, Dokumente zusammenfassen, Bewerbungen analysieren, Mitarbeiteranfragen beantworten, Reports automatisieren. Anschließend bewertet man Nutzen, Aufwand und technische Machbarkeit und erstellt daraus eine Prioritätenliste.

Das Problem liegt bereits in dieser Logik.

Denn nicht jeder KI-Use-Case gehört auf dieselbe Rangliste. Manche Anwendungen sollten gar nicht erst priorisiert werden, weil das zugrunde liegende Problem noch nicht verstanden ist, die technische Zuverlässigkeit für die möglichen Folgen nicht ausreicht oder der Business Case nicht trägt.

Eine hohe erwartete Zeitersparnis kann ein unvertretbares Risiko nicht kompensieren. Eine besonders belastende Aufgabe macht eine unzuverlässige Automatisierung nicht besser. Und eine technisch beeindruckende Lösung ist kein sinnvoller Use Case, wenn sie kaum relevanten Nutzen erzeugt.

Deshalb lautet die zentrale Regel:

Erst disqualifizieren, dann priorisieren.

Die Auswahl von KI-Use-Cases sollte nicht mit einem Gesamtscore beginnen, sondern mit einer Abfolge unterschiedlicher Entscheidungen.

Das Modell lässt sich in drei Phasen gliedern:

Discover → Decide → Deliver & Validate

• Discover: Wie wird die Arbeit tatsächlich erledigt und wo liegen die Probleme?
• Decide: Welche Use Cases sind überhaupt geeignet und welche davon sollten zuerst verfolgt werden?
• Deliver & Validate: Wie wird daraus eine funktionierende Lösung und lässt sich ihr realer Nutzen nachweisen?

Konkret:

Work Discovery → Problem & Process Clarity → Reliability × Criticality → Business & Governance Viability → Pain × Desire → Workflow Fit → Pilot & Evidence

Die vier Gates in der Decide-Phase bestimmen, ob überhaupt und wenn, in welcher Reihenfolge ein Use Case verfolgt wird. Die ersten drei Gates enthalten Knock-out-Kriterien. Gate 4 priorisiert unter den grundsätzlich geeigneten Kandidaten. Workflow Fit und Pilot & Evidence entscheiden anschließend, ob daraus eine tragfähige Lösung wird.

Discover: Work Discovery statt KI-Brainstorming

Der erste Fehler vieler KI-Workshops besteht darin, Mitarbeiter zu fragen:

„Welche KI-Use-Cases fallen Ihnen für Ihre Arbeit ein?“

Damit wird die Lösung bereits vorgegeben.

Die Antworten orientieren sich zwangsläufig an dem, was Menschen über KI kennen: Chatbots, Textgenerierung, Zusammenfassungen, Automatisierung, Recruiting oder Datenanalyse.

Interessanter ist eine andere Frage:

„Zeigen Sie mir, wie Sie diese Aufgabe tatsächlich erledigen.“

Das verändert die Perspektive vollständig.

Nicht die Technologie steht am Anfang, sondern die reale Arbeit.

Eine solche Work Discovery untersucht beispielsweise:

• Was löst einen Vorgang aus und welche Informationen werden dafür benötigt?
• Welche Systeme und Datenquellen werden verwendet?
• Wo müssen Informationen übertragen oder erneut eingegeben werden?
• Wo entstehen Wartezeiten, Rückfragen oder Fehler?
• Welche Fälle sind einfach, welche schwierig?
• Wo ist menschliches Urteil notwendig?
• Welche Arbeit empfinden Beschäftigte als unnötig aufwendig?
• Welche Aufgaben bleiben regelmäßig liegen?

Dabei kann sich herausstellen, dass KI effektiv eine gute Lösung ist.

Es kann aber genauso gut herauskommen, dass ein Prozessschritt abgeschafft, eine Schnittstelle verbessert, ein Formular verändert oder eine klassische Automatisierung eingesetzt werden sollte.

Eine gute AI Discovery beginnt mit Work Discovery.

Decide: Vier Gates vor der Priorisierung

Nach der Work Discovery beginnt die eigentliche Auswahl.

Dabei sollten nicht sofort Punkte verteilt werden. Zunächst muss geprüft werden, ob ein Use Case grundlegende Anforderungen erfüllt.

Die ersten drei Gates enthalten deshalb Knock-out-Kriterien.

Erst Gate 4 priorisiert unter den grundsätzlich geeigneten Kandidaten.

Gate 1: Problem & Process Clarity

Bevor geprüft wird, was eine KI leisten kann, sollte klar sein, welches Problem überhaupt gelöst werden soll.

Die entscheidende Frage lautet:

Verstehen wir die Arbeit und das Problem ausreichend gut, um über KI-Unterstützung oder Automatisierung zu entscheiden?

Das ist etwas anderes als klassische Prozessreife.

Ein Prozess kann hervorragend dokumentiert und standardisiert sein, aber trotzdem unnötige Schritte enthalten. Umgekehrt kann ein wenig standardisierter Prozess sehr gut verstanden sein.

Deshalb geht es hier um Problem & Process Clarity, nicht um einen abstrakten Reifegrad.

Zu prüfen sind insbesondere:

Ziel

Welches konkrete Problem soll gelöst werden?

Nicht:

„Wir möchten KI im Recruiting einsetzen.“

Sondern beispielsweise:

„Unsere Recruiter verbringen durchschnittlich 25 Minuten damit, Informationen aus mehreren Bewerbungsunterlagen in eine einheitliche Arbeitsstruktur zu übertragen.“

Prozess

Wie läuft die Aufgabe in der Realität ab? Nicht nur laut Prozesshandbuch, sondern im Alltag?

Entscheidungen

An welchen Stellen werden Entscheidungen getroffen und worauf basieren sie?

Ausnahmen

Welche Sonderfälle existieren und wie häufig treten sie auf?

Menschliches Urteil

Wo reicht eine Regel nicht aus? Wo werden Erfahrung, Kontext oder Abwägung benötigt?

Ergebnis

Was ist der gewünschte Output und woran lässt sich erkennen, ob er auch gut ist?

Wenn diese Fragen nicht beantwortet werden können, sollte die Reaktion nicht lauten:

„Dann testen wir einfach einmal ein KI-Tool.“

Sondern:

Prozess zuerst verstehen.

Denn sonst besteht die Gefahr, nicht nur eine Aufgabe zu automatisieren, sondern auch bestehende Unklarheit.

Gate-Entscheidung

Problem und Prozess ausreichend verstanden?

• Nein → Work Discovery fortsetzen oder Prozess neu gestalten.
• Ja → technische und risikobezogene Prüfung.

Ein unklar verstandenes Problem ist keine schlechte Punktzahl.

Es ist ein Stoppsignal.

Gate 2: Reliability × Criticality

Erst jetzt beginnt die eigentliche Prüfung der KI.

Dabei reichen Aussagen wie

„GPT kann das“

oder

„Im Test sah das sehr gut aus“

nicht aus.

Entscheidend sind zwei getrennte Fragen:

1. Wie zuverlässig funktioniert die konkrete KI-Lösung bei der konkreten Aufgabe?
2. Wie schwerwiegend sind die Folgen, wenn sie falsch liegt?

Daraus entsteht das zweite Gate:

Reliability × Criticality

Reliability: Funktioniert es unter realen Bedingungen?

Reliability bedeutet nicht, ob ein Modell eine Aufgabe grundsätzlich beherrscht.

Es bedeutet:

Wie zuverlässig erfüllt genau diese Systemkonfiguration genau diese Aufgabe mit unseren Daten und unter unseren realen Bedingungen?

Die geeigneten Messgrößen hängen vom Use Case ab.

Relevant können beispielsweise sein:

• korrekte Extraktion,
• Vollständigkeit,
• Fehlklassifikationen,
• False Positives und False Negatives,
• Halluzinationen,
• Konsistenz,
• Robustheit bei Sonderfällen,
• Qualität bei unterschiedlichen Personengruppen,
• erforderliche menschliche Korrekturen,
• Stabilität bei veränderten Eingabedaten.

Auch das NIST AI Risk Management Framework betrachtet Vertrauenswürdigkeit nicht als eine einzige abstrakte Eigenschaft. Zu den relevanten Merkmalen zählen unter anderem Validität und Zuverlässigkeit, Sicherheit und Resilienz, Transparenz, Erklärbarkeit, Datenschutz und der Umgang mit schädlichem Bias.

Die entscheidende Konsequenz:

Reliability muss für den konkreten Use Case gemessen werden. Sie kann nicht aus der allgemeinen Leistungsfähigkeit eines Modells abgeleitet werden.

Criticality: Was passiert, wenn die KI falsch liegt?

Die zweite Achse betrachtet die Auswirkungen eines Fehlers.

Ein falscher erster Entwurf für eine interne Veranstaltungsankündigung hat andere Konsequenzen als eine fehlerhafte Empfehlung darüber, welcher Bewerber im Auswahlprozess weiterkommt.

Criticality kann deshalb beispielsweise umfassen:

• Auswirkungen auf Menschen,
• Auswirkungen auf Beschäftigungsentscheidungen,
• Diskriminierungsrisiken,
• finanzielle Folgen,
• Datenschutzfolgen,
• rechtliche oder regulatorische Auswirkungen,
• Reputationsschäden,
• Reversibilität einer Entscheidung,
• Wahrscheinlichkeit, dass ein Fehler erkannt wird.

Entscheidend ist nicht nur:

Wie wahrscheinlich ist ein Fehler?

Sondern:

Was passiert, wenn er auftritt?

Die vier Felder

Criticality	Reliability	Konsequenz
hoch	niedrig	nicht automatisieren bzw. Einsatz grundlegend überdenken
hoch	hoch	kontrollierter Einsatz grundsätzlich prüfbar; Governance und menschliche Aufsicht entscheidend
niedrig	hoch	guter Kandidat für weitgehende Automatisierung
niedrig	niedrig	meist geringe Priorität

Eine Aufgabe kann von Mitarbeitern als extrem belastend empfunden werden und trotzdem der falsche Automatisierungskandidat sein.

Pain ist kein Ersatz für Reliability.

Und Begeisterung ist kein Ersatz für Risikokontrolle.

Human in the Loop reicht nicht

Bei kritischen KI-Anwendungen folgt häufig die Antwort:

„Dann kontrolliert eben noch ein Mensch.“

Aber ein Mensch im Prozess ist noch keine wirksame Kontrolle.

Entscheidend ist vielmehr:

• Kann der Mensch einen Fehler überhaupt erkennen?
• Sieht er die notwendigen Ausgangsinformationen?
• Versteht er die Fähigkeiten und Grenzen des Systems?
• Hat er ausreichend Zeit für eine echte Prüfung?
• Kann er dem KI-Output widersprechen?
• Darf er ihn organisatorisch überstimmen?
• Kann er die Entscheidung technisch verändern?
• Wird aus der Kontrolle mit der Zeit nur noch ein Bestätigen des Vorschlags?

Gerade der letzte Punkt ist wichtig.

Menschen können dazu neigen, Empfehlungen automatisierter Systeme übermäßig zu vertrauen. Der EU AI Act adressiert diesen Automation Bias bei der menschlichen Aufsicht über Hochrisiko-Systeme ausdrücklich. Zu wirksamer Aufsicht gehört unter anderem, Fähigkeiten und Grenzen eines Systems zu verstehen, Outputs richtig zu interpretieren und sie gegebenenfalls zu ignorieren, zu überstimmen oder rückgängig zu machen. Die aktuelle konsolidierte Fassung des AI Act berücksichtigt dabei bereits die Änderungen bis Juli 2026.

Die relevante Frage lautet daher nicht:

„Ist ein Mensch beteiligt?“

Sondern:

„Ist die menschliche Kontrolle nachweislich wirksam oder ist sie nur formal vorhanden?“

Gate 3: Business & Governance Viability

Ein Use Case kann technisch geeignet und risikoseitig vertretbar sein und dabei trotzdem keinen Sinn ergeben.

Deshalb folgt eine eigene Viability-Prüfung.

Sie besteht aus zwei Teilen.

Wirtschaftliche Tragfähigkeit

Die erste Frage lautet:

Lohnt sich die Veränderung?

Eine KI-Anwendung, die pro Vorgang 20 Minuten spart, klingt attraktiv.

Wenn der Vorgang jedoch nur 20-mal jährlich auftritt, beträgt die theoretische Einsparung weniger als sieben Stunden pro Jahr.

Eine andere Anwendung spart vielleicht lediglich zwei Minuten. Bei 100.000 Vorgängen jährlich entstehen daraus mehr als 3.000 Stunden potenzieller Zeitgewinn.

Entscheidend ist deshalb nicht allein die Einsparung pro Vorgang, sondern ihr Gesamteffekt über das Prozessvolumen.

Diesem Gesamtnutzen müssen die Kosten der Lösung gegenübergestellt werden, darunter:

• Implementierung,
• Schnittstellen,
• Datenaufbereitung,
• Betrieb,
• Monitoring,
• Qualitätssicherung,
• Schulung,
• Support,
• Governance,
• menschliche Prüfzeit,
• notwendige Nacharbeit.

Ein spektakulärer Use Case kann einen schlechten Business Case haben.

Ein unspektakulärer kann dagegen hoch relevant sein.

Governance-Tragfähigkeit

Daneben steht eine zweite Frage:

Können wir diesen Einsatz organisatorisch und regulatorisch verantworten?

Dazu können je nach Use Case gehören:

• Datenschutz,
• Informationssicherheit,
• Zugriffsrechte,
• Mitbestimmung,
• Dokumentation,
• Verantwortlichkeiten,
• Anbieterabhängigkeit,
• Datenherkunft,
• Auditierbarkeit,
• regulatorische Klassifikation.

Diese Prüfung sollte bewusst getrennt von der technischen Reliability erfolgen.

Eine KI kann technisch hervorragend funktionieren und trotzdem in der vorgesehenen Form organisatorisch, ökonomisch oder rechtlich nicht tragfähig sein.

Gate-Entscheidung

Wirtschaftlich tragfähig und organisatorisch sowie regulatorisch verantwortbar?

• Nein → stoppen oder Design verändern.
• Ja → Mitarbeiterwert beurteilen.

Erst jetzt lohnt es sich, über Priorisierung zu sprechen.

Recruiting und Beschäftigungsentscheidungen: Warum Governance früh beginnen muss

Gerade im HR-Bereich zeigt sich, warum Governance nicht erst am Ende geprüft werden sollte.

Der EU AI Act führt bestimmte KI-Anwendungen im Bereich Beschäftigung ausdrücklich in Anhang III auf. Dazu gehören unter anderem Systeme, die zur Rekrutierung oder Auswahl eingesetzt werden, Bewerbungen analysieren oder filtern und Kandidaten bewerten. Ebenfalls genannt werden bestimmte Systeme für Entscheidungen über Beschäftigungsverhältnisse sowie zur Überwachung oder Bewertung von Leistung und Verhalten.

Das bedeutet allerdings nicht, dass jede KI-Funktion innerhalb eines HR-Prozesses automatisch identisch einzustufen ist.

Art. 6 Abs. 3 sieht für bestimmte in Anhang III genannte Systeme eine differenzierte Beurteilung vor, wenn sie unter anderem nur eine enge prozedurale oder vorbereitende Aufgabe erfüllen und das Ergebnis einer Entscheidung nicht wesentlich beeinflussen. Profiling wird dabei gesondert behandelt.

Damit wird eine für die Use-Case-Bewertung wichtige Regel sichtbar:

Nicht das verwendete Modell allein bestimmt das Risiko. Entscheidend sind Zweck, Funktion und der reale Einfluss innerhalb des Prozesses.

Eine generative KI, die einen Textentwurf erstellt, und dieselbe technische Modellfamilie, die eine Auswahlentscheidung beeinflusst, können deshalb völlig unterschiedlich zu bewerten sein.

Nach der derzeit geltenden Rechtslage gelten die zentralen Hochrisikoanforderungen für Systeme nach Art. 6 Abs. 2 und Anhang III ab dem 2. Dezember 2027. Diese Verschiebung wurde mit der Verordnung (EU) 2026/1744 eingeführt.

Das ist jedoch kein sinnvoller Grund, Governance-Prüfungen bis dahin aufzuschieben. Anforderungen an KI-Kompetenz nach Art. 4 gelten bereits. Unternehmen sollten daher schon heute sicherstellen, dass Personen, die KI-Systeme einsetzen oder beaufsichtigen, über ausreichende Kenntnisse für ihren jeweiligen Einsatzkontext verfügen.

Für die Use-Case-Auswahl genügt deshalb eine praktische Regel:

HR-KI mit Einfluss auf Menschen oder Beschäftigungsentscheidungen frühzeitig fachlich, technisch und regulatorisch prüfen und nicht erst kurz vor dem Rollout.

Gate 4: Pain × Desire

Erst an dieser Stelle kommt eine Frage, die in vielen KI-Projekten fälschlicherweise oft schon ganz am Anfang gestellt wird:

Wo erzeugt die Veränderung tatsächlich Wert für die Beschäftigten?

Die grundsätzlich ungeeigneten Anwendungen wurden jetzt bereits aussortiert. Unter den verbleibenden Kandidaten muss entschieden werden, welche zuerst umgesetzt werden sollten.

Dafür sind zwei getrennte Dimensionen hilfreich:

Pain und Desire.

Pain: Wie belastend ist die heutige Arbeit?

Pain beschreibt die Reibung innerhalb einer Aufgabe, beispielsweise:

• repetitive Tätigkeit,
• unnötige Dateneingaben,
• Medienbrüche,
• Suchaufwand,
• häufige Unterbrechungen,
• Fehlerrisiken,
• administrative Belastung,
• Wartezeiten,
• unnötige Abstimmung.

Hoher Pain bedeutet:

Hier gibt es ein reales Problem.

Aber das allein sagt noch nicht, welcher zusätzliche Wert durch eine Veränderung entsteht.

Desire: Gibt es eine attraktivere Verwendung der frei werdenden Kapazität?

Mit Desire ist hier nicht die Zustimmung zu KI gemeint.

Desire beschreibt, ob es aus Sicht der Beschäftigten eine attraktivere Verwendung der frei werdenden Kapazität gibt.

Das können beispielsweise sein:

• beraten,
• kommunizieren,
• analysieren,
• gestalten,
• entscheiden,
• lernen,
• Beziehungen aufbauen,
• komplexe Fälle bearbeiten.

Eine Automatisierung kann zunächst schlicht Entlastung schaffen: Repetitive oder administrative Arbeit entfällt, Zeit und Reibung werden reduziert. Das ist bereits ein legitimer Nutzen.

Sie kann aber auch Kapazität für Arbeit schaffen, die Beschäftigte als wertvoller erleben. Dann geht es nicht mehr nur um Effizienz, sondern auch um veränderte Rollen und Aufgaben.

Ob diese Arbeit organisatorisch wirklich ermöglicht wird, muss bei der Umsetzung geprüft werden und dies ist ein wesentlicher Punkt. Frei werdende Kapazität erzeugt nicht automatisch wertvollere Arbeit. Dafür müssen Aufgaben, Rollen, Ziele und Erwartungen gegebenenfalls neu gestaltet werden. Wenn Beschäftigte zwar Zeit gewinnen, diese aber lediglich mit zusätzlichem Volumen, mehr administrativen Aufgaben oder unveränderten Zielvorgaben gefüllt wird, bleibt der versprochene Nutzen aus ihrer Sicht aus.

Gerade deshalb sollte bereits vor der Automatisierung geklärt werden, wofür die frei werdende Zeit konkret genutzt werden soll. Mehr Beratung, intensivere Zusammenarbeit, komplexere Fälle oder zusätzliche Lernzeit entstehen nicht von selbst. Die Organisation muss dafür auch tatsächlich Raum schaffen. Sonst wird aus dem Versprechen „KI schafft Zeit für wertvollere Arbeit“ schnell nur „KI schafft Zeit für noch mehr Arbeit“ – und genau das kann Vertrauen und Akzeptanz bei späteren KI-Einführungen beschädigen.

Die vier Felder

Pain	Desire	Einordnung
hoch	hoch	sehr guter Kandidat für frühen Pilot
hoch	niedrig	sinnvolle Entlastung, aber kein großes Transformationsversprechen
niedrig	hoch	möglicher Enabler für wertvollere Arbeit
niedrig	niedrig	geringe Priorität

Diese Matrix ist kein Risikofilter.

Sie ist ein Priorisierungsinstrument.

Der entscheidende Unterschied

Gate 1 bis 3 fragen: Sollten wir diesen Use Case überhaupt verfolgen?

Gate 4 fragt: Welchen der geeigneten Use Cases sollten wir zuerst verfolgen?

Damit endet die eigentliche Auswahlphase.

Was danach folgt, entscheidet darüber, ob aus einem guten Use Case auch eine tragfähige Lösung wird.

Deliver & Validate: Aus einem guten Use Case muss eine funktionierende Lösung werden

Ein Use Case hat die vier Entscheidungstore passiert.

Das bedeutet noch nicht, dass die Arbeit dadurch tatsächlich besser wird.

Jetzt beginnt die Umsetzung.

Workflow Fit: KI muss in die reale Arbeit passen

Ein sinnvoll ausgewählter Use Case kann immer noch scheitern.

Zum Beispiel so:

Ein Mitarbeiter arbeitet in seinem HR-System. Dann öffnet er zusätzlich einen KI-Chat, kopiert Informationen hinein, formuliert einen Prompt, prüft den Output und überträgt das Ergebnis zurück.

Technisch wurde KI eingeführt.

Prozessual wurde zusätzliche Arbeit geschaffen.

Deshalb lautet die nächste Frage:

Wie muss die Lösung in die reale Arbeit integriert werden?

Zu prüfen ist unter anderem:

• Wo erscheint die KI-Unterstützung?
• Welche Informationen erhält das System?
• Müssen Daten manuell übertragen werden?
• Sind die verwendeten Quellen sichtbar?
• Wie wird Unsicherheit dargestellt?
• Wer überprüft welche Ergebnisse?
• Wie werden Fehler korrigiert?
• Wie wird ein KI-Vorschlag verworfen?
• Wo wird das freigegebene Ergebnis weiterverarbeitet?
• Entsteht ein neuer Arbeitsschritt oder entfällt wirklich einer?

Hier zeigt sich ein grundlegender Unterschied zwischen Usability und Workflow Fit.

Ein KI-Tool kann hervorragend bedienbar sein und trotzdem schlecht in die Arbeit passen.

Ein schönes Chatfenster ist kein Prozessdesign.

Pilot & Evidence: Nutzung ist noch kein Nutzen

Am Ende bleibt die wichtigste Frage:

Hat die KI die Arbeit tatsächlich verbessert?

Das kann ein Unternehmen nur beantworten, wenn es vor dem Pilot weiß, wie der Prozess ohne KI funktioniert.

Deshalb gehört eine Baseline zum Pilotdesign.

Je nach Anwendung können beispielsweise erfasst werden:

• Bearbeitungszeit,
• Durchlaufzeit,
• Fehlerquote,
• Nacharbeit,
• Kosten pro Vorgang,
• Prozessabbrüche,
• Qualität,
• Mitarbeitererleben.

Während des KI-Piloten kommen weitere Kennzahlen hinzu:

• Korrekturquote,
• Override-Rate,
• problematische Outputs,
• nicht bearbeitbare Sonderfälle,
• tatsächliche Zeitersparnis,
• neue Fehlerarten,
• zusätzlicher Prüfaufwand.

Nutzungszahlen beantworten lediglich:

Wird das System verwendet?

Nicht:

Ist die Arbeit dadurch besser geworden?

Auch das NIST AI RMF versteht Risikomanagement als fortlaufenden Prozess. Seine vier Kernfunktionen Govern, Map, Measure und Manage verbinden Kontext, Messung und Steuerung.

Ein Pilot sollte deshalb nicht mit der Feststellung enden:

„80 Prozent der Mitarbeiter nutzen das Tool.“

Sondern mit einer evidenzbasierten Entscheidung:

Stoppen, verändern, weiter pilotieren oder skalieren?

Das vollständige Modell: Discover, Decide, Deliver & Validate

Phase 1: Discover

Schritt	Leitfrage	Funktion
Work Discovery	Wie wird die Arbeit tatsächlich erledigt?	Probleme, Entscheidungen und Friktion sichtbar machen

Phase 2: Decide

Gate	Leitfrage	Funktion
1. Problem & Process Clarity	Verstehen wir Problem, Prozess und Entscheidungen ausreichend?	Knock-out / Redesign
2. Reliability × Criticality	Ist die KI zuverlässig genug für die möglichen Folgen ihrer Fehler?	Knock-out / Assist / Automate
3. Business & Governance Viability	Lohnt sich die Lösung und können wir sie verantworten?	Knock-out / Redesign
4. Pain × Desire	Wo erzeugt Veränderung den größten Beschäftigtenwert?	Priorisierung

Phase 3: Deliver & Validate

Schritt	Leitfrage	Funktion
Workflow Fit	Passt die Lösung in die tatsächliche Arbeit?	Lösungsdesign
Pilot & Evidence	Verbessert sie die Arbeit messbar?	Stop / Improve / Scale

Die Struktur macht den Kern des Modells sichtbar:

Die ersten drei Gates können einen Use Case disqualifizieren. Gate 4 priorisiert die geeigneten Kandidaten. Workflow Fit und Pilot & Evidence entscheiden anschließend, ob daraus eine tragfähige Lösung wird.

Ein kritischer Mangel ist keine schlechte Punktzahl.

Er ist ein Stoppsignal.

Beispiel Recruiting: Gleiche Technologie, völlig anderer Use Case

Wie relevant diese Unterscheidung ist, zeigt ein einfaches Recruiting-Beispiel.

Use Case A: KI entscheidet über das Ausscheiden von Bewerbern

Eine KI analysiert Bewerbungen, bewertet Kandidaten und sortiert einen Teil automatisch aus.

Der Business-Nutzen könnte hoch sein. Das Prozessvolumen möglicherweise ebenfalls. Auch der Pain für Recruiter kann erheblich sein.

Trotzdem beginnt die Bewertung nicht dort.

Die entscheidenden Fragen sind:

• Wie zuverlässig ist die Bewertung?
• Welche Bewerber werden fälschlich aussortiert?
• Gibt es relevante Unterschiede zwischen Personengruppen?
• Wie werden Sonderfälle behandelt?
• Kann die Entscheidung nachvollzogen werden?
• Welche Auswirkungen hat ein Fehler?
• Welche regulatorische Einstufung ergibt sich?

Hoher Pain und hoher ROI können diese Fragen nicht überspringen.

Use Case B: KI erstellt eine strukturierte Arbeitsunterlage

Nun eine andere Anwendung.

Eine KI extrahiert vorher festgelegte sachliche Informationen aus Bewerbungsunterlagen und stellt sie für Recruiter strukturiert zusammen.

Sie trifft keine Auswahlentscheidung, vergibt keinen Score und empfiehlt keine Ablehnung. Die Originalunterlagen bleiben verfügbar und der Recruiter kann die extrahierten Informationen prüfen und korrigieren.

Technisch kann dabei dieselbe Modellfamilie wie in Use Case A eingesetzt werden.

Der Use Case ist dennoch grundlegend anders.

Reliability kann beispielsweise anhand korrekter Extraktion und Vollständigkeit gemessen werden. Fehler können durch Rückgriff auf die Quelle leichter erkennbar und reversibel sein.

Aber auch hier darf nicht pauschal behauptet werden, dass die Anwendung deshalb regulatorisch unproblematisch sei. Zweck, konkrete Funktion und tatsächlicher Einfluss auf die weitere Auswahl bleiben entscheidend.

Das Beispiel zeigt:

KI-Risiko ist keine feste Eigenschaft eines Modells. Es entsteht aus dem Zusammenspiel von Technologie, Aufgabe, Prozess und Wirkung.

Die Reihenfolge verändert die KI-Strategie

Die verbreitete Reihenfolge lautet häufig:

Tool auswählen → Use Cases sammeln → priorisieren → ausrollen → Nutzung messen

Das Modell dreht diese Logik um:

Arbeit verstehen → Problem klären → ungeeignete Anwendungen aussortieren → geeignete Anwendungen priorisieren → Workflow gestalten → Wirkung messen → skalieren

KI ist damit nicht mehr der Ausgangspunkt, für den nachträglich Probleme gesucht werden.

Sie wird zu einer möglichen Lösung für ein zuvor verstandenes Arbeitsproblem.

Mehr Automatisierung ist dabei nicht automatisch mehr Erfolg. Eine KI, die einen Menschen bei einer kritischen Aufgabe sinnvoll unterstützt, kann wesentlich wertvoller sein als eine vollständig automatisierte Anwendung mit marginalem Nutzen.

Fazit: Eine gute KI-Strategie erkennt auch, was sie nicht tun sollte

Bei KI-Strategien wird Erfolg häufig daran gemessen, wie viele Use Cases identifiziert, Piloten gestartet oder Mitarbeiter mit Tools ausgestattet wurden.

Das greift zu kurz.

Die Qualität einer KI-Strategie zeigt sich auch daran, wie konsequent ungeeignete Anwendungen aussortiert werden.

Ein guter Einstiegs-Use-Case muss nicht spektakulär sein. Oft ist das Gegenteil der Fall: eine klar verstandene Aufgabe, ein reales Problem, ausreichende technische Zuverlässigkeit, vertretbare Fehlerfolgen, ein tragfähiger Business Case, klare Governance, spürbarer Mitarbeiterwert, gute Integration in den Workflow und messbarer Nutzen.

Eine gute KI-Strategie erkennt nicht nur Chancen.

Sie muss auch begründet Nein sagen können.

Deshalb sollte ein Unternehmen nicht mit der Frage beginnen:

„Was können wir mit KI automatisieren?“

Sondern:

„Welche Arbeit sollten wir verbessern – und unter welchen Bedingungen ist KI dafür wirklich die beste Lösung?“

Erst disqualifizieren. Dann priorisieren.

zum Video auf Youtube

zur Podcast-Folge auf Spotify