Kernaussage: Eine DPIA und eine Grundrechte-Folgenabschätzung dürfen nicht zu zwei widersprüchlichen Beschreibungen desselben KI-Systems werden. Bauen Sie eine versionierte Evidenzplattform mit zwei Linsen: gemeinsame Fakten zu System, Prozess, betroffenen Personen, Daten, Modell und Kontrollen; linsenspezifische Risikoanalyse und Freigaben; sowie eine nachvollziehbare Kette von Risiko über Kontrolle zu Test und operativer Verantwortung. Das reduziert Widersprüche, ohne Datenschutz- und Grundrechtsanalyse zu einem Kontrollkästchen zu verschmelzen.
Rechtliche Grenze: gemeinsame Evidenz ist kein gemeinsames Rechtsurteil
Artikel 27 EU AI Act verpflichtet bestimmte Betreiber vor dem Einsatz bestimmter Hochrisiko-Systeme zu einer Grundrechte-Folgenabschätzung. Wenn Verpflichtungen bereits durch eine DPIA nach Artikel 35 DSGVO erfüllt sind, ergänzt die FRIA diese DPIA. Artikel 35 DSGVO verlangt vor einer voraussichtlich hochriskanten Verarbeitung eine DPIA und benennt Mindestinhalte. Dieser Beitrag beschreibt ein Engineering-Muster, keine Einordnung Ihres Einzelfalls. Klassifizierung, Rolle, sektorale Regeln, Rechtsgrundlage und Konsultationspflichten gehören zu Rechtsberatung sowie den Verantwortlichkeiten von Controller und Betreiber.
Warum getrennte Dokumente driften
Datenschutz, Risiko, Produkt und Engineering betrachten dieselben Fakten zu unterschiedlichen Zeitpunkten: Modell- und Lieferantenversion, Zweck, betroffene Gruppen, Datenkategorien, menschliche Rolle, Region, Entscheidungsfolge, Testergebnisse und Incidents. Werden diese Fakten in separaten Tabellen oder PDFs kopiert, kann eine Bewertung aktuell und die andere veraltet sein. Das Problem ist keine fehlende Prosa, sondern eine nicht versionierte Evidenzlieferkette.
Beginnen Sie mit einem KI-Use-Case-Intake als Policy-as-Code als belastbarem Muster für Evidenzpakete und Verantwortlichkeiten. Ergänzend zeigen Human-in-the-Loop-Freigaben und Audit-Logs, wie eine menschliche Kontrollgrenze technisch geprüft wird. Für Daten- und Zugriffskontrollen bleibt RAG-Sicherheit mit Berechtigungen und Audit-Logs relevant. Diese Kontrollen ersetzen keine Folgenabschätzung.
Architektur: ein Evidenzgraph, zwei kontrollierte Linsen
Verwenden Sie unveränderliche Evidenzobjekte statt eines Masterdokuments. Das Minimum: UseCaseVersion, SystemBoundary, ProcessingActivity, DataAsset, ModelOrComponentVersion, SupplierRecord, AffectedGroup, Risk, Control, TestRun, Finding, Decision, Approval, Incident und ReassessmentTrigger. Jedes Objekt trägt ID, Owner, Quellenlink, Version, Klassifizierung, Erhebungszeitpunkt, Aufbewahrungsregel und Status.
Evidenzfluss: Intake- oder Änderungsereignis → Fakten erfassen und versionieren → gemeinsamer Evidenzgraph → DPIA-Linse (Zweck, Erforderlichkeit/Verhältnismäßigkeit, Risiken personenbezogener Daten, Garantien) plus FRIA-Linse (Prozesskontext, betroffene Gruppen, konkreter Schaden, menschliche Aufsicht, Governance und Beschwerdemechanismus) → Risiko-Kontrolle-Test-Traceability → unabhängige Freigabetasks → Deploy/Hold → Betriebssignale öffnen Evidenz und Bewertung erneut.
Beide Linsen fragen gemeinsame Objekte ab, erzeugen aber getrennte Assessment Records, Schlussfolgerungen und Freigabestati. Ein DPIA-Reviewer braucht keinen breiten Zugriff auf sensible Grundrechtsinterviews; ein FRIA-Reviewer nicht automatisch auf Rohproben personenbezogener Daten. Verknüpfen Sie über IDs, halten Sie pro Sicht nur die nötige Evidenz vor und schützen Sie restriktive Artefakte mit separaten Zugriffsregeln.
Entscheidungstabelle: teilen, aber nicht vermischen
| Evidenzbereich | Kontrolliert teilen | DPIA-Linse | FRIA-Linse | Release-Gate |
|---|---|---|---|---|
| System und Prozess | Systemgrenze, Zweck, Owner, Version | Verarbeitung und Zweck | Betreiberprozess und intendierte Nutzung | Halt bei unbekannter Grenze oder Ownership |
| Personen und Daten | Gruppen, Datenkategorien, Quelle/Version | Erforderlichkeit, Verhältnismäßigkeit, Datenschutzrisiko | Personengruppen und plausibler Schaden | Halt bei nicht verifiziertem Datenfluss |
| Kontrollen und Tests | Kontroll-ID, Owner, Testergebnis, Ablauf | Datenschutz-/Sicherheitsgarantie | Aufsicht, Governance, Beschwerdeweg | Halt bei ungetesteter oder abgelaufener kritischer Kontrolle |
| Änderung und Incident | Release-, Lieferanten-, Modell-, Daten- und Signal-ID | Verarbeitung-Risiko neu bewerten | geänderte Art.-27-Elemente aktualisieren | Halt bis zum scoped Reassessment |
Risiko → Kontrolle → Test maschinell navigierbar machen
Ein brauchbarer Risikoeintrag lautet nicht nur „Bias: mittel“. Er enthält Szenario, betroffene Gruppe, Auswirkung, Begründung der Eintrittswahrscheinlichkeit, Evidenzreferenzen, verantwortliche Rolle und Entscheidung zum Restrisiko. Er verknüpft eine oder mehrere Kontrollen: Berechtigungsregel, menschliche Freigabegrenze, Retrieval-Filter, Sprachsegment-Eval, Rollback oder Beschwerdeworkflow. Jede Kontrolle verknüpft einen Test mit versionierter Methode, Fixture-Referenz, Ergebnis, Review und Ablaufdatum. Der Release-Service blockiert Promotion, wenn eine kritische Kante fehlt, fehlschlägt oder veraltet ist.
Reassessment an technische Realität koppeln
Definieren Sie Trigger als Ereignisse: neue Modell- oder Providerversion; materielle Prompt-/Tooländerung; neue Datenkategorie oder Quelle; andere Nutzergruppe oder Entscheidungsfolge; neue Region; fehlgeschlagener Fairness-, Safety- oder Datenschutztest; Incident oder substantiierte Beschwerde; Kontrollablauf; oder eine von Legal gemeldete geänderte Auslegung. Das Ereignis erzeugt ein scoped Review-Paket mit veränderten Objekten, betroffenen Risiken/Kontrollen und zuständigen Linsen-Ownern.
Artikel 27 verlangt eine Aktualisierung, wenn seine Elemente sich ändern oder nicht mehr aktuell sind. Artikel 35 Absatz 11 DSGVO verlangt eine Überprüfung, wenn sich das Risiko der Verarbeitung ändert. Automatisieren Sie deshalb Faktenrouting und Sperren unreviewter Promotion – nicht Rechtsurteile. Protokollieren Sie Trigger, Scope, Triage, neue Evidenz, Freigabe und Release-Entscheidung.
Fehlermodi, die die Architektur verhindern soll
1. Copy-paste-Drift: Datenschutz und KI-Governance nennen verschiedene Modell- oder Zweckversionen. Gegenmaßnahme: immutable Objekt-IDs und ein Release-Manifest.
2. Oversharing: gemeinsamer Workspace legt Interviewnotizen oder Datenproben für alle offen. Gegenmaßnahme: Feldklassifizierung, linsenspezifische Views, Least Privilege und Access-Audit-Events.
3. Evidenz ohne Nachweis: eine Mitigation gilt als erledigt, hat aber keinen wiederholbaren Test. Gegenmaßnahme: Control-zu-TestRun-Verknüpfung plus ablaufbewusste Gates.
4. Change Blindness: Providerupdate oder Retrieval-Index-Refresh umgeht die Bewertung. Gegenmaßnahme: Lieferanten-, CI/CD- und Data-Catalogue-Events als Reassessment-Trigger.
5. Automation Theatre: ein hoher Score beendet eine Grundrechtsfrage. Gegenmaßnahme: Restrisikofreigabe und Rechtsauslegung bleiben menschliche Entscheidungen mit Begründung.
Was die Plattform nicht löst
Sie entscheidet nicht, ob Ihr System hochriskant ist, ob FRIA oder DPIA erforderlich sind, ob eine Rechtsgrundlage vorliegt oder Restrisiko akzeptabel ist. Sie ersetzt keine Konsultation von DPO, Rechtsberatung, Betroffenenvertretung oder zuständigen Behörden, soweit erforderlich. Sie kostet Betrieb: Objektpflege, Zugriffskonzept, Integrationen und Testwartung. Für einen kleinen Pilot kann ein kompaktes Evidenzregister verhältnismäßig sein. Bei wirkungsrelevanten Einsätzen sind getrennte Dokumente meist der teurere Fehlermodus.
Kleinsten nützlichen Evidenzkern umsetzen
Wählen Sie einen geplanten oder live laufenden Workflow. Versionieren Sie Systemgrenze und Zweck, kartieren Sie drei betroffene Gruppen und Datenflüsse, definieren Sie fünf Risiken, ordnen Sie Kontrollen und Tests zu und aktivieren Sie drei Trigger: Modell-/Providerwechsel, Datenquellenwechsel und fehlgeschlagene Kontrolle. Führen Sie danach ein Tabletop-Reassessment durch und beweisen Sie, dass ein Release mit abgelaufenem kritischem Test nicht durchkommt. Ich unterstütze Privacy-, Risiko- und Engineering-Teams dabei, diesen Evidenzkern in einen umsetzbaren Control-Plane-Backlog zu überführen.
Quellen
Verordnung (EU) 2024/1689, Artikel 27 (EUR-Lex)
