Symbolische Darstellung; KI-generiert.
Der neue A5-Rahmen des BSI soll die Vertrauenswürdigkeit von KI-Systemen systematisch prüfbar machen. Die Analyse zeigt, wie A5 AI Act, Cybersecurity und Assurance miteinander verbindet, welche Rolle maschinenlesbare Kontrollen spielen – und warum Nachweisfähigkeit für Unternehmen und Sicherheitsfachkräfte an Bedeutung gewinnt.
Mit der AI-Audit and Assurance Assessment Architecture (A5) entwickelt das Bundesamt für Sicherheit in der Informationstechnik (BSI) einen Prüfrahmen für KI-Systeme. Der im Juli 2026 veröffentlichte Community Draft soll Akteure entlang der KI-Wertschöpfungskette dabei unterstützen, die Vertrauenswürdigkeit von KI-Systemen systematisch und nachvollziehbar zu bewerten. Dazu verbindet A5 Prüfkriterien mit einer Prüfungsmethodik und stellt die Kriterien zusätzlich maschinenlesbar im OSCAL-Format bereit.
Auf den ersten Blick könnte A5 damit wie ein weiterer Baustein in einer ohnehin komplexen Landschaft aus AI Act, Cyber Resilience Act (CRA), ISO-Normen und bestehenden Sicherheitsstandards erscheinen. Tatsächlich adressiert der Ansatz jedoch ein grundlegenderes Problem: Regulierung kann Anforderungen an sichere und vertrauenswürdige KI formulieren. Für Unternehmen, Prüfer und Behörden stellt sich anschließend die schwierigere praktische Frage, wie sich nachweisen lässt, dass diese Anforderungen bei einem konkreten KI-System tatsächlich erfüllt werden. Genau an dieser Schnittstelle zwischen Regulierung, technischer Sicherheit und Prüfung liegt die mögliche Bedeutung von A5.
1. Warum Europa bei KI nicht bei allgemeinen Prinzipien stehen bleiben kann
Die europäische KI-Regulierung versucht zwei Ziele miteinander zu verbinden: die wirtschaftliche und gesellschaftliche Nutzung künstlicher Intelligenz zu ermöglichen und gleichzeitig Risiken für Sicherheit, Gesundheit und Grundrechte zu begrenzen. Der AI Act verfolgt dafür einen risikobasierten Ansatz. Nicht jedes KI-System unterliegt denselben Anforderungen; Umfang und Art der regulatorischen Pflichten hängen wesentlich vom jeweiligen Einsatz und seiner Risikokategorie ab.
Für Hochrisiko-KI verlangt die Verordnung unter anderem Risikomanagement, Anforderungen an Daten und Daten-Governance, technische Dokumentation, Protokollierung, Transparenz gegenüber Betreibern, menschliche Aufsicht sowie angemessene Genauigkeit, Robustheit und Cybersicherheit. Der AI Act beschränkt Cybersicherheit dabei ausdrücklich nicht auf klassische Angriffe gegen Server, Benutzerkonten oder Netzwerke. Artikel 15 nennt auch KI-spezifische Angriffsformen wie Data Poisoning, Model Poisoning, adversariale Eingaben beziehungsweise Model Evasion sowie Angriffe auf Vertraulichkeit oder Modellschwächen.
Auch die menschliche Aufsicht ist mehr als eine formale Vorgabe. Bei Hochrisiko-Systemen sollen die zuständigen Personen die Fähigkeiten und Grenzen des Systems verstehen, seine Ergebnisse angemessen interpretieren und bei Bedarf eingreifen oder den Betrieb unterbrechen können. Der AI Act berücksichtigt dabei ausdrücklich das Risiko, dass Menschen den Ergebnissen eines automatisierten Systems zu stark vertrauen – den sogenannten Automation Bias .
Damit entsteht eine Lücke zwischen rechtlicher Anforderung und technischer Umsetzung. Eine Vorschrift kann verlangen, dass ein System robust oder ausreichend gegen Cyberangriffe geschützt sein muss. Sie beantwortet damit noch nicht vollständig, wie diese Eigenschaften bei einem konkreten System gemessen, geprüft und gegenüber Dritten belastbar nachgewiesen werden sollen. Dass Messmethoden selbst eine wichtige Rolle spielen, zeigt Artikel 15: Die Europäische Kommission soll gemeinsam mit relevanten Akteuren die Entwicklung von Benchmarks und Messmethoden für Genauigkeit und Robustheit fördern.
Die Herausforderung liegt deshalb nicht nur darin, Anforderungen an vertrauenswürdige KI zu definieren, sondern auch geeignete Kriterien, Prüfverfahren und Nachweise zu entwickeln, mit denen ihre Umsetzung belastbar beurteilt werden kann.
2. Von vertrauenswürdiger zu prüfbarer KI: Warum das BSI A5 entwickelt
Die Arbeiten des BSI zur Prüfbarkeit von KI-Systemen reichen mehrere Jahre vor A5 zurück. Gemeinsam mit dem TÜV-Verband und dem Fraunhofer Heinrich-Hertz-Institut (HHI) organisierte das BSI im Oktober 2020 den Workshop „Auditing AI Systems: From Basics to Applications“. Die Ergebnisse flossen in das 2021 veröffentlichte Whitepaper Towards Auditable AI Systems: Current Status and Future Directions ein. 2022 folgte mit Towards Auditable AI Systems: From Principles to Practice eine weitere gemeinsame Untersuchung. Ziel dieser Arbeiten war es, den Stand der Prüfbarkeit von IT-Sicherheit und weiteren Eigenschaften von KI-Systemen zu erfassen und Bereiche zu identifizieren, in denen geeignete Prüfverfahren noch fehlten.
Hinter dieser Entwicklung steht eine technische Besonderheit. Bei klassischen Softwaresystemen kann sich eine Bewertung stark auf Programmcode, Konfiguration, Infrastruktur und deterministisch definierte Funktionen konzentrieren. Bei KI-Systemen können zusätzlich Trainings- und Testdaten, Modellarchitektur, Modellversion, Eingabedaten und der konkrete Einsatzkontext die Aussagekraft einer Prüfung beeinflussen. Das Modell allein ist deshalb häufig nicht der vollständige Prüfgegenstand.
A5 setzt hier mit einer modularen und erweiterbaren Prüfarchitektur an. Nach Angaben des BSI richtet sie sich an Akteure entlang der KI-Wertschöpfungskette – von Anbietern und Betreibern bis zu Personen, die mit Entwicklung, Betrieb oder Aufsicht befasst sind. Der Community Draft umfasst ein horizontales Trustworthiness-Basismodul, eine Prüfmethodik und ein Betriebsmodul für Cloud-Infrastruktur. Die drei Dokumente liegen in Version 0.9 mit Stand vom 30. Juni 2026 vor.
Bei der Prüfungsmethodik orientiert sich das BSI am Cloud Computing Compliance Criteria Catalogue (C5), dessen Prüfungslogik wiederum auf dem internationalen Assurance-Standard ISAE 3000 aufbaut. Dadurch lassen sich zwei Ebenen unterscheiden: Kriterien bestimmen, was bewertet werden soll; die Prüfungsmethodik beschreibt, wie geeignete Nachweise erhoben und daraus ein begründetes Prüfungsurteil abgeleitet werden.
Assurance bedeutet dabei keine Garantie, dass ein KI-System fehlerfrei oder unangreifbar ist. Gemeint ist ein strukturierter Prüfprozess, bei dem anhand definierter Kriterien und geeigneter Evidenz eine begründete Beurteilung ermöglicht wird. Ihre Aussagekraft bleibt an den Prüfgegenstand, die verwendeten Kriterien und die Qualität der Nachweise gebunden.
Das ist bei KI besonders relevant. Eine vorhandene Richtlinie beweist noch nicht, dass eine Sicherheitskontrolle im Betrieb wirksam funktioniert. Ebenso zeigt ein erfolgreicher technischer Test nicht automatisch, dass dieselbe Eigenschaft über den gesamten Lebenszyklus eines sich verändernden Systems erhalten bleibt. Je nach Prüfgegenstand können deshalb unterschiedliche Nachweise erforderlich sein, etwa technische Tests, Dokumentation, Protokolle, Prozessnachweise, Datenanalysen oder Beobachtungen des laufenden Betriebs.
A5 ist damit weder ein deutscher Ersatz für den AI Act noch ein zweites KI-Gesetz. Der AI Act legt rechtliche Anforderungen fest; A5 soll einen Rahmen bereitstellen, in dem Eigenschaften eines KI-Systems strukturiert bewertet und ihre Umsetzung nachvollziehbar belegt werden können.
3. OSCAL: Von Dokumenten zu maschinenlesbaren Nachweisen
Eine der technisch interessantesten Entscheidungen des BSI betrifft nicht die einzelnen Prüfkriterien, sondern deren Bereitstellung. A5 veröffentlicht die Kriterien zusätzlich im Open Security Controls Assessment Language (OSCAL)-Format. OSCAL ist eine vom US-amerikanischen National Institute of Standards and Technology (NIST) entwickelte Initiative zur maschinenlesbaren Darstellung von Sicherheitskontrollen und zugehörigen Informationen. Sie unterstützt strukturierte Formate wie XML, JSON und YAML und umfasst neben Kontrollkatalogen auch Modelle für Implementierungen, Assessment-Pläne und Assessment-Ergebnisse.
Der Unterschied zu einem klassischen PDF ist praktisch relevant. Anforderungen in Dokumenten müssen von Menschen gelesen, interpretiert und häufig manuell in GRC-Systeme, Kontrollmatrizen oder Audit-Werkzeuge übertragen werden. Maschinenlesbare Kontrollen können dagegen eindeutig referenziert, importiert, miteinander verknüpft und von Software weiterverarbeitet werden.
Für A5 eröffnet dies die Möglichkeit, Prüfkriterien stärker in bestehende Compliance- und Sicherheitsprozesse einzubinden. Interne Kontrollen können bestimmten A5-Kriterien zugeordnet und mit Nachweisen oder Prüfungsergebnissen verbunden werden. Werden weitere Kontrollkataloge strukturiert verarbeitet, lassen sich Überschneidungen erkennen und vorhandene Informationen möglicherweise wiederverwenden.
Der mögliche Nutzen liegt deshalb weniger im Dateiformat selbst als in einer stärker datenbasierten Nachweisführung. Beziehungen zwischen Anforderungen, Kontrollen, Systemen und Prüfungsergebnissen können maschinenlesbar abgebildet werden. Das OSCAL Assessment Results Model unterstützt dabei sowohl zeitpunktbezogene Prüfungen als auch Informationen für eine kontinuierliche Überwachung.
Gerade bei KI-Systemen kann diese Nachvollziehbarkeit relevant sein. Ändern sich Modelle, Datenquellen, Komponenten oder Betriebsbedingungen, stellt sich die Frage, ob vorhandene Nachweise weiterhin aussagekräftig sind oder Bewertungen wiederholt werden müssen. Strukturierte Beziehungen zwischen Prüfgegenstand, Kontrolle und Evidenz können helfen, solche Abhängigkeiten sichtbar zu machen. Ob daraus tatsächlich geringerer administrativer Aufwand entsteht, hängt jedoch von der konkreten Implementierung, den eingesetzten Werkzeugen und der Qualität der zugrunde liegenden Daten ab.
Die Grenzen dieser Automatisierung müssen klar bleiben. Maschinenlesbare Compliance ist nicht dasselbe wie automatisierte Sicherheit. OSCAL kann Informationen strukturieren und deren Verarbeitung erleichtern. Es entscheidet nicht selbst, ob ein Datensatz geeignet ist, ein Modell ausreichend robust reagiert oder menschliche Aufsicht tatsächlich wirksam funktioniert.
Der Fortschritt besteht deshalb nicht darin, menschliche Prüfung zu ersetzen, sondern Anforderungen, Kontrollen und Nachweise so zu strukturieren, dass ihre Beziehungen konsistenter erfasst und technisch weiterverarbeitet werden können.
4. A5 im regulatorischen Gefüge: AI Act, CRA und bestehende Standards
Die Bedeutung von A5 lässt sich nur verstehen, wenn unterschiedliche Ebenen klar voneinander getrennt werden. Der AI Act ist eine unmittelbar geltende EU-Verordnung und bestimmt unter anderem, welche Pflichten für bestimmte Akteure und KI-Systeme gelten. Bei Hochrisiko-KI gehören dazu beispielsweise Qualitätsmanagement, technische Dokumentation, Protokollierung und – abhängig von der jeweiligen Konstellation – Konformitätsbewertungsverfahren.
Für die technische Konkretisierung sieht das europäische System insbesondere harmonisierte Normen vor. Werden deren Fundstellen im Amtsblatt der Europäischen Union veröffentlicht und decken sie die entsprechenden Anforderungen ab, können sie unter den im AI Act festgelegten Voraussetzungen eine Konformitätsvermutung begründen. Der AI Act regelt außerdem gemeinsame Spezifikationen und Konformitätsbewertungsverfahren (Art. 40–43 AI Act).
Daraus folgt eine wichtige Grenze für A5: Ein Prüfrahmen wird nicht allein dadurch zu einer harmonisierten europäischen Norm oder zu einem gesetzlich vorgeschriebenen Konformitätsbewertungsverfahren. Ein A5-Assessment kann daher nicht automatisch mit einer rechtlich erforderlichen Konformitätsbewertung nach dem AI Act gleichgesetzt werden. Welche regulatorische Bedeutung A5 künftig erhält, hängt davon ab, wie der Rahmen weiterentwickelt und mit europäischen Normungs- und Konformitätsstrukturen verbunden wird.
Der Cyber Resilience Act ergänzt dieses Gefüge auf Produktebene. Besonders relevant ist Artikel 12 CRA für Produkte mit digitalen Elementen, die zugleich als "Hochrisiko-KI-Systeme" im Sinne des AI Act eingestuft werden. Erfüllt ein solches Produkt die dort festgelegten Bedingungen, gilt es hinsichtlich der erfassten Cybersicherheitsanforderungen zugleich als konform mit den entsprechenden Anforderungen aus Artikel 15 des AI Act.
Für Unternehmen ist diese Verknüpfung praktisch relevant. Sie zeigt, dass AI Governance, Produktsicherheit und Cybersecurity regulatorisch nicht vollständig getrennt betrachtet werden können. Wo Anforderungen mehrere Regelwerke berühren, gewinnt die Fähigkeit an Bedeutung, Kontrollen und Nachweise so zu strukturieren, dass vermeidbare Doppelarbeit reduziert werden kann.
Von dieser gesetzlichen Ebene sind Managementsystemstandards zu unterscheiden. ISO/IEC 27001:2022 definiert Anforderungen an ein Informationssicherheitsmanagementsystem (ISMS), ISO/IEC 42001:2023 an ein AI Management System (AIMS).
A5 setzt auf einer anderen Ebene an. Während solche Standards vor allem regeln, wie eine Organisation Risiken, Verantwortlichkeiten und Prozesse systematisch steuert, richtet eine Prüfarchitektur wie A5 den Blick stärker darauf, wie definierte Eigenschaften eines Prüfgegenstands anhand von Kriterien und Evidenz bewertet werden können. Beide Perspektiven können sich ergänzen, ersetzen einander aber nicht.
Daraus ergibt sich ein wichtiger analytischer Befund: Methodisch ist der Vergleich A5–C5 präziser als der Vergleich A5–ISO/IEC 27001. Das BSI orientiert die A5-Prüfmethodik ausdrücklich an C5, während ISO/IEC 27001 und ISO/IEC 42001 organisatorische Managementstandards sind. Für die organisatorische Steuerung ist daher ISO/IEC 42001 die nähere KI-Parallele zu ISO/IEC 27001; für die Kriterien- und Assurance-Logik ist C5 die sachnähere Vergleichsgröße für A5.
Ob A5 tatsächlich eine ähnliche praktische Stellung für KI erreichen wird wie C5 für Cloud-Dienste, bleibt offen.
5. Zwischen Nachweisfähigkeit und Scheinsicherheit: Was A5 für Unternehmen bedeutet
Aus dieser Einordnung folgt zunächst, was Unternehmen nicht aus A5 ableiten sollten. Der Community Draft ist kein Gesetz, und seine Nichtanwendung stellt keinen eigenständigen Verstoß gegen den AI Act dar. Rechtliche Verpflichtungen ergeben sich aus den einschlägigen Rechtsakten sowie aus der Rolle des Unternehmens, der Art des KI-Systems und dessen regulatorischer Einordnung. A5 kann ein Instrument zur strukturierten Prüfung sein; es ist nicht selbst die Rechtsgrundlage dieser Pflichten.
Das praktische Risiko liegt daher weniger darin, A5 nicht anzuwenden, als darin, die eigene Nachweisfähigkeit zu spät aufzubauen. Ein Unternehmen kann Sicherheitsmaßnahmen technisch umgesetzt haben und dennoch Schwierigkeiten bekommen, wenn später nicht mehr nachvollziehbar ist, welche Modellversion geprüft wurde, welche Daten und Betriebsbedingungen relevant waren, welche Tests durchgeführt wurden oder wer eine wesentliche Änderung genehmigt hat.
Diese Problematik wird durch den Lebenszyklus von KI-Systemen verstärkt. Modelle, Datenbestände, externe Komponenten und Einsatzkontexte können sich verändern. Ein früherer Prüfnachweis muss deshalb nicht automatisch dieselbe Aussage für eine spätere Systemversion ermöglichen. Der AI Act berücksichtigt diesen dynamischen Charakter unter anderem durch Artikel 72, der für Hochrisiko-KI ein dokumentiertes Post-Market-Monitoring-System zur systematischen Erfassung und Analyse relevanter Informationen über den Lebenszyklus vorsieht.
Daraus lässt sich ein praktischer Grundsatz ableiten: Prüfbarkeit sollte möglichst während Entwicklung, Beschaffung und Betrieb entstehen und nicht erst unmittelbar vor einem Audit. Werden Anforderungen früh mit Verantwortlichkeiten, Kontrollen und geeigneten Nachweisen verbunden, lässt sich leichter erkennen, wo Evidenz fehlt und welche Veränderungen eine erneute Bewertung erforderlich machen.
Das betrifft auch die Lieferkette. Viele Organisationen entwickeln KI-Systeme nicht vollständig selbst. Modelle, Cloud-Infrastruktur, Softwarekomponenten und Datenquellen können von verschiedenen Anbietern stammen. Die Beurteilung des Gesamtsystems kann deshalb von Informationen abhängen, über die das einsetzende Unternehmen selbst nicht unmittelbar verfügt.
Langfristig könnte dies auch Beschaffungsentscheidungen beeinflussen. Neben Funktion, Preis und Leistungsfähigkeit könnte bei regulierten oder sicherheitskritischen Anwendungen stärker berücksichtigt werden, welche Informationen ein Anbieter über Sicherheitsmaßnahmen, Systemänderungen und relevante Nachweise bereitstellen kann. Dies ist keine allgemeingültige Beschaffungsanforderung, sondern eine plausible Folge zunehmender Anforderungen an die Nachweisbarkeit von KI-Systemen.
Eine strukturierte Prüfarchitektur kann hierbei Vorteile bieten. Anforderungen lassen sich früher mit internen Kontrollen verbinden, Verantwortlichkeiten transparenter abbilden und vorhandene Nachweise gegebenenfalls systematischer wiederverwenden. Dies kann interne Governance ebenso unterstützen wie spätere Prüfungen, Kundenanfragen oder Due-Diligence-Prozesse.
Die Anwendung eines umfassenden Prüfrahmens erzeugt allerdings selbst Aufwand. Kontrollen müssen implementiert, Evidenzen gepflegt und Bewertungen gegebenenfalls wiederholt werden, wenn sich relevante Eigenschaften des Systems ändern. Insbesondere für kleinere Unternehmen können dadurch zusätzliche Kosten entstehen. Hinzu kommt das Risiko, mehrere Frameworks parallel zu pflegen, ohne ihre Überschneidungen sinnvoll abzubilden.
Noch problematischer wäre Checkbox-Compliance: die Annahme, dass ein formal gut dokumentiertes System automatisch sicher sei. Eine positive Prüfung gilt für einen definierten Prüfgegenstand, bestimmte Kriterien und die zugrunde liegende Evidenz. Sie beweist weder Fehlerfreiheit noch Schutz gegen alle zukünftigen Angriffe. Compliance und Sicherheit überschneiden sich, sind aber nicht identisch. Der Nutzen von A5 hängt deshalb wesentlich davon ab, ob der Rahmen technische Sicherheit, Governance und Nachweisführung tatsächlich miteinander verbindet oder lediglich als zusätzlicher Kontrollkatalog behandelt wird.
Für die Einordnung von A5 ist schließlich sein aktueller Entwicklungsstand relevant. Der am 6. Juli 2026 vom BSI veröffentlichte A5 Community Draft war zunächst bis zum 31. August 2026 zur öffentlichen Kommentierung vorgesehen. Die veröffentlichten A5-Dokumente liegen in Version 0.9 mit Stand vom 30. Juni 2026 vor. Zum Zeitpunkt dieser Analyse am 2. September 2026 führte das BSI A5 weiterhin als Community Draft; eine aktualisierte Finalfassung war noch nicht veröffentlicht. Für Unternehmen spricht dies gegen eine vorschnelle Festlegung interner Prozesse auf jedes Detail der aktuellen Fassung. Gleichzeitig wäre es kurzsichtig, die weitere Entwicklung abzuwarten, ohne sich bereits mit der grundlegenden Architektur von A5 und der eigenen Prüfbereitschaft auseinanderzusetzen.
6. Was Unternehmen und Fachkräfte beherrschen müssen
In der Zusammenschau der technischen, regulatorischen und prüfmethodischen Anforderungen spricht vieles dafür, AI Assurance als Schnittstellenaufgabe zu behandeln. Das ist keine formale Vorgabe von A5 oder des AI Act, sondern eine analytische Schlussfolgerung aus der Struktur des Prüfgegenstands: Sobald belastbare Aussagen über ein KI-System erforderlich sind, treffen technische Sicherheit, Daten- und Modellverständnis, Risikomanagement, Governance und Audit aufeinander.
Unternehmen benötigen deshalb nicht zwangsläufig eine neue Abteilung mit der Bezeichnung „AI Assurance“. Sie benötigen zunächst eindeutige Verantwortlichkeiten über den Lebenszyklus ihrer KI-Systeme. Es muss geklärt sein, wer über einen Einsatz entscheidet, Risiken bewertet, technische Änderungen freigibt, den Betrieb überwacht und beurteilt, ob Veränderungen eine erneute Prüfung erforderlich machen.
Diese organisatorische Aufgabe wird durch den AI Act zusätzlich unterstrichen. Artikel 4 verlangt von Anbietern und Betreibern, Maßnahmen zur Entwicklung eines ausreichenden Maßes an KI-Kompetenz bei ihrem Personal und anderen Personen zu treffen, die in ihrem Auftrag mit dem Betrieb und der Nutzung von KI-Systemen befasst sind. Dabei sind unter anderem technische Kenntnisse, Erfahrung, Ausbildung und der jeweilige Nutzungskontext relevant.
KI-Kompetenz ist deshalb nicht mit der Fähigkeit gleichzusetzen, generative KI zu bedienen oder gute Prompts zu formulieren. Das erforderliche Wissen hängt von der jeweiligen Aufgabe ab. Wer ein KI-System nutzt, benötigt ein anderes Verständnis als jemand, der seine Sicherheitsarchitektur analysiert, Risiken bewertet oder Prüfnachweise beurteilt.
Für Cybersecurity-Fachkräfte erweitert sich damit der Prüfgegenstand. Sie müssen keine großen KI-Modelle selbst entwickeln können, sollten aber verstehen, welche Datenflüsse, Identitäten, Berechtigungen, Schnittstellen, externen Komponenten und Infrastrukturabhängigkeiten für die Sicherheit eines KI-Systems relevant sind und welche KI-spezifischen Angriffs- und Fehlermöglichkeiten hinzukommen. Gleichzeitig müssen sie einschätzen können, wie technische Kontrollen und Veränderungen in Governance, Risikomanagement und Prüfung einzuordnen sind. Klassische Anwendungssicherheit, Zugriffssteuerung und Infrastrukturabsicherung verlieren dadurch nicht an Bedeutung, sondern werden um zusätzliche KI-spezifische Fragestellungen erweitert.
Technisches Verständnis allein genügt für eine Prüfung jedoch nicht. Entscheidend ist auch, welche Aussage durch einen Nachweis tatsächlich getragen wird. Eine umfangreiche Logdatei ist beispielsweise nicht automatisch geeignete Evidenz. Relevant ist, welche Anforderung sie belegen soll, ob die notwendigen Ereignisse erfasst werden und ob sich die Informationen zuverlässig dem untersuchten System und Zeitraum zuordnen lassen.
Hier entsteht die unmittelbare Verbindung zu GRC und Audit. Regulatorische oder normative Anforderungen müssen in überprüfbare technische und organisatorische Kontrollen übersetzt werden. Umgekehrt muss sich nachvollziehen lassen, welche Risiken, Kontrollen und bestehenden Nachweise von einer technischen Veränderung betroffen sind.
Für einzelne Fachkräfte bedeutet dies nicht, gleichzeitig Jurist, Auditor, Security Engineer und Machine-Learning-Entwickler werden zu müssen. Realistischer ist eine fundierte Expertise in einem Kerngebiet, ergänzt durch ausreichendes Verständnis angrenzender Disziplinen. Ein GRC-Spezialist muss beispielsweise kein Modell trainieren können, sollte aber nachvollziehen können, welche technischen Sachverhalte hinter Begriffen wie Datenintegrität, Robustheit oder Model Monitoring stehen.
Auch für Auditoren steigen damit die fachlichen Anforderungen. KI-Systeme können aufgrund ihrer Datenabhängigkeit, probabilistischen Ergebnisse und Veränderungen während des Lebenszyklus andere Prüfprobleme erzeugen als viele traditionelle IT-Systeme. Eine Bewertung kann deshalb nicht ausschließlich auf der Existenz von Richtlinien und Prozessbeschreibungen beruhen. Je nach Prüfgegenstand ist technisches Fachwissen erforderlich; zugleich darf aus einem erfolgreichen Einzeltest keine weitergehende Aussage abgeleitet werden, als die vorhandene Evidenz tatsächlich trägt.
Daraus entwickelt sich ein Tätigkeitsfeld an der Schnittstelle von Cybersecurity, AI Governance, GRC und Audit. Ob sich dafür dauerhaft Berufsbezeichnungen wie AI Security Auditor oder AI Assurance Specialist etablieren, lässt sich derzeit nicht belastbar vorhersagen. Deutlich erkennbar ist jedoch der fachliche Bedarf, technische Eigenschaften von KI-Systemen in überprüfbare Risiko- und Kontrollaussagen übersetzen zu können.
7. Schluss: Wird A5 das „C5 für KI“?
A5 erscheint zu einem Zeitpunkt, an dem sich die europäische KI-Regulierung zunehmend von allgemeinen Anforderungen zur praktischen Umsetzung bewegt. Der AI Act beschreibt, welche Eigenschaften und Prozesse bei bestimmten KI-Systemen erforderlich sind. Die anschließende Herausforderung besteht darin, diese Anforderungen in Kriterien, Kontrollen und belastbare Nachweise zu übersetzen.
Hier liegt die mögliche Bedeutung von A5. Die Architektur verbindet die langjährigen Arbeiten des BSI zur Prüfbarkeit von KI mit einer modularen Kriterienstruktur, einer an C5 orientierten Prüfungsmethodik und maschinenlesbaren OSCAL-Daten. Sie versucht damit, regulatorische, organisatorische und technische Perspektiven in einen prüfbaren Zusammenhang zu bringen.
Der Vergleich mit C5 ist deshalb methodisch begründbar, bleibt hinsichtlich seiner zukünftigen Bedeutung aber eine Zukunftshypothese. A5 liegt zum Zeitpunkt dieser Analyse als Community Draft vor. Seine spätere Stellung wird davon abhängen, wie sich die Kriterien in realen Prüfungen bewähren, wie der Rahmen weiterentwickelt wird, wie er mit europäischen Normungs- und Konformitätsstrukturen zusammenspielt und ob seine Ergebnisse als belastbarer Nachweis akzeptiert werden.
A5 ersetzt weder den AI Act und den CRA noch Managementsystemstandards wie ISO/IEC 27001 oder ISO/IEC 42001. Ebenso kann eine Prüfung keine absolute Sicherheit garantieren, sondern nur eine begründete Aussage über einen definierten Prüfgegenstand anhand festgelegter Kriterien und verfügbarer Evidenz ermöglichen.
Für Unternehmen liegt der strategische Wert deshalb weniger darin, möglichst früh einen weiteren Compliance-Katalog abzuarbeiten. Wichtiger ist die Fähigkeit, KI-Systeme so zu entwickeln, zu beschaffen und zu betreiben, dass ihre sicherheits- und governancebezogenen Eigenschaften später nachvollziehbar bewertet werden können. Für Fachkräfte entsteht parallel ein Kompetenzfeld, in dem technisches Sicherheitsverständnis mit Governance, Risikomanagement und Prüfung verbunden wird.
Ob A5 tatsächlich zum „C5 für KI“ wird, ist offen. Der grundlegendere Wandel ist jedoch bereits sichtbar: Bei vertrauenswürdiger KI wird künftig nicht allein zählen, welche Eigenschaften ein Anbieter seinem System zuschreibt, sondern welche dieser Eigenschaften sich belastbar nachweisen lassen. A5 ist ein deutscher Versuch, für genau diesen Übergang von Vertrauen zu überprüfbarer Vertrauenswürdigkeit eine technische und methodische Architektur zu schaffen.
Literatur- und Quellenverzeichnis
Alle Onlinequellen wurden zuletzt am 2. September 2026 abgerufen.
Bundesamt für Sicherheit in der Informationstechnik (BSI) (2026a): A5 – Horizontales Trustworthiness Basismodul. Version 0.9, Community Draft, Stand 30. Juni 2026. Bonn: Bundesamt für Sicherheit in der Informationstechnik.
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KI/A5/A5_Horizontales-Trustworthiness-Basismodul.pdf
Bundesamt für Sicherheit in der Informationstechnik (BSI) (2026b): A5 – Prüfmethodik. Version 0.9, Community Draft, Stand 30. Juni 2026. Bonn: Bundesamt für Sicherheit in der Informationstechnik.
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KI/A5/A5-Pruefmethodik.pdf
Bundesamt für Sicherheit in der Informationstechnik (BSI) (2026c): A5 – Betriebsmodul Cloud-Infrastruktur. Version 0.9, Community Draft, Stand 30. Juni 2026. Bonn: Bundesamt für Sicherheit in der Informationstechnik.
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KI/A5/A5_Betriebsmodul-Cloud-Infrastruktur.pdf
Bundesamt für Sicherheit in der Informationstechnik (BSI) (2026d): Prüfkatalog vertrauenswürdige KI-Systeme: BSI veröffentlicht Community Draft des A5. Pressemitteilung, Bonn, 6. Juli 2026.
https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2026/260706_KI_A5-Community-Draft.html
Bundesamt für Sicherheit in der Informationstechnik (BSI) (2020): Cloud Computing Compliance Criteria Catalogue – C5:2020. Bonn: Bundesamt für Sicherheit in der Informationstechnik.
https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/Kriterienkatalog-C5/C5_Archiv/C5_Archiv.html
Bundesamt für Sicherheit in der Informationstechnik (BSI), TÜV-Verband und Fraunhofer Heinrich-Hertz-Institut (HHI) (2021): Towards Auditable AI Systems: Current Status and Future Directions. Whitepaper, Mai 2021.
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/Towards_Auditable_AI_Systems.pdf
Bundesamt für Sicherheit in der Informationstechnik (BSI), TÜV-Verband und Fraunhofer Heinrich-Hertz-Institut (HHI) (2022): Towards Auditable AI Systems: From Principles to Practice. Whitepaper, Mai 2022.
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/Towards_Auditable_AI_Systems_2022.pdf
Europäische Union (2024/2026): Verordnung (EU) 2024/1689 des Europäischen Parlaments und des Rates vom 13. Juni 2024 zur Festlegung harmonisierter Vorschriften für künstliche Intelligenz und zur Änderung mehrerer Rechtsakte der Union (Verordnung über künstliche Intelligenz / Artificial Intelligence Act). ABl. L, 2024/1689, 12. Juli 2024. Für diese Analyse verwendet in der konsolidierten Fassung vom 27. Juli 2026 einschließlich der Änderungen durch Verordnung (EU) 2026/1744.
https://eur-lex.europa.eu/eli/reg/2024/1689
Europäische Union (2024b): Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen und zur Änderung der Verordnungen (EU) Nr. 168/2013 und (EU) 2019/1020 sowie der Richtlinie (EU) 2020/1828 (Cyberresilienz-Verordnung / Cyber Resilience Act). ABl. L, 2024/2847, 20. November 2024. Insbesondere Art. 12.
https://eur-lex.europa.eu/eli/reg/2024/2847/oj/deu
International Auditing and Assurance Standards Board (IAASB) (2013): International Standard on Assurance Engagements (ISAE) 3000 (Revised): Assurance Engagements Other than Audits or Reviews of Historical Financial Information. New York: International Federation of Accountants, veröffentlicht am 9. Dezember 2013.
https://www.iaasb.org/publications/international-standard-assurance-engagements-isae-3000-revised-assurance-engagements-other-audits-or
International Organization for Standardization / International Electrotechnical Commission (ISO/IEC) (2022): ISO/IEC 27001:2022 – Information security, cybersecurity and privacy protection — Information security management systems — Requirements. 3. Auflage, Oktober 2022. Geneva: ISO.
https://www.iso.org/standard/27001
International Organization for Standardization / International Electrotechnical Commission (ISO/IEC) (2023): ISO/IEC 42001:2023 – Information technology — Artificial intelligence — Management system. 1. Auflage, Dezember 2023. Geneva: ISO.
https://www.iso.org/standard/42001
National Institute of Standards and Technology (NIST) (2026): Open Security Controls Assessment Language (OSCAL). Gaithersburg, MD: National Institute of Standards and Technology. Herangezogen wurden insbesondere die OSCAL-Konzeption sowie das Assessment Results Model zur strukturierten Darstellung von Assessment-Ergebnissen und Continuous-Monitoring-Informationen.
https://pages.nist.gov/OSCAL/