Forum Discussion
AI Hub --> Project Structure In Microsoft Foundry
The AI Hub → Project structure works great for a single team. But when you've got a large org with multiple departments, each running their own hub with several projects. I found it doesn't quite fit the deployment model we needed.
Here's the scenario: I create a hub per department, and they can share resources and apply governance across their projects. But I also need org-level policies that apply across all department hubs. And visibility into programs that span multiple departments. With the current two-level structure, I don't have a structural layer for that.
Current options both have tradeoffs:
- Single org-wide hub with departments as projects = lose department-level resource isolation and independent governance
- Separate hubs per department = manually replicate org-level policies, no rollup reporting across departments
For my scenario, it would help if: there was an intermediate level , either nested hubs or an explicit "portfolio/program" grouping, so governance can work at both org and department levels, with rollup visibility.
Curious: are others running into this? How are you structuring org-level governance across multiple department hubs? Looking forward for suggestions on this, how others are doing this.
1 Reply
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.
