AI Didn't Get Rolled Out. It Seeped In (And That's the Problem)
- Chris Terrell
- May 8
- 4 min read
There's a difference between a rollout and a seep.
A rollout has a project plan. There's a kickoff meeting. Someone owns the implementation. People get trained. There's a go-live date, and then there's a post-mortem where everyone agrees it went better than expected while privately knowing it didn't.
AI didn't do any of that. It just showed up.
It's in your search engine. It's drafting your teammates' emails without anyone announcing it. It's sitting inside the SaaS platforms you already paid for, quietly offering to summarize your meetings and rewrite your subject lines. Nobody held a steering committee meeting and decided to roll it out. It seeped in while you were handling something else.
That's what makes this adoption moment genuinely strange — and why the usual change management playbook doesn't quite fit.
The Three-Gate Question
A change management researcher at Prosci named Tim Creasey has been noodling on this, and his framing is surprisingly useful. He built a simple game around a question that sounds obvious until you actually try to answer it:
Should this task be done by a human alone, by a human with AI assistance, or by AI alone?
That's it. Three gates. You take a scenario — a client deliverable, a data task, a communication — and you decide which bucket it belongs in.
Simple in theory. Genuinely hard in practice.
Because here's the thing: most people walk into AI with the assumption that the technology should do everything. We've seen this pattern before. It's the same instinct that produces monday.com boards where every column is automated, every status is supposed to update itself, and nobody has agreed on what "done" actually means. The tool becomes the answer before anyone's asked the question.
The three-gate question forces the question first.
The Billing Problem Nobody Wants to Talk About
Here's a real conversation that happens in consulting engagements right now:
A client needs a custom API connection between two systems. Traditionally, that's a 10-hour job — digging through Stack Overflow, testing code you half-understand, debugging something you can't fully read, probably giving up once and starting over. With AI assistance, the same outcome takes an hour.
So. How many hours do you bill?
This isn't a hypothetical. It's happening to every consultant, developer, and knowledge worker whose output AI has turbocharged. The efficiency gain is real. The value delivered to the client is identical. But the nine hours of effort that used to be the proof of value? Gone.
The client got what they needed. The service provider compressed their timeline dramatically. And all that efficiency — all that newly created capacity — largely flowed to the client without anyone negotiating it.
If you're pricing on time, AI just made nine hours of your expertise uncollectible.
This isn't a complaint. It's a structural shift that anyone providing services needs to reckon with. Value-based pricing starts sounding less like consultant-speak and more like survival when you can do in an hour what used to take a day.
AI Is in Your SaaS Whether You Like It or Not
The adoption complexity isn't just individual. It's also organizational — and weirder.
Most tech rollouts have a sponsor. Somebody owns the license, controls the training, decides the implementation timeline. With AI, the platforms you're already paying for have started surfacing AI features inside tools your teams use every day. There was no announcement. There was no change order. It just appeared in the interface.
For operations leaders, this creates a new category of process debt that nobody budgeted for: the quiet accumulation of AI-assisted work happening outside any sanctioned process. Your team is using it. You probably don't know exactly how. And unlike a SaaS rollout where you can track logins and measure adoption, AI-assisted work is mostly invisible.
The frog-in-boiling-water version of this is that your processes are slowly changing — people are working faster, shortcuts are being taken, outputs look polished — but the underlying logic of how the work actually gets done hasn't been examined. When something breaks, you won't know if it broke because of AI or despite it.
Small Experiments, Not Big Bets
The honest answer — for individuals and organizations alike — is that nobody fully knows how this settles yet.
What we do know is that the pattern that works isn't the one we learned from traditional software rollouts. You don't architect an enterprise AI strategy, secure stakeholder buy-in across three business units, and launch in Q3. That's not how it's working.
What actually seems to work: small experiments in low-stakes contexts, done by curious people with some psychological safety to screw up. The Google API script that would've taken 10 hours and probably got abandoned — that's a perfect AI experiment. Low stakes, contained, already annoying enough that you won't miss it if the AI gets it wrong.
You learn what the technology can actually do for your specific work. You build intuition for which gate a task belongs in. You make a mess in a place where the mess is recoverable.
The worst version of this is the opposite: assuming AI will replace entire job functions, cutting headcount based on productivity projections, and then discovering that the humans were doing more than the job description said — and that AI is doing less than the demo suggested.
That debt, when it comes due, is going to be expensive.
Process Debt is a podcast for operations leaders who've bought the software, done the rollout, and are still fielding complaints about why nobody fills out the status column. New episodes wherever you listen.



Comments