Cifrado local vs nube clásica: qué cambia de verdad cuando se filtran tus datos

Si tienes una pequeña empresa o trabajas por tu cuenta con documentos de clientes, la pregunta no es realmente «¿podrían filtrarse mis datos?». Las brechas les ocurren a empresas mucho más grandes que la tuya, y a los proveedores en los que confían. La pregunta útil es: cuando se produce una filtración, ¿qué sale realmente? La respuesta depende casi por completo de algo que la mayoría nunca comprueba: quién tiene las claves de tus archivos.

Este artículo no es asesoramiento jurídico. Es un recorrido, en lenguaje claro, por lo que expone una brecha de datos en dos configuraciones: tus archivos en un servicio en la nube clásico (Google Drive, Dropbox, Notion, la mayoría de las herramientas SaaS), frente a tus archivos cifrados localmente en tu propio equipo antes de que nada salga de él.

Respuesta rápida

En un servicio en la nube clásico, tus archivos suelen estar cifrados «en reposo» en los servidores del proveedor, pero el proveedor tiene las claves de descifrado. Así que una brecha en ese proveedor, un empleado desleal o una solicitud de una autoridad válida pueden exponer tu contenido real de forma legible. Con el cifrado local, del lado del cliente, tus archivos se cifran en tu dispositivo con una clave que nunca sale de él en claro; el servidor (si es que sincronizas) solo guarda blobs cifrados opacos. Si ese servidor sufre una filtración, los atacantes obtienen un texto cifrado que no pueden leer sin tu contraseña. La diferencia en una brecha es tajante: la nube cifrada en reposo filtra tus documentos; el cifrado del lado del cliente filtra ruido.

Por qué esto quita el sueño a los equipos pequeños y a los autónomos

Cuando manejas datos de otras personas (contratos de clientes, notas de salud, registros financieros, archivos fuente, documentos de recursos humanos), una brecha no es solo problema tuyo. Puede que debas una explicación a esas personas y, posiblemente, a una autoridad de control.

Según el RGPD, una violación de la seguridad de los datos personales puede obligarte a notificarla a tu autoridad de control (en general, en un plazo de 72 horas desde que tienes conocimiento de ella) y, cuando el riesgo para las personas es alto, a comunicarla también a los afectados. Ese es el principio; los umbrales y la redacción exactos están en el reglamento y en las guías de tu autoridad nacional, así que tómalo como orientación, no como un dictamen jurídico.

Esta es la parte que lo cambia todo, y donde el cifrado deja de ser una función de seguridad abstracta: las autoridades de control y sus guías suelen tratar los datos que se han vuelto ininteligibles para personas no autorizadas (por ejemplo, correctamente cifrados con claves que el atacante no tiene) de forma muy distinta a los datos que se han filtrado en claro. Un cifrado fuerte no borra por arte de magia todas las obligaciones, pero puede ser la diferencia entre «los datos expuestos son ilegibles para quien los robó» y «tenemos que decirles a 4000 clientes que sus contratos andan por ahí». Esa es la verdadera apuesta detrás de la aburrida expresión «quién tiene las claves».

La diferencia de fondo: dónde ocurre el cifrado y quién tiene la clave

Casi todos los servicios serios cifran los datos «en reposo». La expresión suena tranquilizadora y es discretamente engañosa. Significa que los datos están cifrados en los discos del proveedor, con claves que gestiona el proveedor. Protege contra alguien que robe físicamente un disco duro de un centro de datos. No protege contra una brecha en el propio proveedor, porque la misma infraestructura que sirve tus archivos también tiene las claves para descifrarlos.

El cifrado del lado del cliente invierte el orden. El archivo se cifra en tu dispositivo, con una clave derivada de tu contraseña, antes de que se escriba en el disco o se suba. El servicio, si lo hay, recibe algo que no puede leer. Es la propiedad que se llama cifrado zero-knowledge: el proveedor guarda tus datos, pero por su propia estructura es incapaz de descifrarlos.

Estas dos ideas, extremo a extremo y zero-knowledge, se usan como sinónimos y no son exactamente lo mismo; si quieres la distinción precisa, la desglosamos en cifrado de extremo a extremo vs zero-knowledge. Para analizar una brecha, el atajo que importa es sencillo: ¿tiene el servidor la clave en algún momento, sí o no?

Lo que expone una brecha, lado a lado

