By now Blyde Financial Services, a fictional South African financial-services group, has heard the phrase "landing zone" in four different meetings. The cloud team means the platform it runs. The data office means the governance plane under its data products. The AI platform team means the gateway, model catalogue and evaluation registry. The collections team, planning its arrears-support agent, means identity, authority and approval for agents.
Each group is right about its own layer. The risk is that each one builds its layer as a separate estate, with its own identity model, its own logging, its own network and its own idea of who approves what. Blyde would then have four landing zones and no foundation.
This part puts the four side by side. It shows what each one governs, which controls they share and which they do not, and the order in which they must exist. It then follows one fraud workload through all four.
Four layers, one estate
The four foundations are best understood as layers, each assuming the one below:
- The cloud landing zone governs where systems run: the accounts or subscriptions, identity, networks, policy, logging, recovery and cost controls that every workload inherits. In this series it splits into the platform landing zone and application landing zones.
- The data landing zone governs what can be trusted: ownership, classification, quality, lineage, access, retention and data products.
- The AI landing zone governs intelligence: approved models, the gateway, grounding, prompts and evaluations, safety, monitoring and cost.
- The agentic landing zone governs authority and action: agent identity, grants, policy before action, credential brokering, approval, durable state and containment.
The vendors agree on the bottom layer and increasingly on the next ones. Microsoft's Cloud Adoption Framework describes Azure landing zones as a platform landing zone plus workload landing zones, which this series calls application landing zones. AWS uses AWS Control Tower to set up a governed multi-account landing zone, and its Landing Zone Accelerator is aimed at regulated workloads. Google Cloud defines a landing zone as "a modular and scalable configuration that enables organizations to adopt Google Cloud for their business needs" (all checked on 7 November 2026). Microsoft's AI guidance adds that AI workloads do not need a different landing-zone architecture, as part 7 noted. That is the point of this part: the upper layers extend the foundation. They do not replace it.
What is shared and what is not
The most expensive mistake is to duplicate shared controls in every layer. The second most expensive is to assume the shared controls cover everything.
| Control | Built once in the cloud landing zone | What each upper layer adds |
|---|---|---|
| Identity | Workforce and workload identity, groups, privileged access | Data: purpose-based access. AI: per-workload gateway keys. Agentic: agent identities with sponsors |
| Logging and audit | Central log store, retention, tamper protection | Data: lineage. AI: prompt and response telemetry rules. Agentic: action evidence records |
| Policy as code | Allowed services, regions, configurations | Data: classification rules. AI: approved models. Agentic: authority grants |
| Network | Hub, egress, private endpoints, DNS | AI: private model endpoints. Agentic: tool egress allow-lists |
| Recovery | Backup, restore, regional design | Data: reproducible datasets. AI: model and index recovery. Agentic: resumable state |
| Cost | Tags, budgets, chargeback | AI: token spend per workload. Agentic: cost per completed task |
| Security monitoring | Threat detection, incident process | Agentic: kill switch, revocation and quarantine |
Read across any row and the pattern is the same. The base control is built once, and each layer adds only what is genuinely new to it. If your AI team runs its own log store or your agent team runs its own identity provider, a shared control has been duplicated, and the copies will drift.
Some controls are separate by nature. Classification belongs to the data layer, evaluation thresholds to the AI layer and authority grants to the agentic layer. No amount of network or policy work in the cloud landing zone can substitute for them.
Which foundation must come first
Each layer depends on the one below in a specific way.
- Data needs cloud. Without shared identity and policy, data access is granted by sharing keys, and classification cannot be enforced.
- AI needs data. Without published data products, grounding reads raw copies, permissions do not survive the trip and evaluations are not reproducible.
- Agents need AI. Without approved models and release thresholds, an agent's reasoning is untested, and no amount of authority control makes an untested planner safe to act.
- Agentic action needs all three. An agent's grant refers to data it may read, models it may use and systems it may change. Each of those must already be governed.
This does not mean finishing each layer before starting the next. It means extending each layer only as far as the workload in front of you needs, and never skipping one. Blyde's first AI workload used two data products, not the whole catalogue. Its first agent used one model and three tools.
The order also explains a common failure. Organisations under pressure to show AI often start at the top, with an agent demo, and discover the missing layers in production. The series close in part 10 turns this order into a roadmap.
One fraud workload through four layers
Blyde's fraud operations team receives thousands of card-fraud alerts a week. The new workload helps an analyst triage each alert. It gathers evidence, scores the alert, drafts a case summary and, where the rules allow, places a temporary hold on the card while the analyst reviews. Volumes and steps are illustrative.
| Step | Layer that governs it | What the layer provides |
|---|---|---|
| Alert arrives from the card platform | Cloud | Private connectivity, workload identity, central logging |
| Transaction history and previous cases are retrieved | Data | Published data products with owners, classification and access by purpose |
| A fraud model scores the alert | AI | Approved model version, evaluation on a labelled set, monitoring for drift |
| A language model drafts the case summary | AI | Gateway, versioned prompt, release threshold, telemetry rules for personal information |
| The agent proposes a temporary card hold | Agentic | Agent identity and sponsor, grant check, policy before action |
| The hold is placed, or waits for the analyst | Agentic | Risk tier: automatic below a threshold, analyst approval above it |
| Every step is recorded for audit and complaints | All four | Shared log store, lineage, prompt telemetry and the action evidence record |
The table also shows where an incident would be investigated. If the summary is wrong, the AI layer's evaluation and prompt history are the evidence. If the hold was placed on the wrong card, the agentic layer's grant and evidence record are. If the transaction history was stale, the data product's quality results are. Four layers with clear boundaries give four places to look, not one large argument.
Fraud is also an area where agents widen the attack surface as well as the defence. Agentic banking expands the fraud surface covers that side of the problem.
Who owns what
Layers with clear boundaries still fail if nobody is accountable for the decisions between them. Blyde's responsibility map puts each recurring decision against the teams involved.
Three decisions are worth calling out.
- Data classification is carried out by the data office, but the business owner is accountable, because only the owner knows what the data means.
- Release thresholds are set and owned by risk, and measured and enforced by the workload and AI platform teams, as described in part 7.
- The agent authority grant is the decision most organisations leave blank. The business owner is accountable for what an agent may do, not the AI team that built it. The workload team proposes the grant, and platform, AI and risk are consulted.
Landing zones are products, not one-off projects argued that each layer needs a product owner. The responsibility map is how those product owners avoid stepping on each other.
Anti-patterns to avoid
- Four estates. Separate tenants, identity models or log stores for data, AI and agents. Each looks faster at first and becomes an integration project later.
- One giant team. A single central team that owns every layer and becomes the queue for every workload. The centre sets rules and runs shared services, and domain and workload teams build on them.
- Starting at the top. An agent pilot before data products and evaluation exist. It will either stay a demo or reach production without its foundations.
- Treating the layers as stages that end. Each layer is a product with a backlog. The cloud landing zone does not stop changing when the data landing zone starts.
A readiness check across the four
| Layer | Ready for the next workload when... |
|---|---|
| Cloud | A new application landing zone can be issued in days with identity, policy, logging and recovery already in place |
| Data | The workload's data exists as published products with owners, classification, quality results and access by purpose |
| AI | The model is approved, the prompt is versioned, an evaluation set exists and the gateway attributes cost |
| Agentic | The agent has an identity and sponsor, a signed grant, policy enforcement before action, an approval path and a tested kill switch |
Key points
- Cloud, data, AI and agentic landing zones are four layers on one estate, not four estates.
- Build shared controls (identity, logging, policy, network, recovery, cost, security monitoring) once, and add only what is new in each layer.
- Classification, evaluation thresholds and authority grants are separate by nature and cannot be inherited from the layer below.
- Extend each layer only as far as the current workload needs, and never skip one.
- A business owner, not the AI team, is accountable for what an agent may do.
This is part 9 of Cloud Foundations, Explained End to End. Previous: Agentic landing zones: from governed intelligence to governed action. Next: A 12-month landing-zone roadmap for a mid-sized organisation
How CloudNala can help
CloudNala helps organisations that have started building data, AI or agent platforms in parallel to bring them onto one foundation. We map which controls are duplicated across teams and which are missing. We then design the shared and layer-specific controls and agree a responsibility map with the platform, data, AI, risk and business owners, so that the next workload crosses all four layers without four separate negotiations.
Background reading: Microsoft, What is an Azure landing zone?; AWS, What is AWS Control Tower?; Google Cloud, Landing zone design.
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