Data Debt Is Becoming an Enterprise AI Security Risk

Google News surfaced a warning from IT Brew that challenges a common enterprise AI assumption: newer models cannot compensate for years of neglected data controls.

The immediate issue is data debt, the accumulated cost of incomplete, inconsistent, inaccessible, or poorly governed information. That debt predates generative AI. However, AI systems can expose it faster and distribute its consequences further.

The conflict is no longer limited to whether bad data produces weak answers. AI agents can retrieve records, invoke software, and make recommendations across business systems. When their underlying data lacks clear ownership or access rules, an accuracy problem becomes a security problem.

This puts enterprise leaders in an uncomfortable position. They face pressure to expand AI while security teams still lack reliable inventories, classifications, retention policies, and permission maps. Deployment speed and accountable data governance are now moving at different rates.

A June 2026 study from Genpact and HFS Research gives that tension a financial frame. Its authors surveyed 2,002 executives across 16 industries and identified data, technology, process, and talent debt as barriers to AI value.

The report estimates that these accumulated liabilities leave about $18 trillion in potential value trapped across Global 2000 companies. That estimate deserves caution, but the underlying problem is concrete. AI cannot safely use information an organization does not understand.

The Google News Warning Is About Infrastructure, Not Just Models

The important change is that data debt now shapes what AI systems can access, expose, and act upon.

IT Brew’s coverage builds on a wider reassessment of enterprise AI readiness. Companies spent years treating scattered records, duplicate databases, undocumented fields, and broad permissions as manageable operational friction. AI turns those compromises into inputs.

A conventional application usually reaches information through predefined queries and predictable workflows. A generative AI assistant can retrieve semantically related material from several repositories. An agent can go further by choosing tools and taking actions.

That expanded reach changes the security calculation. A forgotten document in an old shared drive might not attract attention during normal work. A retrieval system can surface it because its contents resemble a user’s question, even when its storage location appears obscure.

A stale entitlement creates a similar problem. An employee who retains access after changing roles might rarely visit the old system. An AI assistant connected to that system can bring its contents into routine conversations. In practice, a salesperson who moved to another region might ask for account history and receive pricing concessions or customer notes from a territory they no longer manage.

The original access failure remains human-made. AI increases the frequency and scale at which the failure can matter.

This is why the distinction between data quality and data security is becoming less useful. An incorrect customer classification can distort an AI recommendation. A missing sensitivity label can expose the same customer’s private information.

Both failures originate in data management. Their consequences land in different parts of the business.

The enterprise debt study defines data debt as the drag created by fragmented, inaccessible, poor-quality, or inadequately governed information. It places that burden beside process, technology, and talent debt.

Those categories interact. Legacy applications create fragmented data. Fragmented data forces employees to build manual workarounds. Manual workarounds depend on undocumented knowledge held by a few people.

Adding AI to that environment does not remove the dependencies. It can hide them behind a conversational interface.

The study found that poor decision quality and unreliable insights were the most frequently selected primary business effect of data debt, at 18%. Higher costs and wasted effort followed at 15%.

Security does not sit outside that chain. A business cannot consistently protect data if it cannot identify authoritative copies, responsible owners, or legitimate users. It also cannot explain an AI decision when the supporting records lack provenance.

Provenance describes where information came from and how it changed. It becomes essential when a model combines search results, internal documents, user instructions, and external tools. In joint guidance, the NSA, CISA, FBI, and international partners specifically recommend tracking data provenance and authenticating trusted revisions throughout the AI lifecycle.

Without provenance, investigators might see an unsafe output but struggle to reconstruct its cause. Was the source inaccurate, poisoned, outdated, improperly permissioned, or simply misunderstood by the model?

Google News is useful here as a signal of growing attention, not as the evidence itself. The underlying evidence comes from enterprise surveys, security telemetry, standards, and reported organizational experience.

IT Brew’s own automation research found that only 12% of surveyed IT professionals felt very confident that employees understood relevant data security policies. That figure reflects awareness, not technical enforcement, but it highlights the weak human layer surrounding rapid adoption.

The same research found that 29% of respondents experienced slightly increased complexity after AI deployments. Complexity matters because security teams must understand a system before they can monitor it reliably.

A complicated AI stack can span data warehouses, vector databases, model providers, identity systems, plugins, and employee devices. Each connection creates another place where permissions, logging, or retention rules can diverge.

The headline, therefore, is not that enterprise data needs another cleanup campaign. AI has changed the consequences of postponing that work.

Data Debt Expands the AI Attack Surface

Poorly governed data gives AI systems more opportunities to reveal sensitive information or follow compromised context.

An attack surface includes every path through which a system can be manipulated or reached. AI expands that surface because natural language becomes an interface to data and software.

The risk begins before an attacker enters the picture. Employees can paste proprietary material into unapproved services. Teams can connect assistants to repositories without reviewing inherited permissions. Developers can collect operational logs containing secrets or personal data.

These actions create shadow AI, meaning AI use that operates outside approved security and governance controls. The tools may be legitimate, but the organization cannot reliably observe how information moves through them.

Cyberhaven’s AI risk research analyzed billions of data movements involving generative AI services, endpoint applications, and agents. The company says enterprise AI behavior is creating risks that older controls often cannot see.

Vendor research should be read with its commercial incentives in mind. Still, the described visibility gap aligns with a basic security principle: controls cannot protect information they cannot locate or classify.

Data debt weakens that visibility in several ways.

First, duplicate records make it difficult to identify the authoritative version. Security teams might secure a current database while an older export remains available through a shared folder.

Second, incomplete classification leaves models without dependable rules for handling sensitive content. A document can contain confidential information even when its file label says nothing.

Third, inconsistent identities obscure who should have access. Acquisitions, contractor accounts, shared credentials, and role changes can leave permissions that outlive their business purpose.

Fourth, weak retention practices keep information available after its value has expired. AI retrieval makes that dormant information easier to rediscover.

Fifth, missing lineage prevents teams from tracing an output back to its origin. This complicates incident response and makes harmful errors harder to contain.

These weaknesses become more serious when AI agents receive standing access. Standing access remains available continuously, instead of being granted briefly for a specific task.

An assistant that only drafts text from approved documents has limited operational reach. An agent that can read invoices, update customer records, and send messages combines several trust boundaries.

If one connected repository contains misleading instructions, the agent can encounter indirect prompt injection. In that attack, malicious text inside external or retrieved content attempts to redirect the model’s behavior.

The model might treat the hostile text as an instruction rather than ordinary data. Effective defenses require more than filtering suspicious phrases. Systems must separate trusted instructions from untrusted content and restrict what tools can do.

Data debt complicates that separation. When organizations lack reliable source inventories, they cannot easily decide which repositories deserve trust. When document ownership is unclear, nobody has a clear duty to review risky content.

Access control also behaves differently in retrieval systems. A search index can preserve information after the original document is deleted or restricted. Cached embeddings, which are numerical representations used for semantic search, can create additional lifecycle questions.

The embedding might not reproduce a source document by itself. However, the indexed text, metadata, retrieval cache, and model logs can each preserve sensitive details.

Security teams must know which components store raw content and which store derived representations. They must also understand deletion behavior across the entire pipeline. For example, when a departing contractor loses access to a project folder, the same restriction should promptly reach the search index; otherwise, former teammates may continue seeing excerpts from documents that the source system no longer returns.

The Cloud Security Alliance reported that unstructured information represents an estimated 70% to 90% of enterprise data. Its unstructured data study argues that traditional governance practices are struggling with this volume.

Unstructured data includes emails, chat messages, documents, recordings, and presentations. It is also the material that retrieval-augmented generation systems often target first.

That creates a central reversal. The information businesses once considered too scattered to manage has become valuable AI context. Its usefulness attracts integration before governance work is complete.

Faster AI Deployment Collides With Accountable Governance

The primary contest is between deployment speed and the ability to explain every important data access or AI action.

AI programs often begin with a visible business target. A support team wants faster responses. A finance group wants automated invoice review. An engineering organization wants assistants that search technical documentation.

Data remediation has a less immediate payoff. Cataloging records, reviewing permissions, removing duplicates, and defining retention rules can feel detached from the demonstration executives expect.

That difference in visibility encourages teams to build the AI layer first. They connect a model to existing systems, test a promising workflow, and postpone foundational work until scale becomes necessary.

The approach works while the pilot remains narrow. It fails when the organization adds users, repositories, tools, or autonomous actions.

Security teams then inherit a system whose value depends on broad access. Restricting that access can reduce answer quality. Leaving it broad can violate least-privilege principles.

Least privilege means giving each user or service only the access required for its present task. It becomes harder to apply when an agent performs many tasks for many users.

An employee’s access rights should not automatically become an agent’s permanent permissions. The agent can operate faster, combine information across systems, and act when the employee is not watching each step.

