Ein Data-Governance-Council aufbauen, dem Aufsichtsbehörden vertrauen

# Ein Data-Governance-Council aufbauen, dem Aufsichtsbehörden vertrauen

Ein staatlicher Versicherungsprüfer fragt einen Schadenleiter: „Wer hat das März-Update Ihres Claims-Scoring-Modells genehmigt, und welche Daten haben sich geändert?" Der Leiter stockt, fragt bei der IT nach, fragt beim Aktuariat nach und schickt drei Tage später eine unvollständige Antwort. Diese Verzögerung, nicht die Modelländerung selbst, löst eine formelle Untersuchung aus. Aufsichtsbehörden erwarten keine Perfektion. Sie erwarten Nachvollziehbarkeit. Diese Lektion baut die Gremienstruktur, die aus „Wer hat das genehmigt" eine Fünf-Minuten-Antwort macht statt einer Drei-Tage-Suchaktion.

Warum Versicherer das besonders brauchen

Versicherung läuft auf Daten, die gleichzeitig sensibel (Gesundheit, Fahrzeugregister, kreditbasierte Versicherungsscores) und folgenreich sind (sie entscheiden, wer Deckung erhält und zu welchem Preis). Zwei regulatorische Druckpunkte treffen hier zusammen:

• Datenschutzrecht: In den USA regeln einzelstaatliche Gesetze wie der California Consumer Privacy Act (CCPA) und branchenspezifische Regeln nach dem NAIC (National Association of Insurance Commissioners) Insurance Data Security Model Law, wie personenbezogene Daten erhoben, gespeichert und geteilt werden. In Europa regelt die DSGVO (Datenschutz-Grundverordnung) die Verarbeitung personenbezogener Daten, und der EU AI Act ergänzt Pflichten für „hochriskante" KI-Systeme, worunter explizit Preisbildungs- und Underwriting-Modelle in der Lebens- und Krankenversicherung fallen.
• Model Governance: Das NAIC Model Bulletin on the Use of Algorithms, Artificial Intelligence Systems, and Predictive Models (ab 2023 von mehreren Staaten übernommen) verlangt von Versicherern, die Governance über KI- und Prognosemodelle in Underwriting, Tarifierung und Schaden zu dokumentieren. Colorados SB21-169 verlangt bereits, dass Versicherer Tarifierungs- und Underwriting-Modelle auf unfaire Diskriminierung testen.

Beide Druckpunkte stellen dieselbe Grundfrage: Können Sie Ihre Arbeit belegen? Ein Data-Governance-Council ist die Struktur, die diese Nachweise laufend erzeugt, nicht erst auf Anfrage.

Die zentralen Rollen

Ein Council, dem Aufsichtsbehörden vertrauen, hat klar getrennte Rollen, nicht ein einziges „Datenteam", das alles macht.

1. Data Governance Council (das Gremium selbst)

Tagt monatlich (oder ad hoc bei dringenden Änderungen). Cross-funktional: Aktuariat, Schaden, Underwriting, IT/Data Engineering, Compliance, Recht und ein Sponsor auf Vorstandsebene. Dieses Gremium genehmigt wesentliche Änderungen an Datenquellen, Modell-Inputs und Scoring-Logik.

2. Data Owner

Eine namentlich benannte Führungskraft aus dem Business (z. B. Head of Claims), verantwortlich für die Korrektheit und angemessene Nutzung eines bestimmten Datensatzes. Nicht identisch mit der Person, die die Datenbank technisch betreibt.

3. Data Steward

Operative Rolle, üblicherweise im Data-/Analytics-Team, verantwortlich für tägliche Datenqualitätsprüfungen, Lineage-Dokumentation und das Melden von Anomalien an den Data Owner.

4. Model Risk Officer oder Validation Lead

Unabhängig von dem Team, das das Claims-Scoring-Modell baut. Prüft Modelländerungen vor dem Go-live auf Bias, Drift und Performance. Diese Trennung von „Builder" und „Validator" ist das Erste, worauf Prüfer schauen; das NAIC-Bulletin und die meisten einzelstaatlichen Prüfungen kontrollieren die Unabhängigkeit zwischen Modellentwicklung und Modellvalidierung explizit.

