Konzeptdokument · Vertraulich

Data Governance
Platform

Hauck & Aufhäuser Fund Services (HAFS-Group)

Zentrale Plattform für Metadata Management, Data Quality, Data Lineage, Data Classification und Compliance – abgestimmt auf die regulatorischen Anforderungen der HAFS-Group unter DORA, CSSF und DSGVO.

Requirements

Feature-Bereiche

Klassifizierungsstufen

Entities

Kapitel 01

Vision & Ziele

Strategische Einordnung der Data Governance Platform im Kontext der HAFS-Group und ihrer regulatorischen Anforderungen.

Ausgangslage

Die HAFS-Group verwaltet als Fondsadministrator umfangreiche Datenbestände über mehrere Quellsysteme hinweg – darunter Oracle-Datenbanken und Sage BOB. Aktuell fehlt eine zentrale Plattform, die Metadaten systematisch erfasst, Datenqualität überwacht, Datenflüsse nachvollziehbar macht und die Einhaltung regulatorischer Anforderungen sicherstellt.

Als regulierter Finanzdienstleister unterliegt die HAFS-Group strengen Anforderungen an Datenhaltung, Klassifizierung und Nachvollziehbarkeit. Die bestehende Information Classification Policy (V1.3) definiert bereits fünf Klassifizierungsstufen, die in der neuen Plattform technisch abgebildet und durchgesetzt werden müssen.

Regulatorischer Kontext: Die Plattform adressiert Anforderungen aus DORA (EU 2022/2554) für digitale operationale Resilienz, CSSF Circular 20/750 bzw. 25/881 für ICT Risk Management sowie der DSGVO für den Schutz personenbezogener Daten.

Scope: HAFS-Group Entitäten

Entität	Standort	Regulierung	In Scope
Hauck & Aufhäuser Fund Services S.A. (HAFS)	Luxemburg	DORA, CSSF	✓ Ja
Hauck & Aufhäuser Administration Services (HAAS)	Deutschland	DORA, BaFin	✓ Ja
Hauck Aufhäuser Lampe Fund Services Ireland (HALFI)	Irland	DORA, CBI	✓ Ja

Vision Statement

«Eine zentrale, intelligente Data Governance Plattform, die Metadaten, Datenqualität, Lineage, Klassifizierung und Compliance in einer einheitlichen Oberfläche vereint – und so die HAFS-Group befähigt, ihre Daten als strategischen Vermögenswert zu managen.»

Strategische Ziele

Metadata-Transparenz

Vollständige Erfassung aller Datenobjekte aus Oracle, Sage BOB und weiteren Quellen

Datenqualität

Kontinuierliches Monitoring und Alerting bei Qualitätsabweichungen

Nachvollziehbarkeit

End-to-End Lineage von Quelle bis Report für Impact-Analysen

Compliance

Automatische Klassifizierung, Audit-Trail und Policy-Enforcement

Data Protection

DLP-Integration zur Verhinderung unkontrollierter Datenabflüsse

Self-Service

Data Stewards und Fachbereiche können Metadaten eigenständig pflegen

Ziel-KPIs

KPI	Zielwert	Messzeitraum
Metadata Coverage (erfasste Datenobjekte)	>90%	12 Monate nach Go-Live
Data Quality Score (Durchschnitt aller Domains)	>85%	6 Monate nach Go-Live
Classification Coverage	100%	3 Monate nach Go-Live
Lineage Coverage (kritische Datenpfade)	>80%	12 Monate nach Go-Live
Audit Compliance Rate	>95%	Laufend
DLP Policy Enforcement Rate	100%	Ab Go-Live DLP-Modul

Referenzsysteme

Als Benchmark und Inspirationsquelle für die Plattform dienen zwei etablierte Systeme:

Referenz A

OpenMetadata

Open-Source Data Catalog & Governance Plattform. Stärken: Metadata Harvesting, Data Quality Framework, Lineage, Glossary. Referenz für Architektur-Patterns und API-Design.

Open SourceCatalogQuality

Referenz B

Microsoft Purview

Enterprise Data Governance Suite. Stärken: Data Classification, DLP, Compliance, Information Protection. Referenz für Classification-Schema und DLP-Policies.

EnterpriseDLPClassification

Kapitel 02

Anforderungen & MoSCoW

Alle 29 Anforderungen priorisiert nach der MoSCoW-Methode: Must Have, Should Have, Could Have.

Must Have

Should Have

Could Have

Won’t Have

📚

Metadata Management

Business Glossary / Data Dictionary

Verwaltung von Fachbegriffen mit Definition, Owner, Gültigkeitsstatus und Verlinkung zu Datenobjekten zur Schaffung einer einheitlichen Terminologie.

Must

Automatisches Metadata Harvesting

Automatisches Auslesen von Metadaten aus Quellsystemen (Oracle-Datenbanken, Sage BOB) via Connectors/API.

Must

Manuelles Metadata Enrichment

Data Stewards müssen technische Metadaten mit fachlichem Kontext anreichern können (Beschreibungen, Klassifizierungen, Verantwortlichkeiten).

Must

Metadata Enrichment per Script / KI

Massendatenanreicherung per Script oder mittels KI-gestützter Automatisierung.

Must

🔍

Data Catalog

Asset Inventory

Zentrales Verzeichnis aller Datenobjekte: Tabellen, Felder, Reports, Dashboards, Dateien.

Must

Search & Discovery

Volltextsuche und facettierte Filterung, damit Nutzer Datenobjekte selbstständig finden können.

Must

Data Domain Management

Strukturierung des Data Catalogs nach Data Domains mit Unter-Domains. Rechte werden nach unten vererbt.

Must

🔄

Data Lineage

Technische Lineage

Automatisches Tracking von Datenflüssen zwischen Systemen (Quelltabelle → Transformation → Zieltabelle → Power BI Report).

Must

Business Lineage

Vereinfachte Darstellung für nicht-technische Stakeholder: „Welche Quelldaten fließen in diesen Report?“

Could

Impact Analysis

Vorwärts-Analyse: Welche Reports/Systeme sind betroffen, wenn sich Tabelle X ändert?

Should

🔒

Data Classification

Klassifizierungs-Schema

Abbildung der 5-stufigen Datenklassifizierung (Non-business, Public, Internal, Confidential, Highly Confidential) gemäß HAFS Classification Policy V1.3.

Must

PII/GDPR-Kennzeichnung

Automatische oder manuelle Markierung personenbezogener Daten für GDPR-Compliance.

Must

Tagging

Kennzeichnung von Daten (z.B. Gold-Status, regulatorische Anforderungen, etc.).

Must

✅

Data Quality

DQ Rule Definition

Definierbarkeit von Qualitätsregeln auf Feld- und Tabellenebene (Vollständigkeit, Eindeutigkeit, Validität, Konsistenz).

Must

DQ Profiling

Automatische Analyse von Ist-Qualität: Null-Werte, Duplikate, Werteverteilungen.

Must

DQ Monitoring & Alerting

Regelmäßige automatisierte Prüfläufe mit Benachrichtigung bei Abweichungen.

Must

DQ Scorecard / Dashboard

Visualisierung von Qualitätskennzahlen nach Data Domain und über Zeit.

Must

👥

Ownership & Stewardship

Rollen-Management

Abbildung von Data Owner, Data Steward, Data Custodian, Data Consumer direkt am Datenobjekt.

Must

Aufgaben- und Workflow-Management

Zuweisung und Tracking von Stewardship-Aufgaben (z.B. „Metadaten pflegen“, „DQ-Problem lösen“).

Should

Approval Workflows

Formalisierte Freigabeprozesse für Änderungen an kritischen Datenobjekten.

Should

📜

Compliance & Audit

Audit Trail / Change Log

Vollständige, unveränderliche Protokollierung aller Änderungen an Metadaten, Klassifizierungen und Policies.

Must

Policy Management

Abbildung und Verknüpfung von Datenpolicies (Data Classification Policy, Data Access Policy) mit betroffenen Datenobjekten.

Must

📄

Data Contracts

Data Contract Management

GUI die dem Open Data Contract Standard folgt (ODCS v3.1.0).

Could

Genehmigungsworkflow

Workflow zur Beantragung, Rückfrage, Weiterleitung und Genehmigung von Data Contracts.

Could

SLA-Tracking

Tracking der in den Data Contracts vereinbarten SLA.

Could

🛡

Data Loss Prevention (DLP)

DLP Tracking & Enforcement

Verhindert, dass sensible oder klassifizierte Daten das Unternehmen unkontrolliert verlassen. Z.B. Dokumente mit Label „Streng vertraulich“ dürfen nicht per E-Mail nach extern gesendet werden.

Should

🔐

Zugriffsverwaltung & Sicherheit

Role-Based Access Control (RBAC)

Rollenbasierter Zugriff auf das Tool selbst und auf sensible Metadaten.

Must

⚙

Usability & Administration

Konfigurierbare Metadaten-Schemata

Eigene Felder und Attribute ergänzbar, um spezifische Anforderungen abzubilden.

Should

Rollenspezifische Dashboards

Unterschiedliche Einstiegsansichten für Data Owner, Data Steward, Compliance-Verantwortliche.

Could

Kapitel 03

Plattform-Architektur

Schichtenarchitektur der Data Governance Platform mit Integrationsschicht zu den Quellsystemen der HAFS-Group.

┌────────────────────────────────────────────────────────────────┐
│                    PRESENTATION LAYER                      │
│  Web UI (React/Next.js)  ·  API Gateway  ·  Admin Portal    │
└──────────────────────────────┬─────────────────────────────────┘
                               │
┌──────────────────────────────┴─────────────────────────────────┐
│                      SERVICE LAYER                          │
│  ┌───────────┐ ┌──────────┐ ┌───────────┐ ┌───────────┐  │
│  │ Metadata  │ │ Catalog   │ │ Quality   │ │ Lineage   │  │
│  │ Service   │ │ Service  │ │ Service   │ │ Service   │  │
│  └───────────┘ └──────────┘ └───────────┘ └───────────┘  │
│  ┌───────────┐ ┌──────────┐ ┌───────────┐ ┌───────────┐  │
│  │ Classifi- │ │ Policy   │ │ DLP       │ │ Contract  │  │
│  │ cation    │ │ Service  │ │ Service   │ │ Service   │  │
│  └───────────┘ └──────────┘ └───────────┘ └───────────┘  │
└──────────────────────────────┬─────────────────────────────────┘
                               │
┌──────────────────────────────┴─────────────────────────────────┐
│                   INTEGRATION LAYER                        │
│  Oracle Connector  ·  Sage BOB Connector  ·  File Scanner  │
│  Power BI Connector  ·  REST API  ·  JDBC/ODBC            │
└──────────────────────────────┬─────────────────────────────────┘
                               │
┌──────────────────────────────┴─────────────────────────────────┐
│                       DATA LAYER                           │
│  PostgreSQL  ·  Elasticsearch  ·  Neo4j (Lineage Graph)   │
│  Redis (Cache)  ·  MinIO (Object Storage)                │
└────────────────────────────────────────────────────────────────┘

Technology Stack

Schicht	Technologie	Zweck
Frontend	React / Next.js	Web UI, Server-Side Rendering, Dashboard-Komponenten
API Gateway	Nest.js	REST API, Authentication, Rate Limiting
Backend Services	Nest.js (TypeScript)	Microservices für Metadata, Catalog, Quality, Lineage, Classification
Relationale DB	PostgreSQL	Metadaten, Policies, Audit Trail, User Management
Suchindex	Elasticsearch	Volltextsuche, Asset Discovery, DQ Profiling Results
Graph DB	Neo4j	Data Lineage Graphen, Impact Analysis
Cache	Redis	Session Management, API Caching
Object Storage	MinIO	Dokumente, Attachments, Export-Dateien
Orchestrierung	Kubernetes (RKE2)	Container-Orchestrierung, Service Mesh
CI/CD	GitLab CI / GitHub Actions	Automatisierte Build- und Deploy-Pipeline
Monitoring	Prometheus + Grafana	Infrastruktur- und Application-Monitoring
AI/ML	Claude API / Python	Auto-Classification, Metadata Enrichment, PII Detection

Integrationsmuster

Die Plattform verbindet sich über dedizierte Connectors mit den Quellsystemen der HAFS-Group:

Oracle Connector

JDBC-basierter Connector für automatisches Schema-Crawling, Tabellen-/Spalten-Metadaten, DQ Profiling direkt auf der Datenbank.

JDBCAuto-Discovery

Sage BOB Connector

API-basierter Connector für die Extraktion von Buchhaltungs-Metadaten, Kontenplänen und Stammdaten-Strukturen.

REST APIBatch

Power BI Connector

Integration über Power BI REST API für Report-Metadaten, Dataset-Lineage und Usage Analytics.

REST APILineage

KI-Strategie

AI & Automation Hub

KI-gestützte Automatisierung durchdringt jedes Modul der Plattform – von intelligenter Klassifizierung über Chatbot-Interaktion bis hin zu prädiktiver Qualitätsanalyse.

KI-Philosophie: Die Plattform setzt KI nicht als Gadget ein, sondern als durchgängigen Automatisierungsmotor. Jeder manuelle Prozess wird hinterfragt: „Kann KI das schneller, präziser oder proaktiv erledigen?“ Das Ergebnis: bis zu 80% weniger manueller Aufwand für Data Stewards bei höherer Qualität.

