Zwei Tage Meldefrist: Wie Sie Ihren selbst gehosteten LLM-Stack für Artikel 73 protokollieren

Die meisten Compliance-Projekte scheitern nicht am Willen, sondern an der Uhr. Wenn ein Kreditantrag falsch abgelehnt, eine Bewerberauswahl diskriminierend getroffen oder eine Diagnoseunterstützung fehlerhaft war, beginnt die Frist des EU AI Act in dem Moment, in dem Ihr Unternehmen davon Kenntnis erlangt. Nicht in dem Moment, in dem Sie verstanden haben, was passiert ist. Und genau dazwischen liegt die Arbeit: Prompt rekonstruieren, Modellstand feststellen, Retrieval-Kontext nachvollziehen, Betroffene eingrenzen.

Dieser Beitrag beschreibt, welche Telemetrie ein selbst gehosteter LLM-Stack führen muss, damit eine Meldung nach Artikel 73 überhaupt fristgerecht möglich ist – und wie Sie dieses Log gestalten, ohne es selbst zum Datenschutzrisiko zu machen.

Die Fristen und wann welche gilt

Artikel 73 Absatz 1 verpflichtet Anbieter von Hochrisiko-KI-Systemen, schwerwiegende Vorfälle an die Marktüberwachungsbehörde des Mitgliedstaats zu melden, in dem der Vorfall eingetreten ist. Der Auslöser ist präzise formuliert: Gemeldet wird, sobald ein Kausalzusammenhang zwischen KI-System und Vorfall festgestellt ist – oder dessen hinreichende Wahrscheinlichkeit.

Frist	Rechtsgrundlage	Auslösendes Schadensbild
15 Tage	Art. 73 Abs. 2	Regelfall – jeder schwerwiegende Vorfall, gerechnet ab Kenntniserlangung
10 Tage	Art. 73 Abs. 4	Tod einer Person
2 Tage	Art. 73 Abs. 3	Weitverbreiteter Verstoß oder schwere und irreversible Störung kritischer Infrastruktur
7 Tage	Art. 73 Abs. 8	Reaktionsfrist der Behörde nach Eingang der Meldung – Maßnahmen nach VO (EU) 2019/1020

Der Titel dieses Beitrags nennt bewusst die härteste Stufe, aber die Reihenfolge sollte klar sein: 15 Tage sind der Normalfall, zwei Tage der Worst Case. Wer nur den Worst Case plant, baut zu teuer; wer nur den Normalfall plant, hat im Ernstfall kein Verfahren.

Was als schwerwiegender Vorfall gilt

Artikel 3 Nummer 49 definiert vier Folgen, von denen eine eintreten muss: Tod oder schwere gesundheitliche Schädigung einer Person, schwere und irreversible Störung des Betriebs kritischer Infrastruktur, Verletzung von Grundrechtsschutzpflichten des Unionsrechts oder schwerer Sach- beziehungsweise Umweltschaden. Entscheidend für die Praxis: Der Leitlinienentwurf der Kommission stellt ausdrücklich klar, dass ein indirekter Kausalzusammenhang genügt. Eine fehlerhafte KI-Analyse, die erst über eine nachgelagerte ärztliche Entscheidung zum Schaden führt, zählt ebenso wie eine auf fehlerhafter KI-Bewertung beruhende Kreditablehnung oder eine diskriminierende KI-gestützte Bewerberauswahl.

Wann die Uhr tatsächlich zu ticken beginnt

Der Digital Omnibus wurde am 24. Juli 2026 im EU-Amtsblatt veröffentlicht und trat am 27. Juli 2026 in Kraft. Damit gelten die Regeln für eigenständige Hochrisiko-KI-Systeme nach Anhang III erst ab dem 2. Dezember 2027, die für in Produkte eingebettete Hochrisiko-Systeme nach Anhang I erst ab dem 2. August 2028. Die Artikel-73-Meldepflicht hängt an diesem Hochrisiko-Regime – die Zwei-Tage-Uhr läuft für Hochrisiko-Anbieter also nicht seit dem 2. August 2026, sondern erst ab diesen Terminen.

Für ein mittelständisches Unternehmen bedeutet das rund fünfzehn Monate Vorlauf. Das klingt nach viel und ist es nicht: Ein Audit-Log, das im Dezember 2027 sechs Monate Historie vorweisen muss, muss spätestens im Frühsommer 2027 produktiv laufen – inklusive Retention, Zugriffskonzept und Betriebsvereinbarung.

