EU AI Act

Diese Seite ist derzeit noch ein Entwurf. Weitere Informationen sowie Diskussionen über Änderungen an diesem Entwurf gibt es evtl. auf der Diskussion-Seite.

---

Leitfaden zum EU AI Act (2024/1689): Risikoklassen, Pflichten für Anbieter/Betreiber, ISMS-Integration nach ISO 27001/BSI-Grundschutz. Fristen, Vorlagen

Einleitung

Der EU AI Act (Verordnung (EU) 2024/1689) stellt das weltweit erste umfassende Regelwerk für den sicheren und menschenrechtskonformen Einsatz von Künstlicher Intelligenz (KI) dar. Er verfolgt einen risikobasierten Ansatz, der KI-Systeme je nach potenzieller Gefährdung mit gestaffelten Pflichten belegt und so Innovationen fördert, während fundamentale Rechte geschützt werden.

Historie

• 2021: EU-Kommission legt Entwurf vor (21. April).​
• 2022–2023: Verhandlungen; EU-Rat nimmt Ausrichtung an (Dez. 2022), Einigung der Verhandlungsführer (Dez. 2023).​
• 2024: Vom Rat gebilligt (21. Mai 2024), Veröffentlichung im Amtsblatt (12. Juli), Inkrafttreten (1./2. August).
• Status 2026: Vollanwendbarkeit größtenteils (August 2026), Hochrisiko-KI bis August 2027.​

Zweck und Relevanz

Der Act schafft rechtliche Klarheit für Unternehmen, Behörden und Entwickler in der EU und darüber hinaus. Er adressiert Risiken wie Diskriminierung durch Bias, Manipulation oder Verlust der menschlichen Kontrolle und verhindert ein regulatorisches Vakuum angesichts der rasanten KI-Diffusion (z. B. generative Modelle wie ChatGPT). Relevanz ergibt sich aus hohen Bußgeldern (bis 7% globalen Umsatzes) und extraterritorialer Geltung: Jede KI, die in der EU vermarktet oder eingesetzt wird, fällt darunter.

Regelungsschwerpunkte

Der Act klassifiziert KI-Systeme in vier Risikostufen mit gestaffelten Pflichten:

• Unannehmbares Risiko (Art. 5): Verboten seit Feb. 2025, z. B. Echtzeit-Biometrie in öffentlichen Räumen (Ausnahmen: Strafverfolgung), Emotionserkennung am Arbeitsplatz, soziale Scoring-Systeme.
• Hohes Risiko (Art. 6, Anhang III): Strenge Anforderungen (z. B. Bildgebung in Medizin, kritische Infrastruktur, Bildung); Konformitätsbewertung, Risikomanagement, Datenqualität, Transparenz, menschliche Aufsicht.
• General-Purpose AI (GPAI, Kap. V): Seit Aug. 2025: Technische Dokumentation, Trainingsdaten-Summary, Risikominimierung (systemisches Risiko: Tests, Meldungen).​
• Geringes Risiko: Transparenzpflichten (z. B. Deepfakes kennzeichnen).​

Risikobasierter Ansatz

Im Gegensatz zu technologie-neutralen Regelwerken wie der DSGVO wendet der AI Act eine proportional proportionale Regulierung an: Von Verboten bei unannehmbarem Risiko (Art. 5) über strenge Anforderungen bei hohem Risiko (Art. 6 ff.) bis hin zu Transparenzpflichten bei geringem Risiko. Dies ermöglicht Flexibilität – z. B. Open-Source-GPAI mit Ausnahmen – und integriert sich nahtlos in bestehende Managementansätze.​

Geltungsbereich

• KI-Systeme: Software, die autonom Inhalte erzeugt, Vorhersagen trifft oder Entscheidungen fällt (Art. 3).
• Geografisch: EU-weit, extraterritorial bei EU-Betroffenen oder -Marktzugang.
• Akteure: Anbieter, Betreiber (Deployer), Importeure, Nutzer; Ausnahmen für Militär/Medizin (bereits reguliert).

Bezug zu ISMS

