Skip to main content

KI-Check Handbuch – Der 8-Schritte-Prozess

GEALAN Fenster-Systeme GmbH
Stand: 17.02.2026 | Version: 3.3 | Status: Freigegeben

Wie dieses Handbuch aufgebaut ist​

Dieses Prozess-Handbuch beschreibt die acht Schritte des KI-Checks detailliert und praxisnah. Jeder Schritt folgt der gleichen Struktur:

📋 Worum geht's? – Zweck und Ziel des Schritts
🎯 Was wird geprüft? – Konkrete Prüfkriterien und Anforderungen
👥 Wer ist beteiligt? – Rollen und Verantwortlichkeiten
📝 Welche Dokumente entstehen? – Artefakte und Outputs
⚙️ Wie läuft es ab? – Ablauf, Tools, Methoden
⚠️ Stolpersteine & Lösungen – Typische Probleme und wie man sie vermeidet
✅ Checkliste – Was muss erledigt sein, bevor es weitergeht?

Prozess-Übersicht: Die 8 Schritte im Überblick​

Schritt 1 – Formalisierung & Risk-Scoring​

📋 Worum geht's?​

In diesem ersten Schritt verwandeln Sie Ihre KI-Idee in einen strukturiert dokumentierten Use Case. Aus „Wir wollen mal ChatGPT ausprobieren" wird ein präziser Steckbrief mit allen relevanten Informationen: Was genau soll die KI tun? Welche Daten werden verarbeitet? Wer nutzt sie? Wie ist sie integriert?

Das Herzstück dieses Schritts ist das Risk-Scoring: Anhand von sechs objektiven Kriterien wird ein Risikowert zwischen 6 und 18 Punkten berechnet. Dieser Score entscheidet automatisch, welchen Prüfpfad Ihr Use Case durchläuft:

  • Score 6-9 (Low-Risk): Fast-Track – schneller Quick-Check, ~10-15 Tage
  • Score 10-14 (Medium-Risk): Standard – vollständige Prüfung, ~4-6 Wochen
  • Score 15-18 (High-Risk): Full Review – intensive Prüfung mit STOP-Gate, ~6-8 Wochen

Wichtig: In Schritt 1 wird nur die technische Risikobewertung durchgeführt. Die rechtliche Zulässigkeitsprüfung (Ist die Anwendung überhaupt erlaubt? Verstößt sie gegen EU AI Act Art. 5 oder RBV §3?) erfolgt erst in Schritt 2. Dieser Schritt fragt: „Wie riskant ist der Use Case technisch?" – nicht: „Ist er verboten?"

Abgrenzung zu Schritt 2

Schritt 1 berechnet das technische Risiko (Daten, Integration, Reichweite).
Schritt 2 prüft die rechtliche Zulässigkeit (Verbote, Hochrisiko-KI, Mitbestimmungspflicht).

🎯 Was wird geprüft?​

Der Use-Case-Steckbrief erfasst 14 Pflichtfelder (7 allgemeine Informationen + 6 Risk-Scoring-Kriterien + 1 Kontextfeld "Systemtyp"), die vollständig ausgefüllt sein müssen, bevor der Risk-Score berechnet werden kann.

Allgemeine Informationen​

1. Titel des Use Case (max. 100 Zeichen)
Eine knappe, eindeutige Bezeichnung, die sofort klar macht, worum es geht.
✅ Gut: „Copilot für E-Mails mit Kundendaten im Vertrieb"
❌ Schlecht: „Copilot testen" (zu vage), „Microsoft 365 Copilot Enterprise Lizenz – Pilot Phase Q1 2026 für ausgewählte Vertriebsmitarbeiter zur Effizienzsteigerung" (zu lang)

2. Beschreibung des Use Case (max. 500 Zeichen)
Was macht die KI konkret? Beschreiben Sie den Ablauf: Input → Verarbeitung → Output.
✅ Beispiel: „Vertriebsmitarbeiter geben Kundenanfragen in Outlook ein. Copilot analysiert die E-Mail-Historie, schlägt eine Antwort vor und fügt relevante Produktinformationen ein. Der Mitarbeiter prüft, überarbeitet und versendet die E-Mail manuell."

3. Geschäftsbereich / Organisationseinheit
Welche Abteilung oder welches Team nutzt die KI?
Auswahl: HR, IT, Vertrieb, Marketing, Einkauf, Produktion, Logistik, Kundendienst, Management, Controlling, ...

4. Antragsteller / Use-Case-Owner
Wer ist verantwortlich für den Use Case? Name, E-Mail, Telefon.
Diese Person ist der zentrale Ansprechpartner und muss bei Rückfragen erreichbar sein.

5. Tool-Anbieter & Produktname
Welches konkrete Tool wird genutzt?
✅ Beispiel: „Microsoft Corporation – Microsoft 365 Copilot"
✅ Beispiel: „OpenAI – ChatGPT Enterprise"
❌ Schlecht: „KI-Tool" (zu vage)

6. Zweckkategorie
Was soll die KI tun? Auswahl: Text (Schreiben, Übersetzen, Zusammenfassen), Bild (Generierung, Bearbeitung), Audio (Transkription, Sprachsynthese), Video (Schnitt, Untertitel), Analyse (Datenauswertung, Reporting), Coding (Code-Generierung, Debugging), Recherche (Informationssuche), Automatisierung (Workflow, Prozesse).

7. Geplante Reichweite
Wie viele Personen werden die KI nutzen?
Auswahl: Pilot (1-5 Nutzer), Team (6-20), Bereich (21-100), Unternehmensweit (>100).

Starten Sie mit Pilot

Auch wenn Sie langfristig eine unternehmensweite Nutzung planen: Starten Sie immer als Pilot (1-5 Nutzer). Das senkt den Risk-Score, beschleunigt die Freigabe und ermöglicht iteratives Lernen. Nach erfolgreicher Testphase können Sie skalieren – dann ist ein Re-Check erforderlich.

8. Systemtyp (Kontextfeld)
Wie unterstützt die KI?
Auswahl: Assistierend (reine Vorschläge, keine Aktionen), Entscheidungsunterstützung (bereitet Entscheidungen vor), Semi-automatisch (führt Aktionen mit Human-in-the-Loop aus).

Hinweis: Systemtyp fließt NICHT in den Risk-Score ein

Systemtyp ist ein Kontextfeld zur besseren Einordnung des Use Case und dient der Dokumentation. Die Bewertung der Automatisierung erfolgt über Kriterium 9 (Autonomie) im Risk-Scoring.

Risk-Scoring-Kriterien (6 Kriterien à 1-3 Punkte)​

Die folgenden sechs Kriterien bilden die Basis für die Risikobewertung. Für jedes Kriterium wird eine Punktzahl von 1 (niedriges Risiko) bis 3 (hohes Risiko) vergeben. Der Gesamtscore ist die Summe aller sechs Werte.

9. Datenart – Welche Daten werden verarbeitet?

  • 1 Punkt: Keine personenbezogenen Daten (nur anonymisierte, aggregierte oder öffentliche Daten)
  • 2 Punkte: Personenbezogene Daten allgemein (Namen, E-Mail-Adressen, Kundennummern, Rechnungsadressen)
  • 3 Punkte: Besondere Kategorien nach Art. 9 DSGVO (Gesundheitsdaten, biometrische Daten, rassische/ethnische Herkunft, politische Meinungen, religiöse Überzeugungen, Gewerkschaftszugehörigkeit, sexuelle Orientierung)

Beispiel:
ChatGPT für allgemeine Brainstorming-Anfragen ohne GEALAN-Daten → 1 Punkt
Copilot für E-Mails mit Kundendaten → 2 Punkte
KI-gestützte Gesundheitsanalyse von Mitarbeitenden → 3 Punkte

