6 Aufsichtsbehörden stellen KI-Teams eine Frage, die die meisten Organisationen nicht sauber beantworten können: „Zeigen Sie mir die Nachweise.“ Audit-Anfragen von internen Compliance-Teams, externen Prüfern und Aufsichtsbehörden kommen inzwischen schneller, als Speicher- und Security-Teams reagieren können – nicht weil Kontrollen fehlen, sondern weil die Nachweise nicht konsistent erfasst, aufbewahrt oder geschützt werden. Solide KI-Audit-Frameworks schließen diese Lücke, bevor aus einem Audit eine Feststellung wird. Dieser Leitfaden richtet sich an CISOs und Sicherheitsarchitekten, die für die Audit-Bereitschaft verantwortlich sind. Er erklärt, was KI-Audit-Frameworks sind, warum der regulatorische Druck gerade jetzt so hoch ist, welche Komponenten sie funktionieren lassen und wie Infrastrukturentscheidungen darüber bestimmen, ob Audit-Nachweise einer Prüfung standhalten. Was sind KI-Audit-Frameworks? KI-Audit-Frameworks sind strukturierte Sammlungen von Kontrollen, Dokumentationsanforderungen und Prüfprozessen, mit denen Organisationen ihre Verantwortung für KI-Systeme nachweisen. Sie beantworten, wer ein Modell freigegeben hat, mit welchen Daten es trainiert wurde, wie Entscheidungen protokolliert werden, ob Ergebnisse angefochten werden können und wie sich das System nach einer Kompromittierung wiederherstellen lässt. Der Begriff deckt ein breites Spektrum ab. Am einen Ende stehen schlanke interne Governance-Checklisten. Am anderen Ende stehen formale Compliance-Programme, die an regulatorischen Anforderungen ausgerichtet sind – am EU AI Act, an ISO/IEC 42001 (dem Standard für KI-Managementsysteme), an auf KI-Workloads ausgeweiteten SOC-2-Type-II-Prüfungen und am AI Risk Management Framework (AI RMF) des NIST. Die meisten Security-Teams in Unternehmen bauen am Ende etwas dazwischen: ein Framework, das mehreren externen Standards zugeordnet ist und zugleich in die bestehenden Audit-Abläufe der Organisation passt. Ein funktionierendes KI-Audit-Framework hat sechs Kernthemen: Modell-Governance. Wer hat das Modell für die Produktion freigegeben? Gibt es einen Nachweis dieser Entscheidung, einschließlich Version, Lineage der Trainingsdaten und Risikobewertung? Datenherkunft. Woher stammen Trainings- und Inferencing-Daten? Ist ihre Integrität überprüfbar? Unterliegen sie Aufbewahrungs- oder Löschpflichten? Protokollierung von Entscheidungen. Werden Modelleingaben und -ausgaben für jede folgenreiche Entscheidung manipulationssicher erfasst? Zugriffskontrolle. Wer kann Modellgewichte, Trainingsdaten und Inferencing-Logs lesen? Wird der Zugriff protokolliert und regelmäßig überprüft? Erkennung von Vorfällen und Drift. Wie erkennt die Organisation, dass sich das Verhalten eines Modells wesentlich verändert hat? Gibt es ein dokumentiertes Reaktionsverfahren? Wiederherstellbarkeit. Wird ein Modell oder werden seine zugehörigen Daten beschädigt – durch Ransomware, Innentäter oder eine kompromittierte Lieferkette –, kann die Organisation dann einen bekannten fehlerfreien Zustand wiederherstellen und das belegen? Warum die Audit-Bereitschaft für KI jetzt dringend ist Drei regulatorische Entwicklungen haben die Zeitpläne für Organisationen verkürzt, die KI-Governance „später“ angehen wollten. Der EU AI Act. Hochrisiko-KI-Systeme – etwa in Personalauswahl, Kreditwürdigkeitsprüfung, medizinischer Diagnostik, Strafverfolgung und kritischer Infrastruktur – müssen technische Dokumentation vorhalten, Betriebsprotokolle führen und sich Konformitätsbewertungen unterziehen. Organisationen mit EU-Bezug, die Hochrisiko-KI einsetzen, haben Pflichten, die bereits gelten oder gerade in Kraft treten – nicht erst in einem künftigen Durchsetzungszyklus. ISO/IEC 42001. Der erste internationale Standard für KI-Managementsysteme bietet ein zertifizierbares Framework, das sich eng an ISO 27001 anlehnt. Für Organisationen, die bereits nach ISO 27001 zertifiziert sind, ist die Erweiterung auf ISO/IEC 42001 ein naheliegender nächster Schritt – und Prüfer bestehender Zertifizierungen stellen bereits Fragen, die dieser Standard abdeckt. Vorschriften zur Cyber-Resilienz. Der EU Cyber Resilience Act und der Digital Operational Resilience Act (DORA) behandeln KI-abhängige Systeme als digitale Produkte bzw. als Infrastruktur von Finanzdienstleistungen, die Sicherheits- und Prüfbarkeitsanforderungen unterliegen. Insbesondere DORA verlangt von Finanzunternehmen, wiederherstellbare IKT-Systeme zu betreiben – und KI-Inferencing-Pipelines fallen eindeutig darunter. Diese Vorschriften haben eine gemeinsame Audit-Anforderung: Die Organisation muss Nachweise vorlegen können, nicht nur Behauptungen. Logdateien, die sich nachträglich löschen, verändern oder überschreiben lassen, sind keine Nachweise. Die Speicherarchitektur ist entscheidend. Komponenten eines wirksamen KI-Audit-Frameworks Governance-Struktur Jedes KI-Audit-Framework braucht einen benannten Verantwortlichen – meist den CISO oder eine Stellvertretung – mit der Befugnis, ein System bis zur Behebung von Mängeln anzuhalten. Verantwortung ohne Befugnis erzeugt Dokumentation, die Prüfer verwerfen. Die Governance-Struktur sollte KI-Systeme Risikostufen zuordnen, für jede Stufe Prüfrhythmen festlegen und Eskalationswege definieren, wenn ein System seine freigegebenen Parameter verlässt. Daten- und Modell-Lineage Die Lineage-Dokumentation sollte für jedes produktive Modell beantworten: Welche Trainingsdaten wurden verwendet, aus welcher Quelle, in welcher Version, und wurden sie seit dem letzten Audit verändert? In der Praxis ist das schwieriger, als es klingt. Teams, die in der Cloud gehostete Foundation-Modelle nutzen, haben oft keinen vollständigen Einblick in die Lineage. Das Framework sollte Mindestanforderungen an die Lineage definieren und Lücken ausdrücklich kennzeichnen, statt sie undokumentiert zu lassen. Für Organisationen, die im großen Maßstab arbeiten, hängt die Daten-Lineage direkt mit den Funktionen für den Audit-Trail des Speichers zusammen – konkret damit, ob der Objektspeicher protokolliert, wer auf Trainingsdaten zugegriffen oder sie verändert hat, und ob diese Logs aufbewahrt und geschützt werden. Unveränderliche Audit-Logs Audit-Logs sind nur so glaubwürdig wie ihre Integritätsgarantien. Logs auf beschreibbaren Dateisystemen, die privilegierte Administratoren löschen können oder die neben den überwachten Systemen liegen, sind keine Audit-Nachweise – sie sind ein Risiko. Unveränderlicher Speicher mit Object Lock oder WORM-Semantik (Write Once, Read Many) ist die Grundvoraussetzung für Audit-Logs, die einer Prüfung standhalten. Die Anforderungen an Unveränderlichkeit gehen über Logs hinaus. Modellartefakte, Trainingsdatensätze und Konfigurations-Snapshots, die in Nachweispaketen verwendet werden, sollten alle in Speicher liegen, der unbemerkte Änderungen verhindert. Zugriffskontrolle und Identitätsmanagement Identitäts- und Zugriffsmanagement (IAM) legt über Richtlinien fest, wer Modellartefakte und Audit-Daten lesen, schreiben oder löschen darf. Das Framework sollte Zugriff nach dem Least-Privilege-Prinzip mit rollenbasierten Richtlinien, verpflichtende MFA für privilegierte Vorgänge und regelmäßige Zugriffsüberprüfungen vorschreiben. Jeder privilegierte Vorgang an audit-relevanten Daten sollte einen Eintrag im Zugriffslog erzeugen, der selbst unveränderlich ist. Zero-Trust-Architektur beruht auf dem Prinzip „Never trust, always verify“, das hier direkt greift. Audit-Datenspeicher als hochsensible Ressourcen zu behandeln, die eine kontinuierliche Verifizierung erfordern, statt als Ressourcen, auf die interne Nutzer nach dem Passieren des Perimeters frei zugreifen, entspricht sowohl einer guten Sicherheitslage als auch den sich abzeichnenden regulatorischen Vorgaben. Reaktion auf Vorfälle und Wiederherstellbarkeit Ein KI-Audit-Framework ist ohne getesteten Wiederherstellungsplan unvollständig. Prüfer nach DORA und dem NIST Cybersecurity Framework wollen nicht nur sehen, dass Kontrollen existieren, sondern auch, dass die Organisation den Betrieb wiederherstellen und die Integrität der wiederhergestellten Daten belegen kann. Wiederherstellungstests für KI-Workloads sollten die Wiederherstellung von Modellartefakten aus dem Backup, den Abgleich von Prüfsummen mit gespeicherten Werten und die Bestätigung umfassen, dass die Kontinuität der Audit-Logs über das Wiederherstellungsereignis hinweg erhalten bleibt. Richtlinie zur Datenaufbewahrung Eine Richtlinie zur Datenaufbewahrung regelt, wie lange Audit-Nachweise aufbewahrt werden und wann sie gelöscht werden dürfen. Die Aufbewahrungsfristen für KI-Audit-Logs liegen je nach regulatorischem Kontext typischerweise bei drei bis sieben Jahren. Das Framework sollte die Durchsetzung des Lebenszyklus automatisieren, sodass Logs für den erforderlichen Zeitraum aufbewahrt werden, in diesem Zeitraum nicht manuell gelöscht werden können und nach Ablauf der Frist auf dokumentierte, prüfbare Weise entfernt werden. Best Practices für die Umsetzung Stufen Sie Ihre KI-Systeme nach Risiko ein. Nicht jedes Modell braucht dieselben Audit-Abläufe. Eine Empfehlungs-Engine für interne Inhalte birgt ein anderes Risiko als ein Modell, das über Kreditanträge entscheidet. Die Einstufung lenkt den Audit-Aufwand dorthin, wo er am meisten zählt, und hält die Compliance-Kosten verhältnismäßig. Bauen Sie auf bestehenden Frameworks auf, statt bei null anzufangen. ISO 27001, SOC 2 und NIST CSF bieten bereits Audit-Strukturen, in deren Aufbau Ihre Organisation womöglich Jahre investiert hat. KI-Audit-Anforderungen lassen sich oft als Erweiterungen bestehender Kontrollen statt als parallele Programme integrieren. Das verringert die Ermüdung der Prüfer und hält die Audit-Nachweise gebündelt. Automatisieren Sie die Erfassung von Nachweisen auf Infrastrukturebene. Manuelle Erfassung von Nachweisen ist langsam, fehleranfällig und teuer. Jeder Audit-Log-Eintrag, jeder Zugriffsdatensatz und jede Integritätsprüfung, die automatisch erfasst werden – möglichst mit kryptografischen Zeitstempeln –, senkt die Kosten für ein Nachweispaket, wenn ein Audit ansteht. Testen Sie die Wiederherstellbarkeit vor einem Vorfall, nicht währenddessen. Best Practices für Zero-Trust-Sicherheit umfassen regelmäßige Wiederherstellungsübungen für sensible Datenspeicher. Auch KI-Infrastruktur gehört in diesen Übungsplan. Eine Wiederherstellung, die nie getestet wurde, ist kein Wiederherstellungsplan – sondern eine Hoffnung. Behandeln Sie Benennung und Versionierung als Audit-Anforderungen. Informelle Benennungen für Modelle und Datensätze („final“, „final_v2“, „final_v2_wirklich“) sind eine wiederkehrende Feststellung in KI-Audits. Setzen Sie für Modellartefakte und Snapshots von Datensätzen von Anfang an semantische Versionierung durch. Wie Scality ADI die Audit-Bereitschaft für KI unterstützt Infrastrukturentscheidungen, die Jahre vor einem Audit getroffen werden, entscheiden darüber, ob die Erfassung von Nachweisen einfach oder forensisch aufwendig ist. Scality ADI (Autonomous Data Infrastructure) ist eine Dateninfrastruktur für Enterprise-KI, Cyber-Resilienz und souveräne Kontrolle, die autonom und nachhaltig die passenden Speichermedien im Maßstab von mehreren Petabyte bis Exabyte zuordnet. Cyber-Resilienz ist in Scality ADI Teil der Architektur: Schutz, Wiederherstellbarkeit und Prüfbarkeit sind in die Plattform integriert, statt nachträglich aufgesetzt zu werden. Für Security-Teams, die KI-Audit-Frameworks aufbauen, deckt das CORE5-Modell für Cyber-Resilienz von Scality ADI fünf der häufigsten Anforderungen an Audit-Nachweise direkt ab: Unveränderlichkeit. Object Lock mit WORM-Semantik bedeutet, dass Audit-Logs, Modellartefakte und Snapshots von Trainingsdaten während der Aufbewahrungsfrist weder überschrieben noch gelöscht werden können – weder durch Ransomware noch durch Administratoren oder andere Akteure. Erasure Coding. Ausfallsicherheit im standortübergreifenden Maßstab stellt sicher, dass Nachweise auch beim Ausfall eines Standorts wiederherstellbar sind. Prüfer, die eine Wiederherstellung zu einem bestimmten Zeitpunkt verlangen, erhalten sie. Metadatenschutz. Scality ADI schützt Objektmetadaten zusammen mit den Inhalten, sodass Zugriffseinträge und Systemlogs über Speicherereignisse hinweg ihre Integrität behalten. Standortübergreifende Ausfallsicherheit. KI-Workloads, die sich über mehrere Regionen erstrecken, brauchen Audit-Nachweise, die denselben geografischen Kontrollen unterliegen wie die Daten. Standortübergreifende Replikation hält Nachweise über Rechtsordnungen hinweg konsistent. Richtliniengesteuerter Lebenszyklus. Aufbewahrungs- und Löschrichtlinien werden auf Speicherebene durchgesetzt, nicht durch Anwendungslogik, die sich umgehen lässt. Genau auf diesen Mechanismus achten Prüfer, wenn sie prüfen, ob Aufbewahrungspläne tatsächlich eingehalten werden. Scality ADI dient zudem als unveränderliches, hoch skalierbares S3-Objektziel für die Backup-Ökosysteme – Veeam, Commvault, Rubrik, Atempo –, mit denen Organisationen ihre KI-Infrastruktur schützen. Backup-Jobs schreiben mit aktiviertem Object Lock auf Scality ADI; die entstehenden Backup-Kopien sind konstruktionsbedingt manipulationssicher und prüfbar. So hält die CORE5-Cyber-Resilienz von Scality ADI einem Audit stand → Häufig gestellte Fragen Was sind KI-Audit-Frameworks? KI-Audit-Frameworks sind Governance-Strukturen, mit denen Organisationen ihre Verantwortung für KI-Systeme nachweisen – mit Blick auf Modell-Lineage, Protokollierung von Entscheidungen, Zugriffskontrolle, Reaktion auf Vorfälle und Wiederherstellbarkeit. Sie übersetzen interne Kontrollen in Nachweise, die externe Prüfer und Aufsichtsbehörden zufriedenstellen. Welche Vorschriften verlangen Audit-Fähigkeiten für KI? Der EU AI Act schreibt technische Dokumentation und Betriebsprotokolle für Hochrisiko-KI-Systeme vor. ISO/IEC 42001 bietet einen zertifizierbaren Standard für KI-Managementsysteme. SOC 2 Type II lässt sich auf KI-Workloads ausweiten. DORA verlangt wiederherstellbare IKT-Systeme, wozu auch die Infrastruktur für KI-Inferencing gehört. Das AI RMF des NIST bietet einen Ansatz für das Risikomanagement, der sowohl die interne Governance als auch Gespräche über regulatorische Compliance prägt. Wie unterstützt unveränderlicher Speicher die Audit-Bereitschaft für KI? Unveränderlicher Speicher verhindert, dass Audit-Logs, Modellartefakte und Trainingsdaten nachträglich verändert oder gelöscht werden. Das ist die technische Grundlage für manipulationssichere Nachweise – ohne sie sind Audit-Logs Behauptungen statt Belege. Object-Lock-Semantik auf Speicherebene setzt Aufbewahrungspläne automatisch durch und widersteht sowohl externen Angriffen als auch Bedrohungen durch Innentäter. Was ist der Unterschied zwischen KI-Audit-Frameworks und klassischen IT-Audit-Frameworks? Klassische IT-Audit-Frameworks (SOC 2, ISO 27001, NIST CSF) konzentrieren sich auf Systeme, Zugriffskontrollen und betriebliche Kontinuität. KI-Audit-Frameworks erweitern diese Themen um modellspezifische Risiken: Herkunft der Trainingsdaten, Verantwortlichkeit für algorithmische Entscheidungen, Modelldrift und die Integrität von Inferencing-Logs über die Zeit. Die meisten Organisationen bauen KI-Audit-Programme als Erweiterung bestehender IT-Audit-Strukturen auf statt als eigenständige Programme. Wie oft sollten KI-Systeme auditiert werden? Hochrisiko-KI-Systeme – die sich auf Rechte, Sicherheit oder finanzielle Ergebnisse von Personen auswirken – sollten mindestens jährlich überprüft werden, mit kontinuierlicher automatisierter Überwachung dazwischen. Systeme mit geringerem Risiko können einem zweijährlichen Zyklus folgen. Die regulatorische Einstufung des Systems und die Häufigkeit von Modellaktualisierungen sind die beiden Faktoren, die die Audit-Häufigkeit am häufigsten bestimmen. Weiterführende Artikel Audit-Trail des Speichers – wie Speichersysteme im Unternehmen Audit-Nachweise erzeugen und schützen Was ist unveränderlicher Speicher? Definition, Vorteile und Funktionsweise – Grundlagen zu WORM-Semantik und Object Lock CORE5-Lösung für Cyber-Resilienz – die Architektur von Scality für Cyber-Resilienz mit fünf Säulen Fünf Stufen unzerstörbarer Cyber-Resilienz (auf Englisch) – ein schrittweises Reifegradmodell für die Resilienz der Speicherebene EU Cyber Resilience Act – was der CRA verlangt und wen er betrifft Der Digital Operational Resilience Act (DORA) erklärt – Geltungsbereich, Anforderungen an das IKT-Risikomanagement und Testpflichten nach DORA Richtlinie zur Datenaufbewahrung: Definition, Beispiele und Best Practices – wie sich Aufbewahrungspläne so strukturieren lassen, dass sie Aufsichtsbehörden genügen
