The EU AI Act's enforcement timeline has moved from "future deadline on a slide" to "active obligation" for a meaningful set of AI use cases in 2026. If your product touches EU users and uses AI for anything beyond the most trivial features, this is no longer a legal team's problem to worry about later — it directly shapes what engineering teams need to document and build now.
The risk tiers, in plain terms
The Act sorts AI use cases into risk tiers rather than regulating "AI" as one thing. Unacceptable-risk uses are banned outright — things like social scoring by public authorities or certain forms of manipulative or exploitative AI targeting vulnerable groups. High-risk uses are allowed but come with substantial obligations — think AI used in hiring decisions, credit scoring, biometric identification, or safety-critical infrastructure. Limited-risk uses mainly carry transparency obligations — telling users they are interacting with AI, or that content is AI-generated. Minimal-risk uses, which cover most everyday AI features like spam filtering or a recommendation widget, carry essentially no new obligations.
The engineering-relevant question for most product teams is simply: which tier does our feature fall into, and that answer is not always obvious at first glance. A resume-screening assistant is high-risk. A support chatbot suggesting help articles is probably limited-risk. An AI feature that scores loan applications is high-risk regardless of how small a part of the overall decision it plays.
What high-risk classification actually requires
If your feature lands in the high-risk tier, engineering teams need to produce and maintain:
- A risk assessment document describing what could go wrong, how likely it is, and what mitigations are in place — this needs to be a living document updated as the system changes, not a one-time PDF.
- Data governance documentation covering what data trains or informs the system, how it was sourced, and what steps were taken to check for bias in the training or evaluation data.
- Human oversight mechanisms — a documented, actually-functioning way for a human to review, override, or halt the AI's decisions, not a theoretical checkbox. Regulators are specifically looking for oversight that is genuinely usable, not decorative.
- Logging and traceability — the system needs to log its decisions and the inputs behind them in a way that supports later audit, which has real implications for what your logging infrastructure needs to capture and retain.
- Accuracy and robustness testing records — documented evidence that the system was tested for performance across different subgroups and conditions, not just an aggregate accuracy number.
Practical compliance checklist for engineering teams
- Classify every AI feature in your product against the four risk tiers, and document the reasoning, not just the conclusion.
- For anything limited-risk or above, add a clear AI-disclosure notice to the user-facing interface — this is a genuinely easy win to get done early.
- For high-risk features, build the human oversight path first, before optimizing model quality — a system without a working override mechanism is not compliant no matter how accurate it is.
- Instrument logging for AI decisions now, even if you have not finalized your full compliance documentation — retrofitting logging after the fact is far more painful than building it in from day one.
- Keep a paper trail of your data sourcing and bias testing as you go, rather than trying to reconstruct it after a regulator asks.
The penalties are real enough to plan around
Fines under the Act scale with severity and company size, and for the most serious violations — prohibited uses, in particular — the penalties are structured to be meaningful even for large companies, not a rounding-error cost of doing business. That is enough reason on its own for engineering leadership to treat this as a genuine architectural constraint, not a compliance afterthought to bolt on before an EU launch.
Why this is a staffing and process problem, not just a legal one
Meeting these obligations well requires engineers who build documentation and oversight mechanisms into the development process itself, rather than treating compliance as a separate task handed off after the fact. This is exactly the kind of disciplined, documentation-aware engineering practice we build into how our dedicated teams work. If your product needs AI features built with EU compliance in mind from the start, contact AllDomainSoft to talk through your specific use case and risk tier.
