AI DPIA Checklist for Spain-Facing SaaS Startups (2026): GDPR Article 35 Status

Written and reviewed by Irfan Ullah, Founder of TrusteraAI. Last updated: September 2026 · Regulatory review: September 2026.

AI DPIA checklists can create two costly forms of confusion: treating every AI system that touches personal data as an automatic DPIA trigger, or confusing the EU AI Act’s high-risk timetable with GDPR’s separate DPIA obligation. For a Spain-facing SaaS team, either mistake can send compliance work toward the wrong deadline while an existing GDPR obligation remains unaddressed. This distinction matters particularly in 2026 because the GDPR DPIA obligation and the EU AI Act’s high-risk timetable operate on separate legal frameworks and timelines.

Quick Answer: An AI DPIA checklist for Spain-facing SaaS companies verifies whether GDPR Article 35 requires a Data Protection Impact Assessment for a given AI feature, using the actual Article 35(1) risk test and Article 35(3) triggers — not AI Act classification. A checklist accurate as of September 2026 must also reflect that the Digital Omnibus (Regulation (EU) 2026/1744, in force July 27, 2026) deferred the relevant EU AI Act Annex III high-risk obligations to December 2, 2027, without changing GDPR’s DPIA requirement, which remains applicable today.

The AEPD is an active enforcement authority for data-protection compliance in Spain, including matters involving automated decision-making, profiling, biometric processing, and other AI-related uses of personal data. A checklist built on the wrong timeline can leave a startup addressing the wrong compliance deadline while an existing GDPR obligation remains unaddressed.

A note on how to read this checklist: items below fall into three categories — items directly grounded in GDPR, the AI Act, or applicable Spanish law (“Required”); items where the organization must assess whether a legal threshold is met (“Assessment”); and TrusteraAI operational recommendations that help implement or evidence compliance but aren’t themselves statutory requirements (“Recommended”). Each item is labeled accordingly.

🎯 Start Here

• Need the full checklist now? Jump to The Master DPIA Checklist
• Confused about what’s actually required in 2026? Jump to What Applies Now vs. What’s Deferred
• Not sure a DPIA even applies to your feature? Jump to Screening: Does This Feature Need a DPIA?
• Just getting your compliance foundation in place? Jump to Foundation: Before You Start Screening

What Is an AI DPIA Checklist?

Quick Answer: An AI DPIA checklist is a structured control set that verifies both (a) whether GDPR Article 35 requires a Data Protection Impact Assessment for a specific AI-powered feature, and (b) whether a required DPIA is actually complete — as distinct from a general AI governance checklist, which covers controls across every applicable framework rather than this one GDPR obligation.

For a Spain-facing SaaS company, this checklist sits alongside two other regulatory tracks that are easy to conflate:

• The EU AI Act’s high-risk regime — partly deferred to December 2027 under the Digital Omnibus, and enforced by AESIA, Spain’s dedicated AI supervisory authority
• GDPR Article 35 — the DPIA obligation itself, enforced by the AEPD, fully live today, and never on the AI Act’s timeline to begin with

This checklist addresses the GDPR track specifically. If your feature is also high-risk under the AI Act, the relevant Article 26/27 items appear in the AI Act Overlay section below, tracked on their own separate timeline.

What Applies Now vs. What’s Deferred

This is a distinction that requires care in 2026 — either because content was written before the Digital Omnibus, or because it doesn’t separate “GDPR obligation” from “AI Act obligation” in the first place.

