Path isolato.
Ogni tenant ha il suo path di storage. I documenti di un tenant non sono tecnicamente raggiungibili da un altro: il filtro tenant è applicato a livello di accesso, non solo di query.
Multi-tenant con storage isolato, ruoli e permessi granulari, audit log immutabile, autenticazione a due fattori, SSO via Microsoft e Google. Meccanismi standard, applicati con rigore.
// 01Multi-tenant
Multi-tenant
con storage isolato.
Ogni organizzazione vive nel proprio tenant: storage isolato, configurazione AI separata, utenti distinti, knowledge layer indipendente. Niente leakage cross-tenant — è una garanzia architetturale, non una regola applicativa che qualcuno può bypassare.
Setup separato.
Ogni tenant configura il suo: connettori AI, modelli, cap token, visibility mode del knowledge layer, asset type, entity type, categorie. Nessuna contaminazione fra impostazioni.
Identità distinte.
Lo stesso indirizzo email può appartenere a tenant diversi (collaborazioni, consulenti). Ogni appartenenza è esplicita, con il suo set di ruoli e permessi nel tenant ospitante.
// 02Roles e
Roles e
permessi granulari.
Ruoli DAM definiti dall'admin, ognuno con un set di permessi su: visualizzazione, modifica, gestione asset; accesso amministrazione DAM; accesso all'audit log. Ogni utente ha un ruolo per tenant.
ruoli · esempio
Admin DAM
tutti i permessivieweditmanageadminaudit
Editor
scrive sugli assetviewedit
Viewer
sola letturaview
Auditor (custom)
solo auditviewaudit
// 03Audit log
Audit log
immutabile.
Ogni azione rilevante finisce in audit log: workflow (approvazioni, version bump), system event (creazione tenant, configurazione), user action (login, download, share, accessi a documenti). Nessun evento può essere modificato dopo il fatto.
audit log · ultimi eventi
workflowsystemuser_action
- 14:32:08workflowapprove · stage 1 · contratto-acme-rinnovo · v3m.crocchiolo
- 14:30:12user_actiondownload · contratto-acme-rinnovo · v3m.crocchiolo
- 14:28:45workflowversion_bump · v2 → v3 · "SLA aggiornato"m.crocchiolo
- 14:25:01user_actionshare_created · asset 142 · scadenza 7 giornib.lombardini
- 14:18:22systemconfig_change · knowledge_layer · cap token raisedadmin@theka
- 14:11:09user_actionlogin · MFA verifiedb.lombardini
filtrabile per utente · tipo · oggetto · range temporale
// 04MFA, SSO, email
MFA, SSO, email
verification.
Login locale con email + password verificata. SSO via OAuth Microsoft e Google (sia per autenticazione utente sia per connessione organization). MFA disponibile come step di verifica aggiuntivo.
Verifica secondo fattore.
Endpoint /auth/mfa-verify per la verifica MFA. Configurabile come obbligatorio per il tenant o per i ruoli admin.
Microsoft e Google.
OAuth per login utente, OAuth per connessione organization. Le credenziali rimangono sull'identity provider — Theka non vede mai password.
MicrosoftGoogle
Email confermata.
Login locali richiedono email verification prima di poter accedere a tenant attivi. Niente account fantasma con indirizzi non controllati.
// 05Approval come
Approval come
governance.
Il workflow di approvazione (vedi Asset) non è solo organizzativo: è uno strumento di governance. Un documento signed ha attraversato i suoi stage con approvazioni tracciate. L'audit log lo dimostra.
Riprodurre la storia.
Per ogni asset arrivato a final o signed puoi ricostruire passo passo: chi ha caricato cosa, chi ha approvato in quale stage, con quale commento, in che data. Tutto in audit log.
Anche le risposte
AI lasciano traccia.
Ogni interazione con la chat AI — domanda, risposta, fonti citate — è registrata in audit log. L'utilizzo dell'AI resta quindi pienamente tracciabile: chi ha chiesto cosa, chi ha visto cosa, in che momento.
// contattoValutiamo Theka
Valutiamo Theka
sul vostro archivio.
Una call di 30 minuti per una demo guidata e una valutazione preliminare di idoneità al vostro contesto operativo.