EU-KI-Gesetz (AI Act) in der Praxis: GPAI-Modelle, Audit-Trails und technische Umsetzung
Executive Summary
- ✓Gestaffelte Durchsetzung bis 2027: Nach den Verboten unzulässiger Praktiken (Februar 2025) und den GPAI-Pflichten (August 2025) greifen ab August 2026 die vollen Anforderungen für Hochrisiko-KI-Systeme nach Anhang III bei Bußgeldern bis 35 Millionen Euro oder 7 Prozent des Weltumsatzes.
- ✓Kapitel V (Art. 51 **bis 55) für GPAI-Modelle: Das Open-Weights-Privileg nach Artikel 53 Absatz 2 befreit zwar quelloffene Basismodelle unterhalb der Systemrisiko-Schwelle von 10^25 FLOPs von Dokumentationspflichten, entbindet aber niemals das betreibende Unternehmen bei Hochrisiko-Anwendungen.
- ✓Revisionssichere Telemetrie nach Artikel 12: Hochrisiko- und kritische Enterprise-KI-Systeme erfordern lückenlose, kryptografisch verkettete Audit-Trails über System-Prompts, RAG-Vektor-Chunks, Modell-Hashes, Temperatur-Parameter und Tool-Calls mittels OpenTelemetry und S3-Object-Lock (WORM).
- ✓Über 60 Prozent TCO*-Vorteil durch eigenes AI-Gateway: Ein selbst gehosteter Governance-Stack aus LiteLLM, Langfuse, ClickHouse und Ceph/MinIO vermeidet unkontrollierten Datenabfluss an US-Clouds und senkt die Fünfjahreskosten gegenüber proprietären Enterprise-Compliance-Add-ons drastisch.
Mit der Verordnung (EU) 2024/1689 hat die Europäische Union das weltweit erste horizontal verbindliche Produktsicherheits- und Infrastrukturrecht für künstliche Intelligenz geschaffen. Was in vielen Vorstandsetagen zunächst als reine Dokumentationsaufgabe für die Rechtsabteilung galt, erweist sich in der Praxis als tiefgreifende Architekturvorgabe für Rechenzentren, Datenpipelines und Engineering-Teams.
Das Gesetz verabschiedet sich von unverbindlichen Ethik-Leitlinien und koppelt die Zulässigkeit eines KI-Einsatzes direkt an die Risikoklasse des jeweiligen Anwendungsfalls. Während unvertretbare Praktiken wie Social Scoring oder Emotionserkennung am Arbeitsplatz nach Artikel 5 seit Februar 2025 untersagt sind, stehen für CIOs zwei zentrale Säulen im Fokus.
Kapitel V (Artikel 51 bis 55) regelt seit August 2025 den Umgang mit KI-Modellen mit allgemeinem Verwendungszweck (General-Purpose AI, kurz GPAI). Ab August 2026 greifen zudem die strengen Pflichten für Hochrisiko-Systeme nach Kapitel III, darunter Personal-Recruiting, Kreditwürdigkeitsprüfung, Versicherungsmathematik und kritische Infrastrukturen. Wie sich dies in NIS-2, DORA und Data Act einfügt, zeigt unser Leitfaden zum europäischen Regulierungsrahmen für IT-Entscheider.
Kapitel V im Detail: GPAI-Modelle, die 10^25-FLOPs-Schwelle und das Open-Weights-Privileg
In der Praxis ist zunächst zwischen einem Basismodell mit allgemeinem Verwendungszweck (GPAI-Modell) und dem darauf aufbauenden KI-System zu unterscheiden. Ein GPAI-Modell wie GPT-4o, Claude 3.5, Llama 3 oder Mistral Large ist ein vielseitiges Fundament, das erst durch System-Prompts, Retrieval-Augmented Generation (RAG) und Funktionsaufrufe zum zweckgebundenen KI-System wird.
Kapitel V adressiert Pflichten direkt an die Modellanbieter und differenziert nach der Trainingsrechenleistung. Gemäß Artikel 51 Absatz 2 gilt ein GPAI-Modell als Modell mit systemischem Risiko, sobald die kumulierte Trainings-Rechenleistung den Schwellenwert von 10 hoch 25 Gleitkommaoperationen (10^25 FLOPs) überschreitet oder die Kommission es entsprechend einstuft.
Alle GPAI-Anbieter müssen nach Artikel 53 technische Unterlagen für nachgelagerte Systemintegratoren (Downstream Deployers) bereitstellen, den EU-Urheberrechtsvorbehalt nach Artikel 4 Absatz 3 der DSM-Richtlinie achten und eine Zusammenfassung der Trainingsdaten veröffentlichen. Ab der Grenze von 10^25 FLOPs verlangt Artikel 55 zusätzlich verpflichtendes Red-Teaming, Vorfallmeldungen an das EU AI Office und strengen Schutz der Modellgewichte.
Open-Weights-Ausnahme nach Artikel 53 Absatz 2 und Rollenverschiebung nach Artikel 25
Für Unternehmen, die aus Gründen der digitalen Souveränität und Datenhoheit auf offene Sprachmodelle setzen, enthält Artikel 53 Absatz 2 eine wichtige Erleichterung. Werden Modellgewichte, Architektur und Nutzungsinformationen unter einer freien Lizenz veröffentlicht, entfallen unterhalb der 10^25-FLOPs-Schwelle weite Teile der Behördendokumentation auf Modellebene, während Trainingsdaten-Zusammenfassung und Urheberrechtspflicht bestehen bleiben.
Besonders kritisch für interne Engineering-Teams ist jedoch die Rollenverschiebung nach Artikel 25. Nutzt ein Unternehmen ein GPAI-Modell unverändert über Prompting und RAG, bleibt es rechtlich Betreiber (Deployer). Modifiziert das Team jedoch ein Modell für einen Hochrisiko-Zweck nach Anhang III wesentlich, etwa durch tiefgreifendes Fine-Tuning via LoRA oder QLoRA, wird das Unternehmen selbst zum gesetzlichen Anbieter (Provider).
Architektonischer Blindspot: Unbeabsichtigte Anbieter-Rolle durch Fine-Tuning und flüchtige API-Logs
Viele Teams trainieren offene Basismodelle per Fine-Tuning auf internen Kredit-, Bewerber- oder Schadensdaten nach, ohne zu beachten, dass sie dadurch gemäß Artikel 25 selbst zum gesetzlichen Anbieter eines Hochrisiko-KI-Systems werden. Gleichzeitig verlassen sich Unternehmen bei Cloud-APIs auf Standard-Dashboards, die nach 30 Tagen überschrieben werden und weder abgerufene RAG-Fragmente noch Modell-Snapshots speichern, was gegen die sechsmonatige Aufbewahrungspflicht nach Artikel 19 verstößt.
Um diese Haftungsrisiken frühzeitig einzugrenzen, erfordert jede Modellanpassung eine formale Architekturprüfung. Welche persönlichen Sorgfaltspflichten für Vorstände und Geschäftsführer aus dem Zusammenspiel von KI-Verordnung und Cybersicherheitsrecht resultieren, analysieren wir im Beitrag zur Organhaftung unter NIS-2 und EU AI Act.
Ergänzende Architektur-Analysen und technische Entscheidungsmatrizen für Ihre IT-Planung finden Sie in unseren weiterführenden Leitartikeln zu Enterprise KI-Strategie im Enterprise-Einsatz, zu DeepSeek On-Premises im Enterprise-Einsatz sowie zu Autonome KI-Agenten im Enterprise-Einsatz.
Technischer Deep-Dive: Unveränderbare Audit-Trails nach Artikel 12 und Artikel 19 implementieren
In der technischen Umsetzung verlangen Artikel 12 (Aufzeichnungspflichten) und Artikel 19 (Automatisch erzeugte Protokolle) eine belastbare Telemetrie-Architektur. Hochrisiko-KI-Systeme müssen Ereignisse (Logs) über ihren gesamten Lebenszyklus automatisch protokollieren, um Risiken im Betrieb zu erkennen, Entscheidungen forensisch nachzuvollziehen und die menschliche Aufsicht nach Artikel 14 zu gewährleisten.
Bei probabilistischen Sprachmodellen und agentischen Workflows, die über Vektordatenbanken auf Unternehmenswissen zugreifen und API-Werkzeuge (Tool-Calling) ausführen, reicht ein herkömmliches Server-Log nicht aus. Jede Inferenz-Transaktion muss über ein zentrales AI-Gateway und eine Observability-Schicht (OpenTelemetry GenAI Semantic Conventions und selbst gehostetes Langfuse) als strukturierter JSON-Trace mit fünf Pflichtelementen erfasst werden.
Die fünf Pflichtfelder eines AI-Act-konformen Inferenz-Protokolls und WORM-Speicherung
Erstens muss das Protokoll die exakte Modell-Identität samt Versions-Revision oder kryptografischem SHA-256-Hash der Modellgewichte (etwa bei vLLM-Deployments) sowie alle Sampling-Parameter wie Temperature, Top-P und Seed-Wert erfassen. Zweitens werden Benutzereingabe und das assemblierte System-Prompt-Template samt Versionsnummer gespeichert, wobei eine vorgelagerte PII-Maskierung (etwa Microsoft Presidio) Klarnamen DSGVO-konform pseudonymisiert.
Drittens erfordert Retrieval-Augmented Generation (RAG) die Speicherung des exakten Abruf-Kontexts. Da sich Vektordatenbanken wie Qdrant oder Milvus laufend ändern, hält der Trace Dokumenten-IDs, Versions-Zeitstempel, Similarity Scores und den Wortlaut der injizierten Text-Chunks fest. Den datenschutzkonformen Aufbau beschreibt unser Leitfaden für lokale LLMs und Enterprise-RAG mit voller Datensouveränität.
„Ein KI-System ohne kryptografisch gesicherten Audit-Trail über Prompts, abgerufene RAG-Fragmente und Modell-Hashes ist unter dem EU AI Act ein unversicherbares Blindflug-System: Erst deterministische Telemetrie macht probabilistische Modelle im Unternehmensbetrieb beherrschbar und revisionsfähig.“
Viertens werden bei agentischen Systemen alle Funktionsaufrufe (Tool-Calls), übergebenen JSON-Parameter und Rückgabewerte angebundener ERP- oder CRM-Systeme als Child-Spans im OpenTelemetry-Trace gespeichert. Fünftens dokumentiert der Trace gemäß Artikel 14 den Human-in-the-Loop-Entscheid, also welcher berechtigte Sachbearbeiter den KI-Vorschlag geprüft, freigegeben oder übersteuert hat.
Um die gesetzliche Mindestaufbewahrungsfrist von sechs Monaten nach Artikel 19 Absatz 1 und Artikel 26 Absatz 6 manipulationssicher zu erfüllen, werden die in Langfuse und ClickHouse gesammelten Traces stündlich über SHA-256-Merkle-Trees kryptografisch verkettet. Anschließend werden diese Pakete im Parquet-Format auf einen lokalen Ceph- oder MinIO-Objektspeicher mit aktiviertem S3-Object-Lock (WORM) geschrieben.
Architektur- und Compliance-Matrix: Die Risikoklassen und GPAI-Pflichten im technischen Vergleich
Damit Architektur-Boards ihre KI-Workloads belastbar einstufen können, müssen juristische Normkategorien direkt in konkrete Infrastruktur-Anforderungen übersetzt werden. Die folgende Bloomberg-Radar-Matrix stellt die fünf zentralen Regulierungsstufen der Verordnung (EU) 2024/1689 samt Stichtagen und technischer Pflichtarchitektur gegenüber:
| Regulierungsstufe & Normartikel | Typische Enterprise-Workloads & Schwellenwerte | Technische Pflichtarchitektur im Betrieb | CIO-Bewertung |
|---|---|---|---|
| 1. Verbotene KI-Praktiken (Art. 5, seit 02/2025) | Emotionserkennung am Arbeitsplatz, Social Scoring, unterschwellige Verhaltensmanipulation, ungezieltes Gesichts-Scraping. | Vollständige technische Sperrung über API-Gateways; sofortige Abschaltung betroffener Schatten-IT-Tools und Drittanbieter-Plugins. |
Bis 35 Mio. € StrafeNull-Toleranz / Sperrpflicht
|
| 2. Hochrisiko-KI nach Anhang III (Art. 6-49, ab 08/2026) | Bewerber-Screening (HR), Kredit-Scoring, Versicherungs-Tarifierung, kritische Infrastruktursteuerung, Bildungsbewertung. | Lückenlose Ereignisprotokollierung (Art. 12), WORM-Speicherung ab 6 Monaten (Art. 19), Human-in-the-Loop-Freigabe (Art. 14), Robustheitstests. |
Höchste Audit-TiefeOTel + WORM-Storage Pflicht
|
| 3. GPAI-Modelle mit Systemrisiko (Art. 51 & 55, seit 08/2025) | Proprietäre und offene Frontier-Modelle mit einer Trainings-Rechenleistung von mehr als 10^25 FLOPs oder Kommissions-Einstufung. | Adversariales Red-Teaming, Meldung schwerwiegender Vorfälle an das EU AI Office, gehärteter Schutz der Modellgewichte und API-Endpunkte. |
Strikte Provider-LastAbhängigkeit über Gateway kapseln
|
| 4. Offene GPAI-Modelle (Open Weights, Art. 53 Abs. 2) | Quelloffene Basismodelle (z. B. Llama- oder Mistral-Derivate unterhalb 10^25 FLOPs) im eigenen Rechenzentrum via vLLM. | Befreiung von der Behördendokumentation auf Modellebene; volle Datenhoheit ohne US-Telemetrie; Hochrisiko-Pflichten gelten nur bei Anhang-III-Einsatz. |
Souveränes PrivilegIdeale Enterprise-Basis
|
| 5. Transparenzpflichtige Systeme (Art. 50, ab 08/2026) | Kunden-Chatbots, KI-generierte Texte, Audio- und Video-Inhalte (Deepfakes), interne Wissensassistenten ohne Grundrechtseingriff. | Maschinenlesbare Wasserzeichen und kryptografische Herkunftsnachweise (C2PA-Metadaten) sowie eindeutige Kennzeichnung der KI-Interaktion im UI. |
Geringer AufwandUI-Labeling & C2PA-Signatur
|
Aus der Matrix wird der strategische Hebel für die IT-Architektur deutlich: Ein zentrales, selbst kontrolliertes AI-Gateway fungiert als einheitlicher Policy Enforcement Point. Es blockiert unzulässige Praktiken technisch und stattet Hochrisiko-Workflows automatisch mit der vollen OpenTelemetry- und WORM-Protokollierung nach Artikel 12 aus.
Vollkostenrechnung über 60 Monate: Proprietäre Cloud-Governance versus souveräner AI-Audit-Stack
Die Wahl der Telemetrie-Architektur bestimmt maßgeblich die Fünfjahres-Gesamtkosten (TCO) der KI-Plattform. Wir betrachten als Referenz ein Unternehmen mit 2.500 Mitarbeitenden, das zwölf produktive KI-Fachanwendungen (darunter drei Hochrisiko-Workflows in HR, Kreditprüfung und Schadensregulierung) mit monatlich 150 Millionen Token und 1,2 Millionen Inferenz-Spans betreibt.
Im proprietären Cloud-Szenario summieren sich Lizenzaufschläge für verwaltete Guardrails, volumenbasierte Observability-Plattformen (Abrechnung pro Span und Gigabyte) sowie Cloud-Compliance-Speicher auf durchschnittlich 16.300 Euro pro Monat. Über 60 Monate entsteht allein für die Logging- und Governance-Schicht ein Mittelabfluss von rund 980.000 Euro bei gleichzeitigem Datenabfluss in Drittstaaten.
Ein souveräner Open-Source-Stack aus LiteLLM, selbst gehostetem Langfuse auf Kubernetes, ClickHouse und Ceph/MinIO-WORM-Storage verursacht inklusive Enterprise-Support, Speicherplatz und anteiligem DevOps-Aufwand laufende Kosten von 4.200 Euro monatlich. Zuzüglich 85.000 Euro Initialprojekt für Architektur und Signaturverkettung liegen die 60-Monats-Gesamtkosten bei 337.000 Euro, was einer Netto-Einsparung von über 640.000 Euro (rund 65 Prozent) entspricht.
Die Make-or-Buy Sourcing-Weiche für AI-Governance und Artikel-12-Telemetrie
Je nach interner Plattform-Reife und Schutzbedarf der verarbeiteten Geschäftsdaten haben sich drei Bereitstellungsmodelle für den AI-Act-Compliance-Stack etabliert.
Erstens (Eigenbetrieb): Organisationen mit eigener Kubernetes-Plattform und hohen Geheimschutzanforderungen betreiben sowohl lokale Open-Weights-Modelle (via vLLM) als auch den Audit-Stack aus LiteLLM, OpenTelemetry, Langfuse und Ceph-WORM-Storage in eigener Regie. Dies eliminiert jegliches Drittparteienrisiko bei hochsensiblen Forschungs-, Finanz- oder Personaldaten.
Zweitens (Co-Managed): Gehobene Mittelständler betreiben das zentrale AI-Gateway, die PII-Maskierung und den WORM-Audit-Tresor im eigenen Haus, beziehen die Sprachmodell-Inferenz jedoch flexibel über europäische API-Endpunkte wie Mistral AI oder Aleph Alpha. Da jeder Aufruf das eigene Gateway passiert, bleibt der Artikel-12-Audit-Trail vollständig unter eigener Kontrolle.
Drittens (Managed Service): Unternehmen ohne eigenes MLOps-Team vergeben den Betrieb der KI- und Logging-Plattform an einen nach BSI C5 und ISO/IEC 27001 testierten europäischen Managed-Service-Provider. Vertraglich wird gesichert, dass sämtliche OpenTelemetry-Rohdaten und WORM-Archive über S3-Schnittstellen im Eigentum des Auftraggebers verbleiben und nach ISO/IEC 42001 dokumentiert werden.
Der 4-Phasen-Umsetzungsfahrplan: In sechs Monaten zur prüfungssicheren KI-Architektur
Angesichts der verbindlichen Stichtage empfiehlt sich ein strukturiertes Sechsmonatsprogramm, das juristische Klassifizierung und technische Infrastruktur schrittweise zusammenführt.
Phase 1 (Monat 1): KI-Systeminventar, Risikoklassifizierung und Artikel-25-Rollenprüfung
IT-Architektur, Informationssicherheit und Rechtsabteilung erfassen alle genutzten KI-Systeme und ordnen sie eindeutig den Kategorien der Verordnung (Verboten nach Art. 5, Hochrisiko nach Anhang III, Transparenzpflichtig nach Art. 50) zu. Parallel wird geprüft, ob eigenes Fine-Tuning eine Anbieter-Verantwortung nach Artikel 25 auslöst.
Phase 2 (Monat 2 bis 3): Zentrales AI-Gateway, PII-Filterung und KI-Kompetenz nach Artikel 4
Direkte API-Verbindungen einzelner Abteilungen werden abgeschaltet und auf ein zentrales Enterprise-AI-Gateway (LiteLLM) mit rollenbasierter Zugriffskontrolle und automatischer PII-Pseudonymisierung umgeleitet. Gleichzeitig wird die seit Februar 2025 geltende Pflicht zur KI-Kompetenz (Artikel 4) durch technische Schulungen für Entwickler und Fachbereiche umgesetzt.
Phase 3 (Monat 4 bis 5): Produktivsetzung der OpenTelemetry-Pipeline und des WORM-Audit-Speichers
Für alle geschäftskritischen und Hochrisiko-Workflows wird die Protokollierung nach Artikel 12 aktiviert. Prompts, RAG-Chunks, Modellversionen und Tool-Calls fließen über OpenTelemetry nach Langfuse und ClickHouse, während ein Hintergrunddienst stündlich SHA-256-verkettete Blöcke im S3-Object-Lock-Speicher (WORM) archiviert.
Phase 4 (Monat 6): Human-in-the-Loop-Validierung, Red-Teaming und Konformitätsakte
Die Benutzeroberflächen der Hochrisiko-Systeme erhalten verbindliche Freigabe- und Übersteuerungsfunktionen für menschliche Aufsichtspersonen nach Artikel 14. Abschließend durchlaufen die Systeme automatisierte Prompt-Injection-Tests nach OWASP-Standard, deren Ergebnisse in der technischen Dokumentation nach Anhang IV hinterlegt werden.
Fünf Kontrollfragen für Vorstand und IT-Leitung zur AI-Act-Architektur
1. Können wir für jede KI-Entscheidung der letzten sechs Monate den exakten Prompt, die RAG-Quellen und die Modellversion rekonstruieren?
Lassen Sie sich in einer Stichprobe zeigen, wie eine KI-Antwort aus dem Vormonat forensisch nachvollzogen wird. Fehlen die damals abgerufenen Vektor-Dokumentenfragmente oder die exakte Modell-Revision, besteht eine akute Nachweislücke gegenüber Artikel 12 und Artikel 19.
2. Haben wir durch eigenes Fine-Tuning unbemerkt die gesetzliche Rolle eines Hochrisiko-Anbieters nach Artikel 25 übernommen?
Prüfen Sie alle Projekte, in denen Basismodelle mit Unternehmensdaten nachtrainiert oder in Prozesse nach Anhang III (wie Bewerberauswahl oder Bonitätsprüfung) integriert wurden. Bei einer wesentlichen Modifikation greifen die vollen Konformitäts- und Dokumentationspflichten eines Herstellers.
3. Sind unsere Audit-Protokolle physisch und kryptografisch gegen nachträgliche Veränderung durch Administratoren geschützt?
Ein reines Monitoring-Dashboard erfüllt keine revisionssichere Aufbewahrungspflicht. Stellen Sie sicher, dass OpenTelemetry-Traces mit kryptografischen Prüfsummen verkettet und auf einem Speicher mit aktiviertem S3-Object-Lock (WORM) abgelegt werden.
4. Wie verhindern wir technisch den unkontrollierten Abfluss von Geschäftsgeheimnissen an externe GPAI-Modelle?
Erst ein zentrales AI-Gateway, das den gesamten ausgehenden Datenverkehr bündelt, sensible Entitäten vorab maskiert und verbotene Anwendungsfälle nach Artikel 5 technisch abweist, macht Ihre Compliance-Strategie im Rechenzentrum durchsetzbar.
5. Wie ist die menschliche Aufsicht nach Artikel 14 in den Benutzeroberflächen unserer Fachabteilungen verankert?
Prüfen Sie, ob Fachanwender in der Oberfläche die verwendeten Quellendokumente und Konfidenzwerte einsehen können, ob das Design aktiv vor Blindvertrauen (Automation Bias) schützt und ob jede menschliche Übersteuerung im Audit-Trail protokolliert wird.
Strategisches Fazit: Regulatorische Präzision als Treiber für erstklassige KI-Systemarchitektur
Die Verordnung (EU) 2024/1689 verlangt von europäischen Unternehmen, künstliche Intelligenz mit derselben architektonischen Disziplin zu betreiben, die für geschäftskritische Datenbanken und Zahlungssysteme längst selbstverständlich ist. Wer die Regeln aus Kapitel V für GPAI-Modelle und die Protokollierungspflichten nach Artikel 12 konsequent in seine Plattform-Architektur übersetzt, vermeidet nicht nur empfindliche Bußgelder.
Durch die Kombination aus offenen Open-Weights-Modellen, einem zentralen AI-Gateway, standardisierter OpenTelemetry-Beobachtbarkeit und unveränderbaren WORM-Speichern entsteht eine hochmoderne, kosteneffiziente KI-Infrastruktur. Unternehmen gewinnen volle Transparenz über ihre probabilistischen Systeme, senken ihre langfristigen Plattformkosten um über 60 Prozent und sichern ihre Digitale Souveränität.
Häufig gestellte Fragen (FAQ) zur technischen Umsetzung des EU AI Act
Wann genau treten die verschiedenen Pflichten des EU AI Act für Unternehmen verbindlich in Kraft?
Die Verordnung (EU) 2024/1689 gilt gestaffelt: Seit dem 2. Februar 2025 greifen die Verbote unzulässiger Praktiken (Art. 5) sowie die Pflicht zur KI-Kompetenz (Art. 4). Seit dem 2. August 2025 gelten die Regeln für GPAI-Modelle (Kapitel V). Am 2. August 2026 folgen die Pflichten für Hochrisiko-Systeme nach Anhang III, während Produkt-KI nach Anhang I bis August 2027 Übergangsfrist hat.
Befreit der Einsatz von Open-Source-Sprachmodellen (Open Weights) vollständig von den Pflichten des KI-Gesetzes?
Nein. Das Privileg nach Artikel 53 Absatz 2 befreit lediglich den Anbieter eines quelloffenen GPAI-Modells unterhalb von 10^25 FLOPs von bestimmten Dokumentationspflichten auf Modellebene. Setzt ein Unternehmen ein solches Modell jedoch für einen Hochrisiko-Zweck nach Anhang III (etwa im Personalwesen oder der Kreditvergabe) ein, müssen sämtliche Hochrisiko-Pflichten wie Artikel-12-Logging uneingeschränkt erfüllt werden.
Welche konkreten technischen Daten müssen im Audit-Trail nach Artikel 12 und Artikel 19 gespeichert werden?
Um eine KI-Entscheidung lückenlos zu rekonstruieren, muss das Protokoll für jede Transaktion den Zeitstempel, die genaue Modellversion samt Parametern (Temperature, Top-P), das System-Prompt-Template, die im RAG-Prozess abgerufenen Dokumenten-Chunks samt Versionsstand, etwaige Funktionsaufrufe (Tool-Calls) sowie die Freigabe oder Korrektur durch die menschliche Aufsichtsperson mindestens sechs Monate lang revisionssicher speichern.
Wie lässt sich die Pflicht zur sechsmonatigen Log-Aufbewahrung (Art. 19 AI Act) mit der DSGVO-Datenminimierung vereinbaren?
Artikel 19 und Artikel 26 Absatz 6 schaffen eine gesetzliche Aufbewahrungspflicht im Sinne von Artikel 6 Absatz 1 Buchstabe c DSGVO. Dennoch muss die Speicherung datenschutzfreundlich erfolgen: Ein vorgelagertes AI-Gateway pseudonymisiert personenbezogene Klardaten (PII) vor der Speicherung im OpenTelemetry-Trace und beschränkt den Zugriff auf die Zuordnungstabelle strikt auf autorisierte Revisionsrollen.
Macht eine Anpassung über Retrieval-Augmented Generation (RAG) unser Unternehmen bereits zum KI-Anbieter nach Artikel 25?
Die bloße Anbindung einer Wissensdatenbank über RAG oder die Gestaltung von System-Prompts gilt in der Regel nicht als wesentliche Veränderung der Modellarchitektur, solange die Zweckbestimmung nicht verschoben wird. Baut ein Unternehmen aus einem Basismodell jedoch erstmals ein Hochrisiko-System nach Anhang III für den eigenen Betrieb oder für Dritte, greifen die Anbieterpflichten nach Artikel 25.
Auditierbare Primärquellen & Technische Referenzen
| Institution & Herausgeber | Primärquelle & Normdokument | Architektonische Relevanz für den CIO |
|---|---|---|
| Europäische Union (Amtsblatt EUR-Lex) | Verordnung (EU) 2024/1689 (EU AI Act) ↗ | Verbindlicher Gesetzestext zu GPAI-Modellen (Kapitel V, Art. 51-55), automatischer Ereignisprotokollierung (Art. 12), Aufbewahrungsfristen (Art. 19) und Rollenverschiebung (Art. 25). |
| Cloud Native Computing Foundation (CNCF) | CNCF OpenTelemetry & Cloud Native Standards ↗ | Technische Referenz für herstellerneutrale Telemetrie-Pipelines und standardisierte GenAI-Spans zur lückenlosen Erfassung von Prompts, Modellparametern und Tool-Calls. |
| OWASP Foundation | OWASP Top 10 for Large Language Model Applications ↗ | Prüfkatalog zur Abwehr von Prompt Injection, unsicherer Plugin-Ausführung und Datenabfluss im Rahmen der geforderten Robustheits- und Cybersicherheitspflichten nach Art. 15 und Art. 55. |
| Agentur der Europäischen Union für Cybersicherheit (ENISA) | ENISA Cybersecurity for Artificial Intelligence ↗ | Europäisches Rahmenwerk für die Härtung des gesamten KI-Lebenszyklus, Manipulationsschutz von Trainings- und RAG-Datenbeständen sowie kryptografische Nachweisführung. |
| Bundesamt für Sicherheit in der Informationstechnik (BSI) | BSI IT-Grundschutz & Sichere KI-Systeme ↗ | Verbindliche Vorgaben für revisionssichere Protokollierung (OPS.1.1.5), Mandantentrennung, Schlüsselmanagement und unveränderbare WORM-Archivspeicher im Enterprise-Betrieb. |
*Modellrechnung: Alle angegebenen Lizenz-, Infrastruktur- und TCO-Werte verstehen sich als unverbindliche Beispielkalkulation auf Basis typischer Szenarien.
**Verweise auf Gesetzestexte, Paragrafen (u. a. DSGVO, NIS-2, EU AI Act, DORA, GoBD, BetrVG) und Compliance-Normen dienen ausschließlich der unverbindlichen technischen Fachinformation für IT-Entscheider. Sie stellen keine Rechtsberatung nach dem Rechtsdienstleistungsgesetz (RDG) dar; für eine rechtsverbindliche Beurteilung Ihrer spezifischen Unternehmensorganisation konsultieren Sie bitte Ihren Rechtsbeistand oder Datenschutzbeauftragten.
DAS CxO-PARADOX
Wie falsche digitale Souveränität Wirtschaft und Staat entkernt und wie echte Unabhängigkeit gelingt.
Von Mathias Diwo · Executive Tech Advisor
- ✓ 6-Hebel-Plan: Geordneter Ausstieg aus VMware- & Hyperscaler-Lock-ins
- ✓ Board Scorecard: One-Page IT-Governance für Vorstand & Aufsichtsrat
- ✓ Sofort lesbar: Vollständiges Kapitel 1 als Vorab-Dossier
Strategische Vertiefung im gleichen Themencluster
Weiterführende Architektur- und Handlungsleitfäden für CIOs & IT-Entscheider.
Sovereign AI & Lokale LLMs: Enterprise-RAG unter DSGVO und EU AI Act
Externe Cloud-KI-APIs gefährden Geschäftsgeheimnisse und führen bei produktiven Unternehmens-Workloads zu unkontrollierbaren Token-Kosten. Dieser Leitfaden zeigt die Referenzarchitektur für lokale Sprachmodelle mit vLLM, Qdrant und mandantensicherem RAG unter DSGVO und EU AI Act.
Lokale LLMs und Enterprise RAG: Datenschutzkonforme KI ohne Cloud-Zwang
Die Anbindung externer US-Cloud-Sprachmodelle gefährdet Geschäftsgeheimnisse und verletzt die DSGVO. Dieser Architektur-Leitfaden zeigt den Aufbau einer autarken Enterprise-RAG-Pipeline mit lokalen Open-Weight-Modellen, Qdrant, Keycloak-RBAC und vLLM.
Mathias Diwo
Herausgeber & Executive Tech AdvisorGründer von TechNavigator.de, Buchautor (HYBRID WORK) und strategischer Beirat für CIOs und Vorstände. Begleitet mittelständische Konzerne und Verwaltungsorganisationen bei Cloud-Exit-Strategien, NIS-2 Haftungsschutz und digitaler Souveränität.