Most RBAC implementations in software engineering divide the world into admin, editor, and viewer. That taxonomy doesn't map cleanly onto an ML team's actual permission structure, where the interesting questions are not "can you read this file" but "can you approve a model going to production" and "can you override a retrain policy that another team set."
ML governance RBAC has to model decisions, not just data access. That requires a different set of primitives — and it requires designing those primitives before you have 30 models in production and a compliance team asking who approved the last retrain on the fraud classifier.
The four roles that matter in ML model governance
Based on how enterprise ML platform teams actually structure accountability, there are four roles that need distinct permission sets in a model governance system:
ML Engineer: Creates and updates model artifacts, runs training pipelines, submits retrain proposals. Does not have unilateral promotion authority. Can view model metrics, drift signals, and governance history for models they own. Cannot modify policy configuration.
ML Lead: Reviews and approves retrain proposals for models in their domain. Can modify policy configuration for their models, subject to Compliance Owner co-approval for regulated models. Has rollback authority within their model portfolio. Can delegate approval to other ML Leads but not to ML Engineers.
Compliance Owner: Co-approval authority on policy changes for regulated models. Can view all governance events across the platform. Cannot directly trigger retrains or modify model artifacts. Has export authority for audit evidence packages. The compliance role is read-heavy and approval-heavy — not engineering-heavy.
Data Steward: Controls access to training datasets and feature definitions. Can gate whether a retrain pipeline is allowed to use a specific dataset version. Does not have model promotion authority but does have veto authority over training data usage. This role is often overlooked in RBAC designs and creates a gap when data policies change without model policies being updated.
Permission objects: what needs to be scoped
In a model governance context, permission objects are not just files or API endpoints. The objects that need explicit access control are:
Model artifacts: Read, write, promote, rollback. Not all four need to be granted together. An ML Engineer typically needs read + write (for their own models) but not promote or rollback. A production SRE might need rollback authority without write access.
Policy configuration: Read, propose change, approve change. Policy changes should require a proposer and an approver at minimum — they're governance events themselves.
Retrain proposals: Submit, approve, reject, cancel. Submit is for ML Engineers and automated systems. Approve and reject are for ML Leads and Compliance Owners. Cancel should be limited to ML Leads and above.
Audit logs: Read (own team), read (all), export. Compliance Owners need read-all and export. ML Engineers should see their own models' governance history but not necessarily the full cross-team audit log.
Drift alerts and monitor configuration: Who can acknowledge an alert (suppressing it for a configured window) vs. who can modify the threshold that generates it. These should be separate permissions — alert suppression should be available to ML Engineers; threshold modification should require ML Lead or above.
Scoping permissions to model boundaries
A significant RBAC design question for platform organizations is whether permissions are global or model-scoped. Global permissions ("ML Lead can approve any model's retrain") are simpler to administer but create problems in multi-team environments where business units have different risk profiles and you don't want a fraud team ML Lead accidentally approving a clinical risk model retrain.
Model-scoped permissions solve this but introduce administration overhead. The practical answer for most organizations is to implement team-based model portfolios with global role assignments within a team, and cross-team permissions as explicit exceptions requiring ML Lead approval on both sides.
A growing logistics platform that operates both a route optimization model and a carrier risk scoring model learned this the hard way: their original flat RBAC allowed any ML Lead to approve any model promotion. When a route optimization retrain was accidentally approved by a carrier risk ML Lead who didn't understand the route optimization model's quality gate implications, the resulting rollback took three hours and required reconstructing which approval was valid. Team-scoped portfolios with explicit cross-team delegation would have prevented the ambiguity.
The compliance owner role and its tensions
The compliance role in ML governance creates a structural tension: compliance review should be a gate, not a rubber stamp, but compliance reviewers typically don't have ML expertise and can't meaningfully evaluate whether a model's performance metrics justify promotion.
We're not saying compliance owners should approve or reject based on technical ML metrics — that's the ML Lead's domain. What compliance owners should gate is: is the governance process being followed? Are the required approvers present? Does the retrain proposal include the required documentation (feature change summary, evaluation dataset provenance, policy compliance statement)? Did the model pass quality gates? The compliance gate is a process gate, not a technical merit gate.
This distinction needs to be built into the RBAC model. If the compliance approval UI shows the compliance owner a wall of model metrics, it implicitly creates an expectation they should evaluate those metrics. The interface should show compliance owners the governance checklist they can meaningfully review, not the technical artifacts that are the ML Lead's responsibility.
Temporary elevated access and time-bounded grants
Every RBAC system needs a mechanism for temporary elevated access — the on-call SRE who needs rollback authority at 2am, the external consultant who needs read access to audit logs for a three-week engagement, the ML Engineer who needs one-time promotion authority when the ML Lead is unreachable in an incident.
In an ML governance context, these temporary grants are themselves governance events. A time-bounded elevation of an ML Engineer to ML Lead permissions should be recorded in the audit log: who granted it, for what duration, for which models, and who approved the grant. The grant should auto-expire at its defined time boundary without requiring manual revocation.
Temporary grants that aren't recorded as governance events create the same audit trail gap as unrecorded retrain approvals — you end up with a governance history that shows who had permanent permissions but can't explain why a particular decision was made by someone who wasn't supposed to have that authority.
RBAC and the approval chain configuration
The final piece is that RBAC roles need to be referenced in retrain policy approval chains — the policy configuration should name roles, not individual users. "Requires ML Lead approval" is a durable policy statement. "Requires [email protected] approval" is a fragile dependency on an individual whose org role might change next quarter.
When the approval chain references roles and the RBAC system defines who holds those roles, adding a new ML Lead automatically grants them approval authority on the appropriate models without requiring policy file changes. This is the difference between a governance system that maintains itself and one that requires constant manual synchronization between org changes and policy configuration.