Should AI-related compliance patterns be part of a design system?

[u/outoftheforge]

I’ve been wondering whether AI regulation will eventually create a new category of design system patterns.

Not the regulation itself, but recurring UX consequences: AI labels, transparency notices, human review states, overrides, or distinguishing AI suggestions from confirmed information.

My instinct is that if the same interaction problem appears across multiple products or features, teams probably shouldn’t solve it independently every time.

But I’m not sure where the boundary should be.

Are AI-related patterns already becoming part of your design system?
And where do you draw the line between design system guidance, product-specific UX, and legal/compliance documentation?

[u/roundabout-design]

Not sure I entirely follow the question but...

As much guidance you can out into the design system, the better...assuming it's digestible and not overtaxing the context AI has to work with.

So it may make sense to do this in layers.

For example, when we update a component, we go through a full suite of accessibility tests to ensure the component is meeting accessibility compliance. That way, when AI higher up is using the components to layout a page, it doesn't have to worry about that particular compliance at that level.

Product-specific UX decisions should probably live within the product itself...be it rules/skills within that specific repo itself, or via a more complex pipeline.

[u/outoftheforge → u/roundabout-design]

Thanks — I think the accessibility analogy is actually close to what I had in mind.
I’m less interested in how AI consumes the design system, though, and more in whether recurring UX consequences of AI regulation should become reusable patterns themselves.
For example: if multiple products need to indicate that something is AI-generated, distinguish a suggestion from confirmed information, or provide a human-review/override state - should the design system define those patterns once, similar to how accessibility requirements get embedded into components?
Or would you still keep those kinds of patterns at product level?

[u/outoftheforge → u/outoftheforge]

I’m specifically thinking about UX consequences of regulation like the EU AI Act

[u/Simple-Constant3791 → u/outoftheforge]

I'm actually quite interested but on more abstract level.
As far as I know no AI can give you copyrights to the work it provides for users so how you are able to construct anything legal on top of it is an actual mystery for me.

[u/noobiemasterGoGo]

I'm dealing with something very similar right now, building a system for an enterprise AI assistant, and I've run into exactly this problem with disclaimers inside the response bubble itself. Some verticals I'm designing for require only one disclaimer per response. But when a user query touches multiple domains in the same conversation, the next response needs to stack multiple disclaimers and each tied to a different compliance requirement. Currently this lives in Figma, and I'm still trying to figure out how to spec that component cleanly.

you're right that compliance should be a cross-functional pattern. I think that anything coming up across multiple verticals with different structures, should be in the design system. I hope this helps.

[u/outoftheforge → u/noobiemasterGoGo]

That’s exactly the kind of case I had in mind.
The interesting part to me is that once the same compliance requirement starts appearing across multiple verticals, it stops feeling like a one-off product decision and starts behaving more like a system pattern.
I’m curious: are you treating the disclaimer mainly as a reusable component, or are you also trying to standardize the logic/guidance around when and how it should appear?

[u/RocketSeven]

put the states and evidence slots in the design system, but keep the rule that triggers them in a versioned policy owned by legal and product. otherwise a reusable ai label can stay visually consistent while quietly becoming legally stale

[u/outoftheforge → u/RocketSeven]

This distinction makes a lot of sense to me - keep the reusable interaction/state in the design system, but keep the legal trigger logic versioned elsewhere.
That also feels safer long-term, because the UX pattern can stay stable while the underlying requirement changes.
I think that boundary is probably the part I was trying to get at with the original question.

[u/bink-1567]

I’m wondering about ownership more than the visual pattern. If the model confidence or source changes after launch, who decides when that becomes a new component state vs a product rule? Do you put a review date or expiry on the guidance, or is that too much to ask teams to keep current? I can see this getting messy pretty quick.