If you deploy an AI system in a regulated environment, you will encounter impact assessment obligations from multiple directions. The EU AI Act requires a Fundamental Rights Impact Assessment (FRIA). GDPR requires a Data Protection Impact Assessment (DPIA). ISO 42001 calls for AI-specific impact analysis. The NIST AI Risk Management Framework asks for context and impact mapping. Medical device regulations under the EU MDR and ISO 14971 require clinical evaluation and risk management. These are not separate, unrelated exercises. They share a common structure, and organisations that recognise this can build one disciplined process that satisfies all of them.
The Universal Structure of Impact Assessments
Regardless of the framework, every impact assessment follows the same four-step methodology:
- Identify affected parties: Who will be subject to the AI system's outputs? This includes direct users, individuals whose data is processed, and populations affected by downstream decisions.
- Assess risks and harms: What are the potential negative consequences? These range from fundamental rights violations (FRIA) to data protection harms (DPIA) to clinical safety risks (EU MDR, ISO 14971).
- Document mitigations: What controls, oversight measures, and technical safeguards are in place to reduce identified risks?
- Review continuously: How will the assessment be updated as the system changes, as new data emerges, and as model behaviour drifts over time?
This is not a coincidence. Regulators converged on this structure because it works. The differences between frameworks lie in scope (which rights or harms are covered), trigger (what initiates the obligation), and reporting (who must be notified). The analytical method is consistent.
Framework-by-Framework Requirements
EU AI Act Article 27: Fundamental Rights Impact Assessment (FRIA)
Article 27 of EU AI Act Regulation 2024/1689 requires certain deployers of high-risk AI systems to conduct a Fundamental Rights Impact Assessment before deployment. The obligation applies to:
- Public bodies deploying any high-risk AI system listed in Annex III
- Private bodies deploying high-risk AI systems listed in Annex III point 1 (biometric identification), point 6 (law enforcement), point 7 (migration and border control), or point 8 (administration of justice)
The FRIA must cover: a description of the deployer's processes and conditions of use; the geographic scope and period of deployment; the categories of natural persons likely to be affected; specific risks to fundamental rights including dignity, privacy, non-discrimination, freedom of expression, and access to justice; the human oversight and technical measures taken to address identified risks; and any relevant fundamental rights bodies consulted.
Article 27(4) requires deployers to notify the relevant national market surveillance authority of the results before putting the system into use. This is an active obligation, not passive record-keeping.
GDPR Article 35: Data Protection Impact Assessment (DPIA)
When AI processing is likely to result in a high risk to the rights and freedoms of natural persons, GDPR Article 35 requires a Data Protection Impact Assessment. This applies to any data controller, not just AI deployers specifically. The DPIA must include a systematic description of the processing, an assessment of necessity and proportionality, an evaluation of risks to data subjects, and the measures to address those risks. If your AI system processes personal data and also triggers FRIA requirements, you need both assessments.
ISO 42001 Annex B: AI Management System Impact Assessment
ISO/IEC 42001 (the AI management system standard) includes Annex B guidance on conducting AI impact assessments. Unlike regulatory mandates, this is a voluntary standard, but organisations seeking ISO 42001 alignment must demonstrate a structured impact assessment process. The standard calls for identifying stakeholders, evaluating potential societal and individual impacts, and establishing proportionate controls. It emphasises integration with the organisation's broader management system rather than treating impact assessment as an isolated compliance exercise.
NIST AI RMF: Map Function (Context and Impact Analysis)
The NIST AI Risk Management Framework organises risk management into four functions: Govern, Map, Measure, and Manage. The Map function is where impact assessment lives. It requires organisations to establish the context in which the AI system operates, identify stakeholders who may be affected, and catalogue risks across categories including validity, safety, fairness, privacy, and transparency. NIST does not prescribe a single assessment template. Instead, it provides a flexible framework that organisations adapt to their sector and risk profile.
EU MDR: Clinical Evaluation and Risk-Benefit Analysis
For AI systems that qualify as medical devices under the EU Medical Device Regulation (2017/745), clinical evaluation is the impact assessment equivalent. Manufacturers must demonstrate that the device achieves its intended clinical benefits and that residual risks are acceptable relative to those benefits. When the AI component drives or influences clinical decisions, the clinical evaluation must address the AI-specific risks: data quality, algorithmic bias, performance degradation, and the adequacy of human oversight in clinical workflows.
ISO 13485 and ISO 14971: Risk Management for Medical Devices
ISO 14971 provides the international standard for risk management of medical devices, and ISO 13485 requires its implementation within the quality management system. For AI-enabled medical devices, this means identifying hazards introduced by the AI component (training data bias, model drift, edge-case failures), estimating their probability and severity, implementing risk controls, and verifying residual risk acceptability. The process is continuous: risk management files must be updated whenever the device or its operating context changes.
How Frameworks Overlap
| Dimension | EU AI Act FRIA | GDPR DPIA | ISO 42001 | NIST AI RMF | EU MDR / ISO 14971 |
|---|---|---|---|---|---|
| Trigger | Deployment of specific high-risk AI (Annex III) | High-risk data processing | Voluntary alignment | Voluntary adoption | AI classified as medical device |
| Who does it | Deployer | Data controller | Organisation (any role) | Organisation (any role) | Manufacturer |
| Scope of assessment | Fundamental rights (EU Charter) | Data protection rights | Societal and individual impact | Validity, safety, fairness, privacy | Clinical safety, risk-benefit |
| Timing | Before deployment | Before processing begins | Ongoing within management system | Throughout AI lifecycle | Before market placement; ongoing |
| Reporting | Notify market surveillance authority | Consult supervisory authority if high residual risk | Internal management review | Internal governance | Clinical evaluation report; technical file |
| Continuous review | Update when system changes materially | Review when processing changes | Integrated into PDCA cycle | Measure and Manage functions | Post-market surveillance |
Why Continuous Assessment Matters
A point-in-time impact assessment captures the risk profile at the moment of deployment. It says nothing about what happens after the model encounters real-world data, after user behaviour patterns shift, or after upstream data pipelines change. Model drift, distribution shift, and evolving use patterns can introduce new risks that did not exist at deployment.
Every framework recognises this. The EU AI Act requires updates when the system changes materially. GDPR calls for review when the nature of processing changes. ISO 14971 mandates post-market surveillance. NIST structures its entire framework around iterative Measure and Manage cycles. ISO 42001 embeds impact assessment into the Plan-Do-Check-Act loop.
A continuous approach to impact assessment is not optional best practice. It is what the regulations actually require. Organisations that treat the initial assessment as a one-time document will find themselves non-compliant the moment their system changes.
Building a Unified Impact Assessment Process
A practical, multi-framework impact assessment process should follow these steps:
- Determine applicable frameworks: Identify which regulations and standards apply to your AI system. An EU-deployed system processing personal data may need to satisfy FRIA, DPIA, and ISO 42001 simultaneously. A medical AI will add EU MDR and ISO 14971. The Vigilens classifier identifies your system's regulatory obligations in six questions.
- Map affected parties comprehensively: Document all categories of natural persons whose rights, safety, or interests could be affected. Go beyond direct users to include individuals subject to AI-driven decisions, populations exposed to systemic bias, and communities affected by aggregate deployment patterns.
- Assess risks across all applicable scopes: A unified assessment should evaluate fundamental rights (for FRIA), data protection (for DPIA), clinical safety (for EU MDR), and broader societal impact (for ISO 42001 and NIST). Consolidate these into a single risk register with clear traceability to each framework's requirements.
- Document mitigations with dual attribution: For each risk, document both the human oversight measure and the technical control. Tag each mitigation to the specific framework requirement it satisfies. This creates the traceability auditors and regulators expect.
- Establish continuous monitoring: Define triggers for reassessment: model retraining, data pipeline changes, performance metric drift, user complaint patterns, and regulatory updates. Automate detection where possible.
- Maintain reporting readiness: Keep assessment documentation in a state where it can be submitted to a market surveillance authority (FRIA), a data protection authority (DPIA), or an audit team (ISO 42001) at any time, without scrambling to compile records.
Frequently Asked Questions
Do all AI governance frameworks require impact assessments?
Yes. The EU AI Act requires a Fundamental Rights Impact Assessment (FRIA) for certain deployers. GDPR Article 35 requires a Data Protection Impact Assessment (DPIA) when processing poses high risks to individuals. ISO 42001 Annex B calls for AI-specific impact assessments. The NIST AI RMF Map function requires context and impact analysis. EU MDR requires clinical evaluation and risk-benefit analysis. ISO 14971 mandates risk management for medical devices. The methodology is consistent across all of them: identify affected parties, assess risks, document mitigations, and review continuously.
Can a single impact assessment process satisfy multiple frameworks?
In principle, yes. The underlying methodology is consistent: identify who is affected, evaluate the nature and severity of potential harms, document controls and mitigations, and establish a review cycle. A structured, continuous impact assessment process can produce the evidence and documentation required by FRIA, DPIA, ISO 42001, NIST AI RMF, and medical device regulations simultaneously. Each framework has specific scope and reporting obligations that must be addressed individually, but the analytical work is shared.
How does the EU AI Act FRIA differ from a GDPR DPIA?
A GDPR DPIA covers data protection rights only. The EU AI Act FRIA covers the full range of fundamental rights under the EU Charter, including dignity, non-discrimination, freedom of expression, and access to justice. If your AI system processes personal data, you will need both a DPIA and a FRIA. The FRIA also requires notification to the national market surveillance authority before deployment, which the DPIA does not.