E2E KI-Prüfung mit Dokumentenpflichten (Version 3.2)

GEALAN Fenster-Systeme GmbH
Stand: 17.02.2026
Version: 3.2
Status: Freigegeben

---

Änderungshistorie

Version	Datum	Änderung
1.0	09.02.2026	Erstversion (10 Schritte)
2.0	15.02.2026	• Schritte 10 → 8 (Schritt 2+3 merged, Schritt 8 entfernt) • Fast-Track für Low-Risk Cases • Automatisiertes Risk-Scoring • Anbieterprüfung nach Fachprüfungen verschoben
3.1	15.02.2026	• Dokumenten-Numerierung entfernt (Dokument 01/02/03/04 → sprechende Namen) • Dokument 02 eliminiert (Gate-Entscheidung direkt im System) • Finale Namen: KI Check - Use-case-Steckbrief, KI Check - Einzelanlage zur KI-RBV, KI Check - Management-Entscheidung
3.0	15.02.2026	• Fokus auf Prozessdokumentation (Praktische Hinweise & Beispiele ins Handbuch ausgelagert) • Neutralere Formulierungen (tool-agnostisch) • Verbesserte Übergänge zwischen Schritten • Klarere Struktur pro Schritt
3.2	17.02.2026	• Schritt 1: Systemtyp als Datenfeld ergänzt (Art der KI-Unterstützung: Assistierend / Entscheidungsunterstützung / Semi-automatisch) • Schritt 4 (IT-Security) korrigiert: Systemtyp, Autonomiegrad, Integrationsgrad und Externe Weitergabe aus "Erforderliche Daten" entfernt (bereits in Schritt 1 erfasst) • Prüfumfang Schritt 4 fokussiert auf technische Sicherheitsmaßnahmen: Zugriffskontrolle, Verschlüsselung, DLP, Monitoring & Incident-Management • Punkt "Cloud & Datenspeicherung" aus Schritt 4 entfernt (gehört zu Schritt 6)

---

Zweck des Dokuments

Dieses Dokument beschreibt den End-to-End-Prüf- und Entscheidungsprozess für den Einsatz von KI-Anwendungen im Unternehmen.

Ziel ist es, KI-Vorhaben einheitlich, nachvollziehbar und revisionsfest von der ersten Idee bis zur Entscheidung oder formellen Ablehnung zu steuern. Der Prozess stellt sicher, dass rechtliche, datenschutzrechtliche, mitbestimmungsrelevante und IT-sicherheitsbezogene Anforderungen frühzeitig erkannt, geprüft, dokumentiert und in eine verantwortete Management-Entscheidung überführt werden.

Der Prüfprozess operationalisiert die Vorgaben der SOP „Einsatz von KI-Anwendungen" sowie der geltenden KI-Rahmenbetriebsvereinbarung. Er unterscheidet bewusst zwischen prüfbaren Standardfällen und nicht zulässigen Hochrisiko-Kontexten (gem. RBV Abschnitt 3).

---

Prozessübersicht (8 Schritte)

SLA-Zielwerte:

• Fast-Track (Low-Risk): ~10-15 Arbeitstage
• Standard (Medium-Risk): ~4-6 Wochen
• Vollprüfung (High-Risk): ~6-8 Wochen

---

Schritt 1 – Formalisierung & Risk-Scoring

Zweck

Aus einer informellen KI-Idee wird ein strukturiert dokumentierter Use Case mit objektivem Risk-Score. Die quantitative Risikobewertung ermöglicht eine erste, automatisierte Routing-Entscheidung (Fast-Track / Standard / Vollprüfung).

Abgrenzung zu Schritt 2: Schritt 1 führt eine technische Klassifizierung durch (Datenart, Autonomie, Integration). Die rechtliche Zulässigkeitsprüfung (AI-Act-Verbote, Hochrisiko-Fälle gem. RBV) erfolgt in Schritt 2.

SLA

3 Arbeitstage (typisch 1-2 Tage, max. 5 Tage bei unklaren Fällen)

Verantwortlichkeiten

• Use-Case-Owner: Erstellt den Use-case-Steckbrief
• KI-Manager: Koordiniert Prozess, validiert Vollständigkeit, berechnet Risk-Score
• DSB & IT-Security: Informiert (keine Freigabe in Schritt 1)

Erforderliche Daten

Folgende Informationen werden in diesem Schritt erfasst:

Datenfeld	Beschreibung	Wertebereich / Format
Titel	Kurzbeschreibung des Use Case	Freitext (max. 100 Zeichen)
Use-Case-Beschreibung	Input → Verarbeitung → Output	Freitext (max. 500 Zeichen)
Geschäftsbereich	Organisatorische Zuordnung	Auswahl: HR, IT, Vertrieb, Produktion, ...
Antragsteller	Verantwortliche Person	Personenauswahl
Tool-Anbieter	Name des KI-Tool-Anbieters	Freitext
Zweckkategorie	Art der KI-Anwendung	Auswahl: Text, Bild, Audio, Video, Analyse, Coding, ...
Skalierungsgrad	Geplante Reichweite	Auswahl: Pilot (1-5), Team (6-20), Bereich (21-100), Unternehmen (>100)
Systemtyp	Art der KI-Unterstützung	Auswahl: Assistierend / Entscheidungsunterstützung / Semi-automatisch
Risk-Score	Automatisch berechnet aus 6 Kriterien	Numerisch: 6-18 Punkte
Prozessstatus	Aktueller Prozessschritt	Automatisch: „S1 Formalisierung"

Artefakt: Die Daten werden in KI Check - Use-case-Steckbrief strukturiert erfasst.

Prüfumfang: Risk-Scoring

Die Risikobewertung erfolgt anhand einer standardisierten Matrix mit 6 Kriterien (je 1-3 Punkte):

Kriterium	1 Punkt (niedrig)	2 Punkte (mittel)	3 Punkte (hoch)
1. Datenart	Keine personenbezogenen Daten	Personenbezogene Daten (allgemein)	Besondere Kategorien (Art. 9 DSGVO)
2. Autonomie	Rein unterstützend (100% manuell)	Teil-automatisiert (KI schlägt vor)	Automatisierte Entscheidung
3. Integration	Stand-alone / Read-only	Schreibzugriff (1 System)	Multi-System-Integration
4. Reichweite	Pilot (1-5 Nutzer)	Team/Bereich (6-100)	Unternehmensweit (>100)
5. Externe Weitergabe	Nein	Möglich (z.B. Export)	Ja (automatisch)
6. HR-Kontext	Nein	Indirekt (z.B. Meeting-Notizen)	Direkt (Bewerbung, Bewertung)