5. Privacy Officer / DPO (Data Protection Officer)

Nach DSGVO für viele Versicherer verpflichtend, die sensible Daten in großem Umfang verarbeiten. Prüft, ob neue Datennutzungen (z. B. Telematik-Fahrdaten in ein Claims-Modell aufnehmen) eine neue Rechtsgrundlage oder eine Datenschutz-Folgenabschätzung (DSFA) erfordern.

6. Escalation Owner

Eine benannte Führungskraft (oft Chief Data Officer oder Chief Risk Officer), die Entscheidungen trifft, die das Council nicht im Konsens lösen kann, z. B. eine Meinungsverschiedenheit zwischen Aktuariat und Compliance, ob eine Variable ein Proxy für ein geschütztes Merkmal ist.

Der Eskalationspfad, konkret

So sollte es ablaufen, wenn jemand vorschlägt, eine neue Variable in das Claims-Scoring-Modell aufzunehmen, etwa einen „Household Stability"-Score eines Drittanbieters:

1. Vorschlag erfasst in einem Änderungsregister mit Business-Begründung, Datenquelle und beabsichtigter Verwendung.

2. Data StewardData StewardA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.Vollständige Definition ansehen → prüft die Lineage: Woher kommt dieser Score, ist ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → lizenziert, hat der Anbieter eine eigene Bias-Dokumentation.

3. Privacy Officer prüft: Sind das personenbezogene Daten nach DSGVO/CCPA, haben wir eine Rechtsgrundlage, braucht es eine DSFA.

4. Model Risk Officer führt einen Disparate-Impact-Test durch: Korreliert die neue Variable stark mit geschützten Merkmalen (Ethnie und, in vielen US-Staaten inzwischen, Proxys für Ethnie in kreditbasiertem Scoring).

5. Abstimmung im Council: Mehrheitsbeschluss protokolliert mit Namen, Daten und abweichenden Meinungen, die festgehalten und nicht verworfen werden.

6. Sign-off-Ritual: Data Owner und Model Risk Officer zeichnen beide einen Änderungsdatensatz ab, bevor es in Produktion geht.

7. Escalation Owner wird nur hinzugezogen, wenn in Schritt 5 keine Einigung erzielt wird.

Das entscheidende Artefakt ist das Änderungsregister: ein strukturiertes Log, nicht ein Protokoll, das in E-Mails verschwindet. Eine einfache Version:

change_id | date | model | field_added | proposer | data_source |
bias_test_result | privacy_review | council_decision | approver | sign_off_date

Jede Zeile dieser Tabelle sollte in einer Prüfung in unter einer Minute beantwortbar sein. Das ist die wertvollste Gewohnheit, die ein Council sich aneignen kann: die Entscheidung in dem Moment aufschreiben, in dem sie fällt, und nicht später aus dem Gedächtnis rekonstruieren.

Für eine praxisnahe Vorlage zur Dokumentation von KI-/Modell-Governance-Entscheidungen bietet das NIST AI Risk Management Framework eine kostenlose, branchenneutrale Struktur, die viele Versicherer adaptieren: NIST AI RMF.

Sign-off-Rituale, die einer Prüfung standhalten

Drei Gewohnheiten unterscheiden Councils, die eine Prüfung überstehen, von denen, die es nicht tun:

• Doppeltes Sign-off statt Einzelgenehmigung. Der Business Owner und ein unabhängiger Risk-/Compliance-Prüfer zeichnen beide ab. Ein einziger Name auf einer Änderung ist für Prüfer ein Warnsignal; es bedeutet, dass keine unabhängige Kontrolle stattgefunden hat.
• Versionierte Modelldokumentation. Jede ausgerollte Version des Claims-Scoring-Modells sollte einem konkreten, mit Zeitstempel versehenen Genehmigungsdatensatz zuzuordnen sein. Wenn Ihr Data-Science-Team git-artige Versionierung für Code nutzt, sollte dieselbe Disziplin für die Governance-Unterlagen gelten.
• Quartalsweises Self-Audit statt nur jährlich. Ziehen Sie eine Zufallsstichprobe der Änderungen des letzten Quartals und prüfen Sie, ob der Papierweg mit dem übereinstimmt, was in Produktion läuft. Genau das wird das Prüfteam einer Aufsichtsbehörde tun, also machen Sie es zuerst bei sich selbst.

