Enterprise Data Isolation Strategies for AI Governance

Every enterprise procurement cycle for AI tooling hits the same question: where does our data live, and what separates it from everyone else’s? Feature comparison tables cover model support, pricing tiers, and integration options. They rarely address the question that security architects and compliance leads actually care about — the physical and logical boundaries around AI governance data.

Data isolation is not a feature toggle. It is a deployment architecture decision that determines network boundaries, compute models, and data residency guarantees. Organizations evaluating AI governance platforms need to understand the difference between policy-enforced isolation and architecture-enforced isolation — because procurement officers will ask.

The Four-Tier Model

Arbitex provides four distinct isolation tiers. Each tier represents a different deployment architecture — not a different configuration within the same shared environment. The tier you choose determines the physical and logical boundaries around your AI governance data.

Tier 1: Shared (Multi-Tenant SaaS)

Arbitex manages the full stack — data plane and control plane — in Arbitex-operated infrastructure. Tenants are logically isolated at the API and data layers. Each tenant’s data is encrypted with a dedicated key. DLP pipeline execution, audit logging, and model routing are all tenant-scoped.

Shared tenancy is not a compromise on security. Per-tenant encryption, per-tenant audit chains, and per-tenant DLP pipeline execution are enforced at this tier. The isolation is logical rather than physical, but it is enforced at the API and data layers — not through application-level access controls alone.

This tier delivers the fastest time-to-governance. Deployment is measured in hours. There is no infrastructure to provision, no containers to manage, and no capacity planning required.

Tier 2: Enhanced (Dedicated Partitions)

Arbitex manages both planes with dedicated compute and storage resources allocated per tenant. The tenant’s AI traffic is processed on dedicated instances and stored in dedicated partitions — no shared database tables, no shared processing queues, no shared object stores.

The distinction between Shared and Enhanced is the move from logical isolation to physical partitioning. Network-level segregation within Arbitex-managed infrastructure adds a physical boundary to the logical isolation of the Shared tier. When procurement asks whether your data is physically separated, the answer at the Enhanced tier is yes.

This tier is for organizations that require demonstrable physical separation in procurement reviews and security questionnaires without operating their own infrastructure.

Tier 3: Outpost (Hybrid Deployment)

The customer operates the Arbitex data plane inside their own VPC or on-premises infrastructure. Arbitex manages the control plane — policy management, dashboards, reporting. AI traffic — prompts, responses, and DLP inspection results — is processed and stored entirely within the customer’s environment.

The data plane communicates with the control plane over outbound-only HTTPS. No inbound ports are required. Only policy configuration and anonymized telemetry cross the boundary. The customer’s AI traffic never leaves their network.

Outpost addresses data residency, compliance, and contractual requirements that prohibit AI traffic processing outside the customer’s own infrastructure.

Tier 4: Air-Gap (Isolated Outpost)

The customer operates the data plane with no internet egress. The container image bundles GeoIP data for offline geographic enrichment. Policy bundles sync from a local store. Software updates are distributed as Ed25519-signed bundles for operator-controlled staged application. No startup dependency on external infrastructure.

This tier is designed for defense environments, government agencies operating at IL4/IL5, healthcare isolated networks, and any deployment where outbound connectivity from the governance layer is prohibited.

Per-Tenant Guarantees at Every Tier

Regardless of which isolation tier you choose, five per-tenant guarantees are enforced:

Per-tenant encryption. Each tenant’s data is encrypted with a dedicated key at rest. Key material is not shared across tenants at any isolation tier.

Per-tenant audit chain. HMAC-chained audit logs are scoped to the individual tenant. No cross-tenant log aggregation or commingling of audit records.

Per-tenant DLP pipeline. DLP inspection runs in the context of the requesting tenant’s policy configuration. One tenant’s DLP rules never evaluate another tenant’s traffic.

Per-tenant routing configuration. Model routing rules, provider credentials, and fallback chains are tenant-scoped. No shared model configuration between tenants.

Per-tenant SIEM delivery. SIEM connector configuration is per-tenant. Audit events route to the tenant’s own SIEM endpoint, not a shared collector.