Übersicht: KI-Features pro Modul

📚

Metadata Management

Auto-Enrichment, KI-generierte Beschreibungen, Glossar-Term-Suggestions, Schema-Similarity-Erkennung

🔍

Data Catalog

Semantische Suche (NLP), Chatbot-Discovery, Smart Recommendations, Auto-Tagging

🔄

Data Lineage

Implicit Lineage Discovery, SQL-Analyse, Predictive Impact Scoring, Business Lineage Generation

🔒

Classification

Auto-Classification Engine, PII-Scanner, Smart Labeling, Compliance-Auto-Assessment

✅

Data Quality

Auto-Rule-Generation, Anomalie-Erkennung, Predictive DQ Scoring, Root-Cause-Analyse

🛡

DLP & Compliance

Behavioral Analytics, Anomalie-Erkennung bei Datenzugriff, Auto-Compliance-Reports

👥

Stewardship

Intelligentes Task-Routing, Workload-Balancing, Auto-Priorisierung, Chatbot-Support

📄

Data Contracts

Auto-Draft aus Metadaten, SLA-Prädiktion, intelligente Schwellenwert-Empfehlungen

Governance Chatbot

Der Governance Chatbot ist der zentrale KI-Assistent der Plattform. Er steht allen Nutzern – vom Data Consumer bis zum Compliance Officer – als natürlichsprachliche Schnittstelle zur Verfügung. Der Chatbot nutzt RAG (Retrieval Augmented Generation) über den gesamten Data Catalog, Glossar, Policies und Audit Trail.

Chatbot-Fähigkeiten

Fähigkeit	Beispiel-Frage	KI-Aktion
Asset Discovery	„Wo finde ich die NAV-Daten?“	Semantische Suche im Catalog, zeigt relevante Assets mit Kontext
Lineage-Auskunft	„Woher kommen die Daten im NAV Daily Report?“	Traversiert Lineage-Graph, gibt verständliche Zusammenfassung
DQ-Status	„Wie ist die Datenqualität in Fund Accounting?“	Aggregiert DQ-Scores, nennt aktive Violations
Klassifizierungs-Hilfe	„Wie soll ich Kundenadressen klassifizieren?“	Zitiert HAFS Policy V1.3, empfiehlt „Confidential“ + PII-Tag
Policy-Auskunft	„Darf ich diese Datei per E-Mail verschicken?“	Prüft Klassifizierung, nennt Handling-Regeln, warnt bei Verstoß
Impact-Analyse	„Was passiert, wenn wir die Tabelle PRICES ändern?“	Führt Forward-Impact-Analyse durch, listet betroffene Reports
Compliance-Check	„Sind wir DORA-konform für Fund Accounting?“	Prüft Policies, Coverage, Audit Status, generiert Compliance-Report
Stewardship-Support	„Was sind meine offenen Aufgaben als Data Steward?“	Zeigt priorisierte Task-Liste mit Empfehlungen

governance.hafs.de/assistant

Woher kommen die Daten im NAV Daily Report und wie ist deren Qualität?

🤖

NAV Daily Report – Lineage & Qualität

Der Report bezieht seine Daten aus 3 Quelltabellen:
• POSITIONS (Oracle) – DQ: 96.2% ✓
• PRICES (Oracle) – DQ: 98.1% ✓
• FX_RATES (Oracle) – DQ: 94.8% ⚠

⚠ Warnung: FX_RATES hat 3 aktive Violations (Aktualität). Letzer Refresh: vor 26h (SLA: 24h).

Quellen: Lineage-Graph, DQ-Engine · Stand: vor 12 Min.

Wer ist für FX_RATES verantwortlich und ist das DORA-relevant?

🤖

FX_RATES – Verantwortlichkeiten:
• Data Owner: J. Weber (Treasury)
• Data Steward: K. Müller
• Klassifizierung: Confidential

🚨 DORA-Relevanz: JA – FX_RATES ist in der DORA ICT Asset Registry erfasst und unterliegt Art. 11 (ICT Risk Management). Die aktuelle DQ-Violation sollte als operationelles Risiko dokumentiert werden.

Soll ich einen Stewardship-Task für K. Müller erstellen?

➤

Governance Chatbot – Natürlichsprachliche Abfragen über Lineage, DQ, Policies und Compliance mit kontextbezogenen Antworten

Auto-Assessment Engine

Die Auto-Assessment Engine führt kontinuierlich automatisierte Bewertungen durch – ohne manuellen Aufwand. Sie prüft Compliance, Datenqualität, Klassifizierungs-Coverage und Policy-Einhaltung und generiert Handlungsempfehlungen.

📋

Compliance Auto-Assessment Vollautomatisch

Prüft automatisch für jede Data Domain:

Classification Coverage: Sind alle Assets klassifiziert? Welche fehlen?
Policy Alignment: Sind alle relevanten Policies (HAFS V1.3, Data Retention, Access) zugewiesen?
DORA-Konformität: Sind ICT-Assets erfasst? Sind Lineage-Pfade dokumentiert?
DSGVO-Check: Sind PII-Felder markiert? Sind Aufbewahrungsfristen definiert?
Ownership: Hat jedes kritische Asset einen Data Owner und Steward?

Output: Compliance Score (0-100%), detaillierter Report mit Findings und priorisierten Maßnahmen, automatische Ticket-Erstellung für offene Punkte.

📊

Data Quality Auto-Assessment Prädiktiv

Geht über einfaches Rule-Checking hinaus:

Anomalie-Erkennung: ML-basierte Erkennung ungewöhnlicher Wertverteilungen und plötzlicher Änderungen
Trend-Vorhersage: Prädiktive Modelle sagen DQ-Score-Entwicklung 30 Tage voraus
Root-Cause-Analyse: KI identifiziert automatisch die wahrscheinliche Ursache für DQ-Violations
Auto-Rule-Generation: Analysiert Datenprofile und schlägt automatisch passende DQ-Regeln vor
Correlation: Erkennt Zusammenhänge zwischen DQ-Problemen über verschiedene Assets

🔒

Classification Auto-Assessment KI-Scanner

Vollautomatische Klassifizierung neuer und bestehender Assets:

Content-basierte Analyse: Scannt Spalteninhalte und erkennt Patterns (IBAN, E-Mail, Telefon, etc.)
Schema-basierte Analyse: Inferiert Klassifizierung aus Spaltennamen, Datentypen und Constraints
Kontext-basierte Analyse: Berücksichtigt Domain, benachbarte Tabellen und historische Klassifizierungen
Confidence Scoring: Jede Auto-Klassifizierung erhält einen Confidence-Score (0-100%)
Human-in-the-Loop: Bei Confidence <80% wird ein Data Steward zur Bestätigung eingeladen

governance.hafs.de/ai/assessments

87%

Gesamt-Score

96%

Classification

91%

DQ Score

78%

DORA Compliance

72%

Lineage Coverage

🤖 KI-generierte Empfehlungen (priorisiert)

⚠ KRITISCH: 42 Assets ohne Lineage in Fund Accounting

DORA Art. 11 erfordert dokumentierte Datenflüsse für alle kritischen ICT-Assets.

Auto-Fix

⚠ WARNUNG: 18 PII-Felder ohne Highly Confidential Label

KI hat E-Mail, Telefon und IBAN-Patterns erkannt – Confidence: 94%. Auto-Reklassifizierung möglich.

Auto-Classify

💡 EMPFEHLUNG: 23 DQ-Regeln automatisch vorgeschlagen

Basierend auf Profiling-Ergebnissen wurden Regeln für Completeness und Validity generiert.

Review

✓ OK: Data Retention Policies für 98% der Assets zugewiesen

2% Restlücke in IT & Infrastructure Domain. Automatische Zuweisung möglich.

Auto-Assign

Auto-Assessment Dashboard – KI-generierte Compliance-Scores, priorisierte Empfehlungen und One-Click Auto-Fixes

KI-Automatisierung im Detail

Auto-Enrichment Pipeline

Die KI-Pipeline verarbeitet jedes neue oder geänderte Asset automatisch:

┌────────────┐     ┌────────────┐     ┌────────────┐     ┌────────────┐     ┌────────────┐
│ 1. HARVEST  │ ──> │ 2. PROFILE  │ ──> │ 3. CLASSIFY │ ──> │ 4. ENRICH   │ ──> │ 5. VALIDATE │
│ Connector   │     │ DQ Profiling│     │ Auto-Label  │     │ KI-Beschr.  │     │ Human-in-   │
│ crawlt Meta │     │ Statistiken │     │ PII-Scan    │     │ Tag-Suggest │     │ the-Loop    │
└────────────┘     └────────────┘     └────────────┘     └────────────┘     └────────────┘
  Automatisch       Automatisch       KI (Claude)       KI (Claude)       Ab <80% Conf.

Predictive Analytics

📈

DQ-Trend-Vorhersage

ML-Modelle analysieren historische DQ-Scores und prognostizieren die Entwicklung der nächsten 30 Tage. Frühwarnung bei drohendem Absinken unter Schwellenwerte, bevor Violations entstehen.

🚨

Anomalie-Erkennung

Statistische Modelle erkennen ungewöhnliche Muster: plötzliche Sprung in Null-Werten, unerwartete Datentypänderungen, massenhaft fehlende Datensätze. Sofortige Alerts an Data Owner.

🔒

Risiko-Scoring für Zugriff

KI bewertet Zugriffsanfragen basierend auf: Rolle des Antragstellers, Sensitivität des Assets, bisheriges Zugriffsverhalten, Zeitpunkt der Anfrage. High-Risk-Requests erfordern zusätzliche Genehmigung.

🔄

Implicit Lineage Discovery

KI analysiert SQL-Queries, Stored Procedures und ETL-Job-Logs, um implizite Datenflüsse zu erkennen, die nicht explizit dokumentiert sind. Ergänzt den Lineage-Graph automatisch.

Intelligentes Stewardship

KI optimiert die Arbeit der Data Stewards durchgängig:

KI-Feature	Automatisierung	Manueller Aufwand
Aufgaben-Priorisierung	KI priorisiert Tasks nach Urgency, Impact und DORA-Relevanz	Entfällt
Smart Routing	Tasks werden automatisch dem am besten geeigneten Steward zugewiesen	Entfällt
Batch-Enrichment	KI generiert Beschreibungen für 100+ Assets gleichzeitig	Review statt Erstellen
Duplikat-Erkennung	KI erkennt doppelte Glossar-Einträge und ähnliche Assets	Merge-Entscheidung
Veraltungs-Check	KI erkennt veraltete Beschreibungen und Glossar-Einträge	Update bestätigen
Compliance-Reminder	Automatische Erinnerungen für ausstehende Reviews und Approvals	Entfällt

Technology Stack: KI-Komponenten

Komponente	Technologie	Einsatzbereich
LLM (Chatbot, Enrichment)	Claude API (Anthropic)	Chatbot, Auto-Beschreibungen, Policy-Interpretation, Compliance-Reports
RAG Framework	LangChain + Elasticsearch Vector	Kontextbezogene Antworten über Catalog, Glossar, Policies
PII Detection	Claude + Regex + spaCy	Erkennung personenbezogener Daten in Spalteninhalten
Anomalie-Erkennung	Python (scikit-learn, Prophet)	DQ-Trend-Vorhersage, Zugriffsanomalien, Daten-Anomalien
Auto-Classification	Claude + Custom ML Model	5-Stufen-Klassifizierung basierend auf Inhalt und Kontext
Embedding-Modell	Sentence Transformers	Semantische Suche, Asset-Similarity, Glossar-Matching
Workflow-Orchestrierung	Temporal.io	Auto-Assessment Pipelines, Batch-Processing, Scheduling

Kapitel 04

Metadata Management

Zentrale Verwaltung technischer und fachlicher Metadaten mit automatischem Harvesting und KI-gestützter Anreicherung.

Business Glossary / Data Dictionary

Das Business Glossary bildet die zentrale Terminologie der HAFS-Group ab. Jeder Fachbegriff enthält eine Definition, einen verantwortlichen Owner, einen Gültigkeitsstatus und Verlinkungen zu den technischen Datenobjekten im Data Catalog. So entsteht eine einheitliche Sprache über alle Bereiche und Entitäten hinweg.

Automatisches Metadata Harvesting

Die Plattform crawlt in konfigurierbaren Intervallen die Quellsysteme und extrahiert automatisch technische Metadaten: Schemas, Tabellen, Spalten, Datentypen, Constraints, Indizes und Beziehungen. Unterstützte Quellen im ersten Schritt:

Quellsystem	Connector-Typ	Erfasste Metadaten	Frequenz
Oracle Database	JDBC Crawler	Schemas, Tabellen, Spalten, Views, Procedures, Constraints	Täglich / On-Demand
Sage BOB	REST API	Kontenpläne, Buchungskreise, Stammdaten-Strukturen	Wöchentlich
Power BI	REST API	Reports, Datasets, Datenquellen, Refresh-Status	Täglich
Dateisystem/SharePoint	File Scanner	Dateien, Ordnerstruktur, Dateigrößen, Klassifizierung	Wöchentlich

Manuelles & KI-gestütztes Enrichment

