Data Friction Is a Tax on AI: Why Enterprise AI Stalls
IN BRIEF
Enterprises are not fully operationalizing AI because the data fueling projects isn’t completely activated. The cause is data friction: barriers to the free flow of information that waste time, delay results, and frustrate everyone involved. Data friction imposes a tax on AI.
Despite all the hype and the billions of dollars spent, agentic AI is far from reaching its promised potential. Numerous studies indicate that goals for agentic AI projects are not being met.
For example:
- IDC says 88 percent of POCs involving AI did not reach deployment.
- McKinsey reports that only seven percent of companies have fully scaled AI across their organizations; and
- Deloitte says that while 91 percent of organizations surveyed plan to increase spending on AI, “just ten percent say they are currently realizing significant ROI from agentic AI.”
What’s behind this gap between expectations and reality?
To gain more insight, we commissioned a study by Enterprise Management Associates (EMA). They interviewed 152 IT and security leaders about their experiences with AI projects.
EMA’s central finding is that security and compliance reviews impose what they call an “AI friction tax.” Here’s how they describe it:
AI friction—the accumulated drag imposed by security reviews, compliance processes, sensitive data access challenges, autonomy constraints, and trust concerns—is measurably slowing deployment, reducing functionality, and increasing the operational cost of AI governance. Organizations have the ambition and the budget. What they lack is a clear path from prototype to production that doesn’t stall in the reviews, approvals, and data access bottlenecks that define the gap between AI initiative and AI impact.
Taken together, these frictions add up to what amounts to an AI friction tax—a cost enterprises pay not in a single line item but across three: time lost to delay, capability lost to restricted deployment, and budget lost to compliance overhead.
There’s only one reason this tax is assessed: the underlying data isn’t protected in a way that lets AI use it freely.
Specifically, EMA found that among the companies they interviewed:
- 82.9 percent said security or compliance reviews have delayed AI projects from moving into production.
- 81.6 percent reported that AI agents were deployed in a diminished state because of security concerns.
- 66.7 percent of delayed projects waited a month or longer, with 29.4 percent stalled four months or more.
- 55.3 percent cited security reviews as a top AI production bottleneck, with 47.4 percent also putting “difficulty securing sensitive data” into that category.
- 91.5 percent said “AI-ready data without roadblocks” would be extremely valuable or very valuable.
The concept of an AI friction tax goes a long way toward explaining the gaps that IDC, McKinsey, Deloitte and others have observed about slow progress toward production AI with meaningful ROI. The AI friction tax is slowing deployment and diminishing results.
What can be done?
First, business and IT leaders need to acknowledge that two priorities currently at odds have to coexist: all relevant data must be made available to agentic AI models; and that data must be fully protected and compliant.
If you don’t give an AI model all the relevant information it requires to complete its task, the results will inevitably be diminished and the project goals unmet. At the same time, if that data is not fully protected at all stages of the project, the organization will be at risk for breaches that potentially could cost tens of millions of dollars.
The challenges of supplying sufficient data to agentic AI are very different from past concerns about data security, governance, and compliance – and they require a solution that differs from legacy approaches.
This new approach – exemplified by Protegrity – is both proactive and comprehensive, and covers the entire lifecycle of protecting sensitive data and knowledge:
Control
Discover the sensitive data and knowledge and set live policy for what’s allowed.
Enforcement
Apply that policy at the point of use—in the database, in motion, and inside the agent’s reasoning—so protection follows data and knowledge however and wherever they’re consumed.
Verification
Provide cryptographic proof of what ran, what was protected, and what was touched.
Execution
Deploy the full lifecycle of control, enforcement, and verification in live production environments—not just in demos or proofs of concept. This is what Protegrity has been doing for more than 20 years.
The Protegrity approach
Protegrity ends the standoff between security and data access by delivering more productive data and better knowledge protection. Everyone wins from one system: fully usable data for the data team, provable protection for security and governance, and production AI at scale that satisfies corporate expectations.
An enterprise’s most sensitive data must be kept safe to use, so it powers AI instead of sitting locked away. Security and compliance reviews aren’t at fault for data friction. It’s the architecture that makes them necessary. Change the architecture and the friction goes away.
The optimal architecture turns protection from a data friction tax into fuel for AI success. It has three pillars.
1. Protect data and knowledge.
Don’t lock down access to sensitive data – that greatly dilutes AI model reasoning. Keep data usable without security compromises. A date of birth becomes an age range a model can use without anyone seeing the actual date. An agent reasons on who-did-what-to-whom without ever touching a real identity. Semantic tokens preserve the relationships while protecting the people.
And protect the inference – e.g., the salary you can rebuild from headcount, budget, and job level, not just the field it sits in. That’s the gap between knowing data is sensitive and protecting what makes it sensitive. AI reasons on a complete set of real (but protected) information, not on a watered-down subset that produces diminished results.
2. Prevent AI leakage.
Agentic workflows create a new class of data movement that legacy controls weren’t designed for. It’s not a file transfer or an API call returning a record. It’s an agent that synthesizes multiple sources, some of them sensitive, into an answer that reads like a business recommendation and potentially is emailed to a distribution list.
This is called inferred leakage, which occurs when unauthorized parties deduce sensitive, proprietary knowledge by piecing together data points that individually raise no alarms when accessed. No DLP rule identifies what’s happening because no single data element crosses a threshold.
Preventing leakage takes a fundamentally different architecture. De-identify data at the point of ingestion, so that at every point downstream, it holds no value to anyone but an authorized user with approved intentions.
Enforce data policy with federated guardrails across the full agentic workflow – from the point of retrieval, through analysis and reasoning, to the final output. Prevention, not just detection; enforcement, not just observation.
This is context-aware data protection – what data and security leaders need but struggle to deliver.
3. Attest the AI stack.
Production AI needs proof: cryptographic evidence confirming which model ran; that the agent was who it claimed to be and stayed within policy; that protection was in force end-to-end. Proof that’s quantum-ready, so it still verifies years from now. Attestation is what lets an AI initiative enter production and survive an audit, earning the status of “trusted.”
Those three pillars are the architecture Protegrity built – operating on a single, unified platform. But architecture alone leaves one question open: who controls the data while all this runs – and does that control survive crossing a cloud, a vendor, or a border? That’s sovereignty.
Sovereignty. Sensitive data stays under an organization’s control regardless of where AI operates. It’s not under the control of a cloud provider or the vendor of the AI model. Protection and policy travel with the data across departments and national borders.
What makes Protegrity unique?
Protegrity addresses the full stack – control, enforcement, verification, and execution. Most vendors address one or two stages; very few provide enforcement.
Consider these categories:
- Data Security Posture Management vendors (Cyera, BigID, Varonis) target discovery and classification. They offer visibility but no enforcement. They tell you there’s a fire; we put it out.
- Identity and Access Management solutions (SailPoint, Okta, CyberArk) decide who gets in, but access is not context. They can verify who you are, but they can’t see what you’re combining, why you’re asking, or what the answer will reveal. In the AI era, least privilege must become least context.
- Data Loss Prevention tools (Forcepoint, Microsoft Purview) sit at the perimeter, catching known patterns at the edge. But agentic leakage doesn’t happen at the edge – it happens inside the reasoning chain, where perimeter tools can’t see. Protection must be embedded in the workflow, not wrapped around it.
- Model security and guardrail startups (Protect AI, HiddenLayer) scan for vulnerabilities in the model itself but have no capability at the data and knowledge layer, where the sensitive assets live.
And to be clear about what isn’t on this list: the models, MCP implementations, and orchestration frameworks AI runs on are not data protection controls. Every one of them assumes the data arriving is already safe to use. That assumption is exactly the gap Protegrity fills.
The seams between point tools are where AI breaks. Leakage happens in a handoff, but no single-purpose tool can prove what happened for an audit. Policy loses consistency when data crosses a corporate or national boundary. Protegrity closes those seams: one policy, one point of enforcement, one chain of evidence.
It’s important to point out that the platforms data lives on – notably AWS, Azure, Databricks, Google Cloud and Snowflake – aren’t competitors of Protegrity. In fact, we make them better. Their security is specific to their environment; it can’t follow your data across multi-platform environments that may include clouds, borders, or vendors; and it can’t remove the reason teams hold sensitive data back in the first place. Protegrity can. Protection and policy travel with the data, so more of it can move to the platforms – and the AI workloads – where it creates value. The cloud providers win, because restricted data is data that never reaches their services. Customers win, because the data friction tax stops accruing at the platform door.