The conversation around the EU AI Act's high-risk classification often turns toward a purpose-built system: for example, a dedicated CV screener or a scoring algorithm from a specialized vendor. The assumption is that general-purpose tools like the widely popular ChatGPT or Copilot sit in a different category, one that carries lighter obligations or none at all.
That assumption deserves a second look. The AI Act's taxonomy is more nuanced and organizations using general-purpose AI for certain sensitive tasks may be operating a high-risk AI system without realizing it and may have acquired unexpected obligations.
General-Purpose Does Not Mean Low-Risk
The EU AI Act organizes AI systems into different tiers based on the risks they pose, ranging from lower-risk applications, such as spam filters or playlist recommendations, to high-risk ones, where the stakes for individuals are significant. High-risk AI systems are those the Act considers capable of causing serious harm to people's rights, safety, or livelihoods. The Act lists specific use cases that generally qualify. These include systems used in recruitment and hiring, employee performance monitoring, creditworthiness assessment or credit scoring, and education, among others.
General-purpose AI models, meaning the underlying technology that powers tools like ChatGPT, have their own separate rules under the Act, specifically in Chapter V. Strictly speaking, the Act distinguishes between general-purpose AI models and general-purpose AI systems. A model is not an AI system on its own; it becomes part of an AI system when combined with other components, such as an interface or application layer.
While general-purpose AI models are regulated through the separate rules of Chapter V, nothing excludes general-purpose AI systems from being classified in any of the risk categories. General-purpose AI systems, which are based on general-purpose models, may be high-risk, or may serve as components of high-risk systems. Whether a general-purpose system enters high-risk territory does not depend only on its underlying technology. It also depends on its intended purpose, including the purpose for which a provider markets it or a downstream organization configures, integrates, or repurposes it in practice.
Intent and Practice
Under the AI Act, one of the central concepts is intended purpose: what the system is actually designed and marketed to do. The intended purpose is the answer to the question: what does the provider say this tool is for?
The high-risk classification follows the purpose, not the technology (notice how Annex III of the AI Act refers to “AI systems intended to…”). A general-purpose assistant that a provider explicitly promotes for recruitment screening or employee performance monitoring would carry a high-risk classification on that basis alone. By contrast, where a provider does not list any high-risk use among the tool's purposes, the better reading of the law is that the product does not automatically become high-risk simply because those uses are technically possible. Organizations should check what their tools' documentation actually says, since the answer can vary from one provider to another, and can change over time.
But intended purpose is only half the story. From a compliance standpoint, we should also check what a specific organization actually does with the tool. Consider a few practical examples:
- A company feeds job applications into a general-purpose chatbot and asks it to rank the candidates and identify the strongest fit.
- An HR manager uses the same tool to analyze employee performance data, flag low performers, and draft termination recommendations.
- A financial institution prompts a general-purpose AI to assess the creditworthiness of loan applicants.
When Things Get More Complex
This is where the compliance picture becomes more serious.
The AI Act distinguishes between two types of organizations in the AI supply chain. A deployer is a company or individual that uses an AI system in a professional context. A provider is the entity responsible for placing the AI system on the market or putting it into service and ensuring it meets the Act's requirements. Being a provider comes with heavier obligations, including ensuring that the system meets the Chapter III requirements, maintaining technical documentation, operating a quality management system, enabling required record-keeping, designing for effective human oversight, and completing the relevant conformity assessment.
However, according to the AI Act, if a company modifies the intended purpose of a non-high-risk AI system, including a general-purpose one, in such a way that it becomes high-risk, that company is no longer just a deployer. It can become the provider of that specific high-risk system, with the obligations that entails.
In practice, three scenarios are worth distinguishing:
- Scenario A: The company uses a vendor's dedicated HR tool. For example, a third-party vendor offers a recruitment or performance management system that is already designated as high-risk and built for that purpose. Here the company is a deployer, not a provider. Its obligations are lighter than the provider's, but still meaningful.
- Scenario B: The company builds or configures a specific workflow. The company creates an internal process where a general-purpose tool screens applications, scores candidates, or generates performance evaluations. In this scenario, the company may have repurposed the general-purpose assistant into a high-risk AI system. If the setup amounts to modifying the system's intended purpose so that it becomes high-risk under Article 6 AI Act, the company can be treated as the provider of that specific high-risk system and become subject to provider obligations.
- Scenario C: An employee makes a one-off prompt. An HR professional pastes a CV into a chat interface and asks the tool to assess the candidate. The Act does not draw a bright line here, and whether this constitutes a modification of intended purpose is legally unsettled and it is better to proceed with caution.
What to Do?
The line between using AI as a helpful assistant and operating a high-risk AI system can be thin, and it is drawn by the purpose for which the tool is marketed, configured, integrated, or actually used in practice.
Technical safeguards can help prevent general-purpose systems from being used for specific sensitive purposes, but the importance of AI literacy cannot be overstated: staff should understand the systems available to them, the risks they carry, and the rules of use, calibrated to their role and responsibilities.
Finally, please be aware that this article covers the core framework, but the analysis in practice is rarely straightforward. Whether a specific tool crosses into high-risk territory should be evaluated case by case in a way that a short blog post cannot fully do. If you are concerned that an AI system your organization uses may already be operating in high-risk territory, it is worth getting a professional opinion before the applicable obligations become enforceable. We are happy to help.
No comments