Zugang geschützt

EU AI Act — Betreiber-Guide
EU AI Act · Betreiber-Perspektive · Referenz

Wer KI einsetzt, muss wissen, was er einsetzt.

Entscheidungsmatrix und schrittweiser Umsetzungsguide für die zentralen Betreiberpflichten der Verordnung (EU) 2024/1689 — ausgelegt auf den Worst Case: keine bestehenden Strukturen, Neueinführung ab null.

STAND · APRIL 2026 STICHTAG · 02.08.2026 (ANHANG III) DE-AUFSICHT · BNETZA / KOKIVO
Inhalt
  1. Entscheidungsmatrix — Ja/Nein-Pfade durch den AI Act
  2. Art. 4 — KI-Kompetenzpflicht (für alle)
  3. Art. 5 — Verbotsprüfung
  4. Art. 25 — Anbieter-Falle prüfen
  5. Art. 50 — Transparenzpflichten
  6. Art. 26 — Hochrisiko-Betreiberpflichten (12 Absätze)
  7. Art. 27 — Grundrechts-Folgenabschätzung (FRIA)

01 · MATRIXEntscheidungsmatrix

Der Baum beantwortet die Frage: Welche AI-Act-Pflichten gelten für diesen konkreten KI-Einsatz? Ein Durchlauf pro KI-System im Unternehmen. Die Antworten sind dokumentationspflichtig — auch das Ergebnis „nicht Hochrisiko".

START Für jedes KI-System einzeln Q1 · Fällt der Einsatz unter Art. 5 Verbote? Social Scoring · Manipulation · Ungezielte Gesichtsbildersammlung · Biometr. Echtzeit-Fernidentif. · Emotionserkenn. am Arbeitsplatz JA STOP Einsatz rechtswidrig NEIN Q2 · Verändern wir das System? (Art. 25) • Eigenes Branding? • Retraining / Architekturänderung? • Zweckänderung zu Hochrisiko? • GPAI-Finetuning für Hochrisiko-Einsatz? JA ANBIETER Art. 16, Art. 9-15 anderer Pflichtenpfad NEIN Q3 · Chatbot · Voicebot · Deepfake · KI-Content? Direkte Interaktion mit Menschen oder KI-generierte Inhalte zu Themen von öffentlichem Interesse JA (parallel) Art. 50 Transparenzpflichten WEITER Q4 · Fällt das System unter Anhang III? • Biometrie (nicht verboten) • Kritische Infrastruktur • Bildung / Berufsausbildung • Beschäftigung / HR • Grundversorgung (Kredit / Versicherung / Sozialleistungen) • Strafverfolgung • Migration / Asyl • Justiz / Demokratie NEIN NICHT-HOCHRISIKO Nur Art. 4 Kompetenzpflicht + ggf. Art. 50 JA Q5 · Greift Ausnahme nach Art. 6 Abs. 3? 1. Eng umgrenzte prozedurale Aufgabe 2. Verbesserung menschl. Tätigkeit 3. Musterkennung ohne Ersatz 4. Rein vorbereitende Aufgabe (Profiling → immer HR!) JA + kein Profiling NICHT-HOCHRISIKO Dokumentierte Begründung · Art. 6(4) NEIN / Profiling HOCHRISIKO-SYSTEM Art. 26 Betreiberpflichten greifen vollständig Q6 · FRIA-pflichtig nach Art. 27? • Öffentliche Stelle • Private Grundversorgung • Kreditscoring (Anh. III Nr. 5 b) • Lebens- / Krankenversicherungs-Pricing (Anh. III Nr. 5 c) JA Art. 26 + Art. 27 FRIA VOR Einsatz + MÜB-Notifikation NEIN Art. 26 allein 12 Betreiberpflichten QUERSCHNITTSPFLICHTEN · IMMER ZU PRÜFEN ▸ Art. 4 Kompetenzpflicht · gilt für jeden KI-Nutzer im Unternehmen ▸ Art. 5 Verbote · gelten absolut, unabhängig von Risikoklasse ▸ Art. 50 Transparenz · sobald Chatbot / Deepfake / KI-Content ▸ Betriebsrat nach BetrVG §§ 87, 90 · bei jedem Arbeitsplatz-KI-Einsatz ZEITACHSE · BETREIBER 02.02.2025 Art. 4 Kompetenz · Art. 5 Verbote 02.08.2025 GPAI-Anbieterpflichten (mittelbar) 02.08.2026 Art. 26 · Art. 27 · Art. 50 · Bußgelder durchsetzbar 02.08.2027 Art. 6(1) · Anhang I · Bestandssyst. · ggf. Omnibus-Verschiebung LEGENDE Entscheidungsknoten (Ja/Nein) Stop · Rechtswidrig · Hochrisiko Zulässiger Endzustand · Pflichten zugeordnet Anbieter-Pfad (nicht in diesem Guide) Dokumentation jedes Durchlaufs ist Pflicht — auch bei Ergebnis „nicht Hochrisiko". Für jedes KI-System einzeln, pro wesentlicher Änderung erneut. Digital-Omnibus (19.11.2025) könnte 02.08.2026 auf 02.12.2027 verschieben — Status: Trilog.

