Der EU-Aktionsplan für Cybersecurity und Künstliche Intelligenz ist kein neues Compliance-Regelwerk. Die Mitteilung der Europäischen Kommission bündelt vielmehr operative Initiativen für den sicheren Umgang mit fortgeschrittenen KI-Fähigkeiten: Modellbewertungen, strukturierter Zugang zu KI-Cyberfähigkeiten, kontrollierte Testumgebungen und der Einsatz von KI zur Stärkung der Cyberresilienz.
Für Unternehmen ist der Plan dennoch relevant. Er konkretisiert, welche Fähigkeiten für einen kontrollierten Einsatz von KI in Security-Prozessen erforderlich werden können. Entscheidend ist dabei, politische Maßnahmen des Aktionsplans von bereits geltenden oder künftig anwendbaren Pflichten aus dem AI Act, NIS2, DORA oder dem Cyber Resilience Act (CRA) zu trennen.
Aktionsplan richtig einordnen: Umsetzungssignal statt neuer Pflicht
Der Aktionsplan COM(2026) 577 final vom 7. Juli 2026 ist eine Mitteilung der Kommission. Er schafft selbst keinen eigenständigen allgemeinen Pflichtenkatalog für Unternehmen. Insbesondere soll der geplante europäische Blueprint für den strukturierten Zugang zu fortgeschrittenen KI-Cyberfähigkeiten keine neuen Verpflichtungen für KI-Anbieter begründen.
Der Plan verfolgt drei miteinander verbundene Ziele: die sichere und verantwortungsvolle Nutzung fortgeschrittener KI, die Stärkung von Cybersecurity und Cyberresilienz in der Union sowie den Ausbau europäischer KI-Fähigkeiten für Cybersecurity. Daraus folgt keine neue Sonderpflicht, jedes KI-System nach den Methoden des Aktionsplans zu betreiben. Für Geschäftsleitungen, CISOs und Beschaffungsverantwortliche ist er aber ein belastbares Umsetzungssignal: KI-Systeme und KI-gestützte Security-Werkzeuge sollten nicht außerhalb des etablierten Risiko- und Kontrollsystems beschafft oder betrieben werden.
Evaluierung, sicherer Zugang und Tests sind unterschiedliche Aufgaben
Die Kommission will bis 2027 eine EU-Evaluierungskapazität für KI-Modelle aufbauen, die auch Cybersecurity abdecken soll. Diese Kapazität soll systemische Risiken und Risikominderungen bewerten, ist jedoch ausdrücklich keine Konformitätsbewertungsstelle. Daneben sollen Kommission und ENISA bis zum vierten Quartal 2026 einen Blueprint entwickeln, der Kriterien und Sicherheitsverfahren für den strukturierten Zugang geeigneter Organisationen zu fortgeschrittenen KI-Cyberfähigkeiten enthält.
Davon zu unterscheiden sind operationelle Tests. ENISA und die Gemeinsame Forschungsstelle sollen eine sichere Testplattform entwickeln, auf der KI etwa für Schwachstellenscans, Remediation oder Incident Response kontrolliert erprobt werden kann, ohne reale kritische Infrastrukturen zu gefährden. Die Unterscheidung ist praktisch wesentlich: Eine Modellbewertung untersucht Risiken des Modells und die Wirksamkeit von Risikominderungen. Ein betrieblicher Test untersucht dagegen, ob ein konkreter Einsatzfall unter definierten Sicherheitsgrenzen zuverlässig und beherrschbar funktioniert.
Unternehmen sollten diese Ebenen auch intern nicht vermischen. Ein Anbieterbericht über Modellbewertungen ersetzt keine Prüfung der eigenen Konfiguration, Berechtigungen, Datenflüsse und Automatisierungslogik. Umgekehrt lässt sich aus einem erfolgreichen Pilotversuch nicht auf die regulatorische oder sicherheitstechnische Eignung eines Modells für alle Kontexte schließen.
Geltendes Recht bleibt der Maßstab
Ob rechtliche Pflichten bestehen, richtet sich nicht nach dem Aktionsplan, sondern nach Rolle, Systemklassifizierung, Sektor und Produktbezug. Der AI Act enthält bereits anwendbare Pflichten für Anbieter von GPAI-Modellen mit systemischem Risiko. Dazu gehören Bewertungen nach dem Stand der Technik, dokumentierte adversarielle Tests, die Bewertung und Minderung systemischer Risiken, Informationen zu relevanten schweren Vorfällen sowie angemessener Cyberschutz für Modell und physische Infrastruktur.
Die Anforderungen an Hochrisiko-KI gelten zeitlich gestaffelt. Nach der Verordnung (EU) 2026/1744 beginnen die zentralen Anforderungen für Systeme nach Artikel 6 Absatz 2 und Anhang III ab dem 2. Dezember 2027; für Systeme nach Artikel 6 Absatz 1 und Anhang I ab dem 2. August 2028. Soweit diese Regeln anwendbar sind, betreffen sie unter anderem Risikomanagement über den Lebenszyklus, technische Dokumentation sowie Ereignisprotokollierung und deren Aufbewahrung.
Für von NIS2 erfasste Einrichtungen verlangt die NIS2-Richtlinie angemessene und verhältnismäßige Risikomanagementmaßnahmen. Ihr Mindestkatalog umfasst unter anderem Lieferkettensicherheit, sichere Beschaffung, Asset Management, Zugriffskontrolle, Incident Handling, Business Continuity, Schwachstellenbehandlung und Wirksamkeitsprüfungen. KI ist dort kein isoliertes Spezialthema. KI-Anbieter und KI-gestützte Security-Dienste können jedoch in den Anwendungsbereich dieser bestehenden Prozesse fallen.
Für Finanzunternehmen ist zusätzlich DORA relevant, wenn KI-SaaS, Modell-APIs oder Managed-AI-Security-Services als IKT-Dienstleistungen einzuordnen sind. Die Verantwortung für IKT-Drittrisiken verbleibt beim Finanzunternehmen; vertragliche Vereinbarungen sind im Register der Informationen zu führen. Der CRA kann bei KI-gestützter Software relevant werden, wenn diese ein Produkt mit digitalen Elementen im Anwendungsbereich der Verordnung ist. Seine Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle gelten seit dem 11. September 2026; im Übrigen gilt der CRA grundsätzlich ab dem 11. Dezember 2027.
KI im ISMS: Inventar, Risiko und klare Freigaben
Eine belastbare Governance beginnt mit einem zentralen Inventar. Es sollte nicht bei einer Liste von Chatbots oder Modellnamen bleiben. Sinnvoll sind Angaben zu Modelltyp und Anbieter, fachlichem Zweck, Einsatzkontext, Datenklassen, Schnittstellen, Berechtigungen, Automatisierungsgrad, sicherheitsrelevanten Aktionen und regulatorischer Einordnung. Besonders kritisch sind Werkzeuge, die Security Operations unterstützen, etwa KI-basierte Schwachstellenscanner, automatisierte Triage, Threat-Intelligence-Auswertung, Code- oder Konfigurationsanalyse und Remediation-Unterstützung.
Die Risikobewertung sollte über Datenschutz- und allgemeine Modellrisiken hinausgehen. Relevante Szenarien umfassen Prompt Injection, Datenabfluss über Eingaben oder angebundene Werkzeuge, manipulierte Kontextdaten, unzulässige Tool-Aufrufe, fehlerhafte oder nicht nachvollziehbare Empfehlungen, missbräuchliche Automatisierung, übermäßige Berechtigungen sowie Abhängigkeiten von Modell oder Anbieter. Diese Risiken lassen sich in bestehende ISMS-Prozesse einordnen; sie benötigen nicht zwingend ein separates KI-Managementsystem.
Geschäftsleitung und zuständige Governance-Funktionen sollten eine nachvollziehbare Freigabelogik festlegen. Dazu gehören zulässige Zwecke, verbotene Handlungen, maximale Rechte, erforderliche menschliche Prüfung sowie Kriterien für die Produktionsfreigabe. Ebenso wichtig sind Ausstiegskriterien, etwa bei Sicherheitsvorfällen, wesentlichen Änderungen des Dienstes oder eingeschränktem Modellzugang.
Vor Produktion testen und Nachweise sichern
KI-Cybersecurity-Anwendungsfälle sollten risikoorientiert zunächst in isolierten oder anderweitig kontrollierten Umgebungen getestet werden. Tests sollten prüfen, ob definierte Sicherheitsgrenzen eingehalten werden, welche Fehlerraten auftreten, wann eine Eskalation erfolgt und ob die Berechtigungen tatsächlich auf das notwendige Maß beschränkt sind. Bei automatisierten Maßnahmen ist zusätzlich zu bewerten, welche Auswirkungen Fehlentscheidungen auf Produktivsysteme haben und ob Rückfallverfahren funktionieren.
Evidenzfähige Unterlagen erleichtern interne Freigaben, Audits und die Reaktion auf Vorfälle. Dazu können ein Systemsteckbrief, die Freigabeentscheidung, Risikoanalyse, Datenflussbild, Rollen- und Berechtigungskonzept, Testplan und Testprotokoll gehören. Ergänzend sind dokumentierte Grenzen der Automatisierung, eine Konfigurationsbaseline, ein Monitoring- und Logging-Konzept sowie ein Incident-Runbook sinnvoll. Protokollierung dient dabei nicht nur der Nachweisführung: Sie ermöglicht, sicherheitsrelevante Eingaben, Tool-Aufrufe, Entscheidungen und Eskalationen nachvollziehen zu können.
Beschaffung und Lieferantensteuerung als Sicherheitskontrolle
Die vorgesehene EU-Blueprint-Initiative verweist ausdrücklich auf Vorsorge für eingeschränkten oder entzogenen Zugang zu relevanten KI-Modellen oder -Systemen. Für die Beschaffung folgt daraus eine praktische Frage: Kann der kritische Prozess weiterarbeiten, wenn ein Modell, eine API oder ein KI-Sicherheitsdienst ausfällt, sich wesentlich ändert oder nicht mehr verfügbar ist?
Lieferantenprüfungen und Verträge können deshalb – abhängig von Kritikalität, Datenarten und regulatorischem Kontext – Anforderungen zu Datenverwendung, Speicher- und Trainingsoptionen, Unterauftragnehmern, Sicherheitsarchitektur sowie Identitäts- und Zugriffssteuerung abdecken. Ebenfalls relevant sind Protokollierbarkeit, Informationen zu Schwachstellen und Sicherheitsvorfällen, Änderungsmitteilungen, Audit- oder Informationsrechte und Exit-Unterstützung. Technische Fallbacks, alternative Betriebsverfahren und klar geregelte Datenexporte gehören in dieselbe Betrachtung wie vertragliche Zusagen.
Prioritäten für die Umsetzung
Ein zweckmäßiger Einstieg ist die Zusammenführung vorhandener Prozesse statt der Aufbau paralleler KI-Silos. Erstens sollten Organisationen KI-Systeme und KI-gestützte Security-Tools inventarisieren und nach Kritikalität bewerten. Zweitens sind Mindestkontrollen für Daten, Zugriffe, Protokollierung, menschliche Freigaben und Incident Response festzulegen. Drittens sollten risikoreiche Anwendungsfälle kontrolliert getestet werden, bevor sie produktive Rechte oder automatisierte Eingriffsmöglichkeiten erhalten. Viertens sind Anbieterabhängigkeit, Vertragsanforderungen und Fallback-Szenarien in Beschaffung und Resilienzplanung zu verankern.
Der Aktionsplan ersetzt keine Einzelfallprüfung nach AI Act, NIS2, DORA oder CRA. Er macht aber deutlich, dass sichere KI-Nutzung künftig stärker an nachweisbare Bewertungen, kontrollierte Tests, begrenzte Zugriffe und belastbare Lieferantensteuerung geknüpft sein wird. Organisationen, die diese Elemente in ISMS, Beschaffung und Betriebsprozesse integrieren, schaffen dafür eine belastbarere Grundlage.