Audit RGPD e registro degli accessi
betool è costruito per soddisfare i requisiti del RGPD senza conformità aggiunta a posteriori: ogni accesso al contenuto di un utente da parte di un agent appartenente a un'altra organizzazione viene registrato, e ogni organizzazione può consultare il proprio registro.
Il registro degli accessi
Una tabella dedicata registra, per ogni accesso cross-tenant:
- Il timestamp (precisione al microsecondo)
- L'org destinataria (il cui contenuto è stato letto)
- L'org lettrice (tipicamente il vendor)
- Il ruolo / agent / utente che ha effettuato la lettura
- Il tipo di entità (vocabolario chiuso:
exchange_text,knowledge_chunk,audio_segment…) - L'ID dell'entità
- Il contesto d'uso (missione, ticket, proposta)
Il vocabolario delle entità è chiuso a livello di database (vincolo CHECK) e chiuso a livello di codice (whitelist applicativa). Aggiungere un tipo richiede una nuova migrazione più l'aggiornamento della whitelist. Nessuna voce a sorpresa.
Diritto di accesso (Articolo 15)
Ogni organizzazione può consultare I PROPRI registri di accesso tramite:
GET /api/admin/me/content-reads
Filtri disponibili: intervallo temporale, tipo di entità, ID dell'entità, identità lettrice. Esportazione CSV / Excel per la condivisione con un responsabile della protezione dei dati.
Nessun accesso cross-org al registro di audit: il vendor non vede mai i registri di audit di un cliente.
Diritto alla cancellazione (Articolo 17)
Sono supportati tre livelli di cancellazione:
- Cancellazione utente — un utente finale richiede la cancellazione dei propri dati all'interno di un'organizzazione cliente. L'organizzazione avvia la cancellazione tramite il pannello di amministrazione o l'API di amministrazione.
- Cancellazione dell'organizzazione — un'organizzazione lascia betool. Tutte le sue risorse vengono eliminate: tabelle filtrate per
org_id, storage dei file svuotato, segreti rimossi. Finestra contrattuale predefinita: 30 giorni per il ripensamento, poi svuotamento irreversibile. - Cancellazione legale — su ordine del tribunale, cancellazione di elementi specifici senza toccare il resto. Registrata nella traccia di audit con un riferimento alla base giuridica.
Opt-in e opt-out della lettura cross-tenant
Per impostazione predefinita, l'opt-in di lettura cross-tenant è impostato su FALSE. Un'organizzazione può abilitarlo in Amministrazione → Privacy → Lettura cross-tenant.
Tre modalità:
- Rifiuto totale — predefinito. Il vendor non può accedere a nessun contenuto di questa org. Conseguenza: non è possibile alcun supporto cross-org a livello di contenuto (restano disponibili il supporto strutturale e i flag di business).
- Opt-in temporaneo — autorizzazione per una finestra temporale definita, revocabile.
- Opt-in permanente — per i clienti che desiderano un supporto proattivo (raro nel settore bancario, comune nel SaaS standard).
Il vendor NON PUÒ attivare questo opt-in per conto del cliente. Questo è un test fondamentale: se il vendor può attivarlo senza un'azione del cliente, l'architettura è compromessa.
Garanzia sulle operazioni distruttive
Qualsiasi operazione che distrugge o sostituisce contenuti (DELETE, REPLACE-IN-PLACE) è rifiutata al validatore se l'org destinataria non ha attivato l'opt-in di lettura. Motivazione: senza visibilità, l'operatore proporrebbe un payload che potrebbe sovrascrivere ciecamente contenuti esistenti.
Negazione a cascata se l'audit non è disponibile
Se il database di audit non è disponibile (incidente infrastrutturale), tutte le letture cross-tenant sono rifiutate. Politica rigorosa: nessuna lettura senza traccia.
Conseguenza lato codice: un chiamante che intercetta un'eccezione deve ri-sollevare l'errore di audit prima di qualsiasi elaborazione di business. Questo è un invariante verificato dal benchmark di sicurezza.
Cookie di consenso
Sul sito marketing e sul chat widget vengono impostati soltanto i cookie strettamente necessari. Nessun cookie di analytics di terze parti senza un banner di consenso conforme.