Why AI Pushes CISOs to Rethink Production Data Policies

The rise of in-house AI development is creating a challenge for CISOs. Security must learn how to balance the need for production data in model training with the policies designed to keep that data secure.

DOWNLOAD NOW: Using Production Data in AI Development

Most organizations have long-standing policies that prohibit the use of production data in development environments. The reasoning is based on the fact that development environments typically operate with looser security controls than their production counterparts. AI model training is changing this established practice, forcing CISOs to reconsider when and how production data can be safely used outside production systems.

READ MORE: The Real Role of AI in Security Operations

The Unique Data Requirements of AI

Unlike traditional software development, AI model training requires access to production data. When models are trained, the model becomes a representation of the training data. Traditional application development, by contrast, produces software that consumes or manipulates data but doesn't embody it.

Moving production data into development environments with weaker security controls introduces risk. But restricting AI teams from accessing the data they need to build effective models hampers innovation and competitive advantage.  Security experts note that organizations performing in-house model training should move AI development to environments with the same security controls as production systems. Because production data is typically required to train AI models, it makes sense to elevate the security posture of training environments rather than lower the protection standards for sensitive data.

This approach mirrors how development teams interact with external APIs—by hosting a development version of the model in a production environment and allowing development and quality assurance teams to access it. Special consideration must be given to retrieval augmented generation applications, which are likely to return significant quantities of production data directly.

Not every AI project demands access to production data. While model training always requires real data, building autonomous AI agents to interact with websites does not—developers can use test accounts with synthetic data during development. Similarly, AI projects focused on natural language processing for feature extraction can rely on synthetic data.

If the output of the AI development effort is a model, production data is required. If the output is a process, synthetic or anonymized data is acceptable.

READ MORE: How to Effectively Use AI

How to Limit Access to Production Data

One challenge CISOs face when allowing production data for AI model training is that other development teams might start requesting access for their own purposes. Application developers, data visualization teams, and data engineering groups have sought production data access, arguing it reduces risks associated with synthetic or anonymized data not really representing real-world conditions.

But the risk profiles differ significantly. With model training, production data can be deleted from the development environment once training concludes—a step that should ideally be automated in the continuous integration/continuous delivery or machine learning operations pipeline. This time-limited exposure minimizes risk.

Other development activities lack such clear boundaries. Application developers and data engineering teams require ongoing access to testing data, leading to data hoarding that extends risk exposure indefinitely. If these teams genuinely require production data, security leaders should enforce the same controls as in production environments.

DOWNLOAD NOW: Tips for Reducing AI Risk

Critical Considerations with Production Data

Before permitting production data in any development context, CISOs should evaluate several factors.

Organizations must determine who owns the data and whether they approve its use in environments with fewer security controls. The 2024 Snowflake breaches revealed how data owners were unaware that their information had been aggregated in cloud environments without multi-factor authentication requirements.

Also, if data originated externally, legal agreements likely mandate specific controls or prohibit certain uses. Data privacy policies may also prescribe strict limitations on how collected data can be used. And the "right to be forgotten" presents an emerging challenge. How organizations will handle this requirement when data contributes to an AI model remains unresolved in case law. Security experts recommend retaining detailed artifacts documenting which data was used to train specific models, ideally generated automatically through machine learning operations pipelines and stored in artifact repositories.

How to Move Forward with Production Data and AI

With in-house AI development accelerating, many organizations are reassessing their production data policies. Some are moving AI development and model training to production environments. Other organizations are applying stricter controls to development environments in which AI training occurs.

AI model training's use of production data differs from traditional development activities. While production data would be convenient for application developers and data visualization teams, it's not required—and the risks of providing access remain high. AI development might warrant special consideration, but it cannot extend to every team requesting production data access. 

DOWNLOAD NOW: AI Acceptable Use Policy Template

Get the Latest Analysis on the CISO Talent Landscape

You can also download our 2025 Security Organizational Design Benchmark Report—and gain access to valuable insights on team design, leadership positions, and pay ranges broken out by three distinct revenue and staffing clusters: contact us to request the full report.

Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.