Sovereign AI deployment: data residency, control plane location, and regulatory alignment

Updated August 18, 2026

TL;DR: Sovereign AI deployment means your data, governance logic, and audit logs never leave your own infrastructure. Most organizations treat AI sovereignty as a data storage question, but the real compliance risk sits in where the policy enforcement control plane executes and where telemetry routes at runtime. External gateways intercept your traffic from outside your perimeter. A self-hosted control plane enforces standards-aligned policies on every agent interaction before the model call completes, keeping the entire evidence chain inside your defined trust boundary. This matters directly under the EU AI Act and GDPR Chapter V, and for AIUC-1 and ISO/IEC 42001 conformity. This guide covers both patterns: pure self-hosted deployments where every component runs inside your own infrastructure, and hybrid deployments where a self-hosted control plane governs access to external model endpoints.

Most organizations treat AI sovereignty as a data storage question. The more consequential compliance risk sits one layer deeper: where the policy enforcement control plane executes, and where enforcement telemetry routes at runtime. An external gateway that intercepts traffic from outside your perimeter places governance decisions, prompt data, and audit streams on vendor infrastructure, creating transfer and jurisdiction obligations that data storage controls alone cannot resolve.

This guide maps those architectural decisions to the specific regulatory requirements, under the EU AI Act, GDPR Chapter V, ISO/IEC 42001, and AIUC-1, that make the distinction mandatory.

Architecting infrastructure for sovereign AI

The industry has been solving a perimeter problem with a perimeter tool. External AI gateways intercept traffic from outside your perimeter. That architecture means enforcement telemetry, prompt data, and policy decisions all traverse the gateway vendor's infrastructure before returning to your application. For organizations operating under GDPR, the EU AI Act, or ISO/IEC 42001, that routing is not a configuration detail. It is a compliance gap at the architectural level.

A sovereign AI architecture requires three surfaces to stay inside your trust boundary:

• Data storage: All prompt inputs, model outputs, and audit records remain inside your defined perimeter
• Governance logic: Policy enforcement executes locally before any external routing
• Audit logs: Generated and retained exclusively within your infrastructure, consumed by your Security Information and Event Management (SIEM) system

Prediction Guard's self-hosted control plane implements this architecture. The control plane is central processing unit (CPU)-only, so you do not need graphics processing unit (GPU) resources to enforce governance policies. Registered models run on GPU or CPU depending on workload. Developers change only the base_url and governance is enforced transparently.

Architecting for sovereign data storage

Data storage in a sovereign AI deployment covers three distinct surfaces: prompt inputs, model outputs, and audit records. Each carries distinct regulatory risk if it touches external infrastructure.

When a prompt containing Personally Identifiable Information (PII) or regulated financial data is sent to an external gateway vendor, that data transits the vendor's network even if the downstream model is self-hosted. GDPR Chapter V prohibits transfers of personal data to third countries unless specific safeguards are in place. If your gateway vendor's infrastructure is US-hosted and your data subjects are EU residents, that transit is a Chapter V transfer regardless of where your model weights sit.

The sovereign storage design principle is straightforward: no prompt data, no completion data, and no audit log should touch infrastructure you do not own and control.

Infrastructure ownership and AI sovereignty

Infrastructure ownership does not mean you must buy and rack your own hardware. It means the control plane, governance logic, and audit log generation run inside infrastructure you control, whether that is an on-site data center, a dedicated cloud VPC, or an air-gapped cluster. What it explicitly excludes is vendor-managed software as a service (SaaS) control planes that route your telemetry externally.

Prediction Guard's hardware and infrastructure agnosticism applies to model hosting, and governance policy configuration in the Admin Console carries forward regardless of the underlying infrastructure provider.

Mapping regulatory constraints to code

Translating compliance requirements into API calls does not require developers to learn the EU AI Act. It requires architecture that enforces policy at the system level, so the developer's interaction with that policy is zero.

The Prediction Guard control plane is OpenAI-compatible at /chat/completions and /responses, and Anthropic-compatible at /messages. Developers change only the base_url. Every call passing through that endpoint is evaluated against the governance policies security and governance, risk, and compliance (GRC) teams configure on the Govern page of the Admin Console. If a prompt contains PII, the control plane detects and masks it locally before forwarding the sanitized prompt to the model. Compliance teams receive an audit log entry for every governed interaction, and developers ship without changing a line of code.

Mandatory data residency under EU AI Act and GDPR

The EU AI Act and GDPR each impose distinct data governance requirements that affect deployment architecture. The subsections below map those requirements to specific control plane decisions.

EU AI Act sovereign deployment rules

The EU AI Act establishes data governance and data quality requirements for high-risk AI systems under Article 10. Conformity must be demonstrated through verifiable evidence spanning design, development, deployment, and post-market monitoring under Articles 43 and 44, covering the quality management system (QMS) under Article 17, the risk management system across the AI lifecycle, and technical documentation under Article 11 and Annex IV. Article 12 automatic logging requirements further mandate that high-risk systems record inputs, outputs, and decision points to identify risks and substantial modifications.

A high-risk AI system cannot satisfy these conformity requirements with a spreadsheet and a wiki policy. It requires system-level controls that are demonstrably enforced, with evidence that can be produced for a notified body or a market surveillance authority. That evidence must be generated inside your perimeter to remain under your direct control.

GDPR compliance for AI data transfers

GDPR Article 44 states that transfers to third countries are only permitted when the conditions of Chapter V are met. When prompt data containing personal information transits an external gateway vendor's infrastructure located outside the European Economic Area (EEA), the processing occurs on vendor infrastructure subject to a different legal jurisdiction, creating obligations under Chapter V regardless of where model inference runs.

Prediction Guard mitigates this at the source. PII detection and masking execute locally, inside your environment, before any data leaves your perimeter. Where data does transit your perimeter to an external model endpoint, it has already been masked locally. That masking does not eliminate Chapter V obligations, but it does reduce breach notification exposure and strengthens the organization's position when demonstrating appropriate technical and organizational measures under GDPR Article 32.

Navigating regional data sovereignty laws

Beyond GDPR, regional data sovereignty legislation expands the mandatory compliance surface. California's Transparency in Frontier Artificial Intelligence Act (TFAIA), enacted as SB 53, and the Colorado AI Act impose requirements on automated decision systems with obligations that vary by risk classification. A self-hosted control plane allows governance policies to be tailored per region or per department without rebuilding the underlying infrastructure, providing one enforcement architecture across multiple regulatory regimes.

Industry-specific data residency mandates

Sector-specific overlays make the data residency requirements most concrete:

1. Healthcare (Health Insurance Portability and Accountability Act [HIPAA]): AI systems processing protected health information (PHI) must ensure PHI does not transit uncontrolled third-party networks. Local PII masking reduces the volume of identifiable PHI that transits external infrastructure, supporting the technical safeguard requirements under the HIPAA Security Rule, but whether masked data qualifies as de-identified under HIPAA depends on whether the conditions of the Safe Harbor or Expert Determination method are met for that specific dataset.
2. Financial services (SOC 2 Type II): AI systems processing non-public customer financial data must satisfy SOC 2 Trust Services Criteria for availability, confidentiality, and processing integrity. Routing customer financial data through an external gateway vendor introduces a third-party service organization into the audit scope. SOC 2 assessors evaluate not only your own controls but the controls at every service organization with access to in-scope data. Where that assessment has not been completed for the gateway vendor, the processing path creates gaps in your SOC 2 audit evidence.
3. Enterprise governance (ISO/IEC 42001): Organizations pursuing ISO/IEC 42001 certification must demonstrate that governance controls operate consistently across the defined scope of their AI management system. When an external gateway sits outside that scope boundary, the governance evidence it generates may not satisfy a third-party conformity assessor, who evaluates whether controls are uniformly applied and independently verifiable within your own infrastructure. A self-hosted control plane keeps the enforcement path inside the certified scope, so conformity evidence is available for assessor review without depending on a vendor to produce records from their own infrastructure.

Architecting logic for sovereign AI compliance

Sovereign compliance depends on three distinct architectural surfaces: where governance logic executes, how runtime enforcement operates, and where audit logs are generated and retained. Each surface carries independent regulatory risk.

Control plane jurisdiction requirements

If your control plane executes in a different jurisdiction than the data it governs, you have introduced a transfer at the point of enforcement that requires a valid Chapter V legal mechanism, such as Standard Contractual Clauses, an adequacy decision, or another approved basis under GDPR Article 46. Organizations routinely satisfy this through SCCs as a contractual fallback that governs the processing relationship rather than each individual API call. The compliance question is whether that mechanism is in place, documented, and defensible under a transfer impact assessment.

Running the control plane inside your own virtual private cloud (VPC) in the EU, or within the relevant legal boundary, eliminates this jurisdictional gap. When the control plane runs inside your infrastructure, you are the data controller for the governance path, and there is no external processor in the chain from prompt ingestion through policy enforcement to audit log generation.

Securing sovereign AI execution paths

Runtime policy enforcement means intercepting every AI input, tool call, and model response before execution, evaluating it against active governance policies, and either allowing, blocking, or rewriting it. This is not retrospective log analysis. It is a synchronous gate on every agent interaction.

The Open Worldwide Application Security Project (OWASP) Top 10 for Agentic Applications (2026) documents ten risk categories relevant to this execution model:

• ASI01 (Agent Goal Hijack): Requires policy enforcement to intercept agent actions before they complete, because post-hoc detection of a hijacked agent goal after the tool call executes does not prevent the harm
• ASI02 (Tool Misuse and Exploitation): Requires that governance policy evaluate tool call parameters at the control plane before forwarding
• ASI03 (Identity and Privilege Abuse): Requires that access controls at the control plane level determine which registered agents and MCP servers are permitted to call which models and tools at all.

Prediction Guard addresses ASI03 through access controls configured at registration and in policy configuration, which determine whether an agent can call a given model or tool at all. This is system-level policy enforcement, not fine-grained per-tool authorization that independently authorizes each tool invocation at the tool server level. If your compliance requirements include per-tool authorization controls, confirm the specific capability against current product documentation during your deployment scoping process.

Defining audit log retention zones

ISO/IEC 42001 Annex A Control A.6.2.8 ("AI System: Recording of Event Logs") requires that organizations determine at which phases of the AI system lifecycle event log recording is enabled. Prediction Guard's implementation of A.6.2.8 records prompts, tool invocations, outputs, and affected resources as a replayable trace bound to users, sessions, and data sources, consistent with the evidence structure that third-party assessors expect when evaluating conformity.

The architectural requirement is where those logs are generated and who retains them. Prediction Guard generates structured, SIEM-ready audit logs as a byproduct of active runtime enforcement. The control plane formats log output for native ingestion by Splunk, Datadog, and other targets via syslog. Your existing SIEM ingestion pipeline handles delivery. Prediction Guard does not hold SIEM credentials or store logs. Storage and retention are exclusively within your infrastructure.

Mapping infrastructure ownership to legal mandates

Different deployment architectures produce structurally different legal risk profiles. The subsections below map data residency, processor relationships, and inspection rights to the three main architecture patterns organizations evaluate.

Self-hosted vs. vendor-managed control planes

The legal risk profile of different deployment models differs structurally. The table below captures the differences across the three main architecture patterns:

Noma Security offers runtime policy enforcement, but its Kong Gateway plugin requires outbound HTTPS access to api.noma.security on port 443. That routing means enforcement telemetry and audit streams transit Noma's external cloud infrastructure by default, placing governance records outside your perimeter. The relevant architectural distinction is not whether runtime enforcement exists, but where the enforcement decisions and telemetry route. Prediction Guard's honest assessment of Noma and alternatives analysis for regulated industries cover this distinction in depth.

Defining data processor vs controller

Under GDPR Article 28, the data controller determines the purposes and means of processing. A data processor acts on the controller's instructions. When governance enforcement runs on a vendor-managed gateway outside your perimeter, that vendor becomes a data processor with access to your prompt data, model responses, and governance telemetry, creating a Data Processing Agreement (DPA) obligation and extending the processor chain to any subprocessors the vendor uses.

When your control plane runs inside your own infrastructure, there is no external processor in the governance path from prompt ingestion through policy enforcement to audit log generation. For regulated organizations, this simplifies the Article 28 processor chain significantly, though the specific controller/processor determination always depends on your contractual arrangements and processing purposes.

Third-party audit and inspection rights

A self-hosted architecture supports a compliance requirement that vendor-managed control planes cannot: the right of a third-party assessor to logically inspect the system performing governance enforcement. An ISO/IEC 42001 certification body can review your control plane configuration, your policy definitions, and your audit log output when those artifacts exist inside your infrastructure and are subject to your access controls. Under the EU AI Act, many high-risk AI systems in Annex III follow an internal conformity assessment path under Annex VI, where the organization self-assesses without a notified body. In that path, producing verifiable governance evidence from systems you control directly satisfies the self-assessment requirement, rather than depending on a notified body to retrieve records from a vendor's external infrastructure.

Managing subprocessor data residency

External AI APIs introduce a subprocessor risk independent of the primary gateway vendor. An AI Bill of Materials in CycloneDX format provides a structured inventory of these dependencies. EU AI Act Article 11 and Annex IV technical documentation requirements have made this inventory a procurement obligation, not an optional security artifact. Prediction Guard captures models, MCP servers, datasets, and dependencies through AI System registration. The AIBOM in CycloneDX format is the exportable inventory from that registration, not a separate workflow.

Deployment patterns for sovereign AI compliance

Sovereign AI deployment spans a range of architectural patterns, from standard self-hosted control planes to fully air-gapped environments. The subsections below cover five deployment patterns and the regulatory triggers for each.

Architecting for sovereign AI data residency

A sovereign AI reference architecture routes every governance component through the customer's trust boundary. The user application calls the control plane endpoint, which runs inside the customer's own Kubernetes cluster or dedicated VPC. The control plane evaluates the request against active governance policies, masks or blocks regulated data locally, and routes the approved request to a registered model inference server. Audit log output is formatted by the control plane and ingested by the customer's SIEM within the same trust boundary.

For a deep look at how this architecture supports agentic AI workloads at scale, Prediction Guard's analysis of cost, governance, and compliance trade-offs covers the deployment patterns in detail.

Evaluating cloud region residency risks

Hyperscaler "sovereign cloud regions" address data storage residency but do not solve governance sovereignty. AWS Outposts extends AWS compute into customer facilities, and Azure Arc projects on-premises and multi-cloud resources into Azure's management plane. Both are described by their providers as managed offerings, which implies continued operational dependencies on the cloud provider for management, updates, and monitoring. Organizations evaluating these offerings for sovereign AI governance should verify the specific control plane dependency model against their own security and data sovereignty requirements before assuming parity with a self-hosted deployment. For organizations where "sovereign" must mean no vendor has operational access to the systems enforcing AI policy, hyperscaler sovereign regions are insufficient. The distinction is between data storage residency (where data rests at rest) and control plane residency (where governance logic executes at runtime).

Regulatory triggers for private hosting

The regulatory threshold for mandatory self-hosted deployment is clearer than most architecture discussions acknowledge. You need a self-hosted control plane when:

• Any AI workload processes sensitive technical data that your organization has classified as requiring perimeter containment under your security policy or customer contractual obligations
• Any AI agent accesses data your organization or its customers have classified as restricted or confidential, where your security team has determined that data must remain within a defined network boundary to satisfy contractual or regulatory obligations
• Any high-risk AI system under the EU AI Act requires conformity assessment supported by verifiable evidence across the quality management system, risk management system, and event logging requirements under Articles 11, 12, and 17. The EU AI Act does not mandate self-hosting, but producing that evidence is more straightforward when governance controls execute inside your own infrastructure and the resulting records are under your direct access and retention authority rather than a vendor's.
• Any agentic AI workflow processes PHI under HIPAA, PII under GDPR, or confidential customer data within the scope of your SOC 2 program.

Where applicable law or contract requires that regulated data remain within a defined perimeter, the architecture decision narrows from a trade-off analysis to a legal or contractual requirement. For the EU AI Act and the sector-specific thresholds above, self-hosting is not mandated, but it materially changes how hard the evidence is to produce and who controls it.

Architecting sovereign hybrid deployments

Organizations that need access to frontier model capabilities available only through closed-vendor APIs can maintain a sovereign governance architecture. The pattern: self-hosted control plane inside your perimeter, with external model endpoints as registered downstream targets. Every prompt the control plane forwards to an external endpoint has already been evaluated against governance policy, PII-masked locally, and logged. The response is evaluated again before it returns to the application.

OWASP ASI04 (Agentic Supply Chain Vulnerabilities) and ASI07 (Insecure Inter-Agent Communication) both apply to this hybrid pattern. The control plane's registered model and MCP server inventory closes the supply chain visibility gap, and the governance policy on outbound calls closes the inter-agent communication risk.

Air-gapped deployment infrastructure requirements

Air-gapped deployments satisfy the most stringent requirements for national security workloads and defense-adjacent environments handling classified-adjacent data. The Prediction Guard control plane supports fully disconnected, air-gapped deployment with no external network dependencies for policy enforcement. All governance policies, model registrations, and audit log generation execute entirely offline, satisfying the isolation requirements of regulated workloads including HIPAA Security Rule technical safeguards and ISO/IEC 42001 conformity requirements for air-gapped environments. The Prediction Guard EP12 video on self-hosted sovereignty and EP02 video on air-gapped AI for manufacturing walk through implementation patterns in constrained environments.

Mapping compliance requirements to deployment

The architectural decisions covered in earlier sections translate into specific evidence requirements for conformity assessment and regulatory review. The subsections below map evidence to the regulatory regimes already introduced.

Architecting for EU data sovereignty

EU AI Act conformity for high-risk AI systems requires that deployment architecture produce verifiable evidence of governance enforcement across the AI system lifecycle. Notified body conformity assessment focuses on a documented quality management system under Article 17, a risk management system covering the full lifecycle, and technical documentation under Article 11 and Annex IV, including the event logging records required by Article 12. All of these artifacts must be producible from systems within your control. A notified body cannot verify conformity from records that live on a vendor's cloud and are accessible only through that vendor's APIs.

Enforcing residency via control planes

Active runtime enforcement is the mechanism that makes data residency commitments verifiable rather than aspirational. A policy document that says "we do not send regulated data outside our perimeter" is a statement of intent. A control plane that intercepts every agent call, applies PII detection and masking locally, and blocks policy violations before the model call completes is a verifiable control.

AIUC-1's six pillars (Data and Privacy, Security, Safety, Reliability, Accountability, Society) each have operational requirements that runtime enforcement addresses. The AIUC-1 crosswalks at aiuc-1.com/crosswalks map these pillars against the EU AI Act, NIST AI RMF, ISO/IEC 42001, MITRE ATLAS, OWASP large language model (LLM) Top Ten, OWASP AI Vulnerability Scoring System (AIVSS), and the OWASP Top 10 for Agentic Applications, giving compliance teams a single reference point for multi-framework coverage from one control plane deployment. For a practitioner-level discussion of how organizations are applying the standards, certification, audit, and insurance flywheel to agentic AI, the Practical AI episode on AIUC-1 and building trust in AI agents covers the governance frameworks that anchor that process.

Enforcing HIPAA technical safeguards in sovereign AI workflows

HIPAA Security Rule Technical Safeguard requirements under 45 CFR 164.312 apply to any AI system that accesses, processes, or transmits electronic protected health information (ePHI). Three safeguard categories are most directly implicated when AI agents handle clinical or administrative health data: access controls, audit controls, and integrity controls.

Access controls under 164.312(a)(1) require that only authorized users and systems access ePHI. Prediction Guard's Admin Console enforces which registered agents, users, and applications can call which models and tools, applying those controls uniformly at the control plane level before any model call completes.

Audit controls under 164.312(b) require mechanisms to record and examine system activity in systems that contain or use ePHI. The structured audit log generated for every governed interaction by the control plane provides this replayable trace, formatted for ingestion by the organization's SIEM and retained within the customer's own infrastructure.

Integrity controls under 164.312(c)(1) require that ePHI is not improperly altered or destroyed. Runtime enforcement that evaluates model outputs before they return to the application provides a verifiable mechanism for detecting and blocking outputs that would inappropriately modify or expose ePHI.

Whether specific Prediction Guard deployment configurations satisfy each technical safeguard for a given healthcare AI use case depends on the organization's own risk analysis under 45 CFR 164.308(a)(1). Frame self-hosted deployment as a technical measure that supports your HIPAA compliance program rather than as a guarantee that the program is satisfied.

Clarifying sovereign AI standards and controls

The subsections below address four practitioner-level implementation questions: how to align control plane zones with sovereignty boundaries, how to integrate hyperscaler endpoints, what evidence auditors require, and how vendor geography affects compliance.

Aligning control plane zones with sovereignty

Control plane zone alignment means the network boundary your control plane occupies matches your defined data sovereignty boundary. For a healthcare organization processing ePHI, the control plane must sit inside a network segment that satisfies HIPAA Security Rule requirements for electronic PHI containment. The practical check: draw your data sovereignty boundary on a network diagram. If your control plane sits inside that boundary, your governance is sovereign. If the control plane connects externally, even through an encrypted tunnel, governance decisions cross that boundary and you have a compliance gap.

Integrating hyperscaler AI in sovereign architectures

Prediction Guard is model agnostic. The control plane governs open-source model families, closed-vendor endpoints, and self-hosted models under one policy framework. When your organization uses hyperscaler model APIs because a specific capability requires them, the sovereign architecture pattern keeps the control plane inside your perimeter and treats the hyperscaler endpoint as a governed downstream target. When you switch model vendors, you register the new endpoint in the Admin Console and apply the same governance policies. You do not rebuild your compliance posture. Prediction Guard's AI engineers page covers the developer ergonomics of this composability pattern in detail.

What evidence do assessors and procurement reviewers require?

ISO/IEC 42001 certification bodies, EU AI Act notified bodies, and enterprise procurement reviewers ask for the same four categories of evidence when evaluating sovereign AI deployment claims:

1. AI asset inventory: A complete list of every model, tool, MCP server, and dataset in production, in a versioned format reviewable by a third party. The AIBOM in CycloneDX format satisfies this requirement.
2. Governance policy documentation: A verifiable record of which policies were active on which AI systems at which times. The Admin Console governance configuration provides this.
3. Audit logs demonstrating runtime enforcement: A replayable trace of prompts, tool invocations, outputs, and affected resources, bound to users, sessions, and data sources, as ISO/IEC 42001 A.6.2.8 requires. The SIEM-ready audit log output generated by the control plane provides this.
4. Architecture documentation confirming data flows: A technical description of where data transits during inference, including network diagrams showing control plane and model inference server placement, confirming no regulated data leaves the sovereignty boundary.

Prediction Guard's NIST AI RMF implementation playbook maps these artifacts to specific NIST AI RMF function requirements.

Mapping vendor geography to compliance

