Das hier ist ein vollständig KI generierter Artikel.

Der EU AI Act wird oft als reines Compliance-Thema behandelt, doch seine Anforderungen an die Cybersicherheit sind deutlich konkreter und weitreichender, als viele Zusammenfassungen vermuten lassen. Besonders heikel: Die meisten Unternehmen nutzen KI über externe Modelle und SaaS-Produkte, die sie nicht selbst kontrollieren – genau dort entsteht eine gefährliche Lücke zwischen gesetzlichen Pflichten und realen technischen Einflussmöglichkeiten.

Die vier Angriffskategorien des EU AI Act

Artikel 15 des EU AI Act verlangt, dass Hochrisiko-KI-Systeme „resilient gegen Versuche unbefugter Dritter“ sind, die Nutzung, Ausgaben oder Performance durch Ausnutzung von Schwachstellen zu verändern. Konkret nennt der Gesetzestext vier Bedrohungskategorien:

  • Datenvergiftung (Data Poisoning): Manipulation der Trainings- oder Eingabedaten, um das Modell systematisch zu Fehlverhalten zu bringen.
  • Modellvergiftung (Model Poisoning): Direkte Beeinflussung der Modellparameter oder -gewichte, etwa über kompromittierte Trainingspipelines.
  • Adversarielle Beispiele: Speziell präparierte Eingaben, die für Menschen harmlos wirken, aber gezielt Fehlklassifikationen oder unerwünschte Ausgaben provozieren.
  • Vertraulichkeitsangriffe und Modellschwachstellen: Angriffe, die Trainingsdaten rekonstruieren, sensible Informationen aus dem Modell extrahieren oder Designfehler ausnutzen.

Wichtig ist die Formulierung in Artikel 15: Unternehmen sollen diese Angriffe nicht nur verhindern, sondern Massnahmen treffen, um sie zu „verhindern, zu erkennen, darauf zu reagieren, sie zu beheben und zu kontrollieren“. Damit verlangt der EU AI Act einen vollständigen Sicherheitszyklus – Prävention allein reicht nicht.

Kontinuierliches Risikomanagement statt einmaligem Audit

Artikel 9 des EU AI Act schreibt ein „kontinuierliches iteratives“ Risikomanagement über den gesamten Lebenszyklus eines Hochrisiko-KI-Systems vor. Dazu gehören regelmässige, systematische Überprüfungen und Aktualisierungen. Für die Praxis bedeutet das:

  • Risikoanalysen dürfen kein einmaliges Projekt sein, sondern müssen laufend aktualisiert werden.
  • Sicherheitsmassnahmen sind an neue Angriffstechniken und Modellversionen anzupassen.
  • Monitoring und Logging werden zu Kernanforderungen, um Angriffe überhaupt erkennen und bewerten zu können.

Der Gesetzgeber lässt bewusst Spielraum: Artikel 15 Absatz 5 spricht von Massnahmen „soweit angemessen“. Unternehmen müssen also nicht jede denkbare Massnahme implementieren, sondern jene, die zum konkreten System und dessen Risiko passen. Ein biometrisches Identifikationssystem hat ein anderes Bedrohungsprofil als ein interner Support-Chatbot.

Wann ein KI-System wirklich „Hochrisiko“ ist

Nicht jedes System, das in einer Hochrisiko-Kategorie des Anhangs III auftaucht, ist automatisch Hochrisiko. Artikel 6 Absatz 3 sieht eine Ausnahme vor, die allerdings zweistufig ist. Ein System fällt nur dann aus der Hochrisiko-Klasse heraus, wenn:

  • es kein erhebliches Risiko für Gesundheit, Sicherheit oder Grundrechte darstellt und die Entscheidungsfindung nicht wesentlich beeinflusst, und
  • mindestens eine von vier Bedingungen erfüllt ist, etwa dass es nur eine enge, rein prozedurale Aufgabe erfüllt oder lediglich vorbereitende Tätigkeiten für eine anschliessende menschliche Bewertung übernimmt.

In der Praxis ist diese Ausnahme eng. Ein zentrales „No-Go“: Sie gilt nie, wenn das System Profiling natürlicher Personen vornimmt. Ein KI-Tool, das Bewerberinnen und Bewerber bewertet oder rankt, wird damit praktisch immer als Hochrisiko eingestuft – selbst wenn ein Mensch formal „im Loop“ bleibt. Ein System, das nur Felder aus Dokumenten extrahiert, bevor eine Person entscheidet, kann dagegen eher unter die Ausnahme fallen.

Wenn die Ausnahme greift, verpflichtet Artikel 6 Absatz 4 den Anbieter, diese Einstufung zu dokumentieren, bevor das System auf den Markt kommt. Unternehmen, die solche Systeme einsetzen, sollten sich diese Dokumentation aktiv zeigen lassen und prüfen, ob sie im Fall einer Anfrage durch Behörden verfügbar ist.

