When you type a prompt into ChatGPT and press enter, the text doesn’t travel in a straight line from your browser to a model and back. It traverses a supply chain of intermediaries – each one copying, logging, inspecting, or transforming your data before the next link in the chain even knows you exist. A 2025 analysis by the Cloud Security Alliance identified a minimum of seven distinct processing stages between a user’s keystroke and a generated response, with enterprise deployments frequently adding four or five more.
This is the AI supply chain, and most users have never seen a map of it.
Stage 1: The Client Application Layer
Your data journey begins before you finish typing. Modern AI chat interfaces implement predictive telemetry that captures keystroke timing, paste events, cursor position, and input field interactions. OpenAI’s web client, for instance, sends periodic heartbeat signals to its analytics infrastructure while you compose a prompt. These signals don’t contain your prompt text, but they encode behavioral metadata: how long you spent typing, whether you edited your input, and how many characters you deleted before submitting.
This telemetry feeds product analytics pipelines operated by the AI provider or, in many cases, by third-party analytics services embedded in the application. A 2024 audit by PrivacyTests found that ChatGPT’s web interface loaded scripts from 14 distinct third-party domains, including analytics, error tracking, and A/B testing services. Each of these services received some subset of your interaction metadata.
For enterprise deployments using API integrations, the client layer is controlled by the enterprise’s own software. But this merely shifts the telemetry collection from the AI provider to the enterprise’s application stack, which typically includes its own constellation of analytics, logging, and monitoring services.
The prompt hasn’t left your device yet, and your behavioral data has already been distributed to multiple parties.
Stage 2: The Network Transit Layer
Once submitted, your prompt travels through the public internet. In the simplest case, an HTTPS connection encrypts the payload between your browser and the AI provider’s edge infrastructure. But “the network” is not a single pipe – it is a chain of autonomous systems operated by internet service providers, content delivery networks, and transit providers.
Your ISP can observe the destination domain and the volume of data exchanged, even if it cannot read the encrypted payload. In jurisdictions with mandatory data retention laws – including the EU’s proposed metadata retention frameworks and existing national implementations – this connection metadata may be stored for months or years.
Cloudflare, which provides CDN and DDoS protection for many AI services, processes the TLS termination at its edge nodes. This means Cloudflare’s infrastructure briefly holds the decrypted request before re-encrypting it for transit to the AI provider’s origin servers. Cloudflare processes approximately 20% of all global web traffic, positioning it as a significant intermediary in the AI data supply chain.
For users accessing AI through corporate VPNs or secure access service edge (SASE) platforms like Zscaler or Netskope, the network layer adds another intermediary. These platforms typically perform TLS inspection – decrypting, scanning, and re-encrypting traffic – which means your prompt text is visible to the SASE provider’s infrastructure in cleartext. Zscaler processes over 400 billion transactions daily across its cloud, and its AI-specific inspection features explicitly analyze prompt content for data loss prevention purposes.
Stage 3: The API Gateway and Load Balancer
Your request arrives at the AI provider’s infrastructure, but it doesn’t go directly to a GPU. It first hits an API gateway layer responsible for authentication, rate limiting, request validation, and routing.
This gateway layer is a distinct system from the model inference infrastructure. It maintains its own logs, its own data stores, and its own access patterns. API gateways commonly log the full request payload for debugging, abuse detection, and billing purposes. Even providers that claim not to log prompt content for training purposes may still log it at the gateway layer for operational reasons.
At scale, providers operate multiple API gateway clusters across geographic regions. OpenAI’s infrastructure spans data centers in the U.S. and has processing arrangements with Microsoft Azure’s global network. A request from a user in Frankfurt may be routed to a gateway in Virginia, or it may be processed at a European edge node, depending on load balancing decisions that the user has no visibility into or control over.
The load balancer that sits in front of the gateway makes routing decisions based on request characteristics, server health, and geographic proximity. These routing decisions are typically logged, creating a metadata trail that maps which users were routed to which backend clusters at which times.
Stage 4: The Safety and Moderation Layer
Before your prompt reaches the model, it passes through a content moderation pipeline. OpenAI’s moderation system, for example, is a separate model that classifies inputs for policy compliance. This moderation model processes the full text of your prompt, and its classifications (along with confidence scores) are logged.
The moderation layer serves a legitimate safety function, but it also constitutes a distinct data processing step with its own retention policies, access controls, and potential for data exposure. OpenAI’s moderation API, which is also offered as a standalone product, processes text and returns risk scores across multiple categories. The operational question is how long these moderation logs are retained and who has access to them.
Some enterprise deployments add additional moderation layers. Microsoft’s Azure OpenAI Service includes a content filtering system that operates independently of OpenAI’s own moderation. This means an enterprise user’s prompt may be analyzed by two separate moderation systems, each maintaining its own logs and each operated by a different corporate entity.
For organizations subject to regulatory oversight, the moderation layer creates an additional compliance challenge: moderation logs may contain the very content that the organization needed to keep confidential, now stored in a system operated by the AI provider under the provider’s data governance framework rather than the organization’s own.
Stage 5: The Model Inference Layer
Your sanitized, validated, moderated prompt finally reaches a GPU cluster for inference. This is the step most users imagine as “the entire process” – the model reads your prompt and generates a response. In practice, this step involves its own set of data handling considerations.
During inference, your prompt is loaded into GPU memory alongside model weights. In shared inference environments, multiple users’ requests may be processed on the same GPU cluster simultaneously through techniques like continuous batching. Research published at USENIX Security 2024 demonstrated that side-channel attacks on shared GPU infrastructure could theoretically leak information between concurrent inference requests, though practical exploitation remains difficult.
The inference layer also generates its own telemetry: token counts, latency measurements, error rates, and in some configurations, attention pattern metadata that reveals which parts of your prompt the model focused on during generation. This telemetry feeds into the provider’s performance monitoring systems, which are typically retained for weeks or months.
Providers that offer model customization or fine-tuning features may route inference through specialized pipelines where your data is processed alongside the custom model weights. In these environments, the boundary between “inference” and “training” becomes blurred, and the mechanisms that allow opt-out of training data use may not apply to telemetry generated during inference.
Stage 6: The Logging and Observability Layer
Modern cloud infrastructure generates comprehensive observability data, and AI providers are no exception. Distributed tracing systems like Jaeger or Datadog APM create detailed records of each request’s journey through the provider’s infrastructure, including timing data, error states, and often partial or full payload content.
This observability layer exists primarily for engineering purposes – debugging production issues, identifying performance bottlenecks, and monitoring system health. But it constitutes a parallel data store that may not be covered by the same data governance policies that apply to the primary conversation storage. When OpenAI or Anthropic publish data retention policies, those policies typically address conversation data explicitly but are less specific about operational telemetry and observability logs.
A 2025 report by Datadog found that the average cloud application generates 31 TB of observability data per month. For an AI provider processing hundreds of millions of requests daily, the volume of operational telemetry is staggering. This data is often retained for 30 to 90 days for engineering purposes, creating a window during which prompt content may be accessible through operational systems even if it has been deleted from the primary conversation store.
Stage 7: The Response Delivery Chain
The model’s response traverses the same supply chain in reverse, with each intermediary processing the output text. The safety layer scans the response for policy violations. The API gateway logs the response for billing and abuse monitoring. The network transit layer carries the encrypted response back through ISPs and CDN infrastructure. The client application renders the response and may log it locally.
But the response delivery chain introduces an additional intermediary for streaming responses: the server-sent events (SSE) infrastructure that enables token-by-token delivery. Streaming responses require maintaining an open connection between the server and client, during which partially generated text may be buffered at multiple points in the infrastructure.
For enterprise deployments that integrate AI providers through middleware platforms – Langchain, LlamaIndex, custom orchestration layers – the response may pass through additional processing stages for retrieval-augmented generation (RAG), response formatting, or citation injection. Each of these middleware components maintains its own logging and telemetry.
The Multiplication Problem
The critical insight about the AI supply chain is not that any single intermediary is necessarily malicious or negligent. It is that the multiplication of intermediaries creates a combinatorial explosion of potential data exposure.
If each of seven processing stages has a 99.5% probability of handling your data correctly (an optimistic assumption for complex cloud systems), the probability that your data is handled correctly across all seven stages is 0.995^7 = 96.5%. For enterprise deployments with 11 or more processing stages, that figure drops below 95%. At scale – millions of prompts per day – a 3.5% failure rate translates to hundreds of thousands of daily instances where data handling deviates from the intended policy.
These deviations range from mundane (a log entry retained longer than policy specifies) to severe (prompt content exposed through a misconfigured observability dashboard). The 2023 ChatGPT conversation history leak, which exposed users’ chat titles and partial conversation content to other users due to a Redis cache misconfiguration, illustrated how failures in operational infrastructure – not the model itself – create data exposure.
Third-Party Sub-Processors
The supply chain extends beyond the AI provider’s own infrastructure. Major providers rely on extensive networks of sub-processors – third-party companies that handle some aspect of data processing on the provider’s behalf.
OpenAI’s sub-processor list includes Microsoft (cloud infrastructure), Stripe (payment processing), and multiple analytics providers. Anthropic similarly relies on AWS infrastructure and various operational services. Each sub-processor has its own security posture, its own data retention policies, and its own regulatory obligations.
Under GDPR, the primary data controller (the AI provider) is responsible for the actions of its sub-processors. But this legal framework assumes that the controller has meaningful oversight of sub-processor behavior – an assumption that becomes tenuous in complex cloud supply chains where sub-processors themselves rely on sub-sub-processors.
The practical implication is that your prompt data may be processed by companies you’ve never heard of, under data governance frameworks you’ve never consented to, in jurisdictions you’d never choose. The AI privacy by country analysis becomes relevant here: data processed through U.S. infrastructure is subject to U.S. legal process regardless of where you’re located.
The Enterprise Amplification
For enterprise AI deployments, the supply chain problem is amplified by the organization’s own middleware. A typical enterprise AI integration involves:
- Identity provider (Okta, Azure AD): authenticates the user and may log the request context
- API management platform (Apigee, Kong): routes the request and logs payloads for governance
- Data loss prevention system (Netskope, Microsoft Purview): inspects prompt content for sensitive data
- Orchestration layer (Langchain, custom): preprocesses the prompt and may add context from internal systems
- Vector database (Pinecone, Weaviate): stores and retrieves enterprise knowledge for RAG
- AI provider: the actual model inference (with all seven stages described above)
- Monitoring platform (Datadog, Splunk): captures telemetry across the entire stack
Each of these components is operated by a different vendor, governed by a different contract, and secured by a different team. The aggregate data exposure surface of an enterprise AI deployment dwarfs what individual users face.
A 2025 survey by Gartner found that the average enterprise AI deployment involved 8.3 distinct vendor relationships. The complexity of managing data privacy across this vendor ecosystem has created an entirely new category of enterprise software: AI governance platforms.
Mapping Your Own Supply Chain
Organizations deploying AI tools should map their complete data supply chain using a structured methodology:
Step 1: Enumerate all intermediaries. List every system, service, and vendor that touches prompt data between the user’s device and the model.
Step 2: Classify data exposure at each stage. For each intermediary, determine what data it receives (full payload, metadata only, or derivative data), how long it retains that data, and who has access.
Step 3: Identify jurisdictional boundaries. Map the geographic locations of each intermediary’s data processing infrastructure. Pay particular attention to cross-border data transfers that may be subject to regulatory restrictions.
Step 4: Assess contractual coverage. Verify that each intermediary is covered by a data processing agreement that aligns with your organization’s privacy requirements. Gaps in contractual coverage represent unmanaged risk.
Step 5: Test the chain. Conduct controlled tests with synthetic sensitive data to verify that each intermediary handles data according to its stated policies. Trust but verify.
This supply chain mapping exercise typically reveals intermediaries that the organization was unaware of – shadow dependencies inherited from vendor infrastructure choices rather than deliberate organizational decisions.
Architectural Alternatives
The supply chain problem is not inevitable. It is a consequence of architectural choices that prioritize convenience and cost over privacy.
Zero-knowledge architectures fundamentally restructure the supply chain by ensuring that intermediaries process encrypted data they cannot read. In a zero-knowledge AI system, the prompt is encrypted on the client device before it enters the supply chain. Intermediaries transport and route the encrypted payload without accessing its content. Only the inference layer – running in a trusted execution environment or using privacy-preserving computation techniques – processes the decrypted prompt, and only in ephemeral memory that is destroyed after generating the response.
This approach doesn’t eliminate intermediaries. The network, the gateway, the load balancer, and the observability systems all still exist. But they handle ciphertext rather than plaintext, which reduces the consequence of any single intermediary’s failure or compromise from “full data exposure” to “encrypted data exposure.”
PII stripping offers a complementary approach: removing identifiable information from prompts before they enter the supply chain, then re-injecting it into responses on the client side. This technique reduces the sensitivity of the data flowing through the supply chain without requiring changes to the supply chain’s infrastructure.
The Stealth Cloud Perspective
The AI supply chain problem is fundamentally a trust distribution problem. Every intermediary in the chain requires your trust, and every intermediary represents a potential failure point for that trust. The industry’s current architecture distributes your most sensitive cognitive output across an opaque network of corporate systems, operational telemetry, and third-party sub-processors.
Stealth Cloud’s architecture was designed specifically to collapse the supply chain. By processing prompts at the edge with zero-knowledge encryption and client-side PII stripping, the number of intermediaries that handle readable data drops from seven or more to effectively one: the ephemeral inference process itself. No gateway logs your plaintext prompt. No observability system captures your conversation. No sub-processor you’ve never heard of retains a copy of your strategic thinking.
The question for any organization using AI is straightforward: how many hands do you want touching your data before it reaches a model? The answer should be as close to zero as architecture permits.