KI-Governance & Compliance-Management nach der KI-Verordnung (AI Act)

Die meisten Organisationen können die Frage noch nicht beantworten: „Welche KI-Systeme betreiben wir, in welcher Rolle und mit welcher Risikoklasse?“ KI-Governance-Plattformen führen ein lebendiges Register der Systeme, Modelle und Agenten, ordnen sie mit LLMs vorab nach der Verordnung (EU) 2024/1689 ein und entwerfen die Unterlagen (technische Dokumentation, FRIA, Kompetenznachweise, Überwachungsnachweise), abgebildet auf ISO/IEC 42001. Menschen entscheiden über die Einordnung; die KI nimmt ihnen das Ausfüllen von Formularen ab.

Problem & Nutzen

• Heute: KI kommt durch viele Türen: zugekaufte SaaS mit eingebauter KI, Cloud-APIs, selbst entwickeltes ML, von Mitarbeitenden eingeführte Werkzeuge, Agenten. Das Inventar liegt in Tabellen; die Einordnung erfolgt ad hoc; Dokumentation wird einmalig für ein Audit geschrieben und veraltet.
• KI-Nutzen: automatische Erfassung und Vorab-Einordnung von Anwendungsfällen, Extraktion von Fakten aus Herstellerdokumenten, Dokumententwürfe zur Prüfung, laufende Kontrollnachweise statt jährlicher Hektik, eine gemeinsame Sicht für Recht, Sicherheit, Datenschutz und Fachverantwortliche.
• Regulatorischer Treiber: Der AI Act gilt stufenweise. Die Verbote (Art. 5) und die KI-Kompetenz (Art. 4) gelten seit dem 2. Februar 2025; die GPAI-Pflichten seit dem 2. August 2025. Das Digital Omnibus on AI (Verordnung (EU) 2026/1744, in Kraft seit dem 27. Juli 2026) verschiebt die Hochrisiko-Pflichten nach Anhang III auf den 2. Dezember 2027 und die in Produkte eingebetteten Systeme nach Anhang I auf den 2. August 2028 [1][2]. Die Verschiebung ändert Fristen, nicht den Bedarf an einem Inventar: Sie können nicht einordnen, was Sie nicht finden, und Art. 5 ist bereits durchsetzbar.

Varianten

• Compliance-Management nach der KI-Verordnung (Kern): Rollenbestimmung (Anbieter, Betreiber, Einführer, Händler), Risikoklasse, Pflichtenliste, Konformitätsdokumentation, Transparenz nach Art. 50, Informationen für nachgelagerte Anbieter von GPAI.
• Managementsystem nach ISO/IEC 42001: KI-Richtlinie, Risikobewertung, Kontrollen (Anhang A), interne Audits und Zertifizierungsnachweise [3].
• Modellrisikomanagement bei Banken und Versicherungen (Branchen: banking, insurance): Modellinventar mit Stufung, unabhängige Validierungsberichte, Challenger-Modelle, Drift- und Fairness-Überwachung gemäß US-Fed SR 26-2 (17. April 2026, löste SR 11-7 ab, ist vor allem für Banken mit mehr als 30 Mrd. USD Bilanzsumme relevant und nimmt generative und agentische KI-Modelle ausdrücklich vom Anwendungsbereich aus), dem EZB-Leitfaden zu internen Modellen und BaFin-MaRisk AT 4.3.5 [5][6]. Gleicher Kern aus Register, Dokumentation und Überwachung; die Anforderungen an Validierungstiefe und Unabhängigkeit sind strenger, und Kreditscoring sowie die Preisbildung in der Lebens- und Krankenversicherung gelten nach Anhang III als Hochrisiko.

So funktioniert es

1. discovery & intake (SEC-013 feeds, procurement, MLOps registry, intake form)
2. register entry (system, model, owner, vendor, purpose, data, users affected)
3. role + risk classification (LLM pre-classifier with Art. 5 / Annex III / Art. 50 checks, cited reasoning)
4. human review: legal/compliance owner confirms or overrides
5. obligations mapping (AI Act articles, ISO 42001 controls, GDPR, sector rules)
6. document drafting (Annex IV, FRIA, DPIA, model cards, vendor questionnaires)
7. evidence collection (tests, bias metrics, logs, literacy training, incidents)
8. continuous monitoring (drift, change triggers re-assessment)
9. audit pack / dashboards

• Vorab-Einordnung: Ein LLM mit Retrieval über die Verordnung, die Leitlinien der Kommission (verbotene Praktiken, Definition des KI-Systems) und Ihre Richtlinien liest die Beschreibung des Anwendungsfalls und schlägt eine Klasse mit Artikelverweisen vor. Es muss Unsicherheit kennzeichnen; Grenzfälle (z. B. Anhang III „Beschäftigung“ oder „wesentliche Dienste“) gehen an die Rechtsberatung.
• Dokumentenextraktion: Das LLM liest Modellkarten, AVV und Sicherheitsberichte der Hersteller und füllt Fragebögen aus; Lücken werden als offene Aufgaben aufgelistet.
• Entwurf: Strukturierte Erzeugung in Vorlagen (Überschriften nach Anhang IV, FRIA-Fragen), mit Quellenverweis je Aussage.
• Mensch-in-der-Schleife (Human-in-the-Loop): Freigabe der Einordnung, jede Erklärung gegenüber Aufsichtsbehörden oder Kunden, FRIA-Schlussfolgerungen, Risikoakzeptanz.

Datenaufbereitung

Die „Daten“ sind hier vor allem ein Inventar der KI-Systeme und ihrer Unterlagen, keine Trainingsdaten. Sie sind verstreut: Bestellungen und SaaS-Verträge in ERP oder Beschaffung, Herstellerdokumente und AVV im DMS oder auf Dateiablagen, Cloud-KI-Dienste in Admin-Konsolen, Modellartefakte in MLOps-Registern und Schatten-KI in Browsern und Postfächern der Mitarbeitenden. Typische Lücken sind fehlende Verantwortliche, nicht dokumentierte Verwendungszwecke, veraltete oder eingescannte Verträge, doppelte Einträge und fehlende Angaben, wer was nutzt.

Schritte der Aufbereitung: - Eine erste Liste aus Beschaffung, SSO-App-Katalog, Cloud-Konsolen und Spesenabrechnungen ziehen; SEC-013 für Schatten-KI ausführen. - Papierverträge digitalisieren und Herstellerdokumente an jeden Eintrag anhängen (siehe PREP-006, PREP-007). - Zuerst ein minimales Registerschema und ein Kategorienschema festlegen (PREP-019) und je Eintrag eine verantwortliche Person benennen (PREP-004). - Vorhandene Kennzeichnungen der Datensensibilität weiterverwenden (PREP-024, SEC-017). - Prüfen, welche Einträge personenbezogene Daten enthalten (PREP-025).

Rechnen Sie mit etwa einem Drittel des Aufwands für Aufbau und Bereinigung des ersten Inventars; der Rest entfällt auf Einordnung und Dokumentation. Eine wiederkehrende Erkennung verhindert, dass das Register verfällt.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A, weil ausgereifte, in der EU gehostete Governance-Plattformen (z. B. trail, Saidot) Register, Vorlagen und Workflow zu Abopreisen für einen Standardprozess liefern.
• Großunternehmen: Weg B, weil das Register im bestehenden GRC-/CMDB-Umfeld liegen sollte, mit eigenen Taxonomien und Anbindungen an Cloud- und MLOps-Inventare.
• Öffentlicher Sektor: Weg C, weil Open-Source-GRC (z. B. CISO Assistant) auf souveräner Infrastruktur bei geringem Volumen Beschaffungs- und Hosting-Hürden vermeidet.
• Entwickler: Weg C, weil Modellkarten, Register und Drift-Werkzeuge (MLflow, Evidently) Open Source sind und sich in bestehende Pipelines einfügen.

