Version 11.14.0¶

October 29, 2026

This page contains the following new features, enhancements, and fixed issues for DataRobot's Self-Managed AI Platform 11.14.0 release.

Platform¶

Risk management frameworks now generally available¶

Risk management is now generally available. You can apply a risk management framework to a Use Case, custom model version, registered model version, or deployment, and track how each one meets your organization's compliance requirements throughout the model lifecycle.

When you apply a framework, you select a risk level, or for the built-in EU AI Act framework, complete a short guided questionnaire that sets the risk level for you. DataRobot then checks the asset against the framework's mitigation methods. It marks each method as passing or failing where it can determine the status from the asset's configuration, and reports a compliance score—the percentage of required methods the asset meets. To raise the score, follow the guidance for each method that isn't passing. Pages earlier in the lifecycle show a read-only preview of frameworks applied later, with a link to where you can make changes.

For the EU AI Act framework, obligations are split into in-platform mitigation methods, out-of-platform compliance requirements, and information for downstream providers of general-purpose AI (GPAI) models.

Administrators define the frameworks in Admin settings > Risk management. They can create a framework from scratch or start from a copy of the EU AI Act template, and set the risk levels, requirements, and mitigation methods for each framework. Built-in frameworks can't be edited or deleted. Editing a framework recalculates the compliance score for every asset that uses it.

For more information, see Risk management and Risk management frameworks.

Link more asset types to Use Cases¶

You can now link more Registry, Console, and Agentic AI assets to Workbench Use Cases. Applications and deployments could already be linked. Now you can also link these assets from their actions menu by clicking Link to Use Cases:

• Prompts
• Application sources
• Custom jobs
• Registered models
• Custom models
• Service artifacts
• Deployed workloads

Linking these assets to a Use Case keeps related work in one place, so collaborators can find everything that belongs to a project.

Usage explorer reports LLM usage by hosting type¶

For increased transparency for single-tenant SaaS users, the LLM API usage report in Usage explorer (Account settings) and Tenant usage explorer (Admin settings) is now split into two categories:

• LLM-DR hosted, for usage of LLMs where DataRobot's own provider access is applied.
• LLM-BYOK (bring your own key), for usage where you supply your own LLM provider credentials (for example, through an OpenAI, Azure, or Anthropic account).

Previously, both were grouped together under a single LLM API usage report, which made it harder to distinguish token consumption by source.

Topology spread for LRS deployment replicas¶

The LRS operator now spreads the replicas of deployment-backed LRS (custom model deployments, custom applications, and NIM deployments) across availability zones and nodes. You configure this cluster-wide in the lrs-operator chart. By default, both spreads are preferences and never block scheduling. For deployment-backed LRS, these settings replace the per-LRS ha_topology_key and topology_spread_constraints fields, which are now ignored. Existing deployments keep their current placement rules until their replica count changes.

Before you install or upgrade, see LRS topology spread for the defaults and a checklist for choosing settings.

Clean up unused images and delete old versions¶

You can now delete individual custom model versions and custom environment versions from Registry.

To keep container registries from filling up, resource cleanup scans nightly for images that DataRobot no longer needs—images whose custom model, job, application, or environment was deleted, or that DataRobot does not track. Each scan writes a report and deletes nothing by default. Self-managed system administrators can turn on deletion with triggerCleanup in the cronjob settings, change the schedule, and set the number of images removed per run with RESOURCE_CLEANUP_IMAGE_MAX_N_REMOVALS_CLEANUP in the core chart.

Automate inactive account management¶

System administrators can now automatically disable dormant accounts in their organization, marking them for deletion after a configured period of inactivity. A background job reviews the last activity for each user and, when an account exceeds the configured period, disables the account or marks it for deletion. System administrators set separate periods for regular users and for organization and system administrators, plus a grace period that applies after an administrator re-enables a disabled account. Permanent deletion of a marked account is always a manual action; DataRobot does not delete accounts automatically. Configure the lifecycle in the organization's profile from the Inactive account policy tab of Admin settings > Organizations.

Python client v3.21¶

Python client v3.21 is now generally available. For a complete list of changes introduced in v3.21, see the Python client changelog.

DataRobot REST API v2.50¶

DataRobot's v2.50 for the REST API is now generally available. For a complete list of changes introduced in v2.50, see the REST API changelog.

Issues fixed in Release 11.14.0¶

Code-first fixes¶

• MMM-25361: The Python datarobot-mlops library can now report geospatial coordinates with custom metric values.

Data fixes¶

• DM-19714: Fixes an issue where a dataset owner could lose access to the Spark SQL workspace associated with a dataset after another user added a new version, causing a Data engine workspace state not found error for running, viewing, or sharing the asset. Now, when a new version is created, dataset owners are granted owner access to the associated Spark SQL workspace, while other users with access to the dataset are granted consumer access.

• DM-22761: Fixes an issue where the experiment Features page in Workbench crashed for a numeric feature that has no outliers.

Application fixes¶

• AECO-19: Fixes an issue where users with the Apps Consumer role received a 403 error on the Applications page.

