Blyde Financial Services, a fictional South African financial-services group, ran its first generative AI pilot the way most organisations do. The document-processing team got a model endpoint in its own application landing zone, wrote a prompt that summarised scanned claims and showed the results to a steering committee. It worked well enough that three more teams asked for the same thing: customer service for call summaries, fraud operations for case notes and the employee knowledge team for a policy assistant.
Six months later Blyde had four model deployments, four sets of keys, four prompt libraries in four repositories, no shared test set and an invoice nobody could split by team. None of the four could say which model version produced last Tuesday's answers. Every one of them sat inside a well-governed cloud landing zone, and every one of them had rebuilt the same AI plumbing by hand.
That is the gap an AI landing zone fills. This part defines it, shows what it adds to the cloud and data foundations from earlier in the series, and draws the boundary between what the AI platform owns and what each workload team keeps.
A definition, and what it is not
In this series an AI landing zone is the shared, governed foundation that AI workloads inherit: approved models and endpoints, a gateway, grounding through governed data, prompt and evaluation assets, safety controls, monitoring, cost management and responsible-use controls. It sits on the platform landing zone and reads from the data landing zone.
It is not a second estate. Microsoft's Cloud Adoption Framework says so directly: "AI workloads don't require a different Azure landing zone architecture or governance model" (Architecture and governance for AI, updated October 2026, checked on 7 November 2026). The same page tells platform teams to extend the existing governance baseline with policies for the AI services they approve, and to place AI workloads under the existing management groups rather than create AI-specific ones. The AI landing zone is that extension plus the shared services that sit on top of it.
The other clouds frame it the same way. AWS publishes a Well-Architected Generative AI Lens (first released April 2025), which applies the existing pillars to the generative AI lifecycle and was last revised in November 2025. Google Cloud's Well-Architected Framework has an AI and ML perspective that does the same for each pillar. Microsoft also maintains an open-source AI Landing Zones project in the Azure GitHub organisation. It provides Bicep and Terraform reference implementations built on Azure Verified Modules, including an agent landing zone on Microsoft Foundry and an AI gateway landing zone on Azure API Management. It can connect to a shared platform hub or be deployed standalone, and the project notes that some included services may be in preview (all checked on 7 November 2026).
Deployable templates are useful, as part 5 argued for modules generally. They do not decide who approves a model, what counts as a passing evaluation or who pays for tokens. Those are the parts of an AI landing zone that make it a foundation.
Why cloud and data controls are not enough
A cloud landing zone governs where systems run. A data landing zone governs what can be trusted. Neither was designed for components that behave like these:
- Output is not deterministic. The same input can produce different answers, and a model upgrade can change behaviour without a single line of your code changing. Testing becomes evaluation against a labelled set, repeated on every change.
- Prompts are code. A one-line change to a system prompt can alter every answer. Prompts need versioning, review and release like any other asset.
- The model is a supplier. Model versions retire, regions differ in which models they offer, and capacity is not guaranteed. Microsoft's guidance warns that model availability and capacity vary by region.
- Cost scales with use, not with servers. Tokens are billed per call, so cost must be attributed per workload from the first day.
- New leak paths appear. Prompts and responses may contain personal information, and logs, traces and caches can store them. Do your observability tools store the prompt? covers the trap.
Each of those needs a control. If every workload builds its own, you get Blyde's four disconnected pilots.
The shared services
The AI landing zone provides six services that workloads consume rather than build.
- Approved models and endpoints. A catalogue of models the organisation has approved, for which uses and in which regions, with the policy that blocks unapproved deployments. Microsoft's guidance points to Azure Policy definitions for Foundry model deployments for exactly this.
- An AI gateway. One place for keys, quotas, routing, rate limits and usage telemetry. The model gateway is not the AI platform explains what a gateway does and does not control, and Virtual keys are an accountability mechanism covers per-team attribution.
- Grounding connectors to data products. Retrieval reads published data products from the data landing zone, with their classifications and access policies intact, not a copy of the raw lake.
- A prompt and evaluation registry. Prompts are versioned next to the evaluation sets they must pass, so that a prompt or model change is a release with evidence.
- Safety filters and red-team tests. Content filters, prompt-injection defences and adversarial test suites, shared and maintained centrally, with workload-specific additions.
- Monitoring, usage and cost. Traces, quality signals and spend per workload, with clear rules about what is logged and for how long.
A secure enterprise AI reference architecture walks through these layers for a single request. The landing-zone question is different. It is not how one request is protected but who provides each service to every workload, and on what terms.
Risk language that already exists
Blyde did not invent a risk framework. It mapped its controls to the NIST AI Risk Management Framework and its four functions: govern, map, measure and manage. It also used the Generative AI Profile (NIST AI 600-1), published in July 2024. Checked on 7 November 2026, NIST says AI RMF 1.0 is being revised, so the mapping should be reviewed when the revision appears.
The mapping is useful because it splits the work. Govern maps to the approval rules and responsible-use policy. Map maps to the use-case register and risk tiering. Measure maps to the evaluation registry and red-team suites. Manage maps to monitoring, incident review and model retirement. A control that maps to none of the four is probably decoration. A function with no control in the landing zone is a gap.
Where the ownership boundary sits
The technology choices are the easy part. Most AI platform disputes are about ownership.
At Blyde the split became:
- The AI platform team owns the model catalogue, the gateway, keys and quotas, the shared safety filters, telemetry and cost reporting, and the evaluation tooling.
- Each workload team owns its use case, its prompts, its choice of grounding sources, its task-specific test sets, its release decision and its users.
- The risk and responsible AI function owns use-case risk tiering, the responsible-use policy, the rules for approving a model and the release thresholds.
The release threshold is where the boundary matters most. It is set by risk, measured by the workload team against its own test set and enforced by the platform, which will not route production traffic to a prompt or model version that has not passed. No single team can waive it. That is what makes the evaluation a control rather than a report. Evaluate each AI layer differently covers what each layer's evaluation should measure.
Two things the central team should not do. It should not write workload prompts, because it does not own the use case. And it should not become the only route to production for every experiment. Sandboxes with spending limits and no production data let teams learn without waiting. Every AI pilot needs a graduation path describes how an experiment earns its way onto the shared platform.
From four pilots to one foundation
Blyde moved the four pilots across in about a quarter. The sequence matters more than the timing:
- Stand up the gateway and route one workload through it, so cost and usage are visible before anything else changes.
- Publish the model catalogue and the policy that blocks unapproved deployments in application landing zones.
- Move prompts into the registry and write the first evaluation set with the document-processing team.
- Switch retrieval from the team's own copies to published data products.
- Only then onboard the other three workloads, which now inherit the controls instead of building them.
The most useful finding was the dullest. Two of the four pilots used different versions of the same model for no reason anyone could remember. Consolidating them reduced the evaluation and upgrade work, not just the bill.
What an AI landing zone does not do
An AI landing zone governs intelligence: which models run, what they are grounded in, how they are tested and what they cost. It does not decide what an AI system may do. A model that drafts a reply to a customer in arrears is governed here. An agent that sends that reply, books a payment arrangement or changes a limit needs a different foundation, one that governs authority. That is the subject of the next part.
Does a workload need the AI landing zone?
| Question | If yes |
|---|---|
| Does it call a generative or machine-learning model in production? | It uses the approved catalogue and the gateway |
| Is it grounded in organisational data? | It reads published data products through the grounding connectors |
| Can a prompt or model change alter what users see? | Its prompts and test sets live in the registry, behind a release threshold |
| Could its prompts or outputs contain personal information? | It follows the platform's logging and retention rules for AI telemetry |
| Does it spend more than a sandbox budget? | Its usage is attributed per workload through the gateway |
| Can it take actions in business systems, not just produce text? | It also needs the agentic landing zone (part 8) |
Key points
- An AI landing zone is the shared foundation AI workloads inherit: models, gateway, grounding, prompt and evaluation assets, safety, monitoring, cost and responsible-use controls.
- It extends the platform landing zone's governance baseline and reads from the data landing zone. It is not a separate estate, and Microsoft's own guidance says AI does not need a different landing-zone architecture.
- Deployable templates such as Microsoft's AI Landing Zones help, but they do not settle approval, evaluation thresholds or cost ownership.
- Map the controls to the NIST AI RMF functions so that gaps are visible.
- The release threshold is set by risk, measured by the workload and enforced by the platform.
- An AI landing zone governs intelligence, not authority.
This is part 7 of Cloud Foundations, Explained End to End. Previous: A data landing zone is not just a data lake. Next: Agentic landing zones: from governed intelligence to governed action
How CloudNala can help
CloudNala designs AI landing zones for organisations that have more than one AI pilot and no shared foundation underneath them. We inventory the models, keys, prompts and test sets already in use and design the shared services and policies. We then agree the ownership split between the AI platform, workload teams and risk, and move the first workload across with a working release threshold, so that the next three inherit the controls instead of rebuilding them.
Background reading: Microsoft, AI adoption in the Cloud Adoption Framework; AWS, Generative AI Lens; Google Cloud, AI and ML perspective; NIST, AI RMF and AI 600-1.
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 a Landing Zone Review or write to us at consult@cloudnala.co.za