10. Autonomie – Wie stark greift die KI in Entscheidungen ein?

  • 1 Punkt: Rein unterstützend (KI liefert Vorschläge, Mensch entscheidet und führt aus)
  • 2 Punkte: Teil-automatisiert (KI bereitet vor, Mensch genehmigt vor Ausführung – „Human-in-the-Loop")
  • 3 Punkte: Vollautomatisiert (KI trifft Entscheidungen und führt eigenständig aus, ohne vorherige menschliche Prüfung)

Beispiel:
ChatGPT schlägt Textentwurf vor, Mitarbeiter überarbeitet und veröffentlicht → 1 Punkt
Copilot erstellt E-Mail-Entwurf, Mitarbeiter klickt auf „Senden" → 2 Punkte
KI sortiert Bewerbungen automatisch aus und lehnt ab → 3 Punkte

Vollautomatisierte Entscheidungen über Personen sind verboten

DSGVO Art. 22 und RBV §3 verbieten vollautomatisierte Entscheidungen über Personen im HR-Kontext (Recruiting, Leistungsbewertung). Selbst wenn technisch möglich: Immer Human-in-the-Loop einbauen!

11. Integration – Wie tief ist die KI in Systeme integriert?

  • 1 Punkt: Stand-alone / Read-only (keine Schreibrechte auf Unternehmenssysteme; isoliert oder nur lesend)
  • 2 Punkte: Schreibzugriff auf ein System (KI kann Daten in einem System ändern oder erstellen, z.B. CRM-Einträge, E-Mails)
  • 3 Punkte: Multi-System-Integration (KI ist mit mehreren Systemen verbunden und synchronisiert Daten, z.B. ERP ↔ CRM ↔ HR-System)

Beispiel:
ChatGPT im Browser, keine Integrationen → 1 Punkt
Copilot mit Zugriff auf Outlook (E-Mails schreiben) → 2 Punkte
KI synchronisiert Daten zwischen ERP, CRM und HR-System → 3 Punkte

12. Reichweite – Wie viele Personen nutzen die KI?

  • 1 Punkt: Pilot (1-5 Nutzer)
  • 2 Punkte: Team/Bereich (6-100 Nutzer)
  • 3 Punkte: Unternehmensweit (>100 Nutzer)

Praktischer Hinweis: Die Reichweite bezieht sich auf die tatsächlichen Nutzer, nicht auf potenzielle. Wenn Sie ein Tool für 200 Mitarbeitende lizenzieren, aber nur 3 Personen im Pilot testen, gilt: 1 Punkt (Pilot).

13. HR-Kontext – Verarbeitet die KI Mitarbeiter- oder Bewerberdaten?

  • 1 Punkt: Kein HR-Bezug (keine Mitarbeiter- oder Bewerberdaten)
  • 2 Punkte: Allgemeine HR-Daten (Abwesenheitskalender, Kontaktdaten, Organigramme, Schulungsanmeldungen – nicht beurteilungsrelevant)
  • 3 Punkte: Beurteilungs-/bewerberrelevant (Leistungsbewertungen, Bewerbungsunterlagen, Kompetenzprofile, Feedbackdaten – entscheidungsrelevant für Einstellung, Beförderung, Kündigung)

Beispiel:
ChatGPT für Marketing-Texte → 1 Punkt
Copilot erstellt Meeting-Zusammenfassung mit Teilnehmerliste → 2 Punkte
KI bewertet Kandidaten anhand von CVs → 3 Punkte (und RBV §3 verboten)

14. Externe Weitergabe – Verlassen Daten das Unternehmen?

  • 1 Punkt: Nur intern (Daten bleiben bei GEALAN, keine Weitergabe an Dritte)
  • 2 Punkte: An Vertragspartner (Daten gehen an Kunden, Lieferanten oder Geschäftspartner im Rahmen vertraglicher Beziehungen)
  • 3 Punkte: Öffentlich (KI-Ergebnisse werden veröffentlicht – Website, Social Media, öffentliche Dokumente)

Beispiel:
ChatGPT für interne Notizen → 1 Punkt
Copilot erstellt Kundenberichte per E-Mail → 2 Punkte
KI generiert Social-Media-Posts → 3 Punkte

Risk-Score: Berechnung & Routing​

Der Gesamtscore ist die Summe der sechs Kriterien:

Score = Datenart + Autonomie + Integration + Reichweite + HR-Kontext + Externe Weitergabe

Möglicher Wertebereich: 6 Punkte (minimales Risiko) bis 18 Punkte (höchstes Risiko).

Basierend auf dem Score erfolgt die automatische Routing-Entscheidung:

Risk-ScoreRoutingSLA (Gesamt)Prüfpfad
6-9 PunkteFast-Track~10-15 TageS1 → S2 (Quick-Check) → S7 (Management) → S8 (Betrieb)
10-14 PunkteStandard~4-6 WochenS1 → S2 (Gate) → S3/S4/S5 (parallel) → S6 (Anbieter) → S7 → S8
15-18 PunkteFull Review~6-8 WochenS1 → S2 (STOP-Gate) → S3/S4/S5 (vertieft) → S6 → S7 → S8 (meist: STOP in S2)
Fast-Track-Kriterien

Auch wenn der Score 6-9 Punkte beträgt, kann der Fast-Track nur genutzt werden, wenn alle der folgenden Bedingungen erfüllt sind:

  • ✅ Keine besonderen Kategorien (Art. 9 DSGVO)
  • ✅ Kein HR-Kontext (Kriterium 13 = 1 Punkt)
  • ✅ Keine vollautomatisierten Entscheidungen (Kriterium 10 ≤ 2 Punkte)
  • ✅ Kein Schreibzugriff auf mehrere Systeme (Kriterium 11 ≤ 2 Punkte)
  • ✅ Keine öffentliche Weitergabe (Kriterium 14 ≤ 2 Punkte)

Wenn auch nur eine Bedingung nicht erfüllt ist, rutscht der Use Case in den Standard-Pfad – selbst bei niedrigem Score.

👥 Wer ist beteiligt?​

Use-Case-Owner / Antragsteller:
Die Person oder das Team, das den Use Case nutzen möchte. Sie füllen den Use-Case-Steckbrief aus (Felder 1-14). Sie kennen den Business-Kontext am besten und müssen alle Fragen wahrheitsgemäß beantworten – denn das Risk-Scoring basiert auf diesen Angaben.

KI-Manager:
Koordiniert den Prozess, prüft die Vollständigkeit des Steckbriefs, berechnet den Risk-Score (meist automatisiert im SharePoint-Cockpit) und legt den Routing-Pfad fest. Der KI-Manager ist die zentrale Anlaufstelle bei Fragen oder Unklarheiten.

Datenschutzbeauftragte:r (DSB) & IT-Security:
Werden in Schritt 1 informiert, aber nicht aktiv eingebunden. Ihre Prüfung erfolgt erst in Schritt 3 (Datenschutz) und Schritt 4 (IT-Security) – oder bei Fast-Track in Schritt 2 (Quick-Check).

Kontakt zum KI-Manager

Bei Unsicherheiten beim Ausfüllen des Steckbriefs: Kontaktieren Sie frühzeitig den KI-Manager ([ki-manager@gealan.de]). Ein kurzes Telefonat (5-10 Minuten) kann Rückfragen vermeiden und die Bearbeitung beschleunigen.

📝 Welche Dokumente entstehen?​

Primäres Artefakt: KI Check – Use-Case-Steckbrief

Dieses Dokument (früher: „Dokument 01") ist das zentrale Artefakt von Schritt 1. Es enthält:

  • Alle 14 Pflichtfelder (Titel, Beschreibung, Geschäftsbereich, Antragsteller, Anbieter, Zweck, Reichweite, Systemtyp)
  • Die Bewertung der sechs Risk-Scoring-Kriterien (je 1-3 Punkte)
  • Den berechneten Gesamtscore (6-18 Punkte)
  • Die Routing-Entscheidung (Fast-Track / Standard / Full Review)
  • Prozessstatus: „S1 – Formalisierung & Risk-Scoring"
  • Zeitstempel: Wann wurde der Steckbrief erstellt?

Speicherort: SharePoint-Cockpit (zentrale Ablage für alle KI-Checks).
Zugriff: Use-Case-Owner, KI-Manager, DSB, IT-Security, Betriebsrat (je nach Prozessschritt).
Format: Strukturiertes SharePoint-Formular (automatisiert befüllte Felder) oder Word-Template (bei Bedarf).

⚙️ Wie läuft es ab?​

Ablauf im Detail​

1. Use-Case-Owner füllt den Steckbrief aus
Der Antragsteller öffnet das SharePoint-Formular (oder Word-Template) und beantwortet alle 14 Pflichtfelder. Besonders wichtig: Die sechs Risk-Scoring-Kriterien (9-14) müssen ehrlich und präzise bewertet werden.

Typische Bearbeitungszeit: 20-30 Minuten (bei klaren Use Cases), bis zu 1 Stunde (bei komplexen Integrationen oder unklaren Datenflüssen).

2. Use-Case-Owner reicht den Steckbrief ein
Nach Fertigstellung wird der Steckbrief im SharePoint-Cockpit gespeichert und an den KI-Manager weitergeleitet. Status: „Eingereicht, warte auf Validierung".

3. KI-Manager prüft Vollständigkeit
Der KI-Manager prüft, ob alle Pflichtfelder ausgefüllt sind und ob die Angaben plausibel sind. Typische Fragen:

  • Ist die Beschreibung konkret genug? („Wir wollen Copilot nutzen" ist zu vage – Was genau soll Copilot tun?)
  • Sind die Risk-Scoring-Bewertungen nachvollziehbar? (Wenn der Use Case als „keine personenbezogenen Daten" markiert ist, aber Kundendaten verarbeitet werden, stimmt etwas nicht.)
  • Fehlen wichtige Informationen? (Z.B. Anbieter genannt, aber kein Produktname.)

Wenn Lücken oder Widersprüche gefunden werden: Der KI-Manager kontaktiert den Use-Case-Owner per E-Mail oder Telefon und bittet um Nachbesserung. Status: „Zurück zur Bearbeitung".

Wenn alles OK ist: Weiter zu Schritt 4.

4. Risk-Score wird berechnet
Im SharePoint-Cockpit wird der Score automatisch berechnet (Summe der Kriterien 9-14). Der Score und die Routing-Entscheidung werden im Steckbrief dokumentiert.

5. Routing-Pfad wird festgelegt
Basierend auf dem Score und den Fast-Track-Kriterien entscheidet das System (oder der KI-Manager manuell), welchen Pfad der Use Case nimmt:

  • Fast-Track (6-9 Punkte + Kriterien erfüllt): Weiter zu Schritt 2 (Quick-Check)
  • Standard (10-14 Punkte): Weiter zu Schritt 2 (Standard-Gate)
  • Full Review (15-18 Punkte): Weiter zu Schritt 2 (High-Risk-Gate mit STOP-Verdacht)

6. Use-Case-Owner wird informiert
Der Use-Case-Owner erhält eine automatisierte E-Mail mit dem Ergebnis:

„Ihr Use Case ‚Copilot für E-Mails' wurde mit einem Risk-Score von 12 Punkten bewertet. Routing: Standard-Prozess (~4-6 Wochen SLA). Nächster Schritt: Risk-Assessment & Gate (Schritt 2). Sie werden informiert, sobald die Prüfung abgeschlossen ist."

7. Übergang zu Schritt 2
Der Use-Case-Steckbrief wird an die Prüfer in Schritt 2 weitergeleitet (KI-Manager, DSB, IT-Security, ggf. Betriebsrat). Status: „S2 – Risk-Assessment & Gate".

Tools & Hilfsmittel​

SharePoint-Cockpit:
Zentrale Plattform für den gesamten KI-Check. Enthält:

  • Formular für Use-Case-Steckbrief (mit Pflichtfeldern, Dropdown-Menüs, automatisiertem Risk-Scoring)
  • Dashboard für KI-Manager (Übersicht aller laufenden Use Cases, SLA-Überwachung, Eskalationen)
  • Workflow-Automatisierung (Status-Updates, E-Mail-Benachrichtigungen, Fristenerinnerungen)

Word-Template (Fallback):
Falls SharePoint nicht verfügbar ist, gibt es ein Word-Template für den Use-Case-Steckbrief. Dieses muss manuell ausgefüllt und per E-Mail an den KI-Manager gesendet werden. Der KI-Manager überträgt die Daten dann ins SharePoint-Cockpit.

Risk-Scoring-Matrix (Spickzettel):
Ein einseitiges PDF mit der kompakten 6×3-Matrix und kurzen Erklärungen zu jedem Kriterium. Hilft beim Ausfüllen des Steckbriefs.

⚠️ Stolpersteine & Lösungen​

Problem 1: „Ich bin mir unsicher, wie ich die Risk-Scoring-Kriterien bewerten soll."

Häufigste Unsicherheit: Was zählt als „personenbezogene Daten"? Wann ist eine Entscheidung „vollautomatisiert"?

Lösung:

  • Nutzen Sie die Risk-Scoring-Matrix (siehe oben). Dort sind alle Kriterien mit Beispielen erklärt.
  • Im Zweifel: Kontaktieren Sie den KI-Manager frühzeitig. Er kann Ihnen in 5-10 Minuten helfen, die richtige Bewertung zu finden.
  • Tendenz zur Vorsicht: Wenn Sie zwischen zwei Punktwerten schwanken, wählen Sie den höheren Wert. Besser einmal zu vorsichtig als zu riskant.
Ehrlichkeit ist Pflicht

Das Risk-Scoring basiert auf Ihren Angaben. Wenn Sie bewusst niedrigere Punktzahlen wählen, um einen Fast-Track zu erzwingen, riskieren Sie rechtliche Konsequenzen (DSGVO-Verstoß, AI-Act-Verstoß) und Vertrauensverlust. Seien Sie ehrlich – auch wenn das bedeutet, dass die Prüfung länger dauert.

Problem 2: „Unser Use Case ist komplex. Ich kann ihn nicht in 500 Zeichen beschreiben."

Lösung:

  • Fokus auf Input-Verarbeitung-Output: Beschreiben Sie was die KI tut, nicht warum sie es tut oder wie großartig das ist. Geschäftsnutzen und strategische Begründung gehören nicht in die Beschreibung.
  • Beispiel (zu lang): „Wir möchten Microsoft 365 Copilot einsetzen, um die Produktivität unserer Vertriebsmitarbeiter zu steigern, indem wir repetitive Aufgaben wie E-Mail-Beantwortung automatisieren und dadurch mehr Zeit für Kundenberatung schaffen. Copilot soll auf Outlook und SharePoint zugreifen und intelligente Vorschläge machen." (268 Zeichen – aber viel Füllwort)
  • Beispiel (besser): „Vertrieb nutzt Copilot in Outlook. Copilot analysiert E-Mail-Historie, schlägt Antworten vor, fügt Produktinfos ein. Mitarbeiter prüft, überarbeitet, sendet manuell. Zugriff: Outlook (Schreibrechte), SharePoint (lesend)." (199 Zeichen, präzise)

Problem 3: „Wir wollen mehrere Use Cases mit dem gleichen Tool. Brauchen wir für jeden einen eigenen Steckbrief?"

Antwort: Ja.

Ein Tool kann mehrere Use Cases haben – mit unterschiedlichen Risiken. Beispiel:

  • Use Case A: „ChatGPT für Marketing-Brainstorming" (Score 6 → Fast-Track)
  • Use Case B: „ChatGPT für Übersetzung von Kundendokumenten" (Score 11 → Standard)
  • Use Case C: „ChatGPT für automatische Bewerberbewertung" (Score 16 → STOP)

Jeder Use Case braucht einen eigenen Steckbrief, weil Risiken und Prüfanforderungen unterschiedlich sind.

Tool-Freigabe ≠ Use-Case-Freigabe

„ChatGPT ist freigegeben" bedeutet nicht, dass Sie es für jeden Zweck nutzen dürfen. Jeder neue Einsatzzweck = neuer Use Case = neuer Check.

Problem 4: „Wir haben den Steckbrief eingereicht, aber seit 5 Tagen keine Rückmeldung erhalten."

Lösung:

  • Prüfen Sie den Status im SharePoint-Cockpit. Steht dort „Warte auf Validierung" oder „Zurück zur Bearbeitung"?
  • Kontaktieren Sie den KI-Manager. Vielleicht liegt der Steckbrief in seiner Warteschlange, weil er gerade mehrere Use Cases parallel bearbeitet.
  • SLA-Überwachung: Der KI-Manager wird bei Fristüberschreitung automatisch erinnert. Wenn der SLA (3 Arbeitstage für Schritt 1) überschritten wird, eskaliert das System an das Management.

✅ Checkliste: Schritt 1 abgeschlossen?​

Bevor der Use Case zu Schritt 2 weitergehen kann, müssen alle der folgenden Punkte erfüllt sein:

  • ☐ Use-Case-Steckbrief vollständig ausgefüllt (alle 14 Pflichtfelder)
  • ☐ Beschreibung ist präzise und konkret (Input → Verarbeitung → Output erkennbar)
  • ☐ Systemtyp erfasst (Assistierend / Entscheidungsunterstützung / Semi-automatisch)
  • ☐ Risk-Scoring-Kriterien bewertet (Kriterien 9-14, jeweils 1-3 Punkte)
  • ☐ Risk-Score berechnet und dokumentiert (Summe 6-18 Punkte)
  • ☐ Routing-Pfad festgelegt (Fast-Track / Standard / Full Review)
  • ☐ Steckbrief vom KI-Manager validiert (keine offenen Rückfragen, keine Widersprüche)
  • ☐ Prozessstatus aktualisiert („S1 – Formalisierung & Risk-Scoring" abgeschlossen)
  • ☐ Use-Case-Owner über Routing informiert (E-Mail mit Score, Pfad, nächsten Schritten)
  • ☐ Steckbrief an Prüfer in Schritt 2 weitergeleitet (KI-Manager, DSB, IT-Security)

Wenn alle Punkte erfüllt sind: ✅ Schritt 1 abgeschlossen → Weiter zu Schritt 2 (Risk-Assessment & Gate).

Nächster Schritt: 📖 Schritt 2 – Risk-Assessment & Gate (wird im nächsten Kapitel beschrieben)

Schritt 2 – Risk-Assessment & Gate​

📋 Worum geht's?​

Schritt 2 ist die zentrale Gate-Funktion des gesamten KI-Checks. Hier wird entschieden, ob Ihr Use Case rechtlich zulässig ist – oder ob er gegen EU AI Act Art. 5 (verbotene Praktiken) oder gegen unsere interne RBV §3 (Hochrisiko-Verbote) verstößt.

Anders als Schritt 1, der eine technische Risikobewertung vornimmt („Wie riskant ist der Use Case?"), erfolgt in Schritt 2 eine rechtliche Zulässigkeitsprüfung („Ist der Use Case überhaupt erlaubt?").

Schritt 2 hat drei Varianten – abhängig vom Risk-Score aus Schritt 1:

  • Variante A: Quick-Check (Score 6-9) – Schnelle Plausibilitätsprüfung für Low-Risk-Use-Cases
  • Variante B: Standard-Gate (Score 10-14) – Vollständige rechtliche Prüfung für Standard-Use-Cases
  • Variante C: High-Risk-Gate (Score 15-18) – Intensive Prüfung mit hoher STOP-Wahrscheinlichkeit

Wichtig: Das Gate ist kein Automatismus. Selbst bei niedrigem Risk-Score kann ein Use Case gestoppt werden, wenn er gegen Verbote verstößt. Und selbst bei hohem Score kann er (mit Auflagen) freigegeben werden, wenn alle Risiken beherrschbar sind.

Das STOP-Gate ist endgültig

Wenn Schritt 2 zu einem STOP führt (AI-Act-Verbot oder RBV §3-Hochrisiko), endet der Prozess. Sie können den Use Case nicht „einfach trotzdem machen". Eine Redesign-Beratung durch den KI-Manager ist aber möglich – vielleicht lässt sich der Use Case so anpassen, dass er zulässig wird.

🎯 Was wird geprüft?​

Die Prüfung erfolgt in drei Schritten – die Detailtiefe hängt vom Risk-Score ab:

1. SOP-Relevanz: Fällt der Use Case überhaupt unter die KI-SOP?​

Prüfung: Ist das Tool/System überhaupt ein KI-System im Sinne unserer SOP?

✅ Ja: Weiter prüfen (AI-Act-Verbote, Hochrisiko)
❌ Nein: Prozess endet (Use Case ist nicht prüfpflichtig)

Typische Nicht-KI: Einfache Regelautomatisierung (If-Then-Else), Makros, Suchfunktionen, klassische Datenbanken.

2. AI-Act-Verbote (Art. 5): Liegt eine verbotene Praktik vor?​

Der EU AI Act Art. 5 verbietet bestimmte KI-Praktiken vollständig. Diese sind in der EU generell nicht zulässig – unabhängig davon, wie gut die Schutzmaßnahmen sind.

Verbotene Praktiken:

Social Scoring:
Bewertung von Personen nach ihrem Sozialverhalten (z.B. „Trustworthiness-Score" für Mitarbeitende).

Emotion Recognition am Arbeitsplatz:
Erkennung oder Interpretation von Emotionen von Mitarbeitenden oder Bewerbern – z.B. durch Analyse von Mimik, Stimme, Text. Ausnahme: Medizinische Gründe oder Sicherheit (z.B. Müdigkeitserkennung bei Piloten).

Subliminal Manipulation:
Unterschwellige Verhaltensmanipulation, die Menschen zu Entscheidungen bringt, die sie sonst nicht getroffen hätten.

Exploitation of Vulnerabilities:
Ausnutzung von Schwächen spezifischer Gruppen (Alter, Behinderung, soziale/wirtschaftliche Lage), um deren Verhalten zu beeinflussen.

AI-Act-Verstoß = Bußgeld bis 35 Mio. €

Verstöße gegen Art. 5 können mit bis zu 35 Mio. € oder 7% des weltweiten Jahresumsatzes geahndet werden. Diese Verbote gelten absolut – es gibt keine Ausnahmen durch „ausreichende Schutzmaßnahmen".

Wenn AI-Act-Verbot vorliegt: ❌ STOP – Prozess endet. Kein Re-Design möglich (es sei denn, die verbotene Funktion wird komplett entfernt).

3. Hochrisiko-KI (Anhang III AI Act + RBV §3): Ist der Use Case Hochrisiko-KI?​

Der EU AI Act definiert in Anhang III bestimmte Bereiche als Hochrisiko-KI. Diese sind grundsätzlich erlaubt, aber nur unter strengen Auflagen (Risikomanagementsystem, Dokumentation, menschliche Aufsicht, Konformitätsbewertung).

Bei GEALAN gilt aber: Per RBV §3 sind Hochrisiko-Use-Cases im HR-Bereich grundsätzlich verboten – auch wenn der EU AI Act sie erlauben würde.

Hochrisiko-Bereiche (Anhang III Nr. 4 – Beschäftigung & HR):

  • Recruiting & Personalauswahl: KI wertet Bewerbungen aus, rankt Kandidaten, empfiehlt Vorauswahl.
  • Leistungs- & Verhaltensbeurteilung: KI bewertet Mitarbeiterleistung, erstellt Rankings, empfiehlt Beförderungen/Kündigungen.
  • Aufgabenzuweisung: KI entscheidet, wer welche Aufgaben bekommt.
  • Überwachung von Arbeitsleistung: KI trackt Produktivität, Pausen, Aktivitäten.

Wenn Hochrisiko-Verdacht vorliegt:

  • Fast-Track (Score 6-9): ❌ Umleitung in Standard-Pfad – eine schnelle Freigabe ist nicht mehr möglich.
  • Standard/High-Risk (Score 10-18): ❌ STOP (per RBV §3 verboten).
RBV §3: Hochrisiko-KI im HR bei GEALAN verboten

Bei GEALAN sind Hochrisiko-Use-Cases im HR-Bereich grundsätzlich nicht zulässig. Grund: Schutz von Mitarbeiter- und Bewerberrechten vor automatisierter Diskriminierung.

Aber: Redesign-Beratung ist möglich. Beispiel: Statt „KI trifft Entscheidung" → „KI schlägt vor, Mensch entscheidet" (Human-in-the-Loop). Dadurch sinkt die Autonomie, der Use Case wird kein Hochrisiko mehr.

👥 Wer ist beteiligt?​

KI-Manager:
Führt die Gate-Prüfung durch, koordiniert Rückfragen, trifft die Routing-Entscheidung (Fast-Track / Standard / Full Review / STOP).

Datenschutzbeauftragte:r (DSB):
Bewertet AI-Act-Compliance, DSGVO-Aspekte und Hochrisiko-Verdacht. Wird bei unklaren Fällen konsultiert.

Rechtsabteilung (Legal):
Prüft AI-Act-Verbote (Art. 5) und Hochrisiko-Kategorien (Anhang III). Wird bei komplexen rechtlichen Fragen hinzugezogen.

Use-Case-Owner:
Liefert bei Rückfragen zusätzliche Informationen (z.B. „Werden Emotionen ausgewertet?" – „Wird die KI auf Bewerberdaten angewendet?").

📝 Welche Dokumente entstehen?​

Gate-Entscheidung (direkt im SharePoint-Cockpit):
Die Ergebnisse der Gate-Prüfung werden direkt im SharePoint-System dokumentiert. Es gibt kein separates Word-Dokument mehr (früher: „Dokument 02 Pre-Assessment"). Die wichtigsten Felder:

  • SOP anwendbar: Ja / Nein
  • AI-Act-Verbot: Ja / Nein (wenn ja: welches?)
  • Hochrisiko-Verdacht: Ja / Nein / Unklar (wenn ja: welche Kategorie?)
  • Blocker-Status: STOP / HOLD / Kein Blocker
  • Routing-Entscheidung: Fast-Track / Standard / Full Review / STOP
  • Begründung: Freitext (Warum wurde gestoppt? Warum weitergeleitet?)

⚙️ Wie läuft es ab?​

Die Prüfung erfolgt in drei Varianten – je nach Risk-Score aus Schritt 1.

Variante A: Quick-Check (Score 6-9 Punkte)​

Ziel: Schnelle Freigabe für risikoarme Use Cases, die alle Fast-Track-Kriterien erfüllen.

Ablauf:

  1. SOP-Relevanz prüfen: Ist das Tool ein KI-System? → Ja/Nein
  2. AI-Act-Verbote prüfen: Social Scoring, Emotion Recognition, Manipulation, Vulnerabilities? → Nein (hoffentlich!)
  3. Fast-Track-Kriterien validieren:
    • ✅ Keine besonderen Kategorien (Art. 9 DSGVO)
    • ✅ Kein HR-Kontext (Kriterium 12 = 1 Punkt)
    • ✅ Keine vollautomatisierten Entscheidungen (Kriterium 9 ≤ 2 Punkte)
    • ✅ Kein Multi-System-Schreibzugriff (Kriterium 10 ≤ 2 Punkte)
    • ✅ Keine öffentliche Weitergabe (Kriterium 13 ≤ 2 Punkte)

Gate-Entscheidung:

  • ✅ Alle Checks OK: → Fast-Track zu Schritt 7 (Management-Entscheidung) – Schritte 3-6 werden übersprungen!
  • ⚠️ Ein Kriterium nicht erfüllt: → Umleitung in Standard-Pfad (S3-S6) – keine Abkürzung mehr möglich.
  • ❌ AI-Act-Verbot: → STOP – Prozess endet.

Typische Bearbeitungszeit: 2 Arbeitstage (oft nur 1 Tag).

Variante B: Standard-Gate (Score 10-14 Punkte)​

Ziel: Vollständige rechtliche Zulässigkeitsprüfung für Standard-Use-Cases.

Ablauf:

  1. SOP-Relevanz prüfen (wie Variante A)
  2. AI-Act-Verbote prüfen (wie Variante A)
  3. Hochrisiko-Verdacht prüfen (Anhang III AI Act):
    • HR-Recruiting (Anhang III Nr. 4a)?
    • Leistungs-/Verhaltensbeurteilung (Anhang III Nr. 4b)?
    • Profiling mit Rechtswirkung (DSGVO Art. 22)?
    • Kreditscoring (Anhang III Nr. 5)?
    • Biometrische Identifikation (Anhang III Nr. 1)?
    • Kritische Infrastruktur (Anhang III Nr. 2)?

Gate-Matrix:

SOP anwendbar?AI-Act-Verbot?Hochrisiko (RBV §3)?Routing
❌ Nein--Ende (nicht prüfpflichtig)
✅ Ja❌ Ja-STOP (nicht zulässig)
✅ Ja✅ Nein❌ Ja (HR)STOP (RBV §3 Verbot)
✅ Ja✅ Nein✅ NeinStandard-Pfad (→ S3-S6)

Typische Bearbeitungszeit: 5 Arbeitstage.

Variante C: High-Risk-Gate (Score 15-18 Punkte)​

Ziel: Intensive Prüfung für komplexe, risikoreiche Use Cases – mit hoher Wahrscheinlichkeit endet der Prozess hier.

Ablauf:

  1. SOP-Relevanz, AI-Act-Verbote, Hochrisiko-Verdacht (wie Variante B)
  2. Erweiterte Hochrisiko-Bewertung:
    • Detaillierte AI-Act-Compliance-Analyse (Anhang II + III)
    • Ist ein Risikomanagementsystem erforderlich? (Art. 9 AI Act)
    • Ist eine Konformitätsbewertung erforderlich? (Art. 43 AI Act)
    • Muss ein Notified Body (benannte Stelle) eingebunden werden?
    • Kann das Risiko überhaupt beherrscht werden?

Mögliche Ergebnisse:

  • ✅ Freigabefähig (mit umfangreichen Auflagen): → Standard-Pfad (S3-S6) – aber mit intensiveren Prüfungen.
  • ⚠️ HOLD (bis Risk-Mitigations umgesetzt): → Zurück zu Schritt 1 für Anpassungen (z.B. Autonomie senken, Human-in-the-Loop einbauen).
  • ❌ STOP (Risiko nicht beherrschbar): → Prozess endet.

Typische Bearbeitungszeit: 7 Arbeitstage.

⚠️ Stolpersteine & Lösungen​

Problem 1: „Unser Use Case wurde gestoppt (STOP-Gate). Können wir ihn trotzdem umsetzen?"

Antwort: Nein – aber Redesign ist möglich.

Ein STOP-Gate ist endgültig. Wenn der Use Case gegen AI-Act Art. 5 oder RBV §3 verstößt, können Sie ihn nicht „einfach trotzdem machen" – das wäre illegal.

Aber: Der KI-Manager bietet Redesign-Beratung an. Oft lässt sich der Use Case so anpassen, dass er zulässig wird:

  • Beispiel 1 (Hochrisiko-Recruiting): Statt „KI sortiert Bewerbungen automatisch aus" → „KI erstellt Vorschlagsliste, Personaler prüft jede Bewerbung" (Human-in-the-Loop). Dadurch sinkt die Autonomie von 3 auf 2 Punkte, der Hochrisiko-Verdacht entfällt.
  • Beispiel 2 (Emotion Recognition): Statt „KI erkennt Emotionen von Mitarbeitenden in Meeting-Videos" → „KI erstellt reine Meeting-Zusammenfassung ohne Emotionsanalyse". Die verbotene Funktion wird entfernt.

Kontaktieren Sie den KI-Manager für eine Redesign-Beratung. Die Beratung ist kostenlos und dauert ~30-60 Minuten.

Problem 2: „Wir haben einen niedrigen Risk-Score (7 Punkte), wurden aber trotzdem in den Standard-Pfad umgeleitet. Warum?"

Antwort: Ein Fast-Track-Kriterium war nicht erfüllt.

Auch wenn der Score niedrig ist, müssen alle der folgenden Bedingungen erfüllt sein, um den Fast-Track zu nutzen:

  • ✅ Keine besonderen Kategorien (Art. 9 DSGVO)
  • ✅ Kein HR-Kontext
  • ✅ Keine vollautomatisierten Entscheidungen
  • ✅ Kein Multi-System-Schreibzugriff
  • ✅ Keine öffentliche Weitergabe

Wenn eine einzige Bedingung nicht erfüllt ist, rutscht der Use Case in den Standard-Pfad. Grund: Diese Kriterien sind besonders sensibel und erfordern eine vollständige Prüfung – auch wenn das Gesamtrisiko niedrig ist.

Beispiel: Ihr Use Case hat Score 7, aber die KI greift auf HR-Daten zu (Abwesenheitskalender). → HR-Kontext = 2 Punkte → Fast-Track-Kriterium „Kein HR-Kontext" nicht erfüllt → Standard-Pfad.

Problem 3: „Was bedeutet ‚HOLD'? Ist der Use Case abgelehnt?"

Antwort: Nein. HOLD bedeutet: „Der Use Case ist potenziell zulässig, aber noch nicht freigabefähig – weil wichtige Maßnahmen fehlen."

Typische HOLD-Gründe:

  • Risk-Mitigations fehlen: Z.B. „Human-in-the-Loop muss erst implementiert werden, bevor wir weitermachen können."
  • Informationen fehlen: „Wir können nicht beurteilen, ob es Hochrisiko ist, weil unklar ist, welche Daten verarbeitet werden. Bitte klären Sie das."
  • Anpassungen erforderlich: „Der Use Case ist zu riskant. Wenn Sie die Autonomie senken (von 3 auf 2 Punkte), können wir weitermachen."

Was tun bei HOLD?

  • Kontaktieren Sie den KI-Manager, um zu klären, welche Maßnahmen erforderlich sind.
  • Setzen Sie die Maßnahmen um (z.B. Workflow anpassen, Human-in-the-Loop einbauen).
  • Reichen Sie den Use Case erneut ein – der Prozess startet bei Schritt 1 oder 2 (je nachdem, was geändert wurde).

✅ Checkliste: Schritt 2 abgeschlossen?​

Bevor der Use Case weitergehen kann, müssen alle der folgenden Punkte erfüllt sein:

  • ☐ SOP-Relevanz geprüft (Ja/Nein dokumentiert)
  • ☐ AI-Act-Verbote geprüft (Art. 5 – Social Scoring, Emotion Recognition, Manipulation, Vulnerabilities)
  • ☐ Hochrisiko-Verdacht geprüft (Anhang III – HR, Profiling, Kredit, Biometrie, Infrastruktur)
  • ☐ Blocker-Status gesetzt (STOP / HOLD / Kein Blocker)
  • ☐ Routing-Entscheidung getroffen (Fast-Track / Standard / Full Review / STOP)
  • ☐ Begründung dokumentiert (Warum wurde gestoppt? Warum weitergeleitet?)
  • ☐ Gate-Entscheidung im SharePoint-Cockpit gespeichert
  • ☐ Use-Case-Owner über Routing informiert (E-Mail mit Ergebnis, nächsten Schritten)
  • ☐ Bei STOP: Redesign-Beratung angeboten (KI-Manager kontaktiert Use-Case-Owner)

Wenn alle Punkte erfüllt sind:

  • ✅ Fast-Track: → Weiter zu Schritt 7 (Management-Entscheidung)
  • ✅ Standard/Full Review: → Weiter zu Schritt 3 (Datenschutz) + Schritt 4 (IT-Security) + Schritt 5 (Betriebsrat) – parallel
  • ❌ STOP: → Prozess endet (Redesign-Beratung möglich)
  • ⚠️ HOLD: → Zurück zu Schritt 1 (Anpassungen vornehmen)

Nächster Schritt:

Schritt 3 – Datenschutzprüfung​

📋 Worum geht's?​

In Schritt 3 prüft der Datenschutzbeauftragte (DSB), ob Ihr Use Case die DSGVO einhält. Das Ziel: Sicherstellen, dass alle personenbezogenen Daten rechtskonform verarbeitet werden, Risiken beherrschbar sind und – wenn nötig – eine Datenschutz-Folgenabschätzung (DSFA) durchgeführt wird.

Diese Prüfung läuft parallel zu Schritt 4 (IT-Security) und Schritt 5 (Betriebsrat). Das spart Zeit und beschleunigt den Prozess.

Wichtig: Schritt 3 wird nur durchlaufen, wenn der Use Case den Standard- oder Full-Review-Pfad nimmt. Bei Fast-Track wird Schritt 3 übersprungen (die Datenschutz-Prüfung ist dann minimal und wird in Schritt 2 mit abgedeckt).

🎯 Was wird geprüft?​

Der DSB prüft fünf zentrale Bereiche:

1. Rechtsgrundlage (Art. 6 DSGVO bzw. §26 BDSG)​

Jede Verarbeitung personenbezogener Daten braucht eine Rechtsgrundlage. Die DSGVO nennt sechs mögliche Rechtsgrundlagen (Art. 6 Abs. 1):

  • a) Einwilligung (explizit, freiwillig, widerrufbar)
  • b) Vertragserfüllung (zur Durchführung eines Vertrags erforderlich)
  • c) Rechtliche Verpflichtung (z.B. steuerrechtliche Aufbewahrungspflichten)
  • d) Schutz lebenswichtiger Interessen (z.B. medizinische Notfälle)
  • e) Öffentliches Interesse (Aufgaben im öffentlichen Interesse)
  • f) Berechtigtes Interesse (nach Abwägung mit Interessen der Betroffenen)

Im Beschäftigungskontext gilt zusätzlich §26 BDSG (Durchführung des Arbeitsverhältnisses) – diese Rechtsgrundlage wird häufig für Mitarbeiterdaten genutzt.

Bei besonderen Kategorien (Art. 9 DSGVO) – Gesundheitsdaten, biometrische Daten, rassische/ethnische Herkunft, politische Meinungen, religiöse Überzeugungen, Gewerkschaftszugehörigkeit, sexuelle Orientierung – ist eine zusätzliche Rechtsgrundlage erforderlich (z.B. Art. 9 Abs. 2 lit. b für Arbeitsrecht, oder Art. 9 Abs. 2 lit. a für explizite Einwilligung).

Keine Rechtsgrundlage = STOP

Wenn keine Rechtsgrundlage vorliegt, ist die Verarbeitung rechtswidrig. Der Use Case kann nicht freigegeben werden. Blocker-Status: STOP – Prozess endet.

2. DSGVO-Grundsätze (Art. 5)​

Der DSB prüft, ob die fünf Grundsätze der DSGVO eingehalten werden:

Zweckbindung (Art. 5 Abs. 1 lit. b):
Daten dürfen nur für den angegebenen Zweck genutzt werden. Beispiel: Wenn die KI Daten für Rechnungsstellung verarbeitet, dürfen diese Daten nicht plötzlich für Marketing genutzt werden.

Datenminimierung (Art. 5 Abs. 1 lit. c):
Es dürfen nur die Daten verarbeitet werden, die für den Zweck tatsächlich erforderlich sind. Beispiel: Wenn die KI nur Name und E-Mail braucht, darf nicht das komplette CV hochgeladen werden.

Speicherbegrenzung (Art. 5 Abs. 1 lit. e):
Daten dürfen nicht länger gespeichert werden, als erforderlich. Ein Löschkonzept muss vorhanden sein.

Richtigkeit (Art. 5 Abs. 1 lit. d):
Es muss einen Mechanismus geben, um Daten zu aktualisieren oder zu berichtigen, wenn sie falsch sind.

Integrität & Vertraulichkeit (Art. 5 Abs. 1 lit. f):
Technische Maßnahmen (Verschlüsselung, Zugriffskontrolle) müssen vorhanden sein. Diese werden in Schritt 4 (IT-Security) detailliert geprüft.

3. Datenschutz-Folgenabschätzung (DSFA) erforderlich? (Art. 35 DSGVO)​

Eine DSFA ist eine systematische Bewertung der Risiken für die Rechte und Freiheiten betroffener Personen. Sie ist Pflicht, wenn:

  • Systematische Bewertung persönlicher Aspekte (Profiling): Die KI erstellt Profile, Scores oder Rankings von Personen.
  • Umfangreiche Verarbeitung besonderer Kategorien (Art. 9): Gesundheitsdaten, biometrische Daten, etc.
  • Systematische Überwachung öffentlich zugänglicher Bereiche: Z.B. Videoüberwachung mit Gesichtserkennung.
  • Hohes Risiko für Rechte & Freiheiten: Die Datenschutzkonferenz (DSK) hat eine Blacklist mit 26 Verarbeitungstätigkeiten veröffentlicht, die immer eine DSFA erfordern.

DSFA-Ablauf (falls erforderlich):

  1. Beschreibung der Verarbeitungsvorgänge (Was wird wie verarbeitet?)
  2. Bewertung der Notwendigkeit & Verhältnismäßigkeit (Ist die Verarbeitung wirklich erforderlich?)
  3. Risikoanalyse (Eintrittswahrscheinlichkeit × Schwere des Schadens)
  4. Abhilfemaßnahmen (TOMs) (Welche Maßnahmen senken das Risiko?)
  5. Dokumentation im DSFA-Bericht (strukturiertes Dokument, wird archiviert)

Bearbeitungszeit einer DSFA: 7-10 zusätzliche Arbeitstage (verlängert den SLA von Schritt 3).

DSFA erforderlich = längerer SLA

Wenn eine DSFA erforderlich ist, verlängert sich die Bearbeitungszeit von Schritt 3 von 5 auf 7-10 Arbeitstage. Planen Sie das bei der Zeitplanung ein.

4. Betroffenenrechte & Informationspflichten (Art. 13/14 DSGVO)​

Betroffene (Mitarbeitende, Kunden, Bewerber) haben Rechte, die gewährleistet sein müssen:

  • Information (Art. 13/14): Wer verarbeitet die Daten? Zu welchem Zweck? Wie lange? Wer hat Zugriff?
  • Auskunft (Art. 15): Recht auf Kopie der gespeicherten Daten.
  • Löschung (Art. 17): „Recht auf Vergessenwerden", wenn Zweck erfüllt oder Rechtsgrundlage entfällt.
  • Widerspruch (Art. 21): Recht, gegen die Verarbeitung zu widersprechen (insbesondere bei berechtigtem Interesse, Art. 6 Abs. 1 lit. f).
  • Bei automatisierten Entscheidungen (Art. 22): Recht auf menschliche Überprüfung der Entscheidung.

Der DSB prüft:
✅ Ist eine Datenschutzerklärung / Information nach Art. 13/14 vorbereitet?
✅ Gibt es einen Prozess für Auskunfts-, Löschungs- und Widerspruchsanfragen?

5. Auftragsverarbeitung (AVV) erforderlich? (Art. 28 DSGVO)​

Wenn ein externer Anbieter (z.B. Microsoft, OpenAI, Google) personenbezogene Daten im Auftrag von GEALAN verarbeitet, muss ein Auftragsverarbeitungsvertrag (AVV) abgeschlossen sein.

In Schritt 3 prüft der DSB nur, ob ein AVV erforderlich ist. Die detaillierte Prüfung des AVV (Inhalt, Sub-Processors, Zertifikate) erfolgt in Schritt 6 (Anbieter- & Vertragsprüfung).

👥 Wer ist beteiligt?​

Datenschutzbeauftragte:r (DSB):
Führt die vollständige Datenschutzprüfung durch, bewertet Rechtsgrundlagen, entscheidet über DSFA-Erfordernis, dokumentiert Ergebnisse.

KI-Manager:
Koordiniert den Prozess, liefert Informationen aus Schritt 1 & 2, verfolgt SLAs.

Rechtsabteilung (Legal):
Unterstützt bei komplexen Rechtsgrundlagenfragen (z.B. berechtigtes Interesse, §26 BDSG-Auslegung).

Use-Case-Owner:
Liefert bei Rückfragen Detailinformationen (z.B. „Welche Daten genau werden verarbeitet?" – „Wie lange werden Daten gespeichert?").

📝 Welche Dokumente entstehen?​

Datenschutz-Vermerk (strukturierte Dokumentation):
Zusammenfassung der Prüfungsergebnisse:

  • Rechtsgrundlage (welche?)
  • DSGVO-Grundsätze eingehalten (ja/nein, Begründung)
  • DSFA erforderlich (ja/nein)
  • Betroffenenrechte gewährleistet (ja/nein)
  • AVV erforderlich (ja/nein)
  • Blocker-Status (STOP / HOLD / Kein Blocker)
  • Auflagen (falls vorhanden)

DSFA-Bericht (falls erforderlich):
Separates, strukturiertes Dokument mit Risikoanalyse, Abhilfemaßnahmen und Dokumentation.

VVT-Eintrag (Verzeichnis von Verarbeitungstätigkeiten):
Jede neue Verarbeitungstätigkeit wird ins VVT eingetragen (Pflicht nach Art. 30 DSGVO).

⚙️ Wie läuft es ab?​

1. DSB erhält Use-Case-Steckbrief & Gate-Entscheidung
Der DSB bekommt alle Informationen aus Schritt 1 (Steckbrief) und Schritt 2 (Gate-Ergebnis) als Grundlage.

2. DSB prüft Rechtsgrundlage
Welche Rechtsgrundlage (Art. 6 DSGVO, §26 BDSG) liegt vor? Bei besonderen Kategorien (Art. 9): Zusätzliche Rechtsgrundlage erforderlich?

3. DSB prüft DSGVO-Grundsätze
Zweckbindung, Datenminimierung, Speicherbegrenzung, Richtigkeit eingehalten?

4. DSFA-Entscheidung
Ist eine DSFA erforderlich? Falls ja: DSFA-Prozess anstoßen (7-10 Tage Zusatzaufwand).

5. Betroffenenrechte & Informationspflichten prüfen
Information nach Art. 13/14 vorbereitet? Prozesse für Auskunft, Löschung, Widerspruch vorhanden?

6. AVV-Erfordernis prüfen
Liegt Auftragsverarbeitung vor? Falls ja: AVV-Prüfung erfolgt in Schritt 6.

7. Blocker-Status & Auflagen setzen
Ergebnis:

  • ✅ Kein Blocker: Rechtskonform (ggf. mit Auflagen) → Weiter zu Schritt 4/5/6.
  • ⚠️ HOLD: Auflagen müssen vor Weiterleitung umgesetzt werden (z.B. „Löschkonzept erstellen").
  • ❌ STOP: Keine Rechtsgrundlage oder DSFA negativ → Prozess endet.

8. Ergebnisse dokumentieren & Use-Case-Owner informieren
Datenschutz-Vermerk wird im SharePoint-Cockpit gespeichert. Use-Case-Owner erhält E-Mail mit Ergebnis.

⚠️ Stolpersteine & Lösungen​

Problem 1: „Der DSB sagt, wir brauchen eine DSFA. Wie lange dauert das?"

Antwort: 7-10 zusätzliche Arbeitstage.

Eine DSFA ist kein „Formular ausfüllen", sondern eine systematische Risikoanalyse. Typischer Ablauf:

  • Tag 1-2: Beschreibung der Verarbeitung, Informationen sammeln
  • Tag 3-4: Risikoanalyse (Eintrittswahrscheinlichkeit × Schwere)
  • Tag 5-6: Abhilfemaßnahmen definieren (TOMs)
  • Tag 7: Dokumentation im DSFA-Bericht
  • Tag 8-10: Abstimmung mit Use-Case-Owner, finale Freigabe

Tipp: Bereiten Sie alle Informationen vor (Welche Daten? Woher? Wohin? Wie lange? Welche Schnittstellen?), bevor die DSFA startet. Das spart Zeit.

Problem 2: „Wir haben keine Rechtsgrundlage. Können wir trotzdem weitermachen?"

Antwort: Nein.

Ohne Rechtsgrundlage ist die Verarbeitung rechtswidrig (DSGVO Art. 6 Abs. 1). Der Use Case wird gestoppt.

Aber: Der DSB kann helfen, eine passende Rechtsgrundlage zu identifizieren. Beispiele:

  • Berechtigtes Interesse (Art. 6 Abs. 1 lit. f): Oft geeignet für interne Prozesse (z.B. IT-Security-Monitoring, Fraud-Detection). Erfordert Abwägung mit Interessen der Betroffenen.
  • §26 BDSG (Beschäftigungsverhältnis): Geeignet für Mitarbeiterdaten, wenn die Verarbeitung zur Durchführung des Arbeitsverhältnisses erforderlich ist.
  • Einwilligung (Art. 6 Abs. 1 lit. a): Nur geeignet, wenn freiwillig, explizit und widerrufbar. Im Beschäftigungskontext oft problematisch (Machtasymmetrie).

Kontaktieren Sie den DSB frühzeitig, um die Rechtsgrundlage zu klären – idealerweise schon vor Schritt 1.

Problem 3: „Die DSFA hat ergeben, dass das Risiko zu hoch ist. Was nun?"

Antwort: Entweder Abhilfemaßnahmen umsetzen oder stoppen.

Eine negative DSFA bedeutet nicht automatisch STOP. Wenn Abhilfemaßnahmen (TOMs – technische und organisatorische Maßnahmen) das Risiko auf ein akzeptables Niveau senken können, kann der Use Case weitergehen – mit Auflagen.

Typische Abhilfemaßnahmen:

  • Pseudonymisierung / Anonymisierung von Daten
  • Zugriffskontrolle (nur berechtigte Personen haben Zugriff)
  • Löschfristen festlegen (Daten werden nach 6 Monaten automatisch gelöscht)
  • Human-in-the-Loop (KI schlägt vor, Mensch entscheidet)
  • DLP-Regeln (Data Loss Prevention – Daten können nicht unbefugt exportiert werden)

Wenn keine Maßnahmen das Risiko senken können, endet der Prozess. Blocker-Status: STOP.

✅ Checkliste: Schritt 3 abgeschlossen?​

  • ☐ Rechtsgrundlage geprüft & dokumentiert (Art. 6 DSGVO, §26 BDSG, Art. 9 bei bes. Kategorien)
  • ☐ DSGVO-Grundsätze geprüft (Zweckbindung, Datenminimierung, Speicherbegrenzung, Richtigkeit)
  • ☐ DSFA-Erfordernis bewertet (ja/nein, bei ja: DSFA durchgeführt)
  • ☐ Betroffenenrechte & Informationspflichten geprüft (Art. 13/14, Prozesse für Art. 15/17/21)
  • ☐ AVV-Erfordernis geprüft (ja/nein, detaillierte Prüfung erfolgt in Schritt 6)
  • ☐ Blocker-Status gesetzt (STOP / HOLD / Kein Blocker)
  • ☐ Auflagen dokumentiert (falls vorhanden)
  • ☐ Datenschutz-Vermerk im SharePoint-Cockpit gespeichert
  • ☐ Use-Case-Owner über Ergebnis informiert (E-Mail mit Status, Auflagen, nächsten Schritten)
  • ☐ VVT-Eintrag erstellt (Verzeichnis von Verarbeitungstätigkeiten aktualisiert)

Wenn alle Punkte erfüllt sind: ✅ Schritt 3 abgeschlossen → Weiter zu Schritt 4/5/6 (parallel).

Schritt 4 – IT-Security-Prüfung​

📋 Worum geht's?​

In Schritt 4 prüft IT-Security, ob Ihr Use Case technisch sicher betrieben werden kann. Das Ziel: Sicherstellen, dass IT-Risiken beherrschbar sind, Zugriffe kontrolliert werden, Daten geschützt sind und im Notfall reagiert werden kann.

Diese Prüfung läuft parallel zu Schritt 3 (Datenschutz) und Schritt 5 (Betriebsrat).

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

Wichtiger Hinweis zu Schritt 4

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

Schritt 4 fokussiert sich auf technische Security-Maßnahmen.

🎯 Was wird geprüft?​

IT-Security bewertet vier zentrale Bereiche:

A) Zugriffskontrolle & Identitätsmanagement​

  • Least-Privilege-Prinzip (nur notwendige Berechtigungen)
  • SSO/MFA (Single Sign-On & Multi-Faktor-Authentifizierung)
  • Rollenkonzept (definierte Benutzerrollen)
  • Audit-Logging (Zugriffe protokolliert)

B) Technische Sicherheitsmaßnahmen​

