By Adam Wolf
Most enterprise AI infrastructure conversations land on the same tension. Builders want self-service: instant access to GPUs, a stable endpoint for a model, a notebook, or a fine-tuning run that starts without a ticket. Platform teams want per-team quotas, identity-aware access, audit trails, tenant isolation, and cost attribution they can defend. Both sides are right, and most platforms make you choose between them because self-service and control get layered onto a base that was designed for neither. ClearML’s position is that the two belong in the same control plane, and the architecture that makes self-service safe is the architecture that makes control enforceable. This piece walks through how that works across compute, data, identity, endpoints, and the security model that holds them together.
Why self-service AI is table stakes
The pressure to offer self-service AI comes from who wants to build with it. Three years ago the people consuming AI infrastructure inside an enterprise were mostly ML engineers, data scientists, and platform teams. Today that population includes finance analysts building agents with Claude Code, operations teams deploying internal AI applications, customer success teams running their own retrieval systems, and researchers training models the central platform never commissioned. Google’s 2025 DORA report found 90% of technology professionals using AI at work, and Stack Overflow’s 2025 Developer Survey put daily AI use among professional developers at 51%, with 84% using or planning to use these tools. The question platform teams are being asked has moved from whether one more model can ship to whether the rest of the company can build without waiting in their queue.
Four control concerns most platforms cannot address together
Self-service without control fails in four predictable ways, and each one traces to the architecture underneath rather than to the intent of the policy.
GPU consumption that nobody bounds. Any team launching any job on any GPU produces contention first and a cost problem shortly after. Quotas, fair-share scheduling, and over-quota rules are what decide the cluster by business priority instead of by who queued the most jobs; per-tenant attribution is what lets finance reconstruct who consumed what; and preemption with graceful abort is what keeps urgent work from waiting behind exploratory work.
Data access that does not match the access model elsewhere. Self-service environments routinely run one identity model for the platform, another for the data stores, and a third for the model registry or the endpoints. Builders hold static credentials, service accounts get shared across teams, and personal API keys live on laptops. The property the enterprise loses is the one that defines its security posture, where identity flows through the system in a single line, and removing access in one place removes it everywhere.
Endpoints that ship without governance. A model running in a notebook is a contained workload. A model reachable from outside the cluster, taking real traffic from real users, is a production system. Platforms that make deployment a one-click action without making access control part of that same action put production systems in front of users the security team never reviewed. The URL works and the audit log does not.
Multi-tenancy implemented as configuration. Many platforms advertise multi-tenancy and deliver namespaces, labels, and conventions. The teams on top share a control plane and an API server, and separation holds only while the configuration stays correct and the workloads stay inside their labels. We made the longer version of this argument in Why RBAC Isn’t Enough, and the short version is that a boundary you can misconfigure is a boundary you will eventually misconfigure.
Identity and RBAC: the foundation
Self-service begins with who, and every other control layer depends on the identity model being right. ClearML federates with the enterprise identity provider through SSO, supporting SAML, OIDC, and LDAP, so a user who joins through the corporate IdP arrives as a first-class identity governed by the same group membership the rest of the organization uses. Group-based access rules then govern what that user sees, which projects they reach, which datasets they read, which queues they submit to, and which endpoints they can call, covering both platform entities (projects, experiments, models, datasets) and hardware resources exposed through queues.
The operational payoff is administrative. Adding a user to the right group grants access, compute, data, and deployment permissions in one step, and removing them reverses all of it. Platform teams manage group membership instead of configuring five access control surfaces every time someone joins or leaves a project.
Resource policies: how GPUs become a governed service
Compute is the dimension most platforms break first. ClearML’s resource policies let administrators define quotas and reservations per user group and hand that capacity to users through execution queues, where each queue matches a resource profile that sets what a job running through it receives. A resource pool is the aggregation underneath, whether that is a Kubernetes cluster, a GPU SuperPOD, or a cloud autoscaler, and administrators set how much of it is available.
Quotas alone leave capacity idle, which is what over-quota allocation addresses. Teams burst above their guaranteed allocation while other teams are not using theirs, and when the owners need that capacity back, ClearML preempts the over-quota jobs and returns it. Preemption is graceful: users register an abort callback, a Python or bash script that runs when the job is stopped, so the work saves a checkpoint and resumes from that state when it is rescheduled. Administrators control which queues allow over-quota access and which users may exceed their limits.
Two capabilities extend the same semantics further. Dynamic fractional GPUs allocate slices per task at the queue level instead of pre-partitioning hardware, reconfiguring the MIG profile on MIG-enabled cards and applying driver-level memory limits with time-slicing elsewhere, and the scheduler counts those fractions against quotas and over-quotas like whole GPUs. The same partitioning approach extends to AMD Instinct accelerators. Spillover rules let work move to secondary capacity when the primary pool is full, with the policy traveling alongside the job.
What makes this self-service is that the whole interaction happens through a queue. The user submits a job, the queue carries the policy, the scheduler enforces it, and the audit log records what happened. Nobody submitting work needs to know which cluster ran it or how the quota was applied. The Policy Manager dashboard gives administrators the other half of that picture: total capacity across clusters, and reserved against idle against over-quota usage.
The AI Application Gateway: endpoints with governance attached
The production endpoint is where self-service most often breaks the security model. The AI Application Gateway is the component that handles that transition at scale, covering HTTPS and raw TCP routing, SSL termination, token-based authentication, and group-based RBAC in a single component deployed alongside the ClearML Server. Production and development environments each get their own namespace-scoped gateway instance with their own tokens, so a misconfiguration in development cannot expose production endpoints.
For production, static routes decouple the external URL from whatever runs behind it, so the URL survives redeployment. Per-endpoint RBAC rejects a valid token when the user is outside the authorized group. Load balancing across instances of the same model includes session affinity, which matters for LLM serving engines such as vLLM and SGLang that maintain a KV cache and need the same consumer landing on the same instance for that cache to pay off.
A model deployed through the gateway inherits its governance posture by default: authentication required, RBAC enforced, endpoint monitored, and audit trail generated. The builder configured none of that, and the platform applied it because the endpoint was created through the gateway. That is what makes one-click deployment safe to offer.
Multi-tenancy: boundaries that hold under load
ClearML’s multi-tenant deployment lets one platform serve multiple teams, or multiple customers in the case of a service provider, with each tenant running its own configuration and user namespace on a single server deployment and its own identity provider integration. The commitment is that isolation is a property of the platform rather than a setting layered on top of it.
Topology is a choice per tenant. Some tenants share GPU pools with dynamic allocation, while others get dedicated clusters where physical separation is required, and administrators pick based on workload sensitivity. For Kubernetes environments where namespaces have been the usual tenant boundary, ClearML supports virtual clusters through SUSE k3k on RKE2, giving each tenant its own Kubernetes API server and control plane running as pods inside the host cluster. Tenants get what looks like a dedicated cluster with full admin access, while the platform team sees quota-governed entries in one list with the same resource policies applied across all of them. Inside each tenant, RBAC handles separation between users and groups, which is the second level that lets a research group and a regulated business unit share infrastructure without reaching into each other’s work.
Observability and audit: the operational layer
A self-service platform that does not produce the right record is one the security team cannot certify, however well access control behaves at runtime. ClearML surfaces per-endpoint request volume, latency, memory, and utilization across CPU, GPU, I/O, and network for active endpoints; attributes compute consumption back to the user, group, project, and tenant that consumed it; and shows queue metrics for what is running and what is waiting. Model deployments, endpoint creation, quota changes, and group membership updates are logged.
The Platform Management Center holds the cross-tenant view, where administrators see consumption across tenants without seeing into the workloads themselves, which is the balance multi-tenant operations need. The same data is available through the REST API, so existing SIEM, observability, and financial reporting systems can ingest it without a custom integration each time. That is what makes the architecture defensible at audit time instead of at incident time.
How the layers compound
The value sits in how these components reinforce each other inside one control plane. A user who authenticates through the IdP and joins a group inherits access rules, compute allocation, endpoint permissions, and audit identity in a single step, and the same group membership that decides which projects they see also decides which queues they submit to and what they spend against. The RBAC rules governing who reads a dataset also govern who deploys a model that consumes it and who calls the endpoint exposing it.
A model deployed through the gateway inherits authentication from its tenant, RBAC from its endpoint group, resource policy from its serving queue, isolation from its parent tenancy, and monitoring from the platform default. The deployment stays self-service and the governance arrives with it, because policy is a runtime property of the workload instead of a wiki page someone was supposed to read before clicking deploy.
The right question to ask
Whether to offer self-service is already settled, since the workforce will use AI either way, and the only open question is whether that use happens inside the platform or around it. The question worth asking is whether the platform underneath is architected so that self-service and control are properties of one system, instead of competing demands managed across separate tools.
ClearML’s position, built over a decade of enterprise deployments across regulated industries, research, and the public sector, is that self-service AI is a platform property. The identity model, the resource policies, the gateway, the tenancy model, and the observability surface belong in the same control plane because they all govern the same workloads. Teams that get this right have a self-service experience the platform team can defend at audit and builders can rely on at the next launch. Teams that do not spend the following quarters reconciling two operating models, two cost ledgers, and two on-call rotations, with the self-service experience eroding each time another control gets bolted on.
If you would like to discuss how ClearML fits into your self-service AI platform strategy, get in touch.