Weg A — Kaufen (Standardsoftware) (empfohlen für KMU)

• Governance-Plattformen: trail (DE, EU), Saidot (FI, EU), Modulos (CH), Credo AI, Holistic AI, IBM watsonx.governance, OneTrust AI governance, ServiceNow AI Control Tower, Governance-Funktionen von Microsoft Purview/Azure AI Foundry, Collibra und Fairly AI.
• Modellrisiko (Banken/Versicherungen): ValidMind, SAS Model Risk Management, MRM-Suiten der Klasse Moody's und Bloomberg, Fiddler/Arize für die Überwachung.
• Weg A wählen, wenn: Sie innerhalb weniger Wochen ein prüffähiges Register, Workflow und Vorlagen brauchen. Prüfen Sie EU-Hosting, rollenbasierten Prüf-Workflow, Aktualität der Vorlagen (Änderungen durch das Omnibus), Konnektoren (Cloud, MLOps, SaaS-Erkennung) und Exportformate.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Erfassungsformular + Register in einem vorhandenen GRC/CMDB (ServiceNow, Jira, SharePoint/Dataverse, Notion-ähnliche Datenbank), eine LLM-API in einer EU-Region (Mistral, Azure OpenAI EU Data Zone, Anthropic oder Google über EU-Regionen) mit strukturierten Ausgaben für Einordnung und Dokumentenentwurf, RAG über die Verordnung und Ihre Richtlinien.
• Orchestrierung mit n8n, Power Automate oder einem kleinen Dienst; Anbindung an Cloud-Inventare (AWS Bedrock/SageMaker, Azure AI, Vertex AI) über deren APIs.
• Weg B wählen, wenn: Governance in einem vorhandenen GRC-Umfeld mit eigenen Taxonomien liegen muss.

Weg C — Selbst betreiben (Open Source)

• Open-Weight-Modelle (Mistral Small/Large, Qwen3, Llama, gpt-oss) hinter vLLM oder Ollama; Embeddings (BGE-M3, multilingual-e5) mit pgvector oder Qdrant; Register in Postgres oder Eramba/CISO Assistant (Open-Source-GRC) [7]; MLflow-Modellregister; Modellkarten mit Hugging-Face-Werkzeugen; Drift/Fairness mit Evidently, Fairlearn, AI Fairness 360.
• Hardware: HW2 genügt (geringes Volumen, Prompts in Dokumentgröße). Der Betriebsaufwand ist klein; die eigentliche Schwierigkeit ist die Pflege der Inhalte.

Weg D — Eigenes Training

Selten gerechtfertigt. Ein feingetunter Klassifikator auf Basis Ihrer bisherigen Einordnungsentscheidungen könnte die Triage in sehr großen Beständen (Tausende Systeme) beschleunigen, aber ein per Prompt gesteuertes LLM mit menschlicher Prüfung reicht meist aus.

Stand der Technik (2026)

• Governance-Plattformen haben sich auf Folgendes angeglichen: automatisiertes Inventar (Cloud, SaaS, Code, Agenten), LLM-gestützte Risikofragebögen, Kontrollbibliotheken für ISO 42001 und die KI-Verordnung sowie Agentenregister (siehe AGENT-025). Analysten fassen dies als „AI TRiSM“/KI-Governance-Plattformen zusammen.
• Normen: ISO/IEC 42001 (Managementsystem) ist der faktische Zertifizierungsweg; die harmonisierten Normen von CEN-CENELEC JTC 21 zur Verordnung verzögern sich, was ein Hauptgrund für die Verschiebung durch das Omnibus ist [2][3]. Die Leitlinien der Kommission zu verbotenen Praktiken und zur Definition des KI-Systems sind die zentralen Auslegungstexte.
• Grenzen und Fehlerbilder: Die LLM-Einordnung kann Grenzfälle nach Anhang III übersehen oder zu streng einordnen; aus Herstellerangaben erzeugte Dokumentation kann ungeprüft sein; Inventare verfallen ohne Erkennung und Zuständigkeit; Compliance zum Abhaken ohne echte Tests (siehe SEC-014) vermittelt falsche Sicherheit; die Rechtslage (Omnibus, Leitlinien, nationale Behörden) ändert sich, daher brauchen Vorlagen eine Versionsverwaltung.

