The EU AI Act, in practice

How much of the EU AI Act is actually design work? Less than I expected. Most of it is risk management, documentation, conformity assessments and logs. When I worked through it for a high-risk matching feature, I expected far more interface obligations than I found.

The few that are there shape the product, though: what people have to be told, what they need to understand and what they must be able to override. If these come in late, you end up retrofitting them onto a system that is already in customers' hands.

Legal status as of 16 October 2026, including the Digital Omnibus. This is a designer's reading of the Act, not legal advice.

Risk, not technology

The AI Act is risk based. It looks at the risk a use case poses to the health, safety or fundamental rights of the people affected. The same model can be minimal risk in a writing assistant and high risk in a hiring tool.

• Prohibited: for example manipulating people or exploiting their vulnerabilities, social scoring, emotion recognition at work or in education, and real-time remote biometric identification in public spaces for law enforcement. From 2 December 2026, also AI that generates non-consensual intimate images or child sexual abuse material.
• High risk: the use cases in Annex III, such as employment, education, credit scoring and law enforcement, plus AI used as a safety component in products that are already regulated, like medical devices.
• Transparency risk: chatbots, generated content and deepfakes.
• Minimal risk: everything else.

Private companies are not exempt. The Act covers AI placed on the market or used in the EU, wherever the provider is based.

What applies to everyone

Telling people about AI (Article 50)

Since 2 August 2026, regardless of the risk level:

• Providers have to design systems so that people know they're interacting with an AI, unless it's obvious from the context. Think chat interfaces and voice assistants.
• Providers of systems that generate audio, images, video or text have to mark the output in a machine-readable way, unless the system only assists with standard editing. Systems on the market before 2 August 2026 have until 2 December 2026.
• Deployers have to visibly label deepfakes, and AI-generated text published to inform the public on matters of public interest, unless a person has reviewed the text and takes editorial responsibility for it.
• Deployers have to tell people exposed to emotion recognition or biometric categorisation.

Each duty covers only the systems it names, but it applies regardless of risk level, so a narrow single-purpose tool can be covered too. The Commission has published guidelines on Article 50, a voluntary Code of Practice on marking and labelling, and free EU labelling icons. None of them prescribe one technique, so where and how the disclosure shows up is still our decision. A label that disappears in a screenshot or an export does not do its job.

AI literacy (Article 4)

Companies that build or use AI have to take measures to support the AI literacy of their staff, taking into account people's knowledge and experience, the context the AI is used in and who it is used on.

The Digital Omnibus softened this in July 2026. There is no level anyone has to reach, and the Act doesn't ask for a certificate. A record of the trainings helps you show what you did, but the duty is taking the measures, not keeping the record. For high-risk systems, the people assigned to human oversight still need to be trained.

The onboarding we design is part of how users get there.

Are you high risk?

In HR, Annex III covers AI used to recruit or select people, and AI used to make decisions about promotion or termination, to allocate tasks based on behaviour or personal traits, or to monitor and evaluate performance.

Article 6(3) has a narrow exception: a listed system isn't high risk if it doesn't materially influence decisions, for example because it only performs a narrow procedural or preparatory task. Whether that applies depends on the specific use. You have to document the assessment and still register the system. And a system that profiles people is always high risk.

My reading: adding human review to a high-risk system doesn't take it out of the category.

Providers, deployers and third-party AI

Providers build the system and carry most of the obligations. Deployers use it: they follow the instructions, assign trained people to human oversight, keep logs and inform the people affected. If you put your name on a third-party high-risk system or substantially modify it, you become the provider (Article 25).

An example of this would be my matching project. Buying the matching from a vendor doesn't buy compliance. If we ship it under our own name, we are the provider.

Some deployers also have to run a fundamental rights impact assessment before they put a high-risk system into use: public bodies, private companies providing public services, and companies using AI to assess creditworthiness or to price life and health insurance.

What high risk means for the interface

For high-risk systems, Articles 13 and 14 include obligations that need to be considered in the design process, from user flows to the actual interface. A few other articles add to them.

