Who Wrote This Screen? Provenance That Works Beyond the Badge
Generative AI is no longer confined to experimental tools. It is appearing in customer service summaries, drafting assistants, analytics dashboards and case-management interfaces. For UK product teams, the design question is not whether to add an AI label. It is how to make the origin and status of content legible enough that people can make informed judgements. Provenance is becoming part of the interface, and therefore part of accessibility.
Provenance is an accessibility requirement
If a screen contains generated text, users need to know what kind of content they are dealing with. That requirement is especially acute for people using screen readers, magnification, speech input or plain-language support. A visual badge that says 'AI-generated' may be invisible to assistive technology, or it may be announced so often that it becomes noise. A confidence indicator that relies on colour alone excludes users who cannot perceive it. An edit history hidden behind a mouse-only hover state is not a history for everyone.
Provenance design therefore has to meet the same standards as any other accessible component. Labels need accessible names, states need text equivalents, and changes need to be announced at the right level of urgency. The aim is not to decorate every paragraph with metadata. It is to ensure that the information people need in order to trust, challenge or verify content is available in a form they can use.
Three questions users actually ask
Much of the current debate about AI transparency is framed around disclosure. In practice, users tend to ask three more specific questions. First: who or what produced this? Second: what has changed since it was produced? Third: how certain is the system, and why? Interface patterns should be organised around those questions rather than around a general disclaimer.
A source label at the point of consequence is often enough for the first question. 'Drafted by AI', 'Edited by a caseworker' or 'From your submitted record' is more useful than a generic banner at the top of the page. The second question calls for an edit history that shows meaningful changes, not a raw log. The third calls for confidence expressed in words and reasons: 'Low confidence: the address was not matched to a postcode' is more actionable than a percentage with no context.
Patterns that carry their weight
Several patterns are emerging as practical building blocks. Source chips can sit beside generated passages where the distinction matters, provided they are consistently worded and accessible. Confidence cues should combine text, visual treatment and an explanation, and should be reserved for decisions where uncertainty changes what the user should do. Edit history can be presented as a layered diff with a plain-language summary, and it should survive export or print if the service allows those actions.
Human-review checkpoints are the strongest provenance pattern for high-consequence flows. Before a payment, an eligibility decision or a formal response is issued, the interface should show whether a human has reviewed the content and what role that reviewer held. This is not a decorative assurance badge. It is a checkpoint in the service journey, with a named owner and an audit trail.
Avoiding disclaimer theatre
Provenance fails when it becomes theatre. A repeated footer that says 'This page may contain AI-generated content' trains users to ignore it. A modal warning on every visit creates fatigue and undermines accessibility. The better approach is tiered disclosure: lightweight labels for low-stakes content, clearer explanations where users may act on the information, and human-review checkpoints where outcomes are significant.
Consistency matters as much as placement. Teams should agree a small vocabulary and use it across products: generated, edited, reviewed, uncertain, verified. Icons should not carry meaning alone. Colour should not be the only signal. Labels should be written in UK English and tested with users who rely on assistive technology, including people with cognitive access needs who may find repeated metadata more disabling than helpful.
Governance behind the interface
An accessible provenance interface depends on an accountable back end. Teams need to record which model or service produced content, which version was used, what source data informed it and whether a human intervened. That record supports user-facing history, internal audit and incident review. In UK public services, data protection impact assessments and equality considerations should inform how provenance is designed, particularly where automated outputs influence access to services.
Procurement can reinforce this. Contracts for AI-enabled tools should require exportable provenance logs, accessible label components and clear human-review controls. Without those requirements, design teams are left to improvise transparency on top of systems that were never built to disclose their own workings.
Practical checks
A useful test is to ask whether a screen-reader user can identify generated content within a few seconds of encountering it. Can they understand why a confidence cue is low? Can they reach the edit history without a mouse? Can they tell whether a human has reviewed a decision? If the content is exported, does the provenance travel with it? These questions are more valuable than a general commitment to transparency.
Provenance is not a badge bolted onto an AI feature. It is an interface contract between the service, the user and the organisation accountable for the outcome. Designed well, it builds trust without clutter. Designed poorly, it becomes another layer of noise that disabled users are expected to navigate. The difference lies in treating provenance as part of the accessibility and product design process from the start.
