The Policy Theatre Is Over
For two years, DACH enterprises have been writing AI governance policies, drafting vendor questionnaires, and running tabletop exercises with their compliance officers. The policies are impressive. The reality is not. When a regulator or auditor asks how you know a high-risk AI system complied with the EU AI Act's transparency obligations, or how you can prove that a customer-facing agent never routed sensitive data through a non-EU model endpoint, the policy document does not answer the question. The workflow log does.
The regulatory convergence of the EU AI Act, NIS2, and DORA has created a new compliance surface that most enterprises have not yet mapped. It is not about where your cloud instances run. It is about whether you can reconstruct the data supply chain of every AI decision that touched regulated data, and whether that reconstruction would survive a forensic audit. Sovereignty, in this context, is not a cloud vendor's marketing claim. It is the ability to produce an evidence trail showing which identity, which model, which prompt, which vendor API, and which workflow step processed which data, at what time, under whose authority.
Why Workflow Logs Are Now the Compliance Artefact
Traditional compliance artefacts are static. A data processing agreement, a vendor security questionnaire, a policy document — these are representations of intent. They describe what should happen. AI systems, particularly agentic systems, operate in a different time domain. An agent can trigger a workflow independently, call multiple external models in parallel, transform data across three vendor boundaries, and log the result in a shared service account, all within two seconds. The human who authorised the agent may not even know the workflow ran. The compliance officer certainly does not.
This creates a visibility gap that regulators are already targeting. DORA, which became applicable in January 2025, requires financial institutions to demonstrate operational resilience, including the ability to trace third-party dependencies and data flows during incidents. NIS2, now being enforced across EU member states, mandates supply chain risk management and incident reporting for critical infrastructure operators. The EU AI Act, with its obligations for deployers of high-risk AI systems taking effect in August 2027, requires deployers to maintain logs sufficient to demonstrate compliance with transparency, human oversight, and accuracy obligations. All three frameworks converge on the same question: can you show me, with evidence, what your AI system did, and who was accountable for each step?
The answer, for most enterprises, is no. Not because they lack policies, but because their logging infrastructure was designed for human-operated systems. A user logs in, performs an action, logs out. Audit trails capture the action, the timestamp, the user ID. AI agents do not operate that way. They act across multiple systems simultaneously, often under shared credentials or service accounts that provide no granular attribution. They make decisions that trigger downstream workflows without direct human involvement. They call external model APIs that may themselves be opaque, rate-limited, or subject to vendor-side logging policies that the enterprise does not control. The result is a compliance gap that policy documents cannot close.
The Four Layers of an Auditable AI Data Supply Chain
An auditable AI data supply chain is not a single log file. It is a layered architecture that captures identity, data lineage, model provenance, and decision context at every step. Identity governance is the foundation. Every agent, every model call, every workflow step must be attributable to a specific identity with a specific scope of authority. Shared service accounts are not auditable. A "finance-agent" identity that can access any model, any data source, any external API is a compliance failure waiting to be documented. Role-based obligation mapping, as described in recent compliance frameworks, ensures that every action is tied to the role that bears the regulatory obligation for that action — developer, deployer, data owner, or end user.
Data lineage is the second layer. When an agent processes a customer record, that record's journey through the system must be traceable. Which database did it come from? Was it masked, encrypted, or transformed before it reached the model? Which vendor API received it, and under what contractual and technical controls? If the data crossed a regional boundary, was that crossing logged, and was it compliant with the relevant data residency obligations? Data lineage is not a metadata problem. It is a workflow problem. The log must show the data's path, not just its origin and destination.
Model provenance is the third layer. Which model processed the data? Was it a private-tenant deployment, a shared multi-tenant endpoint, or an external API call to a third-party provider? If the model was fine-tuned, what data was used for fine-tuning, and was that data subject to the same residency and sovereignty controls as the production data? If the model made a prediction or generated content, what was the prompt, and who approved the prompt template? Model provenance is where sovereignty claims meet reality. A vendor may promise that your data never leaves the EU, but if your agent can call any model through any API without a governed gateway, the promise is unenforceable.
Decision context is the fourth layer. Why did the workflow run? What triggered it? What was the expected outcome, and what was the actual outcome? If the agent made a decision that affected a regulated entity — a loan approval, a fraud alert, a customer communication — what human oversight was in place, and how was that oversight logged? Decision context is the layer that connects technical logs to business accountability. It is the layer that answers the regulator's question: who was responsible for this outcome, and how do you know?
The Gateway Model: Enforcing Sovereignty at the Workflow Edge
Patchwork sovereignty approaches do not work. Multiple vendors, mismatched controls, unclear accountability — this is the architecture that fails audits. The alternative is a governed gateway for all model access. Every external model call, every agent workflow, every data transformation routes through a single enforcement layer that applies prompt security, guardrails, and full audit logging. Without a gateway, there is nothing standing between the AI and the rest of the world. With a gateway, every interaction is a compliance event.
The gateway model is not new. It is how enterprises have managed API access, identity federation, and third-party integrations for a decade. What is new is the recognition that AI model access is now a regulated activity, subject to the same auditability requirements as financial transactions or healthcare data access. AWS and Microsoft have announced European Sovereign Cloud offerings, with phased availability beginning in 2025. These are infrastructure plays. They solve the problem of where compute happens. They do not solve the problem of what the compute does, or how you prove what it did. That requires workflow-level governance, not infrastructure-level promises.
A governed gateway enforces three capabilities that policy documents cannot deliver. Prompt security ensures that no agent can inject arbitrary instructions into a model call without review. Prompt injection is a documented vulnerability in research and increasingly observed in production systems. Logging the prompt is not enough. The gateway must validate the prompt against a library of approved templates, reject unauthorised variations, and log the rejection as a compliance event. Guardrails enforce business rules and regulatory constraints at runtime. If a workflow attempts to route EU customer data through a non-EU model endpoint, the gateway blocks the call and logs the attempt. If an agent tries to access a data source without the correct role-based permissions, the gateway denies access and triggers an alert. Guardrails are not post-hoc reviews. They are real-time enforcement. Audit logging captures every interaction in a format that survives forensic analysis. The log must include the identity, the data lineage, the model provenance, and the decision context. It must be immutable, timestamped, and stored in a jurisdiction that aligns with the enterprise's regulatory obligations. A log that can be edited, deleted, or lost is not a compliance artefact. It is evidence of a control failure.
What This Means for DACH Mid-Market Enterprises
DACH Mittelstand firms are not hyperscalers. They do not have dedicated AI governance teams, unlimited budgets, or the luxury of building everything in-house. They are running AI pilots, scaling a handful of use cases, and trying to stay compliant without derailing the business. The good news is that the gateway model does not require hyperscaler scale. It requires clarity about what needs to be logged, who needs to see it, and how the evidence will be used when the regulator asks.
The practical steps are not exotic. Start with identity. Replace shared service accounts with role-based identities that map to regulatory obligations. If you cannot attribute an action to a specific role, you cannot defend it in an audit. Instrument the workflow. Every agent, every model call, every data transformation must generate a log entry that includes identity, data lineage, model provenance, and decision context. If your current logging infrastructure cannot capture these dimensions, it is not fit for purpose. Implement a gateway. Route all external model access through a single enforcement layer that applies prompt security, guardrails, and audit logging. If your agents can call any model through any API without governance, you have already failed the audit. Test the evidence. Run a tabletop exercise where the compliance officer asks for the audit trail of a specific AI decision. If you cannot produce the trail in minutes, not days, your logging architecture is not auditable.
The cost of these steps is modest. The cost of not taking them is existential. When NIS2 enforcement scales, when DORA audits become routine, when the EU AI Act's high-risk provisions are tested in court, the enterprises that can produce an auditable data supply chain will survive. The enterprises that relied on policy documents will not.
A Diagnostic maps your current AI workflows to the four layers of an auditable data supply chain — identity, data lineage, model provenance, and decision context — before the regulator asks for the evidence.