GDPR + EU AI Act for DACH SaaS: A Current Planning Framework

If you sell SaaS in DACH and use AI, GDPR and the EU AI Act may both apply, but not every control applies to every feature. Start with the use case, personal-data processing, and your role in the AI value chain. Under the current European Commission implementation timeline, Article 50 transparency applies from 2 August 2026, Annex III high-risk requirements from 2 December 2027, and Annex I product-embedded high-risk requirements from 2 August 2028. Legal and governance owners confirm the analysis; product and engineering teams produce the evidence relevant to the system.

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. Relevant dates depend on the role and system:

• 2 February 2025. Prohibited practices (Art. 5) and AI literacy duty (Art. 4) in force.
• 2 August 2025. Governance provisions and obligations for providers of GPAI models began applying, with transition rules for older models.
• 2 August 2026. Article 50 duties apply to specified AI interactions and generated or manipulated content.
• 2 December 2027. Requirements for Annex III high-risk systems begin applying under the AI Omnibus timeline.
• 2 August 2028. Requirements for high-risk AI embedded in Annex I regulated products begin applying.

GDPR supervision depends on jurisdiction and processing context. Germany has federal and state supervisory authorities; Austria has the Datenschutzbehörde. AI Act enforcement mainly sits with national competent market-surveillance authorities, with the AI Office and European Data Protection Supervisor responsible in defined areas. Confirm the competent authority rather than assuming that a particular regulator reviews every SDLC.

Is my AI feature high-risk under Annex III?

Annex III covers specified uses in biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice and democratic processes. The exact purpose and conditions matter. Examples include certain CV screening, worker monitoring and creditworthiness systems, but a sector label or the use of AI alone does not settle classification. Use the Commission's current draft high-risk guidance alongside the legal text, and check for later final guidance.

1. Does the intended purpose meet an Annex I or Annex III category and its conditions? If not, assess other AI Act and GDPR duties rather than assuming only Article 50 remains.
2. For Annex III, does Article 6(3) exclude the system because it poses no significant risk and meets a listed condition? Profiling systems do not receive that exclusion. Document the assessment and check any registration duty.
3. If the system is high-risk, map provider, deployer and other role-specific duties. The complete provider control set is not automatically owned by every SaaS deployer.

What evidence might the build and governance teams need?

There is no universal list of nine engineering-owned artifacts. Applicability and accountability depend on role, processing and system classification. A practical evidence map can include:

1. Records of processing where Article 30 GDPR requires them, supported by maintained data-flow and system records.
2. A DPIA where processing is likely to create high risk to people's rights and freedoms under Article 35 GDPR.
3. Technical documentation under Annex IV where the company has the relevant high-risk provider obligation.
4. Logging appropriate to the applicable AI Act role and system. Article 19's six-month rule concerns logs automatically generated by a high-risk system while under the provider's control, unless other law provides otherwise.
5. Human-oversight measures for applicable high-risk systems, including competent people, authority and usable controls.
6. Article 50 notices or machine-readable marking for the interactions and content categories that the provision covers.
7. GPAI training-content and copyright-policy material where the company is actually a GPAI model provider, not merely because it uses fine-tuning.
8. A serious-incident workflow for providers of high-risk systems, reflecting the two-day, ten-day and fifteen-day deadlines in Article 73.
9. Post-market monitoring where provider duties require it, proportionate to the system and evidence needed.

The consolidated AI Act source on EUR-Lex is the controlling reference for role-specific requirements.

What can an illustrative responsibility matrix look like?

The following is a coordination example, not a statutory allocation or a complete checklist. A five-person company may combine roles, use external advisers, or assign different accountable owners. First mark each control applicable or not applicable.

"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 regimes can overlap, but each trigger must be assessed separately:

• Training data. GDPR needs a lawful basis and compliance with its other principles when personal data is processed. AI Act Article 10 data-governance requirements apply to relevant high-risk systems.
• Automated decisions. GDPR Article 22 concerns decisions based solely on automated processing that have legal or similarly significant effects. Human-intervention safeguards apply in specified exception cases. AI Act Article 14 separately addresses oversight for high-risk systems.
• Transparency. GDPR Articles 13 and 14 may require information about personal-data processing; AI Act Article 50 covers specified interactions and content. Neither is a universal notice for every AI output.
• Records. Article 30 GDPR records and Article 11 AI Act technical documentation have different triggers and responsible roles. Shared evidence can reduce duplication without collapsing the legal requirements.
• Risk assessment. A GDPR DPIA and AI Act risk-management system can reuse evidence, but they are not interchangeable and need not always be one document.

See the official GDPR text on EUR-Lex when mapping Articles 22, 30 and 35.

What about GPAI providers vs deployers?

A DACH SaaS company integrating a third-party model may be a deployer of that model and a provider of its own AI system, depending on what it develops and places on the market. Roles must be assessed separately. Fine-tuning does not automatically make the company a provider of a new GPAI model. The Commission's GPAI provider guidance says significant modifications can change that role, while minor modifications generally do not. Article 25 separately addresses when another actor assumes provider obligations for an AI system, such as through substantial modification or a changed intended purpose.

How should build-time cost be estimated?

There is no defensible universal percentage for retrofitting or designing this evidence. Estimate from the applicable controls, current architecture, data lineage, model and vendor access, testing gaps, documentation state, security controls, review cadence and external assurance. Early classification can prevent rework, but it does not make compliance evidence cost-free. For RAG, agent and MCP features, scope transparency, logging and human-control needs from the actual role and use case.

Other regimes can affect the same roadmap, but their application dates and technical scope require separate analysis. Our overview of Stripe Billing and German e-invoicing addresses billing requirements independently.

A privacy vendor or pseudonymization layer can change risks and data flows, but it does not automatically remove or preserve every controller duty. Read what a pseudonymization gateway changes about GDPR scope, then reassess the concrete processing and roles.