02 · UMSETZUNGSchritt-für-Schritt-Guides

Jeder Guide geht vom Worst Case aus: keine bestehenden Strukturen, keine Inventare, keine Policies, keine Schulungen. Das ist die Ausgangslage bei einer Neueinführung — und realistisch auch bei 70% der bestehenden deutschen Mittelständler.

GUIDE 01 · IMMER
Art. 4 — KI-Kompetenzpflicht
Pflicht für alle Betreiber · seit 02.02.2025 in Kraft · Größe irrelevant
Ausgangslage (Worst Case) Niemand im Unternehmen weiß, welche KI-Systeme überhaupt im Einsatz sind. Mitarbeitende nutzen ChatGPT / Copilot / Claude informell, ohne Schulung, ohne Richtlinie, ohne Nachweis. Embedded KI (M365, DATEV, Salesforce, Personio) läuft unbemerkt mit.

Schritte

  1. KI-InventurAlle KI-Systeme erfassen. Nicht nur die offensichtlichen (Chatbots, GPT) — auch eingebettete: Copilot in M365, Predictive Features in CRM, Scoring in HR-Tools, Assistenten in Code-Editoren. Quelle: IT-Asset-Liste + Fachbereichs-Interviews + Vertragsdurchsicht SaaS.
  2. Nutzer-MappingPro System: Wer nutzt es, in welcher Rolle, für welche Zwecke, mit welchen Daten. Das wird später Grundlage der Risikoklassifizierung (Zweck entscheidet).
  3. Kompetenzprofile definierenDrei Stufen reichen: Basis-Nutzer (alle), Power-User (HR / Finance / Marketing etc.), Aufseher (Human-Oversight-Personen nach Art. 26). Pro Stufe: Welche Kenntnisse sind angemessen?
  4. SchulungsprogrammModular aufbauen: Basismodul (Grundlagen, Risiken, Halluzinationen, Datenschutz, Prompting), Vertiefungsmodule pro Stufe. Interne oder externe Durchführung — Hauptsache dokumentiert.
  5. AssessmentKeine Fortbildung ohne Wissensabfrage. Kurzer Test pro Modul. Sonst ist „Kompetenz" nicht nachweisbar.
  6. NachweisdokumentationPro Mitarbeitenden: Name, Rolle, absolvierte Module, Datum, Testergebnis. Formfrei, aber personalisiert und revisionsfest.
  7. NutzungsrichtlinieWas darf man mit welchem Tool? Welche Daten dürfen rein? Wer ist Ansprechpartner bei Unsicherheit? Schriftlich, an alle kommuniziert, bestätigt.
  8. Update-RhythmusHalbjährliches Update-Modul bei Rechtsänderungen (Digital Omnibus, neue Guidelines, sektorale Leitlinien). Ohne Rhythmus altert die Kompetenz weg.
Abdeckung & Folgerung
Art. 4 Kompetenz Art. 5 Verbotsprüfung Art. 25 Anbieter-Falle Art. 50 / 26 / 27 Risikoklassifizierung Die KI-Inventur aus Schritt 1 ist die Grundlage für alle weiteren Artikel. Ohne vollständiges Inventar lässt sich weder Art. 5 sauber prüfen noch Art. 25 oder Art. 26 anwenden. Art. 4 ist damit der sinnvolle Erst-Auftrag jedes Beratungsmandats. DIREKT ABGEDECKT: Art. 4 (KI-Kompetenz) VORBEREITEND FÜR: Art. 5, 25, 26, 27, 50
Direkt abgedeckt Vorbereitet / nächster Schritt Nicht betroffen
Nächster Schritt Mit dem fertigen KI-Inventar unmittelbar in Art. 5 Verbotsprüfung und parallel Art. 25 Anbieter-Falle-Check eintreten. Beide sind kurz — aber ohne sie kannst du die Risikoklassifizierung nicht korrekt abschließen.
GUIDE 02 · VETO
Art. 5 — Verbotsprüfung
Acht absolute Verbote · seit 02.02.2025 · bis 35 Mio. € / 7% Umsatz bei Verstoß
Ausgangslage (Worst Case) Das Unternehmen hat nie geprüft, ob eingesetzte Systeme verbotene Praktiken bedienen. Typische blinde Flecken: Emotionserkennung in Call-Center-Software, Social-Scoring-ähnliche Gamification in HR-Tools, biometrische Zugangssysteme mit unspezifizierter Datenbasis.

Schritte

  1. Acht Verbotskategorien der Reihe nach prüfenFür jedes KI-System aus dem Inventar durchgehen: (a) Unterschwellige Beeinflussung/Manipulation, (b) Ausnutzung von Schwächen bestimmter Personengruppen, (c) Social Scoring durch Behörden, (d) Predictive Policing rein auf Persönlichkeitsbasis, (e) Ungezielte Gesichtsbildersammlung aus Internet/CCTV, (f) Emotionserkennung am Arbeitsplatz/in Bildung (mit engen Ausnahmen), (g) Biometrische Kategorisierung nach sensiblen Merkmalen, (h) Echtzeit-Fernidentifizierung im öffentlichen Raum zu Strafverfolgungszwecken.
  2. Dokumentierte NegativbestätigungPro System ein kurzer Vermerk: „System X, Einsatzzweck Y, geprüft gegen Art. 5 lit. a–h, keine Verbotstatbestände erfüllt, Datum, verantwortlich." Formal simpel, rechtlich essenziell.
  3. Bei Treffer: Sofortiger EinsatzstoppKein Weiterbetrieb, auch nicht „übergangsweise". Rechtsrat einholen (ob tatsächlich Verbotstatbestand erfüllt oder Fehleinschätzung). Wenn bestätigt: abschalten, dokumentieren, Personal informieren.
  4. Grenzfälle: Externe EinschätzungBesonders bei Emotionserkennung (Ausnahmen für Sicherheit/Medizin), biometrischer Kategorisierung (Kennzeichnung nach „sensiblem Merkmal" auslegungsoffen) und Manipulation (Abgrenzung zu legitimem Marketing). Im Zweifel externer Rechtsrat — Fehleinschätzung kostet potentiell 7% Konzernumsatz.
  5. Anbieter-Anfrage bei UnsicherheitWenn SaaS-KI eingesetzt wird und unklar ist, welche Techniken tatsächlich laufen (z.B. „adaptive UX" in Marketing-Tools): schriftliche Anbieter-Anfrage mit konkreten Fragen. Antwort dokumentieren.
Abdeckung & Folgerung
Art. 5 Verbote Art. 25 Anbieter-Rolle Anhang III-Prüfung Hochrisiko-Klass. Art. 5 ist ein reiner Gate-Check: entweder geht das System durch, oder es wird abgeschaltet. Die Prüfung erzeugt pro System die erste belastbare Legal-Opinion im Dossier. Parallel laufen Art. 4 (Kompetenz) und Art. 25 (Anbieterrolle) weiter. DIREKT ABGEDECKT: Art. 5 FOLGT: Art. 25 Anbieter-Falle-Check
Direkt abgedeckt Nächster Schritt
Nächster Schritt Art. 25 Anbieter-Falle. Muss vor der Hochrisiko-Klassifizierung laufen — wenn das Unternehmen tatsächlich Anbieter ist, greifen andere, strengere Pflichten (Art. 16 ff.), und die Betreiber-Logik dieses Guides passt nicht mehr.
GUIDE 03 · KRITISCH
Art. 25 — Anbieter-Falle prüfen
Rollenwechsel Betreiber → Anbieter · häufigster Compliance-Fehler im Mittelstand
Ausgangslage (Worst Case) Das Unternehmen hält sich selbstverständlich für „nur Nutzer" von KI. Tatsächlich werden zugekaufte Modelle mit eigenen Daten feingetuned, interne Tools unter eigenem Branding deployed, oder GPAI-Agenten für HR- / Finance-Entscheidungen gebaut. Die Anbieterrolle ist de facto eingetreten, ohne dass es jemand gemerkt hat.

Schritte

  1. Vier Trigger-Fragen pro System(1) Versehen wir das System mit eigenem Namen/Logo und bringen es in Verkehr? (2) Nehmen wir eine wesentliche Änderung am System vor, die den Hochrisiko-Charakter berührt — Retraining, Architekturänderung, signifikantes Finetuning? (3) Verändern wir den Zweck so, dass ein Nicht-Hochrisiko-System nun Hochrisiko-Aufgaben übernimmt? (4) Finetunen wir ein GPAI-Modell (GPT, Claude, Llama) für einen Hochrisiko-Einsatz?
  2. Retraining: harte FrageWas zählt als „wesentliche Änderung"? Einfaches Prompt-Engineering: nein. Einzelne Function-Calling-Integration: meist nein. RAG mit eigenen Dokumenten: meist nein. Finetuning auf eigenen Datensätzen: meist ja. Eigene Agent-Architektur um ein LLM: fast immer ja.
  3. Agent-Systeme: besonderer AlarmWer Agenten baut, die selbstständig Entscheidungen treffen, Tools nutzen und Aktionen im Unternehmen ausführen (HR, Finance, Vertrag), baut mit hoher Wahrscheinlichkeit ein neues KI-System im Sinne des AI Act — mit Anbieterrolle. Das ist 2026 der häufigste Anbieter-Falle-Trigger.
  4. Bei JA zu einer Trigger-Frage: Anbieter-Pflichtenpfad öffnenDer Gang wechselt vollständig: Art. 16 (allgemeine Anbieterpflichten), Art. 9 (Risikomanagementsystem), Art. 10 (Daten-Governance), Art. 11 (technische Dokumentation), Art. 12 (Logging), Art. 13 (Transparenz gegenüber Betreibern), Art. 14 (Human Oversight Design), Art. 15 (Genauigkeit / Robustheit / Cybersicherheit), Art. 43 (Konformitätsbewertung), Art. 47 (EU-Konformitätserklärung), Art. 48 (CE-Kennzeichnung), Art. 49 (Registrierung EU-Datenbank).
  5. Bei allen NEIN: Dokumentierte NegativprüfungSchriftlicher Vermerk pro System, dass die vier Trigger negativ geprüft wurden, mit Begründung. Das ist der Gegennachweis, falls eine Aufsicht später nachfragt.
  6. Vertragliche Absicherung mit dem AnbieterAuch als Betreiber sollten Verträge mit KI-Anbietern klären: Welche Hochrisiko-Einsätze sind vom Anbieter freigegeben? Wer verantwortet Konformität? Wer stellt technische Dokumentation bereit? Wer haftet bei Bußgeld?
Abdeckung & Folgerung
Art. 25 Rollen-Check ANBIETER-Pfad Art. 16, 9-15, 43, 47, 48, 49 BETREIBER-Pfad weiter zu Art. 50 / 26 / 27 Anh. III-Prüf. Hochrisiko? Art. 25 ist ein Weichen-Artikel: Entweder bleibt der Pfad der Betreiber-Guide relevant, oder das Unternehmen ist rechtlich Anbieter — dann gelten Art. 16 ff. (dieser Guide verzichtet bewusst auf Anbieterpflichten). DIREKT ABGEDECKT: Art. 25 FOLGT (Betreiber): Anhang III-Klassifizierung
Direkt abgedeckt Nächster Schritt (Betreiber)
Nächster Schritt Pro System Anhang-III-Klassifizierung: Fällt der Einsatzzweck unter eine der acht Hochrisiko-Kategorien? Wenn ja: weiter zu Art. 26. Wenn nein: nur Art. 4 + ggf. Art. 50. Parallel Art. 50 prüfen, wenn Chatbot, Voicebot, Deepfake oder KI-Content im Einsatz sind.
GUIDE 04 · BREIT
Art. 50 — Transparenzpflichten
Ab 02.08.2026 · trifft vermutlich mehr KMU als Hochrisiko-Regeln · vier Absätze
Ausgangslage (Worst Case) Chatbot auf der Unternehmenswebsite läuft ohne Kennzeichnung. Marketingabteilung nutzt KI-generierte Bilder ohne Hinweis. Voicebot im Kundenservice gibt sich als Mensch aus. Social-Media-Redaktion produziert KI-Texte zu politischen Themen ohne Kenntlichmachung. Nichts davon ist dokumentiert.

Schritte

  1. Touchpoint-InventurAlle Stellen, an denen KI direkt mit Menschen interagiert oder Output an Menschen ausliefert: Chatbots (Web, App, WhatsApp), Voicebots (Hotline, IVR), Video-Avatare, Deepfakes im Marketing, KI-generierte Bilder / Texte / Audio. Pro Touchpoint: Wer ist verantwortlich? Welches Tool? Welche Zielgruppe?
  2. Absatz-ZuordnungArt. 50 hat vier Absätze mit unterschiedlichen Adressaten: Abs. 1 — Anbieter generativer KI (Wasserzeichen, Provenance); Abs. 2 — Betreiber von Emotionserkennung / biometrischer Kategorisierung (Info an Betroffene); Abs. 3 — Betreiber von Deepfakes (Kennzeichnung als künstlich); Abs. 4 — Betreiber von KI-Texten zu Angelegenheiten öffentlichen Interesses (Kennzeichnung, mit redaktioneller Ausnahme).
  3. Chatbot-KennzeichnungAus Art. 50 Abs. 1 (Anbieter-Pflicht) ergibt sich mittelbar, dass der Betreiber sicherstellen muss, dass der Nutzer weiß, mit einer KI zu interagieren. Saubere Umsetzung: erstes Chatbot-Statement enthält „Sie sprechen mit einem KI-Assistenten". Bei Voicebots analog. Keine Täuschung, kein menschlicher Name ohne Zusatz.
  4. Deepfake-Kennzeichnung (Abs. 3)Jedes künstlich erzeugte oder bearbeitete Bild-/Audio-/Videomaterial, das eine reale Person, einen Gegenstand, Ort oder Ereignis darstellt und fälschlich als echt erscheinen könnte, muss als KI-Output gekennzeichnet sein. Umsetzung: sichtbarer Hinweis im Bild, in der Bildunterschrift, in den Metadaten — mindestens eines davon klar und zugänglich.
  5. KI-Text-Kennzeichnung (Abs. 4)KI-generierte Texte, die über Angelegenheiten öffentlichen Interesses informieren sollen, müssen als KI-generiert gekennzeichnet sein — außer der Text durchläuft redaktionelle Prüfung durch einen Menschen mit Verantwortlichkeit. Für Unternehmens-Content-Marketing zu politischen / wirtschaftlichen Themen relevant.
  6. Interne RichtliniePro Content-Kategorie festschreiben, welche Kennzeichnung wie aussieht. Wo steht der Hinweis? Wie formuliert? Wer prüft vor Veröffentlichung? In bestehende Redaktions-/Publishing-Workflows integrieren, nicht als Parallelprozess.
  7. MonitoringStichprobenhafte Nachprüfung: Ist die Kennzeichnung tatsächlich auf allen Outputs? Besonders bei automatisierten Generierungen, wo der Prompt-Änderung die Kennzeichnung kippen kann. Quartalsweise reicht.
Abdeckung & Folgerung
Art. 50 Abs. 1-4 Art. 4 parallel Art. 26 (falls HR) Hochrisiko? Art. 50 ist Querschnitt: gilt zusätzlich zu Hochrisiko-Pflichten, nicht statt dessen. Ein Chatbot kann unter Art. 50 fallen UND gleichzeitig Hochrisiko sein (z.B. in der Kreditberatung) — dann greifen Art. 50 + Art. 26 + Art. 27 kumulativ. DIREKT ABGEDECKT: Art. 50 Abs. 1-4 NÄCHSTER SCHRITT: Anhang-III-Prüfung
Direkt abgedeckt Nächster Schritt (falls HR) Parallel aktiv
Nächster Schritt Wenn Chatbot / Voicebot / KI-Output zugleich in einem Hochrisiko-Kontext (HR-Bewerberchat, Kreditvorklärung, Versicherungs-FAQ mit Auswirkung auf Vertragsabschluss) betrieben wird: Art. 26. Sonst genügt Art. 50 + Art. 4 als Gesamtpflichtenkatalog.
GUIDE 05 · HOCHRISIKO
Art. 26 — Hochrisiko-Betreiberpflichten
12 Absätze · ab 02.08.2026 · Kern des Betreiber-Compliance-Pakets
Ausgangslage (Worst Case) Ein Hochrisiko-System (z.B. Bewerber-Scoring-Tool) ist bereits produktiv im Einsatz. Keine Gebrauchsanweisung vorhanden, keine Human-Oversight-Rolle zugewiesen, kein Logging, keine Monitoring-Prozesse, keine Vertragsklauseln mit dem Anbieter. Der Betriebsrat wurde nicht informiert.

Schritte — pro Absatz geordnet

  1. Abs. 1 — Gebrauchsanweisung beschaffen und lesenVom Anbieter die vollständige Gebrauchsanweisung / Betriebsanleitung anfordern. Fehlt sie, ist der Anbieter selbst nicht konform — schriftliche Nachforderung mit Fristsetzung. Tatsächlicher Einsatz wird gegen die Gebrauchsanweisung abgeglichen; Abweichungen werden entweder angepasst oder als Zweckänderung dokumentiert (dann Art. 25 erneut!).
  2. Abs. 2 — Human-Oversight-Person benennenKonkrete natürliche Person, nicht „die Abteilung". Anforderungsprofil: fachliche Kenntnis des Einsatzbereichs, KI-Kompetenz (Art. 4!), Autorität zur Intervention bis zum Systemstopp, Zeitbudget. Rollenbeschreibung, Vertretungsregel, Eskalationspfad schriftlich. Mindestens eine Person; bei 24/7-Betrieb oder hohem Volumen mehrere im Schichtbetrieb.
  3. Abs. 3 — Input-Daten kontrollierenSoweit der Betreiber die Eingabedaten auswählt: Relevanz (gehören die Daten zur Fragestellung?), Repräsentativität (decken sie die Population ab, die das System bewerten soll?), Qualität (Fehler, Dubletten, veraltete Stände?). Pro Datenquelle ein Datenblatt: Herkunft, Aktualisierungsfrequenz, dokumentierte Qualitätsprüfung. Bei SaaS-Systemen: klären, welche Inputs die Instanz vom Betreiber erhält.
  4. Abs. 4 — Laufendes Monitoring + AussetzungspflichtKPIs pro System definieren: Fehlerrate, Bias-Indikatoren (z.B. Ablehnungsquoten nach Gruppen), Beschwerdeaufkommen, abweichende Entscheidungen der Human-Oversight. Quartalsweiser Review mit Protokoll. Eskalations-Playbook: Ab welchem Schwellwert wird ausgesetzt? Wer entscheidet? Wer informiert Anbieter und Behörde?
  5. Abs. 5 — Logging mind. 6 MonateWelche Logs das System erzeugt, ist Anbieterthema. Welche davon der Betreiber hostet und aufbewahrt, ist Betreiberthema. Pro System klären: Wo liegen die Logs? Wer hat Zugriff? Wie lange werden sie vorgehalten (mindestens 6 Monate; in regulierten Branchen länger)? Sind sie behördenzugänglich? Bei Cloud-KI: Vertragsklausel mit dem Anbieter prüfen/nachverhandeln.
  6. Abs. 6 — Arbeitnehmer VOR Einführung informierenReihenfolge entscheidend: Informationspflicht an Arbeitnehmervertretung und betroffene Beschäftigte BEVOR das System in Betrieb geht. Überlagert sich mit § 87 Abs. 1 Nr. 6 und § 90 BetrVG — Betriebsrat hat Mitbestimmungsrecht. Faustregel: mindestens 6 Wochen Vorlauf, schriftliche Information, Dialog, Betriebsvereinbarung wenn möglich.
  7. Abs. 7 — Registrierung öffentlicher StellenBehörden, öffentliche Einrichtungen, andere öffentliche Stellen müssen sich vor Einsatz in der EU-Datenbank (Art. 71) registrieren. Privatwirtschaftliche Betreiber sind nicht registrierungspflichtig. Bei Mischformen (öffentlich-rechtlicher Rundfunk, kommunale Unternehmen) im Einzelfall prüfen.
  8. Abs. 8 — Erklärung auf Betroffenen-VerlangenWer von einer Hochrisiko-KI-Entscheidung betroffen ist, kann eine klare, aussagekräftige Erklärung verlangen — zur Rolle der KI und zu den Hauptelementen der Entscheidung. Umsetzung: Standard-Erklärungstext pro Entscheidungstyp vorbereiten; Anfrage-Kanal (E-Mail, Formular) einrichten; Reaktionsfrist definieren (analog DSGVO-Auskunft: i.d.R. 30 Tage). Unterscheidet sich von Art. 22 DSGVO — greift auch bei KI-unterstützten Entscheidungen mit menschlichem Finalzug.
  9. Abs. 9 — Behördenkooperation vorbereitenTechnische Dokumentation des Anbieters muss jederzeit beschaffbar sein. Eigene Logs, Monitoring-Reports, Schulungsnachweise, Human-Oversight-Protokolle in einem Auskunfts-Dossier zusammenführen. Ein Verantwortlicher als Behörden-Ansprechpartner benannt. Antwortfristen der BNetzA einhalten.
  10. Abs. 10 — DSFA nutzen statt neu aufsetzenWer eine Datenschutz-Folgenabschätzung nach Art. 35 DSGVO hat: bestehendes Dokument erweitern um KI-spezifische Bewertungen (Bias, Genauigkeit, Auswirkungen auf Grundrechte jenseits Datenschutz). Spart Aufwand und vermeidet Doppelstrukturen. Bei FRIA-Pflicht nach Art. 27: DSFA und FRIA verzahnen.
  11. Abs. 11 — Vorfallmeldung einrichten„Schwerwiegender Vorfall" ist in Art. 3 Nr. 49 definiert: Tod, schwere Gesundheitsschäden, ernsthafte Störung kritischer Infrastruktur, Verletzung von Grundrechten u.a. Meldekette: Betreiber → Anbieter (unverzüglich) → Anbieter meldet an Behörde (Fristen nach Art. 73 gestaffelt, bei Tod sofort, sonst bis 15 Tage). Interne Meldeprozedur definieren, Verantwortlichkeiten klären.
  12. Abs. 12 — FRIA-Verweis prüfenWenn der Betreiber unter Art. 27 fällt (öffentliche Stelle / private Grundversorgung / Kreditscoring / Lebens- und Krankenversicherung-Pricing), gilt zusätzlich die Grundrechts-Folgenabschätzung — vor Inbetriebnahme, siehe Guide 06.
Abdeckung & Folgerung
Art. 26 — Abs. 1 bis 12 1 Gebrauchsanweisung 2 Human Oversight 3 Input-Daten 4 Monitoring 5 Logging 6 Arbeitnehmer-Info 7 Registrierung (öff.) 8 Erklärungsrecht 9 Behördenkoop. 10 DSFA nutzen 11 Vorfallmeldung 12 FRIA-Verweis Art. 4 vorausgesetzt Kompetenz v. Oversight-Person DSGVO / DSFA (Art. 35) Abs. 10 verzahnt Art. 27 FRIA falls Abs. 12 greift Art. 26 ist der umfangreichste Betreiber-Paragraph. Er baut auf Art. 4 (Kompetenz), verzahnt mit DSGVO (DSFA) und führt im Sonderfall weiter zu Art. 27 FRIA. NÄCHSTER SCHRITT: Art. 27 FRIA-Prüfung (falls Abs. 12 greift)
Art. 26 voll abgedeckt Nächster Schritt (FRIA) Vorausgesetzt / verzahnt
Nächster Schritt Art. 27 Grundrechts-Folgenabschätzung — aber nur, wenn Abs. 12 greift (öffentliche Stelle, Grundversorgung, Kreditscoring, Lebens-/Krankenversicherung). Andernfalls ist mit Art. 26 der Kern-Pflichtenkreis geschlossen; laufender Betrieb wird durch jährlichen Review und Vorfallprotokoll stabilisiert.
GUIDE 06 · FRIA
Art. 27 — Grundrechts-Folgenabschätzung
Nur für bestimmte Betreiber · vor Inbetriebnahme · separates Instrument zu DSFA
Ausgangslage (Worst Case) Der Betreiber fällt unter Art. 27 (z.B. Kommunalverwaltung mit KI-gestütztem Sozialleistungs-Screening, oder private Krankenversicherung mit Risiko-Scoring für Prämien), hat bisher nur DSFA gemacht, keine FRIA. System steht vor Inbetriebnahme, Projektplan sieht Go-Live in drei Monaten vor.

Schritte

  1. Anwendbarkeit prüfenFRIA-Pflicht besteht für: (a) Einrichtungen des öffentlichen Rechts, (b) private Akteure, die öffentliche Dienste erbringen, (c) Betreiber von Hochrisiko-KI nach Anhang III Nr. 5 lit. b (Kreditwürdigkeitsbewertung natürlicher Personen, außer Betrug), (d) Betreiber von Hochrisiko-KI nach Anhang III Nr. 5 lit. c (Risikobewertung / Preisgestaltung bei Lebens- und Krankenversicherung).
  2. Template auswählenDas Amt für Künstliche Intelligenz (AI Office) veröffentlicht bzw. wird ein Muster-Template bereitstellen. In der Zwischenzeit: eigene Struktur auf Basis der Art. 27 Abs. 1 Mindestinhalte — siehe Schritt 3.
  3. Mindestinhalte dokumentieren (Abs. 1)(a) Beschreibung der Betreiberprozesse, in denen das System eingesetzt wird, (b) Einsatzdauer und -häufigkeit, (c) betroffene natürliche Personen/Gruppen, (d) spezifische Grundrechtsrisiken (in welcher Gruppenspezifität?), (e) Maßnahmen menschlicher Aufsicht nach Art. 26 Abs. 2, (f) Maßnahmen bei Risikoeintritt (Beschwerdemechanismen, interne Governance).
  4. Grundrechts-MappingKonkrete Grundrechte der EU-Grundrechtecharta durchgehen: Menschenwürde (Art. 1), Nichtdiskriminierung (Art. 21), Datenschutz (Art. 8), Recht auf gute Verwaltung (Art. 41), faires Verfahren (Art. 47) u.a. Pro relevantem Grundrecht: Wie wirkt sich das KI-System potenziell aus? Welche Populationsgruppen sind besonders exponiert?
  5. RisikominderungsmaßnahmenPro identifiziertem Risiko: technische und organisatorische Maßnahmen. Technisch: Bias-Tests, Fairness-Metriken, Konfidenzschwellen, Fallback-Regeln. Organisatorisch: verstärkte Human Oversight, Eskalationswege, Beschwerdemanagement, regelmäßige Audits.
  6. DSFA-VerzahnungWenn DSFA nach Art. 35 DSGVO vorliegt: die dort behandelten Datenschutzrisiken werden nicht erneut aufgerollt, sondern referenziert. FRIA ergänzt um Grundrechte jenseits Datenschutz (Nichtdiskriminierung, Verfahrensrechte, Teilhabe).
  7. Notifikation an MarktüberwachungsbehördeNach Abschluss der FRIA: Meldung an die zuständige Marktüberwachungsbehörde (in Deutschland perspektivisch BNetzA / KoKIVO, je nach Sektor auch BaFin bzw. Datenschutzaufsicht). Formular nach Art. 27 Abs. 3 — das AI Office wird auch hierfür ein Template bereitstellen.
  8. Aktualisierung bei Änderungen (Abs. 2)Ändern sich wesentliche Elemente (Einsatzzweck, Gruppen, System-Architektur), muss die FRIA aktualisiert werden. Review-Rhythmus: mindestens jährlich, zusätzlich anlassbezogen.
Abdeckung & Folgerung
Art. 27 FRIA Art. 26 parallel Hochrisiko-Betrieb DSGVO Art. 35 DSFA verzahnt MÜB Meldung FRIA ist der letzte Prüfschritt VOR Inbetriebnahme für den adressierten Betreiberkreis. Sie verzahnt sich mit DSFA (Datenschutz) und läuft parallel zum Art.-26-Betriebsregime. Nach Abschluss: MÜB-Notifikation — dann kann der Go-Live erfolgen. DIREKT ABGEDECKT: Art. 27 (FRIA) NACH GO-LIVE: Art. 26 laufender Betrieb
Direkt abgedeckt Parallel / verzahnt
Nächster Schritt Nach abgeschlossener FRIA und Notifikation an die MÜB: Go-Live. Ab diesem Moment greifen die laufenden Art. 26-Pflichten (Monitoring, Logging, Vorfallmeldung) plus jährliche FRIA-Aktualisierung. Bei wesentlichen Systemänderungen: erneute FRIA und Anbieter-Falle-Check (Art. 25) — Veränderung ist Trigger für Rollenprüfung.

03 · BETRIEBNach dem Go-Live

Mit abgeschlossener Erstumsetzung beginnt der laufende Betrieb. Vier Rhythmen, die institutionell verankert werden sollten:

  1. Quartalsweise · Monitoring-ReviewKPI-Check pro Hochrisiko-System, Bias-Indikatoren, Beschwerdeaufkommen, Human-Oversight-Protokoll. Dokumentierter Bericht.
  2. Halbjährlich · Kompetenz-Update (Art. 4)Rechtsänderungen (Digital Omnibus!), neue Leitlinien, sektorale Besonderheiten in Schulungsmodule einarbeiten. Alle Mitarbeitenden durchlaufen Update.
  3. Jährlich · FRIA-Review + GesamtauditFRIA aktualisieren, DSFA abgleichen, KI-Inventar nachziehen, Gebrauchsanweisungen der Anbieter auf Änderungen prüfen.
  4. Anlassbezogen · Rollen-Neuprüfung (Art. 25)Bei jeder wesentlichen Änderung am System — neues Fine-Tuning, Zweckerweiterung, Agent-Funktionen — Anbieter-Falle neu prüfen. Nicht warten bis zum Jahresaudit.