EU AI Act Compliance für KI-Entwickler: Was Sie vor August 2026 tun müssen

Ein entwicklerorientierter Leitfaden zur EU-AI-Act-Compliance vor der August-2026-Frist — Anforderungen, Daten-Governance und praktische Schritte.

Die August-2026-Frist ist real

Der EU AI Act ist im August 2024 in Kraft getreten. Die Pflichten für Hochrisiko-KI-Systeme greifen vollständig ab August 2026. Das ist nicht mehr lange hin.

Es handelt sich um die weltweit erste umfassende KI-Regulierung, und die Durchsetzung ist ernst gemeint: Strafen von bis zu 35 Millionen EUR oder 7 % des weltweiten Jahresumsatzes, je nachdem welcher Betrag höher ist. Zum Vergleich: Die DSGVO sieht maximal 20 Millionen EUR oder 4 % des Umsatzes vor. Der EU AI Act geht weiter.

Wenn Sie KI-gestützte Features entwickeln — Kundensupport-Bots, Dokumentenverarbeitungs-Pipelines, Entscheidungsunterstützungssysteme, alles was ein LLM nutzt — haben Sie mit hoher Wahrscheinlichkeit Pflichten unter dieser Verordnung. Die Frage ist nicht, ob der AI Act für Sie gilt. Sondern welche Anforderungen gelten und ob Sie rechtzeitig bereit sein werden.

Dieser Beitrag deckt ab, was Engineering-Teams vor August 2026 tun müssen. Praktische Schritte.

Wen es betrifft: Provider vs Deployer

Der AI Act unterscheidet zwischen zwei Schlüsselrollen:

• Provider (Anbieter): Die Stelle, die ein KI-System entwickelt oder entwickeln lässt und es unter eigenem Namen oder eigener Marke auf den Markt bringt oder in Betrieb nimmt.
• Deployer (Betreiber): Die Stelle, die ein KI-System unter eigener Verantwortung einsetzt. Nicht der Endnutzer — die Organisation, die das KI-System in ihre Abläufe integriert.

Wenn Sie Features auf Basis von OpenAI, Anthropic, Google oder einem anderen Drittanbieter-LLM bauen, sind Sie mit hoher Wahrscheinlichkeit ein Deployer. Der LLM-Anbieter ist der Provider. Sie haben trotzdem Pflichten — andere, aber reale.

Manche Teams sind beides. Wenn Sie ein Modell fine-tunen oder ein System bauen, das mehrere KI-Komponenten zu etwas Neuem kombiniert, können Sie für dieses System als Provider eingestuft werden. Die Einstufung ist wichtig, weil Provider strengeren Anforderungen unterliegen.

Risikoklassifizierung

Der AI Act definiert vier Risikostufen:

1. Unannehmbares Risiko — Vollständig verboten. Social Scoring, biometrische Echtzeit-Fernidentifizierung im öffentlichen Raum (mit Ausnahmen), Manipulation vulnerabler Gruppen. Falls Sie irgendetwas davon tun: aufhören.
2. Hochrisiko — Strenge Anforderungen. KI-Systeme für Beschäftigungsentscheidungen, Kreditwürdigkeitsbewertungen, Bildungszulassungen, kritische Infrastruktur, Strafverfolgung, Migration/Grenzkontrolle. Erfordert Konformitätsbewertungen, Qualitätsmanagementsysteme, menschliche Aufsicht und umfangreiche Dokumentation.
3. Begrenztes Risiko — Transparenzpflichten. Chatbots müssen offenlegen, dass sie KI sind. KI-generierte Inhalte müssen gekennzeichnet werden. Systeme zur Emotionserkennung und biometrischen Kategorisierung müssen die Nutzer informieren.
4. Minimales Risiko — Keine spezifischen Pflichten unter dem AI Act (obwohl die DSGVO weiterhin gilt).

Was die meisten Engineering-Teams übersehen: Viele Enterprise-KI-Features fallen in die Kategorien begrenztes oder hohes Risiko. Ein Kundensupport-Bot, der Service-Ergebnisse beeinflusst? Potenziell Hochrisiko, wenn er Entscheidungen über Personen trifft oder maßgeblich beeinflusst. Ein Dokumentenverarbeitungssystem, das Daten für Versicherungsansprüche extrahiert? Hochrisiko. Ein internes Tool, das der Personalabteilung beim Bewerber-Screening hilft? Hochrisiko.

Selbst wenn Ihr System nur begrenztes Risiko darstellt, brauchen Sie Transparenzmaßnahmen. Und wenn Sie personenbezogene Daten verarbeiten (das tun Sie wahrscheinlich), gilt die DSGVO unabhängig von der AI-Act-Klassifizierung.

