GDPR data governance framework for enterprise LLM deployment — Reference Architecture

Reference architecture · published 2026-10-16 · regulated enterprise · GDPR · layout spec_first · implementation executed in CI before publish

Deployment parameters

Every value below is a parameter you can hold a vendor or an internal team to. Adjectives are not acceptance criteria.

The control that resolves this is a Classification-Routed Multi-Cloud Estate, evaluated before the request reaches a model provider rather than audited afterwards. In regulated enterprise the binding constraint is GDPR, and the question it actually asks is what is the lawful basis, and can you actually erase. The shape below holds p95 ≤ 600ms over gRPC with mTLS, and ships with a standard-library implementation that runs as written.

The control gap

Workloads span several providers and regions, and the decision of which model may see which data lives in prompt text, a wiki page, or a developer's judgement. That is not a control, so the governance board cannot approve the estate even though every individual component is defensible.

What GDPR specifically requires

GDPR asks two things an audit log does not answer: under what lawful basis was this processed, and can you erase it on request. Erasure is the harder one — a prompt embedded into a vector index and a fine-tune has propagated beyond the row you deleted.

The artifact that satisfies it is a lineage graph from source record to every derived artifact. The way teams most often fail it: an erasure request that cannot be honoured because the data survives in embeddings, caches and eval sets.

The implementation — Classification-driven routing gate with recorded reasons

Standard-library Python, no external dependencies, runs as written. Executed by the publish gate: if it raises, this page does not ship. Wire it behind gRPC with mTLS; the failure mode it guards against is a half-open HTTP/2 stream silently dropping the deadline. The output you hand the assessor is the data-subject lineage and erasure report.

"""Classification-driven routing gate for a multi-cloud LLM estate.

Why this shape: "which model may see this data" is a governance decision, and
if it lives in prompt text or a developer's judgement it is not a control. It
has to be a deterministic function of the data's classification and the
destination's attested properties, evaluated before egress.

The gate below is the smallest thing that an actual data-governance board will
accept: classification in, allowed destinations out, with a recorded reason for
every allow and every deny.
"""
import re
from dataclasses import dataclass
from enum import IntEnum


class Class(IntEnum):
    PUBLIC = 0
    INTERNAL = 1
    CONFIDENTIAL = 2
    RESTRICTED = 3      # PII / PHI / material non-public


DETECTORS = {
    "email": re.compile(r"[\w.+-]+@[\w-]+\.[\w.]{2,}"),
    "iban": re.compile(r"\b[A-Z]{2}\d{2}[A-Z0-9]{10,30}\b"),
    "card": re.compile(r"\b(?:\d[ -]?){13,19}\b"),
    "ssn": re.compile(r"\b\d{3}-\d{2}-\d{4}\b"),
    "mrn": re.compile(r"\bMRN[:\s-]*\d{6,10}\b", re.I),
}


def luhn(number: str) -> bool:
    """Card detectors without Luhn produce false positives on order numbers,
    and a gate that cries wolf gets switched off."""
    digits = [int(c) for c in re.sub(r"\D", "", number)]
    if len(digits) < 13:
        return False
    checksum, parity = 0, len(digits) % 2
    for i, d in enumerate(digits):
        if i % 2 == parity:
            d *= 2
            if d > 9:
                d -= 9
        checksum += d
    return checksum % 10 == 0


def classify(text: str, floor: Class = Class.INTERNAL) -> tuple:
    """-> (classification, evidence). Deterministic and explainable."""
    found = []
    for name, rx in DETECTORS.items():
        for m in rx.finditer(text or ""):
            if name == "card" and not luhn(m.group(0)):
                continue
            found.append(name)
            break
    return (Class.RESTRICTED if found else floor), sorted(set(found))


@dataclass(frozen=True)
class Destination:
    name: str
    region: str
    max_class: Class
    zero_retention: bool
    dpa_signed: bool
    subprocessors_disclosed: bool


class Denied(Exception):
    pass


