The EU AI Act for teams shipping ML features: a builder's orientation

If you are shipping an ML or AI feature into the EU and wondering whether the EU AI Act applies to your product, the short answer is: it almost certainly touches you, but most features land in the lighter tiers, and the main thing you owe today is transparency — telling people when they are interacting with AI and labelling AI-generated content. This is a builder's orientation, written by engineers who ship these features for clients. It is general information, not legal advice. For an actual classification of your product, get qualified counsel.

We are Amplified Creations, a digital studio in Leiria and Lisboa. We build recommender systems, web platforms and capture pipelines, and almost everything we ship now has an ML or AI component somewhere. So the question "does the AI Act apply to my product, and how risky is my feature?" is one we have to answer for our own roadmap. Here is how we think about it, in plain language.

Does the EU AI Act apply to my product?

The EU AI Act is the European Union's horizontal regulation for artificial intelligence. "Horizontal" means it is not industry-specific — it applies across sectors based on what an AI system does and how risky that use is, not whether you are in finance or fitness or furniture. It entered into force in 2024 and its obligations phase in over a multi-year timeline rather than landing all at once.

It reaches you if you place an AI system on the EU market or put it into service in the EU, or if the output of your system is used in the EU — even when your company sits elsewhere. The practical takeaway: if you have EU users, assume it is in scope and the only real question is which tier. It does not matter that you are a small team or that your model is a 200-line ranker. Size does not exempt you; risk classification does the work.

One useful definition up front. The Act distinguishes between roles. A provider develops an AI system and puts it on the market under its own name. A deployer uses an AI system under its own authority in a professional context. The obligations differ. Most of the time, when you build a feature for your own product, you are the provider; when you wire up someone else's model into a workflow, you may be a deployer, or both. This matters because the heavier duties fall mostly on providers of high-risk systems.

The four risk tiers, in plain language

The Act sorts AI systems into a small number of risk tiers. Getting your feature into the right bucket is the whole game, because the obligations scale with the tier.

Unacceptable risk — banned

A narrow set of practices is prohibited outright. Think social scoring by public authorities, certain kinds of manipulative or exploitative systems that cause harm, untargeted scraping of facial images to build recognition databases, and most real-time remote biometric identification in public spaces. If your feature is here, the answer is not "comply" — it is "do not ship it". For the overwhelming majority of product teams, nothing you are building lives in this tier. It is worth reading the list once so you can confidently rule it out.

High-risk — heaviest obligations

This is the tier that carries real engineering and documentation weight. High-risk systems are, broadly, AI used as a safety component of a regulated product, or AI used in specific sensitive domains: things like recruitment and worker management, access to education, access to essential private and public services and benefits, credit scoring, certain law-enforcement and migration uses, and some biometric and critical-infrastructure cases.

If your feature decides who gets hired, who gets a loan, or who gets into a school, assume you are in or near this tier and get advice early. High-risk does not mean banned — it means obligations: a risk-management system, data governance, technical documentation, logging, human oversight, accuracy and robustness, and a conformity process before you go to market. That is a real program of work, not a checkbox. The honest engineering reaction is that you want to know you are here before you build, not after.

Limited risk — transparency duties

This is where a lot of normal product AI lives. "Limited risk" is shorthand for systems that are not high-risk but interact with people in ways that could mislead them if undisclosed. The duty here is transparency, and it is concrete:

• If users interact with an AI system such as a chatbot, they should be told they are dealing with a machine, unless it is obvious from context.
• AI-generated or AI-manipulated content — synthetic images, audio, video, and generated text published to inform the public — should be labelled as artificially generated, in a machine-readable way where feasible.
• Deep fakes and similar synthetic media carry disclosure expectations.

The point of these duties is not paperwork; it is that people should not be deceived about whether a human or a machine is on the other side. If you build an LLM chatbot, this tier is your baseline even when nothing else applies.

Minimal risk — almost everything else

The vast majority of AI in production — spam filters, recommendation widgets, search ranking, inventory forecasting — sits in minimal risk, where the Act imposes no specific mandatory obligations beyond the rules that already apply to your software (GDPR, consumer law, and so on). Voluntary codes of conduct are encouraged, but you are not carrying a compliance program just for the AI part.

Why a small explainable ranker is lighter than an LLM chatbot

