GDPR + EU AI Act Stacking: What a DACH SaaS Founder Has to Ship by 2026

If you sell SaaS in DACH and your product has an AI feature, two rulebooks stack on top of each other. GDPR has applied since 2018. Under the current EU AI Act timeline, prohibited-practice bans and AI literacy duties already apply, GPAI rules are active, Article 50 transparency starts on 2 August 2026, stand-alone high-risk duties on 2 December 2027, and product-embedded high-risk duties on 2 August 2028. Engineering produces the technical evidence; legal owners confirm the classification and obligations.

This is engineering perspective, not legal advice. We have shipped AI features for DACH clients under the GDPR regime and we have re-scoped active builds against the AI Act timeline.

What is the actual enforcement timeline I need to plan against?

The AI Act applies in stages. The ones that matter for a DACH SaaS founder running an AI feature:

• 2 February 2025. Prohibited practices (Art. 5) and AI literacy duty (Art. 4) in force.
• 2 August 2025. General-Purpose AI (GPAI) provider obligations, governance, penalties framework.
• 2 August 2026. Article 50 transparency duties apply.
• 2 December 2027. Stand-alone high-risk duties under Annex III apply.
• 2 August 2028. High-risk duties for AI embedded in regulated products apply.

Germany's SDLC reviewers (BfDI and state DPAs) and Austria's DSB will lead GDPR enforcement; market-surveillance authorities for AI Act enforcement are being designated by each member state through 2026.

Is my AI feature high-risk under Annex III?

The decision tree is short. Your system is high-risk if it falls under Annex III categories: biometric identification, critical infrastructure, education and vocational training access, employment and worker management, access to essential private and public services (including credit scoring and insurance pricing), law enforcement, migration, justice administration, democratic processes. For most B2B SaaS, the high-risk bucket gets hit by CV screening, employee monitoring, credit scoring, and insurance pricing features.

1. Is the use-case in Annex III? If no, skip to Art. 50 transparency duties only.
2. If yes, does the Art. 6(3) derogation apply (purely preparatory, narrow procedural, deviation from prior decision, pattern detection)? If yes, register but reduced obligations.
3. If no derogation. Full Chapter III stack applies. Risk-management system, data governance, technical documentation, logging, transparency to deployer, human oversight, accuracy and robustness, quality management system, conformity assessment, EU database registration, post-market monitoring.

What artifacts does the build team actually own?

This is the part most legal-led compliance projects get wrong. Compliance artifacts are not Word documents written at launch. They are by-products of how the system is built. The nine the engineering team owns:

1. Records of processing (Art. 30 GDPR). Generated from infrastructure-as-code and data-flow diagrams, kept in sync via CI.
2. DPIA (Art. 35 GDPR) for high-risk processing. Stored next to the architecture decision records, not in legal's SharePoint.
3. Technical documentation (AI Act Annex IV). Model card, training data summary, performance metrics, known limitations.
4. Logging (AI Act Art. 12). Tamper-evident event log of model inputs, outputs, version, operator. Retained six months minimum.
5. Human oversight design (Art. 14). UX surfaces for review, override, abort. Documented in the product spec.
6. Transparency notice (Art. 50). Disclosure when a user interacts with AI or sees AI-generated content.
7. Copyright disclosure for GenAI training data (Art. 53(1)(d)) if you fine-tune.
8. Incident reporting pipeline (Art. 73). Serious incident reporting within 15 days to market-surveillance authority.
9. Post-market monitoring (Art. 72). Drift detection, performance regression alerts, periodic review.

What does the compliance-stack matrix actually look like for a 5-person team?

Compliance Theater fails because nobody owns the artifact. Here is the table we use in scoping conversations. Adjust roles to your org.

"Compliance design starts at architecture, not at launch. If you cannot point to the line of code that produces the artifact, the artifact is fiction."

How does GDPR stack on top of the AI Act in practice?

The two regimes overlap heavily, and the overlaps are where founders trip:

• Training data. GDPR lawful basis (Art. 6) plus AI Act data governance (Art. 10). If you train on EU personal data without a clean basis, both rulebooks bite.
• Automated decisions. GDPR Art. 22 requires a route to human intervention; AI Act Art. 14 requires human oversight by design. Same problem, two compliance hooks.
• Transparency. GDPR Art. 13/14 information duties at collection; AI Act Art. 50 at interaction. You will write both.
• Records. GDPR Art. 30 and AI Act Art. 11 documentation. Build one source of truth, render two views.
• Risk assessment. GDPR DPIA and AI Act Art. 9 risk-management overlap. Modern practice combines them into one document with both legal annexes.

What about GPAI providers vs deployers?

Most DACH SaaS founders are deployers of foundation models from OpenAI, Anthropic, Mistral, or open-source weights. Deployer obligations are lighter than provider obligations but not absent. If you fine-tune a model and deploy it under your brand, you may become a provider for AI Act purposes, picking up technical documentation, copyright disclosure, and (for high-risk) the full Chapter III stack. Read Art. 25 carefully before fine-tuning, because the regulatory cost step-change at "I am now a provider" is significant.

What does this cost in build-time?

From Wavect's engagement history on AI-feature builds: stacking the compliance artifacts into an existing SaaS adds 10 to 20 percent to engineering time when retrofitted. Built in from architecture, the marginal cost is closer to 3 to 5 percent. The expensive move is bolting it on at launch. The cheap move is owning the artifacts as code from sprint one. RAG and agent features hit transparency and logging requirements first; MCP tool integrations need the audit trail story before you ship.