AI for Social-Benefits Eligibility: High-Risk Under Annex III Point 5(a)
Social benefits eligibility AI is high-risk under EU AI Act Annex III point 5(a). Public-authority deployers must run a FRIA. Deadline: 2 December 2027.
When a public authority uses an AI system to decide whether a person qualifies for housing benefit, disability support, or unemployment assistance, that system is high-risk under Regulation (EU) 2024/1689 — full stop. Annex III, point 5(a) draws the line explicitly: AI intended to be used by, or on behalf of, public authorities to evaluate eligibility for essential public assistance and services, or to grant, reduce, revoke, or reclaim those benefits, is high-risk. No threshold to cross, no judgment call for the deployer. Classification is automatic under Article 6.
The stakes make the classification predictable. A system that wrongly denies a housing allowance to a family or cuts a disability pension based on a scoring error affects subsistence income, healthcare access, and housing security — precisely the fundamental rights the EU AI Act is designed to protect. The well-documented welfare-fraud-detection scandals across Europe — where algorithmic risk scores systematically flagged low-income and immigrant households — sit at the centre of why point 5(a) exists.
Under the Digital Omnibus agreed in May 2026, the compliance deadline for stand-alone Annex III systems has moved from 2 August 2026 to 2 December 2027. That is the date by which both the provider of the eligibility system and the public authority deploying it must have their obligations in place. Two years of runway sounds generous; the documentation and assessment work required makes it tight.
What Annex III Point 5(a) Covers — and What It Does Not
The high-risk trigger is the combination of two elements: a public authority actor and an eligibility-affecting function. A system that evaluates whether a person qualifies for unemployment compensation, means-tested welfare, housing allowances, disability pensions, child maintenance, healthcare subsidies, or similar essential benefits falls squarely inside point 5(a). So does a system that recommends reducing, suspending, or reclaiming benefits already in payment.
What falls outside: a chatbot that explains how to apply for housing benefit, a document-classification tool that sorts uploaded evidence without evaluating entitlement, a calculation tool that applies a fixed statutory formula with no prediction or scoring component. These do not evaluate eligibility in the sense the Act means; they may be minimal-risk or, if customer-facing and generative, limited-risk under Article 50.
The Article 6(3) filter — which allows a provider to self-assess that an Annex III system poses no significant risk of harm and therefore need not be treated as high-risk — rarely applies here. Systems that profile natural persons are always high-risk regardless of the exemption. A benefits-eligibility model inherently profiles applicants against criteria. Providers who attempt the 6(3) route must document the assessment and register it, but national regulators and the European Data Protection Board have signalled that systems affecting access to essential services carry inherent risk characteristics that make the exemption difficult to sustain.
The Obligation Stack for Providers
The provider of a social-benefits eligibility system — the organisation that develops it, places it on the market, or puts it into service under its own name — carries the heaviest obligations under Articles 9 through 15, reinforced by Articles 16, 43, 47, 48, and 49, and Articles 72 and 73 for post-market monitoring and incident reporting.
Risk management system (Article 9). Providers must establish and maintain a documented risk management system across the system's full lifecycle. For benefits eligibility AI, this means identifying where the system produces errors — false positives that trigger wrongful denials, false negatives that enable fraud, or both — and quantifying how those errors distribute across demographic groups. Stratified error analysis by age, gender, disability status, nationality, and household composition is not optional; it is the mechanism for demonstrating that bias does not systematically disadvantage protected groups. Residual risks must be documented and reviewed after each material update.
Data and data governance (Article 10). Training, validation, and testing data must be representative of the population the system will assess. A benefits-eligibility model trained on data from one municipality or region may perform poorly for a different demographic mix. Data provenance, collection methodology, and any known limitations must be documented. Where sensitive categories of personal data (health status, disability classification, ethnic origin) are processed under GDPR Article 9, that processing needs a legal basis and adequate safeguards layered on top of Article 10 compliance.
Technical documentation (Article 11, Annex IV). The Annex IV documentation pack covers nine categories: general system description; system architecture and training-data specifications; monitoring and control procedures; performance metrics stratified by demographic group; risk management records; lifecycle change log; harmonised standards applied; the EU Declaration of Conformity; and the post-market monitoring plan. This documentation must be retained for ten years (Article 18) and produced to competent authorities on request.
Human oversight by design (Article 14). The system must be designed so that a caseworker can understand its output, assess its reliability in context, and override it without technical obstruction. Where the system generates a recommendation, the person taking the final decision must have the competence and authority to disregard it. Article 14 requires that the system include appropriate human-machine interface tools to make this effective — not a tick-box override button, but a workflow in which human review is substantively possible.
Accuracy, robustness, and cybersecurity (Article 15). Benefits systems hold sensitive personal data for large volumes of people. Article 15 requires adequate protection against adversarial inputs, data poisoning, and manipulation. Accuracy metrics must be reported in the technical documentation with enough granularity that a regulator can assess whether the system is fit for purpose across its intended user population.
Conformity assessment (Article 43). Before placing the system on the market or putting it into service, the provider must complete a conformity assessment. For most Annex III categories — including point 5(a) — this follows the Annex VI internal self-assessment route, not mandatory notified-body involvement. The provider checks its own documentation against the Article 9–15 requirements, records the findings, and issues the EU Declaration of Conformity under Article 47 before affixing the CE marking under Article 48.
Registration (Article 49). Providers must register the system in the EU database for high-risk AI systems before market placement. Public-authority deployers must also register, and certain fields in that registration — including information relevant to non-public oversight — are not visible to the general public but are accessible to competent authorities.
Post-market monitoring and incident reporting (Articles 72 and 73). Providers must collect and analyse data on system performance in the field through a post-market monitoring plan. Where a serious incident occurs — a malfunction that contributes to a significant harm, such as a systematic wave of wrongful denials — the provider must report it to the relevant market-surveillance authority. Article 73 sets timelines: 15 days from awareness in most cases; 2 days for widespread infringement or serious disruption; 10 days where a person has died.
The Deployer's Obligations — Public Authorities Under Article 26 and Article 27
A public authority that deploys a benefits-eligibility AI system it did not develop is a deployer under Article 26. Deployer obligations are lighter than provider obligations but are not trivial, and for public-sector deployers in this specific use case, Article 27 adds a mandatory step that most deployers in other sectors do not face.
Article 26 baseline. The deployer must use the system in accordance with the provider's instructions, ensure that relevant staff have the competence and training to oversee it, ensure input data is appropriate and sufficiently representative, monitor operation for anomalies, log activities for at least six months (Article 26), and report serious risks or incidents to the provider and, where required, to the competent authority.
Article 27 Fundamental Rights Impact Assessment (FRIA). Public authorities deploying high-risk AI must conduct a FRIA before deployment. This is not a data protection impact assessment — it is broader. The FRIA under Article 27 examines impacts on the range of fundamental rights at stake: the right to social security and protection against poverty (EU Charter Article 34); non-discrimination and equal treatment (Charter Article 21); the right to an effective remedy and access to a fair process (Charter Article 47); and the right to data protection (Charter Article 8). For benefits eligibility, the assessment must specifically address whether the system creates systemic barriers for particular groups — elderly persons with limited digital access, non-native language speakers, persons with complex household structures — and what overrides and appeals mechanisms exist.
The FRIA must be documented and registered. Article 27 also requires that the deployer involve relevant stakeholders, which for a public social-services context typically means consulting with civil-society organisations, disability advocacy groups, and unions that represent benefit recipients.
A practical point: the FRIA is not a one-time exercise. If the system changes materially, or if monitoring data reveals patterns not anticipated at deployment, the assessment needs to be updated.
A note on role shifts (Article 25). A public authority that customises a procured system to the point of substantially modifying its intended purpose, or places it on the market under its own name, becomes a provider — and inherits the full provider obligation stack. Municipalities and social-services agencies that build bespoke eligibility engines on top of commercial model APIs should take advice on whether Article 25 applies to them.
Real-World Context: Why This Use Case Has Political Weight
The EU AI Act's inclusion of social-benefits eligibility in Annex III point 5(a) was not accidental. The drafters had specific systems in mind. The Dutch SyRI (Systeem Risico Indicatie) affair — in which an algorithmic risk-scoring tool targeted low-income and immigrant households for welfare-fraud investigation and was struck down by a Dutch court in 2020 as a disproportionate violation of the right to private life — is the paradigm case. Similar systems were deployed in the UK, France, and several other member states, often with scant transparency and no meaningful right of appeal.
Point 5(a) operationalises the lesson: if a public authority uses an automated system to make or materially influence eligibility decisions affecting people's access to essential support, the public has a legitimate interest in knowing the system exists, how it works, how its errors are distributed, and what recourse exists. The FRIA, the registration requirement, and Article 14's human-oversight mandate collectively impose a transparency and accountability floor that those earlier systems never met.
For a deploying public authority, this also means the Article 27 assessment is not a compliance formality. It is a public document. Civil-society groups, journalists, and advocacy organisations can and will read it.
How Confir Helps
Confir's rule-based classification engine runs through the Annex III point-by-point scoping logic to confirm whether a given system meets the Article 6 + point 5(a) threshold. Because the engine is deterministic — the same intake produces the same finding, and every rule that fires is human-readable — the classification output is audit-defensible without ambiguity about how the result was reached.
For deploying public authorities, Confir runs the Article 27 FRIA as a structured workflow: guided intake across the seven impact areas, documentation of mitigation measures, and a structured output ready for registration. For providers, the AIRC, AITR, AITO, and AIGM assessment modules map directly to the Articles 9–15 obligation stack, generating the Annex IV technical documentation pack and the Article 47 Declaration of Conformity as structured outputs. The immutable audit log ensures the compliance record holds up under regulatory scrutiny.
Both providers and deployers can confirm their obligation set and begin assessment work in a single session. No consultants, no six-month implementation — self-serve from €600/year.
Compliance Timeline
The obligations under Articles 9–15, 26, 27, 43, 47, 48, and 49 apply to social-benefits eligibility AI from 2 December 2027 — the revised deadline under the Digital Omnibus political agreement of May 2026, which deferred the original 2 August 2026 date for stand-alone Annex III systems. The deadline for high-risk AI embedded in Annex I regulated products is 2 August 2028, but social-benefits eligibility systems are not product-safety components; the 2027 date applies.
Non-compliance after that date exposes providers and deployers to penalties under Article 99(4): up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. For organisations below a certain scale, Article 99(6) caps the fine at the lower of the percentage or the fixed amount — a proportionality protection, but not a reason to deprioritise compliance.
The documentation work for a benefits-eligibility system — data quality audits, stratified performance testing, FRIA, technical documentation pack, conformity assessment — typically takes months. Starting well before the deadline is not optional; it is the realistic pace of the task.
Frequently Asked Questions
Which specific benefit programmes does Annex III point 5(a) cover?
Point 5(a) applies to AI used to evaluate eligibility for "essential public assistance benefits and services, including healthcare services." The scope is broad: housing allowances, unemployment compensation, disability pensions, child maintenance and family benefits, means-tested welfare payments, social care services, and subsidised healthcare access all fall within it. The trigger is the combination of a public-authority actor and a function that determines whether a person qualifies for — or should have reduced, revoked, or reclaimed — one of these benefits. Private insurers running their own discretionary schemes are not caught by point 5(a), though they may face separate high-risk classification under point 5(c) if they use AI for health or life insurance risk assessment and pricing.
Does Article 27 apply to every deployer of benefits-eligibility AI, or only public bodies?
Article 27 applies specifically to deployers that are public bodies, or that operate on behalf of a public authority. A municipality running a housing-benefit assessment system owes the FRIA; a private outsourcing firm processing applications on behalf of that municipality also owes it. A private company running its own employee-benefit scheme, with no public-authority involvement, does not fall within Article 27's scope — though it still carries all Article 26 deployer obligations, including human oversight and the six-month log retention under Article 26.
What is the correct conformity assessment route for a social-benefits eligibility system?
For Annex III point 5(a) systems, the standard route is Annex VI internal self-assessment under Article 43. The provider conducts the conformity assessment itself, checks its documentation against the Articles 9–15 requirements, issues the EU Declaration of Conformity under Article 47, and affixes the CE marking under Article 48. Mandatory third-party notified-body assessment (Annex VII) is reserved primarily for Annex III point 1 biometric systems, not for the Annex III point 5 services cluster. Internal assessment does not mean informal assessment — the documentation burden is the same; the assessor is the provider rather than an external body.
How long must deployers retain the logs they keep under Article 26?
Article 26 requires deployers to keep the logs automatically generated by the high-risk AI system for at least six months, or longer where other EU or member-state law (such as GDPR or sector-specific administrative law) requires a longer retention period. The six-month minimum is a floor, not a ceiling. For social-services contexts, national administrative law often imposes longer retention obligations; the deployer should check which rule sets the longer period and apply that.
What penalties apply if a social-benefits eligibility AI system is non-compliant after 2 December 2027?
Non-compliance with the high-risk obligations — Articles 9–15 for providers, Article 26 for deployers — is subject to penalties under Article 99(4): up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. Article 99(6) provides that for companies below a certain scale, the fine is capped at the lower of the fixed amount or the percentage, which is meaningful protection for smaller operators. Supplying incorrect or misleading information to competent authorities during an investigation is a separate tier under Article 99(5): up to €7,500,000 or 1%.
Can a public authority use the Article 6(3) exemption to avoid the high-risk classification?
In theory, Article 6(3) permits any provider (including a public authority acting as provider under Article 25) to self-assess that the system poses no significant risk of harm and is therefore not high-risk. In practice, this exemption is extremely narrow for benefits-eligibility AI. The Act specifies that any system that profiles natural persons is always high-risk — and an eligibility model profiles applicants by definition. Even where a public authority believes the 6(3) route might apply, it must document the assessment rigorously and register it. The EDPB and national supervisory authorities have signalled scepticism about the exemption's application to systems affecting access to essential services.
What should a public authority do if it discovers its deployed system is producing systematically biased outcomes?
First, Article 26 requires the deployer to monitor operation and report serious risks or incidents to the provider immediately. If the bias pattern constitutes a serious incident — defined in Article 3(49) and reportable under the provider's Article 73 duty — the provider must notify the relevant market-surveillance authority within the applicable timelines (15 days for most incidents, 2 days for widespread infringement). The deployer should also consider suspending or restricting the system's use pending remediation. The FRIA produced under Article 27 should be updated to reflect the findings, and the registration in the EU database should be amended accordingly. Affected applicants who received adverse decisions during the period of biased operation may have remedies under national administrative law and GDPR Article 22 where automated decision-making affected them individually.
Related guides
- Article 6 high-risk classification criteria
- determine your AI system's risk level
- Article 9 risk management requirements
- enterprise compliance obligations
- AI risk assessment methodology
- Annex III high-risk use cases
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →