Why do traditional data in motion and data at rest models fail for AI risk?

Why This Matters for Security Teams

Traditional data in motion and data at rest models assume that risk appears at a clear technical boundary, such as a network transfer, a storage location, or an encrypted file. AI workflows often bypass those assumptions. Users move sensitive prompts, source material, and outputs through browser sessions, copied text, plugins, and application connectors that never look like classic file transfer events. That means governance, monitoring, and retention controls can miss the point where data actually entered an AI system.

This matters because AI risk is not just about whether data is stored or transmitted. It is also about who can influence the model, what context it can ingest, and whether the output can be trusted, explained, or audited later. Guidance from the NIST Cybersecurity Framework 2.0 is helpful here because it shifts attention toward outcomes, governance, and continuous protection rather than a narrow storage or transport view. That framing fits AI far better than legacy boundary thinking.

Security teams also get tripped up when they try to retrofit DLP or storage classification controls onto AI use without understanding the workflow. A prompt may include regulated data, but the same material can be copied into a chat interface, summarized by an external service, and reused downstream without a durable boundary event. In practice, many security teams encounter the breach only after the model has already used the data, rather than through intentional governance of the input path.

How It Works in Practice

AI risk management needs to follow the lifecycle of the interaction, not just the location of the file. The question is less “Where is the data stored?” and more “What context did the model receive, from whom, under what policy, and with what downstream permissions?” That is why the NIST AI Risk Management Framework is a better fit than a purely state-based data model. It encourages organisations to govern AI use, map risks, measure control effectiveness, and manage the full system lifecycle.

In practical terms, security teams should treat prompts, retrieved context, uploaded documents, and model outputs as governed events. That often means logging the interaction, tagging the source of the input, classifying the sensitivity of the context, and defining whether the content can be retained, reused, or sent to another service. For higher-risk workflows, the controls should also cover model provenance, connector trust, and output validation. This is especially important when AI systems are connected to SaaS tools, knowledge bases, or agentic workflows that can act on behalf of a user.

• Record the AI interaction, not just the file object.
• Classify prompts and retrieved context before they enter the model.
• Restrict connectors, plugins, and tool access by business purpose.
• Validate model outputs before operational use or automated action.
• Preserve enough telemetry for audit, incident response, and policy review.

The NIST IR 8596 Cyber AI Profile is useful for translating these ideas into cyber operations, especially where AI is embedded into detection, analysis, or response tooling. ISO/IEC 42001:2023 AI Management System Standard also helps by anchoring AI controls in management-system discipline, which is often what state-based data models lack. These controls tend to break down when AI is used through unmanaged browser-based assistants and ad hoc integrations because the organization loses visibility into the actual input path.

Common Variations and Edge Cases

Tighter AI data controls often increase friction for users and product teams, so organisations have to balance protection against speed and usability. That tradeoff is especially visible when teams want to block all external AI use, but business units depend on rapid summarisation, retrieval, or code assistance. Current guidance suggests the answer is not blanket denial or blind trust, but policy-based governance that distinguishes low-risk from high-risk use cases.

There is also no universal standard for classifying AI inputs and outputs yet. Some organisations treat prompts as records, some treat them as transient telemetry, and others apply sensitivity labels only when the input contains regulated content. The right approach depends on the workload, jurisdiction, and retention obligations. For example, a customer-support copilot, a developer assistant, and an internal research agent do not create the same risk profile even if they all use the same underlying model.

Edge cases become sharper when AI systems can take actions, not just generate text. Once an agent can open tickets, query systems, or trigger workflows, the risk shifts from data handling to delegated authority. In those environments, identity, privilege, and authorization become part of the AI risk model, which is why AI governance increasingly intersects with NHI and access control design. This is where traditional data state models fail most clearly: they do not explain who or what was allowed to act on the information after it entered the system.

Related resources from NHI Mgmt Group

• When does AI create more governance risk than traditional data systems?
• Why do AI native workflows create more identity risk than traditional engineering models?
• Why do traditional access controls fail to protect sensitive data in cloud and AI environments?
• Why does unprofiled data create more AI risk than traditional reporting risk?