The Data Protection Officer in Frankfurt and the AI Officer in Dublin are looking at the same system: an HR resume-ranker that processes 40,000 candidate profiles a year across the EU footprint. The DPO has a GDPR Article 35 Data Protection Impact Assessment in flight. The AI Officer has an EU AI Act Article 27 Fundamental Rights Impact Assessment in flight. They are running them on different templates, with different reviewers, on different timelines, and they will arrive at slightly different conclusions about the same population, the same lawful basis questions, and the same mitigation set. A regulator looking at both artifacts later will spot the inconsistency before lunch. This is the lesson where the DPIA and the FRIA become one workstream: separate articles, overlapping evidence, single template, one signed-off artifact per system per year, two officers co-owning the file.

Why a Combined DPIA/FRIA Template Is the Defensible Posture in 2026

The DPIA and the FRIA are statutorily distinct. The DPIA sits under GDPR Article 35; the FRIA sits under EU AI Act Article 27. They have different scopes, different triggers, and different review authorities. The DPIA addresses processing of personal data and the rights of data subjects; the FRIA addresses fundamental-rights impact of an AI system on affected persons in a deployment context. The two are not interchangeable, and one cannot be substituted for the other.

What they share is bigger than what separates them. Both require an identification of affected populations. Both require risk assessment with severity and likelihood. Both require mitigation measures. Both require oversight. Both require documentation that will be reviewed by an authority. For many high-risk AI systems that process personal data, which is most of Annex III, both will be required. The European Data Protection Board signalled in its 2025 statement on the AI Act that integration of DPIA and FRIA workflows is consistent with the supervisory-authority expectation, provided the distinct article-specific requirements of each are visibly addressed. The EDPB has not endorsed merging the two into a single artifact; it has endorsed integrated workstreams that produce both DPIA-compliant and FRIA-compliant output from a single evidentiary base.

The operational economics are decisive. Running DPIA and FRIA as parallel artifacts on parallel templates with parallel reviewers doubles the elapsed time, the headcount cost, and, most importantly, the consistency-risk surface. Two separate documents on the same system will say slightly different things about the affected population, the residual risk, or the consent posture, and a regulator will find the divergence. A combined workstream with shared evidence and parallel sign-off produces one canonical view of the system's risk and two compliant artifacts.

This is the L2 artifact for this lesson: a combined DPIA/FRIA template, a roles RACI for the DPO and the AI Officer, and the Article 27(3) notification process for the national supervisory authority. The lesson walks the GDPR Article 35 triggers, the AI Act Article 27 triggers, the overlap zone, the distinct elements that each article uniquely requires, and the twelve-section template that integrates them.

GDPR Article 35 - When a DPIA Is Required

GDPR Article 35(1) requires a DPIA where processing is "likely to result in a high risk to the rights and freedoms of natural persons." Article 35(3) lists three specific cases where a DPIA is always required, and Article 35(4) authorises supervisory authorities to publish lists of additional cases where a DPIA is required. The triggers, in operational terms:

• Article 35(3)(a) - Systematic and extensive evaluation of natural persons based on automated processing, including profiling, on which decisions are based that produce legal effects or similarly significantly affect the natural person. Credit-scoring, insurance underwriting, employment screening, fraud-scoring, eligibility decisioning. The same systems that often trigger the Article 27 FRIA.
• Article 35(3)(b) - Processing on a large scale of special categories of data (Article 9) or personal data relating to criminal convictions and offences (Article 10). Health-AI applications, biometric systems processing biometric data for identification, AI systems processing political-opinion or sexual-orientation inferences. The Article 9 overlap with the AI Act Article 10(5) bias-monitoring carve-out is where the lawful-basis stacking gets technical.
• Article 35(3)(c) - Systematic monitoring of a publicly accessible area on a large scale. Smart-city camera systems, retail-analytics camera networks, public-transport AI surveillance, traffic-management AI that captures faces or licence plates.
• Article 35(4) supervisory-authority lists. Each EU Member State's data-protection authority publishes a list of processing operations requiring a DPIA. CNIL (France), BfDI / Landes-DPAs (Germany), Garante (Italy), AEPD (Spain), DPC (Ireland), and the others. The lists vary by Member State and are updated periodically. A multi-jurisdiction deployment must check each relevant national list.

