Accordo sul trattamento dei dati personali (DPA) — SophiaTerra

⚠️ BOZZA TECNICA. NON È ANCORA IN VIGORE E NON PRODUCE EFFETTI FRA LE PARTI. Questo testo è stato scritto leggendo il codice del prodotto, per dare a un consulente privacy una base concreta su cui lavorare: descrive quello che il software fa davvero, non quello che sarebbe comodo poter dichiarare. Non è stato validato da un legale, non è stato sottoscritto e nessuno lo ha ancora accettato. I punti IN MAIUSCOLO sono lacune note: vanno colmate o verificate prima di proporlo a un cliente. Fino ad allora il trattamento resta regolato dai Termini di Servizio e dall'Informativa sulla privacy.

Accordo ai sensi dell'art. 28, par. 3, del Regolamento (UE) 2016/679 ("GDPR").

Versione: bozza 1 — 31 agosto 2026.

Premessa — le parti, l'oggetto del rapporto, come si accetta

Responsabile del trattamento (chi eroga il servizio): Azienda Agricola Obletter Giovanni Battista — impresa individuale, che opera il servizio con il marchio "SophiaTerra".

• Sede: Via Sicilia 2/a, frazione Villanova, 65012 Cepagatti (PE), Italia
• P.IVA: IT02773610692 — Codice Fiscale: BLTGNN96H13C632L — REA: PE 424009
• Email: info@sophiaterra.com — PEC: gb.obletter@pec.it
• Non è stato nominato un DPO: non ricorrono i casi di nomina obbligatoria dell'art. 37 GDPR.

Titolare del trattamento (il cliente): l'impresa o il professionista che apre un'azienda ("organizzazione") su SophiaTerra e vi immette dati. Il Titolare è identificato dai dati forniti in registrazione e in onboarding — denominazione, codice fiscale e/o partita IVA, sede, indirizzo email di riferimento — che valgono, ai fini di questo accordo, come sue coordinate contrattuali.

Perché serve. Il cliente decide quali dati caricare e a che scopo: è lui il Titolare. SophiaTerra li elabora per suo conto e secondo le sue istruzioni: è il Responsabile. L'art. 28 GDPR richiede che questo rapporto sia regolato per iscritto. Questo documento è quel contratto.

Come si accetta — DA IMPLEMENTARE. Alla data odierna il modulo di registrazione non raccoglie un'accettazione esplicita di questo accordo e non registra da nessuna parte chi lo ha accettato, quando, e in quale versione. Serve: (a) una spunta separata in fase di registrazione o al primo accesso; (b) una riga salvata con utente, azienda, data/ora e versione del testo accettato; (c) la conservazione delle versioni precedenti. FINCHÉ QUESTO NON ESISTE, L'ACCORDO NON RISULTA CONCLUSO CON NESSUN CLIENTE.

Rapporto con gli altri documenti. Questo accordo integra i Termini di Servizio. In caso di contrasto su come vengono trattati i dati personali, prevale questo accordo. L'Informativa sulla privacy e la Cookie Policy riguardano i trattamenti in cui SophiaTerra è titolare autonomo (dati di registrazione, fatturazione, contatti dal sito): sono un'altra cosa e restano valide per la loro parte.

1. Oggetto, durata, natura e finalità del trattamento

1.1 Oggetto. Il trattamento dei dati personali che il Titolare, i suoi utenti autorizzati e i connettori che il Titolare collega immettono nel servizio SophiaTerra.

1.2 Natura delle operazioni. Raccolta, registrazione, organizzazione, strutturazione, conservazione, consultazione, estrazione, elaborazione mediante un modello di intelligenza artificiale, comunicazione ai sub-responsabili elencati al §6, cancellazione.

1.3 Finalità. Esclusivamente l'erogazione del servizio come descritto nei Termini: organizzare i dati dell'azienda, rispondere alle domande dell'utente tramite l'agente "Sophia", produrre documenti e riepiloghi, e far funzionare i connettori che il Titolare attiva. Nessun'altra.

In particolare il Responsabile non usa i dati del Titolare per finalità proprie, non li cede a terzi diversi dai sub-responsabili del §6, non li usa per addestrare modelli. Sul lato del fornitore del modello, i termini commerciali dell'API di Anthropic prevedono che i contenuti trasmessi non siano usati per addestrare i modelli (come già dichiarato nella privacy policy): VERSIONE E DATA DEI TERMINI COMMERCIALI SU CUI SI FONDA QUESTA AFFERMAZIONE DA ALLEGARE.

1.4 Come funziona, in concreto. Per rispondere a una richiesta, il servizio trasmette ad Anthropic il testo della domanda, la parte di dati aziendali necessaria a rispondere e i documenti che l'utente allega in quella conversazione. I PDF che non contengono testo estraibile (le scansioni) e le immagini vengono trasmessi integralmente al modello, non solo il testo che se ne ricava.

Quando la domanda lo richiede, il modello può inoltre usare gli strumenti che il fornitore esegue sulla propria infrastruttura: una ricerca sul web, il recupero della pagina trovata e un ambiente di calcolo. Le parole della ricerca le formula il modello a partire dalla domanda e dai dati che ha davanti, quindi possono contenere dati del Titolare; insieme alla ricerca viene trasmessa anche una localizzazione approssimativa ricavata dall'anagrafica dell'azienda — paese, regione e comune — per ottenere risultati pertinenti. Per un'impresa individuale il comune della sede coincide di norma con il domicilio del titolare (cfr. §6.6). Questi tre strumenti non sono attivi nell'analisi dei documenti caricati, che gira in modalità ridotta. DI QUALI FORNITORI SI SERVA ANTHROPIC PER LA RICERCA SUL WEB, E CON QUALI GARANZIE, NON È STATO VERIFICATO: DA CHIARIRE CON IL SUO ACCORDO EX ART. 28.

