Reducing Exposure

Lesson 3 of 3 in Data Leakage and Memorization.

Both leakage directions yield to the same discipline: control what enters the pipe, then control the pipe. The cheapest wins come first. Most prompts carry more than the task needs — full customer records where three fields would do, whole documents where a paragraph suffices, conversation history nobody trimmed. Minimizing sensitive context is a pure win: less exposure, fewer tokens, often better outputs.

The next layer is transformation. Redact or pseudonymize before the model sees the data: detect identifiers (names, account numbers, addresses), replace them with stable placeholders like {{CUSTOMER_1}}, send the transformed prompt, and re-substitute the real values in the response after it returns — the model completes the task without ever holding the identity. Be honest about the limits: PII detection on free text is imperfect (recall is never 100%, and context can re-identify a “redacted” record), so treat redaction as strong attenuation, not erasure.

Shape selection is the structural decision the rest hangs off. Managed platforms document the two mechanisms that matter — private connectivity and data-handling commitments — and for many workloads those, plus redaction, are enough. At the far end sits self-hosting: open weights on your own GPUs, prompts that never leave your VPC, and every operational burden that entails (the foundations capstone walks that trade-off). The tree below is a starting posture, not a compliance determination.

Data sensitivity → consumption shape

Interactive decision tree — outcomes:

  • Managed API, standard business terms

    Lowest-friction shape. Still do log hygiene on your side — non-sensitive workloads have a way of accreting sensitive inputs as products grow.

  • Managed platform on verified business terms

    Proceed with the tier whose commitments you verified, plus minimization and your own logging review. Re-check the terms on a schedule — they change.

  • Managed platform + private endpoint + redaction pipeline

    Layered posture for sensitive data on managed infrastructure: pseudonymize before sending, no-training tier, private connectivity, and audited logs. Redaction is attenuation, not erasure — keep the residual risk in the register.

  • Self-host open weights

    Maximal control: prompts never leave your boundary, and every mechanism is yours to configure — along with every operational obligation. Your own logs are now the primary leak surface.

  • Don’t send that data yet

    No shape currently fits: raw sensitive data, unverified terms, no capacity to self-host. Shrink the workload’s data needs, negotiate terms, or build the redaction pipeline first.

One honest paragraph about deletion, because every data-protection conversation eventually arrives here. Once data has been trained into weights, there is no reliable way to delete it. Weights are not a database: an example’s influence is distributed across parameters, entangled with everything learned alongside it. Machine unlearning — surgically removing one example’s influence — is an active research area without production-grade guarantees for LLMs today; output filters can suppress known strings but do not remove them; the only certain removal is retraining without the data, which at LLM scale is usually economically absurd. The asymmetry is the lesson: data is trivial to ingest and near-impossible to un-ingest, so every control in this module that operates before training or before transmission is worth ten that operate after. This is also why Fine-tuning on customer data deserves the same scrutiny as pre-training: a Base model you rent plus your fine-tuning data equals a new artifact that has memorization risk on your data.

In production

All three clouds document the two mechanism families this lesson leans on: private connectivity, so prompt traffic never crosses the public internet, and configurable safeguards that can catch sensitive data at the boundary. The commitments differ in detail and change over time — treat the docs, not this paragraph, as the source of truth.

AWS

Amazon Bedrock documents interface VPC endpoints via AWS PrivateLink so traffic between your VPC and the service avoids the public internet, with VPC Flow Logs for monitoring — and extends VPC protection to model customization and batch inference jobs. On the data-in-prompts side, Bedrock Guardrails includes documented sensitive-information filters that block or mask PII (plus custom regex patterns) in inputs and outputs — a managed building block for the redaction layer.

Azure

Azure AI Foundry resources support disabling public network access entirely, with an Azure Private Link private endpoint into your VNet; DNS remaps to a privatelink subdomain so in-VNet clients resolve the private IP while the connection string stays unchanged. The content filtering system documents optional PII detection among its filters, and network isolation for dependent resources (Search, Storage) is configured separately — the boundary is only as private as its least private dependency.

Google Cloud

Vertex AI documents Private Service Connect endpoints: an internal IP in your VPC fronts the service, reachable from VPC, on-premises (over HA VPN or Interconnect), or multicloud without public IPs — with dedicated PSC-based private endpoints for self-deployed models. Its documented safety filters include a non-configurable filter for sensitive personally identifiable information (SPII) in responses, alongside the configurable harm-category filters.

Interactive checkpoint quiz (1 questions) — open this page in a browser to take it.