The EU AI Act has been in force since August 2024, but only now is it becoming concrete for most companies: on August 2, 2026 – three weeks from now – the obligations for high-risk AI systems take effect, the most extensive stage of the phased rollout. Anyone who commissions, operates, or is currently having software with AI features developed should be able to answer three questions now: Which risk class? Which role do we play – provider or deployer? And what is documented?
A note on framing upfront: this article is not legal advice. It is the practical perspective of a development agency that builds AI features for B2B clients and therefore has to answer these classification questions in every project.
The risk classes – and where your software probably stands
The AI Act does not regulate "AI" as a technology, but intended purposes. Four classes determine your obligations:
| Risk class | Typical examples | Obligations | Relevance for B2B software |
|---|---|---|---|
| Prohibited | Social scoring, manipulative techniques | Banned since February 2025 | practically none |
| High-risk | Applicant screening, credit scoring, critical infrastructure, medical devices | Risk management, data quality, documentation, human oversight, CE conformity – from August 2, 2026 | only for Annex III use cases |
| Limited risk | Chatbots, AI assistants, generated content | Transparency and labeling obligations | covers most AI features on the web |
| Minimal risk | Spam filters, internal automation, code assistants | no new obligations (voluntary codes of conduct) | the majority of internal AI use |
The good news for most of our clients: a RAG search across your own product data, an internal document assistant, or AI-accelerated development itself is not a high-risk use case. The obligation that affects almost everyone is less spectacular – transparency: users must be able to recognize that they are interacting with AI, and AI-generated content must be identifiable as such.
The deployer blind spot: affected even if you only buy
The most common misconception in conversations with decision-makers: "We don't develop AI, so this doesn't affect us." The AI Act distinguishes between providers and deployers – and deployers have obligations of their own. Anyone using an AI system under their own authority must, depending on the class, ensure human oversight, control input data, report incidents, and – since February 2025 – be able to demonstrate that their staff have sufficient AI competence (Article 4, "AI literacy").
In concrete terms: the Copilot licenses in your development team, the chatbot widget from your SaaS vendor, and the internally cobbled-together GPT tool all belong in a system inventory – including purpose, risk classification, and approval status. Unapproved tool usage ("shadow AI") is thus no longer just a security issue, but a compliance issue.
The checklist for software buyers
- Create a system inventory: which AI systems and features are running in our organization – purchased, embedded, commissioned?
- Document the risk classification: check each system's intended purpose against Annex III; record the result in writing, even if it reads "minimal".
- Clarify roles: where are we a deployer, and where (for instance with heavily customized systems) possibly a provider?
- Implement transparency: label AI interaction and generated content across all user touchpoints.
- Demonstrate AI competence: document training – this obligation has applied since February 2025.
- Review contracts: for commissioned development, risk classification, training exclusions, and documentation obligations belong in the statement of work.
What this means for ongoing projects
For new projects, the classification is cheap – it costs one workshop module. Retrofitting is expensive: a system that is later classified as high-risk needs risk management, data quality evidence, and technical documentation retroactively. That is why the AI Act classification belongs at the start of a project, in the same phase as the data protection impact assessment and the hosting decision. With fines of up to 35 million euros or 7 percent of global revenue for the most serious violations, this is not a formality.
How we handle this
In our projects, the classification is part of discovery: intended purpose checked against Annex III, transparency obligations built into the UX requirements, tool approvals recorded in the project documentation. For existing systems, we offer the classification as part of our AI audit – details on our page on AI-assisted software development.
