GDPR 'delete' môže prejsť každou kontrolou, kým 5 zo 6 stores stále má dáta
'Zmazali sme riadok' overuje, že delete sa vykonal; GDPR Článok 17 žiada, že neprežije obnoviteľná kópia. Postavili sme 6-store forget-verification benchmark: bežný 'zmaž riadok' vzor skóruje 0.17 (5 stores stále tečie) vs 1.00 pre správny hard-delete, plus podpísaný proof-of-erasure.
Right-to-erasure požiadavka má presný význam a väčšina stackov ticho odpovedá na slabší. „Zmazali sme riadok a zalogovali to" overuje, že delete sa vykonal. GDPR Článok 17 žiada niečo iné: že neprežije žiadna obnoviteľná kópia. To sú rôzne tvrdenia a v tej vzdialenosti medzi nimi žije všetko riziko.
Postavili sme malý benchmark, ktorý tú vzdialenosť meria, a číslo je nepríjemné.
Delete môže prejsť každou kontrolou, kým 5 zo 6 stores stále má dáta
Fakt v reálnom agent/RAG stacku nežije na jednom mieste. Žije v primary logu, vo vektorovom indexe (ako embedding), v embedding/response cache a — podľa tvojej infry — v Qdrant kolekcii, pgvector tabuľke a S3 snapshote. Zmaž primary riadok a zaloguj to (bežný vzor), a toto nájde forget-verification audit naprieč tým 6-store fan-outom:
| stratégia mazania | forget-verification skóre | stores, ktoré stále tečú |
|---|---|---|
| zmaž riadok + zaloguj (bežný bug) | 0.17 | vector-index, embed-cache, qdrant, pgvector, s3-snapshots |
| hard-delete + reindex všade | 1.00 | žiadny |
Skóre je zlomok stores, z ktorých hodnota už nie je obnoviteľná po zmazaní. „Delete", ktorý vrátil 200, nechal dáta obnoviteľné v piatich zo šiestich miest.
Prečo prežitý embedding nie je inertný
Toto nie je nové, ale oplatí sa zopakovať: prežitý embedding zrekonštruuje svoj zdroj. Morris et al. ukázali zhruba 92% exact rekonštrukciu krátkych vstupov z ich embeddingov („Text Embeddings Reveal (Almost) As Much As Text", EMNLP 2023) a Ghost Vectors (arXiv 2606.18497) ukazuje, že soft-deleted vektory ostávajú rekonštruovateľné v HNSW indexoch. Takže „zmazali sme riadok" môže byť pravda v tom istom momente, keď je obsah na jeden nearest-neighbour dopyt.
„API vrátilo 200" a „je to preč" oddeľuje background proces
Vektorové enginy to defaultne zhoršujú. Qdrant značí zmazané body v bitmaske a fyzicky ich zahodí až keď segment prekročí optimizer deleted_threshold (0.2, s 1000-vektorovým minimom) — roztrúsené delety môžu ostať pod tou čiarou donekonečna. pgvector dedí Postgres MVCC: tuple je dead ale na disku do VACUUM, a HNSW graf sa opraví až vtedy. A na versioned S3 buckete je „delete" len delete-marker cez živú verziu, na jeden list-object-versions dopyt. Takže delete, o ktorom si appka myslí, že spravila, a fyzický stav na disku oddeľuje compaction, vacuum alebo garbage-collect, ktorý sa možno nikdy nespustí.
Dôkaz, nie log
Oprava nie je lepší delete log. Je to brať delete ako tvrdenie, ktoré sa adversariálne otestuje, a vydať podpísaný artefakt, keď prejde. inspeximus ErasureAuditor zaregistruje každý store, kde môžu subjektove dáta žiť, po tvojom zmazaní sa z každého pokúsi obnoviť (verbatim scan pre text a cache, nearest-neighbour rekonštrukcia pre prežité vektory, soft-delete-state check pre Qdrant/pgvector/S3), a compliance_receipt() zabalí výsledok ako podpísaný, overiteľný proof-of-erasure — artefakt, ktorý DPO reálne odovzdá regulátorovi, tamper-evident pod vlastným kľúčom.
```python from inspeximus.erasure_auditor import ErasureAuditor, verify_compliance_receipt, ed25519_verify
receipt = auditor.compliance_receipt("user:alice", ["12.69"], sign=my_signer, pubkey=my_pk, request_id="dsar-2026-07", basis="GDPR Art.17")
verify_compliance_receipt(receipt, ed25519_verify) # (True, "ok") ```
Poctivý rozsah
Auditujú sa stores, ktoré zaregistruješ — nie zálohy, ktoré nie, a nedokáže fyzickú deštrukciu; vektorová kontrola je dolná hranica leaku, keďže plná inverzia je silnejšia než nearest-neighbour rekonštrukcia. Keď store tečie, oprava je hard-delete plus reindex, alebo crypto-shredding kľúča namiesto riadku. Ale mení to, čo môžeš povedať, z „spravili sme delete" na „žiadny zaregistrovaný store to už nemá, a tu je podpísaný dôkaz" — čo je tvrdenie, o ktoré Článku 17 vždy išlo.
Je to open (MIT), zero-dependency, a benchmark je spustiteľný: pip install inspeximus.
FAQ
Splní „zmazali sme riadok" GDPR Článok 17? Nie samo o sebe. Článok 17 je o tom, že dáta už nie sú obnoviteľné, nie o tom, že sa delete vykonal. Prežitý embedding, soft-deleted vektor alebo S3 delete-marker môžu nechať obsah obnoviteľný, kým delete log hlási hotovo.
Kde „delete" zvyčajne prežije? Vo vektorovom indexe (embedding zrekonštruuje text), v embedding/response cache, a v soft-delete rezíduu samotného enginu — Qdrant body pod optimizer threshold, pgvector dead tuples pred VACUUM, S3 delete-marker cez živú verziu.
Čo je forget-verification skóre? Zlomok stores, kde môžu subjektove dáta žiť, z ktorých hodnota už nie je obnoviteľná po tvojom zmazaní. Správny hard-delete skóruje 1.00; bežný „zmaž riadok" vzor skóroval 0.17 v našom 6-store benchmarku.