Der AI Act ergänzt Informationssicherheits-Managementsysteme (ISMS) nach ISO 27001 oder BSI IT-Grundschutz ideal. KI-Risiken (z. B. Modellklau, Datenvergiftung) fließen in Risikoanalysen (Cl. 6/8 ISO 27001) ein, Controls wie A.5.7 (Bedrohungserkennung) decken Cybersicherheit ab. Synergien zu NIS-2 (kritische Infrastruktur) und DSGVO (Datenverarbeitung) erleichtern die Umsetzung; eine KI-Richtlinie passt in den PDCA-Zyklus.

• Zweck und Relevanz des EU AI Act (Verordnung (EU) 2024/1689)
• Risikobasierter Ansatz: Von Technologie-neutral zu KI-spezifisch
• Geltungsbereich: KI-Systeme in der EU, extraterritoriale Wirkung
• Bezug zu ISMS (ISO 27001, BSI IT-Grundschutz, NIS-2)

Definitionen und Begriffe

Dieses Kapitel schafft ein einheitliches Begriffsverständnis, das für die rechtssichere Anwendung des EU AI Act und seine Einbettung in ein ISMS unerlässlich ist.

KI-System

Der EU AI Act definiert ein KI-System als ein durch Menschen entwickeltes System, das mit einem gewissen Grad an Autonomie auf Basis von Machine-Learning-, logik- oder wissensbasierten Methoden arbeitet und dazu bestimmt ist, aus Eingabedaten Output wie Vorhersagen, Entscheidungen, Empfehlungen oder Inhalte zu erzeugen, die Einfluss auf physische oder virtuelle Umgebungen haben.

Wesentliche Punkte dabei:

• Es geht ausdrücklich um Software; reine Hardware fällt nur mittelbar über das integrierte KI-System darunter.
• „Autonomie“ bedeutet nicht völlige Unabhängigkeit, sondern dass das System ohne jede einzelne Entscheidung eines Menschen operiert.
• Generative KI (z. B. Text-, Bild-, Code-Modelle) ist explizit eingeschlossen.

Für ein ISMS ist entscheidend: KI-Systeme sind als eigene Informations‑ und Geschäftsassets zu erfassen (Modell, Trainingsdaten, Runtime-Umgebung, Schnittstellen).

General-Purpose AI (GPAI)

GPAI-Modelle (general purpose AI) sind KI-Modelle, die für sehr unterschiedliche Zwecke eingesetzt werden können und nicht von vornherein auf ein enges Einsatzfeld begrenzt sind (z. B. große Sprachmodelle, multimodale Foundation Models).

Wesentliche Merkmale:

• Sie können in zahlreichen Branchen und Anwendungsfällen wiederverwendet werden (z. B. Kundenservice, Entwicklung, Office-Automation).
• Sie werden oft als Basis-Komponente in anderen KI-Systemen genutzt („downstream use“).
• Der EU AI Act sieht dafür eigene Pflichten vor (u. a. Dokumentation, Transparenz zu Trainingsdaten, Unterstützung nachgelagerter Anwendende).

Im ISMS-Kontext müssen GPAI-Modelle getrennt von spezifischen Fachanwendungen betrachtet werden: ein Modell kann unterschiedlichen Risikoklassen unterliegen, je nachdem, wofür es eingesetzt wird.

Rollen: Anbieter, Betreiber und weitere Akteure

Der EU AI Act unterscheidet mehrere Rollen, die für Governance, Haftung und ISMS-Abgrenzung wichtig sind:

• Anbieter (Provider): Die natürliche oder juristische Person, die ein KI-System erstmalig unter eigenem Namen oder Marke in Verkehr bringt oder in Betrieb nimmt. Für diese Rolle gelten u. a. die Pflichten zur Konformitätsbewertung, technischen Dokumentation, CE‑Kennzeichnung und Überwachung des Systems im Feld.
• Betreiber (Deployer/User): Die Stelle, die ein KI-System in eigener Verantwortung einsetzt. Im Unternehmenskontext ist das typischerweise die Organisation, die ein KI-Produkt im Fachbereich produktiv nutzt (z. B. ein Krankenhaus, das ein KI-Diagnosesystem betreibt).
• Importeur / Händler / Bevollmächtigte: Parteien, die KI-Systeme aus Drittstaaten in die EU bringen oder unter fremder Marke vertreiben, übernehmen bestimmte Teile der Anbieterpflichten.

