The industry has produced a standard picture of what a company needs to do AI properly. Sixteen components, layered like a stack. It is on every consulting deck and every vendor slide.
We took it apart against real work — reading incoming referrals, processing invoices, investigating short payments, recommending next steps for a complex patient.
What we found: almost all of it is work your organization already does, under an unfamiliar name. One thing is genuinely missing, and it is not a technology.
What this is about, and what it is not
This is about process automation — the routine, high-volume work moving through your business every day. Documents arriving, data read, a decision made, a system updated. Referrals, invoices, claims, orders, applications. It is the largest AI opportunity in most companies, and the one where the standard architecture is most oversold.
Three other kinds of AI work are different, and this does not apply to them.
Analytics and decision support. Forecasting, planning, answering questions about your own numbers. Here the constraint is your data, not the AI — and fragmented, inconsistently defined data will not become intelligible because a model was pointed at it. That does require investment, and it is the one place an overhaul may be exactly right.
Engineering. AI is reshaping how software gets built. Different tools, different economics.
Research and model building. A department building models on your own data — clinical risk, pricing, demand — is doing specialist work with real infrastructure behind it.
The failure is applying one picture to all four, so a company running a single predictive model inherits the requirements of a company that builds models for a living, then applies them to invoice processing. Different workloads need different roads—not one architecture built for the hardest journey.
The picture was drawn for a different company
The companies publishing these architectures build and operate their own models. Their diagram reflects their problem: computing capacity, training pipelines, model versioning. Your company almost certainly buys AI as a service, the way you buy email or storage.
Applying their diagram to your business is like planning a distribution centre because you bought a delivery van. Both involve logistics. Only one needs the warehouse.
The usual complaint about industry content is that it underestimates how complicated large enterprises are. Here it is the reverse. The real problem is simpler than the picture suggests, and organisations take on the complexity anyway — because that is what the picture showed.
Most of it, you already have
Securing access to a model is a configuration task for the team that secures everything else. Tracking the instructions given to a model is what your software teams do with every other piece of code. Checking that an invoice total adds up is validation you would want whether a machine or a person entered it. Some of it you have bought twice — the search technology sold as essential AI infrastructure is now a standard database feature.
This matters commercially. Each of these has an owner, a skillset and a budget line today. Presented as sixteen new components, it reads as a new function needing new people. Presented accurately, it is existing teams doing familiar work.
And most of it will arrive without you buying it
The majority of AI in your company will not be built by your teams. It will appear inside software you already licensed — a feature in a release, a setting switched on by default. No one requested it, no review was triggered. It is simply there, in the hands of staff who act on what it suggests.
You cannot govern that with internal tooling, because it is not yours. You govern it by changing what you require of any system, from anyone, before it is trusted with real work.
What is actually missing
Your organization knows how to test software: the same input should produce the same result every time.
These systems do not work that way. They are right most of the time and wrong some of the time, and the proportion shifts quietly — when incoming documents change, or a supplier updates their model without telling you. A system can pass every check your company performs today and still be wrong far more often than anyone realises.
Nobody owns the question of whether it is good enough. Not testing, which checks consistency. Not the delivery team, which will not set a bar for itself. Not procurement, which does not know to ask. Not your risk function, built for a different kind of model.
That is the gap — not a missing tool, a missing accountability. Closing it needs a few hundred examples where you already know the right answer, and someone senior enough to say a number is not good enough yet.
The technology is cheap and the judgement is not. Companies buy a system for measuring AI quality, then discover they have nothing to measure it against.
The line that matters, and the question that finds it
Inside every one of these systems is a threshold — the point above which the machine’s work is accepted without a person checking it.
Raising it is how the savings are earned; reviewing everything costs what the manual process cost. It is also the moment the system stops assisting your staff and starts acting on its own.
That is a decision about risk. It should be made deliberately, by someone accountable, with evidence in front of them. Today it is usually a setting an engineer adjusts to improve throughput. Nothing announces that the human check was removed.
So ask whoever runs this for you: how much of our AI now runs without a person confirming it, and who signed off on that number?
A percentage with a name attached means the discipline is working. “I would have to check” means the line moved on its own.
What this means for what you fund
Fund the accountability, not the architecture.
Some cloud configuration. One place where quality across every AI system is visible. Expert time to build the examples that define what “correct” means in your business. And a rule that nothing reaches production, built or bought, without a published accuracy number and a named owner for the threshold.
What can wait: the specialist tooling and a team to build it. That earns its place once many systems are running and the shared burden is real. Standing it up first produces a capability nobody asked for — while the AI that actually matters arrives quietly inside software you already own.
The bottom line: The vocabulary made familiar work look like new infrastructure, and new infrastructure looks like it needs a new team. Strip the vocabulary and what is left is a standard, a gate, and someone accountable for saying no.
If You Want the Detail
This piece is the short version. The full teardown walks all sixteen components against real work.
- The Enterprise AI Platform: What’s Left When You Unpack It — the method, the scorecard, and what survives
- What the Model Call Actually Reduces To — gateways, prompts, output structure, guardrails
- The Quality Bar Nobody Owns — evaluation, measurement, and the one thing genuinely missing
- The Layers You Already Have, or Never Needed — vector stores, agents, and the MLOps stack
- Governance Is a Form, Not a Platform — the seven artefacts, and the software you did not buy
Tech Canvas 