The AI team built something impressive.

The model works.
The data pipeline is running.
The business outcome is real.

Nobody asked who has access to the training data — or what happens if a query to the model can be used to reconstruct it.

This is not a hypothetical risk. It is a gap that exists in most enterprise AI deployments — and it lives precisely between the AI team’s responsibilities and the IT security team’s responsibilities, which means neither group owns it.

The conversation required to close it usually hasn’t happened yet.

Why enterprise AI creates a new security surface

Traditional application security is well understood.

Protect the perimeter. Control access to databases. Encrypt sensitive data in transit and at rest. Audit who queried what. The frameworks exist. The tools exist. The ownership is clear.

AI systems create a different kind of exposure — one that doesn’t fit neatly into existing security frameworks.

When a model is trained on sensitive data, that data doesn’t just pass through the system and disappear. It becomes encoded in the model’s parameters. Under certain conditions, with carefully crafted queries, it can be partially reconstructed.

When an AI agent is given access to enterprise data sources to accomplish a task, it has effective read access to every piece of data within its scope — and the question of whether that access is appropriate is often never formally reviewed.

When employees use external AI tools to process work data — drafting emails, summarizing reports, analyzing contracts — that data leaves the organization’s control in ways that existing data loss prevention tools were never designed to detect.

These exposures don’t belong to the AI team.
They don’t belong to IT security.
They belong to a conversation between the two that most organizations have not had.

The four exposures that fall between teams

Training data that is more sensitive than anyone accounted for

AI models are trained on data. The data used for training is typically selected by the data science team based on relevance and availability.

The question of whether that data is appropriate to use for model training — whether it contains PII that should have been masked, whether it includes records from regulated populations, whether its use for this purpose was covered by the terms under which it was collected — is frequently not asked until much later.

In some cases, it is never asked.

The result is models built on training data that creates legal and regulatory exposure the organization cannot see until something surfaces it:

AI agents with access they were never supposed to have

AI agents are practical systems that need access to data to function.

The scope of that access is defined during development — typically by the team building the agent, using the permissions that are easiest to provision rather than the minimum access actually required.

When an agent is provisioned with broad read access to an enterprise data source “to keep things simple,” the agent has effective access to every record in that source. If the agent’s outputs are accessible to end users, those end users have indirect access to data they were never intended to see.

This is a version of the over-provisioned access problem that enterprise security teams understand well in the context of human users. In the context of AI agents, most organizations have not yet applied the same discipline:

Shadow AI that IT doesn’t know about

The AI tools that IT approved are not the only AI tools employees are using.

Employees use external AI assistants to summarize meeting notes, draft communications, analyze documents, and process data. They paste content from internal systems into publicly accessible AI interfaces. They upload files to get better answers.

Each of these actions represents a data transfer that existing data loss prevention tooling was not designed to detect — because the transfer looks like normal web traffic, not an unauthorized data export.

Organizations that believe their AI data exposure is limited to the systems IT approved for use are operating on an assumption that is almost certainly incorrect.

The model itself as a data leakage vector

A deployed AI model that accepts external queries can, under certain adversarial conditions, reveal information about its training data through its outputs.

This is not a theoretical research concern. It is a known class of attack — model inversion, membership inference — that has been demonstrated against models trained on medical, financial, and personal data.

Most enterprise AI teams have not built defenses against this class of attack into their production systems. Most IT security teams are not yet evaluating deployed models for this exposure.

The gap exists because it requires knowledge from both domains simultaneously — and the conversation between the two teams typically hasn’t happened:

Why Observability Still Fails Most Teams

Why this gap persists across organizations

The AI-security gap is not caused by negligence. It is caused by organizational structure.

AI teams own model development and deployment. Their domain expertise is in data, modeling, and delivery.

IT security teams own infrastructure security, access controls, and compliance frameworks. Their domain expertise is in threat modeling and control design.

The security risks created by AI systems require knowledge from both domains — and in most organizations, there is no formal mechanism for the two teams to evaluate AI deployments together before they go to production.

This is why the gap persists even in organizations with mature security practices and technically strong AI teams.

Each team is doing its job.
Neither team owns the intersection:

The cost of discovering this gap late

Organizations that discover AI security gaps through an incident — a regulatory inquiry, a data breach investigation, a public disclosure — face costs that extend far beyond the technical remediation.

Regulatory exposure from improperly handled training data.
Reputational damage from disclosed data leakage.
Operational disruption from AI systems that have to be taken offline during investigation.
Erosion of stakeholder trust in AI investments that is difficult to rebuild.

The competitive and financial cost of this discovery path makes the investment in the conversation — and in closing the gap proactively — straightforward to justify:

What the conversation needs to cover

The organizations that have closed this gap share one practical approach: they created a structured conversation between the AI team and IT security that runs at the start of every AI initiative — not at the end.

That conversation covers:

what data is being used for training, and whether its use is appropriate under applicable policies and regulations
what access scope is required for AI agents, and whether that scope can be minimized without impairing function
what employee behavior with external AI tools has been observed, and whether current DLP tooling addresses it
what the deployed model’s exposure surface is, and whether adversarial query scenarios have been evaluated
who owns the response if any of these surfaces is exploited

This does not require a new security framework.
It requires a recurring conversation that currently isn’t happening:

If your AI team and IT team are operating in parallel without intersecting

If AI systems are moving to production without a formal security review designed for AI-specific exposures…

If the training data used in active models has never been evaluated for regulatory or policy appropriateness…

If nobody has formally assessed what access scope AI agents are operating with…

The gap exists.

The question is whether you find it proactively or reactively.

How to close the gap before it becomes an incident

A focused Data & AI Delivery Efficiency Audit evaluates one AI initiative or deployed system and identifies:

what data exposures exist in the training and inference pipeline
where AI agent access scope exceeds what is operationally necessary
whether current observability is sufficient to detect anomalous query patterns
which organizational gaps are preventing the AI and security teams from evaluating systems together
what changes would close the highest-risk exposures before the next deployment

The result is not a theoretical risk report.

It is a practical picture of where the gap is — and what the conversation between your two teams needs to cover.

The Security Conversation Your AI Team and Your IT Team Still Haven't Had