Enterprise AI projects often face the same challenge early: the most valuable data is not on the public internet. It usually sits inside private subnets, behind firewalls, route controls, and access policies that were designed to protect sensitive business systems. This pattern is especially common in regulated and data-sensitive environments such as financial services, healthcare, and other industries where trusted private data must remain inside controlled network boundaries. Enterprise AI around trusted private data and governed execution, and Oracle AI Data Platform (AIDP) is built to support that model. (blogs.oracle.com)
Enterprise AI = Private Data + Business Semantics + Workflow Embedding |
Accessing Private Data is exactly why private workspaces matter in AIDP. In AIDP Workbench, a Workspace is the logical container for notebooks, files, folders, workflows, jobs, and compute clusters. A workspace configured with private network access enables data sources in Private Data to appear as external catalog in the AIDP workbench. This enables all the compute resources in that workspace to reach data assets inside a private network.
Architecture overview
A typical private data might look something like above. Note that user may not have private data in an AI Lakehouse – it could be anything such as a Oracle Database, Exadata or something else. Nevertheless, the left side shows the customer-controlled private environment inside an OCI region with a VCN hub containing LAKEHOUSE/APEX environment in a private subnet. To provide external access to this AI Lakehouse in AIDP workbench, a private endpoint IP, and a firewall path are created. The right side shows AIDP Workbench with both default compute and a dedicated private workspace. The private workspace enables the connection to the private endpoint for the AI Lakehouse. Inside the overall AIDP Workbench is a typical medallion layers bronze, silver, and gold layers. Note that the Private Data AI Lakehouse appears in the bronze layer as an external catalog.
The key design point is simple: private data stays private, but AIDP can still work with it through a workspace that is explicitly configured for that network. That is, for AIDP to access private-network data, you create a workspace with private network access enabled, select the VCN and subnet, and optionally provide network security group and SCAN proxy details when needed. (docs.oracle.com)
This makes private workspaces more than a networking feature. They are the mechanism that allows AIDP compute to participate in a secure enterprise architecture while still working through familiar platform constructs such as catalogs, notebooks, Spark workloads, and governed data products.
How to setup Private Data access in Oracle AIDP
Pre-requisites
- In order to create a Workspace that can access existing data assets in an existing private network, you need to have the IAM policies to inspect the VCN of the data asset, the subnet of the data asset, and, if network-security-group is used, to inspect the network-security-group of the data asset within their respective compartments. For more information, see IAM Security Policies. Here is an example of exact individual policies you need:
Allow group <group-name> to inspect vcns in compartment <network-compartment-name>
Allow group <group-name> to inspect subnets in compartment <network-compartment-name>
Allow group <group-name> to inspect network-security-groups in compartment <network-compartment-name>Note that you can consolidate all of the above in a single IAM policy for simplicity if you use virtual network family as below:
Allow group <group-name> to inspect virtual-network-family in compartment <network-compartment-name>- For workspace creation, you need the CREATE_WORKSPACE permission or the AI_DATA_PLATFORM_ADMIN role within AIDP. See documentation.
Step 1: Create Private Workspace
During the creation of the private workspace, you will have the option of specifying the networking details of the target data assets. OCI’s documentation lays out a straightforward process for creating a workspace with private network access enabled. This enables network connectivity between the AIDP workspace artifacts and the private data.
Note that users can expand the “Advanced options” section for additional network security group details of the destination data assets as seen below:
Step 2: Create an External Catalog
In the next step, users will create an external catalog as the representation of the destination data assets. As documented on AIDP documentation page, user use the private workspace created in the previous step to create this external catalog which allows users to access the private data assets using the familiar and convenient 3 part namespace: <<catalog_name>>.<<schema_name>>.<<table_name>>. The example shown below is creating a connection to private Oracle exadata instance:
Step 3: Querying private data with a familiar three-part namespace
External catalog tables can be accessed in notebooks via the 3 part namespace:
spark.read.table("<<catalog_name>>.<<schema_name>>.<<table_name>>")In the example seen below, we are loading the private data in the Oracle exadata in the dataframe and printing the first 5 records:
Using external catalog allows the operational complexity to stay behind the scenes, while the developer experience stays familiar using the 3 part namespace. Once the private workspace and external catalog are set up correctly, teams can discover the catalog in AIDP and query it using the same namespace pattern they already use elsewhere in the platform. For enterprise teams, that is a major advantage: private infrastructure can remain private, while access becomes standardized and governed through AIDP.
Security & Private Data Governance
One of the strongest parts of this model is that access to private data is not only controlled by network setup alone. Once the source is surfaced into AIDP as an external catalog, teams can use AIDP RBAC roles to manage who can discover, query, and work with that catalog inside the platform. That gives administrators an additional governance layer on top of OCI network and IAM controls, which is especially important in enterprise environments where access needs to be granted intentionally, reviewed regularly, and aligned with team responsibilities rather than shared broadly.
This is especially relevant for industries like financial services, healthcare, and other regulated sectors, where core data systems often cannot be exposed publicly just to support AI or analytics workloads. Private workspaces provide a practical way to bring AIDP compute to the data, instead of moving sensitive data into a less controlled environment.
Final takeaway
Private workspaces are one of the most important features for making Oracle AI Data Platform practical in real enterprise environments. They provide a secure and governed way to let AIDP compute access private data without requiring that data to be exposed publicly or moved into a less controlled environment. Once configured properly, that private data can appear as an external catalog and be queried using the familiar three-part namespace, which makes the experience much more natural for data engineers, analysts, and data scientists working inside AIDP.
For more information, please visit: