26/10/2026

NIST AI 100-2: Taxonomie adversarialer Angriffe auf KI

NIST AI 100-2 ist die Taxonomie adversarialer Angriffe auf KI, die das US-amerikanische National Institute of Standards and Technology unter dem Titel „Adversarial Machine Learning“ herausgibt: ein gemeinsames Vokabular für Angriffe auf prädiktive und generative KI und die dazugehörigen Gegenmaßnahmen. Für europäische Teams zählt das Dokument, weil Artikel 15 der KI-Verordnung genau diese Angriffsklassen nennt, ohne sie technisch auszufüllen. Wir zeigen, wie die Taxonomie aufgebaut ist, was sie bewusst offenlässt und wie aus ihren Kennungen eine prüffähige Nachweisakte wird.

Geöffnete Holzschublade einer Sammlung mit beschrifteten Fächern, darin kleine Messingschlüssel, eine gesprungene Lupe und ein gebrochenes Wachssiegel als Sinnbild für die Taxonomie NIST AI 100-2

Auf einen Blick

<code>NIST AI 100-2e2025</code> vom März 2025 ist das umfassendste öffentliche Vokabular für Angriffe auf KI-Systeme, aber freiwillig und ausdrücklich kein Compliance-Instrument.
Neu in NIST AI 100-2 sind stabile Kennungen: nach unserer Zählung 5 Verletzungskategorien und 25 Angriffskennungen vom Typ <code>NISTAML.022</code>.
Diese Kennungen taugen als Primärschlüssel für Bedrohungsregister, Testplan und die Nachweisakte nach Artikel 15 für Hochrisiko-KI-Systeme.
Die Entscheidung über akzeptable Restrisiken klammert NIST AI 100-2 bewusst aus; die KI-Verordnung verlangt sie in Artikel 9 und Anhang IV.
2026 kamen <code>ETSI EN 304 223</code>, <code>ISO/IEC 27090</code> und die Meldepflichten des Cyber Resilience Act hinzu; das Etikett „Super Intelligence“ auf NIST-Seiten ändert am Dokument nichts.

NIST AI 100-2: was das Dokument ist und was nicht

Der vollständige Titel lautet „Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations“. Die geltende Fassung NIST AI 100-2e2025 ist auf März 2025 datiert. Das Editorial Review Board von NIST gab sie am 20. März 2025 frei, die Ankündigung des CSRC folgte am 24. März 2025. Die Vorgängerin NIST AI 100-2e2023 erschien im Januar 2024. Autoren sind Apostol Vassilev (NIST), Alina Oprea (Northeastern University), Alie Fordyce und Hyrum Anderson (Cisco), Xander Davies (UK AI Security Institute) und Maia Hamin (US AI Safety Institute).

Nach unserer Zählung umfasst die Ausgabe 2025 127 Seiten und 449 nummerierte Literaturangaben, die Ausgabe 2023 kam auf 107 Seiten und 354 Angaben. Ein Glossar legt die Begriffe fest, auf die sich Entwicklung, Security und Prüfer einigen können. Konzeptionell baut der Bericht auf dem NIST AI RMF auf und übernimmt dessen Begriffe Sicherheit, Resilienz und Widerstandsfähigkeit. Wer generative Systeme betreibt, liest ihn sinnvollerweise zusammen mit dem Profil NIST AI 600-1.

Zwei Abgrenzungen prägen die Compliance-Arbeit. Die Executive Summary hält fest, dass der Bericht keine Empfehlungen zur Risikotoleranz gibt. Eine Fußnote stellt klar, dass er „does not establish any legal standard or any other legal requirement or defense under any law“. NIST AI 100-2 ist damit Referenzvokabular, kein Prüfmaßstab.

Von NIST AI 100-2e2023 zu NIST AI 100-2e2025

Fünf Änderungen sind für die Praxis relevant. Erstens die Kennungen: Die Ausgabe 2023 hatte keine, die Ausgabe 2025 vergibt nach unserer Zählung 30 <code>NISTAML</code>-Codes. Zweitens heißt die Zielkategorie für generative KI nicht mehr „abuse“, sondern „misuse“. Drittens gibt es einen eigenen Abschnitt zur Lieferkette generativer KI, viertens neue Abschnitte zur Sicherheit von Agenten und zu Benchmarks. Fünftens wuchs das Literaturverzeichnis von 354 auf 449 Einträge.

