ISO/IEC 27090: Was die neue Norm über Angriffe auf KI sagt

Seit Oktober 2026 gibt es eine ISO-Norm, die sich um eine einzige Frage dreht: Wie greift man ein KI-System an, und was hilft dagegen? ISO/IEC 27090:2026, erste Ausgabe, erarbeitet im selben Unterausschuss wie die ISO/IEC 27001 (ISO/IEC JTC 1/SC 27). 56 Seiten, davon sechs Seiten Literatur mit 115 Quellen.

Ich habe sie von vorn bis hinten gelesen. Die Norm ist ein Katalog. Zu jeder Angriffsart steht dasselbe Raster: wie der Angriff funktioniert, was danach kaputt ist, wie man ihn bemerkt und wie man ihn eindämmt. Das ist nüchtern, an manchen Stellen sehr technisch und an erstaunlich vielen Stellen ehrlich.

Für den Mittelstand steckt die wichtigste Aussage nicht in den exotischen Angriffen. Sie steht ganz vorn: Ein KI-System ist zuerst Software. Wer seine Informationssicherheit im Griff hat, hat einen großen Teil schon erledigt. Den Rest ordne ich hier ein, mit dem, was Sie ab Montag damit anfangen.

Ein Leitfaden, kein Zertifikat

ISO/IEC 27090 stellt keine Anforderungen an ein Managementsystem. Sie gibt Hinweise. Zertifizieren lässt sich nach ihr niemand. Wer ein Zertifikat will, geht weiter über ISO/IEC 27001 für die Informationssicherheit oder ISO/IEC 42001 für das KI-Managementsystem. Die 27090 ist das Fachbuch, das man daneben legt.

Ganz ohne Pflicht ist sie trotzdem nicht. Das verbindliche „shall“ steht im eigentlichen Text genau zweimal, beide Male in Abschnitt 5.1. Die bekannten Maßnahmen der ISO/IEC 27002 sind umzusetzen, so weit Ihre Risikobeurteilung sie verlangt. Und die KI-spezifischen Angriffe aus der Übersichtstabelle sind über den ganzen Lebenszyklus zu berücksichtigen. Alles andere sind Empfehlungen.

Für die Steuerung verweist die Norm auf ISO/IEC 42001: ein Programm, das alle KI-Systeme im Haus erfasst, ihre Risiken analysiert und steuert (5.2). Die Begriffe holt sie aus ISO/IEC 22989 und ISO/IEC 23053, die beiden einzigen normativen Verweise. Wer die 42001 schon eingeführt hat, findet in der 27090 also keine neue Bürokratie. Er findet den Stoff, den seine Risikobeurteilung bisher nur grob benannt hat.

Spannend wird der Blick in die KI-Verordnung. Artikel 15 Absatz 5 verlangt von Hochrisiko-KI-Systemen Schutz gegen manipulierte Trainingsdaten, gegen vergiftete vortrainierte Komponenten, gegen Eingaben, die das Modell zu Fehlern verleiten, und gegen Angriffe auf vertrauliche Daten. Das liest sich wie eine Kurzfassung von Abschnitt 6 der neuen Norm. Gelten wird es für Hochrisiko-Systeme nach Anhang III ab dem 2. Dezember 2027, nach Anhang I ab dem 2. August 2028 (Artikel 113 in der Fassung der Verordnung (EU) 2026/1744).

Eine Konformitätsvermutung bringt die 27090 trotzdem nicht. Sie ist keine harmonisierte Norm. Was sie liefert, sind Sprache und Katalog, mit denen Sie belegen können, dass Sie über genau diese Angriffe nachgedacht und entschieden haben.

Neun Angriffe im Hauptteil, sechs im Anhang

Abschnitt 6 beschreibt neun Angriffsarten, jede im selben Raster. Anhang B ergänzt sechs Fälle, in denen ein klassischer Angriff bei KI eine eigene Note bekommt. Die Übersicht in meinen Worten:

Zwei Dinge fallen beim Lesen auf. Erstens braucht nicht jeder Fall einen Angreifer. Vertrauliches im Output, ein Leck bei Trainingsdaten oder bei Eingaben entsteht auch durch einen schlichten Fehler im Betrieb (6.8, B.6, B.7). Zweitens ist die Norm ehrlich, wo es wehtut. Ob Trainingsdaten vergiftet wurden, lässt sich nach ihrer eigenen Einschätzung bis heute nicht verlässlich automatisch erkennen; sie nennt das ein offenes Forschungsfeld (6.2.3).

