Data Governance Agents Enforce Policy. They Cannot Own It

In August 2025 KPMG announced services for building and running AI agents on Oracle Cloud Infrastructure (opens in a new tab), aimed at enterprise data management. A consulting firm packaging agent capability on a database vendor's stack is not the interesting part.

The interesting part is what the pitch assumes about you: that your data policies are already specific enough for an agent to execute.

For most organizations that assumption is false, and closing the gap is the actual work. The agent is the easy purchase.

What was announced, and what was not

The offering runs on Oracle Cloud Infrastructure, using OCI Generative AI Service and AI Agent Studio to build agents and agent templates for data management work. It follows KPMG Workbench, a multi-agent platform launched in June 2025 on Azure AI Foundry that connects agents from Oracle, Salesforce, ServiceNow, Workday and other systems of record. PwC has a competing orchestration platform for multi-vendor agent deployments.

The strategic read is straightforward. The integrators are not selling models. They are selling the layer between your systems of record and whichever model you pick, because that layer is where switching costs live.

What is not public is any specific deployment architecture. Nobody outside the two firms knows how a real install is wired, and a diagram of it is speculation. The shape of the problem does not depend on the diagram, though, and it does not change with the vendor.

Governance is a decision, not a task

Data governance gets described as work. Catalog the assets, trace the lineage, run the quality checks, file the evidence. That description is why governance teams are permanently behind: it frames governance as an inventory problem, and inventories grow faster than any team.

The inventory was never the point. The point is a small set of decisions. Which data is sensitive. Who may see it. How long it is kept. What happens when it is wrong. Each of those is a judgment with an owner and a consequence.

An agent can execute a judgment that has already been made. It cannot make one, and it cannot be accountable for one.

The test I use: can you write the rule as a conditional with a specific action and a named owner?

"PII must not leave the boundary" is not a rule. It is a sentiment. "A column tagged PII may not be copied to a destination outside the authorized enclave. The copy fails and the requester is notified" is a rule. The first sounds like policy and enforces nothing, which is why so many governance programs produce documents that no system reads.

Three jobs an agent can take

Discovery, quality monitoring and lineage are the three places agents earn their cost. Each one breaks in a specific way.

Cataloging. Agents are good at finding assets, inferring schema and tagging candidates for review. They are bad at deciding whether a field is sensitive. A column called notes can hold a diagnosis, an account number, or a complaint about a manager. A false positive wastes a steward's afternoon. A false negative is the finding that ends the audit.

Quality monitoring. Continuous checks are genuinely better than the quarterly sample, and agents make continuous checks cheap. The catch is the remediation path. If an agent flags an anomaly and nobody defined what happens next, you have built a faster way to produce a list of known problems.

Lineage. Passive observation beats asking people to update a diagram, and the diagram is always wrong. But an agent only sees the flows it is instrumented on. The data movement that hurts you is usually the manual one: the export, the email, the analyst with a local copy. No collector sees that.

None of these failures are model failures. They are specification failures, and they were there before anyone said "agent."

The question an auditor will ask

When an auditor asks why a record was deleted, "the agent applied the retention policy" is not an answer. The answer is the policy, the version in force on that date, the inputs the agent evaluated, and the person accountable for the policy.

That means a governance agent has to produce evidence, not only actions. Which makes this a logging and versioning problem before it is a model problem. If the policy that ran at 3am is not the text you can produce at 9am, you cannot defend the decision.

There is a second risk that gets less attention. If the control protecting sensitive data is an agent's judgment, then the agent's inputs become an attack surface. An instruction hidden in a document the agent reads is a data governance incident, not a curiosity. Anyone running a document-ingesting agent over a real corpus should assume a hostile document will land in it.

What to do before you buy anything

Three steps, in order. None of them require a license.

1. Write the rules down as conditionals. One sentence each: condition, action, owner. Count how many you can write without arguing. That count is your automation ceiling, and it is usually lower than anyone expects.
2. Plant a violation and test for it. Pick one policy, one dataset, one known breach that should be caught. If the agent cannot find the violation you planted, you have seen a demonstration, not a control.
3. Name the accountable person. Not the team, not the vendor. A person who signs when the agent is wrong. If the answer is "the platform," you have bought tooling and kept the risk.

The KPMG and Oracle offering is a reasonable bet on a real shift, and the boring parts of governance are exactly what agents should absorb. But the part that decides whether the program survives contact with an auditor is the part you have to write yourself, and no partnership announcement changes that.