Enterprise AI Architecture · Part III · Data

Chapter 8 — Data Protection

By Anjaneyullu Tamma

A support engineer needs three sentences of context, so she pastes the customer record into a chat window.

No source code left the building this time. No secret was typed.

But the record had a name, a diagnosis, and an account number.

The chat window belonged to someone else's server, in a jurisdiction no one had checked.

The data wasn't stolen. It was sent — by policy, one field at a time, to a place it was never allowed to go.

Nothing was hacked.

The architecture just never asked the data where it was permitted to be.

Purpose

Define the five control families that keep sensitive data safe as it moves through an AI pipeline — ingestion, embedding, retrieval, prompt assembly, the third-party model-API boundary, and back — and show precisely where each one sits relative to the trust boundary established in Chapter 5. The chapter's discipline is simple to state and hard to build: treat the call to any model provider as a border crossing, not an internal function call, and architect every control family around that fact. Policy says what data may go where; this chapter makes that physically so.

Executive Summary

In an AI system, the highest-risk moment isn't a database breach — it's the ordinary, successful API call to a model provider that was never supposed to see that data in the first place.

• The model-API call is a border crossing. Every prompt sent to a third-party provider is data leaving your perimeter; the whole chapter is about deciding, deliberately, what is allowed to cross.
• Embeddings are not anonymous. Vector representations can be partially reconstructed back into source text — encrypting the database around them is necessary but not sufficient.
• Vector databases are the least mature access-control surface in the AI stack today. Several ship with authentication off by default, and misconfiguration, not sophisticated attack, is the dominant failure mode.
• Masking and utility are in tension, not alignment. Redact too aggressively and the model stops working; redact too little and PII survives in the context window. There is no default-safe setting.
• Residency law is arriving mid-build. The EU AI Act's data-governance article and China's new cross-border certification regime are both taking effect within months of each other — architectures decided now should assume the rules tighten, not loosen.

Running Examples

Two programs at Northwind Holdings — the fictional insurance and financial-services group introduced in Chapter 5 — thread through this chapter, because data protection is easiest to reason about against a concrete shape of workload rather than an abstract one.

Prior Authorization — cleared in minutes, not days. Northwind Holdings' clinical prior-authorization workflow, introduced in Chapter 6, runs on a PHI-scoped, private-cloud deployment with a signed Business Associate Agreement (BAA), an immutable, timestamped audit trail, and grounding restricted to approved clinical guidelines and plan policy. It is the spine for this chapter's treatment of encryption-in-use (confidential computing for a regulated inference workload), data residency (why private-cloud, not a public multi-tenant endpoint), and audit-log retention under HIPAA.

Sanctions and Adverse-Media Screening. Northwind Holdings' financial-crime team runs a screening workflow over cross-border entity data — names, geographies, relationships — pulled from external adverse-media sources, with provenance and citations on every match and an immutable audit trail for examiners, the kind of counterparty and claimant screening a large commercial insurer runs routinely on large or cross-border risks. It is the spine for tokenization and masking of PII during triage, secure-pipeline lineage (where did this evidence come from, and who touched it), and cross-border transfer mechanics whenever screening data or vendors sit outside the analyst's jurisdiction.

Read Prior Authorization wherever this chapter discusses encryption-in-use, residency, and HIPAA-grade audit retention. Read Sanctions Screening wherever it discusses tokenization or masking of entity data and secure-pipeline lineage across jurisdictions.

What Data Protection Covers Here — and Isn't

This chapter is not general data-protection 101. Encryption and access control are assumed baseline competence, not news. It is specifically about the new trust boundaries an AI pipeline introduces: the embedding as a semi-reversible representation of source text, the vector store as a comparatively immature access-control surface, the third-party model API as a border crossing, and the training or fine-tuning corpus as a place data can be permanently memorized.

Key Principles

The model-API call is the trust boundary, not the database. Every control in this chapter exists to decide what is allowed to cross it. This is the same discipline Chapter 5 built around the gateway pattern, applied one layer down: a database breach is a known, bounded incident with an established playbook; a routine, successful prompt to a third-party model that was never supposed to see that field is a quieter and more common failure, and it produces no alert at all unless something is built to look for it.

Reversible and irreversible controls solve different problems. Tokenization — reversible, vaulted — serves processes that need the real value back under audit. Masking — typically irreversible — serves training corpora and public logs that never should get it back. Treating the two as interchangeable defaults is how a reversible surrogate ends up in a permanent training set, or an irreversible mask ends up blocking a legitimate downstream lookup.