Verantwortlichkeiten: Provider vs. Deployer

Der EU AI Act unterscheidet klar zwischen Providern (die KI-Systeme entwickeln oder in Verkehr bringen) und Deployern (die sie einsetzen). Die meisten Unternehmen sind Deployer: Sie nutzen APIs grosser Modelle, integrieren Microsoft Copilot oder setzen SaaS-Produkte mit eingebetteter KI ein.

Artikel 26 definiert Pflichten für Deployer, die direkt in den Bereich Cybersicherheit hineinwirken, unter anderem:

  • Nutzung der Systeme gemäss den Anweisungen des Providers, insbesondere im Hinblick auf Sicherheits- und Konfigurationsvorgaben.
  • Sicherstellung einer kompetenten menschlichen Aufsicht über das System.
  • Aktives Monitoring des Betriebs, um Anomalien, Fehlfunktionen oder Sicherheitsvorfälle zu erkennen.
  • Verantwortung für die Qualität und Relevanz der Eingabedaten, damit diese nicht selbst zum Angriffsvektor werden.

Damit verschiebt der EU AI Act einen Teil der Verantwortung für KI-Sicherheit explizit auf die Anwenderseite – auch wenn das zugrunde liegende Modell ausserhalb der eigenen Infrastruktur betrieben wird.

Die Supply-Chain-Lücke bei KI-Sicherheit

Die grösste praktische Herausforderung liegt in der Lieferkette: Unternehmen sollen Risiken managen, die in Modellen entstehen, die sie weder trainiert noch konfiguriert haben. Typische Konstellationen sind:

  • Nutzung von Foundation Models über API (z.B. Text- oder Bildmodelle grosser Anbieter).
  • Einsatz von Productivity-Suiten mit integrierter KI (z.B. Office- oder Kollaborationsplattformen).
  • SaaS-Produkte, in denen KI-Funktionen tief im Produktkern verankert sind.

Hier können Unternehmen die internen Sicherheitsmassnahmen des Providers nicht direkt beeinflussen. Trotzdem bleiben sie für den sicheren Einsatz verantwortlich. Das erzeugt eine Lücke zwischen gesetzlichen Anforderungen und technischer Steuerbarkeit, die sich nur über robuste Governance und Lieferantenmanagement schliessen lässt.

Praktische Schritte für Unternehmen

Um die Anforderungen des EU AI Act im Bereich Cybersicherheit pragmatisch zu adressieren, bieten sich mehrere Handlungsfelder an:

  • Inventarisierung von KI-Systemen: Übersicht schaffen, welche KI-Funktionen wo im Unternehmen genutzt werden, inklusive Schatten-IT und eingebetteter KI in SaaS-Produkten.
  • Risikoklassifizierung: Systeme anhand der Kriterien des Anhangs III und der Ausnahme nach Artikel 6 einstufen und dokumentieren.
  • Vertragliche Absicherung: Sicherheitsanforderungen, Logging, Incident-Reporting und Dokumentationspflichten gegenüber Providern vertraglich festschreiben.
  • Technisches Monitoring: Eingaben, Ausgaben und relevante Systemmetriken überwachen, um Daten- und Modellvergiftung sowie adversarielle Muster zu erkennen.
  • Prozesse für Incident Response: Klare Abläufe definieren, wie auf KI-bezogene Sicherheitsvorfälle reagiert, wie eskaliert und wie mit Behörden kommuniziert wird.

Besonders wichtig ist, dass diese Massnahmen nicht als separates KI-Projekt laufen, sondern in bestehende Informationssicherheits- und Compliance-Strukturen integriert werden.

Fazit

Der EU AI Act verlangt von Unternehmen im Bereich Cybersicherheit deutlich mehr als nur ein paar zusätzliche Policies. Er fordert einen durchgängigen Sicherheitszyklus für Hochrisiko-KI-Systeme, der von der Abwehr konkreter Angriffskategorien bis hin zu kontinuierlichem Risikomanagement reicht. Die grösste Herausforderung entsteht dort, wo KI über externe Modelle und SaaS-Produkte konsumiert wird: Unternehmen tragen Verantwortung für Systeme, die sie technisch nur begrenzt kontrollieren. Wer diese Supply-Chain-Lücke mit klarer Governance, vertraglichen Anforderungen und technischem Monitoring adressiert, reduziert nicht nur regulatorische Risiken, sondern stärkt auch die eigene Sicherheitsposition gegenüber einer neuen Generation von Angriffsvektoren.

Quelle: https://socradar.io/blog/eu-ai-act-cybersecurity/