The database team knew something had changed. Query volumes had shifted. Infrastructure costs were climbing in ways that didn’t align with any project they’d approved or any workload they recognised. The pattern was consistent enough to be real, diffuse enough to be hard to explain.
So they went looking for answers.
The conversation with the AI delivery team was polite and unproductive. The AI team had recently shipped several agent-based features. Yes, those agents connected to production systems. Yes, they used existing service accounts. No, there hadn’t been a formal infrastructure change request – the agents were application-layer components, not infrastructure changes. The change control process didn’t apply. The API keys had been provisioned through the standard developer access workflow.
From every process standpoint, nothing irregular had happened. From the database team’s standpoint, something had clearly changed – and they had no formal mechanism to say so before it happened, and no clear accountability chain to pursue now that it had.
This is becoming less unusual.
The Separation That No Longer Holds
Every article in Phase Two of this series has diagnosed a technical problem created by agentic AI. Load profiles that no longer resemble human-generated workloads. Identity models that can’t express what an agent actually is or who is responsible for its actions. Audit trails that record what happened without being able to say why or on whose authority. Capacity costs that accumulate in systems owned by teams who had no role in the decisions that drove them.
Those are technical problems. But underneath each one is an organisational problem that makes every technical problem harder to resolve: the people deploying agentic AI are not the people responsible for the systems it’s stressing. This is not a new separation – application teams have always operated at a distance from infrastructure teams. What is new is the speed at which agentic AI collapses the technical boundary between them, leaving the organisational one standing unsupported.
Most organisations have not yet recognised the implications.
How Governance Gets Bypassed
Classic enterprise architecture maintained a meaningful separation between application-layer decisions and infrastructure-layer consequences. That separation wasn’t just technical – it was organisational. The teams who built applications operated within constraints set by the teams who owned infrastructure. Change control, architecture review, access approval – those processes were slow, sometimes frustrating and frequently gamed. But they served a function: ensuring that someone with responsibility for downstream consequences had been consulted before upstream decisions became irreversible.
Agentic AI doesn’t bypass those processes through deliberate circumvention. It bypasses them through category error. An agent is treated as an application. An MCP server configuration is treated as a developer concern. A service account credential is treated as a standard API access decision. None of those categorisations are obviously wrong – and none of them trigger the governance processes designed to protect infrastructure from consequences that haven’t been modelled yet.
The agent reaches directly into the system of record. But the governance process that would have required someone to think about that was never invoked, because nobody classified the deployment as the kind of change that process was designed to catch.
The Incentive Gap
The team deploying agents is measured on delivery speed, feature velocity, AI adoption metrics. Those are legitimate measurements – they reflect real business value. The team owning systems of record is measured on availability, compliance and cost efficiency. Those are also legitimate measurements. They reflect a different set of real business values.
The problem is that these measurement frameworks were designed for a world where the two groups operated in genuinely separated domains. The technical problems Phase Two has been diagnosing were not isolated failures. They reflected a deeper mismatch between architecture and ownership. The load patterns that agents generate came from agents that nobody asked the database team to model for. The identity gaps that agent deployments create run on credentials provisioned through a process that never consulted the team responsible for what those credentials could reach. The audit trail failures this series has examined exist because the team responsible for reconstructing what happened wasn’t part of the decision to deploy the system that made reconstruction necessary. The capacity costs that surface without warning land in infrastructure budgets owned by teams who weren’t in the room when the workload was created.
In each case, the costs and risks of agent deployment are landing on teams who had no role in the deployment decision. And in each case, the absence of clear organisational ownership wasn’t designed. It emerged.
When Accountability Has Nowhere to Land
There is a moment where the problem becomes much easier to see: the post-incident review.
Something goes wrong – a production slowdown, a compliance finding, an audit query that can’t be answered. The organisation needs to establish what happened, who authorised it and who is accountable. In a pre-agentic architecture, those questions had clear answers. The system that caused the incident was owned by a team, that team sat within a governance structure, and accountability flowed through that structure even if imperfectly.
With agent-generated incidents, the questions don’t resolve cleanly. The agent ran on credentials belonging to a service account. The service account was provisioned by a developer team. The agent was deployed by an AI product team. The system it affected is owned by a database infrastructure team. The compliance obligation sits with a risk and audit function. Nobody in that chain made a decision that was individually unreasonable. The collective outcome was an accountability gap that the post-incident review cannot close – because the organisational structure was never designed to span it.
The database team from the opening of this article – the one that saw rising costs and shifting load and could not explain it to the AI team – was not experiencing a communication failure. They were experiencing this gap. They had the data. They lacked standing.
A Gap Governance Hasn’t Caught Up With
Enterprise AI governance is beginning to mature, but most of what exists focuses on model behaviour: bias, fairness, transparency, regulatory compliance. Those are legitimate concerns. They are also concerns about a different layer of the problem.
The governance gap this article describes – between the people making agent deployment decisions and the people responsible for the infrastructure those agents reach into – is not yet a category that enterprise governance frameworks have caught up with. It is not addressed by model cards or ethical AI policies or responsible AI principles. It sits below the layer those frameworks are designed to operate at.
What it would require is governance that spans the boundary between AI deployment and systems-of-record ownership: processes that treat agent deployment as an infrastructure decision, not just an application one; accountability structures that follow consequences rather than stopping at team boundaries; measurement frameworks that make the infrastructure costs of AI deployment visible to the teams generating them.
None of those exist in mature form. The direction is becoming clear. The instruments are not yet there.
The gap between the people driving AI adoption and the people responsible for the systems it overwhelms is not a competence problem. It is not a communication problem. It is a structural problem – and the structures that would close it are still being invented.
This article is part of the Databases in the Age of AI series.
flashdba 