AI Hub --> Project Structure In Microsoft Foundry

hi amol_pol​ Great question — you’re definitely not alone in running into this, and what you’re describing is a very common pattern in larger enterprises adopting Foundry at scale.

Short answer: Today, AI Foundry doesn’t have a native “third layer” (like portfolios / programs / nested hubs). The Hub → Project model is intentionally simple, but it does create friction once you move beyond a single team or department.

That means most organizations end up solving org-level governance outside of Foundry’s structural model, rather than inside it.

How teams are handling this in practice:

1.Treat Hubs as department-level execution units

Your instinct here is right:

One Hub per department or domain

Projects under the hub for workloads, products, or teams

Department-level governance, budgets, and shared resources live here

This maps well to ownership and chargeback.

2.Move org-level governance up to Azure management layers

Instead of expecting Foundry to model org structure, teams are enforcing it via Azure primitives:

Management Groups

Org-wide policies (regions, SKUs, allowed models, networking)

Security baselines

Azure Policy / Initiative

Model restrictions

Logging / diagnostics enforcement

Network isolation requirements

RBAC patterns

Central platform team has read / policy roles across hubs

Departments have full control only in their own hub

Foundry then becomes one workload type governed by Azure, not the place where governance logic lives.

3.Create a “virtual portfolio layer” via tagging + metadata

Since there’s no native rollup layer, most teams simulate one:

Mandatory tags on hubs and projects

OrgUnit

Program

DataDomain

CostCenter

Use these tags for:

Cost rollups

Security reviews

Reporting dashboards (Cost Management, Log Analytics, Power BI)

This gives you cross-department visibility without restructuring hubs.

4.Centralized observability instead of centralized structure

Rather than forcing everything into one hub, teams centralize:

• Logs
• Metrics
• Evaluations
• Cost exports

This allows:

• Org-level reporting
• Program-level insights
• Department-level autonomy

In practice, visibility scales better than hierarchy.

I’d recommend as a minimum “operating model”

Until Foundry evolves:

Org level

• Azure Management Groups
• Azure Policy + Cost controls
• Central monitoring

Department level

• One Hub per department/domain
• Department-owned governance and budgets

Program level (cross-dept)

• Tagging + reporting
• Shared standards and templates
• Possibly shared CI/CD patterns

Curious to see how others reply — especially if anyone has found a cleaner pattern or heard roadmap signals from Microsoft.