AI Risk Classes: A Practical Guide for Your Software Company

Maxim Letski
Maxim Letski
03.08.2026

Key Takeaways

  • The AI Act's risk-based approach: The EU AI Act sorts AI systems into risk classes based on their use case: from prohibited systems, through high-risk and transparency-obligated systems, to systems with no specific obligations.
  • Extensive obligations at high risk: Systems that make consequential decisions about people, such as automated applicant screening, require substantial measures like risk management, technical documentation, and monitoring.
  • Light transparency duties for many SaaS products: Many AI features in SaaS products (e.g., chatbots) fall into this category, where clearly labeling the AI is enough to stay compliant.
  • Early compliance as a strategic advantage: An early risk analysis of your own AI use, transparent labeling, and a structured AI governance program make later audits easier, build trust with customers and partners, and reduce future costs and risks.

What do the AI Act's risk classes mean for my software company?

Do you run a software company that uses or builds AI? Then this post is for you. AI is in nearly every SaaS product today, from automation and personalization to support bots. The opportunities are huge, and so are the regulatory ground rules. To promote responsible AI, the EU AI Act is the first Europe-wide framework to classify AI by its risk. Each risk class comes with corresponding obligations for the AI's providers and deployers. As a software company, you need to understand where your product lands regulatorily before you use or sell it.  

How is my AI classified?

What matters is the use case you're building or deploying AI for. As a rule of thumb: The greater the impact on people, jobs, opportunities, or safety, the stricter the rules.  

The good news: Most SaaS use cases are permitted.  

The bad news: Misclassifying your AI invites operational and legal trouble.

Which AI uses are banned outright?

AI that massively interferes with people's rights and freedoms may not be deployed at all. Typical use cases include subliminal manipulation of users, exploiting particular vulnerabilities (e.g., children or people who are ill), biometric categorization of sensitive characteristics, and emotional surveillance of people. If your software company deploys an AI system that captures and analyzes a candidate's emotional reactions during a job interview, for example, that is a prohibited practice. The rule here: Hands off these use cases.

When is your product high-risk AI?

Even if your AI isn't banned, it may still be heavily regulated. That's the case when it's used in sensitive areas of life and has real consequences for people. Practical examples include an AI used by HR to automatically pre-screen applicants, or an AI that decides on access rights or safety functions. If your product lands in this risk class, substantial obligations follow: risk management, clean training data, technical documentation, and post-launch monitoring. In short: more governance, more process, more responsibility.  

What if my AI doesn't fall into these categories?

If your AI isn't prohibited, it may still be subject to transparency obligations. Most SaaS products with AI land in this category. Here, the concern is less about interference with fundamental rights and more about deception and identity risks caused by a lack of transparency. If a chatbot on your website answers support questions or sells products, for example, there's a transparency risk if users don't realize they're talking to a machine or viewing AI-generated content. AI systems with transparency risks therefore have to meet certain obligations, such as labeling the AI as such and marking its content. For software companies, especially scale-ups, this is easy to implement: a notice in the UI, clear labels, and clean communication, and you're compliant without bending the product out of shape.  

Is there AI with no extra obligations at all?

Your AI may also carry no specific risk. Typical examples are translation features, music and product recommendations, simple automations, and internal optimization algorithms. These carry no additional obligations under the AI Act and can be developed and used freely. Responsible use of AI is still expected, of course, and obligations under other laws on data protection or cybersecurity continue to apply.  

So what does this mean for my software company in practice?

Rather than getting nervous when the audit comes, take an early look at your AI: in particular, by listing every AI feature, determining its risk class, reviewing your UI and transparency, and setting up an AI governance program. Classifying early means problematic features can be adjusted while the AI product is still being designed. A clearly documented governance program ensures new features can be reviewed and approved on an ongoing basis, so your team can expand its AI quickly without compliance checks slowing things down every time. Transparent labeling and fair data practices show customers, partners, and investors that your software company uses AI ethically and responsibly, which strengthens mutual trust.

Bottom line: If you understand early on which risks your AI solution carries and take the necessary measures, you'll save a great deal of time, cost, and stress later, while building trust with customers, partners, and investors.  

Conclusion

The EU AI Act isn't meant to block innovation; it's meant to steer it. AI features without specific risks can be developed and tested flexibly, while high-risk and transparency-risk systems are operated in a controlled, safe way. What's decisive is classifying your AI correctly within the AI Act's risk classes. Early AI compliance is no obstacle. Quite the opposite: It can be a strategic advantage for your software company.