Gemeinsame Bausteine & Kombinationen

• Erkennung: SEC-013 (Schatten-KI, AI-SPM) speist das Register; SEC-017 (Datenklassifizierung) liefert Fakten zur Datensensibilität.
• Kontrollen und Tests: SEC-009 (Nachweise zu ISO 27001, NIS2, DORA), SEC-010 (Guardrails zur Laufzeit), SEC-012 (KI-Bedrohungsmodellierung), SEC-014 (Red Teaming) liefern Nachweise für die Pflichten zum Risikomanagement.
• Datenschutz: SEC-018 (Verarbeitungsverzeichnis, DSFA) teilt Datenabbildung und FRIA-/DSFA-Inhalte.
• Agenten und Inhalte: AGENT-025 (Governance der Agentenflotte), ANOM-015 (Kennzeichnung nach Art. 50).

Aufwand, Kosten & Kennzahlen

• Weg A: 2-8 Wochen bis zu einem gefüllten Register in einem KMU; Einführungen in Großunternehmen dauern Quartale, vor allem wegen Konnektorarbeit und organisatorischer Zuständigkeit. Die Preise richten sich üblicherweise nach System, Nutzer oder Plattformabo (Angebote der Hersteller nötig).
• Weg B/C: 2-4 Monate; die Kosten entstehen durch Inhaltspflege, juristischen Prüfaufwand und Integration, nicht durch Rechenleistung.
• Kennzahlen: Anteil der KI-Systeme, die mit benannter verantwortlicher Person registriert sind; Anteil eingeordneter und geprüfter Systeme; Zeit von der Erfassung bis zur Einordnung; Vollständigkeit der Dokumentation je Hochrisiko-System; Abschlussquote der KI-Kompetenz-Schulung; überfällige Neubewertungen; rechtzeitig gemeldete Vorfälle; beim MRM: Rückstau bei der Validierung und Abdeckung der Modellstufen.

Menschen & Veränderung