def route(text: str, destinations: list, required_region: str = None) -> dict:
    """Pick the first destination whose ATTESTED properties cover the data.

    Order matters: destinations are supplied in preference order (cheapest or
    fastest first) and the gate takes the first one that is lawful, so cost
    optimisation can never override a control.
    """
    level, evidence = classify(text)
    reasons = []
    for d in destinations:
        if d.max_class < level:
            reasons.append(f"{d.name}: max_class {d.max_class.name} < {level.name}")
            continue
        if required_region and d.region != required_region:
            reasons.append(f"{d.name}: region {d.region} != {required_region}")
            continue
        if level >= Class.RESTRICTED and not d.zero_retention:
            reasons.append(f"{d.name}: retains prompts, unusable for {level.name}")
            continue
        if level >= Class.CONFIDENTIAL and not d.dpa_signed:
            reasons.append(f"{d.name}: no DPA on file")
            continue
        if level >= Class.RESTRICTED and not d.subprocessors_disclosed:
            reasons.append(f"{d.name}: subprocessors undisclosed")
            continue
        return {"allowed": True, "destination": d.name,
                "classification": level.name, "evidence": evidence,
                "rejected": reasons}
    raise Denied(f"no lawful destination for {level.name} data: {reasons}")


if __name__ == "__main__":
    dests = [
        Destination("shared-us", "us-east-1", Class.INTERNAL, False, True, False),
        Destination("eu-pooled", "eu-west-1", Class.CONFIDENTIAL, False, True, True),
        Destination("eu-dedicated", "eu-west-1", Class.RESTRICTED, True, True, True),
    ]
    print(route("Summarise this quarter's churn drivers.", dests))
    print(route("Patient MRN 4471902 reports side effects.", dests,
                required_region="eu-west-1"))
    try:
        route("Card 4111111111111111 was declined.",
              [d for d in dests if not d.zero_retention])
    except Denied as e:
        print("correctly denied:", str(e)[:96])

The GDPR control, as code

Article 17 erasure propagated into derived artifacts. This is the artifact an assessor asks for under GDPR specifically — it is not the same control as the one above, and a system that implements one does not thereby implement the other. It executes under the same publish gate.

"""Article 17 erasure that propagates into derived artifacts.

The erasure request everyone implements is a DELETE on the source row. The one
that fails an audit is the derived copy: embeddings in a vector index, a cached
retrieval chunk, a fine-tuning corpus, a prompt log. Article 17(2) expects
controllers to take reasonable steps to inform processors of the erasure, and a
vector built from personal data is still personal data.

So erasure is modelled as a lineage walk with a receipt per derived artifact,
and the request is not complete until every downstream store confirms.
"""
from datetime import datetime, timezone


class Store:
    def __init__(self, name: str, kind: str):
        self.name, self.kind = name, kind
        self.rows: dict[str, dict] = {}
        self.erased: list[str] = []

    def put(self, key: str, subject_id: str, payload: str) -> None:
        self.rows[key] = {"subject_id": subject_id, "payload": payload}

    def erase_subject(self, subject_id: str) -> int:
        doomed = [k for k, v in self.rows.items() if v["subject_id"] == subject_id]
        for k in doomed:
            del self.rows[k]
            self.erased.append(k)
        return len(doomed)

    def holds(self, subject_id: str) -> int:
        return sum(1 for v in self.rows.values() if v["subject_id"] == subject_id)


class ErasureOrchestrator:
    """Lineage-aware erasure. A store that is not registered cannot be erased,
    so registration is the control — an unregistered derived store is exactly
    how personal data survives a 'completed' erasure."""

    def __init__(self):
        self.stores: list[Store] = []
        self.lineage: dict[str, list[str]] = {}

    def register(self, store: Store, derived_from: str | None = None) -> Store:
        self.stores.append(store)
        if derived_from:
            self.lineage.setdefault(derived_from, []).append(store.name)
        return store

    def execute(self, subject_id: str) -> dict:
        receipts = []
        for store in self.stores:
            held = store.holds(subject_id)
            removed = store.erase_subject(subject_id)
            receipts.append({"store": store.name, "kind": store.kind,
                             "held": held, "erased": removed})
        residual = {s.name: s.holds(subject_id) for s in self.stores
                    if s.holds(subject_id)}
        return {
            "subject_id": subject_id,
            "completed_at": datetime.now(timezone.utc).isoformat(timespec="seconds"),
            "receipts": receipts,
            "residual": residual,
            "complete": not residual,
            "derived_stores_covered": sorted(
                s.name for s in self.stores if s.kind != "source"),
        }


