In AD 208, Cao Cao commanded an army so powerful that few would have dared challenge it. He controlled an overwhelming share of the resources, the largest talent pool, and seemingly unlimited capacity to execute. His objective was equally ambitious: cross the Yangtze River, defeat the forces of Sun Quan and Liu Bei, and unify China.
In today’s business language, think of it as a market leader with dominant market share, deep pockets, the best talent in the industry, and a strategic mandate to transform the business and reshape the competitive landscape.
On the other side of the river were Sun Quan and Liu Bei: two much smaller, scrappier rivals whose combined forces were vastly outnumbered.
At first glance, this looked like a straightforward victory for Cao Cao. But there was one problem: his northern soldiers were unfamiliar with fighting on water. They became seasick and struggled to operate on the ships. So Cao Cao came up with a seemingly elegant solution: chain the ships together and lay planks across them, effectively turning the fleet into a stable platform. Everyone could now move as if they were on solid ground.
In enterprise AI terms, it sounds familiar: build one centralized, enterprise-wide AI platform; connect every business unit; unify data, models, governance and approval processes; standardize the experience and keep everything under control.
At the strategy meeting, someone might have asked: What if they attack us with fire?
Cao Cao had an answer. It was winter. The prevailing wind came from the northwest. His forces were on the northern bank, while the enemy was on the southern bank. If they tried to set his ships on fire, the wind would simply carry the flames back toward them.
The logic was airtight. The risk was under control. Except for one thing: the wind changed. And that is when the Battle of Red Cliffs became one of the most famous turning points in Chinese history.
The opposing commander, Zhou Yu, saw the vulnerability immediately: the ships were chained together.
Huang Gai, a veteran general trusted by Cao Cao, proposed a deception. He would pretend to defect, approach Cao Cao’s fleet with a group of ships loaded with fuel and kindling, and then set them ablaze.
Cao Cao’s soldiers watched the approaching ships, convinced that Huang Gai was coming to surrender. Then the flames started. A strong southeastern wind carried the fire from ship to ship. What had been designed to create stability became a mechanism for spreading destruction. The fleet burned. The camps on shore caught fire. Cao Cao’s forces were defeated.
The traditional Chinese literary version of the story later added many memorable elements: the famous “borrowing of the east wind,” elaborate stratagems, and the pursuit at Huarong Pass. But the historical account recorded in Zizhi Tongjian is much more concise.
And its description of the battle contains two details that matter enormously:
- The ships were connected.
- The wind was strong.
One was a structural vulnerability. The other was an unexpected variable. Together, they turned Cao Cao’s greatest advantage into his greatest weakness.
That is a surprisingly useful way to think about enterprise AI transformation.
Centralized control vs. independent agility
How do you avoid systemic risk in your AI architecture?
Cao Cao chained his ships together. The immediate benefit was obvious: his soldiers could move across the water without getting seasick. Stability improved. Coordination improved. The fleet became easier to manage.
But the same decision created a systemic vulnerability. Previously, if one ship caught fire, only one ship would burn. Now, if one ship caught fire, the entire fleet could burn. The fact that the ships were connected was the vulnerability Huang Gai saw — one Cao Cao had created himself.
Many large enterprises face a similar temptation when they begin their AI transformation.
The instinct is often to build one centralized, enterprise-wide AI platform: connect every business unit, consolidate data, standardize capabilities, establish common governance and create a consistent user experience.
From a governance perspective, this makes perfect sense. It reduces duplicated investment, strengthens security and compliance, and creates economies of scale. But it follows the same underlying – and faulty – logic as chaining the ships together: take a collection of independent units and bind them into one centrally managed system.
The problem is that once everything is tightly coupled, three challenges emerge.
- Concentrated risk: A data incident in one business unit can quickly become a company-wide trust and compliance crisis.
- Loss of speed: Business teams lose the ability to experiment independently. When a new AI opportunity emerges, their first question may no longer be “Can we try this?” but “When can the central team approve it?”
- The illusion of transformation: A centralized AI platform can make an organization feel as though it is transforming, when it may simply be using AI to make existing processes faster and cheaper — without questioning whether those processes should exist in their current form at all.
Of course, centralized platforms and independent agility are not mutually exclusive.
A mature AI architecture should provide common capabilities, security guardrails and economies of scale at the platform level, while preserving room for business units to make their own choices and iterate independently.
Coupling should be intentional. It should never become a chain.That means clearly separating the governance boundaries between the platform and the applications built on top of it:
Standardize the platform. Empower the applications. This allows the organization to maintain common standards and risk controls while preserving each business unit’s ability to respond when the market changes.
The question is not whether the ships should be connected. It is which ships need to be connected, at which layer, and for what purpose.
Top-down transformation vs. innovation from within
Where does the real engine of AI adoption come from?
Huang Gai’s deception was not simply a military trick.It worked because it provided a plausible means for the fire attack to approach. Huang Gai was a veteran general known to Cao Cao. His reputation made his surrender believable. The fire did not come from outside; it was brought from within.
This is another useful lesson for enterprise AI.
When organizations launch an AI transformation, the default approach is often top-down: headquarters defines the strategy, builds the platform, establishes the governance model, and then rolls it out across the business.
The challenge is that new technology naturally creates a trust barrier. People are being asked to change how they work, learn unfamiliar tools and absorb the cost of experimentation. And that is why some of the fastest AI successes we see often originate much closer to the business.
People who have spent years working within a function understand where the real friction is. When they also develop enough AI literacy to recognize what the technology can and cannot do, they can identify far more precise entry points and validate new use cases with much less effort.
These people may not be the most technically sophisticated ones in the organization. But they often have something just as valuable: business knowledge and internal trust.
Top-down strategy and bottom-up innovation are therefore not competing models. They solve different problems:
- Top-down leadership provides direction, resources, risk management and the framework for scaling.
- Business-led innovation provides relevance, speed and practical validation.
The most effective AI strategy does both. Set the direction from the top, then identify and activate the people within the organization who can make that direction real.
Every organization needs its own version of Huang Gai: people who understand the business deeply enough to know where AI can create value, and who have enough credibility to bring that change into the organization from within.
The question is not whether transformation should be top-down or bottom-up. It is: “Who inside the business can carry the spark?”
A strategy that was logical vs. a paradigm that has changed
What should guide judgment during an AI transformation?
Cao Cao was not careless about risk. According to the historical account, his advisors had considered the possibility of a fire attack. His reasoning was straightforward: The enemy was to the south. His forces were to the north. It was winter. The prevailing wind came from the northwest. So if the enemy tried to use fire, the flames would be blown back toward them.
The reasoning was not irrational. In fact, it was based on years of experience. Cao Cao had spent decades fighting in northern China. His understanding of winter weather had been repeatedly validated. The problem was not that his experience was wrong.
The problem was that he had carried a local rule into a different environment and treated it as universal.
The Yangtze River region followed a different set of climatic conditions. The context had changed. And when the context changes, even a perfectly rational model can produce the wrong answer.
We hear similar arguments from companies when discussing AI:
- “Our industry is too specialized. AI won’t be able to handle it.”
- “We have twenty years of proprietary know-how. A model can’t understand it.”
- “Our customers need trust. A machine can’t provide that.”
These statements may have been perfectly reasonable under the previous technological landscape. But AI is not simply a better tool. It represents a paradigm shift.
The experience that made someone an excellent seafarer in the sailing ship era does not necessarily tell them how a steamship will behave.
The same is true for AI. Many organizations are making perfectly rational judgments about AI based on assumptions that are no longer stable.
They mistake:
- “It doesn’t work yet” for “It will never work.”
- “I’ve never seen it” for “It doesn’t exist.”
- “We’ve done it this way for twenty years” for “We’ll do it this way for the next twenty.”
These are dangerous cognitive traps during a technological transition. The answer is not to dismiss experience. Experience remains one of the most valuable sources of judgment. But organizations need to make one additional habit part of every AI strategy discussion: what assumptions underpin our conclusion, and are those assumptions still valid in the new technological paradigm?
At critical moments in AI strategy, organizations should also deliberately bring different perspectives into the room. Not because those people necessarily have the right answer. But because they may ask the question nobody else thought to ask.
In Cao Cao’s camp, the missing person was not another strategist. It was someone asking: “What if the wind is different on the other side of the river?”
Centralized command vs. distributed decision-making
Where should decision rights sit in the AI era?
Cao Cao’s command structure was highly centralized. Orders flowed from the central command and were communicated through the hierarchy. That model worked well on the battlefields Cao Cao knew: large open spaces, relatively predictable conditions, and enough time for orders to travel through the chain of command.
Red Cliffs was different. The battlefield was changing by the minute. And when Huang Gai’s ships approached, Cao Cao’s soldiers simply watched. They waited for instructions. By the time anyone could react, the fire had already spread. This is where the contrast with the opposing forces becomes important.
Huang Gai saw the opportunity created by the connected ships and acted through the existing command structure, bypassing the lengthy escalation process. The broader principle is simple: when the environment changes faster than the hierarchy can respond, centralized decision-making becomes a liability.
Large enterprises often fall into exactly this trap with AI. They centralize the platform; they centralize approval; they centralize access. And they centralize decisions about which use cases are allowed, which data can be used and which models can be deployed.
The intention is understandable: control risk and prevent chaos. But this model carries an implicit assumption: AI is stable enough for the center to evaluate everything before the business needs to act.
In reality, the opposite is often true. AI opportunities are distributed. Business needs are highly contextual. The teams closest to customers and operations usually see the opportunities first. And while headquarters is still evaluating whether a use case is worth pursuing, the use case may already have changed. While the governance team is still assessing whether a model is safe, the model itself may have gone through several iterations.
So the question is not: Should we control AI or not? It is: What should be controlled centrally — and what should be decided locally?
The lesson from Red Cliffs is surprisingly relevant. Central leadership should own three things:
- Strategic intent: What are we trying to achieve?
- Guardrails: What are the non-negotiable security, compliance and risk boundaries?
- The arsenal: What common models, data infrastructure, platforms and security capabilities should everyone have access to?
Then comes the crucial part: When the opportunity appears, make the decision where the opportunity is visible.
Applied to enterprise AI governance, the principle is straightforward:
- Centralize what needs to be centralized: Security, compliance, architectural principles and resource efficiency.
- Decentralize what benefits from proximity to the business: Which use cases to pursue, how to apply AI, how to experiment and how quickly to iterate.
The teams closest to the business are often the ones who can see where the next opportunity is emerging. Give them the tools. Give them the guardrails. Then let them move.
The Red Cliffs Test for Enterprise AI
The Battle of Red Cliffs is often remembered as a story of an outnumbered force defeating a much larger army. But from an enterprise AI perspective, the more interesting lesson is different.
Cao Cao did not lose because he lacked resources. He lost because the way he organized his resources created a vulnerability; his transformation was driven from the center rather than from the edge; his judgment relied too heavily on assumptions that had changed; and his decision-making structure could not respond quickly enough when the environment shifted.
That makes Red Cliffs an unexpectedly useful framework for thinking about AI transformation.
Four questions are worth asking:
- When designing your AI architecture, are you building a resilient fleet or chaining every ship together into one fragile system?
- When driving AI adoption, is the innovation engine sitting in a strategy document at headquarters or in the hands of the people inside the business who can actually carry the spark?
- When assessing the timing and risks of AI, are your decisions based on what your experience tells you today or on what may be possible under tomorrow’s technological paradigm?
- And when designing AI governance, are you trying to control every movement of every ship or are you setting the direction, the boundaries and the capabilities that allow the fleet to move?
The companies that get these choices right will not necessarily be the ones with the biggest AI budgets, the most advanced models or the largest technology teams. They will be the ones that understand where to standardize, where to experiment, which assumptions to challenge, and where to place decision rights.
In the next decade of AI-driven competition, that may prove to be the difference between an organization that merely adopts AI — and one that truly transforms with it.
