EU-AI-Act-Audit-Readiness: Kann Ihre KI-Runtime Beweise liefern?

Kurz gesagt: Bei einem Audit geht es nicht um Ihr Modell, sondern darum, ob Ihre Runtime zeigen kann, wer jede KI-Aktion autorisiert hat, was sie verändert hat und wo die Belege liegen – und Auditierbarkeit lässt sich nicht nachträglich aufsetzen, sondern nur in dem Moment festhalten, in dem sie geschieht.

Stellen Sie sich einen Konferenzraum vor.

Ein in Europa tätiges Versicherungsunternehmen hat eine externe Prüfung als Compliance-Generalprobe für den AI Act beauftragt. Der Prüfer setzt sich, öffnet seinen Laptop, kein Smalltalk, und stellt die erste Frage:

„Rufen Sie mir den vollständigen Hergang jener Schadenmeldung des letzten Monats auf, die von der KI automatisch als ‚hohes Betrugsrisiko’ markiert und daher abgelehnt wurde – wer hat es ausgelöst, auf welche Daten stützte sich die KI, welche Regel wurde angewandt, wer hat es gegengeprüft, welchen Weg ging der Einspruch des Kunden.”

Dann wird es still im Raum.

Nicht, weil diese Ablehnung zwingend falsch war, sondern weil es für den Abschnitt, in dem die KI an dieser Entscheidung beteiligt war, im System keinen einzigen vollständigen, durchgängigen, unbestreitbaren Ort gibt, an dem man ihn aufrufen könnte. Die Schadendaten liegen in einem System, der Scoring-Dienst der KI in einem anderen, die Gegenprüfungsdatensätze in einem dritten, und das alles steht nicht in derselben Buchführung wie die menschlichen Handlungen. Um die vom Prüfer verlangte Linie zusammenzusetzen, müssten drei Teams drei Tage lang Logs durchwühlen, und es wäre nicht einmal garantiert, dass es vollständig zusammenpasst.

Dieses Unternehmen wurde damals nicht bestraft – es war ja nur eine Generalprobe. Aber die Sanktionen des AI Act für hochriskante KI-Systeme bemessen sich nach einem Prozentsatz des weltweiten Umsatzes, in einer Größenordnung, die jedes Unternehmen ernst nehmen lässt. Und das, was die Generalprobe aufdeckte, wird das echte Audit ein paar Wochen später wortwörtlich noch einmal fragen.

Dieser stille Konferenzraum ist genau das Szenario, dem 2026 viele Unternehmen bald gegenüberstehen.

Der Countdown ist real, und er ist sehr nah

Der Zeitplan des EU AI Act ist real, aber die Pflichten greifen gestaffelt. Nach dem Inkrafttreten 2024 folgen Verbote, Transparenz-, Governance- und Hochrisiko-Pflichten schrittweise. Am 3. Juni 2026 hat die EU zudem das Gesetz für Cloud- und KI-Entwicklung (CADA) vorgeschlagen und damit einen Souveränitätsrahmen für Cloud- und KI-Dienste in die Debatte gebracht. Für Unternehmen, die in Europa geschäftlich tätig sind oder europäische Kunden bedienen, ist das keine ferne Zukunft.

Und die schmerzhafteste Zahl ist: Umfragen zeigen, dass 78 % der Führungskräfte nicht zuversichtlich sind, ein unabhängiges KI-Governance-Audit innerhalb von 90 Tagen zu bestehen. Nicht, weil sie nicht compliant sein wollen, sondern weil sie, wenn es wirklich in jenem Konferenzraum darauf ankommt, keine Antwort haben.

Das Audit prüft nicht das Modell, sondern die Runtime

Das Erste, was viele Teams für die Compliance tun, ist, das Modell zu bewerten – ob es Zertifizierungen hat, ob es schädliche Inhalte ausgibt. Das ist wichtig, aber nicht das Hauptschlachtfeld des Audits. Was die Regulierung wirklich will, ist, ob Sie für jede einzelne Handlung, mit der KI das Geschäft berührt, drei Dinge klar darlegen können:

Was der Prüfer fragt	Was dabei geprüft wird	Folge, wenn Sie es nicht beantworten können
Werden diese Daten rechtmäßig verarbeitet?	Wo die Daten liegen, wer sie lesen darf, ob sie je die EU verlassen haben	Verstoß gegen Datenresidenz, Exposition gegenüber dem CLOUD Act
Wer hat die KI zu dieser Handlung autorisiert?	Nach wessen Berechtigung Handlungen wie Ablehnung oder Auszahlung gelten	Verantwortung nicht zuzuordnen, Handlung unkontrollierbar
Wurde der Schritt mit KI-Beteiligung protokolliert?	Ob eine vollständige, unbestreitbare Beweiskette vorgelegt werden kann	Audit scheitert sofort

Keine einzige Frage betrifft das Modell. Sie alle betreffen jene Schicht jenseits des Modells – die Runtime, die Daten trägt, Berechtigungen erzwingt und Beweise aufzeichnet.

Was der AI Act von „hochriskanten Systemen” eigentlich verlangt

Das ist kein abstraktes „compliant sein”. Der AI Act benennt für hochriskante KI-Systeme (Schadenregulierung, Kredit, Personalbeschaffung, kritische Infrastruktur und Ähnliches) mehrere harte Pflichten, die es lohnt, Punkt für Punkt durchzugehen – denn sie fallen fast alle auf die Runtime, nicht auf das Modell:

Anforderung des AI Act	Auf welcher Schicht sie fällt	Kann das Modell sie liefern
Automatische Ereignisprotokollierung (nachvollziehbar)	Audit-Log der Runtime	Nein, das Modell hinterlässt keine Spur
Menschliche Aufsicht (kritische Entscheidungen eingreif- und revidierbar)	Genehmigung und Prozess der Runtime	Nein, muss per Prozess erzwungen werden
Erklärbarkeit der Entscheidung (worauf gestützt)	Von der Runtime aufgezeichnete Eingaben und Regeln	Teilweise, aber die unbestreitbare Aufzeichnung liegt in der Runtime
Daten-Governance (Herkunft, Berechtigung, Residenz)	Berechtigungen und Deployment der Runtime	Nein

Sie werden feststellen: So stark das Modell auch ist, in dieser Tabelle kann es in keiner einzigen Spalte ein Häkchen setzen. Genau das ist die Wurzel des Phänomens, dass so viele Teams „das Modell sehr sorgfältig wählen, die Compliance aber nicht bestehen” – sie strengen sich auf der falschen Schicht an. Was die Regulierung will, wächst strukturell auf der Runtime.

Kauft man nicht einfach ein Compliance-Tool?

Die natürlichste Reaktion ist: Es gibt am Markt einen Haufen „AI-Act-Compliance-Plattformen”, und die Anbieter werben alle damit, compliant zu sein – unterschreibt man ein DPA, holt sich ein Zertifikat, lagert man die Sache nicht damit aus?

Dieser Weg löst einen Teil, aber nicht das Problem in jenem Konferenzraum.

Compliance-Tools und Zertifizierungen leisten Aufzeichnung und Bestätigung: Sie sagen der Regulierung „wir haben Prozesse, Dokumente, Datenverarbeitungsvereinbarungen”. Aber der Prüfer will nicht „ob Sie Prozesse haben”, sondern „rufen Sie den vollständigen Hergang genau dieser einen Sache auf”. Dokumente können die Rechtmäßigkeit einer konkreten Einzelhandlung nicht beweisen, und ein DPA kann nicht beantworten, ‚auf welche Berechtigung gestützt die KI diese Ablehnung tätigte und wer sie gegenprüfte’. Diese Art Beweis kann nur die Runtime, die jene Handlung tatsächlich ausführt, im Augenblick des Geschehens aufzeichnen. Tools zu kaufen hilft Ihnen, die „Regelwerksschicht” zu beherrschen, nicht die „Handlungsschicht” – und wenn das Audit bis zum Ende nachhakt, fragt es immer nach einer konkreten Einzelhandlung.

Auditierbarkeit lässt sich nicht nachholen

Daraus folgt eine harte Wahrheit, die viele nicht erkennen: Compliance ist kein Dokument, das Sie im dritten Quartal zusammenschustern, sondern eine Eigenschaft, die ein System entweder besitzt oder nicht.

Jene Beweiskette, die der Prüfer will, muss im Augenblick, in dem die Handlung geschieht, aufgezeichnet werden. Hat die Runtime sie damals nicht aufgezeichnet, lässt sich auch durch alle Last-Minute-Anstrengungen vor August der wahre Hergang jener Ablehnung des letzten Monats nicht herbeizaubern – Sie können nur „rekonstruieren”, und einer rekonstruierten Aufzeichnung sieht der Prüfer auf einen Blick an, dass sie nicht vertrauenswürdig ist.

Genau deshalb ist „erst KI einführen, Compliance später” eine gefährliche Wette: Sie wetten darauf, dass das Audit nicht nach jenen Handlungen fragt, die damals nicht aufgezeichnet wurden. Sobald danach gefragt wird, werden alle KI-Entscheidungen jenes Zeitraums zu einer nicht belegbaren leeren Fläche.

Bevor Sie in den Auditraum gehen, prüfen Sie sich mit diesen fünf Fragen – bei jeder, die Sie nicht mit „ja” beantworten können, ist genau dieser Punkt Ihr Risiko:

Können Sie zu einer beliebig herausgegriffenen Geschäftshandlung mit KI-Beteiligung an Ort und Stelle den vollständigen Hergang aufrufen?
Werden Berechtigungen von der Runtime erzwungen oder im Prompt geschrieben?
Stehen die Handlungen von Mensch und Agent in demselben Audit-Log?
Unter wessen Hoheitsbereich fallen diese Daten und Verarbeitungsprozesse?
Können Sie bei einem Problem einen bestimmten Agent oder eine bestimmte Handlungskategorie per Knopfdruck stoppen?

Warum „die Regel in den Prompt schreiben” diese Hürde nicht nimmt

Etliche Teams haben durchaus Governance betrieben, nur an der falschen Stelle – im Prompt. „Du darfst nur Daten abfragen, für die der aktuelle Nutzer berechtigt ist”, „hochriskante Schadenmeldungen müssen menschlich gegengeprüft werden” – im Alltag wirkt das auch brauchbar. Aber es besteht das Audit nicht, aus zwei jeweils tödlichen Gründen:

Erstens: Ein Prompt ist eine Empfehlung, keine Kontrolle. Er wirkt, weil das Modell „gehorchen will”, und wird von einem einzigen Jailbreak oder einer nicht abgedeckten Grenze umgangen. Fragt der Prüfer „wie garantieren Sie, dass eine bestimmte Schadenkategorie sicher menschlich gegengeprüft wird”, ist „wir haben es in den Prompt geschrieben” keine unterschriftsfähige Antwort.

Zweitens: Ein Prompt erzeugt keine Aufzeichnung. Das Audit will strukturierte, unbestreitbare Beweise, und die kann ein Prompt nicht liefern.

Was Compliance wirklich verlangt, ist, die Governance von „einer Empfehlung im Prompt” auf „einen Zwang in der Ausführungsengine” zu verlagern – Berechtigungen werden bei jedem Lesen und Schreiben von der Runtime verifiziert, und das Audit ist ein natürliches Nebenprodukt der Handlung.

Nach CADA wird „wo die Daten liegen” zur harten Kennzahl – aber Self-Hosting ist kein Freibrief

CADA schiebt eine weitere Sache in den Vordergrund: Datensouveränität. Im Kern fragt es, unter wessen Hoheitsbereich Ihre Daten und KI-Verarbeitungsprozesse fallen. Diese Frage zielt direkt auf die Deployment-Form. Eine KI-Runtime, die echte Geschäftsdaten liest, einem externen SaaS zu überlassen, dessen Innenleben Sie nicht einsehen können und das zudem dem CLOUD Act unterliegt, lässt sich unter dem neuen Rahmen immer schwerer unterschreiben. Self-Hosting kann Datenresidenz, Dritt-Exposition und Sichtbarkeit auf einen Schlag verbessern – self-hosted gehört nicht zwingend das Modell, sondern jene Runtime, die Objekte, Berechtigungen, Werkzeuge, Genehmigungen und Audit-Beweise trägt.

