No headings found on page
var(--variable-rOO7maPRf)

Designing a system beyond AI labelling

The EU AI Act could have been met with a single banner. I reframed it as a product strategy problem and designed a contextual trust system that tells users what the AI made and how far to rely on it.

AI

Eugene Kim

⋅

23 min read

We could have met the EU AI Act with one banner: "This content was generated by AI." But that banner only answers "Is this page compliant?" It doesn't answer the question users actually have: "What did the AI make, and how far can I trust it?"

I work on improving AI experiences for AI-native research products at YouGov. This is the story of how a compliance checklist for AI labelling turned into a contextual trust system that behaves differently depending on where, and how, AI shows up.

It started as a checklist

A deadline set by regulation

Yabble is an AI research platform. It summarises survey responses, groups them into themes, and lets researchers talk to simulated consumer personas. From August 2026, the EU AI Act's transparency duties applied in full: users had to know when they were interacting with AI, and AI-generated content had to be labelled.

An internal audit showed most products already passed. But one data exploration view and five Virtual Audiences (simulated persona) pages had no AI notice at all, and persona images weren't marked as AI either.

So the fastest fix was proposed: pin a banner to the top of every page saying "AI-generated content. Use with caution." One component, one string, one sprint.

Something didn't sit right

The banner would pass the audit. But what would it actually tell users? When I walked through how researchers really work, I kept finding moments the banner couldn't answer.

The moments a banner can't answer

  • Mixed screens: real survey data sits right next to themes the AI grouped. A page banner can't say which part is which.

  • Leaving the platform: export an AI summary into a report and the on-screen label disappears. Whoever reads that report never knows the AI wrote it.

  • People who look real: a simulated persona's answer can read like a real respondent's voice.

  • Outputs people have edited: if a researcher refines and approves an AI-generated codeframe, is it still an AI output?

  • Warnings that become wallpaper: when every screen shows the same warning, people stop seeing it.

Changing the question

The banner was solving the company's question: "Did this page meet the rules?" The user's question was different: "Which of this did the AI make, and how much can I rely on it?"

How might we make AI involvement legible at the level of each output, in proportion to its consequence, and still true after it leaves the platform, without slowing research down?

The regulation was the floor. The real problem for the product was trust.

Why this is a product strategy problem

  • AI is the product. At Yabble, AI isn't an add-on; it's the core value. If users don't trust AI outputs, they don't use them. If they trust them too much, wrong conclusions end up in client decks. Labelling is how we calibrate that trust.

  • Five products, two companies. Yabble's five products and our parent company YouGov's products had to follow the same rules. Label each product separately and they'd quickly start speaking different languages.

  • Regulation keeps moving. Hard-code wording into every screen and every change in interpretation means touching every screen again. We needed one set of strings, approved once by Legal, used by every product.

So I reframed the work. Not "Where do we put the label?" but "How do we build a system where every AI output explains itself?"

Hypotheses, not certainty

Before building anything, I wrote the system down as hypotheses we could test against the banner. These five carry the story:

  • H1. Label the output, not the page. A chip that names what the AI did ("AI summary") will help users identify AI content more accurately than a page banner.

  • H2. Caution where it counts. Showing the caution only at export, share and decision moments will raise recall and reduce fatigue.

  • H3. Show how it was made. A "How was this made?" view with sources and confidence will lead users to check low-confidence outputs, rather than everything or nothing.

  • H4. Make simulated people unmistakable. A distinct treatment for personas will mean no one mistakes them for real respondents.

  • H5. Labels that follow the work. Labels that change state when people edit and approve will build ownership without feeling deceptive.


Designing labels that read the context

1. Three cues

An icon, a colour and a text label, used alone or together.

  • Icon: a standalone star (✦) for features that are AI by nature, and a small star badge on the corner of an existing icon when AI augments a feature that already existed.

  • Colour: a gradient reserved for AI and never used anywhere else, so it keeps its meaning.

  • Text: say what the AI did, not just "AI". For example, "Yabble AI Summary" or "Themes by Yabble AI".

Colour is never the only signal. Someone with colour vision deficiency, or a report printed in greyscale, still needs to tell AI content apart.

2. More cues as space and stakes grow

Put all three cues everywhere and they become wallpaper again. So the amount of signal depends on how much room a surface has and how much rides on the output:

  • AI entry points: standalone star and a gradient button.

  • AI output mixed with real data: star badge, gradient border and "Themes by Yabble AI".

  • Dense tables and numbers: a small star in the column header, with the detail in a tooltip.

  • Simulated personas: standalone star and "AI Persona", never removed.

  • Exported files: always in text, in footers, captions and CSV headers.

