Risk Scoring and Eligibility Decisions: Where GDPR Meets the AI Act

Risk scoring and eligibility decision systems are now foundational to the operational logic of many public and private entities across Europe. From creditworthiness assessments and insurance premium calculations to social benefit eligibility checks and recruitment filtering, automated processing of personal data to derive risk profiles or eligibility outcomes touches nearly every sector. These systems promise efficiency and consistency, but they also create significant legal exposure when their design, deployment, or governance fails to align with European data protection and AI governance standards. The intersection of the General Data Protection Regulation (GDPR) and the new Artificial Intelligence Act (AI Act) forms the primary legal framework governing these systems. Understanding how these two regimes interact is not merely an academic exercise; it is a practical necessity for any organization deploying automated decision-making at scale. This article provides a detailed analysis of how to map common risk-scoring and eligibility decision systems to GDPR and AI Act obligations, focusing on transparency, lawful basis, risk management, and the documentation required to reduce legal exposure.

The Intersection of GDPR and the AI Act

The legal landscape for automated decision-making in Europe has historically been anchored in the GDPR, specifically Article 22, which grants individuals the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal effects or similarly significantly affects them. The AI Act, which entered into force in 2024, introduces a parallel and complementary layer of regulation for certain categories of AI systems, many of which are used for risk scoring and eligibility decisions. The two regimes operate on different but overlapping logics. GDPR is fundamentally a rights-based instrument focused on the protection of personal data and the autonomy of the data subject. The AI Act is a product safety and fundamental rights framework that regulates the design and governance of AI systems based on their risk level.

For risk-scoring and eligibility systems, this intersection means that an organization must satisfy the requirements of both regimes simultaneously. A system that is compliant with GDPR may still fall foul of the AI Act if it is classified as a high-risk AI system and fails to meet the stringent conformity assessment, risk management, and data governance requirements. Conversely, a system that meets the AI Act’s technical requirements for a high-risk system may still be unlawful under GDPR if there is no valid lawful basis for the processing or if the data subject’s rights are not adequately respected. The key is to view these frameworks not as separate checklists but as an integrated compliance architecture. The AI Act’s requirements for transparency, human oversight, and robustness can be seen as operationalizing some of the principles already embedded in GDPR, such as data minimization, accuracy, and accountability.

Defining the Systems: Risk Scoring and Eligibility Decisions

Before dissecting the legal obligations, it is crucial to define the systems in question. Risk scoring typically involves assigning a numerical score or category to an individual (or entity) based on a variety of data points, intended to predict a future outcome, such as the likelihood of defaulting on a loan, committing fraud, or making an insurance claim. The score itself may not be the final decision-maker but serves as a critical input for subsequent human or automated actions. Eligibility decisions are the output of a process that determines whether an individual qualifies for a product, service, or benefit. This can range from a simple binary “yes/no” for a credit card application to a complex determination of social welfare entitlement based on a combination of personal circumstances.

These two concepts often overlap. A risk score is frequently used to determine eligibility. For example, a low credit score (risk scoring) leads to ineligibility for a preferential mortgage rate (eligibility decision). The legal analysis must therefore consider the entire pipeline: the data collection, the model training and operation, the scoring mechanism, and the final decision-making act. It is this entire chain of processing that falls under the scrutiny of GDPR and the AI Act.

Scope of Application: When Do the Rules Apply?

GDPR applies to any processing of personal data of individuals in the EU, regardless of where the processing entity is located. This is a broad and extraterritorial scope. The AI Act, similarly, has a broad scope, applying to providers placing AI systems on the EU market, deployers using AI systems within the EU, and providers and deployers outside the EU if the AI system’s outputs are used in the EU. For a typical risk-scoring or eligibility system used by a European bank or public agency, both regimes apply directly.

The critical distinction arises with the AI Act’s risk-based classification. Not all AI systems are regulated equally. The AI Act categorizes AI systems into four tiers: unacceptable risk (prohibited), high-risk, limited risk (transparency obligations), and minimal risk (no specific obligations). Most risk-scoring and eligibility systems used in critical sectors will fall into the high-risk category, triggering a host of new obligations. It is essential for deployers to conduct a thorough classification exercise to determine where their systems lie on this spectrum.

Lawful Basis under GDPR: The Gateway to Processing

Under GDPR, any processing of personal data must be grounded in one of six lawful bases. For risk-scoring and eligibility decisions, which are often data-intensive and have significant impacts on individuals, the choice of lawful basis is a foundational decision with profound implications for data subject rights. The most common bases invoked for these purposes are consent and legitimate interest. Public bodies may also rely on public task or legal obligation.

Consent as a Lawful Basis

Using consent as the lawful basis for risk scoring is often fraught with difficulty. To be valid, consent must be freely given, specific, informed, and unambiguous. It must also be as easy to withdraw as it is to give. The power imbalance between a data subject and a financial institution or public authority makes it challenging to argue that consent was “freely given.” Regulators and courts have consistently held that consent is not a valid basis when there is a clear dependency for the provision of a service. If an individual cannot refuse consent without suffering a detriment, the consent is not considered freely given. For example, requiring a job applicant to consent to a profiling system as a condition of application is highly likely to be invalid. Therefore, while consent might be appropriate for low-stakes, optional services (e.g., a voluntary wellness app that provides a health risk score), it is rarely suitable for core eligibility or risk assessment functions.

