Souveräne KI
KI-Audit unter dem EU-KI-Gesetz: Was es erfordert
Niemand kann ein System prüfen, das keine Spuren hinterlassen hat. Das ist der einfache Satz hinter einer komplizierten Debatte. Der AI Act verlangt zwar Rückverfolgbarkeit, überlässt die Ausgestaltung der Audit-Rollen jedoch weitgehend den Sektoren und Mitgliedstaaten. Was nicht verhandelbar ist, ist die technische Voraussetzung. Ohne Protokolle, ohne Zugriffsnachweise und ohne Versionsverlauf scheitert jedes Audit, unabhängig davon, wer es wann durchführt.
Dieser Beitrag legt dar, was ein KI-Audit beinhaltet, welche Artikel welche Verpflichtung auslösen, wen die jeweilige Verpflichtung trifft und welche Infrastruktur ein Audit überhaupt erst möglich macht.
Der Zeitplan, vor allem anderen
Die KI-Verordnung, Verordnung (EU) 2024/1689, ist seit dem 1. August 2024 in Kraft. Die Verbote nach Artikel 5 und die Pflicht zur KI-Kompetenz nach Artikel 4 gelten seit dem 2. Februar 2025, die Verpflichtungen für KI mit allgemeinem Verwendungszweck und der Sanktionsrahmen seit dem 2. August 2025 und der Transparenzrahmen nach Artikel 50 seit dem 2. August 2026, vorbehaltlich der Omnibus-Übergangsregelung für maschinenlesbare Kennzeichnung nach Artikel 50 Absatz 2 (Europäische Kommission).
Der Hochrisiko-Katalog, den dieser Artikel betrifft, hat sich verschoben. Der Digital Omnibus zur KI, Verordnung (EU) 2026/1744, wurde am 24. Juli 2026 im Amtsblatt veröffentlicht und ist seit dem 27. Juli 2026 in Kraft (Europäische Kommission). Demnach gelten die Regeln für die in Anhang III aufgeführten Hochrisiko-Systeme ab dem 2. Dezember 2027 und jene für in physische Produkte eingebettete Hochrisiko-KI nach Anhang I ab dem 2. August 2028 (Europäische Kommission). Die Kernpflichten zur Transparenz nach Artikel 50 wurden nicht als Block verschoben: Die meisten gelten seit dem 2. August 2026, mit einer Übergangsfrist bis zum 2. Dezember 2026 für die Pflicht zur maschinenlesbaren Kennzeichnung nach Artikel 50 Absatz 2 für generative KI-Systeme, die vor diesem Datum in Verkehr gebracht wurden (Europäische Kommission; White & Case LLP). Seit dem 2. August 2026 müssen Organisationen weiterhin offenlegen, wenn Nutzer mit einem KI-System interagieren, Deepfakes und bestimmte KI-generierte Inhalte kennzeichnen sowie Personen benachrichtigen, die einer Emotionserkennung oder biometrischen Kategorisierung ausgesetzt sind (Europäische Kommission).
Aus diesem Grund argumentiert dieser Text nicht mit Dringlichkeit. Das Datum, an dem eine Verpflichtung greift, und das Datum, an dem die Infrastruktur vorhanden sein muss, sind zwei verschiedene Termine. Der zweite kommt zuerst.
Was ein KI-Audit ist
Der AI Act definiert „KI-Audit“ nicht als eine einzelne Rolle, und der Begriff bezieht sich je nach Kontext auf drei verschiedene Dinge.
Als Rolle bezeichnet er eine interne oder externe Partei, die ein System auf Konformität prüft. Der AI Act regelt die Konformitätsbewertung in Artikel 43 und das System der notifizierenden Behörden und notifizierten Stellen in den Artikeln 28 bis 39. Der AI Act schafft keine geschützte Berufsbezeichnung „KI-Auditor“. Interne Compliance-Funktionen, Wirtschaftsprüfer und spezialisierte technische Prüfer können diese Rolle gleichermaßen übernehmen, je nach System und Sektor.
Als Prozess bedeutet es systematische Risikobewertung, Überprüfung der Dokumentation und laufende Überwachung nach dem Inverkehrbringen. Der Prozess beginnt vor der produktiven Nutzung und erstreckt sich über den gesamten Lebenszyklus. Wesentliche Änderungen lösen eine erneute Bewertung aus (Artikel 43, AI Act Service Desk).
Als Infrastruktur bezeichnet es die technischen Voraussetzungen, die ein Audit erst möglich machen: Protokollierung, Zugriffskontrolle, Versionsnachweise. Diese dritte Bedeutung ist die einzige, die nicht delegiert werden kann. Eine Organisation kann die Rolle und den Prozess einkaufen. Die Infrastruktur muss sie selbst betreiben oder zumindest kontrollieren.
Welcher Artikel welche Verpflichtung auslöst
Präzision zahlt sich hier aus, da die im Umlauf befindlichen Zusammenfassungen routinemäßig zwei Artikel verwechseln.
Artikel 11: Technische Dokumentation. Sie muss vor dem Inverkehrbringen vorliegen und die in Anhang IV genannten Informationen abdecken. Die Aktualisierungspflicht ist das, was zählt: Systemänderungen, neue Modellversionen oder geänderte Nutzungsbedingungen erfordern eine Aktualisierung. Artikel 11 verlangt, dass die Dokumentation auf dem neuesten Stand gehalten wird; in der Praxis erfordern neue Modellversionen, Konfigurationsänderungen oder geänderte Nutzungsbedingungen entsprechende Versions- und Änderungsnachweise in der Audit-Akte, nicht optionale Metadaten (Artikel 11, AI Act Service Desk).
Artikel 12: Protokollierungsfunktion. Hochrisiko-KI-Systeme müssen technisch die automatische Aufzeichnung von Ereignissen während der gesamten Lebensdauer des Systems ermöglichen. Die Protokollierung muss ein dem Verwendungszweck angemessenes Maß an Rückverfolgbarkeit ermöglichen und Ereignisse abdecken, die für die Identifizierung von Situationen relevant sind, in denen das System ein Risiko darstellen oder eine wesentliche Änderung erfahren könnte, sowie die Überwachung nach dem Inverkehrbringen gemäß Artikel 72 erleichtern. Die Verordnung schreibt für die meisten Systeme kein Format und keine obligatorische Feldliste vor, sondern nur diese Zwecke (Artikel 12, AI Act Service Desk).
Artikel 19: Aufbewahrung durch den Anbieter. Anbieter bewahren die in Artikel 12 Absatz 1 genannten Protokolle, die ihre Hochrisiko-Systeme automatisch generieren, soweit diese Protokolle ihrer Kontrolle unterliegen, für einen für den Verwendungszweck angemessenen Zeitraum und mindestens sechs Monate auf, sofern das Unionsrecht oder das nationale Recht nichts anderes vorsieht. Anbieter, die Finanzinstitute sind, führen diese als Teil der nach dem Finanzdienstleistungsrecht aufzubewahrenden Dokumentation (Artikel 19, AI Act Service Desk).
Artikel 26 Absatz 6: Aufbewahrung durch den Betreiber. Die spiegelbildliche Pflicht auf Betreiberseite, ebenfalls mindestens sechs Monate für die seiner Kontrolle unterliegenden Protokolle, mit derselben Ausnahme für Finanzdienstleistungen (Artikel 26, AI Act Service Desk).
Kurz gesagt: Artikel 12 verlangt, dass das System protokollieren kann. Die Artikel 19 und 26 Absatz 6 verlangen, dass jemand die Protokolle aufbewahrt. Wer Artikel 19 als Quelle der Protokollierungspflicht anführt, verkennt die Struktur – und wird in einer Ausschreibung danach gefragt werden.
Zum weiteren Audit-Umfeld gehören auch Artikel 9 (Risikomanagementsystem), Artikel 10 (Daten-Governance), Artikel 14 (menschliche Aufsicht), Artikel 17 (Qualitätsmanagementsystem) und Artikel 72 (Überwachung nach dem Inverkehrbringen).
Anbieter oder Betreiber: Die Rollenfrage bestimmt alles andere
Diese Unterscheidung wird häufig falsch herum dargestellt, meist in der Form, dass die Konformitätspflicht beim Betreiber verbleibt und nicht an den Anbieter übertragen werden kann. Das stellt das System auf den Kopf.
Die Konformitätsbewertung ist eine Pflicht des Anbieters. Artikel 16 verpflichtet Anbieter sicherzustellen, dass ihr Hochrisiko-System vor dem Inverkehrbringen oder der Inbetriebnahme dem entsprechenden Konformitätsbewertungsverfahren nach Artikel 43 unterzogen wird, zusammen mit dem Qualitätsmanagementsystem nach Artikel 17 und der Protokollaufbewahrung nach Artikel 19. Der Betreiber hat eigene, engere Pflichten nach Artikel 26: Betrieb gemäß der Gebrauchsanweisung, Gewährleistung der menschlichen Aufsicht, Überwachung des Betriebs, Aufbewahrung von Protokollen.
Der Punkt, auf den die meisten dieser Texte abzielen, ist ein anderer und völlig korrekt: Man kann zum Anbieter werden, ohne selbst ein Modell entwickelt zu haben. Artikel 25 behandelt einen Händler, Importeur, Betreiber oder sonstigen Dritten als Anbieter, wenn diese ihren Namen oder ihre Marke auf einem bereits auf dem Markt befindlichen Hochrisiko-System anbringen, eine wesentliche Änderung vornehmen, die es als Hochrisiko-System belässt, oder den Verwendungszweck eines Systems (einschließlich eines Systems mit allgemeinem Verwendungszweck) so ändern, dass es zu einem Hochrisiko-System wird. Eine Organisation, die ein eingekauftes Modell unter eigenem Branding als internes Werkzeug für einen Zweck einführt, für den es nicht bestimmt war, hat sich somit möglicherweise den gesamten Anbieter-Katalog aufgeladen (Artikel 25, AI Act Service Desk).
Für die Beschaffung ergibt sich daraus eine konkrete Frage: Welche Rolle nehmen wir bei diesem System ein, und was müssten wir ändern, damit sich die Rolle ändert?
Was die Infrastruktur leisten muss
Vier Fähigkeiten tragen zur Auditierbarkeit bei. Keine davon kann nachträglich nachgerüstet werden, da jede Aufzeichnungen erzeugt, die später entweder existieren oder eben nicht.
Protokollierung auf Inference-Ebene
Ein prüfbares Protokoll beantwortet für jede Anfrage, wer sie gestellt hat, welches Modell in welcher Version geantwortet hat, zu welchem Zeitpunkt und unter welcher Autorisierung. Lücken sind kein technischer Makel; sie mindern den Beweiswert des gesamten Zeitraums. Wichtig ist auch, dass die Protokolle unter der Kontrolle der Organisation stehen, da die Aufbewahrungspflichten in Artikel 19 und Artikel 26 Absatz 6 genau daran anknüpfen.
Dokumentations- und Versionsnachweise
Die technische Dokumentation nach Artikel 11 ist nur so verlässlich wie der Nachweis, welchen Systemzustand sie beschreibt. Ohne einen Versionsverlauf der verwendeten Modelle und der aktiven Konfiguration lässt sich nicht nachweisen, dass die Dokumentation zum Zeitpunkt des Audits korrekt war.
Zugriffskontrolle und Richtliniendurchsetzung
Auditierbarkeit erfordert, dass das System jederzeit beantworten kann, wer unter welchen Bedingungen auf welches Modell zugreifen durfte. Rollenbasierte Zugriffskontrolle und Richtliniendurchsetzung auf Modellebene sind hier keine reinen IT-Sicherheitsmaßnahmen. Sie bilden den Kontext, der ein Protokoll erst aussagekräftig macht.
Kontrolle über die Ausführungsumgebung
Eine Organisation, die die Infrastruktur nicht kontrolliert, kontrolliert auch die Protokolle nicht vollständig. Dies ist kein Argument gegen externe Dienste an sich, sondern eine Frage des Beweisumfangs: Welche Aufzeichnungen liegen bei uns, welche beim Anbieter, und was könnten wir einer Aufsichtsbehörde aus eigener Kraft vorlegen?
Shadow AI: Der Teil, der sich dem Audit entzieht
Selbst die robusteste Audit-Infrastruktur erfasst nur das, was innerhalb ihrer Grenzen geschieht. Die Nutzung von KI außerhalb freigegebener Systeme, über öffentliche Endpunkte oder Consumer-Anwendungen, hinterlässt in der eigenen Infrastruktur keine Spuren. Es gibt kein Protokoll, keinen Zugriffsnachweis, keine Dokumentation.
Für die Pflicht zur KI-Kompetenz ist dies von direkter Bedeutung: Eine Organisation, die nicht weiß, welche Werkzeuge ihre Mitarbeiter tatsächlich nutzen, kann weder angemessen schulen noch nachweisen, dass sie dies getan hat. Beachten Sie, dass die Pflicht selbst eher entschärft als abgeschafft wurde. Seit dem 27. Juli 2026 müssen Anbieter und Betreiber Maßnahmen ergreifen, die den Aufbau von KI-Kompetenz unterstützen – unter Berücksichtigung von Wissen, Erfahrung, Ausbildung, Nutzungskontext und betroffenen Personen –, anstatt ein bestimmtes individuelles Niveau zu garantieren, und die Kommission sowie die Mitgliedstaaten nehmen nun eine stärkere Rolle bei der Förderung ein (Europäische Kommission).
Zu den Sanktionen, da hier sehr viele Falschinformationen kursieren: Die Obergrenze von 35 Millionen Euro oder 7 % des weltweiten Jahresumsatzes nach Artikel 99 Absatz 3 gilt bei Nichteinhaltung der Verbote nach Artikel 5. Verstöße gegen Hochrisiko- und Transparenzvorschriften liegen bei bis zu 15 Millionen Euro oder 3 % nach Artikel 99 Absatz 4. Den Höchstwert auf diese anzuwenden, ist der am weitesten verbreitete Fehler in Kommentaren zum AI Act. Die Liste in Artikel 99 Absatz 4 nennt die Pflicht zur KI-Kompetenz nicht, sodass es dafür keine eigene Stufe auf EU-Ebene gibt; die Mitgliedstaaten können jedoch eigene Regelungen nach Artikel 99 Absatz 1 erlassen (Artikel 99, AI Act Service Desk).
Die ursächliche Beobachtung gilt nach wie vor und ist der eigentliche Punkt: Organisationen, die es versäumen, eine konforme und wirklich nutzbare interne Alternative bereitzustellen, erzeugen Shadow AI selbst. Menschen suchen nach Werkzeugen, die funktionieren. Wo keine freigegebene Option existiert, bleibt die nicht freigegebene bestehen. Verbote ohne Alternative verlagern das Problem, anstatt es zu lösen.
Fazit
Auditierbarkeit entsteht nicht durch nachgelagerte Compliance-Arbeit. Sie entsteht durch Entscheidungen vor der produktiven Nutzung. Drei Schritte sind unabhängig vom Zeitplan sinnvoll:
Erstens: Bestandsaufnahme. Nicht nur der dokumentierten Systeme, sondern explizit dessen, was außerhalb der Governance läuft. Ohne dieses Bild ist jede Risikobewertung unvollständig.
Zweitens: Klärung der Rolle. Für jedes System: Anbieter oder Betreiber, und was würde diese Einstufung ändern?
Drittens: Konsolidierung. Bereitstellung, Governance und Protokollierung sind eine einzige Entscheidung. Wenn Sie diese als drei getrennte Projekte betreiben, werden Sie an der Integration scheitern – genau dann, wenn Nachweise verlangt werden.
Diese Entscheidung liegt nicht allein bei der IT. Der CISO, der Datenschutzbeauftragte und die Rechtsabteilung gehören an den Tisch, denn die Wahl des Betriebsmodells bestimmt den Rahmen dessen, was später überhaupt nachgewiesen werden kann.
Xinity bietet die Schicht um Open-Source-Modelle: Bereitstellung auf eigener Hardware, Durchsetzung von Zugriffsrichtlinien, Protokollierung jeder Inferenz mit Benutzeridentität, Zeitstempel und Modellversion. Testen Sie das 30-tägige Pilotprojekt auf Ihrer eigenen Infrastruktur, noch vor jeder langfristigen Verpflichtung.
Souverän durch Architektur, nicht durch Vertrag.
KI-Erklärung: Dieser Beitrag wurde mit KI-Unterstützung verfasst und vom Xinity-Team überprüft.