KI-Compliance-Architektur: Designprinzipien für CISOs

5

Die meisten KI-Compliance-Programme scheitern an derselben Stelle: in dem Moment, in dem eine Aufsichtsbehörde, ein Prüfer oder ein Versicherer Nachweise verlangt. Der Richtlinienordner ist dick, die Model Cards sind ordentlich, und der Kontrollkatalog ist vier Frameworks zugeordnet – doch die eigentlichen Logs, Lineage-Daten und Wiederherstellungsnachweise liegen auf einer Infrastruktur, die nie dafür ausgelegt war, sie zu liefern. Eine solide KI-Compliance-Architektur schließt diese Lücke, indem sie Compliance als Eigenschaft der Architektur behandelt und nicht als Dokumentationsübung. Dieser Leitfaden richtet sich an CISOs und Sicherheitsarchitekten, die für KI-Systeme im Rahmen des EU AI Act, von DORA, ISO/IEC 42001, SOC 2 und einer wachsenden Zahl branchenspezifischer Vorschriften verantwortlich sind. Er erklärt, was KI-Compliance-Architektur ist, welche Designprinzipien sie dauerhaft tragfähig machen, welche Komponenten in jeder glaubwürdigen Referenzarchitektur vorkommen und wie die Speicherebene darüber entscheidet, ob Compliance-Nachweise einer Prüfung standhalten.

Was ist KI-Compliance-Architektur?

KI-Compliance-Architektur ist die Gesamtheit der technischen und betrieblichen Designentscheidungen, mit denen eine Organisation fortlaufend nachweisen kann, dass ihre KI-Systeme gesetzliche, regulatorische und vertragliche Pflichten erfüllen. Sie ist die Brücke zwischen einer schriftlichen Compliance-Richtlinie und der laufenden Infrastruktur, die diese Richtlinie einhalten muss. Die Disziplin ist jünger als ihr Ursprung – die Compliance-Architektur im Unternehmen –, doch die Struktur ist vertraut. Eine Compliance-Architektur beantwortet für jedes KI-System in Produktion vier Fragen: Welche Regeln gelten, welche Kontrollen setzen diese Regeln um, wo liegt der Nachweis, dass diese Kontrollen funktionieren, und wie reagiert die Organisation, wenn eine Kontrolle versagt oder sich die Regeln ändern? Der Unterschied bei KI: Die Regeln reichen heute bis in den Modelllebenszyklus selbst hinein. Herkunft der Trainingsdaten, Modellversionierung, Protokollierung von Entscheidungen, Drift-Monitoring und Wiederherstellungstests sind keine optionale technische Sorgfalt mehr. Sie sind ausdrückliche Pflichten nach dem EU AI Act, ISO/IEC 42001 und einer wachsenden Zahl nationaler Vorschriften. Eine KI-Compliance-Architektur sorgt dafür, dass diese Pflichten mechanisch erfüllt werden statt durch Kraftakte. Die Compliance-Architektur unterscheidet sich von zwei angrenzenden Disziplinen, ist aber mit ihnen verzahnt:

• KI-Governance legt die Richtlinien fest – wer was auf welchen Daten für welchen Anwendungsfall entwickeln darf.
• KI-Compliance-Architektur übersetzt diese Richtlinien in durchsetzbare Kontrollen in der Infrastruktur.
• KI-Audit-Frameworks bündeln die daraus entstehenden Nachweise, damit externe Prüfer verifizieren können, dass die Kontrollen gegriffen haben.

Das Auslassen der Architekturebene ist der häufigste Grund, warum Compliance-Programme beim ersten Besuch einer Aufsichtsbehörde zusammenbrechen.

Warum KI-Compliance heute ein Architekturproblem ist

Jahrelang konnte sich Compliance-Arbeit auf nachträgliche Berichte stützen. Logs wurden exportiert, Tabellen abgeglichen und Ausnahmen in Textform erklärt. Bei KI-Workloads ist dieser Ansatz aus drei Gründen nicht mehr haltbar.

Volumen und Geschwindigkeit. Ein einziges produktives Modell kann täglich Millionen von Inferencing-Datensätzen erzeugen, von denen jeder für eine Aufsichtsbehörde relevant sein kann, die sehen will, wie eine folgenreiche Entscheidung zustande kam. Manueller Abgleich skaliert nicht in diesem Takt. Kontrollen müssen dort durchgesetzt werden, wo die Daten entstehen.

Verteilte Angriffsfläche. KI-Pipelines erstrecken sich über Objektspeicher, GPU-Cluster, Vektordatenbanken, Feature Stores und Modellregister – oft über On-Premises, Colocation und mehrere Clouds hinweg. Compliance-Nachweise müssen den Daten lückenlos über diese gesamte Fläche folgen. Eine Kontrolle, die nur auf einer Ebene existiert, existiert faktisch nicht.

Kritische Prüfung. Vorstände, Aufsichtsbehörden, Versicherer und Security-Teams geben sich nicht mehr mit Behauptungen zufrieden. Sie wollen unveränderliche Nachweise, schnelle Wiederherstellungsbelege und nachweisbare Kontrolle über die Rechtsordnung. Diese Anforderung verändert, was die Infrastruktur leisten muss – nicht nur, was in Richtlinien steht. Der EU AI Act, ISO/IEC 42001, DORA, NIS2und der EU Cyber Resilience Act weisen alle in dieselbe Richtung: Belegen Sie es mit Nachweisen, und zwar zum Zeitpunkt der Anfrage. Das ist ein Architekturstandard, kein Berichtsstandard.

Designprinzipien für KI-Compliance-Architektur

Jede glaubwürdige KI-Compliance-Architektur beruht auf denselben wenigen Prinzipien. Sie sind nicht neu. Es sind die Prinzipien, auf denen gute Sicherheitsarchitektur ohnehin beruht – angewendet mit der Disziplin, die KI-Workloads verlangen.

Prinzip 1: Compliance ist eine Eigenschaft der Plattform, keine Hülle um sie herum

Kontrollen, die in Anwendungscode, geplanten Skripten oder manuellen Prüfschritten liegen, weichen ab, sobald sich das Personal ändert. Kontrollen in der Speicher-, Identitäts- und Netzwerkschicht tun das nicht. Die erste Designentscheidung in einer KI-Compliance-Architektur besteht darin, möglichst viele Kontrollen im Stack nach unten zu verlagern – in Systeme, die Richtlinien standardmäßig durchsetzen und die sich auch von einem gut meinenden Ingenieur unter Zeitdruck nicht umgehen lassen.

Prinzip 2: Nachweise werden erzeugt, nicht zusammengestellt

Von Hand erstellte Audit-Pakete sind langsam, teuer und lückenanfällig. Audit-Pakete aus einer Infrastruktur, die jeden Zugriff, jede Änderung und jedes Lifecycle-Ereignis protokolliert, sind schnell, günstig und vollständig. Die Architektur sollte Nachweise als Nebenprodukt des normalen Betriebs erzeugen. Muss jemand daran denken, ein Ereignis zu erfassen, wird dieses Ereignis irgendwann nicht erfasst.

Prinzip 3: Unveränderlichkeit ist die Grundlage für Nachweise

Ein Log, das sich bearbeiten lässt, ein Modellartefakt, das sich ersetzen lässt, oder ein Trainingsdatensatz, der sich unbemerkt aktualisieren lässt, kann nicht als Nachweis dienen. Unveränderlicher Speicher mit Object Lock und WORM-Semantik (Write Once, Read Many) ist die Mindestanforderung für jedes Artefakt, das die Organisation in einem Audit verteidigen will. Das gilt für Modell-Checkpoints, Snapshots von Trainingsdaten, Inferencing-Logs, Konfigurationsdatensätze und Zugriffslogs gleichermaßen.

