# Model hub

> Centralized AI Trust Layer view of LLM usage across UiPath products, with model status, routing, and replacement controls per tenant.

**Model hub** is a dedicated space within the [AI Trust Layer](./about-ai-trust-layer.md) where administrators and compliance teams can understand how LLMs are used across UiPath products in a tenant or organization.

It gives you a single place to see which models exist and where they run, understand their status, configure routing where supported, and replace models with your own subscription or model. Model hub represents the effective tenant-level state of the governance defined through AI Trust Layer and Automation Ops policies; identity-specific policy assignments for users and groups remain in Automation Ops.

## Benefits of Model hub

| Benefit | What it enables |
| --- | --- |
| Centralized model operations | Work with model usage, status, and routing across products and features, all in one place. |
| Faster compliance posture | Validate which providers and models are used, and how traffic is routed. |
| Lower operational risk | See blocked and deprecated models early. |
| Controlled change management | Track configuration changes and whether a system or a user initiated them. |
| Self-serve custom LLM configurations | Replace supported models with your own subscription (BYOS), or add your own model (BYOM). |

## Organization versus tenant view

Model hub is available as a tab in the AI Trust Layer administration experience, and is accessible at the organization level and at the tenant level. The level determines what you can see and change.

| Aspect | Organization view | Tenant view |
| --- | --- | --- |
| Purpose | A lightweight overview, and a launchpad into the tenant level. | The main configuration space for a tenant's models. |
| Information shown | One card per tenant, with the number of models, the tenant region, and status counts such as Active, Custom, or Deprecating soon. | A grid of the models used per product and feature. |
| Available actions | Browsing tenants and their high-level model status, opening a tenant with **View details**, and starting a custom model with **Add custom model**. | Configuring routing, replacing models, and reviewing configuration history. |
| Limitations | No per-feature configuration, routing changes, or residency settings. | Shows the tenant-level effective state only. |