Das neue Etikett „Super Intelligence“

Seit der Executive Order „Inaugurating the Era of Super Intelligence“ vom 29. September 2026 (Fact Sheet des Weißen Hauses) schreiben Bundesbehörden der US-Exekutive in offiziellen Mitteilungen „Super Intelligence“ statt „Artificial Intelligence“. Die Projektseite des NCCoE heißt nun „Super Intelligence: Adversarial Machine Learning“. Am 20. Oktober 2026 wurden die SP 800-53 Control Overlays for Securing AI Systems (COSAiS) in COSIS umbenannt, mit dem Hinweis „Previously issued documents and publications have not been altered“. Die Overlays nennen <code>NIST AI 100-2e2025</code> als Grundlage. Eine Ausgabe 2026 oder einen öffentlichen Entwurf haben wir bis zum 22. Oktober 2026 nicht gefunden, obwohl NIST im März 2025 jährliche Aktualisierungen angekündigt hatte.

Wie die Taxonomie aufgebaut ist

Die Taxonomie von NIST AI 100-2 beschreibt jeden Angriff entlang fünf Dimensionen. Wer ein Bedrohungsmodell schreibt, sollte sie als Pflichtfelder übernehmen:

Systemtyp: prädiktive KI wie Klassifikatoren und Erkennungsmodelle oder generative KI wie Sprachmodelle, RAG-Anwendungen und Agenten.
Lebenszyklusphase: vom Training über die Feinabstimmung bis zum Betrieb; Poisoning setzt früh an, Evasion und Prompt Injection zur Laufzeit.
Ziele des Angreifers: Verfügbarkeit, Integrität und Privatsphäre, bei generativer KI zusätzlich Missbrauch („misuse“).
Fähigkeiten des Angreifers: etwa Kontrolle über Trainingsdaten, Kontrolle über das Modell, reiner Abfragezugang oder Kontrolle über Ressourcen, die ein RAG-System oder ein Agent mit Werkzeugen einliest.
Wissen des Angreifers: White-Box, Black-Box oder Gray-Box.

Ein Beispiel: Ein Kundenchatbot mit RAG-Anbindung, den Externe nur über die Weboberfläche erreichen, hat es mit einem Black-Box-Angreifer zu tun, der Abfragezugang und indirekten Einfluss auf die Wissensbasis hat. Daraus folgen andere Kennungen als für ein intern trainiertes Bilderkennungsmodell, dessen Trainingsdaten aus fremden Quellen stammen. Für Prüfer ist diese Struktur nachvollziehbar, weil jede Einstufung eine Begründung trägt.

Aus den Zielen entstehen die fünf Verletzungskategorien mit eigenem Code: <code>NISTAML.01</code> Verfügbarkeit, <code>NISTAML.02</code> Integrität, <code>NISTAML.03</code> Privatsphäre, <code>NISTAML.04</code> Missbrauch, <code>NISTAML.05</code> Lieferkette. Darunter hängen die Angriffskennungen. Die zweite Ziffer verweist auf die Kategorie, unter der ein Angriff zuerst geführt wird. Derselbe Angriff kann mehrfach auftauchen, Prompt Injection (<code>NISTAML.018</code>) etwa unter Verfügbarkeit, Integrität, Privatsphäre und Missbrauch.

Warum das für ein Register zählt: Werkzeuge, Scanner und Produktnamen wechseln, die Kennung bleibt. Wer Risiken, Kontrollen, Tests und Befunde auf <code>NISTAML</code>-Codes schlüsselt, kann Ergebnisse aus verschiedenen Testwerkzeugen zusammenführen, Abdeckungslücken per Abfrage sichtbar machen und dieselbe Zeile später einer anderen Norm zuordnen. NIST AI 100-2 liefert damit eine gemeinsame Sprache für die KI-Sicherheit, die Entwicklung, Security und Compliance gleichermaßen lesen können.

Angriffe auf prädiktive KI: Evasion, Poisoning, Privatsphäre

Evasion. Bei der Evasion (<code>NISTAML.022</code>) verändert der Angreifer Eingaben zur Laufzeit so, dass das Modell falsch entscheidet. Die Black-Box-Variante (<code>NISTAML.025</code>) kommt ohne Modellkenntnis aus und nutzt nur Abfragen. Weil manipulierte Beispiele oft von einem Modell auf ein anderes übertragbar sind, bleiben auch Systeme angreifbar, deren Gewichte geheim sind. NIST AI 100-2 nennt Fälle aus der physischen Welt, etwa Stoppschilder, die als Tempolimit-Schilder klassifiziert werden.

Poisoning. Verfügbarkeitsangriffe verschlechtern das Modell insgesamt: Data Poisoning (<code>NISTAML.013</code>), Model Poisoning (<code>NISTAML.011</code>), Clean-Label Poisoning (<code>NISTAML.012</code>) und Energy-Latency-Angriffe (<code>NISTAML.014</code>), die Rechenzeit und Energiebedarf hochtreiben. Gezieltes Poisoning (<code>NISTAML.024</code>) verfälscht nur bestimmte Vorhersagen. Backdoors (<code>NISTAML.023</code>, als Clean-Label-Variante <code>NISTAML.021</code>) verankern einen Auslöser, der erst später wirkt. Model Poisoning gegen die Integrität (<code>NISTAML.026</code>) und über die Lieferkette (<code>NISTAML.051</code>) manipuliert das Modell selbst, etwa ein vortrainiertes Modell aus einem öffentlichen Repository.

Privatsphäre. Model Extraction (<code>NISTAML.031</code>) bildet Funktion oder Parameter über Abfragen nach, Reconstruction (<code>NISTAML.032</code>) gewinnt Trainingsdaten zurück, Membership Inference (<code>NISTAML.033</code>) klärt, ob ein Datensatz im Training war, und Property Inference (<code>NISTAML.034</code>) erschließt Eigenschaften der Trainingsdaten insgesamt. Bei personenbezogenen Trainingsdaten ist das unmittelbar ein Datenschutzthema. Wer Modelle über eine API anbietet, sollte Extraction und Membership Inference deshalb als Standardszenarien behandeln, nicht als Randfall.

Gegenmaßnahmen. NIST AI 100-2 nennt Adversarial Training, Randomized Smoothing und formale Verifikation gegen Evasion, Datenbereinigung und Modellinspektion gegen Poisoning sowie Differential Privacy gegen Angriffe auf die Privatsphäre. Der Bericht warnt zugleich, dass diese Maßnahmen weitgehend empirisch sind: Für die verbreiteten ML-Algorithmen gibt es keine informationstheoretischen Sicherheitsbeweise. Für die Nachweisführung heißt das, dass Wirksamkeit durch Tests belegt wird, nicht durch den Verweis auf eine Technik. Wie solche Tests aufgebaut sind, beschreibt unser Beitrag zum KI-Red-Teaming.

Angriffe auf generative KI: Lieferkette, Prompt Injection, Agenten

Bei generativen Systemen verschiebt sich der Schwerpunkt vom Training zur Laufzeit. Direkte Prompt Injection (<code>NISTAML.018</code>) umfasst Eingaben, die Sicherheitsvorgaben aushebeln, Jailbreaks eingeschlossen. Indirekte Prompt Injection (<code>NISTAML.015</code>) platziert Anweisungen in Inhalten, die das System selbst abruft: Webseiten, E-Mails, Dokumente im RAG-Index. Eine Variante (<code>NISTAML.017</code>) lässt das Modell zeitraubende Hintergrundaufgaben ausführen und greift so die Verfügbarkeit an.