AI chat works the other way round. Everything on screen is AI, so instead of a star on every message, the chat is marked once at the top for the whole session. Then the cues mark the exceptions: real survey data, a simulated persona speaking, or a claim with no source behind it.

3. Detail that unfolds only as far as you need

Legal text can't all live on the screen, so disclosure comes in four layers:

  1. Cue (1 to 4 words): the icon, colour or name.

  2. Tooltip (2 to 3 sentences): what the AI did, what it drew on, and one limit.

  3. "How was this made?" panel: sources, sample, model, date and confidence.

  4. AI information page (long form): legal notices, data and privacy, known limits and an improvements log.

"Yabble AI grouped 412 responses into 8 themes. Smaller opinions can get missed, so check the quotes before you share."

Example tooltip

4. The system assigns the label, not the model

Which label an output gets is decided by the pipeline that produced it. The model never gets to call its own answer "verified". Designers don't have to judge it screen by screen, Legal can document the rules, and every product behaves the same way.

5. When people edit, the label changes

A designer I worked with at YouGov proposed a sharp rule: once a person has edited and approved an AI output, it's no longer freshly generated AI content. I adopted the rule, but scoped where it applies:

  • AI-generated: when an output is first created. Applies to every output.

  • AI draft, edited: when a person changes the content (typo fixes don't count). Applies to outputs people curate.

  • Reviewed: when a person signs off. Applies to codeframes and report summaries.

  • Always AI: no matter what is edited. Applies to AI chat, simulated personas and AI scores.

Even when the visible label gets lighter, the original generation record stays in the log, so a label never claims more human work than actually happened.

6. Habits every AI output keeps

  • Show the source: "Based on 412 responses · Wave 3", with numbered citations that link back to the originals.

  • Say when it doesn't know: if there's no evidence, show "No verified data" instead of leaving a blank.

  • Say that results can vary: next to Regenerate, tell people that running it again may give a different answer.

  • Ask for review before it leaves: a person checks it before it's applied or added to a report.

  • Take feedback, and show what changed: every output can be rated or reported, and improvements are logged on the AI information page.

The goal was never to hide the AI. It was to give users what they need to judge what the AI did.


How we'll know it works

Two rounds of validation

First, moderated usability tests check that people understand the cues. Then, after a staged rollout, live product analytics check that the same behaviour shows up in real use. These are proposed targets:

  • H1: at least 90% of participants correctly identify AI content.

  • H2: at least 80% recall the caution, with no more than 3 notices per session.

  • H3: low-confidence outputs get checked twice as often as high-confidence ones.

  • H4: zero participants mistake a persona for a real person.

  • H5: reviewers rate the labels at least 4 out of 5 for honesty.

We also set guardrails. Task time can't get more than 10% slower, and label-related support requests can't go up. Earning trust can't come at the cost of slowing research down.

Rolling out in phases

  1. Fix the gaps: add the star and a named label to the six unlabelled screens, and caption persona images.

  2. Build the system: shared components, tooltips, source grounding, feedback and the AI information page, plus the first round of usability tests.

  3. Extend it: edit-aware label states and content credentials, built together with YouGov.

The one-line banner lives on inside phase one. It didn't get thrown away; it became the first step of the system.

Looking back

Compliance work usually starts with "What's the minimum we have to do?" That question matters. But once I asked "What does the user need to know in this moment?", the same obligation became a chance to design trust into the product.

And it wasn't something I could build alone. Wording Legal could approve, metadata engineering could attach, and a rule from a designer at another company all had to fit together. My job as a designer was to weave those into one shared language.

This piece covers the work up to the framework and the validation plan. When the test results come in, I'll share what held up and what didn't.

Try this yourself

If you've picked up a design task that started from regulation or policy, these questions might help:

  • Is your solution answering the company's question, or the user's?

  • Is the same notice repeated on every screen? When does it really need to appear?

  • Does the meaning survive once the output leaves the screen?

  • Is a designer judging the rule screen by screen, or is the system deciding?

  • Can you turn your certainty into a hypothesis you can test?



No headings found on page
No headings found on page
var(--variable-rOO7maPRf)
var(--variable-rOO7maPRf)
var(--variable-rOO7maPRf)
var(--variable-rOO7maPRf)