The Article 35(7) substantive requirements for the DPIA itself: systematic description of the processing operations and purposes; assessment of necessity and proportionality; assessment of risks to data-subject rights; and the measures envisaged to address the risks. Article 35(2) requires consultation with the Data Protection Officer where one is designated. Article 36 requires prior consultation with the supervisory authority where the DPIA indicates high residual risk that the controller cannot mitigate.

The DPIA is the GDPR's signature impact-assessment instrument. It long predates the AI Act, the methodology is mature, and the supervisory-authority expectations are well-developed. The 2017 Article 29 Working Party guidelines (WP 248 rev.01) remain the canonical methodology reference. CNIL's PIA software tool is the de facto reference implementation for many programs.

EU AI Act Article 27 - When a FRIA Is Required

Article 27(1) lists four trigger categories for the FRIA. The triggers are narrower than the DPIA, they apply only to deployers of specific high-risk AI systems, but where they apply, they are firm. The triggers:

• Public-body deployers of any Annex III high-risk AI system. Government agencies, ministries, public universities, public hospitals, municipal authorities, public-broadcasting authorities. A public body deploying any Annex III system, §1 biometrics, §3 education, §4 employment, §5 essential services, §6 LE, §7 migration, §8 justice, owes a FRIA.
• Private operators providing public services with any Annex III system. Private contractors operating prisons, private hospitals delivering public-health services, private utilities providing essential services. A private operator delivering a service that has been classified as a public service under national or EU law and using an Annex III system in that delivery owes a FRIA.
• All deployers of Annex III §5(b) creditworthiness scoring systems. Banks, credit-card issuers, mortgage lenders, fintech-credit providers, embedded-finance operators. Regardless of public-body status. The Aug 2, 2026 FRIA capability deadline applies to private-sector banks, not just public banks.
• All deployers of Annex III §5(c) life and health insurance risk-assessment and pricing systems. Private life insurers, private health insurers, life-and-health underwriting platforms. Regardless of public-body status.

The Article 27(1) substantive requirements for the FRIA: description of the deployment process consistent with the intended purpose; period and frequency of use; categories of natural persons and groups likely to be affected; specific risks of harm likely to impact those categories; human-oversight measures pursuant to Article 14; measures to be taken if those risks materialise (governance arrangements, complaint mechanisms, recourse); and identification of the supervisory authority for notification.

Article 27(3) requires notification of the FRIA to the national supervisory authority. The deployer notifies the results of the FRIA to the national market-surveillance authority designated under Article 70. The Commission is empowered to publish a template (Article 27(5)). As of mid-2026 the template is in draft circulation and is expected to be finalised in the late-2026 implementing-act window. Programs should prepare for a Commission-published template structure and design the internal FRIA template to be readily transposable into the Commission's structure when published.

The FRIA is the AI Act's signature impact-assessment instrument. The methodology is newer than the DPIA, the article was drafted with the Charter of Fundamental Rights of the EU in mind, not GDPR practice, and the methodology is still maturing through Member State practice. Programs should not assume DPIA methodology transfers directly into FRIA. The two methodologies share elements but the FRIA's fundamental-rights frame is broader than the DPIA's data-subject-rights frame.

The Overlap Zone and the Distinct Elements

Most enterprise Annex III systems that process personal data will need both a DPIA and a FRIA. The overlap zone is where the two artifacts examine the same fact base. The distinct elements are where each article uniquely requires its own analysis. Mapping the overlap and the distinct elements is the engineering work that produces the combined template.

The overlap zone - addressed once, cited from both artifacts:

• Affected-population identification (data subjects under GDPR; affected persons and groups under AI Act).
• Bias examination (GDPR fairness principle under Article 5(1)(a); AI Act Article 10 data-governance plus FRIA risk-of-harm analysis).
• Risk assessment methodology (severity × likelihood under both regimes, with regime-specific risk taxonomies overlaid).
• Mitigation measures (technical and organisational measures under GDPR Article 32; oversight and governance measures under AI Act Article 14 and Article 27(1)(e)).
• Human-oversight design (DPIA's data-subject-rights perspective; FRIA's Article 14 oversight perspective).
• Documentation retention and management-review cycle (GDPR controller accountability under Article 24; AI Act Article 18 record-keeping for high-risk systems).
• Stakeholder consultation (DPIA encourages consultation with affected persons or representatives; FRIA does not mandate but supports it).

Distinct DPIA elements: addressed only in the GDPR section of the combined artifact:

• Lawful basis for processing under GDPR Article 6: consent, contract, legal obligation, vital interests, public task, legitimate interests. For special-category data, Article 9 additional grounds.
• Consent design under GDPR Article 7 where consent is the lawful basis: freely given, specific, informed, unambiguous; revocable; auditable.
• Information to data subjects under Articles 13 and 14: privacy notice content, timing, language, accessibility.
• Data-subject rights: Article 15 access, Article 16 rectification, Article 17 erasure, Article 18 restriction, Article 20 portability, Article 21 objection, Article 22 automated decision-making with significant effect (right not to be subject to + safeguards including human-review pathway, the right to express a point of view, the right to contest).
• Data minimisation and accuracy under Article 5(1)(c) and 5(1)(d).
• Storage limitation and retention schedule under Article 5(1)(e).
• Security of processing under Article 32: pseudonymisation, encryption, confidentiality, integrity, availability, resilience, restoration.
• Cross-border transfer mechanism under Chapter V - Schrems II analysis, Standard Contractual Clauses, adequacy decisions, Binding Corporate Rules, Article 49 derogations.
• Breach notification process under Articles 33 (to supervisory authority within 72 hours) and 34 (to data subjects without undue delay where high risk).
• DPO consultation outcome under Article 35(2).
• Prior-consultation trigger to supervisory authority under Article 36 where residual risk is high.

Distinct FRIA elements, addressed only in the AI Act section of the combined artifact:

• Description of the deployment process consistent with the intended purpose (Article 27(1)(a)).
• Period and frequency of use (Article 27(1)(b)).
• Categories of natural persons and groups likely to be affected (Article 27(1)(c)), broader than GDPR data subjects, includes indirect affected persons and affected groups.
• Specific risks of harm likely to impact those categories (Article 27(1)(d)): fundamental-rights frame including Charter Articles 1 (dignity), 7 (private life), 8 (data protection), 14 (education), 15 (occupation), 20 (equality before law), 21 (non-discrimination), 31 (working conditions), 41 (good administration), 47 (effective remedy).
• Human-oversight measures pursuant to Article 14 (Article 27(1)(e)), the oversight is on the AI system, not the processing.
• Measures to be taken if those risks materialise: governance arrangements, complaint mechanisms, recourse (Article 27(1)(f)).
• Identification of the supervisory authority for notification under Article 27(3).
• Article 27(3) notification process: submission timing, format, follow-up cadence.
• Integration with the Article 26 deployer monitoring runbook, the FRIA informs the post-deployment monitoring; the monitoring updates the FRIA.
• Article 86 right-to-explanation design where applicable (§5(b) credit-scoring and other systems with significant individual impact).

The overlap zone is approximately 50-60% of the substantive content. The DPIA-only material is approximately 20-25%. The FRIA-only material is approximately 20-25%. The combined template structure is engineered to surface the overlap once and call out the distinct elements clearly under each regime's section.

The Combined DPIA/FRIA Template - Twelve Sections

The combined template structure that produces both a DPIA-compliant and a FRIA-compliant artifact from a single workstream:

1. Section 1 - System description. AI system name, provider, version, intended purpose (Article 4(12) AI Act + linking to Article 13 instructions for use), deployment context, deployment surface, integration points. Overlap zone, cited from both DPIA and FRIA.
2. Section 2 - Lawful basis and AI Act applicability. GDPR Article 6 lawful basis stacking (with Article 9 special-category overlay where applicable); AI Act tier classification (Annex III sub-category citation, Article 27 trigger, Article 50 disclosure trigger). DPIA-distinct and FRIA-distinct elements addressed in parallel subsections.
3. Section 3 - Affected populations. GDPR data subjects (direct), AI Act affected persons (direct and indirect), affected groups, vulnerable subgroups, intersectional analysis. Overlap zone with FRIA-distinct expansion to affected groups beyond data subjects.
4. Section 4 - Processing and deployment description. GDPR processing operations (collection, storage, use, transfer, deletion); AI Act deployment process (period and frequency of use, integration with human reviewers). Overlap zone with parallel descriptions per regime.
5. Section 5 - Necessity and proportionality. GDPR Article 35(7)(b) necessity-and-proportionality assessment; AI Act intended-purpose alignment and least-intrusive-means analysis. Overlap zone with regime-specific framing.
6. Section 6 - Risk identification. GDPR risks to data-subject rights (taxonomy under WP 248); AI Act fundamental-rights risks (Charter article-by-article); bias and discrimination risk (overlap with both); security risks (overlap with both); accuracy and reliability risks. Overlap zone with regime-specific risk taxonomies in parallel subsections.
7. Section 7 - Risk assessment. Severity × likelihood matrix; per-risk score; per-risk residual rating after mitigation. Overlap zone, single assessment exercise; both regimes reference the same outputs.
8. Section 8 - Mitigation measures. Technical measures (encryption, pseudonymisation, access controls, audit logs); organisational measures (training, role-based access, segregation of duties); GDPR-specific (data minimisation, retention, breach response); AI-Act-specific (Article 14 human oversight, Article 27(1)(f) recourse, Article 86 explanation). Overlap zone with regime-specific subsections.
9. Section 9 - Data-subject rights and AI Act recourse. Article 22 automated-decision-making safeguards (human-review pathway, right to express view, right to contest); Articles 13-21 rights operationalisation; AI Act Article 27(1)(f) complaint mechanisms and recourse; Article 86 right-to-explanation where applicable. DPIA-distinct and FRIA-distinct elements with explicit cross-references.
10. Section 10 - Cross-border transfer and breach. GDPR Chapter V transfer mechanism; SCCs / adequacy / BCR / Article 49 derogations; Articles 33 and 34 breach-notification process. DPIA-distinct.
11. Section 11 - Oversight and governance. DPO consultation (Article 35(2)) with outcome; AI Officer sign-off; Article 27(3) supervisory-authority notification; Article 36 prior-consultation trigger; management-review cadence; refresh trigger conditions. Combined oversight section with both signatories.
12. Section 12 - Documentation and retention. Combined artifact retained per GDPR controller accountability (Article 24) and AI Act Article 18 record-keeping (typically 10 years for high-risk systems). Overlap zone with regime-specific retention triggers.

Twelve sections, two compliant artifacts, one workstream. The template is designed for a 30-50 page typical artifact for a Fortune-500 system. The signoff page identifies both the DPO (DPIA owner under Article 35(2)) and the AI Officer (FRIA owner under Article 27).

Roles, RACI, and the Article 27(3) Notification Process

The combined workstream needs a clear roles structure to prevent the diffusion-of-responsibility failure mode where everyone assumes the other officer owns the work and neither completes it. The RACI for a typical enterprise:

• DPO (Data Protection Officer), Accountable for DPIA-compliant output. Owns the GDPR-distinct sections (Sections 2 GDPR-side, 9, 10, 11 DPO-consultation). Sign-off on the DPIA portion. Article 36 prior-consultation decision authority.
• AI Officer (or Chief AI Officer), Accountable for FRIA-compliant output. Owns the FRIA-distinct sections (Sections 2 AI-Act-side, 9 FRIA-side, 11 AI-Officer-signoff). Sign-off on the FRIA portion. Article 27(3) notification authority.
• Privacy Engineering / AI Engineering joint team: Responsible for the overlap-zone sections (Sections 1, 3, 4, 5, 6, 7, 8, 12). Produces the evidence base that both officers use.
• Information Security / CISO, Consulted on Section 8 technical measures; Section 10 breach response; Section 11 oversight.
• Legal / Compliance: Consulted on Section 2 lawful basis, Section 9 rights operationalisation, Section 10 cross-border-transfer mechanism, Section 11 supervisory-authority notification.
• Business Unit / System Owner: Responsible for Section 1 system description, Section 4 processing/deployment, Section 5 necessity-and-proportionality. Provides the operational facts.
• Affected-Person Representatives, Consulted where appropriate (works council for §4 employment systems; consumer advocacy for §5(b)/§5(c) systems; civil-society groups for public-service deployments).
• National Supervisory Authority, Informed via Article 27(3) FRIA notification; consulted via Article 36 GDPR prior consultation where residual risk is high.

The Article 27(3) notification process for the FRIA-side notification:

1. Identify the supervisory authority. Article 70 designates national market-surveillance authorities. For most Member States, the national data-protection authority is one of the designated bodies; in some Member States there is a separate AI supervisory body. Identify the relevant authority for the deployer's establishment and for each Member State of operation.
2. Prepare the notification. Use the Commission-published template (Article 27(5)) when issued; until then, structure the notification on the Article 27(1) requirements with regime-appropriate citations.
3. Submit the notification. Article 27(3) does not specify a precise timing but supervisory-authority practice will establish expectations. Submit at completion of the FRIA and at each material refresh.
4. Track the notification. Confirmation of receipt, any follow-up requests from the authority, any required updates. The notification register becomes part of the Article 18 record-keeping.
5. Refresh on triggering events. Material change in intended purpose, period or frequency of use, affected populations, identified risks, or mitigation measures triggers a refresh of the FRIA and a refreshed notification.