Data Stewards reichern die technischen Metadaten mit fachlichem Kontext an: Beschreibungen, Klassifizierungen, Business-Owner-Zuordnungen und Glossar-Verlinkungen. Für Massenanreicherung steht ein Script-Interface und eine KI-gestützte Auto-Suggestion bereit, die auf Basis von Spaltennamen, Datentypen und Wertmustern automatisch Vorschläge für Beschreibungen und Klassifizierungen generiert.

🤖

KI-gestütztes Auto-Enrichment Vollautomatisch

Die KI analysiert Spaltennamen, Datentypen, Wertmuster und Beziehungen, um automatisch fachliche Beschreibungen zu generieren. Der Enrichment-Prozess läuft in drei Stufen:

Auto-Beschreibung: LLM generiert fachliche Beschreibungen für Spalten und Tabellen basierend auf Schema-Analyse (z.B. nav_value DECIMAL(18,6) → „Nettoinventarwert des Fonds in Basiswährung, berechnet zum Bewertungsstichtag“)
Auto-Glossar-Matching: Semantic Similarity erkennt, welche Spalten zu welchen Glossar-Begriffen gehören und schlägt Verlinkungen vor (Confidence > 85% = Auto-Link, < 85% = Vorschlag an Steward)
Schema-Similarity: Identifiziert ähnliche Tabellen/Spalten über verschiedene Quellsysteme hinweg (z.B. CLIENTS.email in Oracle und Kunden.E_Mail in Sage BOB)
Auto-Tagging: Automatische Erkennung und Zuweisung von Tags basierend auf Inhaltsanalyse (PII, Finanzdaten, DORA-relevant)

💬

Metadata Chatbot Natural Language

Data Stewards können per natürlichsprachlicher Eingabe Metadaten pflegen und abfragen:

„Setze die Beschreibung von NAV_DAILY.benchmark_return auf: Benchmark-Rendite des Vergleichsindex zum Bewertungsstichtag“
„Welche Tabellen im Fund Accounting Schema haben noch keine Owner-Zuweisung?“
„Zeige mir alle Spalten, die PII enthalten könnten aber noch nicht als PII markiert sind“
„Generiere Beschreibungen für alle Spalten der Tabelle POSITIONS“

governance.hafs.de/glossary

Alle (142) Approved (98) Draft (31) Deprecated (13)

NAV (Net Asset Value)

Der Nettoinventarwert eines Fonds, berechnet als Gesamtvermögen abzüglich Verbindlichkeiten, geteilt durch die Anzahl ausgegebener Anteile.

Approved

Owner: T. Schmidt·Domain: Fund Accounting·4 verknüpfte Assets

ISIN

International Securities Identification Number – eindeutige 12-stellige Kennnummer für Wertpapiere gemäß ISO 6166.

Approved

Owner: M. Weber·Domain: Securities·12 verknüpfte Assets

KYC Score

Know-Your-Customer Risikobewertung eines Investors basierend auf PEP-Status, Herkunftsland und Transaktionshistorie.

Draft

Owner: K. Müller·Domain: Compliance·2 verknüpfte Assets

Business Glossary – Fachbegriffe mit Definitionen, Owner, Status und verknüpften Datenobjekten

governance.hafs.de/metadata/enrichment

🤖 Auto-Enrichment für: FUND_SCHEMA.NAV_DAILY (24 Spalten)

nav_value DECIMAL(18,6)

🤖 KI-Vorschlag: „Nettoinventarwert des Fonds in Basiswährung, berechnet zum Bewertungsstichtag.“

96% Confidence ✓ ✗

Auto-Glossar: NAV Finanzdaten DORA-relevant

fund_currency VARCHAR(3)

🤖 KI-Vorschlag: „ISO 4217 Währungscode der Basiswährung des Fonds (z.B. EUR, USD, GBP).“

93% Confidence ✓ ✗

investor_name VARCHAR(255)

🤖 KI-Vorschlag: „Vollständiger Name des Investors/Anteilseigners.“ ⚠ PII erkannt → Empfehlung: Highly Confidential

78% Confidence ✓ ✗

🔒 PII DSGVO Kundendaten

🤖 24 Spalten analysiert · 18 auto-enriched (✓) · 4 Review benötigt · 2 PII erkannt

Alle akzeptieren

KI Auto-Enrichment – Automatische Beschreibungsgenerierung mit Confidence-Score, PII-Erkennung und One-Click-Approval

Kapitel 05

Data Catalog

Zentrales Verzeichnis aller Datenobjekte mit leistungsfähiger Suche und hierarchischer Domain-Struktur.

Asset Inventory

Der Data Catalog bildet das zentrale Verzeichnis aller Datenobjekte der HAFS-Group. Jedes Asset – ob Datenbanktabelle, Spalte, Report, Dashboard oder Datei – wird mit technischen und fachlichen Metadaten erfasst und durchsuchbar gemacht. Der Catalog dient als Single Point of Truth für alle datenbezogenen Informationen.

Erfasste Asset-Typen

Asset-Typ	Quelle	Erfasste Attribute
Datenbanktabellen	Oracle, PostgreSQL	Schema, Spalten, Datentypen, Constraints, Zeilen-Count, Größe
Views & Procedures	Oracle	Definition, Abhängigkeiten, Parameter
Reports & Dashboards	Power BI	Titel, Datasets, Datenquellen, Refresh-Status, Nutzungsstatistik
Dateien	SharePoint, Netzlaufwerke	Pfad, Typ, Größe, Klassifizierung, Ersteller
Buchhaltungsobjekte	Sage BOB	Kontenpläne, Buchungskreise, Mandanten-Struktur
API Endpoints	Manuell / Discovery	URL, Methoden, Parameter, Datenformate

Search & Discovery

Die Suche kombiniert Elasticsearch-basierte Volltextsuche mit facettierter Filterung. Nutzer können nach Asset-Name, Beschreibung, Tags, Owner, Domain, Klassifizierung und Datentyp filtern. Eine semantische Suche ermöglicht zusätzlich die Suche nach fachlichen Konzepten („Kundendaten“, „NAV-Berechnung“).

🔍

Semantische Suche & KI-Discovery NLP-Engine

Die KI-gestützte Suche geht weit über einfache Volltextsuche hinaus:

Semantische Suche: Sentence Transformers erzeugen Embeddings für alle Assets. Suche nach „Kundendaten“ findet auch CLIENTS, INVESTORS und KYC_DATA ohne exakten Keyword-Match
Natural Language Query: Nutzer können in natürlicher Sprache suchen: „Welche Tabellen enthalten NAV-Berechnungsdaten und werden täglich aktualisiert?“
Smart Recommendations: „Nutzer die dieses Asset angesehen haben, schauten auch...“ basierend auf Nutzungs-Patterns und Lineage-Nachbarschaft
Auto-Domain-Zuweisung: KI schlägt für neue Assets automatisch die passende Data Domain vor basierend auf Schema-Kontext und Ähnlichkeitsanalyse

💡

Catalog Chatbot Conversational

Ein in den Catalog integrierter Chatbot beantwortet Fragen zu Datenobjekten in natürlicher Sprache:

„Was ist die Tabelle NAV_DAILY und wofür wird sie genutzt?“ → Liefert Beschreibung, Owner, Lineage-Kontext und DQ-Score
„Wer ist der richtige Ansprechpartner für Fondsdaten?“ → Leitet zum Data Owner der Domain Fund Accounting
„Gibt es eine API für Wechselkursdaten?“ → Durchsucht APIs und Tabellen semantisch und zeigt relevante Assets

Data Domain Management

Der Catalog wird in hierarchische Data Domains strukturiert. Jede Domain kann Unter-Domains enthalten. Zugriffsrechte werden über die Hierarchie vererbt: Wer Zugriff auf eine übergeordnete Domain hat, erhält automatisch Zugriff auf alle Unter-Domains.

HAFS-Group (Root Domain)
├── Fund Accounting
│   ├── NAV Calculation
│   ├── Transfer Agency
│   └── Fund Reporting
├── Securities
│   ├── Trade Processing
│   └── Settlement
├── Compliance & Risk
│   ├── KYC / AML
│   ├── Regulatory Reporting
│   └── Risk Management
├── Finance & Accounting
│   ├── General Ledger (Sage BOB)
│   └── Accounts Payable / Receivable
└── IT & Infrastructure
    ├── System Metadata
    └── Access Logs

governance.hafs.de/catalog

Alle Assets (1.247) Tabellen (634) Reports (89) Dateien (412) APIs (112)

3 Ergebnisse für „NAV Berechnung“ in Domain: Fund Accounting

🗃

FUND_SCHEMA.NAV_DAILY

Oracle · Fund Accounting · 24 Spalten · 1.2M Zeilen

Confidential DQ: 94%

Tägliche NAV-Berechnungsergebnisse aller verwalteten Fonds inkl. Anteilswert, Fondsvermögen und Benchmarkvergleich.

Owner: T. Schmidt PII: Nein Lineage: 3 Upstream

📈

NAV Daily Report

Power BI · Fund Reporting · 6 Datasets

Confidential

Dashboard mit täglichen NAV-Werten, Performance-Vergleich und Abweichungsanalyse für das Management.

🗃

FUND_SCHEMA.NAV_CALC_PARAMS

Oracle · Fund Accounting · 18 Spalten · 340 Zeilen

Internal DQ: 98%

Konfigurationsparameter für NAV-Berechnung: Bewertungsmethoden, Cut-Off-Zeiten, Rundungsregeln.

Data Catalog – Volltextsuche mit facettierten Filtern, Asset-Details und Qualitätsindikatoren

governance.hafs.de/catalog/FUND_SCHEMA.NAV_DAILY

🔒 Confidential DQ: 94% KI-Enriched DORA-relevant Finanzdaten

Asset-Informationen

Typ:Oracle Tabelle

Schema:FUND_SCHEMA

Spalten:24

Zeilen:1.247.832

Größe:2.4 GB

Letztes Update:Heute 06:47 UTC

Verantwortlichkeiten

Data Owner:T. Schmidt

Data Steward:K. Müller

Domain:Fund Accounting > NAV Calculation

Glossar-Terms:NAV, Fonds, Anteilswert

Data Contract:NAV Daily Contract v2.1 ✓

Upstream:3 Quellen

Schema (Top 6 von 24 Spalten)

SpalteDatentypKlassif.PIIDQ

fund_idNUMBER(10)Internal❌100%

calc_dateDATEInternal❌100%

nav_valueDECIMAL(18,6)Confid.❌97.2%

investor_nameVARCHAR(255)Highly C.🔒 PII99.8%

fund_currencyVARCHAR(3)Internal❌100%

benchmark_returnDECIMAL(10,6)Confid.❌84.1%

Asset Detail View – Vollständige Übersicht eines Datenobjekts mit Schema, Klassifizierung, DQ-Score und Verantwortlichkeiten

governance.hafs.de/catalog/search

🤖

🤖 KI-Analyse: Semantische Suche nach „Kundendaten“ + Filter: DSGVO-Tag · 5 relevante Assets gefunden

CLIENTS · Oracle · Compliance & Risk

Kundenstammdaten inkl. Name, Adresse, Geburtsdatum, Steuernummer, KYC-Status

Highly Conf.PII

🤖 Relevanz: 98% · 14 PII-Felder erkannt · DSGVO Art. 6 & 15 relevant

INVESTORS · Oracle · Fund Accounting

Investorendaten für Fondsanteile inkl. Identifikation und Kontaktdaten

Highly Conf.PII

🤖 Relevanz: 95% · 8 PII-Felder · Cross-Referenz zu CLIENTS über investor_id

KYC_DATA · Oracle · Compliance & Risk

Know-Your-Customer Daten: PEP-Screening, Risikobewertung, Sanktionsprüfung

Highly Conf.

🤖 Relevanz: 87% · Indirekte Kundendaten über Risikobewertung

Semantische KI-Suche – Natürlichsprachliche Abfrage findet relevante Assets über Bedeutung, nicht nur Keywords

Kapitel 06

Data Lineage

End-to-End Nachverfolgung von Datenflüssen – von der Quelle bis zum Report für Impact-Analysen und Compliance.

Technische Lineage Must Have

Die technische Lineage erfasst automatisch den vollständigen Datenfluss: Quelltabelle → ETL/Transformation → Zieltabelle → Report/Dashboard. Die Lineage wird als gerichteter Graph in Neo4j gespeichert und ermöglicht sowohl Rückwärts-Analyse (Woher kommen die Daten?) als auch Vorwärts-Analyse (Wohin fließen die Daten?).

Lineage-Erfassung: Die Plattform extrahiert Lineage-Informationen aus SQL-Queries (Oracle), ETL-Job-Definitionen, Power BI Dataset-Konfigurationen und manuellen Annotationen. KI-Unterstützung hilft bei der Erkennung impliziter Datenflüsse.

Beispiel: NAV-Berechnungs-Lineage

  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
  │  POSITIONS  │    │  ETL: NAV    │    │  NAV_DAILY  │    │  NAV Daily  │
  │  (Oracle)   │───>│  Calculation │───>│  (Oracle)   │───>│  Report     │
  └──────────────┘    └──────┬───────┘    └──────────────┘    └──────────────┘
  ┌──────────────┐    │                       (Power BI)
  │  PRICES     │    │
  │  (Oracle)   │───┘
  └──────────────┘
  ┌──────────────┐    │
  │  FX_RATES   │    │
  │  (Oracle)   │───┘
  └──────────────┘

