Designing with AI: UX, regulation and responsibility in the new generation of digital products.

Introduction: regulation has changed the brief.

For years, a UX designer’s brief came from three sources: the product (what we want to build), the user (what they need) and the business (what constraints apply). In 2026, with the EU AI Act activating in August, a fourth source of requirements has taken on its own weight and can no longer be delegated to the legal department: the regulator.

This isn’t a subtlety. It’s a shift in what it means to design products with AI.

Artificial intelligence has transformed the context we work in. We no longer design only static interfaces or deterministic flows. Today we design systems that generate variable responses, learn from user behaviour, and make decisions with real impact on people’s lives. In parallel, a demanding regulatory framework is consolidating: the EU AI Act, the California law on training-data transparency in force since January, the European Accessibility Act in force since June 2025, and growing case law on copyright in generated outputs.

This redefines the UX designer’s role. Designing usable experiences is no longer enough. Now we have to design experiences that are comprehensible, controllable, traceable and auditable — because the party who comes asking for accountability is no longer only the user; it’s also the regulator.

The thesis that anchors this article is simple: regulation has stopped being external context that we have to adapt to. It has become a design discipline in its own right. And treating it as such isn’t accepting a burden; it’s drawing on a source of requirements that, read well, improves the product for everyone.

The new paradigm: from deterministic interfaces to decision systems.

In traditional design, the system is predictable, rules are defined, and behaviour is stable. In AI-powered products, the system is probabilistic, responses can vary, and behaviour can become opaque even to those who built it.

This introduces a fundamental change: designing is no longer just defining what happens, but how and why it happens, and how it gets communicated to the user that what they see may be different from what someone else would see in the same context.

From deterministic flow to probabilistic flow.

Before, without AI:

Form → deterministic validation → fixed result

The user intuitively understands the contract: if I enter the same data, I get the same result. The experience is reproducible, explainable and auditable by construction.

Now, with AI:

User input → model interpretation → variable response

Here the contract breaks. The same input can produce different responses at different times. The model can have biases, hallucinations, or simply be updated without the user knowing.

This opens three design questions that didn’t exist before:

How do you explain variability without eroding trust? A user whom the system told “yes” yesterday and “no” today needs to understand whether that’s legitimate (different context, new data) or a fault (inconsistent model).
How do you handle non-deterministic errors? A hallucination isn’t a reproducible bug: it can appear once and never return. How do you design an error-reporting system when the error can’t be replicated?
How do you prevent blind trust? Generative models produce convincing output even when they’re wrong. Design has to inject healthy cognitive friction at moments where the user might delegate their judgement without meaning to.

The new discipline: designing uncertainty.

This is what sets UX for AI-powered products apart from everything that came before. We no longer design flows; we design bounded uncertainty fields. Showing the user, without overwhelming them, three things:

What is reasonably safe in the response.
What is reasonably uncertain.
What to do when the uncertainty matters too much.

On this foundation rest the three regulatory pillars the AI Act imposes, which the rest of this article develops as concrete design problems.

Regulation as a design discipline.

The EU AI Act doesn’t lay out an aesthetic checklist. It lays out three principles that are, to all effects, functional requirements of the product: transparency, risk classification, and traceability.

They’re not abstract principles. They’re design problems. And if you read them carefully, they’re also a legal validation of many things good UX has been asking for for years: that users understand what’s happening to them, that they can intervene, that they have someone to complain to. The difference is that now, failing to meet them carries penalties of up to 35 million euros or 7% of global turnover.

The three pillars are developed separately below, but the operational truth is that they get implemented together. No serious product can solve one without the other two.

1. Transparency: designing so the user knows what they’re interacting with.

Regulation requires that users know when they’re interacting with AI, especially in chatbots, assistants, content generators, recommenders, and any system that makes automated decisions with impact. This applies from August 2026 to all products operating in the European market, and non-European products that serve European users are included.

But “transparency” in well-done design isn’t a sentence in the footer. It’s a set of visual, semantic and timing decisions.

Transparency misunderstood.

Design that meets the requirement badly is easy to recognise:

The “this is an AI” indication appears once, at the start, in small text, and disappears for the rest of the session.
The avatar is human, the name is human, the tone imitates human conversation, and somewhere hidden it says “virtual assistant”.
Generated content has no visible marker and mixes with human-curated content without distinction.

This complies with the letter but violates the spirit. And in 2026, with the AI Act in force, “complying with the letter” will no longer be enough defence when a user or a regulator asks why the product induces confusion.

Transparency well understood: layers, not sentences.

Effective transparency operates in three simultaneous layers:

Layer 1: persistent identity. The user knows at all times what or who they’re interacting with. A chatbot doesn’t introduce itself at the start and then erase that signal; it keeps a visible indicator (icon, colour, label) throughout the session. If there’s a transition from AI to human, the user perceives it without ambiguity.

Layer 2: output marking. AI-generated content is visually distinguished from content curated by humans. It doesn’t have to be a huge banner; it can be a subtle icon, a differentiated background colour, a tooltip on hover. But it has to exist and be consistent across the product. This not only meets the regulatory labelling obligation; it also trains the user to read the product with the correct cognitive layer.

Layer 3: mechanism explanation. When the user needs it, they can access an explanation of how the system made the decision or generated the content. It doesn’t have to be a technical paper; it can be a sentence (“Based on your last 10 interactions and your location”) with an option to expand for those who want more detail.

Real UX decisions that appear when designing transparency.

Where to place it. The AI indication has to appear where the user looks, not where the team finds it convenient. Testing this with eye-tracking in real usability sessions is the difference between complying and confusing.

How much emphasis to give. Too much emphasis creates fatigue and the user ignores it. Too little, and it goes unnoticed. The balance depends on the system’s risk level (more on this in the next pillar).

How it affects trust. There’s a consistent finding in UX studies of AI products: users trust products that openly acknowledge their limits more than products that hide they use AI. Transparency doesn’t erode trust; it builds it. But only when it’s sincere, not when it’s a legal tack-on.

What happens when the user turns it off. If you give the option to hide the “AI-generated” label (which sometimes helps clean reading), how do you make sure the user remembers that what they’re reading was generated? One option: mark the session, not the element, with a periodic reminder.

Transparency isn’t text. It’s perception plus context plus time.

2. Risk: designing according to impact on the user.

The AI Act classifies systems into four levels: unacceptable risk (prohibited), high risk (strict obligations), limited risk (transparency obligations), and minimal risk (no specific obligations). But for day-to-day design work, this classification translates into something more operational: how much impact the system’s decision has on the user’s life, and therefore how much UX rigour is needed.

UX demand scale by risk level.

Case	Risk	Demand	Minimum patterns
Film or music recommendations	Minimal	Low	Visible AI label, “not interested” option.
Personalised feed, e-commerce	Limited	Medium	Persistent transparency, personalisation controls, option to view without personalisation.
Automated content moderation	Limited–high	Medium–high	Reason given, appeal path, clear response deadline.
Credit scoring, employment decisions, access to essential services	High	Maximum	Detailed explanation, mandatory human alternative, accessible support, documented traceability, explicit review right.

The table isn’t exhaustive, but it illustrates the principle: UX isn’t the same for every AI-powered product. A song recommender can be handled with a subtle label. A system deciding whether someone gets a loan has to be designed with an entire different architecture.

The mandatory patterns in high-risk systems.

When the system falls into the AI Act’s high-risk category, there are patterns that are no longer optional:

Meaningful human oversight. It’s not enough that “someone is in charge somewhere”. The regulation requires that the person has real capacity to understand the decision, enough time to review it, and authority to reverse it. From a UX standpoint, this is a double responsibility: designing an interface for the end user and an interface for the human supervisor, because if the supervisor can’t do their job, the product fails to comply.

Operational right to explanation. A user affected by an automated decision has the right to understand why it was made. “Why” doesn’t mean the code; it means the main factors in language the user understands. “Your application was denied primarily because the credit history of the last 12 months didn’t meet the minimum threshold.” This is microcopy, and it’s regulation.

Accessible human alternative. In high-impact decisions, the user must be able to request that the decision be reviewed by a person. This flow has to be as easy to find as the automated flow. Hiding it behind six clicks, a phone line no-one answers, or an intimidating form is, in practice, denying it.

Record-keeping and auditability. Every relevant decision leaves a trail. This is covered in detail in the third pillar, but worth flagging early: the system cannot forget what it decided about whom.

What this pillar demands of the designer.

Three things that weren’t in the role before:

Map the system’s real risk from discovery. Before designing screens, know whether this is a recommender or a high-risk classifier. It changes everything.
Design for the worst case, not the average case. What happens to the user the model classifies wrongly? If the honest answer is “they get stuck with no way out,” the product isn’t ready.
Defend the human supervisor’s time. Product teams tend to cut human-review time to cheapen operations. Designing supervisor UX with realistic workloads, not fantasy ones, is part of the job.

3. Traceability: designing so what happened can be audited.

This pillar is the most invisible in traditional UX and the most decisive in regulatory UX. Traceability means that the system can answer, to anyone with the right to ask, what it decided, when, based on what, and who could have changed it.

It sounds like a technical concern. It is. But it has deep design implications that are often ignored.

The system cannot forget.

In traditional products, deleting data often aligns with design: ephemeral sessions, clean histories, “we don’t store anything”. In impactful AI products this changes. Every relevant decision must be logged with its context: which model version produced it, which input data it had, which factors weighed, which human reviews it had.

This enters direct tension with GDPR’s data minimisation principle, which requires retaining only what’s necessary. And resolving that tension is, again, a design decision: what’s kept, for how long, with what permissions, and how the user is told that their decisions leave a trace that isn’t marketing, it’s audit.

Three levels of traceability for the designer.

Traceability for the user. The user affected by a decision has the right to see their own history: what’s been recommended to them, what’s been denied, why. The UX pattern here is an accessible, filterable, exportable history. Not buried under advanced settings.

