Research · AI governanceMBA thesis · 2026

Governing AI in enterprise UX practice

Six interviews, four countries, five organisations. Original qualitative research into how enterprise design teams are actually handling AI tool use, and what a governance framework needs to address before the adoption-governance gap becomes unmanageable.

Research explainer

A short AI-narrated overview of the research and its findings. Nine minutes, useful if you'd rather watch than read.

Method

6 semi-structured interviews, interpretivist thematic analysis (Braun and Clarke, 2006)

Scope

4 countries, 4 sectors — media, SaaS, fintech, consulting

Central finding

0 organisations with formal AI governance in place

Programme

MBA, Tomorrow University · 2026

The problem

AI adoption has outpaced the structures meant to manage it.

AI tools have moved into professional design work faster than anyone expected. They are not being tested in innovation labs. They are being used in live projects, generating real outputs that reach real products. The organisational structures meant to manage how those tools are used have not kept pace.

There are no formal policies in most teams, no approval processes, no quality checks specifically designed for AI-generated work. When I asked one participant how his organisation managed AI tool use in design work, he replied: "I have no clue to be honest."

"I have no clue to be honest. They were just talking from the compliance legal perspective, but they don't necessarily understand exactly where is that information being used."

Participant 2 (SaaS, Canada) — on how their organisation managed AI tool use

Approach

Six conversations, four countries, one question

I spoke with six senior UX designers working inside large organisations across Germany, Canada, Poland, and the USA. They came from broadcast media, software, financial services, and AI consulting. We talked about how they actually use AI day to day, and what their organisation does, if anything, to manage it.

Being a practising enterprise designer myself meant I could ask better questions and spot things an outsider might miss. It also meant my own experience could colour how I read what I heard. I kept notes on my assumptions throughout and went back to the transcripts whenever I felt myself reaching for a conclusion the data hadn't yet supported.

Findings

Six patterns. One consistent finding: nobody is in charge.

Across all six interviews, the same problems kept appearing in different forms. The six themes form a cascade — each one creates the conditions for the next, which is why addressing just one in isolation is not enough.

No rules, so people make their own. None of the five embedded organisations had any formal structure for managing how AI tools were used. Practitioners were making it up individually, with no shared rules and no organisational backing.

AI is quietly breaking design systems. AI tools that generate code or components often work with limited memory of what has already been built. They duplicate things that already exist, generate inconsistencies, and slowly erode the shared foundations teams depend on.

Who made this decision? When AI produces a design, it is unclear whether the designer made it or just approved it. That ambiguity over authorship and accountability is unresolved in most teams, and no one is formally responsible for closing it.

Someone has to check the AI's work. That's not in anyone's job description. Designers are informally reviewing everything AI generates, but this verification layer is invisible in most team processes. It depends entirely on one person's time and judgment, with no organisational authority behind it.

Other teams are making design decisions using AI. Product managers, developers, and marketers are using AI to generate visual outputs without involving designers or following shared standards. Design quality is spreading across the organisation without design ownership spreading with it.

Regulation is the only thing setting limits. For most teams, external legal requirements are the only real boundary on how AI is used. Governance is arriving as compliance rather than as a deliberate team decision, and only in companies where regulation already applies.

"They don't remember anymore that there were some components for filters, so they just build a new filter component."

Participant 3 (Broadcast media, Poland) — on AI coding agents duplicating design system components

Central insight

Governance that works is structural, not procedural.

Procedural governance means writing policies and asking people to follow them. The problem is that AI generates output so fast that by the time a human reviewer sees one artefact, ten more have already been produced. Procedural governance cannot keep up with that volume.

Structural governance embeds the rules into the tool itself before it generates anything. The constraint is architectural rather than behavioural — the right behaviour happens by default, not by memory.

Procedural — limited at scale

Write policies. Ask people to follow them.

Relies on human memory. Vulnerable to bypass. Individual verification burden. Cannot keep pace with AI's output volume.

Structural — more robust at scale

Embed constraints into the tool before it generates.

Constraint is architectural, not behavioural. The right behaviour happens by default, not by memory. Output is governed before anyone sees it.

"If they're using Claude, and it automatically uses the right colours and the right language, that's a really good solution."

Participant 5 (SaaS, Canada) — on encoding design system rules into AI tool configurations

The framework

Modular, not monolithic. Organisations do not have to start from the same place.

The framework produced by this study is built around one principle: governance should be modular. Teams can start with one dimension and build from there. The most immediate action for most teams is configuring AI tools to follow design system rules automatically, so consistency happens at the point of generation, not in the review that follows.

Scratch-builders

Constrained orgs

Teams without external compulsion

Teams with regulatory skeletons

Decision quality

Iterative comparison protocols — compare AI outputs against human baselines before accepting

Tool-level access controls — use existing security infrastructure to gate which AI tools can process which data

Creative agency

Workflow protocols protecting human baselines — designer defines the problem before AI generates options

Mandatory human design reviews — add a formal AI-output review step to existing approval workflows

System consistency

AI tool configs synchronised to the design system — keep config files (e.g. claude.md) in version control alongside the system

System-aware AI agent constraints — scope AI tools to the design system's token and component context

Who needs to act

Three groups, three different requirements.

UX leads

Stop waiting for problems in final output.

Encode standards into AI tool configurations before output is generated. Update design system handoffs to include an explicit review step for AI-generated artefacts.

Product orgs

Treat AI tool adoption as an enterprise risk.

Governance that depends on one person checking every output will collapse under volume. Embed design leads in IT and Legal AI tool approval processes. These are leadership decisions.

Researchers

Test whether structural governance improves outcomes.

Move beyond general AI ethics to validate practitioner-grounded frameworks at enterprise scale. The open question is whether structural governance improves quality or simply shifts the problem.

Outcome

Governance dimensions: decision quality, creative agency, design system consistency

Entry points: voluntary teams building from scratch, regulated teams with an existing constraint skeleton

1st

Practitioner-grounded governance framework for AI-integrated enterprise UX, no prior study at this scope

The framework is designed to be practical. Teams can start with one dimension and build from there. The most immediate thing most teams can do is configure their AI tools to follow design system rules automatically — so consistency happens at the point of generation, not in the review that comes after.

↓ Download full thesis PDF

Reflection

What this research taught me about my own practice

I expected to find teams that had either figured this out or given up on it. What I found was neither. Most teams were managing AI reasonably well day to day, but couldn't explain why their approach worked or what they'd do if it stopped. That gap, between practice and understanding, is where the real exposure sits. It also changed how I think about my own use of AI in design work. Having a clear sense of where I bring it in and where I don't isn't just a preference. In work with real consequences, it is something you should be able to account for. I can now.

Closing argument

Architect constraints, not just adopt capabilities.

Effective governance cannot be a checklist applied after AI has already produced something. It must be built into the tools, processes, and environments where design work happens, before it happens.

The problem