Enterprise AI agents inherit more than information: existing permissions, data quality issues, and governance gaps. Learn why data readiness should begin with each use case.
What enterprise AI inherits from your data
The scenario below is hypothetical. It illustrates a pattern and does not describe a documented case.
A mid-sized company launches an AI assistant pilot for its finance team. In the first week, an analyst asks the assistant to summarize recent vendor contract terms. The assistant's response unexpectedly includes information from a spreadsheet of executive compensation stored in a team site that was created years ago and shared, at the time, with the entire company.
Nobody was hacked, and no permission was changed. The assistant simply retrieved information the analyst was already allowed to see.
The pilot is paused, the security team opens a review, and employees who were enthusiastic about the tool begin to wonder whether it is safe to use.
The failure did not start with the AI. It started years earlier, when a sharing setting was chosen for convenience and never revisited. The assistant made the consequences visible.
Enterprise AI assistants can retrieve organizational information using permissions associated with the signed-in user. Microsoft's documentation for Microsoft 365 Copilot, for example, explains that Copilot operates within existing permissions and access controls, accessing organizational information the user is authorized to access.
That principle is important, but it is not universal. Enterprise agents may also use application permissions, service identities, or delegated connections. Their effective access depends on the platform, configuration, and authorization model.
For assistants operating under user permissions, the problem is straightforward.
For years, overbroad access was often masked by obscurity. A file shared with everyone might still be difficult to locate. Natural-language search and retrieval can remove that practical barrier.
AI does not necessarily create the underlying permission exposure. It can make an existing exposure easier to discover and use.
This distinction matters. An organization may have technically functioning access controls while still granting access more broadly than the business intended.
Two industry sources are worth knowing, and both come with limitations.
Gartner. A July 2024 survey of 1,203 data management leaders found that 63% of organizations either lacked the right data management practices for AI or were unsure whether they had them.
Gartner also predicted that, through 2026, organizations would abandon 60% of AI projects unsupported by AI-ready data.
Two cautions apply. The 60% figure is a prediction, not a measured outcome. And AI-ready data encompasses quality, governance, metadata, and ownership broadly—not oversharing specifically.
Varonis. The data security vendor examined 1,000 organizational environments for its 2025 State of Data Security Report and reported that 99% had sensitive data dangerously exposed to AI tools.
This is a vendor finding drawn from environments the company assessed, not a representative survey of all enterprises. It nevertheless highlights the potential scale of existing data exposure.
These sources point toward a significant readiness problem, but they do not establish that permission hygiene directly determines AI project success or employee adoption.
The case for reviewing permissions before deployment rests on documented system behavior, observed exposure patterns, and established security principles.
That is a reasonable basis for preventive action. It is not proof of every downstream business outcome.
Four questions apply to the data an assistant or agent can reach:
The first three are governance questions. The fourth is a quality question.
Each matters for a different reason.
Incorrect permissions can expose information to unintended audiences. Missing ownership makes remediation difficult. Poor-quality content can produce unreliable answers even when access is properly controlled.
A useful readiness assessment must consider both whether the system should access the information and whether that information is suitable for its intended purpose.
After a data exposure scare, the instinct may be to demand an enterprise-wide cleanup before any AI assistant or agent goes live.
That is rarely achievable in a reasonable timeframe. As an absolute prerequisite, it can become a reason never to start.
Gartner's guidance points toward a more iterative approach: align data readiness activities with specific AI use cases while extending existing data management practices.
A use case has a boundary—the repositories, sites, mailboxes, databases, and connected services that the system is expected to access.
Readiness within that boundary is a manageable project.
A contract-summarization assistant for finance needs the relevant finance content reviewed. It does not necessarily require every repository in the enterprise to be remediated before the pilot begins.
But the boundary must reflect actual system behavior. An agent with broad search permissions or enterprise-wide connectors cannot be treated as though it only accesses one departmental folder.
Some foundations must also exist at the enterprise level: a functioning identity and access model, an established classification approach, and clearly assigned responsibilities for data ownership.
Each use case builds on those foundations.
Without them, every project must invent its own governance process.
"One use case at a time" describes how to prioritize and execute data readiness reviews—not an excuse to postpone foundational controls.
This approach is consistent with the risk-based thinking of the NIST AI Risk Management Framework, particularly its emphasis on understanding the context and risks of a specific AI system.
NIST does not prescribe this exact use-case-by-use-case review process. That connection is our interpretation.
ISO/IEC 42001 provides a broader AI management system structure within which organizations can establish responsibilities, governance processes, and continual improvement.
This is the part that goes beyond risk.
If the information an agent can reach is classified, appropriately permissioned, and owned, leaders have a stronger basis for approving access to additional content.
If it is not, the cautious response may be to restrict access.
That restriction can be necessary. But an assistant that cannot retrieve the information employees need may provide limited value.
In our assessment, this creates an important relationship between governance and usefulness.
Data readiness is not simply about preventing inappropriate access. It can also help organizations determine when broader, authorized access is justified.
This relationship should not be overstated.
The evidence discussed above concerns data readiness and exposure, not a demonstrated causal relationship between permission practices and employee AI adoption.
Technology acceptance research provides a useful perspective. Davis's Technology Acceptance Model emphasizes perceived usefulness and perceived ease of use, while the Unified Theory of Acceptance and Use of Technology considers factors such as facilitating conditions.
An assistant that consistently fails to answer legitimate business questions may struggle to demonstrate usefulness, regardless of how sophisticated the underlying technology is.
Whether stronger data governance directly improves adoption or sustained utilization remains a question for further investigation.
Three shifts follow.
Ownership. Data readiness sits between IT, security, and the business. Each may assume another group is responsible.
Technical administrators can identify broad permissions, but business owners are often best positioned to determine whether those permissions are appropriate.
Accountability must be explicit.
Sequencing. Readiness belongs before the pilot, not only after the first incident.
A narrowly scoped review can reveal material risks without requiring an organization-wide remediation program.
Measurement. Security findings alone do not tell leaders whether an AI deployment is successful.
Organizations should evaluate both the risks associated with accessible data and whether the approved system actually helps employees complete intended tasks.
Either measure alone can mislead.
Scoped data readiness addresses an important inbound risk: an AI system retrieving information that should not be available within its intended operating context.
It does not solve every enterprise AI security problem.
Prompt injection can occur when instructions embedded in retrieved content influence an AI system's behavior, even when permissions are correct.
Outbound data leakage can occur when employees disclose sensitive information to unauthorized external tools.
Excessive agent privileges can allow an autonomous system to perform actions beyond what its business purpose requires.
These risks demand additional controls and deserve separate treatment.
Data readiness is necessary for many enterprise AI deployments, but it is not a complete AI security strategy.
The question for enterprise leaders is not whether every piece of organizational data is ready for AI.
It is whether the information behind the next assistant or agent is appropriate for its intended use, and whether the foundations that make that assessment repeatable are in place.
Organizations that approach readiness one use case at a time can make progress without ignoring existing risk.
More importantly, they can begin treating governance not simply as a restriction, but as the process that allows them to approve useful AI capabilities with greater confidence.
As enterprise AI systems become more autonomous, the ability to grant appropriate access—and demonstrate why that access is justified—will become increasingly important.
Explore N2iT Research training and insights to connect adoption research with practical learning and application.