The EU AI Act in Practice: What Product Teams Actually Need to Do

Most teams are waiting for legal to tell them what to do

I've spoken to a dozen product and engineering leads in the past few months about the EU AI Act. Almost all of them said some version of the same thing: "We're waiting for our legal team to give us a framework." A few had hired an external consultant. One had a slide deck from a conference that nobody had read past page four.

That instinct — treat it as a compliance and legal problem — is understandable. Regulation sounds like law, law sounds like lawyers. But the EU AI Act is, at its core, a product engineering problem. The obligations it creates land squarely on the people building the system: the product managers defining what the system does, the engineers choosing the model and the data pipeline, the architects deciding how outputs get surfaced to users. Legal can tell you what the rules say. Only your team can actually implement them.

I've been working through this hands-on while building CVChatly, an AI-powered job search platform. We use LLM agents, we process CV data, and we interact with job seekers making real decisions about their careers. That puts us in a position where ignoring the Act was never an option. Here is what I've learned doing it, not reading about it.

Start with your risk classification, and be honest about it

The first thing the Act asks you to do is classify your system. Most teams rush this step and land on "limited risk" because it feels safer. Sometimes that's right. Often it isn't.

The high-risk categories are specific. Annex III lists them: AI used in employment and recruitment is explicitly there. That includes systems that sort CVs, rank candidates, or influence hiring decisions. If your product touches that pipeline, you are in high-risk territory regardless of how you describe yourself in your marketing copy.

CVChatly helps job seekers prepare their CVs and practice interviews. We help the candidate, not the recruiter. That matters for classification. But I still had to think carefully about whether any feature we were building could be construed as influencing a hiring decision, even indirectly. The honest answer shapes everything that comes after.

The practical exercise here is straightforward: for each AI-powered feature, write one sentence describing what decision it supports or influences, and who makes that decision. Then check that sentence against Annex III. Do this as a product team, not as a legal exercise. You know what your system actually does. Your lawyer probably doesn't.

What high-risk compliance actually requires you to build

If you land in high-risk, the Act requires a set of things that sound bureaucratic but are genuinely useful engineering practices when you implement them properly.

Risk management system. This is not a document. It is a process that runs throughout the system lifecycle. In practice, it means you maintain a living log of the risks your AI system can create — wrong outputs, biased outputs, outputs that users over-trust — and you have mitigations for each. We built this into our sprint cycle. Every time we ship a new agent capability, we add a row to the risk log. It takes fifteen minutes. It has already caught two things we would have shipped without thinking twice.

Data governance. Training data and fine-tuning data must be documented: where it came from, how it was processed, what biases it might carry. If you're using a third-party model through an API — which most teams are — you don't control the training data, but you do control the data you feed in at inference time. That's where your GDPR obligations and your AI Act obligations overlap. For CVChatly, every piece of CV data a user uploads is processed under a clear legal basis, stored with a defined retention period, and never used to train or fine-tune anything without explicit consent. That's not just compliance; it's what users deserve.

Technical documentation. Article 11 requires you to maintain documentation that describes the system's intended purpose, its performance, its limitations, and the measures taken to manage risk. Think of it as a living technical spec that you keep current. If you already write proper architecture decision records and maintain a product spec, you are halfway there. The gap is usually the limitations section — teams document what the system does well and skip over what it gets wrong.

Human oversight. This is the one that generates the most debate. The Act requires that high-risk systems be designed so that humans can effectively oversee, understand, and where necessary intervene or override the system. "Effectively" is the key word. A confirm button that nobody reads is not human oversight. We designed CVChatly's CV analysis feature so that every suggestion is presented as a suggestion, with a plain-language explanation of why it was made, and the user can accept, edit, or reject each one individually. That's not just good UX. It's the architecture of oversight.

Limited-risk systems still have real obligations

If your system is limited-risk — a chatbot, a content recommendation engine, a generative feature that produces text or images — the main obligation is transparency. Users must know they are interacting with an AI system. That sounds trivial. It isn't, once you think about it carefully in your specific product context.

What does "knowing" actually mean in your UI? Is a small disclaimer in the footer enough? Almost certainly not. We put an explicit label on every AI-generated output in CVChatly. Not because regulators told us to, but because users make better decisions when they know what they're looking at. They push back more, they edit more, they engage more critically. That makes the product better.

The transparency obligation also covers deepfakes and AI-generated media. If your product generates synthetic images, audio, or video, you must label it as such. This is one of the clearest and most enforceable provisions in the Act. Don't assume your current terms of service covers it. It probably doesn't.

The practical starting point for any product team

You don't need a full compliance programme to start. You need three things done well.

1. Classify every AI feature honestly. Write the one-sentence description of what decision it influences and check it against Annex III. Do this in a product meeting, not a legal review.
2. Start your technical documentation now. Open a document, describe the system's intended purpose, its known limitations, and the data it processes. Keep it updated as you ship. The habit matters more than the format.
3. Design oversight into the UX. Every AI output that a user acts on should be presented as something they can question, edit, or reject. If your current design doesn't allow for that, fix the design.

The EU AI Act will be enforced. The first cases will set the tone for what regulators consider acceptable. Product teams that have done the work — even imperfectly — will be in a fundamentally different position from those who treated it as a future problem. I'd rather be in the first group.

The fundamentals of building trustworthy software haven't changed. Document what you build, understand its risks, design for human control, and be honest with your users. The AI Act is asking you to do those things rigorously and verifiably. That's a reasonable ask.