Das Policy-Theater ist vorbei
Seit zwei Jahren schreiben DACH-Unternehmen AI-Governance-Richtlinien, entwerfen Lieferantenfragebögen und führen Tischübungen mit ihren Compliance-Beauftragten durch. Die Richtlinien sind beeindruckend. Die Realität ist es nicht. Wenn eine Aufsichtsbehörde oder ein Prüfer fragt, wie Sie wissen, dass ein Hochrisiko-KI-System die Transparenzpflichten des EU AI Act erfüllt hat, oder wie Sie nachweisen können, dass ein kundenorientierter Agent niemals sensible Daten über einen Modell-Endpunkt außerhalb der EU geleitet hat, beantwortet das Policy-Dokument die Frage nicht. Das Workflow-Log tut es.
Die regulatorische Konvergenz von EU AI Act, NIS2 und DORA hat eine neue Compliance-Oberfläche geschaffen, die die meisten Unternehmen noch nicht kartiert haben. Es geht nicht darum, wo Ihre Cloud-Instanzen laufen. Es geht darum, ob Sie die Data Supply Chain jeder KI-Entscheidung rekonstruieren können, die regulierte Daten berührt hat, und ob diese Rekonstruktion einer forensischen Prüfung standhalten würde. Souveränität ist in diesem Kontext kein Marketing-Versprechen eines Cloud-Anbieters. Es ist die Fähigkeit, eine Beweiskette vorzulegen, die zeigt, welche Identität, welches Modell, welcher Prompt, welche Anbieter-API und welcher Workflow-Schritt welche Daten wann und unter wessen Autorität verarbeitet hat.
Warum Workflow-Logs jetzt das Compliance-Artefakt sind
Traditionelle Compliance-Artefakte sind statisch. Ein Datenverarbeitungsvertrag, ein Lieferanten-Sicherheitsfragebogen, ein Policy-Dokument – das sind Absichtserklärungen. Sie beschreiben, was passieren soll. KI-Systeme, insbesondere agentische Systeme, operieren in einer anderen Zeitdomäne. Ein Agent kann einen Workflow eigenständig auslösen, mehrere externe Modelle parallel aufrufen, Daten über drei Anbietergrenzen hinweg transformieren und das Ergebnis in einem gemeinsam genutzten Service-Account protokollieren – alles innerhalb von zwei Sekunden. Der Mensch, der den Agenten autorisiert hat, weiß möglicherweise nicht einmal, dass der Workflow gelaufen ist. Der Compliance-Beauftragte mit Sicherheit nicht.
Dies schafft eine Sichtbarkeitslücke, die Regulierungsbehörden bereits ins Visier nehmen. DORA, das seit Januar 2025 gilt (mit gestaffelten Compliance-Fristen bis 2026), verlangt ICT-Risikomanagement und Drittanbieter-Überwachung—was AI-Workflows einschließt, wenn sie kritische Funktionen unterstützen. NIS2, das nun in den EU-Mitgliedstaaten durchgesetzt wird, schreibt Supply-Chain-Risikomanagement und Vorfallsmeldung für Betreiber kritischer Infrastrukturen vor. Der EU AI Act, dessen Hochrisiko-Bestimmungen ab August 2026 gelten (volle Compliance bis August 2027), verlangt von Betreibern die Führung von Logs, die ausreichen, um die Einhaltung von Transparenz-, Aufsichts- und Genauigkeitspflichten nachzuweisen. Alle drei Rahmenwerke konvergieren auf dieselbe Frage: Können Sie mir mit Beweisen zeigen, was Ihr KI-System getan hat und wer für jeden Schritt verantwortlich war?
Die Antwort lautet für die meisten Unternehmen: Nein. Nicht weil ihnen Richtlinien fehlen, sondern weil ihre Logging-Infrastruktur für von Menschen bediente Systeme konzipiert wurde. Ein Nutzer meldet sich an, führt eine Aktion aus, meldet sich ab. Audit-Trails erfassen die Aktion, den Zeitstempel, die Nutzer-ID. KI-Agenten operieren nicht so. Sie handeln gleichzeitig über mehrere Systeme hinweg, oft unter gemeinsam genutzten Credentials oder Service-Accounts, die keine granulare Zuordnung ermöglichen. Sie treffen Entscheidungen, die nachgelagerte Workflows auslösen, ohne direkte menschliche Beteiligung. Sie rufen externe Modell-APIs auf, die selbst undurchsichtig, ratenlimitiert oder Gegenstand anbieterseitiger Logging-Richtlinien sein können, die das Unternehmen nicht kontrolliert. Das Ergebnis ist eine Compliance-Lücke, die Policy-Dokumente nicht schließen können.
Die vier Ebenen einer prüfbaren AI Data Supply Chain
Eine prüfbare AI Data Supply Chain ist keine einzelne Log-Datei. Es ist eine geschichtete Architektur, die Identität, Data Lineage, Modell-Provenienz und Entscheidungskontext bei jedem Schritt erfasst. Identity Governance ist das Fundament. Jeder Agent, jeder Modellaufruf, jeder Workflow-Schritt muss einer spezifischen Identität mit einem spezifischen Autoritätsbereich zuordenbar sein. Gemeinsam genutzte Service-Accounts sind nicht prüfbar. Eine „Finanz-Agent"-Identität, die auf jedes Modell, jede Datenquelle, jede externe API zugreifen kann, ist ein Compliance-Versagen, das darauf wartet, dokumentiert zu werden. Rollenbasierte Zugriffskontrolle (RBAC), erweitert um Compliance-Verpflichtungen, stellt sicher, dass jede Aktion an die Rolle gebunden ist, die die regulatorische Verpflichtung für diese Aktion trägt – Entwickler, Betreiber, Datenbesitzer oder Endnutzer.
Data Lineage ist die zweite Ebene. Wenn ein Agent einen Kundendatensatz verarbeitet, muss die Reise dieses Datensatzes durch das System nachvollziehbar sein. Aus welcher Datenbank kam er? Wurde er maskiert, verschlüsselt oder transformiert, bevor er das Modell erreichte? Welche Anbieter-API hat ihn empfangen, und unter welchen vertraglichen und technischen Kontrollen? Wenn die Daten eine regionale Grenze überschritten haben, wurde diese Überschreitung protokolliert, und war sie konform mit den relevanten Datenresidenz-Verpflichtungen? Data Lineage ist kein Metadaten-Problem. Es ist ein Workflow-Problem. Das Log muss den Pfad der Daten zeigen, nicht nur Ursprung und Ziel.
Modell-Provenienz ist die dritte Ebene. Welches Modell hat die Daten verarbeitet? War es ein Private-Tenant-Deployment, ein gemeinsam genutzter Multi-Tenant-Endpunkt oder ein externer API-Aufruf an einen Drittanbieter? Wenn das Modell Fine-Tuning durchlaufen hat, welche Daten wurden dafür verwendet, und unterlagen diese Daten denselben Residenz- und Souveränitätskontrollen wie die Produktionsdaten? Wenn das Modell eine Vorhersage getroffen oder Inhalte generiert hat, was war der Prompt, und wer hat das Prompt-Template genehmigt? Modell-Provenienz ist der Punkt, an dem Souveränitätsversprechen auf die Realität treffen. Ein Anbieter mag versprechen, dass Ihre Daten die EU nie verlassen, aber wenn Ihr Agent jedes Modell über jede API ohne ein gesteuertes Gateway aufrufen kann, ist das Versprechen nicht durchsetzbar.
Entscheidungskontext ist die vierte Ebene. Warum lief der Workflow? Was hat ihn ausgelöst? Was war das erwartete Ergebnis, und was war das tatsächliche Ergebnis? Wenn der Agent eine Entscheidung getroffen hat, die eine regulierte Entität betraf – eine Kreditgenehmigung, eine Betrugswarnung, eine Kundenkommunikation –, welche menschliche Aufsicht war vorhanden, und wie wurde diese Aufsicht protokolliert? Entscheidungskontext ist die Ebene, die technische Logs mit geschäftlicher Verantwortlichkeit verbindet. Es ist die Ebene, die die Frage der Regulierungsbehörde beantwortet: Wer war für dieses Ergebnis verantwortlich, und wie wissen Sie das?
Das Gateway-Modell: Souveränität am Workflow-Rand durchsetzen
Flickwerk-Souveränitätsansätze funktionieren nicht. Mehrere Anbieter, nicht übereinstimmende Kontrollen, unklare Verantwortlichkeit – das ist die Architektur, die Audits nicht besteht. Die Alternative ist ein gesteuertes Gateway für jeden Modellzugriff. Jeder externe Modellaufruf, jeder Agenten-Workflow, jede Datentransformation läuft über eine einzige Durchsetzungsebene, die Prompt Security, Guardrails und vollständiges Audit-Logging anwendet. Ohne Gateway steht nichts zwischen der KI und dem Rest der Welt. Mit Gateway ist jede Interaktion ein Compliance-Ereignis.
Das Gateway-Modell ist nicht neu. Es ist die Art und Weise, wie Unternehmen seit einem Jahrzehnt API-Zugriff, Identity Federation und Drittanbieter-Integrationen verwalten. Was neu ist, ist die Erkenntnis, dass KI-Modellzugriff jetzt eine regulierte Aktivität ist, die denselben Prüfbarkeitsanforderungen unterliegt wie Finanztransaktionen oder Gesundheitsdatenzugriff. AWS kündigte seine European Sovereign Cloud für 2025 an (geplanter Start Ende 2025). Microsoft betreibt bereits seit 2023 seine EU Data Boundary. Das sind Infrastruktur-Spielzüge. Sie lösen das Problem, wo Compute stattfindet. Sie lösen nicht das Problem, was das Compute tut oder wie Sie nachweisen, was es getan hat. Das erfordert Governance auf Workflow-Ebene, nicht Infrastruktur-Versprechen.
Ein gesteuertes Gateway setzt drei Fähigkeiten durch, die Policy-Dokumente nicht liefern können. Prompt Security stellt sicher, dass kein Agent willkürliche Anweisungen in einen Modellaufruf einfügen kann, ohne Überprüfung. Prompt Injection ist ein dokumentierter Angriffsvektor. Template-Validierung ist ein wichtiger Baustein, muss aber durch Input-Sanitization, Output-Filtering und Context-Isolation ergänzt werden, um Defense-in-Depth zu erreichen. Den Prompt zu protokollieren reicht nicht aus. Das Gateway muss den Prompt gegen eine Bibliothek genehmigter Templates validieren, nicht autorisierte Variationen ablehnen und die Ablehnung als Compliance-Ereignis protokollieren. Guardrails setzen Geschäftsregeln und regulatorische Einschränkungen zur Laufzeit durch. Wenn ein Workflow versucht, EU-Kundendaten über einen Modell-Endpunkt außerhalb der EU zu leiten, blockiert das Gateway den Aufruf und protokolliert den Versuch. Wenn ein Agent versucht, auf eine Datenquelle ohne die korrekten rollenbasierten Berechtigungen zuzugreifen, verweigert das Gateway den Zugriff und löst einen Alarm aus. Guardrails sind keine nachträglichen Überprüfungen. Sie sind Echtzeit-Durchsetzung. Audit-Logging erfasst jede Interaktion in einem Format, das forensische Analysen übersteht. Das Log muss die Identität, die Data Lineage, die Modell-Provenienz und den Entscheidungskontext enthalten. Es muss unveränderlich, mit Zeitstempel versehen und in einer Jurisdiktion gespeichert sein, die mit den regulatorischen Verpflichtungen des Unternehmens übereinstimmt. Ein Log, das bearbeitet, gelöscht oder verloren werden kann, ist kein Compliance-Artefakt. Es ist der Beweis für ein Kontrollversagen.
Was das für DACH-Mittelstandsunternehmen bedeutet
DACH-Mittelstandsfirmen sind keine Hyperscaler. Sie haben keine dedizierten AI-Governance-Teams, keine unbegrenzten Budgets und nicht den Luxus, alles intern zu bauen. Sie führen AI-Piloten durch, skalieren eine Handvoll Use Cases und versuchen, compliant zu bleiben, ohne das Geschäft zu entgleisen. Die gute Nachricht ist, dass das Gateway-Modell keine Hyperscaler-Größe erfordert. Es erfordert Klarheit darüber, was protokolliert werden muss, wer es sehen muss und wie die Beweise verwendet werden, wenn die Regulierungsbehörde fragt.
Die praktischen Schritte sind nicht exotisch. Beginnen Sie mit Identität. Ersetzen Sie gemeinsam genutzte Service-Accounts durch rollenbasierte Identitäten, die auf regulatorische Verpflichtungen abgebildet sind. Wenn Sie eine Aktion nicht einer spezifischen Rolle zuordnen können, können Sie sie in einem Audit nicht verteidigen. Instrumentieren Sie den Workflow. Jeder Agent, jeder Modellaufruf, jede Datentransformation muss einen Log-Eintrag erzeugen, der Identität, Data Lineage, Modell-Provenienz und Entscheidungskontext enthält. Wenn Ihre aktuelle Logging-Infrastruktur diese Dimensionen nicht erfassen kann, ist sie nicht zweckmäßig. Implementieren Sie ein Gateway. Leiten Sie jeden externen Modellzugriff über eine einzige Durchsetzungsebene, die Prompt Security, Guardrails und Audit-Logging anwendet. Wenn Ihre Agenten jedes Modell über jede API ohne Governance aufrufen können, haben Sie das Audit bereits nicht bestanden. Testen Sie die Beweise. Führen Sie eine Tischübung durch, bei der der Compliance-Beauftragte nach dem Audit-Trail einer bestimmten KI-Entscheidung fragt. Wenn Sie den Trail nicht in Minuten, nicht Tagen, vorlegen können, ist Ihre Logging-Architektur nicht prüfbar.
Die Kosten dieser Schritte sind bescheiden. Die Kosten, sie nicht zu unternehmen, sind existenziell. Wenn die NIS2-Durchsetzung skaliert, wenn DORA-Audits zur Routine werden, wenn die Hochrisiko-Bestimmungen des EU AI Act vor Gericht getestet werden, werden die Unternehmen überleben, die eine prüfbare Data Supply Chain vorlegen können. Die Unternehmen, die sich auf Policy-Dokumente verlassen haben, werden es nicht.
Ein Diagnostic bildet Ihre aktuellen AI-Workflows auf die vier Ebenen einer prüfbaren Data Supply Chain ab – Identität, Data Lineage, Modell-Provenienz und Entscheidungskontext – bevor die Regulierungsbehörde nach den Beweisen fragt.
References: CSO Online, „Sovereign cloud won't fix your AI risk. Identity governance will," 2026, https://www.csoonline.com/article/4184634/sovereign-cloud-wont-fix-your-ai-risk-identity-governance-will.html; iTnews, „Digital sovereignty is no longer optional - Agentic AI has made it fundamental," 2026, https://www.itnews.com.au/feature/digital-sovereignty-is-no-longer-optional---agentic-ai-has-made-it-fundamental-626693; Dark Reading, „Auditability in the Age of Autonomy: Preparing for the Next Compliance Wave," 2026, https://www.darkreading.com/identity-access-management-security/auditability-in-the-age-of-autonomy-preparing-for-the-next-compliance-wave; Accounting Today, „Why your AP AI will fail an audit," 2026, https://www.accountingtoday.com/opinion/why-your-ap-ai-will-fail-an-audit; Bloomberg Law, „Companies Can Tackle AI Compliance by Using Multipart Framework," 2026, https://news.bloomberglaw.com/legal-exchange-insights-and-commentary/companies-can-tackle-ai-compliance-by-using-multipart-framework-1.