Trust-Infrastructure statt Compliance-Software

Zwischen zwei Organisationen, die beide behaupten, den EU AI Act zu erfüllen, liegt oft ein unsichtbarer Graben. Die eine hat ihre Pflichten in einer Software abgebildet: Aufgaben angelegt, Häkchen gesetzt, Fristen dokumentiert. Die andere kann auf Nachfrage zeigen, warum eine Aussage stimmt — mit Aufzeichnungen, die belegen, wer wann was entschieden hat und woher die zugrunde liegenden Daten stammen. Beide sagen „compliant". Nur die zweite kann es beweisen. Dieser Unterschied ist keine Nuance, sondern der konzeptionelle Kern dessen, was Trust-Infrastructure von Compliance-Software trennt.

Compliance ist eine Folge, kein Werkzeug

Der verbreitete Denkfehler beginnt bei der Reihenfolge. Compliance wird als Ziel behandelt, das man mit dem richtigen Tool erreicht — so wie man Buchhaltung mit einer Buchhaltungssoftware erledigt. Doch Compliance im Sinne des EU AI Act ist kein Zustand, den eine Software herstellt. Sie ist das Ergebnis einer belastbaren Grundlage: der Fähigkeit, jederzeit nachweisen zu können, dass die eigenen KI-Systeme so betrieben werden, wie es die Verordnung (EU) 2024/1689 verlangt.

Diese Grundlage ist die eigentliche Infrastruktur. Sie besteht nicht aus To-do-Listen, sondern aus Nachweisen — aus Aufzeichnungen, die auch dann noch tragen, wenn eine Aufsichtsbehörde, ein Auditor oder ein Kunde im Vendor-Assessment sie hinterfragt. Wer diese Grundlage besitzt, ist compliant, weil er es zeigen kann. Wer nur die Verwaltungsschicht besitzt, ist es nur, solange niemand nachfragt. Genau deshalb ist die Buyer Promise „Evidence-based AI Trust — nachweisbar, audit-ready" bewusst so formuliert: Sie verspricht Nachweisbarkeit, nicht eine „100 % Compliance", die ohnehin niemand seriös garantieren kann.

Was der EU AI Act tatsächlich verlangt: Nachweise

Der Gesetzestext selbst macht deutlich, dass es um Belege geht, nicht um Selbstauskünfte. Artikel 11 der Verordnung verpflichtet Provider von Hochrisiko-KI zur technischen Dokumentation — und zwar so, dass eine Behörde daraus beurteilen kann, ob das System die Anforderungen erfüllt. Es genügt nicht, dass die Anforderungen erfüllt sind; es muss aus den Unterlagen hervorgehen.

Artikel 12 verlangt, dass Hochrisiko-KI-Systeme technisch so ausgelegt sind, dass Ereignisse über die gesamte Lebensdauer automatisch aufgezeichnet werden — Logging als Konstruktionsprinzip, nicht als nachträgliche Beilage. Artikel 19 verpflichtet Provider, die von ihren Systemen automatisch erzeugten Protokolle aufzubewahren, soweit sie diese kontrollieren. Und Artikel 17 fordert von Providern ein Qualitätsmanagementsystem, dessen Verfahren schriftlich festgehalten sein müssen. Der rote Faden durch all diese Vorschriften ist derselbe: Der Regelgeber interessiert sich nicht für Absichten, sondern für überprüfbare Spuren.

Eine Compliance-Software, die Aufgaben verwaltet, adressiert diese Anforderungen nur an der Oberfläche. Sie kann festhalten, dass jemand eine Aufgabe als erledigt markiert hat. Was sie in der Regel nicht leistet, ist der manipulationssichere Beleg dafür, dass die zugrunde liegende Tätigkeit tatsächlich und korrekt stattgefunden hat — mit einer Herkunft, die sich später unabhängig prüfen lässt.

Die drei Eigenschaften belastbarer Nachweise

