How should transparency disclosures be tested with users?

What should a disclosure test check?

A disclosure test should check three things: noticing, understanding, and action. Noticing means the user sees the disclosure in the flow, without having to search for it. Understanding means the user grasps that they are interacting with an AI system, or that content was artificially generated or manipulated, and what that means for the interaction or the content. Action means the user knows what to do next, whether that is to continue, to seek human help, to treat content with caution, or to follow an escalation route. A test that checks only whether the disclosure is present on the page, without checking whether users notice or understand it, does not evidence that the disclosure works. Each of the three checks should be recorded separately, with the evidence for each.

Who should be included in testing?

Testing should include representative users of the actual system or publication, not only internal staff who already know the system is AI. It should include people with different levels of familiarity with AI, different languages, different devices, and different accessibility needs, including people who use screen readers, voice control, or other assistive technology. It should also include people who might reasonably expect a human in that context, because those are the people for whom disclosure matters most. A test sample that includes only frequent, tech-savvy users will overstate how well the disclosure works for the wider audience. The sample, the recruitment method, and the limitations of the sample should be recorded, so that the test result is understood within its limits.

For the broader regulatory framework, see Transparency duties for AI.

How should testing be carried out?

Testing should be carried out in the actual context, using the real interface, channel, or publication format, with realistic tasks. For an interactive system, the test should follow a first interaction from start to finish, checking the disclosure at the point it appears. For published content, the test should follow the content as the audience will encounter it, including on mobile devices and after sharing. Testing methods can include moderated observation, unmoderated tasks with follow-up questions, and accessibility checks, chosen to fit the context. The test should be planned in advance, with tasks, questions, and success criteria set before the test, so that results are judged against a standard rather than fitted to the outcome. Findings should be recorded verbatim where possible, with the design changes made in response.

What should happen when testing finds a problem?

When testing finds that users do not notice or do not understand a disclosure, the design should be changed and retested, rather than the finding being noted and left. Changes can include moving the disclosure earlier in the flow, making it more prominent, simplifying the wording, changing the channel, or adding a reminder. Each change should be recorded with the finding it addresses and the retest result, so that the file shows an iterative improvement process. A disclosure that fails testing and is left unchanged, with a note that users should have noticed it, does not meet the purpose of Article 50. The provider or deployer should also consider whether the problem is specific to a group, a device, or a language, and should fix the problem for that group rather than averaging the result across all users.

When should testing be repeated?

Testing should be repeated when the disclosure design changes, when the interface or channel changes, when the audience or context changes, or when monitoring shows that users are misunderstanding the disclosure in operation. Monitoring can include complaints, support queries, user feedback, and analytics on interaction patterns, where those data are available and lawful to use. A periodic review should check whether the disclosure still works for the current audience and context, even where no design change has occurred, because user expectations and familiarity with AI change over time. The review cadence, the owner, and the trigger for out-of-cycle retesting should be recorded in the transparency file, so that testing is a planned activity rather than a one-time exercise before launch.

Continue with Article 50 interaction disclosure.

What does this guide not decide?

This guide does not decide whether a particular disclosure is clear, distinguishable, or effective, or whether a test sample or method is sufficient. It does not design a disclosure or assess a test report. Those questions depend on the disclosure, the context, the users tested, and the consolidated legal text. A provider or deployer should test with representative users, record the test and the design changes, and confirm the position with a competent authority or legal adviser where the disclosure is borderline or the audience is at particular risk of misunderstanding.

Frequently asked questions

Continue through this AI Act cluster

• Transparency duties for AI
• Article 50 interaction disclosure
• Accessibility of transparency notices
• Design and records for transparency notices
• Provider responsibilities
• How must synthetic content be marked and made detectable?