The EU AI Act for product managers: compliance as a design principle, not a brake

Which risk class hits your product?

The AI Act thinks in purposes, not technologies. Prohibited are practices such as social scoring or manipulative systems. High risk covers systems that decide about people – creditworthiness, hiring, exam scoring, critical infrastructure. Limited risk mainly means transparency: chatbots must identify themselves, AI-generated content must be labelled. The rest – the large majority of typical SaaS features – is minimal risk.

The product-strategy consequence: the risk class is designable. Whether your feature “decides” or “suggests”, whether a human approves or automation acts – these are product decisions that directly determine which duties apply. A human-in-the-loop step can make the difference between the high-risk regime and a transparency duty. That is exactly why classification belongs in the define phase, not in legal after launch.

What applies now – and what the Digital Omnibus shifts

Since 2 February 2025 the prohibitions and the AI literacy duty apply; since 2 August 2025, the rules for general-purpose models. High-risk obligations were originally set for 2 August 2026 – but on 7 May 2026 the Council, Parliament and Commission provisionally agreed in the Digital Omnibus to shift them: Annex III systems now from 2 December 2027, systems embedded in products under Annex I from 2 August 2028. Formal adoption is expected in the coming weeks.

The fine logic remains sharp: up to 35 million euros or 7 per cent of global turnover for prohibited practices, up to 15 million or 3 per cent for high-risk violations. For DACH companies, though, the primary risk isn't the fine – it's the deal: enterprise customers now ask about AI Act conformity in procurement the way they ask for ISO certificates. No answer, no contract – long before any regulator shows up.

The five building blocks that belong in the product

Inventory. A living list of all AI functions with purpose, model, data sources and risk class. Without an inventory, every further duty is groping in fog.

Transparency. Users must be able to tell when AI is involved – in the interface, not the small print. That doubles as good expectation management and lowers support load.

Logging. Which model version answered when, with what context? Without that trail you can neither reconstruct errors nor answer an auditor.

Human oversight. Define per feature where a human can intervene and where one must approve. That is product design – and at the same time the most effective lever on the risk class.

Supply chain. Model providers, API services, hosting: settle contractually who carries which duties and which assurances you can pass on. In DACH, the question of EU hosting and data residency belongs in the same clause.

Recommendations

• Build the inventory this week. Record every AI function with purpose, model, data and risk class. It is the cheapest compliance measure with the biggest effect – and the basis for everything else.
• Design the risk class actively. Check in the define phase whether a human-in-the-loop step takes your feature out of the high-risk regime. Compliance architecture is product work.
• Use the omnibus time instead of burning it. The shifted high-risk deadlines are construction time for logging, documentation and supplier contracts – not an invitation to reopen the topic in 2027.
• Make conformity sellable. A one-page AI governance factsheet for procurement (risk classes, hosting, logging, oversight) wins more DACH deals than another feature.

Scope & caveats

• Status of the deadlines: provisional Digital Omnibus agreement of 7 May 2026; formal adoption was still pending at the time of writing. Details may still change in the legislative process – track the final publication in the Official Journal.
• This article is product-strategy guidance, not legal advice. Classifying specific systems – especially near the high-risk boundary – belongs in the hands of specialised lawyers.
• Switzerland is not directly bound by the AI Act, but effectively is: sell into the EU or serve EU users and you are in scope – and Swiss enterprise customers increasingly copy the requirements into their own procurement.

Matching use cases from the library

From the article straight into practice: these use cases put the concepts to work with Teklens.