Encryption at rest is necessary and now insufficient. Embeddings, model weights, and prompt or trace logs are new artifacts that classical encryption programs often miss entirely, because the program was written before those artifacts existed. An encryption inventory that lists databases and object storage but not the vector index or the trace store is not out of date by accident — it was simply never asked the question.

Residency is enforced at the routing layer, not the legal department. A jurisdiction rule that isn't a machine-checked gate on the inference call is a policy, not a control — the same discipline Chapter 7 applies to any other data-usage rule. A memo that says "EU customer data stays in the EU" protects no one if the inference router has no way to know, at request time, where the customer or the endpoint actually is.

Encryption — At Rest, In Transit, In Use

The three familiar states extend into the pipeline with two AI-specific additions: embeddings and vector indexes need the same encryption-at-rest discipline as the source documents they were built from, and encryption-in-use has become achievable through confidential computing — hardware-enforced GPU trusted-execution environments that keep model weights and data encrypted even in VRAM, with cryptographic attestation that the enclave is running the code it claims to be running. For the Prior Authorization workflow, this is the difference between "we trust the cloud provider's operational controls" and "we can prove, cryptographically, that no one — including the cloud provider's own operators — read the clinical record during inference."

Embeddings Are Not Anonymous

A vector embedding looks like a harmless list of floating-point numbers, and that appearance has led more than one architecture review to treat "we only stored the embedding, not the text" as a compliance answer. It isn't. A growing line of embedding-inversion research shows partial-to-substantial reconstruction of source text from vector representations alone, including recent few-shot inversion attacks demonstrated against commercial embedding APIs, with no defense yet established as reliably effective across the board. For the Sanctions Screening workflow's entity-relationship vectors — names, geographies, and the relationships between them — the practical implication is direct: those vectors carry meaningfully reconstructible information about real people and entities, not an anonymized fingerprint of them.

Tokenization, Format-Preserving Encryption, and Masking

Four mechanisms cover most of what an AI pipeline needs, and each answers a different question about whether — and how — a value needs to come back.

Tokenization replaces a value with a surrogate that looks arbitrary and is reversible only through a lookup in a governed vault. It is the right choice when a downstream process needs the real value back under audit — an analyst confirming a flagged entity, a claims system reconciling a payout.

Format-preserving encryption (FPE) — standardized by NIST as FF1 and FF3-1 in SP 800-38G — produces a value of the same format and length, reversible with a key rather than a vault lookup. It is useful precisely where a downstream system's schema validation would reject a token but can accept a same-shape encrypted value. One caution belongs here in bold: FF3 itself was broken and formally deprecated after its initial standardization — a pointed argument against rolling a custom scheme in-house, and a reminder to track NIST guidance rather than freeze it at first implementation.

Static masking permanently transforms a corpus — the right and irreversible-by-design choice for fine-tuning and evaluation data, because training data can be memorized, and a model that memorizes a masked value has memorized nothing sensitive.

Dynamic masking applies at query time, in front of a retriever or tool call, varying by the requester's authorization. It is the mechanism that lets the same underlying record show a full field to an authorized case reviewer and a masked one to a general support agent.

Artifact — redaction-pipeline configuration. A layered entity-recognition pipeline, applied at both the live-prompt injection point and the retrieved-chunk injection point, with a distinct anonymization action per entity type:

# redaction-pipeline.yaml
pipeline:
  analyzer:
    engine: ner-layered          # statistical NER + regex/checksum recognizers
    entities:
      - PERSON
      - US_SSN
      - CREDIT_CARD
      - MEDICAL_LICENSE
      - DIAGNOSIS_CODE
      - ACCOUNT_NUMBER
      - GEO_LOCATION
    language: en
    confidence_threshold: 0.72

  anonymizers:
    PERSON:            { action: replace,   surrogate: "[PERSON]" }
    US_SSN:             { action: mask,      chars_to_mask: 9, from_end: false }
    CREDIT_CARD:         { action: tokenize,  vault: kms/vault/pci }
    MEDICAL_LICENSE:     { action: tokenize,  vault: kms/vault/phi }
    DIAGNOSIS_CODE:      { action: fpe,       key_ref: kms/fpe/clinical }
    ACCOUNT_NUMBER:      { action: tokenize,  vault: kms/vault/financial }
    GEO_LOCATION:        { action: generalize, level: region }

  injection_points:
    - stage: live_prompt
      apply: true
    - stage: retrieved_chunks     # the point most pipelines omit
      apply: true
      note: "retrieved context is scanned identically to the live prompt"

  fail_mode: closed               # unscanned content is blocked, not passed through

The Masking-Utility Tradeoff

