Workflow-Audit für Agent Readiness: Methodik

“Welche HR-Prozesse sind KI-fähig?” ist die falsche Frage

Eine HR-Verantwortliche sitzt im Steuerkreis ihres KI-Programms. Auf der Folie steht: “Phase 1 - Krankmeldungsverarbeitung automatisieren.” Sechs Wochen später ist der Pilot zurückgestellt. Die Begründung: “Funktioniert nicht zuverlässig genug.” Was ist passiert? Das Projekt hat den Workflow als eine Einheit behandelt. Aber Krankmeldungsverarbeitung ist keine Einheit. Sie ist eine Sequenz aus zwölf Entscheidungspunkten - und zwei davon hätten beim Menschen bleiben müssen.

Das ist keine Anekdote. Es ist das Grundmuster. KI-Projekte in HR scheitern selten an der Modellqualität und fast immer an der Granularität der Frage. Wer fragt “Welche Workflows automatisieren wir?”, bekommt unbrauchbare Antworten. Wer fragt “An welchen Entscheidungspunkten innerhalb eines Workflows?”, bekommt eine umsetzbare Architektur.

Diese Methodik beschreibt, wie man die richtige Frage stellt. Sie ist technologie-agnostisch - keine Modellpräferenz, kein Anbieter, kein Stack. Sie produziert vier Artefakte aus einem Audit: ein Agent-Design, eine Betriebsvereinbarungs-Vorlage, eine Decision-Layer-Spezifikation und die EU-AI-Act-Dokumentation für Hochrisiko-Systeme (Frist 2. August 2026, voraussichtlich verschoben auf Dezember 2027).

McKinsey schätzt, dass 60 - 70 % der administrativen Tätigkeiten in HR mit existierender Technologie automatisierbar sind. Die Adoption liegt bei 3 %. Die Lücke entsteht nicht aus Skepsis. Sie entsteht aus dem Mangel an einer Methode, die Workflow-Ebene auf Entscheidungspunkt-Ebene herunterbricht.

Ein typischer HR-Prozess hat zwölf Entscheidungspunkte, nicht einen

Vor der Klassifikation steht die Kartierung. Sie scheitert an einer Eigenheit erfahrener Mitarbeiter: Sie treffen viele Entscheidungen unbewusst. “Prüfen, ob die Krankmeldung ein Startdatum hat” wahrnehmen sie nicht als Entscheidung. Sie tun es einfach. Für einen Agenten ist jede solche Prüfung eine explizite Entscheidung, die spezifiziert werden muss.

Die Methode, die diese impliziten Entscheidungen sichtbar macht, ist die “Was könnte schiefgehen”-Technik: Für jeden Schritt im Workflow fragen, was hier fehlschlagen oder eine andere Aktion erfordern könnte. Jede Antwort offenbart einen Entscheidungspunkt.

Bevor man kartiert, muss man die Workflow-Grenze ziehen. Ein Workflow hat einen Auslöser, eine Sequenz von Verarbeitungsschritten und einen oder mehrere Endpunkte. Häufiger Fehler: Die Grenze zu weit fassen. “Onboarding” ist nicht ein Workflow - es ist eine Sammlung von fünf bis acht Teil-Workflows (Vertragserstellung, IT-Provisioning, Compliance-Dokumentation, Arbeitsplatzeinrichtung, Schulungsanmeldung, Buddy-Zuordnung, Probezeit-Tracking). Jeden Teil-Workflow separat auditieren.

Am Beispiel der Krankmeldungsverarbeitung - Auslöser: Mitarbeiter reicht eine Krankmeldung ein. Endpunkte: SAP-Datensatz aktualisiert, Vorgesetzter informiert, Payroll angepasst, Wiedereingliederungsaktion geplant falls Schwelle überschritten. Was die meisten Organisationen als einen Schritt beschreiben, ist eine Kette aus zwölf:

