Platform organizations — where a central ML infrastructure team supports multiple business units, each with their own ML engineers and use cases — are increasingly common as enterprises mature their ML capabilities. The central platform team builds and maintains the shared serving infrastructure, model registry, and monitoring tooling. The business unit teams train models, own model quality, and manage the business context for their predictions.
This structure creates a governance design problem that purely team-scoped or purely platform-scoped approaches both handle poorly: business units need autonomy over their own models' governance decisions, but the platform team needs portfolio-level visibility and control, and certain controls (data governance, security posture, compliance posture for shared infrastructure) need to operate at the platform level regardless of business unit.
The ownership ambiguity problem
Consider a manufacturing enterprise with three business units: Supply Chain, Quality Control, and Demand Forecasting. Each has its own ML team with three to five engineers. They share a central ML platform team that manages SageMaker infrastructure, the central model registry, and monitoring tooling. Each business unit has its own compliance requirements — Supply Chain models touch vendor contracts; Quality Control models affect product certification decisions; Demand Forecasting models influence financial planning.
Without explicit governance structure, ownership ambiguity appears in three recurring scenarios:
A drift alert fires on the Quality Control defect detection model. The business unit ML Lead is in meetings. The platform team sees the alert in the monitoring dashboard. Can the platform team acknowledge the alert? Should they? Who owns the decision to queue a retrain?
The central compliance team needs an audit report for all models that affected financial decisions in Q3. The Demand Forecasting team's audit history is in their governance records. The platform team has infrastructure-level logs. Neither alone constitutes a complete audit package.
A business unit wants to modify the drift threshold for their search ranking model because the current threshold fires too frequently. The platform team owns the policy configuration infrastructure. The business unit owns the model. Who can authorize the threshold change?
The organizational ownership model
The governance structure that resolves these ambiguities most cleanly is a two-layer ownership model:
Platform team owns: infrastructure availability and security controls; the policy configuration system (the rails that make policies enforceable); cross-portfolio monitoring views; audit log infrastructure and retention; shared compliance posture for the platform.
Business unit teams own: their models' specific policies (the content of the policies, not the infrastructure); their approval chains; their drift thresholds; governance decisions within their model portfolio; producing audit evidence from their governance records when requested.
The platform team is the landlord. Business unit teams are the tenants. Tenants configure their own apartments (policy content, approval chains); the landlord maintains the building systems (infrastructure security, audit log retention, compliance infrastructure). Neither can operate independently of the other, and neither should have unconstrained authority over the other's domain.
RBAC structure for multi-team platform organizations
The RBAC model needs to encode both the organizational boundary (which team owns which models) and the platform-level roles that cut across team boundaries. The roles that need to exist in addition to the standard four:
Platform Admin: Configuration-level access to the governance infrastructure itself. Can modify platform-wide settings, create and delete team portfolios, and assign Team Owners. Should be a small group (two to four people) with the access audited rigorously.
Team Owner: Administrative access within a business unit's model portfolio. Can assign ML Engineers, ML Leads, and Compliance Contacts within their portfolio. Cannot access other teams' model governance records without explicit cross-team grant.
Platform Compliance Officer: Read access to governance records across all portfolios. Export authority for cross-portfolio audit packages. No modification authority. This role satisfies the central compliance team's need for portfolio-level visibility without giving them authority over individual teams' governance decisions.
Cross-Team Delegate: Time-bounded access to another team's model governance actions. Used for shared models (a model that the Supply Chain team trained but the Procurement team also uses), for temporary coverage during personnel gaps, or for external reviewer access. Requires Team Owner approval on both sides. Expires automatically.
Shared models: the governance edge case
Shared models — where one team trains a model that multiple business units depend on for predictions — are the most complex governance case. The training team owns the model lifecycle and retrain decisions. The dependent teams need visibility into the model's governance status (is it drifting? is there a retrain in flight? was it rolled back yesterday?) because changes to the model affect their downstream systems.
The governance solution for shared models is subscription-based notification rather than shared ownership. Dependent teams subscribe to governance events for models they depend on — retrain proposals, promotions, rollbacks — and receive structured notifications that they can act on in their own governance processes (e.g., initiating a retrain of their own downstream model if an upstream model was rolled back). They don't have approval authority over the upstream model's governance decisions; they have visibility into those decisions.
Audit evidence for cross-team reviews
When a central compliance team needs to produce an audit package for a regulator or internal review board, the cross-team governance structure creates an evidence aggregation challenge. The Demand Forecasting team's governance records are in their portfolio. The Quality Control team's records are in theirs. The central platform infrastructure logs are separate.
We're not saying that teams should share governance record storage — the separation of business unit records is operationally appropriate and supports the team ownership model. We're saying that the audit export capability needs to support portfolio-scoped queries that can be executed by the Platform Compliance Officer role without requiring each team to produce their evidence independently and then manually combine the results.
A cross-portfolio audit export that produces governance records for all models whose predictions affect a specific category of outcome (e.g., all models affecting financial decisions, across all business unit portfolios) in a single structured export is the capability that makes a multi-team governance structure auditable at the enterprise level, not just at the team level.
When the governance structure should be reconsidered
The two-layer ownership model works well when business units have meaningful independence in their model governance. It becomes a source of friction rather than clarity when business units are too small (a single ML Engineer per unit means "ML Lead" approval is self-approval), when compliance requirements are highly correlated across all business units (making the team-level separation more overhead than value), or when the central platform team is chronically understaffed and ends up becoming a de facto governance decision-maker for business unit models rather than a platform provider.
The right governance structure follows the organizational structure — it shouldn't be imposed in a way that conflicts with how teams actually make decisions. If the organizational reality is that the central platform team makes most model lifecycle decisions because business units don't have deep ML expertise, the governance model should reflect that reality rather than maintain a formal structure that doesn't match how authority actually flows.