Devhook S.r.l.Trattamento dei dati
Questo documento descrive quali dati il gestionale interno di Devhook S.r.l. tratta, dove vivono e verso quali fornitori escono. È un documento tecnico di trasparenza, mantenuto insieme al software e aggiornato a ogni versione che cambia un flusso di dati.
Non sostituisce l'informativa privacy ai sensi degli articoli 13 e 14 del GDPR, che è un documento legale separato.
Dove vivono i dati
- Database e documenti: Supabase (PostgreSQL), regione Unione Europea — Francoforte. Ogni tabella ha Row Level Security: la lettura e la scrittura sono riservate agli amministratori dell'organizzazione.
- Applicazione: server dedicato (VPS Hostinger) sul dominio devcore.vision, raggiungibile solo via HTTPS.
- Nessun dato sanitario di pazienti viene mai caricato nel sistema: è una regola di progetto, non una preferenza.
Chi può accedere
- Gli amministratori, con email e password più autenticazione a due fattori obbligatoria (TOTP), verificata sui dispositivi sconosciuti.
- Gli account ospite creati per le cartelle condivise vedono e caricano documenti SOLO nella cartella condivisa con loro: non hanno accesso al resto del gestionale e non possono modificare né eliminare nulla. L'accesso si revoca in un clic.
- Ogni scrittura significativa lascia una riga nel registro attività: chi, cosa, quando.
Fornitori che ricevono dati
Questi sono tutti i servizi esterni verso cui il gestionale invia dati. L'elenco corrisponde alle integrazioni presenti nel codice.
| Fornitore | Cosa riceve | Perché | Usato per addestrare l'AI |
|---|---|---|---|
| Anthropic — API Claude | testo delle comunicazioni, documenti allegati ai clienti (PDF e immagini), pagine del Second Brain, dati del team usati nelle valutazioni; per la sincronizzazione email: metadati e i primi 2.000 caratteri del corpo ripulito — mai gli allegati, mai il corpo integrale; messaggi della chat Slack interna del team | analisi clienti e prodotti, assistente documentale, riassunti, lettura delle fatture, sintesi della conoscenza, traduzioni, estrazione di proposte dalle email, distillazione della chat Slack in note e task suggerite | No |
| Voyage AI (MongoDB) | testo di pagine di conoscenza, comunicazioni (incluse quelle approvate dalla revisione email) e post-mortem | indice semantico per la ricerca «situazioni simili» | No |
| claude.ai — connettore MCP | i risultati dei tool richiamati durante una chat (pagine, comunicazioni, timeline cliente, storico offerte) | consultare il Second Brain dalle conversazioni Claude | Dipende dall'account |
| Telegram | nome del destinatario e testo del promemoria | notifiche e solleciti sulle task | Non applicabile |
| Fatture in Cloud | dati di fatture e registrazioni contabili | contabilità e riconciliazione dei movimenti | Non applicabile |
| Revolut Business | movimenti e saldi dei conti (sola lettura) | cassa, previsioni e riconciliazione bancaria | Non applicabile |
| Hostinger Mail | messaggi delle caselle collegate: via API per la contabilità, via IMAP in sola lettura per la sincronizzazione email per-utente | import delle fatture ricevute; sincronizzazione email con proposte soggette a revisione umana | Non applicabile |
Le funzioni AI, in concreto
- Le chiamate AI del gestionale passano dall'API di Anthropic con una chiave aziendale: i termini commerciali dell'API escludono l'uso di input e output per l'addestramento dei modelli.
- Fa eccezione il connettore MCP verso claude.ai: lì la conversazione segue le impostazioni privacy dell'account che la apre, non quelle dell'API. Chi usa il connettore dovrebbe verificarle.
- Ogni chiamata interattiva è limitata (trenta all'ora per l'organizzazione) e registrata nel registro attività con modello e token consumati.
- Sui clienti con la «redazione dati» attiva, i documenti sono esclusi dal contesto inviato all'AI.
- Il modello propone, la persona approva: le pagine di conoscenza non vengono mai pubblicate senza revisione umana.
- La policy di Voyage AI sull'addestramento è stata verificata: i dati inviati per l'indice semantico non vengono usati per addestrare modelli.
La sincronizzazione email, in concreto
- Ogni amministratore collega la propria casella Hostinger via IMAP, in sola lettura: nessuna email viene mai marcata come letta, e ciascuno vede esclusivamente la propria posta.
- La password della casella è cifrata nel Vault di Supabase e viene decifrata solo sul server, il tempo di aprire la connessione: non transita mai verso il browser e non compare nei log.
- Si sincronizzano solo le cartelle scelte esplicitamente (whitelist). Qualunque cartella con «No Sync» nel nome è rifiutata alla radice: è il posto della posta che non deve uscire dall'infrastruttura, per scelta e procedura concordata.
- All'AI passano solo metadati, i primi 2.000 caratteri del corpo ripulito e i nomi degli allegati — mai il contenuto dei file, mai il corpo integrale.
- Il modello propone, la persona approva: nulla diventa comunicazione, task, documento o nota senza approvazione esplicita nella Revisione email. Le email grezze restano per-utente e fuori dall'indice semantico condiviso: nell'indice entra solo ciò che è stato approvato.
- Gli allegati vivono in uno staging privato e temporaneo: vengono promossi al Drive solo su approvazione, altrimenti la pulizia automatica li rimuove (scartati subito, gli altri dopo 60 giorni a proposte chiuse).
Cosa non facciamo
- Nessun dato sanitario di pazienti entra nel sistema.
- Le chiavi di servizio del database, che aggirerebbero le regole di accesso, non sono presenti in produzione.
- Il codice del gestionale è in un repository privato.
- I promemoria WhatsApp non passano da alcun server: aprono l'applicazione col messaggio già scritto e l'invio parte dal telefono di chi lo manda.
Per esercitare i diritti previsti dal GDPR o per chiarimenti: devhook@pec.it
Torna all'accessov2.93.0