Obligation	Status as of September 2026
GDPR Article 35 — DPIA requirement (risk-based)	✅ Fully applicable; unaffected by the AI Act’s timeline
GDPR Article 36 — Prior consultation with AEPD for unmitigated high risk	✅ Applicable now, where conditions are met
GDPR Article 27 — EU representative for non-established controllers	✅ Applicable now, where Article 3(2) applies
GDPR Article 22 — Automated decision-making safeguards	✅ Applicable now; overlaps with DPIA screening for the same feature
EU AI Act Article 50 — Transparency	✅ Applicable from August 2, 2026; Article 50(2) has a December 2, 2026 compliance date for certain systems placed on the market before August 2, 2026
EU AI Act Article 5 — Prohibited practices	✅ Applicable since February 2, 2025
EU AI Act Article 26 — Deployer obligations for Annex III high-risk systems	⏸️ Relevant Annex III obligations deferred to December 2, 2027 under the amended timetable
EU AI Act Article 27 — Fundamental Rights Impact Assessment (FRIA)	⏸️ For the relevant Annex III high-risk systems covered by the amended timetable, the applicable Article 27 obligations are deferred to December 2, 2027; Article 27 applies only to specified deployer categories and systems, not all Annex III deployers

Building a DPIA checklist around this table first — before assigning work — prevents a team from treating the AI Act’s 2027 deferral as cover for skipping a GDPR DPIA that’s actually due now, while also making sure Article 50 transparency work (which is live) doesn’t get deprioritized behind Article 26 work (which isn’t due for over a year).

How to Use This Checklist

Each item below is tagged by the role primarily responsible — [Legal], [Technical], [Governance] — and by category: Required, Assessment, or Recommended. Mark each ✅ Done, 🔄 In Progress, or ⛔ Gap. Not every item applies to every AI feature; the Screening section determines relevance before you move into the full checklist.

Run the Screening section against each AI feature individually rather than once for the whole company — a “yes, we need a DPIA” answer for one feature (say, an AI hiring tool) doesn’t extend automatically to a different, lower-risk feature (say, an internal analytics dashboard). Track each feature’s checklist status separately.

Foundation: Before You Start Screening

DPIA screening produces unreliable results without this foundation in place first.

• [Governance, Recommended] A current inventory of AI features exists, listing what each one does, what data it touches, and who owns it
• [Governance, Recommended] Each AI feature has a named business owner and a named technical owner
• [Governance, Recommended] A clearly identified person or team is responsible for coordinating GDPR risk decisions and the DPIA process, with the controller retaining responsibility for compliance
• [Legal, Assessment] The company has confirmed, in writing, which GDPR territorial-scope provision applies — including Article 3(1), where there is an EU establishment, and Article 3(2), where the company is not established in the EU but offers goods or services to, or monitors the behaviour of, individuals in the EU
• [Governance, Recommended] A process exists for someone to flag a new AI feature for DPIA screening before it ships, not after

The Master DPIA Checklist

Screening: Does This Feature Need a DPIA?

Run this per feature.

• [Legal, Assessment] Confirm whether the feature processes personal data; if it does not, the GDPR Article 35 DPIA requirement does not apply to that processing activity, although other regulatory obligations may still apply
• [Legal, Required] Assess whether the processing is, in context, likely to result in a high risk to individuals’ rights and freedoms — the core Article 35(1) test
• [Legal, Assessment] Check whether the system systematically and extensively evaluates people through automated processing or profiling, and whether decisions based on that evaluation produce legal or similarly significant effects (Article 35(3)(a))
• [Legal, Assessment] Check whether the processing involves large-scale special category or criminal-offense data (Article 35(3)(b))
• [Legal, Assessment] Check whether the processing involves large-scale systematic monitoring of publicly accessible areas (Article 35(3)(c))
• [Legal, Assessment] Apply the broader DPIA risk criteria reflected in EDPB/WP29 guidance; the EDPB states that, in most cases, processing meeting two or more criteria should be assessed through a DPIA, while a single criterion may still be sufficient depending on the circumstances
• [Legal, Assessment] Cross-check against the AEPD’s orientative high-risk factors — profiling, large-scale processing, sensitive data, novel or unproven technology — noting these inform the risk analysis rather than override it. For a practical Spain-specific screening aid, the AEPD also provides its EVALÚA_RIESGO RGPD tool; its risk factors are not exhaustive and should be adapted to the specific processing
• [Legal, Required] Where the feature involves solely automated decision-making covered by GDPR Article 22, assess the applicable Article 22 conditions and exceptions and implement the required safeguards, including human intervention, the opportunity to express a point of view, and the right to contest the decision where Article 22(3) applies
• [Governance, Recommended] Document the screening decision either way — including a “DPIA not required” conclusion — to support the controller’s Article 5(2) accountability obligations