1.5 Nessuna decisione automatizzata. Il servizio non adotta decisioni basate unicamente su un trattamento automatizzato che producano effetti giuridici o incidano in modo analogo significativo sugli interessati (art. 22 GDPR). Le risposte di Sophia hanno natura informativa e le decisioni restano del Titolare.

1.6 Durata. Dall'accettazione fino alla cessazione del contratto di servizio, e per il tempo ulteriore previsto al §9 per la restituzione o la cancellazione. Le clausole che per loro natura devono sopravvivere (riservatezza, cancellazione, audit sui trattamenti già svolti) restano efficaci.

2. Tipi di dati personali e categorie di interessati

2.1 Tipi di dati personali trattati per conto del Titolare.

2.2 Categorie di interessati.

• utenti registrati dell'azienda cliente, nei ruoli previsti dal prodotto (titolare, operatore, consulente, staff);
• il titolare o il rappresentante dell'impresa cliente, quando persona fisica o ditta individuale;
• clienti e fornitori dell'azienda cliente, ricavati da fatture e anagrafiche;
• dipendenti e manodopera dell'azienda cliente;
• mittenti e destinatari delle email e delle PEC lette dai connettori;
• utenti Telegram collegati al bot.

I contatti raccolti dal modulo pubblico del sito da persone non registrate non rientrano in questo accordo: rispetto a quei dati SophiaTerra è titolare autonoma e vale l'informativa privacy.

2.3 Categorie particolari (art. 9) e dati giudiziari (art. 10). Il servizio non è progettato per trattarli e il Titolare si impegna a non immetterli. Va detto con chiarezza: non esiste oggi alcun controllo tecnico che li riconosca o li blocchi. Se il Titolare li carica — per esempio dati sanitari dentro documenti del personale — vengono trattati come qualunque altro contenuto e trasmessi al fornitore del modello. La responsabilità di non immetterli resta del Titolare.

3. Istruzioni documentate del Titolare

3.1 Il Responsabile tratta i dati personali soltanto su istruzione documentata del Titolare, compreso il trasferimento verso paesi terzi (§11).

3.2 Che cosa vale come istruzione. Costituiscono l'insieme completo delle istruzioni: a) questo accordo e i Termini di Servizio; b) le operazioni che gli utenti autorizzati compiono nell'interfaccia del servizio (inserimenti, modifiche, cancellazioni, attivazione di un connettore, invio di un documento); c) le richieste rivolte all'agente "Sophia" da un utente autorizzato a farlo; d) le istruzioni successive impartite per iscritto a info@sophiaterra.com.

3.3 Il Responsabile non tratta i dati per finalità proprie né li comunica a terzi, salvo quanto previsto al §6 e salvo obblighi di legge.

3.4 Obblighi di legge. Se un obbligo del diritto dell'Unione o dello Stato membro impone un trattamento non previsto dalle istruzioni, il Responsabile informa il Titolare prima di procedere, a meno che quella stessa norma lo vieti per motivi di interesse pubblico.

3.5 Istruzioni contrarie al Regolamento. Se ritiene che un'istruzione violi il GDPR o altre norme sulla protezione dei dati, il Responsabile informa immediatamente il Titolare e può sospendere l'esecuzione dell'istruzione fino a chiarimento (art. 28, par. 3, ultimo comma).

3.6 Un limite da conoscere. Chi opera dentro il servizio agisce per conto del Titolare: spetta al Titolare stabilire chi può accedere, con quale ruolo, e revocare gli accessi che non servono più. Il Responsabile non entra nel merito di quelle scelte e non è in grado di distinguere un utente autorizzato da uno che il Titolare ha dimenticato di rimuovere.

4. Riservatezza delle persone autorizzate

4.1 Il Responsabile garantisce che le persone autorizzate al trattamento dei dati del Titolare si siano impegnate alla riservatezza o abbiano un adeguato obbligo legale di riservatezza, e che accedano ai dati solo per quanto necessario a erogare il servizio, assistere il Titolare o diagnosticare un guasto.

4.2 Stato di fatto. Il Responsabile è un'impresa individuale: alla data odierna l'unica persona fisica con accesso amministrativo all'infrastruttura è il suo titolare. ELENCO NOMINATIVO DELLE PERSONE AUTORIZZATE E IMPEGNI DI RISERVATEZZA SOTTOSCRITTI: DA PREDISPORRE prima dell'ingresso di collaboratori, dipendenti o fornitori di assistenza tecnica.

4.3 Un limite tecnico da dichiarare, non da nascondere. Le credenziali di amministrazione del database e dei fornitori consentono tecnicamente la lettura dei dati di tutte le aziende clienti. Non esiste oggi un vincolo tecnico che lo impedisca, né un registro degli accessi amministrativi che lo renda verificabile a posteriori (§5). Il limite è contrattuale e organizzativo, non tecnico.

5. Misure di sicurezza (art. 32)

Questo capitolo descrive le misure effettivamente in essere. Le misure che non ci sono sono elencate al §5.3: dichiararle sarebbe peggio che ammetterle.

5.1 Misure in essere

a) Autenticazione. L'accesso è gestito da Clerk (§6). SophiaTerra non conserva le password degli utenti. La sessione è tenuta da un cookie tecnico con durata fino a 7 giorni: è l'impostazione predefinita del fornitore, che il progetto non configura da nessuna parte — DURATA EFFETTIVA DELLA SESSIONE: DA CONFERMARE SUL PANNELLO DI CLERK, perché è il valore dichiarato anche nella Cookie Policy. AUTENTICAZIONE A DUE FATTORI: DA VERIFICARE SE È ATTIVA SULL'ISTANZA DI PRODUZIONE e se sia imponibile agli utenti del Titolare.

b) Controllo degli accessi. Tutte le pagine e tutte le API richiedono una sessione valida, tranne un elenco chiuso di rotte pubbliche: pagina di presentazione, pagine legali (compreso questo documento), accesso e registrazione, immagini di anteprima dei link, modulo di contatto, la pagina informativa dichiarata al webmaster dal programma che consulta i siti dei bandi, i webhook che si autenticano con una firma o un segreto proprio, e un endpoint interno di valutazione della qualità dell'agente, protetto da un segreto dedicato e inerte se quel segreto non è configurato. Le pagine della dashboard e le API dell'agente richiedono anche un'azienda attiva.

c) Isolamento per azienda. Ogni tabella di dati porta l'identificativo dell'azienda. In tutto ciò che passa dall'interfaccia — le pagine e le API usate da un utente collegato — l'azienda si ricava dalla sessione, mai da un parametro della richiesta, e ogni lettura o scrittura passa da quel contesto.

Restano fuori da questa regola le chiamate che una sessione non l'hanno, e vanno dette: nessuna di esse lascia scegliere l'azienda a chi chiama, ma nessuna di esse la ricava dalla sessione.

• L'endpoint interno di valutazione della qualità dell'agente lavora su un'azienda fissa nel codice — l'azienda del Responsabile stesso: un identificativo eventualmente inviato nella richiesta non viene letto.
• Il webhook di Telegram ricava l'azienda dalla chat da cui arriva il messaggio, attraverso il collegamento salvato nel database quando un titolare o un amministratore ha richiesto il codice di abbinamento.
• Il rientro dal consenso Google ("Accedi con Google"), quando quel collegamento è attivo (§6.7), ricava l'azienda da un parametro di stato firmato dal server e legato a un cookie monouso; il rientro dal consenso Meta la ricava invece dalla sessione, come tutto il resto.
• Il webhook dei pagamenti ricava l'azienda dai dati che il fornitore restituisce nell'evento, di cui verifica la firma.
• Le esecuzioni programmate (briefing giornaliero, ricerca dei bandi) non hanno un'azienda sola: scorrono le aziende interessate e trattano ciascuna nel proprio contesto.

È un isolamento applicativo: vedi il §5.3 per ciò che non è.

d) Ruoli. Il servizio distingue chi può far modificare i dati aziendali da chi può solo consultarli. La distinzione poggia sul ruolo "membro" presso il fornitore di autenticazione, che è l'unica fonte di verità sui ruoli: la colonna "ruolo" presente nel database dell'applicazione è descrittiva e non governa alcun accesso. Il controllo prende due forme: il rifiuto della richiesta (errore 403, oppure un messaggio nel modulo dove l'operazione non passa da una chiamata API) e, nell'agente, l'omissione di uno degli strumenti che il modello può usare.

Il criterio, e i suoi confini. La decisione sul ruolo ha da oggi una funzione condivisa, ma va richiamata endpoint per endpoint: non esiste un punto unico che la applichi, e alla data di questa bozza sedici punti ripetono ancora la stessa condizione scritta a mano. Il controllo è messo dove un membro modificherebbe i dati dell'azienda, i suoi collegamenti a servizi esterni o il suo rapporto contrattuale — acquisti, portale di fatturazione, riscatto di codici. Non è messo sulle letture, che restano aperte a chiunque abbia una sessione e un'azienda attiva, né sull'uso ordinario del prodotto — la chat, il caricamento di documenti, l'estrazione dei dati da un documento prima della conferma — che consuma i crediti dell'azienda e lascia scritte la conversazione e la memoria. L'elenco che segue è quello riscontrato leggendo il codice il 31 agosto 2026 ed è per sua natura una fotografia: VA RIVERIFICATO A OGNI MODIFICA DEGLI ENDPOINT DI SCRITTURA.

Dove il controllo agisce, e con che effetto:

• onboarding: anagrafica, intervista, documento e chiusura del questionario rifiutano la richiesta (errore 403) senza scrivere nulla;
• connettori: importazione delle fatture elettroniche; conferma dei dati estratti dal fascicolo aziendale e dall'export social; collegamento e scollegamento della casella email/PEC; avvio e revoca del collegamento a Gmail e ai profili Facebook/Instagram tramite OAuth; sincronizzazione delle metriche social. Il rifiuto arriva prima di leggere il file caricato o di toccare le credenziali nel vault. Sull'avvio del consenso OAuth il rifiuto non è un errore 403 ma un rientro in dashboard con un messaggio di collegamento non riuscito, perché quelle richieste rispondono solo con un reindirizzamento;
• pagamenti: l'avvio dell'acquisto di un abbonamento o di una ricarica e l'apertura del portale di fatturazione del fornitore dei pagamenti — dal quale si cambia il metodo di pagamento, si scaricano le fatture con i dati fiscali dell'azienda e si disdice l'abbonamento. Il rifiuto arriva prima che la sessione di pagamento venga creata;
• crediti: il riscatto di un codice che accredita crediti all'azienda. Non è una chiamata API ma un'azione del modulo, che mostra all'utente il motivo del rifiuto;
• Telegram: la richiesta del codice che collega una chat, perché la chat collegata scrive; lo scollegamento di una chat già collegata; l'accensione e lo spegnimento del briefing giornaliero, che vale per tutte le chat dell'azienda;
• conversazioni: la cancellazione di una conversazione. Il registro è tenuto per azienda e non per utente, quindi cancellare significherebbe cancellare anche le conversazioni degli altri;
• memoria dal questionario: il salvataggio, nella memoria dell'azienda, del profilo raccolto dal questionario iniziale. Qui il rifiuto è silenzioso: resta nei log del server, e la pagina dichiara ugualmente all'utente che il profilo è stato salvato;
• agente, in parte: nella chat e nel caricamento di documenti il ruolo non impedisce l'uso e non toglie all'agente ogni possibilità di scrivere. Gli strumenti di scrittura sono tre e il ruolo ne toglie uno: quello che riscrive le schede strutturate dell'azienda (magazzino, clienti e fornitori, parcelle, finanza, dipendenti, bandi, anagrafica…), che a un membro non viene proprio consegnato. Gli altri due restano disponibili anche al membro: uno salva nella memoria dell'azienda un fatto nuovo appreso dalla conversazione o da un documento; l'altro corregge un fatto già in memoria e nel farlo marca come superate fino a tre voci precedenti. Quella memoria è tenuta per azienda e rientra nelle risposte successive di Sophia a chiunque: un utente in sola lettura può quindi lasciarvi contenuto permanente e far invecchiare voci scritte da altri. Restano scritte anche la conversazione e i suoi messaggi, e i crediti si consumano lo stesso: è un controllo parziale, non un divieto d'uso.

Dove non agisce, e va detto invece che taciuto. Le operazioni seguenti restano possibili a qualunque utente con una sessione valida e un'azienda attiva, quale che sia il suo ruolo:

• uso dell'agente e consumo di crediti: la chat, il caricamento di documenti e l'estrazione dei dati dal fascicolo aziendale e dall'export social prima della conferma. L'estrazione non scrive le schede dell'azienda, ma ne consuma i crediti e trasmette il documento al fornitore del modello;
• onboarding: la registrazione dello stato delle domande d'ingresso — quali sono già state poste e la chiusura del giro;
• segnalazioni: il testo inviato con il pulsante di segnalazione di un problema, che finisce nei log applicativi;
• tutte le letture: elenco delle chat Telegram collegate, stato dei connettori, saldo dei crediti, dati aziendali, conversazioni dell'azienda. Chi è invitato in sola lettura vede tutto ciò che l'azienda ha dentro.

Restano fuori dal controllo, per costruzione, le chiamate senza sessione elencate alla lettera c): lì un ruolo non esiste e la barriera è un'altra (firma, segreto condiviso, stato firmato). Per il canale Telegram questo significa che chi dispone di una chat collegata fa scrivere i dati dell'azienda senza che il ruolo venga più verificato, e con tutti e tre gli strumenti di scrittura dell'agente: il ruolo agisce una volta sola, quando la chat viene collegata.

Inoltre l'interfaccia non nasconde al membro i comandi che gli sono preclusi: il rifiuto arriva dopo il clic. In due casi non arriva affatto all'utente: la cancellazione di una conversazione, dove l'errore è ignorato dal lato browser e la conversazione riappare al primo ricaricamento, e il salvataggio del profilo del questionario, dove la pagina annuncia comunque il salvataggio. Il controllo confronta il valore esatto del ruolo "membro", quindi un ruolo personalizzato creato in futuro presso il fornitore di autenticazione non sarebbe intercettato: PRIMA DI INTRODURRE NUOVI RUOLI VA RIVISTO QUESTO ELENCO.

e) Cifratura in transito. HTTPS verso l'applicazione; connessione al database su HTTPS; posta in uscita su SMTP con TLS implicito (porta 465); lettura delle caselle su IMAP con TLS (porta 993).

f) Cifratura a riposo, a livello applicativo. Le credenziali dei connettori del Titolare (posta, PEC, fatturazione elettronica, Facebook/Instagram) sono cifrate con AES-256-GCM prima di essere scritte: il database contiene solo il testo cifrato e la chiave vive esclusivamente in una variabile d'ambiente, mai nel database e mai nel codice.

g) Segreti. Chiavi API e credenziali stanno in variabili d'ambiente presso il fornitore di hosting, non nel codice sorgente e non nel repository.

h) Autenticazione delle chiamate automatiche. Il webhook dei pagamenti verifica la firma del fornitore; il webhook di Telegram verifica un segreto condiviso; le esecuzioni programmate verificano un segreto dedicato. Nessuna di queste rotte è accessibile senza la prova corrispondente.

i) Freni contro abusi e sovraccarico. Tetto di richieste al minuto per azienda, tetto di richieste contemporanee, budget a crediti che si esaurisce.

j) Minimizzazione dei file. I documenti caricati non vengono conservati come file e non esiste alcun archivio di oggetti presso terzi (§2.1).

k) Nessuno strumento di statistica, profilazione o tracciamento errori di terze parti è installato nel prodotto; i caratteri tipografici sono serviti dal dominio del servizio, quindi il browser dell'utente non contatta server esterni per caricarli.