Legitimate Interest: A Balancing Act

Legitimate interest is the most flexible lawful basis, but it requires a three-part test: (1) the organization must have a legitimate interest in the processing; (2) the processing must be necessary to achieve that interest; and (3) the individual’s interests, rights, and freedoms must not override that legitimate interest. This is the balancing test. For a bank, preventing fraud or assessing credit risk is a clear legitimate interest. However, the bank must demonstrate that its profiling activities are strictly necessary and that the impact on the individual is proportionate. This involves implementing safeguards, such as providing meaningful information about the logic involved, offering human intervention, and ensuring the data used is accurate and relevant. The use of special category data (e.g., health data for insurance risk scoring) is subject to even stricter conditions and generally cannot be processed on the basis of legitimate interest alone unless specific exceptions apply.

Public Task and Legal Obligation

For public sector entities, the lawful basis is often public task. This requires the processing to be necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller. For example, a social security agency assessing eligibility for benefits relies on this basis. The legal framework establishing the agency’s mission and powers provides the necessary grounding. Similarly, legal obligation may apply where a specific law requires a particular assessment or reporting, such as anti-money laundering checks.

Key Takeaway: The choice of lawful basis is not a matter of convenience. It dictates the scope of data subject rights, particularly the right to object (which is stronger when processing is based on legitimate interest) and the right to erasure. An incorrect choice can invalidate the entire processing operation from the outset.

Transparency and the Right to Explanation

Transparency is a cornerstone of both GDPR and the AI Act, but they approach it from different angles. GDPR’s transparency is centered on the data subject’s right to be informed about the processing of their personal data. The AI Act’s transparency obligations are focused on ensuring that deployers can understand and appropriately use the AI system, and that individuals interacting with it are aware they are doing so.

GDPR’s Information Requirements

Articles 13 and 14 of GDPR require controllers to provide data subjects with a concise, transparent, intelligible, and easily accessible description of the nature of the processing, the purposes, the lawful basis, and the envisaged consequences. For a risk-scoring system, this means the privacy notice cannot be a generic boilerplate. It must clearly state that automated decision-making, including profiling, is taking place, explain the logic involved (in non-technical terms), and outline the significance and envisaged consequences for the data subject. Simply stating “we may use your data to assess your eligibility” is insufficient. A better approach would be: “We use an automated system to analyze your transaction history and personal details to calculate a risk score, which determines your eligibility for our premium services. You have the right to object to this processing and to request human intervention.”

The “Right to an Explanation” under GDPR

While GDPR does not explicitly grant a “right to an explanation” of the algorithmic logic, Article 22(3) provides the data subject with the right to obtain human intervention on the part of the controller, to express their point of view, and to contest the decision. The European Court of Justice has clarified that this right implies a meaningful and sufficient explanation of the reasons justifying the decision. A controller cannot simply say “the computer said no.” They must be able to explain the key factors that led to the adverse outcome, even if they cannot reveal the proprietary details of the algorithm. This requires robust logging and interpretability features within the system.

AI Act Transparency Obligations

For high-risk AI systems, the AI Act imposes specific transparency duties on the deployer. When using a high-risk system to make decisions affecting individuals, the deployer must inform the individuals that they are being subject to the output of an AI system. This is a direct and explicit obligation. For example, if a company uses an AI system to screen CVs, candidates must be informed. This goes beyond the GDPR’s general privacy notice by mandating a specific notification about the use of AI. This requirement aims to prevent a “black box” scenario where individuals are unknowingly profiled by complex systems. It also supports the individual’s ability to exercise their rights under GDPR, as they are made explicitly aware that an AI-driven process is at play.

Explainability in Practice

From a practical standpoint, achieving meaningful transparency requires a multi-layered approach. At the highest level, the privacy notice and direct notifications must provide a clear overview. For individuals who contest a decision, the organization must have the technical and procedural capability to generate a post-hoc explanation. This may involve using interpretability techniques like SHAP or LIME to identify the features that most heavily influenced a specific outcome. The explanation provided to the data subject must be understandable, not just a list of feature importances. It should be framed in the context of the decision, for example: “Your application was declined primarily because of a high number of recent credit applications and a short credit history.” This level of detail is necessary to fulfill the spirit of GDPR’s right to human intervention and contestation.

Risk Management and Data Governance

The AI Act introduces a formalized risk management system (RMS) for high-risk AI systems, which must be a continuous, iterative process throughout the system’s lifecycle. This complements GDPR’s principles of data protection by design and by default, and its requirements for data accuracy and security. For deployers of risk-scoring systems, this means moving beyond a static compliance mindset to one of ongoing monitoring and mitigation.

The AI Act’s Risk Management System

