EU AI Act for an AI feature: what to check before release

The moment before release

The feature is almost ready. The demo works: a user enters a short product brief, the AI system generates page copy, and an editor can adjust the result before publishing. The team is already thinking about the release, then someone asks a simple question in standup: do we need to label this as AI-generated, and who is responsible if the system gets something wrong?

That is where the EU AI Act stops being an abstract headline. For a product team, it becomes a pre-release check: what are we shipping, who can use it, what risk tier does it fall into, what does the user see, and what evidence will we have if we need to explain the system later.

This article is not a replacement for legal advice. It is a practical way for a developer, DevOps engineer, or feature owner to prepare a useful technical package before speaking with legal, without panic and without hiding behind the phrase “we just connected a model.”

First, describe what the AI actually does

The weakest start to a compliance review is saying “there is some AI in the product.” That immediately hides the boundaries of responsibility. A better start is to describe the feature as a small user scenario.

For example: the user writes a brief, the system sends it to a model, receives generated text, displays the result in an editor, and the user can accept, change, or reject the output. If the feature generates images, write the same kind of flow: who enters the prompt, where the image is stored, whether it is published externally, and whether users can download it.

This description is not paperwork for its own sake. It tells the team whether there is an AI system, where synthetic content appears, whether the user directly interacts with AI, and what event logs must exist. Without this map, the team will argue about the regulation without understanding the feature.

A useful test: a new engineer should be able to read the description and explain within five minutes what the model creates, where a human can intervene, and what will be released.

Then decide the risk tier

The EU AI Act is built around a risk-based approach. Different AI systems do not have the same obligations. A system that helps write product copy and a system that affects access to a job, education, credit, or a critical service are not in the same category.

At a high level, there are four zones. Some practices are prohibited. Some systems are high-risk and need stronger controls. Some systems have limited risk, where the main concern is transparency for the user. Many everyday features may remain minimal risk, but that does not mean the team should leave no documentation behind.

For our SaaS text generation feature, the team should not try to make a heroic final legal conclusion alone. It should prepare a short note: what the feature does, why it appears to be or not to be high-risk, which users are affected, and whether the output could influence people’s rights or important decisions.

The common anti-pattern is simple: calling everything minimal risk because “it is only text.” Text can be a harmless draft, but it can also appear in a rejection message to a job candidate, a medical suggestion, or a financial decision. The risk comes from the context of use, not from how impressive the model looks.

Check transparency obligations

For many product teams, the most visible part of the EU AI Act is transparency obligations. A user should not accidentally believe they are talking to a human if they are actually interacting with AI. For some synthetic content, labeling or a technical way to recognize origin may also be required.

In our example, this becomes a set of engineering questions. Can the user see that the text was suggested by AI? Does the human keep final control before publication? Do we store the generation event in the event log? Can an exported result lose its label? Does support know how to respond to a complaint about an incorrect output?

The interface does not need to be frightening or overloaded with legal warnings. But the disclosure should be honest and stable. If the user clicks “Generate description” and receives editable text with a clear origin marker, that is better than hiding AI behind a vague word such as “improve” and leaving no trace.

Exports deserve special attention. Many teams label output in the web interface but forget the PDF, public page, API response, or integration with another service. That is often where transparency breaks.

Prepare the minimum release artifacts

A pre-release review should not become twenty documents that nobody reads. For a useful first level, a team can start with a small set of artifacts.

The first artifact is a short feature and data-flow description. The second is a risk tier note with open questions. The third is an inventory of models, APIs, and providers used by the feature. The fourth is test evidence: normal outputs, refusals, errors, and attempts to bypass limits. The fifth is an event log: at minimum, time, user or technical identifier, action type, model or configuration version, and result status.

The team also needs an incident path. Not a ten-page novel, just a practical answer: who receives a report, who can disable the feature, where the event logs are stored, how quickly the product team must collect facts, and when security, legal, or support should be involved.

A good test is this: if tomorrow a user says an AI-generated result harmed or misled them, can the team reconstruct what happened without digging through chat history?

Make it part of the release process

The best place for an EU AI Act review is not a heroic document created minutes before a deadline. It should be a normal release gate, next to security, privacy, accessibility, and observability checks.

For a small AI feature, the gate can stay short. Is the scenario described? Is the preliminary risk tier recorded? Were transparency obligations checked? Do event logs exist? Did the team test unwanted outputs? Is there an incident owner? Can the team disable the feature without rolling back the whole release?

If the answer to two or three questions is “we do not know,” that does not always mean the release must stop. It does mean the risk is unmanaged. The safer move may be to narrow the rollout, limit the audience, add human confirmation, or postpone part of the functionality.

Common mistakes

The first mistake is bringing up the EU AI Act only after the feature is already in production. Then every fix feels like emergency repair, and the team starts arguing with reality.

The second is thinking only about the model. Regulatory risk often lives in the product: who sees the result, what decision it supports, whether there is human control, and whether history can be checked.

The third is failing to label synthetic content when it leaves the editor. If content moves into a public channel, integration, or file, the marker should not disappear on the way.

The fourth is having no event logs. Without logs, the team may have good intentions but no facts.

Practical takeaway

For an engineering team, the EU AI Act is best treated as part of operational readiness, not as a legal storm cloud over the release. Start with a feature map, record the preliminary risk tier, check transparency, keep the minimum artifacts, and add a short gate before launch.

This will not make the product automatically compliant. It will make conversations with legal, security, and the business much more concrete. Most importantly, the team will know what it is shipping, how to explain it to users, and what to do when the system gets something wrong.

Sources

• Docker Blog: What Does EU AI Act Compliance Require? — https://www.docker.com/blog/eu-ai-act-compliance/
• Regulation (EU) 2024/1689 on artificial intelligence — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
• European Commission: Regulatory framework on AI — https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
• European Commission: AI Office — https://digital-strategy.ec.europa.eu/en/policies/ai-office