Wer vor einem Audit nach KI-Verordnung oder ISO/IEC 42001 steht, muss sich für ein KI-Sicherheitsframework entscheiden, und das Angebot umfasst inzwischen mehr als fünfzehn Kandidaten: Gesetze, Normen, Bedrohungskataloge, Kontrollmatrizen und die Frameworks der Plattformanbieter. Wir stellen sie nicht in eine Rangliste, sondern ordnen sie vier Familien zu, die vier verschiedene Fragen beantworten. Am Ende stehen eine Auswahlregel nach Rolle und die Liste der Nachweise, die ein Prüfer tatsächlich akzeptiert.
Auf einen Blick
- Vor der Wahl eines KI-Sicherheitsframeworks steht die Frage, was es beantworten soll: Recht, Bedrohungen, Kontrollen oder Verantwortung.
- Das Recht legt fest, was Sie beweisen (Art. 15 und 55 KI-VO, Cyber Resilience Act), Bedrohungskataloge, was Sie testen, Kontrollkataloge, was Sie belegen.
- Der Oktober 2026 hat die Antwort verschoben: ISO/IEC 27090 ist erschienen, EN 18286 steht als erste harmonisierte Norm im Amtsblatt, prEN 18282 hat die öffentliche Umfrage hinter sich.
- Über den neuen Art. 42 Abs. 3 KI-VO kann eine CRA-Konformitätserklärung die Cybersicherheit nach Art. 15 abdecken, nicht aber Genauigkeit und Robustheit.
- Nur CSA AICM und Databricks DASF liefern Mappings auf KI-Verordnung und ISO/IEC 42001 auf Kontrollebene. SAIF, CoSAI, AWS und Microsoft sind Umsetzungshilfen, kein Konformitätsnachweis.
Was ein KI-Sicherheitsframework ist und was nicht
Ein KI-Sicherheitsframework ist ein benannter, versionierter Satz von Bedrohungen, Kontrollen oder Verantwortlichkeiten zur Absicherung eines KI-Systems (Daten, Modell, Pipeline, Anwendung, Agenten), an dem ein Dritter Sie messen kann. Die beiden Adjektive tragen die Definition: Eine interne Checkliste ohne Namen und Version ist kein Framework, weil kein Prüfer sie gegen eine Referenz halten kann. Den größeren Zusammenhang erläutert unser Überblick zur KI-Sicherheit.
Vier Familien beantworten vier verschiedene Fragen:
- <b>Recht:</b> was Sie beweisen müssen. Artikel 15 der KI-Verordnung, Artikel 55 Absatz 1 Buchstabe d für Modelle mit systemischem Risiko, der Cyber Resilience Act.
- <b>Bedrohungskataloge:</b> was Sie testen müssen. MITRE ATLAS, die OWASP-Listen, NIST AI 100-2.
- <b>Kontrollkataloge:</b> was Sie belegen müssen. CSA AI Controls Matrix, Databricks DASF, ISO/IEC 42001 Anhang A, ISO/IEC 27090, die NIST-Overlays, ETSI EN 304 223, ENISA.
- <b>Architektur und Verantwortung:</b> wer was verantwortet. Google SAIF, CoSAI, AWS, Microsoft, Cisco.
Wer ein KI-Sicherheitsframework aus nur einer Familie wählt, lässt drei Fragen offen. Ein Bedrohungskatalog sagt nicht, welche Kontrolle der Auditor sehen will, ein Kontrollkatalog nicht, welche Angriffe Sie testen, ein Gesetz nicht, wer in der Cloud den Schlüssel verwaltet.
Drei Abgrenzungen. Erstens ist ein KI-Sicherheitsframework kein Produkt für AI Security Posture Management: Solche Werkzeuge erzeugen Nachweise, sie sind kein Maßstab. Zweitens ist es kein KI-Safety-Framework. Cisco argumentierte am 16. Dezember 2025, Security und Safety seien untrennbar; die KI-Verordnung regelt beides dennoch in getrennten Artikeln, und ein Audit folgt dieser Trennung. Drittens ist es nicht Ihr KI-Governance-Rahmenwerk: Dieses ordnet Rollen, Gremien und Richtlinien für alle KI-Risiken, das Sicherheitsframework ist ein Baustein darin.
Die Karte 2026: alle Frameworks in einer Tabelle
| Framework | Herausgeber | Familie | Aktuelle Version (Datum) | Umfang | Bezug zu Recht oder Norm |
|---|---|---|---|---|---|
| KI-Verordnung, Artikel 15 | Europäische Union | Recht | Verordnung (EU) 2024/1689; gilt ab 2. Dezember 2027 (Anhang III) und 2. August 2028 (Anhang I) | ein Artikel, sechs benannte Angriffsklassen | ist das Recht |
| Cyber Resilience Act | Europäische Union | Recht | Verordnung (EU) 2024/2847; Meldepflichten ab 11. September 2026, volle Anwendung ab 11. Dezember 2027 | wesentliche Anforderungen nach Anhang I | Art. 12 Abs. 1: Cybersicherheit nach Art. 15 gilt als erfüllt |
| prEN 18282 | CEN-CENELEC JTC 21 | Harmonisierte Norm (Entwurf) | öffentliche Umfrage 15. Mai bis 14. Juli 2026 | nicht öffentlich | für Art. 15 geschrieben |
| ISO/IEC 27090:2026 | ISO/IEC JTC 1/SC 27 | Leitfaden | erschienen im Oktober 2026, 56 Seiten | Leitfaden, nicht zertifizierbar | Nachweis in Audits nach ISO/IEC 27001 und 42001 |
| ISO/IEC 42001:2023, Anhang A | ISO/IEC JTC 1/SC 42 | Zertifizierbares Managementsystem | Dezember 2023 | Maßnahmen in Anhang A (A.6.2, A.7, A.8.4, A.10.3) | Zertifikat |
| NIST AI RMF 1.0 und NIST AI 600-1 | NIST | Risikoframework | Januar 2023, Juli 2024 | vier Funktionen, Merkmal „secure and resilient“ | freiwillig; von AICM und DASF gemappt |
| NIST Cyber AI Profile (NIST IR 8596) | NIST und MITRE | Community-Profil zu CSF 2.0 | erster Vorentwurf 16. Dezember 2025; noch kein öffentlicher Entwurf | drei Schwerpunkte (Secure, Defend, Thwart) | CSF 2.0 und AI RMF |
| NIST SP 800-53 Control Overlays for Securing AI Systems | NIST | Kontroll-Overlay | Konzeptpapier 14. August 2025; noch kein Overlay-Entwurf | fünf Overlays | SP 800-53 Rev. 5 |
| NIST AI 100-2 E2025 | NIST | Bedrohungstaxonomie | 24. März 2025, 127 Seiten | zwei Taxonomien (prädiktive und generative KI) | keiner |
| Guidelines for Secure AI System Development | NCSC und CISA, 23 mitzeichnende Organisationen | Lebenszyklus-Leitfaden | 27. November 2023 | vier Phasen | keiner |
| ETSI EN 304 223 | ETSI (nach dem britischen AI Cyber Security Code of Practice) | Basisanforderungen | TS April 2025, EN Dezember 2025 | 13 Prinzipien, 72 Vorgaben, fünf Phasen | keiner |
| ENISA FAICP | ENISA | Good-Practice-Framework | 7. Juni 2023 | drei Ebenen | Zusammenarbeit nach Erwägungsgrund 78 KI-VO |
| MITRE ATLAS | MITRE | Wissensbasis zu Bedrohungen | Release 2026.10 (28. Oktober 2026) | 16 Taktiken, 129 Techniken, 92 Subtechniken, 44 Gegenmaßnahmen | ATT&CK |
| OWASP Top 10 for LLM 2026, Agentic Top 10, AI Exchange | OWASP GenAI Security Project | Bedrohungslisten und Kontrollleitfaden | August 2026, Dezember 2025, Flagship seit März 2025 | 10 + 10 Einträge, mehr als 50 Kontrollen | NIST, ATLAS, CWE; die AI Exchange floss in ISO/IEC 27090 und prEN 18282 ein |
| CSA AI Controls Matrix | Cloud Security Alliance | Kontrollkatalog | v1.1, 22. Juni 2026 | 247 Kontrollen, 18 Domänen, AI-CAIQ mit 320 Fragen | ISO/IEC 42001, ISO 27001, NIST AI RMF, AI 600-1, BSI AIC4, KI-Verordnung |
| Databricks DASF | Databricks | Kontrollkatalog | v3.0, 20. März 2026 | 13 Komponenten, 97 Risiken, 73 Kontrollen | ATLAS, OWASP, SP 800-53, CSF, ENISA, ISO/IEC 42001, 27001, KI-Verordnung |
| Google SAIF | Google (Daten an CoSAI übergeben) | Architektur und Risikokarte | SAIF 2.0, 6. Oktober 2025 | 15 Risiken, 24 Kontrollen, drei Agentenprinzipien | keiner |
| CoSAI, AWS, Microsoft | OASIS, AWS, Microsoft | Geteilte Verantwortung und Scoping | CoSAI Shared Responsibility Framework v1.0 Mai 2026; AWS AI Security Framework Mai 2026; Microsoft-Agentenmodell August 2026 | Schichten, Scopes, Prinzipien | keiner (Verweise auf OWASP und ATLAS) |
Die Tabelle sagt, was jeder Eintrag ist; welchen Sie übernehmen, entscheiden die Familien. Ein Gesetz ersetzt keinen Kontrollkatalog, eine Bedrohungsliste keine Verantwortungsmatrix, und kein KI-Sicherheitsframework der Tabelle beantwortet alle vier Fragen allein. Drei Einträge sind Entwürfe oder Konzepte (prEN 18282, Cyber AI Profile, SP-800-53-Overlays); sie gehören in Ihre Planung, nicht in Ihre Prüfgrundlage. Ciscos Integrated AI Security and Safety Framework vom 16. Dezember 2025 fehlt bewusst als eigene Zeile: Mit 19 Angreiferzielen und mehr als 150 Techniken ist es eine Taxonomie und gehört zu den Bedrohungskatalogen, neben ATLAS und OWASP.
Bedrohungskataloge: was Artikel 15 Absatz 5 zu testen verlangt
Artikel 15 Absatz 5 der KI-Verordnung verlangt, dass Hochrisiko-KI-Systeme Versuchen unbefugter Dritter standhalten, ihre Verwendung, Ausgaben oder Leistung durch Ausnutzung von Systemschwachstellen zu verändern. Die Vorschrift nennt die Angriffe, die technische Lösungen verhüten, erkennen, beantworten, beseitigen und kontrollieren sollen: Manipulation des Trainingsdatensatzes („data poisoning“), Manipulation vortrainierter Komponenten („model poisoning“), Eingaben, die das Modell zu Fehlern verleiten sollen („adversarial examples“ oder „model evasion“), Angriffe auf die Vertraulichkeit sowie Modellmängel. Der Bedrohungskatalog ist der Teil des KI-Sicherheitsframeworks, der diese Liste in testbare Techniken übersetzt; die Angriffsformen erklären wir unter adversariale KI-Angriffe.
MITRE ATLAS ist der umfangreichste Katalog. Das Release 2026.10 vom 28. Oktober 2026 zählt 16 Taktiken, 129 Techniken, 92 Subtechniken, 44 Gegenmaßnahmen und 77 Fallstudien. Die ersten agentischen Techniken kamen mit v5.0.0 am 30. September 2025; seit Mitte 2026 erscheint monatlich ein Release.
Die OWASP Top 10 for LLM 2026 vom 3. August 2026 lauten: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Excessive Agency, LLM04 Supply Chain, LLM05 Data and Model Poisoning, LLM06 Unbounded Consumption, LLM07 Misinformation, LLM08 Hidden Context Exposure, LLM09 Vector and Embedding Weaknesses, LLM10 Improper Output Handling. Für Agenten kommt die Agentic Top 10 vom 9. Dezember 2025 hinzu, von ASI01 Agent Goal Hijack bis ASI10 Rogue Agents (mehr unter Sicherheit von KI-Agenten).
NIST AI 100-2 E2025 vom 24. März 2025 liefert zwei Taxonomien: prädiktive KI (Evasion, Poisoning, Privacy) und generative KI (Lieferkette, direkte und indirekte Prompt Injection, Agenten), mit jährlichen Aktualisierungen.
Wir mappen die sechs Angriffsklassen des Artikels einmal auf die drei Kataloge:
| Angriffsklasse nach Art. 15 Abs. 5 | MITRE ATLAS | OWASP | NIST AI 100-2 |
|---|---|---|---|
| Data Poisoning | Poisoning-Techniken | LLM05 | Poisoning |
| Model Poisoning | Lieferketten- und Poisoning-Techniken | LLM04 und LLM05 | Poisoning und Lieferkette |
| Adversarial Examples oder Model Evasion | Evasion-Techniken | LLM01 für Evasion auf Prompt-Ebene | Evasion |
| Angriffe auf die Vertraulichkeit | Exfiltrations- und Inferenztechniken | LLM02 | Privacy |
| Modellmängel | keine Angriffsklasse | LLM07, LLM10 | keine Angriffsklasse |
| Unbefugte Veränderung von Verwendung oder Ausgaben | Techniken zu Agentenkonfiguration und Context Poisoning, AML.T0080 und AML.T0081 | ASI03, ASI06 | Abschnitt zu Agenten |
Modellmängel finden Sie durch Evaluierung, nicht durch Angriffssimulation. Die letzte Zeile ist bei Agenten die wichtigste, denn sie deckt ab, was ein Angreifer über Konfiguration und Kontext erreicht.
Kontrollkataloge: wo das KI-Sicherheitsframework zum Nachweis wird
Ein Kontrollkatalog sagt, was Sie gegen die Bedrohungen tun und wie Sie es belegen; erst hier wird ein KI-Sicherheitsframework prüffähig.
<b>CSA AI Controls Matrix.</b> Die AICM v1.1 vom 22. Juni 2026 umfasst 247 Kontrollziele in 18 Domänen und fünf Säulen, mit Mappings und Gap-Analyse zu ISO/IEC 42001, ISO 27001, NIST AI RMF, NIST AI 600-1, BSI AIC4 und der KI-Verordnung sowie dem Fragebogen AI-CAIQ (320 Fragen). STAR for AI kennt Level 1 (Selbstbewertung) und Level 2 (Zertifizierung auf Basis von ISO 42001 oder 27001). Die AICM passt, wenn Sie bereits die CCM oder ISO 27001 betreiben.
<b>Databricks DASF.</b> Version 3.0 vom 20. März 2026 erweitert das Framework um Agenten: 13 Komponenten, 97 Risiken, 73 Kontrollen, ein Kompendium mit Anwendbarkeitsreitern und Mappings auf acht Referenzen bis zur KI-Verordnung. Plattformgeprägt, am stärksten auf einem Lakehouse.
<b>ISO/IEC 42001 und 27090.</b> In ISO/IEC 42001 tragen diese Maßnahmen aus Anhang A die Sicherheit: A.6.2.2 (Anforderungen und Spezifikation), A.6.2.4 (Verifizierung und Validierung), A.6.2.5 (Bereitstellung), A.6.2.6 (Betrieb und Überwachung), A.6.2.7 (technische Dokumentation), A.6.2.8 (Ereignisprotokolle), A.7.2 bis A.7.6 (Daten), A.8.4 (Kommunikation von Vorfällen) und A.10.3 (Lieferanten). ISO/IEC 27090:2026 sagt einem Auditor nach ISO 27001 oder 42001, was Sicherheit eines KI-Systems bedeutet: erschienen im Oktober 2026, 56 Seiten, aus SC 27, ein Leitfaden, nicht zertifizierbar. ISO/IEC 27091 zum Datenschutz ist seit Juli 2026 im FDIS-Stadium. Das Zusammenspiel mit der KI-Verordnung zeigt unser ISO-42001-Baukasten.
<b>NIST.</b> Die SP-800-53-Overlays (Konzeptpapier vom 14. August 2025, kommentierte Gliederung im Januar 2026, kein Overlay-Entwurf) und das Cyber AI Profile (Vorentwurf vom 16. Dezember 2025, Kommentarfrist bis 30. Januar 2026, im Oktober 2026 kein öffentlicher Entwurf) sind vielversprechend, aber noch keine zitierfähige Baseline. Das NIST AI RMF enthält keine Kontrollen; die Brücke zur klassischen Cybersicherheit schlägt das NIST CSF 2.0.
<b>ETSI, NCSC und CISA, ENISA.</b> ETSI EN 304 223 ist mit 13 Prinzipien, 72 Vorgaben und fünf Phasen die einzige Baseline mit nummerierten Vorgaben; sie stammt aus dem britischen Code of Practice vom 31. Januar 2025. Die Leitlinien von NCSC und CISA (vier Phasen) und der agentische Leitfaden der CISA vom 1. Mai 2026 beschreiben Betriebspraxis. Die drei Ebenen des ENISA FAICP erinnern daran, dass allgemeine Cybersicherheit zuerst gilt.
Unsere Regel für jedes KI-Sicherheitsframework auf Kontrollebene: ein Kontrollkatalog, eine Gap-Analyse gegen das Recht, gepflegt als lebendes Dokument. Wer zwei Kataloge parallel führt, pflegt zwei Wahrheiten.
Architektur und geteilte Verantwortung: SAIF, CoSAI, AWS, Microsoft
Die vierte Familie beantwortet eine Organisationsfrage: Wer besitzt welche Kontrolle, und auf welcher Schicht sitzt sie?
<b>Google SAIF.</b> SAIF 2.0 vom 6. Oktober 2025 gliedert die Absicherung in vier Komponentenbereiche mit 15 Risiken und 24 Kontrollen und formuliert drei Prinzipien für Agenten: klar definierte menschliche Verantwortliche, begrenzte Befugnisse, beobachtbare Aktionen und Planung. Eine Risiko-Selbstbewertung erzeugt einen Bericht. Im September 2025 übergab Google die SAIF-Daten an CoSAI, wo sie als CoSAI Risk Map weitergeführt werden.
<b>CoSAI.</b> Die Coalition for Secure AI (OASIS, gestartet im Juli 2024) veröffentlichte am 16. Juli 2025 Prinzipien für Secure-by-Design-Agentensysteme: menschlich gesteuert und rechenschaftspflichtig, begrenzt und widerstandsfähig, transparent und überprüfbar. Es folgten ein AI Incident Response Framework (Oktober 2025, Playbooks mit ATLAS-Bezug), das AI Shared Responsibility Framework v1.0 (Mai 2026, fünf Schichten, je Komponente eine verantwortliche Partei), MCP Security v2.0 (September 2026) und Zero Trust for AI Systems (16. September 2026).
<b>AWS.</b> Die Generative AI Security Scoping Matrix (Oktober 2023) unterscheidet fünf Scopes, die Agentic AI Security Scoping Matrix (November 2025) vier. Das AWS AI Security Framework vom Mai 2026 ordnet kumulative Kontrollen drei Schichten und drei Phasen zu.
<b>Microsoft.</b> Das Modell geteilter Verantwortung für KI und das Agentenmodell vom August 2026 verteilen Pflichten zwischen Plattform und Kunde; die Agentenrisiken sind auf OWASP und ATLAS gemappt.
Unser Urteil: Diese Dokumente klären, wer welche Kontrolle besitzt und wo sie sitzt. Kein KI-Sicherheitsframework dieser Familie ist auf Artikel 15 gemappt. Nutzen Sie sie, um Kontrollen zuzuweisen, etwa in einer RACI-Matrix mit dem Cloud-Anbieter, nie, um Konformität zu behaupten. Bei Schatten-KI zeigt eine solche Matrix schnell, wo niemand zuständig ist.
Das Recht hinter dem KI-Sicherheitsframework: Artikel 15, Artikel 42 Absatz 3, Cyber Resilience Act
Ein KI-Sicherheitsframework ist nur so viel wert wie seine Rückbindung an das Recht.
<b>KI-Verordnung.</b> Nach Artikel 15 Absatz 1 der Verordnung (EU) 2024/1689 müssen Hochrisiko-KI-Systeme ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit erreichen und über den gesamten Lebenszyklus halten. Absatz 4 verlangt Widerstandsfähigkeit gegen Fehler und Störungen, nennt technische Redundanz und adressiert Rückkopplungsschleifen bei Systemen, die weiterlernen. Nach Artikel 13 Absatz 3 Buchstabe b Ziffer ii nennt die Betriebsanleitung das Maß an Genauigkeit, Robustheit und Cybersicherheit, gegen das getestet wurde. Für GPAI-Modelle mit systemischem Risiko gilt seit dem 2. August 2025 Artikel 55 Absatz 1 Buchstaben a und d: dokumentierte Adversarial Tests und angemessene Cybersicherheit für Modell und physische Infrastruktur.
<b>Vermutungswirkungen.</b> Nach Artikel 42 Absatz 2 begründet ein Zertifikat nach einem Schema des Rechtsakts zur Cybersicherheit (Verordnung (EU) 2019/881) ab dem 2. August 2026 die Konformitätsvermutung für die Cybersicherheit nach Artikel 15. Der neue Absatz 3, eingefügt durch den digitalen Omnibus zur KI (Verordnung (EU) 2026/1744, in Kraft seit 27. Juli 2026), öffnet mit Artikel 12 Absatz 1 CRA einen zweiten Weg: Ein Hochrisiko-KI-System, das zugleich Produkt mit digitalen Elementen ist, gilt bei der Cybersicherheit als konform mit Artikel 15, wenn es die wesentlichen Anforderungen des CRA erfüllt und die CRA-Konformitätserklärung das geforderte Niveau belegt. Notifizierte Stellen nach der KI-Verordnung dürfen dabei auch die CRA-Anforderungen prüfen (Artikel 12 Absatz 2 CRA). Erwägungsgrund 77 begrenzt den Effekt auf die Cybersicherheit, nicht Robustheit und Genauigkeit.
<b>Fristen.</b> Anhang III gilt ab dem 2. Dezember 2027, Anhang I ab dem 2. August 2028; der CRA verlangt Meldungen ab dem 11. September 2026 und gilt vollständig ab dem 11. Dezember 2027. Den Anwendungsbereich klärt unser Leitfaden zu Hochrisiko-KI-Systemen, das Verfahren die Seite zur Konformitätsbewertung.
<b>Normen.</b> EN 18286 zum Qualitätsmanagementsystem wurde durch den Durchführungsbeschluss (EU) 2026/2274 vom 12. Oktober 2026 im Amtsblatt zitiert, als erste harmonisierte Norm unter der KI-Verordnung. prEN 18282, die Cybersicherheitsspezifikation für KI-Systeme aus JTC 21 WG 5, lag vom 15. Mai bis 14. Juli 2026 zur öffentlichen Umfrage aus; die Frist des Normungsauftrags endet am 28. Februar 2027.
<b>ENISA.</b> Am 7. Juli 2026 legte ENISA ihre Einschätzung zur Cybersicherheit im Zeitalter der Frontier-KI vor, zeitgleich mit dem EU-Aktionsplan zu Cybersicherheit und KI: NIS2, CRA und KI-Verordnung sind für Modelle mit systemischem Risiko zusammen zu lesen. Der Bericht ENISA Threat Landscape 2026 vom 22. September 2026 zählt KI-gestützte Angriffe zu den führenden Bedrohungen.
<b>Vorfälle.</b> Meldepflichtig nach Artikel 73 ist ein Sicherheitsvorfall nur als schwerwiegender Vorfall im Sinne von Artikel 3 Nummer 49. Betreiber überwachen und setzen die Nutzung nach Artikel 26 Absatz 5 aus; mehr unter KI-Vorfallmeldung.
So wählen Sie aus: eine Auswahlregel nach Rolle
Ihre Rolle entscheidet; die rechte Spalte nennt, was ein Prüfer am Ende sehen will.
| Ihre Rolle | Rechtlicher Anker | Bedrohungskatalog | Kontrollkatalog | Nachweis, den ein Prüfer akzeptiert |
|---|---|---|---|---|
| Anbieter eines Hochrisiko-KI-Systems | Art. 9, 11, 13, 15, 43 KI-VO | ATLAS, OWASP, NIST AI 100-2 | ISO/IEC 42001 Anhang A oder CSA AICM; prEN 18282, sobald harmonisiert | Cybersicherheitsteil nach Anhang IV, Test- und Red-Team-Berichte, Kennzahlen in der Betriebsanleitung, EU-Konformitätserklärung |
| Anbieter eines Produkts mit digitalen Elementen | Art. 12 CRA, Art. 42 Abs. 3 KI-VO | dieselben | wesentliche Anforderungen nach Anhang I CRA | CRA-Konformitätserklärung mit Angabe des Niveaus nach Art. 15 |
| Betreiber | Art. 26 und 73 KI-VO | OWASP Agentic Top 10 für Agenten | AI-CAIQ an den Anbieter, Matrix geteilter Verantwortung (CoSAI, AWS oder Microsoft), Überwachung | Anbieterfragebogen, Nachweis zur Betriebsanleitung, Überwachungsprotokoll, Entscheidung über die Aussetzung |
| Anbieter eines GPAI-Modells mit systemischem Risiko | Art. 55 Abs. 1 Buchst. a und d KI-VO | ATLAS, Frontier-Evaluierungen | CoSAI, die ENISA-Einschätzung, der Verhaltenskodex | dokumentierte Adversarial Tests, Cybersicherheitsmaßnahmen für Modell und Infrastruktur |
| Unternehmen, das auf einer Cloud-Plattform baut | Art. 15 oder 26, je nach Rolle | OWASP Top 10 for LLM | Framework der Plattform (SAIF, DASF, AWS, Microsoft) als Umsetzungsebene, AICM für den Konformitätsanspruch | Kontroll-Mapping mit Gap-Analyse |
Drei Regeln gelten für jede Zeile. Erstens: ein Kontrollkatalog, ein Bedrohungskatalog, ein Verantwortungsmodell; mehr erzeugt doppelte Pflege, weniger lässt eine Frage offen. Zweitens: Mappen Sie jeden der drei einmal auf die sechs Angriffsklassen aus Artikel 15 Absatz 5 und führen Sie das Mapping als eigenes Dokument; Fragen nach Ihrem KI-Sicherheitsframework beantworten Sie dann mit einem Verweis. Drittens: Stellen Sie das Mapping unter Änderungskontrolle. Eine neue Framework-Version, ein neues Modell oder ein neuer Agent öffnet es erneut; bei monatlichen ATLAS-Releases heißt das, ein festes Prüfintervall festzulegen. Zugekaufte Systeme gehören zusätzlich in Ihre Lieferanten-Due-Diligence.
Für Unternehmen in Deutschland kommt eine nationale Schicht hinzu. Das BSI liefert eigenes Material: den Kriterienkatalog AIC4 (freiwillig, Erweiterung des C5, ohne Zertifizierungsverfahren), eine Checkliste zur Härtung von LLM-Anwendungen gegen Evasion-Angriffe, die Mindestelemente einer SBOM für KI und den C5:2026, gültig seit April 2026. Das KI-MIG ist seit dem 29. Juli 2026 in Kraft und benennt die Bundesnetzagentur als Marktüberwachungsbehörde. Kann ein KI-System Beschäftigte überwachen, bestimmt der Betriebsrat nach § 87 Absatz 1 Nummer 6 BetrVG mit; planen Sie die Betriebsvereinbarung parallel zum Sicherheitskonzept.
Vom KI-Sicherheitsframework zum Prüfnachweis
Ein Prüfer bewertet kein KI-Sicherheitsframework, sondern Artefakte. Diese sieben tragen ein Audit nach KI-Verordnung, ISO/IEC 42001 oder ISO 27001:
- <b>Kontroll-Mapping mit Gap-Analyse gegen Artikel 15.</b> Es zeigt je Anforderung die abdeckende Kontrolle und die offene Lücke. AICM und DASF liefern ein solches Mapping mit; Sie passen es an, statt es neu zu schreiben.
- <b>Threat Model je System.</b> Es prüft das System gegen die sechs Klassen aus Artikel 15 Absatz 5 und nennt die ATLAS-Release und OWASP-Version, gegen die es geschrieben wurde.
- <b>Berichte zu Adversarial Tests und Red Teaming.</b> Datiert, mit Umfang und Befunden, nach jeder wesentlichen Änderung wiederholt. Das Vorgehen beschreibt unser Leitfaden zum KI-Red-Teaming.
- <b>Cybersicherheitsteil der Dokumentation nach Anhang IV und Kennzahlen in der Betriebsanleitung.</b> Die Werte nach Artikel 13 müssen sich in den Testberichten wiederfinden.
- <b>Anbieterfragebogen und Aufteilung der Verantwortung.</b> Der ausgefüllte AI-CAIQ und Ihre Matrix nach CoSAI, AWS oder Microsoft zeigen, wer welche Kontrolle betreibt.
- <b>Incident-Playbooks und Entscheidungsprotokoll nach Artikel 73.</b> Die Playbooks beschreiben die Reaktion, das Protokoll, warum gemeldet wurde oder nicht. Gerade die Nichtmeldung braucht eine dokumentierte Begründung.
- <b>SAIF- oder DASF-Risikobericht als Arbeitspapier.</b> Er hilft bei der Priorisierung und gehört in die Akte, nie als Konformitätsbehauptung. Diese trägt das Mapping aus Punkt 1.
Diese Artefakte gehören in eine Governance-Plattform, nicht in verstreute Ordner. Die Reihenfolge ist fest: zuerst das KI-Register mit allen Systemen und Rollen, dann ein Kontrollkatalog je System, dann Nachweise mit Datum und Verantwortlichem. Ein Compliance-Monitoring für KI-Systeme zeigt, welche Nachweise ablaufen und welche Mappings eine neue Version wieder geöffnet hat. So bleibt das KI-Sicherheitsframework ein gepflegter Zustand statt eines einmaligen Projekts.
Häufige Fragen
<b>Was ist ein KI-Sicherheitsframework?</b>
Ein KI-Sicherheitsframework ist ein benannter, versionierter Satz von Bedrohungen, Kontrollen oder Verantwortlichkeiten, an dem ein Dritter die Absicherung Ihres KI-Systems messen kann. Wir unterscheiden vier Familien: Das Recht sagt, was Sie beweisen müssen, Bedrohungskataloge wie MITRE ATLAS, was Sie testen, Kontrollkataloge wie CSA AICM oder ISO/IEC 42001 Anhang A, was Sie belegen, und Architekturleitfäden wie SAIF oder CoSAI, wer was verantwortet. Ein vollständiges Setup nimmt aus jeder Familie einen Vertreter.
<b>Welches KI-Sicherheitsframework verlangt die KI-Verordnung?</b>
Keines namentlich. Artikel 15 verlangt ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit und nennt in Absatz 5 die Angriffe, denen ein Hochrisiko-System standhalten muss. Für die Cybersicherheit ist prEN 18282 geschrieben, eine Vermutungswirkung entsteht aber erst mit der Zitierung im Amtsblatt. Bis dahin tragen ISO/IEC 42001 Anhang A oder die CSA AICM mit Gap-Analyse. Für Produkte mit digitalen Elementen öffnet Artikel 42 Absatz 3 den Weg über den Cyber Resilience Act.
<b>Ist ISO/IEC 27090 eine zertifizierbare Norm?</b>
Nein. ISO/IEC 27090:2026 aus SC 27, erschienen im Oktober 2026, ist ein Leitfaden mit 56 Seiten zu Bedrohungen und Kompromittierungen von KI-Systemen. Zertifizieren lassen Sie ein Managementsystem nach ISO/IEC 27001 oder 42001. Dort wirkt ISO/IEC 27090 indirekt: Die Norm sagt dem Auditor, was Sicherheit eines KI-Systems bedeutet, und Ihre Maßnahmen werden daran gemessen. Gleichen Sie Ihre Erklärung zur Anwendbarkeit vor dem nächsten Überwachungsaudit gegen die Norm ab.
<b>NIST AI RMF oder NIST Cyber AI Profile: Welches ist das Sicherheitsframework?</b>
Keines von beiden ist heute ein vollständiges Sicherheitsframework. Das NIST AI RMF 1.0 (Januar 2023), ergänzt durch NIST AI 600-1 (Juli 2024), ist ein Risikoframework mit vier Funktionen und dem Merkmal „secure and resilient“, aber ohne Kontrollen. Das Cyber AI Profile baut auf CSF 2.0 auf (Secure, Defend, Thwart), liegt aber erst als Vorentwurf vom 16. Dezember 2025 vor. Kontrollen liefern bis auf Weiteres CSA AICM oder DASF, beide auf das AI RMF gemappt.
<b>Brauchen Sie ein Framework, wenn Ihr Anbieter das Modell betreibt?</b>
Ja. Als Betreiber tragen Sie eigene Pflichten aus den Artikeln 26 und 73: Nutzung gemäß Betriebsanleitung, Überwachung, Aussetzung bei Risiken, Information bei schwerwiegenden Vorfällen. Der Anbieter verantwortet die Sicherheit des Modells, Sie verantworten Konfiguration, Zugriffe, Daten und Agentenrechte. Ein Verantwortungsmodell von CoSAI, AWS oder Microsoft zieht die Grenze, der AI-CAIQ des Anbieters belegt seine Seite, und die OWASP Agentic Top 10 benennt die Bedrohungen auf Ihrer Seite.
<b>Was unterscheidet ein Sicherheitsframework von AI Security Posture Management?</b>
Ein KI-Sicherheitsframework ist ein Maßstab: Es legt fest, welche Bedrohungen Sie betrachten, welche Kontrollen Sie umsetzen und wer sie verantwortet. AI Security Posture Management ist eine Werkzeugkategorie, die Modelle, Endpunkte, Datenflüsse und Fehlkonfigurationen findet und laufend bewertet. Ein solches Werkzeug liefert Nachweise für einzelne Kontrollen, ersetzt aber weder das Kontroll-Mapping noch die Gap-Analyse gegen Artikel 15. Prüfer akzeptieren seine Ausgaben als Belege, nicht als Rahmen.
Fazit
Die Wahl eines KI-Sicherheitsframeworks ist keine Produktentscheidung, sondern eine Arbeitsteilung. Das Recht entscheidet, was Sie beweisen müssen: Artikel 15, Artikel 55 für Modelle mit systemischem Risiko, der Cyber Resilience Act für Produkte mit digitalen Elementen. Der Bedrohungskatalog entscheidet, was Sie testen, der Kontrollkatalog, was Sie zeigen, das Verantwortungsmodell, wer es tut. Seit Oktober 2026 liegen mit ISO/IEC 27090 und EN 18286 die ersten belastbaren Bausteine vor, und prEN 18282 hat die öffentliche Umfrage hinter sich. Unsere Empfehlung: je Familie ein Vertreter, einmal auf die sechs Angriffsklassen gemappt und in Ihrer KI-Governance verankert. Beginnen Sie mit einem System, seinem Registereintrag und seinem Nachweisordner; jedes weitere System folgt demselben Muster.