Gesamt-Score: 6-18 Punkte

Routing-Logik

Basierend auf dem Gesamt-Score wird der Use Case einem von drei Prüfpfaden zugeordnet:

Risk-Score	Routing	Fast-Track möglich?	Voraussetzungen für Fast-Track
6-9 Punkte	Low-Risk	✅ Ja	• Keine bes. Kategorien (Art. 9) • Kein HR-Kontext • Kein Profiling • Kein Schreibzugriff • Keine externe Weitergabe
10-14 Punkte	Medium-Risk	❌ Nein	Standard-Pfad: S1 → S2 → S3-S6 → S7 → S8
15-18 Punkte	High-Risk	❌ Nein	Vollprüfung mit vertiefter Risikoanalyse

Hinweis zum Fast-Track:
Der Fast-Track ist eine Abkürzung für risikoarme Use Cases direkt zu Schritt 7 (Management-Entscheidung). Die Fachprüfungen (Datenschutz, IT-Security) entfallen, wenn die o.g. Voraussetzungen erfüllt sind. Die finale Prüfung erfolgt dennoch in Schritt 2 (Quick-Check).

Übergang zu Schritt 2:
Der Risk-Score gibt eine erste technische Einschätzung. In Schritt 2 erfolgt die rechtliche Zulässigkeitsprüfung (AI-Act-Verbote, RBV-Hochrisiko) sowie die finale Routing-Bestätigung.

Outputs

• ✅ Use Case strukturiert dokumentiert (KI Check - Use-case-Steckbrief)
• ✅ Risk-Score berechnet und dokumentiert
• ✅ Routing-Pfad bestimmt (Fast-Track / Standard / Vollprüfung)
• ✅ Prozessstatus: „S1 Formalisierung"

Rechtliche Grundlagen

• EU AI Act (Art. 6, Anhang III – High-Risk-Definitionen)
• DSGVO (Art. 5, 6, 9, 22 – Datenarten, Rechtsgrundlagen, automatisierte Entscheidungen)
• BetrVG (§§ 87, 94 – Mitbestimmung bei Überwachung, Profiling)
• RBV KI (Abschnitt 3 – Verbote & Hochrisiko-Fälle)

---

Schritt 2 – Risk Assessment & Gate

Zweck

Schritt 2 ist die zentrale Gate-Funktion des Prozesses: Hier wird geprüft, ob der Use Case rechtlich zulässig ist und welcher Prüfpfad durchlaufen werden muss. Die Prüfung erfolgt in drei Varianten, abhängig vom Risk-Score aus Schritt 1.

Abgrenzung zu Schritt 1:
Während Schritt 1 eine quantitative, technische Risikobewertung vornimmt, erfolgt in Schritt 2 die qualitative, rechtliche Bewertung. Der Use Case kann hier gestoppt werden (STOP), wenn Verbote oder Hochrisiko-Fälle vorliegen.

SLA

• Fast-Track (6-9 Punkte): 2 Arbeitstage
• Standard (10-14 Punkte): 5 Arbeitstage
• High-Risk (15-18 Punkte): 7 Arbeitstage

Verantwortlichkeiten

• KI-Manager: Gate-Entscheidung, Routing-Koordination
• DSB: AI-Act-Compliance, DSGVO-Prüfung
• Rechtsabteilung: AI-Act-Verbote, Hochrisiko-Bewertung gem. RBV

Erforderliche Daten

Folgende Informationen werden in diesem Schritt gesetzt bzw. validiert:

Datenfeld	Beschreibung	Wertebereich
SOP anwendbar	Fällt der Use Case unter die KI-SOP?	Ja / Nein
AI-Act verboten	Liegt ein Verbot nach Art. 5 AI Act vor?	Ja / Nein
Hochrisiko-Verdacht	Anhang III AI Act Kategorie betroffen?	Ja / Nein / Unklar
Blocker-Status	Hindernisse für Freigabe	STOP / HOLD / Kein Blocker
Prozessstatus	Aktueller Prozessschritt	„S2 Risk Assessment"

Artefakt: Die Gate-Entscheidung wird in Gate-Entscheidung (direkt im System) dokumentiert.

Prüfumfang: Drei Gate-Varianten

Variante A: Fast-Track (6-9 Punkte)

Ziel: Schnelle Plausibilitätsprüfung für risikoarme Use Cases.

Prüfung:

1. SOP-Relevanz: Fällt der Use Case unter die KI-SOP?
2. AI-Act-Verbote (Art. 5): Social Scoring, Emotion Recognition (Workplace), Subliminal Manipulation, Exploitation of vulnerabilities?
3. Fast-Track-Kriterien (Validierung):
   • Keine besonderen Kategorien (Art. 9 DSGVO)
   • Kein HR-Kontext
   • Kein Profiling
   • Kein Schreibzugriff
   • Keine externe Weitergabe

Gate-Entscheidung:

• ✅ Alle Checks OK → Fast-Track zu Schritt 7 (Management-Entscheidung)
• ⚠️ Ein Kriterium nicht erfüllt → Umleitung in Standard-Pfad (S3-S6)
• ❌ AI-Act-Verbot → STOP

Variante B: Standard (10-14 Punkte)

Ziel: Vollständige rechtliche Zulässigkeitsprüfung für Standardfälle.

Zusätzliche Prüfung:

• Hochrisiko-Verdacht (Anhang III AI Act):
  • HR-Recruiting
  • Leistungs-/Verhaltensbewerung von Beschäftigten
  • Profiling mit Rechtswirkung
  • Kreditscoring
  • Biometrische Identifikation
  • Kritische Infrastruktur

⚠️ WICHTIG: Gem. RBV Abschnitt 3 sind Hochrisiko-Use-Cases (Anhang III AI Act) generell nicht zulässig. Bei positivem Hochrisiko-Verdacht → STOP.

Gate-Matrix:

SOP anwendbar?	AI-Act-Verbot?	Hochrisiko (RBV)?	Routing
Nein	-	-	Ende (nicht prüfpflichtig)
Ja	Ja	-	STOP (nicht zulässig)
Ja	Nein	Ja	STOP (RBV Verbot)
Ja	Nein	Nein	Standard-Pfad (S3-S6)

Variante C: High-Risk (15-18 Punkte)

Ziel: Vertiefte Analyse für komplexe, risikoreiche Use Cases.

Erweiterte Prüfung:

• Detaillierte AI-Act-Compliance-Analyse (Anhang II + III)
• Erweiterte Hochrisiko-Bewertung
• Risikomanagementsystem erforderlich?
• Konformitätsbewertung erforderlich?
• Notified-Body-Einbindung notwendig?

Mögliche Ergebnisse:

• ✅ Freigabefähig (mit umfangreichen Auflagen) → Standard-Pfad
• ⚠️ HOLD (bis Risk-Mitigations umgesetzt) → zurück zu Schritt 1 für Anpassungen
• ❌ STOP (nicht beherrschbar) → Prozess endet

Outputs

• ✅ Prozessstatus: „S2 Risk Assessment"
• ✅ Gate-Felder gesetzt (SOP / AI-Act / Hochrisiko)
• ✅ Dokument 02 (Pre-Assessment) vollständig
• ✅ Blocker-Status dokumentiert
• ✅ Routing-Entscheidung getroffen (Fast-Track / Standard / Vollprüfung / STOP)

Rechtliche Grundlagen

• EU AI Act (Art. 5 – Verbotene Praktiken, Art. 6 + Anhang III – High-Risk)
• DSGVO (Art. 5, 6, 9, 22)
• BetrVG (§§ 87, 94)
• RBV KI (Abschnitt 3, Seite 3) – Hochrisiko-Verbot

---

Schritt 3 – Datenschutzprüfung

Zweck

Sicherstellen, dass der Use Case rechtskonform nach DSGVO ist, Risiken beherrschbar sind und ggf. eine Datenschutz-Folgenabschätzung (DSFA) durchgeführt wird.

SLA

5 Arbeitstage (typisch 3-5 Tage, bei DSFA-Erfordernis 7-10 Tage)

Verantwortlichkeiten

• DSB (Datenschutzbeauftragter): Rechtskonformität prüfen, DSFA-Notwendigkeit bewerten
• KI-Manager: Koordination, Nachverfolgung
• Rechtsabteilung: Unterstützung bei Rechtsgrundlagen
• Use-Case-Owner: Zulieferung von Detailinformationen

Erforderliche Daten

Folgende Informationen werden in diesem Schritt geprüft bzw. gesetzt:

Datenfeld	Beschreibung	Wertebereich
Personenbezogene Daten	Werden personenbezogene Daten verarbeitet?	Nein / Möglich / Ja
Datenklasse	Art der verarbeiteten Daten	Keine / Allgemein / Besondere Kategorien (Art. 9)
Beschäftigungskontext	Betrifft der Use Case Mitarbeiterdaten?	Nein / Indirekt / Ja
Überwachung / Profiling	Werden Personen überwacht oder bewertet?	Nein / Möglich / Ja
DSFA erforderlich	Muss eine Datenschutz-Folgenabschätzung durchgeführt werden?	Ja / Nein
Blocker-Status	Hindernisse für Freigabe	STOP / HOLD / Kein Blocker
Prozessstatus	Aktueller Prozessschritt	„S3 Datenschutz"

Prüfumfang

A) Rechtsgrundlage (Art. 6 DSGVO bzw. § 26 BDSG)

Prüfung, ob eine Rechtsgrundlage für die Datenverarbeitung vorliegt:

• Art. 6 Abs. 1 lit. a (Einwilligung)
• Art. 6 Abs. 1 lit. b (Vertragserfüllung)
• Art. 6 Abs. 1 lit. f (Berechtigtes Interesse)
• § 26 BDSG (Beschäftigungsverhältnis)

Bei besonderen Kategorien (Art. 9) ist eine zusätzliche Rechtsgrundlage erforderlich:

• Art. 9 Abs. 2 lit. b (Arbeitsrecht)
• Art. 9 Abs. 2 lit. a (explizite Einwilligung)

B) DSGVO-Grundsätze (Art. 5)

• Zweckbindung: Verarbeitung nur für definierten Zweck
• Datenminimierung: Nur notwendige Daten
• Speicherbegrenzung: Löschkonzept vorhanden
• Richtigkeit: Mechanismus zur Datenaktualisierung
• Integrität & Vertraulichkeit: Technische Maßnahmen (siehe Schritt 4)

C) DSFA-Prüfung (Art. 35 DSGVO)

Eine DSFA ist erforderlich bei:

• Systematischer Bewertung persönlicher Aspekte (Profiling)
• Umfangreicher Verarbeitung bes. Kategorien (Art. 9)
• Systematischer Überwachung öffentlich zugänglicher Bereiche
• Hohem Risiko für Rechte & Freiheiten (Blacklist DSK)

DSFA-Ablauf (falls erforderlich):

1. Beschreibung der Verarbeitungsvorgänge
2. Bewertung der Notwendigkeit & Verhältnismäßigkeit
3. Risikoanalyse (Eintrittswahrscheinlichkeit × Schwere)
4. Abhilfemaßnahmen (TOMs)
5. Dokumentation im DSFA-Bericht

D) Betroffenenrechte & Informationspflichten

• Information nach Art. 13/14 DSGVO vorbereitet
• Prozess für Auskunft (Art. 15), Löschung (Art. 17), Widerspruch (Art. 21)
• Bei automatisierten Entscheidungen (Art. 22): Widerspruchsrecht & menschliche Überprüfung

E) Auftragsverarbeitung (Art. 28 DSGVO)

• Liegt Auftragsverarbeitung vor? (wird in Schritt 6 detailliert geprüft)
• AVV (Auftragsverarbeitungsvertrag) erforderlich?

Entscheidungslogik

Prüfergebnis	Blocker-Status	Routing
Rechtsgrundlage fehlt	STOP	Prozess endet (keine rechtmäßige Verarbeitung möglich)
DSFA erforderlich & negativ	STOP	Risiko nicht beherrschbar
DSFA erforderlich & HOLD	HOLD	Bis Maßnahmen umgesetzt
Rechtskonform (ohne Auflagen)	Kein Blocker	→ Schritt 4
Rechtskonform (mit Auflagen)	Kein Blocker	Auflagen dokumentieren → Schritt 4