l) Tracciabilità del consumo. Ogni chiamata all'agente registra azienda, utente e token consumati. È tracciabilità del consumo, non un registro degli accessi ai dati (§5.3).

m) Verifiche automatiche prima del rilascio. Il progetto ha una suite di test automatici eseguita prima delle pubblicazioni. Verifica il comportamento del prodotto: non è un test di sicurezza.

5.2 Riservatezza, integrità, disponibilità, resilienza (art. 32.1.b)

Le misure di §5.1 coprono riservatezza e, in parte, integrità. Disponibilità e resilienza dipendono oggi interamente dai fornitori di infrastruttura (database e hosting) e non sono governate da procedure proprie del Responsabile: vedi §5.3, punti sul ripristino.

5.3 Misure che NON sono in essere — dichiarate apertamente

1. BACKUP E RIPRISTINO: NESSUNA PROCEDURA PROPRIA, DOCUMENTATA O PROVATA. Non esiste nel progetto uno script di salvataggio, un calendario di copie, una ritenzione dichiarata né una prova di ripristino mai eseguita. Ciò che esiste è quanto offerto dal fornitore del database (Neon): TIPO DI COPIE, FINESTRA DI RIPRISTINO E RITENZIONE DA ACCERTARE SUL PIANO EFFETTIVAMENTE ATTIVO (art. 32.1.c: capacità di ripristinare tempestivamente la disponibilità dei dati).
2. CIFRATURA A RIPOSO DELL'INTERO DATABASE: DIPENDE DAL FORNITORE, DA CONFERMARE con il suo accordo. A livello applicativo sono cifrate solo le credenziali dei connettori (§5.1.f).
3. NESSUN REGISTRO DEGLI ACCESSI AI DATI (audit log). Non è possibile ricostruire chi abbia letto quale dato e quando, né dal lato degli utenti del Titolare né dal lato amministrativo. È il limite che pesa di più sul §8.
4. NESSUNA SICUREZZA A LIVELLO DI RIGA NEL DATABASE (row-level security). L'isolamento fra aziende è garantito dal codice dell'applicazione: un difetto di programmazione in una singola query potrebbe, in linea di principio, esporre dati di un'altra azienda. Il rischio è mitigato dal fatto che nelle chiamate con sessione l'azienda si ricava dalla sessione e mai da un parametro della richiesta; per le poche chiamate senza sessione vale quanto detto al §5.1.c.
5. NESSUNA VERIFICA DI SICUREZZA INDIPENDENTE (test di intrusione, revisione esterna del codice) e nessuna procedura documentata di verifica periodica dell'efficacia delle misure (art. 32.1.d).
6. NESSUNA PROCEDURA SCRITTA DI GESTIONE DEGLI INCIDENTI (chi fa cosa, in quali tempi, con quali registri).
7. SEPARAZIONE FRA AMBIENTE DI SVILUPPO E PRODUZIONE: DA CONFERMARE. Il codice conserva traccia di un periodo in cui le istanze di sviluppo e di produzione scrivevano nello stesso database. Va accertato che oggi l'ambiente di sviluppo punti a un database separato e che nessun dato reale di clienti sia usato per prove.
8. NESSUNA CERTIFICAZIONE (ISO/IEC 27001, SOC 2) e nessuna adesione a codici di condotta ex artt. 40-42.
9. NESSUNA PSEUDONIMIZZAZIONE dei dati trattati: i dati sono in chiaro nel database, salvo le credenziali dei connettori.

6. Sub-responsabili

6.1 Autorizzazione generale. Il Titolare autorizza in via generale il Responsabile a ricorrere ai sub-responsabili elencati al §6.3, e a sostituirli o aggiungerne altri alle condizioni del §6.2.

6.2 Modifiche e preavviso. Prima di aggiungere o sostituire un sub-responsabile, il Responsabile ne dà comunicazione al Titolare all'indirizzo email associato all'azienda e sulla pagina di questo documento, con un preavviso di almeno PREAVVISO DA CONFERMARE — PROPOSTA: 30 GIORNI. Entro lo stesso termine il Titolare può opporsi per motivi ragionevoli e documentati legati alla protezione dei dati. Se l'opposizione non può essere accolta senza rinunciare al fornitore, il Titolare può recedere dal servizio senza penali, con rimborso della quota di abbonamento non goduta.

Il Responsabile si impegna a vincolare ciascun sub-responsabile, tramite contratto, a obblighi di protezione dei dati non meno onerosi di quelli qui assunti, e risponde verso il Titolare del loro operato. ALLA DATA ODIERNA QUESTO NON È STATO VERIFICATO PER NESSUNO DEI SUB-RESPONSABILI ELENCATI AL §6.3: la clausola vale come impegno per il futuro, non descrive uno stato di fatto.

6.3 Elenco dei sub-responsabili attivi (aggiornato al 31 agosto 2026).

6.4 Precisazioni sulla posta. Il servizio usa due canali distinti: uno per la posta diretta ai clienti (Register.IT) e uno per gli avvisi interni al Responsabile (Gmail). Va segnalato un caso particolare: quando l'invio al cliente fallisce, il messaggio destinato al cliente — indirizzo, oggetto e testo integrale — viene inoltrato alla casella del titolare del Responsabile attraverso Gmail, perché non vada perduto. È un trattamento reale e va conosciuto.