Impact Analysis Should Have

Die Impact Analysis beantwortet die Frage: „Was passiert, wenn sich Tabelle X ändert?“ Sie traversiert den Lineage-Graph vorwärts und zeigt alle betroffenen Transformationen, Zieltabellen und Reports. Dies ist besonders kritisch für Schema-Änderungen an Oracle-Tabellen, die nachgelagerte NAV-Berechnungen und Regulatory Reports beeinflussen können.

Impact-Analyse Anwendungsfälle

Szenario	Analyse-Richtung	Ergebnis
Spalte in Oracle-Tabelle wird umbenannt	Vorwärts	Betroffene ETL-Jobs, Views, Reports, Downstream-Tabellen
Power BI Report zeigt falsche Daten	Rückwärts	Datenquellen, Transformationen, letzte Änderungen identifizieren
Neue DSGVO-Anforderung für ein Datenfeld	Vorwärts	Alle Orte, an denen dieses Feld gespeichert/verarbeitet wird
Datenquelle wird abgelöst	Vorwärts	Alle abhängigen Systeme und Prozesse

🔄

Implicit Lineage Discovery SQL-Analyse

Die KI erkennt automatisch Datenflüsse, die nicht explizit dokumentiert sind:

SQL-Parsing: Automatische Analyse aller SQL-Queries, Stored Procedures und Views in Oracle. Erkennung von JOINs, Subqueries und CTEs zur Lineage-Extraktion
ETL-Log-Analyse: KI analysiert ETL-Job-Logs und erkennt Datenflüsse aus Laufzeit-Informationen, auch wenn keine formale Lineage-Definition existiert
Power BI DAX-Analyse: Automatisches Parsen von DAX-Formeln in Power BI Datasets zur Erkennung von Report-zu-Datenquelle-Beziehungen
Spalten-Level-Lineage: KI-gestützte Erkennung welche Quellspalten in welche Zielspalten fließen, inkl. Transformationslogik

🚨

Intelligente Impact-Vorhersage Prädiktiv

Die KI geht über statische Impact-Analyse hinaus und prognostiziert potenzielle Auswirkungen:

Change Risk Score: Automatische Bewertung des Risikos einer Schema-Änderung (0-100) basierend auf Anzahl nachgelagerter Assets, deren Klassifizierung und regulatorischer Relevanz
Proaktive Warnungen: „Die geplante Änderung an POSITIONS betrifft 3 Highly Confidential Downstream-Assets und 2 DORA-relevante Reports. Empfehlung: Extended Review“
Auto-Business-Lineage: KI generiert automatisch die Business-Lineage-Ansicht aus der technischen Lineage durch Aggregation und Benennung auf Geschäftsprozess-Ebene

Business Lineage Could Have

Die Business Lineage ist eine vereinfachte Darstellung für nicht-technische Stakeholder. Statt einzelner Tabellen und Spalten zeigt sie den Datenfluss auf Geschäftsprozess-Ebene: „Welche Geschäftsdaten fließen in diesen Management-Report?“ Die Business Lineage wird aus der technischen Lineage abgeleitet und durch manuelle Annotationen ergänzt.

governance.hafs.de/lineage/NAV_DAILY

SOURCE

POSITIONS

Oracle · 18 cols

SOURCE

PRICES

Oracle · 12 cols

SOURCE

FX_RATES

Oracle · 8 cols

➔

TRANSFORMATION

ETL: NAV Calc

SP_CALC_NAV_DAILY

Schedule: Täglich 06:00

➔

TARGET

NAV_DAILY

Oracle · 24 cols

🔒 Confidential

➔

REPORT

NAV Daily

Power BI

REPORT

Regulatory Filing

CSSF Report

Data Lineage – Visualisierung des Datenflusses von Quellen über Transformationen zu Reports

Kapitel 07

Data Classification

Umsetzung der HAFS Information Classification Policy V1.3 mit 5 Klassifizierungsstufen und automatischer PII-Erkennung.

Referenz: Dieses Modul setzt die „HAFS Group Information Classification Policy (incl. Data Handling)“ V1.3, erstellt von Matthias Kraft (28.01.2026), technisch um. Die Policy gilt für alle drei Entitäten: HAFS, HAAS und HALFI.

Klassifizierungs-Schema (5 Stufen)

Gemäß der HAFS Classification Policy müssen alle Informationen einer von fünf Klassifizierungsstufen zugeordnet werden. Die Plattform bildet diese Stufen technisch ab und verknüpft sie mit konkreten Handling-Regeln.

⚪

1. Non-business Keine Kontrollen

Informationen, die für den privaten Gebrauch gesammelt oder erstellt wurden und keinen Bezug zum Geschäft der HAFS-Group haben. Keine Mindestanforderungen an die Handhabung.

🟢

2. Public Minimal

Bereits für die Öffentlichkeit freigegebene Informationen. Vor Veröffentlichung muss eine Management-Freigabe erfolgen. Keine besonderen Schutzmaßnahmen erforderlich.

🔵

3. Internal Basis-Schutz

Informationen, die allen HAFS-Group Mitarbeitern zugänglich sind, aber nicht nach außen gelangen dürfen. Unbefugte Offenlegung würde zu minimalem bis geringem Risiko führen. Beispiele: Interne Prozessdokumentationen, allgemeine Richtlinien.

🟠

4. Confidential Erhöhter Schutz

Informationen, die nicht für den allgemeinen internen Zugriff bestimmt sind und aufgrund ihrer Sensitivität erhöhten Schutz erfordern. Zugriff nur für Personen mit legitimem Need-to-Know. Unbefugte Offenlegung würde zu mittlerem Risiko führen. Beispiele: Kundendaten, Vertragsinformationen, NAV-Daten.

🔴

5. Highly Confidential Höchster Schutz

Sensible Informationen, die das höchste Schutzniveau erfordern. Zugriff nur für eine spezifisch definierte Gruppe autorisierter Personen auf strikter Need-to-Know-Basis. Unbefugte Offenlegung würde zu hohem Risiko und erheblichem Schaden führen. Beispiele: Passwörter, Kryptoschlüssel, M&A-Daten, PII.

Data Handling Matrix

Die folgende Matrix definiert die Handling-Regeln pro Klassifizierungsstufe gemäß der HAFS Policy:

Regel	Internal	Confidential	Highly Confidential
Teilen intern	✓ Frei	✓ Need-to-Know	⚠ Nur autorisiert
Teilen extern	❌ Nicht erlaubt	❌ Nur mit NDA	❌ Nur mit Management-Freigabe + NDA
E-Mail intern	✓ Erlaubt	✓ Verschlüsselt	⚠ Verschlüsselt + DLP
E-Mail extern	❌	❌ Nur verschlüsselt	❌ Verboten
Speicherung	Genehmigte Systeme	Genehmigte Systeme, zugriffsbeschränkt	Verschlüsselt, strikt zugriffsbeschränkt
Drucken	✓ Erlaubt	⚠ Kontrollierter Bereich	❌ Nur Secure Print
Verschlüsselung at Rest	Optional	Empfohlen	✓ Pflicht
Verschlüsselung in Transit	✓ TLS	✓ TLS	✓ TLS + E2E
Löschung	Standard	Sichere Löschung	Sichere Löschung + Nachweis

PII/GDPR-Kennzeichnung

Die Plattform erkennt personenbezogene Daten (PII) automatisch durch Pattern-Matching und KI-basierte Analyse. Erkannte PII-Felder werden automatisch mit einem GDPR-Tag versehen und erhalten mindestens die Klassifizierung „Confidential“. Die Erkennung umfasst: Namen, E-Mail-Adressen, Telefonnummern, Adressen, IBAN, Geburtsdaten, Steuernummern und nationale Identifikationsnummern.

Tagging-System

Zusätzlich zur Klassifizierung können Datenobjekte mit frei definierbaren Tags versehen werden. Vorkonfigurierte Tags umfassen: Gold/Silver/Bronze (Datenqualitätsstufe), DORA-relevant, CSSF-relevant, DSGVO-relevant, PII, Finanzdaten, Kundendaten.

🔒

KI-Auto-Classification Confidence Scoring

Die KI klassifiziert Datenobjekte automatisch gemäß der HAFS Policy V1.3:

Content-based Classification: spaCy und Custom NER-Modelle scannen Dateninhalte und erkennen PII (Namen, IBAN, Steuernummern), Finanzdaten (NAV, Kurse) und vertrauliche Geschäftsdaten
Confidence Scoring: Jede Auto-Classification enthält einen Confidence-Score (0-100%). Ab 90% wird automatisch klassifiziert, 70-90% als Vorschlag an den Data Steward, <70% wird zur manuellen Prüfung markiert
Context-aware Upclassification: KI erkennt, wenn Daten in Kombination sensibler sind als einzeln (z.B. Name + Geburtsdatum = PII → Highly Confidential, auch wenn einzelne Felder nur Internal wären)
Drift Detection: Kontinuierliche Überwachung ob sich Dateninhalte so verändern, dass eine Reklassifizierung notwendig wird (z.B. neue PII-Felder in einem bisher unkritischen Dataset)

📈

PII-Discovery-Engine Deep Scan

Erweiterte PII-Erkennung über einfache Regex-Patterns hinaus:

Multi-Language NER: Erkennung von PII in Deutsch, Englisch und Französisch (HAFS, HAAS, HALFI)
Fuzzy PII Detection: Erkennung verschleierter PII (z.B. „M. Kraft“ als potentieller Personenname, auch wenn nicht als Vor-/Nachname-Feld markiert)
Cross-System PII-Mapping: Identifizierung, wo dieselbe Person über verschiedene Systeme verteilt gespeichert ist (DSGVO Art. 15 Auskunftsrecht)
Automatischer DSGVO-Report: Auf Knopfdruck: „Wo sind die Daten von Person X gespeichert?“ → vollständiges Data Subject Access Request (DSAR) Ergebnis

governance.hafs.de/classification

Klassifizierungs-Übersicht

Non-business

Public

487

Internal

589

Confidential

103

Highly Conf.

Coverage nach Domain

Fund Accounting98%

Securities95%

Compliance & Risk87%

Finance (Sage BOB)72%

IT & Infrastructure54%

Letzte Auto-Scan Ergebnisse

12 neue PII-Felder erkannt

vor 2 Stunden · FUND_SCHEMA

34 Assets ohne Klassifizierung

vor 2 Stunden · Sage BOB Import

Auto-Classification: 156 Assets aktualisiert

vor 4 Stunden · KI-basiert

Neuer Scan geplant

Morgen 03:00 UTC · Vollständig

Classification Dashboard – Übersicht der Klassifizierungsstufen, Domain-Coverage und Auto-Scan Ergebnisse

Kapitel 08

Data Quality

Kontinuierliche Überwachung der Datenqualität mit regelbasierten Prüfungen, Profiling und automatisiertem Alerting.

Qualitätsdimensionen

Die Plattform misst Datenqualität anhand von sechs standardisierten Dimensionen, die auf jedes Datenobjekt angewendet werden können:

✓

Vollständigkeit

Sind alle erwarteten Werte vorhanden? Anteil Null/Leer-Werte.

🔓

Eindeutigkeit

Sind Datensätze frei von Duplikaten? Unique-Constraint-Prüfung.

✅

Validität

Entsprechen Werte dem definierten Format und Wertebereich?

🔗

Konsistenz

Sind Daten über verschiedene Systeme hinweg widerspruchsfrei?

⏰

Aktualität

Wie aktuell sind die Daten? Alter seit letztem Update.

🎯

Genauigkeit

Bilden die Daten die Realität korrekt ab? Referenzvergleich.

DQ Rule Definition

Qualitätsregeln werden auf Feld- und Tabellenebene definiert. Jede Regel enthält eine Dimension, einen Schwellenwert und eine Aktion bei Verletzung. Beispiele:

Regel	Dimension	Asset	Bedingung	Schwellenwert
NAV darf nicht NULL sein	Vollständigkeit	NAV_DAILY.nav_value	NOT NULL	100%
ISIN muss gültiges Format haben	Validität	SECURITIES.isin	Regex: [A-Z]{2}[0-9A-Z]{10}	100%
Keine doppelten Fonds-IDs	Eindeutigkeit	FUNDS.fund_id	UNIQUE	100%
NAV-Daten max. 24h alt	Aktualität	NAV_DAILY.calc_date	Age < 24h	>95%
Summe Anteile = Gesamtfonds	Konsistenz	NAV_DAILY vs. POSITIONS	Cross-Check	100%

DQ Profiling

Das automatische Profiling analysiert die Ist-Qualität jedes Datenobjekts: Null-Wert-Anteil, Werteverteilungen, Min/Max/Avg, Datentyp-Konsistenz, Duplikate und Ausreißer. Die Ergebnisse werden historisch gespeichert, um Trends zu erkennen und Verschlechterungen frühzeitig zu identifizieren.

DQ Monitoring & Alerting

Regelmäßige Prüfläufe (konfigurierbar: stündlich, täglich, wöchentlich) führen die definierten DQ-Rules automatisch aus. Bei Verletzungen werden Alerts ausgelöst: E-Mail an den Data Owner, Ticket im Stewardship-Workflow oder Eskalation an den Data Steward.

