Christof Jori

7 min read · 26 May 2026

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 been live since 2018. The EU AI Act (Regulation 2024/1689) phases in from February 2025 to August 2027. As of mid-2026, prohibited-practice bans and AI literacy obligations are already enforced, GPAI rules apply, and high-risk system obligations land 2 August 2026. Your build team owns nine artifacts. Your DPO owns four. The CEO signs them.

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.

Stacking compliance into your build?

 Book Free Consultation

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. High-risk systems (Annex III) obligations and transparency duties (Art. 50) apply.
  • 2 August 2027. High-risk systems embedded in regulated products (Annex I) covered.

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.

ControlApplies underOwner in a 5-person team
Data Processing AgreementGDPR Art. 28CEO or Founder
Records of Processing (Art. 30)GDPRTech Lead
DPIAGDPR Art. 35Tech Lead plus external DPO
Sub-processor listGDPR Art. 28(2)CEO
Risk-management systemAI Act Art. 9Tech Lead
Data governanceAI Act Art. 10Data Engineer
Technical documentationAI Act Annex IVML Engineer
LoggingAI Act Art. 12Backend Engineer
Transparency to usersAI Act Art. 50Product Lead
Human oversight UXAI Act Art. 14Product Lead
Copyright disclosure (GenAI)AI Act Art. 53(1)(d)ML Engineer
Incident reporting pipelineAI Act Art. 73Tech Lead
Post-market monitoringAI Act Art. 72ML Engineer
Christof Jori

"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.

Final thoughts

GDPR plus AI Act is not double work if you treat compliance as architecture. Records of processing, DPIA, technical documentation, logging, transparency UI, human-oversight surfaces. Each one maps to a line of code, a database table, or a UI component. The legal team writes the disclosures; the engineering team produces the substance.

If you are a DACH SaaS founder reading this in 2026 and your AI feature is shipping, audit yourself against the nine engineering-owned artifacts above. The August 2026 high-risk deadline does not move. The fines are real. But the work is not exotic. It is good engineering documented honestly. That is a discipline a serious team picks up once and reuses on every product.

Building under the AI Act timeline?

 Book Free Consultation
Christof Jori

7 min read · 26 May 2026