The corporate jurisdiction of your AI vendor matters independently of where their servers are located. US-headquartered vendors operating under the Foreign Intelligence Surveillance Act (FISA) Section 702 and the CLOUD Act can be compelled to disclose data held in any of their infrastructure, including EU-located data centers. Organizations processing EU personal data or defense-adjacent workloads require vendors with no access to their data, regardless of server geography.

When the control plane runs inside your own infrastructure, this jurisdictional risk is removed from the governance path. Prediction Guard deploys inside your environment. No Prediction Guard system has access to your prompts, model responses, policy configurations, or audit logs, because those artifacts are generated and retained entirely within your own infrastructure.

Framework mapping across sovereign AI deployment capabilities:

If your current AI governance architecture does not produce these capabilities inside your own infrastructure, you have a gap between your compliance documentation and your actual compliance posture. Book a deployment scoping call to map your specific regulatory constraints to deployment decisions, or read the NIST AI RMF implementation playbook to review which framework functions we address at the system level.

FAQs

Does Prediction Guard store our audit logs?

No. Prediction Guard generates structured, SIEM-ready audit logs at runtime as a byproduct of active policy enforcement, but storage and retention are handled entirely by your existing SIEM (such as Splunk or Datadog) within your own infrastructure. Prediction Guard does not hold SIEM credentials or retain any log data.

What is the hardware requirement for the Prediction Guard control plane?

The control plane is CPU-only and does not require GPU resources to enforce governance policies. Registered models can run on GPU or CPU depending on your specific workload requirements, but the governance enforcement layer itself runs on standard compute.

Does Prediction Guard support air-gapped deployments?

Yes. Prediction Guard supports fully disconnected, air-gapped deployment with no external network dependencies for policy enforcement, supporting the isolation requirements of regulated workloads, including HIPAA Security Rule technical safeguards and ISO/IEC 42001 conformity requirements for air-gapped environments.

How does a self-hosted control plane affect our GDPR data controller status?

When the control plane runs inside your own infrastructure, there is no external data processor in the chain from prompt ingestion through policy enforcement to audit log generation. This removes the Article 28 processor relationship and associated DPA obligations for that governance layer, though your specific controller and processor status always depends on your contractual arrangements and processing purposes.

Can we govern external model APIs through a self-hosted control plane?

Yes. Prediction Guard is model agnostic. External model endpoints are registered as downstream targets in the Admin Console, and the control plane applies PII masking, prompt injection detection, and other governance policies locally before forwarding only the sanitized prompt to the external endpoint. Governance policy configuration in the Admin Console carries forward across model vendors.

Key terms glossary

Sovereign AI control plane: An internal software infrastructure that unifies, secures, and governs AI models, tools, and services entirely within the customer's secure perimeter, ensuring that policy enforcement, telemetry, and audit logs never transit external networks.

Runtime policy enforcement: The active evaluation and modification (allowing, blocking, or rewriting) of AI inputs and outputs at the API level before the model call completes, executed synchronously on every agent interaction to prevent policy violations from reaching production.

AIBOM (AI Bill of Materials): An exportable inventory of an AI system's models, datasets, tools, and dependencies, formatted in the CycloneDX standard for compliance auditing and structured to satisfy EU AI Act Article 11 and Annex IV technical documentation requirements.

Control plane jurisdiction: The legal and network boundary within which the AI governance logic executes, which determines whether cross-border transfer obligations apply to the governance decision path itself, independent of where model weights are stored.

Data residency: The geographic and legal boundary within which data must remain during collection, processing, and storage, as defined by applicable law (GDPR Chapter V, HIPAA, SOC 2, EU AI Act) and the contracts that implement those laws.

AIUC-1: A cross-framework standard that maps controls and requirements across the EU AI Act, NIST AI RMF, ISO/IEC 42001, MITRE ATLAS, OWASP LLM Top Ten, OWASP AIVSS, and the OWASP Top 10 for Agentic Applications, providing compliance teams with a unified reference point for multi-framework coverage.