Verschlüsselung:

  • TLS 1.3 (für Datenübertragung)
  • At-Rest-Encryption (Verschlüsselung gespeicherter Daten)

API-Security:

  • API-Key-Management / Token-basierte Authentifizierung
  • Rate-Limiting (Schutz vor Missbrauch)
  • Input Validation (Eingabeprüfung gegen Injection-Angriffe)

Network Security:

  • Firewall-Regeln (nur notwendige Ports offen)
  • IP-Whitelisting (optional, bei besonders sensiblen Systemen)

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

  • Copy/Paste-Control für sensible Daten
  • Export-Logs (Audit-Trail für Datenexporte)
  • Encryption für externe Weitergabe (falls Daten das Unternehmen verlassen)

D) Monitoring & Incident-Management​

  • Security-Monitoring (Logging & Alerting)
  • Incident-Response-Plan (Wer wird bei Security-Incidents informiert?)
  • Rollback-Mechanismus (Können Aktionen rückgängig gemacht werden?)
  • Vulnerability Scans / Penetration Tests (bei High-Risk-Cases)

Security-Controls nach Risikostufe​

IT-Security definiert risikobasierte Controls:

RisikostufeTypische ControlsReview-Zyklus
NiedrigSSO/MFA, Basic Logging, TLS 1.3Jährlich
Mittel+ Rollenkonzept, DLP-Regeln, Audit-LogsQuartalsweise
Hoch+ Read-Only-Modus (wo möglich), Human-in-the-Loop für kritische Aktionen, Detailliertes Audit-Log, Penetration-TestMonatlich

Entscheidungslogik​

Prüfer-ErgebnisBlocker-StatusRouting
Sicherheit gewährleistet (alle Controls erfüllbar)✅ Kein Blocker→ Weiter zu S5/S6
Kritische Controls fehlen (z.B. SSO nicht möglich)⚠️ HOLD→ Kompensationsmaßnahmen oder Anbieter-Wechsel
Risiko nicht beherrschbar❌ STOP→ Prozess endet

👥 Wer ist beteiligt?​

IT-Security-Team:
Führt Sicherheitsbewertung durch, definiert Controls.

IT-Abteilung:
Prüft technische Machbarkeit, Architektur-Review.

KI-Manager:
Koordiniert Prozess.

Use-Case-Owner:
Liefert technische Details.

📝 Welche Dokumente entstehen?​

Security-Vermerk (strukturierte Dokumentation):

  • Security-Controls definiert
  • Blocker-Status (STOP / HOLD / Kein Blocker)
  • Auflagen (falls vorhanden)

Liste erforderlicher Controls:
Wird in KI Check – Management-Entscheidung übernommen.

⚙️ Wie läuft es ab?​

1. IT-Security erhält Steckbrief & Gate-Entscheidung

2. Zugriffskontrolle prüfen
SSO/MFA möglich? Rollenkonzept vorhanden? Audit-Logging aktiviert?

3. Technische Sicherheitsmaßnahmen bewerten
Verschlüsselung (TLS 1.3, At-Rest)? API-Security? Network Security?

4. DLP-Erfordernis prüfen
Können sensible Daten unbefugt exportiert werden? DLP-Regeln erforderlich?

5. Monitoring & Incident-Management prüfen
Security-Monitoring vorhanden? Incident-Response-Plan definiert? Rollback möglich?

6. Security-Controls definieren
Welche Maßnahmen sind für diese Risikostufe erforderlich?

7. Blocker-Status setzen

  • ✅ Kein Blocker: Sicherheit gewährleistet → Weiter
  • ⚠️ HOLD: Kritische Controls fehlen → Nachbesserung erforderlich
  • ❌ STOP: Risiko nicht beherrschbar → Prozess endet

8. Ergebnisse dokumentieren & Use-Case-Owner informieren

⚠️ Stolpersteine & Lösungen​

Problem: „IT-Security fordert SSO/MFA, aber der Anbieter unterstützt das nicht."

Lösung: Entweder Anbieter wechseln oder Kompensationsmaßnahmen:

Kompensationsmaßnahmen (wenn Anbieter-Wechsel nicht möglich):

  • IP-Whitelisting (Zugriff nur aus GEALAN-Netzwerk)
  • Zusätzliche Audit-Logs (wer hat wann auf was zugegriffen?)
  • Reduzierte Berechtigungen (Read-Only statt Read-Write)
  • Verstärkte Überwachung (Security-Monitoring mit Alerting)

Wichtig: Kompensationsmaßnahmen sind kein 1:1-Ersatz für SSO/MFA. IT-Security entscheidet, ob Kompensation ausreichend ist oder ob der Use Case gestoppt wird.

Rechtliche Grundlagen​

  • DSGVO Art. 32 (Sicherheit der Verarbeitung)
  • IT-Sicherheitsgesetz (IT-SiG)
  • BSI-Grundschutz (Best Practices für IT-Sicherheit)

✅ Checkliste: Schritt 4 abgeschlossen?​

  • ☐ Zugriffskontrolle geprüft (SSO/MFA, Least-Privilege, Rollenkonzept, Audit-Logs)
  • ☐ Technische Sicherheitsmaßnahmen bewertet (Verschlüsselung, API-Security, Network Security)
  • ☐ DLP-Erfordernis geprüft (Copy/Paste-Control, Export-Logs, Encryption)
  • ☐ Monitoring & Incident-Management geprüft (Security-Monitoring, Incident-Response, Rollback)
  • ☐ Security-Controls definiert (risikobasiert: Niedrig / Mittel / Hoch)
  • ☐ Blocker-Status gesetzt (STOP / HOLD / Kein Blocker)
  • ☐ Security-Vermerk im SharePoint-Cockpit gespeichert
  • ☐ Use-Case-Owner über Ergebnis informiert

