We made the following AI Governance operating model changes.
Important To align with the updated operating model, you may need to perform several post-upgrade configuration tasks. For a comprehensive checklist of steps needed to finalize your environment transition, go to the Required actions section.
Changes to asset type names
The following out-of-the-box asset types are renamed:
| Previously named | New asset type name |
|---|---|
| Foundational AI Model | AI Base Model |
| Deployed AI Model | AI Model Version |
| All subtypes of "Deployed AI Model", for example Azure AI Foundry Model. | Now have the suffix ‘Version’ added to their current names, for example Azure AI Foundry Model Version. |
New asset types
The following new out-of-the-box asset types are added, to deepen our AI platform integrations:
| New asset type | Description |
|---|---|
| AI Model Deployment | The operational instance where a model version is assigned computational resources to execute. |
| AI Endpoint | The access point for external systems that provides a consistent interface for underlying deployments. |
| AI Monitor | The configuration of automated tracking parameters used to observe real-world performance. |
New asset type groups
The following new out-of-the-box asset type groups are added:
| New asset type group | Description |
|---|---|
| Inference Data | Groups asset types that can be used as inference data, such as Table, Storage Container, and File. |
| Output Data | Groups asset types that hold the output generated by deployments, such as Table, Storage Container, and File. |
New relation types
The following relation types are added in analogy to previously existing ones:
| New relation type | Consistent with the previously existing relation type |
|---|---|
| AI Use Case uses / used in AI Base Model | AI Use Case uses / used in AI Model Version |
| AI Model Version is provided by / provides Vendor | AI Base Model is provided by / provides "Vendor |
The previously existing relation types are maintained and form an additional layer in the concept of “inherited governance”. For more information, go to Shifting from manual documentation to inherited governance.
Relation types that are being phased out
In accordance with the new out-of-the-box asset types, we are phasing out relation types for some asset types and introducing others to take their place. This does not mean that the relation types themselves are being phased out. It means that you can now remove them from asset type assignments if you want to do so.
Because they might be in use in your Collibra environment, we did not remove them from any asset type assignments.
| Phased out relation type | Replaced by | Relevant asset type |
|---|---|---|
| Foundational AI Model is deployed by / is deployment of Deployed AI Model | AI Base Model has version / is version of AI Model Version | AI Base Model |
| Foundational AI Model trained by / trains Asset |
No replacement. It is being phased out from the AI Base Model asset type because training data is relevant to specific AI Model Versions. |
AI Base Model |
| Deployed AI Model infers from / used as input for inference of Asset |
AI Model Deployment uses / is used by Inference Data The target is a newly created asset type group Inference Data. This allows you to choose which asset types can act as inference data. By default, this asset type group contains the asset types Table, File, and Storage Container. |
AI Model Version |
| Deployed AI Model has output / is data Asset |
AI Model Deployment produces / is produced by Output Data. The target is a newly created asset type group Output Data. This allows you to choose which asset types can act as output data. By default, this asset type group contains the asset types Table, File, and Storage Container. |
AI Model Version |
| Foundational AI Model is deployed by / is deployment of Deployed AI Model | AI Base Model has version / is version of AI Model Version | AI Model Version |
New attribute types
| Attribute type | Description | Assigned to asset type |
|---|---|---|
| Implemented Content Filtering | Lists activated content filters on an AI Model deployment | AI Model Deployment |
| Initiating User in Source | Shows the user who initiated resource creation in the source system | AI Model Deployment |
| Compute Configuration | Capacity and resources allocated to an asset | AI Model Deployment |
| Traffic Split | Reflects how traffic sent to an endpoint is split between different deployments | AI Endpoint |
| Data Drift Detection | Captures if data drift detection is enabled on the AI Monitor | AI Monitor |
| Prediction Drift Detection Enabled | Captures if prediction drift detection is enabled on the AI Monitor | AI Monitor |
| Schedule | Frequency at which a monitor analyzes data | AI Monitor |
| Alert Configuration | Threshold conditions triggering alerts and the notification channels used | AI Monitor |
| Safeguard Effectiveness | Indicates the effectiveness of safeguards in place (assigned to AI Use Case) | AI Use Case |
| Owner in Source | Text attribute for identifying the owner (assigned to AI Base Model) | AI Base Model |
| Supported Input Modalities | Fundamental types of input a model accepts | AI Model Version |
| Supported Output Modalities | Fundamental types of output data a model can generate | AI Model Version |
| Supported Model Customizations | Available pathways for adapting a model’s base capabilities | AI Model Version |
| Framework | The machine learning framework used to build the model | AI Model Version |
| Tool Usage | Indicates which tools or skills an agent is allowed to use | AI Agent |
Updates to content filtering-related attributes
The attribute type Content Filters is renamed to Required Content Filtering, and a new attribute type Implemented Content Filtering is added. Required Content Filtering is included in the global assignments of the AI Base Model and AI Model Version asset types. Implemented Content Filtering is added to the global assignment of the AI Model Deployment asset type. The plan is to ingest values for Implemented Content Filtering via our AI integrations and allow for comparison with the Required Content Filtering.
Attribute types that are being phased out
In accordance with the new out-of-the-box asset types, we are phasing out the following attribute types. This does not mean that the attribute types themselves are being phased out. It means that you can now remove them from asset type assignments if you want to do so.
Because they might be in use in your Collibra environment, we did not remove them from any asset type assignments.
| Phased out attribute type | Justification | Relevant asset type |
|---|---|---|
| AI System Provider | Phased out in favor of the new relation type “AI Base Model is provided by / provides Vendor", for consistency on how vendor information between AI Base Models and AI Model Versions is captured. | AI Base Model |
| Model Name | The model name is now the name of the asset. | AI Base Model |
| Model Lifecycle Status | This is now identified by the status of the asset. | AI Base Model |
| Version | This is only relevant for AI Model Version assets. | AI Base Model |
| Retrain Cycle |
It is available, however, on the global assignment of the AI Base Model asset type. |
AI Model Version |
Shifting from manual documentation to inherited governance
As AI Governance matures, we recognize the need to stop considering governance as a post-deployment checklist, and start integrating directly in the AI Development Life Cycle (AIDLC).
The challenge is that previously, integrations often only captured a model after it was deployed. This made governance reactive and forced teams to "re-govern" every time a model was retrained.
The AI Governance asset model evolution effectively enables "inherited governance". AI base models and AI model versions are ingested as soon as they appear in your development environment (for example, SageMaker Registry), thereby ensuring immediate oversight.
The new AI model hierarchy
The model is now structured to mirror the reality of MLOps, while enabling a "define once, apply everywhere" workflow.
| Asset type | Primary role | Example | Governance logic |
|---|---|---|---|
| AI Base Model | The "parent" identity. It forms a foundational business concept that defines the model's purpose and governing principles, remaining constant across all technical iterations." | A business user who talks about the credit scoring model. | Define core rules: Ownership, intended use, and general risk policies. |
| AI Model Version | The technical artifact. A specific, immutable implementation of the model logic and parameters that serves as the audited "raw" model version before it is activated. |
The technical implementation of the credit scoring model:
|
Inherit and refine:
|
| AI Model Deployment | The deployment of an AI model version on specific compute resources. This is where inference data is being processed and transformed into output. |
|
Monitor and enforce: The operational level where the rules are tested against real-world performance. |
| AI Endpoint | The stable interface. A specific network address or API gateway through which a model is accessed, providing the bridge between an AI Model Deployment and the consuming applications. | Credit scoring model access point. | Subscribe: The permanent link for consumers and data products to access the model. |
Key concept: Inherited governance
This is our primary value proposition for reducing manual effort for AI teams.
"Define once" principle
At the base model level, users define the global context:
- Who owns this?
- What is the risk tier?
- Which regulatory frameworks apply?
These rules automatically flow down to every version and deployment. Data scientists no longer have to fill out the same fields every time they retrain a model.
Additive sensitivity
Governance is not one-size-fits-all. While a version inherits the rules of the base model, it allows for additive governance. For example, If model version 2.0 uses a more sensitive training dataset than version 1.0, the user can add stricter safeguards specifically to that version. The system combines the base rules with these version-specific requirements.
Operationalizing the rules: the deployment level
The AI Model Deployment asset is where the rubber meets the road. This asset links directly to the technical monitoring jobs in the AI platform. The purpose is to compare the rules defined at the base or version level against the reality, which is observed during monitoring at the deployment level.
Required actions
Ensure that you read through the following sections and take the required actions as necessary.
Re-run your integrations
If your AI model assets were created by one of our supported integrations, re-running the integration is the recommended first step, as this automatically cleans up phased-out relations and replaces them with new ones.
Evaluate your custom workflows
If you customized workflows or built integrations for AI Governance that use scripting logic to retrieve asset types, relation types, or attribute types by name, instead of UUIDs, review and test them to ensure they align with the updated asset model.
Note To ensure workflow stability, we recommend using UUIDs or public IDs rather than display names when retrieving asset, relation, or attribute types. Unlike names, these identifiers remain constant even if the aspects of the operating model are renamed.
Optimize your metadata
To ensure your environment fully leverages the updated operating model, review the following steps and implement adjustments where necessary. We recommend doing this at your earliest convenience; however, existing uncleaned data will not cause technical issues. You can schedule these changes over time; completing them is not required on the day your Collibra environment is upgraded.
When migrating metadata, choose the method based on the volume of your metadata. For smaller volumes, use the UI to manually delete any newly irrelevant attributes and relations, and manually add new relations where necessary. For larger volumes, use the import and export feature.
Delete experimentation data
Usage data often reveals limited attributes or relations of 'phased out' types on non-production instances, indicating manual experimentation with AI Governance. Before migrating metadata, delete test assets, attributes with test values, and relations to test assets.
Evaluate renamed asset types
For assets initially created as Foundational AI Models, evaluate whether they represent a version-agnostic grouping of model versions. If so, keep the asset type unchanged. If they correspond to a specific model version, update the asset type to AI Model Version.
If you have multiple AI Model Version assets that belong together, but lack a linked AI Base Model, create an AI Base Model asset and relate it to the AI Model Version via the relation type "AI Base Model has version / is version of AI Model Version". For assets created via an integration, the integration should handle this.
Evaluate new asset types, relation types, and attribute types
For new asset types, relation types, and attribute types, no action is required of you.
If you have custom workflows or integrations, you can evaluate whether the new types could enhance your logic.
If you are manually adding relations to inference data or output data, or if you do this via a custom workflow or custom integration, evaluate which asset types you want to use as inference data or output data. Update the asset types included in the asset groups, if necessary.
Evaluate phased out relation types and attribute types
For Model Name attributes on AI Base Model assets, ensure that the asset has the correct name. You can then delete the attributes.
For Model Lifecycle attributes on AI Base Model assets, ensure that the asset has the correct status. You can then delete the attributes.
Attributes of the type Version on an AI Base Model assets suggest the asset might have the wrong type. Determine the correct asset type (AI Base Model or AI Model Version) and update it if necessary. If it is truly an AI Base Model asset, delete the attributes.
Replace AI System Provider attributes on AI Base Model assets with a relation of type "AI Base Model is provided by / provides Vendor", linking to a Vendor asset named after the AI system provider.
Evaluate if relations created as "Foundational AI Model is deployed by / is deployment of Deployed AI Model" reflect that the AI Base Model asset (renamed from Foundational AI Model) is the version-agnostic grouping of the linked AI Model Version assets (renamed from Deployed AI Model). If so, migrate the relations to "AI Base Model has version / is version of AI Model Version". Otherwise, decide whether to remove the relations or migrate them to a custom relation type.
Relations of type "AI Base Model trained by / trains Asset" on an AI Base Model asset suggests the asset may have the wrong type. Determine the correct asset type (AI Base Model or AI Model Version) and update it if necessary. If AI Model Version is the correct asset type, you have to migrate these relations to the relation type "AI Model Version trained by / trains Asset". If it is truly an AI Base Model asset, delete the relations.
For attributes of type Retrain Cycle on AI Model Version assets, we recommend migrating the values to the AI Base Model asset.
For relations created as "Deployed AI Model infers from / used as input for inference of Asset", create an AI Model Deployment asset for each deployment using this data for inference. Link the deployment to the AI Model Version asset and connect the inference data to the AI Model Deployment assets via relations of type "AI Model Deployment uses / is used by Inference Data".
For relations created as "Deployed AI Model has output / is data Asset", create an AI Model Deployment asset for each deployment generating this data. Link the deployment to the AI Model Version asset and connect the output data to the AI Model Deployment assets via relations of type "AI Model Deployment produces / is produced by Output Data".
When all attribute types and relation types have been deleted or migrated to another type, remove the unused attribute type or relation type from the assignments of the relevant asset types.
Evaluate customized asset page layouts
We updated the default asset page layouts for AI Governance asset types to reflect all asset model changes. If you customized a layout, it is unsubscribed from the default and remains unchanged to preserve your customizations. We recommend reviewing customized layouts to align them with these asset model changes. You can choose one of two approaches:
- If you only reordered characteristics or changed sections, consider reverting to the default layout to resubscribe to future automatic updates.
- If you added custom characteristic types that you want to keep, manually add new out-of-the-box relation types and attribute types to the layout.