Auditoría RGPD y registro de accesos
betool está construido para cumplir los requisitos del RGPD sin conformidad añadida a posteriori: cada acceso al contenido de un usuario por parte de un agente perteneciente a otra organización se registra, y cada organización puede consultar su propio registro.
El registro de accesos
Una tabla dedicada registra, para cada acceso cross-tenant:
- La marca de tiempo (precisión de microsegundo)
- La organización de destino (cuyo contenido se leyó)
- La organización lectora (normalmente el proveedor)
- El rol / agente / usuario que realizó la lectura
- El tipo de entidad (vocabulario cerrado:
exchange_text,knowledge_chunk,audio_segment…) - El ID de la entidad
- El contexto de uso (misión, ticket, propuesta)
El vocabulario de entidades está cerrado a nivel de base de datos (restricción CHECK) y cerrado a nivel de código (lista blanca de la aplicación). Añadir un tipo requiere una nueva migración más la actualización de la lista blanca. Sin entradas sorpresa.
Derecho de acceso (artículo 15)
Cada organización puede consultar SUS PROPIOS registros de acceso mediante:
GET /api/admin/me/content-reads
Filtros disponibles: rango temporal, tipo de entidad, ID de entidad, identidad lectora. Exportación CSV / Excel para compartir con un delegado de protección de datos.
Sin acceso cross-tenant al registro de auditoría: el proveedor nunca ve los registros de auditoría de un cliente.
Derecho de supresión (artículo 17)
Se admiten tres niveles de supresión:
- Supresión de usuario — un usuario final solicita la eliminación de sus datos dentro de una organización cliente. La organización activa la supresión desde el panel de administración o la API de administración.
- Supresión de organización — una organización abandona betool. Se eliminan todos sus recursos: tablas filtradas por
org_id, almacenamiento de archivos purgado, secretos eliminados. Ventana contractual por defecto: 30 días para la retractación, luego purga irreversible. - Supresión legal — por orden judicial, eliminación de elementos concretos sin tocar el resto. Registrada en la pista de auditoría con una referencia a la base legal.
Opt-in y opt-out de lectura cross-tenant
Por defecto, el opt-in de lectura cross-tenant está fijado en FALSE. Una organización puede activarlo en Administración → Privacidad → Lectura cross-tenant.
Tres modos:
- Rechazo total — por defecto. El proveedor no puede acceder a ningún contenido de esta organización. Consecuencia: no es posible ningún soporte cross-tenant a nivel de contenido (el soporte estructural y los indicadores de negocio siguen disponibles).
- Opt-in temporal — autorización durante una ventana de tiempo fija, revocable.
- Opt-in permanente — para clientes que desean soporte proactivo (raro en banca, común en SaaS estándar).
El proveedor NO PUEDE activar este opt-in en nombre del cliente. Esta es una prueba fundamental: si el proveedor puede activarlo sin una acción del cliente, la arquitectura está rota.
Salvaguarda de operaciones destructivas
Cualquier operación que destruya o reemplace contenido (DELETE, REPLACE-IN-PLACE) se rechaza en el validador si la organización de destino no ha activado el opt-in de lectura. Motivo: sin visibilidad, el operador estaría proponiendo un payload que podría sobrescribir a ciegas el contenido existente.
Denegación en cascada si la auditoría no está disponible
Si la base de datos de auditoría no está disponible (incidente de infraestructura), todas las lecturas cross-tenant se rechazan. Política estricta: sin lectura sin rastro.
Consecuencia del lado del código: un llamador que capture una excepción debe volver a lanzar el error de auditoría antes de cualquier procesamiento de negocio. Es un invariante verificado por el benchmark de seguridad.
Cookies de consentimiento
En el sitio de marketing y el widget de chat, solo se establecen cookies estrictamente necesarias. Sin cookies de analítica de terceros sin un banner de consentimiento conforme.