Here is the part that actually changes how we build. Two features can both be "AI" and land in very different tiers, and the design choice drives the difference.

Take our work on Jofit, a wellness app with a recommender that suggests sessions. It is a small, explainable ranker — not a large language model. It scores a bounded set of options against features we chose and can inspect, and we can say for any recommendation why it ranked the way it did. Because it is not used to decide hiring, credit, education or another high-risk domain, and because it is not a conversational agent pretending to be human, it typically sits in minimal or, at most, limited-risk territory. We do not need a deep-fake label on a workout suggestion.

Now contrast an LLM chatbot. The moment a feature talks to users in natural language as if it were a person, the limited-risk transparency duty attaches — you must disclose that it is AI. If that chatbot also generates content published to the public, labelling expectations stack on top. And general-purpose AI models that sit underneath have their own provider-side obligations around documentation and, for the most capable models, systemic-risk duties. None of this makes LLMs unshippable. It does mean an opaque conversational system pulls more obligations, by design, than a transparent ranker doing a narrow job.

This is not a legal conclusion about any specific product — your classification depends on your actual use, your domain, and facts we cannot see from here. It is the pattern we use to steer architecture early, then confirm with counsel.

What Amplified Creations actually does about this

We bias hard toward small, explainable, documentable ML over opaque LLMs whenever the job allows it, and the AI Act is one of several reasons. An explainable ranker like Jofit's is auditable: we can write down the features, the scoring logic, and the data sources, and reconstruct any decision. That same documentation that makes a model debuggable also makes it defensible if a regulator or client ever asks how it works.

Concretely, the documentation hygiene we keep helps regardless of which tier a feature lands in. For our ML work we maintain a plain description of what the system does and its intended purpose, where the training and input data come from, what the known limitations are, what human oversight exists in the loop, and a changelog of model versions. On the web side, our stack — PHP 8.3, Cockpit CMS, server-rendered pages with full JSON-LD and cookieless, privacy-first analytics — is built so we are not quietly collecting or inferring things we would then have to explain. When we do introduce a conversational or generative feature, we add the "you are talking to AI" disclosure and content labelling as part of the build, not as a retrofit. We do not claim to certify anyone's compliance; we are engineers, and we bring qualified legal counsel in for classification and conformity questions.

The short version

• Assume scope. If you have EU users, the AI Act likely applies; the real question is which tier.
• Four tiers: unacceptable (banned), high-risk (heavy obligations), limited-risk (transparency duties), minimal-risk (almost everything, few specific duties).
• Transparency is the common baseline: tell users when they are talking to AI, and label AI-generated content.
• Design drives tier. A small explainable ranker usually stays light; an LLM chatbot pulls transparency and, often, more.
• Documentation hygiene pays off either way. Write down purpose, data, limitations, oversight, and versions.
• Get counsel for classification. This is orientation, not legal advice.

FAQ

Does the EU AI Act apply to my product if my company is outside the EU?

Quite possibly yes. The Act can reach providers and deployers outside the EU when an AI system is placed on the EU market or its output is used in the EU. Being headquartered elsewhere does not by itself exempt you. Confirm your specific situation with qualified counsel.

Is a recommender system high-risk under the AI Act?

Usually not, on its own. A recommender used for content, products or sessions typically sits in minimal or limited-risk territory. It tends toward high-risk only when it is used to decide things in sensitive domains like employment, credit, or access to essential services. Your actual use determines the tier, so confirm classification with a lawyer.

What is the transparency obligation in practice?

Mainly two things: tell users when they are interacting with an AI system such as a chatbot, unless it is obvious, and label AI-generated or AI-manipulated content as artificially generated. The goal is that people are not deceived about whether a human or a machine produced what they are seeing.

Do I need a compliance program for a minimal-risk feature?

Not specifically for the AI Act. Minimal-risk systems carry no specific mandatory AI Act obligations beyond the laws that already apply to your software, such as data protection and consumer rules. Voluntary codes are encouraged but not required.

Why does Amplified Creations prefer explainable ML over LLMs?

Because small, explainable models are auditable and documentable, which keeps obligations lighter and decisions defensible. We can reconstruct why a recommendation happened, which helps with debugging, with clients, and with any regulatory question — without the heavier transparency and documentation load an opaque conversational system tends to attract.