Enterprise AI
Control Plane

An AI control plane is the software layer that governs how AI requests move through enterprise infrastructure — from input policy enforcement and capability qualification, through model selection and provider routing, to response validation, cost control, and execution audit. While an AI gateway primarily mediates and manages AI traffic, a control plane governs the broader execution lifecycle before, during, and after every model call. The term comes from network and cloud architecture, where the control plane governs how traffic is directed — distinct from the data plane, which carries it.

An AI gateway is primarily concerned with mediating and managing AI traffic — routing requests to model providers, handling failover, caching, and provider abstraction. Modern gateways also increasingly include guardrails, policy controls, observability, PII protection, spend controls, and audit logging. An AI control plane extends the scope toward lifecycle-wide execution governance: deterministic input policy enforcement before routing, session-aware context across interactions, response validation before delivery, immutable governance provenance, and organisational controls across providers and agent frameworks. The distinction is one of architectural scope rather than a binary capability difference.

An LLM router selects which model or provider handles a request — based on cost, latency, capability, or availability. It is one decision: execution destination. An AI control plane contains an LLM router as one capability, surrounded by input policy enforcement, capability qualification, response validation, governance, cost optimisation, and audit provenance. In CARDIAC-PURR AI Control Plane, the LLM Router is the routing engine within the broader control plane — not the product itself.

A control plane becomes relevant when routing alone is not sufficient — when an organisation must enforce deterministic policy at runtime, validate responses before they reach users, maintain session-level context, produce governance evidence for audit or regulatory workflows, restrict which models are eligible for particular tasks, or govern AI behaviour consistently across agent frameworks and multiple providers. Common triggers include operating under applicable AI regulation, running AI in regulated industries, deploying autonomous agents in production, requiring cost governance across providers, or needing operational auditability beyond access logs. An AI gateway is often sufficient for prototyping, access standardisation, and basic multi-provider failover.

No. PURR SHIELD is a separate memory-resilience technology operating at the GPU memory-protection layer, within the CARDIAC-PURR technology family. The LLM Router is the model-routing capability inside CARDIAC-PURR AI Control Plane, operating above the AI stack to select the appropriate model and provider for each request.

Layer 1 (Intelligent Routing & Optimisation) evaluates task complexity, latency, provider availability, capability, pricing, and context to pick the most efficient model per request, with cascade recovery and fallback execution if a provider degrades.

No. The platform requires no training at all — this is by design and is a deliberate part of how it's differentiated from competitors. Classification uses deterministic rule-based logic rather than a trained model, per our own Article 10 compliance documentation.

Routing latency depends on the implementation, configured checks, network path, and provider response behavior. It should be measured in the customer's own environment.

Provider support should be confirmed for the intended deployment. The architecture is presented as a control-plane approach for working across model providers, not as a public compatibility guarantee.

Routing accuracy should be evaluated against an agreed test set and method. Published numbers should only be used after the evidence is reviewed.

Yes — confirmed at three real, independent layers: organisation-level budget limits, organisation-level rate limits, and a model allowlist. This is enforcement scoped per organisation, not a single global policy applied identically to every customer.

No. Most AI gateways focus on access and interoperability — getting a request to a model and back. CARDIAC-PURR AI Control Plane is built around deterministic execution governance, runtime risk prevention, financial optimisation, and operational control. Its LLM Router handles model and provider selection as one capability within the broader control plane. Routing is the front door; governance is everything that happens before a response is allowed to reach production.

Layer 1 (Intelligent Routing & Optimisation) evaluates task complexity, latency, provider availability, capability, pricing, and context to pick the most efficient model per request, with cascade recovery and fallback execution if a provider degrades. Layer 2 (Risk Prevention & Governance Engine) is a multi-stage, 5-layer guard hierarchy enforcing policy constraints, model eligibility, confidence thresholds, and validation logic before a response reaches the user. Layer 3 (Financial Optimisation & Observability) measures every routing decision, provider substitution, and cost through the Model Delta Index (MDI), giving real-time cost visibility and procurement-grade reporting.

Any cost-accounting or routing-reporting method should be documented for the specific deployment and reviewed against the customer's own provider invoices before claims are made.

One line of code: swap base_url to https://api.cardiac-purr.com/v1. Compatible with the standard OpenAI Python SDK via the base-URL swap. Everything else stays the same.

Confirmed — the /v1/route/preview dry-run endpoint returns a routing decision with no billing or audit side effects.

Fixed, not customer-configurable. The primary provider is whatever the router already selected for that request; the fallback order beyond that is derived automatically from the platform's own provider registry at call time — deterministic, but not a preference list a customer can set.

An LLM router evaluates each request and selects an appropriate model, model tier, or provider based on factors such as task requirements, capability, policy, cost, latency, and availability. In CARDIAC-PURR, the LLM Router is a capability within the broader AI Control Plane, which also applies governance, response validation, failover, observability, and auditability across the execution lifecycle — so routing is one governed step rather than the whole product.

An LLM router can reduce unnecessary model spend by directing requests to an appropriate model, model tier, or provider rather than using the most expensive option for every workload. CARDIAC-PURR measures routing and cost outcomes per request. Published benchmark results ranged from 30.9% to 88.3% savings depending on provider pricing structure and workload composition, and should not be interpreted as a universal savings guarantee — results vary by deployment.

A traditional API gateway manages general application traffic — authentication, access control, rate limiting, and routing between services. An AI gateway is designed specifically for traffic between applications and AI models, and may add model and provider routing, AI-specific observability, prompt controls, spend management, caching, guardrails, and related governance features. An AI Control Plane extends beyond traffic mediation toward lifecycle-wide execution governance, validation, provenance, and policy control across providers and agent frameworks.

An LLM router selects a model or provider for a given request — it makes one decision: execution destination. An AI gateway mediates and manages the broader flow of AI traffic, typically adding provider abstraction, failover, rate limiting, caching, cost tracking, and increasingly policy and observability features on top of routing. In practice, the boundary between a sophisticated LLM router and a lightweight AI gateway is often a matter of implementation depth rather than a hard architectural distinction. In CARDIAC-PURR AI Control Plane, the LLM Router is the routing module within the broader control plane — responsible for model and provider selection as one step in the governed execution pipeline.

No — though the two are complementary. AI governance describes the policies, processes, accountability frameworks, and organisational controls that determine how AI systems are developed, deployed, and monitored. An AI control plane is runtime infrastructure that enforces those policies during execution and records the resulting decisions as governance evidence. In short: governance defines the rules; the control plane enforces them at execution time and produces the audit record.

An MCP (Model Context Protocol) gateway primarily governs the connection between AI agents and external tools or MCP servers — managing access, permissions, and context for agent-tool interactions. An AI control plane governs a broader execution scope that can include model selection, provider routing, input policy enforcement, response validation, cost control, observability, and auditability across both direct application calls and agentic workflows. The two can coexist in an architecture: an MCP gateway handling agent-tool access while a control plane governs the model execution layer above it.

Not necessarily. They can exist as separate architectural layers, or the capabilities of both can be incorporated into a single control-plane implementation. The right architecture depends on the organisation's routing requirements, governance obligations, security posture, observability needs, and compliance context. CARDIAC-PURR AI Control Plane is designed to serve as the single governed execution layer above model providers — covering routing, policy, validation, and auditability without requiring a separate gateway in front of it.

No. A control plane governs both direct application-to-model requests and agentic workflows through the same execution layer. Autonomous agents increase the importance of runtime policy, provenance, and auditability — because agent systems make many model calls with less human review between steps — but agent usage is not a requirement. Many enterprise teams adopt a control plane initially for governed multi-provider routing and cost optimisation on standard application requests, then extend the same layer to cover agent workloads as those systems mature. See Agentic Framework Support for integration details.

Common triggers include: operating across multiple AI providers or models and needing consistent governance above them; requirements for deterministic runtime policy enforcement; model eligibility restrictions by task, user, or organisational unit; response validation before output reaches end users; cost governance and verified savings measurement across providers; audit or record-keeping obligations under applicable AI regulation or internal compliance requirements; deployment of autonomous agents in production workflows; or enterprise observability requirements beyond provider-level access logs. None of these individually mandates a control plane — the appropriate architecture depends on the specific requirements. For a detailed look at deployment scenarios, see Use Cases and Compliance.