Telemetry from Teleport illustrates the concern. Its 2026 survey covered 205 CISOs, security architects, and platform leaders. The company reported that organizations with over-privileged AI systems experienced 4.5 times more security incidents than those enforcing least privilege.

The identity security findings come from a vendor and do not establish causation. They still point to a credible mechanism: unnecessary access increases the number of damaging actions a compromised system can take.

Good governance must operate at several levels.

At the data level, teams need owners, classifications, quality rules, retention periods, and approved uses. At the identity level, they need clear mappings among users, services, agents, and resources.

At the model level, they need testing for leakage, unsafe tool selection, unreliable outputs, and manipulation. At the operational level, they need logs that connect an AI action to its user, data sources, model, instructions, and tools.

None of these controls works well in isolation.

A perfect access log cannot explain whether a source was accurate. A clean data catalog cannot stop an agent from taking an unnecessary action. Strong model testing cannot compensate for credentials that allow unrestricted production changes.

This is why purchasing an AI security product does not erase data debt. Products can improve discovery, monitoring, policy enforcement, or testing. They cannot decide every organization’s legitimate ownership and use rules.

Those decisions require business participation. Legal teams understand contractual obligations. Privacy teams understand personal-data requirements. Department leaders understand which records remain operationally necessary.

Security teams translate those responsibilities into controls, but they cannot invent the underlying business context. CISA and the UK National Cyber Security Centre’s joint secure-AI guidelines, endorsed by 23 cybersecurity organizations, similarly place responsibility on secure design, transparency, and organizational ownership across development and operation.

The pressure extends to knowledge workers. Employees often create local archives, duplicate notes, or private exports because official systems are difficult to search. These copies can preserve valuable context while escaping centralized governance.

A well-designed knowledge management system can reduce unnecessary fragmentation when its access and retention rules remain clear. It can also create new risk when teams ingest material without reviewing permissions.

The objective is not maximum centralization. It is predictable control over where information lives, who can reach it, and how AI can use it.

That goal conflicts with the belief that an AI model should search everything. Broad retrieval can improve convenience, but it also increases exposure and makes incorrect context harder to detect.

The secure alternative is selective retrieval. Systems should filter sources according to the user, task, sensitivity, and current authorization state before content reaches the model.

That filtering must happen at request time. Copying documents into a central index under one service account can flatten the distinctions that existed in source systems.

Teams also need explicit tool boundaries. An agent that analyzes an invoice does not automatically need permission to approve payment. An assistant that recommends a customer response does not need authority to send it. In practice, the finance reviewer should see the proposed payment, source invoice, and exception flags, while the agent remains unable to release funds without a separate authorized approval.

These distinctions slow initial deployment. They also make scaled deployment more defensible.

What the Data Debt Numbers Do Not Prove

Enterprise debt research identifies a widespread constraint, but it does not show that every AI failure begins with bad data.

The $18 trillion estimate from Genpact and HFS Research is the most striking figure associated with the recent coverage. It represents modeled potential value, not money recorded in corporate accounts.

The estimate combines possible revenue growth and cost reductions if Global 2000 companies resolve four kinds of enterprise debt. It should not be interpreted as a guaranteed return from data modernization.

Only one of the four categories is data debt. Process, technology, and talent constraints can block a project even when its information is accurate and well governed.

A model can also fail because of limitations unrelated to data hygiene. It can hallucinate, misunderstand a request, select the wrong tool, or respond inconsistently to similar prompts.

Security failures have many sources. A compromised dependency, stolen credential, vulnerable API, unsafe plugin, or flawed application design can bypass otherwise good data governance.

Treating data debt as the single cause would repeat the same simplification that created the problem. Enterprise AI systems are sociotechnical systems, meaning their behavior depends on software, information, processes, and people together.

The report’s survey design also matters. Executive responses reveal perceived organizational constraints. They do not offer an independent audit of every participating company’s data estate.

Respondents might use “data debt” to describe different conditions. One executive may mean duplicate customer records. Another may mean poor analytics quality, limited access, or missing governance.

The category remains useful because these conditions share a delayed-cost pattern. Organizations gained short-term speed by postponing work, then encountered higher costs when AI required consistent information.

However, the label can become too broad. Vendors can attach “debt” to any legacy problem and present modernization as the obvious solution.

That framing risks encouraging another expensive transformation program without clear priorities. A company might replace platforms while preserving unclear ownership and excessive access.

The better test is operational. Can the organization answer specific questions about a high-value AI workflow?

Teams should know which sources the system uses, who owns them, and when they were last reviewed. They should know whether permissions remain aligned with current roles.

They should know what the agent can do after retrieving information. They should also know whether investigators can reconstruct an important decision without relying on the model’s narrative.

The National Institute of Standards and Technology organizes AI risk work around governing, mapping, measuring, and managing risk. Its AI Risk Management Framework and Generative AI Profile call for documented system purposes, continuous monitoring, defined incident-response ownership, and regular review of third-party AI systems rather than reliance on a single control or product.

That lifecycle view fits data debt because old weaknesses rarely disappear through one migration. Teams must continue checking quality, permissions, provenance, and use as systems evolve.

Another uncertainty concerns measurable security outcomes. Survey respondents can report weak readiness, but enterprises rarely disclose detailed AI incidents. Public data therefore offers an incomplete view of frequency and severity.

Some incidents may be classified as ordinary data loss, access abuse, or application compromise even when AI influenced the path. Others may involve unsafe outputs without causing a reportable breach.

This makes comparison difficult. Organizations need internal definitions for AI-related incidents before they can evaluate whether controls reduce them.

A useful definition should capture model manipulation, unauthorized data disclosure, unsafe agent actions, and compromised AI infrastructure. It should also distinguish confirmed harm from policy violations and near misses.

Without that discipline, leaders can claim improvement because reported incidents remain low. The number might instead reflect limited detection.

The skeptical conclusion is straightforward. Data debt is a credible risk multiplier, not a complete explanation for AI insecurity.

Companies that clean their records but ignore agent identity, model behavior, and software dependencies will remain exposed. Companies that buy monitoring tools but leave ownership unresolved will face the same ambiguity under better dashboards.

Three Signals Will Show Whether AI Security Is Catching Up

The next test is whether enterprises turn concern about data debt into narrower permissions, traceable retrieval, and measurable incident reduction.

The first signal is the adoption of task-specific identity controls for AI agents. Organizations should move away from shared service accounts and permanent credentials.

Each agent should have a distinct identity, limited permissions, and an accountable human or business owner. Access should narrow according to the task and expire when no longer needed. NIST’s 2026 concept paper on the identity and authority of software agents identifies authorization, auditing, non-repudiation, and prompt-injection controls as specific areas requiring stronger standards and implementation guidance.

If this becomes standard practice, the gap between AI deployment and security readiness will begin to close. If standing access remains common, data debt will keep translating into a larger blast radius.

The second signal is evidence that retrieval systems preserve source permissions and deletion rules. Enterprise AI vendors increasingly promise secure connectors, but buyers need technical proof.

Security teams should test whether revoked access disappears from search results promptly. They should verify how indexes, caches, logs, and backups handle deleted material.

They should also check whether citations reliably identify the exact source used for an answer. A generic link to a repository is insufficient when investigators need document-level provenance.

Progress here would strengthen the argument that organizations can use dispersed information without flattening its controls. Continued permission drift would show that convenience still outranks accountable retrieval.

The third signal is better disclosure of AI-related security events. Enterprises and vendors need consistent categories that distinguish data leakage, prompt injection, excessive agency, identity abuse, and infrastructure compromise.

More reports do not necessarily mean security is worsening. Early increases can show that detection and classification are improving.

The important measure is whether organizations reduce severe outcomes and shorten the time required to contain them. That requires comparable metrics, not isolated marketing claims.

These three signals should appear in procurement reviews and operational dashboards. They are more informative than the number of pilots launched or employees given access to an assistant.

Google News attention will continue shifting toward AI agents, new security products, and major incidents. Readers should look beneath those headlines for the condition of the data layer.

Ask whether a featured system knows which information is authoritative. Ask whether its access follows the user and the task. Ask whether its actions can be reconstructed after something goes wrong.

Enterprise leaders should start with one valuable workflow rather than an organization-wide cleanup promise. Map its sources, owners, permissions, retention requirements, agent tools, and failure paths.

Then test the controls with revoked accounts, poisoned documents, outdated records, and requests that cross authorization boundaries. Record what the system retrieved, ignored, and attempted to do.

That exercise will not eliminate every AI risk. It will reveal whether the organization understands the system it has already deployed.

The question is no longer whether data debt reduces model quality. It is whether businesses will retire that debt before AI turns every forgotten permission and unmanaged record into an active security decision.