✅

Auto-Rule-Generation Self-Learning

Die KI lernt automatisch DQ-Regeln aus den Daten:

Statistical Profiling: Automatische Erkennung von Normalwerten und Ausreißern. Generiert daraus Regeln: „NAV_DAILY.nav_value liegt typischerweise zwischen 50 und 500 – Warnung bei Abweichung >20%“
Pattern Learning: KI erkennt Muster in Datenänderungen und erstellt zeitbasierte Regeln: „NAV-Daten werden werktags zwischen 06:00-08:00 UTC aktualisiert – Alert wenn 09:00 ohne Update“
Cross-System Consistency: Automatische Erkennung von Inkonsistenzen zwischen Oracle und Sage BOB (z.B. Kundennamen unterschiedlich geschrieben)

📈

Prädiktive Qualitätsanalyse Prädiktiv

Die KI erkennt Qualitätsprobleme bevor sie kritisch werden:

DQ-Trend-Vorhersage: Prophet/ARIMA-Modelle prognostizieren den DQ-Score für die nächsten 30 Tage: „Warnung: DQ-Score für Fund Accounting wird voraussichtlich unter 90% fallen“
Root-Cause-Analyse: Bei DQ-Violations identifiziert die KI automatisch die wahrscheinliche Ursache durch Lineage-Analyse: „NULL-Werte in NAV_DAILY.nav_value korrelieren mit fehlenden Daten in PRICES (upstream)“
Anomalie-Erkennung: Isolation Forest erkennt ungewöhnliche Datenveränderungen: „Unerwarteter Anstieg der Zeilen-Anzahl in CLIENTS um 300% – mögliches Duplikat-Problem“
Auto-Remediation Vorschläge: KI schlägt Behebungsmaßnahmen vor: „12 Duplikate in CLIENTS erkannt. Vorschlag: Merge-Kandidaten basierend auf Name+Geburtsdatum-Ähnlichkeit“

governance.hafs.de/quality

91.4%

Gesamt DQ-Score

▲ +1.2% vs. Vormonat

1.247

Geprüfte Assets

Aktive Violations

342

Aktive Regeln

DQ-Score nach Domain

Fund Accounting94.2%

Securities92.8%

Compliance & Risk90.1%

Finance (Sage BOB)85.3%

IT & Infrastructure88.7%

Aktuelle Violations

RegelAssetDimensionStatus

NAV NULL-Werte erkanntNAV_DAILYVollständigkeitKritisch

ISIN Format-Fehler (3 Datensätze)SECURITIESValiditätWarnung

Duplikate in KundenstammCLIENTSEindeutigkeitWarnung

Data Quality Dashboard – DQ-Score pro Domain, Regel-Violations und Trend-Übersicht

governance.hafs.de/quality/predictive

📈 DQ-Trend-Vorhersage (nächste 30 Tage)

🤖 Warnung: DQ-Score für Fund Accounting wird voraussichtlich von 94.2% auf 89.1% fallen (unter 90%-Schwellenwert). Ursache: Steigende NULL-Rate in NAV_DAILY seit 5 Tagen.

DQ-Score Trend & Prognose – Fund Accounting

94.8

-4W-3W-2W-1WJetzt+1W+2W+3W+4W

90% Schwellenwert

🤖 KI Root-Cause-Analyse

Problem: NULL-Werte in NAV_DAILY.nav_value steigen seit 5 Tagen (0.3% → 2.8%)
Ursache: Upstream-Tabelle PRICES liefert unvollständige Kursdaten für 3 Fonds (LU0123, LU0456, LU0789)
Empfehlung: Data Owner Securities (J. Weber) kontaktieren – SWIFT-Datenlieferant prüfen

🤖 Auto-Ticket erstellen Lineage anzeigen

Prädiktive DQ-Analyse – KI-Trend-Vorhersage mit Schwellenwert-Warnung und automatischer Root-Cause-Analyse über Lineage

Kapitel 09

Ownership & Stewardship

Klare Verantwortlichkeiten für Datenobjekte mit Rollen-Modell, Aufgaben-Management und Approval-Workflows.

Rollen-Modell Must Have

Jedes Datenobjekt im Catalog wird mit definierten Verantwortlichkeiten versehen. Die Rollen werden direkt am Asset hinterlegt und sind über die Plattform einsehbar.

Rolle	Verantwortung	Typische Person	Rechte in der Plattform
Data Owner	Geschäftliche Verantwortung für Datenobjekte. Entscheidet über Klassifizierung, Zugriff und Nutzung.	Abteilungsleiter, Team Lead	Klassifizierung ändern, Zugriff genehmigen, Policies zuweisen
Data Steward	Operative Pflege der Metadaten und Datenqualität. Setzt die Vorgaben des Data Owners um.	Fachexperte, Analyst	Metadaten bearbeiten, DQ-Regeln definieren, Glossar pflegen
Data Custodian	Technische Verwaltung der Datenspeicherung und -sicherheit.	DBA, IT Operations	Connector-Konfiguration, Backup, technische Metadaten
Data Consumer	Nutzt Daten für Berichte, Analysen oder Geschäftsprozesse.	Mitarbeiter, Analyst, Manager	Lesen, Suchen, Lineage einsehen

RACI-Matrix

Aktivität	Owner	Steward	Custodian	Consumer
Klassifizierung festlegen	A	R	I	I
Metadaten pflegen	A	R	C	I
DQ-Regeln definieren	A	R	C	I
Zugriff genehmigen	R	C	I	I
Technische Infrastruktur	I	I	R	–
Daten nutzen/analysieren	I	I	–	R

R = Responsible, A = Accountable, C = Consulted, I = Informed

Aufgaben- und Workflow-Management Should Have

Data Stewards erhalten automatisch Aufgaben bei DQ-Violations, fehlenden Metadaten oder ausstehenden Klassifizierungen. Aufgaben werden im Kontext des Datenobjekts angezeigt und können mit Fristen, Prioritäten und Kommentaren versehen werden.

Approval Workflows Should Have

Änderungen an kritischen Datenobjekten (Highly Confidential, DORA-relevant) erfordern eine formalisierte Freigabe. Der Workflow: Antragsteller → Data Steward (Review) → Data Owner (Genehmigung). Für Highly Confidential Assets: zusätzliche Genehmigung durch Compliance.

👥

Intelligentes Aufgaben-Routing Smart Routing

Die KI optimiert die Zuweisung und Priorisierung von Stewardship-Aufgaben:

Smart Task Routing: KI bestimmt automatisch den richtigen Steward basierend auf Domain-Expertise, aktuellem Workload und historischer Performance: „DQ-Issue in NAV_DAILY → T. Schmidt (Fund Accounting Steward, Auslastung: 62%, Ø Lösungszeit: 2h)“
Prioritäts-Scoring: Automatische Berechnung der Aufgaben-Priorität basierend auf: Klassifizierung des betroffenen Assets, Anzahl nachgelagerter Consumer, regulatorische Relevanz und SLA-Deadline
Workload Balancing: Erkennt Überlastung einzelner Stewards und schlägt Umverteilung vor: „T. Schmidt hat 14 offene Tasks. Empfehlung: 5 Tasks an K. Müller (Fund Accounting, Auslastung: 35%) umleiten“
Deadline-Vorhersage: KI prognostiziert voraussichtliche Lösungszeit basierend auf ähnlichen historischen Aufgaben

💬

Stewardship-Assistent Copilot

Ein KI-Copilot unterstützt Data Stewards bei ihren täglichen Aufgaben:

Daily Briefing: Automatische Zusammenfassung: „Heute: 3 neue DQ-Violations, 5 Metadaten-Reviews ausstehend, 1 Approval wartet seit 48h (Eskalation empfohlen)“
Lösungsvorschläge: Bei DQ-Violations schlägt der Assistent konkrete Behebungsschritte vor: „NULL-Werte in ISIN-Feld → Datenquelle SWIFT-Import prüfen, letzte 3 Importe zeigen Missing-Rate von 2%“
Auto-Documentation: Generiert automatisch Zusammenfassungen abgeschlossener Tasks für den Audit Trail

governance.hafs.de/stewardship

🤖 KI Daily Briefing – 23. Februar 2026

Guten Morgen, T. Schmidt. Heute: 3 neue DQ-Violations in Fund Accounting (1 kritisch), 5 Metadaten-Reviews ausstehend, 1 Approval wartet seit 48h (Eskalation empfohlen). Ihre Auslastung: 72%. Empfehlung: Kritische NAV-Violation zuerst bearbeiten.

Offene Tasks

DQ-Violations

Diese Woche erledigt

72%

Auslastung

PrioAufgabeAssetDeadlineKI-Vorschlag

P1DQ-Violation: NAV NULL-WerteNAV_DAILYHeute🤖 Upstream PRICES prüfen

P2Metadaten-Review: 5 neue SpaltenPOSITIONSMorgen🤖 Auto-Enriched, prüfen

P2Approval ausstehend seit 48hFX_RATES SchemaÜberfällig🤖 Eskalation an Owner

P3Klassifizierung prüfen: 4 AssetsSage BOB ImportDiese Woche🤖 2 auto-klassifiziert

Stewardship Dashboard – KI-Daily-Briefing, priorisierte Aufgaben mit Lösungsvorschlägen und Auslastungsübersicht

Kapitel 10

Compliance & Audit

Lückenlose Protokollierung, Policy Management und regulatorische Compliance für DORA, CSSF und DSGVO.

Audit Trail / Change Log Must Have

Jede Änderung an Metadaten, Klassifizierungen, Policies, Rollen und DQ-Regeln wird vollständig und unveränderlich protokolliert. Der Audit Trail erfasst: Zeitstempel, Benutzer, betroffenes Objekt, vorherigen Wert, neuen Wert und die Art der Änderung. Die Daten werden in einer append-only Struktur gespeichert und können nicht nachträglich geändert oder gelöscht werden.

Erfasste Ereignisse

Ereignis-Kategorie	Beispiele	Aufbewahrung
Metadaten-Änderungen	Beschreibung geändert, Tag hinzugefügt, Owner gewechselt	7 Jahre
Klassifizierungs-Änderungen	Hochstufung auf Confidential, PII-Tag gesetzt	7 Jahre
Policy-Änderungen	Neue Policy zugewiesen, Regel geändert	10 Jahre
Zugriffs-Ereignisse	Login, Asset-Zugriff, Export, Download	3 Jahre
DQ-Ereignisse	Regel verletzt, Score geändert, Alert ausgelöst	5 Jahre
Workflow-Ereignisse	Approval erteilt, Task abgeschlossen, Eskalation	7 Jahre

Policy Management Must Have

Datenpolicies werden zentral verwaltet und mit betroffenen Datenobjekten verknüpft. Jede Policy enthält: Titel, Beschreibung, Gültigkeitsbereich, verknüpfte Assets, verantwortliche Person und Prüfzyklus. Die Plattform trackt die Einhaltung automatisch und generiert Compliance-Reports.

Vorkonfigurierte Policies

Information Classification Policy

HAFS Policy V1.3 – 5-stufige Klassifizierung mit Data Handling Regeln. Gilt für alle Entitäten.

HAFS V1.3Alle Assets

Data Retention Policy

Aufbewahrungsfristen pro Datentyp und Klassifizierung. Automatische Löschhinweise bei Ablauf.

DSGVODORA

Data Access Policy

Zugriffsregeln basierend auf Klassifizierung und Rolle. Need-to-Know-Prinzip für Confidential+.

RBACCSSF

📋

Auto-Compliance-Reporting Vollautomatisch

Die KI generiert automatisch regulatorische Compliance-Reports:

DORA Compliance Report: Automatische Bewertung der DORA-Konformität aller Datenobjekte mit Gap-Analyse: „92% der DORA-relevanten Assets haben vollständige Klassifizierung, 8% (12 Assets) benötigen Nacharbeit“
CSSF 20/750 Report: Automatischer Nachweis der Einhaltung der CSSF Circular-Anforderungen für die luxemburgische Aufsicht
DSGVO Art. 30 Verzeichnis: Automatische Generierung des Verarbeitungsverzeichnisses aus Metadaten, Klassifizierungen und Lineage-Informationen
Executive Summary: Monatlicher KI-generierter Compliance-Bericht für das Management mit Trend-Analyse und Handlungsempfehlungen

🕵

Audit-Anomalie-Erkennung Security AI

KI-basierte Überwachung des Audit Trails auf verdächtige Muster:

Unusual Access Patterns: „Benutzer X hat in den letzten 24h auf 47 Highly Confidential Assets zugegriffen – 340% über Normalwert. Investigation empfohlen“
Privilege Escalation Detection: Erkennung ungewöhnlicher Rechte-Änderungen: „3 Benutzer wurden heute zu Data Owner hochgestuft – entspricht nicht dem normalen Pattern“
Compliance Drift Alert: Frühwarnung wenn Compliance-Werte sinken: „Classification Coverage in Finance-Domain ist in 2 Wochen von 94% auf 78% gesunken“
Auto-Investigation: Bei Anomalien erstellt die KI automatisch einen Investigation-Report mit Timeline, betroffenen Assets und empfohlenen nächsten Schritten

governance.hafs.de/audit