Weitere Kennungen betreffen Integrität und Vertraulichkeit: Misaligned Outputs (<code>NISTAML.027</code>), Prompt Extraction (<code>NISTAML.035</code>), der Abfluss von Informationen aus Nutzerinteraktionen (<code>NISTAML.036</code>), Angriffe auf Trainingsdaten (<code>NISTAML.037</code>), Data Extraction (<code>NISTAML.038</code>) und die Kompromittierung verbundener Ressourcen (<code>NISTAML.039</code>). Hinzu kommt die Lieferkette: Modelle, Gewichte und Datensätze Dritter, die der eigene Betrieb übernimmt. NIST verweist in Abschnitt 4.2.4 etwa auf Forschung, nach der sich gängige Quantisierungsverfahren ausnutzen lassen, um ein schädliches quantisiertes Sprachmodell zu erzeugen, während das Ausgangsmodell unauffällig wirkt. Wer solche Modelle einsetzt, sollte ihr Verhalten fortlaufend überwachen. Eine KI-Stückliste (AI-BOM) ist hier die Grundlage jeder Prüfung: Jede Komponente Dritter braucht einen Herkunftsnachweis, bevor sie in Produktion geht.

Bei Agenten bleibt NIST AI 100-2 vorsichtig: Sicherheitsforschung speziell zu Agenten „is still in its early stages“ (Abschnitt 3.5). Die Konsequenz benennt der Bericht trotzdem klar. Weil Agenten Werkzeuge nutzen, wird aus einer Prompt Injection ein Weg zur Ausführung beliebigen Codes oder zum Abfluss von Daten aus der Umgebung des Agenten. Schutzmaßnahmen für den produktiven Einsatz beschreibt unser Beitrag zur Sicherheit von KI-Agenten.

Für Tests verweist NIST AI 100-2 auf öffentliche Benchmarks und Werkzeuge, darunter JailbreakBench, HarmBench, AgentDojo, Garak und PyRIT. Die Zuordnung dieser Angriffe zu den Risiken der OWASP Top 10 für LLM-Anwendungen erleichtert das Gespräch mit Entwicklungsteams, die OWASP bereits kennen.

Was NIST AI 100-2 bewusst ausklammert

Nach unserer Zählung mit pypdf erwähnt die Ausgabe 2025 weder die KI-Verordnung noch eine einzige ISO/IEC-Norm. Das Wort „compliance“ kommt einmal vor, „regulation“ zweimal. Das ist kein Versäumnis, sondern Absicht. In Abschnitt 4.2.5 schreibt NIST: „A key question that this taxonomy deliberately leaves aside is how organizations can make decisions about the development and use of AI systems in light of evidence about the increasing diversity of AML attacks and the efficacy and limitations of available mitigations.“ Der Abschnitt hält lediglich fest, dass Entwickler adversariale Risiken zunehmend in Tests vor der Bereitstellung prüfen, etwa durch strukturiertes Red Teaming.

In die Sprache des Risikomanagements übersetzt: Die Taxonomie sagt, was passieren kann und was dagegen hilft, aber nicht, wann ein Unternehmen ein System trotz bekannter Schwächen betreiben darf. Ebenfalls außerhalb des Rahmens bleiben klassische Cyberangriffe auf die Plattform, nicht adversariale Konstruktionsfehler und jede Aussage zur Risikotoleranz. Dazu kommt ein Befund, den NIST aus der Forschung übernimmt: Solange ein Modell mit irgendeiner Wahrscheinlichkeit ein unerwünschtes Verhalten zeigen kann, lässt sich ein Prompt finden, der es auslöst. Für die Plattformseite bleiben bewährte Rahmenwerke wie das NIST Cybersecurity Framework zuständig, für das Managementsystem die Normenfamilie um ISO/IEC 42001.

Genau diese Lücke füllt die KI-Verordnung. Artikel 9 verlangt ein Risikomanagement, das auch vernünftigerweise vorhersehbare Fehlanwendung abdeckt, und Artikel 9 Absatz 5 verlangt, dass das Restrisiko als vertretbar beurteilt wird. Anhang IV Nummer 2 Buchstabe h fordert in der technischen Dokumentation eine Beschreibung der getroffenen Cybersicherheitsmaßnahmen. Wer nur die Taxonomie abarbeitet, hat eine vollständige Liste, aber noch keinen Nachweis. Die Entscheidung, die NIST AI 100-2 offenlässt, ist in Europa eine Pflicht mit Unterschrift.

