All articles
Data Governance Assets Become The Context Layer For Enterprise AI Agents
Trideep Patra, Chief Technology and Transformation Officer at Apex Technology Systems, argues that agents need lineage, classification, and policy as code before they touch enterprise data.

A lot of people are talking about AI governance, which reduces cost and risk. That has to be done, but in order for AI to be adopted, the first thing is the raw input, which is data, and that has to be organized.

Enterprise data governance has produced a large body of documentation. Active metadata, data classifications, and lineage records were built to document controls and standardize definitions across systems. An agent querying that same data has no colleague to ask and no memory of how the business works, leaving those records as the only description of what the data means. Enterprises deploying agents against governed data are now finding a second use for artifacts they built for compliance.
Trideep Patra is Chief Technology and Transformation Officer at Apex Technology Systems, where his work covers cloud data management, AI governance, and total cost of ownership advisory for financial and insurance clients. He previously ran global data management at Everest Insurance, leading an Azure migration and a centralized master reference data platform, and previously set enterprise data strategy at AmeriHealth Caritas. He is also the author of Governing the Autonomous Frontier, a reference guide to autonomous data governance.
"A lot of people are talking about AI governance, which reduces cost and risk. That has to be done, but in order for AI to be adopted, the first thing is the raw input, which is data, and that has to be organized," says Patra. He spent three decades on the IT and data side before turning to how agents should be introduced to it. Patra puts the readiness question ahead of the build question, and his answer points at material most enterprises already own.
Governance output, agent input
Patra points to the output of two decades of governance programs as the material an agent needs. Those programs ran on a schedule set by auditors, and the engineers building systems had faster ways to get the same answers. "By the process of governance, we have created a lot of data dictionaries, business glossaries, taxonomies, so many things," says Patra. "But go and ask any technologist how many times they have gone back and referred to that reference data, that master data, that business taxonomy."
He sees the same omission repeating with agents. Most large enterprises already hold the artifacts, which makes this a question of exposing what exists to a machine reader. "People are trying to build the agent without understanding how it should be organized, how the business contextual organization of the data should be," Patra notes. "And to do that, the first thing that you need is the governance."
Lineage before the first decision
Patra's model for how an agent should investigate a problem comes from production support. The path runs the same way every time, and it depends on a record of which system fed which. "If a production ticket has been raised, we are assigning it to a production support person," says Patra. "They go by the lineage one step at a time and understand what is really causing the particular issue. Similarly, the agent has to also function."
The lineage record has to be in place before the agent starts. Older estates make it harder to assemble, since a mainframe pipeline can carry two decades of accumulated transformations. "Before AI starts working, it has to understand the lineage," Patra explains. "Where should I look for the data? What code or transformation are you currently applying? Before AI takes a decision, it has to be provided the whole lineage harvesting as an input."
Lineage tells an agent where a value came from, classification tells it what the value is, and policy expressed as code tells it what to do about it. "On the basis of the Social Security number, I see the policy as a code, the Rego code, is like this," says Patra. "On the basis of that I am going to stop, or I am going to mask the data. First is the identification. Second is what the policy is talking about. And depending on the policy, what kind of action the agent has to take."
Humans make the call
Patra separates the work an agent does from the accountability for it. An agent produces code, analysis, and recommendations, and a named person stays answerable for what ships. "An agent is your peer, your worker whom you are asking to do some work," says Patra. "Once they deliver some work, you are the one who is going to be responsible. An agent cannot be responsible for whatever output it gives."
He applies that split to data asset certification, where the agent assembles the evidence and a steward makes the call. Patra puts the difference in hours. "If a person will be given all these tasks, it will take him at least three days of work," he says. "But with all this information, the agent can do it in 30 minutes."
The operating unit Patra describes puts those roles together by domain, with a data engineer, a steward, a business product owner, and a member of the security team working alongside the agent. A customer-domain squad draws different people than a claims or corporate finance squad, and Patra notes that data and security organizations typically run on separate objectives. "It is not about only the agents solving the problem, or the human, or the data engineer and the data steward," he concludes. "It is all about how they all work collaboratively to address a specific issue."




