Der EU-Aktionsplan für Cybersecurity und Künstliche Intelligenz vom 7. Juli 2026 ist kein neuer Rechtsakt mit unmittelbar sanktionierbaren Einzelpflichten für Unternehmen. Als Kommissionsmitteilung COM(2026) 577 final bündelt er vielmehr europäische Prioritäten für den sicheren Einsatz fortgeschrittener KI und für die Abwehr KI-gestützter Angriffe. Für Geschäftsleitungen, CISOs und Governance-Funktionen liegt die Relevanz deshalb nicht in einer zusätzlichen Compliance-Schicht. Der Plan verdichtet vielmehr die Erwartung, bestehende Sicherheits-, Resilienz- und Risikomanagementmechanismen auf KI auszurichten.
Im Mittelpunkt steht eine doppelte Perspektive: KI kann Erkennung, Triage, Threat Intelligence, Schwachstellenbehandlung und Incident Response beschleunigen. Zugleich erweitert sie die Angriffsfläche, schafft Abhängigkeiten von Modellen, Daten, Schnittstellen und Anbietern und kann Fehlentscheidungen mit hoher Geschwindigkeit skalieren. Unternehmen sollten KI-Sicherheit daher nicht als isoliertes AI-Governance-Thema behandeln, sondern als Bestandteil ihrer Sicherheitsarchitektur und Resilienz-Governance.
Orientierungssignal statt neuer unmittelbarer Pflicht
Der Aktionsplan ergänzt nach Darstellung der Kommission den bestehenden europäischen Rahmen aus AI Act, NIS2, Cyber Resilience Act (CRA), DORA und Cyber Solidarity Act. Er verfolgt drei miteinander verbundene Ziele: die sichere und verantwortungsvolle Nutzung fortgeschrittener KI, die Stärkung von Cybersecurity und Resilienz sowie den Ausbau europäischer KI-Fähigkeiten für die Cybersicherheit.
Die Kommission bezeichnet als Frontier AI die fortschrittlichsten verfügbaren oder in Entwicklung befindlichen KI-Modelle. Deren Fähigkeiten können Verteidigung und Reaktion verbessern, aber auch automatisierte, skalierbare und komplexere Angriffe erleichtern. Der Plan fordert insbesondere kritische Sektorbetreiber und Finanzunternehmen dazu auf, ihre Risikomanagementrahmen auf Angriffe mit höherer Frequenz und Skalierung auszurichten und Patch-Zyklen zu beschleunigen. Das ist ein politisch-operatives Erwartungssignal, keine neue, unmittelbar geltende Einzelpflicht aus der Mitteilung.
Auch angekündigte EU-Maßnahmen sind sorgfältig einzuordnen: Eine europäische Bewertungskapazität für KI-Modelle ab 2027, ein Blueprint für strukturierten Zugang zu fortgeschrittenen KI-Fähigkeiten und eine sichere Testplattform waren zum Recherchestichtag geplante Maßnahmen. Sie dürfen nicht als bereits verfügbare Unternehmensdienste vorausgesetzt werden.
KI wird zum Sicherheitswerkzeug und zur Sicherheitsabhängigkeit
Besondere Aufmerksamkeit verdienen KI-Use-Cases mit operativer Wirkung. Dazu zählen die KI-gestützte Suche und Priorisierung von Schwachstellen, SOC-Triage, Codeanalyse, Threat Intelligence, Unterstützung der Incident Response sowie Agenten mit Zugriff auf Ticketsysteme, Quellcode oder Entwicklungs- und Produktionsumgebungen. Der Nutzen solcher Systeme hängt nicht allein von der Modellqualität ab. Entscheidend sind ihre Berechtigungen, Datenquellen, Schnittstellen und die Reichweite möglicher Aktionen.
Eine praxistaugliche Risikobewertung sollte Use-Cases daher nach Eingriffstiefe unterscheiden. Eine KI, die einen Befund zusammenfasst, ist anders zu bewerten als ein System, das Tickets verändert, Zugänge sperrt, Konfigurationen ändert, Code bereitstellt oder Remediation in Produktion auslöst. Mit jeder zusätzlichen Tool-Anbindung steigen Risiken durch fehlerhafte Priorisierung, missbräuchliche Aufrufe, Rechteausweitung und schwer nachvollziehbare Kettenentscheidungen.
Ein zentrales Steuerungsinstrument ist ein KI-Use-Case-Register. Es sollte mindestens Zweck, Systemgrenzen, Modelltyp und Provider, Datenkategorien, angebundene Werkzeuge und Systeme, Automatisierungsgrad, betroffene Geschäftsprozesse, verantwortliche Rollen sowie die regulatorische Einordnung erfassen. So entsteht eine belastbare Grundlage für Freigaben, Kontrollen und spätere Audits.
Sicherer Modell- und Datenzugang als Architekturaufgabe
KI-Sicherheit beginnt nicht beim Prompt, sondern bei Architektur und Berechtigungen. Modellzugriff, Orchestrierung, Datenquellen und ausführende Werkzeuge sollten technisch getrennt sein. Erforderlich sind getrennte Identitäten und Schlüssel, Least Privilege, zeitlich und sachlich begrenzte Berechtigungen, Secret Management, Netzwerksegmentierung sowie klar definierte Freigabepunkte für sicherheitsrelevante Aktionen.
Vor einer Modellanbindung muss die Datenklassifikation geklärt sein. Telemetrie, Quellcode, Schwachstellendaten, Incident-Artefakte, Zugangsdaten sowie Kunden- und personenbezogene Daten dürfen nicht pauschal gleich behandelt werden. Unternehmen sollten zulässige Datenflüsse, Filter- oder Maskierungsregeln, Speicherorte, Aufbewahrung und Übermittlungswege festlegen. Dies gilt auch für Daten, die ein Agent aus Wissensdatenbanken oder Ticketsystemen abruft.
Protokollierung erfüllt zwei Funktionen: operative Steuerung und forensische Aufklärung. Nachvollziehbar sein sollten mindestens Eingaben, verwendete Datenquellen, Modell- und Versionsstand, Tool-Aufrufe, Berechtigungsentscheidungen, Ergebnisse, menschliche Freigaben oder Übersteuerungen sowie tatsächlich ausgeführte Änderungen. Für Hochrisiko-KI-Systeme verlangt der AI Act unter anderem technische Logging-Fähigkeiten, menschliche Aufsicht sowie Anforderungen an Genauigkeit, Robustheit und Cybersicherheit. Ob ein konkreter Security-Use-Case als Hochrisiko-System einzuordnen ist, muss jedoch anhand von Funktion, Rolle und Klassifizierung geprüft werden.
Testen, validieren und wirksam übersteuern
Vor dem produktiven Einsatz sollten KI-Funktionen in kontrollierten Umgebungen getestet werden. Der Aktionsplan sieht hierfür perspektivisch eine sichere Testplattform vor, unter anderem für Schwachstellenscanning, Remediation und Incident Response; auch Cyber Ranges sollen Tests ohne Risiko für reale kritische Infrastruktur ermöglichen. Unabhängig von dieser angekündigten EU-Initiative bleibt jedes Unternehmen für seine eigene Testmethodik und Freigabe verantwortlich.
Relevante Testszenarien umfassen Prompt Injection, Datenabfluss, fehlerhafte Security-Empfehlungen, missbräuchliche Tool-Aufrufe, Rechteausweitung, Fehlalarme, übersehene kritische Befunde sowie Modell- oder Provider-Ausfälle. Bei KI-gestützter Schwachstellenbehandlung reicht eine höhere Zahl erkannter Befunde nicht aus. Die nachgelagerte Kette aus Validierung, Risikoentscheidung, Change-Freigabe, Patch und Rollback muss dieselbe Skalierung bewältigen können.
Menschliche Kontrolle darf dabei nicht auf eine formale Sichtung reduziert werden. Verantwortliche Personen benötigen ausreichende Kompetenz, eindeutige Entscheidungsbefugnisse und eine reale Interventionsmöglichkeit. Für risikoreiche Aktionen sind verbindliche Freigabegrenzen, ein Stop- oder Kill-Switch und technisch belastbare Fallback-Verfahren erforderlich.
Vorhandene Kontrollfamilien KI-tauglich weiterverwenden
Ein separates Parallelregime für KI ist selten zweckmäßig. Die NIS2-Richtlinie verlangt für erfasste wesentliche und wichtige Einrichtungen angemessene und verhältnismäßige technische, operative und organisatorische Maßnahmen. Ihr Katalog umfasst Risikoanalyse, Incident Handling, Business Continuity, Lieferkettensicherheit, Schwachstellenmanagement, Wirksamkeitskontrollen, Zugriffskontrolle und Asset Management. Diese Kontrollfamilien lassen sich unmittelbar auf KI-gestützte Security-Prozesse übertragen.
Für bestimmte digitale Einrichtungen konkretisiert die NIS2-Umsetzungsverordnung, dass die Schwachstellenbehandlung mit Change Management, Security Patch Management, Risiko- und Incident Management kompatibel sein soll. KI-gestützte Priorisierung oder Remediation sollte deshalb in diese etablierten Abläufe eingebettet werden, nicht daneben betrieben werden.
Für Finanzunternehmen verlangt DORA ein ICT-Risikomanagement mit Schutz, Prävention, Erkennung, Response, Recovery, Resilienztests und Drittparteirisikomanagement. Bei Modell-, Cloud-, Agenten- und Managed-Security-Anbietern sind insbesondere Kritikalität der unterstützten Funktion, Abhängigkeiten, Konzentrationsrisiken, Substituierbarkeit und Unterbeauftragungen zu bewerten. Die Verantwortung des Finanzunternehmens bleibt auch bei Nutzung externer ICT-Dienste bestehen.
Der CRA ist rechtlich vor allem für Hersteller von Produkten mit digitalen Elementen relevant. Für diese Konstellationen verknüpft er risikobasierte Cybersicherheit über den Produktlebenszyklus mit Vulnerability Handling. Seine Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle gelten seit dem 11. September 2026; die wesentlichen übrigen Anforderungen grundsätzlich ab dem 11. Dezember 2027. Betreiber von KI-Systemen sollten diese Herstellerpflichten nicht pauschal auf sich übertragen, können die zugrunde liegenden Prozesse aber fachlich nutzen.
Resilienz-Governance und ein pragmatischer Startpunkt
KI-gestützte Security-Werkzeuge benötigen definierte Ausfallszenarien: entzogener Modellzugang, kompromittierte API-Schlüssel, manipulierte Wissensdatenbanken, kompromittierte Agenten, fehlerhafte automatisierte Sperrungen oder Verlust der Nachvollziehbarkeit. BCMS und Incident Response müssen festlegen, wie Detection, Triage und Response ohne den KI-Service fortgeführt werden. Lieferantenanforderungen sollten Datenverarbeitung, Modellwechsel, regionale Verfügbarkeit, Schnittstellenänderungen, Zugriffsentzug, Support im Sicherheitsvorfall und exportierbare Logs abdecken.
Für einen realistischen 90-Tage-Start sollten Unternehmen erstens sicherheitsrelevante KI-Use-Cases und ihre Zugriffe erfassen. Zweitens sind Datenflüsse, Schlüssel, Berechtigungen und Automatisierungsgrenzen zu prüfen. Drittens folgen Tests für Fehlverhalten und Ausfall sowie die Nachschärfung von Incident-Playbooks, Lieferantensteuerung und Fallback-Betrieb. Die Geschäftsleitung sollte Risikotoleranz, zulässige Automatisierungsstufen, Verantwortlichkeiten und Eskalationsschwellen festlegen. Geeignete Kennzahlen sind etwa die Zeit bis zur Validierung KI-generierter kritischer Befunde, die Quote verworfener KI-Empfehlungen, Patch-Zeiten und die Wiederherstellungsfähigkeit ohne KI-Service.
Der Aktionsplan verlangt damit keine neue isolierte KI-Compliance. Er macht jedoch deutlich, dass sichere KI-Nutzung nur dann resilient wird, wenn Modellzugang, Datenkontrolle, Tests, menschliche Intervention, Lieferantensteuerung und Notfallbetrieb als zusammenhängende Sicherheitsarchitektur gesteuert werden.
Quellen und weiterführende Informationen
- Europäische Kommission / EUR-Lex: Action Plan on Cybersecurity and Artificial Intelligence, COM(2026) 577 final
- EUR-Lex: Verordnung (EU) 2024/1689 – Artificial Intelligence Act
- EUR-Lex: Richtlinie (EU) 2022/2555 – NIS2-Richtlinie
- EUR-Lex: Verordnung (EU) 2022/2554 – DORA
- EUR-Lex: Verordnung (EU) 2024/2847 – Cyber Resilience Act
- EUR-Lex: Durchführungsverordnung (EU) 2024/2690 zu NIS2-Risikomanagementmaßnahmen