Escenario	Nube clásica (cifrada en reposo)	Cifrado local / del lado del cliente
Ataque a los servidores del proveedor	El atacante puede acceder a los archivos de forma legible si también accede a las claves	El atacante obtiene blobs cifrados opacos, inútiles sin tu contraseña
Empleado desleal o comprometido	Puede llegar a acceder al contenido (herramientas de soporte, paneles de administración)	No puede leer el contenido; las claves no están en el servidor en forma utilizable
Solicitud de una autoridad al proveedor	El proveedor puede verse obligado a facilitar datos legibles	El proveedor solo puede facilitar texto cifrado que no puede descifrar
Te roban el portátil	Depende del cifrado del disco; los datos de las apps pueden ser legibles	Los archivos siguen cifrados uno a uno; hace falta tu contraseña
Filtración de una copia de seguridad o de un bucket mal configurado	Se exponen documentos legibles	Se exponen blobs cifrados, no el contenido

Fíjate en las dos últimas filas. El cifrado del lado del cliente no es un escudo mágico: si tu portátil está desbloqueado y tu espacio de trabajo abierto, un atacante con acceso físico está dentro de tu perímetro de confianza. La protección es más fuerte justo donde la nube clásica es más débil, es decir, en el lado del servidor, el lugar que no controlas y no puedes auditar.

Pero ¿basta alguna vez con el cifrado «en reposo»?

A veces, sí, y aquí importa ser honestos. Si tu modelo de amenazas es el robo de un disco de un centro de datos o la pérdida de una cinta de copia de seguridad, el cifrado en reposo se encarga de ello. Si necesitas que los servidores del proveedor procesen activamente tu contenido (búsqueda de texto completo en sus servidores, funciones de IA, colaboración en el servidor, conversión de formatos), tienen que poder leerlo, y el cifrado del lado del cliente rompería esas funciones. Es un compromiso real, no una nota al pie de marketing. Muchos equipos lo aceptan a sabiendas.

El problema es que la mayoría de la gente nunca hizo ese compromiso de forma consciente. Dieron por hecho que «cifrado» significaba «la empresa no puede leer mis cosas», y con las herramientas en la nube clásicas esa suposición suele ser falsa. Notion, por ejemplo, cifra los datos en reposo pero no está cifrado de extremo a extremo y tiene las claves, algo que explicamos en detalle en ¿está Notion cifrado?.

Cómo es de verdad un buen cifrado del lado del cliente

No todas las apps «cifradas» son iguales, así que ayuda saber qué incluye un diseño serio. Las piezas que conviene comprobar:

Un cifrado autenticado fuerte. El estándar actual es AES-256-GCM, que cifra y además detecta las manipulaciones. Es la misma clase de primitiva que usan TLS, Signal y WireGuard.
Una jerarquía de claves sensata. La clave que cifra tus datos debe ser aleatoria y no guardarse nunca en claro: se envuelve con una clave derivada de tu contraseña, de modo que cambiar la contraseña vuelve a envolver una sola clave en lugar de volver a cifrarlo todo, y una copia robada de los datos del servidor no abre nada. Este enfoque de dos capas es el modelo KEK/FEK.
Una derivación de clave lenta. Tu contraseña debe estirarse con una función deliberadamente lenta para que forzarla salga caro. PBKDF2 con un número alto de iteraciones o Argon2id son las opciones habituales.
Una vía de recuperación que no devuelva la clave a un servidor. Una frase de recuperación escrita (al estilo BIP-39) significa que el respaldo eres tú, no el proveedor.

Si quieres el modelo mental completo de los modelos de amenazas y de cómo elegir una herramienta, cómo cifrar tus notas es un buen punto de partida práctico.

Lo que significa para ti, en concreto

Cambies o no algún día de herramientas, estos pasos reducen tu exposición el día en que se produzca una filtración:

Haz inventario de quién puede leer tus archivos sensibles. Para cada herramienta, hazle al proveedor una sola pregunta: ¿los archivos están cifrados de extremo a extremo o del lado del cliente, o solo «en reposo»? Si solo están cifrados en reposo, da por hecho que una brecha en ese proveedor expone contenido legible.
Activa el cifrado del disco completo en todos tus dispositivos (BitLocker en Windows, FileVault en macOS, LUKS en Linux). Es tu base para la fila del «portátil robado» de arriba, y es gratis.
Separa los datos muy sensibles. Los contratos de clientes, los historiales médicos y los documentos financieros merecen cifrado del lado del cliente, aunque tus notas generales no lo necesiten.
Guarda una copia local cifrada de todo lo crítico, para que una caída de un proveedor en la nube o un bloqueo de tu cuenta no te dejen también sin acceso a tu propio trabajo.
Apunta tu método de recuperación y guárdalo sin conexión. El cifrado del lado del cliente significa que nadie puede restablecer tu contraseña por ti, que es justo la idea, y también el riesgo.
Ten preparado un reflejo ante las brechas. Sabe quién es tu autoridad de control y, más o menos, en qué consiste tu obligación de notificación antes de necesitarlo, porque el plazo es corto.