• Früh einbinden: Geschäftsleitung (Mandat, KI-Richtlinie), Recht/Compliance (Verantwortliche für die Einordnung), IT und IT-Sicherheit (Erkennung, Konnektoren), Datenschutzbeauftragte(r) (Abstimmung DSFA/FRIA), Abteilungsleitungen (Systemverantwortliche) und Personalabteilung (Kompetenznachweise).
• Betriebsrat: abhängig. Das Register enthält Namen von Mitarbeitenden und Kompetenznachweise, und jede Nutzungsprotokollierung kann zur Verhaltensüberwachung geeignet sein (§ 87 Abs. 1 Nr. 6 BetrVG, objektive Eignung genügt laut BAG). Der Betriebsrat ist in jedem Fall rechtzeitig zu unterrichten, wenn KI-gestützte Arbeitsprozesse geplant werden (§ 90 Abs. 1 Nr. 3), und kann einen KI-Sachverständigen hinzuziehen (§ 80 Abs. 3). Öffentliche Stellen beteiligen den Personalrat. Nur relevant, wo ein Gremium besteht.
• Datenschutz: personenbezogene Daten auf die Namen der Verantwortlichen beschränken, den Datenschutzbeauftragten einbinden, einen Auftragsverarbeitungsvertrag (AVV) mit den Plattformanbietern und mit den für Entwürfe genutzten LLM-Anbietern abschließen.
• KI-Kompetenz: Art. 4 verlangt Maßnahmen zur Förderung der KI-Kompetenz der Beschäftigten; dieser Anwendungsfall protokolliert sie, starten Sie das Schulungsprogramm also zusammen mit dem Register (GUIDE-006).
• Kommunikation und Pilot: das Register als sicheren Hafen für nützliche Werkzeuge darstellen, nicht als Verbotsliste; Pilot mit 10-20 Systemen und einer aufgeschlossenen Abteilung.
• Bedenken: „Mehr Bürokratie“ begegnet man mit einem kurzen Erfassungsformular; der Angst vor Schuldzuweisung mit einem sanktionsfreien ersten Inventar. Menschen geben jede Einordnung frei.
• Siehe GUIDE-014, GUIDE-007 und GUIDE-004.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Das Governance-Werkzeug selbst hat minimales Risiko, da es nicht unter Anhang III fällt. Die Pflicht zur KI-Kompetenz nach Art. 4 gilt für die Beschäftigten. Die Verbote nach Art. 5 (Social Scoring, Emotionserkennung am Arbeitsplatz/in der Schule, ungezieltes Auslesen von Gesichtsbildern, bestimmte biometrische Kategorisierung und manipulative KI) sind zuerst zu prüfen, und jeder Treffer stoppt das Projekt; sie gelten bereits, mit Geldbußen bis zu 35 Mio. EUR oder 7 % des Umsatzes [1].
• Rollenverwechslung: Betreiber, die ein System wesentlich verändern oder ihren Namen darauf setzen, können zu Anbietern werden (Art. 25); das Werkzeug sollte dies prüfen.
• DSGVO: Register enthalten Namen von Mitarbeitenden und können auf Systeme verweisen, die personenbezogene Daten verarbeiten; FRIA und DSFA sollten abgestimmt werden; AVV der Hersteller und EU-Hosting für den LLM-Entwurf.
• Branchenregeln: SR 26-2 (ersetzte SR 11-7 im April 2026), EZB-Leitfaden, MaRisk AT 4.3.5, EIOPA-Stellungnahme zur KI-Governance, DORA-Register der IKT-Drittanbieter (IKT-Anbieter von KI).
• Risiken und Gegenmaßnahmen: übermäßiges Vertrauen in die KI-Einordnung (verpflichtende menschliche Freigabe, Quellenangaben); veraltete Dokumente (Änderungsauslöser, Prüftermine); falsche Sicherheit (Verknüpfung mit Tests); keine Rechtsberatung.

Erste Schritte

1. Ein erstes Inventar aufbauen: Beschaffungslisten, SSO-App-Katalog, Cloud-KI-Dienste, MLOps-Register; SEC-013-Erkennung ausführen.
2. Jeden Eintrag zuerst auf Art. 5 prüfen, dann auf Anhang III, GPAI und Art. 50, und die Rolle (Anbieter/Betreiber) festhalten.
3. Verantwortliche, eine einfache Richtlinie zu Risikostufen und ein Erfassungsformular für neue KI-Anwendungsfälle festlegen.
4. Eine Plattform (Weg A) oder einen LLM-gestützten Klassifikator (Weg B) an 10-20 Systemen pilotieren und dabei Prüfzeit und Korrekturquote messen.
5. KI-Kompetenz-Schulungen mit protokolliertem Abschluss einführen und vierteljährliche Neuprüfung sowie Änderungsauslöser festlegen.

Quellen

1. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
2. Gibson Dunn — EU AI Act Omnibus Agreement: postponed high-risk deadlines — https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes/
3. European Parliament Legislative Train — Digital Omnibus on AI — https://www.europarl.europa.eu/legislative-train/package-digital-package/file-digital-omnibus-on-ai
4. ISO/IEC 42001:2023 AI management systems — https://www.iso.org/standard/81230.html
5. Federal Reserve SR 26-2 Revised Guidance on Model Risk Management (17 Apr 2026, supersedes SR 11-7) — https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm
6. European Commission — AI Act regulatory framework and guidelines — https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
7. CISO Assistant (open-source GRC) — https://github.com/intuitem/ciso-assistant-community
8. trail (DE) — https://www.trail-ml.com ; Saidot (FI) — https://www.saidot.ai ; ValidMind — https://validmind.com