Outputs

• ✅ Prozessstatus: „S3 Datenschutz"
• ✅ Datenschutz-Felder validiert
• ✅ DSFA-Entscheidung dokumentiert
• ✅ Blocker-Status gesetzt
• ✅ Auflagen (falls vorhanden) dokumentiert

Artefakte:

• Datenschutz-Vermerk (strukturierte Dokumentation der Prüfergebnisse)
• DSFA-Bericht (falls erforderlich, separates Dokument)
• VVT-Eintrag (Verzeichnis von Verarbeitungstätigkeiten) aktualisiert

Rechtliche Grundlagen

• DSGVO (Art. 5, 6, 9, 13, 14, 15, 17, 21, 22, 28, 35)
• BDSG (§ 26 – Beschäftigtendatenschutz)
• DSK-Blacklist (Muss-Liste für DSFA)

---

Schritt 4 – IT-Security-Prüfung

Zweck

Sicherstellen, dass der Use Case technisch sicher betrieben werden kann und IT-Risiken beherrschbar sind.

SLA

5 Arbeitstage (typisch 3-5 Tage, bei komplexen Integrationen 7-10 Tage)

Verantwortlichkeiten

• IT-Security-Team: Sicherheitsbewertung, Controls definieren
• IT-Abteilung: Technische Machbarkeit, Architektur-Review
• KI-Manager: Koordination
• Use-Case-Owner: Zulieferung technischer Details

Erforderliche Daten

Folgende Informationen werden in diesem Schritt validiert bzw. gesetzt:

Datenfeld	Beschreibung	Wertebereich
Blocker-Status	Hindernisse für Freigabe	STOP / HOLD / Kein Blocker
Prozessstatus	Aktueller Prozessschritt	„S4 Security"

ℹ️ Hinweis: Systemtyp, Autonomiegrad, Integrationsgrad und Externe Weitergabe werden bereits in Schritt 1 (Risk-Scoring) erfasst und müssen hier nicht erneut validiert werden.

Prüfumfang

A) Zugriffskontrolle & Identitätsmanagement

• Least-Privilege-Prinzip: Nur notwendige Berechtigungen
• SSO / MFA: Single Sign-On & Multi-Faktor-Authentifizierung
• Rollenkonzept: Definierte Benutzerrollen & Berechtigungen
• Audit-Logging: Zugriffe & Aktionen protokolliert

B) Technische Sicherheitsmaßnahmen

• Verschlüsselung:
  • TLS 1.3 für Datenübertragung
  • Verschlüsselung at rest (falls personenbezogene Daten)
• API-Sicherheit:
  • API-Keys / Token-Management
  • Rate-Limiting & Input-Validation
• Network Security:
  • Firewall-Regeln
  • IP-Whitelisting (falls erforderlich)

C) Data Loss Prevention (DLP) – Technische Maßnahmen

• Copy/Paste-Kontrolle: Bei sensiblen Daten
• Export-Logs: Audit-Trail bei Datenexport
• Verschlüsselung: Bei externer Weitergabe

D) Monitoring & Incident-Management

• Security-Monitoring: Logging & Alerting
• Incident-Response-Plan: Wer wird bei Sicherheitsvorfällen informiert?
• Rollback-Mechanismus: Können Aktionen rückgängig gemacht werden?
• Vulnerability-Scans: Penetration-Tests (bei hohem Risiko)

Security Controls

Je nach Risikoeinschätzung werden Controls festgelegt:

Risikostufe	Typische Controls
Niedrig	• SSO/MFA • Basis-Logging • Jährliches Review
Mittel	+ Rollenkonzept + DLP-Regeln + Quartalsweises Review + Verschlüsselung (TLS 1.3)
Hoch	+ Read-only-Modus (wo möglich) + Human-in-the-Loop (kritische Aktionen) + Detailliertes Audit-Log + Monatliches Review + Penetration-Test

Entscheidungslogik

Prüfergebnis	Blocker-Status	Routing
Risiko nicht beherrschbar	STOP	Prozess endet
Controls fehlen & kritisch	HOLD	Bis Maßnahmen umgesetzt
Sicher (ohne Controls)	Kein Blocker	→ Schritt 5/6
Sicher (mit Controls)	Kein Blocker	Controls dokumentieren → Schritt 5/6

Outputs

• ✅ Prozessstatus: „S4 Security"
• ✅ Security-Controls definiert
• ✅ Blocker-Status gesetzt

Artefakte:

• Security-Vermerk (strukturierte Dokumentation der Prüfergebnisse)
• Liste erforderlicher Controls (wird in KI Check - Management-Entscheidung übernommen)

Rechtliche Grundlagen

• DSGVO (Art. 32 – Technische & organisatorische Maßnahmen)
• IT-Sicherheitsgesetz (IT-SiG)
• BSI-Grundschutz (falls anwendbar)

---

Schritt 5 – Betriebsrat / Mitbestimmung

Zweck

Prüfung, ob Mitbestimmungsrechte nach BetrVG betroffen sind und ggf. Abschluss einer Einzelanlage zur KI-Rahmenbetriebsvereinbarung.

SLA

7-10 Arbeitstage (abhängig von BR-Verfügbarkeit, ggf. 14 Tage bei Verhandlungen)

Verantwortlichkeiten

• HR / Personalabteilung: Federführung, BR-Kontakt
• Betriebsrat: Prüfung, Verhandlung, Freigabe/Ablehnung
• KI-Manager: Koordination, Dokumentation
• Use-Case-Owner: Detailinformationen liefern

Wann ist Schritt 5 erforderlich?

Betriebsrat-Prüfung ist verpflichtend, wenn mindestens eines der folgenden Kriterien zutrifft:

• Beschäftigungskontext = Ja (direkt HR-bezogen)
• Überwachung / Profiling = Ja (§ 87 Abs. 1 Nr. 6 BetrVG)
• Leistungs- oder Verhaltenskontrolle möglich (§ 87 Abs. 1 Nr. 6 BetrVG)
• Automatisierte Personalauswahl / -bewertung (§ 95 BetrVG)

Wenn keines zutrifft: Schritt 5 wird übersprungen (nur Information an BR)