Prinzip 4: Die Lineage ist von der Quelle bis zur Entscheidung lückenlos

Aufsichtsbehörden und Prüfer akzeptieren keine Lineage, die bei „das Datenteam hat es übergeben“ endet. Für jede folgenreiche Modellausgabe sollte die Architektur es ermöglichen, den Inferencing-Datensatz bis zur Modellversion zurückzuverfolgen, die Modellversion bis zu ihrem Trainingslauf, den Trainingslauf bis zur Datensatzversion und die Datensatzversion bis zu den Quellen, die dazu beigetragen haben. Jeder Schritt in dieser Kette braucht eine Integritätsgarantie.

Prinzip 5: Wiederherstellung ist Teil der Compliance, nicht davon getrennt

DORA und der EU Cyber Resilience Act sagen es ausdrücklich: Ein System, das sich nicht wiederherstellen lässt, lässt sich nicht verteidigen. Eine KI-Compliance-Architektur muss getestete Wiederherstellungsverfahren für Modellartefakte, Trainingsdatensätze, Inferencing-Logs und Konfigurationszustände umfassen. Ziele für Wiederherstellungszeit und Wiederherstellungspunkt gehören von Anfang an in das Compliance-Design.

Prinzip 6: Souveränität ist in der Architektur verankert, nicht in Versprechen

Wo Daten liegen, wer auf sie zugreifen kann und welchem Recht sie unterliegen, sind zunehmend harte Anforderungen statt Präferenzen. Die Architektur sollte Datenresidenz, Prüfbarkeit und betriebliche Souveränität als durchgesetzte Eigenschaften verankern – Platzierungsrichtlinien, rechtsordnungsbewusste Replikation und Identitätsgrenzen, die nicht vom guten Willen eines Anbieters abhängen. Wie sich das in Speicherentscheidungen niederschlägt, zeigt der Beitrag zu Best Practices für Datensouveränität im Detail.

Prinzip 7: Kontrollen versagen kontrolliert

Produktivsysteme fallen aus. Compliance-Kontrollen müssen so versagen, dass Nachweise erhalten bleiben und die Organisation geschützt ist – nicht so, dass neue Lücken entstehen. Die Architektur sollte standardmäßig schließen: Kann eine Kontrolle ihren Zustand nicht verifizieren, ist es sicherer, den Vorgang abzulehnen, die Ablehnung zu protokollieren und sie zur manuellen Prüfung vorzulegen.

Komponenten einer Referenzarchitektur für KI-Compliance

Aus den sieben Prinzipien ergibt sich eine Referenzarchitektur mit erkennbarer Form. Die folgende Übersicht skizziert die Ebenen, die in jeder ausgereiften Umsetzung vorkommen.

Einige Komponenten verdienen einen genaueren Blick.

Modell- und Datensatzregister

In der Registerebene lebt die Lineage. Jedes Modell, das in Produktion geht, sollte einen Eintrag mit Version, Snapshot der Trainingsdaten, Evaluierungsergebnissen, Freigabesignaturen und Einsatzbereich haben. Datensätze sollten mit derselben Disziplin versioniert werden. Informelle Benennungen – „final“, „final_v2“, „final_v2_wirklich“ – sind die häufigste Audit-Feststellung in frühen KI-Compliance-Prüfungen.

Unveränderliche Audit-Trails

Audit-Logs, die das Schicksal der überwachten Systeme teilen, sind keine Audit-Logs. Sie müssen in einen Speicher geschrieben werden, der Änderungen während der Aufbewahrungsfrist verhindert, über Fehlerdomänen hinweg repliziert werden und abfragbar sein, ohne die Integrität zu gefährden. In der Praxis wird diese Anforderung im Audit-Trail des Speichers umgesetzt.

Durchsetzung von Aufbewahrung und Löschung

Viele KI-Compliance-Pflichten bringen harte Unter- und Obergrenzen für die Aufbewahrung mit sich – dies sieben Jahre aufbewahren, jenes innerhalb von dreißig Tagen nach einem Auskunftsersuchen löschen. Die Durchsetzung von Richtlinien auf Speicherebene stellt sicher, dass diese Fristen eingehalten werden, auch wenn die Anwendungslogik sie vergisst. Eine dokumentierte Richtlinie zur Datenaufbewahrung , gestützt durch Lifecycle-Kontrollen auf Speicherebene, ist die Kombination, auf die Prüfer achten.

Wiederherstellung und Integritätsprüfung

Ein Modell wiederherzustellen ist nicht dasselbe, wie ein Modell wiederherzustellen, das nicht manipuliert wurde. Wiederherstellungsverfahren sollten Prüfsummen mit signierten Registerwerten abgleichen, bestätigen, dass die Kontinuität der Audit-Logs über das Wiederherstellungsereignis hinweg erhalten bleibt, und belegen, dass das wiederhergestellte System dasjenige ist, das vor dem Vorfall lief.

Wie Scality ADI KI-Compliance-Architektur unterstützt

Compliance-Architektur steht und fällt mit der Speicherebene. Logs, Modellartefakte, Trainingsdatensätze und Konfigurations-Snapshots liegen letztlich alle auf Objektspeicher – und die Integritätseigenschaften dieses Speichers entscheiden, ob der Rest der Architektur überhaupt etwas zu verteidigen hat. 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 CISOs und Sicherheitsarchitekten, die eine KI-Compliance-Architektur entwerfen, lässt sich das CORE5-Modell für Cyber-Resilienz von Scality ADI direkt auf die oben genannten Designprinzipien abbilden:

• 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. Das ist Prinzip 3, durchgesetzt in hardwaregestützter Software statt in Prozessen.
• Erasure Coding. Hohe Ausfallsicherheit im standortübergreifenden Maßstab bedeutet, dass Nachweise den Ausfall eines Standorts überstehen. Nach DORA angeforderte Wiederherstellungsnachweise lassen sich ohne separate, eigens für die Compliance vorgesehene Backup-Ebene erbringen.
• Metadatenschutz. Objektmetadaten werden mit denselben Integritätsgarantien wie die Inhalte geführt, sodass Zugriffseinträge, Klassifizierungstags und Lineage-Verweise über Speicherereignisse hinweg ihren Wert behalten.
• Standortübergreifende Ausfallsicherheit. Geografische Replikation hält Nachweise über Rechtsordnungen hinweg konsistent und unterstützt Souveränitätsanforderungen, ohne parallele Steuerungsebenen zu erzwingen.
• Richtliniengesteuerter Lebenszyklus. Aufbewahrungs- und Löschrichtlinien werden auf Speicherebene durchgesetzt statt in einer Anwendungslogik, die sich umgehen lässt. Genau auf diesen Mechanismus achten Prüfer, wenn sie fragen, ob Aufbewahrungspläne tatsächlich eingehalten werden.

Scality ADI umfasst vier Speicherebenen – GPU-Direct-Flash, heiß mit QLC und NL-SSD, warm mit NL-HDD und HDD sowie kalt mit Band und Cloud-naher Archivierung – in einem einzigen Betriebsmodell. KI-Compliance-Nachweise können daher demselben Lebenszyklus folgen wie die Daten, die sie beschreiben: heiß während der aktiven Phase einer Untersuchung, warm während der Aufbewahrungsphase und kalt für langfristige Pflichten, ohne jemals den Audit-Rahmen der Plattform zu verlassen. Scality ADI dient zudem als unveränderliches, hoch skalierbares S3-Objektziel für die Backup-Ökosysteme – Veeam, Commvault, Rubrik, Atempo –, mit denen die meisten Unternehmen ihre KI-Infrastruktur schützen. Backup-Kopien, die mit aktiviertem Object Lock auf Scality ADI geschrieben werden, sind konstruktionsbedingt manipulationssicher – genau die Eigenschaft, die wiederherstellungsbezogene Compliance-Pflichten tatsächlich verlangen.

So liefert Scality ADI Cyber-Resilienz und souveräne Kontrolle für Enterprise-KI

Häufig gestellte Fragen

Was ist KI-Compliance-Architektur?

KI-Compliance-Architektur ist die Gesamtheit der technischen und betrieblichen Designentscheidungen, mit denen eine Organisation fortlaufend nachweisen kann, dass ihre KI-Systeme regulatorische, vertragliche und interne Pflichten erfüllen. Sie übersetzt ein Compliance-Programm in Kontrollen auf Infrastrukturebene, sodass Nachweise von der Plattform erzeugt statt von Hand zusammengestellt werden.

Worin unterscheidet sich KI-Compliance-Architektur von KI-Governance?

KI-Governance definiert die Richtlinien – welche KI zulässig ist, auf welchen Daten und für welchen Zweck. KI-Compliance-Architektur setzt diese Richtlinien als durchsetzbare Kontrollen in der Infrastruktur um. Governance ohne Architektur erzeugt gut geschriebene Dokumente, die beim ersten Audit scheitern. Architektur ohne Governance erzeugt Kontrollen, die sich von der eigentlichen Absicht entfernen.

Welche Vorschriften bestimmen Entscheidungen zur KI-Compliance-Architektur?

Der EU AI Act, ISO/IEC 42001, DORA, NIS2, der EU Cyber Resilience Act, auf KI-Workloads ausgeweitete SOC-2-Type-II-Prüfungen und das AI Risk Management Framework des NIST sind die häufigsten Treiber. Branchenspezifische Vorschriften – HIPAA für KI im Gesundheitswesen, Finanzaufsichtsbehörden für Kredit- und Handelsmodelle – bringen weitere Anforderungen mit sich, die die Architektur berücksichtigen muss.

Welche Rolle spielt unveränderlicher Speicher für die KI-Compliance?

Unveränderlicher Speicher ist die Grundlage für manipulationssichere Nachweise. Audit-Logs, Modellartefakte und Snapshots von Trainingsdaten, die mit Object Lock und WORM-Semantik gespeichert werden, lassen sich während der Aufbewahrungsfrist weder ändern noch löschen. Ohne diese Eigenschaft sind Compliance-Nachweise eine Behauptung statt eines Belegs.

Wie oft sollte eine KI-Compliance-Architektur überprüft werden?

Die Architektur selbst sollte mindestens jährlich und nach jeder wesentlichen regulatorischen Änderung überprüft werden. Die Kontrollen innerhalb der Architektur sollten fortlaufend getestet werden – Zugriffsüberprüfungen vierteljährlich, Wiederherstellungsübungen mindestens jährlich und Integritätsprüfungen kontinuierlich. Für Hochrisikosysteme nach dem EU AI Act empfiehlt sich in allen Punkten ein engerer Rhythmus.

Weiterführende Artikel

• Audit-Trail des Speichers – wie Speichersysteme im Unternehmen Compliance-Nachweise erzeugen und schützen
• Was ist unveränderlicher Speicher? Definition, Vorteile und Funktionsweise – Grundlagen zu WORM-Semantik und Object Lock
• Framework für Daten-Compliance – Aufbau eines strukturierten Compliance-Programms über Datensysteme hinweg
• Richtlinie zur Datenaufbewahrung: Definition, Beispiele und Best Practices – wie sich Aufbewahrungspläne so strukturieren lassen, dass sie Aufsichtsbehörden genügen
• CORE5-Lösung für Cyber-Resilienz – die Architektur von Scality für Cyber-Resilienz mit fünf Säulen
• Der Digital Operational Resilience Act (DORA) erklärt – Geltungsbereich, Anforderungen an das IKT-Risikomanagement und Testpflichten nach DORA
• Zero-Trust-Architektur – das Prinzip „Never trust, always verify“ in der KI-Infrastruktur