Menschliche Aufsicht: Praxisleitfaden fuer SaaS-Teams

Menschliche Aufsicht ist nur wirksam, wenn eine Person das Ergebnis eines KI-gestuetzten Ablaufs beeinflussen kann. Ein Freigabe-Button allein reicht nicht. Die pruefende Person braucht Kompetenz, Kontext, Zeit, Befugnisse und technische Mittel, um Grenzen zu verstehen, ungewoehnliche Ergebnisse zu erkennen, Outputs zu verwerfen und den Prozess bei Bedarf zu stoppen oder zu eskalieren.

Bei Hochrisiko-KI nach dem EU AI Act ist dies eine formelle Design- und Betriebspflicht. Artikel 14 verlangt verhaeltnismaessige Massnahmen, mit denen natuerliche Personen das System ueberwachen und interpretieren, Automation Bias erkennen, Outputs ueberstimmen oder rueckgaengig machen und das System sicher anhalten koennen. Artikel 26 verlangt von Betreibern zudem, die Aufsicht Personen mit Kompetenz, Schulung, Befugnissen und Unterstuetzung zuzuweisen. Ausserhalb der Hochrisiko-Kategorie ist dasselbe Muster oft sinnvoll, darf aber nicht automatisch als gesetzliche Artikel-14-Pflicht bezeichnet werden.

Wann die Pflicht gilt

Klassifizieren Sie zuerst den Use Case und bestimmen Sie die Rolle des Unternehmens. Ein SaaS-Unternehmen kann Anbieter sein, wenn es ein System unter eigenem Namen entwickelt oder vermarktet, oder Betreiber, wenn es ein System unter eigener Verantwortung nutzt. Risiko, Autonomie und Einsatzkontext bestimmen die angemessene Aufsicht.

Nach dem Stand vom 22. Juli 2026 beschreibt die Kommission eine politische Einigung ueber einen geaenderten Zeitplan: Bestimmte Hochrisiko-Bereiche des Anhangs III sollen ab 2. Dezember 2027 und in regulierte Produkte eingebettete Systeme ab 2. August 2028 erfasst werden. Die zugehoerigen Leitlinien sind noch Entwurf und nicht rechtsverbindlich. Teams sollten daher den finalen Gesetzestext und Sektorregeln verfolgen.

Andere Gesetze, Vertraege, Sicherheitsanforderungen oder interne Risikogrenzen koennen auch ausserhalb von Artikel 14 eine menschliche Pruefung begruenden. Dokumentieren Sie den Grund praezise.

Sieben Bausteine einer echten Kontrolle

1. Entscheidung: Definieren Sie den konkreten Output und seine Folge.
2. Pruefer: Benennen Sie eine Rolle mit passendem Fachwissen.
3. Information: Zeigen Sie Inputs, Outputs, Unsicherheit, Regeln, Grenzen und Verlauf.
4. Eingriff: Ermoeglichen Sie Verwerfen, Korrigieren, Rueckgaengigmachen, Aufschieben und Eskalieren.
5. Trigger: Definieren Sie Pflichtpruefungen bei fehlenden Daten, geringer Sicherheit, Konflikten, sensiblen Kontexten oder Anomalien.
6. Nachweis: Protokollieren Sie Entscheidung, Grund, Zeit, Eskalation und Ergebnis datensparsam.
7. Test: Pruefen Sie mit realistischen Ausnahmen, ob Menschen rechtzeitig handeln koennen.

Praktischer Workflow

Beginnen Sie im KI-Inventar und erfassen Sie Entscheidungen statt nur Tools. Halten Sie Zweck, Betroffene, Daten, Output, Folgehandlung, Kundenkonfiguration, Eigentuemer, Rolle und Klassifizierung fest. Priorisieren Sie Entscheidungen zu Zugang, Auswahl, Beschaeftigung, Bildung, Sicherheit, Kredit, Identitaet oder wesentlichen Kundenpflichten.

Waehlen Sie dann ein Aufsichtsmuster: Freigabe vor der Entscheidung, nachtraegliche Stichprobe, Ausnahmepruefung, Vier-Augen-Prinzip oder laufendes Monitoring. Das Muster muss zu moeglichem Schaden und Umkehrbarkeit passen. Ein Textvorschlag kann Stichproben erlauben; eine Kontosperre oder Bewerberablehnung kann eine vorherige Pruefung erfordern.