Wenn alle Punkte erfüllt sind: ✅ Schritt 4 abgeschlossen → Weiter zu Schritt 5/6 (parallel).

Schritt 5 – Betriebsrat / Mitbestimmung​

📋 Worum geht's?​

In Schritt 5 prüft die Personalabteilung (HR) gemeinsam mit dem Betriebsrat, ob Mitbestimmungsrechte nach BetrVG betroffen sind. Falls ja, wird eine KI Check – Einzelanlage zur KI-RBV erstellt und die Zustimmung des Betriebsrats eingeholt.

Diese Prüfung läuft parallel zu Schritt 3 (Datenschutz) und Schritt 4 (IT-Security).

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

🎯 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).

👥 Wer ist beteiligt?​

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

📝 Welche Dokumente entstehen?​

KI Check – Einzelanlage zur KI-RBV (falls BR-Trigger = Ja):

  • Zweck, Systemdetails, zulässiger Nutzungszweck
  • Ausdrückliche Ausschlüsse (keine Leistungsbewertung, kein Scoring)
  • Art der Nutzung (Human-in-the-Loop, teilautomatisiert)
  • Transparenz- & Informationspflichten

BR-Freigabe-Vermerk:
Strukturierte Dokumentation oder E-Mail/Protokoll.

⚙️ Wie läuft es ab?​

  1. Mitbestimmungstatbestand klären (§87, §94, §95 BetrVG)
  2. KI-Rahmenbetriebsvereinbarung (RBV) anwenden
  3. Einzelanlage erstellen (falls BR-Trigger = Ja)
  4. Einzelanlage an BR übermitteln
  5. Präsentationstermin (optional)
  6. BR prüft & entscheidet:
    • ✅ Freigegeben → Prozess läuft weiter
    • ⚠️ Freigegeben mit Auflagen → Auflagen dokumentieren & umsetzen
    • 🔄 Verhandlung → HOLD (bis Einigung)
    • ❌ Abgelehnt → STOP

⚠️ Stolpersteine & Lösungen​

Problem: „Der Betriebsrat lehnt ab. Was nun?"

Antwort: Entweder Redesign oder Prozess endet.

Häufigste Ablehnungsgründe:

  • Überwachung zu stark: Reduktion der Überwachungsfunktionen (z.B. nur aggregierte Daten, keine Einzelpersonen).
  • Automatisierung zu hoch: Human-in-the-Loop einbauen.
  • Transparenz fehlt: Klare Informationspflichten definieren.

Kontaktieren Sie HR & KI-Manager für Redesign-Beratung.

✅ Checkliste: Schritt 5 abgeschlossen?​

  • ☐ Mitbestimmungstatbestand geprüft (§87, §94, §95 BetrVG)
  • ☐ KI-RBV geprüft (fällt Use Case unter RBV?)
  • ☐ Falls BR-Trigger = Ja: Einzelanlage zur KI-RBV erstellt
  • ☐ Einzelanlage an BR übermittelt
  • ☐ BR-Freigabe eingeholt (Freigegeben / Freigegeben mit Auflagen / Verhandlung / Abgelehnt)
  • ☐ Blocker-Status gesetzt
  • ☐ Auflagen dokumentiert (falls vorhanden)
  • ☐ BR-Freigabe-Vermerk im SharePoint-Cockpit gespeichert
  • ☐ Use-Case-Owner über Ergebnis informiert

Wenn alle Punkte erfüllt sind: ✅ Schritt 5 abgeschlossen → Weiter zu Schritt 6.

Schritt 6 – Anbieter- & Vertragsprüfung​

📋 Worum geht's?​

In Schritt 6 prüfen Einkauf / Legal, ob 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.

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

🎯 Was wird geprüft?​

1. Anbieterstatus klären

  • Bereits freigegeben → Vertragsprüfung
  • Neu → Anbieter-Onboarding starten
  • Mit Einschränkungen → Einschränkungen vs. Use Case abgleichen

2. Vertragsprüfung

  • Gültiger Rahmenvertrag vorhanden?
  • Use Case durch Vertrag abgedeckt?
  • Haftung & Garantien akzeptabel?
  • Kündigung & Exit geregelt?

3. Auftragsverarbeitungsvertrag (AVV) – falls Personendaten verarbeitet werden

AVV muss gem. Art. 28 DSGVO enthalten:

  • Gegenstand & Dauer
  • Art & Zweck
  • Arten personenbezogener Daten
  • Kategorien betroffener Personen
  • Pflichten & Rechte
  • TOMs (technische & organisatorische Maßnahmen)
  • Sub-Processor-Regelung
  • Unterstützung bei Betroffenenanfragen
  • Löschung / Rückgabe nach Vertragsende

4. Sub-Processor-Prüfung & Datenorte

  • Liste der Sub-Processor angefordert
  • Datenorte geprüft:
    • EU/EWR → ✅ OK
    • UK, USA, Schweiz → Angemessenheitsbeschluss vorhanden?
    • Drittland → Standardvertragsklauseln (SCC) erforderlich?

5. Cloud & Datenspeicherung

  • Datenort: Wo werden Daten gespeichert? (EU/EWR oder Drittland?)
  • Sub-Processor-Liste: Wer verarbeitet Daten im Auftrag?
  • Backup & Recovery: Sind Backup-Mechanismen vorhanden?
Wichtig: Cloud & Datenspeicherung in Schritt 6

Die Prüfung von Datenorten, Sub-Processoren und Backup-Mechanismen erfolgt in Schritt 6 (Anbieter- & Vertragsprüfung), nicht in Schritt 4 (IT-Security).

Schritt 4 fokussiert sich auf technische Security-Maßnahmen, Schritt 6 auf vertragliche & datenschutzrechtliche Aspekte der Anbieterbeziehung.

👥 Wer ist beteiligt?​

Einkauf / Legal: Vertragsverhandlung, Freigabe.
DSB: AVV-Prüfung, Datenortprüfung.
IT-Security: Sub-Processor-Prüfung, technische Aspekte der Datenspeicherung.
KI-Manager: Koordination.

📝 Welche Dokumente entstehen?​

  • Anbieter-Freigabe-Vermerk
  • Vertragsprüfungs-Checkliste
  • AVV-Kopie (bei Personendaten)
  • Sub-Processor-Liste mit Datenorten

⚙️ Wie läuft es ab?​

  1. Anbieterstatus klären
  2. Vertragsprüfung durchführen
  3. AVV prüfen (falls Personendaten)
  4. Sub-Processor & Datenorte prüfen
  5. Spezifische Anforderungen aus Schritten 3-5 integrieren
  6. Blocker-Status setzen
  7. Ergebnisse dokumentieren & Use-Case-Owner informieren

⚠️ Stolpersteine & Lösungen​

Problem: „Der Anbieter hat keinen AVV."

Lösung: AVV muss verhandelt werden. Ohne AVV ist die Verarbeitung personenbezogener Daten rechtswidrig. Blocker-Status: HOLD (bis AVV vorliegt).

✅ Checkliste: Schritt 6 abgeschlossen?​

  • ☐ Anbieterstatus geprüft (Freigegeben / Neu / Mit Einschränkungen)
  • ☐ Vertragscheck durchgeführt
  • ☐ AVV vorhanden & geprüft (falls Personendaten)
  • ☐ Sub-Processor-Liste & Datenorte geprüft
  • ☐ Cloud & Datenspeicherung geprüft (Datenort, Backup & Recovery)
  • ☐ Anforderungen aus Schritten 3-5 integriert
  • ☐ Blocker-Status gesetzt
  • ☐ Anbieter-Freigabe-Vermerk im SharePoint-Cockpit gespeichert
  • ☐ Use-Case-Owner über Ergebnis informiert

Wenn alle Punkte erfüllt sind: ✅ Schritt 6 abgeschlossen → Weiter zu Schritt 7.

Schritt 7 – Management-Entscheidung​

📋 Worum geht's?​

In Schritt 7 konsolidiert der KI-Manager alle Prüfungsergebnisse und erstellt eine Management-Entscheidung. Das Management trifft die finale Entscheidung: Freigegeben (Grün), Freigegeben mit Auflagen (Gelb) oder Abgelehnt (Rot).

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

🎯 Was wird geprüft?​

Das Management prüft die Zusammenfassung aller Prüfungen:

  • Datenschutz: OK / HOLD / STOP?
  • IT-Security: OK / HOLD / STOP?
  • Betriebsrat: Freigegeben / Freigegeben mit Auflagen / Abgelehnt?
  • Anbieter & Vertrag: OK / HOLD / STOP?

Basierend darauf trifft das Management die finale Entscheidung.

👥 Wer ist beteiligt?​

KI-Manager: Erstellt Entscheidungsvorlage (KI Check – Management-Entscheidung), präsentiert.
Management (Entscheider): Finale Entscheidung.

  • Abteilungsleiter (Pilot, Low-Risk)
  • Bereichsleiter (Team/Bereich, Medium-Risk)
  • Geschäftsführung (Unternehmensweit, High-Risk)

DSB, IT-Security, HR, Legal: Beratend (bei Rückfragen).

📝 Welche Dokumente entstehen?​

KI Check – Management-Entscheidung (Entscheidungsvorlage):

