Most organizations that set out to “do something with AI” believe they have a technology problem. They run pilots, fill spreadsheets with use cases, and produce polished strategy decks, yet nothing reaches production. When the momentum stalls, the easy conclusion is that AI isn’t ready.
Luise Freese, developer, consultant, and author of the upcoming book, “From Prototypes to Production: A 90-Day Playbook for Shipping Enterprise AI”, thinks that diagnosis is almost always wrong. In part one of this two-part #shifthappens conversation with Dux Raymond Sy, she explains why the real gap isn’t whether AI works, but whether an organization can operate it.
AI Doesn’t Cover Your Problems. It Exposes Them
The instinct, Luise explains, is to treat AI as a shortcut around work that companies were told to do years ago. The intranet is a mess and nobody can find anything, so the plan is to slap a chatbot on top of it and let the bot go find the document.
It rarely works, and she’s blunt about why. This is a garbage-in, garbage-out problem, and AI doesn’t sugarcoat garbage — it surfaces it faster. Without a stable foundation, AI amplifies the problems already in the environment rather than hiding them. Good data quality, security, and governance may be boring, she admits, but data is what fuels AI. The most sophisticated model in the world is useless on top of data nobody trusts.
Running AI Is Not the Same as Proving AI
Luise mentions that a reliable path to production is the way to operationalize AI. Software that includes AI is still software. Software must be deployed, monitored, supported, and maintained – AI changes none of that.
For example, if deployment depends on one hero engineer running a script on their laptop, you’re already failing. If nothing monitors cost and impact, you’re already failing. And if governance is something you promise to sort out later with a slide deck when something goes wrong, that isn’t governance — it’s a nightmare waiting to happen. The order matters: Figure out the path to production first, then run the experiment.
To make the point, Luise compares the situation to a decathlon, the ten-event contest where winning depends on every discipline. In this case, new tools have lowered the barrier to exactly one event: writing the code. The other nine disciplines haven’t moved: requirements, edge cases, data modeling, testing, documentation, integration, lifecycle management, and accountability. If you only make the code easier without addressing the other disciplines, AI simply helps you fail faster.
The Model is the Last One Percent
There’s a temptation to obsess over which model is most capable — a fascinating question for LinkedIn tech influencers and a largely irrelevant one for real enterprise AI, Luise posits. Accentuating her point, she describes a customer running seven separate CRMs that don’t talk to each other. Every Monday, a script runs for three hours to sync them, and no one can work all morning. Would a newer, cleverer model fix that? Of course not. The problem isn’t intelligence; it’s foundation. Once that foundation is real, choosing a model is maybe the last one or two percent of the work.
Why the Prison Forms
A good proof of concept can prove the possibility, but it can’t prove survivability: whether AI can run inside a real organization, with real data and real workflows. That’s the distinction most teams miss when they treat the proof of concept as the finish line instead of the starting point. What survives often isn’t the best idea but the one that accidentally found ownership and usage, because the best ideas usually require the most integration work and quietly die for lack of it.
The warning signs show up early. The strongest signal, Luise says, is when everyone can describe what the demo does, but nobody can describe the operating model behind it. Who owns it? Which budget sustains it over time? What data feeds it? How is it monitored? What happens when it fails? If those questions trigger a round of "we’ll figure that out later," the team is already drifting toward the prison.
What It Takes to Escape the Proof-of-Concept Prison
Luise’s advice for breaking the cycle isn’t about better demos. It’s about building the operating discipline that lets a good idea survive contact with the real organization.
Anchor AI Use Cases in Real Operations
Begin with the workflows people use every day and look for the specific points where AI can support a decision or carry out a step – then design within those constraints. That discipline filters out the automation-in-disguise ideas and keeps teams focused on the one or two cases where a model genuinely changes the outcome. This way, AI earns its place in the workflow as opposed to being handed the workflow based on blind faith.
Define Ownership Before You Build
Another failure point is when the model works but no one can say who owns the data, the prototype, or the outcome. Naming a clear owner, a sustaining budget, and success criteria before a line of code is written is what closes that gap and answers the questions that usually get deferred: Who maintains it after the excitement fades, and who funds it after the pilot?
Strengthen Data Before Scaling AI
Before scaling anything, Luise argues for getting honest about data quality, ownership, and accessibility, then putting governance in place so results stay consistent as more people and workflows depend on them. It may feel like a detour from the AI project, but it’s the part that decides whether the AI project survives at all.
Treat Early Experiments as a Foundation
A pilot’s job isn’t to prove AI works; that’s settled. Its job is to reveal what production will demand under real conditions – such as what needs to be integrated and monitored, as well as where it breaks. The goal is to apply and incorporate these lessons to the next AI initiative.
Evaluate Progress by What Can Move Forward
Most organizations measure momentum by activity, such as the number of pilots running. Luise pushes leaders to measure something harder: how many initiatives can make the transition into production. That lens exposes which projects have owners, funding, and a real operating model, and which ones are quietly stalled. This way, additional resources can be allocated to the former, rather than the latter.
Soundtrack of Shift
Luise chose Bob Dylan’s “The Times They Are a-Changin’.” To her it isn’t a song about comfortable, neatly planned change. It’s about the moment the old order can no longer pretend things will stay the same — which is precisely where enterprise AI catches so many organizations still managing new technology with old structures, governance habits, and success metrics.
Experimentation isn’t the problem. Experimentation without a path to production is. Leaders should stop asking how many AI initiatives they have and start asking how many can survive contact with real workflows, real data, real users, and real accountability. That’s the number that matters.
Be on the lookout for part two of our podcast with Luise and Dux, as they tackle the harder AI governance questions — agents, delegated authority, and why shipping AI safely takes more than an intelligent model.
Episode Resources
#shifthappens Research: 2026 State of AI
#shifthappens Insights:
- PoCs Aren’t the Problem: Why AI Never Reaches Production
- The Illusion of Progress: Why “Doing AI” Rarely Means Deploying It
- Past the AI Demo: Production-Ready Before Cleverness
- Prototype to Production: Who Owns AI Agents When They Break?
#shifthappens Podcasts:
- AI Is a Tool, Not a Search Engine
- AI Readiness Starts Before AI: Identity, Endpoints, and Security First
- Turning Hype Into Habit: Making AI Adoption Stick
Dux Raymond Sy on LinkedIn
Luise Freese on LinkedIn
From Prototypes to Production: A 90-Day Playbook for Shipping Enterprise AI
