Forum Discussion
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.