We're not designing AI products wrong. We're designing them for the wrong user.

Here's a failure mode that is not hypothetical.

An AI agent applies a promotional pricing rule to a product catalogue. The rule was specified in natural language — conversational, the way consumer AI interfaces are designed to accept input. The AI interprets it correctly in the general case and incorrectly in three edge cases involving bundle pricing logic. The change executes across an integrated inventory system. By the time the error is caught, the mispriced products have been live for four hours across 20,000 store integrations. The correction requires a manual audit of every affected SKU.

Nobody designed for this failure. They designed for the average case, the way consumer AI UX is designed — for the interaction that works, not for the interaction that misfires at scale.

This is what happens when you take a design playbook built for consumer AI and apply it to enterprise operations. It doesn't produce bad UX. It produces systems where the failure modes are invisible until they're catastrophic.

The consumer AI UX playbook

Consumer AI UX has a coherent, well-developed design philosophy. It emerged from products like ChatGPT, Midjourney, and Claude — tools where the primary design challenge is reducing the barrier between a user's intent and a useful AI output.

The principles are internally consistent. Make input conversational — natural language lowers the cognitive cost of engagement. Make output exploratory — show variations, encourage iteration, treat the first response as a starting point. Make failure graceful — if the AI gets it wrong, it's easy to try again with a different prompt. Design for the average user's first interaction, not for the power user's hundredth.

These principles produce genuinely good design for consumer contexts. They are actively dangerous in enterprise ones.

The consumer AI design philosophy is optimised for delight on the path that works. Enterprise AI has to be designed for survival on the path that doesn't.

Why consumer AI principles fail in enterprise

The failure is structural, not executional. It's not that consumer AI design patterns are applied badly in enterprise contexts. It's that they were built for a fundamentally different risk environment.

In consumer AI, the blast radius of a wrong output is bounded. A user gets a bad poem, a hallucinated fact, an image that misses the brief. They try again. The cost is seconds of frustration and a slightly worse experience. The system is designed around this — graceful failure states, easy reprompting, outputs that are clearly outputs rather than executed actions.

In enterprise AI, the blast radius scales with the system's integration surface. An AI that generates incorrect copy for a product listing affects one page. An AI that executes an incorrect inventory reallocation affects fulfilment across every warehouse the system is integrated with. An AI that misapplies a pricing rule doesn't produce a wrong answer — it produces a wrong state that the system then acts on, downstream, automatically, before anyone has reviewed it.

The design implications are completely different. Consumer AI can be conversational because conversation is reversible — you can clarify, correct, redirect. Enterprise AI cannot be conversational in the same way because the conversation ends in an execution, and executions in integrated operational systems are not easily reversed.

Role-based permissions are a design constraint that consumer AI never encounters. In a consumer AI writing tool, every user has the same action surface — they can prompt, they can save, they can share. In enterprise AI, the action surface is a function of organisational authority. A warehouse manager can approve inventory reallocation. They cannot approve pricing changes. A category manager can update product attributes. They cannot trigger fulfilment logic. The AI's proposal set — what it even surfaces as options — must be scoped to what the logged-in user is authorised to approve.

This is not a backend access-control problem. It's a design problem. An AI that surfaces proposals the user cannot approve creates confusion about what the system can do. An AI that only surfaces proposals within the user's authority creates a qualified, trustworthy proposal set. The design decision — what the AI shows, not just what it executes — is load-bearing in a way that consumer AI design never has to consider.

The enterprise AI design principles that actually work

The supervised autonomy architecture we built at Fynd was a deliberate rejection of the conversational AI model.

The loop — Observe → Propose → Preview → Approve → Execute → Audit — was designed around one premise: the AI does the cognitive work, the human authors the outcome, the system executes with a complete record. Not because we didn't trust the AI's accuracy. Because we understood that trust in enterprise AI is not built through accuracy alone. It's built through visibility — through an operator seeing, repeatedly, that the system understood the situation before they approved the action.

Preview before execution is not a UX nicety. It's the mechanism by which trust accumulates.

The specific design of the preview matters as much as its existence. We moved from natural language summaries to database-level diffs — the actual before and after state of every record the action would affect. The summary told operators what would change. The diff showed them. The difference in approval confidence was immediate and significant.

The audit trail is a design requirement, not a compliance afterthought. When something goes wrong in an enterprise system — not if — the operator needs to reconstruct three things: what the AI proposed, what the human approved, and what the system executed. These are three potentially different things. The design of the audit system has to capture all three, at the moment they occurred, with enough context to make the reconstruction meaningful. This requires designing the logging architecture as a user experience — one whose primary user is the operator trying to recover from an incident, not the compliance team generating a report.

Blast radius as a design input. For every AI action surface we designed, the first question was: what is the maximum damage this action can cause if it misfires? Not the average case — the maximum case. The answer determined how much friction the approval flow needed. Low blast radius actions — single-record updates, reversible configuration changes — got streamlined approval. High blast radius actions — bulk operations, pricing changes, fulfilment logic — got explicit diff review, role confirmation, and a deliberate pause in the interaction. The friction was not accidental. It was calibrated.

What the industry needs to do differently

The enterprise AI design discourse needs to separate from the consumer AI design discourse. Not because they don't inform each other — they do — but because conflating them produces a set of best practices that is correct for one context and actively harmful in the other.

Evaluation criteria need to separate. Consumer AI UX is evaluated on time-to-first-useful-output, engagement, and the quality of the average interaction. Enterprise AI UX should be evaluated on recovery time from a misfire, audit completeness, approval accuracy under time pressure, and the rate of silent errors — AI actions that executed correctly in the technical sense but incorrectly in the operational sense. These metrics don't exist in consumer AI evaluation frameworks. They need to exist in enterprise ones.

Design patterns need to be documented separately. The conversational input model, the exploratory output model, the graceful failure model — these are consumer AI patterns with consumer AI assumptions baked in. Enterprise AI needs its own pattern library: the diff-first approval model, the blast-radius-calibrated friction model, the role-scoped proposal model, the audit-first logging model. Some of this work is happening inside enterprise product teams. Almost none of it is being shared publicly.

Close

The enterprise AI design failures of the next three years are already being designed right now.

They're being designed by teams who have read the right articles about AI UX, applied the right consumer AI principles with genuine craft and care, and built products that will work beautifully in demos and fail consequentially in production.

Not because they designed badly. Because they designed for the wrong user — for the curious first-time experimenter rather than the operations manager whose business runs on the system being correct.

The consumer AI user can afford for the AI to be wrong sometimes. The enterprise operator cannot.

That difference is the entire design problem. And until the industry treats it as such — with separate principles, separate patterns, and separate evaluation criteria — we will keep producing enterprise AI that looks like consumer AI and fails like a system that was never designed for what it's actually being asked to do.