Erforderliche Daten

Folgende Informationen werden in diesem Schritt gesetzt:

Datenfeld	Beschreibung	Wertebereich
BR-Trigger	Ist BR-Prüfung erforderlich?	Ja / Nein
BR-Freigabe	Status der Betriebsrat-Prüfung	Ausstehend / Freigegeben / Freigegeben mit Auflagen / Abgelehnt
Blocker-Status	Hindernisse für Freigabe	STOP / HOLD / Kein Blocker
Prozessstatus	Aktueller Prozessschritt	„S5 BR"

Prüfumfang

A) Mitbestimmungstatbestand klären

• § 87 Abs. 1 Nr. 6 BetrVG: Überwachung von Verhalten/Leistung?
• § 94 BetrVG: Personalfragebogen, Beurteilungsgrundsätze?
• § 95 BetrVG: Auswahlrichtlinien (Ein-/Umgruppierung, Versetzung)?

B) KI-Rahmenbetriebsvereinbarung (RBV) anwenden

Die RBV KI regelt:

• Verbotene Praktiken (Abschnitt 3)
• Hochrisiko-Fälle (Anhang III AI Act)
• Transparenzpflichten
• Verfahren für Einzelanlagen

Vorgehen:

1. Prüfen, ob Use Case unter RBV fällt
2. Falls ja: Einzelanlage (KI Check - Einzelanlage zur KI-RBV) erstellen
3. BR-Freigabe einholen

C) Einzelanlage erstellen (KI Check - Einzelanlage zur KI-RBV)

„KI Check - Einzelanlage zur KI-RBV"

Inhalt:

• Zweck: Konkrete Beschreibung des KI-Systems
• Verweis auf Vorprüfungen: Use-case-Steckbrief, DSFA, Security-Assessment
• Systemdetails: Name, Anbieter, Einsatzbereiche, Skalierung, Systemtyp, Autonomie, Integration
• Zulässiger Nutzungszweck: Kurzbeschreibung (Verweis auf Steckbrief)
• Ausdrückliche Ausschlüsse:
  • Keine Leistungs-/Verhaltensbewertung von Mitarbeitern
  • Keine automatisierten Einzelentscheidungen (Art. 22 DSGVO)
  • Kein Scoring/Ranking von Mitarbeitern
  • Sonstige ausgeschlossene Nutzungen
• Art der Nutzung gem. Art. 22 DSGVO:
  • Human-in-the-Loop (Mensch entscheidet final)
  • Teilautomatisiert (mit ausdrücklicher Zustimmung)
• Transparenz- & Informationspflichten: Verweis auf RBV und DSGVO-Informationspflichten

D) BR-Freigabe einholen

• Einzelanlage an BR übermitteln
• Präsentationstermin (optional)
• BR prüft & entscheidet:
  • ✅ Freigegeben → Prozess läuft weiter
  • ⚠️ Freigegeben mit Auflagen → Auflagen dokumentieren & umsetzen
  • 🔄 Verhandlung → HOLD (bis Einigung)
  • ❌ Abgelehnt → STOP

Entscheidungslogik

BR-Ergebnis	Blocker-Status	Routing
BR nicht erforderlich	-	Info an BR, → Schritt 6
Freigegeben	Kein Blocker	→ Schritt 6
Freigegeben mit Auflagen	Kein Blocker	Auflagen dokumentieren → Schritt 6
Verhandlung läuft	HOLD	Bis Einigung erzielt
Abgelehnt	STOP	Prozess endet

Outputs

• ✅ Prozessstatus: „S5 BR"
• ✅ BR-Trigger validiert
• ✅ Falls erforderlich: KI Check - Einzelanlage zur KI-RBV erstellt & genehmigt
• ✅ BR-Freigabe dokumentiert
• ✅ Blocker-Status gesetzt
• ✅ Auflagen (falls vorhanden) dokumentiert

Artefakte:

• KI Check - Einzelanlage zur KI-RBV (Einzelanlage zur RBV KI) – falls BR-Trigger = Ja
• BR-Freigabe-Vermerk (strukturierte Dokumentation oder E-Mail/Protokoll)

Rechtliche Grundlagen

• BetrVG (§§ 87, 94, 95 – Mitbestimmungsrechte)
• DSGVO (Art. 22 – Automatisierte Entscheidungen)
• RBV KI (Rahmenbetriebsvereinbarung KI bei GEALAN) – Abschnitt 3: Verbote & Hochrisiko

---

Schritt 6 – Anbieter- & Vertragsprüfung

Zweck

Sicherstellen, dass der Use Case auf einer validen vertraglichen Grundlage steht, der Anbieter freigegeben ist und alle datenschutz- & sicherheitsrelevanten Vereinbarungen getroffen sind.

Warum erst nach den Fachprüfungen?
Die Anbieterprüfung erfolgt erst, nachdem alle fachlichen Anforderungen (Datenschutz, IT-Security, BR-Auflagen) bekannt sind. So werden Vertragsverhandlungen effizienter, da alle Anforderungen in einem Schritt geklärt werden können.

SLA

5 Arbeitstage (typisch 3-5 Tage, bei neuen Anbietern 7-10 Tage)

Verantwortlichkeiten

• Einkauf / Legal: Vertragsverhandlung, Freigabe
• DSB: AVV-Prüfung (Auftragsverarbeitungsvertrag)
• IT-Security: Sub-Processor-Prüfung, Datenort
• KI-Manager: Koordination

Erforderliche Daten

Folgende Informationen werden in diesem Schritt validiert bzw. gesetzt:

Datenfeld	Beschreibung	Wertebereich
Anbieterstatus	Freigabestatus des KI-Tool-Anbieters	Neu / Freigegeben / Mit Einschränkungen
Vertragscheck abgeschlossen	Wurde der Vertrag geprüft?	Ja / Nein
Blocker-Status	Hindernisse für Freigabe	STOP / HOLD / Kein Blocker
Prozessstatus	Aktueller Prozessschritt	„S6 Vertrag"

Prüfumfang

A) Anbieterstatus klären

Anbieter bereits freigegeben?

• Ja → Vertragsprüfung (B)
• Nein → Anbieter-Onboarding starten
• Mit Einschränkungen → Einschränkungen vs. Use Case abgleichen