NIST AI 100-2 und Artikel 15 Absatz 5 KI-Verordnung: die Zuordnung

Artikel 15 Absatz 5 der KI-Verordnung verlangt zunächst, dass Hochrisiko-KI-Systeme widerstandsfähig gegen Versuche unbefugter Dritter sind, ihre Verwendung, Ausgaben oder Leistung durch Ausnutzung von Systemschwachstellen zu verändern. Dann wird er konkret. Die deutsche Fassung lautet: „Die technischen Lösungen für den Umgang mit KI-spezifischen Schwachstellen umfassen gegebenenfalls Maßnahmen, um Angriffe, mit denen versucht wird, eine Manipulation des Trainingsdatensatzes (‚data poisoning‘) oder vortrainierter Komponenten, die beim Training verwendet werden (‚model poisoning‘), vorzunehmen, Eingabedaten, die das KI-Modell zu Fehlern verleiten sollen (‚adversarial examples‘ oder ‚model evasions‘), Angriffe auf vertrauliche Daten oder Modellmängel zu verhüten, zu erkennen, darauf zu reagieren, sie zu beseitigen und zu kontrollieren.“ Wo die englische Fassung von „confidentiality attacks“ spricht, steht im Deutschen „Angriffe auf vertrauliche Daten“.

Die Verordnung nennt Klassen, NIST AI 100-2 liefert Kennungen. Die folgende Zuordnung ist unsere eigene Arbeitshilfe, keine amtliche Auslegung:

Begriff in Art. 15 Abs. 5	Klassen und Kennungen in NIST AI 100-2	Nachweise für die Akte
Data Poisoning (Trainingsdatensatz)	<code>NISTAML.013</code>, <code>NISTAML.012</code>, <code>NISTAML.024</code>, Backdoors <code>NISTAML.021</code> und <code>NISTAML.023</code>	Herkunfts- und Bereinigungsnachweise der Trainingsdaten, Poisoning-Tests, Verweis auf die Daten-Governance nach Artikel 10
Model Poisoning (vortrainierte Komponenten)	<code>NISTAML.011</code>, <code>NISTAML.026</code>, Lieferkette <code>NISTAML.051</code>	AI-BOM, Herkunft und Hash-Prüfung der Modelle, Zusicherungen der Lieferanten
Adversarial Examples oder Model Evasion	<code>NISTAML.022</code>, <code>NISTAML.025</code>, bei generativen Systemen nach unserer Lesart auch Prompt Injection <code>NISTAML.018</code> und <code>NISTAML.015</code>	Testplan und Ergebnisse adversarialer Tests, Kennzahlen zur Widerstandsfähigkeit im Testabschnitt nach Anhang IV
Angriffe auf vertrauliche Daten	<code>NISTAML.031</code> bis <code>NISTAML.039</code> (Extraction, Membership und Property Inference, Prompt und Data Extraction)	Tests auf Angriffe gegen die Privatsphäre, Nachweise zu Rate Limiting und Ausgabefilterung, Verweis auf die Datenschutz-Folgenabschätzung nach DSGVO
Modellmängel	weitgehend außerhalb von NIST AI 100-2, da nicht adversariale Fehler ausgeklammert sind	Tests zu Genauigkeit und Widerstandsfähigkeit nach Artikel 15 Absätze 1 bis 4
Rückkopplungsschleifen (Art. 15 Abs. 4, weiterlernende Systeme)	Poisoning über Rückkopplung, <code>NISTAML.013</code> und <code>NISTAML.024</code>	Überwachung von Drift und Eingabedaten, Plan zur Beobachtung nach dem Inverkehrbringen (Artikel 72)

Zum Zeitplan: Nach dem Digital-Omnibus, Verordnung (EU) 2026/1744 (Amtsblatt vom 24. Juli 2026, in Kraft seit 27. Juli 2026), gilt Artikel 15 für Hochrisiko-Systeme nach Anhang III ab dem 2. Dezember 2027 und für Systeme nach Anhang I ab dem 2. August 2028. Für KI-Modelle mit allgemeinem Verwendungszweck mit systemischem Risiko gelten Artikel 55 Absatz 1 Buchstabe a (Modellbewertung einschließlich dokumentierter Angriffstests) und Buchstabe d (angemessenes Cybersicherheitsniveau für Modell und physische Infrastruktur) bereits seit dem 2. August 2025. Seit dem 2. August 2026 kann die Kommission Geldbußen verhängen. Das Kapitel Safety and Security des Praxisleitfadens für KI mit allgemeinem Verwendungszweck vom 10. Juli 2025 konkretisiert Bewertungen, adversariale Tests und Sicherheitsmaßnahmen.