Over-redaction breaks coreference, degrades summarization quality, and undermines RAG grounding — a clinical note with every name and date blacked out stops being clinically useful long before it stops containing PHI. Under-redaction leaves real PII sitting in the context window, retrievable by anyone with query access. Current research is moving toward utility-preserving surrogate substitution — replacing a name with a plausible fictional one rather than a black box — rather than blanket blackout, but this is an active, unsettled research area, not a solved default an architecture can simply adopt.

Secure Pipelines

Data lineage — tracking a piece of data from source document through chunking, embedding, indexing, retrieval, and prompt assembly — turns a breach at any one stage into a traceable blast radius instead of an open question. Without it, "what did the compromised index actually expose" has no answer faster than re-deriving the whole pipeline by hand.

Vector-database access control is today's documented weak point. Namespace, partition, and metadata-filter isolation exist in most major vector databases, but they are not enabled automatically — they must be explicitly configured, and misconfiguration, not sophisticated attack, is the dominant real-world failure mode. Confirmed cases include anonymous read and write access to production vector stores; write access is the more dangerous of the two, because it enables retrieval poisoning — quietly inserting content a RAG pipeline will later retrieve and trust — rather than simple data exposure.

The embedding model itself carries supply-chain risk that is easy to underweight: an embedding model pulled from a public hub is an executable artifact — subject to deserialization risk in common model-file formats — not just a mathematical function, and it warrants the same provenance and signing scrutiny an enterprise already applies to an LLM's own weights.

For Sanctions Screening, this is the difference between an examiner accepting a match's evidentiary chain and an examiner rejecting it — every piece of adverse-media evidence needs a traceable path from external source to the analyst's screen.

Data Residency

Sovereignty and cross-border transfer rules for AI inference and training are evolving on two fronts at once. The EU AI Act's data-governance article (Article 10) imposes obligations on training, validation, and testing data for high-risk systems, with a narrow, safeguard-bound exception permitting the processing of special-category data solely to detect and correct bias — and it intersects with GDPR's existing cross-border transfer regime (Chapter V: adequacy decisions, standard contractual clauses) in ways still being actively mapped as both regimes evolve together. Separately, China's cross-border personal-information transfer framework offers a security-assessment pathway, a standard-contract pathway, and a newer certification pathway with its own impact-assessment requirement and multi-year validity period — and it governs transfers of personal information out of China, including AI training and inference data specifically, not just conventional data exports.

Prior Authorization's private-cloud, PHI-scoped deployment is the in-region, self-hosted pattern in practice: rather than resolve a transfer-mechanism question for every clinical record, the architecture avoids the question by keeping processing in-region in the first place.

Data Protection in Practice

The classification-to-handling matrix is the artifact that operationalizes everything above: rows are classification tiers, columns are pipeline stages, and every cell states the required control — or states plainly that the combination is blocked.

Artifact — data-classification-to-handling matrix.

Artifact — OPA/Rego residency-enforcement snippet. Denies an inference request when the data subject's region and the target endpoint's region don't satisfy an approved transfer mechanism:

package residency.authz

default allow := false

# Approved transfer mechanisms, keyed by (subject_region, endpoint_region)
approved_mechanism[{"subject": s, "endpoint": e}] if {
    mechanism := data.transfer_mechanisms[s][e]
    mechanism.status == "approved"
}

allow if {
    input.subject_region == input.endpoint_region
}

allow if {
    input.subject_region != input.endpoint_region
    approved_mechanism[{"subject": input.subject_region, "endpoint": input.endpoint_region}]
}

deny_reason := reason if {
    not allow
    reason := sprintf(
        "no approved transfer mechanism from %v to %v",
        [input.subject_region, input.endpoint_region]
    )
}

Artifact — key-management architecture note. One enterprise KMS root anchors the entire chapter's encryption controls, but it issues a distinct data-encryption key per pipeline stage — ingestion, embedding index, prompt/trace log, and detokenization vault each hold their own key, rotated on an independent cadence. The design goal is blast-radius containment: a compromised key at one stage unlocks that stage alone, never the whole pipeline. This is the same principle Figure 8.2's ring diagram makes visual, applied down to the operational detail of who rotates what and how often.

Figure 8.1, revisited: every stage in that pipeline diagram is one of the controls above, placed at the exact point it protects — ingestion is the redaction pipeline and tokenization gate, the encrypted index is the vector-database access control, the model-API boundary is the residency check and the border crossing itself.

Design Tradeoffs

There are no free data-protection controls; every one buys safety with reversibility, latency, cost, or access to capability. The point of an architecture is to make those trades on purpose.

Best Practices

