What happens after the AI deployment team flies home
Let me tell you about a conversation I keep having.
It usually starts about six weeks after “go-live.” A COO or CIO - sometimes someone I’ve known for years, sometimes a stranger who found my last article, reaches out. The tone is always the same: not panic, exactly. Something closer to quiet embarrassment.
The story is always some version of this. The company brought in a serious implementation team. Good engineers. The kind of embedded, build-it-in-production engagement I wrote about last time - the model that Anthropic, OpenAI, AWS and Microsoft have now collectively put close to US$10 billion behind. The pod arrived, mapped the workflow, connected the data, shipped something genuinely impressive, ran the handover workshop, left the runbooks, and flew home.
And for a few weeks, it worked beautifully.
Then week seven arrived. The model provider shipped an update and the agent’s behaviour shifted subtly, but enough that the operations team stopped trusting it. The workflow owner who’d been trained resigned for a better offer (in this market, of course she did). A new regulatory circular landed and nobody was sure whether the system’s data handling still complied. Usage, which had peaked in week three, was now quietly sliding back toward the old way of doing things.
Nothing was broken. Everything was decaying.
I’ve started calling this day 46 - a nod to the 45-day deployment sprints that have become the industry’s standard rhythm. It’s the day the engagement ends and the ownership question begins. And after two decades of transformation work, and the last several years deep in AI implementation across this region, I’ve come to believe something that sounds obvious but changes everything once you act on it:
Deployment is an event. Transformation is a capability. And almost every AI contract being signed today pays for the first while assuming the second.
Why good deployments decay
Here’s what I’ve observed, again and again, across industries and markets. Five things start eroding the moment the deployment team leaves, not because anyone did bad work, but because nobody was assigned to own them.
Model currency. Frontier models now change monthly, sometimes weekly. A system tuned in March behaves differently in June. Traditional software waited for you to upgrade; AI upgrades underneath you, whether you’re ready or not. Someone has to be re-evaluating, re-testing, re-tuning - continuously.
Regulatory alignment. Especially here in Asia. Between MAS guidance in Singapore, PDPA obligations, Indonesia’s data-protection regime, and sector rules evolving in every market we operate in, compliance is not a checkbox at go-live. It’s a moving target. A system that was compliant on day 1 is only probably compliant on day 100.
Adoption. This is the silent killer. Usage always peaks during the engagement - the pod is there, the energy is high, leadership is watching. Then attention moves on, and humans do what humans do: drift back to the familiar. Adoption doesn’t fail loudly. It just fades.
Workflow fit. The pod redesigned the workflow as it existed in Q2. But businesses move. A new product launches, a team restructures, a supplier changes and the beautifully built system now sits slightly askew from how work actually happens. Small misalignments compound into abandonment.
Internal skills. The runbook is not the capability. I’ve watched organisations receive genuinely excellent documentation and still flounder, because reading about a system and being able to evolve it are entirely different things. And skills walk out the door - attrition doesn’t check whether someone was your designated AI owner first.
Notice what all five have in common: none of them are engineering failures. They are ownership failures. And they are entirely predictable which means they are entirely designable-for.
The Day 46 Checklist
So here is what I now tell every leader before they sign any AI implementation contract with a global deployment company, a hyper-scaler pod, a Big Four firm, or with us. Ask these five questions. Put the answers in writing. Make them part of the contract, not the conversation.
1. Who re-validates the system when the model changes and how will we know it happened? If the answer involves hoping the vendor’s release notes are thorough, you don’t have an answer. You need a named owner and a standing evaluation process.
2. Which of our people can modify this system without calling anyone and how many of them are there? One trained person is not capability; it’s a single point of failure with a LinkedIn profile. If the number isn’t at least three, your transformation has a resignation-letter-sized hole in it.
3. What is our adoption number today, and who reports it monthly to whom? Not “do people like it” - an actual metric, on an actual dashboard, with an actual name beside it. What gets measured after go-live is what survives after go-live.
4. When regulation changes, whose job is it to re-assess this system within what timeframe? “Legal will look at it” is not a process. In a multi-jurisdiction region like ours, this needs to be someone’s explicit, recurring responsibility.
5. What does month 12 look like and is anyone accountable for getting us there? A deployment without a growth path is a monument. The first workflow should be the cheapest one you ever deploy, because everything you learned should compound into the second and third. If nobody owns that compounding, it won’t happen.
Five questions. If you can answer all five with names, numbers and dates - genuinely, you’re in rare company, and whatever partner you’ve chosen, keep them. If you can’t, no engineering excellence on days 1 through 45 will save you from days 46 through 460.
The mindset shift underneath the checklist
I’ll be honest about the deeper point, because this is where my conviction actually lives.
The global FDE wave and I said this last time, I welcome it sincerely - has correctly diagnosed that AI value is created inside businesses, not in model APIs. But it has inherited an old assumption from the consulting industry it’s disrupting: that transformation is something done to an organisation by experts who then leave.
Twenty years of transformation work has taught me the opposite. Lasting change is something an organisation learns to do to itself. The best engagement is one structured to make the external partner progressively unnecessary where every sprint deliberately transfers not just a system, but the judgment to run it, question it, and extend it.
That’s why at MASSIVUE we’ve always paired implementation with structured capability building, and why our engagements are designed around a simple test I’d encourage you to apply to any partner, ourselves included: are they building your independence, or their indispensability?
The ten-billion-dollar deployment wave will land some remarkable systems across Asia in the next eighteen months. Whether those systems are still creating value in 2028 will be decided not by the brilliance of the pods that built them but by what was put in place for day 46.
Ask the five questions. Before you sign.
Sandeep Joshi is the Founder and Managing Director of MASSIVUE, a Singapore-headquartered AI transformation and capability-building firm serving enterprises across APAC. If you’d like the Day 46 Checklist as a one-page board reference, or a 30-minute Day-46 Diagnostic conversation about a system you’ve already deployed, reach out directly or via massivue.com.
Previously in this series: “The Last Mile Belongs to the Local” - on the US$10 billion FDE wave and what it means for Asia’s enterprises.
Thanks for reading Sandeep's Substack! Subscribe for free to receive new posts and support my work.