Un estudio de abogados maneja, por definición, información confidencial: datos personales, estrategias procesales, documentos de clientes. Cuando esa información vive en la nube, la pregunta no es "¿están seguros mis datos?" sino "¿cómo, exactamente?". Este artículo abre la caja: las capas concretas de seguridad de Legio, sin marketing.
El principio: cada estudio ve solo lo suyo
Legio es multi-inquilino: muchos estudios comparten la misma infraestructura, pero nadie puede ver los datos de otro. Esto no se logra "teniendo cuidado en el código" —se logra con barreras que el sistema no puede saltear aunque el código tenga un bug.
RLS: la base de datos se defiende sola
La primera barrera es RLS (Row Level Security), una función de PostgreSQL. Cada tabla
—contactos, expedientes, documentos, agenda— tiene políticas que filtran las filas a nivel
de motor de base de datos: una consulta solo devuelve las filas que pertenecen a las
organizaciones del usuario que pregunta. No es un WHERE que el programador podría olvidar:
es una regla que la base aplica a toda consulta, siempre.
En Legio, esas políticas se apoyan en una función que devuelve las organizaciones del
usuario autenticado, y comparan contra el organization_id de cada fila. Si un usuario del
Estudio A intenta leer un contacto del Estudio B, la base devuelve cero filas. No hay
mensaje de error que filtre información, no hay "casi": simplemente no existe para él.
Aislamiento en el asistente de IA
El asistente de IA es poderoso: puede leer y crear contactos, expedientes y documentos. Por eso es el punto donde el aislamiento importa más. La regla de oro: el servidor nunca le cree al navegador quién sos.
Cada pedido al backend viaja con un token de sesión (JWT) firmado por el sistema de autenticación. El backend valida ese token y deriva de él la identidad del usuario y su organización. Aunque alguien manipulara el pedido para pedir datos de otro estudio, el servidor ignora lo que venga en el cuerpo del mensaje y usa solo lo que el token —firmado y verificable— afirma. Esta verificación se aplica en todas las rutas del backend, no solo en el chat.
Los secretos: lo que nunca se expone
Una aplicación tiene "llaves" (claves de API, claves de base de datos) que jamás deben llegar al navegador ni a un repositorio público. En Legio:
- Las claves con privilegios (la que puede saltear RLS, las de los modelos de IA) viven solo en el servidor, en variables de entorno, nunca en el código que se descarga al navegador.
- El navegador solo recibe una clave pública por diseño (limitada por RLS), pensada exactamente para eso.
- Los archivos con secretos están excluidos del control de versiones, y el sistema avisa si detecta una configuración insegura.
El cifrado: ilegible incluso para nosotros
El cuerpo de los documentos generados por IA —escritos, demandas, borradores— se guarda
cifrado en la base de datos con algoritmo AES, vía la extensión pgcrypto de PostgreSQL.
El detalle importante es dónde vive la llave: en una bóveda de secretos dentro de la
propia base (Supabase Vault), generada por la base y que nunca aparece en el código, ni en
la configuración, ni en este repositorio. Si alguien obtuviera una copia de la columna
cifrada, vería texto ininteligible —algo como enc:v1:ww0EBwMC…— sin forma de leerlo.
¿Por qué solo algunos campos y no todo? Porque cifrar rompe la búsqueda: un nombre cifrado no se puede buscar con "contiene Pérez". La decisión de ingeniería es cifrar lo confidencial y voluminoso (cuerpos de documentos) y dejar en claro lo que el abogado necesita buscar rápido (nombres, números de expediente), que de todos modos está protegido por RLS y por el cifrado en reposo de la infraestructura.
Los documentos: bajo llave
Los archivos que se suben (escaneos de DNI, contratos, pruebas) viven en almacenamiento privado. No son accesibles con un link público: para abrir uno hay que estar autenticado y el sistema genera un enlace firmado y temporal cada vez. Un documento de un cliente no se puede compartir "sin querer" pegando una URL.
Las puertas de entrada: control de tráfico
- CORS: el backend solo acepta pedidos desde los dominios propios de Legio. Una página de un tercero no puede llamar a nuestra API desde el navegador de un usuario.
- Rate limiting: hay un límite de pedidos por minuto. El asistente de IA, que consume más recursos, tiene un límite más estricto. Esto frena abusos, fuerza bruta y scraping.
- Sanitización de entradas: los términos de búsqueda se limpian antes de tocar la base, para que nadie pueda inyectar condiciones que alteren una consulta.
Honestidad sobre el modelo
Ninguna seguridad es "absoluta", y desconfiá de quien diga lo contrario. Lo que ofrecemos es defensa en capas: para que se filtre un dato tendrían que fallar varias barreras independientes a la vez —el token, RLS, el cifrado, los permisos de archivos—. Y seguimos midiendo: revisamos periódicamente los advisors de seguridad de la base, rotamos claves y endurecemos lo que haga falta.
En resumen
La privacidad en Legio no es una promesa, es una arquitectura: RLS que aísla cada estudio a nivel de base de datos, identidad verificada por token en todo el backend, secretos que nunca tocan el navegador, cifrado de los documentos sensibles con la llave fuera del alcance, almacenamiento privado con enlaces firmados, y control de tráfico en cada puerta. Tus datos son tuyos —y la ingeniería está hecha para que siga siendo así aunque algo, en algún lado, falle.