The EU AI Act for Product Teams: A Practical Reading

The EU AI Act is the first broad law that regulates artificial intelligence by what it is used for rather than by how it is built. If you sell software with AI features to customers in the European Union, or your system's output is used there, it applies to you, including companies based in the UK, Switzerland or Qatar.

This is a practical reading for product managers and engineers. It is not legal advice, and the obligations are being phased in over several years with guidance still being published, so check the current timeline with your counsel. What we can offer is how the Act maps onto everyday product and engineering decisions.

The core idea: risk depends on use

The Act sorts AI systems into tiers based on the harm they could cause in a given context. The same underlying model can sit in different tiers depending on what you do with it.

• Prohibited practices. A short list of uses that are banned outright, such as certain forms of manipulative techniques, social scoring and some biometric uses.
• High-risk systems. AI used in sensitive areas listed in the Act, for example employment and recruiting decisions, access to education, credit scoring, certain medical devices and critical infrastructure. These carry the heaviest obligations.
• Transparency obligations. Systems that interact with people or generate content, such as chatbots and generated media, must make that clear to users.
• Minimal risk. Most AI features, such as spam filters, search ranking or writing aids, have no specific new obligations beyond existing law.

There are also separate rules for providers of general-purpose AI models. Most product companies use those models rather than train them, so their obligations come from how they deploy the model, not from the model itself.

Step one: map your AI features

Before anyone debates obligations, list every place AI is used in your product and internal tools. For each one, write down what it does, who it affects, what decision it influences and whether a human reviews the output. You will usually find that most features are minimal risk, one or two need transparency notices, and occasionally one touches a high-risk area.

Recruiting is a common example. A feature that ranks or filters job candidates is the kind of use the Act lists as high-risk. When we built AI scoring for asynchronous video interviews on Digital Arrow, a recruiting and HR platform, the design question was not just whether the model worked but how recruiters stay in control of the decision.

The same mapping exercise often reveals AI that nobody thought of as a feature: a vendor tool with built-in scoring, a support platform that drafts replies, an analytics add-on that predicts churn. Under the Act, deploying a third-party system still carries obligations for the deployer, so these belong on the list too.

What high-risk obligations look like in practice

If a feature does fall into the high-risk category, the obligations translate into engineering work you would recognise:

1. Risk management across the lifecycle, documented and revisited when the system changes.
2. Data governance: knowing where training and evaluation data came from, and checking it for relevance and bias.
3. Technical documentation describing the system, its purpose, its limits and how it was tested.
4. Logging so that outputs can be traced after the fact.
5. Human oversight designed into the workflow, so a person can understand, override or stop the system.
6. Accuracy, robustness and security measured and maintained, not assumed.

None of this is exotic. It is what a well-run AI project should have anyway. The difference is that it must now be written down and kept current.

Provider or deployer?

The Act distinguishes between providers, who develop an AI system or place it on the market under their own name, and deployers, who use one in their operations. A company that builds an AI feature into its own software product and sells it is usually acting as a provider for that feature. A company using a third-party AI tool internally is usually a deployer. The obligations differ, so work out which role you play for each entry on your list before deciding what applies.

If you substantially modify a third-party system, or put your name on it, your role can shift towards provider. That is worth knowing before you fine-tune or rebrand a vendor model.

Transparency is a design task

For the much larger group of features with transparency duties, the work is mostly in the interface. Users should know when they are talking to an AI system rather than a person, and generated content should be identifiable as such where the Act requires it. Good product teams were already doing this because it builds trust. Clear labels, an easy route to a human and honest descriptions of what the assistant can and cannot do are the practical answer.

Engineering habits that make compliance cheaper

• Keep an evaluation set for every AI feature and record results for each model or prompt change.
• Log prompts, retrieved context, model versions and outputs, with retention rules that respect GDPR.
• Version prompts and configuration like code, so you can say exactly what was running on a given date.
• Make human review a real step with its own interface, not a checkbox.
• Write a short model card for each feature: purpose, data, known limits, owner.

These habits overlap heavily with what we describe in LLM agents in production. Teams that already evaluate and log properly will find the Act adds paperwork rather than new engineering.

Where to start this quarter

• Complete the inventory of AI features and third-party AI tools.
• Classify each one by risk tier and by your role as provider or deployer.
• Add AI disclosure to every interface where users talk to or receive content from a model.
• Pick the highest-risk feature and bring its documentation, logging and oversight up to standard first.
• Assign an owner who tracks guidance as it is published and updates the inventory.

For companies selling into Germany or Switzerland, customers increasingly ask about AI Act readiness during procurement. Having the inventory and documentation ready shortens those conversations considerably.

Building AI for European users?

We design and build AI features with evaluation, logging and human oversight in from the start. Read about our custom AI development work, or contact us to review an AI feature you are planning.