Anbieter-Onboarding (bei neuen Anbietern):

1. Due Diligence:
   • Finanzielle Stabilität
   • Referenzen / Marktreputation
   • Compliance (GDPR, ISO 27001, SOC 2)
   • Sub-Processor-Liste
2. Master Agreement verhandeln
3. Freigabe durch Legal & Einkauf

B) Vertragsprüfung (bei bestehendem Anbieter)

• Gültiger Rahmenvertrag vorhanden?
• Use Case durch Vertrag abgedeckt?
  • Nutzungsumfang (Nutzeranzahl, Datenvolumen)
  • Geografische Beschränkungen
  • Nutzungsrechte (Commercial Use, API-Zugriff)
• Haftung & Garantien:
  • SLA (Service Level Agreement)
  • Verfügbarkeitsgarantien
  • Haftungsbeschränkungen akzeptabel?
• Kündigung & Exit:
  • Kündigungsfristen
  • Datenrückgabe / -löschung geregelt

C) Auftragsverarbeitungsvertrag (AVV) – falls Personendaten verarbeitet werden

AVV vorhanden & gültig?

AVV muss gem. Art. 28 DSGVO enthalten:

• Gegenstand & Dauer der Verarbeitung
• Art & Zweck der Verarbeitung
• Art der personenbezogenen Daten
• Kategorien betroffener Personen
• Pflichten & Rechte des Verantwortlichen
• Weisungsbefugnis des Verantwortlichen
• Vertraulichkeitsverpflichtungen
• Technische & organisatorische Maßnahmen (TOMs)
• Sub-Processor-Regelung (Genehmigungspflicht)
• Unterstützung bei Betroffenenanfragen
• Löschung / Rückgabe nach Vertragsende
• Prüfrechte des Verantwortlichen

D) Sub-Processor-Prüfung

• Liste der Sub-Processor angefordert
• Datenorte (Server-Standorte) geprüft:
  • EU/EWR → OK
  • UK, USA, Schweiz → Angemessenheitsbeschluss vorhanden?
  • Drittland ohne Angemessenheitsbeschluss → Standardvertragsklauseln (SCC)?
• Jeder Sub-Processor durch AVV abgedeckt

E) Spezifische Anforderungen aus Schritten 3-5 integrieren

• Datenschutz-Auflagen aus Schritt 3:
  • DSFA-Maßnahmen vertraglich vereinbart?
  • Löschfristen im Vertrag?
• Security-Controls aus Schritt 4:
  • SSO/MFA-Unterstützung vertraglich zugesichert?
  • Audit-Logging & Zugriffsprotokolle?
  • Penetration-Tests / Security-Audits?
• BR-Auflagen aus Schritt 5:
  • Transparenzpflichten (Welche Daten werden wo verarbeitet?)
  • Ausschlüsse (z.B. "Keine Nutzung für Leistungsbewertung")

Entscheidungslogik

Prüfergebnis	Blocker-Status	Routing
Anbieter nicht freigabefähig	STOP	Prozess endet
Vertrag fehlt / nicht verhandelbar	STOP	Prozess endet
AVV fehlt (bei Personendaten)	HOLD	Bis AVV vorliegt
Sub-Processor in unsicherem Drittland	HOLD	Bis SCC oder Alternative
Alles OK	Kein Blocker	→ Schritt 7
OK mit Auflagen (z.B. Nachverhandlung)	Kein Blocker	Auflagen dokumentieren → Schritt 7

Outputs

• ✅ Prozessstatus: „S6 Vertrag"
• ✅ Anbieterstatus validiert (Freigegeben / Mit Einschränkungen)
• ✅ Vertragscheck dokumentiert
• ✅ AVV vorhanden & geprüft (falls relevant)
• ✅ Blocker-Status gesetzt
• ✅ Auflagen (falls vorhanden) dokumentiert

Artefakte:

• Anbieter-Freigabe-Vermerk (strukturierte Dokumentation)
• Vertragsprüfungs-Checkliste (intern, Legal)
• AVV-Kopie (bei Personendaten, abgelegt in Vertragsmanagement)
• Sub-Processor-Liste (strukturierte Dokumentation)

Rechtliche Grundlagen

• DSGVO (Art. 28 – Auftragsverarbeitung, Art. 44-49 – Drittlandtransfer)
• Standardvertragsklauseln (SCC) der EU-Kommission
• Angemessenheitsbeschlüsse (UK, USA-DPF, Schweiz, …)

---

Schritt 7 – Management-Entscheidung

Zweck

Konsolidierung aller Prüfergebnisse und finale Entscheidung durch das Management (Freigabe / Freigabe mit Auflagen / Ablehnung).

SLA

3 Arbeitstage (typisch 1-3 Tage, bei Rückfragen bis 5 Tage)

Verantwortlichkeiten

• KI-Manager: Erstellt Entscheidungsvorlage (KI Check - Management-Entscheidung), präsentiert
• Management (Entscheider): Finale Entscheidung
  • Je nach Skalierung & Risiko:
    • Abteilungsleiter (Pilot, Low-Risk)
    • Bereichsleiter (Team/Bereich, Medium-Risk)
    • Geschäftsführung (Unternehmensweit, High-Risk)
• DSB, IT-Security, HR, Legal: Beratend (bei Rückfragen)

Erforderliche Daten

Folgende Informationen werden in diesem Schritt gesetzt:

Datenfeld	Beschreibung	Wertebereich
Genehmigungsstatus	Finale Entscheidung des Managements	Approved / ApprovedWithConditions / Rejected
Blocker-Status	Hindernisse für Freigabe	STOP bei Rejected, sonst Kein Blocker
Auflagen – Kurzfassung	Liste der verbindlichen Auflagen	Max. 8 Auflagen, je 1 Zeile
Review-Datum	Datum der nächsten Überprüfung	Datum (6-12 Monate nach Go-Live)
Prozessstatus	Aktueller Prozessschritt	„S7 Decision"

Vorbereitung: KI Check - Management-Entscheidung erstellen

„KI Check - Management-Entscheidung"

Struktur:

1. Referenzen:

   • Use-Case-ID / Titel
   • Geschäftsbereich, Tool/Anbieter
   • Anbieterstatus
   • Skalierungsgrad
   • Artefakt-Ordner

