
Discover how the 70-20-10 framework helps enterprises scale AI through workflow redesign, governance, and people adoption.
Most enterprise AI programs do not fail because the model was wrong. They fail because the organization was not ready to run it.
The technology has never been more capable. The gap is not intelligence; it is infrastructure. Not model infrastructure, but organizational infrastructure: the people who need to adopt it, the processes that need to be redesigned around it, and the investment logic that needs to govern it. Executives who close that gap are the ones turning AI experiments into operating advantage. The ones who do not are paying for a growing portfolio of impressive pilots that never graduate to production.
The 70-20-10 framework, adapted from its origins in learning and development into enterprise AI strategy, offers one of the clearest mental models for thinking about where that gap lives and how to close it deliberately.
Why AI Transformation Stalls at the Organizational Layer
A typical enterprise AI program starts with technology. A model is selected, a vendor is engaged, a use case is scoped, a pilot is run. The demo works. The model answers questions correctly on staged data. Leadership is encouraged.
Then the workflow hits real conditions: messy data, exception cases, compliance checkpoints, approval chains, systems that were never designed to talk to each other, and employees who were never told why the tool exists or what it means for their role. The pilot stalls. The business case erodes. The next quarter brings a new pilot.
The pattern is not an AI problem. It is an organizational change problem wearing AI clothes. The 70-20-10 framework helps executives see it clearly and act on it systematically.
The Framework: What 70-20-10 Actually Means for AI
Originally developed to describe how adults learn (70% through experience, 20% through social interaction, 10% through formal instruction), the 70-20-10 principle translates with striking relevance into AI transformation strategy.
In the enterprise AI context, it maps to where your transformation investment and attention should actually go:
70% on process and workflow redesign. The majority of AI transformation value and the majority of its failure risk lives not in the model but in the work the model is supposed to improve. Before an AI system can operate in production, the underlying workflow needs to be understood at a level of precision that most organizations have never needed before. Who owns each step? What are the exception cases? Where do compliance rules apply? What does a good output actually look like? What happens when the system is wrong? These are not AI questions. They are operations questions. And they take the majority of the effort to answer well.
20% on people and adoption. One of the most consistent findings across enterprise AI programs is that technology readiness runs well ahead of people readiness. The system is built. The workflow is mapped. The model is tuned. And then it sits unused because the team it was built for does not trust it, does not understand it, or was not involved in designing it. Twenty percent of transformation investment needs to go toward the people layer: change management, role redesign, training, communication, and the organizational trust-building that comes from involving frontline users before launch rather than after.
10% on the model and technology. This is the number that surprises most executives, because it is where almost all of the vendor conversation lives. The model matters. The integration matters. The infrastructure matters. But in a well-run AI transformation, these are the smallest part of the challenge, because they are the most tractable. Models improve. Integrations can be engineered. Cloud infrastructure scales. What cannot be bought off a shelf is a redesigned claims process, a retrained underwriting team, or an organization that trusts its AI systems enough to let them run the work.
The People Layer: Where Adoption Actually Happens
The 20% that covers people is not a soft, secondary concern. It is the difference between a system that gets used and one that gets bypassed.
Enterprise AI adoption follows a predictable arc. Early adopters engage immediately, often without prompting. A large middle group waits to see whether the tool is reliable, whether it changes their role in ways they understand, and whether leadership is serious about it. A smaller group resists, sometimes for legitimate reasons (the tool does not fit how they actually work) and sometimes because the change was announced rather than co-designed.
The Process Layer: Where Value and Risk Both Live
The 70% that covers process is the hardest work and the most consequential.
AI does not improve vague processes. It amplifies the structure of whatever workflow it is applied to. A well-defined, well-governed claims triage process becomes faster and more consistent with AI. A poorly documented, exception-heavy, politically complicated claims process becomes faster and more consistently wrong.
The practical implication for executives: the workflow redesign work that precedes an AI buildout is not a phase to compress in order to get to the technology faster. It is the investment that determines whether the technology delivers. Organizations that blueprint before they build, that map the users, systems, data flows, decision rules, exception cases, and approval paths before a single model is trained, consistently move from pilot to production faster than those that start with the technology and reverse-engineer the process later.
The Technology Layer: Governance-First, Not Governance-Later
The 10% is real engineering work, but its success depends entirely on whether the other 90% was done well.
This is the operating principle at ArqAI Labs: governance is not layered on top of the AI system. It is compiled into it, from the first workflow blueprint through every deployment and every expansion that follows.
Applying the Framework: What Executives Should Do Differently
The 70-20-10 framework is useful not because it is a formula but because it forces the right prioritization conversation at the beginning of an AI program rather than at the end of a failed one.
Start with the workflow, not the model. Pick one high-value process where AI should be doing more than answering questions. Understand it at the level of precision that production requires: users, systems, data, decision rules, compliance touchpoints, exception cases, and success metrics. That investment pays for itself in faster deployment and lower rework.
Then scale from one working system. The goal of the first AI deployment is not to solve the biggest problem. It is to prove that the organization can take one workflow from blueprint to production with the controls, adoption, and measurement in place to build on. That working pattern is what everything else scales from.
ArqAI Labs: Built for the 90% Executives Underinvest In
ArqAI Labs designs, builds, and runs production AI workflows for complex enterprise environments. Our engagement model is structured around exactly the framework described here: workflow strategy first, agentic buildout second, governance by design throughout, and managed operations to ensure systems keep performing after launch.
We work with teams in healthcare, insurance, banking, retail, and manufacturing, where the workflows are high-stakes, the compliance requirements are real, and the cost of a failed pilot is not just budget but trust.
If you have a workflow where AI should be doing more than answering questions, bring it to us. We will help you blueprint it, govern it, build it, and run it.
Frequently asked questions
What is the 70-20-10 rule in the context of AI transformation?
In enterprise AI transformation, the 70-20-10 framework is a prioritization model that allocates executive attention and investment across three layers. Seventy percent should go toward process and workflow redesign, which is where most AI value is created and most AI programs fail. Twenty percent should go toward people and adoption, covering change management, role design, training, and the organizational trust-building that determines whether a system gets used.
Why do most enterprise AI programs fail to move from pilot to production?
The most common failure mode is not technical. Pilots fail to scale because the underlying workflow was not designed for AI operation, the people expected to use the system were not involved in designing it, and governance controls were treated as a post-launch concern rather than a build requirement.
What does governance-first AI mean in practice for enterprise workflows?
Governance-first means that policy checks, approval paths, audit trails, exception handling, and human review loops are designed into the AI workflow before it touches production data, not added after the system has been running for a few months. In practice, it means defining who can approve what, which decisions require human review, how exceptions are routed, what gets logged for compliance purposes, and what the rollback path looks like before a single agent takes a live action.
How should executives measure the success of an AI transformation program?
Beyond model accuracy, which is necessary but not sufficient, production AI programs should be measured on workflow throughput improvement, exception rate and handling quality, human review utilization (whether review loops are calibrated correctly, not just present), adoption rate among the target users, audit trail completeness, time from exception to resolution, and unit cost per workflow outcome.
How long does it take to move a workflow from AI pilot to production?
The honest answer depends almost entirely on how much workflow redesign and governance work has been done before the buildout begins. Programs that start with a well-mapped workflow, clearly defined decision rules, identified users, scoped integrations, and agreed governance requirements can move from blueprint to a working production system in 30 to 90 days for a focused workflow.
Put these ideas to work in your operation.
Reading about operational AI is the easy part. Tell us which workflow should run differently and we will scope the path.