Geben Sie Pruefern kurze, konkrete Anweisungen zu Zweck, unzulaessiger Nutzung, Leistung, Grenzen, Interpretation, Datenqualitaet, Automation Bias, Eskalation und Stop-Verfahren. Befugnisse muessen praktisch sein: Ein Pruefer sollte einen offensichtlich fehlerhaften Ablauf pausieren koennen, ohne unrealistische Freigabehuerden zu ueberwinden.

Die Produktoberflaeche sollte Fakten von KI-Inferenzen trennen, die Rolle der KI sichtbar machen und Widerspruch erleichtern. Engineering definiert das Verhalten bei fehlenden Daten, Ausfall, Drift, unplausiblen Outputs oder Rueckstau. Sichere Fallbacks koennen manuelle Bearbeitung, Verzoegerung, eingeschraenkte Funktion oder kontrolliertes Abschalten sein.

Testen Sie False Positives, False Negatives, mehrdeutige Ergebnisse, fehlende Inputs, moegliche Verzerrung, unerwartetes Verhalten und Nutzung ausserhalb des Zwecks. Beobachten Sie Ueberstimmungsraten, Eskalationsgruende, Alter offener Faelle, Beschwerden und Ergebnisse. Eine Ueberstimmungsrate von null kann auch Automation Bias oder eine unbrauchbare Kontrolle anzeigen.

Nachweise und typische Fehler

Bewahren Sie Klassifizierung, Rollenanalyse, Zweck, Aufsichtsdesign, Anbieteranweisungen, Verfahren, Verantwortliche, Kompetenzkriterien, Schulungen, Zugriffskontrollen, Tests, Entscheidungsprotokolle, Eskalationen, Vorfaelle und Korrekturmassnahmen auf. Ein Screenshot eines Buttons reicht nicht; der Nachweis sollte zeigen, dass ein Eingriff funktioniert.

Typische Fehler sind symbolische Pruefung ohne Kontext oder Befugnis, eine Pruefung nach einer unumkehrbaren Handlung, versteckte Unsicherheit und blindes Vertrauen in Anbieterangaben. Schulung ersetzt keine fehlende Override-Funktion, Protokollierung oder Eskalation. Aenderungen an Modell, Daten, Zweck, Schwelle, Nutzergruppe oder Workflow muessen eine Neubewertung ausloesen.

Beispiele

Bei einem Support-Entwurf sieht ein Agent Ticket und Kontokontext, kann frei bearbeiten und genehmigt vor dem Versand. Rechtliche, Sicherheits- oder Erstattungsthemen gehen an Spezialisten. Bei Bewerber-Rankings braucht die pruefende Person relevante Bewerbungsdaten, Faktoren, Grenzen und die Befugnis, das Ranking zu ignorieren. Bei Security-Erkennung muessen Analysten Signale pruefen und Empfehlungen rueckgaengig machen koennen; ein Anstieg falscher Alarme braucht einen getesteten Stop-Pfad.

FAQ

Was ist der praktische Zweck menschlicher Aufsicht?

Eine kompetente Person soll Schaden verhindern oder reduzieren, indem sie einen KI-gestuetzten Prozess versteht, ueberwacht, hinterfragt, ueberstimmt oder stoppt.

Reicht ein Human-in-the-loop-Kontrollkaestchen?

Nein. Es braucht Informationen, Kompetenz, Zeit, Befugnisse, Eingriffsmoeglichkeiten, Eskalation und Tests mit realistischen Fehlern.

Was sollte zuerst dokumentiert werden?

Die beaufsichtigte Entscheidung, moeglicher Schaden, Klassifizierung, Eigentuemer, Prueferrolle, benoetigte Informationen, Eingriffe, Eskalationstrigger und aufzubewahrende Nachweise.

Quellen

• Verordnung (EU) 2024/1689, insbesondere Artikel 14 und 26.
• Erlaeuterungen des AI Act Service Desk der Europaeischen Kommission.
• Entwurf der Kommissionsleitlinien fuer Hochrisiko-KI-Systeme.