Definition · Vidai Architecture
What is an AI control plane?
An AI control plane is the infrastructure layer that sits between every application in an organisation and every model it calls, providing centralised governance, observability, cost attribution and policy enforcement.
Unlike an AI gateway, which routes requests, a control plane is the system of record for what those requests did, what they cost, and whether they were allowed.
It's the operational layer for AI. Not a model. Not a framework. Not a proxy. The thing that turns ungoverned AI usage into a stack you can audit, bill against, and defend.
Where the term comes from
Control plane is borrowed, not invented. In networking, the distinction between the control plane and the data plane has been the foundational architectural decision for thirty years. The data plane is where packets flow. The control plane is everything that decides which packets are allowed to flow, where they go, what they cost the operator, and what the operator is permitted to learn about them.
The same distinction applies to AI:
- The data plane is the model call itself, the request body, the tokens, the response.
- The control plane is everything that governs the call: who is allowed to make it, against which provider, under which policy, at what cost, with what audit trail.
A gateway lives on the data plane: it forwards requests. A control plane is a category above. It contains a gateway as one of its components, the way a network's control plane contains routing tables as one of its components, but it's not reducible to that one part.
What an AI control plane includes
Four capabilities define the category. A system is a control plane to the degree it provides all four; anything missing one of them is something else (a proxy, an observability tool, a billing layer).
- A cost ledger. Per-request attribution that can be enforced, not just reported. The difference between a log file ("here is what was spent") and a ledger ("here is what was spent, by whom, against which budget, and what happens at the threshold") is the difference between observability and governance.
- Policy enforcement. Guardrails that run inline on every request, not as advisory dashboards. A control plane decides whether the call proceeds, not whether to flag it after the fact.
- Observability as a system of record. Every request frozen as an immutable, signed event, the artefact an auditor can rely on, not a screenshot of a Grafana dashboard.
- Translation by construction. Native support for every major SDK dialect in both directions, so the application keeps speaking the SDK it was written against and the control plane handles the wire format the chosen model actually speaks.
These four are not features. They are the definitional surface. A system with three of them and missing the fourth is in an adjacent category.
How it differs from a gateway, a proxy, and an SDK
The terms are often used interchangeably. They shouldn't be.
An AI gateway routes requests from one or many applications to one or many providers. It typically handles fallbacks, basic rate limiting and some translation. A gateway is concerned with getting the request to the right place. It's a data-plane object.
A proxy is a thinner thing, usually a single application's outbound hop to a single provider, with logging bolted on. The team running it owns it as code. Proxies are tactical: they answer a question for one team.
An SDK is client-side. It's the library the application uses to speak to the gateway, proxy, or model. It's not infrastructure. It's the code-shaped end of the request.
A control plane sits above all three. It contains the gateway as one of its functions, replaces the proxy entirely (one shared boundary instead of many bespoke ones), and is the thing the SDK ends up speaking to. Where a gateway forwards, a control plane governs. Where a proxy is a tactical hop, a control plane is a strategic boundary. Where an SDK is client code, a control plane is the operational system the client code reports into.
The shortest way to put it: a gateway is what makes AI work. A control plane is what makes AI accountable.
Why the distinction matters
Most organisations cross a quiet threshold around the point where they have more than one AI-using application, more than one model provider, and at least one team accountable for cost or compliance. Up to that threshold, a gateway is enough. There is one application, one provider, one team, and the question of governance is the same question as the question of routing. They collapse into each other and a gateway answers both.
Past that threshold, they separate. Routing becomes a small part of the problem. The larger problem is: which team's budget did that request hit, which policy was applied, which auditor will see what record of it, and what happens when the regulation changes next quarter. A gateway has no representation for any of this. A control plane has it as the central object.
The reason the distinction matters in 2026 is that the threshold is being crossed by enterprises whose entire AI strategy was built around a gateway, and they're discovering they don't have the operational layer they need. The control plane is what they end up building anyway, badly, over eighteen months, or what they buy as a category.