Enterprise AI has moved well past the pilot stage. According to the F5 2026 State of Application Strategy Report, 78% of organizations said they are already operating AI inference. And 98% said they are preparing for agentic AI.
As enterprises race ahead with implementing AI systems, data governance is emerging as a key challenge. AI systems depend on data at every stage of their lifecycle. Organizations feed data into AI models for training and refinement. AI tools receive data as prompts, retrieve data from vector databases, and output data as narrative responses. And autonomous agents access data to fulfill tasks.
Each step involves a data governance decision. Data flow must be monitored and data access controlled. Too few organizations have governance in place before deploying the latest tool or developing a new agent. As a result, data, and the business, are left exposed to multiple threats.
The first step in implementing AI data governance is understanding how it differs from both traditional data governance and AI model governance. You can then focus on areas of greatest risk and establish practices that control sensitive data without slowing down AI implementation.
What is AI data governance?
AI data governance is the set of policies and technical controls that oversee how data is collected, classified, used, transmitted, retained, and deleted across the AI lifecycle. Data governance should cover a wide range of data, including:
- Data used for training and fine-tuning models.
- Prompts and responses exchanged during inference.
- Data that augments responses from models.
- Tool and API calls made by agents.
- Telemetry data generated during AI processes.
Traditional approaches to data governance won’t work with AI systems. Those approaches focus primarily on structured data that resides in enterprise repositories. That data, at rest, is accessed through predictable queries, and access is reviewed on a periodic cycle.
AI system data has different attributes and behaviors. Specifically, AI data is:
- Unstructured and conversational: Free-form prompts and AI-generated responses can’t be governed by policies designed for structured data residing in databases.
- In motion: In AI systems, data is constantly moving as prompts are input into a model, which returns a response. An AI agent might make thousands of calls to APIs and models in seconds. The quarterly access reviews of traditional data governance models won’t be sufficient to control this data in motion. AI data governance must be automated to keep up with the machine speed of AI systems.
- Non-deterministic: An AI model might answer the same question differently each time. Output controls have to evaluate meaning and context. They can’t rely on the pattern matching of traditional data governance.
With AI system data, governance must be enforced inline, at the points of interaction.
AI data governance vs. AI model governance
AI data governance and AI model governance must work together, but they are distinct strategies. They are often owned by different teams.
AI model governance focuses on controlling models and agents. Model governance strategies control which models are approved for use, who owns the models, how they are trained, which version is running in production, how behavior is monitored, and when models are retired.
AI data governance centers on the data accessible to AI and the paths it travels along. These strategies control how data is classified, what data is prevented from moving beyond the enterprise, where it should be processed, and how long it should be retained.
| AI data governance | AI model governance | |
|---|---|---|
Core question | What data can flow into and out of AI systems? | Which models and agents are approved, and how should they behave? |
Typical artifacts | Data classification policies, redaction and blocking rules, retention and residency requirements | Model inventory, evaluation results, documentation, version history |
Key controls | Inline inspection of prompts, responses, and tool calls | Approval workflows, versioning, permission scoping, monitoring of model drift and behavior |
Usual owners | Security, privacy, and data protection teams | Machine learning engineering, risk, and compliance teams |
Example of failure | Sensitive data leaves through an ungoverned prompt or response | An unapproved or outdated model acts with more access than intended |
AI data and model governance must work together because otherwise they will fail together. If model prompts and responses are not inspected, even a thoroughly documented, well-evaluated model can still leak regulated data. Similarly, if an unapproved agent has access to a customer database, strong data controls might not keep data from being exposed.
This interdependence is reflected in established AI governance frameworks and standards. The National Institute of Standards and Technology AI Risk Management Framework (NIST AI RMF) takes a lifecycle approach to AI risk through its Govern, Map, Measure, and Manage functions. ISO/IEC 42001 similarly establishes an organization-wide management system for governing AI, while the Cloud Security Alliance AI Controls Matrix (AICM) translates AI governance into actionable security controls. Across these approaches, data and model governance are not treated in isolation: both are part of managing AI risk across the lifecycle.
Identifying key AI data risks
There are several potential ways that data might be accidentally or purposefully exposed while flowing through AI systems. AI governance exists to close or mitigate these vulnerabilities.
- Shadow AI: Employees frequently adopt AI tools without the knowledge of security or IT teams. Even when you have enterprise-wide security solutions or data governance policies in place, data flowing through unsanctioned AI systems remains ungoverned.
- Input: When using sanctioned tools, employees still might inadvertently input sensitive information, ranging from customer data to health information, simply because it’s the fastest way to answer questions. That data can be exposed to exfiltration.
- Output: When prompted in certain ways, a generative AI model can reproduce fragments of training data, including pieces of personal information (sometimes called a memorization leak). An attacker can use AI to reassemble those pieces, reconstructing sensitive information for fraudulent aims.
- Retrieval pipelines: Retrieval-augmented generation (RAG) draws on data stored in vector databases. When documents are embedded into those databases without their original access controls, a model can surface content to a user who does not have permission to open the original file.
- Agents with standing privileges: Any threat to an agent extends to the tools, databases, and servers the agent is connected to. If an agent is given broad permissions, the data it touches can become exposed.
- Third-party models: Sending prompts to an external model means that sensitive data leaves the organization’s control and may cross geographical boundaries. This makes it more difficult to govern retention periods, control processing locations, meet data localization requirements, and ensure sensitive information is not used for model training.
- Data persistence: Deleting data after a certain period of time or in response to a customer request is often a requirement of data governance policies. Deleting records from a database is simple enough, but it’s more difficult to remove information already absorbed into model weights. As a result, plan carefully as to what data you use for training.
Why security tools leave gaps for AI systems
Data loss prevention (DLP) and data security posture management (DSPM) tools can be extremely valuable for securing enterprise data. But AI systems can uncover important limitations of these tools, including:
- Lack of real-time data visibility: DSPM tools map where sensitive data lives. But the data used by AI systems is on the move, and it becomes vulnerable as it moves. DSPM tools can’t provide the real-time visibility needed for governing that data.
- Classification tuned for structured data: DLP and DSPM tools use pattern matching to classify data. This works for structured data, but not as well for the unstructured, narrative content that users include as prompts and receive as responses.
- Enforcement in the wrong place: A DLP tool might be able to block an upload from an endpoint, but be unable to stop a user from sending a prompt containing sensitive information. The tool would have to reach the inference layer, where the data exchange is occurring.
- No usable record: Compliance teams often need to show what an AI system was asked, how it responded, and which policy was applied. Conventional DLP and DSPM tools can’t produce that evidence.
These tools were simply not built for protecting data in AI workflows. They must be supplemented with AI-specific strategies and solutions.
Practices to strengthen AI data governance
Not all AI governance strategies are identical. However, strategies that successfully minimize risks often share several of these eight best practices.
- Inventory all AI use: Before you can govern data, you need to know where and how data is being used by AI across your enterprise. Catalog not only approved applications and agents, but also unsanctioned tools to uncover every path where data might be flowing.
- Classify data during interactions: In addition to classifying data at rest, you need to classify data in prompts, responses, and tool calls. Doing so requires capabilities to understand conversational context rather than only structured patterns.
- Enforce policies inline: Data governance policies should be enforced as data is flowing, before it reaches its destination. Redacting sensitive data as it is being input in a prompt, for example, enables employees to keep working while preventing that data from being ingested into a model’s knowledge base, internal or external.
- Apply the principle of least privilege: Models, agents, and RAG tools must be prevented from accessing sensitive data. Establish guardrails for AI systems, ensuring AI models and agents can access only what they absolutely need to, and review system permissions on the same cadence as human users.
- Produce an audit trail: To improve incident response and comply with regulations, keep an audit trail that contains requests, responses, policies applied, and enforcement decisions. You can use that information to fine-tune policies and demonstrate compliance.
- Test continuously: Threats evolve quickly. A policy that successfully protects sensitive data today may no longer be as effective in six months. Implementing red teaming and automated testing can help find gaps and update policies.
- Control the data supply chain: Comprehensive governance requires visibility into every element in an AI system that touches data. When you use external models, for example, review the provider’s terms for training opt-outs, retention windows, processing locations, and use of subprocessors.
- Assign ownership: AI data governance can involve security, privacy, legal, data science, and application teams. Assign ownership of data governance and conduct recurring reviews to help ensure that systems deployed don’t drift from established policies.
Applying governance where AI runs
Most data governance practices are effective only if they are applied in the direct path of AI traffic. That is the principle behind the F5 approach to AI data governance and security.
The F5 AI Security Platform brings together discovery, governance, testing, and runtime protection across enterprise AI. F5 Workforce AI Security provides visibility into sanctioned and unsanctioned AI use, including the models, tools, prompts, and data being used across the workforce. F5 AI Gateway provides a control point for governing access to AI models, agents, and tools. F5 AI Red Team uses adversarial testing to identify vulnerabilities and weaknesses in AI systems, while F5 AI Guardrails enforces policies during AI interactions to help prevent sensitive data leakage, malicious activity, and policy violations.
Data does not need to be a vulnerability. With the right data governance in place, you can move ahead with AI adoption, securely and confidently.
Frequently asked questions
What is the difference between AI data governance and traditional data governance?
Traditional data governance primarily manages structured data at rest in repositories. AI data governance must cover unstructured data in motion, like the text users input into AI tools and receive as AI-generated responses. Because that data is in motion, governance must be applied inline, at points of interaction.
How does AI data governance relate to AI model governance?
AI model governance oversees models and agents. For example, organizations must inventory models, manage permissions for agents, and monitor behavior. AI data governance focuses on the data flowing into and out of those models and agents. In practice, data and model governance must work together because when one fails, so does the other.
Why are traditional security solutions, like DLP and DSPM tools, insufficient for AI data governance?
While data loss prevention (DLP) and data security posture management (DSPM) tools are essential for protecting data, they have limited utility for AI data governance. Most can’t provide real-time data visibility, classify unstructured data, enforce governance during inference, or generate audit trails for AI systems.
How does F5 help organizations build effective data governance strategies?
The F5 AI Security Platform enables organizations to discover AI usage across the enterprise, develop data governance policies, and implement policies while data is flowing through AI systems. Organizations can also use F5 capabilities to generate audit-ready records to comply with laws, frameworks, and standards relating to data and AI systems.
Learn more about the F5 AI Security Platform.
About the Author
Related Blog Posts
When patching can't keep pace and protection can't wait
Because security threats move faster than app development and deployment cycles, protection must operate independently. Here’s how modern WAAP steps up.
Securing the new control points in the AI journey
AI architecture is fundamentally different than traditional IT environments and requires a different security strategy to protect critical AI workloads.
The patch window has closed. Here is how F5 is built for what comes next.
As AI models have changed software security, the industry needs to adapt.
Best practices for optimizing AI infrastructure at scale
Optimizing AI infrastructure isn’t about chasing peak performance benchmarks. It’s about designing for stability, resiliency, security, and operational clarity
Datos Insights: Securing APIs and multicloud in financial services
New threat analysis from Datos Insights highlights actionable recommendations for API and web application security in the financial services sector
How AI inference changes application delivery
Learn how AI inference reshapes application delivery by redefining performance, availability, and reliability, and why traditional approaches no longer suffice.