if __name__ == "__main__":
    orch = ErasureOrchestrator()
    src = orch.register(Store("crm_postgres", "source"))
    vec = orch.register(Store("vector_index", "embedding"), derived_from="crm_postgres")
    cache = orch.register(Store("retrieval_cache", "cache"), derived_from="vector_index")
    logs = orch.register(Store("prompt_log", "log"), derived_from="crm_postgres")

    src.put("c-1", "subject-77", "Jana Soor, contract renewal notes")
    vec.put("v-1", "subject-77", "[0.11, -0.4, ...]")
    cache.put("k-1", "subject-77", "chunk: contract renewal notes")
    logs.put("l-1", "subject-77", "prompt containing the same notes")
    src.put("c-2", "subject-90", "unrelated subject")

    result = orch.execute("subject-77")
    assert result["complete"], result["residual"]
    assert len(result["derived_stores_covered"]) == 3, result
    assert sum(r["erased"] for r in result["receipts"]) == 4, result
    assert src.holds("subject-90") == 1, "erasure must not over-reach"

    # An unregistered derived store is the failure this design exists to expose.
    orphan = Store("analytics_extract", "warehouse")
    orphan.put("a-1", "subject-77", "same personal data, different copy")
    assert orphan.holds("subject-77") == 1
    assert orphan.name not in {s.name for s in orch.stores}

    print("GDPR Article 17 lineage erasure: OK")
    print(f"  stores erased {len(result['receipts'])}, complete={result['complete']}")
    print(f"  UNREGISTERED store still holding data: {orphan.name} "
          f"({orphan.holds('subject-77')} row) — registration is the control")

The request path

Classification-Routed Multi-Cloud Estate — the request path, with the decision points that must exist before the first model call:

flowchart TB
    IN[Request payload] --> CLS[Deterministic classifier<br/>regex + Luhn/checksum]
    CLS --> LV{Classification}
    LV -->|PUBLIC / INTERNAL| D1[shared-us]
    LV -->|CONFIDENTIAL| D2[eu-pooled<br/>DPA required]
    LV -->|RESTRICTED| D3[eu-dedicated<br/>zero-retention + subprocessors]
    LV -->|no lawful destination| DN[Deny + reason]
    D1 --> LOG[(Decision log)]
    D2 --> LOG
    D3 --> LOG
    DN --> LOG
    D3 --> LIN[Lineage tag on<br/>embeddings / cache / evals]
    ATT[Destination attestations] -.-> LV
    ATT --> DR[Drift detector]

The parts you have to build

1. Deterministic classifier — Pattern plus validator (Luhn, checksum) so the gate does not cry wolf.
2. Destination attestations — Region, max class, retention, DPA, subprocessor disclosure — as data.
3. Routing gate — First lawful destination in preference order; cost can never override a control.
4. Decision log — A recorded reason for every allow AND every deny.
5. Lineage tags — Classification travels with derived artifacts: embeddings, caches, evals.
6. Drift detector — Alerts when a destination's attested properties change.

Risk register with acceptance criteria

Each row carries an acceptance parameter rather than an adjective, because "low latency" cannot be signed off. Retention here is bound by per the data class retention schedule, enforced automatically.

Questions to answer before approval

• A data subject requests erasure. Trace exactly what gets deleted, including embeddings and cached completions.
  Every derived artifact carries the source record id, so erasure traverses the lineage graph. The completion report lists each store touched and the rows removed.
• What function decides which destination may see RESTRICTED data, and where does it run?
  The routing gate, evaluated before egress. It is a deterministic function of the data's classification and the destination's attested properties, and it fails closed when no destination is lawful.
• Show me the recorded reason for a denial last week.
  Every allow and every deny is written to the decision log with the reason — which destinations were rejected and on which property — so a denial is explainable months later.
• When a document is embedded, does the embedding carry its classification — and is that enforced on read?
  Yes. The classification tag propagates into every derived store, including embeddings, caches and eval sets, and is enforced on read as well as write.
• What happens when a provider adds a subprocessor you have not disclosed?
  The drift detector alerts when a destination's attested properties change, and routing is re-evaluated against the new attestation. Attestations are versioned data, not a one-off questionnaire.
• How do you prove processing stayed in the contracted region?
  The provider endpoint is pinned per region and the served region is asserted on the response; a mismatch fails the request rather than completing it quietly.

Adjacent problems

• Part of enterprise ai data governance.
• A different failure mode of the same component: fedRAMP Moderate data governance framework for enterprise LLM deployment.
• The same control appears in SOX data governance framework for enterprise LLM deployment.
• The same control appears in PCI DSS 4.0 data governance framework for enterprise LLM deployment.
• ISO/IEC 27001:2022 data governance framework for enterprise LLM deployment applies the same mechanism under a different obligation.
• If this is the blocker in front of you: enterprise AI infrastructure review.