Anforderungen, die für Engineering-Teams relevant sind

Drei Artikel des AI Act haben direkte Auswirkungen darauf, wie Sie KI-Features bauen und betreiben.

Artikel 10: Daten-Governance

Hochrisiko-KI-Systeme müssen mit Trainings-, Validierungs- und Testdatensätzen entwickelt werden, die angemessenen Daten-Governance- und Management-Praktiken unterliegen. Für Deployer, die Drittanbieter-LLMs nutzen, bedeutet das: Welche Daten Sie an das Modell senden, ist relevant.

Sie müssen:

• Verstehen, welche Daten in Ihre KI-Systeme fließen
• Sicherstellen, dass Eingabedaten relevant und repräsentativ sind
• Potenzielle Verzerrungen identifizieren und adressieren
• Ihre Daten-Governance-Praktiken dokumentieren

Für Engineering-Teams: Sie brauchen Transparenz darüber, welche Daten Ihre Anwendung an LLM-Provider sendet. Kein vages Gefühl von "wir senden Kundennachrichten" — tatsächliches, auditierbares Wissen darüber, welche personenbezogenen Daten, sensiblen Informationen und geschäftskritischen Inhalte durch Ihre KI-Pipeline fließen.

Artikel 13: Transparenz

KI-Systeme müssen so konzipiert sein, dass Deployer Ergebnisse interpretieren und das System angemessen nutzen können. Das bedeutet:

• Protokollierung dessen, was an das Modell geht und was zurückkommt
• Verständnis, wie sich das System bei verschiedenen Eingaben verhält
• Dokumentation zur bestimmungsgemäßen Verwendung und zu Einschränkungen
• Ermöglichung menschlicher Aufsicht über den Systembetrieb

Für Entwickler: Sie brauchen Audit-Trails. Jede Anfrage an ein LLM, welche Daten sie enthielt, welche Regeln oder Filter angewendet wurden, wie die Antwort ausfiel. Nicht nur fürs Debugging — als Compliance-Nachweis.

Artikel 15: Genauigkeit, Robustheit und Cybersicherheit

KI-Systeme müssen angemessene Niveaus an Genauigkeit, Robustheit und Cybersicherheit erreichen. Sie müssen widerstandsfähig gegen Versuche unbefugter Dritter sein, ihre Nutzung oder Leistung durch Ausnutzung von Schwachstellen zu verändern.

Lesen Sie den letzten Teil noch einmal. Der AI Act verlangt explizit Resilienz gegen Adversarial Attacks auf KI-Systeme. Das schließt Prompt Injection ein — Versuche, das Modellverhalten durch manipulierte Eingaben zu beeinflussen. Unter Art. 15 ist Prompt-Injection-Prävention keine nette Zusatzmaßnahme. Es ist eine Compliance-Anforderung.

Wenn Sie noch keine Prompt-Injection-Erkennung und -Blockierung implementiert haben, gibt es jetzt einen regulatorischen Grund damit anzufangen. Details finden Sie in unserem Prompt-Injection-Präventionsleitfaden.

Wo AI Act auf DSGVO trifft: die doppelte Compliance-Herausforderung

Wenn Sie in der EU operieren (oder Daten von EU-Bürgern verarbeiten), kennen Sie die DSGVO bereits. Der AI Act ersetzt die DSGVO nicht — er fügt eine Schicht darüber hinzu. Und die beiden Verordnungen verstärken sich gegenseitig auf eine Weise, die für KI-Engineering relevant ist.

Datenminimierung trifft bei LLMs besonders hart

DSGVO Artikel 5 verlangt Datenminimierung: Nur personenbezogene Daten verarbeiten, die für den festgelegten Zweck erforderlich sind.

Jeder Kundenname, jede E-Mail-Adresse, Postanschrift, Telefonnummer oder Kontokennung in einem Prompt braucht eine Rechtfertigung. Senden Sie die Daten, weil das Modell sie braucht, um eine nützliche Antwort zu generieren? Oder weil sie in den Quelldaten standen und niemand sie entfernt hat?

Die meisten Teams, mit denen wir sprechen, sind überrascht, wie viel PII durch ihre KI-Pipelines fließt, wenn sie tatsächlich hinschauen. Support-Ticket-Text wird wörtlich gesendet. Kundendatensätze werden in Context Windows gekippt. Interne Dokumente mit Mitarbeiternamen und Kontaktdaten werden als Retrieval-Augmented-Generation-Quellen genutzt. All das ist Verarbeitung personenbezogener Daten unter der DSGVO.

Drittanbieter-LLMs und Datenverarbeitung

