Això no és assessorament jurídic. És una descripció del que fa el codi, escrita perquè el teu advocat pugui contrastar-la amb el codi font.

Qui respon de què

El RGPD assigna rols, i el rol decideix qui deu què. Arkeion es distribueix en dues formes, i cadascuna cau a un costat diferent d’aquesta línia.

Si encastes el motor o l’executes tu mateix, no som encarregats del tractament. Mai no rebem les teves dades, no hi ha cap contracte per signar i no hi ha res nostre en què hagis de confiar. El motor és MIT o Apache-2.0 i el format de fitxer està publicat, així que res d’aquest muntatge no depèn que nosaltres continuem existint.

Si fas servir Arkeion Cloud, Syrakon tracta dades personals seguint les teves instruccions i se’ns aplica tot l’article 28: contracte per escrit, llista de subencarregats, assistència amb les sol·licituds dels interessats i supressió o devolució en acabar.

El problema de la supressió

Llegeix aquesta secció dues vegades abans de posar dades personals a Arkeion. És l’únic punt on la decisió central de disseny del motor juga en contra d’una obligació legal, i no hi ha redacció que ho faci desaparèixer.

Arkeion és append-only amb copy-on-write. Actualitzar una fila no sobreescriu la fila antiga: escriu una versió nova i manté l’antiga accessible mitjançant AS OF. Aquest és tot el sentit del producte, i és exactament el que l’article 17 no vol.

Hi ha exactament una eina que elimina història: vacuum, amb una política de retenció. Admet tres formes: conservar-ho tot, conservar les últimes n versions o conservar-ho tot des d’una marca de temps. Les tres són una frontera global.

La conseqüència és crua. Per garantir que les versions històriques de l’interessat B han desaparegut, la frontera ha de quedar per damunt de l’última versió de B, cosa que descarta la història de totes les altres files per sota d’aquesta mateixa línia. La supressió completa d’una persona, sense donar res per suposat sobre on apareixen les seves dades, vol dir KeepLast(1): llençar la història sencera de la base de dades. No hi ha purga per fila, per clau ni per interessat, i no insinuarem el contrari.

Dos detalls operatius que importen si penses prometre a algú un termini de supressió:

• vacuum es nega a executar-se mentre existeixi qualsevol branca diferent de main. Una sol·licitud de supressió queda bloquejada fins que fusionis o eliminis les altres.
• vacuum retorna ocupat si hi ha una transacció d’escriptura oberta, i reescriu el fitxer sencer, així que mentre s’executa necessita aproximadament el doble de la mida de la base de dades en espai lliure.

Què vol dir honestament «supressió física»

vacuum construeix un fitxer nou que només conté les versions per damunt de la frontera i el reanomena sobre l’antic. Les versions podades no arriben a escriure’s al fitxer nou, i un AS OF per sota de la frontera retorna un error de versió no trobada en lloc de dades. Això és real, i és més que una marca d’esborrat.

Però el fitxer antic es desenllaça, no es tritura. Res no sobreescriu aquells blocs. En un sistema de fitxers copy-on-write, en un volum amb instantànies o en un SSD fent anivellament de desgast, els bytes anteriors poden sobreviure al mitjà molt després del reanomenament. Així que la frase exacta és «eliminat del fitxer de la base de dades», no «destruït al disc», ni «suprimit de manera verificable». L’informe de vacuum és el nostre propi recompte del que va descartar, no una certificació, i cap test no comprova que el contingut suprimit no sigui al fitxer nou.

El patró que sí que funciona

La sortida no és demanar una funcionalitat: és una decisió d’esquema, i l’has de prendre abans d’escriure la primera fila.

Separa la identitat dels esdeveniments. La taula d’identitat és petita, guarda la correspondència entre un identificador opac i la persona real, i rep una política de retenció agressiva: col·lapsar-la a una sola versió no costa gairebé res. La taula d’història és la gran, la append-only, i no conté mai un nom, un correu ni un camp de text lliure on algú acabarà escrivint-ne un.

Una sol·licitud de supressió esborra llavors la correspondència i aplica vacuum a la taula petita. La història conserva la seva cadena de hashes i el seu registre complet de versions, i ningú no pot saber de qui era.

Un advertiment, perquè aquí és on l’argument se sol vendre per damunt del que dona: això només arriba a l’anonimat si després la reidentificació no és raonablement possible de debò. Una fila d’història amb un codi postal, una data de naixement i un diagnòstic rar pot identificar algú sense cap nom adjunt. Les dades pseudonimitzades continuen sent dades personals: el patró et porta de «impossible» a «manejable», no de «impossible» a «exempt».