• AECO-608: On self-managed and single-tenant deployments, administrators can set CUSTOM_APP_SIGN_IN_ORG_SSO_NAME to the name of an organization sign-on configuration. Users who open a custom application while signed out are sent to that organization's SSO sign-in page instead of the DataRobot root page.

• AECO-744: Fixes an issue where custom applications were not stopped after the configured idle timeout and continued to run.

Predictive AI fixes¶

• UIUX-17153: Fixes an error on the Lift Chart and ROC Curve insights for models with multiple backtests.

Registry and Console fixes¶

• MMM-25410: For self-managed deployments, including STS, the deployment and workload tag UI now honors the configured limits for tags per deployment, tag name length, and tag value length (MMM_MAX_DEPLOYMENT_TAGS_PER_DEPLOYMENT, MMM_MAX_DEPLOYMENT_TAG_NAME_LENGTH, and MMM_MAX_DEPLOYMENT_TAG_VALUE_LENGTH).

• PRED-13553: The requires_ha field in the custom model workshop is deprecated. High availability is enabled automatically when the replica count is greater than 2.

• PRED-13870: The image rotation job now rotates the images of running inference servers.

• RAPTOR-19617: Fixes an issue where creating a model package with training data from a custom inference model required two concurrent worker slots. On a license limited to one concurrent worker, that job hung and then timed out. The job now runs in a single worker slot.

• RAPTOR-20388: Fixes an issue where creating an execution environment version failed with a 409 error after an older version was deleted because deleted versions were still counted toward the version limit. Deleted versions are no longer included in that count.

• UIUX-17163: Fixes an issue where search in the Registry Jobs list returned no matches for jobs beyond the currently loaded page.

• MMM-25355: Fixes an issue where creating a deployment tag failed with a 409 error when the tag name matched an existing runtime parameter on the same deployment. Tags and runtime parameters are matched separately, so the same name can be used for both.

Platform fixes¶

• CMPT-7359: Fixes an issue, introduced in 11.11.0, where the covalent-env-config ConfigMap set COVALENT_JOB_EKS_IAM_ROLE_ARN to null when no EKS IAM role ARN was configured. Kubernetes drops null keys, so the live ConfigMap never matched the rendered manifest and GitOps tools reported the application as permanently out of sync. The key now defaults to an empty string. If you added an ignoreDifferences workaround for this key, you can remove it after upgrading.

• CMPT-7767: Installing or upgrading with FluxCD no longer fails with "duplicate key: S3_BUCKET" when workload-api is enabled.

• INF-541: GET /api/v2/imageCleanups/{scanId}/report/ and GET /api/v2/cveCleanups/{scanId}/report/ now return 409 Conflict when a scan has not started, is queued or in progress, or has failed, instead of an empty 200 response. The retrieve, report, and cleanup endpoints return 404 when the scan belongs to a different cleanup type. System administrators can use /api/v2/lrsCleanups/ when the RESOURCE_LRS_CLEANUP feature flag is enabled.

• INF-884: Fixes an issue where jobs and image builds could fail to start on large self-managed installations with many deployments. Kubernetes service links add environment variables to each pod for every Service in the namespace. They are now disabled by default for the kubeworkers compute-services, k8s-watcher, and k8s-collector workloads, which keeps the job configuration Secret under the Kubernetes 1 MB limit. To restore the previous behavior, set component.k8s.enableServiceLinks: true in the Helm values.

• PLT-24666: Fixes an issue where users created through just-in-time provisioning were not assigned a Non-Builder seat when the organization had unlimited seat capacity. Those users are now assigned a Non-Builder seat when the account is created.

• PLT-24096: Non-Builder users can now call GET /api/v2/groups/. Applications that authorize users by group membership no longer receive a 403 error for those users.

• PLT-24004: Fixes an issue where permanently deleting a user was reported as completed when deletion failed while removing the user's no-code applications, which left the account partially deleted. That failure is now reported as a failed deletion.

• PLT-23571: Fixes an issue where a new install rendered Secret/auth-server-system-secrets with both secretsSystem and secretsCookie set to the published placeholder insecure-default-must-be-changed. secretsSystem is the Ory Hydra key that protects stored application secrets, and secretsCookie signs session cookies. This affected 11.11.0, 11.12.0, and earlier chart releases on installs that used the chart defaults, including on-premises, STS, and local development. DataRobot-managed SaaS environments are unaffected, because they load these keys from an external secret store. Installs that already supply the keys through External Secrets are also unaffected. The chart no longer falls back to that placeholder. A standard helm install generates a random key on first install and reuses it on later upgrades. GitOps and helm template installs must supply both keys explicitly, because the renderer cannot generate a stable key. A helm upgrade does not replace a key that is already in the cluster, so an install that still has the placeholder keeps it. Contact DataRobot Support for the key rotation procedure. Include auth-server-system-secrets in backups, because the generated key exists only in the cluster.

• UIUX-17168: Fixes an issue where the Cancel and Apply filters buttons on Admin > Organizations > Members were hidden behind the table header, so filters could not be applied.

All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.