Ob eine Aufzeichnung als Nachweis taugt oder nur als Behauptung, entscheidet sich an drei Eigenschaften.

Erstens Provenance — die Herkunft. Ein Nachweis muss zeigen, woher eine Information stammt: welches System, welche Datenquelle, welche Version, welcher Zeitpunkt. Ein Wert ohne Herkunft ist ein Gerücht, kein Beleg. Der EU AI Act greift diese Logik in den Datenanforderungen des Artikels 10 auf, der für Hochrisiko-KI dokumentierte Aussagen über Trainings-, Validierungs- und Testdaten verlangt.

Zweitens Integrität — die Manipulationssicherheit. Eine Aufzeichnung, die sich unbemerkt nachträglich ändern lässt, verliert ihren Beweiswert. Deshalb ist der Unterschied zwischen einem editierbaren Feld in einer Datenbank und einem manipulationsevidenten Protokoll kein technisches Detail, sondern die Trennlinie zwischen Dokumentation und Nachweis.

Drittens Prüfbarkeit — die Auditierbarkeit. Ein Nachweis muss von einem Dritten ohne Zutun des Erstellers nachvollzogen werden können. Erst wenn Auditor, Behörde oder Kunde die Spur eigenständig verfolgen können, wird aus einer internen Aussage ein extern belastbarer Beleg. Diese Prüfbarkeit ist auch der Grund, warum ein AI Management System nach ISO/IEC 42001 auf dokumentierte Information und interne Audits setzt — ein AIMS lebt davon, dass sich seine Wirksamkeit nachweisen lässt, nicht davon, dass sie behauptet wird.

Warum die Unterscheidung jetzt wirtschaftlich wird

Solange niemand ernsthaft nachfragt, sehen beide Ansätze gleich aus. Das ändert sich mit dem Forcing Event: Ab dem 2. Dezember 2027 greift die Durchsetzung der Hochrisiko-Pflichten des EU AI Act (Digital Omnibus). Ab diesem Punkt kann die Frage „Können Sie das nachweisen?" jederzeit gestellt werden — von Marktüberwachungsbehörden, aber ebenso von Kunden, die ihre eigene Lieferkette absichern müssen, und von Versicherern, die Risiken bepreisen.

An diesem Punkt kippt der wirtschaftliche Wert. Eine Verwaltungsschicht, die nur Aufgaben abbildet, erzeugt in dem Moment Aufwand, in dem der Nachweis nachträglich rekonstruiert werden muss — oft unter Zeitdruck und mit lückenhaften Spuren. Eine Trust-Infrastructure, die Nachweise laufend miterzeugt, hat den Beleg dann bereits vorliegen. Der Unterschied ist nicht kosmetisch: Er entscheidet darüber, ob Nachweisbarkeit ein planbarer Betriebsprozess oder eine wiederkehrende Feuerwehrübung ist. Wer die regulatorischen Konsequenzen fehlender Nachweise einordnen will, findet eine Übersicht zu Sanktionen auf ki-bussgeld.de.

Vom Werkzeug zur Grundlage

Der Perspektivwechsel ist einfach zu formulieren und schwer umzusetzen: Nicht fragen „Welches Tool macht mich compliant?", sondern „Welche Nachweise brauche ich — und wie entstehen sie zuverlässig als Nebenprodukt meines normalen Betriebs?". Compliance-Software beantwortet die erste Frage. Trust-Infrastructure beantwortet die zweite, und die erste löst sich als Folge davon.

Für Organisationen in DE, im EU27-Rest, in UK und in CH bedeutet das, den Aufbau von Nachweisfähigkeit nicht als Reporting-Aufgabe zu behandeln, sondern als Architekturentscheidung: Provenance, Integrität und Prüfbarkeit gehören in die Systeme hinein, nicht in ein nachgelagertes Formular. Je früher diese Grundlage steht, desto weniger wird der 2. Dezember 2027 zum Stichtag, der überrascht.

Mehr zur AEGIRA Trust-Platform: aegira.ai