The notification register should track the date of submission, the authority receiving the notification, the system identifier, the FRIA version, any authority follow-up, and the next-refresh trigger. The register integrates with the AI inventory and the Annex IV technical-file backlog.

The Article 10(5) Bias-Monitoring Special-Category-Data Carve-Out

A subtle but operationally critical interaction: AI Act Article 10(5) creates a narrow carve-out for processing special-category personal data (GDPR Article 9) for the purpose of bias monitoring of high-risk AI systems, where strict conditions are met. The carve-out allows providers to process special-category data for bias detection and correction in development, without that processing relying on data-subject consent (which is often impractical at the dataset scale required). The conditions are demanding: state-of-the-art security and privacy-preserving measures; pseudonymisation; access controls; retention strictly necessary for the bias-monitoring purpose; no further processing beyond bias monitoring.

The interaction with GDPR is technical. Article 10(5) provides the AI Act foundation; the controller still needs a GDPR Article 6 lawful basis (typically Article 6(1)(e) public interest or Article 6(1)(f) legitimate interest, with Article 9(2) ground stacked, typically Article 9(2)(g) substantial public interest under Member State or Union law where one is established, or Article 9(2)(j) archiving / research where applicable). The combined DPIA/FRIA must explicitly walk the Article 10(5) + Article 6 + Article 9 lawful-basis stack for any bias-monitoring data processing in scope.

The DPO and the AI Officer should jointly own the Article 10(5) analysis because the analysis sits squarely in the overlap. Programs that punt the Article 10(5) analysis to one office or the other will produce inconsistent justification.

Cross-Walks - GDPR, AI Act, ISO 42001, NIST AI RMF

The combined DPIA/FRIA artifact will be reviewed by multiple authorities and auditors. The cross-walk that should sit at the front of the artifact:

• GDPR Articles cited: 5 (principles), 6 (lawful basis), 7 (consent), 9 (special-category data), 13 and 14 (information to data subjects), 22 (automated decision-making), 25 (data protection by design and by default), 32 (security of processing), 33 (breach notification to authority), 34 (breach notification to data subjects), 35 (DPIA), 36 (prior consultation).
• EU AI Act Articles cited: 10 (data governance, including 10(5) bias-monitoring carve-out), 14 (human oversight), 26 (deployer obligations), 27 (FRIA, including 27(1) requirements and 27(3) notification), 50 (transparency obligations), 72 (post-market monitoring system by providers), 73 (incident reporting).
• ISO 42001 controls cited: A.5 (impact assessment of AI system, the Annex A control that directly maps to FRIA + DPIA), A.7 (data for AI systems: bias monitoring, data quality, data lineage), A.9 (system performance), A.10 (information security), A.16 (incident handling).
• NIST AI RMF cited: Map 5 (impacts on individuals, groups, communities, organizations, and society are characterized), Measure 2 (AI system performance and trustworthiness measurement), Govern 2 (accountability structures).
• Charter of Fundamental Rights of the EU cited: Article 1 dignity, Article 7 private and family life, Article 8 data protection, Article 14 education, Article 15 occupation, Article 20 equality before the law, Article 21 non-discrimination, Article 31 working conditions, Article 41 good administration, Article 47 effective remedy. The Charter cross-walk is the FRIA's fundamental-rights frame.

Cross-walking the combined artifact against the four reference frameworks plus the Charter produces an audit-defensible posture across the EDPB inspection, the AI supervisory authority review, the ISO 42001 Stage 2 audit, and the customer-assurance pack used by procurement teams.

Six Common Mistakes - And How to Catch Them

Mistake 1 - Running DPIA and FRIA on Separate Templates

The DPO's privacy team is running a DPIA on the privacy-program template. The AI Officer's AI-governance team is running a FRIA on a newly-drafted FRIA template. The two artifacts will not agree on the affected population, the residual risk, or the mitigation set. The fix is the combined twelve-section template with shared evidence and parallel sign-off.

Mistake 2 - Missing GDPR Article 22 Design in the FRIA

The FRIA addresses Article 14 human oversight under the AI Act and considers the work done. But Article 22 GDPR has its own safeguards for automated decision-making with significant individual effect: the right not to be subject to such a decision (with exceptions), the right to obtain human intervention, the right to express the data subject's point of view, the right to contest. The Article 14 AI Act oversight is necessary but not sufficient for Article 22 GDPR safeguards. The combined template addresses both explicitly in Section 9.

Mistake 3 - Missing the Article 27 FRIA for §5(b)/§5(c) Deployers

A private bank deploying a credit-scoring AI assumes the FRIA applies only to public-body deployers and skips Article 27. Wrong. Article 27(1) explicitly extends FRIA to all deployers of Annex III §5(b) creditworthiness systems and §5(c) life/health insurance systems regardless of public-body status. The Aug 2, 2026 FRIA capability deadline applies. Missing this is a frequent fail.

Mistake 4 - Missing the Article 27(3) Supervisory-Authority Notification

The FRIA is completed and filed in the internal artifact repository. But Article 27(3) requires notification of the FRIA to the national supervisory authority designated under Article 70. The notification step is overlooked or deferred indefinitely. The notification register should be operational from the first FRIA completion, not added later.

Mistake 5 - Missing the Member State Article 35(4) DPIA List Check

A multi-Member-State deployment checks the GDPR Article 35(3) automatic triggers and concludes no DPIA is required. But Article 35(4) authorises national supervisory authorities to publish lists of additional processing operations requiring a DPIA, and many Member States have published expansive lists. CNIL's list, the German BfDI / Landes-DPA lists, the Garante's list, the AEPD's list, the DPC's list, each must be checked for relevant deployment Member States. Missing the list check is a frequent under-tiering failure.

Mistake 6 - Treating the Combined Template as Static

The combined template is built in early 2026 and not refreshed. The Commission publishes the Article 27(5) FRIA template in late 2026 with structural specifications. The EDPB issues 2027 guidance on integration. National supervisory authorities publish expectation notes through 2026-2027. The combined template must be living: refreshed against Commission, EDPB, and national supervisory-authority guidance as it issues. The combined template versioning, refresh cadence, and stakeholder review cycle should be designed in from the start.

Key Takeaways

• The DPIA and FRIA are statutorily distinct but operationally overlapping. Running them as parallel artifacts on parallel templates doubles cost and creates consistency risk. Running them as a single workstream with a combined template and parallel sign-off produces both compliant artifacts efficiently.
• GDPR Article 35 DPIA triggers, systematic and extensive evaluation with automated processing and legal effects (35(3)(a)); large-scale special-category or criminal data (35(3)(b)); large-scale systematic monitoring of publicly accessible area (35(3)(c)); Member State supervisory-authority lists under 35(4).
• EU AI Act Article 27 FRIA triggers, public-body deployers of any Annex III system; private operators providing public services with Annex III systems; all deployers of §5(b) creditworthiness systems; all deployers of §5(c) life/health insurance systems. The §5(b)/§5(c) Aug 2, 2026 capability deadline applies to private-sector deployers.
• The overlap zone is 50-60% of substantive content. Affected-population identification, bias examination, risk assessment, mitigation, oversight, documentation, stakeholder consultation. Addressed once and cited from both regimes.
• The DPIA-distinct elements include lawful basis (Articles 6 + 9), consent design (Article 7), data-subject rights (Articles 13-22 with Article 22 automated decision-making), cross-border transfer (Chapter V), breach notification (Articles 33 + 34).
• The FRIA-distinct elements include deployment process description, period and frequency of use, categories of affected persons and groups, fundamental-rights risk taxonomy (Charter cross-walk), Article 14 human oversight, recourse mechanisms, and Article 27(3) supervisory-authority notification.
• The combined twelve-section template: system description, lawful basis and AI Act applicability, affected populations, processing and deployment, necessity and proportionality, risk identification, risk assessment, mitigation, rights and recourse, cross-border and breach, oversight and governance, documentation and retention.
• The DPO owns the DPIA portion; the AI Officer owns the FRIA portion; joint engineering team owns the overlap zone. Combined sign-off page with both officers.
• Article 10(5) bias-monitoring special-category-data carve-out requires the GDPR Article 6 + Article 9 lawful-basis stack to be walked explicitly in the combined artifact. The DPO and AI Officer jointly own the Article 10(5) analysis.
• Article 27(3) notification to the national supervisory authority is a frequently-missed step. The notification register should be operational from the first FRIA completion and refreshed on material change.
• The L2 artifact for this lesson: combined DPIA/FRIA template with twelve sections, roles RACI for DPO + AI Officer + joint engineering + InfoSec + Legal + Business Unit + Affected-Person Representatives + National Supervisory Authority, and the Article 27(3) notification process documentation.