Come è stato accertato il fornitore SMTP (31 agosto 2026). Il codice non nomina alcun fornitore: legge l'indirizzo del server da una variabile d'ambiente. Il valore configurato è authsmtp.securemail.pro, che risolve su smtp.securemail.pro e sull'indirizzo IP 81.88.48.66; la rete cui quell'indirizzo appartiene è intestata a Register.IT S.p.A., Via Ponti 6, 24126 Bergamo, Italia. Il trattamento avviene quindi nell'Unione europea e il fornitore non compare nella tabella dei trasferimenti extra-SEE (§11.2). Poiché il fornitore dipende da una variabile d'ambiente, cambiarla cambia il sub-responsabile: questa riga va riverificata se quel valore viene modificato.

6.5 Fornitore della casella collegata dal Titolare. Quando il Titolare collega la propria PEC, il servizio accede alla casella presso il gestore scelto dal Titolare stesso (l'impostazione predefinita del prodotto è Aruba). Quel gestore non è un sub-responsabile nominato dal Responsabile: è un fornitore del Titolare, con cui il rapporto è già suo. Il Responsabile è il soggetto che accede alla casella su istruzione del Titolare, tramite credenziali che il Titolare fornisce e che vengono conservate cifrate (§5.1.f).

6.6 Chiamate a terzi che non comportano dati personali. Per le previsioni meteo il servizio interroga Open-Meteo trasmettendo soltanto il nome del comune o una coppia di coordinate, senza alcun identificativo dell'utente o dell'azienda, senza chiave e senza account. Non è qualificato come responsabile ex art. 28. Si segnala comunque perché, per un'impresa individuale, la sede coincide di norma con il domicilio del titolare.

6.7 Servizi predisposti ma non attivi. Nel codice esistono, spenti, l'integrazione con un fornitore di embedding per la ricerca semantica, l'accesso alla casella Gmail tramite "Accedi con Google" con permesso di lettura dell'intera casella, e due provider per la fatturazione elettronica via SdI. Nessuno di essi è oggi configurato, e finché non lo saranno nessun dato li raggiunge. Se e quando verranno accesi, questo elenco e l'informativa privacy saranno aggiornati prima dell'attivazione. DA VERIFICARE PRIMA DELLA FIRMA: l'assenza delle relative chiavi nelle variabili d'ambiente dell'ambiente di produzione, che non è stato possibile ispezionare.

7. Assistenza al Titolare

7.1 Diritti degli interessati (artt. 12-23). Tenendo conto della natura del trattamento, il Responsabile assiste il Titolare con misure tecniche e organizzative adeguate per dare seguito alle richieste degli interessati. Se una richiesta arriva direttamente al Responsabile, questi non risponde nel merito e la trasmette al Titolare senza ritardo.

Che cosa il prodotto consente oggi, senza intervento manuale:

• cancellare le singole conversazioni con Sophia dalla propria area;
• esportare in Excel i dati di clienti, fornitori e magazzino;
• correggere i dati aziendali dalle rispettive sezioni.

Che cosa richiede un intervento manuale, oggi:

• l'estrazione completa dei dati di un'azienda in un unico pacchetto (portabilità);
• la cancellazione dell'intera azienda e di tutti i suoi dati;
• la consultazione e la cancellazione delle voci della memoria dell'azienda (§2.1), che non ha una pagina propria: dalla conversazione si può chiedere a Sophia di correggere un fatto, ma la voce vecchia resta nel database marcata come superata, non viene cancellata. NON ESISTE UNA FUNZIONE DI AUTOSERVIZIO PER NESSUNA DELLE DUE. Si eseguono su richiesta scritta a info@sophiaterra.com. TEMPI DI RISCONTRO DA FISSARE — PROPOSTA: 10 GIORNI LAVORATIVI, compatibili con i termini che l'art. 12 impone al Titolare.

7.2 Sicurezza (art. 32). Il Responsabile assiste il Titolare mettendo a disposizione la descrizione delle misure in essere e delle lacune note (§5), perché il Titolare possa valutarne l'adeguatezza al rischio dei propri trattamenti.

7.3 Violazioni (artt. 33-34). Vedi §8.

7.4 Valutazione d'impatto e consultazione preventiva (artt. 35-36). Il Responsabile fornisce al Titolare le informazioni necessarie: categorie di dati, flussi verso i sub-responsabili, ubicazione, misure di sicurezza, tempi di conservazione. NON È STATA REDATTA ALCUNA VALUTAZIONE D'IMPATTO SUL SERVIZIO: DA VALUTARE CON IL CONSULENTE SE SIA DOVUTA, considerato che il servizio applica un modello di intelligenza artificiale a dati aziendali e, tramite fatture e PEC, a dati di terzi che non hanno alcun rapporto con il Titolare del servizio.

8. Violazione dei dati personali

8.1 Notifica. Il Responsabile informa il Titolare senza ingiustificato ritardo dopo essere venuto a conoscenza di una violazione dei dati personali trattati per suo conto, e comunque entro TERMINE DA CONFERMARE — PROPOSTA: 48 ORE, all'indirizzo email associato all'azienda.

8.2 Contenuto. Nei limiti delle informazioni disponibili: natura della violazione, categorie e numero approssimativo di interessati e di registrazioni coinvolte, probabili conseguenze, misure adottate o proposte per porvi rimedio e attenuarne gli effetti, punto di contatto. Le informazioni mancanti sono fornite man mano che diventano disponibili.

8.3 Chi notifica all'autorità. La notifica al Garante (art. 33) e la comunicazione agli interessati (art. 34) spettano al Titolare. Il Responsabile non le esegue in sua vece e collabora fornendo quanto in suo possesso.

8.4 Capacità di accorgersene: un limite da dichiarare. In assenza di un registro degli accessi ai dati (§5.3), la capacità di rilevare un accesso abusivo compiuto con credenziali valide è limitata. Il rilevamento si appoggia oggi agli avvisi dei fornitori (autenticazione, database, hosting, pagamenti) e ai log dell'applicazione, la cui finestra di conservazione dipende dal piano attivo: DURATA DI CONSERVAZIONE DEI LOG PRESSO L'HOSTING DA VERIFICARE. Un incidente più vecchio di quella finestra potrebbe non lasciare tracce ricostruibili.

9. Cancellazione o restituzione dei dati

9.1 Alla cessazione del servizio, a scelta del Titolare comunicata per iscritto, il Responsabile restituisce i dati personali trattati per suo conto oppure li cancella, cancellando le copie esistenti salvo quanto previsto al §9.4.

9.2 Finestra per la scelta. DA CONFERMARE — PROPOSTA: 30 GIORNI dalla cessazione per chiedere la restituzione. In assenza di richiesta entro il termine, si procede alla cancellazione. Va coordinato con quanto già dichiarato nell'informativa privacy, che indica una conservazione fino a 12 mesi dalla chiusura dell'account: I DUE TERMINI VANNO ALLINEATI.

9.3 Formato della restituzione. Oggi il servizio produce fogli Excel per le sezioni che li prevedono; UNA PROCEDURA DI RESTITUZIONE COMPLETA, IN FORMATO STRUTTURATO E DI USO COMUNE, NON È ANCORA DEFINITA NÉ AUTOMATIZZATA. Va definita prima che il documento diventi efficace: è la clausola che un cliente strutturato verifica per prima.

9.4 Eccezioni. Restano conservati i dati per i quali il diritto dell'Unione o dello Stato membro impone la conservazione, per il tempo da esso previsto. Rientrano qui i dati di fatturazione del rapporto con il cliente (10 anni), rispetto ai quali però il Responsabile agisce come titolare autonomo e non in forza di questo accordo.

9.5 Copie di sicurezza. La cancellazione dalle copie di sicurezza segue i cicli di ritenzione del fornitore del database e NON PUÒ ESSERE GARANTITA IMMEDIATA: TEMPI DA ACCERTARE (§5.3, punto 1).

9.6 Presso i sub-responsabili. Il Responsabile trasmette la richiesta di cancellazione ai sub-responsabili coinvolti. I tempi effettivi dipendono da ciascuno: DA VERIFICARE NEI RISPETTIVI ACCORDI, in particolare la ritenzione dei contenuti trasmessi al fornitore del modello.

10. Audit e informazioni per dimostrare la conformità

10.1 Il Responsabile mette a disposizione del Titolare tutte le informazioni necessarie per dimostrare il rispetto degli obblighi dell'art. 28 e consente e contribuisce ad attività di revisione, comprese le ispezioni, svolte dal Titolare o da un incaricato da lui scelto.

10.2 Modalità. Con preavviso scritto ragionevole (PROPOSTA: 30 GIORNI), in orario lavorativo, non più di una volta l'anno — salvo violazione accertata, richiesta motivata di un'autorità di controllo o modifica sostanziale del servizio — con oneri a carico del Titolare, con impegno di riservatezza dell'incaricato e senza compromettere la sicurezza e la riservatezza dei dati di altri clienti. L'incaricato non deve essere un concorrente del Responsabile.

10.3 Che cosa può essere fornito oggi. Questo documento, la descrizione dell'architettura e dei flussi di dati, l'elenco aggiornato dei sub-responsabili e i loro accordi quando disponibili, la descrizione delle misure in essere e delle lacune del §5.3.

10.4 Che cosa non esiste. NESSUNA CERTIFICAZIONE, NESSUNA RELAZIONE DI AUDIT INDIPENDENTE, NESSUN QUESTIONARIO DI SICUREZZA GIÀ COMPILATO. Un cliente strutturato lo chiederà: è bene saperlo in anticipo.

11. Trasferimenti al di fuori dell'Unione europea

11.1 Regola. Il Responsabile non trasferisce dati personali del Titolare fuori dallo Spazio economico europeo se non verso i sub-responsabili elencati al §6.3 e a condizione che sussista una garanzia adeguata ai sensi degli artt. 44 e seguenti del GDPR.

11.2 Fornitori che comportano un trasferimento extra-SEE.

11.3 Ubicazione dell'infrastruttura. Il database (Neon) è configurato su infrastruttura UE a Francoforte: è l'unica ubicazione riscontrata, e lo è dalla stringa di connessione dell'ambiente di produzione. PER L'HOSTING (VERCEL) LA REGIONE DI ESECUZIONE NON È DETERMINATA: il progetto non ne imposta alcuna (né in vercel.json né in next.config.ts) e il pannello del fornitore non è stato ispezionato. Va accertata prima della firma: Vercel esegue l'intera applicazione, quindi vi passa ogni dato del Titolare, e se le funzioni girano fuori dal SEE il fornitore va aggiunto alla tabella del §11.2 con la relativa base giuridica. In ogni caso l'ubicazione dei dati non esclude di per sé un accesso da fuori dal SEE da parte del personale di assistenza del fornitore: DA VERIFICARE NEI RISPETTIVI ACCORDI.

11.4 Valutazione d'impatto sul trasferimento (TIA). NON È STATA REDATTA. Va predisposta almeno per i trasferimenti verso gli Stati Uniti e, in via prioritaria, per il canale Telegram.

11.5 Il Titolare, accettando questo accordo, impartisce istruzione al Responsabile di effettuare i trasferimenti descritti, nei limiti e con le garanzie qui indicate.

12. Disposizioni finali

12.1 Modifiche. La versione vigente di questo accordo è pubblicata su questa pagina con la data di aggiornamento. Le modifiche sostanziali sono comunicate con preavviso all'indirizzo email associato all'azienda; le versioni precedenti restano consultabili su richiesta.

12.2 Gerarchia. In caso di contrasto con i Termini di Servizio su come vengono trattati i dati personali, prevale questo accordo.

12.3 Legge applicabile e foro. Legge italiana. Per le controversie è competente il foro di Pescara, come nei Termini, fermo restando quanto inderogabilmente previsto dalla legge.

12.4 Contatti. info@sophiaterra.com — PEC gb.obletter@pec.it. Non è stato nominato un DPO.

Appendice — punti aperti, per chi rivede questo testo

Questa appendice non fa parte dell'accordo: è la lista, in un posto solo, di tutto ciò che va deciso o verificato prima che il documento possa avere valore.

1. Accettazione: nessun meccanismo raccoglie e registra l'accettazione (utente, data, versione). Finché manca, l'accordo non è concluso con nessun cliente (Premessa).
2. Accordi con i sub-responsabili: nessuno dei nove è stato verificato. Vanno raccolti, letti e allegati — con attenzione particolare a Telegram, per cui va accertato se esista un accordo ex art. 28 (§6.3, §11.2). Nell'accordo con Anthropic va cercata anche la risposta su quali fornitori serva la ricerca sul web che il modello può usare (§1.4).
3. Backup e ripristino: non esiste procedura propria. Vanno accertati tipo di copie, finestra di ripristino e ritenzione del piano attivo sul database, e va eseguita una prova (§5.3.1).
4. Cifratura a riposo del database: da confermare con l'accordo del fornitore (§5.3.2).
5. Registro degli accessi ai dati: non esiste. Incide su §4.3, §8.4 e §10.
6. Row-level security: assente; l'isolamento è solo applicativo (§5.3.4).
7. Separazione sviluppo/produzione: da confermare che oggi siano database distinti (§5.3.7).
8. Autenticazione a due fattori: da verificare se attiva e imponibile (§5.1.a). Sulla stessa pagina del pannello va confermata la durata della sessione (dichiarata in 7 giorni qui e nella Cookie Policy, ma non impostata nel codice).
9. Variabili d'ambiente di produzione: non ispezionabili da qui. Va confermato che i servizi dichiarati spenti (embedding, "Accedi con Google" con lettura della casella, provider SdI) non abbiano chiavi configurate in produzione (§6.7).
10. Termini da fissare: preavviso sui sub-responsabili (30 gg), notifica di violazione (48 h), riscontro sui diritti (10 gg lavorativi), finestra di restituzione (30 gg), preavviso di audit (30 gg). Tutti proposti, nessuno deciso.
11. Allineamento con la privacy policy: la conservazione post-chiusura indicata lì (12 mesi) e la finestra di restituzione proposta qui (30 giorni) dicono cose diverse (§9.2).
12. Procedura di restituzione completa e di cancellazione integrale di un'azienda: da progettare; oggi sono operazioni manuali senza tempi né formato definiti (§7.1, §9.3).
13. DPIA e TIA: nessuna delle due è stata redatta (§7.4, §11.4).
14. Ubicazione ed entità contrattuale di Telegram e Meta: da accertare (§6.3). Per il fornitore SMTP l'accertamento è stato fatto il 31/08/2026 — Register.IT S.p.A., Bergamo, Italia (§6.4) — e resta solo da raccogliere l'accordo ex art. 28. Allo stesso titolo va accertata la regione di esecuzione delle funzioni presso Vercel: non è configurata nel progetto e non è stata letta sul pannello del fornitore, quindi oggi non si può dire né che l'applicazione giri nel SEE né il contrario (§11.3).
15. Rapporto fra i documenti legali: i Termini rinviano ora a questo accordo (§5, §7 e §8 dei Termini) e l'informativa privacy non ne presuppone più l'efficacia. Resta da raccoglierne l'accettazione (punto 1).
16. Controllo di ruolo, che cosa resta scoperto: il 31 agosto 2026 il controllo è stato esteso ai pagamenti (acquisto e portale di fatturazione), al riscatto dei codici, allo scollegamento di una chat Telegram, al briefing giornaliero e al salvataggio del profilo del questionario. Restano fuori, e vanno decisi: il consumo dei crediti dell'azienda con l'uso ordinario del prodotto (chat, documenti, estrazioni prima della conferma); i due strumenti con cui l'agente scrive nella memoria dell'azienda, che restano consegnati anche a un utente in sola lettura; lo stato delle domande d'ingresso; e tutte le letture, aperte a chiunque sia nell'azienda. L'elenco del §5.1.d va tenuto aggiornato a ogni modifica degli endpoint di scrittura.
17. Memoria dell'azienda: i fatti che l'agente salva in modo permanente (§2.1) non hanno una pagina da cui consultarli, correggerli o cancellarli, e una voce corretta resta nel database marcata come superata. Incide sui diritti di accesso, rettifica e cancellazione (§7.1) e sulla cancellazione a fine rapporto (§9).