Traceability for the internal supervisor. Product, support and compliance teams need to be able to reconstruct what happened when a user complains. The pattern here is an internal case-review tool, which the designer often doesn’t see but must design if they want their product to respond well when something goes wrong.

Traceability for the regulator. In an audit, the competent authority can request evidence of how the system works, how its decisions were documented, and how incidents were handled. This isn’t visible UX, but a designer who doesn’t think about this is building a product the organisation won’t be able to defend.

The most important pattern: the review path.

If there’s one UX pattern that defines whether an AI-powered product is defensible, it’s this: the user can request a decision be reviewed, and the system responds within a clear timeframe and with a clear reason.

Badly implemented, this pattern is a generic contact form that sends to a mailbox nobody reads. Well implemented, it includes:

Visible, direct access from the decision itself, not from a distant menu.
A form that lets you attach context (documents, screenshots, free narrative).
Immediate confirmation with a case number.
A committed, visible deadline.
A follow-up channel.
A resolution with an explicit reason, not just “accepted” or “rejected”.

An AI-powered product without a decent review path isn’t designed, it’s deployed.

Human in the loop: designing the intervention, not cutting it.

In all three pillars, a figure appears that isn’t the user: the human supervisor. The AI Act requires it for high-risk systems, but it’s good practice in practically any AI-powered product that makes impactful decisions.

Designing the human loop well has three requirements:

That it be meaningful. One person clicking “approve” without reading isn’t oversight, it’s theatre. Designing supervisor UX means showing them the relevant information in a form they can process in the time they have, not the time the product wishes they had.

That it be reversible. The supervisor’s decision isn’t immune. There has to be a clear process for a supervisor to review what another decided, and for the user to challenge that review.

That it be psychologically sustainable. Human supervisors of automated systems suffer from something known as automation fatigue: if the system gets it right 95% of the time, the person stops looking carefully and becomes a rubber stamp. Designing against this means random case sampling, rotation, specific alerts that force active review, metrics that don’t reward speed over correctness.

The human in the loop isn’t an infinite resource. It’s part of the system, and if it’s badly designed, it fails.

Designing for three audiences at once.

What makes UX for AI-powered products distinct from traditional UX isn’t only the probabilistic nature of the system. It’s that the designer now serves three simultaneous audiences, each with different needs that can conflict:

The user, who needs to understand, control and, if needed, dispute.
The organisation, which needs to operate, scale and demonstrate compliance.
The regulator, who needs to be able to audit and sanction if anything fails.

These three audiences can’t be satisfied with the same design. The user wants simple explanations; the regulator wants documented evidence; the organisation wants all of that to be produced without blocking the product.

The UX designer in 2026 is, increasingly, the person who finds the balance between these three demands without betraying any of them. It’s not legal’s job. It’s not plain product’s job. It’s design work, because it materialises in concrete screens, flows, copy and information architecture.

Implications for the profession.

This shift has practical consequences worth naming:

Regulatory literacy stops being optional. A UX designer who doesn’t understand the AI Act, the EAA and the CDSM Directive can’t defend an AI-powered product in 2026. You don’t need to be a lawyer, but you do need to be able to read a recital and translate it into component requirements.

Work with legal becomes continuous, not occasional. The “design first and then legal approves” model no longer works. The “design with legal from discovery” model does, because many regulatory decisions condition which architecture is viable.

New roles appear. Designers specialising in explainability, human-oversight designers, appeal-path designers. These aren’t minor niches; they’re areas where products are staking their regulatory survival.

The portfolio changes. What differentiates a senior designer of AI-powered products today isn’t the visual portfolio. It’s the demonstrable capacity to have designed transparency, oversight and appeal flows that withstand audit. That’s what companies operating in regulated markets are looking for.

Conclusion: regulation as ally.

The temptation, facing a demanding regulatory framework, is to read it as a burden: costs, limits, friction. Ten years of work on digital products make me read it the opposite way.

Regulation is codifying, with legal force and the threat of fines, things good designers have been asking for for years without success: that users understand what systems do, that they can intervene, that they have someone to complain to, that automated decisions are reviewable. For years, those requests crashed against “no time, no budget, not a priority”. In 2026, with penalties of up to 35 million euros or 7% of global turnover, they are a priority.

Designing with AI in 2026 isn’t just designing intelligent systems. It’s designing defensible systems: before the user, before the regulator, and ultimately before oneself. The question that defines whether a product is well made is no longer just “do users like it?”. It’s also: if tomorrow I’m asked to account for what this product decided, can I explain why it behaves this way, prove there is real oversight, and show the path the user has to dispute it?

If the answer is yes, you’re designing AI-powered products. If the answer is no, you’re deploying risks with an interface on top.

The real value of the designer in this context isn’t making AI look friendlier. It’s making the product comprehensible to the user, operable by the organisation and auditable by the regulator, all at once. That triple alignment is the new frontier of UX design, and it’s where the quality of digital products will be decided over the coming years.