The second week of claims-assistance design work at Outeniqua Assurance, a fictional South African short-term insurer, began with a poster. Someone in the delivery team had printed a supplier's "AI stack" diagram: forty-odd product logos arranged in coloured bands, from chips at the bottom to copilots at the top. Outeniqua was a cloud customer of that supplier, so the poster was not wrong. It was simply the wrong tool. It answered "what can we buy?" when the architect needed to answer "what does this system need, and what do we already know how to do?"
Part 1 argued that an experienced cloud architect does not start over. This part makes that concrete. It sets out stable layers that outlive any product map, then sorts each familiar cloud discipline into three groups: what carries over unchanged, what changes shape, and what is genuinely new.
Learn the layers, not the poster
Product maps change every few months. Services are renamed, merged, moved into preview or retired. An architect who learns AI through a product map spends their time keeping up with the map. An architect who learns stable layers can place any new product in seconds and ask the right question about it.
This is the same argument made in Capability architecture, not another AI logo landscape: describe what the system must be able to do, then choose products to provide it. For AI systems, eight layers cover nearly every design CloudNala sees.
| Layer | What it answers | Example services, checked on 5 November 2026 |
|---|---|---|
| Experience | How people and systems interact with the capability | Existing portals, apps and contact-centre tools |
| Agent runtime and orchestration | What decides the next step, and within which limits | Coded workflows; Microsoft Foundry Agent Service |
| Data and memory | What the system reads, retrieves and retains | Azure AI Search; existing claims and policy databases |
| AI services | Extraction, classification, speech, vision | Document-processing and vision services in the provider's catalogue |
| Models | Which models perform which jobs | Models deployed through Microsoft Foundry, or another provider's catalogue |
| Infrastructure | Where it runs and how it connects | Azure Container Apps, Azure Functions, private networking |
| Governance | Who may do what, and what is permitted | Identity provider, Azure Key Vault, Azure API Management as a gateway |
| Operations | How it is observed, evaluated and costed | Azure Monitor and Application Insights; evaluation pipelines |
The examples are Microsoft services because Outeniqua is a Microsoft customer, and every name in the third column appears in current Microsoft Learn architecture guidance, including Microsoft's workload personas for AI workloads. They are examples of how a layer can be filled, not a recommended architecture and not a ranking. AWS publishes parallel guidance in its Well-Architected Generative AI Lens (publication date 19 November 2025, checked on 5 November 2026), and the same eight layers can be filled from its catalogue or from open-source components.
Two points about the layers matter more than the table. First, most of them are not AI-specific: experience, data, infrastructure, governance and operations are layers a cloud architect already designs. Second, the boundaries overlap. A gateway is both governance and infrastructure. Retrieval is both data and an AI service. Treat the layers as a checklist of questions, not as boxes that must each contain a product.
What carries over unchanged
Some disciplines carry over almost exactly. For these, an experienced cloud architect is already the most qualified person in the room.
- Landing zone and environment design. Subscriptions or accounts, policy, segregation of production from non-production.
- Network segmentation and private connectivity. Model endpoints and search indexes need private paths and egress control like any platform service.
- Encryption and key management. Documents, indexes and stored prompts are data at rest.
- Infrastructure as code and environment promotion. Prompts, tool definitions and evaluation sets should be promoted the same way as code.
- Disaster recovery for stateful components. Indexes, case stores and configuration need recovery plans. The model needs a continuity plan rather than a restore plan: an alternative region, deployment or model that has passed the same evaluation, because you do not own the model itself. That leads to the next group.
What changes shape
Most disciplines carry over but change shape. The underlying skill applies. The question it asks is different.
Identity becomes delegated identity. In a conventional system, a service calls another service under its own identity. When an assistant calls a tool on behalf of a claims handler, the question becomes whose authority it is using. Outeniqua's design passes the handler's identity to the policy system, so that the assistant can never read a policy the handler could not read. Identity before intelligence covers the gateway patterns that make this practical.
Access control extends to retrieval. Permissions have to be enforced at the moment of retrieval, not only at the front door. Permission-aware retrieval explains why an index that ignores source permissions is a data leak waiting for the right question.
Reliability includes a dependency you cannot fix. Model services throttle, change quotas and occasionally fail. The architect cannot raise their availability, only design around them: queueing, fallbacks to a smaller model where quality allows, and a degraded mode in which the business process continues without the assistant.
Observability must capture behaviour, not only health. A trace that shows a 200 response and a latency is not enough. The team needs to know which documents were retrieved, which model version answered and which tools were called. Those traces can contain personal information, so the observability design is also a data-protection design. Do your observability tools store the prompt? sets out the questions.
Cost becomes variable per outcome. Conventional cloud cost is largely driven by capacity and usage you can forecast. AI cost is mostly consumption, and it varies with document length, retries and model choice. The useful unit is cost per accepted outcome, here cost per assisted claim, as argued in Cost per prompt is the wrong metric.
Change management includes model and prompt changes. A model version upgrade, a new system prompt or a changed tool description can change behaviour without a line of application code changing. Treat each as a production change with evidence, as An MCP upgrade is a production change argues for tool servers.
What is genuinely new
A few disciplines have no close cloud equivalent. These are where an architect needs to build working proficiency deliberately.
- Evaluation design. Choosing representative cases, defining what good looks like, setting thresholds and deciding when the set must be rerun. This replaces assertion-based testing for any non-deterministic step.
- Grounding data design. Deciding which content the system may rely on, how it is prepared, how it stays current and how its provenance is recorded. Microsoft's AI workload guidance treats grounding data design as its own technical design area.
- Model selection and routing. Matching jobs to models on evidence, not reputation. Use the smallest model that reliably passes the evaluation covers the method.
- Contracts with a model. Structured inputs and typed outputs that the rest of the system can validate, so that a malformed answer is caught rather than acted on.
- Authority design. Writing down, per action, what the system may recommend, prepare or do, and where a person must decide.
- Behaviour drift. Accepting that quality can change when inputs change, even when nothing in the system was deployed, and designing monitoring for it.
Outeniqua's transfer map in practice
Outeniqua's architect turned this into a change to the architecture document template, not a separate AI document. The existing sections stayed: context, landing zone, identity, network, data, integration, resilience, operations, cost. Three things changed.
First, several existing sections gained AI-specific questions. The identity section now asks about delegated identity for tools. The data section asks which content is grounding data and who owns its currency. The cost section asks for cost per assisted claim at expected volumes.
Second, three new sections were added: evaluation (set, threshold, owner, rerun triggers), model and prompt management (versions, routing, change process), and authority (what the assistant may recommend, prepare and do, and which decisions remain with claims officials).
Third, the review panel changed. A claims operations manager now reviews the authority section, because only the business can say which claims decisions must stay with a person. The architect owns the document. She no longer owns every answer in it.
The template change took a day. The first design written against it exposed two real gaps: the policy-wording repository had no owner for currency, and nobody had defined what an acceptable claim summary looked like. Both were organisational problems, and both would have surfaced in production otherwise.
Mistakes to avoid
- Mapping products before capabilities. Start from the eight layers and the system's needs, then fill them.
- Treating "changes shape" as "unchanged". Identity, observability and cost look familiar and behave differently. They are where experienced architects are most often caught out.
- Treating "new" as "someone else's job". Evaluation and authority design belong in the architecture, even when specialists do the detailed work.
- Freezing a product map into a standard. If your standard names a specific preview service, date it and review it, or it will outlive the product.
Key points
- Learn eight stable layers (experience, agent runtime, data and memory, AI services, models, infrastructure, governance, operations) and treat products as dated examples.
- Landing zones, segmentation, encryption, infrastructure as code and recovery of stateful components carry over almost unchanged.
- Identity, access control, reliability, observability, cost and change management carry over but change shape, and they catch experienced architects out.
- Evaluation, grounding data design, model routing, model contracts, authority design and behaviour drift are genuinely new.
- Extend the architecture template you already use, and add the business owner of decisions to the review panel.
Next: Part 3, The AI architect capability matrix, and a 90-day lab. All parts are on the series page.
How CloudNala can help
CloudNala runs AI architecture reviews that start from your existing architecture template rather than a vendor poster. We map your planned AI capability onto the eight layers, mark each discipline as carried over, changed in shape or new, extend your template and review panel accordingly, and test one live design against it so your team can see where the real gaps sit.
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 Architecture Review or write to us at consult@cloudnala.co.za