These guarantees are architectural, not policy-based. They are enforced at the API, data, and processing layers — not through access control lists that could be misconfigured.

Choosing the Right Tier

The decision framework is not about security posture alone. It maps to data residency requirements, regulatory obligations, infrastructure capacity, and operational preference.

Choose Shared when your organization does not have strict data residency requirements, cloud-hosted AI traffic processing is acceptable under your compliance framework, and speed of deployment is a priority. Most commercial enterprises, SaaS companies, and organizations without air-gap requirements start here.

Choose Enhanced when procurement or compliance reviews require demonstrable physical separation of compute and storage, but you do not want to operate infrastructure. This tier gives security teams a concrete answer when vendor questionnaires ask about data co-location.

Choose Outpost when AI traffic — including prompt content and model responses — cannot leave your network boundary. This is the tier for regulated enterprises with data residency mandates, contractual restrictions on cloud processing, or compliance frameworks that require on-premises data handling.

Choose Air-Gap when the deployment environment has no outbound internet connectivity. This is not a preference — it is a hard requirement in defense, classified-adjacent government environments, and healthcare systems with strict network isolation mandates.

Regulatory Acceptance by Tier

Compliance frameworks do not always specify which isolation model they require, but they do specify what evidence they expect. Understanding how each tier maps to regulatory evidence requirements helps organizations choose the right architecture before procurement.

HIPAA and OCR investigations. The OCR’s enforcement posture for AI tools focuses on whether the covered entity has a business associate agreement with the vendor and whether PHI in AI requests is governed by documented technical safeguards. Shared and Enhanced tiers meet this requirement when a signed BAA is in place — the per-tenant encryption and per-tenant audit chain provide the documented technical safeguards OCR would review. Outpost and Air-Gap add a data residency argument: if legal counsel requires that PHI never leave the organization’s own systems during inspection, only these tiers satisfy that requirement.

GLBA and SEC Reg FD. Financial regulators focus on the governance record, not the deployment model. For broker-dealers under SEC Reg FD, the relevant requirement is that AI governance records for covered business communications are retained in a non-alterable format for six years. The HMAC-chained audit log is the evidence record regardless of tier. However, for financial institutions with strict data residency under GLBA — where NPI and MNPI in AI prompts cannot transit third-party infrastructure — Outpost is the appropriate tier.

NIST AI RMF (GOVERN function) for government. Federal agencies implementing the NIST AI RMF face a tiering question when the Govern function requires that AI systems use only compliant data handling infrastructure. For agencies operating at IL4 or IL5, the Air-Gap tier is required — the deployment environment itself must satisfy the impact level boundary, and any outbound connectivity from the governance layer may disqualify the deployment. Agencies at IL2 may use Outpost. Commercial cloud use cases can use Shared or Enhanced.

ITAR and EAR for defense contractors. ITAR-controlled technical data and EAR-restricted information in AI prompts are subject to export control requirements that prohibit transfer outside authorized boundaries. Cloud-hosted inspection — where AI prompts cross a third-party vendor’s network infrastructure — requires legal review for ITAR compliance. Arbitex Outpost and Air-Gap tiers keep the inspection boundary inside the customer’s authorized perimeter. No ITAR-controlled data transits Arbitex infrastructure during DLP inspection.

Architecture-Level vs. Configuration-Level Isolation

The distinction matters for procurement. Many AI governance platforms offer “enterprise isolation” that amounts to separate database schemas or API key scoping within shared compute. The network boundary does not change. The processing infrastructure does not change. The isolation is policy-enforced, not architecture-enforced.

Arbitex’s isolation tiers are different deployment architectures with different network boundaries. Moving between tiers involves architectural changes — deploying a data plane in your VPC, for example — not flipping a feature flag. This is deliberate. The isolation guarantee is structural, not configuration-based.

When a security architect asks “can another tenant’s administrator see our data?” the answer is no — at every tier. When they ask “is our data on shared infrastructure?” the answer depends on the tier, and the tier is verifiable in the tenant’s configuration and audit records.

For a complete technical breakdown of each tier — including compute isolation, storage isolation, and network boundary details — see the Data Isolation Architecture page.