Aber man muss ehrlich einen Satz sagen: Self-Hosting ist kein Freibrief, es ist ein Handel. Läuft die Runtime auf Ihrer eigenen Infrastruktur, fallen Patchen, Schlüsselrotation, das Sicherstellen, dass keine Logs verloren gehen, und das Notabschalten per Knopfdruck im Ernstfall – diese Tätigkeiten und die Beweislast – ebenfalls auf Sie. Was Sie eintauschen, ist Kontrolle, der Preis ist Verantwortung. Umgekehrt: Wollen Sie, dass ein anderer diese Verantwortung für Sie trägt, bedeutet das meist, dass Sie ihm auch die Daten übergeben. Diese Rechnung hat keine kostenlose Seite; es kommt darauf an, welcher Preis für Sie tragbar und unterschreibbar ist.

Wie eine unterschreibbare Runtime aussieht

Drehen Sie die obigen Anforderungen um, und Sie haben die Abnahmeliste. Die direkteste Prüfung ist nicht der Blick in die Produktbroschüre, sondern ob das System an Ort und Stelle jene Aufzeichnung ausspucken kann, die der Prüfer will. Auf ObjectOS sieht jene Ablehnung vom Anfang, aufgerufen, so aus:

{
  "event": "claim.decision.update",
  "actor": { "type": "agent", "on_behalf_of": "user:risk.bot.supervised" },
  "object": "ins_claim/CLM-88231",
  "decision": { "from": "pending", "to": "rejected", "reason_code": "fraud_high" },
  "model_evidence": ["device_mismatch", "velocity_anomaly"],
  "permission_checked": "claims_adjuster → allowDecide: true",
  "human_review": { "rule": "fraud_high → muss menschlich gegengeprüft werden", "by": "user:wang.adjuster", "at": "2026-05-12T09:40:55Z" },
  "timestamp": "2026-05-12T09:31:02Z"
}

In dieser Aufzeichnung steht alles – wer, was getan, worauf die KI sich stützte, welche Berechtigung getroffen wurde, wer gegenprüfte, wann. Sie ist keine nachträglich nachgereichte Konstruktion, sondern eine Eintragung, die die Runtime nebenbei festhält, während der Agent in beaufsichtigter Identität ein governtes Werkzeug aufruft. Mensch und Agent durchlaufen dieselbe Berechtigungsengine und schreiben in dasselbe Log. Die Geschäftsdefinition (Objekte, Berechtigungen, Gegenprüfungsprozess) wiederum sind diffbare, nachvollziehbare Metadaten in Ihrem Repository – fragt der Prüfer „welche Schadenkategorie muss menschlich gegengeprüft werden”, liegt die Antwort nicht in jemandes Kopf, sondern steht in der Prozessdefinition geschrieben.

Schlusswort

Bis August sind es nur noch wenige Wochen. Zurück in jenen Konferenzraum: Wenn sich der Prüfer jetzt sofort setzte und von Ihnen den vollständigen Hergang einer KI-Entscheidung des letzten Monats verlangte – kann Ihr System ihn in diesem Augenblick ausspucken, ohne dass drei Teams drei Tage lang Logs durchwühlen?

Wenn Sie es nicht können, liegt es fast nie daran, dass das Modell untauglich ist, sondern daran, dass die Governance auf der falschen Schicht platziert wurde – in den Prompt gesteckt, an Regelwerksdokumente ausgelagert, statt in die Runtime gefallen. Verlagert man sie zurück in die Runtime, ist jene Beweiskette schon da, bevor Sie sie brauchen. Diese Sache lässt sich nicht nachholen, man kann sie nur jetzt sofort zur Tatsache machen.

npm i -g @objectstack/cli && os start

Lassen Sie einen Agent in der Identität eines bestimmten Nutzers einen Datensatz ändern und schlagen Sie dann das Audit-Log auf – Sie werden sehen, dass jene Linie, die der Prüfer will, von vornherein da war.