Most enterprise AI programs deploy the technology. Very few redesign the work.
That distinction is where the majority of AI value gets lost. The tool goes live. The workflows around it stay structurally unchanged. Humans adapt informally, parallel processes multiply, and the decision architecture the AI was designed to improve becomes a layered system of workarounds that no one formally approved, and no one formally owns.
This edition covers the AI in Practice pillar of the AI Change Loop framework: the structural discipline that determines whether AI actually changes how work gets done, or whether it becomes an expensive layer on top of work that continues largely as before.
The AI in Practice Gap: Why Workflow Redesign Is the Step Most Programs Skip
There is a consistent pattern in enterprise AI programs that have strong technical deployment and disappointing business outcomes. The AI model performs as designed. The accuracy metrics are solid. The system is stable. And six months post go-live, the business KPIs the program was built to move have not moved materially.
The diagnostic almost always finds the same structural condition. The AI was deployed into the existing workflow. The existing workflow was not redesigned to absorb it.
This is the AI in Practice gap. It is not a technology failure. It is an architecture failure. The program treated deployment as the destination when deployment was only the starting condition for the harder work: redesigning the decision topology so that AI produces measurable performance effects instead of sitting alongside a workflow that continues to operate on its original logic.
What AI in Practice Actually Governs
The AI in Practice pillar covers seven domains. Each one addresses a specific structural condition in the workflow environment where AI is operating.
The first is workflow topology redesign. This is the domain that determines where AI actually intervenes in the decision sequence, what authority it holds at each intervention point, where humans confirm or override, and where escalation triggers activate. When this work is not done, AI is overlaid on the existing workflow rather than embedded in it. The result is a parallel system: the official AI-assisted process and the informal human process that continues to run alongside it because no one redesigned the topology to make the AI-assisted path the actual path.
The second is decision boundary and override engineering. This domain defines when AI decisions are advisory, when they are default, when override is permitted, how override is documented, and how escalation is triggered. Authority ambiguity at the human-AI interface is one of the most reliable predictors of adoption failure in the data. When employees cannot answer the question of whether they are responsible for an AI-assisted decision or the AI is, they resolve the ambiguity in the most conservative direction available: they treat every AI output as advisory, document everything manually, and produce the exact parallel process the topology redesign was supposed to eliminate.
The third is parallel process elimination. This is the domain that addresses what happens to the existing processes when AI goes live. In most programs, the answer is: nothing. The existing processes remain active, the AI-assisted processes are added alongside them, and the organization ends up running both in parallel indefinitely. This is not a transition phase. It is a structural failure. Parallel processes consume capacity, produce data inconsistency, and create the shadow systems that undermine the value hypothesis from beneath.
The fourth is data integrity and trust architecture. AI outputs are only as trustworthy as the data they are generated from, and employees know this. When the data quality architecture has not been addressed before deployment, employees develop accurate but operationally destructive skepticism toward AI outputs. They cannot tell which outputs to trust and which to question, so they apply blanket skepticism to all of them. The governance failure is that this skepticism is rational given the data environment, and no amount of change communications will resolve it.
The fifth is behavioral reinforcement and nudge design. This domain addresses the structural design of the work environment to make AI-assisted behavior easier than non-AI-assisted behavior. When the AI-assisted path requires more steps, more documentation, or more time than the existing path, employees take the existing path. Not because they are resistant. Because they are rational. Behavioral reinforcement design ensures that the architecture supports the behavior the program needs, rather than requiring employees to sustain effort against the grain of their environment.
The sixth is decision quality instrumentation. This is the measurement architecture that determines whether AI is actually improving the quality of decisions, not just the speed. Programs that measure adoption and login frequency are not measuring decision quality. Decision quality instrumentation tracks the outcomes of AI-assisted decisions against baseline, identifies the decision types where AI is adding value and those where it is not, and produces the governance signal that tells the program whether the value hypothesis is on track before the financial results make it visible.
The seventh is operational sustainment architecture. This domain addresses the structural conditions that prevent integration gains from regressing once the program's formal deployment activity is complete. Without sustainment architecture, the gains achieved in the first six months post go-live erode as program resources redirect to the next initiative, manager attention shifts, and the informal behavioral environment gradually reverts toward pre-deployment patterns.
Where Orien Found the Gap
At Orien, the AI-augmented underwriting workflow in Wave 1 was technically sound at go-live. The model accuracy was within spec. System stability was not an issue. What the program had not done was redesign the underwriting decision topology.
The existing underwriting process had six review checkpoints. The AI-assisted process was designed to reduce that to three. But the topology redesign had not been completed before go-live. The six checkpoints remained active. The AI outputs were inserted as an additional input at checkpoint two. The result was that underwriters were doing more work than before deployment, not less, because they were maintaining the original six-checkpoint process and additionally interpreting AI recommendations at checkpoint two.
Decision latency increased 11% in the first eight weeks. The program's value hypothesis assumed a 23% reduction in cycle time. The gap between those two numbers was entirely attributable to the topology redesign that had been deferred.
The remediation required AIP-1 workflow topology redesign to be completed under live program conditions, which is significantly more complex and disruptive than completing it before go-live. The duplicate checkpoints were identified, the authority boundaries were clarified, and the decommissioning sequence was executed over a six-week period. Cycle time dropped 14% within 60 days of the redesigned topology going live.
The lesson is not that topology redesign is complicated. It is that deferring it is more complicated.
The Three Questions AI in Practice Answers
The AI in Practice pillar is the structural discipline that answers three questions every AI transformation needs to be able to answer before go-live.
Has the decision topology been redesigned so that AI is embedded in the workflow rather than overlaid on it? Not described in the design documents. Actually redesigned, with the old topology decommissioned or on a defined decommissioning timeline.
Have the authority boundaries at every AI intervention point been defined explicitly, so that every employee who works in that decision environment knows exactly when to rely on AI outputs, when to question them, when to override, and how to document each of these?
Is there a behavioral signal architecture in place that will detect topology regression, parallel process re-emergence, and override pattern divergence in the first 90 days post go-live?
If the answer to any of these is no, the program has an AI in Practice gap. The technology may be performing. The workflow is not.
Why This Step Gets Skipped
Workflow topology redesign requires authority that most AI program teams do not have. It requires decisions about which existing processes will be decommissioned, which checkpoints will be eliminated, and which roles will have their decision authority restructured. Those are organizational decisions, not technology decisions. They require executive sponsorship, cross-functional governance authority, and a willingness to make structural changes that create short-term disruption in exchange for long-term performance gains.
Programs that are scoped as technology deployments do not have that authority. Programs that are scoped as transformation programs do. The difference in scope is the difference between a program that deploys AI and a program that realizes AI value.
That scoping decision happens in Phase 0, before the program architecture is set. It cannot be retrofitted at month four when the adoption data comes back, and the topology problem becomes visible.
Has your AI program formally decommissioned any existing process, checkpoint, or workflow step since deployment, or are the pre-deployment processes still running alongside the AI-assisted ones?
If nothing has been decommissioned, you have parallel processes. Parallel processes are not a transition phase. They are the structural condition that prevents the value hypothesis from being realized.
The Deloitte State of AI in the Enterprise 2026 has a section on workflow integration that is worth reading alongside this edition. The finding that stands out is the gap between organizations that report AI deployment and organizations that report AI integration. Deployment means the technology is live. Integration means the workflow has been redesigned to absorb it. Deloitte puts those two populations at very different points on the value realization curve, and the distance between them maps almost exactly to the AI in Practice domains that the higher-performing organizations have in place and the lower-performing ones do not.
Find it at deloitte.com.
Edition 8 on July 2 brings the final piece of the framework arc: The Performance Integration Model. The previous three editions have covered the structural conditions that determine whether humans are ready, whether workflows are redesigned, and whether the program has the authority to make those changes. The next edition covers how you know whether any of it is working: Continuous Performance Integration as a governance operating system, the four cadence levels, and the signal architecture that connects every domain in the framework to a governed outcome.
Subscribe to aichangeloop.com if someone forwarded this to you.
AI Change Intelligence
Published: Wednesday, June 18, 2026
By Raheel Malik, AI Change Architect™ aichangeloop.com