Phase 4 · Operational Step 7 von 9
Risiko-, Datenschutz- und Compliance-Check vorbereiten
Risiko-Matrix und Risiko-Register verbinden Ursache, Wirkung, Kontrolle, Owner und Pilotentscheidung.
Was du mitnimmst
GraphRAG-Risiken werden handhabbar, wenn sie als konkrete Betriebsentscheidungen formuliert sind.
Betriebsziel
Welche Betriebsfähigkeit du herstellst
Du machst Datenschutz-, Compliance-, Qualitäts- und Plattformrisiken vor dem Pilotentscheid sichtbar.
Input
Ausgangsartefakt aus Entwerfen
Aus Absichern kommen Erprobungsrahmen, Policy-Matrix, Eval-Set, Trace-Modell, Routenbudget und Review-Workflow. Das Risiko-Register bündelt diese Vorarbeiten und übersetzt sie in eine Entscheidungsvorlage.
Prinzip
Betriebsprinzip
Ein Risiko ist erst hilfreich, wenn Ursache, Wirkung, Kontrolle und Entscheidung sichtbar sind.
Das Prinzip ist eine Risiko-Matrix. Jedes Risiko bekommt eine Position nach Wahrscheinlichkeit und Auswirkung. Hohe Auswirkung verlangt klare Kontrollen, auch wenn das Risiko selten auftritt. Hohe Wahrscheinlichkeit verlangt Monitoring, Evaluation oder Scope-Anpassung, auch wenn die einzelne Wirkung begrenzt bleibt.
Die Matrix hilft, die passende Betriebsantwort zu wählen: akzeptieren, begrenzen, überwachen, vor der Erprobung klären oder als Stop-Kriterium behandeln. Entscheidend ist die Verbindung zur Kontrolle. Mit einer benannten Kontrolle wird aus der Sorge eine Betriebsfrage.
Operational Artefact
Betriebsartefakt
Das Betriebsartefakt ist ein Risiko-Register für den Erprobungsrahmen. Es ist größer als eine reine Liste, weil jede Zeile eine Entscheidung vorbereitet: Was kann passieren, warum passiert es, welche Wirkung hätte es, welche Kontrolle greift und wie wirkt sich das auf die Erprobung aus?
| Risiko-ID | Ursache | Wirkung | Owner | Kontrolle | Pilotentscheidung |
|---|---|---|---|---|---|
| wrong-project-path | Entity Resolution verwechselt CRM mit Projekt Alpha | falsche Betroffenheit und falsche Verantwortlichkeit | Compliance Lead | Review Gate, Trace-Pfad, Eval-Frage mit Erwartung | vor Erprobung klären |
| sensitive-derived-path | erlaubte Einzeldaten erzeugen eine sensible Ableitung | Compliance-relevanter Kontext wird sichtbar | Governance Owner | Policy-Matrix, Pfad-Governance, Audit-Log | Erprobungsrahmen begrenzen |
| stale-policy-source | veraltete Richtlinie bleibt im Evidence Store aktiv | Antwort verweist auf eine überholte Prüfpflicht | Content Owner | Quellenversion im Trace, Reprocessing, Monitoring | mit Update-Routine erproben |
| deletion-gap | gelöschte Quelle bleibt in Index oder Graph erreichbar | Löschpflicht wird technisch unvollständig umgesetzt | Data Owner | Löschjob, Index-Rebuild, Trace-Nachweis | Gate-Kriterium vor Go |
| vendor-lock-risk | Plattformfunktionen binden Datenmodell und Betrieb eng an einen Anbieter | Wechselkosten und Betriebsabhängigkeit steigen | Architektur Owner | Exportformat, Architekturentscheidung, Kostenreview | bewusst akzeptieren oder begrenzen |
Unter der Tabelle steht die Betriebsregel: Jede Risikozeile braucht einen Owner, eine Kontrolle und ein Entscheidungssignal. Der Owner trägt die fachliche Einordnung. Die Kontrolle zeigt, wie das Risiko im Betrieb begrenzt wird. Das Entscheidungssignal legt fest, ob die Erprobung starten kann, enger geschnitten wird oder eine zusätzliche Vorarbeit braucht.
Control
Kontrollfrage
Diese Frage muss beantwortbar sein
Welche Kontrolle reduziert welches Risiko, und reicht diese Kontrolle für eine begrenzte Erprobung?
Risk
Betriebsrisiko
Worauf du achten musst
Risiken bleiben als allgemeine Schlagworte stehen. Dann fehlt die Grundlage, um sie zu akzeptieren, zu reduzieren, zu überwachen oder als Stop-Kriterium zu behandeln.
Prüfen
Woran du es erkennst
Prüfpunkt
Der Risiko-Check ist belastbar, wenn jedes kritische Risiko eine konkrete Kontrolle und eine Pilotentscheidung hat.
Üben
Mini-Aufgabe
Ergänze ein Risiko für Datenlöschung oder Reprocessing. Beschreibe Ursache, Wirkung, Kontrolle und Entscheidung.
Musterlösung
Risiko: Eine gelöschte oder aktualisierte Richtlinie bleibt im Vector Store, Evidence Store oder Graph aktiv. Ursache: Reprocessing und Löschroutine sind unvollständig. Wirkung: Antworten verwenden veraltete Pflichten oder zeigen eine Quelle, die aus dem Betrieb entfernt wurde. Kontrolle: Quellenversion im Trace, Löschjob, Index-Rebuild und Monitoring-Frage im Eval-Set. Entscheidung: Erprobung nur mit klarer Update- und Löschroutine.
Reflektieren
Prüffragen
1.Was macht ein Risiko handhabbar?
Wenn Ursache, Wirkung, Kontrolle und Pilotentscheidung benannt sind.
2.Warum braucht Risikoarbeit konkrete Begriffe?
GraphRAG hat konkrete Betriebsrisiken wie falsche Kanten, sensible Ableitungen oder veraltete Quellen. Jedes dieser Risiken braucht eine eigene Kontrolle und eine eigene Pilotentscheidung.
3.Was prüft das Risiko-Register gegen die vorherigen Steps?
Ob Erprobungsrahmen, Policy, Evaluation, Trace, Kosten und Review die wichtigsten Risiken bereits abdecken und welche Entscheidung daraus für die Erprobung folgt.
Kernaussage
GraphRAG-Risiken werden handhabbar, wenn sie als konkrete Betriebsentscheidungen formuliert sind.