Crypto-shredding, i exactament què et dona

La resposta estàndard a «append-only contra supressió» és el crypto-shredding: no esborris les dades, destrueix la clau i el text xifrat es converteix en soroll. És una bona resposta. També la reclamen de manera rutinària productes la granularitat de claus dels quals no la sosté, així que aquí va exactament on la nostra la sosté i on no.

El motor té una clau per base de dades. El xifratge és a escala de pàgina en el sentit que la pàgina és la unitat que segella cada operació: un xifrador AES-256-GCM per fitxer, amb el nonce com a comptador per pàgina. No és una clau per pàgina. I una pàgina és un node B-tree que conté files de qui resulti quedar ordenat a prop, així que la unitat de xifratge i la unitat de supressió no coincideixen. Destruir la clau no elimina una persona; elimina la base de dades.

Això descarta triturar un interessat dins del motor. No descarta el crypto-shredding: mou la frontera de la clau als dos llocs on sí que funciona.

Una clau per tenant: aquesta és la que resol les còpies de seguretat

Una base de dades gestionada és un fitxer, i un fitxer admet una clau. Dona a cada tenant la seva i destruir-la deixa la seva base de dades sencera il·legible a tots els llocs on existeixi aquest fitxer, incloses totes les còpies fetes abans de la sol·licitud, en mitjans que ja ningú no pot enumerar.

Això importa perquè les còpies de seguretat són la part de l’article 17 que la majoria de proveïdors s’estalvien sense dir-ho. Una política de retenció no arriba a una instantània presa fa tres mesos; una clau destruïda sí. És supressió de fi de relació —un client que se’n va, un contracte acabat—, no supressió per persona, i en aquesta feina és realment forta.

Una clau per interessat: per damunt del motor, no a dins

Quan hagis de conservar dades identificatives a la història append-only, xifra-les a la teva aplicació amb una clau que pertanyi a aquella persona, i guarda les claus en algun lloc que puguis esborrar de debò.

El clauer és petit per construcció —una fila curta per interessat—, així que la frontera de retenció que resulta ruïnosa en una taula gran aquí és trivial: col·lapsar-lo a una sola versió no costa gairebé res i no s’endú cap història que valgui la pena. És el mateix truc que el patró de pseudonimització de més amunt, un nivell més fort: allà mantenies les identitats fora de la història; aquí les mantens a dins, però il·legibles.

Les quatre coses que han de ser certes, o és teatre

La clau no ha de sobreviure enlloc. Fes una còpia de seguretat del clauer i hauràs desfet la supressió sense adonar-te’n. El clauer és l’única cosa del teu sistema que no ha de ser a les teves còpies de seguretat, i aquesta és una excepció deliberada i documentada, no un descuit.

Les claus no han de ser derivables. Una clau per interessat calculada a partir d’un secret mestre més l’id de l’interessat no queda triturada quan esborres la fila: qualsevol que tingui el mestre la recalcula. Genera-les aleatòriament i guarda-les; no les derivis.

Les metadades sobreviuen, i continuen sent dades personals. El crypto-shredding destrueix el contingut, no l’existència. Que un registre va existir, quan es va escriure, amb quina freqüència va canviar, quina mida tenia i amb què enllaçava queda tot en clar. Si la forma de les dades identifica algú tota sola, això no et salva.

L’estatus jurídic és defensable, no està resolt. La lectura habitual és que les dades que ningú no pot desxifrar estan suprimides a efectes pràctics, i és la posició sobre la qual opera la major part del sector. No és una resolució reguladora universal, i una autoritat de control pot adoptar un criteri més estricte. Dissenya comptant-hi, documenta-ho i no deixis que ningú et digui que és una qüestió tancada.

Com està això avui

El patró per interessat funciona ara mateix, perquè viu a la teva aplicació: el motor només veu text xifrat en una columna. El patró per tenant necessita que el dimoni accepti una clau, cosa que no fa: arkeiond no n’admet cap, així que una base de dades servida està en clar al disc. Fins que això no canviï, el crypto-shredding a escala de tenant està disponible per a desplegaments encastats i autoallotjats, i no per al servei gestionat.

Què demostra la cadena de hashes