Personenbezogene Daten an einen Drittanbieter-LLM-Provider zu senden, stellt eine Datenverarbeitung nach DSGVO Artikel 28 dar. Sie brauchen einen Auftragsverarbeitungsvertrag (AVV) mit jedem KI-Anbieter, den Sie nutzen. Die meisten großen Anbieter bieten diese an, aber Sie müssen sie tatsächlich abgeschlossen haben und sicherstellen, dass Ihre Nutzung innerhalb der vereinbarten Bedingungen bleibt.

Die Daten-Governance-Anforderungen des AI Act unter Art. 10 verstärken dies. Sie müssen dokumentieren, welche Daten wohin fließen, warum und unter welchen Kontrollen. Die beiden Verordnungen schaffen überlappende Pflichten, die in die gleiche Richtung zeigen: Kennen Sie Ihre Daten, minimieren Sie sie, schützen Sie sie, dokumentieren Sie sie.

Das praktische Fazit

Automatisierte PII-Erkennung und -Schwärzung ist nicht mehr optional. Es ist eine Compliance-Anforderung, die gleichzeitig aus zwei Richtungen kommt — dem Datenminimierungsprinzip der DSGVO und den Daten-Governance-Anforderungen des AI Act. Wenn personenbezogene Daten nicht im Prompt sein müssen, sollten sie dort nicht stehen. Und Sie brauchen einen systematischen Weg, das durchzusetzen — nicht nur gute Vorsätze.

Für einen tieferen Einblick in Erkennungsstrategien lesen Sie unseren Beitrag zu PII-Erkennungs-Best-Practices.

Praktische Compliance-Checkliste für Engineering-Teams

Grob in der Reihenfolge der Priorität:

1. KI-Inventar erstellen

Erfassen Sie jeden Service, Endpoint und jedes Feature in Ihrem Stack, das ein LLM oder KI-Modell nutzt. Dokumentieren Sie für jedes:

• Welcher KI-Provider/welches Modell wird genutzt
• Welche Daten fließen an das Modell (Request-Payloads)
• Welche Daten kommen zurück (Response-Payloads)
• Wer hat Zugriff auf die Integration
• Ob personenbezogene Daten betroffen sind (mit hoher Wahrscheinlichkeit ja)

Sie können nicht schützen, was Sie nicht kennen. Shadow AI — Teams, die LLM-Integrationen ohne zentrale Transparenz aufsetzen — ist ein reales Problem. Beginnen Sie damit, ein vollständiges Bild zu bekommen.

2. Datensensitivität pro Endpoint klassifizieren

Nicht alle KI-Integrationen tragen das gleiche Risiko. Ein Code-Completion-Tool, das interne Codebases verarbeitet, ist etwas anderes als ein kundenorientierter Chatbot, der Support-Gespräche verarbeitet. Klassifizieren Sie jede Integration nach:

• Datensensitivität: Werden PII verarbeitet? Sensible Kategorien? Finanzdaten? Gesundheitsdaten?
• Risikostufe: Wäre das unter dem AI Act Hochrisiko, begrenztes oder minimales Risiko?
• Exponierung: Werden die Daten an einen Drittanbieter gesendet oder lokal verarbeitet?

3. Automatisierte PII-Erkennung implementieren

Das ist der technische Kern der Compliance. Sie brauchen Erkennung auf Netzwerkebene, die personenbezogene Daten abfängt, bevor sie Ihre Infrastruktur verlassen.

• Regex-Muster für strukturierte PII: E-Mails, Telefonnummern, Kreditkartennummern, Sozialversicherungsnummern, IBANs. Deterministisch, auditierbar und schnell.
• KI-gestützte Erkennung für unstrukturierte PII: Personennamen, Orte, Organisationen in Fließtext. Lokale KI-Modelle erkennen, was Regex nicht kann.
• DLP-Regeln für geschäftssensible Daten: Quellcode, API-Keys, interne Kennungen.

Die zentrale Anforderung: Erkennung sollte zentralisiert sein, nicht pro Service. Wenn jedes Team seine eigene PII-Bereinigung implementiert, bekommen Sie inkonsistente Abdeckung und keinen einheitlichen Audit-Trail. Ein Proxy-basierter Ansatz bedeutet, dass jede KI-Anfrage die gleiche Behandlung bekommt.

4. Audit-Logging aktivieren

Jede Anfrage an ein LLM sollte einen Audit-Eintrag erzeugen:

• Zeitstempel
• Quell-Service/Endpoint
• Welche Erkennungsregeln angewendet wurden
• Was erkannt wurde (Kategorien, nicht Roh-PII)
• Welche Aktion durchgeführt wurde (geschwärzt, maskiert, blockiert, durchgelassen)

Das ist Ihr Compliance-Nachweis. Wenn ein Regulator fragt "Wie stellen Sie sicher, dass personenbezogene Daten nicht unnötig an KI-Anbieter gesendet werden?", verweisen Sie auf die Logs.