Alle Ereignisse Klassifizierung Metadaten Zugriff Policies

Klassifizierung geändert: Internal → Highly Confidential

Asset: CLIENTS.tax_id · Benutzer: M. Kraft · Grund: PII-Feld erkannt

23.02.2026, 14:32 UTC

Metadaten aktualisiert: Beschreibung hinzugefügt

Asset: NAV_DAILY.benchmark_return · Benutzer: T. Schmidt

23.02.2026, 11:15 UTC

Approval erteilt: Schema-Änderung genehmigt

Asset: FUND_SCHEMA.POSITIONS · Genehmiger: J. Weber · Workflow #WF-0042

23.02.2026, 09:44 UTC

Policy zugewiesen: Data Retention Policy

Domain: Fund Accounting (42 Assets) · Benutzer: Admin

22.02.2026, 16:20 UTC

Audit Trail – Lückenlose Protokollierung aller Änderungen mit Benutzer, Zeitstempel und Kontext

Kapitel 11

Data Loss Prevention

Schutz vor unkontrolliertem Datenabfluss – abgestimmt auf die HAFS Classification Policy und die Anforderungen des CISO.

Hinweis: Data Loss Prevention ist kein klassisches Data-Governance-Thema, sondern gehört zur Information Security. Das Feature ist jedoch in Microsoft Purview enthalten und wurde vom CISO (Matthias Kraft) als wichtige Anforderung eingestuft. Die Integration in die Data Governance Platform ermöglicht eine durchgängige Enforcement-Kette: Klassifizierung → Handling-Regeln → DLP-Enforcement.

DLP-Konzept

DLP verhindert, dass sensible oder klassifizierte Daten das Unternehmen unkontrolliert verlassen oder an unbefugte Personen weitergegeben werden. Die DLP-Regeln basieren direkt auf der Klassifizierung der Datenobjekte und den Handling-Vorgaben der HAFS Classification Policy.

DLP-Regeln nach Klassifizierungsstufe

Klassifizierung	E-Mail nach extern	Cloud-Upload	USB-Export	Drucken	Aktion bei Verstoß
Internal	⚠ Warnung	❌ Blockiert	⚠ Warnung	✓ Erlaubt	Log + Warnung
Confidential	❌ Blockiert	❌ Blockiert	❌ Blockiert	⚠ Nur Secure Print	Log + Block + Alert an CISO
Highly Confidential	❌ Blockiert	❌ Blockiert	❌ Blockiert	❌ Blockiert	Log + Block + Sofort-Alert + Incident

DLP-Kanäle

E-Mail DLP

Überwachung ausgehender E-Mails auf klassifizierte Anhänge und Inhalte. Integration mit Exchange/M365 Transport Rules.

ExchangeM365

Endpoint DLP

Schutz an Endgeräten: USB-Kontrolle, Clipboard-Überwachung, Druck-Kontrolle für klassifizierte Dokumente.

EndpointAgent

Cloud DLP

Verhinderung von Uploads klassifizierter Daten in nicht genehmigte Cloud-Dienste (Shadow IT Prevention).

CASBCloud

Integration mit Microsoft Purview

Für die DLP-Enforcement empfehlen wir die Integration mit Microsoft Purview, da die HAFS-Group bereits M365-Lizenzen nutzt. Die Data Governance Platform liefert die Klassifizierungsinformationen, Purview setzt die DLP-Policies auf Endpoint- und M365-Ebene durch. Die Plattform fungiert als „Classification Source of Truth“, Purview als „Enforcement Engine“.

🛡

Behavioral Analytics & Insider Threat Detection UEBA

KI-basierte User Entity and Behavior Analytics (UEBA) für DLP:

Baseline-Learning: KI lernt das normale Zugriffsverhalten jedes Nutzers: Welche Assets, zu welchen Zeiten, welche Mengen. Abweichungen erzeugen Risk Scores
Insider Threat Scoring: Kombination aus Zugriffsmustern, Datenvolumen, Uhrzeiten und Kündigungsstatus zu einem Risiko-Score pro Mitarbeiter (0-100)
Data Exfiltration Detection: Erkennung von Datenabfluss-Mustern: „Benutzer hat in 1h 340 Confidential-Dokumente heruntergeladen – typisches Pre-Exit-Verhalten“
Kontextuelle DLP-Entscheidungen: KI berücksichtigt Kontext bei DLP-Blockierungen: Ist der Nutzer Data Owner? Liegt eine genehmigte Ausnahme vor? Ist ein legitimer Geschäftsprozess erkennbar?

🔎

Intelligent Content Inspection Deep Content

KI-basierte Inhaltsprüfung geht über Pattern-Matching hinaus:

Semantic Content Analysis: Erkennung vertraulicher Inhalte auch in Freitextfeldern, Kommentaren und Notizen – nicht nur strukturierte PII-Felder
Image/PDF OCR + Classification: Automatische Texterkennung und Klassifizierung von Dokumenten, Scans und Screenshots
Context-aware Blocking: „E-Mail an externe Adresse enthält Tabelle mit ISIN-Daten (Confidential). Blockiert. Empfehlung: Verschlüsselten Link über Secure File Transfer senden“

governance.hafs.de/dlp/monitor

Blockierte Aktionen

Warnungen

847

Geprüfte Aktionen

99.6%

Compliance Rate

🚨 UEBA ALERT – Anomales Zugriffsverhalten

Benutzer K. Müller hat in 1h auf 47 Highly Confidential Assets zugegriffen – 340% über Normalwert. Insider Threat Score: 78/100

Untersuchen

Aktuelle DLP-Ereignisse

❌ BLOCKIERT: E-Mail mit Confidential-Anhang an externe Adresse

Benutzer: A. Becker · Datei: NAV_Report_Q4.xlsx · Empfänger: extern@partner.com

🤖 Empfehlung: Secure File Transfer Link generieren

Heute 14:32 UTC

❌ BLOCKIERT: USB-Export von Highly Confidential Daten

Benutzer: M. Fischer · Datei: Client_Master_Export.csv · 1.247 Datensätze mit PII

Heute 11:15 UTC

⚠ WARNUNG: Interne E-Mail mit Internal-Daten an großen Verteiler

Benutzer: T. Schmidt · Verteiler: all-staff@hafs.de (342 Empfänger)

Heute 09:44 UTC

DLP Live Monitor – Echtzeit-Überwachung von DLP-Events, UEBA-Alerts und blockierten Aktionen mit KI-Empfehlungen

Kapitel 12

Data Contracts

Formalisierte Vereinbarungen über Datenlieferung und -qualität basierend auf dem Open Data Contract Standard (ODCS) v3.1.0.

Priorität: Could Have – Data Contracts sind ein zukunftsweisendes Thema, das die Datenqualität und Verantwortlichkeiten zwischen Datenlieferant und -konsument formalisiert. Die Implementierung basiert auf dem Open Data Contract Standard (ODCS).

Open Data Contract Standard (ODCS)

Der ODCS definiert ein standardisiertes Format für Data Contracts. Ein Contract beschreibt: welche Daten geliefert werden, in welchem Format, mit welcher Qualität, wer verantwortlich ist und welche SLAs gelten. Die Plattform bietet eine GUI zur Erstellung, Verwaltung und Überwachung von Data Contracts nach ODCS v3.1.0.

Referenzen: opendatacontract.com | ODCS v3.1.0 Spezifikation

Contract-Struktur (nach ODCS)

Abschnitt	Inhalt	Beispiel
Fundamentals	Name, Version, Domain, Owner, Description	NAV Daily Data Contract v2.1
Schema	Felder, Datentypen, Constraints, Beschreibungen	nav_value: DECIMAL(18,6), NOT NULL
Data Quality	DQ-Regeln, Schwellenwerte, Messmethoden	Completeness > 99.5%, Freshness < 2h
SLA	Verfügbarkeit, Latenz, Support-Zeiten	99.9% Uptime, Daten bis 07:00 UTC
Security	Klassifizierung, Verschlüsselung, Zugriff	Confidential, TLS 1.3, RBAC
Stakeholders	Provider, Consumer, Steward	Provider: Fund Accounting, Consumer: Reporting

Genehmigungsworkflow Could Have

Neuer Contract → Review durch Data Steward → Freigabe durch Data Owner (Provider) → Akzeptanz durch Data Owner (Consumer) → Aktiv. Bei Änderungen: Versionierung mit erneutem Approval-Prozess.

SLA-Tracking Could Have

Die Plattform überwacht automatisch die in den Data Contracts vereinbarten SLAs: Datenaktualität, Qualitätsschwellenwerte, Verfügbarkeit. Bei SLA-Verletzungen werden automatisch Alerts an die betroffenen Stakeholder gesendet.

📜

Auto-Contract-Drafting Generativ

Die KI unterstützt den gesamten Contract-Lifecycle:

Auto-Draft: KI generiert einen vollständigen ODCS-konformen Contract-Entwurf basierend auf den vorhandenen Metadaten: Schema, Klassifizierung, DQ-Regeln, Owner und typischen SLAs für ähnliche Assets
SLA-Empfehlungen: Basierend auf historischer Performance schlägt die KI realistische SLAs vor: „NAV-Daten werden typischerweise um 06:47 UTC verfügbar (P95). Empfohlenes SLA: 07:00 UTC“
Contract-Compliance-Monitor: Kontinuierliche Überwachung aller aktiven Contracts mit prädiktiver SLA-Verletzungs-Warnung: „SLA-Breach für NAV Daily Contract in 2h wahrscheinlich (87%) – Datenquelle PRICES noch nicht aktualisiert“
Natural Language Contracts: Nutzer beschreiben Anforderungen in natürlicher Sprache, KI generiert den formalen ODCS-Contract: „Ich brauche täglich bis 8 Uhr die NAV-Daten mit mindestens 99% Vollständigkeit“ → Vollständiger Contract

📊

Contract Health Score Monitoring

KI-basiertes Monitoring der Contract-Gesundheit:

Health Dashboard: Aggregierter Score (0-100) pro Contract basierend auf SLA-Einhaltung, DQ-Score und Timeliness der letzten 30 Tage
Trend-Alerts: Frühwarnung bei sinkender Contract-Performance: „NAV Daily Contract Health ist von 96 auf 84 gesunken – 3 SLA-Braches in den letzten 7 Tagen“
Root-Cause bei SLA-Breach: Automatische Lineage-Traversierung bei Breach: „Verspätung bei NAV-Daten durch verzögerten PRICES-Import (Upstream-Abhängigkeit)“

governance.hafs.de/contracts

Aktive Contracts

In Review

96.2

Ø Health Score

SLA-Breach

NAV Daily Data Contract v2.1 · ODCS

Provider: Fund Accounting → Consumer: Reporting, Risk Management

Health Score

SLA: Daten bis 07:00 UTC·Letzte Lieferung: 06:47 UTC ✓·DQ > 99.5%: ✓

Securities Master Contract v1.3 · ODCS

Provider: Securities → Consumer: Fund Accounting, Compliance

Health Score

⚠ SLA-Breach: Daten 2h verspätet·DQ: 94.1% (unter 95% SLA)

🤖 Root-Cause: Verzögerter SWIFT-Import upstream. Empfehlung: Provider kontaktieren.

Client Master Data Contract v1.0 · ODCS

Provider: Compliance → Consumer: Fund Accounting, KYC/AML

Health Score

🔒 Highly Confidential·14 PII-Felder·Alle SLAs erfüllt ✓

Data Contract Manager – ODCS-konforme Contracts mit Health Scores, SLA-Tracking und KI-Root-Cause-Analyse bei Breaches

governance.hafs.de/contracts/draft

Beschreiben Sie den gewünschten Contract in natürlicher Sprache:

„Ich brauche täglich bis 8 Uhr die NAV-Daten aller Fonds mit mindestens 99% Vollständigkeit und korrektem ISIN-Format.“

🤖 Generierter Contract-Entwurf (ODCS v3.1.0):

fundamentals:

name: "NAV Daily Data Contract"

version: 2.1.0

domain: Fund Accounting > NAV Calculation

quality:

completeness: > 99% # aus Ihrer Anforderung

validity_isin: 100% # ISIN-Format ISO 6166

sla:

availability: 08:00 UTC # aus Ihrer Anforderung

uptime: 99.9% # basierend auf historischer Performance

security:

classification: Confidential # auto-erkannt aus Metadaten

Contract erstellen Bearbeiten Zur Review senden

KI Auto-Contract-Draft – Natürlichsprachliche Anforderung wird automatisch in ODCS-konformen Contract umgewandelt

Kapitel 13

Zugriffsverwaltung & Sicherheit

Rollenbasierte Zugriffssteuerung, konfigurierbare Metadaten-Schemata und rollenspezifische Dashboards.

Role-Based Access Control (RBAC) Must Have

Die Plattform implementiert ein feingranulares RBAC-System, das den Zugriff auf das Tool selbst und auf sensible Metadaten steuert. Die Rollen-Hierarchie:

Rolle	Catalog lesen	Metadaten bearbeiten	Klassifizierung ändern	Policies verwalten	Admin
Viewer	✓	❌	❌	❌	❌
Data Consumer	✓	❌	❌	❌	❌
Data Steward	✓	✓ (eigene Domain)	✓ (Vorschlag)	❌	❌
Data Owner	✓	✓	✓	✓ (eigene Domain)	❌
Compliance Officer	✓	✓	✓	✓	❌
Administrator	✓	✓	✓	✓	✓

