Seguridad de los datos

1. Arquitectura y dónde viven los datos

Los datos del cliente viven en una base PostgreSQL administrada por Supabase sobre Amazon Web Services, región San Pablo (sa-east-1). Ningún componente que procesa datos corre fuera de Brasil, salvo el asistente de IA, que recibe sólo resúmenes (sección 5).

Certificaciones de los proveedores. Supabase tiene el informe SOC 2 Tipo 2, ISO 27001 y cumplimiento HIPAA. Son de Supabase como empresa; ADN no tiene certificaciones propias.

¿Por qué Supabase y no AWS directo? Los datos ya están en AWS. Supabase agrega encima la autenticación con MFA, el aislamiento por empresa en la base (Row Level Security), el depósito de secretos (Vault) y el almacenamiento privado de archivos. En AWS «puro» cada una de esas piezas se construye a mano. Si la política del cliente exige una base propia en su cuenta de AWS, es PostgreSQL estándar y se puede migrar.

2. Capas bronce, plata y oro

El dato recorre tres capas (arquitectura medallón) y el usuario sólo ve la última, y sólo cuando está certificada.

Antes de bronce, una zona de prueba aislada. Cada carga pasa 9 controles: filas perdidas, facturas o asientos duplicados, asientos que no balancean, balance que no cuadra, fechas imposibles y clientes desconocidos. Si falla, queda bloqueada con el motivo a la vista y no toca lo certificado.

Nada cambia una cifra sin aprobación humana. Un administrador de la empresa cliente aprueba el pase a los números, con segundo factor, y la aprobación queda en el registro de auditoría.

Cómo lo impone la base, no la web. Las tablas de oro tienen Row Level Security con dos políticas: una que deja leer sólo corridas certificadas y otra, restrictiva, que exige sesión con segundo factor (nivel aal2). Las vistas que consume la web son security_invoker y heredan ese filtro.

3. Acceso y aislamiento entre empresas

Cada fila de la base lleva su empresa, y es la base la que impide cruzarla: una prueba que entra como otra empresa por todos los caminos devuelve cero filas.

Acuerdo de confidencialidad y protección de datos. Antes de recibir cualquier dato, ADN firma con el cliente un acuerdo de confidencialidad y de tratamiento de datos personales, en el marco de la Ley 25.326.

Personal de ADN. Sólo quienes trabajan en la cuenta del cliente, con usuario propio, MFA y registro de actividad, igual que los usuarios del cliente, y con obligación de secreto.

4. Cuarentena y antivirus de archivos

Todo archivo que sube el cliente queda en cuarentena y pasa validación de formato y antivirus antes de que cualquier proceso lo lea.

1. Cuarentena. El archivo se guarda en un almacenamiento privado aparte. Ningún proceso lo abre todavía.
2. Validación por contenido, no por extensión. Sólo .xlsx sin macros y CSV, con tamaño máximo. Se rechazan archivos con macros (.xlsm), con otros archivos embebidos, protegidos con contraseña o que se inflan al descomprimir (zip bomb).
3. Antivirus. ClamAV, con la base de firmas actualizada cada semana, corriendo en el servicio de cargas de Cloud Run. Un archivo infectado se borra y queda rechazado con el nombre de la firma detectada.
4. Zona de prueba. Recién entonces el archivo entra a la carga aislada con sus 9 controles (sección 2).

Cómo se comprueba. En cada cambio de código, una prueba automática confirma que el antivirus detecta el archivo de prueba estándar EICAR. El 31/10/2026 se probó con un Excel real de Odoo: pasó el antivirus y entró a la zona de prueba en unos 90 segundos.

Lo que no se hace: nunca se envían archivos de clientes a servicios como VirusTotal, que comparten lo que reciben con terceros.

El servicio de cargas, por dentro. Sin endpoint público; credenciales en Google Secret Manager, legibles sólo por el servicio; usuario de base propio con privilegios mínimos, sin acceso de lectura ni escritura a las cifras certificadas; despliegue sin contraseñas guardadas, aceptado sólo desde el repositorio de ADN.

Pendiente el mismo circuito para archivos que llegan adjuntos por mail.

5. Inteligencia artificial, auditoría y salida

Qué ve la IA. El asistente lee sólo vistas resumidas de la capa oro, nunca el dato crudo del ERP ni datos personales. Una prueba automática falla si alguien agrega a esas vistas una columna con datos personales. Para proponer cómo leer un archivo nuevo, recibe sólo nombres y formato de columnas, nunca valores. Debajo de cada respuesta, «Qué vio el asistente» muestra el texto exacto que se envió.

Proveedor de IA. API de Anthropic (Estados Unidos). Según sus condiciones comerciales, no puede entrenar modelos con el contenido recibido por la API y lo borra dentro de los 30 días, salvo lo marcado por posible violación de su política de uso (hasta 2 años). Anthropic tiene ISO 27001, ISO/IEC 42001 y SOC 2 Tipo I y II.

Registro de auditoría inalterable. Registra ingresos (con o sin MFA), hojas consultadas, descargas, exportaciones, preguntas al asistente y mails enviados. Cada fila lleva el hash de la anterior: si una se modifica o borra, la cadena se corta en ese punto exacto.

Si el cliente se va. Recibe una exportación completa, un archivo por tabla, con un manifiesto de cantidad de filas y hash de cada archivo. Después se borra todo y se entrega una constancia con el antes y el después en cero. Se conserva sólo el registro de auditoría, con plazo a definir.

Revisión externa. Pendiente revisión de un técnico independiente prevista para el 30/11/2026. Hasta entonces, las revisiones son internas: el asesor de seguridad de Supabase y las pruebas automáticas.