Skip to Content
Home » Blog » AI » EU AI Act Part 4 – What This Looks Like in Your Sector
May 20, 2026

EU AI Act Part 4 – What This Looks Like in Your Sector

EU AI Act Part 4 – What This Looks Like in Your Sector

The first three posts in this series established the framework: the intended purpose doctrine, the Article 6 classification pathways, and the Article 6(3) filter mechanism. The framework is horizontal. It applies the same way regardless of industry. But how it applies in practice depends heavily on the specific systems, relationships, and regulatory contexts of each sector.

 

This post works through three sectors where the classification questions are live and nonobvious: employment and HR technology, financial services, and public sector deployment. In each case, the same underlying doctrines from Posts 1 through 3 produce different problems that practitioners need to anticipate.

Employment and HR Technology

The Annex III use cases for employment cover two categories: systems used for the recruitment or selection of natural persons (point 4(a)), and systems used to manage work-related relationships including task allocation, performance monitoring, and termination decisions (point 4(b)).

 

The documentation consistency problem is acute here. HR technology is a category where the gap between technical documentation and marketing language is frequently wide. Systems described in technical docs as “workforce analytics tools” or “engagement platforms” are routinely marketed with language about “identifying top performers,” “optimizing team composition,” or “understanding individual productivity.” Under the intended purpose doctrine, that marketing language is part of the classification evidence. Practitioners advising HR tech vendors should audit the full documentation package before concluding these systems are outside Annex III scope.

 

The multicomponent pipeline problem is also especially relevant here. A typical enterprise HR deployment chains multiple systems: an applicant tracking system, a resume parsing tool, a candidate scoring module, a scheduling tool, an onboarding platform, and performance monitoring tools. Each component, analyzed in isolation, might appear to fall outside the listed use cases or within a filter condition. But the Commission’s antifragmentation rule means the combined configuration, if its joint outputs materially influence employment decisions about individuals, is assessed as a single system. Practitioners need to map the pipeline, not just the components.

 

The “natural persons” scope question matters. The Annex III employment use cases specifically cover AI systems used to evaluate natural persons. A system that assesses companies or legal entities, without intending to evaluate the natural persons behind them, may fall outside scope. The guidelines confirm that when an owner of a legal entity is assessed for creditworthiness backing a company loan, the owner is not evaluated as a natural person for AI Act purposes because the primary beneficiary is the company. A similar analysis applies in employment contexts where systems evaluate organizational units rather than individuals.

Financial Services

Financial services presents three distinct classification questions, each with a different twist.

 

Credit scoring (Annex III, point 5(b)) covers AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score. The natural persons scope limitation applies here with a useful example the Commission provides directly: an AI system that assesses the creditworthiness of companies by evaluating their balance sheets and financial statements, without being intended to evaluate the personal finances of natural persons, falls outside point 5(b). The classification turns on what the documented intended purpose says about who is being evaluated and with what data.

 

A more complex question involves fine-tuned or embedded models. A general-purpose scoring model deployed by a lender specifically for consumer credit assessment has an intended purpose, as deployed, that squarely falls within point 5(b), even if the base model was originally documented with broader purposes. This is a classic Article 25(1) scenario: a deployer who configures a non-high risk base system for a high-risk use case may have become a provider of a high-risk AI system.

 

Life and health insurance pricing (Annex III, point 5(c)) covers AI systems used for risk assessment and pricing in life and health insurance. The Commission’s Annex III guidance contains detailed worked examples here, including the interplay with the Capital Requirements Regulation and Solvency II Directive, which is relevant for organizations that believe their existing sectoral compliance frameworks cover the territory.

 

The anti-money laundering carve-out is important for compliance technology vendors. Several Annex III use cases in law enforcement (point 6) could theoretically cover AI systems used to detect financial crime. But the guidelines provide a clear example: an accounting firm deploying an AI system to detect money laundering to comply with its own obligations under EU anti-money laundering legislation is acting on its own behalf, not on behalf of law enforcement authorities. That system falls outside the law enforcement Annex III scope. Vendors whose clients are regulated financial institutions deploying AI for AML compliance purposes should understand this carve-out and reflect it in their documentation.

Public Sector Deployment

Public sector AI deployment has two features that practitioners often underestimate.

 

The “on behalf of” extension. Several Annex III use cases apply specifically to use by public authorities “or on their behalf.” This extension covers private entities to which a public authority has delegated activities or requested support in specific cases. A private technology company deploying AI to process benefit applications under a contract with a government agency is acting on behalf of that agency and is within Annex III scope. Practitioners advising government technology vendors need to establish clearly whether their client is operating on its own behalf or on behalf of a public authority—the answer changes the classification.

 

The 2030 compliance deadline can create a false sense of distance. Under Article 111(2) of the AI Act, providers and deployers of high-risk AI systems intended to be used by public authorities must comply with the full set of high-risk obligations by 2 August 2030. This deadline is later than the general deadlines, December 2027 for Annex III systems and August 2028 for Annex I systems, but it does not mean classification work can be deferred. Building the compliance program, including risk management systems, technical documentation, conformity assessments, and human oversight mechanisms, takes years. The 2030 deadline is the finish line, not the starting point.

The Common Thread

Across all three sectors, the classification question ultimately comes back to the same point this series established in Post 1: what does your documentation say your system does, to whom, and in what context? The sector shapes which Annex III use cases are in play and which carve-outs are available, but it does not change the underlying mechanism. The paper trail is the classification.

Next in the series: Part 5 – Building the Paper Trail: What Your Records Actually Need to Contain

 

The Paper Trail series is based on the European Commission’s draft guidelines on the classification of high-risk AI systems under Article 6 of Regulation (EU) 2024/1689, published May 19, 2026, for stakeholder consultation. The guidelines are not yet final. Nothing in this series constitutes legal advice.