Die europäischen Normen, die Artikel 15 tragen werden

Die KI-Verordnung nennt Angriffsklassen, die technische Ausgestaltung übernehmen Normen. Hier hat sich 2026 mehr bewegt als in den Jahren davor.

prEN 18282 und ETSI EN 304 223

<code>prEN 18282</code> ist der Entwurf einer Europäischen Norm zur Cybersicherheit von KI-Systemen aus CEN-CENELEC JTC 21 WG 5, erarbeitet zur Unterstützung von Artikel 15. Die öffentliche Umfrage lief je nach nationalem Normungsinstitut vom 15. Mai bis Mitte Juli 2026, die Veröffentlichung ist zwischen Ende 2026 und Anfang 2027 geplant. Eine Konformitätsvermutung entsteht erst, wenn die Fundstelle im Amtsblatt veröffentlicht ist.

<code>ETSI EN 304 223</code> erschien am 14. Januar 2026 (Pressemitteilung von ETSI). Die Norm formuliert 13 Prinzipien über fünf Lebenszyklusphasen: sicheres Design, Entwicklung, Bereitstellung, Wartung und Lebensende. Sie baut auf ETSI TS 104 223 auf, für generative KI ist ETSI TR 104 159 angekündigt.

ISO/IEC 27090 und der Weg über den Cyber Resilience Act

<code>ISO/IEC 27090:2026</code> ist im Oktober 2026 in erster Ausgabe erschienen, 56 Seiten, ein Leitfaden ohne Zertifizierbarkeit (Bericht bei heise). Behandelt werden Poisoning, Manipulation von Gewichten, Evasion, Extraction, Membership Inference, Model Inversion und Prompt Injection.

Nach Artikel 12 des Cyber Resilience Act, Verordnung (EU) 2024/2847, gilt ein Hochrisiko-KI-System, das zugleich ein Produkt mit digitalen Elementen ist, als konform mit den Cybersicherheitsanforderungen aus Artikel 15, wenn es Anhang I des CRA erfüllt und das Schutzniveau in der EU-Konformitätserklärung nach CRA nachgewiesen ist. Genauigkeit und Widerstandsfähigkeit bleiben Sache der KI-Verordnung. Seit dem 11. September 2026 gelten die Meldepflichten des CRA: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht binnen 14 Tagen nach Verfügbarkeit einer Korrekturmaßnahme bei aktiv ausgenutzten Schwachstellen, jeweils über die zentrale Meldeplattform der ENISA. Hinzu kommt Artikel 42 Absatz 2 KI-Verordnung: Eine Zertifizierung nach einem Schema gemäß Verordnung (EU) 2019/881 begründet die Vermutung, die Cybersicherheitsanforderungen aus Artikel 15 zu erfüllen. Wie diese Wege in die Konformitätsbewertung einfließen, entscheidet sich je System.

Für deutsche Teams ist das BSI die natürliche Referenz: Als nationale Cybersicherheitsbehörde veröffentlicht es Leitfäden zu KI-spezifischen Angriffen, etwa „AI Security Concerns in a Nutshell“ (2023). Ergänzend enthält die ENISA-Studie Securing Machine Learning Algorithms von 2021 einen Katalog von Bedrohungen und Kontrollen.

Unsere Lesart: Alle diese Texte zählen dieselben Angriffsklassen auf wie NIST AI 100-2. Ein Register mit NISTAML-Kennungen als Schlüssel lässt sich für jede Norm neu beschriften, statt es neu aufzubauen.

Von NIST AI 100-2 zur Nachweisakte: sieben Schritte

Inventarisieren und einordnen. Erfassen Sie jedes KI-System und ordnen Sie es als prädiktiv, generativ oder agentisch ein. Halten Sie zugleich den regulatorischen Status fest: Hochrisiko-KI-System, Modell mit allgemeinem Verwendungszweck oder sonstiges System. Erst diese Kombination bestimmt, welche Kennungen relevant sind.
Bedrohungen gegen die Kennungen modellieren. Prüfen Sie jedes System gegen die <code>NISTAML</code>-Liste und dokumentieren Sie realistische Fähigkeiten des Angreifers: nur Abfragezugang, Zugriff auf eine Fine-Tuning-API, Einfluss auf die RAG-Quellen oder Zugriff auf Werkzeuge. Verworfene Kennungen erhalten eine kurze Begründung.
Kontrollen zuordnen. Verknüpfen Sie jede beibehaltene Kennung mit Kontrollen. Für Details auf Technikebene helfen MITRE ATLAS und die OWASP-Listen, die Kennung bleibt der Schlüssel.
Testen. Führen Sie adversariale Tests und Red Teaming mit den Werkzeugen durch, die NIST AI 100-2 nennt, etwa Garak, PyRIT oder AgentDojo. Dokumentieren Sie Methode, Umfang und Ergebnisse je Kennung.
Restrisiko entscheiden und zeichnen. Bewerten Sie das verbleibende Risiko je Kennung und lassen Sie die Bewertung von einer verantwortlichen Person freigeben. Das ist die Entscheidung, die NIST AI 100-2 ausklammert und Artikel 9 Absatz 5 verlangt.
Dokumentation schreiben. Verfassen Sie den Abschnitt zu Cybersicherheitsmaßnahmen nach Anhang IV Nummer 2 Buchstabe h und den Teil zu Artikel 15 in der Konformitätserklärung mit Verweis auf die Kennungen. Prüfer sehen so sofort, welche Angriffsklasse mit welchem Nachweis abgedeckt ist.
Überwachen und melden. Verankern Sie die Kennungen in der Beobachtung nach dem Inverkehrbringen (Artikel 72) und in der Meldung schwerwiegender Vorfälle nach Artikel 73. Bei aktiv ausgenutzten Schwachstellen läuft parallel die 24-Stunden-Frühwarnung des CRA. Überprüfen Sie das Register jährlich, im Takt der angekündigten NIST-Aktualisierungen.

Wer Register, Tests und Freigaben an einem Ort führen will, findet die Funktionen dazu in unserer Software für KI-Risikomanagement.

Häufige Fragen

Ist NIST AI 100-2 in Europa verbindlich?

Nein. Das Dokument ist eine freiwillige Veröffentlichung einer US-Behörde und begründet nach eigener Aussage keine rechtliche Anforderung. In Europa zählen die KI-Verordnung, der Cyber Resilience Act und künftig harmonisierte Normen wie <code>prEN 18282</code>. Trotzdem ist NIST AI 100-2 nützlich, weil es die Angriffsklassen aus Artikel 15 präzise beschreibt und mit stabilen Kennungen versieht. Wer seine Nachweise darauf aufbaut, spricht eine Sprache, die Prüfer, Lieferanten und Testwerkzeuge verstehen, ohne sich rechtlich an NIST zu binden.

Was hat sich zwischen den Ausgaben 2023 und 2025 geändert?

Die Ausgabe 2025 führt die <code>NISTAML</code>-Kennungen ein, nach unserer Zählung 5 Kategorien und 25 Angriffe; 2023 gab es keine. Die Zielkategorie für generative KI heißt nun „misuse“ statt „abuse“. Neu sind ein eigener Abschnitt zur Lieferkette generativer KI sowie Abschnitte zur Sicherheit von Agenten und zu Benchmarks. Der Umfang wuchs von 107 auf 127 Seiten, das Literaturverzeichnis von 354 auf 449 Einträge. Für die Praxis ist die erste Änderung die wichtigste, weil sie das Dokument registerfähig macht.

Deckt NIST AI 100-2 KI-Agenten ab?