Für Betriebe, die Modelle einkaufen, ist Abschnitt 5.5 wichtiger als jede einzelne Angriffsart. Vortrainierte Modelle und fremde Datensätze können Hintertüren enthalten, die erst bei einem bestimmten Auslöser anspringen. KI-Bibliotheken können Schadcode mitbringen. Und die Herkunft eines Modells lässt sich verschleiern. Die Norm empfiehlt geprüfte Herkunft, signierte Modelle und Datensätze, vertrauenswürdige Quellen, regelmäßige Scans der Abhängigkeiten und Tests auf unerwartetes Verhalten (5.5.4, 5.5.5).

Für den Einkauf nennt Anhang B.3.3 vier Punkte, die in keinem Lastenheft fehlen sollten: Sicherheitsanforderungen an Daten- und Modelllieferanten gehören in den Vertrag, die Lieferanten werden geschult, die Modellbeschreibung wird sauber übergeben, und das gelieferte Modell wird vor dem Einsatz gezielt angegriffen, im Fachjargon Red Teaming. Das ist dieselbe Logik wie beim Lieferantenaudit für Zukaufteile, nur mit anderen Prüfmerkmalen.

Zwei ihrer Beispiele sollten in jedem Fertigungsbetrieb ankommen. Bei der vorausschauenden Wartung führt vergiftetes Training dazu, dass ein drohender Ausfall nicht gemeldet wird (6.2.2). Und in einem dokumentierten Versuch reichten drei kaum sichtbare Aufkleber auf der Fahrbahn, damit ein Fahrassistent die Spur falsch las und in den Gegenverkehr lenkte (6.3.2). Aus Anhang B bleibt eine Zahl hängen: Es gibt Eingaben, die ein Modell bis zu dreißigmal so viel Rechenzeit und Energie kosten wie gewöhnliche (B.2.1).

Die übrigen Anhänge sind Werkzeug. Anhang A ordnet jeden Angriff dem Lebenszyklus zu und den Werten, die er trifft: Trainingsdaten, Modell, Parameter, Eingaben, Ausgaben. Anhang C behandelt föderiertes Lernen, bei dem die Daten auf den Geräten oder bei den Partnern bleiben und nur Modellstände wandern.

Ihre Wissensablage zählt jetzt als Trainingsdaten

Der Satz mit der größten Wirkung für Betriebe, die KI nur nutzen, steht in Abschnitt 7.6. Wer einem Sprachmodell Dokumente aus der eigenen Ablage mitgibt, im Fachjargon Retrieval Augmented Generation, steuert damit das Verhalten des Modells. Die Norm zieht daraus die Konsequenz: Diese Ablage braucht denselben Schutz wie Trainingsdaten.

Das dreht eine alte Gewohnheit um. In klassischer IT liegen die heiklen Daten in der Produktion, entwickelt wird mit Testdaten. Bei KI ist es oft umgekehrt, auch das steht in 7.6: Das Training braucht echte Daten, also liegen sie in der Entwicklungsumgebung. Wer seine Schutzmaßnahmen nach dem alten Muster verteilt hat, schützt bei KI die falsche Seite.

Für Ihren Betrieb heißt das zwei Fragen. Wer darf in die Ablage schreiben, aus der Ihre KI liest? Und darf die KI einem Nutzer ein Dokument zeigen, das dieser selbst nie öffnen dürfte? Abschnitt 5.3 nennt dafür als Beispiel eine Rechteprüfung für jedes abgerufene Dokument, unabhängig davon, ob die Anwendung als Ganzes freigegeben ist.

In meinem eigenen Betrieb liest eine KI eingehende Bestell-PDFs von Kunden. Bei einem großen Auftrag mit drei Preiszeilen je Position lag sie bei 40 von 66 Stückpreisen daneben. Ein Angriff war das nicht, nur ein schwer lesbares Dokument. Seit September übernimmt das System aus dem PDF keinen einzigen Preis mehr. Der Preis kommt immer aus unserer Datenbank, und eine Position ohne hinterlegten Preis wird rot markiert.

Was aus einem Dokument kommt, ist ein Vorschlag. Was in Ihrer Datenbank steht, gilt.

Die Regel schützt gegen beides: gegen den Lesefehler und gegen die Datei, in der jemand eine Anweisung in weißer Schrift versteckt hat. Genau diese Linie zieht die Norm. Sie rät, bei unerwünschtem Verhalten zuerst zu klären, ob überhaupt ein Angriff vorliegt (6.11.3.1), und sie stuft Text aus dem Modell als nicht vertrauenswürdig ein, sobald die Daten dahinter es nicht sind (6.10.4). Die Norm rät übrigens auch, mit technischen Details über eigene KI-Systeme in Veröffentlichungen sparsam umzugehen (6.11.2.5). Mehr als diese zwei Sätze schreibe ich deshalb über unser Bestellsystem nicht.

KI-Agenten: Rechte je Aufgabe und mit Ablaufdatum

