01 · NEDİR / DEFINITION

Was bedeutet Consequence & Impact?

Consequence ist die konkrete Folge eines Fehlers oder Missbrauchs. Impact beschreibt deren Schwere und Reichweite für Menschen, Unternehmen, Gesellschaft oder Umwelt. Bewertet wird nicht nur der Normalbetrieb, sondern auch realistisches Versagen.

Kernsatz: Nicht die beeindruckende Funktion bestimmt das Risiko, sondern der plausible Schaden, wenn Output falsch, verzerrt, verspätet oder missbraucht wird.
02 · WARUM RELEVANT?

Warum Fehlfolgen vor dem Go-live prüfen?

Priorisierung

Schwere Folgen erhalten stärkere Controls und frühere Behandlung.

Freigabe

Restrisiko und Go-live-Entscheidung werden nachvollziehbar.

Resilienz

Fallback, Stop, Recovery und Incident Response werden vorab geplant.

Verantwortung

Betroffene Schutzgüter und Risk Owner werden sichtbar.

03 · KUNDENSITUATION

Typisches Praxisbild

Ein AI-Assistent schlägt einem Serviceteam Antworten vor. Ein Halluzinationsfehler ist bei einer Öffnungszeit leicht korrigierbar; dieselbe Fehlerart kann bei Sicherheitsanweisungen Menschen gefährden. R-002 bewertet deshalb Kontext, Wirkung und Reversibilität, nicht nur die technische Fehlerquote.

Warnsignal: „Ein Mensch schaut drauf“ genügt nicht, wenn Zeitdruck, fehlende Fachkenntnis oder Automation Bias eine wirksame Prüfung verhindern.
04 · DISCOVERY-FRAGEN

Was BAIS systematisch abfragt

  1. Welche falschen, verzerrten oder fehlenden Outputs sind plausibel?
  2. Welche Personen, Prozesse, Vermögenswerte oder Rechte wären betroffen?
  3. Wie schwer wäre die direkte und indirekte Folge?
  4. Wie viele Fälle könnten gleichzeitig betroffen sein?
  5. Ist der Schaden erkennbar und vollständig reversibel?
  6. Wie schnell müsste reagiert werden?
  7. Gibt es besonders schutzbedürftige Personen?
  8. Kann derselbe Fehler systematisch skaliert werden?
  9. Welche Abhängigkeiten oder Kaskadeneffekte bestehen?
  10. Welches Restrisiko akzeptiert welcher Owner?
05 · GUTE / SCHLECHTE SZENARIEN

Konkrete Fehlfolge statt „KI kann Fehler machen“

NICHT AUSREICHEND

„Das System könnte falsche Antworten liefern.“

  • Kein Auslöser
  • Keine Betroffenen
  • Keine Auswirkung
  • Keine Reaktion
BELASTBAR

„Eine veraltete Wissensquelle erzeugt eine falsche Vertragsauskunft. Kunden können finanzielle Nachteile erleiden. Vier-Augen-Freigabe, Quellenanzeige und täglicher Content-Check reduzieren das Risiko; Beschwerden lösen sofortige Sperrung aus.“

06 · BEWERTUNG

Impact über fünf Faktoren einordnen

SchwereVon geringem Mehraufwand bis Gefahr für Gesundheit, Sicherheit oder Grundrechte.
ReichweiteEinzelfall, Nutzergruppe oder systematisch viele Betroffene.
ReversibilitätVollständig korrigierbar oder dauerhaft bzw. kaum wiedergutzumachen.
GeschwindigkeitLangsam erkennbar oder sofortige Intervention erforderlich.
WahrscheinlichkeitUnter realistischen Betriebs- und Missbrauchsbedingungen.

Severity-Stufen: 0–2 gering · 3–5 moderat · 6–8 hoch · 9–10 kritisch. Kritische Einzelfolgen dürfen nicht durch Durchschnittswerte verdeckt werden.

07–08 · CONTROLS & EVIDENCE

Was eingerichtet und nachgewiesen wird

ControlEvidence / Nachweis
Impact- und Misuse-SzenarienSzenariokatalog mit Schutzgut, Ursache und Folge
Severity-Matrix mit SchwellenFreigegebene Bewertungsmethodik
Human Oversight & StopRollen, Eskalationsweg und Stop-Test
Fallback und RecoveryRunbook, Wiederanlauf- und Rücknahmetest
Qualitäts- und SicherheitsgrenzenTestbericht, KPI, Alert und Blocking Rule
Restrisiko-FreigabeRisk Acceptance mit Owner, Datum und Auflagen
09 · OWNER / RACI

Wer trägt welche Verantwortung?

