Anonimización antes del modelo
Los datos personales se sustituyen antes de la llamada, nunca después. Fail-closed: si la anonimización falla, la petición no sale.
Ingeniería · Seguridad y cumplimiento
Seguridad y cumplimiento: RGPD y zero-trust en la arquitectura
El cumplimiento normativo se sostiene en el código o no se sostiene. Anonimización de los datos personales antes de procesarlos, aislamiento entre organizaciones aplicado en la base de datos, minimización de lo que se guarda y rastro de cada actuación. Son controles que se pueden verificar leyendo el sistema, no leyendo una política.
Actualizado:
Definiciones clave
- Zero-trust
- Modelo en el que ningún usuario, servicio ni red se considera de fiar por defecto, ni siquiera dentro de la red interna. Cada petición se autentica y se autoriza explícitamente.
- Anonimización previa a la inferencia
- Sustitución de los datos personales antes de enviar el texto a un modelo de IA. El proceso es fail-closed: si la anonimización falla, la petición no sale.
- Row-Level Security (RLS)
- Política nativa de PostgreSQL que filtra las filas por organización dentro de la propia base de datos. El aislamiento deja de depender de que ninguna consulta olvide el filtro.
- Minimización de datos
- Principio del RGPD según el cual solo se trata el dato estrictamente necesario. En la práctica: los documentos de ingesta no se persisten después del parseo.
Los cuatro controles que un documento no puede sustituir
El RGPD no se cumple con un documento. Se cumple con un sistema que anonimiza los datos personales antes de procesarlos, que no guarda lo que no necesita, que no deja que un cliente vea los datos de otro y que deja rastro de quién tocó qué. Los cuatro controles se pueden comprobar leyendo el código y viendo el sistema funcionar. Una política, no: describe la intención, no el comportamiento.
Anonimización antes de la inferencia. Los datos personales se sustituyen antes de la llamada al modelo, nunca después, y el proceso es fail-closed: si la anonimización falla, la petición no sale. No hay una ruta por la que un nombre o un DNI lleguen al modelo por accidente. La inferencia corre además dentro de la Unión Europea. Está explicado en detalle en la landing de RAG privado.
Aislamiento entre organizaciones. Se aplica con Row-Level Security en PostgreSQL: la base de datos filtra por organización en cada consulta, esté el filtro escrito arriba o no. La frontera queda por debajo de la aplicación, y por eso un fallo en el backend no puede cruzar datos entre clientes. El detalle está en la arquitectura multi-tenant.
Minimización y trazabilidad. Los documentos de ingesta no se persisten después del parseo: se procesan y se descartan, porque el dato que no se guarda no se puede filtrar. Y cada actuación deja registro de quién la hizo, cuándo y sobre qué. En un canal de denuncias o en un peritaje judicial eso no es una buena práctica: es lo que hace que lo que entra al sistema aguante después en un juzgado.
Y una aclaración que ahorra tiempo a todo el mundo: no somos una empresa de auditoría ni de pentesting, y no acompañamos certificaciones SOC 2. Lo que hacemos es construir el sistema con los controles dentro, en sectores donde cumplir la norma europea es la condición para poder operar: sin ella no te dejan entrar, y por eso es la garantía que permite confiarle el trabajo a la máquina. Si necesitas una auditoría formal, la firma un auditor acreditado. Lo que sí se puede enseñar es cómo está construido Perizial, que maneja expedientes periciales con datos personales todos los días.
Qué controles lleva el sistema dentro
Aislamiento por organización
Row-Level Security en PostgreSQL. La base de datos filtra por organización aunque la consulta se olvide de hacerlo.
Residencia de datos en la UE
Google Cloud, con la inferencia en europe-southwest1 (Madrid). Los datos y el modelo permanecen en la Unión Europea.
Minimización en la ingesta
Los documentos que entran no se persisten después del parseo. El dato que no se guarda no se puede filtrar.
Trazabilidad de cada actuación
Quién hizo qué, cuándo y sobre qué expediente. Es lo que permite defender un informe si alguien lo discute.
Secretos fuera del repositorio
Las credenciales viven en el gestor de secretos de la plataforma, no en el código ni en un .env que acaba en un correo.
Permiso mínimo por función
Cada servicio y cada persona acceden solo a lo que necesitan para su trabajo. Nada de credenciales de administrador por comodidad.
Citas verificables contra la invención
Si el sistema genera texto, cada afirmación cita su fuente y una persona revisa antes de firmar. En trabajo regulado, quien firma responde.
CI antes de producción
Ningún cambio llega a producción sin pasar por integración continua. El desarrollo se hace con Claude Code y se revisa.
Dónde se puede ver funcionando
Perizial maneja expedientes periciales con datos personales todos los días, en producción y con clientes de pago. Los datos se anonimizan antes de llegar al modelo con un proceso fail-closed, los expedientes están aislados por organización con Row-Level Security en la base de datos, los documentos de ingesta no se guardan después del parseo y la inferencia corre en Madrid. No es un checklist de cumplimiento: es la arquitectura de un producto que ya opera en un dominio regulado, y se puede enseñar funcionando.
Perizial: los controles en un producto real →
Expedientes con datos personales, anonimización previa a la inferencia y aislamiento por organización. Con clientes de pago.
Ingeniería: cómo trabajamos →
La línea de ingeniería a medida de CyberVaultLabs: cómo se define el alcance, qué cuesta y de quién es el código.
Preguntas frecuentes
- ¿Qué significa zero-trust en la práctica?
- Que ningún usuario, servicio ni red se considera de fiar por defecto, ni siquiera dentro de la propia red interna: cada petición se autentica y se autoriza explícitamente. No es un producto que se compra, es una forma de construir. En la práctica se traduce en cosas concretas: permisos mínimos por función, secretos fuera del repositorio, fronteras aplicadas por debajo de la aplicación y registro de cada acceso.
- ¿Hacéis auditorías SOC 2 o pentesting?
- No. Cyber Vault SL no es una empresa de auditoría ni de pentesting, y no acompañamos certificaciones SOC 2. Lo que hacemos es construir el sistema con los controles dentro: anonimización previa a la inferencia, aislamiento por organización en la base de datos, minimización de los datos que se guardan, residencia en la UE y trazabilidad de cada actuación. Si necesitas una auditoría formal, la firma un auditor acreditado, y no somos nosotros.
- ¿El RGPD es cosa del departamento legal?
- Solo en parte. Hay un lado documental —registro de actividades, política de privacidad, encargados de tratamiento— y hay un lado técnico que no cubre ningún documento: que los datos personales se anonimicen antes de procesarse, que no se guarde lo que no hace falta, que un cliente no pueda ver los datos de otro y que quede rastro de quién tocó qué. Sin ese lado técnico, la carpeta de cumplimiento no protege cuando ocurre un incidente.
- ¿Cómo se aíslan los datos entre clientes?
- Con Row-Level Security en PostgreSQL: la base de datos filtra las filas por organización en cada consulta, esté el filtro en el código o no. La frontera queda por debajo de la aplicación, así que un fallo en el backend no puede cruzar datos entre clientes. Es la diferencia entre un aislamiento que depende de que nadie se equivoque nunca y uno que aguanta que alguien se equivoque.
- ¿Qué pasa con los datos personales antes de llegar a un modelo de IA?
- Se anonimizan antes de la llamada al modelo, nunca después, y el proceso es fail-closed: si la anonimización falla, la petición no sale. No existe una ruta por la que un dato identificable llegue al modelo por accidente. La inferencia, además, corre dentro de la Unión Europea, en la región europe-southwest1 (Madrid).
- ¿Qué es un sistema interno de información según la Ley 2/2023?
- El canal por el que una organización obligada debe permitir que se comuniquen infracciones internamente, garantizando la confidencialidad del informante. Lo que se le exige a ese canal no es una funcionalidad, es una propiedad: que lo que entre por él aguante después en un juzgado, con cadena de custodia y trazabilidad íntegra. CyberForensic 360, nuestra tercera plataforma, está construida para eso y hoy está en desarrollo, todavía no comercializada.
- ¿Podéis construir estos controles en el sistema de mi empresa?
- Sí. Es una línea abierta: si tu empresa necesita un sistema propio, lo construimos contigo con estos controles dentro desde el primer día —anonimización previa a la inferencia, aislamiento por organización en la base de datos, minimización en la ingesta y trazabilidad de cada actuación—, no añadidos después. El alcance se cierra por escrito antes de empezar.
Servicios relacionados
RAG empresarial privado →
La anonimización previa a la inferencia y las citas verificables, explicadas en detalle.
SaaS B2B multi-tenant →
Cómo se aplica en la base de datos el aislamiento entre organizaciones que comparten plataforma.
Infraestructura cloud →
Dónde viven los datos, por qué la región se elige por normativa y de quién es la cuenta cloud.
¿Hablamos de tu proyecto?
Escribe a [email protected] y cuenta qué proceso quieres automatizar, qué datos toca y con qué sistemas tiene que hablar. Con eso se puede responder si tiene sentido, qué alcance tendría y en qué rango de precio cae.