GDPR tracing and token accounting architecture for enterprise LLM deployment — Reference Architecture

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

The control that resolves this is a Complete-Trace Reconciliation Ledger, 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 REST over HTTPS, and ships with a standard-library implementation that runs as written.

The blueprint

Complete-Trace Reconciliation Ledger — the request path, with the decision points that must exist before the first model call:

flowchart LR
    REQ[Request] --> OPEN[Open trace<br/>model version pinned]
    OPEN --> CTX[Bind prompt digest + sources]
    CTX --> CALL[Model call] --> OUT[Bind output digest + tokens]
    OUT --> LED[(Ledger)]
    BILL[Provider invoice] --> REC{Reconcile}
    LED --> REC
    REC -->|gap| ALERT[Untraced traffic — find the path]
    REC -->|matches| OK[Completeness holds]

The parts you have to build

1. Per-request trace — Model version, prompt digest, output digest, sources, tokens.
2. Completeness check — A trace missing any required field is reported, not accepted.
3. Source citation list — Which retrieved documents were in context for this answer.
4. Token accounting — Input and output tokens recorded at the call site.
5. Spend reconciliation — Traced tokens against billed tokens; a gap means untraced traffic.
6. Reconstruction API — Given a request id, return everything needed to re-derive the answer.

Technical parameters

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

The architecture friction point

An answer is disputed weeks after it was given and nobody can say which model version, which documents and which prompt produced it. Traces exist, but they are sampled, so the disputed request is the one that was not kept.

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.

Implementation artifact — Trace completeness with spend reconciliation

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 REST over HTTPS; the failure mode it guards against is a retried POST creating a duplicate record. The output you hand the assessor is the data-subject lineage and erasure report.

"""Trace completeness: every response tied to the inputs that produced it.

The failure: an answer is disputed weeks later and nobody can reconstruct which
model version, which retrieved documents and which prompt produced it. Sampling
traces at 1% guarantees the disputed one is missing, so completeness is the
property to enforce — and untraced spend is the signal that it has broken.
"""
import hashlib


class Trace:
    def __init__(self, request_id: str, model_version: str):
        self.request_id = request_id
        self.model_version = model_version
        self.sources: list[str] = []
        self.prompt_digest = None
        self.output_digest = None
        self.tokens = {"in": 0, "out": 0}

    def bind_prompt(self, prompt: str) -> None:
        self.prompt_digest = hashlib.sha256(prompt.encode()).hexdigest()[:16]

    def bind_output(self, output: str) -> None:
        self.output_digest = hashlib.sha256(output.encode()).hexdigest()[:16]

    def cite(self, source_id: str) -> None:
        self.sources.append(source_id)

    def complete(self) -> bool:
        return all([self.prompt_digest, self.output_digest,
                    self.model_version, self.tokens["in"] > 0])

    def missing(self) -> list[str]:
        gaps = []
        if not self.prompt_digest: gaps.append("prompt_digest")
        if not self.output_digest: gaps.append("output_digest")
        if not self.model_version: gaps.append("model_version")
        if self.tokens["in"] <= 0: gaps.append("token_accounting")
        return gaps


class Ledger:
    """Reconciles traced spend against billed spend. A gap means requests are
    escaping the traced path, which is the thing to find — not a rounding
    error to tolerate."""

    def __init__(self, tolerance: float = 0.01):
        self.traces: dict[str, Trace] = {}
        self.tolerance = tolerance

    def open(self, request_id: str, model_version: str) -> Trace:
        t = Trace(request_id, model_version)
        self.traces[request_id] = t
        return t

    def reconstruct(self, request_id: str) -> dict | None:
        t = self.traces.get(request_id)
        if not t:
            return None
        return {"request_id": t.request_id, "model_version": t.model_version,
                "prompt_digest": t.prompt_digest, "output_digest": t.output_digest,
                "sources": list(t.sources), "tokens": dict(t.tokens),
                "complete": t.complete(), "missing": t.missing()}

    def traced_tokens(self) -> int:
        return sum(t.tokens["in"] + t.tokens["out"] for t in self.traces.values())

    def reconcile(self, billed_tokens: int) -> dict:
        traced = self.traced_tokens()
        gap = billed_tokens - traced
        ratio = gap / billed_tokens if billed_tokens else 0.0
        return {"traced": traced, "billed": billed_tokens, "gap": gap,
                "untraced_ratio": round(ratio, 4),
                "within_tolerance": abs(ratio) <= self.tolerance,
                "incomplete_traces": [r for r, t in self.traces.items()
                                      if not t.complete()]}


if __name__ == "__main__":
    led = Ledger()
    t = led.open("req-1", "gpt-x@2026-09")
    t.bind_prompt("What is our refund policy?")
    t.cite("doc://policies/refunds#v7")
    t.tokens = {"in": 820, "out": 240}
    t.bind_output("Refunds are processed within 14 days.")

    rec = led.reconstruct("req-1")
    assert rec["complete"], rec
    assert rec["sources"] == ["doc://policies/refunds#v7"], rec
    assert rec["model_version"] == "gpt-x@2026-09"

    # An incomplete trace must be visible, not silently acceptable.
    t2 = led.open("req-2", "gpt-x@2026-09")
    t2.tokens = {"in": 100, "out": 50}
    assert not t2.complete() and "prompt_digest" in t2.missing(), t2.missing()

    clean = led.reconcile(billed_tokens=1210)
    assert clean["within_tolerance"], clean
    assert clean["incomplete_traces"] == ["req-2"], clean

    # Requests escaping the traced path show up as an untraced gap.
    leaky = led.reconcile(billed_tokens=4000)
    assert not leaky["within_tolerance"], leaky
    assert leaky["untraced_ratio"] > 0.6, leaky

    assert led.reconstruct("req-missing") is None

    print("Trace completeness ledger: OK")
    print(f"  reconstructed req-1 complete={rec['complete']}, "
          f"untraced ratio clean={clean['untraced_ratio']} "
          f"leaky={leaky['untraced_ratio']}")

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")

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.

Review questions and answers

• 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.
• A customer disputes an answer from six weeks ago. What can you reconstruct?
  The model version, prompt digest, output digest, the retrieved sources in context, and token counts — enough to re-derive the answer rather than argue about it.
• How would you know if some requests never reach the traced path?
  Reconciliation. Traced token spend is compared against the provider invoice; a gap beyond tolerance means traffic is escaping the traced path, and that gap is the thing to chase.
• Which model version produced a specific output, and how is that known rather than inferred?
  It is pinned on the trace when the trace opens, before the call. Inferring it afterwards from deployment history is exactly how the wrong version gets attributed.
• Does the trace store the raw prompt, and what does that mean for personal data?
  Digests by default, with raw retained only where there is a lawful basis. The digest is enough to prove which prompt produced which output without storing the text.
• What does tracing add to the latency of the request it traces?
  Nothing on the critical path: trace writes are buffered and asynchronous, and the added p95 is measured against the agreed budget rather than assumed to be negligible.

Related architectures

• Part of enterprise ai compliance architecture.
• A different failure mode of the same component: GDPR retrieval architecture with citation integrity for enterprise LLM.
• A different failure mode of the same component: GDPR agent permission and delegated access architecture for enterprise.
• Where this interacts with another regime, see GDPR reference architecture for enterprise LLM deployment at scale.
• GDPR provider failover and degradation architecture for enterprise LLM covers the adjacent case.
• If this is the blocker in front of you: enterprise AI infrastructure review.