Territorial Scope & Representation

• [Legal, Assessment] Confirm whether GDPR Article 3(2) applies based on actual targeting/offering of goods or services to individuals in the EU — language, currency, marketing, and similar factors, not just server location
• [Legal, Required] If Article 3(2) applies and no EU establishment exists, an Article 27 representative has been appointed in writing, based in the relevant member state
• [Legal, Assessment] Article 27 exemption (occasional processing, no large-scale special category or criminal-offense data, unlikely to result in risk considering the nature, context, scope, and purposes) has been assessed against actual processing activities rather than assumed
• [Legal, Recommended] The appointed representative’s identity and contact details are reflected in the company’s applicable privacy information and other required GDPR documentation

DPIA Content (Article 35(7))

• [Legal, Required] Systematic description of the processing operations and purposes is documented
• [Legal, Required] Necessity and proportionality of the processing in relation to its purpose is assessed, with relevant alternative approaches considered where appropriate
• [Legal, Required] Risks to the rights and freedoms of data subjects are identified, assessed, and documented using a consistent risk methodology
• [Legal, Required] Mitigation measures, safeguards, and security controls addressing each identified risk are documented
• [Legal, Required] Where a Data Protection Officer has been designated, the DPO’s advice on the DPIA is sought and documented (Article 35(2))
• [Legal, Recommended] Residual risk is reassessed after mitigation measures are identified and documented

AI-Specific Risk & Security Checks

These checks supplement the GDPR risk assessment; they do not replace the Article 35 analysis or automatically create a DPIA obligation.

• [Technical, Recommended] Bias and discrimination risk in the model’s training data or outputs has been assessed, including proxy variables that could correlate with protected characteristics
• [Technical, Recommended] Explainability limitations are documented, with alternative transparency measures where full explainability isn’t feasible
• [Technical, Recommended] Model drift/retraining triggers for DPIA re-review are defined and monitored
• [Technical, Recommended] Vendor sub-processing and model-training-on-customer-data terms have been reviewed for every third-party AI vendor involved in the feature
• [Technical, Recommended] Security risk from prompt injection, data poisoning, or model extraction has been assessed for the specific deployment

Spain-Specific Legal & Regulatory Checks

• [Legal, Assessment] Processing has been checked against the AEPD’s published orientative guidance on AI-incorporating processing
• [Legal, Required] Where the DPIA identifies residual high risk that cannot be sufficiently mitigated by reasonable measures, the need for Article 36 prior consultation has been assessed and, where applicable, consultation with the AEPD is initiated before processing begins
• [Legal, Assessment] Where the feature involves employee data, the Estatuto de los Trabajadores limits on staff monitoring have been checked alongside the DPIA itself

For Spain-specific regulatory context throughout this section, see our Spain GDPR Checklist for SaaS and AEPD Inspection Guide.

AI Act Overlay (Where the System Is Also High-Risk Under Annex III)

• [Legal, Assessment] High-risk classification under Annex III has been assessed and documented, even though most resulting obligations aren’t due until December 2027
• [Legal, Required] Where applicable to the deployer and high-risk system, Article 26 deployer obligations and the Article 27 FRIA are scheduled against the December 2, 2027 deadline — tracked separately from the GDPR DPIA timeline
• [Technical, Required] Article 50 transparency disclosures are implemented now, independent of the high-risk timeline
• [Legal, Recommended] Where both a DPIA and an FRIA will eventually be required, the DPIA is structured so relevant sections can be cross-referenced or incorporated into the later FRIA rather than duplicated from scratch — the amended Article 27 expressly allows this

Sign-Off & Review

The following are governance controls recommended for operationalizing the DPIA process; they are not all express Article 35 requirements.

• [Governance, Recommended] Residual risk level and risk acceptance and deployment decision are documented and signed off before the feature ships to Spanish users
• [Governance, Recommended] Review trigger set: material system change, data category change, incident, or 12-month routine review, whichever comes first
• [Governance, Recommended] Sign-off records are retained in a form the AEPD could review on request