An RMS for a high-risk system must include, at a minimum, procedures for identifying, analyzing, and mitigating risks. This involves several key activities:

• Risk Identification: Systematically identifying known and foreseeable risks associated with the system, including potential discrimination, inaccuracy, and misuse.
• Risk Analysis & Estimation: Assessing the severity and probability of each identified risk. For a credit scoring system, this could involve analyzing the risk of disparate impact on protected groups.
• Risk Mitigation: Developing and implementing measures to eliminate or reduce risks to an acceptable level. This could include technical solutions (e.g., fairness-aware algorithms, data augmentation) or procedural controls (e.g., mandatory human review for certain outcomes).
• Residual Risk Evaluation: After mitigation, evaluating whether the remaining risk is acceptable. If not, further mitigation is required.

This entire process must be documented and updated regularly, especially after significant system modifications or when new data or risks emerge.

Data Governance under the AI Act

A novel and critical requirement of the AI Act is its focus on data governance. For high-risk systems that process personal data, the data used for training, validation, and testing must be relevant, representative, free of errors, and complete. This is a direct response to the problem of biased AI. A risk-scoring model trained on historical data that reflects past discriminatory lending practices will perpetuate and amplify that bias. The AI Act requires deployers to proactively assess their datasets for representativeness and potential biases. This includes considering the “reasonably foreseeable” impact of the system on vulnerable groups, such as those with disabilities or from minority backgrounds. This obligation forces a deeper look into the data supply chain than GDPR’s accuracy principle alone might require.

Human Oversight

Both frameworks emphasize the importance of human judgment. GDPR’s right to human intervention is a data subject right. The AI Act makes human oversight a design and operational requirement for high-risk systems. The deployer must ensure that the system is designed to allow for human oversight, and that the individuals overseeing the system are competent, properly trained, and have the authority to intervene and override the system’s decisions. For a risk-scoring system, this means the user interface for a human operator must clearly present the system’s confidence level, the key factors in the decision, and provide a simple mechanism to halt or reverse an automated output. The oversight must be effective; a human who simply rubber-stamps the AI’s recommendation does not constitute meaningful oversight.

Documentation and Proving Compliance

Under both GDPR and the AI Act, the principle of accountability means that organizations must be able to demonstrate their compliance. This requires comprehensive and meticulous documentation. The burden of proof lies with the controller (GDPR) and the provider/deployer (AI Act).

GDPR Documentation Requirements

Key GDPR documentation includes:

• Records of Processing Activities (RoPA): A detailed log of all data processing, including purposes, data categories, recipients, and retention periods.
• Data Protection Impact Assessment (DPIA): Required for processing that is “likely to result in a high risk” to individuals’ rights and freedoms. Automated decision-making, profiling, and the use of new technologies are key triggers for a DPIA. The DPIA must assess the necessity and proportionality of the processing and identify mitigation measures.
• Data Processing Agreements (DPAs): Contracts with any third-party processor (e.g., a cloud provider or a vendor supplying the AI model) that mirror the GDPR obligations.

AI Act Documentation for High-Risk Systems

The AI Act significantly ups the ante on documentation for high-risk systems. Key requirements include:

• Risk Management System Documentation: Records of the entire risk management process, as described above.
• Data Governance and Management Strategy: Documentation detailing the data collection, labeling, cleaning, and analysis procedures, and the measures taken to ensure data quality and mitigate bias.
• Technical Documentation: Detailed information about the system’s design, architecture, algorithms, training methodologies, testing results, and performance metrics. This is intended for regulators and not the public.
• Instructions for Use: Clear and comprehensive instructions for the deployer, including information about the system’s capabilities, limitations, and the necessary human oversight measures.
• Automated Logs: The system must be designed to automatically log events (“logs”) throughout its lifecycle. These logs must be proportionate to the system’s intended purpose and its risk level. They are crucial for post-incident analysis and for demonstrating ongoing compliance.
• Conformity Assessment: Before placing a high-risk system on the market or putting it into service, a conformity assessment must be carried out. For many systems, this will involve the involvement of a third-party notified body.

The technical documentation is a particularly heavy lift. It requires a deep collaboration between legal, compliance, data science, and IT teams to produce a comprehensive record that can withstand regulatory scrutiny.

Practical Compliance Mapping: A Sectoral View

To make these obligations concrete, it is useful to consider how they apply in specific sectors.

Financial Services: Credit Scoring and Fraud Detection

A bank using an AI model for credit scoring must:

1. Establish Lawful Basis: Likely rely on legitimate interest, documenting the balancing test and the necessity of the automated process.
2. Conduct a DPIA: Assess the risks of discrimination and financial exclusion. Mitigation measures might include regular bias audits and a mandatory human review for borderline cases or rejections of applicants from protected groups.
3. Classify the AI System: The credit scoring model is a classic example of a high-risk AI system under the AI Act’s Annex III. It is used to make a critical decision about an individual’s economic situation.
4. Meet AI Act Obligations: The bank (as a deployer) must ensure the model provider has supplied