BLUF: A DPIA and a fundamental-rights impact assessment should not become two competing descriptions of one AI system. Use one versioned evidence platform with two assessment lenses: shared facts about the system, process, people, data, model and controls; lens-specific risk analysis and approvals; and a traceable link from each risk to its control, test and operational owner. This reduces contradictory evidence without collapsing privacy and fundamental-rights analysis into one checkbox.
The legal boundary: shared evidence is not shared legal judgment
Article 27 of the EU AI Act requires specified deployers to perform a fundamental-rights impact assessment before deploying certain high-risk systems. It explicitly says that where an Article 35 GDPR DPIA already meets an Article 27 obligation, the FRIA complements the DPIA. Article 35 GDPR requires a DPIA before processing likely to result in high risk to people’s rights and freedoms, and specifies minimum assessment content. This article describes an engineering pattern, not a determination that either assessment is required for a particular deployment. Classification, role, sector rules, lawful basis and consultation questions require counsel and the accountable controller/deployer.
Why separate documents drift
Privacy, risk, product and engineering teams usually see the same facts at different points in time: model and supplier version, use-case purpose, affected groups, data categories, human role, deployment region, decision consequence, test evidence and incident history. When these facts are copied into separate spreadsheets or PDFs, a change to a retrieval source, model endpoint or user group can leave one assessment current and the other stale. The problem is not insufficient prose. It is an unversioned evidence supply chain.
Start from a policy-as-code use-case intake that establishes ownership, purpose, system and affected-group facts. Then connect supplier and component evidence through the AI supplier control plane and bind technical releases to the lineage gates described in data governance for high-risk AI. These are complementary controls, not substitute assessments.
Architecture: one evidence graph, two controlled lenses
Use immutable evidence objects rather than a master document. Minimum object types are: UseCaseVersion; SystemBoundary; ProcessingActivity; DataAsset; ModelOrComponentVersion; SupplierRecord; AffectedGroup; Risk; Control; TestRun; Finding; Decision; Approval; Incident; and ReassessmentTrigger. Each object has an ID, owner, source link, version, classification, collection time, retention rule and status.
Evidence-flow diagram: intake and change event → fact capture and versioning → shared evidence graph → DPIA lens (processing purpose, necessity/proportionality, personal-data risks, safeguards) plus FRIA lens (process context, affected groups, specific harm, human oversight, governance and complaint arrangements) → risk-to-control-to-test traceability → independent approval tasks → deploy/hold decision → operational signals reopen the relevant evidence and assessment.
The lenses query common objects but create separate assessment records, conclusions and approval states. A DPIA reviewer should not need broad access to sensitive fundamental-rights interview material; a FRIA reviewer should not automatically receive raw personal-data samples. Link by ID, store the minimum necessary evidence in each view and place restricted artefacts behind separate access policies.
Decision table: what can be shared, what must remain lens-specific
| Evidence area | Share as controlled fact | DPIA lens | FRIA lens | Release gate |
|---|---|---|---|---|
| System and process | system boundary, intended purpose, owner, version | processing operations and purpose | deployer process and intended use | hold if boundary or owner is unknown |
| People and data | affected groups, data categories, source/version | necessity, proportionality, personal-data risks | categories of people/groups and plausible harm | hold if affected group or data flow is unverified |
| Controls and tests | control ID, owner, test result, expiry | security/privacy safeguard adequacy | human oversight, governance, complaint mechanism | hold if critical control is untested or expired |
| Change and incident | release, supplier, model, data and signal IDs | reassess processing-risk change | update changed Article 27 elements | hold pending scoped reassessment |
Risk → control → test must be machine-navigable
A useful risk record is not “bias risk: medium”. It states the scenario, affected group, impact, likelihood rationale, evidence references, accountable owner and residual-risk decision. It links to one or more controls: e.g. an eligibility rule, human-approval boundary, retrieval access filter, language-segment evaluation, rollback path or complaint workflow. Every control then links to a test with a versioned method, test data or fixture reference, result, reviewer and expiry. A release service can block promotion when a critical link is absent, failed or stale.
This pattern makes a control assertion falsifiable. “Human oversight exists” becomes: control H-17 requires an authorised approver before an action is executed; integration test T-221 proves the action API rejects an unapproved token; the access-review test has not expired; the owner is named. The graph supports auditability, but does not make a weak human process effective.
A reassessment workflow that reacts to technical reality
Define triggers as events, not calendar reminders alone: a new model or provider release; material prompt/tool change; new data category or source; changed intended user group or decision consequence; expansion to a new region; a failed fairness, safety or privacy test; an incident or substantiated complaint; a control expiry; or a changed legal interpretation raised by counsel. The event creates a scoped review packet showing which evidence objects changed, which risks and controls are affected, and which lens owners must decide.
Article 27 says deployers must update information when its listed elements change or are no longer up to date. GDPR Article 35(11) requires review where necessary, at least when processing risk changes. Engineering should therefore record trigger detection, scope, triage decision, reassessment evidence, approval and release outcome. Do not promise automatic legal conclusions from a rules engine; use automation to route facts and prevent unreviewed promotion.
Failure modes to design out
1. Copy-paste divergence: privacy and AI-governance files cite different model or purpose versions. Mitigation: immutable shared object IDs and a release manifest that references them.
2. Over-sharing: a common workspace exposes interview notes or personal-data samples to every reviewer. Mitigation: field-level classification, lens-scoped views, least-privilege roles and access audit events.
3. Evidence without proof: a mitigation is marked complete but has no repeatable test. Mitigation: require Control → TestRun links and expiry-aware release checks.
4. Change blindness: a provider update, retrieval-index refresh or new user group bypasses assessment. Mitigation: integrate supplier, CI/CD and data-catalogue events with reassessment triggers.
5. Automation theatre: a high score closes a rights-impact question. Mitigation: make residual-risk acceptance and legal interpretation human decisions, with their rationale recorded.
What this platform does not solve
It does not decide whether your system is high-risk, whether a FRIA or DPIA is required, whether processing has a lawful basis, or whether residual risk is acceptable. It does not replace consultation with a DPO, counsel, affected stakeholders or competent authorities where applicable. It also creates real operating cost: object stewardship, access design, integration work and test maintenance. For low-impact pilots, a compact evidence register may be proportionate. For material deployments, disconnected documents are usually the more expensive failure mode.
Implement the smallest useful evidence spine
Choose one live or planned workflow. Version its system boundary and purpose, map three affected groups and data flows, define five risks, assign controls and tests, and establish three triggers: model/provider change, data-source change and failed control. Then run a tabletop reassessment and prove that a release cannot pass with a stale critical test. I can help your privacy, risk and engineering teams design this evidence spine and turn it into an implementable control-plane backlog.
Sources
Regulation (EU) 2024/1689, Article 27 (EUR-Lex)
