When every team ships its own AI agent with its own API key and its own billing account, IT inherits a network of blind spots it never agreed to manage. This is not a hypothetical scenario. It is the current state of AI deployment in most organizations that moved fast on adoption without building a governance model first.
How Fragmentation Happens
The pattern is consistent. A developer team wants to ship a customer support agent. They sign up for an OpenAI key, embed it in the application, and the feature ships in three weeks. Another team does the same for a code review tool. A third for a document summarizer. Each is a reasonable decision made in isolation. None of them tells IT.
By the time the IT department finds out, there are often six to fifteen agent deployments running under credentials that were never provisioned through the company's identity management system. Each has its own billing arrangement, its own data access path, and its own implicit understanding of what prompts are acceptable to send to an external model. That understanding is typically "whatever the agent generates."
This is not a failure of the teams shipping AI features. They shipped quickly because the tools made it easy to ship quickly. The governance infrastructure just did not exist to match the pace.
What IT Can No Longer See
Three specific things disappear when AI governance is per-team:
Cost visibility. Each team sees its own OpenAI or Anthropic bill. Nobody has the aggregate. Finance gets a line item for "AI API costs" that is actually the sum of four separate billing accounts that grew independently. When costs spike, the signal exists in each team's account, but the person with budget oversight is looking at a consolidated view that only shows the total.
Data flow. A customer support agent routinely includes customer names, account IDs, and support history in its prompts. That data leaves the network every time a request fires. Whether that is acceptable under the company's data handling policies is a question nobody is checking, because the team that built the agent is focused on response quality, not data classification.
Policy consistency. One team has established a rule that their agent will not answer questions about competitors. Another team's agent will. A third uses a different model entirely with different behavior characteristics. There is no consistent policy layer. The behavior of your company's AI is the aggregate of however many individual teams decided to configure their agents.
What a Control Plane Actually Does
A control plane does not replace the individual agents or the teams that run them. It sits between the agents and the LLM APIs they call, and it performs three jobs from that position.
First, it normalizes traffic. Every LLM API call routes through a single endpoint instead of directly to OpenAI, Anthropic, Azure, or wherever. The agents do not need to change how they work. From the agent's perspective, it is calling an API that returns a completion. The control plane handles where the request goes and what happens to it in transit.
Second, it enforces policy. At the point where a request passes through the control plane, the system can inspect the prompt, apply data classification rules, and either allow, modify, or block the request. PII detection at this layer catches customer data before it leaves the network. Topic restriction rules apply consistently to every agent, not just the ones whose teams remembered to implement them.
Third, it attributes cost. Because every request passes through a single point, the system tags each request with a team namespace and accumulates cost metrics per team in real time. The finance team's question about which department owns the $63,000 API bill becomes answerable from a dashboard rather than a spreadsheet reconstruction exercise.
The Objection: Will This Create a Bottleneck?
The most common concern is that routing all AI traffic through a centralized layer introduces latency and creates an approval chokepoint. This deserves a direct answer.
On latency: the routing hop adds between three and eight milliseconds in typical configurations, depending on network topology. For the majority of enterprise AI agent use cases, where the model itself takes 400 to 2,000 milliseconds to respond, three to eight milliseconds is not a meaningful degradation. There are edge cases, particularly real-time voice or high-frequency streaming applications where latency is the primary user experience factor, where this tradeoff deserves a harder look. Those are not the majority of enterprise use cases.
On approval bottleneck: a control plane is not an approval queue. Teams do not submit requests for review before deploying an agent. They configure their agent to point at Airia's endpoint instead of directly at OpenAI's endpoint. Routing rules and data policies are configured once by IT at the platform level. The team's iteration speed does not change. The governance layer runs in parallel with whatever the team is building.
How Routing, Policy, and Cost Attribution Work Together
These three capabilities are individually useful, but they compound when they operate from the same layer. Consider an IT team at a growing supply chain software company managing three separate agent deployments their operations team built over the previous year.
Before routing through a control plane, the IT team knew the deployments existed but could not determine: how much each cost per month, whether any were including shipment tracking numbers or customer contact details in outbound prompts, or what would happen to all three if OpenAI had a service degradation event.
After connecting the three agents to a single routing endpoint, cost per deployment became visible within 24 hours. The policy scan found that two of the three agents were including what appeared to be customer contact information in prompt context. One instance was borderline, one was clearly outside their data handling standard. They updated the masking rule once at the control plane level. The agent teams did not need to change any code.
The fallback configuration they set for vendor downtime resolved a third concern: if OpenAI is unavailable, route to their Azure OpenAI deployment instead. That had been on their list for months, pending individual code changes to three separate agents. From the control plane it was a single configuration update that applied to all three simultaneously.
Where We Draw the Line
We are not arguing that teams should route all AI traffic through a control plane in order to restrict what their agents can do. Teams that are building AI features need flexibility, and adding friction to every deployment decision is the wrong outcome.
What we are saying is that IT needs a layer that provides visibility and policy enforcement without requiring per-agent coordination. The fragmentation problem is not a people problem. The teams shipping AI agents are not being irresponsible. They are operating without a shared infrastructure layer that handles governance concerns at the right level of abstraction. A control plane is that infrastructure layer. It belongs to IT, and it runs regardless of which team is shipping which agent.
If you are managing AI governance today by asking teams to self-report their API usage and self-enforce data policies, you are managing a problem that will eventually surface as an unexpected bill, a data incident, or a compliance question you cannot answer. The earlier the infrastructure is in place, the fewer of those situations you will be explaining to your security leadership or your board.