The policy layer is thinner than it looks
As discussed in our recent analysis of frontier model procurement, we view AI acceptable-use policies as inherently flexible — subject to revision, override, or reinterpretation as commercial and government requirements evolve.
For organizations operating in defense, intelligence, critical infrastructure, or export-controlled programs, we believe this highlights a direct implication: a vendor's published policy on data movement and acceptable use is informative but not sufficient. In our view, the more durable question is architectural: what data paths exist in the system, and which ones are structurally absent?
What "data movement" means in AI systems
Cloud-connected AI systems typically have multiple data-movement paths:
Inference telemetry. Prompts, completions, token counts, latency metrics, and error logs transmitted to the vendor or a central monitoring service. The content of this telemetry varies by vendor and configuration, and the vendor can change what is collected through a service update.
Model update channels. Connections that check for and download model updates, weight patches, or configuration changes. These channels move data inbound but may also transmit system state or versioning information outbound.
Usage metering. License verification, billing data, and consumption reporting that requires periodic communication with an external service.
Diagnostic and support channels. Crash reports, performance profiles, and debugging data that may be transmitted automatically or during support interactions.
Each of these paths represents a data-movement decision that the operating organization may or may not have visibility into, and may or may not be able to disable.
Architecture as evidence
The alternative to relying on policy commitments is relying on architectural properties that can be verified:
Absent network paths are stronger than restricted ones. A system with no network interface can't transmit data, regardless of what the software intends to do. A system that has a network interface but is configured not to use it relies on configuration correctness — which can be misconfigured, overridden, or updated.
Verifiable boundaries replace trust. In an air-gapped deployment, the question "does this system send data to the vendor?" has a verifiable answer: inspect the network configuration, monitor for connection attempts, verify the absence of network interfaces. The architectural claim (no network path exists) is testable. A policy claim ("we don't use your data for training") requires trusting the vendor's implementation, which isn't directly testable by the customer.
Dependency inventories reveal hidden paths. Even systems designed for offline operation may contain dependencies that assume network access — license checks, DNS resolution, telemetry defaults. A thorough dependency audit can reveal data-movement paths that policy documentation doesn't mention because the vendor doesn't consider them "data collection."
What organizations should evaluate
When assessing AI systems for environments where data-movement control matters:
Map every outbound path. Run the system on a network-isolated host and monitor for connection attempts during initialization, inference, and shutdown. Catalog every DNS query, every TCP connection attempt, every UDP packet. This is empirical evidence of data-movement behavior — worth more than any policy document.
Distinguish policy from architecture. A vendor that says "we don't collect your data" has made a policy commitment. A system with no network interface has an architectural property. Both have value, but they aren't interchangeable, and an auditor will weight them differently.
Evaluate what the vendor can change remotely. If the system receives updates over the network, the vendor can change its behavior — including its data-collection behavior — without the operator's knowledge or consent. Your ability to control data movement is limited by your ability to control what software runs on your systems.
Treat telemetry configuration as a security boundary. Default telemetry settings are chosen by the vendor, not the operator. In governed environments, telemetry configuration should be reviewed, overridden where necessary, and documented as part of the deployment specification.
The structural argument
Any team that needs long-term control over data movement can't rely solely on vendor commitments. Vendors change ownership, change leadership, face procurement pressure, respond to market incentives. The Anthropic-DoD episode is one instance of a pattern that will recur.
The structural answer is to deploy systems where data-movement properties are architectural — present in the design of the system and the absence of network paths — rather than policy-based. That doesn't require distrusting any specific vendor. It's a recognition that architectural properties are easier to verify, harder to change, and more defensible under audit than policy language that can be revised in a news cycle.