![Model hub Organization view showing one card per tenant with its model count, region, and model status summary](https://dev-assets.cms.uipath.com/assets/images/automation-cloud/model-hub-org-level-37c7d7c5.webp)

To act on the models in a tenant, see [Managing models in Model hub](./managing-models.md).

## Tenant grid

The tenant grid lists one row per feature and model, grouped by product, with the following default columns.

| Column | What it shows | Why it matters |
| --- | --- | --- |
| Product | Product names, such as Agents, act as group headers; the rows beneath them identify the individual feature or capability using the model. | A product can use multiple models depending on the feature. |
| Model | The model in use. | Identifies what is running in practice. |
| Provider | The model provider. | Needed for vendor governance and compliance. |
| Managed by | UiPath, or Custom for custom LLM configurations (BYOS or BYOM). | Clarifies ownership and responsibility. |
| Model routing | The routing region, where applicable. | Supports residency and continuity reasoning. |
| Model status | Active, Blocked, Deprecating soon | Operational readiness and compliance. |

Status cards such as **Active**, **Custom**, **Deprecating soon**, and **Blocked features** summarize the tenant and filter the grid when selected. The **Columns** control adds optional columns, such as **Default model**, and **Search** and **Filters** narrow the list.

![Model hub tenant grid filtered by the Deprecating soon counter](https://dev-assets.cms.uipath.com/assets/images/automation-cloud/deprecating-soon-models-8dba294e.webp)

### Product and feature visibility

The grid shows only the products and features enabled for your tenant. If a product is not enabled, such as Autopilot or a specific Agent capability, its rows do not appear.

Document Understanding is not yet supported in Model hub. Its models are not shown in the grid and cannot be managed from Model hub.

## How policies are reflected in Model hub

Model hub reflects the AI Trust Layer policies, and the related Automation Ops governance, that apply to each tenant. 

In the tenant view, the **Data residency** banner shows whether a policy applies to the tenant, and lets you act on it. When a policy is applied, it is identified by name, and you can change or remove it from the same place. When the tenant has no policy yet, Model hub guides you to create one, as the starting point for controlling where models run and which models are available.

Policies cover more than residency. An AI Trust Layer policy can:

* Enforce data residency and allowed regions, configured in the policy's Regions tab — see [Data residency](#data-residency).
* Block specific models or providers, for example all OpenAI models.
* Block a product's LLM traffic, for example Autopilot.

When a policy blocks something, the grid reflects it as follows:

* Blocked models or providers appear with the **Blocked** status, and are counted on the **Blocked features** status card.
* If a product's LLM traffic is blocked, the models mapped to that product and its features also appear as **Blocked**.

Policies can be applied at the tenant, group, or user level, but the grid shows the effective situation at the tenant level only. A model blocked only for a specific user or group might not appear as blocked in the grid. Policy assignments and effective settings per identity are available in Automation Ops.

| Policy scope | Reflected in the tenant grid? | Where to validate |
| --- | --- | --- |
| Tenant | Yes | Model hub |
| Group | Not shown (tenant view only) | Automation Ops |
| User | Not shown (tenant view only) | Automation Ops |

## Data residency

The data residency information displayed in Model hub reflects the configuration defined in [AI Trust Layer policies](https://docs.uipath.com/automation-ops/automation-cloud/latest/user-guide/settings-for-ai-trust-layer-policies). Residency enforcement for UiPath-managed traffic is configured in the policy's **Regions** tab, where you define which regions LLM traffic is allowed to route through.

By default, UiPath prioritizes product continuity: products aim to keep working even when a model is not available in the tenant's preferred region, so traffic can route through the closest available region. For example, if a model is not available in Australia, traffic can route to the nearest supported region to keep the product operational.

When you enforce residency, LLM traffic can route only through the regions you allow. If traffic cannot be routed through an allowed region, the request fails, and the dependent product feature can fail with it. This is an intentional trade-off: strict compliance takes priority over continuity.

## Custom LLM configurations

Model hub shows customer-controlled entries with **Managed by** set to **Custom**. A custom LLM configuration takes one of two forms:

* Bring Your Own Subscription (BYOS): the same supported model, running on your own subscription.
* Bring Your Own Model (BYOM): a model outside the predefined list for the product.

Because custom entries are customer-controlled, residency, policies, and deprecation apply to them differently:

* The **Model routing** column is blank for custom entries. This is expected: UiPath does not infer routing from or configure your custom model endpoints.
* Residency policies control where UiPath routes UiPath-managed traffic only. A custom entry is not blocked when a UiPath-managed model is unavailable in an allowed region because routing for custom models is determined entirely by your endpoint configuration. Meeting your residency requirements depends on hosting and configuring your endpoints in compliant regions.
* You own the lifecycle of any custom LLM configuration. When a model you use through one is deprecated, UiPath notifies you, and your administrators are responsible for migrating to a replacement before the deprecation date. The migration steps are described in [Managing models in Model hub](./managing-models.md#replace-a-model).

If a custom configuration is missing, outdated, or incorrectly configured, it can stop functioning. In that case, the system automatically reverts to a UiPath-managed LLM to maintain continuity, unless UiPath-managed LLMs are disabled through an Automation Ops policy — then requests fail, and the features that rely on the model can stop working.

The setup and replacement procedures are described in [Configuring LLMs](./configuring-llms.md) and [Managing models in Model hub](./managing-models.md).

## Model status and deprecation

The **Status** column shows where each model is in its lifecycle.

| Status | Meaning |
| --- | --- |
| Active | The model is available for use. |
| Deprecating soon | The model will be retired on a known date, shown in the status details together with the replacement model. Testing and migration are recommended. |
| Preview | The model has limited support, including for residency. |
| Blocked | The model or its traffic is blocked by a policy. |

For details on model lifecycle, see:

* [LLM model lifecycle](https://docs.uipath.com/overview/other/latest/overview/llm-model-lifecycle)
* [LLM model deprecation timeline](https://docs.uipath.com/overview/other/latest/overview/llm-model-deprecation-timeline)