The Enterprise AI Stack Explained
Seven layers, five or six vendors, and nobody accountable for the chain: what each layer owes the one above it, and why the seams are where enterprise AI risk actually lives.
The risk in an enterprise AI stack does not live in any of its layers. It lives in the seams between them, and nobody sells the seams. Seven layers, five or six vendors, and no single party who owes you an answer when an agent does something it should not have. Each layer promises something to the layer above. Buy those layers from different suppliers and the promise is not a warranty but an assumption, and the assumption is what fails.
What are the layers, and in what order do they stack?
| Layer | What it does | What it owes the layer above | Where the seam usually fails |
|---|---|---|---|
| Storage | Holds the corpus and serves records to models on request. | Provenance and jurisdiction per record, plus whether it is lawful to show a model. | The retrieval index outlives the permission that filled it, so revoked documents keep answering. |
| Identity | Names every actor and issues the credential it acts under. | One namespace and one revocation path across people, services and agents. | Delegation carries no expiry, so an agent keeps authority long after the person who granted it leaves. |
| Models | Turns context into a prediction or a draft answer. | A pinned version, a declared context, and calibrated rather than fluent confidence. | Endpoint aliases move underneath you, so the validated version and the serving version quietly diverge. |
| Orchestration | Plans the steps and calls tools on the model's behalf. | An action set fixed before the run and unable to widen while it executes. | Retries and fallbacks execute an action twice while the record shows a single intent. |
| Security | Decides which calls are permitted and blocks the rest. | Enforcement at the point of action, not an alert raised afterwards. | Controls sit on the network path while the agent acts inside a session that already cleared them. |
| Governance | Sets policy, records decisions, and answers to the regulator. | Proof of what was permitted, what was refused, and why, checkable by an outsider. | Policy sits above the enforcement point, so what is written and what is possible drift apart in silence. |
| Interfaces | Presents the stack to the person who approves or refuses. | A true account of what has happened and what happens next, at the moment of choice. | Fluent output reads as certainty, so a human approves an action the screen never showed. |
Storage, identity, models, orchestration, security, governance, interfaces. Read bottom to top. Each layer rests on a claim about what the layer beneath guarantees, and owes something specific to the one above. Almost nobody writes those obligations down: they are drawn on architecture diagrams and enforced by nothing. Here is what each owes upwards.
- Storage and retrieval owes lineage: where each record came from, which jurisdiction it sits in, and whether you may put it in front of a model.
- Identity owes one answer to who is acting, covering humans, services and agents in one namespace with one revocation path.
- Models owe reproducibility: a pinned version, a declared context, and an honest confidence signal rather than a fluent one.
- Orchestration owes a bounded action set, declared before the run and incapable of widening during it.
- Security owes enforcement at the point of action rather than detection after it.
- Governance owes evidence: what was permitted, what was refused, and why, checkable by an outsider who does not trust the vendor.
- Interfaces owe an accurate account of what the stack has done and what it is about to do, at the moment of decision.
What does it mean for one layer to owe another?
It means a warranty, not a feature. Vendors sell features at their layer and disclaim liability at the boundary. The security supplier warrants its controls, not the orchestrator's action set. The model supplier warrants availability, not that the version answering today is the version you validated. Each disclaimer is reasonable alone. Stacked, they produce a system where every layer is compliant and the chain is accountable to nobody.
Why does piecemeal procurement turn choice into risk?
Because the seam is where evidence gets re-serialised. An action starts as an intent in the orchestrator, becomes a token in identity, a permitted call in security, a row in a log, a line in a governance report. Five formats, five clocks, five retention policies, five suppliers with commercial reasons to describe events favourably. Nothing binds the intent at the top to the row at the bottom, so reconstructing what happened is correlation rather than reading. Correlation survives an internal post-mortem. It is far weaker before a regulator applying GDPR Article 22.
Procurement then optimises layer by layer, which is rational. It cannot optimise the chain, because no bidder is bidding for the chain. The residual risk lands with the integrator, and the integrator is you.
Where do the seams fail first?
The identity and orchestration seam, every time. Non-human actors are the newest thing in the stack and the oldest problem in security. An agent needs authority to be useful, the identity layer was designed for people and services, and the shortest path is to let the agent borrow a service principal. The trail then records the credential rather than the decision, and who authorised this has no answer that survives a hostile reading.
Second is governance against security. Governance describes what should happen. Security enforces what can. The gap between them is the compliance surface of the organisation, measured in most stacks in slideware rather than configuration.
Is best of breed not the proven approach?
For most of IT, yes, and this is the honest counter-argument. Layer specialists are better at their layer than any single supplier will be at all seven, and cloud is the right answer for the large majority of enterprise workloads. We are not arguing against that. Our argument is narrower: it applies where an agent takes a consequential action on a regulated matter, and you must one day prove what happened to someone who does not trust you. There, the question stops being which layer is best and becomes who is accountable for the chain. Best of breed answers the first well and cannot answer the second, because there is nobody to ask.
What does a stack without seams look like?
One accountability boundary rather than seven. In Mickai, every consequential action is sealed into the Open Audit Record before it executes, not written to a log after it. The record is signed with post-quantum FIPS 204 ML-DSA-65 and hash-chained, so a regulator or a court can verify it offline, without our cooperation. Agents work inside a gated sandbox under per-action clearance, so the security layer gates the cause, not the outcome. Identity, orchestration, governance and interface are not separate purchases with separate disclaimers; they are faces of one record, running offline on hardware the organisation owns. That removes the last seam: the one between your evidence and someone else's tenancy.
How should a board test its own stack this quarter?
Five questions, answerable in an afternoon.
- Take one automated decision from last month. Who authorised it, by name, and which artefact proves that rather than implies it?
- Which model version produced it, and can we reproduce the output today?
- Could that agent have taken a wider action than the one we assured? If the tool list is assembled at runtime, yes.
- If a regulator asked for the evidence and we declined to help, could they still verify it?
- Which supplier's contract makes them liable for the answers above? If none, the liability is ours.
Frequently asked questions
How many layers are in an enterprise AI stack?
Seven, in the model we use: storage, identity, models, orchestration, security, governance and interfaces. The count matters less than the obligations between them. A stack drawn as five layers or nine has the same seams to defend, and the seams are where accountability dissolves.
Which layer do organisations most often get wrong?
Identity, specifically identity for non-human actors. Agents are routinely given borrowed authority through a service account because it is the fastest route to a working pilot. The result is a trail naming a credential rather than a decision-maker, which holds up internally and fails under GDPR Article 22.
Does consolidating layers just mean vendor lock-in?
It does if the consolidation is a tenancy. It does not if the stack runs on hardware you own, in your jurisdiction, with an audit record a third party can verify offline. The test for lock-in is whether you can prove what your system did without the supplier's permission.
Can we fix the seams without replacing the stack?
Partly, and it is worth doing. Pinning model versions, giving agents first-class identities, fixing the action set before the run and putting one clock across the layers close real gaps. What that work cannot produce is evidence binding intent to execution across every boundary, because it must be created at the moment of action by something sitting under all seven layers.
Mickai is a British Sovereign Intelligence Operating System, built and live today. It runs offline on hardware the organisation owns, in its own jurisdiction, and every consequential action is sealed into the Open Audit Record before it executes, signed with post-quantum FIPS 204 ML-DSA-65 and hash-chained so a regulator or a court can verify it offline. The architecture behind that boundary is protected by 104 filed UK patent applications carrying 2,340 claims, held by Mickai LTD. For the architectural case, see /sovereign-ai. For how the record works, see /oar. To find which seams in your stack would fail a hostile reading today, see /ai-readiness.