Data & AI
Most AI programs don't stall on the model. They stall on the estate underneath.
Proofs of concept work. Production doesn't. The gap is rarely the AI layer.
Every enterprise we walk into has an AI pilot that worked. A summarizer that impressed the executive team, a copilot that handled a support queue for two weeks, a forecasting model that beat the spreadsheet. Almost none of them are in production a year later, and the reason is almost never the model.
The reason is the estate. The data the pilot ran on was hand-assembled for the pilot. The application it needed to write back into is a decade-old system with no API. The platform it would run on has no identity boundary a security team will sign off on. None of that shows up in a proof of concept, because a proof of concept is allowed to cheat.
The pilot that never ships
A pilot proves feasibility under conditions you control. Production asks a different question: can this run every day, on live data, inside a system that is audited, with someone accountable when it is wrong? That question is answered by the estate, not the model.
The pattern is consistent. A team spends eight weeks building something genuinely useful, then spends eighteen months failing to ship it, because shipping it means touching four systems nobody owns end to end. The program does not fail loudly. It gets renewed, rescoped, and quietly parked.
The model was never the constraint. The constraint was that nothing underneath it was ready to be depended on.
What "AI-ready" actually means
"AI-ready" has become a slide title, which is a shame, because it has a concrete definition. An estate is ready when a new workload can get trustworthy data, through a governed interface, on a platform with real boundaries, and can be changed without a freeze window. That is it. Four conditions, all of them unglamorous, none of them about AI.
Read them in reverse and they describe the work we have been doing inside regulated estates since 2006: modernization, consolidation, and operations. The AI wave did not create new engineering problems. It made the existing ones expensive to keep ignoring.
Four things we check first
Before scoping any AI program, we run a short diagnostic on the estate beneath it. Four questions, answered with evidence rather than opinion.
- Where does the truth live? If three systems each hold a version of the customer record and none is authoritative, every model output is contestable, and a contested output is an unused output.
- Can the workload reach it without a human? Extracts, overnight jobs, and manual reconciliations are fine for a pilot and fatal in production. We look for an interface with an owner and a contract.
- What happens when it is wrong? Regulated estates need lineage, retention, and an audit trail before a model touches a decision, not after the first incident.
- Can the surrounding application change? If the app that consumes the output can only be released twice a year behind a freeze, the model's cadence is irrelevant.
The uncomfortable finding
In most engagements, three of the four answers point at the same two or three systems. That is good news: it means the estate work is bounded, and it can be sequenced ahead of the AI work rather than instead of it.
Start with the estate
Find out whether it is the model or the foundation.
We look at the estate beneath your AI program: where the truth lives, what can be reached, and what has to move first.
Start a conversation →Sequencing beats scoping
The instinct when a program stalls is to rescope the AI. The better move is to sequence the estate work in front of it, in slices small enough to ship while the business keeps running.
In practice that means the boring patterns: strangler-fig replacement of the system of record so nothing is rewritten wholesale, feature flags and shadow traffic so the new path is proven under real load, a landing zone that carries the compliance posture from day one, and a data platform with lineage before it has dashboards.
- Modernize the one system the workload depends on, not the portfolio.
- Consolidate the duplicate sources of truth before adding a consumer of them.
- Operate what you ship, so the second workload is cheaper than the first.
Done this way, the estate keeps earning while the work happens, and the AI program stops being a bet on a demo.
Where this leaves you
If you have a pilot that worked and a production date that keeps moving, the diagnosis is usually two systems away from the model. That is a solvable problem, and it is the work we do: modernization and consolidation inside live, mission-critical estates, where failure is not an option.
If it is useful, we will look at your estate and tell you honestly whether the AI program is a modeling problem or a foundation problem. Start a conversation, or read how we sequence this work.
Co-founder of Assembly and CTO. Chris owns Assembly's technical direction, the engineering practices that show up in every engagement, and the architectural standards that govern Assembly's delivery work. He also owns the long-arc decisions that shape how Assembly engagements are structured and delivered. Two decades of hands-on engineering across cloud, applications, and integration at scale.
Chris on LinkedIn →