From Bottleneck to Multiplier: The Human Factor in AI Governance
Agentic AI does not reduce the human role in governance. It moves it from approving individual decisions to defining the constraints that shape all of them.
Ask what the human factor looks like in governance going forward, and you tend to get one of two answers: Either humans become unnecessary, because the machine decides. Or humans have to review everything the machine does, because someone must stay accountable.
Both are wrong, and they are wrong in the same way. They assume the human role is a volume of decisions, so that more automation means fewer humans and more oversight means more humans.
The human factor does not shrink in the age of AI. It moves. From in the loop to above the loop. And what replaces per-decision approval is harder than what it replaces, not easier.
That move is also the difference between the two roles a human can play in a governed AI system. In the first, every decision waits for a person, and the person becomes the bottleneck. In the second, the person sets the constraints that thousands of machine decisions then run inside, and the same effort becomes a multiplier. The interesting question is not whether to keep humans involved, it is which of those two positions you have designed them into.
What agentic AI actually inserts
Modern AI stacks introduce a new layer between the human and the data, and that layer has its own agency. The term “agentic AI” is indicative of exactly this. Three things change at once:
Volume: The rate of physical data access rises by orders of magnitude, because agents automatically pull and evaluate a great deal of input in order to reach an informed decision. Traditional operational database systems with fairly static scaling behavior were not designed for that access profile.
Non-determinism: What gets accessed is decided by the agent, ad hoc. This is the part that breaks the classical model. The human who deployed or scheduled the agent cannot preapprove an access path, because there is no path to approve in advance. There are only constraints. Agents develop strategies the person who deployed them did not anticipate and may not have wanted.
Agents produce and consume their own data: We call it agent context, or agent memory, and it is mission critical for both accuracy and token efficiency. It is also the dimension I see discussed least, and it may be the most consequential. That memory inherits the sensitivity of everything it was built from, and in most stacks today it sits entirely outside the governance perimeter. You can enforce policy perfectly at query time and the agent may still answer from context it cached last week, when its purpose was different.
What replaces per-decision approval
So the human stops being the one who approves each individual access. That role is going away, and not because humans are too slow. It is because the access paths are not knowable in advance to be approved.
What replaces it is more demanding, and it is where the multiplier comes from. Humans define the policy the machine enforces. They audit whether it actually held. And they remain the escalation instance for the ambiguous situations the system cannot resolve on its own. One well-made decision about what an agent’s purpose permits governs every access that agent will ever attempt, which is leverage of a kind that per-transaction approval never had.
The accountability does not move at all. DORA is explicit that the management body carries responsibility for the ICT (information and communication technology) risk management framework, and that responsibility does not transfer to an agent. The EU AI Act’s human oversight requirement asks for precisely this shift, rather than for a human clearing every transaction: a person who is genuinely able to understand the output, override it, and stop the system. The high-risk obligations were deferred to December 2027 by the Digital Omnibus, but the design requirement did not change, and it is only satisfiable if the system was built for it in the first place.
Automating the decision does not delegate the accountability.
The hard part is translation
Here is where this gets genuinely difficult, and it is not a technical difficulty.
Policies are written about purposes, in natural language. “This agent supports mortgage servicing.” Enforcement engines work on identities, roles, rows, and columns. Nothing translates between those two levels automatically. Somebody has to decide which tables, which rows, and which columns actually constitute mortgage servicing, and somebody has to be willing to own that decision.
That is a semantic and organizational problem, not an engineering one. It is most of the work in practice, and it is the part nobody puts on a slide.
It is also why I would describe AI governance as an abstraction layer sitting on top of data governance, rather than a replacement for it. None of the classical controls disappear. Ownership, lineage, quality, access control, privacy, sovereignty, and auditability all matter more with AI, not less. Anyone offering you a new control paradigm for AI is offering you a second governance silo.
What changes is what you are governing. Traditional data governance asks where this data came from, who owns it, who may access it, and under what policy. AI governance asks how it is being used, by which agent, for what purpose, and what that agent is permitted to do. The discipline of AI governance is the translation between those two sets of questions, and the translation is where all the difficulty lives.
Once you see it that way, human-in-the-loop approval has a precise place: It is the exception path, not the operating mode. Every escalation is a translation that failed. That makes it measurable, and it also marks the line between the two roles I described at the start. If you are approving every agent decision by hand, you have not governed anything, you have added a queue, and you have put your best people back into the bottleneck.
Enforcement has to be somewhere the agent cannot go around
Writing a policy that says an agent has a purpose and may only touch what that purpose requires is easy. Making that policy impossible to bypass when the agent actually executes is the hard part, and it is where most AI governance stops short.
Most tooling in this space observes and alerts. But an alert is a report about something that already happened. Governance that only observes is not governance, it is reporting. The test is whether the system can say no, at execution, every time, without anyone being asked.
That has an architectural consequence. If enforcement lives in the application layer or in a proxy in front of the data, there is always another route to the data. So the enforcement point has to be the data layer itself.
This is the reasoning behind the agent governance model in EDB Postgres® AI. Purpose becomes a declared property of the agent. That purpose maps to a PostgreSQL role, and the role is applied at the Postgres execution boundary, so an operation outside the permitted scope is denied rather than flagged. Deliberately, we did not invent a new enforcement layer for AI. EDB has spent two decades hardening Postgres for banks, insurers, and public institutions, and the enforcement primitives were already in the database: role-based access control, row-level security, column masking. These are mechanisms that auditors in these industries have been examining for years. In governance, novelty is a liability. Your auditors should already understand how your controls work, and the fastest way to achieve that is to give them controls they have already seen.
Then there is evidence. Every governed session needs a decision trail: which agent, which declared purpose, which action, and whether it was allowed or denied. From that you get drift detection deterministically, because repeated denials show an agent reaching outside its declared purpose. There is no need to infer intent, which nobody can do reliably anyway. You read hard evidence.
Governed agent memory is the piece that is still genuinely open, at EDB as much as anywhere else. Enforcement at the boundary does not reach what is already inside the agent. Keeping agent memory inside the governed database rather than in a separate store is a precondition for solving the problem, rather than a solution by itself.
The real cost is not the check, it is the uncertainty
Speed and control are usually presented as opposites. They become opposites when control is manual and applied at the end.
I think we misdiagnose where the bottleneck actually sits. Teams rarely lose months to the approval step itself. They lose months to not knowing, in advance, whether they will be allowed. So they build defensively, or they build twice, or they quietly copy the data somewhere easier to work with. Or they never start at all. The constraint is not the person doing the review. It is the uncertainty in front of them.
Which means the unlock is predictability, not permissiveness. If an agent declares its purpose up front and that purpose maps to enforceable permissions in the platform, the team knows on day one exactly what it may touch. That is a constraint, and constraints make engineers faster. An open field with an approval gate at the far end is what makes them slow.
There is an organizational version of the same problem. When AI, data, security, compliance, risk, and business teams disagree, every one of them is behaving rationally. The objectives are all legitimate; they are just not the same. And the consequences are asymmetric: If a business team ships late, that is a missed quarter. If risk approves something that goes wrong, that is a career event. So “no” is the rational answer for risk and “go around them” is the rational answer for the business. Nobody in that picture is behaving badly, which is exactly why goodwill and a steering committee do not fix it.
Architecture makes it worse. If every AI initiative brings its own cloud, its own vector store, its own copy of the data, and its own security model, then every handover point between systems becomes a handover point between teams. And handovers are where accountability gets lost.
The only durable answer I know is to make the safe path the fast path. As long as the governed route is the slow route, you are asking people to choose between their objective and yours, and they will choose theirs.
How to tell whether it is working
Most organizations measure governance by the absence of incidents. That is understandable. Guardrails are invisible when they work. They are expensive—in outages, in remediation, and in penalties—when they fail.
But as a sole metric, absence of incidents is dangerous, because a governance function measured only on incidents can score perfectly by saying no to everything. Zero incidents, zero value. In the agentic era that is not a neutral outcome, it is a competitive loss.
So measure both sides. On enablement: What share of your high-value, regulated data estate are your agents actually cleared to use, weighted by value rather than counted by system? How long does it take to clear a new use case for a new dataset? And how much of it runs on data that was already governed, rather than on a fresh copy? Because reuse is the real maturity signal.
On protection, incidents are a lagging metric. By the time you count them you are measuring history. Two leading indicators are more useful: The escalation rate, which should fall as your policy matures, tells you whether you are codifying judgment or just deferring it. And circumvention, which means shadow AI and the number of data copies created to work around a slow approval, tells you that teams are routing around governance long before anything actually breaks.
Then there is one metric that exposes the architecture underneath all of it: your marginal governance cost per new use case. Is it flat, or does it rise every time? If each project brings another copy of the data, another vector store, another security model, and another pipeline, governance becomes more expensive every time you innovate, and eventually the organization stops innovating or stops governing.
That metric is the one I would watch most closely, because, unlike the others, it cannot be improved by working harder. It is a property of the architecture.
One governed foundation, not one silo per use case
Which brings the argument to its architectural conclusion. The translation problem I described earlier gets multiplied by the number of places you have to translate into. Every copy of the data carries its own access model, its own roles, and its own audit trail. Governance work that should be done once is redone per system, and the versions drift apart over time. That is what makes the marginal cost curve rise, and it is also what creates the handover points between teams where accountability goes missing.
So the design goal we have pursued with EDB Postgres AI is to reduce the number of places where governance has to be reinvented. Transactional workloads, analytics at scale, real-time analytics, open lakehouse data, vector search, and agent workloads are on one governed Postgres foundation rather than on a separate stack per use case.
The benefits of that consolidation are mostly governance benefits, which is the part that tends to get underplayed. Vector embeddings sit beside the enterprise data they describe, so joins and permissions are the same mechanism rather than two mechanisms that have to be kept in agreement. Agent memory can stay inside the governed environment instead of accumulating in another uncontrolled store. An access decision is enforced in one place and provable in one place. And an agent pulling context at machine volume reaches the data directly, without a copy pipeline in between that has to be secured, monitored, and explained to an auditor.
The claim is not that one platform is architecturally tidier. It is that governance cost scales with the number of enforcement points you maintain, so reducing them is the only reliable way to keep the marginal cost of your next use case flat. That is the bet EDB is making, and it is a governance bet before it is a performance one.
Regulators are converging on four questions
Regulations differ in wording, scope, and timing, and that isn’t changing. But at the technology level, the convergence is striking. It reduces to four questions: Where is the data? Who may access it? Why are they accessing it? And what actually happened, provably?
The interesting one is “why,” because it is the new arrival. Classical controls answer who and what. Purpose used to live in a policy document, where nobody could verify it at runtime. AI regulation is pushing purpose down into the technical layer, and that is a real change in what a platform has to be able to do.
It also changes when evidence has to be produced. Most institutions can eventually answer those four questions by pulling logs from six systems over two weeks. What is changing is the expectation that this is an operational capability rather than a project, which means evidence has to be generated at runtime rather than reconstructed afterwards. Six systems is also the reason it takes two weeks, which is the consolidation argument arriving from a different direction.
And there is an uncomfortable side effect that deserves more attention than it gets: A complete trace of what an agent did contains the data it touched. So your evidence store quietly becomes one of your most sensitive data stores, and it has to be governed like one. In most architectures I see, that is not solved.
The practical conclusion is to build for the question rather than for the text. Then the next regulation is largely a mapping exercise.
Governance sets your ceiling, not your speed
The usual argument for good governance is that it makes you faster. I think the sharper point is that it decides how far you are allowed to go.
The shift from generative to agentic AI makes this concrete. With a chatbot, the concern was what it tells you. With an agent, the concern is what it does. And that changes where you are permitted to deploy it at all. Any institution can put AI into internal search or marketing copy. Putting it into credit decisioning, claims handling, financial crime, or client advisory requires you to prove control. So governance is not the brake on an AI program. It is the ceiling on it, and in regulated industries, the value sits almost entirely above that ceiling.
There is an external dimension too, and it is underrated. In the finance sector and other industries, growth runs through data sharing: partnerships, embedded finance, outsourcing, joint ventures. Every one of them requires a counterparty to accept your controls, and they are already assessing them. Your governance posture is being priced by someone else, whether or not you treat it as a differentiator.
All of which comes with one condition: Trust has to be demonstrable. Not asserted in a policy document, but evidenced at runtime. An institution that can say, “We know where the data is, we know what this agent is permitted to do, we enforce it in the platform, and we can show exactly what it did” can move into higher-value processes with real confidence, and it does not have to rediscover trust for every new use case. Being able to make that statement about transactional, analytical, and AI workloads at the same time, from one governed foundation, is what EDB Postgres AI is built for.
So the human factor does not get smaller as AI gets more capable. It gets more consequential. You go from approving thousands of decisions to making a handful that shape all of them, which is precisely how a bottleneck turns into a multiplier. The same people, in a different position in the system.
Trust you cannot prove is only marketing. Trust you can prove is an advantage your competitors will not copy quickly.
EDB Postgres AI brings transactional, analytical, and AI workloads onto one governed Postgres foundation, with agent governance, purpose-bound access enforcement, and runtime evidence built into the data layer rather than bolted on around it. If you are working through these questions in a regulated environment, I would be glad to compare notes.