Für das ISMS ist zentral: Die eigene Rolle muss pro KI-System klar bestimmt und dokumentiert werden, da sich daraus unterschiedliche Pflichten, Risiken und Kontrollanforderungen ableiten.

Risikostufen nach dem EU AI Act

Der Act arbeitet mit mehreren Risikoklassen, die das Schutzniveau und den Aufwand der Compliance unmittelbar steuern:

• Unannehmbares Risiko: KI-Praktiken, die grundsätzlich verboten sind, weil sie Grundrechte oder menschliche Würde in nicht vertretbarer Weise verletzen (z. B. bestimmte Formen von Sozialscoring oder manipulative Systeme, die gezielt Schwächen besonders schutzbedürftiger Gruppen ausnutzen).
• Hohes Risiko: KI-Systeme, die in besonders sensiblen Bereichen eingesetzt werden (z. B. kritische Infrastruktur, Medizin, Bildung, Beschäftigung, Strafverfolgung) oder über die im Ergebnis Menschen stark beeinflussende Entscheidungen getroffen werden. Hier gelten umfangreiche Anforderungen an Risikomanagement, Datenqualität, Transparenz, Dokumentation, Sicherheit und menschliche Aufsicht.
• Sonstige/geringere Risiken: KI-Anwendungen, bei denen primär Transparenzpflichten greifen (z. B. Kennzeichnung von Deepfakes, Hinweis auf Nutzung eines Chatbots).

Diese Risikostufen sind direkt in die Risikomethodik eines ISMS zu integrieren: Die Risikobeurteilung für KI muss sowohl die technischen als auch grundrechtlichen und regulatorischen Aspekte berücksichtigen.

Abgrenzung zu anderen Rechtsrahmen

Im ISMS-Umfeld ist es wichtig, die Schnittstellen zu anderen Regelwerken sauber zu trennen und gleichzeitig zu integrieren:

• DSGVO: Regelt die Verarbeitung personenbezogener Daten, unabhängig davon, ob KI genutzt wird. KI-spezifische Risiken (Profiling, automatisierte Entscheidungen) sind im Zusammenspiel mit DSGVO-Anforderungen (z. B. Transparenz, Betroffenenrechte, Data Protection Impact Assessment) zu betrachten.
• NIS-2 / KRITIS-Regime: Fokussiert auf Verfügbarkeit, Vertraulichkeit und Integrität von Diensten in kritischen Sektoren. Der AI Act ergänzt dies um KI-spezifische Anforderungen, insbesondere wenn kritische Funktionen KI-gestützt sind.
• Produktsicherheits- und Medizinprodukte-Recht: In manchen Bereichen (z. B. Medizin) gelten zusätzliche sektorale Anforderungen; der EU AI Act wirkt hier komplementär und darf nicht isoliert betrachtet werden.

Für ein ganzheitliches ISMS bedeutet das: KI-Compliance ist kein separates „KI-Silo“, sondern eine Querschnittsaufgabe, die an Datenschutz, Informationssicherheit und ggf. Sektorrecht gekoppelt ist.

Risikobasierte Klassifizierung (Art. 6–13)

Dieses Kapitel erläutert, wie die risikobasierte Systematik des EU AI Act funktioniert und welche inhaltlichen Schwerpunkte sich daraus für Governance und ISMS ergeben.

Unannehmbares Risiko (verbotene Praktiken)

Der EU AI Act verbietet bestimmte KI-Anwendungen vollständig, weil sie mit den Werten der EU nicht vereinbar sind. Typische Beispiele (aus Vereinfachungsgründen abstrakt formuliert):

• Systeme, die Verhalten in manipulativer Weise beeinflussen, um Menschen zu Entscheidungen zu drängen, die sie sonst nicht treffen würden, insbesondere, wenn schutzbedürftige Gruppen betroffen sind.
• Bestimmte Formen von sozialem Scoring, bei denen Menschen systematisch anhand ihres Verhaltens oder persönlicher Merkmale bewertet werden und diese Bewertungen weitreichende negative Konsequenzen haben.
• Bestimmte Einsatzformen biometrischer Echtzeit-Überwachung im öffentlichen Raum, mit eng begrenzten Ausnahmen (z. B. schwere Straftaten, Terrorabwehr) und strengen Voraussetzungen.

