Most AI platform discussions begin with a sixteen-component stack: gateways, prompt registries, vector databases, agent runtimes, evaluation platforms. A more practical approach is to take each component apart against real enterprise work and ask what it actually reduces to. Do that, and one turns out to be genuine infrastructure. Most of the rest is work the enterprise already does under an unfamiliar name.
The Method
In my earlier article, Enterprise AI Architecture: What’s New and What Isn’t, I argued that most enterprise architecture already exists and AI introduces a relatively small set of new capabilities.
This article tests that claim component by component. Each one is pushed down to the level of what somebody actually types, configures, or signs.
One test applies to every component: would the second use case otherwise rebuild it? If not, it is not a platform component.
A secondary test catches a great deal. If a capability behaves the same regardless of which hosting channel or programming language you use, it is not yours. It comes from the model, and no platform layer is providing it.
Five use cases, chosen for different data classes, output shapes, and consequences of being wrong.
| Use case | Shape | Where the output goes |
|---|---|---|
| Referral intake | Document to structured fields | Internal system, confirmed by staff |
| Invoice intake | Email attachment to an ERP write | Financial system |
| Payment variance | Structured lookups to ranked reasons | Staff decision |
| Policy Q&A | Retrieval to a prose answer | Staff, advisory only |
| Care task recommendation | Patient context to a suggested task list | Clinician |
A capability list is not an architecture. It becomes one only when each item resolves to a decision, an owner, and a cost.
The Scorecard, in Four Groups
The sixteen do not fail in sixteen different ways. They fail in four, and each group is examined in its own article.
Group one — the model call. Everything surrounding a single request to the model.
| Component | What it actually is |
|---|---|
| Model access / gateway | Real — cloud configuration, owned by cloud engineering |
| Prompt management | Source control, plus one build check |
| Structured output | One request parameter and a schema file |
| Guardrails | Four unrelated things: one config, one validator, one written rule |
A Terraform module, a folder in source control, one parameter, and a page of rules.
Group two — the quality bar. How you know the output is any good.
| Component | What it actually is |
|---|---|
| Evaluation | Real requirement — a few hundred lines, expensive in expert time |
| Observability | Existing logs, one naming convention, one join |
| Golden datasets | Existing records plus two days of labelling |
| Human review | An application screen — but see what it produces |
The only genuine gap in the sixteen, and the only place a new shared component survives.
Group three — already yours, or never yours. Layers that are features of software you run, or infrastructure for a problem you do not have.
| Component | What it actually is |
|---|---|
| Retrieval / vector store | A feature of the database you already run |
| Tool and context layer | Integration work, owned by the integration team |
| Agent orchestration | A function for single-domain work; real for cross-system automation |
| Model registry | Real only if you train models |
| Feature store | Real only if you train models |
| GPU infrastructure | Real only if you host models |
Six layers, none of which needs procuring.
Group four — the gate and the buy side. What you require of anything before it reaches production, built or bought.
| Component | What it actually is |
|---|---|
| Cost management | Existing cloud tooling, one metric definition |
| Governance and risk | Seven artefacts, three tiers, forums you already run |
Most of your AI portfolio will arrive inside software you bought, where none of groups one to three reaches.
One infrastructure item across sixteen components. It is Terraform, and cloud engineering already owns that skill.
The Same Picture, Twice
Read the right panel by who owns each band. Cloud engineering owns the configuration. The application team owns validators, routing, and the review screen. Architecture review owns the gate.
Nothing moved to a new team. One thing moved to a new table.
What Actually Survives
One shared component: a place where measurement lands.
The review screen belongs to each application. What every capability produces is the same — a stream of records saying a person looked at this output and accepted it, corrected this field, or rejected it for this reason.
Collect that centrally and the enterprise can answer three questions it currently cannot. Is our AI getting better or worse? What share of it now runs without a person confirming? Which capability is drifting toward a threshold nobody agreed to move?
In most enterprises this is a table in the data platform, not a service. And it carries the fact of a correction, not its content — values stay in the application, which keeps the shared tier low-classification and cheap to approve.
Two schemas feed it. An evaluation report, published before release. A review record, continuous after it. Both are language-agnostic by design, because a team working inside a purchased product can produce them from an export.
Beyond that: four build checks, one reference implementation per stack, and one number captured before go-live — the manual baseline you cannot reconstruct later.
That is the platform.
The One Thing Nobody Owns
Traditional testing asks whether the same input produces the same output. These systems are not built that way. A system can pass every test your organisation runs today and still be wrong a third of the time.
Nobody currently owns the question of whether it is good enough. Not QA, which tests determinism. Not the delivery team, which will not impose a gate on itself. Not procurement, which does not know to ask. Not the model risk function, which was built for statistical models and has no view on generated text.
The platform is not a stack. It is a table, two schemas, and a gate.
That is the finding. Not a missing tool — a missing accountability.
Where the Diagrams Come From
The transmission is worth naming, because each step is rational and the output is not.
AI labs and infrastructure vendors publish architectures reflecting their own problem: training, serving, and scaling models. Tool vendors extend the diagram, because every layer is a product. Consultancies package it as a reference architecture. Enterprise architects inherit a stack built for model builders.
The usual critique of vendor content is that it underestimates enterprise complexity. Here it is the reverse. An enterprise consuming a managed model has a simpler problem than the diagram implies, and adopts the complexity anyway — because that is what the diagram showed.
Bloat from imported sophistication, not from underestimated difficulty.
What This Does Not Cover
This holds for enterprises that are largely consumers of purchased software, with a thin slice of custom development and an existing data platform.
If you train and serve models, components 13 to 15 are real and this argument does not apply to them. The trouble is that most diagrams conflate the predictive and generative stacks, so an organisation running one risk model inherits the infrastructure requirements of both.
This series is also grounded in process automation. Decision intelligence is a different answer, and it is where a lakehouse, retrieval, and a semantic layer genuinely become architectural capabilities rather than optional enhancements.
The failure is not that any single diagram is wrong. It is applying one diagram to three different classes of work.
What Comes Next
Each group gets its own article.
- What the Model Call Actually Reduces To — components 1 to 4
- The Quality Bar Nobody Owns — components 5, 6, 8 and 9
- The Layers You Already Have, or Never Needed — components 10 to 15
- Governance Is a Form, Not a Platform — components 7 and 16
- Your AI Problem Is Not a Technology Problem — the same argument, for a non-technical reader
Final Thoughts
Most AI platform programmes begin by adopting a capability list and staffing a team against it.
The list is not wrong. It is simply not an architecture until each item has been resolved to a decision, an owner, and a cost. Do that work and the stack collapses. What remains is a table, two schemas, a small set of build checks, and someone accountable for the quality bar.
Unpack the components.
Then decide what to build.
Tech Canvas 