Struktur:

  1. Referenzen: Use-Case-ID, Titel, Geschäftsbereich, Tool/Anbieter, Anbieterstatus, Skalierungsgrad
  2. Kurzbeschreibung & Scope: Use Case in 6 Zeilen (Input → Verarbeitung → Output), Ausschlüsse (3 Bullet Points)
  3. Cockpit-Einordnung: SOP, Systemtyp, Autonomie, Integration, Daten, AI-Act-Verbot, Hochrisiko, BR-Freigabe
  4. Ergebnis-Summary: Vertrag/Anbieter, Datenschutz, IT-Security, Betriebsrat (jeweils Status + Verweis)
  5. Auflagen (max. 8, priorisiert & verifizierbar): Jede Auflage mit Owner & Deadline
  6. Entscheidungsempfehlung (vom KI-Manager): Farbe (Grün / Gelb / Rot), Begründung (5 Bullet Points)
  7. Finale Entscheidung (vom Management): Farbe, Begründung, Review-Datum, Entscheider, Unterschrift

⚙️ Wie läuft es ab?​

  1. KI-Manager erstellt KI Check – Management-Entscheidung
  2. KI-Manager präsentiert Entscheidungsvorlage dem Management
  3. Management prüft & stellt Rückfragen (optional)
  4. Management trifft finale Entscheidung:
    • 🟢 Approved → Weiter zu Schritt 8
    • 🟡 Approved with Conditions → Auflagen umsetzen, dann Schritt 8
    • 🔴 Rejected → STOP
  5. Management-Entscheidung wird unterschrieben & archiviert
  6. Use-Case-Owner wird über Entscheidung informiert

⚠️ Stolpersteine & Lösungen​

Problem: „Das Management lehnt ab, obwohl alle Prüfungen positiv waren. Warum?"

Antwort: Business-Gründe, Risiko-Appetit, strategische Überlegungen.

Das Management kann aus verschiedenen Gründen ablehnen, auch wenn alle Fachprüfungen positiv sind:

  • Kosten zu hoch: Auflagen sind zu teuer (z.B. neue Infrastruktur erforderlich).
  • Business-Nutzen zu gering: Nutzen rechtfertigt den Aufwand nicht.
  • Strategische Gründe: Unternehmen will diesen Bereich (noch) nicht mit KI angehen.

In solchen Fällen: Redesign-Beratung oder Aufschub (Use Case kann später neu eingereicht werden).

✅ Checkliste: Schritt 7 abgeschlossen?​

  • ☐ KI Check – Management-Entscheidung erstellt
  • ☐ Management-Präsentation durchgeführt
  • ☐ Finale Entscheidung getroffen (Approved / Approved with Conditions / Rejected)
  • ☐ Auflagen dokumentiert (falls vorhanden)
  • ☐ Review-Datum gesetzt
  • ☐ Management-Entscheidung unterschrieben
  • ☐ Genehmigungsstatus im SharePoint-Cockpit gesetzt
  • ☐ Use-Case-Owner über Entscheidung informiert

Wenn alle Punkte erfüllt sind:

  • ✅ Approved / Approved with Conditions: → Weiter zu Schritt 8
  • ❌ Rejected: → Prozess endet

Schritt 8 – Betrieb & Review​

📋 Worum geht's?​

Schritt 8 ist der laufende Betrieb des Use Case. Das Ziel: Sicherstellen, dass der freigegebene Use Case compliant bleibt, Auflagen umgesetzt werden und bei Änderungen 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)

🎯 Was wird geprüft?​

Schritt 8 hat 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 unterschrieben
  • Schulungen durchgeführt
  • Monitoring-Dashboard aufgesetzt

Checkliste vor Go-Live:

  • Alle Auflagen umgesetzt?
  • 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?

ÄnderungRe-Check-LevelRü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 hinzugekommenVollständig→ Schritt 2 (+ BR-Prüfung)
Anbieter-WechselVollstä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 neuVollständig→ Schritt 2
Kleinere Anpassungen (z.B. UI-Update)Kein Re-CheckDokumentieren, weiter monitoren

👥 Wer ist beteiligt?​

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

📝 Welche Dokumente entstehen?​

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

⚙️ Wie läuft es ab?​

1. Go-Live-Vorbereitung (5-10 Tage)

  • Auflagen aus Schritt 7 umsetzen
  • Checkliste vor Go-Live abarbeiten
  • Betriebsstatus auf „In Betrieb" setzen

2. Laufender Betrieb (6-12 Monate)

  • Kontinuierliches Monitoring
  • Change-Management (Re-Check-Trigger prüfen bei Änderungen)

3. Review-Termin (6-12 Monate nach Go-Live)

  • Auflagen-Compliance prüfen
  • Scope-Adherence prüfen
  • Drift-Detection prüfen
  • Incident-Review prüfen
  • Anbieter-Status prüfen

4. Review-Ergebnis:

  • ✅ Alles OK: Nächstes Review-Datum setzen (6-12 Monate)
  • ⚠️ Kleinere Abweichungen: Korrekturmaßnahmen definieren (nicht-blockierend), Betrieb läuft weiter
  • 🔄 Auflagen nicht erfüllt: HOLD (Betrieb pausiert bis Auflagen nachgeholt)
  • 🔄 Wesentliche Änderungen: Re-Check auslösen (→ Schritt 2)
  • ❌ Nicht mehr benötigt: Ordentliches Off-Boarding (Betrieb beendet)

⚠️ Stolpersteine & Lösungen​

Problem: „Wir haben neue Features hinzugefügt, aber keinen Re-Check gemacht. Was nun?"

Lösung: Sofort stoppen, Re-Check anstoßen.

Wenn wesentliche Änderungen ohne Re-Check vorgenommen wurden, ist der Use Case nicht mehr compliant. Der Betrieb muss sofort pausiert werden, bis ein Re-Check durchgeführt wurde.

Typische Szenarien:

  • Neue Datenquellen: KI greift jetzt auf HR-Daten zu (vorher nicht) → Re-Check ab Schritt 2.
  • Neue Integration: KI kann jetzt schreiben (vorher nur lesen) → Re-Check ab Schritt 2.
  • Skalierung: Von Pilot (5 Nutzer) auf unternehmensweit (200 Nutzer) → Re-Check ab Schritt 2.

Konsequenz bei Ignorieren: Rechtsverstöße (DSGVO, AI Act, BetrVG), Vertrauensverlust, mögliche Bußgelder.

Kontaktieren Sie sofort den KI-Manager, um den Re-Check anzustoßen.

✅ Checkliste: Schritt 8 abgeschlossen?​

Phase A: Go-Live-Vorbereitung

  • ☐ Alle Auflagen aus Schritt 7 umgesetzt
  • ☐ Betriebsstatus auf „In Betrieb" gesetzt
  • ☐ Review-Datum in Kalender eingetragen
  • ☐ Use-Case-Owner informiert & geschult

Phase B: Laufender Betrieb

  • ☐ Monitoring aufgesetzt (Nutzungszahlen, Fehlerrate, Security-Incidents)
  • ☐ Change-Management etabliert (Re-Check-Trigger bei Änderungen)

Phase C: Review-Zyklus

  • ☐ Review-Termin durchgeführt (6-12 Monate nach Go-Live)
  • ☐ Auflagen-Compliance geprüft
  • ☐ Scope-Adherence geprüft
  • ☐ Drift-Detection geprüft
  • ☐ Incident-Review geprüft
  • ☐ Anbieter-Status geprüft
  • ☐ Review-Ergebnis dokumentiert
  • ☐ Nächstes Review-Datum gesetzt (falls Betrieb weiterläuft)

Wenn alle Punkte erfüllt sind: ✅ Schritt 8 abgeschlossen → Laufender Betrieb mit kontinuierlichem Monitoring.

Abschluss & Zusammenfassung​

✅ Sie haben es geschafft!​

Herzlichen Glückwunsch – Sie haben alle 8 Schritte des KI-Checks durchlaufen. Ihr Use Case ist nun rechtskonform, sicher und freigegeben – oder Sie wissen, warum er (noch) nicht freigabefähig ist und welche Maßnahmen erforderlich sind.

🎯 Die 8 Schritte im Überblick​

SchrittBezeichnungSLA (Fast-Track)SLA (Standard)SLA (Full Review)
S1Formalisierung & Risk-Scoring3 Tage3 Tage3 Tage
S2Risk-Assessment & Gate2 Tage5 Tage7 Tage
S3Datenschutzprüfung-5 Tage7 Tage
S4IT-Security-Prüfung-5 Tage7 Tage
S5Betriebsrat-7-10 Tage10-14 Tage
S6Anbieter & Vertrag-5 Tage7 Tage
S7Management-Entscheidung3 Tage3 Tage5 Tage
S8Go-Live & Review5-10 Tage5-10 Tage10-15 Tage
GesamtEnd-to-End~10-15 Tage~4-6 Wochen~6-8 Wochen

📞 Kontakte​

RolleKontakt
KI-Manager[ki-manager@gealan.de]
Datenschutzbeauftragte:r[dsb@gealan.de]
IT-Security[it-security@gealan.de]
Betriebsrat[betriebsrat@gealan.de]
Legal / Einkauf[legal@gealan.de]

📚 Weiterführende Dokumente​

DokumentLink
📘 KI-Check Grundlagen-Handbuch – Warum, Was, Wie, Rechtlicher Rahmen, Risk-Scoring, RollenGrundlagen-Handbuch
E2E KI-Prüfung V3.2 – Vollständige technische ProzessdokumentationE2E V3.2
SOP Einsatz von KI-Anwendungen – Verbindliche VerfahrensanweisungSOP
Nutzungsrichtlinie KI – Was darf ich als Mitarbeiter:in?Nutzungsrichtlinie
Codex – 10 Gebote für KI – MerkregelnCodex
Merkblatt Hochrisiko-KI – Was ist verboten? Redesign-BeispieleMerkblatt
Rechtlicher Rahmen – Detaillierte Erläuterung EU AI Act, DSGVO, BetrVG, RBVRechtlicher Rahmen
Risk-Scoring & Routing – Vollständige Scoring-MatrixRisk-Scoring

Dokument-Status: ✅ Freigegeben
Erstellt von: KI-Manager
Geprüft durch: DSB, IT-Security, Betriebsrat, Legal, HR
Freigegeben durch: Geschäftsführung
Freigabe-Datum: 17.02.2026

VersionDatumÄnderung
3.317.02.2026Systemtyp in Schritt 1 ergänzt (14. Pflichtfeld); Schritt 4 bereinigt (Cloud & Datenspeicherung zu Schritt 6 verschoben); Hinweise zur Feldverteilung ergänzt
3.216.02.2026Neue Handbuch-Version (Synthese aus V3.1, ausführliche Praxisanleitung, 7-Punkt-Struktur pro Schritt)
3.115.02.2026Aktualisierung nach finalen Dokumentnamen
3.001.02.2026Anpassung an EU AI Act (vollständige Geltung ab 02.08.2024)

✅ Ende des Handbuchs