5. Prompt-Injection-Erkennung hinzufügen

Art. 15 verlangt Robustheit gegen adversariale Manipulation. Bewerten Sie eingehende Anfragen auf Injection-Risiko und definieren Sie Policies für den Umgang mit Hochrisiko-Eingaben — blockieren, protokollieren oder alarmieren.

6. Alles dokumentieren

Compliance ist teilweise eine Dokumentationsübung. Dokumentieren Sie:

• Ihr KI-System-Inventar
• Risikoklassifizierungen für jedes System
• Daten-Governance-Praktiken
• Erkennungsregeln und ihre Begründung
• Incident-Response-Verfahren
• Mechanismen zur menschlichen Aufsicht

Diese Dokumentation bildet Ihr Compliance-Nachweis-Paket. Bauen Sie es laufend auf, nicht in der Woche vor Durchsetzungsbeginn.

Wie Proxy-Level-Schutz ins Compliance-Bild passt

Ein Proxy-basierter Ansatz hat spezifische Vorteile für die Compliance.

Zentralisierter Audit-Trail: Ein einzelner Proxy, der den gesamten KI-Traffic verarbeitet, gibt Ihnen eine zentrale Stelle für Compliance-Nachweise. Jede Anfrage, jede Erkennung, jede Aktion — konsistent über alle Services und Provider hinweg protokolliert. Kein Zusammenstückeln von Logs verschiedener Teams oder Services. Greptures Activity Log und Compliance Reports (Business+-Pläne) sind genau dafür konzipiert.

Auditierbare Erkennung: Regulatoren wollen nicht nur wissen, dass Sie Daten schützen — sie wollen wissen wie. Deterministische Regex-Regeln sind vollständig erklärbar: "Dieses Muster erkennt E-Mail-Adressen, und wir schwärzen sie, bevor sie an den KI-Provider weitergeleitet werden." KI-gestützte Erkennung ergänzt die Abdeckung für unstrukturierte PII. Die Kombination bietet Ihnen sowohl Breite als auch Auditierbarkeit.

Datenminimierung by Design: Greptures Mask-and-Restore-Feature ersetzt echte Werte durch sichere Token, bevor das LLM sie sieht, und tauscht sie in der Antwort wieder ein. Das Modell verarbeitet nie die tatsächlichen personenbezogenen Daten. Das ist Datenminimierung im stärksten Sinne — die Daten erreichen den Auftragsverarbeiter buchstäblich nie.

Zero-Data-Modus: Für maximale Datenminimierung bieten Business+-Pläne den Zero-Data-Modus — Anfragen werden vollständig im Arbeitsspeicher verarbeitet, ohne dass Bodies oder Header gespeichert werden. Sie erhalten Schutz, ohne neue Datenspeicher zu schaffen, um die Sie sich sorgen müssen.

EU-gehostete Infrastruktur: Daten verlassen niemals die EU. Für Organisationen mit Datenresidenz-Anforderungen eliminiert das eine weitere Compliance-Sorge. Alle KI-Erkennungsmodelle laufen lokal auf der Grepture-Infrastruktur — Ihre Daten werden nicht zum Zweck des Schutzes an einen weiteren Dritten weitergeleitet.

Drop-in-Integration: Sie können diese Kontrollen hinzufügen, ohne Ihren KI-Stack umzuschreiben. Installieren Sie das SDK (npm install @grepture/sdk), wrappen Sie Ihren bestehenden OpenAI- oder Anthropic-Client, und Ihr Traffic fließt durch den Proxy. Compliance sollte kein Sechsmonatsprojekt erfordern.

Zentrale Erkenntnisse

Der EU AI Act ist ein Satz technischer Anforderungen, die direkt beeinflussen, wie Engineering-Teams KI-Features bauen und betreiben. Die Überschneidung mit der DSGVO bedeutet, dass die meisten dieser Pflichten bereits galten; der AI Act macht sie explizit und verschärft die Durchsetzung.

Die Kernbotschaft für Engineering-Teams: Wissen Sie, welche Daten durch Ihre KI-Systeme fließen, minimieren Sie sie, schützen Sie sie, protokollieren Sie sie und dokumentieren Sie Ihre Kontrollen. Automatisierte PII-Erkennung, Prompt-Injection-Prävention und umfassendes Audit-Logging sind nicht mehr nur gute Sicherheitspraktiken — sie sind regulatorische Anforderungen.

Wenn Sie loslegen wollen, haben Sie mit der Schnellstart-Anleitung in wenigen Minuten alles am Laufen. Für einen tieferen Blick auf Erkennungsstrategien lesen Sie PII-Erkennungs-Best-Practices.