The consulting model was designed for a specific kind of problem: organizations that lack a specific capability, need to acquire it, and want to move on once they have it.
Implementation of ERP systems. Process redesign. Compliance audits. These problems have a defined end state. When the ERP is configured, the process is redesigned, the audit is complete, the work is done. The consulting team transfers knowledge to the internal team and leaves. The client owns the capability and runs it independently.
AI implementation is a different kind of problem. Understanding why requires understanding what AI systems actually depend on for continued effectiveness.
What makes AI systems work long-term
An AI system in a production environment depends on:
Current business context. The decisions an AI system should support change as the business changes. New products, new markets, new regulations, new competitive dynamics. Each shifts what the system should optimize for and what outputs are useful. A system that was correctly tuned twelve months ago may be producing outputs that were right then but are subtly wrong now.
Quality feedback from real usage. The most valuable information about an AI system's performance comes from watching how real users interact with it: where they override the output, where they trust it without review, where they stop using it entirely. This feedback is only available if someone is there to observe it. A team that was there for implementation and left at deployment doesn't have this information.
Relationship with the people who use it. The judgment calls that determine whether an AI system is working, is this output good enough to act on, is this edge case being handled correctly, is this alert signal or noise, require understanding the people making those calls, the context they're operating in, and the consequences of getting it wrong.
This understanding takes months of embedded presence to develop. It cannot be transferred through documentation or training sessions. It lives in the relationship between a person and an organization.
What the consulting model optimizes for
Consulting firms optimize for deliverables. A deliverable is something that can be scoped, priced, produced, and handed over. A working AI system is a deliverable. The documentation of how it works is a deliverable. The training sessions that teach internal teams to maintain it are deliverables.
The problem is that "the system works" is not the same as "the system is working well for your specific business context in six months." The second outcome requires continued presence. Continued presence is hard to scope and price as a deliverable. So consulting firms scope and price what they can deliver clearly: the system at deployment.
This isn't dishonesty. It's structural. The consulting model is built for discrete deliverables, not for ongoing presence. Organizations that understand this can use consulting firms effectively for the right problems. AI implementation is frequently not the right problem.
What embedding actually requires
Embedding with an organization isn't just being on-site. It's:
Being in the actual workflow. Not the meetings where the workflow is presented, the actual workflow. The 7am calls. The situations where something goes wrong and people improvise. The decisions that get made based on information that was never in any requirements document.
Learning the trust calibration. Every organization has a different sense of how much to trust new information systems. Some teams check every AI recommendation against their own judgment before acting. Some teams pass AI output downstream without review. Neither is inherently right. The embedded leader needs to understand the organization's actual trust calibration and design the system accordingly.
Being present when the system fails. Every system fails at some point. The response to failure, how quickly it's caught, how it's communicated, what's done about it, is more important than the failure itself. An embedded leader who sees the failure, quantifies it, and presents it transparently changes the client relationship in ways that no amount of positive delivery can achieve.
Staying after success. The most valuable period of any AI engagement is the 90 days after deployment. This is when real usage patterns emerge, when edge cases that didn't exist in test data appear, when the business starts making decisions based on AI output and the quality of those decisions becomes visible. Leaving at deployment means missing the period when the system either proves or fails to prove its value.
The cost of departure
When an embedded team leaves at deployment, the costs aren't immediately visible. The system runs. Outputs are produced. Usage continues.
The costs accumulate over months:
- The system slowly drifts from business reality as the context changes and nobody updates it
- Edge cases accumulate unaddressed because the internal team doesn't know the system well enough to diagnose the source
- Trust in the system erodes as inconsistencies appear without explanation
- The internal team builds workarounds rather than fixes because the people who could fix it are gone
- Twelve months later, the system is technically still running and practically no longer trusted
At this point, the organization is often looking for a new vendor. The new vendor's sales pitch: "your last implementation failed because they didn't do it right."
The cycle continues.
When consulting works and when it doesn't
Consulting works when the deliverable is the outcome. Building a database schema. Auditing a security posture. Writing a policy document. These have defined end states that don't require ongoing presence to remain valuable.
Consulting doesn't work when ongoing context is the outcome. An AI system that needs to continue making good recommendations as business context changes. A data pipeline that needs to produce reliable output as source systems evolve. An intelligence platform that needs to surface relevant signals as the threat landscape shifts.
The test: if the value of the engagement degrades without continued involvement, it's an embedding problem, not a consulting problem.
PurviewX embeds with organizations and stays through production. Start a conversation.