Procurement episodes at the frontier show that acceptable-use policies are flexible instruments: revisable, overridable, reinterpreted as commercial and government requirements move.
For defense, intelligence, critical infrastructure, and export-controlled programs, a vendor’s published stance on data movement is informative and not sufficient. The more durable question is architectural: which data paths exist in the system, and which are structurally absent?
Data movement in AI systems
Cloud-connected AI systems typically expose several paths:
Inference telemetry. Prompts, completions, token counts, latency, error logs — content varies by vendor and config, and vendors can change collection via service update.
Model update channels. Inbound weight and config updates; outbound system state or versioning information is common.
Usage metering. License verification, billing, consumption reporting that needs periodic external contact.
Diagnostic and support channels. Crash reports, performance profiles, debugging data — automatic or during support.
Each path is a data-movement decision the operator may not fully see and may not fully disable.
Architecture vs policy
Absent paths beat restricted paths. A system with no network interface cannot transmit, regardless of software intent. A system that has an interface but is configured not to use it depends on configuration remaining correct — and configs get mis-set, overridden, and updated.
Verifiable boundaries replace trust claims. On an air-gapped deployment, “does this system send data to the vendor?” is testable: network configuration, connection monitoring, absence of interfaces. “We do not use your data for training” is a policy claim that requires trusting implementation the customer cannot inspect end-to-end.
Dependency inventories find hidden paths. Even “offline-ready” stacks can contain dependencies that assume network access — license checks, DNS, telemetry defaults. A dependency audit can surface movement the policy document never called “data collection.”
Measurement
Map every outbound path empirically. Run on a network-isolated host. Log DNS, TCP, UDP during init, inference, and shutdown. That measurement beats any brochure.
Separate policy from architecture. Both have value. They are not interchangeable. Auditors weight them differently.
Ask what the vendor can change remotely. Network updates mean the vendor can change behavior — including collection behavior — without the operator’s consent. Control over data movement is bounded by control over what software runs.
Treat telemetry configuration as a security boundary. Defaults are the vendor’s choice. In governed environments, telemetry is reviewed, overridden where required, and recorded in the deployment specification.
Structural durability
Long-term control over data movement cannot rest only on vendor commitments. Ownership changes, leadership changes, procurement pressure, market incentives. The Anthropic–DoD episode is one instance of a recurring pattern.
Deploy systems where data-movement properties are architectural — designed in, and enforced by the absence of network paths — rather than only policy-based. That is not a claim that any specific vendor is untrustworthy. It is a claim that architectural properties are easier to verify, harder to change under pressure, and more defensible under audit than language that can be revised in a news cycle.