An organisation can deploy Microsoft Foundry behind a private endpoint and still not have a production-ready AI capability. The network may be private while nobody is sure who owns the answers. Identity may be centralised while an agent holds more authority than anyone intended. Retrieval may use approved documents while ignoring whether the person asking may see each one. Monitoring may record latency and token counts while nobody measures whether the answer was right.
None of these are solved by adding more Azure icons to a diagram. They are solved by deciding boundaries, responsibilities, flows, policies and evidence. This six-part series works through those decisions in order: platform and product boundaries, network paths, identity and model access, retrieval, agent authority, and finally the operating model that keeps the whole thing honest after go-live.
This series was prompted by Gajanan Hatkar's article, Building a Secure Enterprise Azure AI Foundry Platform: From Architecture to Implementation (23 September 2026). His reference architecture brings Foundry, API Management, Private Link, AI Search, Cosmos DB, Storage, Entra ID, Azure Monitor and Terraform into one useful platform view. CloudNala's series takes that technical foundation as given and extends it into the decisions around it: ownership, product isolation, agent authority, evaluation, support, cost and the South African regulatory context.
A private AI platform controls where traffic can travel. A production AI capability also controls who can act, what the system may know, how quality is measured, who owns failure and what evidence is kept.
How the first deployment becomes a platform by accident
Fynbos Health Administrators is fictional, and its systems and figures are illustrative. Fynbos is a South African medical scheme administrator with its head office in Century City, Cape Town. It has about 2,200 staff, administers four medical schemes with about 380,000 members between them, and runs contact centres in Cape Town and Durban. It already has Microsoft 365, Entra ID and an Azure landing zone in South Africa North, run by a six-person cloud platform team.
In January 2026 an innovation team built the Policy Assistant, an internal tool that answers staff questions about HR and operations policies from the company's SharePoint libraries. They created one subscription, one Foundry resource and one project, connected a model, added Azure AI Search, left public network access on and put an API key in the app's configuration. It worked, and staff liked it.
By April, two other teams had noticed. Member Services wanted a copilot for contact-centre agents answering member questions about benefits, claims and co-payments. The claims team wanted an agent that could look up a claim during a call, draft a resubmission and log a service ticket. Both asked the same thing: could they "just add a project"?
That is the moment most organisations miss. The first project was quietly becoming a shared platform, without anyone having designed it, funded it, secured it for member health data or agreed who would support it at two in the morning. Fynbos stopped, formed a four-person AI platform team, and drew the boundaries first.
Four things that are easy to confuse
The vocabulary matters, because each term implies a different owner:
- An AI product solves a defined user or business problem: the Policy Assistant, the Member Desk copilot, the Claims Query agent.
- An AI platform supplies reusable capabilities and controls to several products: approved models, provisioning, a gateway, guardrails, telemetry standards.
- An Azure landing zone supplies the enterprise cloud foundation everything runs on: subscriptions, policy, connectivity, DNS, identity integration and security monitoring.
- An operating model defines who makes decisions, who supports the service and who accepts the risk.
Putting all of it in one subscription or one Foundry project does not make it a platform. It makes one large shared failure and trust boundary, where a change for one product can break another and nobody can say where one team's responsibility ends.
The four-layer ownership model
Microsoft's current Foundry design gives you a useful technical hierarchy. A top-level Foundry resource (an Azure resource of type Microsoft.CognitiveServices/accounts) is where security, connectivity and model deployments are governed. Projects sit beneath it and, in Microsoft's words, provide boundaries for access control, files, agents and evaluations. The Foundry architecture overview describes this split.
That hierarchy needs to sit inside a wider enterprise model:
| Layer | Typical owner | What belongs here | What should not be hidden here |
|---|---|---|---|
| Enterprise landing zone | Central cloud platform team | Management groups, subscriptions, policy, connectivity, DNS, security monitoring, identity integration | Product prompts, business rules or answer-quality acceptance |
| Shared AI platform | AI platform team | Foundry resources, project vending, approved models, model gateway, common guardrails, telemetry standards | Ownership of every product's knowledge and business outcome |
| AI product | Product-aligned team | User journey, orchestration, retrieval logic, tools, business integrations, product evaluation | Enterprise-wide network or identity policy |
| Governance and operations | Joint business and technology owners | Risk acceptance, evaluation thresholds, incident model, cost allocation, lifecycle decisions | Unnamed committees with no decision rights |
At Fynbos, the cloud platform team keeps the landing zone. The new AI platform team owns the Foundry resources, project vending, model onboarding and the gateway. Each product team owns its prompts, knowledge sources, evaluation sets and support. And each product has a named business owner: the Head of HR Operations for the Policy Assistant, the Head of Member Services for the copilot and the agent.
This separation avoids two opposite failures. The first is central bottlenecking: every prompt change, index update and new tool waits in a queue for a platform team that does not understand claims or HR. The second is uncontrolled federation: every product team creates its own models, networking, secrets, logging and safety controls, the organisation pays for the same platform work several times, and nobody can prove that governance is consistent.
What should be shared, and what should not
Share a capability when all four of these are true:
- Several products need it.
- The control should be applied the same way everywhere.
- Owning it centrally does not erase product accountability.
- The failure boundary is acceptable, meaning an outage or bad change affects only what you can tolerate.
Good candidates for the shared platform:
- Approved infrastructure modules, and Foundry resource and project provisioning.
- Standard private networking and diagnostic settings.
- Model onboarding and retirement.
- Central gateway policies for authentication, token limits and usage metrics.
- Evaluation tooling and telemetry conventions.
- Reusable security patterns, cost tagging and chargeback data.
Assets that usually belong to the product:
- System prompts and business instructions.
- Knowledge sources and their access rules.
- Golden test datasets and task-specific quality thresholds.
- Tool definitions and permitted actions.
- Human handover logic, channel behaviour and business service levels.
The test is simple to state and harder to apply: if the platform team changed this, would they need to understand the product's business to know whether they had broken it? If yes, it belongs to the product.
One Foundry resource or several?
There is no universal answer, and the wrong way to decide is by organisation chart. The boundary should follow risk and operations.
| Signal | Favours one shared resource with separate projects | Favours separate Foundry resources |
|---|---|---|
| Data classification | Similar | Materially different |
| Network boundary | Shared | Separate or legally constrained |
| Model catalogue | Common | Different approval or processing requirements |
| Operations | Same platform team and support model | Different operators or service levels |
| Failure impact | Cross-product effect is acceptable | Strong blast-radius isolation required |
| Lifecycle | Similar release cadence | Independent lifecycle or divestment boundary |
| Cost accountability | Project allocation is enough | Resource-level separation required |
| Tenant or legal entity | Same | Different tenant, entity or contract |
Fynbos ran its three products through that table. The Policy Assistant handles staff policies at low to medium classification, and future internal tools will look similar. The Member Desk copilot and the Claims Query agent both touch member health and claims data, which is special personal information under section 26 of POPIA. They need a tighter network boundary, a separate model and processing approval (Part 3 explains why that approval is not a formality in South Africa North), and a stricter support model, because a contact centre with 450 agents notices an outage within minutes.
The decision: one shared internal Foundry resource, with the Policy Assistant as its first project and room for more; and a separate Foundry resource for member-data products, with the copilot and the agent in their own projects. Both sit on the same landing zone and the same platform baseline. That is two resources, not one per use case. Do not create a separate platform for every idea, and do not put the whole enterprise in one resource because it is simpler on day one.
Current Foundry or classic?
One more distinction belongs in every architecture document and bill of materials, because Microsoft's documentation still shows both.
| Area | Current Microsoft Foundry | Hub-based projects (now labelled classic) |
|---|---|---|
| Top-level governance | Foundry resource | Azure AI hub |
| Project model | Project beneath the Foundry resource | Azure Machine Learning project workspace connected to a hub |
| Resource provider | Microsoft.CognitiveServices | Microsoft.MachineLearningServices |
| Design implication | Use current project and resource RBAC, networking and feature guidance | Keep only where existing workloads or classic features require it |
At the time of writing (October 2026), hub-based projects appear only in the Foundry (classic) portal. A diagram labelled just "AI Foundry" is no longer precise enough: state the resource model, the portal experience, the API version and any migration assumptions. Fynbos's Policy Assistant was already on the current model, which made the reorganisation a matter of boundaries rather than a migration.
A simple vending path
Once the boundaries exist, a new product should not need a bespoke project to get started. Fynbos's AI platform team now runs a short, repeatable path:
- Approved use case, with a named business owner.
- Risk and data classification, including what will enter prompts, indexes, traces and feedback.
- Does an existing boundary fit? If yes, create an isolated project under it. If no, create a separate resource boundary.
- Apply the platform baseline: networking, identity, diagnostics, gateway registration, tags and budgets.
- The product team builds and evaluates, and owns what it builds.
The platform team supplies a paved road. The product team stays accountable for the destination.
Before anything is provisioned, Fynbos asks the product's owner to answer ten questions in writing: the business outcome and user group; what information will enter prompts, retrieval stores, traces and feedback datasets; which data classifications are involved; which deployment types and processing locations are acceptable; which models and tools are allowed; who owns prompts, knowledge, evaluations and support; what must be isolated from other products; who approves production and who can stop the service; how consumption will be allocated; and what the exit path is if a model, feature or provider changes.
Views that prove the boundary
A single architecture diagram cannot answer all of that, so do not ask it to. Different readers need different views, and each view should prove something specific:
| View | Audience | What it should prove | What to leave out |
|---|---|---|---|
| Executive capability | Executives and business owners | Value, users, major risks, accountability | Subnets, SKUs, implementation detail |
| Responsibility | Business, product, platform, suppliers | Who owns each layer and decision | A decorative service catalogue |
| Production deployment | Cloud, security, engineering | Components, boundaries, regions, environments, resilience | Business-process detail |
| Identity and trust | Security, IAM, risk | Human, workload, agent and tool identities, and where authority changes hands | Generic "RBAC" labels with no scope |
| Data and retrieval flow | Data, privacy, AI teams | Source, ingestion, permissions, retrieval, inference, retention, deletion | Unrelated platform services |
| Agent action sequence | Business owner, risk, engineering | Intent, proposal, policy, approval, execution, audit | Full Azure topology |
| Operations | Service, SRE, product, FinOps | Signals, evaluation, incident path, cost, ownership | Design-time tooling |
The rest of this series builds most of these views for Fynbos, one part at a time.
Common mistakes
- The cloud shopping list. A diagram showing Foundry, AI Search, Storage, Cosmos DB, Key Vault, API Management, Firewall, Monitor, Defender and Purview, with no indication of why each is there, which are optional, who owns them or how a request flows. Start from the business journey and add a component only when it performs a named responsibility.
- Treating the landing zone as the solution. Pages on management groups and network topology, and a paragraph on the user experience, knowledge and evaluation. The landing zone is a dependency; the product needs its own views and acceptance criteria.
- Letting the first project become the platform. It was built for one use case and one risk level. Draw the boundaries before the second team arrives, not after.
- One resource per use case. Isolation has a cost in duplicated controls and operations. Separate where the signals say so.
- Labelling everything "AI Foundry". Say whether it is the current resource model or classic hub-based projects; the RBAC, networking and features differ.
Evidence a reviewer should ask for
- A named business owner and product owner for each AI product.
- The four-layer ownership table, filled in with real team names.
- The resource and project boundary decision, with the signals that drove it.
- The shared baseline, and the list of what each product team owns outright.
- Written answers to the provisioning questions for each product.
- The stated resource model (current or classic), portal and API version.
What to take from this part
The platform provides reusable controls; it does not own outcomes. Each AI product needs a named owner, a defined boundary and its own evidence of fitness for purpose.
Draw the boundary before the second team arrives. Otherwise the first project becomes a platform nobody designed.
Share what must be consistent, keep what needs domain judgement. Gateway policy is shared; prompts and evaluation sets are not.
Split Foundry resources on risk and operations, not on the org chart. Fynbos needed two, not three and not one.
Next in the series: Private by design: the network paths of an enterprise AI platform.
How CloudNala can help
We help organisations turn a successful first AI deployment into a deliberate platform: defining the landing zone, platform and product boundaries, deciding how many Foundry resources the risk profile actually needs, and writing the ownership model and vending path that let new products start quickly without inheriting the first project's shortcuts.
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 Production Readiness Review or write to us at consult@cloudnala.co.za