Was Aufsichtsbehörden tatsächlich prüfen

Unterschiedliche Regime, dieselbe Grundfrage, nur anders formuliert:

| Regime | Was gefragt wird | Was es belegt |

|---|---|---|

| NAIC Model Bulletin (USA, einzelstaatlich übernommen) | Haben Sie eine dokumentierte Governance über KI-/Prognosemodelle in Underwriting oder Schaden? | Council-Charter, Änderungsregister, Validierungsberichte |

| Colorado SB21-169 | Haben Sie Tarifierungs-/Underwriting-Algorithmen auf unfaire Diskriminierung getestet? | Bias-Testing-Logs, Methodendokumentation |

| DSGVO (EU) | Gibt es eine Rechtsgrundlage und eine dokumentierte Folgenabschätzung für die Nutzung personenbezogener Daten? | DSFA-Unterlagen, Sign-off des DPO |

| EU AI Act (hochriskante Systeme, gestufte Anwendung über 2026-2027) | Gibt es ein Risikomanagementsystem und menschliche Aufsicht für das KI-System? | Risiko-Logs, Human-in-the-Loop-Sign-off-Nachweise |

Beachten Sie das Muster: Keines dieser Regime fordert eine bestimmte Softwareplattform oder einen bestimmten Gremiennamen. Sie fordern Nachweise eines Entscheidungsprozesses, den ein Dritter im Nachhinein rekonstruieren kann. Das ist das eigentliche Ergebnis eines Governance-Councils: ein Audit Trail, kein Meeting.

Ein häufiges Fehlermuster, das Sie vermeiden sollten

Viele Versicherer bauen auf dem Papier ein eindrucksvolles Council auf und lassen es dann Änderungen rückwirkend genehmigen: Das Modellteam rollt ein Update aus und bringt es Wochen später „zur Kenntnis" in die nächste planmäßige Council-Sitzung. Das ist schlechter als kein Council, denn es erzeugt einen Papierweg, der zeigt, dass Governance umgangen wurde. Aufsichtsbehörden haben genau dieses Muster in Market-Conduct-Prüfungen beanstandet. Die Lösung ist einfach, aber organisatorisch schwer: kein Produktions-Deployment ohne vorherigen, datierten Genehmigungsdatensatz. Bauen Sie die technische Deployment-PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen → so, dass sie eine Sign-off-Ticketnummer verlangt, bevor sie in Produktion pusht. Machen Sie die Kontrolle physisch unumgehbar, nicht bloß per Richtlinie unerwünscht.

Wichtigste Erkenntnisse

• Trennen Sie die Rollen: Data Owner (Business-Verantwortung), Data StewardData StewardA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.Vollständige Definition ansehen → (operative Qualität), Model Risk Officer (unabhängige Validierung), Privacy Officer (Rechtsgrundlage und DSFAs) und einen Escalation Owner für ungelöste Streitfälle.
• Bauen Sie ein Änderungsregister, das jede Modell- oder Datenänderung mit Antragsteller, Bias-Testergebnis, Datenschutzprüfung und doppeltem Sign-off protokolliert, vor dem Deployment, nicht danach.
• Aufsichtsbehörden (von NAIC übernommene einzelstaatliche Regeln, Colorado SB21-169, DSGVO, EU AI Act) stellen alle dieselbe Kernfrage in anderen Worten: KKThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen Sie rekonstruieren, wer was genehmigt hat und warum. Designen Sie für diese Antwort, nicht für das einzelne Gesetz.
• Führen Sie Ihr eigenes Quartals-Audit des Änderungsregisters durch, bevor ein Prüfer es für Sie tut.
• Machen Sie das Umgehen von Governance technisch unmöglich (z. B. Deployment-Pipelines, die eine Sign-off-Ticketnummer verlangen), nicht bloß zur schriftlichen Richtlinie.