The lead cloud architect at Outeniqua Assurance, a fictional South African short-term insurer, was handed a new brief last year: design the architecture for a claims-assistance capability. Policyholders would upload photographs, repair quotes and police case numbers; the system would read them, find the relevant policy wording, draft a summary for the claims handler and ask the policyholder for anything missing. Her first instinct was to book a deep-learning course. Her second, after a week of reading job adverts that asked for "LLMOps", "agentic frameworks" and a long list of tools, was to wonder whether she was the right person at all.
She was. The claims assistant would run in Outeniqua's landing zone, authenticate through its identity provider, call internal claims and policy systems over private networking, store sensitive documents under existing encryption and retention rules, and need recovery targets, monitoring and a monthly budget. Most of the architecture was work she had done for a decade. What was new was real, and it mattered, but it was an extension of the system she already understood, not a replacement for it.
This series is for experienced cloud, solution and enterprise architects making that move. This first part separates what carries over from what is new. Part 2 maps the transfer layer by layer, and Part 3 sets out a capability matrix and a 90-day lab for building the new depth on purpose.
The foundations did not expire
AI systems are software systems that happen to contain a component whose behaviour is learned rather than coded. Everything around that component still needs the disciplines a cloud architect already practises.
- Identity and access. Who may call the system, under which identity it calls other systems, and how rights are reviewed. This becomes more important, not less, once a model can choose to call a tool.
- Network design. Private connectivity to model services, egress control and segmentation. A model endpoint is another dependency with a network path, and it is often outside your estate.
- Data protection. Classification, encryption, residency and retention. Claims documents contain personal information, sometimes about injuries, and none of the obligations change because a model reads them.
- Integration. Contracts, idempotency, retries and failure handling between systems. A model that drafts a summary still has to fetch the policy, and that call still fails at month-end.
- Reliability. Recovery objectives, degraded modes and dependency mapping. A model provider can throttle or fail like any other service.
- Observability. Logs, metrics and traces that let someone reconstruct what happened.
- Automation. Infrastructure as code, pipelines and environment promotion.
- Cost management. Budgets, allocation and the habit of asking what a design will cost to run.
- Customer context. Knowing what the business is trying to achieve and what it cannot afford to get wrong.
When Outeniqua's architect listed these against the claims-assistance brief, every one applied. That list is the base of the AI architecture, and an AI design that skips it is a prototype, whatever its model scores. The secure enterprise AI reference architecture shows how many of its control points are ordinary enterprise controls placed in the right order.
Six concerns that are genuinely new
The extension sits on top of those foundations. For the claims assistant it came down to six concerns.
- Document and data quality, with lineage. The assistant's output is only as good as the photographs, quotes and policy wording it reads. The architect now has to ask where each input came from, which version was used and whether it was fit for this purpose.
- Grounded retrieval. Finding the right clause in the right version of the policy wording, and nothing the handler is not permitted to see.
- Model choice and routing. Which model does which job, at what cost and latency, and what happens when a model version changes.
- Tool permissions. What the assistant may read, what it may write, and under whose authority. In Outeniqua's case it may request missing documents from the policyholder. It may not change a claim's status.
- Evaluation. A defined, repeatable way of showing that the assistant's summaries and requests are good enough, before release and after every material change.
- Human claims authority and case evidence. Who decides the claim, what the assistant's contribution to that decision was, and how the case file records both.
None of the six is exotic. Each has a cousin in conventional architecture: lineage in data engineering, access control in retrieval, dependency management in model choice, least privilege in tool permissions, testing in evaluation, and audit in case evidence. What changes is that they now sit inside the main path of the system, and they cannot be left to a specialist team after the architecture is drawn.
The real shift is non-determinism
If one idea explains why AI architecture feels different, it is this: the same input does not guarantee the same output. Microsoft's Azure Well-Architected guidance for AI workloads puts non-deterministic behaviour at the centre of the architectural challenge, alongside data and application design and operations (checked on 5 November 2026).
Conventional systems are proven with assertions: this input produces exactly this output. A claims summary cannot be proven that way. Two runs may phrase it differently, and both may be acceptable. A third may omit the one exclusion that matters. The architecture therefore needs a different kind of evidence: a set of representative cases, a definition of what an acceptable answer looks like, a threshold, and a way to rerun the whole set when anything changes. That is the discipline set out in Evals that gate real work.
For an architect, this is less a new science than a new obligation in the design. A cloud architecture review asks how the system is tested. An AI architecture review asks the same question and refuses "we tried it and it looked good" as the answer.
Outeniqua's first design review
The most useful thing Outeniqua's architect did was refuse to start a separate "AI architecture" track. She took the design review checklist she already used and extended each question.
| Question she already asked | The extension for the claims assistant |
|---|---|
| Who can call this service? | Which tools may the assistant call, under which identity, with which rights? |
| What is the recovery objective? | What happens when the model service is throttled or unavailable? Outeniqua chose a degraded mode in which handlers work exactly as they do today. |
| What does it cost per month? | What does it cost per assisted claim, including retries and long documents? |
| How do we test it? | Which evaluation set and threshold must pass before release, and who signs off? |
| What data does it store, and for how long? | Are prompts, retrieved passages and drafts stored, where, and under which retention rule? |
| Who owns it in production? | Who holds claims authority? The assistant drafts and requests. A named claims official decides. |
Five of the six rows were answerable with the architect's existing skills, once the question was stated precisely; the authority row also needed the claims business to say which decisions must stay with people. The evaluation row was the one that needed new technical depth, and the team brought in an engineer who had built evaluation sets before. That is a normal architectural move: recognise the gap, name it, staff it.
The last row deserves emphasis. A claims decision has consequences for a policyholder. Outeniqua's design puts the assistant's role in writing: it may summarise, highlight possible exclusions and request missing documents. It may not decline a claim, reduce a payout or tell a policyholder that a claim will fail. Those remain decisions for a person with delegated authority, recorded in the claim's case file in the way described in Every automated recommendation needs a case file. As Agent capability is not agent authority argues, what a system can do and what it may do are separate design decisions, and the architect is the person who writes both down.
What you do not need to become
The anxiety in most architects' questions comes from an implied job description that nobody could meet: model training, GPU programming, fine-tuning, every agent framework, every vector database, and a working knowledge of every new paper.
An AI systems architect does not need most of that. A useful way to think about depth comes in three levels, which Part 3 develops into a full matrix:
- Awareness. Enough to recognise when a technique applies and to ask a specialist the right question. Model training and fine-tuning sit here for most architects.
- Working proficiency. Enough to design, review and challenge the work. Retrieval design, evaluation design, tool permissions and AI cost modelling sit here.
- Specialist depth. Enough to build and tune it. Most architects need this in one or two areas at most, chosen because their organisation needs them.
This matches the argument in AI roles decoded: read the verbs, not the title: the work is described by what you frame, build, integrate, evaluate, operate and govern, not by the tool list in a job advert. For the organisation-wide view of how those paths are taught, see Learning paths by role, not by tool. This series is narrower: it is about one experienced person extending one role.
Where architects go wrong in the move
The common failure modes are recognisable.
- Treating the model as just another API. It has an interface like an API, but its output varies and its quality must be measured. Designs that wrap a model call in a normal integration pattern, with no evaluation and no degraded mode, fail quietly.
- Handing the "AI part" to someone else. When the architect draws the landing zone and leaves the retrieval, tools and evaluation to a data science team, nobody owns the joins. Those joins are where the hard incidents happen.
- Learning frameworks instead of patterns. Framework knowledge dates in months. Knowing when to use a fixed workflow, a bounded agent step or retrieval lasts much longer.
- Forgetting the case. AI-assisted work in an insurer, a bank or a public body ends in a decision about a person. If the design cannot reconstruct who decided what, and on which evidence, it is not finished.
- Over-correcting into scepticism. Some experienced architects respond to hype by refusing to engage. The organisation then designs its AI systems without its most experienced designers.
What this means for South African architects
Many South African organisations run lean architecture teams, and the people being asked to design AI systems are the same people who carry the cloud estate. That is an advantage. Insurers, banks and public bodies operate under supervisory and audit expectations, and POPIA applies to almost every claim, application or complaint an AI system will read. An architect who already knows where personal information flows, how access is reviewed and what the auditors will ask for is better placed to design a defensible AI system than a specialist who knows the newest framework but not the estate.
The gap is real but specific. It is evaluation, grounding, model behaviour and human authority. Those can be learned deliberately, on real work, without starting over.
Key points
- AI systems sit on cloud foundations: identity, networking, data protection, integration, reliability, observability, automation, cost and customer context all carry over.
- Six concerns are genuinely new to the main path of the design: data quality and lineage, grounded retrieval, model choice and routing, tool permissions, evaluation, and human authority with case evidence.
- Non-determinism is the real shift. It turns "how do we test it?" into a design obligation for evaluation evidence.
- Extend the design review you already use instead of starting a separate AI track.
- Most architects need awareness of model training, working proficiency in evaluation and retrieval design, and specialist depth in only one or two areas.
Next: Part 2, What transfers from cloud architecture to AI, and what is new. All parts are on the series page.
How CloudNala can help
CloudNala runs AI architecture reviews for teams designing their first production AI capability on an existing cloud estate. We take your current design review, extend it for retrieval, model choice, tool permissions, evaluation and human authority, test your design against it, and leave your architects with the extended checklist, a gap list and a short plan for the depth your team still needs.
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