Zwölf Entscheidungspunkte in einem Prozess, den die meisten Organisationen als “Mitarbeiter reicht Krankmeldung ein, wir verarbeiten sie” beschreiben. Die Lücke zwischen wahrgenommener Einfachheit und tatsächlicher Komplexität ist typisch - und sie ist der Grund, warum “Wir automatisieren Krankmeldungen” als Projektziel keine Architektur produziert.

Drei Entscheidungs-Typen, drei Tests, eine Klassifikation

Jeder Entscheidungspunkt fällt in genau einen von drei Typen. Die Klassifikation ist binär. Mehrdeutigkeit deutet auf einen Audit-Fehler hin, nicht auf einen Spezialfall.

Typ H - der Mensch entscheidet. Empathie, individuelles Ermessen, rechtliches Risiko bei Automatisierung, Mitbestimmungsmandat des Betriebsrats oder ethische Sensibilität. Testfrage: “Würden zwei verschiedene erfahrene Fachleute denselben Fall zuverlässig identisch entscheiden?” Falls nein - Typ H. Der Mensch bleibt dort, wo Recht es verlangt. Nicht weil er es besser kann.

Typ R - regelbasiert, deterministisch. Die Regel existiert schriftlich (Gesetz, Tarifvertrag, Betriebsvereinbarung, dokumentierte Verfahrensanweisung). Die Eingabedaten sind strukturiert. Das Ergebnis ist deterministisch. Ausnahmen sind selbst regelbasiert - oder sie sind separate Typ-H-Entscheidungspunkte. Testfrage: “Könnte ich diese Entscheidung als Tabellenkalkulations-Formel schreiben?” Falls ja - Typ R.

Typ A - KI-geeignet, probabilistisch mit Grenzen. Die Aufgabe ist Klassifikation, Extraktion oder Abgleich - nicht Erstellung, Bewertung oder Beurteilung. Die Ergebnismenge ist bekannt und endlich. Das Ergebnis ist überprüfbar. Ein Konfidenzschwellenwert ist setzbar; unsichere Fälle eskalieren. Testfrage: “Interpretiere ich Information gegen bekannte Kategorien, oder beurteile ich eine einzigartige Situation?” Falls Kategorien - Typ A.

Die Krankmeldungs-Tabelle ergibt nach diesen Tests:

Acht Typ R, drei Typ A, kein Typ H. Die Folge-Aktionen, die menschliches Ermessen erfordern (BEM-Gespräch, Wiedereingliederungsplanung) sind separate Workflows mit eigener Klassifikation - sie liegen ausserhalb der Krankmeldungsverarbeitung.

Der Score sagt nicht “ob”, sondern “wo der Mensch bleibt”

Aus der Klassifikation ergibt sich ein einfacher Quotient: (Typ R + Typ A) ÷ Gesamtzahl × 100. Die Krankmeldung kommt auf 91,7 %. Das ist hoch. Es heisst nicht, dass 91,7 % “weniger Mensch” gebraucht wird. Es heisst, dass 91,7 % der Einzelentscheidungen architektonisch übernommen werden können - während die menschliche Aufsicht sich auf das konzentriert, wofür Recht und Empathie sie verlangen.

Die Score-Schwellen sind weniger Skala als Deployment-Logik:

Typische Scores nach HR-Domäne: Payroll & Compensation 85 - 95 %, Zeiterfassung 80 - 90 %, Belegverarbeitung 75 - 85 %, Onboarding-Administration 60 - 75 %, Benefits-Einschreibung 65 - 80 %, Recruiting-Screening 40 - 55 %, Performance Management 20 - 35 %, Employee Relations 15 - 30 %. Recruiting und Performance fallen ab nicht weil sie technisch unmöglich sind, sondern weil sie Hochrisiko-Systeme nach Annex III des EU AI Act sind und die menschliche Aufsicht mehr Gewicht bekommt.

Ein Audit-Ergebnis, vier Stakeholder

Pro Entscheidungspunkt entsteht ein strukturierter Datensatz: ID und Beschreibung, Klassifikation mit Begründung, Regelquelle (für R) mit Version und Geltungszeitraum, Konfidenzschwellenwert (für A), Eskalationspfad mit Frist, Audit-Trail-Spezifikation und Anfechtungspfad. Dieser Datensatz hat vier Empfänger:

Das Engineering-Team liest die Klassifikation als Architektur-Spec. Wo R steht, kommt die Rules Engine zum Einsatz; wo A, ein Modellaufruf mit Confidence-Capture; wo H, eine Aufgabe in der Human-Queue. Der Datensatz spezifiziert direkt den Decision Layer - die Schicht zwischen Agent und Zielsystem, die regelbasierte und KI-basierte Entscheidungen orchestriert, das Audit-Trail erzeugt und Eskalationen routet.

Der Betriebsrat liest dieselben Daten als Mitbestimmungsvorlage. Er sieht, welche Entscheidungen automatisiert werden, mit welcher Begründung, mit welcher Eskalation. Eine Rahmen-Betriebsvereinbarung kann direkt aus dem Audit abgeleitet werden, oft schneller als domänenspezifische Einzelvereinbarungen.

Der Wirtschaftsprüfer liest die Regelversionen und Audit-Trail-Spezifikationen als Revisionssicherheit. Welche Regel wurde wann angewandt, welche Daten lagen zugrunde, wer hat entschieden. Die Antwort steht im Audit-Datensatz, nicht in einem separaten Compliance-Dokument.

Die Datenschutzbehörde liest dieselben Daten als EU-AI-Act- und DSGVO-Dokumentation. Art. 11 (Technische Dokumentation), Art. 12 (Aufzeichnungspflichten), Art. 86 (Recht auf Erläuterung) und Art. 22 DSGVO verlangen genau diese Informationen.

Vier Funktionen aus einem Dokument. Das Audit erzeugt sie nicht als Nebenprodukt - es ist primär darauf konstruiert.

Anfechtbarkeit ist Architektur, nicht Compliance-Anhang

Eine automatisierte Entscheidung über einen Menschen ist unter dem EU AI Act und der DSGVO nur dann zulässig, wenn die betroffene Person sie anfechten kann. Anfechtbarkeit ist keine Pflicht, die nachträglich angeflanscht wird - sie ist eine Architektur-Anforderung, die ab dem ersten Audit mitgeplant wird.

Pro Entscheidungspunkt liefert das Audit vier Antworten, die zusammen Anfechtbarkeit ermöglichen. Welche Regel oder welches Modell hat in welcher Version entschieden? Ohne Versionierung ist die spätere Reproduktion unmöglich. Welche Daten lagen der Entscheidung zugrunde - die exakten, zum Zeitpunkt der Entscheidung gültigen, nicht die heutigen? Wer hat entschieden - Mensch, Regelwerk oder KI - und mit welcher Konfidenz? Wie kann die Person Einspruch einlegen - mit konkreter Adresse, konkreter Frist, konkreter nächster Instanz?

Eine Konsequenz der Architektur: Der Agent selbst trifft keine “Entscheidungen” im rechtlichen Sinne. Er führt Operationen aus, die der Decision Layer freigegeben hat. Das ist nicht semantische Spitzfindigkeit. Es ist die Grundlage dafür, dass Entscheidungen prüfbar bleiben, wenn das KI-Modell ausgetauscht wird, der Anbieter wechselt oder ein Fehler im Modell entdeckt wird.

Die Hochrisiko-Klassifikation des EU AI Act trifft viele HR-Workflows direkt: Recruiting-Screening, Performance Management, Beförderungs- und Versetzungsentscheidungen, Schicht-Routing wenn es Personalvorteile beeinflusst (Annex III Nr. 4 lit. a und b). Art. 26 Abs. 7 verpflichtet zusätzlich, Arbeitnehmervertretungen und betroffene Arbeitnehmer vor der Inbetriebnahme zu informieren - nicht danach. Das Audit muss daher pro Workflow zusätzlich beantworten: Fällt dieser Workflow unter Annex III? Ja → die Pflichten aus Art. 11, Art. 14, Art. 15 und Art. 26 treten hinzu, und die Informationspflicht ist Voraussetzung für Inbetriebnahme.