Konfigurierbare Metadaten-Schemata Should Have

Administratoren können eigene Felder und Attribute zu Datenobjekten hinzufügen, um spezifische Anforderungen der HAFS-Group abzubilden. Beispiele: regulatorische Relevanz (DORA/CSSF/DSGVO), Aufbewahrungsfrist, Datenherkunftsland, Verschlüsselungsstatus.

Rollenspezifische Dashboards Could Have

Verschiedene Einstiegsansichten für verschiedene Nutzergruppen: Data Owner sieht eigene Assets mit DQ-Status, Data Steward sieht offene Aufgaben, Compliance Officer sieht Audit-Übersicht und Policy-Compliance, CISO sieht DLP-Events und Classification Coverage.

🔐

Risk-based Access Control Adaptive RBAC

KI-basierte Erweiterung des statischen RBAC um dynamische, risikobewertete Zugriffskontrolle:

Adaptive Access Scoring: Jeder Zugriffsversuch erhält einen Risk Score (0-100) basierend auf: Nutzerrolle, Asset-Klassifizierung, Tageszeit, Standort, vorherige Zugriffsmuster. Score > 70: zusätzliche Authentifizierung erforderlich
Access Anomaly Detection: „Benutzer K. Müller (Data Consumer) versucht auf 12 Highly Confidential Assets zuzugreifen – bisher nur Internal-Assets genutzt. Zugriff pausiert, Prüfung erforderlich“
Least-Privilege-Empfehlungen: KI analysiert tatsächliche Nutzung vs. vorhandene Rechte: „23 Nutzer haben Data Steward-Rechte aber nutzen nur Consumer-Funktionen. Empfehlung: Rechte reduzieren“
Auto-Provisioning: Bei neuem Mitarbeiter schlägt KI basierend auf Abteilung und Rolle automatisch die passenden Zugriffsrechte vor: „Neue Mitarbeiterin in Fund Accounting → Consumer-Zugriff auf Fund Accounting + Securities Domains“

🛠

Personalisierte KI-Dashboards Adaptiv

KI-generierte, personalisierte Einstiegsansichten:

Adaptive Dashboard: KI erkennt die Nutzungsmuster jedes Users und ordnet die Dashboard-Widgets automatisch nach Relevanz: Steward sieht priorisierte Tasks oben, Owner sieht DQ-Trends seiner Assets
Proaktive Insights: „3 Assets in Ihrer Domain haben heute die Klassifizierung geändert – Ihre Review wird benötigt“ wird prominent angezeigt
Natural Language Dashboard: Nutzer können ihr Dashboard per Spracheingabe anpassen: „Zeige mir alle DQ-Violations der letzten Woche in meiner Domain als Trend-Chart“

governance.hafs.de/dashboard/ciso

94.2%

Classification Coverage

▲ +2.1%

99.6%

DLP Compliance

87%

DORA Readiness

▲ +5%

Offene Incidents

Klassifizierungs-Verteilung

■ Non-bus. 23🟢 Public 45🔵 Internal 487🟠 Confid. 589🔴 Highly C. 103

Regulatorische Compliance

DORA (EU 2022/2554)87%

CSSF Circular 20/75093%

DSGVO96%

🤖 KI Executive Insights

• DORA-Gap: 16 Assets in Finance-Domain ohne vollständige Klassifizierung. Empfehlung: Auto-Classification-Scan starten.
• DLP-Trend: 23% weniger Blockierungen vs. Vormonat – Awareness-Schulungen zeigen Wirkung.
• Risiko: 3 Nutzer mit überhöhten Rechten erkannt → Least-Privilege-Review empfohlen.

CISO Executive Dashboard – Rollenspezifische Ansicht mit Security-KPIs, Compliance-Status, KI-Insights und DORA-Readiness

governance.hafs.de/admin/access

Alle Nutzer (47) Data Owner (6) Data Steward (12) Consumer (29)

NutzerRolleDomainsLetzter ZugriffKI Risk Score

T. SchmidtData OwnerFund AccountingHeute 14:3212 🟢

K. MüllerStewardFund AccountingHeute 11:158 🟢

P. Hoffmann ⚠StewardSecuritiesHeute 16:0578 🔴

A. BeckerConsumerReportingGestern5 🟢

🤖 Least-Privilege-Empfehlungen:

• P. Hoffmann: Risk Score 78 – 47 Highly Confidential Zugriffe in 24h (340% über Normalwert). Investigation empfohlen.
• 3 Consumer mit Steward-Rechten, die nur Consumer-Funktionen nutzen → Downgrade empfohlen.
• Neue Mitarbeiterin L. Weber (Finance) → Auto-Provisioning: Consumer-Zugriff auf Finance-Domain.

Zugriffsverwaltung – Nutzerverwaltung mit KI-Risk-Scoring, Least-Privilege-Empfehlungen und anomalem Zugriffsverhalten

Kapitel 14

Referenzsysteme

Vergleich mit OpenMetadata und Microsoft Purview – Build vs. Buy Analyse und Empfehlung.

OpenMetadata

OpenMetadata ist eine Open-Source Data Discovery & Governance Plattform mit starkem Fokus auf Metadata Management, Data Quality und Lineage. Sie dient als Referenzarchitektur für die HAFS Platform.

Feature	OpenMetadata	HAFS Relevanz
Metadata Harvesting	✓ 80+ Connectors (inkl. Oracle, PostgreSQL)	Hoch – Architektur-Referenz für Connectors
Data Quality	✓ Integriertes DQ Framework (Great Expectations)	Hoch – Referenz für DQ-Rule-Engine
Data Lineage	✓ Automatische Lineage-Erkennung	Hoch – Graph-basierte Lineage als Vorbild
Business Glossary	✓ Glossar mit Term-Hierarchien	Hoch – Direkt übertragbar
Data Classification	⚠ Basis-Tagging, keine Policy-Engine	Mittel – Muss erweitert werden (5-Stufen HAFS)
DLP	❌ Nicht vorhanden	Fehlt – Eigenentwicklung notwendig
Data Contracts	⚠ Experimentell	Mittel – ODCS-Konformität fehlt
Audit Trail	✓ Änderungshistorie	Hoch – Muss für DORA erweitert werden

Microsoft Purview

Microsoft Purview ist die Enterprise-Lösung für Data Governance, Classification und DLP innerhalb des M365-Ökosystems. Es ist besonders relevant für Classification und DLP.

Feature	Microsoft Purview	HAFS Relevanz
Data Classification	✓ Sensitivity Labels, Auto-Classification	Hoch – Referenz für 5-Stufen-Schema
DLP	✓ E-Mail, Endpoint, Cloud DLP	Hoch – Enforcement-Engine für DLP-Regeln
Audit & Compliance	✓ Umfangreiche Audit-Logs	Hoch – Referenz für Audit-Anforderungen
Data Catalog	✓ Azure-fokussierter Catalog	Mittel – Begrenzt auf Azure/M365-Quellen
Metadata Harvesting	⚠ Hauptsächlich Azure-Quellen	Gering – Kein Oracle/Sage BOB Support
Data Quality	❌ Kein integriertes DQ Framework	Fehlt – Nicht verfügbar
Data Lineage	⚠ Azure Data Factory Lineage	Gering – Nur Azure-native Quellen
Data Contracts	❌ Nicht vorhanden	Fehlt

Empfehlung: Hybrid-Ansatz

Empfehlung: Custom-Plattform mit OpenMetadata als Architektur-Referenz + Microsoft Purview als DLP-Enforcement-Engine. Die eigene Plattform deckt Metadata Management, Data Quality, Lineage, Classification und Data Contracts ab. Purview wird für DLP auf Endpoint- und M365-Ebene integriert. Dieser Ansatz kombiniert die Flexibilität einer maßgeschneiderten Lösung mit der DLP-Stärke von Purview.

Kapitel 15

Aufwandsplan & Umsetzungsstrategie

Detaillierte Aufwandsschätzung nach Phasen mit User Stories und Rollenzuordnung.

Dokument-ID	HAFS-DG-PLAN-01
Version	1.0
Stand	Februar 2026
Klassifikation	Vertraulich
Zielgruppe	HAFS-Group Management, IT-Leitung, CISO

1. Aufwandsschätzung nach Phasen

Übersicht Gesamtaufwand

Phase	Beschreibung	Dauer	Aufwand (PT)	Team-Größe
Phase 0	Foundation & Infrastruktur (inkl. KI-Infrastruktur)	2 Monate	30–44 PT	3 Personen
Phase 1	Kern-Plattform + KI-Auto-Enrichment & Chatbot	3 Monate	70–94 PT	5 Personen
Phase 2	Data Quality, Lineage + KI-Prädiktive Analyse	3 Monate	56–80 PT	5 Personen
Phase 3	Compliance, DLP, UEBA + KI-Compliance-Engine	2 Monate	48–66 PT	5 Personen
Phase 4	Data Contracts, KI-Dashboards & Gesamtintegration	2 Monate	38–54 PT	4–5 Personen
	Gesamt	12 Monate	242–338 PT

Hinweis: Der geschätzte Aufwand von 242–338 PT umfasst die vollständige Kern-Plattform sowie die KI-Integration in alle Module (Chatbot, Auto-Enrichment, Prädiktive Analyse, UEBA, Auto-Classification, Smart Routing, Contract Drafting).

Phase 0 – Foundation (Monat 1–2)

Ziel: Infrastruktur steht, Datenbanken konfiguriert, CI/CD operativ, Dev-Umgebung bereit.

Arbeitspaket	User Story	PT	Rolle
Kubernetes Setup (RKE2)	Als Platform Engineer möchte ich einen RKE2-Cluster mit dedizierten Node Pools	4–6	Platform
Datenbank-Stack	Als Entwickler möchte ich PostgreSQL, Elasticsearch, Neo4j und Redis bereitstellen	6–8	Platform
CI/CD Pipeline	Als Entwickler möchte ich eine automatisierte Build- und Deploy-Pipeline	4–6	Platform
Monitoring Stack	Als Operations möchte ich Prometheus + Grafana für Observability	2–4	Platform
Security Baseline	Als Security Engineer möchte ich Ingress, TLS, NetworkPolicies konfigurieren	4–6	Security
Architektur-Review	Als Solution Architect möchte ich die Architektur validieren und dokumentieren	2–4	Architect
KI-Infrastruktur	Als AI Engineer möchte ich LLM-API-Anbindung (Claude), Vector Store (ES), spaCy-Modelle und Temporal.io aufsetzen	4–6	AI Engineer
Gesamt Phase 0		30–44

Phase 1 – Kern-Plattform (Monat 3–5)

Ziel: Data Catalog, Metadata Management, Business Glossary, Classification und RBAC live.

Arbeitspaket	User Story	PT	Rolle
Portal Shell & SSO	Als Benutzer möchte ich mich mit meinem AD-Account anmelden und ein einheitliches Portal sehen	4–6	Frontend
Data Catalog API & UI	Als Data Consumer möchte ich Datenobjekte suchen, filtern und Details einsehen	8–10	Full-Stack
Oracle Connector	Als Platform Engineer möchte ich automatisch Metadaten aus Oracle-DBs extrahieren	4–6	Backend
Sage BOB Connector	Als Platform Engineer möchte ich Metadaten aus Sage BOB importieren	4–6	Backend
Business Glossary	Als Data Steward möchte ich Fachbegriffe verwalten und mit Assets verknüpfen	4–6	Full-Stack
Metadata Enrichment UI	Als Data Steward möchte ich technische Metadaten mit fachlichem Kontext anreichern	4–6	Full-Stack
Classification Engine	Als Compliance Officer möchte ich Assets nach 5 Stufen klassifizieren und PII automatisch erkennen	8–10	Backend + AI
RBAC & User Management	Als Admin möchte ich Rollen und Berechtigungen verwalten	4–6	Backend
Data Domain Management	Als Admin möchte ich hierarchische Data Domains mit Rechte-Vererbung anlegen	2–4	Full-Stack
KI: Auto-Enrichment Engine	Als Data Steward möchte ich KI-generierte Beschreibungen, Auto-Glossar-Matching und Schema-Similarity	6–8	AI Engineer
KI: Governance Chatbot	Als Data Consumer möchte ich per natürlicher Sprache Fragen zu Datenobjekten stellen (RAG + LangChain)	6–8	AI Engineer
KI: PII Discovery Engine	Als Compliance Officer möchte ich automatische PII-Erkennung mit Multi-Language NER und Confidence Scoring	4–6	AI Engineer
Testing & Pilot	UAT mit Pilotgruppe, Performance- und Security-Testing	4–6	QA + Team
Gesamt Phase 1		70–94

Phase 2 – Data Quality & Lineage (Monat 6–8)

Ziel: DQ Framework, Profiling, Monitoring, Alerting, Technische Lineage und Impact Analysis.

