An AI system is not an LLM
It is a dozen engineering disciplines wired together, and the model is the smallest part. Assurance is knowing every one of them: what it does, how it fails, and what good looks like.
The anatomy of a production AI system
Six layers, twelve disciplines. Vibes live at the top; incidents come from the bottom. Click a layer for the detail.
The model is one band of six. Everything else is engineering that someone has to own, and it is where we spend most of our time.
Every part, named
What each discipline is, where it fails, and what good looks like, mapped to ISO/IEC 27001:2022 Annex A controls and EU AI Act articles, because that is the language a supplier review speaks. We operate our own ISMS aligned to ISO/IEC 27001, internally audited on a managed GRC platform and working towards certification, so the mapping below is lived, not copied out of the standard.
Surfaces
Where people actually meet the system: chat, the IDE, the API, the tools work already lives in. The common failure is AI bolted on beside the work. Good looks like one protocol underneath every surface, so a capability added once lands everywhere at once.
EU AI ACT ART. 50Orchestration and agents
How work is decomposed, scheduled and recovered: which agent does what, with which tools, and what happens when a step fails. The failure mode is an agent with wide tools and no declared scope. Good looks like narrow remits, designated approvers, and control flow that recovers instead of wedging.
EU AI ACT ART. 14 · ISO 27001 A.8.2Guardrails
The rules that hold when nobody is watching. A policy document is a wish; enforcement lives in the architecture or it does not exist. Good looks like gates a caller in a hurry cannot skip, and approval flows that are code, not custom.
EU AI ACT ART. 9 · ISO 27001 A.5.1Prompt and context engineering
The context window is the real interface to the model, and most incidents blamed on the model are context bugs: the wrong things assembled in the wrong order under the wrong budget. Good looks like context built deliberately, budgeted per source, and versioned like any other code.
EU AI ACT ART. 11 · ISO 27001 A.5.12Retrieval
Grounding answers in your knowledge instead of the model's memory. Stuff-everything RAG with no provenance is how confident nonsense gets citations. Good looks like access-aware retrieval that carries its sources, ranks by confidence, and knows what is stale.
EU AI ACT ART. 10 · ISO 27001 A.5.15Memory
What persists between sessions, and who approved it persisting. Remember everything forever and you have built a liability, not an asset. Good looks like write-gated stores, promotion by approval, and deletion that is deterministic rather than aspirational.
ISO 27001 A.8.10 · A.5.33Models
Rented, versioned, and deprecated on someone else's schedule. Single-model dependence is a supplier risk wearing a technology costume. Good looks like more than one model, chosen per task, replaceable without drama because the harness, not the model, holds your logic.
ISO 27001 A.5.21 · EU AI ACT ART. 53Routing and load balancing
Which model serves which request, in which region, under which quota, and what happens in an outage. These are decisions, and they are made before the incident or during it. Good looks like per-task routing, region pinning where residency demands it, and failover that was rehearsed.
ISO 27001 A.8.14 · EU AI ACT ART. 15Evaluation
The acceptance test for everything above. When a provider deprecates a model, your evaluation set decides the replacement, not the changelog. Good looks like evals that run before any version change, and drift caught by measurement rather than by a user.
EU AI ACT ART. 15 · ART. 72Data and residency
Where everything lives at rest and in flight, and what is allowed to touch it. Good looks like residency stated per service, personal data replaced at a structural boundary before storage or inference, and a deletion path you can demonstrate, not describe.
ISO 27001 A.5.34 · EU AI ACT ART. 10Identity and access
Who and what may call which capability, enforced server side. Agents get identities, scopes and audit trails of their own; authorisation living in a client is authorisation that does not exist. Good looks like role-gated tools where nothing sees everything.
ISO 27001 A.5.16 · A.8.5Observability, audit and cost
Traces, provenance, unit cost, and the audit trail a regulator reads. A system you cannot watch is not deployed, and a reported number that does not trace to a source field is not a metric. Good looks like every answer explainable and every pound attributable.
ISO 27001 A.8.15 · EU AI ACT ART. 12Why this is the assurance.
You cannot govern what you cannot name. Most AI risk conversations stall because one side is talking about a model and the other is talking about a system, and neither has a parts list.
This page is ours. Every engagement starts by mapping the client system against it: which parts exist, which are missing, which are someone else's problem pretending to be yours. The gaps are the work.
Want the parts list applied to your estate? That is an assessment, and it is usually two weeks.
How our own platform implements the data layer, boundary and audit: drawn and published on the ORCA page.
Data handling in ORCA- OpenAI
- Anthropic
- Google Gemini
- Meta
- Mistral AI
- xAI
- DeepSeek
- Cohere
- Qwen
- Ollama
- Hugging Face
- NVIDIA
the model layer we work across · routing, evaluation and fallback Marks are the property of their owners, shown to describe our own stack. No endorsement, sponsorship or partnership implied.
Tell us what you are accountable for.
The useful first conversation is usually about the thing that worries you, not about our capabilities. If it turns out we are the wrong firm for it, we will say so.
One reply from a person who has read what you sent.