Master Status Dashboard

Section	Total Items	✅ Done	🔄 In Progress	⛔ Gap	% Applicable Items Complete
Foundation	5
Screening	9
Territorial Scope & Representation	4
DPIA Content	6
AI-Specific Risk & Security Checks	5
Spain-Specific Legal & Regulatory Checks	3
AI Act Overlay	4
Sign-Off & Review	3

Calculate completion against applicable checklist items only; items marked not applicable should not reduce the completion percentage.

TrusteraAI operational red flag: Any applicable section below 60% complete should trigger escalation to the responsible legal/compliance owner before deployment. This 60% threshold is a TrusteraAI operational rule, not a GDPR or AI Act standard.

Connecting This Checklist to Your Governance Program

This checklist is the DPIA-specific piece, not the whole governance program. It connects to the rest of TrusteraAI’s compliance resources this way:

This checklist builds on the risk assessment methodology covered in our AI Risk Assessment Checklist and pairs directly with our AI Vendor Risk Assessment guide for third-party AI tool vetting, our AI Incident Response Plan for what happens after a control fails, and our Spain GDPR Checklist for SaaS and AEPD Inspection Guide for the regulatory side of serving Spanish customers specifically. For the full governance picture this checklist feeds into, see our AI Governance Checklist for SaaS.

Run this checklist per feature at launch, and again against the full feature set on any regulatory update — the Digital Omnibus is evidence dates can move, and they can move again.

Common Mistakes to Avoid

• Treating the AI Act’s December 2027 deferral as delaying the GDPR DPIA obligation — it doesn’t
• Treating “AI plus personal data” alone as an automatic DPIA trigger, without running the actual Article 35(1)/(3) test
• Assuming Article 3(2) is the only route to GDPR applicability — Article 3(1) can independently apply where there’s an EU establishment
• Skipping the Article 27 representative question because the company has “no EU office,” without checking territorial scope properly
• Completing the DPIA after the feature has already shipped to Spanish users
• Assuming every Annex III high-risk deployer needs an Article 27 FRIA — its scope is limited to specific deployer categories
• Treating a completed DPIA as satisfying an Article 27 FRIA where both apply — they’re separate documents, though sections can be cross-referenced
• Running screening once for the whole product instead of per feature, which hides risk in the features nobody re-checked
• Leaving the “DPIA not required” conclusion undocumented, which removes your best evidence if the reasoning is ever questioned
• Treating TrusteraAI’s recommended controls (scoring methodology, 12-month review cadence, 60% escalation threshold) as if they were themselves GDPR requirements, rather than the operational practices they are

Best Practices

• Run the Screening section per feature, not once for the whole product
• Track the GDPR DPIA timeline and the AI Act Article 26/27 timeline as two separate rows, never merged
• Document “DPIA not required” conclusions with the same rigor as completed DPIAs
• Reassess the DPIA when material changes to the processing, system, model, purposes, data categories, or known risks could affect the original assessment
• Assign a single accountable owner per section, not just per item, so gaps don’t fall between roles
• Keep “Required,” “Assessment,” and “Recommended” items visually distinct in your internal tracking so legal review time goes to the right items first

Key Takeaways

✅ GDPR Article 35’s DPIA requirement is risk-based and fully live today — it was never on the AI Act’s timeline and wasn’t touched by the Digital Omnibus.

✅ The Digital Omnibus deferred the relevant EU AI Act Annex III high-risk obligations, including applicable Article 26 deployer duties and applicable Article 27 FRIA obligations, to December 2, 2027 — track those separately from your GDPR DPIA work.

✅ “AI plus personal data” is not itself a DPIA trigger; the Article 35(1) risk test, Article 35(3) categories, and the broader EDPB/WP29 risk-factor approach are.

✅ GDPR territorial scope can arise under Article 3(1) (EU establishment) or Article 3(2) (targeting/monitoring without establishment) — check both, not just one.

✅ Run screening per feature — one company-wide “yes” or “no” answer isn’t how Article 35 actually works.

Frequently Asked Questions