R · ResponsibleRisk Owner führt Szenarien, Bewertung und Maßnahmen zusammen.
A · AccountableBusiness Owner akzeptiert Restrisiko oder stoppt den Einsatz.
C · ConsultedFachbereich, AI/ML, IT Security, Datenschutz, Compliance und Betroffenenvertretung.
I · InformedBetrieb, Support, Incident Management und betroffene Prozess-Owner.
10–11 · EU AI ACT / DSGVO / ISO

Welche Regelwerke berührt R-002?

  • EU AI Act: Risikomanagement, Genauigkeit, Robustheit, Human Oversight und mögliche Auswirkungen des konkreten Einsatzes.
  • DSGVO: Risiken für Rechte und Freiheiten; bei hohem Risiko kann eine Datenschutz-Folgenabschätzung erforderlich sein.
  • ISO/IEC 42001: AI Impact Assessment, Risikobehandlung, Ziele und dokumentierte Freigaben.
  • ISO/IEC 23894: Identifikation, Analyse, Evaluation, Behandlung und Monitoring von AI-Risiken.
Grenze: Ob rechtlich ein Hochrisiko-System oder eine Pflicht zur DSFA vorliegt, wird anhand des konkreten Systems fachjuristisch bzw. datenschutzrechtlich geprüft.
12 · TECHNISCHE UMSETZUNG

Wie Impact technisch kontrolliert wird

  • Fehlerszenarien in testbare Acceptance- und Red-Team-Cases übersetzen.
  • High-Impact-Aktionen durch Berechtigungen und Vier-Augen-Prinzip begrenzen.
  • Konfidenz, Quellenlage und Policy-Verstöße als Signale erfassen.
  • Hard Stops, Rate Limits und erlaubte Aktionsräume definieren.
  • Fallback auf sicheren manuellen Prozess bereitstellen.
  • Output, Review, Override, Incident und Korrektur revisionsfähig protokollieren.
  • KPI und Alerts an Schadensschwellen statt nur Verfügbarkeit koppeln.
  • Rollback, Betroffeneninformation und Wiederherstellung regelmäßig testen.
13 · HÄUFIGE FEHLER

Was Impact Assessments schwach macht

Nur Normalbetrieb betrachtetWahrscheinlichkeit mit Schwere verwechseltIndirekte Folgen ignoriertDurchschnitt verdeckt ExtremfälleAutomation Bias nicht berücksichtigtRestrisiko ohne Owner akzeptiert
14–17 · EINWÄNDE & KUNDENGESPRÄCH

Sicher erklären, ohne Panik zu erzeugen

30 SEKUNDEN

„R-002 beschreibt nicht nur, ob ein AI-System Fehler machen kann, sondern welche konkreten Folgen daraus entstehen: für wen, wie schwer, wie weitreichend und wie reversibel. Danach wählen wir passende Controls und lassen das verbleibende Risiko verantwortlich freigeben.“

2 MINUTEN

„Dieselbe Modellabweichung kann je nach Prozess harmlos oder kritisch sein. Wir bilden deshalb plausible Fehl- und Missbrauchsszenarien, betroffene Schutzgüter, Schwere, Reichweite, Reversibilität und Reaktionszeit ab. Für hohe Auswirkungen brauchen wir stärkere Prävention, wirksame menschliche Kontrolle, Stop/Fallback, Monitoring und belastbare Nachweise.“

„Das passiert doch sehr selten.“

Eine geringe Wahrscheinlichkeit macht eine existenzielle oder irreversible Folge nicht automatisch akzeptabel. Schwere und Wahrscheinlichkeit werden getrennt betrachtet.

„Wir haben doch einen Disclaimer.“

Ein Hinweis kann Transparenz verbessern, ersetzt aber keine wirksame technische und organisatorische Risikobehandlung.

„Wir testen die Genauigkeit.“

Durchschnittliche Accuracy reicht nicht. Kritische Randfälle, Missbrauch, Kaskaden und Recovery müssen ebenfalls getestet werden.

18 · ABSCHLUSS-CHECKLISTE

R-002 ist vollständig, wenn …

  • plausible Fehl-, Missbrauchs- und Ausfallszenarien beschrieben sind.
  • Betroffene und Schutzgüter je Szenario feststehen.
  • Schwere, Reichweite, Reversibilität, Geschwindigkeit und Wahrscheinlichkeit bewertet sind.
  • kritische Extremfälle separat sichtbar bleiben.
  • präventive, detektive und korrektive Controls definiert sind.
  • Stop, Fallback, Recovery und Incident Response getestet sind.
  • Evidence und offene Restrisiken dokumentiert sind.
  • Risk Acceptance, Owner, Auflagen und Review-Termin vorliegen.