Dónde encaja Filarr (y dónde no)

Filarr es un espacio de trabajo cifrado local-first: notas, archivos y un grafo que los conecta, todo cifrado en tu propio disco. En concreto, cada archivo se cifra por separado con AES-256-GCM con la clave de tu cuenta (la FEK), con un valor aleatorio nuevo para cada archivo; la FEK está envuelta por una clave (la KEK) derivada de tu contraseña con PBKDF2-SHA512 a 600 000 iteraciones (muy por encima de las 210 000 que recomienda OWASP para PBKDF2-SHA512). La recuperación es una frase BIP-39 de 24 palabras que guardas tú, no el servidor.

La sincronización en la nube es opcional. Cuando la activas, los archivos se suben ya cifrados y el backend solo guarda blobs opacos; la clave nunca le llega en claro. Así que, en los escenarios de brecha anteriores, una filtración del almacenamiento de sincronización de Filarr expone texto cifrado, no tus documentos. Si quieres conocer la mecánica exacta, recorrimos el código en cómo la sincronización en la nube de Filarr sigue siendo zero-knowledge, y toda la arquitectura defensiva está documentada en la seguridad de Filarr, capa por capa.

Lo que Filarr no hace, dicho con claridad:

No te hace cumplir el RGPD. El cifrado es una medida técnica; el cumplimiento depende de todo tu tratamiento, tus contratos, tus plazos de conservación y tu base jurídica. Una herramienta no puede certificártelo.
No protege un espacio de trabajo desbloqueado y abierto en un equipo comprometido. El cifrado del lado del cliente protege los datos en reposo y en tránsito, no una sesión que has dejado abierta.
Es más joven que Obsidian o Notion, con un ecosistema de plugins más pequeño y una app móvil que solo existe en Android, desde octubre de 2026. Si hoy necesitas una tienda madura de extensiones, es una carencia real.

El argumento honesto es acotado: si lo que te preocupa es concretamente «qué se filtra cuando atacan a mi proveedor», el cifrado del lado del cliente cambia la respuesta de «los documentos de mis clientes» a «ruido ilegible», y ahí está toda la cuestión.

Preguntas frecuentes

Si un servicio cifra los datos «en reposo», ¿no están mis datos a salvo en una brecha? No necesariamente. El cifrado en reposo protege contra el robo de discos físicos, pero el proveedor tiene las claves, así que una brecha en los sistemas en funcionamiento del proveedor, un empleado desleal o una solicitud de una autoridad todavía pueden exponer contenido legible. El cifrado del lado del cliente es lo que mantiene el contenido ilegible para el propio proveedor.

¿El cifrado me libra de la obligación de notificar una brecha según el RGPD? No, pero puede cambiar la evaluación del riesgo. Las guías suelen tratar los datos que eran ininteligibles para el atacante (correctamente cifrados, sin claves comprometidas) de forma más favorable que los datos filtrados en claro, lo que puede influir en si hay que comunicarlo a los afectados. Es una orientación, no asesoramiento jurídico; consulta las guías de tu autoridad nacional para tu situación.

¿Cuál es la pega del cifrado del lado del cliente? Dos cosas. El proveedor no puede ofrecer funciones que necesiten leer tu contenido (búsqueda en el servidor, IA sobre tus datos, parte de la colaboración), y nadie puede recuperar tu cuenta si pierdes tu contraseña y tu frase de recuperación. Cambias comodidad y una red de seguridad por la garantía de que el proveedor no puede leer tus datos.

¿Local-first es lo mismo que solo sin conexión? No. Local-first significa que tus datos viven en tu dispositivo y funcionan por completo sin conexión, pero puedes seguir sincronizando entre dispositivos. La diferencia con la nube clásica es que la sincronización es opcional y, bien hecha, solo transporta blobs cifrados que el servidor no puede leer.

Me pueden seguir robando el portátil. ¿Sirve de algo el cifrado en ese caso? Sí, en parte. Los archivos cifrados uno a uno más el cifrado del disco completo hacen que un ladrón con el equipo apagado se encuentre con tu contraseña, no con tus documentos. Lo que no protege es un dispositivo desbloqueado con tu espacio de trabajo ya abierto, y por eso siguen importando los hábitos a nivel del dispositivo.