Cada commit calcula el hash del valor anterior de la cadena juntament amb el hash del contingut, la versió, la marca de temps i les arrels. verify() recorre des del gènesi fins al cap i informa de la versió exacta on alguna cosa falla. Canvia un byte d’una pàgina històrica i sortirà a la llum.

La cadena és un SHA-256 sense clau sobre camps públics. No hi ha cap secret, ni signatura, ni codi d’autenticació de missatge. Qualsevol que tingui el fitxer pot recalcular la cadena sencera des del gènesi després de canviar el que vulgui, i verify() passarà. El que toca dir és que qualsevol manipulació queda en evidència, i no farem servir immutable ni inviolable enlloc d’aquest lloc web.

La mitigació és una àncora d’auditoria: un número de versió més el hash de la cadena en aquella versió, quaranta bytes que captures i guardes. Després, verificar contra aquesta àncora detecta qualsevol reescriptura de la història per sota d’ella. Tot el seu valor ve de on la guardes: si viu al costat de la base de dades, no demostra res.

Dos límits que convé dir: no hi ha res notaritzat, segellat en el temps per un tercer, cosignat ni publicat en un registre de transparència, i la comprovació de l’àncora no és avui accessible a través del protocol de xarxa, així que ara com ara és una disciplina per a ús encastat i d’operador.

Xifratge, exactament on aplica

El motor xifra pàgines amb AES-256-GCM quan li proporciones una clau. Li passes trenta-dos bytes en cru; el motor no té magatzem de claus ni funció de derivació, per disseny: la custòdia es queda amb tu. Cada fitxer deriva la seva pròpia subclau, així que reutilitzar una clau mestra entre tenants no pot provocar col·lisions de nonce, i les claus es poden rotar reescrivint el fitxer.

El que això no cobreix importa igual:

• El dimoni no admet clau. Tot el que avui se serveix per xarxa està sense xifrar al disc. El xifratge en repòs per a un producte allotjat és un requisit previ que no hem lliurat, i fins que no ho fem cap pàgina d’aquí no ho afirmarà.
• No hi ha integració amb KMS, HSM ni Vault. Aquí BYOK vol dir literalment que entregues els bytes. No és gestió de claus d’empresa.
• La unitat és la pàgina, i hi ha una clau per base de dades. Per tant, fer crypto-shredding d’una persona concreta és impossible; destruir una clau destrueix la base de dades sencera, no un interessat.

Article per article

Obligació	Què et dona Arkeion	Què continua sent teu
Art. 5.1.e) limitació del termini de conservació	Polítiques de retenció aplicades mitjançant compactació	Per defecte es conserva tot: has de fixar una política expressament
Art. 5.2 responsabilitat proactiva	La història és prova consultable, no una afirmació	Decidir què ha de demostrar aquesta prova
Art. 15 accés	SELECT sobre l’estat actual o sobre qualsevol estat passat	Compondre la resposta; no hi ha ordre d’exportació
Art. 17 supressió	Una frontera de retenció global	El disseny de l’esquema: veure la secció de més amunt
Art. 20 portabilitat	Un sol fitxer, format especificat públicament, tercers poden escriure lectors	Convertir al format que vulgui el destinatari
Art. 25 des del disseny	La pseudonimització surt natural si separes identitat d’història	Fer la separació de debò
Art. 30 registre d’activitats de tractament	Esquema i història de versions	Els registres d’accés: no registrem les lectures
Art. 32 seguretat	AES-256-GCM en repòs (encastat), TLS en trànsit, credencials argon2id, permisos per branca	La custòdia de les claus, i tot el que està per damunt de la base de dades
Art. 33 abast de la bretxa	AS OF diu exactament què existia en un moment donat	Notificar, dins del termini
Art. 44 i ss. transferències	Allotjament a la UE, jurisdicció francesa, propietat europea	Les teves pròpies transferències ulteriors

Preguntes de compradors escèptics

«Append-only i el dret de supressió són incompatibles. Com ho quadreu?» En bona part no ho quadrem, i la secció de dalt ho diu amb un diagrama. La frontera és global. La resposta viable és no ficar dades identificatives a la història append-only des del principi, que és una decisió d’esquema que es pren el primer dia i no es pot reajustar barat.

«vacuum és supressió real o una marca?» Real, en el sentit que les versions podades no arriben a escriure’s al fitxer nou i queden il·legibles a través d’AS OF. No és real en el sentit de trituració: el fitxer antic es desenllaça, no se sobreescriu, i els seus blocs poden persistir al mitjà.

