01 · NEDİR / DEFINITION

Was ist Use Case & Purpose?

Der Use Case beschreibt den konkreten Geschäftsprozess. Der Purpose definiert Ziel, Nutzer, Betroffene, zulässigen Input und Output sowie ausdrücklich ausgeschlossene Nutzungen.

Kernsatz: Ein AI-System muss nicht nur technisch, sondern als begrenzte Aufgabe in einem verantworteten Prozess beschrieben werden.
02 · WARUM RELEVANT?

Warum ist ein klarer Zweck Pflicht?

Risikobewertung

Auswirkungen und Schutzbedarf hängen vom konkreten Einsatz ab.

Controls

Human Oversight, Logging und Freigaben müssen zum Prozess passen.

Regelwerke

EU AI Act und DSGVO knüpfen Anforderungen an Kontext und Daten.

Change Control

Zweckänderungen werden erkennbar und lösen eine Neubewertung aus.

03 · KUNDENSITUATION

Typisches Praxisbild

Ein interner Wissensassistent wird später ungeprüft für Kundenangebote verwendet. Das Modell bleibt gleich, aber Nutzung, Betroffene, Fehlfolgen und erforderliche Controls ändern sich. R-001 verhindert diese schleichende Zweckausweitung.

Warnsignale: „Das Tool kann alles“, „Wir testen erst einmal“ oder „Später entscheiden wir über die Nutzung“ reichen nicht für eine produktive Freigabe.
04 · DISCOVERY-FRAGEN

Was BAIS im Erstgespräch klärt

  1. Welches Geschäftsproblem soll gelöst werden?
  2. In welchem Prozessschritt arbeitet das System?
  3. Wer nutzt es und wer ist betroffen?
  4. Welche Inputs und Outputs sind erlaubt?
  5. Informiert, empfiehlt oder entscheidet es?
  6. Welche Nutzung ist ausdrücklich verboten?
  7. Wer prüft und genehmigt Ergebnisse?
  8. Welche Folgen hätte ein falsches Ergebnis?
  9. Woran wird Nutzen und Qualität gemessen?
  10. Welche Änderung löst eine Neubewertung aus?
05 · GUTE / SCHLECHTE BEISPIELE

Präzision statt Marketingformel

NICHT AUSREICHEND

„Wir nutzen KI, um den Kundenservice zu verbessern.“

  • Kein Prozess
  • Keine Zielgruppe
  • Keine Grenzen
  • Keine Kontrolle
BELASTBAR

„Der Assistent erstellt für geschulte Service-Mitarbeitende Antwortentwürfe aus freigegebenen Quellen. Mitarbeitende prüfen und versenden. Vertrags-, Kulanz- und Sicherheitsentscheidungen sind ausgeschlossen.“

06 · BEWERTUNG

Wie R-001 eingestuft wird

0–2 · NiedrigInterne Unterstützung, klare Grenzen und Owner.
3–5 · MittelExterne Wirkung oder Empfehlung mit menschlicher Prüfung.
6–8 · HochEntscheidungsvorbereitung über Personen oder schwere Fehlfolgen.
9–10 · KritischAutonome erhebliche Entscheidung oder unklarer Zweck.

Der Score ist eine technische und organisatorische Vorprüfung, keine Rechtsklassifizierung.

07–08 · CONTROLS & EVIDENCE

Was eingerichtet und nachgewiesen wird

ControlEvidence / Nachweis
Use-Case-Statement mit In-/Out-of-ScopeFreigegebener Steckbrief
Zulässige und verbotene NutzungPolicy und technische Regeln
Human-Review-PunktProzessdiagramm und Rollenbeschreibung
Abnahmekriterien und KPITestplan und Abnahmeprotokoll
Change-TriggerChange Log, Ticket und Review-Termin
Versionierte FreigabeOwner, Datum, Version und Sign-off
09 · OWNER / RACI

Wer trägt Verantwortung?

