Alle vier Fälle sind erfundene Übungssituationen. Sie beschreiben keine APKV-Projekte, Datenbestände oder Abläufe. Jede Zahl und Schwelle muss in einem realen Projekt mit Betroffenen, Fachbereich, Datenschutz, Security, Legal/Compliance und Betrieb vorab vereinbart werden.
30-Sekunden-Triage vor jedem Modell
| Frage | Wenn unklar | Konsequenz |
|---|---|---|
| Welche Handlung folgt dem Output? | Output klingt nur nach „Insight“ | Kein Target definieren; Workflow zuerst klären. |
| Kann ein Fehler Zugang, Preis, Leistung oder Wartezeit verschlechtern? | Folgen sind indirekt | Betroffenenpfad und Proxy-Wirkung kartieren. |
| Ist Gesundheitsbezug wirklich nötig? | Feature ist nur leicht verfügbar | Weglassen; zweckärmere Baseline testen. |
| Gibt es sicheren Fallback und Widerspruch? | Manuelle Kapazität fehlt | Nicht ausrollen oder Scope/Kapazität ändern. |
Fall A · Dokumentextraktion, advisory-only
Ziel / Nicht-Ziel: Mitarbeitende finden Felder schneller; keine Leistungs- oder Anspruchsentscheidung. Nutzer/Betroffene: Sachbearbeitung und einreichende Personen. Einheit/Label/Horizont: Dokumentversion beim Eingang; Goldfelder aus Doppelreview, bevor spätere Bearbeitungsdaten entstehen. Leakage: keine Abschlusscodes oder nachträglichen Korrekturen als Input.
Baseline → Kandidat: Template-/Regex-Regeln, dann OCR plus Extraktor nur bei nachgewiesenem Mehrwert. Evaluation: Feldgenauigkeit und Coverage je Dokumenttyp, kritische False Extractions, Reviewzeit, Korrekturrate und barrierebedingte Subgruppen; Akzeptanzwerte vorab. Rollout/Betrieb: retrospektiv → Shadow → begrenzte Vorschläge; Confidence-Abstention, versionierte Dokumente, Drift-/Override-Monitoring, manuelle Rückkehr und Owner. Empfehlung: enger advisory Scope; stop bei unzuverlässigem Goldstandard oder nicht kontrollierbaren Fehlfolgen.
Fall B · Wissensassistenz mit Retrieval
Ziel / Nicht-Ziel: Mitarbeitende zu freigegebenen Quellen navigieren; keine individuelle Deckungs-, Leistungs- oder Rechtsauskunft automatisch versenden. Einheit: Frage plus Nutzerrolle, Quellenstand und erlaubter Dokumentraum. Baseline: Suche mit Filtern und Templates. Kandidat: RAG nur bei messbarem Zusatznutzen.
Evaluation: Retrieval Recall@k, Claim-Level-Groundedness, korrekte Fundstelle, Aktualität, Abstention bei unbeantwortbaren Fragen, ACL-Verstöße, Injection-Tests, Latenz und Kosten. Rollout: kuratiertes Eval-Set → Red Team → interner Entwurf mit verpflichtender Quellenprüfung. Betrieb: Dokumentversion, Berechtigungen vor Retrieval, Least Privilege, Outputvalidierung, Kill Switch und Suchfallback. Empfehlung: Wenn strukturierte Suche gleich gut ist, die einfachere Lösung behalten.
Fall C · Arbeitsvolumen prognostizieren
Ziel / Nicht-Ziel: aggregierte Kapazitätsplanung; keine Priorisierung einzelner versicherter Personen. Stakeholder: Operations, Mitarbeitende, indirekt wartende Personen. Einheit/Horizont: Eingangsvolumen pro Queue und Woche für die nächsten vier Wochen; revisionssicherer „as-of“-Datenstand. Leakage: keine nach Horizont bekannten Abschluss- oder Korrekturwerte.
Baseline: saisonales Naivmodell. Kandidat: robuste Zeitreihe erst bei besserer rolling-origin Evaluation. Metriken: MAE/WAPE je Queue, Intervall-Coverage, Unterbesetzungsstunden, Wartezeit und Planstabilität; kleine Queues nicht durch Aggregate verdecken. Rollout/Betrieb: Planer sehen Intervalle und können begründet übersteuern; Monitor für Bias, Coverage, Queue-Neuzuordnung und Datenverzug; Rückfall auf Baseline. Empfehlung: Aggregation und einfache Baseline begrenzen Datenschutz- und Wartungsrisiko.
Fall D · Individuelles Risiko oder Pricing
Zielbehauptung: Eine Person schlägt individuelle Gesundheitsdaten zur automatisierten Risikobewertung oder Preisfindung vor. Erste Antwort: Prototyp stoppen. Der Intended Purpose berührt eine konsequenzielle Entscheidung und einen im AI Act ausdrücklich genannten Bereich; Gesundheitsdaten unterliegen besonderem Schutz.[2][3]
Klärung vor Technik: rechtliche Grundlage und anwendbare Fassung, Verantwortlichkeiten, Betroffene, Profiling, notwendige Daten, mögliche Diskriminierung/Proxies, Widerspruch und Abhilfe, bestehende nicht-AI-Regeln, Beleg eines legitimen Nutzens und echte menschliche Eingriffsmacht. Empfehlung: Im Interview weder Features noch Modell optimieren. Ohne bestätigten zulässigen Zweck, Governance und risikoadäquaten Prüfpfad: No AI. Falls der reale Zweck enger und rein prozedural ist, neuen Scope separat bewerten und dokumentieren.
Executive-Answer-Formel
„Unter diesen Annahmen empfehle ich [Baseline/Advisory/No AI], weil [Nutzerwert] die Risiken [Fehlerfolge/Datenschutz/Fairness/Betrieb] nur dann überwiegt, wenn [vorab definierte Evidenz]. Ich würde mit [Shadow/Pilot] starten, [Metriken/Subgruppen] prüfen und bei [Stop-Kriterien] auf [Fallback] zurückgehen.“
Belege auf dieser Seite
- Private Krankenversicherung (PKV) – Prämien / Sozialtarife · geprüft 2026-09-02
- Regulation (EU) 2016/679 (General Data Protection Regulation) · geprüft 2026-09-02
- Regulation (EU) 2024/1689 (Artificial Intelligence Act), consolidated version · geprüft 2026-09-02
- Verantwortungsvoller Einsatz künstlicher Intelligenz (KI) · geprüft 2026-09-01
- AI RMF Core · geprüft 2026-09-02
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile · geprüft 2026-09-02
- OWASP Top 10 for LLM Applications 2025 · geprüft 2026-09-02