Was in einer Meldung stehen muss

Die Europäische Kommission hat am 26. September 2025 den Entwurf der Guidance on Article 73 AI Act – Incident Reporting samt Meldeformular-Vorlage veröffentlicht; die öffentliche Konsultation lief bis zum 7. November 2025. Die finale Fassung war für die Anwendung ab dem 2. August 2026 vorgesehen. Alle Feldangaben in diesem Abschnitt beziehen sich auf diesen Entwurfsstand und sollten vor dem Produktivgang gegen die dann geltende Endfassung abgeglichen werden.

Die Vorlage verlangt im Kern vier Blöcke:

1. Systemidentifikation: Bezeichnung, Zweckbestimmung, eingesetzte Version, Anbieter- und Betreiberrolle, betroffene Mitgliedstaaten.
2. Vorfallbeschreibung: Zeitpunkt des Eintritts, Zeitpunkt der Kenntniserlangung, Ablauf, Zahl und Kategorie der betroffenen Personen, eingetretene Folge nach Art. 3 Nr. 49.
3. Ursachenhypothese: vermuteter Kausalzusammenhang, betroffene Komponente, Konfigurations- und Modellstand zum Vorfallzeitpunkt.
4. Maßnahmen: Sofortmaßnahmen, geplante Korrekturmaßnahmen, Angaben zur Aufrechterhaltung der Beweislage.

Absatz 5 ist die Entlastung, die viele übersehen: Um die Frist zu wahren, darf ein unvollständiger Erstbericht abgegeben und später durch einen vollständigen Bericht ergänzt werden. Die Frist zwingt Sie also nicht zur fertigen Root-Cause-Analyse – sie zwingt Sie dazu, überhaupt zu wissen, dass etwas passiert ist, und den Vorfall grob einzugrenzen.

Doppelmeldewege sauber trennen

Der Kommissionsentwurf sieht ein vereinfachtes Regime für Sektoren mit bereits bestehenden, gleichwertigen Meldepflichten vor – etwa kritische Infrastruktur unter der NIS-2-Richtlinie (EU) 2022/2555. Dort soll Artikel 73 nur noch für Grundrechtsverletzungen greifen, alle übrigen Vorfälle laufen über die sektorspezifischen Regeln. In der Praxis heißt das: Ihr Runbook muss vier Meldewege getrennt führen – DSGVO Art. 33 mit 72 Stunden, NIS-2, gegebenenfalls DORA und den AI Act – aber alle vier aus derselben Log-Quelle bedienen können. Ein Vorfall, der drei Meldungen mit widersprüchlichen Zeitstempeln erzeugt, ist ein Compliance-Problem für sich.

Nach der Meldung: Untersuchung mit eingefrorenem Stand

Artikel 73 Absatz 6 verlangt, nach der Meldung unverzüglich die erforderlichen Untersuchungen durchzuführen, eine Risikobewertung vorzunehmen und Korrekturmaßnahmen zu ergreifen. Der Leitlinienentwurf konkretisiert das mit einer für Betreiber sehr konkreten Auflage: Während der Untersuchung darf das KI-System nicht so verändert werden, dass die spätere Analyse beeinträchtigt wird, ohne die Behörden vorher zu informieren. Wer in dieser Phase Modell, System-Prompt oder Guardrail-Policy überschreibt, vernichtet Beweise – das ist das stärkste Argument für unveränderliche Logs und eingefrorene Versionsstände.

Warum SaaS-APIs die Meldung praktisch erschweren

Vorab die Einordnung, die in vielen Marketingtexten fehlt: Der AI Act verlangt kein On-Premise. Eine Cloud-API ist nicht rechtswidrig. Belastbar ist eine schwächere, aber praktisch relevantere Aussage – aus Art. 12 (Protokollierungsfähigkeit), Art. 19 und Art. 26 Abs. 6 (Aufbewahrung) sowie Art. 73 Abs. 6 (unveränderte Beweislage) folgt ein Anforderungsprofil, das viele SaaS-Angebote schlicht nicht erfüllen.

Drei Punkte, an denen es in der Praxis bricht:

• Retention: Art. 19 verpflichtet Anbieter, die automatisch erzeugten Logs für einen der Zweckbestimmung angemessenen Zeitraum aufzubewahren, mindestens aber sechs Monate, soweit Unionsrecht oder nationales Recht nichts anderes vorsieht. Dieselbe Mindestfrist gilt nach Art. 26 Abs. 6 für Betreiber. Ein Anbieter, der Request-Logs nach 30 Tagen löscht oder gar nicht exportierbar macht, macht diesen Nachweis für Sie unmöglich.
• Versionsdrift: Ein Modell-Alias hinter einer API kann sich ohne Ihre Kenntnis ändern. Wenn Sie im Meldeformular den „Konfigurationsstand zum Vorfallzeitpunkt" angeben sollen, brauchen Sie eine unveränderliche Referenz – nicht den Namen eines Endpunkts.
• Beweiskette: Was der Provider intern gefiltert, umgeschrieben oder gecacht hat, endet an der API-Grenze. Ihre Rekonstruktion beginnt dort, wo die relevante Verarbeitung schon vorbei ist.

Wer den Stack selbst betreibt, hat diese Probleme nicht – dafür die Pflicht, das Logging selbst zu bauen. Und Achtung bei der Rollenfrage: Meldepflichtig nach Art. 73 ist der Anbieter. Betreiber melden nicht selbst, sondern informieren nach Art. 26 Abs. 5 unverzüglich zuerst den Anbieter, dann Einführer oder Händler und die Marktüberwachungsbehörde. Wer ein Open-Weight-Modell selbst betreibt, es anpasst und unter eigenem Namen bereitstellt, rutscht allerdings häufig in die Anbieterrolle – mit allen Pflichten, die daran hängen.

Referenzarchitektur für das Audit-Log

Das Ziel ist ein strukturiertes, append-only geschriebenes Ereignisprotokoll, aus dem sich jeder einzelne Inferenzaufruf forensisch rekonstruieren lässt, ohne dass der Klartext der Konversation im Log liegt. Bewährt hat sich ein Datensatz pro Aufruf mit folgenden Feldern:

Feld	Beispielwert	Wofür in der Meldung
trace_id	01JD7K…	Verkettung über alle Agentenschritte hinweg
ts_utc	2026-08-25T09:14:02.881Z	Zeitpunkt des Vorfalls, NTP-synchron
prompt_sha256	9f3c1a…	Nachweis der Identität einer Eingabe ohne Klartext
model_digest	sha256:4b8e… (GGUF)	Konfigurationsstand zum Vorfallzeitpunkt
sysprompt_ver	sp-2026.07-r3	Nachvollzug von Verhaltensänderungen
policy_ver / decision	pii.v4 · block	Wirksamkeit der Schutzmaßnahmen
retrieval_refs	[doc:4711#p12, doc:889#p3]	Ursachenhypothese bei falschem Kontext
subject_pseudonym	psd:a91f · role:sachbearb	Eingrenzung betroffener Personen

Technisch ist das kein Sonderweg, sondern gute LLMOps-Praxis. Ein Gateway vor dem Inferenzserver schreibt die Events als JSON Lines, ein Collector legt sie in einen WORM-Bucket (etwa MinIO mit Object Lock im Compliance-Modus oder ein S3-kompatibler Speicher mit Retention-Policy). Der Speicherbedarf ist erfreulich unspektakulär: Bei rund 600 Byte pro Ereignis und 50.000 Aufrufen am Tag ergibt das etwa 30 MB pro Tag, also rund 5,5 GB für die sechs Monate Mindestaufbewahrung – Größenordnung eines einzigen Datenbank-Backups.

Pseudonymisierung und Zweckbindung im Log

Ein Audit-Log, das jede Nutzereingabe im Klartext konserviert, ist kein Compliance-Werkzeug, sondern ein Datenleck mit Aufbewahrungspflicht. Artikel 19 nennt die sechs Monate ausdrücklich unter dem Vorbehalt entgegenstehenden Datenschutzrechts – längere Aufbewahrung kann also datenschutzrechtlich unzulässig sein. Die Auflösung liegt in der Trennung von Nachweis und Inhalt:

• Hashes statt Klartext als Default. Der Prompt-Hash beweist, dass eine bestimmte Eingabe zu einer bestimmten Zeit verarbeitet wurde. Für die Erstmeldung reicht das fast immer.
• Klartext nur zweckgebunden und befristet. Wenn eine Untersuchung nach Art. 73 Abs. 6 die tatsächlichen Inhalte braucht, wird ein separater, verschlüsselter Kurzzeitspeicher (etwa 14 bis 30 Tage) mit Vier-Augen-Freigabe geöffnet – nicht das Dauer-Log.
• Rollen statt Klarnamen. Im Log steht role:sachbearbeiter_einkauf plus Pseudonym; das Mapping auf die reale Identität liegt in einem getrennten System mit eigenem Zugriffskonzept.
• Zugriff auf das Log protokollieren. Wer die Beweismittel liest, muss selbst nachvollziehbar sein – sonst ist die Beweiskraft im Streitfall angreifbar.
• Löschkonzept dokumentieren. Aufbewahrungsfrist, Löschmechanik und Ausnahmen für laufende Untersuchungen gehören ins Verzeichnis der Verarbeitungstätigkeiten.

Für Auswertungen über das Log – Fehlerraten, Guardrail-Trefferquoten, Drift-Analysen – reichen aggregierte Kennzahlen. Wer diese Auswertungen zusätzlich absichern will, kann Aggregate mit Techniken der Differential Privacy verrauschen; für die meisten Mittelständler ist das allerdings deutlich mehr Aufwand als Nutzen, solange Rollen- und Zugriffstrennung sauber sitzt.

Alerting: Schwellen, die eine Frist überhaupt auslösen

Ein sauberes Log ohne Auswertung ist ein Archiv, kein Frühwarnsystem. Und hier lauert ein weit verbreiteter Denkfehler: Schlechtes Monitoring verschiebt den Fristbeginn nicht zu Ihren Gunsten. Die Frist beginnt mit Kenntniserlangung – wer aber erst spät hinsieht, hat am Ende dasselbe Nachweisproblem, plus die Frage der Behörde, warum die Erkennung so lange gedauert hat.

Praktikable Trigger, die sich aus den oben beschriebenen Feldern direkt ableiten lassen:

1. Guardrail-Blockrate: Anstieg über den 7-Tage-Median hinaus, etwa Faktor 3 in einer Stunde – deutet auf Missbrauch oder Prompt-Injection-Wellen hin.
2. Grundrechtsrelevante Kategorien: Jeder Treffer eines Klassifikators für diskriminierende Ausgaben, Bonitäts- oder Bewerberkontexte geht sofort in die Sichtung, nicht in ein Dashboard.
3. Versionswechsel ohne Freigabe: Änderung von model_digest, sysprompt_ver oder policy_ver außerhalb eines freigegebenen Change-Fensters.
4. Retrieval-Anomalien: Antworten ohne jede Quellreferenz oder mit Quellen außerhalb der berechtigten Mandantengrenze.

Dazu gehört ein Eskalationspfad mit benannten Rollen statt Funktionspostfächern: wer sichtet (Betrieb), wer bewertet (Datenschutz plus Fachbereich), wer die Meldung freigibt (Geschäftsführung) und wer sie einreicht. Definieren Sie außerdem, wann eine Meldung im Zweifel abgesetzt wird – Art. 73 Abs. 5 erlaubt den unvollständigen Erstbericht, eine verpasste Frist erlaubt nichts. Systematische Evaluation im Regelbetrieb hilft zusätzlich, weil sie Ihnen eine Baseline gibt, gegen die Anomalien überhaupt erst erkennbar werden.

Probelauf: den Ernstfall einmal durchspielen

Der wirksamste Test kostet einen halben Tag und zeigt in der Regel binnen einer Stunde, welche Felder fehlen. Ablauf:

1. Fiktiven Vorfall definieren. Beispiel: „Am 14. des Vormonats hat der Assistent in einem Bewerberkontext eine diskriminierende Empfehlung ausgegeben; eine betroffene Person hat sich beschwert." Wählen Sie bewusst ein Datum, das mehr als vier Wochen zurückliegt – frische Vorfälle finden sich immer.
2. Rekonstruktion versuchen. Ohne Rückgriff auf Personen, die dabei waren: Welcher Modellstand lief? Welche Policy-Version? Welche Dokumente lagen im Kontext? Wie viele weitere Aufrufe traf dasselbe Muster?
3. Formular füllen. Nehmen Sie die Vorlage aus dem Kommissionsentwurf und tragen Sie ein, was Sie belegen können. Alles, was Sie nur vermuten, wird markiert.
4. Lücken schließen. Jede Markierung ist ein Backlog-Ticket im Logging – typischerweise drei bis sechs Felder.
5. Ergebnis ablegen. Protokoll, Datum, Teilnehmer, gefundene Lücken, umgesetzte Maßnahmen. Das ist Ihr Nachweis der Sorgfalt und zugleich der Beleg, dass Ihr Verfahren geübt ist.

Zwei Fristen sollten Sie dabei mitdenken, die nach der Meldung greifen: Die Marktüberwachungsbehörde muss nach Art. 73 Abs. 8 innerhalb von sieben Tagen geeignete Maßnahmen ergreifen. Und wenn sie Korrekturmaßnahmen fordert, muss der betroffene Wirtschaftsakteur nach Art. 79 Abs. 2 innerhalb der von der Behörde gesetzten Frist handeln – in jedem Fall innerhalb der kürzeren Frist von 15 Arbeitstagen oder der in einschlägigem Harmonisierungsrecht vorgesehenen Frist. Wer bis dahin kein Verfahren für Rollback, Sperrung oder Rückruf einer Modellversion hat, gerät in die nächste Fristverletzung.

Wiederholen Sie den Probelauf halbjährlich. Der zweite Durchlauf dauert erfahrungsgemäß ein Drittel der Zeit des ersten – und genau diese Differenz ist der Unterschied zwischen einer fristgerechten und einer verpassten Meldung.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.

1. AI Act Explorer – Artikel 73 Meldung schwerwiegender Vorfälle, Fristen Abs. 2 bis 8
2. Latham & Watkins – Draft Guidance Reporting Serious AI Incidents (PDF) Analyse des Leitlinienentwurfs, indirekte Kausalität, NIS-2-Abgrenzung
3. Europäische Kommission – Konsultation zum Entwurf und Meldeformular Entwurf vom 26.09.2025, Konsultation bis 07.11.2025
4. AI Act Service Desk – Umsetzungs-Timeline Geltungstermine nach dem Digital Omnibus
5. Gibson Dunn – EU AI Act Omnibus: Postponed High-Risk Deadlines Verschiebung auf 02.12.2027 und 02.08.2028
6. DLA Piper – Digital AI Omnibus: Deferral of High-Risk Obligations Einordnung der Fristverschiebung für Anhang I und III
7. AI Act Explorer – Artikel 79 15 Arbeitstage für Korrekturmaßnahmen des Wirtschaftsakteurs
8. AI Act Explorer – Artikel 99 Bußgeldrahmen, KMU-Regel nach Abs. 6
9. AI Act Explorer – Artikel 19 Aufbewahrung automatisch erzeugter Logs, mindestens sechs Monate
10. AI Act Explorer – Artikel 26 Betreiberpflichten, Abs. 5 Informationskette, Abs. 6 Log-Aufbewahrung
11. AI Act Explorer – Enforcement of Chapter V Kommissionsbefugnisse nach Art. 91 bis 93 seit 02.08.2026
12. JURIST – Tighter EU Oversight for AI Companies Durchsetzungsstart 02.08.2026
13. Rat der EU – Einigung zur Vereinfachung der KI-Regeln Politische Einigung zum Omnibus-Paket

Häufig gestellte Fragen zu Artikel 73

Wann gilt die Zwei-Tage-Frist?

Bei weitverbreiteten Verstoessen oder einer schweren, irreversiblen Stoerung kritischer Infrastruktur. Der Regelfall sind 15 Tage, bei moeglichem Todesfall 10 Tage.

Muessen wir Prompts im Klartext speichern?

Nein und in der Regel sollten Sie es nicht. Hashes plus Metadaten reichen fuer die Rekonstruktion; Klartext nur zweckgebunden, befristet und mit Zugriffsprotokoll.

Gilt Artikel 73 auch fuer Betreiber, nicht nur Anbieter?

Betreiber treffen eigene Informations- und Mitwirkungspflichten. Wer ein Open-Weight-Modell selbst betreibt, rutscht zudem haeufig in die Anbieterrolle.

Was passiert bei falschen oder unvollstaendigen Angaben?

Falsche oder unvollstaendige Angaben gegenueber Behoerden sind eigenstaendig bussgeldbewehrt - mit bis zu 7,5 Mio. Euro oder 1 Prozent des Jahresumsatzes.