«Dieu que no accediu a les nostres dades. Sou root en aquesta màquina.» Correcte. Al nivell gestionat, «no hi accedim» és un compromís sostingut per aïllament i una traça d’auditoria: és una política, no una impossibilitat física. La versió on no podem llegir-les necessita un enclavament confidencial, i això és a la fulla de ruta, no lliurat. Mantenim aquestes dues expressions separades a tot aquest lloc web perquè la diferència és justament el que importa.

«La meva base de dades està xifrada en repòs a Cloud?» Avui no. El dimoni no admet clau. És una mancança que hem de tancar abans de poder vendre un producte allotjat amb un argument de seguretat, i preferim dir-ho aquí que no pas que ho descobreixis en una auditoria de seguretat.

«Podeu fer crypto-shredding d’un sol client?» Dins del motor no: una clau per base de dades, i una pàgina conté files de molta gent, així que destruir la clau destrueix la base de dades, no una persona. Sí que ho pots fer per damunt del motor amb una clau per interessat i un clauer que esborris de debò; la secció de dalt exposa el patró i les quatre condicions que s’han de complir perquè signifiqui alguna cosa. Amb granularitat de tenant funciona directament, i aquesta és la versió que arriba a les teves còpies de seguretat.

«La vostra cadena no està signada. Jo la podria reescriure.» Si tens el fitxer, sí; i nosaltres també podríem. Per això diem que qualsevol manipulació queda en evidència, i no que sigui impossible. Captura una àncora, guarda-la on no puguem arribar, i la garantia es torna real per a tot el que quedi per sota d’aquest punt.

«Registreu qui ha llegit què?» No. Avui no hi ha registre d’accessos, les lectures no deixen rastre i els commits no porten identitat d’actor: la cadena registra què va canviar i quan, mai qui. Si les teves obligacions exigeixen registres d’accés, els has de produir per damunt de la base de dades.

«Com esborro de les vostres còpies de seguretat?» No hi ha producte de còpies de seguretat, i res no propaga un esborrat a les còpies que ja existeixen. És un problema difícil per a tot el sector; preferim admetre-ho que no pas fingir que una política de retenció ho resol.

«Esteu certificats en ISO 27001 o SOC 2?» No, i no ho hem sol·licitat. Si una certificació és per a tu un requisit indispensable, encara no encaixem.

«Què passa amb les nostres dades si Syrakon desapareix?» El motor és MIT o Apache-2.0, el format de fitxer està especificat públicament en aquest lloc web i la teva base de dades és un únic fitxer que ja tens en el teu poder. Pots continuar executant-lo, o escriure el teu propi lector a partir de l’especificació. Aquesta és l’única pregunta de continuïtat que podem respondre sense demanar cap mena de confiança.

«Subencarregats i la CLOUD Act nord-americana?» L’allotjament és europeu sota jurisdicció francesa, i la propietat és europea, que és la part que de debò importa, perquè un proveïdor de propietat nord-americana està exposat triïs la regió que triïs. Cloud encara no està obert; quan obri, la llista de subencarregats es publica juntament amb el contracte.

«Ho podem treure tot?» Copia el fitxer, llegeix-lo amb una implementació independent o treu-lo amb SELECT a través del driver. Avui no hi ha exportació en una sola ordre ni bolcat de dades en CSV, JSON o SQL: l’esquema es bolca, les dades no.

«Truqueu a casa?» Sense telemetria, sense informes d’ús, sense trucades de xarxa que el motor faci pel seu compte.

El que no afirmem

• No diem «compleix el RGPD»: cap base de dades no et pot vendre això.
• No és immutable ni inviolable: el que hi ha és que qualsevol manipulació queda en evidència.
• No està notaritzat, ni ancorat per un tercer, ni signat.
• Avui, no està xifrat en repòs quan se serveix per xarxa.
• No hi ha supressió per interessat dins del motor, ni producte de gestió de claus. El crypto-shredding de més amunt és un patró que implementes tu, no una funcionalitat que lliurem.
• Sense registres d’accés, sense còpies de seguretat gestionades, sense exportació en un clic.
• Sense certificacions de seguretat.

Tot el que hi ha en aquesta pàgina es pot comprovar contra el codi font, que és l’única raó per creure’n res. Si hi trobes una afirmació que el codi no sosté, això és un bug i volem que ens ho expliquis.