• Treat every call to a third-party model provider as data leaving your perimeter, and gate it accordingly.
• Encrypt embeddings and vector indexes with the same rigor as the source documents they were built from.
• Reserve confidential computing for the workloads where the regulatory or trust benefit justifies its latency and attestation cost.
• Apply redaction gates at both the live-prompt and retrieved-chunk injection points, never one alone.
• Explicitly configure vector-database authentication, tenant isolation, and write permissions — do not assume a managed service enables them by default.
• Scrutinize third-party embedding models for supply-chain provenance exactly as you would an LLM's own weights.
• Enforce data residency as a machine-checked gate at the inference-routing layer, not as a legal-review artifact.
• Scope keys per pipeline stage so a single compromised key cannot unlock the whole pipeline.
• Name an owner for the masking-aggressiveness decision on every use case — there is no safe universal default.
• Maintain lineage from source document through prompt assembly so any incident has a traceable blast radius.

Anti-Patterns

• Shipping a vector database on default settings. Authentication, tenant isolation, and write access left exactly as the managed service ships them, because no one owned the configuration step.
• Redacting the prompt but not retrieved chunks. A masking gate in front of the user's typed text while the richer, retrieved RAG payload sails through untouched.
• Encryption-at-rest as the whole answer. A program that encrypts the database and stops there, missing embeddings, model weights, and trace logs entirely.
• Residency as a legal memo. A jurisdiction rule with no enforcement at the routing layer — a policy no request ever actually checks against.
• One redaction setting for every use case. Applying the same aggressiveness dial to a clinical narrative and a routine internal summary, when the two have opposite failure costs.
• Trusting a public embedding model's provenance by default. Pulling a model off a public hub without the signing and scanning scrutiny given to an LLM's own weights.
• Centralizing every key with no per-stage scoping. One compromised key unlocking ingestion, indexing, and the detokenization vault all at once.

Maturity Model

Implementation Checklist

• Every call to a third-party model provider is treated as data leaving the perimeter, with a gate that decides what may cross.
• Embeddings and vector indexes are encrypted with the same rigor as source documents.
• Confidential computing is applied where the regulatory or trust benefit justifies it — not as a blanket default.
• Redaction runs at both the live-prompt and retrieved-chunk injection points.
• Vector-database authentication, tenant isolation, and write permissions are explicitly configured, never assumed.
• Third-party embedding models pass the same provenance and signing scrutiny as an LLM's own weights.
• Data residency is enforced as a machine-checked gate at the inference-routing layer.
• Encryption keys are scoped per pipeline stage, with independent rotation cadences.
• A named owner sets the masking-aggressiveness dial per use case.
• Lineage is tracked from source document through prompt assembly, with a traceable blast radius for any incident.
• Cross-border transfers are documented under a named legal mechanism, not assumed permissible.

Standards and Further Reading

Map this chapter's controls to the obligations an auditor will actually ask about: the EU AI Act's data-governance article (Article 10) for high-risk systems, read alongside GDPR's cross-border transfer chapter (Chapter V); China's PIPL and its 2025–2026 cross-border certification measures; NIST SP 800-38G for format-preserving encryption (FF1/FF3-1, including the FF3 deprecation); the NIST AI RMF Generative AI Profile; ISO/IEC 42001 for data-governance and lifecycle controls; the HIPAA Security Rule and Minimum Necessary Standard; and PCI-DSS tokenization guidance as the pre-AI baseline this chapter extends. (EU AI Act and China certification-regime effective dates are current as of mid-2026 and should be re-verified at press time; a related wave of Chinese technical standards is expected to phase in through 2026.)

Chapter Summary

• The AI-specific trust boundary is the call to a third-party model provider — every control in this chapter decides what is allowed to cross it.
• Encryption at rest and in transit is baseline; encrypting embeddings and using confidential computing for encryption-in-use address artifacts classical programs miss.
• Tokenization, format-preserving encryption, and masking solve different problems — reversibility and permanence, not interchangeable defaults — and redaction has a real utility cost with no safe default setting.
• Vector databases are today's least mature access-control surface; misconfiguration, not sophisticated attack, is the dominant real-world failure, so secure-pipeline lineage and explicit access controls are not optional hardening.
• Data residency law (EU AI Act, GDPR, China's cross-border regime) is tightening in real time — architect for enforcement as code at the routing layer, and expect the rules to move.

Looking Ahead

Data protection makes a single request safe to send. It says nothing about whether the data inside that request was any good to begin with. The next chapter in Part III turns to that quieter risk: validating inputs, scoring confidence, and telling a hallucination apart from data that was simply wrong from the start.

AI Policies (Ch 7) → Data Protection (Ch 8) → Chapter 9: the mechanism that keeps data safe, and the discipline that keeps it trustworthy.