Arbeitspaket	User Story	PT	Rolle
DQ Rule Engine	Als Data Steward möchte ich Qualitätsregeln auf Feld- und Tabellenebene definieren	6–8	Backend
DQ Profiling	Als Data Steward möchte ich automatische Qualitätsanalysen (Null-Werte, Duplikate) sehen	4–6	Backend + Data
DQ Dashboard	Als Data Owner möchte ich DQ-Scores pro Domain und Trends visualisiert sehen	4–6	Frontend
DQ Alerting	Als Data Owner möchte ich bei Qualitätsabweichungen benachrichtigt werden	2–4	Backend
Lineage Engine (Neo4j)	Als Data Engineer möchte ich Datenflüsse automatisch als Graph erfassen	8–10	Backend + Data
Lineage Visualization	Als Data Consumer möchte ich den Datenfluss eines Assets visuell nachverfolgen	4–6	Frontend
Impact Analysis	Als Data Owner möchte ich sehen, welche Systeme betroffen sind, wenn sich ein Asset ändert	4–6	Backend
Power BI Connector	Als Data Engineer möchte ich Report-Metadaten und Lineage aus Power BI importieren	4–6	Backend
KI: Auto-Rule-Generation	Als Data Steward möchte ich KI-generierte DQ-Regeln basierend auf Statistical Profiling und Pattern Learning	4–6	AI Engineer
KI: Prädiktive DQ-Analyse	Als Data Owner möchte ich DQ-Trend-Vorhersagen, Anomalie-Erkennung und Auto-Root-Cause-Analyse	4–6	AI Engineer
KI: Implicit Lineage Discovery	Als Data Engineer möchte ich KI-basierte Erkennung impliziter Datenflüsse aus SQL, ETL-Logs und DAX	4–6	AI Engineer
Testing	Integration Testing, Performance-Tests, KI-Evaluierung	2–4	QA
Gesamt Phase 2		56–80

Phase 3 – Compliance, DLP & Stewardship (Monat 9–10)

Ziel: Audit Trail, Policy Management, DLP-Integration, Stewardship-Workflows.

Arbeitspaket	PT	Rolle
Audit Trail Engine (append-only, 7+ Jahre Retention)	4–6	Backend
Policy Management UI & Engine	4–6	Full-Stack
DLP Integration mit Microsoft Purview	6–8	Backend + Security
DLP Policy-Sync (Classification → Sensitivity Labels)	4–6	Backend
Stewardship Workflow & Task Management	4–6	Full-Stack
Approval Workflows	4–6	Full-Stack
Compliance Dashboard (DORA, CSSF, DSGVO)	4–6	Frontend
KI: Auto-Compliance-Reporting	4–6	AI + Compliance
KI: Audit-Anomalie-Erkennung & UEBA	4–6	AI + Security
KI: Smart Task Routing & Stewardship-Copilot	4–6	AI Engineer
Testing & Integration	2–4	QA + Security
Gesamt Phase 3	48–66

Phase 4 – Data Contracts & Erweiterungen (Monat 11–12)

Ziel: Data Contract Management (ODCS), SLA-Tracking, Business Lineage, Dashboards.

Arbeitspaket	PT	Rolle
Data Contract Management GUI (ODCS v3.1.0)	6–8	Full-Stack
Contract Approval Workflow	2–4	Backend
SLA-Tracking & Monitoring	4–6	Backend
Business Lineage (vereinfachte Sicht)	4–6	Frontend + Backend
Rollenspezifische Dashboards	4–6	Frontend
Konfigurierbare Metadaten-Schemata	2–4	Full-Stack
KI: Auto-Contract-Drafting & Contract Health Score	4–6	AI Engineer
KI: Risk-based Access Control & Adaptive Dashboards	4–6	AI + Frontend
Stabilisierung & Gesamtabnahme	4–6	QA + Team
Gesamt Phase 4	38–54

2. Team-Zusammensetzung

Rolle	Allokation	Aufgaben	Phasen
Solution Architect / Tech Lead	80–100%	Architektur, Code-Reviews, Technische Leitung, AI-Tooling-Strategie	Alle
Senior Full-Stack Engineer	100%	Nest.js Backend, React/Next.js Frontend, Connector-Entwicklung	Phase 1–4
Data Engineer	80%	Neo4j Lineage, DQ-Engine, Profiling, Connector-Integration	Phase 1–3
Platform Engineer	100% (Ph.0), 30% (Ph.1–4)	RKE2, Terraform, Helm, Monitoring, CI/CD	Alle
AI/ML Engineer	80–100%	Chatbot (RAG), Auto-Enrichment, PII-Detection, Prädiktive Analyse, UEBA, Auto-Classification, Smart Routing, Contract Drafting	Alle Phasen

Kostenrahmen

Rolle	PT Gesamt (Min.)	PT Gesamt (Max.)
Solution Architect / Tech Lead	44	60
Senior Full-Stack Engineer	70	90
Data Engineer	40	50
Platform Engineer	24	36
AI/ML Engineer	50	72
QA / Testing	14	30
Gesamt	242	338

Hinweis: Die Angaben sind Richtwerte. Ein verbindliches Angebot wird nach der gemeinsamen Feinplanung und finalen Scope-Definition erstellt.

Zahlungsmodell

Modell	Beschreibung
Time & Material	Abrechnung nach tatsächlichem Aufwand, monatliche Abrechnung
Festpreis pro Phase	Festpreis je Phase nach Scope-Freeze
Hybrid	Phase 0 T&M (Scope noch offen), Phase 1–4 Festpreis

3. Meilensteine & Abnahmen

Meilenstein	Phase	Zeitpunkt	Abnahmekriterien
M0: Infrastruktur Ready	Phase 0	Monat 2	K8s Cluster läuft, DBs konfiguriert, CI/CD operativ
M1: Catalog & Classification Live	Phase 1	Monat 5	Data Catalog mit Oracle-Daten, Classification Engine, Glossary, UAT bestanden
M2: DQ & Lineage Live	Phase 2	Monat 8	DQ-Dashboard, Profiling, Alerting, Lineage-Graph für kritische Pfade
M3: Compliance & DLP Live	Phase 3	Monat 10	Audit Trail, Policy Engine, Purview DLP-Integration, Stewardship-Workflows
M4: Platform Complete	Phase 4	Monat 12	Data Contracts, Business Lineage, rollenspezifische Dashboards, Gesamtabnahme

4. Risiko-Management

Risiko	Wahrscheinlichkeit	Impact	Mitigierung
Oracle-Connector Komplexität (Legacy-Schemas)	Mittel	Hoch	Früher Proof-of-Concept in Phase 0, enger Austausch mit DBA-Team
Sage BOB API-Limitierungen	Mittel	Mittel	API-Analyse in Phase 0, Fallback auf JDBC/ODBC
Scope Creep bei Classification-Regeln	Hoch	Mittel	Striktes Backlog-Management, Fokus auf 5 HAFS-Stufen
Purview DLP-Integration Komplexität	Mittel	Mittel	Microsoft-Expertise im Team, früher PoC
Key-Person-Risiko	Niedrig	Hoch	Dokumentation, Pair Programming, AI-generierter Code ist nachvollziehbar
Regulatorische Änderungen (DORA-Umsetzung)	Niedrig	Hoch	Flexible Architektur, Policy-Engine von Beginn an

5. Nächste Schritte

1. Scope-Workshop

Gemeinsamer Workshop zur Priorisierung der Must-Haves und Abgrenzung des MVP-Scope.

Dauer: 1 Tag · Teilnehmer: IT-Leitung, CISO, Data Stewards

2. Quellsystem-Analyse

Detailanalyse der Oracle-Schemas und Sage BOB APIs für die Connector-Entwicklung.

Dauer: 2–3 Tage · Teilnehmer: DBAs, Entwickler

3. Infrastruktur-Feinplanung

Server-Dimensionierung, Netzwerk-Planung, HA-Konzept.

Dauer: 1 Tag · Teilnehmer: Platform Engineers, IT Operations

4. Vertragliche Vereinbarung

Abrechnungsmodell festlegen (T&M, Festpreis oder Hybrid), Kick-Off Termin vereinbaren.

Dauer: 1 Woche · Teilnehmer: Management, Einkauf

5. Kick-Off Phase 0

Hardware-Bereitstellung, Team-Onboarding, Projektsetup, erste MCP-Iteration starten.

Zieltermin: nach Vertragsschluss

Kapitel 16

Roadmap

Phasenbasierter Rollout über 12 Monate – von der Foundation bis zur vollständigen Data Governance Platform.

Phase 0: Foundation & Infrastruktur

Kubernetes-Cluster, Datenbanken, CI/CD, Monitoring, Security Baseline, KI-Infrastruktur (LLM-API, Vector Store, spaCy, Temporal.io).

Monat 1–2 · 30–44 PT · 3 Personen

RKE2PostgreSQLNeo4jCI/CDKI-Stack

Phase 1: Kern-Plattform + KI-Grundfunktionen

Data Catalog, Metadata Management, Business Glossary, Classification Engine (5 Stufen), Oracle & Sage BOB Connectors, RBAC, Domain Management + KI: Auto-Enrichment, Governance Chatbot, PII-Discovery-Engine, Semantische Suche.

Monat 3–5 · 70–94 PT · 5 Personen

CatalogGlossaryClassificationOracleSage BOBChatbotAuto-EnrichmentPII-Scanner

Phase 2: Data Quality & Lineage + KI-Prädiktive Analyse

DQ Rule Engine, Profiling, Monitoring, Alerting, DQ Dashboard, Technische Lineage (Neo4j), Impact Analysis, Power BI Connector + KI: Auto-Rule-Generation, Prädiktive DQ-Analyse, Anomalie-Erkennung, Implicit Lineage Discovery, Impact-Vorhersage.

Monat 6–8 · 56–80 PT · 5 Personen

DQ EngineProfilingLineageNeo4jPower BIPrädiktive DQAuto-RulesImplicit Lineage

Phase 3: Compliance, DLP, UEBA & KI-Compliance-Engine

Audit Trail, Policy Management, DLP-Integration mit Purview, Stewardship-Workflows, Approval-Prozesse + KI: Auto-Compliance-Reporting, Audit-Anomalie-Erkennung, UEBA, Insider Threat Detection, Smart Task Routing, Stewardship-Copilot.

Monat 9–10 · 48–66 PT · 5 Personen

Audit TrailDLPPurviewWorkflowsDORAUEBAAuto-ComplianceCopilot

Phase 4: Data Contracts, KI-Dashboards & Gesamtintegration

Data Contract Management (ODCS v3.1.0), SLA-Tracking, Business Lineage, rollenspezifische Dashboards + KI: Auto-Contract-Drafting, Contract Health Score, Risk-based Access, Adaptive KI-Dashboards, Gesamtabnahme.

Monat 11–12 · 38–54 PT · 4–5 Personen

ODCSSLABusiness LineageDashboardsAuto-ContractsAdaptive RBACKI-Dashboards

Export

Dokument speichern

Nutze Strg+P / Cmd+P um dieses Dokument als PDF zu speichern.

Data GovernancePlatform

Vision & Ziele

Ausgangslage

Scope: HAFS-Group Entitäten

Vision Statement

Strategische Ziele

Ziel-KPIs

Referenzsysteme

Anforderungen & MoSCoW

Plattform-Architektur

Technology Stack

Integrationsmuster

AI & Automation Hub

Übersicht: KI-Features pro Modul

Governance Chatbot

Chatbot-Fähigkeiten

Auto-Assessment Engine

KI-Automatisierung im Detail

Auto-Enrichment Pipeline

Predictive Analytics

Intelligentes Stewardship

Technology Stack: KI-Komponenten

Metadata Management

Business Glossary / Data Dictionary

Automatisches Metadata Harvesting

Manuelles & KI-gestütztes Enrichment

Data Catalog

Asset Inventory

Erfasste Asset-Typen

Search & Discovery

Data Domain Management

Data Lineage

Technische Lineage Must Have

Beispiel: NAV-Berechnungs-Lineage

Impact Analysis Should Have

Impact-Analyse Anwendungsfälle

Business Lineage Could Have

Data Classification

Klassifizierungs-Schema (5 Stufen)

Data Handling Matrix

PII/GDPR-Kennzeichnung

Tagging-System

Data Quality

Qualitätsdimensionen

DQ Rule Definition

DQ Profiling

DQ Monitoring & Alerting

Ownership & Stewardship

Rollen-Modell Must Have

RACI-Matrix

Aufgaben- und Workflow-Management Should Have

Approval Workflows Should Have

Compliance & Audit

Audit Trail / Change Log Must Have

Erfasste Ereignisse

Policy Management Must Have

Vorkonfigurierte Policies

Data Loss Prevention

DLP-Konzept

DLP-Regeln nach Klassifizierungsstufe

DLP-Kanäle

Integration mit Microsoft Purview

Data Contracts

Open Data Contract Standard (ODCS)

Contract-Struktur (nach ODCS)

Genehmigungsworkflow Could Have

SLA-Tracking Could Have

Zugriffsverwaltung & Sicherheit

Role-Based Access Control (RBAC) Must Have

Konfigurierbare Metadaten-Schemata Should Have

Rollenspezifische Dashboards Could Have

Referenzsysteme

OpenMetadata

Microsoft Purview

Empfehlung: Hybrid-Ansatz

Aufwandsplan & Umsetzungsstrategie

1. Aufwandsschätzung nach Phasen

Übersicht Gesamtaufwand

Phase 0 – Foundation (Monat 1–2)

Phase 1 – Kern-Plattform (Monat 3–5)

Data Governance
Platform