The Fastest AI Is Not the Smartest
There is a pattern that repeats itself in enterprise artificial intelligence projects and that rarely appears in monitoring dashboards: users begin to double-check what they previously accepted without hesitation. Not because the system failed. But because the system moved forward before they could keep up with it.
EY gave a name to that pattern in an article published in Fortune at the end of June 2026. They called it "tempo gap": the point at which the speed of the machine exceeds the human capacity for comprehension. Patricia Camden, customer experience leader at EY Studio+, and John Dubois, AI strategy leader for the Americas, documented this phenomenon based on their work with enterprise clients across different industries. Their diagnosis is direct: most organizations believe their biggest problem with AI is adoption. It is not. It is the pace.
What makes this argument interesting is not that it is new in technical terms. It is that two executives from one of the largest consulting firms in the world are saying it, in a high-impact business publication, using a language that no longer sounds like a euphemism: the problem is not in the algorithm, it is in the design of the human experience surrounding that algorithm. And that has implications that go well beyond user experience.
When the System Works Well and Something Still Goes Wrong
The three cases that Camden and Dubois cite to illustrate the tempo gap are precise in what they reveal. A traveler with a cancelled flight is automatically rerouted to another flight before they can compare options. A customer completes a financial application so quickly that they accept material conditions without having processed them. A patient filling out a medical form sees their sensitive data pre-filled before understanding how it will be used.
In all three cases, the system functioned exactly as it was designed to. There were no technical errors. There were no security failures. And yet, the experience produced hesitation, distrust, and in some environments, the silent reintroduction of manual review into processes that had been automated precisely to eliminate it.
That last point deserves attention. When teams begin to verify outputs they previously accepted, they are not being irrational. They are responding to a design signal: the system moved faster than their capacity for understanding, and that generated a trust deficit that they now have to settle by hand. The cost does not appear in the process speed indicators. It appears in the invisible time that operators spend re-validating what the AI already did.
EY calls this "manual review seeping back into the process". From an organizational architecture perspective, it is something more specific: it is the symptom of a system that was optimized for efficiency without being calibrated for trust. And that distinction is not semantic. It has direct consequences on operational costs and on the real capacity to scale.
The argument underlying EY's diagnosis is that most organizations still treat AI adoption as an efficiency initiative. The corporate conversation remains focused on automation, friction reduction, and speed. What is left out of that conversation is that accelerating workflows also changes the cognitive demands placed on the people who navigate them. And when those demands are not well designed, the promised efficiency becomes an operational illusion: the process is formally faster, but people are running behind it without understanding what they are approving.
The Blind Spot That No One Named in the Design Room
This is where EY's analysis touches on something that goes beyond user experience and enters the territory of power architecture. The tempo gap is not just an interface design problem. It is, first and foremost, a problem of who was present when the design decisions were made.
The three examples EY documents — the rerouted traveler, the financial customer who accepts without reading, the patient with pre-filled data — share a common structure: a system that was designed from the perspective of whoever operates it, not from the perspective of whoever experiences it. The efficiency of automatic rerouting is perfectly logical from the airline's or agency's side. The speed of the financial application is an achievement from the bank's point of view. The pre-filling of medical data looks like a usability improvement from the technical team's standpoint.
What was missing in those design rooms was not malicious intent. It was peripheral intelligence: the perspective of the person at the receiving end of the system, whose experience is not the optimization of the process, but the preservation of their own capacity for agency.
This is a structural pattern in how enterprise AI systems are built. Design and product teams tend to be composed of people who share a set of assumptions about how decision-making works, what constitutes a good experience, and how much time it reasonably takes someone to process information. When those teams are homogeneous in their relationship with technology, in their tolerance for speed, in their prior access to complex financial or medical information, they produce systems calibrated for people like themselves.
The tempo gap is, among other things, the cost of that homogeneity. Not in moral terms, but in terms of design quality. A system that systematically generates hesitation in its users is a system that was designed without incorporating the perspectives of those who most need comprehension before acting. And that is a problem of collective intelligence architecture, not declarative ethics.
EY does not frame its analysis in these terms. Its entry point is more operational: organizations must align the tempo of the machine with the human tempo. That is a sensible prescription. But the prior question is more uncomfortable and more relevant to the companies that are designing these systems right now: from what design room did the assumption emerge that faster is always better, and who was in that room?
Friction as a Design Signal, Not an Obstacle
For more than a decade, the dominant philosophy in digital design was the elimination of friction. Fewer clicks, fewer steps, less time between intention and action. That philosophy produced measurable results: higher conversion rates, greater retention, faster processes. It also produced, silently, systems where speed began to serve those who operate the system more than those who use it.
EY proposes a precise conceptual shift: intentional friction as a design tool. Not arbitrary delays, but deliberate pauses at the moments where a user needs comprehension before acting. A confirmation before executing a financial decision. A brief explanation of how sensitive data will be used. A second of visibility into why the system did what it did.
What is remarkable about this argument is that it is not asking for systems to be slower in absolute terms. It is asking for them to be selectively slower at the moments of greatest consequence for the user. That requires the system to know how to distinguish between a moment of low and high cognitive load, between a routine action and a decision with material implications. That capacity for distinction does not emerge from the algorithm. It emerges from design, and design emerges from those who understand what makes a decision material for someone who does not share the same context as the team that built the system.
In sectors such as financial services, healthcare, or insurance, this argument carries a regulatory dimension that EY mentions in passing but which deserves more weight. Consumer protection regulations, informed consent requirements, and fair disclosure rules are all built on the assumption that people understand what they are agreeing to. An AI system that moves users faster than their capacity for comprehension does not merely produce a poor experience. It produces a legal and regulatory vulnerability that organizations are silently accumulating in every workflow they optimized for speed without considering comprehension.
EY warns that if organizations do not name this problem themselves, a regulator or a customer will. That is a reasonable prediction given the pace at which AI regulatory frameworks are advancing in Europe and, with a lag, in other regions. The question is not whether there will be external scrutiny over how AI systems handle user agency and comprehension. The question is how much accumulated damage there will be before that scrutiny arrives.
The Next Phase of Adoption Is Not Won With Speed
EY's argument has a strategic core worth extracting with precision: the next phase of competitive advantage in AI will not belong to whoever automates fastest, but to whoever best calibrates the pace at which their systems relate to the people who use them.
This is not a concession to slowness. It is a diagnosis about where technical and organizational debt is accumulating in enterprise AI projects. Organizations that have high override rates, unplanned manual review, and systematic user hesitation are not failing at adoption. They are failing at design. And that failure has a direct cost on the return from AI programs, which promised to eliminate manual work and are, in some cases, generating it again through the back door.
The solution EY proposes — aligning the tempo of the machine with the human tempo — requires a capability that cannot be built with better algorithms alone. It requires organizations to incorporate, into their AI system design teams, perspectives from people who represent the full range of user experiences: those with less technological familiarity, those who face greater information asymmetry in financial or medical contexts, those who have more at stake in each interaction.
That is not design philanthropy. It is the structural condition for an AI system to be intelligent enough to know when it should slow down. And a system that does not know when to slow down is not an intelligent system. It is a fast system. The difference between the two is precisely the gap that EY has just given a name to — and that most organizations still do not have on their metrics dashboard.
