EU AI Act: what it asks for and why it is good practice
If your AI application is heading from a proof of concept to production, build the capabilities the EU AI Act describes from the start.
If you own or build an application with AI, and it is heading from a proof of concept towards production with real users, build the capabilities the EU AI Act describes from the start. Put them into the scope of the whole project: the build, the rollout, and the later maintenance and continuity. Scale the effort to the risk: an internal summariser needs far less than a system that screens candidates.
I learned this on DealWizard, a minimal-risk product for the UK market, where the Act did not apply. I built these capabilities anyway, because AI applications are non-deterministic by nature: the same data can, rarely, produce a different recommendation. In my rough estimate this took about 15% of the project, and the output quality rose significantly through a continuous feedback loop.
This article shows what I built, what the Act asks of high-risk systems, and what is urgent now.
What I did in DealWizard
DealWizard turned a property listing into an investment report. I led its technology. It was a minimal-risk system, so the Act would have asked little of it. Each practice below was my choice, and each one matches something the Act asks of high-risk systems.
| Practice | What I did | What the Act asks of high-risk systems |
|---|---|---|
| Replay every result | Every report could be reproduced step by step: prompt, model version, input data, the data behind the analysis and outputs, kept in logs for 30 days. Running the same data again let me watch the AI give, rarely, a different recommendation. | Article 12 |
| Watch production | The main KPIs of every report were monitored and sent to the team, so we could see what happened in production. | Article 14 |
| Verify before the user sees it | A second agent checked every report for consistency before publication. When a report failed, it was regenerated and the team got a notification. I could look at the report and generate it again myself. | Article 14 |
| Let the user say no | A feedback button on every report. The user could ask the AI to generate again, and I could delete a result when needed. | Article 14 |
Article 14 says what human oversight must allow: understanding what the system can and cannot do, noticing automation bias (the habit of trusting the output too much), interpreting the output, overriding or reversing it, and stopping the system.
I did not do everything a high-risk system needs: no formal risk assessment, no technical documentation written to the Act and no registration of the system. DealWizard was minimal risk, so the Act asked for none of it. For a high-risk system all of it is required.
About one report in 20 contradicted itself on ROI: the summary used one calculation method and a later section showed a different figure. It is very hard to prepare a generation so that the first result is always satisfactory. The fix was one exact ROI method calculated once, updated model instructions and an AI evaluator that rereads each finished report, recalculates the ROI where needed and logs the case. After that practically no report failed, and consistent numbers were key to keeping users.
Verification costs money, so model choice mattered. A cheaper model checks faster than a stronger one, and faster than waiting for feedback from a human. At the start I checked outputs by hand, later only when a user reported a problem. Moving from Gemini Pro to Flash-Lite with a cached context cut time and cost about four to five times, with no drop in report quality.
Feedback was the best source of improvement. When a customer told us the generated quality fell short, we used it to improve the output. We loved feedback.
What I do on this website
The AI assistant on michalgorski.com follows the same pattern:
- It says it is an AI, that it can be wrong, and answers only from published information. When it cannot answer, it hands the visitor over to me (try it yourself). That is the idea of Article 50 in practice.
- Rules check each question before the model sees it and each answer before the visitor does. A daily spend limit stops the model when the budget is reached, and the assistant then only hands the visitor over to me.
- I run an evaluation set before changes. The assistant stayed off until I had reviewed the results.
- New knowledge proposed to it is not live until I accept it in an admin screen.
What to build in, from the proof of concept to production
A proof of concept has no compliance requirements. It is an internal toy proving a point. It should still keep each input next to the output it produced and give users a way to comment on that output, so their remarks can improve it.
Before real users arrive, put these into the scope of the project:
| Phase | What to put in scope |
|---|---|
| Build | Log inputs, model version, prompt or configuration and outputs. Verify output with a second agent before the user sees it, wherever the action is not irreversible. Give users a way to comment on a result and to ask for a new one. |
| Rollout | Check outputs by hand at the start, and later when a user reports a problem. Name an owner for the system and classify its use. Check Article 50 wherever the application generates content or talks to customers. |
| Maintenance | Monitor the main quality KPIs and send them to the team. Act on feedback in a continuous loop. Treat a new model, or a model update, as a small release: test it, record who approved it, and give the output and the stability hyper-care after the change. Track the cost. |
| Continuity | Keep logs long enough to replay a decision (30 days in DealWizard). Notify the team when verification fails. Keep the ability to regenerate or delete a result. Take AI literacy measures for the team. |
For business owners, three more things:
- List every AI-enabled application you own and name the owner of each.
- Classify each use. The use sets the tier: summarising meeting notes with a model brings no new duties, and screening CVs with the same model makes it a high-risk system.
- Ask vendors for documentation and logs in the contract.
What the EU AI Act is
Regulation (EU) 2024/1689 is the first comprehensive law on AI in the EU. It entered into force in 2024 and applies in stages. The rules depend on how AI is used and fall into four tiers:
| Tier | What it covers | Status |
|---|---|---|
| Prohibited | Practices such as social scoring and manipulation of people | Banned since February 2025. Article 5 |
| High risk | AI used in recruitment, education, credit scoring and biometrics, among eight areas | The most requirements. Applies from 2 December 2027 (products under Annex I: 2 August 2028). Annex III |
| Transparency | Chatbots and AI-generated content | People must know they deal with an AI, and generated content must be marked. Applies since 2 August 2026. Article 50 |
| Minimal risk | Everything else | No new duties |
For high-risk systems, Articles 10 to 14 cover data, technical documentation, record-keeping, information for deployers and human oversight. For everything else they are good practice.
Separate rules cover general-purpose AI models, such as large language models. They concern the companies that train and release those models. A company that only uses a model is outside them.
Does it apply to you?
The Act applies to you if you build, sell or use software that contains AI, in the EU or for EU customers. It does not matter where your company is registered. The Act names two roles. The provider builds an AI system and puts it on the market. The deployer uses it in a business. Each role has its own duties. To see where you stand, check your role and your tier:
Your role
- Do you build, resell or fine-tune an AI system or model? Then you are likely a provider.
- Do you use AI inside a business process? Then you are a deployer.
Your tier
- Does the system decide, or help decide, about people? Hiring, credit and education are in the high-risk tier.
- Does it talk to people or generate content? A chatbot on your website or generated images and text fall under the transparency duties.
An internal summarising tool is minimal risk. Even then, providers and deployers must take measures to support AI literacy among the people who use it.
What is urgent and what is not
The Digital Omnibus on AI, in force since 27 July 2026, moved the dates of the high-risk tier. The other tiers did not move:
- High risk, Annex III (recruitment, education, credit scoring, biometrics): from 2 August 2026 to 2 December 2027.
- High risk, embedded in regulated products (Annex I): to 2 August 2028. Annex I, Section A lists EU product-safety laws, for example on toys, machinery and medical devices.
- Transparency, Article 50: not delayed. Providers of generative AI systems already on the market have until 2 December 2026 to add machine-readable marking. This is the deadline closest to today.
- Prohibited, Article 5: applying since February 2025.
The requirements for high-risk systems are unchanged. The enforcement date moved. One duty was loosened: under the rewritten Article 4, providers and deployers must still take measures to support AI literacy, but no specific literacy level is required of anyone.
Fines under Article 99 reach EUR 35 million or 7% of worldwide annual turnover for prohibited practices, and EUR 15 million or 3% for most other obligations, including high-risk requirements and Article 50 transparency. The cap is the higher of the two amounts, and for start-ups and other SMEs the lower. National authorities set the actual fine.
Bottom line
Plan these capabilities into the budget of the project, about 15% of it in my rough estimate on DealWizard, and keep paying for them in operation and continuity. Models, data and feedback keep changing. With DealWizard nobody required me to follow the Act, and I followed much of it because it makes sense. The Act is a ready list of questions to ask about a system that cannot be fully predicted. Use it when your proof of concept starts moving towards production.
Sources
All pages accessed on 28 October 2026. The consolidated text on artificialintelligenceact.eu is a reading aid, not the Official Journal.
- Regulation (EU) 2024/1689 on EUR-Lex
- Consolidated text: Article 3, Article 4, Article 5, Article 10, Article 11, Article 12, Article 13, Article 14, Article 50, Article 99, Chapter III: high-risk systems, Chapter V: general-purpose AI models, Annex I and Annex III
- Digital Omnibus on AI (Regulation (EU) 2026/1744): artificialintelligenceact.eu, Orrick and Cuatrecasas
- DealWizard case study