Für das ISMS heißt das:

• Solche Szenarien müssen bereits in der Konzeptionsphase ausgeschlossen werden.
• In Risikoanalysen sind sie als nicht zulässige Risikobehandlung zu dokumentieren.
• Architekturen und Prozesse sollten eine technische und organisatorische „Verbots-Compliance“ sicherstellen (z. B. durch Design-Reviews, Ethik- und Rechtsfreigaben).

Hohes Risiko (High-Risk-KI)

Hochrisiko-KI steht im Mittelpunkt des EU AI Act. Ein KI-System gilt als hochriskant, wenn es:

• in bestimmten sensiblen Sektoren eingesetzt wird (z. B. Medizin, kritische Infrastruktur, Bildung, Justiz, Migration), oder
• Funktionen erfüllt, die erhebliche Auswirkungen auf Rechte, Gesundheit, Sicherheit oder Lebensführung von Personen haben.

Für diese Systeme gelten unter anderem:

• Verpflichtendes Risikomanagement über den gesamten Lebenszyklus (Identifikation, Bewertung, Behandlung und Monitoring von Risiken).
• Anforderungen an Datenqualität und -repräsentativität, um systematische Diskriminierungen (Bias) zu vermeiden.
• Pflichten zur Transparenz und Nachvollziehbarkeit, inklusive technischer Dokumentation, Logging und Aufzeichnungsanforderungen.
• Sicherstellung menschlicher Aufsicht: Menschen müssen in der Lage sein, Entscheidungen nachzuvollziehen, zu hinterfragen und ggf. zu übersteuern.
• Anforderungen an Robustheit, Cybersicherheit und Genauigkeit des Systems.

Im ISMS sind Hochrisiko-KI-Systeme regelmäßig:

• als Assets mit hohem Schutzbedarf zu klassifizieren,
• Gegenstand vertiefter Risikoanalysen (inkl. Grundrechte-Aspekten),
• mit strengen technischen und organisatorischen Maßnahmen (Zugriffsmanagement, Monitoring, Incident-Handling) zu hinterlegen.

General-Purpose AI (GPAI) und systemische Risiken

GPAI-Modelle können selbst oder in ihrer Integration in Hochrisiko-Kontexte zu systemischen Risiken führen, etwa wenn sie in kritischer Infrastruktur, öffentlichen Verwaltungsprozessen oder weitverbreiteten Plattformen eingesetzt werden.

Für GPAI und insbesondere „systemische GPAI“ (Modelle mit besonders weitreichendem Einfluss) gelten zusätzliche Anforderungen, wie z. B.:

• Erstellung und Bereitstellung umfassender technischer Dokumentation für nachgelagerte Nutzende (Entwickelnde und betreibende Organisationen).
• Offenlegung einer allgemeinen Beschreibung der Trainingsdatenquellen, um Transparenz über Herkunft, Typ und mögliche Risiken der Daten zu schaffen.
• Durchführung von Risikoanalysen und -tests, bevor Modelle in großem Maßstab bereitgestellt werden.
• Verpflichtung, bekannte schwerwiegende Vorfälle zu überwachen und zu melden.

Für ein ISMS ist entscheidend:

• Werden GPAI-Modelle als Basis für eigene Produkte genutzt, muss die Organisation die vom Modell-Anbieter gelieferten Informationen systematisch in ihre eigene Risikobewertung, Dokumentation und Sicherheitsmaßnahmen integrieren.
• Es reicht nicht, auf den Anbieter zu verweisen – der eigene Einsatzkontext kann aus einem vermeintlich „allgemeinen“ Modell eine Hochrisiko-Anwendung machen.

Geringeres Risiko und Transparenzpflichten

Nicht jede KI-Anwendung fällt in die Kategorie „hohes Risiko“. Für zahlreiche KI-Systeme sind vor allem Transparenzanforderungen relevant, etwa:

• Kennzeichnung, dass Nutzende mit einem KI-System (z. B. Chatbot) interagieren und nicht mit einer natürlichen Person, sofern dies für das Verständnis erforderlich ist.
• Kennzeichnung von synthetischen oder manipulierten Inhalten (Deepfakes), damit Empfängerinnen und Empfänger erkennen können, dass Inhalte nicht authentisch sind.
• Gegebenenfalls Hinweise auf automatisierte Entscheidungsunterstützung, damit die Rolle der KI im Entscheidungsprozess nachvollziehbar ist.

Im ISMS sollten solche Systeme typischerweise:

• in der Asset-Liste mit moderatem Schutzbedarf geführt werden,
• mit klar definierten Informationspflichten und UX-Vorgaben verbunden sein,
• in Awareness- und Schulungskonzepten berücksichtigt werden (um z. B. Missverständnisse und Fehlinterpretationen zu vermeiden).

Auswirkungen auf das ISMS-Risikomanagement

Die risikobasierte Klassifizierung des EU AI Act sollte im ISMS konkret abgebildet werden, u. a. durch:

• Anpassung der Risikomethodik: Einbezug der AI-Risikokategorien (unannehmbar, hoch, sonstige) in die bestehenden Bewertungsraster für Eintrittswahrscheinlichkeit und Schadensausmaß.
• Ergänzung des Risikoregisters um KI-spezifische Risiken wie:
  • Verzerrte oder diskriminierende Outputs,
  • Datenvergiftung und Modellmanipulation,
  • unerwünschte Modelllecks (Training Data Leakage, IP-Verletzungen),
  • Verlust menschlicher Kontrolle und mangelnde Nachvollziehbarkeit.
• Verzahnung mit Compliance- und Datenschutz-Risiken (insbesondere DSGVO, NIS-2, branchenspezifische Vorgaben).
• Festlegung von Akzeptanzkriterien: Wann ist ein KI-Risiko tolerierbar, wann muss das Design geändert oder der Einsatz untersagt werden?

Damit wird der EU AI Act nicht nur als rechtliche „Schicht“ aufgesetzt, sondern integraler Bestandteil des bestehenden Managementsystems für Informationssicherheit und Compliance.

Rechte und Pflichten der Akteure

Der EU AI Act definiert klare Rollen und damit verbundene Pflichten, um Verantwortlichkeiten zuzuweisen und Haftungen abzugrenzen. Diese müssen im ISMS als organisatorische Rollen (z. B. RACI-Matrix) abgebildet werden.alexanderthamm+1

Anbieter

Anbieter sind primär verantwortlich für die Entwicklung und Markteinführung von KI-Systemen. Pflichten umfassen:

• Erstellung einer umfassenden technischen Dokumentation (Art. 11), die Design, Trainingsdaten, Tests und Risiken beschreibt; Haltbarkeit: 10 Jahre nach Markteinführung.
• Durchführung der Konformitätsbewertung (Art. 19, 43): Intern oder durch benannte Stelle, gefolgt von EU-Konformitätserklärung und CE-Kennzeichnung.
• Nachmarkteüberwachung (Art. 29): Kontinuierliches Monitoring, Incident-Reporting innerhalb 15 Tagen (schwerwiegend: 72 Stunden an AI Office).
• Für GPAI: Offenlegung von Trainingsdaten-Zusammenfassungen und Unterstützung für Betreibende (Art. 52–55).

Im ISMS: Anbieter-Risiken in Lieferantenmanagement (ISO 27001 A.15) integrieren; Verträge müssen Dokumentationspflichten und Audit-Rechte regeln.

Betreiber

Betreiber setzen KI-Systeme ein und tragen operative Verantwortung:

• Risikobewertung vor Einsatz (Art. 29): Speziell bei Hochrisiko-KI; berücksichtigt Einsatzkontext, Grundrechte und Cybersicherheit.
• Menschliche Aufsicht sicherstellen (Art. 14): Schulungen für Überwachungspersonal, Prozesse zur Intervention.
• Transparenz gegenüber Betroffenen (Art. 50): Informieren über KI-Nutzung, wo relevant (z. B. automatisierte Entscheidungen).
• Incident-Meldung und Logging; bei Grundrechtsverletzungen: Impact-Assessment.

Im ISMS: Betreiber-Pflichten in Prozessen wie Asset-Management (A.8) und Incident-Management (A.16) verankern; KPIs für Einsatzüberwachung definieren.

Weitere Parteien

