Practical Implementation Tips for a Fundamental Rights Impact Assessment for High-Risk AI Systems
What Article 27 Actually Requires
The EU AI Act Article 27 requires deployers of high-risk AI systems to conduct a fundamental rights impact assessment before putting the system into use. This is separate from the conformity assessment the provider performs. You, as the deployer, must assess the impact of your specific use of the system on the fundamental rights of the people it affects.
Most organizations confuse this with a data protection impact assessment under GDPR Article 35. They overlap, but they are not the same. A DPIA focuses on data processing risks. A fundamental rights impact assessment covers a broader scope: discrimination, human autonomy, access to justice, freedom of expression, dignity, safety, and democratic participation. You likely need both, and they should inform each other, but one does not replace the other.
The assessment must be completed before the high-risk AI system is put into service. It must be updated when circumstances change materially. And it must be available to regulatory authorities upon request.
How to Structure the Assessment for Auditability
Organize by AI Principle, Not by Article Number
Regulators and auditors need to see that you’ve covered every fundamental right at risk. Organizing your assessment by abstract article numbers makes review difficult. Organizing by AI principle makes your coverage visible and your gaps obvious.
The structure in this guide follows eight principles: accountability, transparency, fairness, harm prevention, privacy, data governance, robustness, and human autonomy. Each principle breaks into topics, and each topic contains specific control objectives representing the minimum standard to protect fundamental rights.
For each control objective, document four things: the current state of the control, the assessed impact level on stakeholders given current control effectiveness, any additional remediation or mitigating actions needed, and the expected impact level after remediation with an assigned owner and timeline.
Original implementation tip: Use a four-level impact scale: critical, high, medium, low. Define each level in concrete terms before the assessment begins. Critical means the AI system could cause irreversible harm to fundamental rights with no effective remedy available. High means significant harm is probable without additional controls. Medium means moderate harm is possible but existing controls partially mitigate it. Low means residual risk is within acceptable tolerance. Without predefined scales, different assessors will rate identical risks differently. I’ve seen the same AI system rated “low impact” by the development team and “high impact” by the legal team because nobody agreed on what the levels meant. Define them once, document them in your assessment methodology, and train every assessor before the first assessment begins.
Accountability
Operator Competence
Your AI system is only as safe as the person operating it. Article 27 assessments must evaluate whether operators are competent to use the system safely and whether safeguards prevent incompetent operation.
What to assess:
Verify that the organization has established programs providing detailed information about the operator’s role, required competencies, and the potential consequences of operator errors. This means documented training programs with completion tracking, competency assessments, and refresher requirements.
Check whether mechanisms prevent unqualified individuals from accessing or operating the AI system. This includes role-based access controls tied to demonstrated competency, not just job title. An operator who completed training 18 months ago but hasn’t used the system since may no longer be competent.
Original implementation tip: Test operator competence, don’t just track training completion. Design a practical assessment where operators must interpret AI system outputs, identify situations requiring human override, and demonstrate they know when and how to escalate. A certificate of training completion proves someone sat through a presentation. A practical assessment proves they can operate the system safely. I implement quarterly competency spot-checks for operators of high-risk AI systems. Select three operators randomly, present them with realistic scenarios including edge cases and system errors, and document their responses. If any operator fails to identify a situation requiring intervention, you have a competence gap that no training record will reveal. This directly affects your impact assessment rating for this control.
Misuse Awareness
High-risk AI systems can be misused deliberately or through negligence. Your assessment must evaluate whether the organization understands misuse risks and educates users accordingly.
What to assess:
Confirm that the system includes assessments evaluating the likelihood and potential outcomes of misuse. This means documented misuse scenarios with probability estimates and consequence analysis, not a generic statement that “misuse is possible.”
Verify that users are educated on ethics and security risks related to the AI system. Training should cover specific misuse scenarios relevant to the system, not generic AI ethics content. A fraud detection system and a hiring screening system have completely different misuse profiles.
Original implementation tip: Build a misuse scenario library specific to each high-risk AI system. For each scenario, document who could misuse the system (internal operators, external actors, upstream data providers), how they could misuse it (input manipulation, output misinterpretation, unauthorized use for unintended purposes, circumventing human oversight), what the consequence would be for affected individuals’ fundamental rights, and what controls prevent or detect the misuse. Review the library annually and after every incident. I’ve found that the most damaging misuse scenarios are rarely the obvious ones. An operator using a risk scoring system to expedite decisions for friends and family is misuse that no technical control catches. Your misuse assessment needs to consider human behavior, not just technical attack vectors.
Auditability
If your AI system’s processes can’t be independently audited, you can’t demonstrate compliance and you can’t identify problems before they cause harm.
What to assess:
Verify that established and traceable processes are available for independent auditing. This means documented decision flows, logged inputs and outputs, version-controlled model artifacts, and clear chains of accountability. Confirm that provisions exist to address issues identified through audits.
Check whether audit trails capture sufficient detail to reconstruct how the AI system reached a specific output for a specific individual. For high-risk systems affecting fundamental rights, “the algorithm decided” is not an acceptable explanation to a regulator or a court.
Original implementation tip: Run a mock audit before your first real assessment. Select five individual decisions made by the AI system in the past 90 days. For each decision, attempt to trace backward from the output to the input data, the model version used, the operator who acted on the output, and the business process that consumed the result. Document every point where the trail breaks. If you can’t reconstruct the full decision chain for any of the five cases, your auditability control is not functioning. The mock audit typically takes two days and reveals gaps that documentation reviews miss entirely. Common failures include logging systems that capture the output but not the specific model version, operator actions recorded in a different system with no linkage to the AI output, and input data that was transformed between collection and model inference with no record of the transformation.
Ability to Redress
When an AI system causes harm, affected individuals must have access to effective remedies. This is a fundamental rights requirement, not a customer service enhancement.
What to assess:
Verify that procedures ensure redress is available in the event of harm or adverse impact caused by the AI system. Redress mechanisms should include the ability to challenge an AI-driven decision, request human review, obtain an explanation, and receive compensation or correction when harm is established.
Confirm that affected parties are informed of their redress opportunities. Information must be accessible, timely, and understandable. Burying redress information in page 47 of terms and conditions does not constitute informing affected parties.
Original implementation tip: Test the redress pathway from the affected individual’s perspective. Submit a complaint about an AI-driven decision through the channels available to the public. Measure how long it takes to receive an acknowledgment, how long until a human reviews the case, whether the explanation provided is meaningful, and whether the outcome can actually be changed. I’ve tested redress mechanisms at organizations that believed they had robust procedures and found response times exceeding 30 days, explanations that consisted of “the system determined your score,” and no actual ability to override the AI decision even after human review. If the redress mechanism can’t change the outcome, it’s not redress. Document the test results in your assessment.
Transparency
Traceability
Traceability means you can track what data went into the AI system and what outputs it produced for any given decision.
What to assess:
Verify that the system ensures traceability of input data and corresponding outputs. For high-risk systems, this means every inference must be logged with the input data, the model version, the timestamp, the output, and the confidence level or probability score.
Check whether traceability extends across the full data pipeline, from data collection through preprocessing, feature engineering, model inference, and post-processing of outputs. Gaps anywhere in this chain undermine traceability for the entire system.
Original implementation tip: Define traceability requirements before deployment, not after. Retrofit logging into a production AI system is expensive and often incomplete. Specify at the design stage what must be logged, at what granularity, in what format, and for how long. For high-risk systems under the EU AI Act, I recommend logging at the individual inference level with sufficient detail to reconstruct the decision for any affected person for the duration of the system’s deployment plus the applicable statute of limitations for legal challenges. In practice, this typically means five to ten years of log retention. Storage costs are trivial compared to the cost of being unable to explain a decision to a regulator or court.
Explainability
Affected individuals and oversight personnel must be able to understand why the AI system produced a specific output.
What to assess:
Verify that users can understand and explain the rationale and criteria behind the AI system’s decisions. “Users” here includes both operators and affected individuals, and they need different levels of explanation.
Check whether the explanation method is appropriate for the AI technique used. A linear regression model can provide direct feature contribution explanations. A deep neural network requires post-hoc explainability methods like SHAP values or LIME. A large language model may require attention-based explanations or chain-of-thought documentation.
Confirm that explanations are tested for comprehensibility with representative users, not just produced and assumed to be understood.
Original implementation tip: Build explanation templates for each high-risk AI system tailored to three audiences. For the affected individual: a plain-language explanation of the key factors that influenced the decision, written at a reading level appropriate for the general public. For the operator: a technical summary showing the top contributing features, confidence scores, and any flags or anomalies. For the regulator or auditor: full technical documentation of the model, its training data, its validation results, and the specific inference details. Most organizations produce only the third type and then struggle when an affected individual or their legal representative asks for an understandable explanation. Pre-building templates for all three audiences saves weeks of reactive work when a complaint or inquiry arrives.
Communication
Transparency extends beyond individual decisions to public communication about how and why the organization uses AI.
What to assess:
Verify that procedures enable communication of algorithm-based decision-making to the public when necessary. Check that processes explain the AI system’s purpose, characteristics, limitations, and shortcomings.
Confirm that affected individuals can access and review data stored, recorded, or produced by the AI system about them. This overlaps with GDPR data subject access rights but extends to AI-specific data including model outputs, scores, and classifications applied to the individual.
Original implementation tip: Publish a public-facing AI transparency register listing every high-risk AI system the organization deploys, its purpose, the types of decisions it influences, and how affected individuals can request more information or exercise their rights. This goes beyond what Article 27 strictly requires, but it demonstrates proactive transparency and significantly reduces the volume of individual inquiries because people can self-serve basic information. Several European public sector organizations have already adopted this approach. It also preempts regulatory requests for information by making it publicly available. The transparency register takes one to two weeks to build initially and requires quarterly updates.
Fairness
Unfair Bias Avoidance
Bias in high-risk AI systems directly violates fundamental rights to non-discrimination and equal treatment. This is the area where regulators and courts have shown the most willingness to take enforcement action.
What to assess:
Verify that procedures evaluate and ensure the diversity and representativeness of datasets, including for specific social groups and use cases. Check that the assessment covers training data, validation data, test data, and production data separately, because bias can enter at any stage.
Confirm that mechanisms assess the diversity and representativeness of the algorithm itself. An unbiased dataset can still produce biased outputs if the model architecture, feature selection, or optimization objective introduces systematic disparities.
Verify that the system evaluates whether specific social groups are disproportionately affected by the AI system. This requires defining which protected groups to test, selecting appropriate fairness metrics, setting quantitative thresholds for acceptable disparity, and measuring against those thresholds regularly.
Confirm that mechanisms flag and correct biases, discrimination, or poor system performance when detected.
Original implementation tip: Don’t test for bias only at deployment. Bias emerges over time as production data distributions shift and feedback loops amplify initial disparities. Implement continuous bias monitoring that measures your chosen fairness metrics weekly or monthly depending on decision volume. Set alert thresholds that trigger investigation when disparity exceeds your defined acceptable range. Track bias metrics as time series, not snapshots. I’ve seen systems that passed bias testing at deployment develop significant disparities within six months because the production population differed from the training population in ways nobody anticipated. A monthly demographic parity check would have caught it in the first 30 days. The cost of monthly monitoring is trivial. The cost of discovering bias after a discrimination complaint reaches a regulator is not.
Choose your fairness metrics deliberately and document why you chose them. Demographic parity, equalized odds, and predictive parity cannot all be satisfied simultaneously in most real-world scenarios. Your assessment should document which metric you selected, why it’s appropriate for your use case, what threshold you set, and what trade-offs that choice implies. A regulator will accept a reasoned choice. They won’t accept “we didn’t think about it.”
Harm Prevention
Social Impact Assessment
High-risk AI systems affect not just individuals but communities and society. Your assessment must consider these broader impacts.
What to assess:
Verify that procedures ensure the public understands the AI system’s social impacts. Check whether the organization has assessed the wider social impact including effects on trust, power asymmetry, access to services, and democratic participation.
Confirm that mechanisms exist to limit or suspend deployment of the AI system based on suspicion or objective criteria indicating unacceptable social harm. This means defined suspension triggers, authorized decision-makers, and tested suspension procedures.
Original implementation tip: Conduct a stakeholder mapping exercise for each high-risk AI system. Identify every group that the system affects directly (people whose data is processed or who receive decisions), indirectly (people affected by decisions made about others, such as family members of denied applicants), and systemically (communities or populations affected by the aggregate pattern of decisions). Most impact assessments only consider direct stakeholders. Indirect and systemic impacts are where the most significant fundamental rights risks often lie. A credit scoring system that systematically disadvantages a geographic area creates systemic harm that individual fairness testing won’t detect. Your assessment should explicitly address all three stakeholder categories with specific impact analysis for each.
For deployment limitation triggers, define quantitative thresholds that mandate automatic escalation. For example: if the system’s error rate for any protected group exceeds twice the overall error rate, deployment must be paused pending investigation. If more than three complaints alleging discrimination are received within any 30-day period, deployment must be reviewed by the AI governance body within five business days. Without predefined triggers, the decision to limit deployment becomes political rather than evidence-based, and the organization defaults to continuing operation because pausing has visible business costs while harm to individuals remains invisible in aggregate metrics.
Privacy
Respect for Privacy and Data Protection
Privacy controls for high-risk AI systems must go beyond general GDPR compliance. The AI-specific privacy risks include inference of sensitive attributes from non-sensitive data, reidentification from aggregated or anonymized datasets, unauthorized secondary use of personal data for model training, and privacy erosion through the accumulation of individually innocuous data points that collectively reveal sensitive information.
What to assess:
Verify that mechanisms enable users to exercise control over the processing of personal data in the AI system. This includes consent management, preference settings, and the ability to opt out where legally permitted.
Confirm that measures ensure lawful processing under applicable data protection laws. For each category of personal data processed by the AI system, document the legal basis for processing (consent, legitimate interest, contractual necessity, legal obligation, vital interest, or public task).
Check that data minimization processes limit the personal data processed to what is strictly necessary for the AI system’s intended purpose. This applies to both training data and production inference data.
Verify that mechanisms ensure compliance with data subject rights including access, rectification, erasure, restriction, portability, and objection. For AI systems, the right to erasure raises specific technical challenges: deleting an individual’s data from a trained model may require retraining, and the organization must have a documented approach to handling this.
Original implementation tip: Map the privacy lifecycle of personal data through the AI system end to end. Document where personal data enters the system, how it is transformed, where it is stored, who can access it at each stage, how long it is retained, and how it is deleted. Then compare this map against your privacy notice and legal basis documentation. Gaps between what actually happens and what you’ve told data subjects are compliance failures, and they’re almost always present the first time you do this exercise. I’ve found production AI systems retaining personal data indefinitely in feature stores that were covered by a privacy notice promising 12-month retention. The privacy notice reflected the policy. The feature store reflected engineering reality. The assessment must reflect engineering reality, not policy intent.
Data Governance
Quality and Integrity of Data
Data quality directly affects fundamental rights. A high-risk AI system making decisions based on inaccurate, incomplete, or outdated data can cause systematic harm at scale.
What to assess:
Verify that specific security measures such as encryption and anonymization are implemented to protect personal data within the AI system. Check that these measures cover data at rest, in transit, and during processing, including within development and testing environments.
Confirm that processes ensure the quality and integrity of data used throughout the AI system lifecycle. Quality measures should cover accuracy, completeness, timeliness, consistency, and relevance.
Verify that the AI system adheres to relevant data security and governance standards such as ISO 27001, ISO 27701, and IEEE standards applicable to AI data management.
Check that access controls limit personal data access to authorized individuals, with access logged and reviewed.
Data Governance Structure
What to assess:
Confirm that a formal data protection impact assessment has been conducted for the AI system’s processing activities. The DPIA should cross-reference the fundamental rights impact assessment, and findings from each should inform the other.
Verify that a Data Protection Officer is appointed and actively oversees compliance with data protection laws as they apply to the AI system. Check whether the DPO has been consulted during the AI system’s design and deployment.
Confirm that mechanisms are in place to report processing activities to the supervisory authority as required.
Verify that controls manage cross-border data transfers for personal data processed by the AI system, including appropriate transfer mechanisms (Standard Contractual Clauses, adequacy decisions, binding corporate rules) and transfer impact assessments.
Original implementation tip: Conduct a data quality assessment specifically for the AI system’s training data and production data. Measure accuracy, completeness, and currency using quantitative metrics, not subjective ratings. For example, measure the percentage of records with missing values in critical fields, the age distribution of records in the training set compared to the current population, and the error rate detected through manual sampling of labeled data. Document these metrics and set minimum thresholds. If training data accuracy falls below your threshold, the model should not proceed to deployment until the data quality issue is resolved. I’ve seen organizations deploy high-risk AI systems trained on data with 15% missing values in key fields and 30% of records older than three years. Nobody measured data quality because nobody defined what “adequate quality” meant for that specific use case. Define it before you build the model.
For cross-border data transfer controls, map every data flow that crosses a jurisdictional boundary. This includes training data sourced from other countries, model inference requests from users in different jurisdictions, and model outputs delivered across borders. Each cross-border flow needs an identified transfer mechanism and a documented transfer impact assessment. Most organizations map transfers for their general IT systems but miss the AI-specific flows, particularly when training data is pooled from multiple subsidiaries or when a centrally hosted model serves users globally.
Robustness
Security
High-risk AI systems face AI-specific security threats beyond traditional cybersecurity risks. Data poisoning, model inversion, adversarial examples, and model extraction attacks can compromise fundamental rights by manipulating system outputs without detection.
What to assess:
Verify that the AI system’s vulnerabilities are regularly assessed, including AI-specific attack vectors. Standard penetration testing and vulnerability scanning are necessary but not sufficient. You need assessments that test for adversarial robustness, data poisoning resilience, and model extraction resistance.
Confirm that mechanisms ensure the integrity and resilience of the AI system against cyberattacks. This includes both preventive controls (input validation, anomaly detection on incoming data, model integrity monitoring) and detective controls (output monitoring for anomalous patterns suggesting the model has been compromised).
Fallback and Safety
What to assess:
Verify that a fallback plan addresses adversarial attacks and other unexpected situations. The plan should define how to detect that the system is under attack or operating abnormally, who has authority to activate fallback procedures, what the fallback process is (human takeover, system shutdown, reversion to a previous model version), how affected individuals are notified, and how the system is restored to normal operation.
Accuracy and Reliability
What to assess:
Confirm that the required level of accuracy for the system’s intended use is regularly assessed and documented. Accuracy requirements should be specific to the use case and the affected population. A 95% accuracy rate may be acceptable for a recommendation system but catastrophically inadequate for a medical diagnostic system.
Verify that datasets are comprehensive and up to date. Stale data produces stale predictions that can systematically harm groups whose circumstances have changed.
Confirm that reliability and reproducibility are regularly evaluated. The system should produce consistent outputs for consistent inputs. If it doesn’t, the variability itself is a risk to fundamental rights because similarly situated individuals receive different outcomes for no defensible reason.
Original implementation tip: Define accuracy requirements in terms of impact on fundamental rights, not just statistical performance. For a high-risk system that determines access to essential services, specify maximum acceptable false negative rates per protected group. A system with 97% overall accuracy but a 15% false negative rate for a specific demographic group is violating fundamental rights even though its aggregate performance looks strong. Disaggregate every accuracy metric by protected characteristic. This is where most organizations fail. They measure and report aggregate performance because it looks better. Regulators and courts will look at disaggregated performance because that’s where discrimination hides.
For fallback plans, conduct a tabletop exercise simulating system failure or compromise. Walk through the fallback procedure step by step. Time how long it takes to detect the problem, activate fallback procedures, switch to manual processing, notify affected individuals, and restore normal operations. Document every gap. Most fallback plans exist on paper but have never been tested. The first time an organization activates its fallback plan should not be during an actual incident. Test it at least annually, and after every significant system change.
Human Autonomy
Human Agency
AI systems must augment human decision-making, not replace it in ways that eliminate meaningful human control.
What to assess:
Verify that the system allows meaningful human interaction and defines task allocation between the AI and the user. “Meaningful” means the human has sufficient information, time, and authority to exercise genuine judgment, not just rubber-stamp the AI output.
Confirm that procedures document the levels of human involvement and intervention points in the AI system. For each decision point, document what the AI system produces, what the human receives, what the human is expected to evaluate, and what actions the human can take.
Human Oversight
What to assess:
Verify that the AI system does not interfere with human decision-making autonomy. This means the system should present outputs as inputs to human judgment, not as final decisions that the human is pressured to accept.
Confirm that mechanisms prevent overconfidence or over-reliance on AI-generated results. This is automation bias, the tendency of humans to defer to automated outputs even when those outputs are wrong. Controls against automation bias include presenting confidence levels alongside outputs, requiring operators to document their independent assessment before seeing the AI output, and rotating operators to prevent habituation.
Verify that the system includes mechanisms to detect and correct erroneous outputs. This includes both automated error detection (output validation rules, anomaly detection on outputs) and human error detection (spot-checking procedures, appeal mechanisms for affected individuals).
Confirm that mechanisms are available to safely abort the AI system’s operation if necessary. The abort mechanism must be accessible to authorized operators, tested regularly, and functional under adverse conditions including system overload or partial failure.
Original implementation tip: Measure automation bias directly. For one month, track the rate at which operators override or modify AI system recommendations. If the override rate is below 2% across all operators, investigate whether this reflects genuinely accurate AI outputs or automation bias. Interview operators. Ask them to describe the last time they overrode the system and why. If they struggle to recall any instance, or if they describe the override process as difficult or discouraged by management, you have an automation bias problem regardless of what the procedures say.
Design the user interface to counteract automation bias. Present the AI recommendation after the operator has recorded their initial assessment, not before. Display confidence levels prominently. Include a mandatory “I independently assessed this case” confirmation that the operator must complete before accepting the AI output. Make the override process as simple as the acceptance process. If accepting the AI recommendation requires one click but overriding it requires three clicks and a written justification, you’ve built automation bias into your interface. These are design choices that directly affect fundamental rights, and they should be documented and assessed as part of your impact assessment.
For the safe abort mechanism, test it under load conditions that simulate a real emergency. Can the system be shut down cleanly when it’s processing 1,000 simultaneous requests? Does aborting the system leave partially processed cases in an indeterminate state? What happens to decisions that were in progress when the abort was triggered? Document the answers. If aborting the system causes more harm than letting it continue (for example, if abort leaves thousands of cases in an unresolved state with no manual fallback), your abort mechanism needs redesign.
Running the Assessment: Process Tips
Who Should Conduct the Assessment
The assessment team must include diverse expertise. A single function cannot adequately assess fundamental rights impacts across all eight principles.
Include legal counsel with expertise in fundamental rights and anti-discrimination law. Include the data protection officer. Include a technical representative who understands the model’s architecture and limitations. Include a representative of the business function that uses the AI system. Include, where possible, representatives of affected communities or independent subject matter experts who can identify impacts the internal team might miss.
Original implementation tip: Bring in someone who will disagree with the project team. Assessment teams composed entirely of people who built or championed the AI system produce assessments that systematically underestimate risk. They suffer from confirmation bias and sunk cost bias. An independent assessor, whether internal (from audit or a different business unit) or external, changes the dynamic. Their role is not to block the project but to stress-test the assumptions. I assign a “red team” member to every high-risk AI assessment whose explicit job is to find the worst plausible impact scenario and challenge the team to prove it can’t happen. This consistently surfaces risks the project team hadn’t considered.
Impact Rating Methodology
Rate each control objective on a consistent scale against two dimensions: the likelihood that the fundamental right will be negatively affected given current controls, and the severity of the impact on affected individuals if it occurs.
Combine these into an overall impact level for each control objective. Document the rationale for each rating explicitly. “Medium” without explanation is not an assessment. “Medium because the system affects credit access for approximately 50,000 individuals annually, current bias testing covers three of five relevant protected characteristics, and the remaining two have not been tested” is an assessment.
Original implementation tip: Calibrate your assessors before the assessment begins. Present three to five hypothetical scenarios with pre-determined ratings and discuss them as a group. This aligns expectations and reduces inter-rater variability. Without calibration, I’ve seen the same control objective rated “low” by one assessor and “high” by another based solely on different interpretations of the scale. Calibration takes 90 minutes and dramatically improves assessment consistency. Document the calibration scenarios and use the same ones for every assessment to maintain comparability across AI systems.
Remediation Planning
For every control objective rated medium or above, document specific remediation actions, not general improvements. Each remediation action needs an owner (named individual, not department), a deadline, a measurable success criterion, and a target impact level after remediation.
Review remediation progress monthly. Report unresolved high and critical findings to the AI governance body. Escalate overdue remediations to executive management.
Original implementation tip: Set a maximum time window for high-impact findings: 90 days to implement remediation, no exceptions without executive-level approval. For critical-impact findings, the AI system should not be deployed or should be suspended until remediation is complete. Without firm deadlines, remediation plans become perpetual work-in-progress items. I’ve audited organizations where high-impact findings from 18 months ago were still “in progress” because nobody enforced the deadline and nobody escalated. The remediation plan existed. The remediation didn’t. Deadlines with escalation make the difference between an assessment that changes outcomes and an assessment that documents problems.
Connecting the Assessment to Other Compliance Obligations
DPIA Integration
Your fundamental rights impact assessment and your GDPR data protection impact assessment should be coordinated. Conduct them in parallel, share findings between the two teams, and cross-reference both assessments in your documentation.
Where the DPIA identifies a high privacy risk that you address with a specific mitigation, reference that mitigation in the fundamental rights assessment’s privacy section rather than duplicating work.
EU AI Act Conformity Assessment
The fundamental rights impact assessment is a deployer obligation. The conformity assessment is a provider obligation. If you are both the provider and the deployer, you need both. If you are only the deployer, your fundamental rights impact assessment should reference the provider’s conformity assessment documentation and identify any gaps between what the provider assessed and how you actually use the system.
Risk Management System
Your fundamental rights impact assessment should feed into your overall AI risk management system required under EU AI Act Article 9. Findings from the impact assessment become entries in your risk register with assigned controls, monitoring metrics, and review cycles.
Original implementation tip: Create a single assessment coordination calendar for each high-risk AI system that schedules the fundamental rights impact assessment, the DPIA, the conformity assessment review, the risk management system update, and bias testing. Align the timing so that each assessment can inform the others. Conducting them independently at different times of year creates inconsistencies. I schedule all assessments for the same quarter, with the fundamental rights impact assessment first (because it has the broadest scope), followed by the DPIA (which focuses on privacy findings from the broader assessment), followed by the risk management update (which incorporates findings from both). This sequence takes six to eight weeks per system and produces a coherent, cross-referenced evidence package.
Documentation and Evidence Requirements
What to Retain
For each completed assessment, retain the full assessment report including all control objective ratings with documented rationale, the assessment methodology documentation including scale definitions and calibration records, evidence supporting each rating (system documentation, test results, policy references, interview notes), the remediation plan with owners, deadlines, and target ratings, evidence of remediation completion for closed items, records of any impact assessment updates triggered by material changes, and the composition and qualifications of the assessment team.
Retain assessment documentation for the duration of the AI system’s deployment plus the applicable statute of limitations for fundamental rights claims in each jurisdiction where the system operates.
Format for Regulatory Submission
The EU AI Act requires that the fundamental rights impact assessment be available to regulatory authorities. Format your documentation so it can be produced on request without significant preparation. This means the assessment report should be a standalone document that a regulator can read without needing access to your internal systems or additional context.
Original implementation tip: After completing each assessment, conduct a “regulatory readiness test.” Hand the assessment report to someone who was not involved in the assessment, ideally someone from your legal or audit team, and ask them to identify within one hour whether the report clearly identifies every fundamental right at risk, whether the impact ratings are justified with specific evidence, whether remediation actions are specific and measurable, and whether the report is understandable without additional verbal explanation. If the reviewer can’t answer these questions from the document alone, the report needs revision before you consider it complete. Regulators will review your assessment without the benefit of your team explaining what you meant. The document must stand on its own.
Key Regulatory and Framework References
EU AI Act:
Article 27 (Fundamental Rights Impact Assessment for High-Risk Systems)
Article 9 (Risk Management System)
Article 13 (Transparency)
Article 14 (Human Oversight)
Article 15 (Accuracy, Robustness, Cybersecurity)
EU Fundamental Rights:
Charter of Fundamental Rights of the European Union
European Convention on Human Rights
EU General Data Protection Regulation (Articles 22, 35)
Standards:
ISO/IEC 42001:2023 (AI Management Systems)
ISO/IEC 23894:2023 (AI Risk Management)
ISO/IEC TR 24027:2021 (Bias in AI Systems)
ISO/IEC TR 24368:2022 (AI Ethics)
IEEE 7010-2020 (Well-being Impact Assessment)
Guidance:
European Commission Assessment List for Trustworthy AI (ALTAI)
EU Agency for Fundamental Rights guidance on AI and fundamental rights
OECD AI Principles (2019, updated 2024)
A fundamental rights impact assessment that documents risks without changing outcomes is a liability, not a protection. It proves you knew about the risk and did nothing.
An assessment that identifies specific harms, rates them honestly, assigns remediation with deadlines, and tracks completion until the residual risk is within acceptable tolerance is what Article 27 demands and what affected individuals deserve.
The assessment is not a compliance exercise. It is the mechanism through which your organization demonstrates that deploying a high-risk AI system is compatible with the fundamental rights of the people it affects. Treat it accordingly.
About the Author
The frameworks, tools, and implementation guidance described in this article are part of the applied research and consulting work of Prof. Hernan Huwyler, MBA, CPA, CAIO. These materials are freely available for use, adaptation, and redistribution in your own AI governance, risk management, and compliance programs. If you find them valuable, the only ask is proper attribution. If you like the content, please like the article and share it.
Prof. Huwyler serves as AI GRC Consultancy Director, AI Risk Manager, and Quantitative Risk Lead, working with organizations across financial services, technology, healthcare, and public sector to build practical AI governance frameworks that survive contact with production systems and regulatory scrutiny. His work bridges the gap between academic AI risk theory and the operational controls that organizations actually need to deploy AI responsibly.
As a Speaker, Corporate Trainer, and Executive Advisor, he delivers programs on AI compliance, quantitative risk modeling, predictive risk automation, and AI audit readiness for executive leadership teams, boards, and technical practitioners. His teaching and advisory work spans IE Law School Executive Education and corporate engagements across Europe and internationally.
Based in the Copenhagen Metropolitan Area, Denmark, with professional presence in Zurich and Geneva, Switzerland, Madrid, Spain, and Berlin, Germany, Prof. Huwyler works across jurisdictions where AI regulation is most active and where organizations face the most complex compliance landscapes.
His code repositories, risk model templates, and Python-based tools for AI governance are publicly available at https://hwyler.github.io/hwyler/. His ongoing writing on Governance, Risk Management and Compliance appears on his blogger website at https://mydailyexecutive.blogspot.com/ (more than 500k views).
Connect with Prof. Huwyler on LinkedIn at linkedin.com/in/hernanwyler to follow his latest work on AI risk assessment frameworks, compliance automation, model validation practices, and the evolving regulatory landscape for artificial intelligence.
If you’re building an AI governance program, standing up an AI risk function, preparing for EU AI Act compliance, or looking for practical implementation guidance that goes beyond policy documents, reach out. The best conversations start with a shared problem and a willingness to solve it with rigor.