R · ResponsibleProduct Owner / Fachbereich erstellt und pflegt den Use Case.
A · AccountableBusiness Owner genehmigt Zweck, Grenzen und Risiko.
C · ConsultedAI/ML, Datenschutz, IT Security, Compliance und Risk.
I · InformedBetrieb, Support, Fachbereiche und gegebenenfalls Betriebsrat.
10–11 · EU AI ACT / DSGVO / ISO

Welche Regelwerke berührt R-001?

  • EU AI Act: Der „intended purpose“ prägt Einordnung, Pflichten und Dokumentation.
  • DSGVO: Zweckbindung, Rechtsgrundlage, Datenminimierung und Transparenz.
  • ISO/IEC 42001: Rollen, Ziele, Impact Assessment und AI-Lebenszyklus.
  • ISO/IEC 23894: Risikokontext, Analyse, Behandlung und Monitoring.
Grenze: BAIS dokumentiert technische und organisatorische Governance. Verbindliche Rechtsberatung wird nicht ersetzt.
12 · TECHNISCHE UMSETZUNG

Wie der Zweck im System verankert wird

  • Use-Case-ID und Version in Systemakte und Konfiguration führen.
  • Datenquellen und Funktionen per Allowlist begrenzen.
  • System Prompt und Guardrails an erlaubte Nutzung koppeln.
  • Rollen und Berechtigungen nach Nutzergruppe trennen.
  • Input, Output, Modell-/Prompt-Version und Review protokollieren.
  • Out-of-Scope-Anfragen ablehnen oder eskalieren.
  • Grenz- und Missbrauchsfälle testen.
  • Neue Daten, Nutzer oder Automatisierung als Reassessment-Trigger behandeln.
13 · HÄUFIGE FEHLER

Was oft schiefläuft

Technologie statt Prozess beschriebenTestbetrieb ohne GrenzenVerbotene Nutzung fehltPurpose Creep nach Go-liveKein Business OwnerKeine Qualitätskriterien
14–17 · EINWÄNDE & KUNDENGESPRÄCH

Sicher erklären, ohne zu raten

30 SEKUNDEN

„R-001 klärt den verbindlichen Einsatzzweck: welches Problem gelöst wird, wer das System nutzt, welche Ergebnisse zulässig sind und was ausgeschlossen bleibt. Daraus leiten wir Risiko, Controls, Verantwortliche und Nachweise ab.“

2 MINUTEN

„Das Risiko hängt nicht nur vom Modell, sondern vom Einsatz ab. Interne Entwürfe sind anders zu bewerten als Entscheidungen über Kunden oder Bewerber. Deshalb dokumentieren wir Prozess, Nutzer, Betroffene, Daten, Output, Human Oversight und Ausschlüsse. Ändern sich Zweck, Daten, Nutzergruppe oder Automatisierung, wird neu bewertet.“

„Wir wollen uns noch nicht festlegen.“

Dann bleibt das System im begrenzten Experimentierstatus. Produktiv braucht es einen freigegebenen Use Case.

„Der Anbieter hat das Modell geprüft.“

Das ersetzt nicht die Prüfung Ihres Prozesses, Ihrer Daten, Nutzer und Fehlfolgen.

„Das bremst Innovation.“

Ein klarer Zweck beschleunigt Tests und Freigaben, weil Grenzen und Erfolgskriterien feststehen.

18 · ABSCHLUSS-CHECKLISTE

R-001 ist vollständig, wenn …

  • Geschäftsproblem und Prozessschritt eindeutig sind.
  • Nutzer und betroffene Personen feststehen.
  • Input, Output und Automatisierungsgrad dokumentiert sind.
  • zulässige und verbotene Nutzungen freigegeben sind.
  • Fehlfolgen und Human Oversight beschrieben sind.
  • Owner, Mitwirkende und Eskalation feststehen.
  • Controls, Tests, Evidence und KPI definiert sind.
  • Version, Freigabe, Review-Zyklus und Change-Trigger vorliegen.