2. Kurzbeschreibung & Scope:

   • Use Case in 6 Zeilen (Input → Verarbeitung → Output)
   • Ausschlüsse (3 Bullet Points: Was ist nicht gemeint?)

3. Cockpit-Einordnung (Schnellübersicht):

   • SOP-Relevanz, Systemtyp, Autonomie, Integration
   • Personenbezogene Daten, Datenklasse
   • Beschäftigungskontext, Profiling
   • AI-Act-Verbot, Hochrisiko-Verdacht
   • Betriebsrat-Freigabe

4. Ergebnis-Summary:

   • Vertrag / Anbieter: Status + Verweis
   • Datenschutz: Status + Verweis
   • IT-Security: Status + Verweis
   • Betriebsrat: Status + Verweis

5. Auflagen (max. 8, priorisiert & verifizierbar):

   • Jede Auflage mit Owner & Deadline
   • Beispiel: "AVV bis 31.03.2026 abschließen (Legal, Q1/26)"

6. Entscheidungsempfehlung (vom KI-Manager):

   • Farbe: ✅ Grün (Approved) / ⚠️ Gelb (Approved with Conditions) / ❌ Rot (Rejected)
   • Begründung (5 Bullet Points)
   • Ersteller, Datum

7. Finale Entscheidung (vom Management):

   • Farbe: ✅ Grün / ⚠️ Gelb / ❌ Rot
   • Begründung (optional, falls abweichend)
   • Review-Datum
   • Entscheider, Funktion, Datum, Unterschrift

Entscheidungslogik

Management-Entscheidung	Status	Blocker	Routing
✅ Approved	Approved	Kein Blocker	→ Schritt 8 (Go-Live)
⚠️ Approved with Conditions	ApprovedWithConditions	Kein Blocker	Auflagen in Change-Mgmt. → Schritt 8
❌ Rejected	Rejected	STOP	Prozess endet

Outputs

• ✅ Prozessstatus: „S7 Decision"
• ✅ Genehmigungsstatus gesetzt
• ✅ KI Check - Management-Entscheidung signiert
• ✅ Auflagen (falls vorhanden) dokumentiert
• ✅ Review-Datum gesetzt
• ✅ Blocker-Status gesetzt

Artefakte:

• KI Check - Management-Entscheidung (Entscheidungsvorlage – KI-Freigabe) – vollständig ausgefüllt & unterschrieben

Rechtliche Grundlagen

• Alle Gesetze/Verordnungen aus Schritten 1-6 (DSGVO, AI Act, BetrVG, RBV)
• Geschäftsordnung (Entscheidungsbefugnisse)

---

Schritt 8 – Betrieb & Review

Zweck

Sicherstellen, dass der freigegebene Use Case im laufenden Betrieb compliant bleibt, Auflagen umgesetzt werden und bei Änderungen (Scope-Drift, neue Risiken) ein Re-Check ausgelöst wird.

SLA

• Go-Live-Vorbereitung: 5-10 Arbeitstage (Auflagen umsetzen)
• Review-Zyklus: 6-12 Monate (je nach Risk-Score & Auflagen)

Verantwortlichkeiten

• Use-Case-Owner: Betrieb, Auflagen-Umsetzung
• KI-Manager: Review-Koordination, Re-Check-Trigger-Prüfung
• DSB, IT-Security, HR: Review-Teilnahme (je nach Relevanz)

Erforderliche Daten

Folgende Informationen werden in diesem Schritt aktualisiert:

Datenfeld	Beschreibung	Wertebereich
Betriebsstatus	Status des Use Case im Betrieb	In Betrieb / Pausiert / Beendet
Review-Datum	Datum der nächsten Überprüfung	Datum (6-12 Monate)
Prozessstatus	Aktueller Prozessschritt	„S8 Review"

Prüfumfang: Drei Phasen

Phase A: Go-Live-Vorbereitung

Vor dem Go-Live müssen alle Auflagen aus Schritt 7 umgesetzt sein:

Typische Aufgaben:

• AVV unterschrieben & abgelegt
• SSO/MFA aktiviert
• DLP-Regeln konfiguriert
• Human-in-the-Loop-Workflow implementiert
• Mitarbeiter-Information (DSGVO Art. 13) versendet
• BR-Einzelanlage (KI Check - Einzelanlage zur KI-RBV) unterschrieben
• Schulungen durchgeführt
• Monitoring-Dashboard aufgesetzt

Checkliste vor Go-Live:

• Alle Auflagen aus KI Check - Management-Entscheidung umgesetzt? (Status: ✅ Erledigt)
• Betriebsstatus auf „In Betrieb" setzen
• Review-Datum in Kalender eintragen
• Use-Case-Owner informiert & geschult

Phase B: Laufender Betrieb

Kontinuierliches Monitoring:

• Nutzungszahlen (Wer nutzt das Tool? Wie oft?)
• Fehlerrate / False Positives
• Security-Incidents
• Datenschutz-Vorfälle

Change-Management:

• Neue Features / Updates vom Anbieter → Re-Check-Trigger prüfen
• Scope-Erweiterungen → Re-Check-Trigger prüfen
• Neue Integration → Re-Check-Trigger prüfen

Phase C: Review-Zyklus

Review-Termin (6-12 Monate nach Go-Live):

Prüfung:

1. Auflagen-Compliance: Sind alle Auflagen weiterhin erfüllt?
2. Scope-Adherence: Wird das Tool nur für den freigegebenen Zweck genutzt?
3. Drift-Detection: Neue Datenarten, Nutzergruppen, Automatisierungsgrade, Integrationen?
4. Incident-Review: Sicherheitsvorfälle, Datenschutz-Beschwerden, BR-Beschwerden?
5. Anbieter-Status: Anbieter weiterhin freigegeben, Sub-Processor-Liste aktualisiert?

Re-Check-Trigger-Matrix

Wann wird ein Re-Check (Rückkehr zu Schritt 2) ausgelöst?

