FAQs for AI Governance

OneTrust recommends creating an AI System in AI Governance when developing, deploying or using an AI solution for an approved use case.

Using the AI System object enables tracking and management of an AI system's lifecycle, including design, deployment, and ongoing monitoring. The AI System object allows you to document and manage the AI system's key details, including its purpose, design specifications, compliance with regulatory requirements, ethical considerations and performance. It also facilitates continuous monitoring and risk management throughout the AI system’s operational life, ensuring transparency, accountability, and alignment with governance policies.

OneTrust recommends using a Project over AI System when:

Exploring a new use case

that will likely involve AI as part of the solution.

Acquiring an asset

that integrates AI in its operation or functionality.

Using the Project object helps facilitate due diligence by allowing you to assess the use case through a governance lens. It supports the consideration of regulatory requirements, potential risks, and ethical implications before implementation. The Project object also enables you to document objectives, privacy, security, and ethical concerns, capture results from initial experiments or proof-of-concepts (POCs), and evaluate the data being used, even in the early stages of project approval.

An AI System refers to a specific solution that is designed to perform a task or solve a problem using AI. It includes the technical details of the AI itself, such as models, datasets, training processes, and performance metrics.

• Examples: Customer-facing chatbots, production recommendation engines, automated decision systems, deployed computer vision systems, operating fraud detection models

An Asset refers to a broader resource or technology that is used or acquired by the organization, which may or may not involve AI. Assets can be hardware, software, data sets, third-party products, or services.

• Examples: Databases, cloud computing platforms, content management systems, productivity platforms

Let’s use an example scenario.

If planning to leverage DataGuidance Copilot, create an Asset record to track the use of DataGuidance technology within your organization. Link the OneTrust Vendor record to this Asset as OneTrust is the provider. Link your organization as the Entity that will be deploying the product/service.

Then create a Project record in AI Governance to assess the DataGuidance Copilot product offering for understanding and documenting it’s capabilities, risks, adherence to regulatory requirements, enforcing implementation of controls, privacy, security and ethical considerations, etc. Ensure to link the DataGuidance Asset record to this project.

If the AI Governance committee approves the use of DataGuidance Copilot, you have the ability to promote this Project record to an AI System and track it throughout it’s deployment lifecycle and post deployment for monitoring. The Project, Asset, Vendor and Entity records gets linked to this AI System automatically upon promotion.

An AI System represents the operational AI capability or application delivered to users or downstream systems. An AI Agent represents a runtime component that performs tasks within that system.

In simple terms:

• AI System = what the business deploys

• AI Agent = how work gets done at runtime

Yes. The current product supports AI Agents as standalone records. However, for most customer implementations, it is clearer to treat agents as components of an AI System, unless the architecture is explicitly agent‑first.

No. Many AI Systems, especially traditional predictive or rules‑based systems, do not require an agent layer. Only create AI Agent records when there is meaningful orchestration, autonomy, or tool‑enabled behavior to govern.

Assessments can attach to multiple inventory types.

Projects

assess the use case or initiative

AI Systems

assess the deployed capability

Models or AI Agents

assess technical or behavioral risk

Today, policies can evaluate attributes and metadata on AI Agent records, including seeded and custom fields populated manually or through automation. Policy support for richer runtime or evaluation‑driven signals is expected to expand over time.

AI Automation collects metadata about the AI assets it discovers, and the exact attributes depend on the connected platform. In general, it can populate shared agent attributes, shared model attributes, system-specific attributes, guardrail attributes, and, for Databricks, dataset attributes. Examples include names and IDs, hosting environment, region, version, model details, deployment status, supported guardrails, and platform-specific fields such as Azure Foundry default model or Amazon Bedrock AgentCore organization. For a full list of supported attributes by platform, see Collected AI Attributes.

After an automation run, discovered records are added to your AI Governance inventory. You can find:

• AI systems in Inventory > AI systems. See Managing AI Systems in AI Governance.

• AI agents in Inventory > AI agents. See Managing AI Agents in AI Governance.

• Models in Inventory > Models. See Managing Models in AI Governance.

• Datasets in Inventory > Datasets. See Managing Datasets in AI Governance.

A successful setup only confirms that the automation was created. If the automation fails later, the most common cause is incorrect credentials. To troubleshoot, review the error details in the automation record. The error messages can help identify the issue.

Check the error details in the automation record.

Deployment takes approximately 20–30 minutes end-to-end, including cloud infrastructure provisioning, K3s installation, container image download, and Helm deployment.

No. You can create only one lightweight worker node per tenant. AI Governance and Data Mapping (Privacy Automation) use the same lightweight worker node when the required SKU or license is enabled.

The default disk size is 512 GB across all supported cloud providers. You can increase the disk size during cloud deployment if needed; 512 GB is the recommended default.

Lightweight worker node pods run in the fixed onetrust namespace. This namespace cannot be changed.

One scan per asset-scanner instance can run in parallel.

No. Only metadata, classification results, and health or status telemetry are sent to OneTrust Cloud. Raw data, including database contents and file data, remains within the lightweight worker node VM and your network.

The cloud deployment either failed or was not completed. Select Activate to retry the deployment, or select Delete to remove the worker node resource. If you delete the resource, manually clean up any orphaned cloud resources.

The most likely cause is a network issue. Verify that the VM can reach the OneTrust tenant URL and NATS:

curl -I https://<tenant>.onetrust.com
curl -I https://ot01.nats.onetrust.com

A healthy lightweight worker node has 18 pods, or 17 when AI Guard is disabled.

This is the typical NATS connectivity failure pattern. These three pods require NATS to function. Ensure that ot01.nats.onetrust.com:443 is allowlisted for WSS traffic.

The Administration tab requires dd-workernode-ops to be running. If this pod is down, the tab may show a service-unavailable message. Check and restore the pod before using administration features.

Export details requires K3s, dd-workernode-ops, and NATS connectivity to be functional. If Export details is unavailable, connect to the VM and run:

./debug.sh run

Check the disk-management guidance. The main actions are to delete old installer directories, prune unused container images, restart Loki if necessary, and use reset_wn only as a last resort. Running destructive scripts carries a risk of data loss.

You can confirm this on the worker node tile on the AI automations screen, where the current version is displayed:

Run the following command on the lightweight worker node VM:

cat ~/onetrust-dd-installer-*/data-discovery/litenode-deployment/worker_node_version.sh

You can also view the version in the Activity tab on the Worker details screen.

Check the GoAgent logs:

cat /var/log/goagent/goagent.log

Upgrades run nightly. If the version has not changed, check that the GoAgent service is active and that dd-workernode-ops is running.

Yes. Manual upgrades require network access to the OneTrust API and a stable K3s cluster. Follow the steps in the Manual upgrade fallback section.

No. Deleting the worker node from OneTrust does not delete cloud resources. Manually clean up the VM, VNet or VPC, NSG or security group, and other associated resources to avoid ongoing costs.

Lightweight worker nodes are designed to be replaceable, and scan results are synchronized to OneTrust Cloud. If the VM is lost, create a new lightweight worker node. Datasource credentials stored in Internal Vault are the primary data at risk; back them up before replacing the worker node or performing recovery actions.