I worked with an enterprise client recently who came in with a straightforward(ish) AI brief. They wanted a way to handle faster analysis of tonnes of survey data. It’s established methodology, right? A large research dataset, AI could compress the time between survey close and client deliverable. The kind of thing that gets quoted in two conversations and built in a few weeks.
If I had built to that brief, we’d have solved the “now” problem perfectly. On time, on budget, and useless (for the future). And that’s what we’re looking at in this article - how to build projects for a moving future.
I’ve lost count of how many organisations I now see going from “we should do something with AI” to a five-figure development quote without anyone mapping the real-world data, the workflow, or the actual opportunity in between. They always fear getting started, so they rush to commission a dev build or pilot off some quick issue or side project sitting on their desk. It’s true about most things, the quote feels like progress, but it’s a bit of a leap of faith. They trigger the build and discover six months later that it did what they asked for instead of what they needed.
Neither outcome is a strategic or technological failure. Both are architecture failures. Architecture-before-build isn’t a new idea. It’s how serious engineering and consulting have always worked - but because of the speed of “proof of concept” these days, it’s getting left or compressed completely. That overhang is what these projects keep falling into.
The audit reframe
The assumption walking in was that “the data” was a survey and some interviews. The audit surfaced five distinct layers the team had never seen on the same page: quantitative assessment responses, qualitative interview transcripts, passive document signals from client materials, benchmark reference data accumulated across engagements, and the proprietary scoring rubric that lived in the heads of three senior researchers. Each layer needed different architectural treatment. And none of it was visible (or scorable) until that SME knowledge was in the room with you.
Every one of those five layers was a consultant’s call before it’s a developer’s responsibility. So, had this gone straight to a dev team, none of them would have surfaced any of these interconnected data connections! The team would have got a faster survey tool and walked right past the four other assets sitting on the table (each with commercial and research value).
Every team I work with has much more usable data than they think they have. I am not just talking about files, databases. I mean process knowledge, decision criteria, subject matter experts, brand guidelines, SOPs, SOWs, playbooks, client communications. Anything that captures how the business actually runs, thinks, decides, and operates. And beyond that how the clients, customers, lapsed leads and industry react to these influences. This is powerful interconnected stuff, and it’s where a solid AI project audit starts.
On this project, the more interesting move wasn’t the cataloguing. It was a reframe of what more they could get from the interviews. Once the layers were visible, “faster analysis of surveys” stopped being the right ambition. The real opportunity sat upstream: changing how the data got captured in the first place. Moving them from survey forms (‘capture gates’) to real-time and recurring conversational assessments, conducted across platforms the org was already using, with the methodology embedded behind the conversation rather than in front of it - this led to a much more contextually rich (more honest) data pool that gave the participant far better recommendations and the client better humanised context to work with.
All because we didn’t rush to a dev team first.
When fine-tuning is a commercial decision
This stage is what determines everything downstream. Where the sensitive data lives and who controls it? Does the AI learn from your data permanently, or reference it on demand? Which existing platforms does it need to sit inside? Who maintains it when there’s no dev or consultant in the room? What does the AI eval against, how do we validate the governance, and where does the human sit at each stage?
The single most consequential decision for this client was whether to bake the benchmark dataset into the model with a fine-tuning approach, or keep it as a retrievable reference layer. Fine-tuning meant retraining every time the benchmark updated (which would be driven by economic reactions). The reference approach meant new data was available the moment it landed - and changeable to suit the nuances of conversational interpretations.
This all sounds super technical, but it’s not. It’s also not a decision that should be made by the dev or IT team. There are considerations and cyber issues to align with, but it’s a commercial decision really - and what the client is willing to maintain over a five-year horizon. The technical answer flows from the commercial answer. Never the other way around.
Once the decision was framed in those terms, the leadership team got MORE engaged with it directly. And once they were engaged, something really interesting happened. They pulled the entire architecture stage in-house. Not because they could build it cheaper. But because of how their data was connected, and where the real intellectual property sat, handing architectural decisions to an external AI agency meant handing over ‘strategic control’ of their own methodology to someone else to wire it up.
Understanding what you own, what it’s worth, and where the build boundaries should sit, is the whole point of this AI architectural stage. (The same pattern shows up in other sectors. A design studio with an 11,000-piece textile archive came in wanting “AI-generated designs” and walked out understanding their archive was an unstructured intelligence asset that needed structuring before anything generative could sensibly be built on top of it. Different sector, identical lesson.)
The discipline the labs and consultancies are now hiring for
For a long time, this stage has been invisible because nobody knew what to call it - or branded it “IT’s problem”. Well this is not IT’s problem to solve. It’s a CTO and CAIO opportunity to get the pipeline and structure right to integrate what you want, not what someone thinks you need!
And recently big LLM players are thinking the same too: Anthropic, Google and OpenAI have each built what amounts to a consultancy inside their labs: a role they’re calling the Forward Deployed Engineer: embedded specialists who sit alongside customers, translate business problems into architecture, and connect AI capability to the operational reality of the organisation.
In May 2026, OpenAI and Anthropic each launched enterprise deployment ventures within days of each other: OpenAI raising around $4 billion for a vehicle built to buy in engineering and services firms, and Anthropic standing up a $1.5 billion services firm with Blackstone, Hellman & Friedman and Goldman Sachs, aimed explicitly at mid-sized companies. Google Cloud is hiring hundreds of FDEs, with Thomas Kurian framing it as scaling customer AI transformation. MarkTechPost’s breakdown covers it across all three.
The reason they’re all spending on ‘people’ rather than models is the same, and the investors backing them are saying the same thing. Blackstone’s Jon Gray, whose firm co-founded the Anthropic venture, described the shortage of skilled implementation partners as one of the biggest bottlenecks to enterprise AI adoption. The model was never the constraint. The gap between a capable model and a working system is the architecture stage.
Accenture stood up a dedicated FDE practice with Microsoft, on top of the $5.9 billion in generative-AI work it books and the 80,000 AI-focused hires it committed to, its pitch running from strategy and architecture through to implementation. Same function, different scale: a deployment company inside the lab, a practice inside the big firms, and independent consultants doing it one client at a time. It’s the same job, and it’s the one I do.
The detail that matters isn’t the job title. It’s what the labs themselves have realised: handing a customer an API and walking away doesn’t deliver flexible and robust ecosystems for nuanced work. Someone has to do the architecture. Someone has to translate tech and opportunity into operational infrastructure - and it’s now also built for what’s next, not what used to be true.
If the model providers and the consultancies are paying six-figure salaries for it, there’s something in that.
The skill in the boardroom
If you’re on this journey, don’t feel like you NEED to start with an IT or development consultancy. Find the problems worth solving, and map these to other areas of the business, and once you’re building this picture of how your data connects together, this is where the opportunities sit. This is where you map the R&D to capability expansion. There’s no need to take a leap of faith on a development quote straight away.
It’s really not a technology decision. It’s a commercial and vision one: what do you own, what’s it really worth, and what are you willing to hand to someone else to build with it. Make those calls first and the build is the easy part. Get them right and you’re not commissioning something that works today - you’re building for where your business is heading. That’s the difference between a tool you’ll replace and an asset you own.