Änderung	Re-Check-Level	Rückkehr zu Schritt
Neue Datenarten (z.B. plötzlich bes. Kategorien)	Vollständig	→ Schritt 2
Neue Integration (Write-Access)	Vollständig	→ Schritt 2
HR-Kontext neu hinzugekommen	Vollständig	→ Schritt 2 (+ BR-Prüfung)
Anbieter-Wechsel	Vollständig	→ Schritt 6
Zweck-Änderung (anderer Use Case)	Vollständig	→ Schritt 1 (neu formalisieren)
Skalierung (Pilot → Unternehmensweit)	Partiell	→ Schritt 2 (Risk-Score neu)
Externe Weitergabe neu	Vollständig	→ Schritt 2
Kleinere Anpassungen (z.B. UI-Update)	Kein Re-Check	Dokumentieren, weiter monitoren

Review-Ergebnis

Ergebnis	Betriebsstatus	Aktion
Alles OK	In Betrieb	Nächstes Review-Datum setzen (6-12 Monate)
Kleinere Abweichungen	In Betrieb	Korrekturmaßnahmen definieren (nicht-blockierend)
Auflagen nicht erfüllt	Pausiert	HOLD bis Auflagen nachgeholt
Wesentliche Änderungen	Pausiert	Re-Check auslösen (→ Schritt 2)
Nicht mehr benötigt	Beendet	Ordentliches Off-Boarding

Outputs

• ✅ Prozessstatus: „S8 Review"
• ✅ Betriebsstatus aktualisiert
• ✅ Review-Protokoll dokumentiert
• ✅ Falls Re-Check erforderlich: Prozess zurück zu Schritt 2
• ✅ Nächstes Review-Datum gesetzt

Artefakte:

• Review-Protokoll (strukturierte Dokumentation)
• Aktualisiertes KI Check - Management-Entscheidung (falls Auflagen ergänzt wurden)

Rechtliche Grundlagen

• DSGVO (Art. 5 Abs. 2 – Rechenschaftspflicht / Accountability)
• ISO 27001 (Kontinuierliches Monitoring)
• RBV KI (kontinuierliche Compliance-Prüfung)

---

Zusammenfassung der Optimierungen (V3.2 vs. V3.1)

Aspekt	V3.1	V3.2	Verbesserung
Schritt 4 - Erforderliche Daten	7 Felder (inkl. Systemtyp, Autonomie, Integration, Externe Weitergabe)	2 Felder (nur Blocker-Status, Prozessstatus)	Keine Redundanz (Felder bereits in S1)
Schritt 4 - Prüfumfang	Punkte B/C enthielten funktionale Aspekte (Integration & Datenfluss, Aktionen & Human-in-the-Loop)	Fokus auf technische Security (Verschlüsselung, API-Security, Monitoring, Incident-Management)	Klare Trennung: Funktion (S1) vs. Security (S4)
Dokumentcharakter	Reine Prozessdoku	Reine Prozessdoku	Unverändert

---

Referenzierte Dokumente & Vorlagen

Im Hub verfügbar:

1. KI Check - Use-case-Steckbrief

   • Formular für Schritt 1: Formalisierung & Risk-Scoring

2. KI Check - Einzelanlage zur KI-RBV

   • Formular für Schritt 5: Betriebsrat / Mitbestimmung

3. KI Check - Management-Entscheidung

   • Formular für Schritt 7: Management-Entscheidung

4. neu_KI-Check_Felder_checked.xlsx

   • Vollständige Feldliste mit Beschreibungen

5. Rahmenbetriebsvereinbarung KI bei GEALAN

   • Rechtliche Grundlage für Hochrisiko-Verbote (Abschnitt 3)

6. KI Check - Handbuch - Auszug 10 Schritte

   • Praktische Hinweise, Beispiele, häufige Fehler (ausgelagert aus Prozessdoku)

---

Dokument-Freigabe

Erstellt von: KI-Manager
Geprüft von: DSB, IT-Security, HR, Legal
Freigegeben von: Geschäftsführung
Datum: 17.02.2026
Version: 3.2
Status: Freigegeben

---

Ende der Prozessdokumentation

---

Änderungsdokumentation V3.2

Wesentliche Änderungen gegenüber V3.1:

Schritt 4 – IT-Security-Prüfung

Problem: Redundanz zwischen Schritt 1 (Risk-Scoring) und Schritt 4 (IT-Security)

Änderungen:

Schritt 1 – Formalisierung & Risk-Scoring:

• ✅ Systemtyp hinzugefügt (Zeile 153): "Art der KI-Unterstützung" (Assistierend / Entscheidungsunterstützung / Semi-automatisch)

Schritt 4 – IT-Security-Prüfung:

1. Tabelle "Erforderliche Daten" (Zeilen 439-447):

   • ❌ Entfernt: Systemtyp, Autonomiegrad, Integrationsgrad, Intern veröffentlicht, Externe Weitergabe
   • ✅ Beibehalten: Blocker-Status, Prozessstatus
   • ℹ️ Neu: Hinweis-Box "Diese Felder werden bereits in Schritt 1 erfasst"

2. Prüfumfang (Zeilen 447-480):

   • ❌ Entfernt: Abschnitt B) Integration & Datenfluss
   • ❌ Entfernt: Abschnitt C) Aktionen & Human-in-the-Loop
   • ❌ Entfernt: Abschnitt C) Cloud & Datenspeicherung (gehört zu Schritt 6)
   • ✅ Neu strukturiert:
     • A) Zugriffskontrolle & Identitätsmanagement (unverändert)
     • B) Technische Sicherheitsmaßnahmen (Verschlüsselung, API-Security, Network Security)
     • C) Data Loss Prevention – Technische Maßnahmen (fokussiert)
     • D) Monitoring & Incident-Management (erweitert)

3. Output "Integration/Autonomie/Systemtyp validiert" entfernt

Rationale:

• Systemtyp wird nun in Schritt 1 erfasst (als Kontextinformation, nicht für Risk-Scoring)
• Autonomie, Integration und externe Weitergabe sind bereits in Schritt 1 (Risk-Scoring-Matrix) enthalten
• Schritt 4 fokussiert nun ausschließlich auf technische Sicherheitsmaßnahmen (Zugriffskontrolle, Verschlüsselung, DLP, Monitoring, Incident-Management)
• Cloud & Datenspeicherung (Datenort, Sub-Processor) werden in Schritt 6 (Anbieter & Vertrag) geprüft
• Klarere Trennung: Schritt 1 = Funktionale Klassifizierung, Schritt 4 = Technische Security, Schritt 6 = Vertragliche & Datenort-Aspekte �����������������������������������������������������������������������������������������������������������������������������������������������������������������������