EU AI Act: definition, risk classes and duties
Why the Term Matters
Anyone who builds or buys AI needs to know which class a system falls into, because effort and liability follow from it. A marketing chatbot has different requirements than a model that helps decide creditworthiness. For a fixed package from workshop to prototype this means an early clarification: which use case is planned, which class applies, which evidence will be needed. That avoids late surprises in operation.
When It Is Relevant
- You plan an AI system that affects people or prepares decisions.
- A prototype should move into real software and needs a solid classification.
- You buy in a third-party system and must check the provider duties.
- An audit or a tender requires proof of the classification.
When Not
When a pure internal experiment runs without real personal impact and never goes live, the formal classification is not in the foreground. Still, a short note on the intended class is worth it, so the jump from test to production system does not trigger duties by accident. The line is fluid and should be checked against the concrete project.
Industries That Use It
- Banks and insurers: systems for credit or claims scoring often fall into strict classes and need early clarification.
- Staffing providers: tools for pre-screening applications touch sensitive areas and require documented review.
- Medical technology: AI inside devices meets its own rules that interact with the AI Act.
- Public administration: applications touching citizens are under special scrutiny and need transparency.
Typical Use Cases
- Classifying a planned use case into a risk class before the build.
- Checking whether a bought-in model meets the provider duties.
- Building documentation that supports a later review.
- Deriving technical requirements such as logging and human oversight.
- Clarifying who is responsible for evidence in operation.
- Preparing for questions from tenders and customer audits.
Decision Guide
| Signal | EU AI Act is in focus | Alternative |
|---|---|---|
| System decides about people | check early as high-risk | design a process without AI automation |
| Pure internal tool, no personal impact | light class likely | an internal policy suffices for now |
| Buying a third-party model | secure provider duties by contract | in-house build with clear ownership |
| Tender requires proof | document the classification | bring in specialist legal advice |
Example
An insurer wants to build an assistant to pre-sort claims reports. In the workshop the team first clarifies whether and how the system influences decisions, before a prototype is built. Only after the classification and clean documentation does the team decide on implementation. This describes the method, not an asserted metric.
Service Connection
The usual entry is the AI workshop for classification, then AI implementation and AI consulting.
Sources
This framing is general orientation and not legal advice. The exact duties follow from the regulation text and accompanying guidelines and should be checked for every project against the currently applicable legal texts. Timelines and details can change.