Your legal team might think the EU AI Act is your main shield against liability. It's not. When your AI system faces discrimination claims, they'll bypass the Act's mechanisms and go straight to EU equality and non-discrimination law. These claims operate very differently from what you're preparing for.
The misconception persists because the EU AI Act dominates compliance discussions. Your team focuses on Technical Documentation (Annex IV), risk tiering, and conformity assessments. Meanwhile, your real legal exposure lies in older anti-discrimination laws that many AI governance teams haven't revisited since law school, if at all.
Myth 1: The EU AI Act's Enforcement Mechanisms Provide Your Primary Legal Protection
Reality: The EU AI Act offers limited remedies for AI-related harms and relies on other EU laws for redress. If your hiring algorithm disadvantages protected groups or your credit scoring system results in disparate outcomes, complainants won't wait for market surveillance authorities. They'll file discrimination claims under existing equality law, which prohibits discrimination based on gender and racial or ethnic origin in employment, social protection, education, and goods and services.
This is critical because the burden of proof, remedies, and enforcement timelines are entirely different. Your Technical Documentation shows AI Act compliance. It doesn't prove you didn't discriminate. You need separate evidence showing your system doesn't cause disparate treatment or impact across protected characteristics.
Myth 2: You Only Need to Worry About Direct Discrimination
Reality: Most algorithmic discrimination cases involve indirect discrimination, where seemingly neutral practices disadvantage people with protected characteristics. Your model doesn't need to use race or gender as inputs to produce discriminatory outcomes.
Consider a system using ZIP code, education level, and employment history to rank loan applications. None of these are protected characteristics. But if they systematically disadvantage applicants from neighborhoods with specific demographic profiles, you're facing an indirect discrimination claim. The complainant doesn't need to prove intent, just disparate impact.
Your model validation documentation should include disaggregated performance metrics across protected groups. When you can't collect certain demographic data directly, use proxy analysis or synthetic data techniques to estimate differential impact. Document these analyses before deployment, not after a complaint is filed.
Myth 3: The Burden of Proof Protects You From Frivolous Claims
Reality: Once a claimant establishes prima facie evidence of discrimination, the burden shifts to you to prove no discrimination occurred. AI opacity makes establishing prima facie evidence challenging, but not impossible. A claimant showing your system rejected their application while approving similar candidates from different demographic groups may be enough.
When the burden shifts, you must demonstrate that no discrimination took place. "The model made that decision" isn't a defense. You need documentation showing how the system reached its conclusion, what factors it weighted, and why those factors don't produce discriminatory outcomes. This requires explainability capabilities beyond what the EU AI Act mandates for Technical Documentation.
Build your validation evidence assuming you'll need to defend specific decisions in court. Log not just aggregate model performance, but decision-level audit trails that connect inputs to outputs with enough transparency to rebut discrimination claims.
Myth 4: Justifying Indirect Discrimination Is Straightforward
Reality: Even if you prove indirect discrimination occurred, you can still prevail if the measure pursued a legitimate aim, was necessary (no less intrusive but equally effective alternative existed), and was proportionate. But "business efficiency" and "cost reduction" rarely qualify as legitimate aims that justify discriminatory outcomes.
You need to document why your specific approach was necessary before deployment. If your credit model produces disparate impact, can you demonstrate that alternative model architectures or feature sets would either perform worse on legitimate risk assessment or produce similar disparate impact? Did you test those alternatives? This isn't post-hoc rationalization; it's prospective justification that belongs in your model development records.
The proportionality analysis requires balancing your legitimate interests against the discriminatory impact. A model that marginally improves fraud detection while significantly disadvantaging protected groups won't survive scrutiny. Your validation should include sensitivity analysis showing the performance-fairness tradeoff you evaluated.
Myth 5: Individual Complaints Are Your Only Exposure
Reality: Some Member States allow collective redress under non-discrimination law, known as actio popularis, where organizations can bring complaints in the public interest without an identifiable complainant. This means advocacy groups can challenge your system's design even if no individual has filed a complaint yet.
Collective actions change your risk calculus. A single complainant might accept a settlement. An advocacy organization wants precedent and systemic change. They'll demand algorithmic audits, design modifications, and ongoing monitoring commitments. Your exposure isn't one settlement; it's operational restrictions across your entire deployment.
Track which Member States where you operate allow actio popularis. In those jurisdictions, assume your high-risk AI systems will face organized scrutiny, not just individual complaints. Your validation evidence needs to withstand coordinated legal challenges, not just regulatory spot checks.
What to Do Instead
Stop treating EU AI Act compliance as your complete legal defense. Map every high-risk AI system to the protected characteristics it might affect and the Member State laws that apply. Your compliance documentation should address both regulatory requirements and discrimination defenses.
Build validation protocols that produce evidence useful in discrimination claims: disaggregated performance metrics, alternative model comparisons, necessity justifications, and proportionality analyses. These don't replace Technical Documentation; they supplement it with the evidence you'll need when someone files under equality law.
Establish monitoring that detects disparate impact before complainants do. Post-Market Monitoring under the EU AI Act tracks technical performance. Your discrimination monitoring tracks differential outcomes across protected groups over time. When you spot emerging disparities, you can investigate and remediate before they become legal claims.
Finally, recognize that Equality Bodies in some Member States have binding decision-making powers and present an alternative to court proceedings. Understand the enforcement landscape in each jurisdiction where you operate. Your response protocols need to account for both judicial and administrative challenges.
The EU AI Act sets the floor for AI governance. EU equality and non-discrimination law determines whether you'll face liability for what your systems actually do. Prepare for both.