Für Organisationen ausserhalb der EU: Die Anforderungen, die der EU AI Act explizit auflistet, sind in fast jedem Rechtssystem als Auslegung allgemeiner Sorgfaltspflichten bereits durchsetzbar - nur ohne klare Pflichtenliste. Wer den Decision Layer EU-AI-Act-konform baut, erfüllt damit auch das, was kalifornische, brasilianische und britische Datenschutzbehörden im Prüfungsfall verlangen.

Vier Klassifikationsfehler verzerren jedes Audit

Eine Regel mit ermessensbedürftigen Ausnahmen wird als Typ R klassifiziert. “Überstunden zu 150 %” klingt regelbasiert. Aber: Feiertag mit 200 %? Schicht über Mitternacht in Feiertag? Individualvertrag, der den Tarifvertrag überlagert? Wenn Ausnahmen Ermessen verlangen, ist der Ausnahmepfad Typ H - auch wenn der Standardfall Typ R ist. Saubere Lösung: Standardfall als R, separater Entscheidungspunkt für die Ausnahmebehandlung als H oder A.

Ein KI-Ergebnis ohne Verifizierbarkeit wird als Typ A klassifiziert. “Die KI bewertet, ob der Kandidat kulturell passt.” Das ist nicht Typ A - es gibt keine überprüfbare richtige Antwort. Kulturelle Passung ist subjektiv. Typ A erfordert, dass das Ergebnis prüfbar ist: “Die KI hat dieses Dokument als Krankmeldung klassifiziert” können zwei Menschen am gleichen Dokument validieren. Subjektive Bewertungen sind Typ H - immer.

Die Auslöser-Entscheidung wird mit der Folge-Aktion verwechselt. “Mustererkennung löst BEM-Prozess aus” - die Erkennung ist Typ R (Schwellenwert), aber der BEM-Prozess enthält Typ-H-Entscheidungen (Wiedereingliederungsplanung). Das Audit muss den Auslöser vom ausgelösten Workflow trennen.

Implizite Entscheidungen werden ignoriert. “Wir prüfen die Krankmeldung” klingt nach einem Schritt. Es enthält mindestens drei Entscheidungen: gültiges Dokument, vollständig, passt zum Mitarbeiter. Das Audit muss zerlegen, bis jeder Punkt genau eine Frage und eine Klassifikation hat.

Was diese Methodik nicht löst

Das Audit liefert Agent Readiness auf Entscheidungspunkt-Ebene und die Decision-Layer-Spezifikation. Es liefert nicht: die Sequenzierung über Workflows hinweg (das hängt von Transaktionsvolumen, Governance-Komplexität und organisatorischer Bereitschaft ab; siehe die H1-H4-Logik im HR-Agent-Katalog), die Technologieauswahl, den organisatorischen Wandel oder die Verhandlungsstrategie mit dem Betriebsrat. Auch die konkrete Implementierung des Decision Layers - Rules Engine, Confidence Capture, Anfechtungs-Endpunkt - ist ein eigenes Thema.

Das Audit liefert die Faktengrundlage. Strategie und Implementierung bauen darauf auf. Wer mit Strategie anfängt und sich die Faktengrundlage später ansieht, baut die Pyramide auf der Spitze.

Weiterführende Artikel

• Der EU AI Act gilt weltweit - warum die Anfechtbarkeitspflicht nicht erst mit dem August-2026-Termin entsteht
• Drei Arten von Entscheidungen: Wann der Mensch, wann die KI - die konzeptionelle Grundlage der H/R/A-Klassifikation
• Decision Layer als Architektur-Pattern - wie die Klassifikation in eine ausführbare Schicht überführt wird
• EU AI Act und HR: Hochrisiko-Klassifikation - welche HR-Workflows unter Annex III fallen

Bert Gogolin

Geschäftsführer, Gosign

AI Governance Briefing

Enterprise AI, Regulierung und Infrastruktur - einmal im Monat, direkt von mir.

E-Mail-AdresseAnmelden

Kein Spam. Jederzeit abbestellbar. Datenschutzerklärung