Teilweise. Abschnitt 3.5 behandelt Agenten und hält fest, dass die Sicherheitsforschung dazu „is still in its early stages“. Der Bericht beschreibt, wie direkte und indirekte Prompt Injection bei Agenten mit Werkzeugzugriff zur Ausführung von Code oder zum Abfluss von Daten führen kann, und nennt AgentDojo und AgentHarm als Benchmarks. Eigene Kennungen nur für Agenten gibt es nicht, relevant sind vor allem <code>NISTAML.015</code>, <code>NISTAML.018</code> und <code>NISTAML.039</code>. Für die Absicherung im Betrieb reicht das nicht, siehe unseren Leitfaden zur Sicherheit von KI-Agenten.

Wie verhält sich das Dokument zu MITRE ATLAS und den OWASP Top 10 für LLM-Anwendungen?

Die drei ergänzen sich. NIST AI 100-2 liefert Klassen, Begriffe und Kennungen. MITRE ATLAS beschreibt Taktiken und Techniken entlang einer Angriffskette mit Fallstudien und eignet sich für Bedrohungsmodellierung und Red Teaming. Die OWASP Top 10 für LLM-Anwendungen priorisieren Risiken aus Sicht der Anwendungsentwicklung. Im Register empfehlen wir die NIST-Kennung als Primärschlüssel und ATLAS- sowie OWASP-Einträge als Querverweise, weil die NIST-Kennungen die gröbere und stabilere Ebene bilden.

Reicht NIST AI 100-2 für Artikel 15 der KI-Verordnung aus?

Nein. Das Dokument hilft, die geforderten Angriffsklassen vollständig zu erfassen und Tests zu strukturieren. Es enthält aber keine Akzeptanzkriterien und keine Aussagen zur Risikotoleranz, und es klammert Modellmängel ohne Angreifer ebenso aus wie klassische Plattformsicherheit. Artikel 15 verlangt außerdem Genauigkeit und Widerstandsfähigkeit, Artikel 9 eine begründete Restrisikoentscheidung und Anhang IV eine Beschreibung der Cybersicherheitsmaßnahmen. Sinnvoll ist NIST AI 100-2 als Gliederung der Nachweisakte, ergänzt um harmonisierte Normen, sobald sie im Amtsblatt stehen.

Warum steht auf NIST-Seiten jetzt „Super Intelligence“?

Eine Executive Order vom 29. September 2026 verpflichtet Bundesbehörden der US-Exekutive, in offiziellen Mitteilungen und nicht gesetzlichen Dokumenten „Super Intelligence“ oder „SI“ statt „Artificial Intelligence“ zu verwenden. Private Unternehmen trifft daraus keine Pflicht. NIST hat Projektseiten umbenannt, etwa die NCCoE-Seite zu Adversarial Machine Learning, und die Overlays COSAiS heißen seit dem 20. Oktober 2026 COSIS. Bereits veröffentlichte Dokumente wurden laut NIST nicht verändert. Die Kennung <code>NIST AI 100-2e2025</code> bleibt daher die richtige Referenz in Ihrer Dokumentation.

Fazit

NIST AI 100-2 ist das präziseste öffentliche Vokabular für Angriffe auf KI, und seit der Ausgabe 2025 hat es, was einem Register bisher fehlte: stabile Kennungen. Ein Compliance-Werkzeug ist es bewusst nicht. Die Entscheidung, welches Restrisiko vertretbar ist, und der Nachweis gegenüber Marktüberwachung und benannten Stellen bleiben bei Ihnen. Unser Vorschlag: Schlüsseln Sie Bedrohungen, Kontrollen, Tests und Freigaben auf <code>NISTAML</code>-Kennungen, ordnen Sie diese Artikel 15 Absatz 5 zu und beschriften Sie dieselben Zeilen später für <code>prEN 18282</code>, <code>ETSI EN 304 223</code> oder <code>ISO/IEC 27090</code> neu. Beginnen Sie mit einem System, am besten dem mit dem höchsten Risiko, und prüfen Sie, welche Kennungen ohne Test, ohne Kontrolle oder ohne unterschriebene Restrisikoentscheidung dastehen. Diese Lücken sind Ihr Arbeitsplan bis Dezember 2027.

Dr. Anna Hoffmann