Esto no es asesoramiento jurídico. Es una descripción de lo que hace el código, escrita para que tu abogado pueda contrastarla con el código fuente.
Quién responde de qué
El RGPD asigna roles, y el rol decide quién debe qué. Arkeion se distribuye en dos formas, y cada una cae a un lado distinto de esa línea.
Si empotras el motor o lo ejecutas tú mismo, no somos encargados del tratamiento. Nunca recibimos tus datos, no hay contrato que firmar y no hay nada nuestro en lo que tengas que confiar. El motor es MIT o Apache-2.0 y el formato de fichero está publicado, así que nada de ese montaje depende de que nosotros sigamos existiendo.
Si usas Arkeion Cloud, Syrakon trata datos personales siguiendo tus instrucciones y nos aplica todo el artículo 28: contrato por escrito, lista de subencargados, asistencia con las solicitudes de los interesados y supresión o devolución al terminar.
El problema de la supresión
Lee esta sección dos veces antes de meter datos personales en Arkeion. Es el único punto en el que la decisión central de diseño del motor juega en contra de una obligación legal, y no hay redacción que lo haga desaparecer.
Arkeion es append-only con copy-on-write. Actualizar una fila no sobrescribe la fila antigua: escribe una versión nueva y mantiene la antigua accesible mediante AS OF. Ese es el sentido entero del producto, y es exactamente lo que el artículo 17 no quiere.
Hay exactamente una herramienta que elimina historia: vacuum, con una política de retención. Admite tres formas: conservarlo todo, conservar las últimas n versiones o conservar todo desde una marca de tiempo. Las tres son una frontera global.
La consecuencia es cruda. Para garantizar que las versiones históricas del interesado B han desaparecido, la frontera tiene que quedar por encima de la última versión de B, lo que descarta la historia de todas las demás filas por debajo de esa misma línea. La supresión completa de una persona, sin dar nada por supuesto sobre dónde aparecen sus datos, significa KeepLast(1): tirar la historia entera de la base de datos. No hay purga por fila, por clave ni por interesado, y no vamos a insinuar lo contrario.
Dos detalles operativos que importan si piensas prometerle a alguien un plazo de supresión:
vacuumse niega a ejecutarse mientras exista cualquier rama distinta demain. Una solicitud de supresión queda bloqueada hasta que fusiones o elimines las demás.vacuumdevuelve ocupado si hay una transacción de escritura abierta, y reescribe el fichero entero, así que mientras se ejecuta necesita aproximadamente el doble del tamaño de la base de datos en espacio libre.
Qué significa honestamente «supresión física»
vacuum construye un fichero nuevo que solo contiene las versiones por encima de la frontera y lo renombra sobre el antiguo. Las versiones podadas no llegan a escribirse en el fichero nuevo, y un AS OF por debajo de la frontera devuelve un error de versión no encontrada en lugar de datos. Eso es real, y es más que una marca de borrado.
Pero el fichero antiguo se desenlaza, no se tritura. Nada sobrescribe esos bloques. En un sistema de ficheros copy-on-write, en un volumen con instantáneas o en un SSD haciendo nivelado de desgaste, los bytes anteriores pueden sobrevivir en el medio mucho después del renombrado. Así que la frase exacta es «eliminado del fichero de la base de datos», no «destruido en el disco», ni «suprimido de forma verificable». El informe de vacuum es nuestro propio recuento de lo que descartó, no una certificación, y ningún test comprueba que el contenido suprimido no esté en el fichero nuevo.
El patrón que sí funciona
La salida no es pedir una funcionalidad: es una decisión de esquema, y hay que tomarla antes de escribir la primera fila.
Separa la identidad de los eventos. La tabla de identidad es pequeña, guarda la correspondencia entre un identificador opaco y la persona real, y recibe una política de retención agresiva: colapsarla a una sola versión no cuesta casi nada. La tabla de historia es la grande, la append-only, y no contiene nunca un nombre, un correo ni un campo de texto libre donde alguien acabará escribiendo uno.
Una solicitud de supresión borra entonces la correspondencia y aplica vacuum a la tabla pequeña. La historia conserva su cadena de hashes y su registro completo de versiones, y nadie puede saber de quién era.
Una advertencia, porque aquí es donde suele venderse el argumento por encima de lo que da: esto solo alcanza el anonimato si después la reidentificación no es razonablemente posible de verdad. Una fila de historia con un código postal, una fecha de nacimiento y un diagnóstico raro puede identificar a alguien sin ningún nombre adjunto. Los datos seudonimizados siguen siendo datos personales: el patrón te lleva de «imposible» a «manejable», no de «imposible» a «exento».
Crypto-shredding, y exactamente qué te da
La respuesta estándar a «append-only frente a supresión» es el crypto-shredding: no borres los datos, destruye la clave y el texto cifrado se convierte en ruido. Es una buena respuesta. También la reclaman de forma rutinaria productos cuya granularidad de claves no la sostiene, así que aquí va exactamente dónde la nuestra la sostiene y dónde no.
El motor tiene una clave por base de datos. El cifrado es a nivel de página en el sentido de que la página es la unidad que sella cada operación: un cifrador AES-256-GCM por fichero, con el nonce como contador por página. No es una clave por página. Y una página es un nodo B-tree que contiene filas de quien resulte quedar ordenado cerca, así que la unidad de cifrado y la unidad de supresión no coinciden. Destruir la clave no elimina a una persona; elimina la base de datos.
Eso descarta triturar a un interesado dentro del motor. No descarta el crypto-shredding: mueve la frontera de la clave a los dos sitios donde sí funciona.
Una clave por tenant: esta es la que resuelve las copias de seguridad
Una base de datos gestionada es un fichero, y un fichero admite una clave. Dale a cada tenant la suya y destruirla deja su base de datos entera ilegible en todos los sitios donde exista ese fichero, incluidas todas las copias hechas antes de la solicitud, en medios que ya nadie puede enumerar.
Eso importa porque las copias de seguridad son la parte del artículo 17 que la mayoría de proveedores se salta sin decirlo. Una política de retención no llega a una instantánea tomada hace tres meses; una clave destruida sí. Es supresión de fin de relación —un cliente que se va, un contrato terminado—, no supresión por persona, y en ese trabajo es realmente fuerte.
Una clave por interesado: por encima del motor, no dentro
Cuando tengas que conservar datos identificativos en la historia append-only, cífralos en tu aplicación con una clave que pertenezca a esa persona, y guarda las claves en algún sitio que puedas borrar de verdad.
El llavero es pequeño por construcción —una fila corta por interesado—, así que la frontera de retención que resulta ruinosa en una tabla grande aquí es trivial: colapsarlo a una sola versión no cuesta casi nada y no se lleva por delante ninguna historia que merezca la pena. Es el mismo truco que el patrón de seudonimización de más arriba, un nivel más fuerte: allí mantenías las identidades fuera de la historia; aquí las mantienes dentro, pero ilegibles.
Las cuatro cosas que tienen que ser ciertas, o es teatro
La clave no debe sobrevivir en ninguna parte. Haz una copia de seguridad del llavero y habrás deshecho la supresión sin darte cuenta. El llavero es lo único de tu sistema que no debe estar en tus copias de seguridad, y esa es una excepción deliberada y documentada, no un descuido.
Las claves no deben ser derivables. Una clave por interesado calculada a partir de un secreto maestro más el id del interesado no queda triturada cuando borras la fila: cualquiera que tenga el maestro la recalcula. Genéralas aleatoriamente y guárdalas; no las derives.
Los metadatos sobreviven, y siguen siendo datos personales. El crypto-shredding destruye el contenido, no la existencia. Que un registro existió, cuándo se escribió, con qué frecuencia cambió, qué tamaño tenía y con qué enlazaba queda todo en claro. Si la forma de los datos identifica a alguien por sí sola, esto no te salva.
El estatus jurídico es defendible, no está zanjado. La lectura habitual es que los datos que nadie puede descifrar están suprimidos a efectos prácticos, y es la posición sobre la que opera la mayor parte del sector. No es una resolución regulatoria universal, y una autoridad de control puede adoptar un criterio más estricto. Diseña contando con ello, documéntalo y no dejes que nadie te diga que es una cuestión cerrada.
Cómo está esto hoy
El patrón por interesado funciona ahora mismo, porque vive en tu aplicación: el motor solo ve texto cifrado en una columna. El patrón por tenant necesita que el demonio acepte una clave, cosa que no hace: arkeiond no admite ninguna, así que una base de datos servida está en claro en el disco. Hasta que eso cambie, el crypto-shredding a nivel de tenant está disponible para despliegues empotrados y autoalojados, y no para el servicio gestionado.
Qué demuestra la cadena de hashes
Cada commit calcula el hash del valor anterior de la cadena junto con el hash del contenido, la versión, la marca de tiempo y las raíces. verify() recorre desde el génesis hasta la cabeza e informa de la versión exacta en la que algo falla. Cambia un byte de una página histórica y saldrá a la luz.
La cadena es un SHA-256 sin clave sobre campos públicos. No hay ningún secreto en ella, ni firma, ni código de autenticación de mensaje. Cualquiera que tenga el fichero puede recalcular la cadena entera desde el génesis después de cambiar lo que quiera, y verify() pasará. Lo correcto es decir que cualquier manipulación queda en evidencia, y no usaremos inmutable ni inviolable en ninguna parte de este sitio.
La mitigación es un ancla de auditoría: un número de versión más el hash de la cadena en esa versión, cuarenta bytes que capturas y guardas. Después, verificar contra esa ancla detecta cualquier reescritura de la historia por debajo de ella. Todo su valor viene de dónde la guardas: si vive al lado de la base de datos, no demuestra nada.
Dos límites que conviene decir: no hay nada notarizado, sellado en el tiempo por un tercero, cofirmado ni publicado en un registro de transparencia, y la comprobación del ancla no es alcanzable hoy a través del protocolo de red, así que hoy por hoy es una disciplina para uso empotrado y de operador.
Cifrado, exactamente dónde aplica
El motor cifra páginas con AES-256-GCM cuando le proporcionas una clave. Le pasas treinta y dos bytes en crudo; el motor no tiene almacén de claves ni función de derivación, por diseño: la custodia se queda contigo. Cada fichero deriva su propia subclave, así que reutilizar una clave maestra entre tenants no puede provocar colisiones de nonce, y las claves se pueden rotar reescribiendo el fichero.
Lo que esto no cubre importa igual:
- El demonio no admite clave. Todo lo que hoy se sirve por red está sin cifrar en el disco. El cifrado en reposo para un producto alojado es un requisito previo que no hemos entregado, y hasta que lo hagamos ninguna página de aquí lo va a afirmar.
- No hay integración con KMS, HSM ni Vault. Aquí BYOK significa literalmente que entregas los bytes. No es gestión de claves de empresa.
- La unidad es la página, y hay una clave por base de datos. Por tanto, hacer crypto-shredding de una persona concreta es imposible; destruir una clave destruye la base de datos entera, no a un interesado.
Artículo por artículo
| Obligación | Qué te da Arkeion | Qué sigue siendo tuyo |
|---|---|---|
| Art. 5.1.e) limitación del plazo de conservación | Políticas de retención aplicadas mediante compactación | Por defecto se conserva todo: tienes que fijar una política a propósito |
| Art. 5.2 responsabilidad proactiva | La historia es prueba consultable, no una afirmación | Decidir qué tiene que demostrar esa prueba |
| Art. 15 acceso | SELECT sobre el estado actual o sobre cualquier estado pasado |
Componer la respuesta; no hay comando de exportación |
| Art. 17 supresión | Una frontera de retención global | El diseño del esquema: ver la sección de más arriba |
| Art. 20 portabilidad | Un solo fichero, formato especificado públicamente, terceros pueden escribir lectores | Convertir al formato que quiera el destinatario |
| Art. 25 desde el diseño | La seudonimización sale natural si separas identidad de historia | Hacer la separación de verdad |
| Art. 30 registro de actividades de tratamiento | Esquema e historia de versiones | Los registros de acceso: no registramos las lecturas |
| Art. 32 seguridad | AES-256-GCM en reposo (empotrado), TLS en tránsito, credenciales argon2id, permisos por rama | La custodia de las claves, y todo lo que está por encima de la base de datos |
| Art. 33 alcance de la brecha | AS OF dice exactamente qué existía en un momento dado |
Notificar, dentro del plazo |
| Art. 44 y ss. transferencias | Alojamiento en la UE, jurisdicción francesa, propiedad europea | Tus propias transferencias ulteriores |
Preguntas de compradores escépticos
«Append-only y el derecho de supresión son incompatibles. ¿Cómo lo cuadráis?» En su mayor parte no lo cuadramos, y la sección de arriba lo dice con un diagrama. La frontera es global. La respuesta viable es no meter datos identificativos en la historia append-only desde el principio, que es una decisión de esquema que se toma el primer día y no se puede reajustar barato.
«¿vacuum es supresión real o una marca?»
Real, en el sentido de que las versiones podadas no llegan a escribirse en el fichero nuevo y quedan ilegibles a través de AS OF. No es real en el sentido de trituración: el fichero antiguo se desenlaza, no se sobrescribe, y sus bloques pueden persistir en el medio.
«Decís que no accedéis a nuestros datos. Sois root en esa máquina.» Correcto. En el nivel gestionado, «no accedemos» es un compromiso respaldado por aislamiento y una traza de auditoría: es una política, no una imposibilidad física. La versión en la que no podemos leerlos necesita un enclave confidencial, y eso está en la hoja de ruta, no entregado. Mantenemos esas dos expresiones separadas en todo este sitio porque la diferencia es justo lo importante.
«¿Está mi base de datos cifrada en reposo en Cloud?» Hoy no. El demonio no admite clave. Es una carencia que tenemos que cerrar antes de poder vender un producto alojado con un argumento de seguridad, y preferimos decirlo aquí a que lo descubras en una auditoría de seguridad.
«¿Podéis hacer crypto-shredding de un solo cliente?» Dentro del motor no: una clave por base de datos, y una página contiene filas de mucha gente, así que destruir la clave destruye la base de datos, no a una persona. Sí puedes hacerlo por encima del motor con una clave por interesado y un llavero que borres de verdad; la sección de arriba expone el patrón y las cuatro condiciones que tienen que cumplirse para que signifique algo. Con granularidad de tenant funciona directamente, y esa es la versión que llega a tus copias de seguridad.
«Vuestra cadena no está firmada. Yo podría reescribirla.» Si tienes el fichero, sí; y nosotros también podríamos. Por eso decimos que cualquier manipulación queda en evidencia, y no que sea imposible. Captura un ancla, guárdala donde no podamos llegar, y la garantía se vuelve real para todo lo que quede por debajo de ese punto.
«¿Registráis quién leyó qué?» No. Hoy no hay registro de accesos, las lecturas no dejan rastro y los commits no llevan identidad de actor: la cadena registra qué cambió y cuándo, nunca quién. Si tus obligaciones exigen registros de acceso, tienes que producirlos por encima de la base de datos.
«¿Cómo borro de vuestras copias de seguridad?» No hay producto de copias de seguridad, y nada propaga un borrado a las copias que ya existen. Es un problema difícil para todo el sector; preferimos admitirlo a fingir que una política de retención lo resuelve.
«¿Estáis certificados en ISO 27001 o SOC 2?» No, y no lo hemos solicitado. Si una certificación es para ti un requisito indispensable, todavía no encajamos.
«¿Qué pasa con nuestros datos si Syrakon desaparece?» El motor es MIT o Apache-2.0, el formato de fichero está especificado públicamente en este sitio y tu base de datos es un único fichero que ya tienes en tu poder. Puedes seguir ejecutándolo, o escribir tu propio lector a partir de la especificación. Esta es la única pregunta de continuidad que podemos responder sin pedir ninguna confianza en absoluto.
«¿Subencargados y la CLOUD Act estadounidense?» El alojamiento es europeo bajo jurisdicción francesa, y la propiedad es europea, que es la parte que de verdad importa, porque un proveedor de propiedad estadounidense está expuesto elijas la región que elijas. Cloud todavía no está abierto; cuando abra, la lista de subencargados se publica junto con el contrato.
«¿Podemos sacarlo todo?»
Copia el fichero, léelo con una implementación independiente o sácalo con SELECT a través del driver. Hoy no hay exportación en un solo comando ni volcado de datos en CSV, JSON o SQL: el esquema se vuelca, los datos no.
«¿Llama a casa?» Sin telemetría, sin informes de uso, sin llamadas de red que el motor haga por su cuenta.
Lo que no afirmamos
- No decimos «cumple el RGPD»: ninguna base de datos puede venderte eso.
- No es inmutable ni inviolable: lo que hay es que cualquier manipulación queda en evidencia.
- No está notarizado, ni anclado por un tercero, ni firmado.
- Hoy, no está cifrado en reposo cuando se sirve por red.
- No hay supresión por interesado dentro del motor, ni producto de gestión de claves. El crypto-shredding de más arriba es un patrón que implementas tú, no una funcionalidad que entreguemos.
- Sin registros de acceso, sin copias de seguridad gestionadas, sin exportación en un clic.
- Sin certificaciones de seguridad.
Todo lo de esta página se puede comprobar contra el código fuente, que es la única razón para creer nada de esto. Si encuentras aquí una afirmación que el código no sostiene, eso es un bug y queremos que nos lo cuentes.