• Transparency (Article 13): deployers need to be able to interpret the output and use it appropriately. That means communicating accuracy, limitations, circumstances in which performance drops and how the system performs for different groups of people, in a way they can understand.
• Human oversight (Article 14): users need to understand what the system can and cannot do, notice when it is not working as expected, stay aware of automation bias, interpret the output, override or reverse it and stop the system. Deciding not to use the output at all is its own path and needs to be designed separately from correcting it.
• Accuracy and robustness (Article 15): engineering sets the numbers. How certainty is communicated, and what the interface shows when the system is unsure or failing, is design.
• Accessibility (Article 16): providers have to meet the EU accessibility requirements. I'd apply them to every surface, including oversight controls and logs.
• Informing people (Article 26): employers have to inform workers and their representatives before using high-risk AI at the workplace, and people affected by decisions the system makes or supports have to be told it was used. In recruiting, those are the candidates. Where and when they get that notice is a design problem.
• Explanation (Article 86): people significantly affected by a decision based on a high-risk system can ask the deployer for a clear explanation of the AI's role in it.

The rest (quality management, registration, logging, incident reporting) sits mostly with legal and engineering. Design still touches it: a log view a non-technical HR manager can actually read, a way to report incidents, and documented design and validation work as part of the quality management system (Article 17).

These obligations only apply to high-risk systems, but they also work well as guidelines for human-centred AI in general. Telling people what a system can do and how well, explaining its output and letting them correct or ignore it builds appropriate trust in any AI product. So even if your product is not high risk, they are worth designing for.

How I applied this to a matching feature

In a candidate-matching feature I worked on, this is how I translated the obligations into design decisions. These are my proposals; the feature hasn't been built or tested yet.

• The system does the finding, a recruiter does the deciding. This is a key point. The product insight says the system has to work without a user action. The Act says a person has to be in the loop before a decision. So while we can surface the talent, a recruiter still reviews the match and can correct or override it.
• Matches are explained per criterion, not as a single score. A number cannot be checked. A breakdown can: which criteria were met, which weren't, where in the profile each was found and how sure the system is. A recruiter can only correct what they can see and understand.
• Talents are told that AI is being used. Under Article 26 that's the deployer's duty, so our customers'. On top of that, I proposed an opt-out that triggers a manual review: a safeguard I chose, not a right the Act grants.
• Bias reduction is a hypothesis to test. A biased system would be a risk to talents, customers and us, so the design aims to reduce bias. Whether it does has to be measured, for example by comparing match results across demographic groups.
• False negatives are the hard half. False positives are easier: the recruiter reviews, sees the talent doesn't match and corrects the system. If a talent isn't surfaced, it won't be reviewed. We cannot rule that out completely, so the cutoff errs towards showing too much and nothing is auto-rejected. The tradeoff here is that recruiters review more weak matches, and we accept that. Whether this actually reduces missed talents, and does so equally across groups, still has to be tested.
• Recruiters can give feedback on matches and report if something went wrong.

Patterns that already answer the obligations

You do not need to invent new patterns. Each obligation that lands on design maps to patterns that already answer it. The first column paraphrases the legal requirement; the other two are my design response, not legal text, and need validating in each product. Codes are HAX guidelines and patterns unless noted.

The full story is in my matching case study.

Standards

Harmonised standards define how to comply in detail. They were delayed, which is one of the reasons the high-risk deadlines moved. The first one, EN 18286 on quality management, was approved in July 2026 and cited in the Official Journal on 14 October 2026. Following it now gives a presumption of conformity for the requirements it covers.

ISO/IEC 42001 is a useful framework for AI governance, but it is not a harmonised standard. Being certified does not mean your system complies with the AI Act.

Timeline

The high-risk dates moved with the Digital Omnibus (Regulation (EU) 2026/1744), which entered into force on 27 July 2026.

A practical checklist for designers

For everyone:

1. Design the AI disclosure: when people talk to AI, and how generated content is marked and labelled.
2. Check your use case against Annex III before assuming you are out of scope.
3. Use the high-risk interface obligations as guidelines, even if you are not high risk.

For high-risk products:

4. Clarify your role with legal: provider or deployer, and whether integrating third-party AI makes you a provider.
5. Design for interpretation: confidence, reasoning, limitations and known failure conditions.
6. Design oversight: dismiss, override, reverse and stop. Make them efficient enough that people actually use them.
7. Design failure states, feedback and incident reporting.
8. Design the notice and the explanation for the people affected.
9. Check accessibility on every surface, including oversight controls and logs.
10. Document design decisions and validation. They are part of the compliance record.