Three weeks into an AI pilot, the demo still looks good. The engineer is curating the inputs by hand, selecting clean records, reformatting dates, quietly discarding the rows that break things. Nobody mentions this. Then the pilot ends, the engineer moves on, and the organisation tries to run the same process at scale. It falls apart immediately.
This is not an AI problem. It’s a data problem. And it’s the most common reason I see AI projects stall in professional services and financial services firms.
The context problem
Anthropic’s enterprise teams have a name for this: the context problem. AI models, including the most capable ones available today, are only as useful as the information you give them. Feed them clean, structured, consistently labelled data and they perform well. Feed them what most firms actually have and they produce unreliable output, miss critical details, or confidently fabricate answers from gaps in the record.
The uncomfortable part is that the pilot almost never reveals this. Someone always manually prepares the data for a demo. The curation work is invisible, which means the dependency on it is invisible too.
The AI didn’t fail. You discovered that your data architecture was never built for machine consumption. Those are different problems with different solutions.
For a financial advisory firm, the architecture I encounter most often looks something like this: client contact details in the CRM, correspondence history in the email client, compliance notes in a shared drive, fee schedules in a spreadsheet, and meeting records in a separate system that nobody fully migrated from five years ago. A human adviser navigates this by memory and habit. An AI model can’t. It needs a complete, consistent record in a single reachable place, or it needs a pipeline that assembles that record reliably before any inference happens.
What fragmented data actually costs
The cost isn’t just failed AI projects. Fragmented data creates overhead long before AI enters the picture.
An operations lead at a mid-sized IFA told me recently that a new client review used to take her team forty-five minutes of preparation: pulling records from four systems, reconciling inconsistencies, checking that the compliance notes matched what the CRM said. Forty-five minutes, multiplied across every review, every week. Nobody had added this up because it had always been that way.
When we looked at what an AI-assisted review process would need, the answer was obvious: the forty-five-minute preparation problem had to be solved first. The AI couldn’t help until the records were consistent and accessible. Once the data architecture was fixed, the AI component took less than a day to configure. The preparation time dropped to around eight minutes.
That’s a Level 2 integration in the L1/L2/L3 framework I use with clients: a workflow connecting existing systems so that data flows to where it’s needed without manual assembly. Configuration work, not engineering. It took about a week. The AI layer, Level 1 (education), was already available in tools the firm was already paying for.
The bottleneck was never the AI.
A practical lens for diagnosing the real blockage
If you’re an operations lead trying to work out where to focus, three questions will tell you most of what you need to know.
Can you describe, precisely, where a given client record lives? Not approximately. Not “it’s in the CRM somewhere.” If the answer requires a conditional (“it depends on when they joined” or “the older ones are in a different folder”), you have a fragmentation problem.
When your team prepares for a client meeting or a compliance review, what do they do in the twenty minutes before it? The answer to this question is usually the clearest possible description of your data gap. Manual preparation steps are the exact tasks that a well-configured system would do automatically.
If you ran your most important client process entirely without your most experienced person, would it still produce the right output? Senior people compensate for architectural failures using institutional knowledge. When they leave, or when you try to scale, the compensation disappears and the failure surfaces.
If any of these questions produces an uncomfortable answer, that’s where to start. Not with the AI model.
Fix the flow before you evaluate the tool
I’m not arguing that AI tools aren’t worth your time. They are, and the capability gap between what was possible two years ago and what’s possible now is significant. But the firms I see getting real value from AI are not the ones who evaluated the most tools. They’re the ones who sorted out how their data moves before they tried to do anything clever with it.
This doesn’t have to be a large programme of work. In most cases the highest-value step is identifying the one or two manual data preparation tasks that happen most frequently, then designing a simple integration that handles them automatically. That’s a weeks-long project, not a transformation programme.
The model you need probably already exists. The data architecture to support it is the part that requires attention.