EU AI Act 2026: Was der Mittelstand zu Transparenz und Datenresidenz wissen muss
Artikel 50 wird im August 2026 verbindlich. Wer KI-Chatbots, KI-generierte Inhalte oder agentenbasierte Workflows einsetzt, muss jetzt Labels, Kennzeichnung und Datenflüsse sauber dokumentieren.
Warum der August 2026 ein reales Datum ist, kein Schreckensszenario
Wer heute einen Chatbot auf der eigenen Website betreibt, einen KI-Agenten in der Kundenkommunikation einsetzt oder Texte, Bilder oder Audio mit generativer KI erzeugt, ist vom Geltungsbeginn des Artikels 50 der EU AI Act direkt betroffen. Die Transparenzregeln treten am 2. August 2026 in Kraft. Die EU-Kommission hat im Mai 2026 mit dem AI Omnibus einen Kompromiss vorgelegt, der generative KI, die bereits vor diesem Datum auf dem Markt war, nur teilweise entlastet: die Pflicht zur maschinenlesbaren Kennzeichnung gilt dort erst ab dem 2. Dezember 2026.
Die gängige Annahme, "wir nutzen nur Standardtools, das betrifft uns nicht", trägt im Mittelstand selten. Sobald ein Unternehmen Inhalte öffentlich macht, die ein KI-System erzeugt oder maßgeblich verändert hat, greift die Kennzeichnungspflicht. Sobald ein System direkt mit Menschen spricht, ohne dass offensichtlich erkennbar ist, dass es KI ist, greift die Hinweispflicht. Die Draft Guidelines der EU-Kommission stellen klar, dass auch KI-Agenten unter Artikel 50 Absatz 1 fallen, insbesondere dann, wenn der Anbieter nicht zuverlässig vorhersagen kann, ob der Agent in einer konkreten Situation mit einem Menschen spricht.
In unseren Projekten beobachten wir, dass viele Mittelständler die Reichweite dieser Pflichten unterschätzen. Wer heute einen Kundenkommunikations-Agenten in Placet einbindet, einen Avy-Workflow zur Rechnungserkennung nutzt oder schlicht Texte in ChatGPT entwirft und auf der eigenen Website veröffentlicht, sollte sich fragen, ob die Kennzeichnung und der Nutzerhinweis sauber umgesetzt sind.
Was Artikel 50 konkret verlangt
Artikel 50 unterscheidet vier Situationen, in denen Transparenzpflichten greifen. Die Pflichten gelten unabhängig davon, ob das System als hochriskant eingestuft ist.
| Situation | Wer ist verpflichtet | Was ist zu tun |
|---|---|---|
| KI interagiert direkt mit Menschen | Anbieter (Provider) | Nutzer müssen klar erkennen können, dass sie mit einer KI sprechen |
| KI erzeugt synthetische Inhalte (Text, Bild, Audio, Video) | Anbieter | Ausgaben müssen maschinenlesbar und technisch als KI-generiert erkennbar gekennzeichnet werden |
| KI zur Emotionserkennung oder biometrischen Kategorisierung | Betreiber (Deployer) | Betroffene Personen müssen informiert werden |
| Deepfakes oder KI-erzeugte Texte zu öffentlichen Belangen | Betreiber | Offenlegung, dass Inhalte KI-erzeugt sind, sofern keine menschliche redaktionelle Verantwortung dokumentiert ist |
Eine wichtige Ausnahme: reine Assistenzfunktionen, etwa Grammatikprüfung oder unmaßgebliche Bearbeitung, fallen nicht unter die Kennzeichnungspflicht. Wer jedoch ein KI-System einsetzt, das Texte eigenständig strukturiert, argumentativ aufbaut oder inhaltlich verändert, ist im Geltungsbereich.
Bei Chatbots und virtuellen Assistenten gilt: der Anbieter muss das System so gestalten, dass Nutzerinnen und Nutzer die Interaktion mit KI erkennen können. Die "Offensichtlichkeit"-Ausnahme greift nur, wenn die KI-Natur für eine vernünftig aufmerksame Person unübersehbar ist. Die EU-Entwurfsleitlinien empfehlen eine zweistufige Prüfung: Zielgruppe definieren, dann beurteilen, wie informiert und aufmerksam ein durchschnittliches Mitglied dieser Gruppe tatsächlich ist.
Datenresidenz: Warum die Deployment-Architektur nicht ausreicht
Artikel 50 betrifft die Nutzerseite. Die Datenresidenz richtet sich nach der DSGVO und entlang der KI-Act-Pflichten für Hochrisikosysteme. Für die meisten Mittelständler ist die wichtigere Frage nicht, ob ein Rechenzentrum in Frankfurt steht, sondern ob der Datenfluss zur Laufzeit überhaupt nachvollziehbar ist.
In der Praxis sehen wir drei typische Bruchstellen, an denen die zugesicherte EU-Datenresidenz zur Fiktion wird.
1. Tool-Calls zur Laufzeit
Ein Agent, der ein Kundenticket bearbeitet, ruft eine Übersetzungs-API auf. Welcher Endpunkt erreicht wird, hängt von Lastverteilung, Failover-Logik und der Agentenlogik ab. Die in der Datenschutz-Folgenabschätzung deklarierte "EU-Übersetzungs-API" kann unter Last auf den US-Endpunkt umgeleitet werden, oder der Agent nutzt einen MCP-Toolkit, der einen Drittanbieter eingebunden hat, der im Verzeichnis der Auftragsverarbeiter gar nicht auftaucht. Jeder dieser Calls ist eine Datenübertragung im Sinne von DSGVO Artikel 28, die ihre eigene vertragliche Grundlage braucht.
2. Vektor-Datenbanken und Replikate
Das Primär-Cluster für die Vektor-Datenbank steht in Frankfurt. Eine Read Replica in us-east-1 wurde vor zwölf Monaten für Latenz-Optimierung eingerichtet. Eine Suchanfrage wird vom Replikat beantwortet. Die Daten haben die Grenze bereits bei der Erstellung der Replica überschritten, und die Embedding-Pipeline repliziert den Index erneut bei jedem Rebuild. Klassische Data-Classification-Tools sehen das Label "DSGVO-relevant" am Chunk, sehen aber nicht den geographischen Hop.
3. Sub-Agent-Delegation
In Frameworks wie LangGraph, CrewAI oder AutoGen werden Aufgaben an Sub-Agenten delegiert. Jeder Knoten kann in einer anderen Cloud-Region laufen. Die Telemetrie auf Framework-Ebene (LangSmith, Arize, Phoenix) zeigt das Verhalten einzelner Agenten, nicht den Datenfluss zwischen ihnen. Wer Cross-Cluster-Identity-Federation einsetzt, verliert in der Regel den Regions-Kontext am Übergang.
Was die DSGVO in Artikel 5 Absatz 1 lit. c und Artikel 32 Absatz 1 lit. d verlangt, ist nicht ein Manifest zur Deployment-Zeit, sondern eine fortlaufende, reproduzierbare Evidenz: Welche personenbezogenen Daten wurden verarbeitet, auf welcher Rechtsgrundlage, durch welchen Auftragsverarbeiter, in welcher Jurisdiktion, mit welchem Transfermechanismus. Eine statische Compliance-Liste reicht nicht mehr.
Was Mittelständler konkret tun sollten
Wir empfehlen drei Schritte, die bis Ende Juli 2026 abgeschlossen sein sollten, damit der August-Stichtag nicht zur Überraschung wird.
Schritt 1: Bestandsaufnahme der KI-Berührungspunkte. Identifizieren Sie alle Stellen, an denen KI-Systeme direkt mit Nutzern sprechen, Inhalte erzeugen, die veröffentlicht werden, oder Mitarbeitende biometrisch auswerten. In der Praxis sind das oft mehr Stellen, als ursprünglich angenommen. CRM-Antwortvorschläge, Avy-Belegerfassung, automatische E-Mail-Klassifizierung, Content-Workflows im Marketing: vieles zählt.
Schritt 2: Kennzeichnung und Hinweise umsetzen. Chatbots brauchen einen sichtbaren oder unmittelbar zugänglichen Hinweis ("Sie sprechen gerade mit einer KI"). KI-erzeugte Inhalte brauchen eine maschinenlesbare Markierung (zum Beispiel über C2PA-Standards) und, wenn sie zu öffentlichen Belangen veröffentlicht werden, einen erkennbaren Hinweis. Wer Texte im Team redaktionell verantwortet, kann sich auf die "menschliche redaktionelle Verantwortung" berufen, sollte das aber dokumentieren.
Schritt 3: Datenflüsse zur Laufzeit sichtbar machen. Eine statische Liste der Auftragsverarbeiter reicht nicht. Wer Sub-Agenten einsetzt, MCP-Toolkits nutzt oder Vektor-Datenbanken mit Replikaten betreibt, sollte eine Methode haben, die Datenflüsse pro Inference nachvollziehbar zu protokollieren. Runtime-AI-BOM-Konzepte (also ein laufend aktualisiertes Inventar aller externen Endpunkte, die ein Agent während der Ausführung tatsächlich kontaktiert) sind ein pragmatischer Einstieg, auch wenn sie noch nicht regulatorisch vorgeschrieben sind. Sie liefern die Evidenz, die ein Datenschutzbeauftragter im Audit braucht.
Warum Human-in-the-Loop plötzlich regulatorisch wertvoll wird
Eine Konsequenz aus dem Transparenzregime, die selten explizit gemacht wird: die "menschliche redaktionelle Verantwortung" ist die einzige breit akzeptierte Ausnahme von der Kennzeichnungspflicht für KI-erzeugte Texte zu öffentlichen Belangen. Konkret bedeutet das, dass Inhalte, die eine KI entwirft und ein Mensch vor der Veröffentlichung verantwortet, nicht als KI-generiert deklariert werden müssen.
Human-in-the-Loop, oft als Sicherheits-Feature diskutiert, bekommt damit eine zusätzliche regulatorische Funktion. Wer in Facio oder Placet einen Freigabe-Schritt zwischen KI-Generierung und Veröffentlichung etabliert, dokumentiert automatisch die redaktionelle Verantwortung und reduziert den Compliance-Aufwand erheblich. Das gilt umso mehr, wenn die Freigabe nachvollziehbar geloggt wird.
Wir sehen in der Praxis, dass Mittelständler, die HITL-Freigaben bereits aus operativen Gründen eingeführt haben (Qualitätskontrolle, Vier-Augen-Prinzip, Schutz vor Halluzinationen), für die August-Deadline deutlich besser aufgestellt sind als Unternehmen, die ihre KI-Workflows bisher vollautomat betreiben.
Die zweite Welle: Hochrisiko-Klassifikationen und ihre Verschiebung
Artikel 50 betrifft die meisten Unternehmen. Die zweite, oft übersehene Welle ist die Hochrisiko-Klassifizierung, die ursprünglich für August 2026 terminiert war. Im AI Omnibus vom Mai 2026 wurden Teile dieser Fristen verschoben, um den Implementierungsdruck zu mildern. Nach den jüngsten Veröffentlichungen bleibt der 2. August 2026 als Stichtag für die Transparenzregeln aktiv. Verschiedene Hochrisiko-Pflichten verschieben sich um mehrere Monate, einige Anforderungen an die KI-Kompetenz (Artikel 4) gelten bereits.
Wer in regulierten Branchen arbeitet (Personenbezogene Daten in großem Umfang, kritische Infrastruktur, Beschäftigung, Bildung, bestimmte industrielle Anwendungen), sollte die Verschiebungen nicht als Entwarnung lesen. Die Compliance-Anforderungen kommen, nur gestaffelt. Die Zeit zwischen August 2026 und der nächsten Hochrisiko-Welle sollte für den Aufbau interner Compliance-Prozesse genutzt werden, nicht für Stillstand.
centerbits Position: Pragmatische Compliance statt Compliance-Theater
Wir bauen Facio und Placet so, dass die Compliance-Anforderungen aus Artikel 50 und der DSGVO ohne Spezialprojekte abgedeckt werden können. Das umfasst drei Dinge:
- Nachvollziehbare Audit-Logs für jede Aktion, die ein KI-Agent im Auftrag eines Nutzers ausführt. Wer wann welche Daten in welches System geschickt hat, ist exportierbar.
- Explizite HITL-Freigaben an den Stellen, an denen Inhalte nach außen gehen, Anfragen beantwortet werden oder Aktionen ausgelöst werden, die rechtliche oder finanzielle Folgen haben.
- Konfigurierbare Region-Bindings für Modell-Endpunkte und Vektor-Datenbanken, damit die EU-Datenresidenz nicht durch Failover-Logik oder Embedding-Services unbeabsichtigt verlassen wird.
Keines dieser Features macht ein Unternehmen automatisch compliant. Sie reduzieren aber den Aufwand, die Anforderungen nachzuweisen, erheblich. In der Diskussion mit unseren Pilotkunden zeigt sich, dass die meisten Compliance-Lücken nicht an fehlender Technik scheitern, sondern an fehlender Dokumentation. Wer Audit-Logs führt, HITL-Schritte loggt und Region-Bindings explizit setzt, ist gegenüber Aufsichtsbehörden in einer deutlich besseren Position als ein Unternehmen, das sich auf Marketing-Aussagen der Modellanbieter verlässt.
Die EU AI Act Transparenzregeln sind kein Grund, KI-Initiativen zu stoppen. Sie sind ein Grund, sie sauber aufzusetzen. Der August 2026 ist ein guter Anlass, die eigenen Workflows ehrlich zu prüfen.
centerbit
Jetzt Termin vereinbaren
Wenn Sie ähnliche manuelle Abläufe in Ihrem Team sehen, schauen wir uns den Prozess im kostenlosen Erstgespräch konkret an.