The Security Paradox Threatening to Torpedo Enterprise AI projects

One of the biggest issues in successfully deploying enterprise AI projects is the risk exposure as employees use AI with company data in ungoverned environments.

Eighty-six percent of companies allow employees to use public AI tools like ChatGPT and Microsoft Copilot, which is up from just 47% the year prior. At the same time, 41% of organizations cite data privacy and security concerns as the single biggest barrier to broader AI adoption. 

If businesses are to move forward successfully implementing enterprise AI projects, they need to rethink how data are prepared, structured, and served to AI in the first place. That rethink should focus first on underlying governance principles – including ownership, access control, lineage, quality, and semantic clarity – and only second on the specific architectural pattern used to implement them.

The Gap Between Using AI and Governing It 

Most employees using AI today are doing so through a chat interface, that is, typing questions into ChatGPT, Copilot, or similar tools and getting answers back. The real value, however, emerges when AI is connected to company data such as financial records, customer information, and operational systems.

When you give an AI tool direct access to raw data, such as rows and columns from a warehouse, or files pulled from a shared drive, the AI inherits whatever governance (or lack of it) applies to that data. If access controls aren’t in place, the AI doesn’t know what it shouldn’t be allowed to see. For example, if there are no rules in place about personally identifiable information (PII), the AI doesn’t know to protect it.

The principle that solves this predates AI: governance should be baked into the way data are defined, protected, and accessed, rather than applied as a separate layer afterward. Originally, this discipline was shaped around human analysts and the applications they built. What’s changed is the consumer: AI agents are also consumers now, and they arrive faster and in far greater numbers than any human team. Whatever an organization chooses to call the approach – governed data sets, data mesh, policy-enforced APIs, centralized platforms, or data products – the underlying requirement is the same: governance should be built in at creation time, not bolted on later.

The important point is not the label, but whether ownership, access controls, documentation, and quality rules are defined up front and consistently enforced.

When governance is managed after the fact, as a layer sitting on top of data, it drifts. Data can change, systems will evolve, and the governance layer becomes outdated. The rules that were meant to protect the data no longer accurately reflect what the data contain or how it’s being used. 

However, when governance is embedded at design time, it travels with the data. Every downstream consumer, whether that’s a human analyst, a business application, or an AI agent, encounters the same rules, enforced the same way. Drift has far less room to creep in because there’s no separate layer to fall behind. Having governance carry through, and not change downstream, is also critical for consistency of the data and transparency, which is important from both a lineage and audit perspective.

The Explainability Issue

While security and privacy are pretty visible concerns, there is also the issue of explainability.

When an off-the-shelf AI model returns an answer, there’s typically no record of why it said what it said. What data did it draw on? What relationships did it infer? If it made a mistake, where did the reasoning go wrong? For many use cases, this lack of visibility is an inconvenience. For businesses using AI to make credit decisions, clinical recommendations, or for financial analysis, it is a regulatory problem.

The EU AI Act is a leading example. The law defines transparency in terms of traceability and explainability. For the systems it designates as “high-risk,” including AI used in credit scoring, hiring, and access to essential services, the Act calls for record-keeping, technical documentation, and enough information for a deployer to interpret and oversee a system’s output. 

Governed data assets, including data products, can help here by providing lineage. When a data product is built, the process is documented, including where the data came from, how records were merged or matched, what validation steps were applied, and what quality standards were enforced.

When an AI agent queries a data product, organizations can configure systems so there’s a record of what was asked and what was returned. Connecting those logs to the AI’s output creates a traceable path from question to answer.

Implementing governed principles can mask or entirely remove PII based on the access rights of whomever is requesting it. For example, a nurse using ChatGPT might have clinical access to PII, whereas an administrator sees a different view of the data without any PII being exposed. 

Privacy protections should not be a blanket decision to either share everything or share nothing. A precise, role-based enforcement that is applied at the moment of access reduces the risk of opening new security gaps.  

Understanding the Data

Even a perfectly governed, fully traceable data set can still lead AI astray if the AI doesn’t understand what the data mean.

Most raw data are built for machines, not people. Column names are abbreviated, coded, or inherited from systems that were built decades ago. Relationships between tables are implicit, known to the engineers who built them, but not recorded anywhere an AI can read. When AI is pointed at these kind of data, it guesses at meaning, and that’s one of the main ways hallucinations can creep in. 

Take a field labeled “STAT” that holds values including “A,” “C,” and “T.” To the engineer who built it, those mean Active, Closed, and Terminated. To an AI model they’re just letters, and it will fill in the meaning, often confidently and incorrectly. But a semantic model records that “STAT” is account status, that “T” means Terminated, and that terminated accounts are excluded from revenue calculations. The same question now returns an answer the business would recognize as correct.

A semantic model defines data in human terms: what each field represents, how concepts relate to one another, and what business vocabulary applies. When that semantic layer travels with the data product, the AI receives not only values, but also context. It understands that two fields are related, that a particular term has a specific meaning in this business, that certain calculations follow defined rules. The answers it produces tend to be more accurate, more consistent, and more useful as a result.

Embedded Reasoning 

There’s one more layer that separates a mature data product approach from a basic one: embedded reasoning.

As organizations build more AI agents, those agents are each given instructions by the teams that build them. The problem is that different teams make different choices. One agent calculates depreciation one way, and another calculates it differently. One applies a particular business rule, another ignores it. The organization ends up with AI that contradicts itself.

The fix is to move those instructions closer to the data. When reasoning guidelines, calculation rules, and business logic are embedded in the data product at design time, every agent consuming the data product can draw on the same guidance and rules. This helps promote more consistent behavior across agents, but true consistency also depends on how those agents are configured, how they interpret the rules, and the nature of the controls in the application and model layers. Consistency is enforced not by hoping each development team gets it right, but by building it into the foundation they’re all drawing from.

Proceed Deliberately

None of this requires governing everything at once, and CDOs shouldn’t try. The more practical path is to start where risk and value are highest – usually customer, financial, or clinical data – and get one domain right before expanding. From there, prioritize governance capabilities in the order an AI agent will test them: access controls and PII handling first, then data quality and certification, then lineage, and finally the semantic definitions that let a system interpret data correctly rather than guess. 

The case for stronger data governance as the infrastructure layer beneath enterprise AI comes down to this: AI can only be as trustworthy as the data it’s given access to.

To reduce the risk of deploying an enterprise AI initiative, data should be delivered through governed mechanisms – whether data products, governed data sets, or other patterns – that are designed to carry their own lineage, enrich semantic meaning, and create reasoning rules that define how they should be used. 

The organizations that will get the most from AI and minimize its risk aren’t the ones moving fastest to connect tools to data. They’re the ones taking the time to make sure the data their AI accesses is governed, explainable, meaningful, and consistent before the agents start running.