• Nachgelagerte Anbieter: Übernehmen Teilanbieterpflichten bei Modifikationen (Art. 28).
• Importeure/Händler: Prüfen Konformität Drittländer-Produkte; Haftung bei Markteinführung (Art. 22–25).
• Bevollmächtigte Vertreter: Für Nicht-EU-Anbieter; vergleichbar mit DSGVO (Art. 26).

Im ISMS: Alle Rollen in der Lieferkette risikobasiert bewerten; Verträge klären Haftungsverteilung.

Sanktionen

Bußgelder (Art. 99): Bis 35 Mio. € / 7% Umsatz bei Verboten; 15 Mio. € / 3% bei anderen Pflichtverletzungen. Durchsetzung durch nationale Marktüberwachungsbehörden und EU AI Office. Im ISMS: In Risikobewertung als regulatorisches Risiko einplanen (Cl. 6.1.2 ISO 27001).

Konkrete Regelungen nach Risikostufe

Hier werden die operativen Anforderungen detailliert, mit Fokus auf Umsetzung in ISMS-Prozessen.

Verbotene KI-Anwendungen (Art. 5)

Vollständig verboten seit 2. Februar 2025:

• Manipulative Subliminaltechniken, die vulnerable Gruppen schädigen.
• Sozialscoring durch öffentliche Behörden.
• Echtzeit-Biometrie im öffentlichen Raum (Ausnahmen: schwere Kriminalität, mit gerichtlicher Genehmigung >24 Std.).
• Emotionserkennung am Arbeitsplatz/Bildungseinrichtungen.
• Biometrische Kategorisierung sensibler Merkmale (z. B. politische/rassische Orientierung).

ISMS-Umsetzung: Design-Phase-Checks (Security by Design, A.14 ISO 27001); Incident-Response auf unbewusste Nutzung.

Hochrisiko-Pflichten (Art. 6–15, Anhang III)

Pflichten für gelistete Sektoren (z. B. Medizinprodukte, Wasser-/Energieversorgung, Kreditscoring, Risikobewertung Straftäter):

• Risikomanagement (Art. 9): Lebenszyklus-Risiken identifizieren, bewerten, mindern; kontinuierlich aktualisieren.
• Datenqualität (Art. 10): Relevanz, Repräsentativität, Genauigkeit; Bias-Tests.
• Technische Dokumentation (Art. 11): Detaillierte Aufzeichnungen für Audits.
• Transparenz (Art. 13): Nachvollziehbarkeit für Betroffene.
• Menschliche Aufsicht (Art. 14): Vermeidung von Risiken durch Automatisierung.
• Robustheit/Cybersicherheit (Art. 15): Resilienz gegen Angriffe, Fallback-Mechanismen.

ISMS-Mapping: Direkt in Risikobehandlung (Cl. 8), Vulnerability-Management (A.12.6), Logging (A.12.4).

GPAI-spezifisch (Kap. V)

Seit 2. August 2025:

• Technische Dokumentation und Trainingsdaten-Summary (Art. 53).
• Risikobewertung für systemische Risiken (Art. 55): Bei Modellen >10^25 FLOPs (z. B. GPT-4-Nachfolger).
• Copyright-Hinweise und Incident-Reporting.

ISMS: Als Cloud-/API-Dienste behandeln (A.14.2); Modell-Updates in Change-Management.

Dokumentations- und Nachweispflichten

• Alle Dokumente 10 Jahre aufbewahren; Vorlagen im Amtsblatt.
• Audits durch benannte Stellen oder interne Checks. ISMS: In Records-Management (A.18.1) und Audit-Prozessen (Cl. 9.2) integrieren.

Governance und Aufsicht (Kap. VII)

Das Governance-System des EU AI Act gewährleistet einheitliche Umsetzung und Durchsetzung EU-weit. Es kombiniert zentrale EU-Institutionen mit nationaler Flexibilität und bindet sich eng an ISMS-Audit- und Überwachungsprozesse (Cl. 9 ISO 27001).

EU AI Office

• Rolle: Zentrale EU-Behörde (neben EBA, ESMA etc.) für Koordination, Richtlinienentwicklung und Überwachung GPAI/systemischer Risiken (Art. 64).
• Zuständigkeiten: Entwicklung von Codes of Practice, Harmonisierungsstandards (CEN/CENELEC), Marktanalyse, Sanktionsaufsicht bei grenzüberschreitenden Fällen.
• ISMS-Bezug: Als externe Stakeholder in Lieferanten- und Compliance-Monitoring (A.15/A.18) einbinden; AI Office-Richtlinien in interne Standards übernehmen.

Nationale Behörden und KI-Boards

• Nationale Marktüberwachungsbehörden: Durchsetzen lokaler Pflichten, Untersuchungen, Bußgelder; Kooperation über EU-Ausschuss (Art. 66).
• Nationale KI-Boards: Beratung, Risikobewertungshilfe für Unternehmen; koordinieren Hochrisiko-Konformität.
• ISMS-Integration: Nationale Ansprechpartner in Incident-Response (A.16) und Audit-Planung definieren; lokale Meldepflichten (72 Std.) in Prozesse einfließen lassen.

Harmonisierte Standards und Sandboxes

• Standards: Freiwillige, aber compliance-vermutende Normen (z. B. EN ISO/IEC 42001); beschleunigte Entwicklung durch EU AI Office.
• Regulatorische Sandboxes: Testumgebungen für innovative KI (Art. 57); nationale Umsetzung bis 2026.
• ISMS-Nutzen: Standards in Control-Sets (Anhang A ISO 27001) referenzieren; Sandboxes für Proof-of-Concepts vor Produktiveinsatz nutzen.

Meldepflichten

• Incidents: Schwere Vorfälle innerhalb 72 Std. an nationale Behörde/AI Office (Art. 73); GPAI: 15 Tage (Art. 55).
• Retraining/Update-Meldungen: Bei wesentlichen Modelländerungen.
• ISMS: Erweitere Incident-Management (A.16.1) um AI-spezifische Kategorien und Fristen; automatisiertes Reporting-Tool einplanen.

Integration in ein ISMS (ISO 27001/BSI-Grundschutz)

Der EU AI Act lässt sich nahtlos in bestehende ISMS nach ISO 27001:2022 oder BSI IT-Grundschutz integrieren, indem KI-Risiken risikobasiert behandelt werden (PDCA-Zyklus).daszeugs+1

Plan

• Asset-Inventarisierung: Alle KI-Systeme (inkl. GPAI-APIs) als Assets erfassen (A.8.1–A.8.4); Risikostufe per EU AI Act-Kriterien klassifizieren.
• Risikobewertung: KI-Risiken (Bias, Adversarial Attacks, Halluzinationen) in Matrix eintragen (Cl. 6/8); Grundrechte-Impact ergänzen.
• ISMS-Erweiterung: Statement of Applicability um AI Act-Controls anpassen.

Do

• KI-Richtlinie: Neue Policy mit Risikostufen, Rollenverteilung (Anbieter/Betreiber), Verboten und Transparenzpflichten erstellen.
• Controls:
  • A.5.7 Bedrohungserkennung auf KI-spezifische Angriffe (Prompt Injection) erweitern.
  • A.14 Lieferantenmanagement: AI-Anbieter-Verträge mit Dokumentationsrechten und SLAs.
  • A.18.1 Compliance: Konformitätserklärungen und Audits dokumentieren.
• Technische Maßnahmen: Model Governance (Versionierung, Red-Teaming), Secure-by-Design.

Check

• Interne Audits: Regelmäßige Reviews von KI-Risiken und Controls (Cl. 9.2); KPIs: Incident-Rate, Konformitätsrate, Bias-Tests.
• Management Review: AI Act-Änderungen besprechen (Cl. 9.3).
• Externe Audits: Vorbereitung auf Zertifizierer (hohe Risiken); ISO 42001 als Ergänzung.

Act

• Schulungen: KI-Literacy für alle Mitarbeitenden; spezifisch für Betreiber (menschliche Aufsicht).
• Kontinuierliche Verbesserung: Lessons Learned aus Incidents; Lieferantenfeedback-Loops.
• Mapping-Tabelle:

EU AI Act	ISO 27001 Control	BSI IT-Grundschutz
Risikomanagement (Art. 9)	Cl. 8, A.12.6	CON.4 Risikomanagement
Cybersicherheit (Art. 15)	A.12.4–A.12.7	SYS.4 Netzwerksicherheit
Incident-Meldung	A.16.1	INC.2 Incident Response
Transparenz (Art. 13)	A.18.1	ORP.3 Organisation

Diese Integration minimiert Redundanzen und stärkt die Zertifizierbarkeit; starte mit Gap-Analyse basierend auf AI Act-Checklisten (BSI-Standard 200-3).

Praktische Umsetzungsempfehlungen

Dieses Kapitel liefert konkrete, umsetzbare Schritte für Unternehmen mit bestehendem ISMS, um den EU AI Act bis zur Vollanwendbarkeit 2026/27 einzubinden.

Gap-Analyse und Roadmap (2026-Fokus)

• Schritt 1: Bestehendes KI-Inventar erstellen (alle Systeme, GPAI-Nutzung, Cloud-APIs); Risikostufen nach Art. 6–13 prüfen.
• Schritt 2: Gegen EU AI Act-Checklist (EU-Kommission, BSI) abgleichen; Lücken in Risikomanagement, Dokumentation, Controls identifizieren.
• Roadmap: Q1/2026: Policy/Schulung; Q2: Hochrisiko-Konformität; Q3: Audits; Q4: Betriebsfähigkeit. Fristen beachten (GPAI ab Aug. 2025).

Vorlagen und Dokumentation

• Risikomatrix: Erweitere ISMS-Matrix um AI-spezifische Achsen (Bias-Wahrsch./Grundrechts-Schaden).
• Konformitätserklärung: Standardvorlage (Art. 19, 43) mit technischer Dokumentation (10-Jahres-Archiv).
• Incident-Reporting: Vorlage für 72/15-Std.-Meldungen (AI Office/nationale Behörde).

Tools und Unterstützung

• BSI-Trassen: IT-Grundschutz++ 2026 für KI-Module (CON.4, SYS.4).
• ISO 42001-Zertifizierung: Ergänzung zu ISO 27001 für KI-Management-Systeme.
• Software: Tools für Bias-Tests (Fairlearn), Modell-Monitoring (WhyLabs), automatisierte Compliance-Checks.

Häufige Fallstricke

• Open Source-GPAI: Keine Anbieterpflichten, aber Betreiber-Risiken bei downstream Hochrisiko-Einsatz.
• Cloud-Training: Extraterritoriale Geltung; US-Provider brauchen bevollmächtigten Vertreter.
• Legacy-Systeme: Retrospective Risikobewertung für bestehende KI.

Übergangsfristen und Priorisierung

Pflicht	Frist	Priorität
Verbotene Praktiken	Feb. 2025	Sofort
GPAI-Dokumentation	Aug. 2025	Hoch
Hochrisiko-CE	Aug. 2026/27	Mittel

Ausblick und Synergien

EU AI Act und NIS-2/DSGVO-Integration

• NIS-2: KI in kritischen Sektoren (CII) verstärkt Cybersicherheitspflichten (Art. 21 NIS-2 + Art. 15 AI Act).
• DSGVO: Automatisierte Entscheidungen (Art. 22) + DPIA für Hochrisiko-KI; einheitliches Risikoregister nutzen.

Globale Vergleiche

• USA: Executive Order (2023) risikobasiert, aber freiwillig; State Laws (z. B. Colorado AI Act).
• China: PIPL + Algorithmus-Registrierung; staatliche Kontrolle vs. EU-Rechtsstaatlichkeit.
• Vereinheitlichung: EU AI Act als globaler Standard (ähnlich GDPR-Effekt).

Zukünftige Entwicklungen

• Delegierte Rechtsakte: AI Office veröffentlicht Codes of Practice (2026), Sektorregulierungen.
• Technische Standards: CEN/CENELEC-Normen für Hochrisiko-Tests (2026/27).
• ISMS-Trends: KI-gestützte ISMS (automatisierte Risikoanalysen) unterliegen selbst AI Act-Pflichten.

Die Integration schafft Wettbewerbsvorteile durch Vertrauen und Compliance-Vorsprung.

Anhang

• Glossar
• Quellenverzeichnis (Amtsblatt, EU-Kommission, BSI)
• Checklisten für Risikostufen