Am konkretesten wird die Norm bei Agenten, also KI-Systemen, die selbst handeln: Mails versenden, Datenbanken abfragen, Code ausführen. Abschnitt 6.11.3.3 beschreibt, worauf es ankommt. Rechte gibt es für eine Aufgabe. Sie laufen nach der Aufgabe ab. Der Agent hat eine eigene Identität und erbt nicht einfach die Rechte des Menschen, der ihn startet.

Übertragen auf einen Angebotsassistenten im Maschinenbau: Er darf die Anfrage lesen, die Preisliste lesen und einen Entwurf anlegen. Versenden darf er nichts. Auf die Lohnbuchhaltung oder fremde Kundenakten hat er keinen Zugriff, auch wenn der Vertriebsleiter, der ihn nutzt, diese Rechte hat. Das Angebot geht erst raus, wenn ein Mensch es freigegeben hat.

Als Ursachen für unerwünschtes Verhalten nennt die Norm neben Angriffen und schlechten Daten zwei, die mit Technik wenig zu tun haben: Nutzer vertrauen der Ausgabe zu sehr, und Entwickler geben dem System zu viele Befugnisse (6.11.3.1). Gegen das zweite hilft keine Firewall. Da hilft nur eine Rechteliste, die so kurz ist, dass sie auf einen Zettel passt.

Ehrlich ist die Norm auch bei der menschlichen Aufsicht (6.11.3.2). Wer am Tag zwanzigmal auf „Bestätigen“ klickt, prüft irgendwann nicht mehr. Sie beschreibt diesen Effekt ausdrücklich und rät, die Menschen aktiv im Ablauf zu halten. Eine Freigabe, die immer erteilt wird, ist keine Aufsicht. Sie ist ein Klickgeräusch.

Was Sie ab Montag damit anfangen

Die gute Nachricht steht in Abschnitt 5.1. Oft ist es wirksamer, den Software-Unterbau abzusichern, als teure Spezialabwehr gegen Abfrage-Angriffe zu bauen. Wer Angst um sein Modell hat, sichert zuerst den Server, auf dem die Modelldateien liegen. Erst die Tür. Dann das Fenster im dritten Stock.

• Eine Liste aller KI-Systeme anlegen, mit Zweck, Datenquellen und verantwortlicher Person (5.2).
• Jede KI-Nutzung protokollieren: Eingabe, Datum, Uhrzeit, Nutzer, Ausgabe und Modellversion (7.5). Ohne die Version lässt sich ein Vorfall später nicht nachstellen.
• Abfragen je Nutzer drosseln. Gebremst wird damit das systematische Ausprobieren, mit dem jemand ein Modell nachbaut oder austrickst; um Serverlast geht es dabei kaum (7.8).
• Modelle nur aus geprüften Quellen beziehen, Prüfsummen und Signaturen kontrollieren und Modelldateien in einem Format laden, das keinen Code ausführt, etwa safetensors (5.5.5, B.4.3).
• Ausgaben behandeln wie Eingaben von außen: prüfen, kodieren, nie ungefiltert in eine Webseite oder ein Folgesystem schieben (6.10).
• Die Wissensablage der KI mit denselben Rechten absichern wie die Originaldokumente (5.3, 7.6).
• Das Verhalten regelmäßig gegen einen festen Testsatz prüfen, damit eine Vergiftung auffällt, bevor sie wochenlang wirkt (6.11.3.5).

Zwei Warnungen aus Abschnitt 7 gehören auf jede Projektliste. Schutzmaßnahmen können sich gegenseitig stören: Ein Modell, das gegen eine Angriffsart trainiert wurde, kann für eine andere anfälliger werden (7.2). Und Schutzmaßnahmen verschleißen, genau wie das Modell selbst (7.4). Fertig abgesichert ist eine KI deshalb nie. Sie bleibt es nur, solange jemand misst.

Als Auditor frage ich nach dieser Lektüre zuerst nach dem Protokoll. Steht dort die Modellversion, lässt sich jeder Vorfall nachvollziehen. In ISO/IEC 42001 hängt das an den Maßnahmen A.6.2.6 und A.6.2.8, in ISO/IEC 27001 an A.8.15 und A.8.16. Die 27090 liefert jetzt die Begründung, warum gerade bei KI nichts davon optional ist.

Die neue Norm macht aus KI-Sicherheit kein Hexenwerk. Sie zeigt, dass der größte Teil Handwerk ist, das Sie aus der Informationssicherheit kennen. Neu ist, wo die Werkstücke liegen: in den Trainingsdaten, in der Wissensablage, in den Rechten des Agenten. Wer dort aufräumt, ist nicht wegen eines Zertifikats sicherer, sondern weil er weiß, was seine KI darf.