Ask five vendors for a secure enterprise AI architecture and you will receive five product maps, each with the vendor's own platform in the middle. Ask an internal team and you will often get a diagram with the model in the centre and a single box labelled "guardrails" next to it.
Neither helps much when you need to decide what to build. A product map tells you what one supplier sells. A single guardrails box suggests that security is one component you can buy and switch on. It is not. Security in an AI system is a property of every layer a request passes through, and the most important controls are the ones that run across all of them: identity, audit and human approval.
This part closes the series with a neutral reference architecture that joins up the earlier parts: review, evidence, approval records and audit. It names layers and responsibilities, not products, so it can be mapped to whichever cloud and vendors you use.
Silverleaf Brokers is fictional, and its systems and figures are illustrative. Its adviser assistant began as a drafting tool. The next request from the business was for the assistant to update client records directly after a review meeting. That one change, from drafting to acting, is what made a deliberate architecture necessary.
Six layers and three cross-cutting controls
Read the stack from top to bottom as a request travels.
Channels and users. Where people reach the system: a web portal, Microsoft Teams, a mobile app, WhatsApp. Each channel brings its own identity assumptions. A request from an authenticated internal portal and one from a messaging channel do not carry the same proof of who is asking.
Application or agent. The owned product: its logic, its versioned prompts and instructions, and the decisions about which tools it may call. This layer should have a named product owner. If nobody owns it, nobody owns its behaviour.
Guardrails. Input screening (prompt injection attempts, out-of-scope requests, personal information that should not be sent onward) and output validation (format, policy, grounding, sensitive content). Plural and layered, as we argued in Guardrails are a stack, not a switch.
Model gateway. The controlled route to approved models: authentication, quotas, routing, logging and cost attribution. A gateway governs only the traffic that passes through it, so direct calls to providers have to be closed off or the gateway is decorative. The gateway is a control point, not a trust boundary explains the limits, and our Model Gateway series goes further.
Registry. The inventory of approved models, prompt and instruction versions, tools and their owners. Without a registry, the audit question "which model and prompt produced this output?" has no answer.
Governed data. Classified sources, with retrieval that applies the same permissions as the system of record. RAG is a data security system is the longer treatment.
Then the three controls that cut across every layer:
- Identity and access. Every layer needs to know who the request is for and with what authority. The anti-pattern is a shared service account at the application layer that turns every user into a superuser for whatever the agent can reach.
- Audit and observability. One trace per request, written to by every layer, so a disputed case can be rebuilt end to end.
- Human approval at actions. Not everywhere, which would make the system useless, but at the boundary where the system changes something that matters or sends something outside the organisation.
Following one request
The architecture is easier to judge when you follow a single request. A Silverleaf adviser, after a meeting, asks the assistant to "update Mr Naidoo's record with the new fleet size and send him the revised pack".
- Identity checked. The request carries the adviser's own identity, not a shared one. The adviser may update records for clients assigned to them.
- Input screened. The request is in scope. Nothing in it attempts to change the assistant's instructions.
- Retrieval, permission-filtered. The assistant retrieves the client's current schedule and the meeting notes, filtered by what this adviser may see.
- Gateway to an approved model. The call goes through the gateway, which records the model version and attributes the cost to the adviser team.
- Output validated. The proposed record change is checked against the record's schema: fleet size must be a whole number, the client reference must match.
- Action needs approval? Updating the client record is a write. Sending a pack externally is an outbound communication. Silverleaf's policy is that the adviser confirms record changes in the interface, and the senior adviser approves any revised pack before it is sent, as in Part 3.
- Human approves. The adviser confirms the record change. The pack waits for the senior adviser.
- Action executed with the adviser's authority, not the assistant's.
- Trace recorded. Every step above writes to the same trace, linked to the client case.
Notice how many control points can stop the request. That is deliberate. A secure design is not one strong wall; it is several layers that can each refuse, so that one failure does not become an incident.
Trade-offs worth stating
This architecture has costs, and pretending otherwise is how teams end up bypassing it.
Latency. Each control adds time. Input screening and output validation can add noticeable delay to a conversational experience. Put the heavier checks where actions happen, not on every chat turn.
Friction. Human approval at every write makes an assistant feel slow. Silverleaf's split, where the adviser confirms their own record changes but external communication needs a second person, is a deliberate balance between speed and consequence.
Operating effort. A registry, a gateway and per-request traces all need owners and upkeep. A small organisation might start with the registry as a spreadsheet and the gateway as one approved route, and grow from there. The layers matter more than the sophistication of each one.
Vendor platforms. Most cloud AI platforms provide several of these layers. That helps, but check which layer each feature really implements, and whether it covers traffic that does not pass through the platform. Embedded AI in software-as-a-service products often sits outside your architecture entirely and needs to be governed through procurement and configuration instead.
Using the reference architecture
A reference architecture is useful for three jobs:
- Design review. Map a proposed AI system onto the six layers and three cross-cutting controls. Empty cells are design questions to answer before build.
- Audit scoping. The layers line up with the audit areas in Part 4, so the same picture organises both the design and its assurance.
- Vendor conversations. Ask each vendor which layers they implement, which they assume you implement, and what evidence their layer produces for your trace.
It is not a product to buy or a target to complete before doing anything. It is a way of making sure that when an AI system starts acting on your behalf, every layer it passes through can explain itself and, when necessary, say no.
This is the last part of the series. Start again at Part 1, AI can produce the document. Who helps you review it? All parts are on the series page.
How CloudNala can help
We help teams design and review enterprise AI architectures layer by layer: mapping a proposed system onto channels, application, guardrails, gateway, registry and governed data, checking identity, audit and approval across all of them, and identifying which vendor features genuinely cover which layer. The output is a design you can build and an evidence plan you can audit.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Assurance Review or write to us at consult@cloudnala.co.za