Privacy & trattamento dati

1. Ruoli GDPR e titolarità del trattamento (Artt. 4, 24, 26, 28 GDPR)

Il soggetto giuridico che gestisce la piattaforma E-CARE è Cooperiamo Insieme — Cooperativa Sociale ONLUS, P.IVA 02812020598, sede legale in Italia (di seguito "Cooperiamo Insieme" o "il gestore della piattaforma"). Contatto privacy: privacy@cooperiamoinsieme.it.

Ai sensi degli Artt. 13–14 GDPR chiariamo in modo esplicito che Cooperiamo Insieme opera con un modello a tre ruoli distinti in funzione della categoria di dati trattati e del rapporto con l'ente aderente (cooperativa sociale, ASL, RSA, studio medico, ADI, famiglia organizzata in crew) che eroga il servizio di assistenza:

Nota. Quando l'ente aderente coincide con Cooperiamo Insieme (uso diretto della piattaforma per assistiti presi in carico dalla cooperativa), Cooperiamo Insieme opera come Titolare unico per tutte le categorie. Il modello a tre ruoli è approfondito nel paragrafo 13.

2. Categorie di dati trattati

E-CARE tratta le seguenti categorie di dati personali:

• Dati identificativi e di account: nome, cognome, email, ruolo nella crew, avatar, credenziali (hash), provider di login (Google/email).
• Dati relativi alla salute dell'assistito (categoria particolare ex Art. 9 GDPR): parametri vitali, terapie, somministrazioni, diario clinico-sociale, registro catetere/diuresi, allergie, patologie, contatti d'emergenza.
• Note vocali e trascrizioni AI: audio registrato dall'operatore inviato al servizio di trascrizione (Lovable AI Gateway); l'audio originale viene scartato subito, il testo trascritto è conservato come nota nel diario.
• Dati di profilo marketplace lavoro: bio pubblica, città, disponibilità (orari/mansioni), foto opzionale, tariffe, esperienze — solo se pubblichi un annuncio "cerco"/"offro".
• Dati di localizzazione: indirizzo inserito per il marketplace, geocodificato a precisione comunale sulla mappa pubblica; coordinate esatte visibili solo agli utenti autenticati con esigenza operativa.
• Dati di fatturazione e pagamento: ragione sociale, codice fiscale/P.IVA, indirizzo di fatturazione, storico transazioni, riferimenti Stripe. Non conserviamo il numero della carta — è gestito direttamente da Stripe (PCI-DSS).
• Endpoint push notification: subscription del browser (endpoint URL, chiavi p256dh/auth) per il recapito delle notifiche, solo se attivi.
• Preferenze di notifica: canali attivi (in-app, email, push) per categoria di evento.
• Messaggistica interna: contenuto dei messaggi tra membri della crew nella chat dell'assistito, con timestamp e riferimenti mittente/destinatario.
• Dati di invito: email dell'invitato alla crew fornita da chi invita, prima della registrazione dell'interessato (cfr. paragrafo 8 — Art. 14 GDPR).
• Consensi versionati: tipo, versione policy, timestamp, IP e user agent al momento dell'accettazione (Art. 7 comma 1 — onere della prova).
• Dati tecnici e log: timestamp di accesso, IP, user agent a fini di sicurezza; log applicativo di errore (stack, path richiesto) senza payload personale.

3. Basi giuridiche

• Art. 6(1)(b) — esecuzione del contratto/servizio: coordinamento assistenza, marketplace lavoro, gestione account, abbonamenti.
• Art. 6(1)(c) — obbligo di legge: conservazione documenti contabili e fiscali (Art. 2220 c.c.), notifica data breach al Garante (Art. 33 GDPR).
• Art. 6(1)(f) — legittimo interesse: sicurezza applicativa, prevenzione abusi e frodi sui pagamenti, log tecnici, audit log admin.
• Art. 6(1)(a) — consenso esplicito: registrazione note vocali, pubblicazione profilo marketplace pubblico, ricezione notifiche push, contatto tramite dati di invito.
• Art. 9(2)(h) — trattamento di dati sanitari per finalità di assistenza e cura da parte di soggetti tenuti al segreto professionale o equivalente (dati clinici, trascrizioni note vocali, riassunti AI).

4. Registro dei trattamenti

Ai sensi dell'Art. 13 GDPR, la tabella seguente riporta per ogni attività di trattamento effettuata da E-CARE la finalità, la base giuridica, le categorie di dati coinvolte, i destinatari e il tempo di conservazione.

I dettagli di conservazione sono riepilogati nel paragrafo 15 — Tempi di conservazione per categoria. I sub-responsabili sono elencati nel paragrafo 5 — Destinatari.

4.1 Mappatura dedicata alle categorie particolari (Art. 9 GDPR)

I trattamenti che coinvolgono dati relativi alla salute o altre categorie particolari ex Art. 9 GDPR richiedono una doppia base giuridica: una condizione di liceità generale ex Art. 6 e una specifica deroga ex Art. 9(2). Per completezza e accountability (Art. 5.2, Art. 30), la tabella seguente isola queste attività, esplicita entrambe le basi, il test di necessità/proporzionalità (Art. 5.1.c) e le garanzie tecnico-organizzative adottate.

Il test di necessità è documentato per ogni funzione AI nella sezione paragrafo 14 — Agenti AI. La revoca del consenso Art. 9(2)(a) non pregiudica l'assistenza, che continua sotto la base primaria Art. 9(2)(h) senza l'ausilio dei modelli AI. La mappatura è aggiornata contestualmente ad ogni modifica del Registro dei trattamenti ex Art. 30 conservato dal DPO.

5. Destinatari e sub-responsabili

L'elenco include i sub-responsabili nominati da Cooperiamo Insieme sia per i trattamenti in cui agisce come Titolare autonomo (piattaforma), sia per quelli svolti come Responsabile per conto dell'ente aderente ex Art. 28 GDPR (vedi paragrafo 1 e paragrafo 13).

• Membri della crew autorizzati dal Titolare, secondo policy RLS per ruolo.
• Ente aderente (cooperativa/RSA/ADI/famiglia organizzata) — vedi paragrafo 13.
• Lovable Cloud — infrastruttura (Supabase/AWS, data center UE): database, storage, autenticazione.
• Lovable AI Gateway — trascrizione, riassunti, chat, matching (modelli Google Gemini e OpenAI).
• Cloudflare (US, SCC) — CDN, mitigazione DDoS, TLS.
• Stripe Payments Europe Ltd. (Irlanda) — pagamenti e abbonamenti, sub-responsabile con DPA e SCC per sub US.
• Google Identity — Single Sign-On (solo se attivato dall'utente).
• Provider email transazionale — invio inviti crew, notifiche di servizio, messaggi admin (DPA e SCC).
• Push service del browser — Google FCM / Apple APNs / Mozilla autopush (recapito notifiche, no contenuto personale).
• Provider di geocoding — OpenStreetMap Nominatim o equivalente (solo indirizzo, no dati identificativi).
• Commercialista / autorità fiscali — dati di fatturazione per obblighi di legge.
• DPO — accesso agli audit log e ai registri privacy per le sue funzioni.

Utilizziamo esclusivamente sub-responsabili nominati ex Art. 28 GDPR, con DPA scritti. La localizzazione primaria del trattamento è UE/SEE; per i fornitori con componenti negli Stati Uniti si applicano il Data Privacy Framework (Art. 45) e/o le SCC UE 2021/914 (Art. 46.2.c) con misure supplementari post-Schrems II. Dettaglio nella tabella seguente.

Le garanzie sono riepilogate in forma sintetica. Il testo completo di SCC, DPA e TIA è disponibile su richiesta scritta a privacy@cooperiamoinsieme.it ex Art. 46.1 GDPR (vedi paragrafo 7.4). Categorie e fornitori possono cambiare: aggiornamenti sostanziali vengono notificati ex paragrafo 18.

6. Conservazione — quadro generale (Art. 5.1.e, Art. 13.2.a GDPR)

In applicazione del principio di limitazione della conservazione (Art. 5.1.e GDPR) e dell'obbligo informativo previsto dall'Art. 13.2.a, E-CARE gestisce i periodi di conservazione secondo un quadro strutturato e verificabile. Nessuna categoria di dati è conservata "a tempo indeterminato".

6.1 Principi applicati

• Limitazione della conservazione (Art. 5.1.e) — durate definite ex ante per ogni categoria e imposte a livello tecnico.
• Minimizzazione (Art. 5.1.c) — raccogliamo solo i dati necessari e cancelliamo appena vengono meno le finalità.
• Integrità e riservatezza (Art. 5.1.f) — durante tutto il periodo di conservazione i dati sono protetti con le misure descritte nella pagina Sicurezza.

6.2 Criteri di determinazione delle durate

Quando non è possibile fissare un termine unico ex ante, la durata è determinata combinando i seguenti criteri (Art. 13.2.a GDPR):

• Obblighi di legge — es. documentazione sanitaria (10 anni), obblighi contabili e fiscali (Art. 2220 c.c., 10 anni).
• Durata del rapporto contrattuale — l'abbonamento, la partecipazione a una crew di assistenza, l'attività sul marketplace.
• Finalità di sicurezza e auditabilità — audit log e log tecnici conservati per il tempo necessario a ricostruire eventi anomali (12–24 mesi).
• Legittimo interesse residuo — es. contestazioni contrattuali, difesa in giudizio, entro i termini di prescrizione ordinari.
• Revoca del consenso — quando il trattamento si fonda sul consenso (Art. 6.1.a / 9.2.a), la revoca fa scattare la cancellazione, salvo tracciatura del consenso stesso (Art. 7.1).

6.3 Titolarità e responsabilità — chi decide le durate

Le durate di conservazione dipendono dalla titolarità del trattamento, che è distribuita tra due soggetti:

6.4 Modalità di cancellazione

• Soft delete immediato al raggiungimento della scadenza o su richiesta dell'interessato: i dati vengono resi non più accessibili dalla piattaforma.
• Hard delete definitivo tramite job cron orario (gdpr-retention): le righe sono rimosse dal database applicativo entro poche ore.
• Anonimizzazione irreversibile per i dati aggregati statistici (es. metriche di utilizzo AI), che possono essere conservati oltre i termini solo in forma non riconducibile all'interessato.
• Cancellazione dai backup: i backup crittografati sono ruotati con finestra di 30 giorni, dopo i quali la cancellazione è completa anche a livello di ripristino.
• Prima della cancellazione puoi sempre esportare i tuoi dati dalla sezione Profilo → I tuoi dati personali (GDPR) (Art. 20 — portabilità).

I periodi di conservazione applicati a ogni categoria specifica sono riepilogati nella tabella di dettaglio al paragrafo 15.

7. Trasferimenti di dati verso paesi terzi (Art. 13.1.f e Artt. 44–49 GDPR)

I dati personali sono ospitati primariamente su data center situati nell'Unione Europea / Spazio Economico Europeo (UE/SEE). Alcuni sub-responsabili operano o hanno sub-processor in paesi terzi (tipicamente Stati Uniti): in questi casi il trasferimento avviene esclusivamente in presenza di una base giuridica valida ex Capo V GDPR, ovvero — in ordine di preferenza applicativa:

• Decisione di adeguatezza della Commissione Europea (Art. 45 GDPR), inclusa la decisione UE–USA Data Privacy Framework (DPF) del 10 luglio 2023 per i fornitori USA che vi hanno aderito.
• Clausole Contrattuali Standard (SCC) UE 2021/914 del 4 giugno 2021 (Art. 46.2.c GDPR), con selezione del modulo appropriato (controller-to-controller, controller-to-processor, processor-to-processor) e le necessarie misure supplementari ex sentenza Schrems II (C-311/18).
• Norme Vincolanti d'Impresa (BCR) approvate ex Art. 47, quando disponibili nel gruppo del fornitore.
• In via residuale ed eccezionale, le deroghe specifiche di cui all'Art. 49 (consenso esplicito informato, esecuzione di un contratto con l'interessato, motivi di interesse pubblico, interessi vitali). Non utilizziamo le deroghe come base ordinaria del trattamento.

Per ciascun trasferimento è stata svolta o è in corso di aggiornamento una Transfer Impact Assessment (TIA) conforme alle Raccomandazioni EDPB 01/2020, che valuta il quadro giuridico del paese di destinazione, la natura dei dati e l'efficacia delle misure supplementari (crittografiche, contrattuali e organizzative).

7.1 Mappa dei trasferimenti per fornitore

7.2 Misure supplementari post-Schrems II

Per i trasferimenti verso paesi terzi che non offrono un livello di protezione sostanzialmente equivalente a quello UE, applichiamo un pacchetto standard di misure supplementari:

• Tecniche: cifratura in transito (TLS 1.2+), cifratura at-rest lato provider, minimizzazione dei dati inviati (in particolare ai modelli AI), pseudonimizzazione degli identificativi diretti dove tecnicamente possibile, payload notifiche neutro.
• Contrattuali: DPA con clausole di zero-retention e divieto di uso per training verso i fornitori AI; obbligo di notifica di richieste governative di accesso; audit right; sub-processor list aggiornata.
• Organizzative: TIA documentata per ogni fornitore extra-SEE, revisione annuale, monitoraggio delle decisioni delle autorità di controllo (EDPB, Garante) e delle pronunce della CGUE.

7.3 Deroghe dell'Art. 49 GDPR

Non facciamo ricorso alle deroghe dell'Art. 49 come base ordinaria del trattamento. In casi eccezionali e non ripetitivi (ad esempio l'esecuzione di una specifica richiesta dell'interessato che comporti l'invio dei suoi dati verso un paese terzo privo di adeguatezza o SCC applicabili), potremo avvalerci dell'Art. 49.1.a— consenso esplicito — previa informativa specifica sui rischi connessi all'assenza di decisione di adeguatezza e di garanzie appropriate.

7.4 Diritto a ricevere copia delle garanzie (Art. 46.1 e Art. 15.2 GDPR)

Hai il diritto di ottenere copia delle Clausole Contrattuali Standard e delle misure supplementari applicate a un trasferimento che ti riguarda, oppure l'indicazione del luogo in cui sono state rese disponibili. Puoi esercitare questo diritto scrivendo a privacy@cooperiamoinsieme.it. Il testo integrale delle SCC UE 2021/914 è pubblicato dalla Commissione Europea al seguente indirizzo: eur-lex.europa.eu/eli/dec_impl/2021/914/oj. L'elenco dei soggetti aderenti al Data Privacy Framework è consultabile su dataprivacyframework.gov/list.

7.5 Aggiornamenti

L'elenco dei fornitori e dei relativi paesi di destinazione è mantenuto allineato al paragrafo 6 (sub-responsabili). In caso di cambio fornitore, aggiunta di un nuovo sub-processor extra-SEE, o nuove decisioni di adeguatezza della Commissione Europea, aggiorniamo questa sezione e incrementiamo la versione della policy indicata in intestazione. Le variazioni sostanziali sono comunicate agli interessati tramite banner in-app o email di servizio prima della loro efficacia.

7.6 Registro dei trasferimenti extra-UE e verifica delle garanzie adeguate (Artt. 44-49 GDPR)

In conformità agli Artt. 44-49 GDPR e agli obblighi di accountability ex Art. 30, il Titolare mantiene un registro dei trasferimenti verso paesi terzi, distinto dal registro dei sub-responsabili (paragrafo 6), che per ciascun flusso documenta: (i) fornitore e paese di destinazione, (ii) categorie di interessati e di dati, (iii) finalità, (iv) strumento Art. 44-49 applicato, (v) esistenza e data della relativa TIA, (vi) evidenze delle garanzie (SCC firmate, certificazione DPF, BCR, DPA), (vii) data di ultima verifica, (viii) responsabile del monitoraggio.

La verifica dell'esistenza di garanzie adeguate segue una gerarchia rigorosa ex Capo V GDPR:

Ogni riga del registro riporta la data di ultima verifica (check semestrale sullo status DPF, annuale sulle SCC e TIA) e viene aggiornata immediatamente a fronte di eventi che possano incidere sull'adeguatezza (nuove pronunce CGUE, revoche di certificazione DPF, modifiche del quadro normativo statunitense come FISA 702 / EO 14086, decisioni del Garante). Copia estratto del registro è fornita su richiesta motivata al DPO.

7.7 Monitoraggio dello status di adeguatezza e delle certificazioni

• Check semestrale DPF: verifica che ogni fornitore USA elencato in paragrafo 7.1 sia ancora Active sull'elenco pubblico del Data Privacy Framework e certificato per HR/non-HR data secondo il flusso.
• Check annuale SCC + TIA: rinnovo della Transfer Impact Assessment con aggiornamento di rischi Paese (leggi di sorveglianza, ordini esecutivi, giurisprudenza), efficacia delle misure supplementari e conclusioni.
• Sub-processor watch: sottoscrizione delle notifiche di sub-processor dei fornitori chiave (Lovable, Stripe, Google, Cloudflare); ogni nuovo sub-processor extra-SEE attiva la procedura di verifica prima del go-live.
• Trigger straordinari di riesame: revoca o annullamento di una decisione di adeguatezza, nuove pronunce CGUE tipo Schrems, provvedimenti Garante/EDPB, breach coinvolgenti un fornitore extra-SEE, cambio del modello AI erogato via Lovable AI Gateway.
• Piano di contingenza: per ciascun trasferimento ad alto impatto è identificato uno scenario di fallback (fornitore alternativo UE, disattivazione della funzionalità AI, degradazione controllata) attivabile in caso di invalidazione delle garanzie.
• Trasparenza verso gli interessati: le variazioni sostanziali sono comunicate come previsto al paragrafo 7.5 e paragrafo 21 (modifiche); l'interessato può in ogni momento richiedere copia delle garanzie (paragrafo 7.4).

La responsabilità operativa del monitoraggio è del Privacy Office con supervisione del DPO; le risultanze confluiscono nel riesame periodico della DPIA (paragrafo 12.3, paragrafo 12.5).

8. Dati raccolti presso terzi (Art. 14 GDPR)

In alcuni casi E-CARE tratta dati che non sono forniti direttamente dall'interessato. In queste ipotesi, ai sensi dell'Art. 14 GDPR ti informiamo su fonte, categorie, finalità e diritti.

8.1 Email dell'invitato alla crew

• Categorie: indirizzo email, nome opzionale, ruolo proposto.
• Fonte: admin o supervisore della crew che ti invita alla piattaforma.
• Finalità: recapito dell'invito e creazione dell'account al primo accesso.
• Base giuridica: Art. 6(1)(b) — esecuzione di misure precontrattuali; Art. 6(1)(f) — legittimo interesse di chi invita alla costituzione della crew.
• Ritenzione: cancellazione automatica se l'invito non è accettato entro 30 giorni; altrimenti confluiscono nel tuo account regolare.
• Diritti: puoi opporti al trattamento e chiedere la cancellazione dell'invito scrivendo a privacy@cooperiamoinsieme.it prima di accettare.

8.2 Dati clinico-sociali di assistiti non utenti dell'app

• Categorie: dati identificativi e dati di salute ex Art. 9 GDPR (diario, terapie, parametri vitali).
• Fonte: familiari, operatori o medici del crew che inseriscono i dati nel diario dell'assistito.
• Finalità: assistenza e cura domiciliare condivisa.
• Base giuridica: Art. 9(2)(h) — finalità di assistenza e cura, sotto responsabilità di soggetti tenuti al segreto professionale o equivalente.
• Diritti: l'assistito o il suo rappresentante legale può esercitare i diritti Artt. 15-22 GDPR tramite il crew, l'ente aderente o direttamente il Titolare/DPO.
• Ritenzione: come il diario clinico-sociale (vedi paragrafo 15).

9. Diritti dell'interessato

Hai diritto di accesso, rettifica, cancellazione, limitazione, portabilità e opposizione (Artt. 15-22 GDPR), nonché di proporre reclamo al Garante per la protezione dei dati personali. Il dettaglio operativo su come esercitare ogni diritto è nella sezione paragrafo 16 — Esercizio dei diritti.

→ Per una guida rapida con azioni self-service e modelli di email precompilati vai alla pagina dedicata Esercita i tuoi diritti.

10. Sicurezza del trattamento (Art. 32 GDPR)

Il Titolare adotta misure tecniche e organizzative adeguate a garantire un livello di sicurezza proporzionato al rischio, con particolare attenzione ai dati sanitari e ai soggetti vulnerabili. Le misure sono riesaminate periodicamente e in occasione di modifiche rilevanti dell'infrastruttura o del trattamento.

9.1 Misure tecniche

• Cifratura in transito: TLS 1.3 su tutti gli endpoint pubblici, HSTS con preload, redirect HTTPS obbligatorio.
• Cifratura at-rest: AES-256 su database, storage oggetti (note vocali, allegati) e backup gestita dal provider infrastrutturale.
• Cifratura applicativa per le note vocali: chiave separata, accesso limitato al crew autorizzato e revocato automaticamente al termine del rapporto.
• Controllo accessi: autenticazione con OAuth Google o email/password (bcrypt), MFA opzionale, gestione ruoli separata dal profilo utente (tabella user_roles + funzione SECURITY DEFINER per evitare privilege escalation).
• Row-Level Security (RLS) attiva su ogni tabella con dati personali: policy per ruolo (assistito, familiare, operatore, medico, supervisore, admin) verificate da test end-to-end automatici (vitals, crew, marketplace).
• Segregazione dei ruoli: chiavi service-role usate solo lato server (edge functions/server functions) e mai esposte al client; chiavi pubblicabili con ambito ridotto per il frontend.
• Header di sicurezza HTTP: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, Referrer-Policy, Permissions-Policy, X-Content-Type-Options.
• Protezione perimetrale: CDN Cloudflare con mitigazione DDoS, rate limiting sugli endpoint sensibili (login, invito crew, webhook pagamenti), validazione firma HMAC sui webhook Stripe.
• Validazione input: schemi Zod su tutte le server function, whitelist di parametri, escape automatico output React contro XSS.
• Audit log append-only su modifiche cliniche, parametri vitali, consensi, ruoli e operazioni admin (conservazione 24 mesi).
• Backup e continuità: backup automatici giornalieri con Point-In-Time Recovery, obiettivi RTO 4h / RPO 24h, procedura di ripristino documentata e testata.
• Aggiornamenti e patch: monitoraggio automatico delle dipendenze (npm audit / dependabot), patch di sicurezza applicate secondo criticità (CVE ≥7.0 entro 7 giorni).
• Gestione segreti: chiavi API e credenziali conservate in secret manager, mai in repository, ruotate in caso di sospetta esposizione.

9.2 Misure organizzative

• Nomine e istruzioni: autorizzati al trattamento designati per iscritto ex Art. 29 GDPR con istruzioni operative e obbligo di riservatezza; responsabili esterni vincolati da DPA ex Art. 28.
• Principio del minimo privilegio: accessi concessi in base al ruolo e alla necessità operativa, revoca immediata al termine dell'incarico.
• Formazione periodica del personale su GDPR, sicurezza informatica, gestione delle emergenze e riconoscimento tentativi di social engineering / phishing.
• Registro dei trattamenti (Art. 30) e DPIA (Art. 35) documentati, riesaminati almeno annualmente. Estratto pubblico DPIA disponibile alla pagina DPIA.
• Procedura data breach (Artt. 33-34): escalation entro 24h, notifica al Garante entro 72h dalla conoscenza, comunicazione agli interessati in caso di rischio elevato, registro violazioni tenuto dal DPO.
• Gestione fornitori: due diligence sui sub-responsabili (certificazioni ISO 27001, SOC 2, sede di trattamento, SCC UE 2021/914 per trasferimenti extra-SEE).
• Data retention: cancellazione automatica dei dati oltre i termini definiti (vedi paragrafo 15), soft delete con periodo di grazia e purge cronizzato.
• Privacy & security by design: pseudonimizzazione ove possibile, minimizzazione dei dati raccolti, revisione del codice con checklist di sicurezza prima del rilascio in produzione.

10.3 Formazione, autorizzazione e controllo del personale (Artt. 29, 32.4 GDPR)

Tutto il personale che accede alla piattaforma E-CARE — dipendenti, collaboratori, operatori della crew e consulenti esterni — opera sotto l'autorità del Titolare e/o dell'ente aderente ai sensi dell'Art. 29 GDPR e tratta i dati esclusivamente in base a istruzioni documentate. La formazione è considerata misura tecnico-organizzativa ex Art. 32.4 e tracciata in registro interno con esito e data di scadenza.

• Nomina scritta e istruzioni operative (Art. 29): all'attivazione dell'account, ogni utente con ruolo operativo (operatore, medico, supervisore, admin) accetta le Istruzioni per gli autorizzati al trattamento, con obbligo di riservatezza esteso oltre la cessazione del rapporto.
• Formazione iniziale obbligatoria prima del primo accesso ai dati clinico-sociali: moduli su GDPR (basi giuridiche, dati particolari Art. 9, diritti degli interessati), sicurezza informatica (password, MFA, phishing, gestione dispositivi), procedure interne (data breach, esercizio dei diritti, escalation al DPO).
• Modulo dedicato alle funzionalità AI e note vocali: uso responsabile degli agenti AI (paragrafo 14), riconoscimento dei limiti dei modelli (allucinazioni, bias, errori di trascrizione), obbligo di revisione umana dei contenuti generati prima di qualunque decisione clinica o organizzativa, verifica del consenso Art. 9(2)(a) prima di attivare trascrizione/estrazione, corretta gestione del kill-switch server-side e della revoca del consenso.
• Aggiornamento periodico: refresh annuale per tutto il personale operativo e ad evento in caso di modifiche a normativa, fornitori AI, procedure interne o a seguito di incidenti/quasi-incidenti. Il mancato aggiornamento entro 30 giorni dalla scadenza comporta la sospensione automatica dei privilegi sui dati particolari (revoca ruolo, blocco delle funzionalità AI sensibili).
• Controllo umano sull'output AI ("human-in-the-loop"): le procedure operative impongono che nessun contenuto generato dall'AI (riassunti, alert, trascrizioni, suggerimenti della chat) sia utilizzato come base decisionale senza verifica esplicita da parte di un operatore competente. L'audit log conserva la traccia della revisione e dell'eventuale correzione, in coerenza con paragrafo 14.5 e paragrafo 14.3-ter.
• Verifica di efficacia: test di comprensione al termine di ciascun modulo, campagne periodiche di phishing simulation, revisione a campione degli accessi e delle correzioni sui contenuti AI, riesame degli incidenti con analisi delle cause umane e aggiornamento dei materiali formativi.
• Off-boarding: alla cessazione del rapporto o del ruolo, revoca immediata delle credenziali, decadenza degli accessi RLS, rimozione dalle crew e conferma scritta dell'obbligo di riservatezza persistente.

L'ente aderente, in qualità di titolare autonomo o contitolare dei dati clinico-sociali (vedi paragrafo 13), si impegna contrattualmente a fornire equivalente formazione al proprio personale che accede alla piattaforma. Su richiesta motivata, il DPO rende disponibile all'interessato o all'autorità di controllo l'evidenza dell'avvenuta formazione (registro anonimizzato con date e moduli erogati) al recapito dpo@cooperiamoinsieme.it.

10.4 Programma di monitoraggio continuo e audit periodici (Artt. 5.1.a, 5.1.d, 5.2, 22, 32.1.d GDPR)

In coerenza con il principio di accountability (Art. 5.2) e con l'obbligo di verifica periodica dell'efficacia delle misure (Art. 32.1.d), il Titolare ha adottato un programma strutturato di monitoraggio continuo e audit indipendenti che copre l'intero ciclo di vita dei dati, con particolare attenzione a liceità e correttezza (Art. 5.1.a), esattezza degli algoritmi (Art. 5.1.d) e diritto a non essere sottoposti a decisioni unicamente automatizzate(Art. 22). Il programma è governato dal DPO e riesaminato dal Titolare almeno annualmente.

• Monitoraggio continuo automatizzato: dashboard interne su tassi di consenso/revoca AI, volumi di trascrizione e retention effettiva, errori dei server function, esiti dei job di anonimizzazione/cancellazione (paragrafo 15.1), alert di sicurezza (accessi anomali, tentativi RLS-violation, spike di errori 401/403).
• Audit trimestrale sui contenuti AI: campionamento cieco di riassunti, trascrizioni e suggerimenti chat; misurazione di accuratezza, presenza di bias (linguistico, di genere, socio-sanitario) e tasso di correzione umana (paragrafo 14.3-ter). Deviazioni oltre soglia attivano il rollback del modello o l'aggiornamento del prompt/guardrail e sono verbalizzate nel registro audit AI.
• Verifica Art. 22 e human-in-the-loop: audit specifico che accerta, tramite ispezione dell'audit log, che nessuna decisione con effetti giuridici o significativi sia stata assunta unicamente su base automatizzata e che ogni output AI risulti validato da un operatore identificato. Le anomalie sono escalate al DPO e possono comportare la sospensione della funzionalità AI interessata.
• Data-minimization review semestrale (Art. 5.1.c): riesame degli schemi dati, dei campi raccolti, dei log applicativi e dei prompt inviati ai fornitori AI, con obiettivo di ridurre categorie, dettaglio e durata; le deliberazioni sono tracciate nel registro retention_reviews (paragrafo 15.1).
• Audit annuale sui diritti degli interessati (Artt. 15-22): campione casuale di richieste ricevute con verifica di tempi di riscontro, completezza, corretta identificazione, rispetto della portabilità (Art. 20) e dell'opposizione alla profilazione (Art. 21). Report al Titolare e al DPO.
• Audit tecnici di sicurezza (Art. 32): scansioni automatizzate delle dipendenze e delle configurazioni, penetration test almeno annuale su autenticazione, RLS e API pubbliche, verifica dei backup con test di ripristino, revisione delle chiavi e dei secret, controllo dei sub-processor (paragrafo 5) e delle TIA per i trasferimenti extra-UE (paragrafo 7).
• Riesame delle DPIA (Art. 35.11): riesame documentato ad ogni cambio sostanziale di fornitore AI, finalità o categorie di dati, e comunque almeno una volta l'anno. Le risultanze aggiornano le misure e, se necessario, l'informativa.
• Audit indipendenti e ispezioni dell'ente aderente: il Titolare consente all'ente aderente (contitolare) audit ragionevoli sulle attività di trattamento pertinenti (Art. 28.3.h) previa pianificazione con il DPO, e riconosce i poteri ispettivi del Garante (Art. 58).
• Gestione delle risultanze: ogni finding è classificato per gravità, assegnato ad un owner con scadenza (corrective action plan) e tracciato fino a chiusura; i rischi residui sono comunicati al Titolare e, se pertinenti agli interessati, riflessi nell'informativa e/o nella pagina Sicurezza.

Report sintetici anonimi sono resi disponibili al DPO (dpo@cooperiamoinsieme.it) e, su richiesta motivata, all'autorità di controllo. Gli interessati che desiderano esercitare i diritti di cui agli Artt. 15-22 — inclusa la contestazione di trattamenti automatizzati ex Art. 22 — possono usare i canali indicati in /diritti.

10.5 Mappatura delle misure Art. 32.1 GDPR: controlli tecnici e organizzativi

Sintesi delle misure tecniche e organizzative adottate ex Art. 32.1 GDPR, con riferimento espresso alle cinque aree indicate dalla norma (cifratura, pseudonimizzazione, backup e resilienza, test periodici, controllo accessi) e al principio di sicurezza by design and by default (Art. 25).

Le misure sono proporzionate al rischio (Art. 32.2) tenuto conto della natura sanitaria dei dati, della presenza di soggetti vulnerabili e dell'uso di sistemi AI (paragrafo 14). Sono riesaminate almeno annualmente e in occasione di modifiche rilevanti dell'infrastruttura, dei fornitori o del contesto normativo. Le risultanze dei test e degli audit alimentano il programma di miglioramento continuo descritto in paragrafo 10.4.

Dettagli tecnici aggiuntivi (headers, provider, certificazioni) sono pubblicati alla pagina Sicurezza. Segnalazioni di vulnerabilità: security@cooperiamoinsieme.it.

10.6 Revisione periodica della minimizzazione dei dati (Art. 5.1.c GDPR)

In attuazione del principio di minimizzazione (Art. 5.1.c GDPR), il Titolare esegue revisioni sistematiche e documentate di tutti i campi di raccolta e dei processi di trattamento, al fine di verificare che i dati personali — in particolare quelli appartenenti a categorie particolari ex Art. 9 — sianoadeguati, pertinenti e limitati a quanto strettamente necessario rispetto alle finalità dichiarate nel Registro dei trattamenti (paragrafo 4).

Cadenza e perimetro delle revisioni

Criteri di valutazione per ogni campo

• Necessità: il campo è indispensabile per la finalità dichiarata? Se no → rimozione o resa opzionale.
• Proporzionalità: il livello di dettaglio è minimo? (es. fascia d'età invece della data di nascita, coordinate arrotondate a 2 decimali nelle viste pubbliche).
• Base giuridica adeguata: la base ex Art. 6/9 copre effettivamente quel campo? In caso contrario → rimozione o raccolta previo consenso esplicito.
• Retention allineata: il campo è cancellato/anonimizzato al termine della finalità (paragrafo 15)?
• Alternative meno invasive: è possibile pseudonimizzare, aggregare o sostituire con placeholder (in particolare per input AI, paragrafo 14.6)?

Azioni conseguenti

Ogni revisione produce un piano d'azione tracciato che può includere: (a) rimozione di campi non più necessari, (b) conversione da obbligatori a opzionali, (c) riduzione della granularità (arrotondamento, categorizzazione), (d) anticipazione della retention, (e) pseudonimizzazione, (f) revisione delle RLS e delle viste pubbliche. Le modifiche sono versionate nelle migrazioni del database e riflesse nel Registro dei trattamenti (paragrafo 4) e nella presente informativa.

Il registro degli esiti (data, campo, decisione, evidenza tecnica) è conservato dal DPO e reso disponibile all'Autorità Garante su richiesta ex Art. 5.2 GDPR (accountability). Le risultanze confluiscono nel programma di monitoraggio continuo (paragrafo 10.4), nel riesame della DPIA (paragrafo 12.5) e nel riesame delle policy di conservazione (paragrafo 15.1).

10.7 Audit periodico dei permessi di accesso (Art. 5.1.f, Art. 32.1.b e 32.4 GDPR)

Data la natura collaborativa del servizio e la sensibilità dei dati clinico-sociali, i permessi di accesso assegnati ai diversi ruoli (familiare, operatore, medico, supervisore, admin) e le appartenenze alle crew degli assistiti sono sottoposti a audit periodico per garantire l'aderenza al principio del least privilege ed escludere accessi superflui, residui o non autorizzati.

Criteri di verifica

• Necessità: il ruolo è ancora funzionale a un compito assegnato? In caso contrario → revoca immediata.
• Livello minimo: il ruolo assegnato è il meno privilegiato tra quelli che consentono di svolgere il compito? (es. operatore anziché supervisore).
• Perimetro crew: l'appartenenza alla crew di un assistito è ancora giustificata dal rapporto di cura in essere?
• Attività: l'account risulta usato negli ultimi mesi? Ultimo sign-in anomalo o assente prolungato → sospensione preventiva.
• Separazione dei ruoli: nessun accumulo indebito (es. familiare che ha anche ruolo operativo su altri assistiti senza motivazione).

Evidenza e tracciabilità

Ogni sessione di audit è registrata nella tabella dedicata access_auditscon: chi ha condotto la revisione, quando, l'ambito verificato, lo snapshot dei totali per ruolo, le modifiche applicate e la data della prossima revisione (default: +6 mesi). Le operazioni di scrittura sono a loro volta tracciate nel registro audit_log. Admin e supervisore accedono al cruscotto operativo dalla sezione Admin → Audit accessi. Le risultanze confluiscono nel monitoraggio continuo (paragrafo 10.4) e, per anomalie strutturali, aggiornano la DPIA (paragrafo 12.5).

11. Cookie

E-CARE utilizza esclusivamente cookie tecnici e voci di localStorage necessari al funzionamento del servizio (sessione, preferenze, protezione CSRF sul checkout). Nessun cookie di profilazione, analytics di terze parti o tracciamento pubblicitario. Ai sensi delle linee guida del Garante Privacy del 10/06/2021, per i soli cookie tecnici non è richiesto banner con blocco preventivo; è comunque presente un avviso informativo nel footer del sito.

Puoi disabilitare o cancellare in qualsiasi momento cookie e voci di localStorage dalle impostazioni del tuo browser. La disabilitazione dei cookie tecnici può impedire l'accesso al servizio.

Gestisci le preferenze cookie — riapre il pannello di consenso granulare per modificare o revocare le tue scelte in qualsiasi momento (Art. 7(3) GDPR).

12. Valutazione d'Impatto sulla Protezione dei Dati (DPIA) — Estratto sintetico

Versione DPIA: 1.0 · Ultimo riesame: giugno 2026 · Prossimo riesame previsto: giugno 2027.

Cooperiamo Insieme — Cooperativa Sociale ONLUS ha effettuato una regolare Valutazione di Impatto sulla Protezione dei Dati (DPIA) ai sensi dell'art. 35 del Regolamento (UE) 2016/679 (GDPR) per il servizio E-CARE, implementando tutte le misure tecniche e organizzative necessarie a ridurre i rischi per gli assistiti e per gli altri interessati a un livello accettabile.

Perché E-CARE è soggetto a DPIA

La DPIA è stata redatta seguendo le linee guida WP248 rev.01 dell'EDPB e il modello del Garante Privacy italiano. Il trattamento ricade in più criteri congiunti:

• trattamento di dati relativi alla salute (categoria particolare ex Art. 9 GDPR);
• coinvolgimento di soggetti vulnerabili (assistiti anziani o non autosufficienti);
• uso di tecnologie innovative (assistenza AI su note vocali e riassunti clinico-sociali);
• trattamento su larga scala con incrocio di dataset (clinico, coordinamento crew, marketplace di assistenza).

Misure adottate

• cifratura TLS 1.3 in transito e AES-256 at-rest;
• Row-Level Security su ogni tabella con controllo granulare per ruolo;
• audit log versionato dei parametri vitali e delle modifiche clinico-sociali;
• consensi versionati e revocabili, con storicizzazione delle policy;
• funzioni di export e cancellazione dati (Artt. 15, 17, 20 GDPR) direttamente dal profilo;
• nessuna decisione automatizzata significativa ex Art. 22: l'AI è di supporto, non sostitutiva;
• hosting dei dati in UE con SCC per gli eventuali trasferimenti verso fornitori AI.

Il dettaglio tecnico è consultabile nella pagina Sicurezza. L'estratto pubblico della DPIA con criteri EDPB WP248, focus tematici e sintesi dei rischi valutati è disponibile alla pagina Valutazione d'Impatto sulla Protezione dei Dati.

12.1 Metodologia e approfondimento (Art. 35.7 GDPR)

La DPIA è stata condotta in modo approfondito e strutturato in conformità all'Art. 35.7 GDPR e alle linee guida EDPB WP248 rev.01, articolandosi nelle seguenti fasi documentate:

1. Descrizione sistematica dei trattamenti, delle finalità e dei legittimi interessi perseguiti (Art. 35.7.a): mappatura completa dei flussi dati, categorie di interessati, categorie di dati (incl. Art. 9), destinatari, tempi di conservazione.
2. Valutazione della necessità e proporzionalità (Art. 35.7.b): analisi delle basi giuridiche (paragrafo 4-4.1), test di minimizzazione, valutazione di alternative meno intrusive per ciascuna finalità (in particolare per la profilazione e la funzionalità AI).
3. Valutazione dei rischi per i diritti e le libertà degli interessati (Art. 35.7.c): identificazione delle minacce, valutazione di gravità e probabilità con matrice 5×5, calcolo del rischio inerente e residuo.
4. Misure previste per affrontare i rischi (Art. 35.7.d): garanzie, misure di sicurezza tecniche e organizzative, meccanismi di supervisione umana, procedure di reclamo.
5. Consultazione del DPO (Art. 35.2) e, se necessario, degli interessati o dei loro rappresentanti (Art. 35.9) tramite le crew familiari e gli enti aderenti.

12.2 Registro dei rischi ad alto impatto e misure di mitigazione documentate

Di seguito la sintesi dei principali rischi identificati per i trattamenti ad alto rischio (profilazione di dati sensibili di soggetti vulnerabili con supporto AI alla cura), con le rispettive misure tecniche e organizzative effettivamente implementatee i riferimenti alle evidenze operative.

Il registro completo dei rischi è gestito nella tabella dpia_risks con tracciamento delle misure, dei responsabili e delle date di verifica. Le evidenze di implementazione sono conservate nel sistema di audit e nella documentazione interna disponibile su richiesta al DPO.

12.3 Governance, riesame periodico e aggiornamento (Art. 35.11 GDPR)

La DPIA è oggetto di un ciclo di governance continuo che garantisce che rimanga aggiornata rispetto all'evoluzione dei trattamenti, delle tecnologie e del contesto di rischio:

• Riesame annuale programmato: revisione formale con verbale, coinvolgimento di DPO, Privacy Office, Responsabile IT e referenti clinici degli enti aderenti (tabella dpia_revisions).
• Riesame ad evento: attivato in caso di (i) nuova finalità o base giuridica, (ii) introduzione di nuovi fornitori/sub-responsabili AI, (iii) modifiche infrastrutturali significative, (iv) incidenti di sicurezza rilevanti, (v) evoluzioni normative o linee guida EDPB/Garante.
• Consultazione preventiva (Art. 36): procedura documentata per contattare l'Autorità Garante quando il rischio residuo rimane elevato dopo le misure di mitigazione.
• Metriche di controllo: KPI trimestrali su incidenti, richieste ex Artt. 15-22, esito dei test di sicurezza automatici e degli audit AI, riesaminati dal DPO.
• Registro delle revisioni versionato: ogni modifica della DPIA è tracciata con versione, data, autore, motivazione e diff rispetto alla versione precedente.

12.4 Evidenze di implementazione delle misure di mitigazione

Le misure identificate nella DPIA non restano teoriche: sono effettivamente implementate, monitorate e documentate. Le principali evidenze operative sono:

• Test automatici di RLS e mascheratura viste pubbliche eseguiti ad ogni deployment (funzioni test_dpia_config_rls, test_public_views_anon_masking) — output archiviati.
• Audit log append-only su tutte le operazioni sensibili (tabella audit_log, storicizzazione vital_measurements_history).
• Dashboard consensi AI per gli assistiti/familiari (/profilo/consensi-ai) e portale self-service dei diritti (/profilo/diritti).
• Registro delle violazioni (paragrafo 17) e procedura di notifica entro 72 ore.
• Formazione periodica del personale su AI, privacy e sicurezza (paragrafo 10.3), con tracciamento delle attestazioni.
• Riesami di retention annuali (tabella retention_reviews, cron gdpr-retention).
• Pen-test annuali e audit AI trimestrali con relazione al DPO.

L'estratto pubblico della DPIA, aggiornato all'ultima revisione, è disponibile alla pagina /dpia. La copia integrale — inclusi registro rischi, matrice di mitigazione e verbali di riesame — è fornita su richiesta motivata al Titolare o al DPO (privacy@cooperiamoinsieme.it).

12.5 DPIA come processo continuo (Art. 35.11 GDPR)

Coerentemente con l'Art. 35.11 GDPR e con le linee guida EDPB, la DPIA non è un adempimento una tantum ma un processo iterativo e permanente, integrato nel ciclo di vita del trattamento e dell'applicazione. Ciò è particolarmente rilevante per E-CARE, dato l'uso di AI per profilazione, alert clinici e supporto alla cura di soggetti vulnerabili.

Trigger che impongono un riesame straordinario

• Introduzione di nuove funzionalità AI (nuovi agenti, modelli, prompt di sistema, funzioni di scoring o classificazione).
• Cambio di fornitore o modello AI (es. nuova versione Gemini/OpenAI, nuovo sub-responsabile) o modifica delle condizioni di zero-retention.
• Estensione dei dati in input ai sistemi AI (nuove categorie di dati sanitari, note vocali, immagini) o delle finalità.
• Modifiche architetturali significative: nuovo datacenter, nuova regione di hosting, cambio di provider infrastrutturale.
• Nuove basi giuridiche o modifiche del perimetro di titolarità (nuovi enti aderenti, nuove crew, contitolarità Art. 26).
• Incidenti di sicurezza o data breach (Artt. 33-34) con impatto potenziale sui trattamenti valutati.
• Reclami sostanziali degli interessati o segnalazioni ricorrenti in merito a output AI (bias, errori, contestazioni ex Art. 22).
• Novità normative o giurisprudenziali (aggiornamenti EDPB, provvedimenti Garante, AI Act, nuove SCC/DPF).
• Superamento di soglie quantitative: crescita significativa del numero di assistiti trattati, dei volumi di note vocali o delle richieste AI.

Cadenza e responsabilità del ciclo continuo

Integrazione nel ciclo di sviluppo (Privacy by Design)

Ogni nuova funzionalità che tratta dati personali — e in particolare ogni nuova capacità AI — è sottoposta a una checklist di pre-DPIA prima del rilascio in produzione: descrizione del trattamento, categorie di dati, base giuridica, valutazione di necessità e proporzionalità, analisi rischi, misure tecniche/organizzative, parere del DPO. Se la checklist rileva rischi elevati o modifiche sostanziali del perimetro, il rilascio è subordinato all'aggiornamento della DPIA. I test automatici di sicurezza (test_dpia_config_rls,test_public_views_anon_masking) sono parte integrante della pipeline di deploy e rappresentano il controllo minimo di efficacia continuativa delle misure.

Verifica di efficacia delle misure di mitigazione

L'efficacia delle misure identificate non è assunta ma verificata periodicamente tramite: (i) test automatici di RLS e mascheratura ad ogni deployment, (ii) pen-test annuali indipendenti, (iii) audit AI trimestrali su un campione rappresentativo di output, (iv) analisi dei reclami e delle contestazioni ex Art. 22, (v) revisione delle metriche di retention (tabella retention_reviews). Eventuali deviazioni attivano azioni correttive tracciate e un aggiornamento della sezione «rischio residuo» della DPIA.

13. Rapporto con l'ente aderente — dettaglio del modello a tre ruoli

Come anticipato al paragrafo 1, E-CARE è utilizzata da enti aderenti (cooperative sociali, ASL, RSA, ADI, studi medici, famiglie organizzate in crew) che erogano il servizio di assistenza domiciliare al proprio assistito. La titolarità del trattamento è distribuita secondo il seguente schema.

13.1 Cooperiamo Insieme come Titolare autonomo (Art. 4.7 e 24)

Per i dati generati dall'uso della piattaforma — account, autenticazione, consensi versionati, log tecnici e di sicurezza, audit log, chat con l'assistente AI di piattaforma, file audio delle note vocali in fase di trascrizione, marketplace lavoro, fatturazione dell'abbonamento — Cooperiamo Insieme determina in autonomia finalità e mezzi.

Impatto sui diritti: l'interessato esercita i diritti Art. 15–22 direttamente verso Cooperiamo Insieme (self-service da Profilo → I tuoi dati personali (GDPR), email a privacy@cooperiamoinsieme.ito alla pagina Esercita i tuoi diritti).

13.2 Cooperiamo Insieme come Responsabile del trattamento (Art. 28)

Per i dati clinico-sociali dell'assistito (dati anagrafici del paziente, parametri vitali, terapie e prescrizioni, diario clinico-sociale, calendario appuntamenti, testo trascritto delle note vocali), il Titolare autonomo è l'ente aderente, perché è quest'ultimo che determina finalità (cura, presa in carico) e mezzi organizzativi, e che mantiene il rapporto diretto con l'interessato. Cooperiamo Insieme tratta questi dati esclusivamente per conto dell'ente aderente, in forza di un Data Processing Agreement (DPA) ex Art. 28.3 che disciplina:

• oggetto, durata, natura e finalità del trattamento;
• istruzioni documentate del titolare;
• obblighi di riservatezza del personale autorizzato;
• misure di sicurezza (Art. 32) — vedi Sicurezza;
• ricorso a sub-responsabili con autorizzazione preventiva (vedi paragrafo 5);
• assistenza al titolare per riscontro alle richieste degli interessati e per obblighi ex Artt. 32–36 (data breach, DPIA);
• restituzione o cancellazione dei dati al termine del rapporto;
• audit e ispezioni.

Impatto sui diritti: per queste categorie l'interessato deve rivolgersi all'ente aderente titolare. Cooperiamo Insieme offre gli strumenti tecnici di export/cancellazione tramite la piattaforma, ma la decisione sostanziale (cancellazione anticipata, portabilità, limitazione, opposizione) compete al titolare. Se ricevi una richiesta tramite E-CARE, la inoltriamo all'ente aderente entro 72 ore (Art. 28.3.e) e ne conserviamo traccia in audit log. I contatti dell'ente titolare sono forniti al momento della presa in carico e comunque disponibili nella sezione Profilo → Enti collegati.

13.3 Cooperiamo Insieme e ente aderente come Contitolari (Art. 26)

Per alcune attività finalità e mezzi sono determinati congiuntamente: in questi casi Cooperiamo Insieme e l'ente aderente sono contitolariex Art. 26 GDPR. Rientrano in questa categoria:

• Suggerimenti clinici prodotti dagli agenti AI: Cooperiamo Insieme definisce il modello, i prompt di sistema, i limiti di sicurezza; l'ente aderente stabilisce i casi d'uso ammessi, la supervisione medica e la validazione umana degli output.
• Alert automatici sui parametri vitali: Cooperiamo Insieme fornisce l'algoritmo di soglia; l'ente configura i valori clinici specifici per ogni assistito e i destinatari degli alert.

È stipulato un accordo di contitolarità ex Art. 26.1 che ripartisce le rispettive responsabilità in materia di trasparenza, esercizio dei diritti e riscontro agli interessati. Il contenuto essenziale dell'accordo è messo a disposizione degli interessati su richiesta (Art. 26.2) scrivendo a privacy@cooperiamoinsieme.it.

Impatto sui diritti: per le attività in contitolarità l'interessato può esercitare i propri diritti indifferentemente presso Cooperiamo Insieme o presso l'ente aderente (Art. 26.3); i due contitolari cooperano internamente per fornire un riscontro unitario.

13.4 Caso particolare: Titolare unico

Quando l'ente aderente coincide con Cooperiamo Insieme (utilizzo diretto della piattaforma per assistiti presi in carico dalla cooperativa), Cooperiamo Insieme è Titolare unico per tutte le categorie e il modello a tre ruoli si collassa in un solo interlocutore.

L'informativa privacy specifica dell'ente aderente prevale, per le finalità di cura, su quanto qui indicato: la presente informativa integra e non sostituisce quella consegnata dall'ente al momento della presa in carico. In caso di conflitto apparente contatta prima il tuo ente aderente; Cooperiamo Insieme, come responsabile o contitolare, offre comunque supporto operativo.

14. Agenti AI, logica algoritmica e base giuridica

14.1 Principi generali

• Nessuna decisione unicamente automatizzata ex Art. 22 GDPR. Ogni output degli agenti AI di E-CARE è un suggerimento che deve essere rivisto, corretto o rifiutato da una persona (operatore, medico, supervisore) prima di produrre effetti sull'assistito o sull'utente.
• Nessuna profilazione ex Art. 4(4) GDPR per finalità di marketing, scoring creditizio, valutazione automatizzata della persona, discriminazione o selezione senza intervento umano.
• Doppia base giuridica per il trattamento di dati sanitari tramite AI:
  • Art. 9(2)(h) GDPR — finalità di assistenza e cura, sotto responsabilità del personale sanitario e socio-assistenziale tenuto al segreto professionale (base primaria, sempre applicabile).
  • Art. 9(2)(a) GDPR — consenso esplicito, specifico e granulare per singolo assistito, raccolto dall'assistito o dal suo rappresentante legale (tutore, amministratore di sostegno, familiare delegato) e non dall'operatore. Il consenso è richiesto per ciascuna funzione AI (trascrizione note vocali, estrazione parametri, riassunti clinici, chat, alert automatici) e viene registrato nella scheda dell'assistito con firmatario, ruolo, evidenza (es. firma cartacea o conferma orale documentata), versione policy, timestamp, IP e user-agent. Costituisce una tutela aggiuntiva sopra la base primaria 9(2)(h): la sua eventuale mancanza disattiva le funzioni AI per quell'assistito ma non pregiudica il diritto all'assistenza, che prosegue con le funzioni deterministiche.
• Diritto di opposizione e revoca (Art. 7 comma 3 GDPR). Il consenso AI è revocabile in qualsiasi momento dalla scheda dell'assistito (sezione «Consenso AI») oppure scrivendo al DPO (dpo@cooperiamoinsieme.it). La revoca è facile come la concessione, non richiede giustificazione e produce effetto immediato: la funzione AI corrispondente viene disattivata per quel singolo assistito, gli output storici già prodotti restano nel diario con la loro attribuzione oppure vengono anonimizzati secondo paragrafo 6.
• Onere della prova (Art. 7 comma 1 GDPR). Ogni consenso raccolto è tracciato in modo append-only: ogni cambiamento di stato (concessione, revoca, rinnovo alla nuova versione policy) genera una nuova riga con timestamp, firmatario e IP. Nessuna riga viene sovrascritta.

14.2 Elenco degli agenti AI

14.3 Logica algoritmica in dettaglio

• Gli LLM sono utilizzati come strumenti di traduzione linguistica (audio→testo, testo→sintesi, testo→campi strutturati), non come sistemi decisionali. Non producono diagnosi, prescrizioni, valutazioni di idoneità o punteggi.
• Nessun modello ML è addestrato o fine-tuned sui dati degli assistiti E-CARE. Utilizziamo esclusivamente modelli generali forniti dai sub-responsabili.
• Opt-out training attivo lato provider AI (Google Gemini, OpenAI) per tutti i dati inviati attraverso il gateway: i contenuti non concorrono all'addestramento dei modelli.
• Nessun dato sanitario è inviato all'agente di matching marketplace: quel modulo lavora solo su profili pubblici e criteri dichiarati dall'utente.
• Minimizzazione dell'input: al modello è inviato solo il testo strettamente necessario alla finalità. Identificativi diretti non essenziali (nome, indirizzo, codice fiscale) sono sostituiti con placeholder quando possibile.
• Trasferimenti extra-UE verso Google/OpenAI (USA) coperti da SCC UE 2021/914 e misure supplementari; vedi paragrafo 7.
• Log e audit: le invocazioni AI sono tracciate nel log applicativo del gateway (metadati tecnici, non contenuto) per finalità di sicurezza e conformità.

14.3-bis Descrizione per singolo agente

I paragrafi seguenti dettagliano — per ciascuno degli agenti richiamati dalla checklist di trasparenza — finalità, categorie di dati coinvolte (con richiamo esplicito all'Art. 9 GDPR), logica applicata, limiti dichiarati e ruolo dell'operatore. La sintesi tabellare resta al paragrafo 14.2; la vista Art. 13-14 paragrafo 2(f) con conseguenze e salvaguardie è al paragrafo 14.5.

Riassunto giornaliero clinico-sociale

• Finalità: fornire all'operatore una sintesi leggibile del turno / del periodo, per accelerare la lettura della cartella.
• Categorie di dati: identificativi dell'assistito, dati sanitari (Art. 9 GDPR) — parametri vitali, terapie, note diaristiche — già presenti in cartella. Nessun dato biometrico, genetico, di orientamento sessuale, politico o religioso.
• Logica applicata: sintesi estrattiva. Il modello riformula e condensa testi già registrati, senza aggiungere diagnosi, prescrizioni, prognosi, punteggi di rischio o giudizi di idoneità.
• Limiti dichiarati: l'output può contenere imprecisioni linguistiche; non è un referto, non ha valore clinico autonomo, non entra in cartella se non validato.
• Ruolo umano: l'operatore legge il riassunto a schermo; nessuna scrittura automatica in cartella. Disclaimer permanente "suggerimento AI da validare".

Alert intelligenti sui parametri vitali

• Finalità: segnalare all'operatore valori fuori soglia (PA, FC, SpO2, T°, glicemia) per accelerare la valutazione clinica.
• Categorie di dati: identificativi minimi dell'assistito e parametri vitali (Art. 9 GDPR) registrati manualmente o da dispositivi domiciliari. Nessuna inferenza su etnia, religione, orientamento, opinioni politiche, disabilità non dichiarate.
• Logica applicata: deterministica. Confronto dei valori misurati con soglie configurate dalla crew clinica (soglie generali + eventuali soglie personalizzate). Nessun modello predittivo o ML addestrato sull'assistito; nessun LLM in questa funzione.
• Limiti dichiarati: le soglie sono orientative e non sostituiscono il giudizio clinico. Falsi positivi e falsi negativi sono possibili in funzione della qualità della misurazione.
• Ruolo umano: l'alert è una notifica, non un'azione. Nessuna chiamata automatica al 118, nessuna somministrazione, nessuna modifica di terapia. L'operatore decide l'intervento e lo registra nel diario.

Chat assistente (chat AI di supporto)

• Finalità: rispondere a domande dell'operatore su un assistito specifico (con contesto di cartella scoped alla sola persona interrogata) o su procedure generali.
• Categorie di dati: contenuto della domanda dell'operatore + contesto minimo tratto dalla cartella dell'assistito citato (potenzialmente dati sanitari Art. 9). Nessun accesso trasversale a cartelle di altri assistiti.
• Logica applicata: LLM generale di terzi (Google Gemini / OpenAI via Lovable AI Gateway) con prompt che vincola il modello a un ruolo di supporto informativo; disclaimer permanente "non sostituisce il giudizio clinico"; opt-out training attivo lato provider.
• Limiti dichiarati: il modello può produrre "allucinazioni" o affermazioni imprecise; non conosce l'evoluzione clinica oltre al contesto passato; non esegue né suggerisce prescrizioni. Le sue risposte non sono referti né consulenze cliniche.
• Ruolo umano: l'operatore valuta e verifica prima di agire. Nessuna azione sull'assistito è automatica. Le interazioni sono registrate come diario per tracciabilità.

Note vocali con AI (trascrizione + estrazione parametri)

• Finalità: convertire in testo la nota vocale dell'operatore e proporre valori dei parametri riconosciuti nel testo.
• Categorie di dati: voce dell'operatore; testo trascritto che può contenere dati sanitari (Art. 9) dell'assistito citato. Nessuna analisi biometrica del timbro né identificazione vocale.
• Logica applicata: (i) servizio ASR speech-to-text; (ii) estrazione strutturata dei parametri con schema Zod che vincola le chiavi ammesse (PA, FC, SpO2, T°, glicemia) e unità/range plausibili. Nessuna inferenza clinica, nessuna correlazione automatica con la terapia in corso.
• Limiti dichiarati: la trascrizione può contenere errori linguistici; l'estrazione può omettere valori o proporne di errati se la nota è ambigua. L'audio è scartato subito dopo la trascrizione.
• Ruolo umano: rilettura obbligatoria del testo trascritto prima del salvataggio; conferma esplicita per ciascun valore estratto. Nessun salvataggio automatico in cartella.

14.3-ter Accuratezza e non discriminazione (Art. 5.1.a, 5.1.d GDPR, Considerando 71)

Anche se gli agenti AI di E-CARE non adottano decisioni unicamente automatizzate ex Art. 22 comma 1, adottiamo per prassi le salvaguardie previste dal Considerando 71 e dai principi di esattezza (Art. 5.1.d) e correttezza e trasparenza (Art. 5.1.a).

Misure per l'accuratezza

• Revisione umana obbligatoria (Art. 22 comma 3): ogni output AI è un suggerimento; l'ingresso in cartella richiede una conferma esplicita dell'operatore identificato a log.
• Estrazione parametri vincolata da schema Zod: chiavi ammesse limitate (PA, FC, SpO2, T°, glicemia), unità di misura e range plausibili; valori fuori range sono contrassegnati e richiedono conferma esplicita.
• Riassunti in modalità estrattiva: il modello sintetizza contenuti già presenti in cartella e non è istruito a produrre diagnosi, prognosi o punteggi.
• Alert su soglie deterministiche configurabili dalla crew clinica, non su modelli predittivi né su reti neurali addestrate sull'assistito.
• Disclaimer permanenti sugli output ("suggerimento AI da validare", "non sostituisce il giudizio clinico") per contestualizzare il livello di affidabilità.
• Audit log delle invocazioni AI: operatore, timestamp, agente, esito (conferma / correzione / rifiuto). Consente revisione qualità e individuazione di pattern di errore.
• Diritto di rettifica (Art. 16): dalla scheda dell'assistito è possibile correggere o cancellare l'output AI; l'operatore validatore resta identificato.
• Revisione periodica di prompt di sistema, disclaimer e schemi di estrazione da parte del Titolare in coordinamento con la crew clinica.

Misure per la non discriminazione

• Nessuna profilazione ex Art. 4(4) per marketing, scoring, valutazione della persona, selezione automatica di assistiti o operatori; principio esplicitato in paragrafo 14.1.
• Divieto di inferenza su categorie protette: gli agenti non sono istruiti a dedurre né esporre origine etnica, religione, opinioni politiche, appartenenza sindacale, orientamento sessuale, dati genetici o convinzioni filosofiche.
• Nessun addestramento sui dati degli assistiti: utilizziamo modelli generali di terzi; opt-out training contrattuale con i fornitori (Google, OpenAI). Il modello non è adattato al singolo assistito.
• Nessuna decisione unicamente automatizzata con effetti giuridici o significativi (Art. 22 comma 1): l'intervento umano identificato a log è obbligatorio per ogni azione sull'assistito o sull'operatore.
• Marketplace lavoro: il matching opera su criteri dichiarati dall'utente (città, mansioni, disponibilità), senza dati sanitari e senza LLM che decidono ammissione o esclusione.
• Kill-switch server-side: in assenza o revoca del consenso AI, le server function AI ritornano 403 senza inviare dati al modello, indipendentemente dall'UI.
• Contestazione e reclamo: canale dedicato al DPO (dpo@cooperiamoinsieme.it) per segnalare esiti percepiti come iniqui, discriminatori o inaccurati. Vedi anche paragrafo 16.

14.3-quater Supervisione umana degli output AI: ruoli, responsabilità e workflow (Art. 22 comma 3 GDPR)

A garanzia dell'Art. 22 comma 3 GDPR e del principio di human-in-the-loop, ogni output prodotto dagli agenti AI di E-CARE (alert, riassunti, estrazioni di parametri, suggerimenti operativi, risposte del chat assistente) è trattato come proposta e non può produrre effetti sull'assistito senza revisione e validazione esplicita di un operatore umano qualificato, identificato e tracciato a log.

Ruoli e responsabilità nel processo di supervisione

Workflow di validazione (per tutti gli output AI)

1. Generazione: l'agente AI produce l'output, marcato in UI come «suggerimento AI da validare» e non ancora vincolante.
2. Revisione: l'operatore qualificato ne verifica accuratezza, completezza, pertinenza clinica e coerenza con la fonte (voce, diario, cartella).
3. Validazione o correzione: l'operatore conferma, modifica o rifiuta. Solo la versione validata entra in cartella o attiva notifiche/azioni.
4. Escalation clinica: per alert su soglie critiche o suggerimenti che impattano terapie, la validazione richiede un profilo medico o infermiere abilitato.
5. Tracciamento: l'audit log registra agente, input (senza esporre dati sensibili in chiaro), operatore validatore, timestamp, esito (conferma/correzione/rifiuto) e — quando applicabile — motivazione della correzione.
6. Contestazione ex post: l'interessato o il DPO possono chiedere revisione ulteriore; l'output può essere rettificato o cancellato (Art. 16-17 GDPR) mantenendo l'audit trail.

Garanzie tecniche di enforcement

• UI: gli output AI sono resi in stato pending con azione esplicita «Conferma» / «Correggi» / «Scarta»; nessun salvataggio silente.
• Server: le mutazioni sui dati dell'assistito richiedono l'identità dell'operatore validatore (RLS + audit log), impedendo l'ingresso di dati non validati.
• Kill-switch consenso: revocato il consenso AI, gli agenti vengono disattivati server-side (403) — vedi paragrafo 14.1.
• Formazione e autorizzazione: solo gli operatori con formazione aggiornata (vedi paragrafo 10.3) possono validare; gli account non conformi sono sospesi.
• Verifica periodica dell'efficacia: audit trimestrale sul tasso di correzione umana e sul rispetto del workflow (vedi paragrafo 10.4).

14.3-quinquies Monitoraggio continuo dei sistemi AI e riesame periodico della DPIA (Artt. 5.1.d, 22, 32, 35 GDPR)

Data la natura sensibile dei dati trattati e l'uso estensivo dell'AI per profilazione, alert e supporto decisionale, il Titolare ha adottato uno specifico programma di monitoraggio continuo dei sistemi AI e di riesame periodico della DPIA, in aggiunta al programma trasversale di cui al paragrafo 10.4.

• Metriche AI monitorate in continuo: accuratezza rispetto al ground truth clinico, tasso di correzione/scarto da parte dell'operatore, falsi positivi/negativi degli alert, indicatori di bias (linguistico, di genere, socio-sanitario), latenza e tasso di errore delle chiamate ai fornitori, volumi di dati inviati (per verifica minimizzazione ex Art. 5.1.c).
• Audit trimestrale indipendente sui modelli AI (Art. 5.1.d, Considerando 71): campionamento cieco di output, valutazione da parte di validatore clinico e verifica statistica del bias tra sotto-gruppi. Deviazioni oltre soglia attivano rollback del modello, aggiornamento dei prompt/guardrail o disattivazione dell'agente.
• Verifica Art. 22: audit del log dimostra che ogni output AI con impatto significativo risulti validato da operatore identificato; le eccezioni sono escalate al DPO e possono comportare la sospensione della funzionalità.
• Misure di sicurezza AI (Art. 32): verifica periodica di autenticazione dei server function AI, RLS sulle tabelle di consenso/output, cifratura in transito, opt-out training verso i fornitori (paragrafo 14.6), gestione delle chiavi e dei secret, review dei sub-processor.
• Riesame periodico della DPIA (Art. 35.11): revisione documentata almeno annuale e comunque ad ogni evento rilevante — nuovo agente AI o fornitore, cambio di finalità o categorie di dati, incidente di sicurezza, modifica normativa (es. Reg. UE 2024/1689 AI Act) o parere del Garante. Il verbale di riesame aggiorna rischi, misure e, se necessario, l'informativa; l'estratto pubblico è consultabile alla pagina /dpia.
• Trasparenza degli esiti: report sintetici anonimi sono disponibili al DPO (dpo@cooperiamoinsieme.it) e, su richiesta motivata, all'autorità di controllo; gli interessati possono richiedere sintesi delle verifiche AI che li riguardano tramite /diritti.

14.4 Diritti specifici sull'uso dell'AI

• Spiegazione: puoi chiedere all'operatore che ha validato l'output AI di illustrarti la logica dell'agente e i motivi della conferma; la sintesi di funzionamento di ogni agente è riportata in paragrafo 14.2.
• Contestazione (Art. 16 GDPR): puoi contestare un valore proposto dall'AI e chiederne la correzione o cancellazione. La revisione umana obbligatoria rende ogni valore attribuibile a un operatore identificato nell'audit log.
• Revoca del consenso (Art. 7 comma 3): dalla scheda dell'assistito, sezione «Consenso AI», è possibile revocare in qualsiasi momento e in modo granulare (per singola funzione AI) il consenso; le funzioni AI corrispondenti vengono disattivate server-side immediatamente per quell'assistito, senza pregiudicare la continuità dell'assistenza (che prosegue con le funzioni deterministiche).
• Intervento umano: è garantito per costruzione — nessun output AI produce effetti senza che una persona lo abbia validato.
• Reclamo al Garante o al DPO, come per gli altri diritti (vedi paragrafo 16).

14.5 Profilazione AI: finalità, dati, base giuridica, logica e conseguenze (Art. 13-14 paragrafo 2(f), Art. 22 GDPR)

Gli agenti AI di E-CARE non effettuano profilazione automatizzata con effetti giuridici o significativi analoghi ex Art. 22 comma 1 GDPR: producono suggerimenti soggetti a revisione umana obbligatoria e non generano scoring, diagnosi, prescrizioni, decisioni di ammissione/dimissione, sospensione di servizi o sanzioni. La descrizione che segue è resa in conformità al principio di trasparenza (Art. 5.1.a) e agli obblighi informativi rafforzati di Art. 13-14 paragrafo 2(f) — logica utilizzata, importanza e conseguenze previste — anche laddove l'Art. 22 non trovi applicazione, quale ulteriore tutela per l'interessato.

Salvaguardie contro decisioni unicamente automatizzate (Art. 22 comma 3 GDPR)

• Divieto interno di configurare workflow in cui un output AI produca autonomamente effetti giuridici o significativi (modifiche terapia, dimissioni, sospensione servizi, sanzioni disciplinari, valutazioni di idoneità) senza validazione umana identificata a log.
• Etichettatura in UI e nel diario: ogni output è marcato come "suggerimento AI da validare" e riporta a log l'operatore validatore, il timestamp e la versione dell'agente.
• Intervento umano garantito: l'interessato o il suo rappresentante può richiedere che una specifica valutazione sia riesaminata da un operatore identificato, esprimere il proprio punto di vista, contestare il risultato e ottenere spiegazione della logica applicata (canale operativo: operatore referente dell'ente aderente + DPO, cfr. paragrafo 16).
• Kill-switch per assistito: la revoca granulare del consenso 9.2.a disattiva server-side la funzione AI corrispondente per quell'assistito. L'assistenza prosegue con funzioni deterministiche, senza pregiudizio sulla continuità del servizio.
• Alert = notifiche, non azioni: gli alert automatici su parametri vitali generano solo notifiche verso l'operatore. Nessun sistema di E-CARE effettua chiamate al 118, somministrazioni, modifiche di terapia o comunicazioni verso terzi in modo automatico.
• Monitoraggio degli output: la crew supervisiona periodicamente qualità e coerenza degli output AI (cfr. valutazione d'impatto in /dpia); in caso di anomalie o bias osservati, l'agente può essere disattivato a livello di piattaforma o di ente aderente.
• Nessun addestramento sui dati degli assistiti (opt-out training presso i sub-responsabili); nessun modello ML proprietario addestrato su dati sanitari dei nostri assistiti.

La logica sintetica di ciascun agente è riportata anche in paragrafo 14.2; la valutazione d'impatto sulla protezione dei dati (DPIA) — inclusi rischi residui e misure di mitigazione — è consultabile alla pagina /dpia.

14.6 Fornitori AI, natura dei servizi e garanzie (Artt. 13.1.e, 28 GDPR)

I servizi di trascrizione, estrazione strutturata, riassunti e chat AI non sono sviluppati né erogati internamente da Cooperiamo Insieme. Utilizziamo modelli generali di terze parti, accessibili attraverso il Lovable AI Gateway, che opera da orchestratore senza conservare i contenuti trattati.

Responsabilità e garanzie indipendenti dalla localizzazione. Le garanzie contrattuali (DPA ex Art. 28.3 GDPR, istruzioni scritte del Titolare, obbligo di riservatezza, assistenza agli interessati, notifica di data breach, cancellazione al termine) si applicano a tutti i sub-responsabili AI, indipendentemente dal fatto che il trattamento avvenga in UE, nel SEE o in un paese terzo. Le Clausole Contrattuali Standard (SCC UE 2021/914) e la decisione di adeguatezza UE–USA (Data Privacy Framework) sono garanzie aggiuntive che si attivano quando e per la sola parte in cui i dati escono dal SEE (Capo V GDPR).

• Lovable AI Gateway — UE (orchestrazione): gateway di instradamento verso i modelli; non conserva audio né testo dei prompt dopo l'elaborazione.
• Google LLC (Gemini) — US/UE a seconda della region del modello. Sub-responsabile ex Art. 28 per trascrizione, riassunti ed estrazione.
• OpenAI, L.L.C. — US: modelli di trascrizione (es. gpt-4o-mini-transcribe) e generazione testuale. Sub-responsabile ex Art. 28.

Il Titolare del trattamento dei dati degli assistiti resta Cooperiamo Insieme (o l'ente aderente per la parte clinico-sociale, cfr. paragrafo 1 e paragrafo 13); i fornitori AI sopra elencati sono sempre Responsabili/Sub-responsabili ex Art. 28 GDPR — mai co-titolari né titolari autonomi dei dati AI degli assistiti. La tabella riflette le configurazioni contrattuali attualmente in essere; eventuali variazioni sostanziali (sostituzione fornitore, cambio di region, modifica dei termini di retention/training) comportano aggiornamento della presente informativa e, se applicabile, notifica ex paragrafo 18 e ri-raccolta del consenso ex paragrafo 14.7. Elenco consolidato di tutti i sub-responsabili al paragrafo 5; mappa dei trasferimenti extra-UE al paragrafo 7; misure di accuratezza e non discriminazione al paragrafo 14.3-ter.

Le garanzie applicate ai sensi degli Artt. 13.1.e e 28 GDPR sono:

• Data Processing Agreement (DPA) ex Art. 28.3 con ciascun fornitore, che disciplina oggetto, durata, natura, finalità, obblighi di riservatezza e assistenza agli interessati.
• Clausole Contrattuali Standard (SCC UE 2021/914) per i trasferimenti verso gli Stati Uniti; come fallback/additivo, la decisione di adeguatezza UE–USA (Data Privacy Framework) per i fornitori che vi aderiscono.
• Zero-retention contrattuale: audio e testo inviati ai modelli non sono conservati dai provider dopo la risposta, salvo quanto tecnicamente necessario per la sola transazione in corso.
• Opt-out dall'addestramento: i contenuti trasmessi non concorrono all'addestramento, al fine-tuning né alla creazione di modelli di terze parti.
• Misure tecniche: cifratura in transito (TLS 1.2+), cifratura at-rest lato provider, minimizzazione dell'input (ad es. nomi sostituiti con placeholder quando possibile), pseudonimizzazione degli identificativi diretti, audit log delle invocazioni.
• Sub-processing: Cooperiamo Insieme mantiene un elenco aggiornato dei sub-responsabili AI (paragrafo 5) e notifica eventuali aggiunte all'ente aderente con adeguato preavviso, come previsto dal DPA.

La mappa completa dei trasferimenti extra-UE e le misure supplementari post-Schrems II sono al paragrafo 7. La tabella consolidata di tutti i sub-responsabili per categoria (con localizzazione e garanzie) è al paragrafo 5. Il modulo di consenso granulare per assistito è al paragrafo 14.7.

14.7 Come raccogliamo il consenso (Art. 7, Art. 9.2.a GDPR)

• Chi firma: l'assistito capace di intendere e volere firma personalmente. In caso di incapacità totale o parziale, firma il rappresentante legale (tutore, amministratore di sostegno con poteri specifici in materia di salute e privacy, familiare delegato con documentazione). Il ruolo del firmatario è registrato esplicitamente nella scheda del consenso.
• Forma: consenso esplicito ex Art. 9.2.a — non desumibile dal silenzio, dall'inattività o da opzioni preselezionate. L'evidenza di raccolta (firma cartacea archiviata dall'ente aderente, conferma orale davanti a due operatori, videochiamata registrata, modulo digitale firmato) è documentata al momento della registrazione.
• Granularità: consenso separato per ciascuna funzione AI — non è ammesso un consenso cumulativo. L'assistito può, ad esempio, autorizzare la trascrizione delle note vocali ma rifiutare la chat AI.
• Informazione preventiva: prima del consenso l'operatore illustra al firmatario finalità, dati trattati, sub-processori (Lovable AI Gateway → Google/OpenAI, USA, coperti da SCC), natura non-clinica e non-decisionale dell'output, durata, modalità di revoca e conseguenze della revoca. La checklist di conferma è integrata nel modulo di raccolta.
• Enforcement tecnico: le server function AI verificano il consenso corrente prima di eseguire il trattamento. In assenza di consenso attivo, l'invocazione ritorna un errore 403 Consenso mancante e nessun dato dell'assistito viene inviato al modello.
• Rinnovo: quando cambia sostanzialmente il testo dell'informativa o la lista dei sub-processori, viene incrementata la versione policy e il consenso viene ri-raccolto. I consensi legati a versioni precedenti restano nella cronologia come prova storica ma non abilitano più il trattamento sulla nuova versione.
• Rapporto con l'Art. 9.2.h: il consenso 9.2.a non sostituisce e non deroga alla base primaria 9.2.h; ne è complemento specifico per l'uso di sistemi AI. Se il rappresentante legale rifiuta il consenso AI, il trattamento sanitario "manuale" (senza AI) prosegue normalmente sotto 9.2.h e nel rispetto degli obblighi professionali della crew.

Note vocali: disattivazione, cancellazione, anonimizzazione (Art. 7.3, 15, 17 GDPR)

Il trattamento «note vocali con AI» è tra i più sensibili trattati dalla piattaforma: per questa ragione ogni assistito (o il suo rappresentante legale) dispone in-app di tre controlli distinti e sempre accessibili, senza doverli richiedere via email:

• Disattivare le note vocali per l'assistito (Art. 7.3 — revoca del consenso): dalla scheda dell'assistito, sezione «Consenso AI», è sufficiente revocare la funzione «Trascrizione automatica delle note vocali». Da quel momento la server function verifica il consenso e blocca ogni ulteriore registrazione con errore 403 Consenso mancante, senza inviare nulla al modello AI. La disattivazione è immediata e non pregiudica l'assistenza, che prosegue con annotazioni manuali. Anche «Estrazione AI di parametri vitali» può essere revocata separatamente.
• Cancellare le note vocali già salvate (Art. 17): dalla scheda dell'assistito, sezione «Note vocali dell'assistito», il pulsante «Cancella tutte le note vocali» rimuove definitivamente i record voice_recordings(id, autore, trascrizione, valori proposti). L'audio originale non è conservato (viene scartato al termine della trascrizione), quindi la cancellazione riguarda il testo trascritto e i metadati. I dati clinici già validati e confluiti nel diario o nei parametri vitali restano — sono di titolarità dell'ente aderente (paragrafo 5) e vengono rettificati o cancellati usando le sezioni corrispondenti.
• Anonimizzare le trascrizioni: la stessa sezione consente di azzerare testo trascritto ed estrazione AI preservando la traccia dell'evento (data, operatore). È la scelta preferita quando l'interessato chiede di rimuovere il contenuto ma il Titolare deve dimostrare che una registrazione era avvenuta (Art. 5.2 — accountability).

Le operazioni di cancellazione e anonimizzazione sono tracciate in audit log (attore, tipo di azione, numero di record impattati) e possono essere richieste dall'assistito, dal rappresentante legale, o eseguite direttamente da admin / creatore della scheda / supervisore / medico di crew. Un familiare delegato può chiederle contattando l'operatore di riferimento o il DPO (dpo@cooperiamoinsieme.it). Il Titolare risponde entro 30 giorni (Art. 12.3) — di norma in giornata.

Una dashboard consolidata nella sezione Profilo permette a operatori, supervisori e familiari di verificare in un colpo d'occhio, per ciascun assistito accessibile, quali funzioni AI sono attivate, chi ha firmato il consenso e quando, e di aprire la scheda per revocare o raccoglierlo.

I fornitori AI (Google, OpenAI) operano come sub-responsabili sotto DPA e SCC UE 2021/914 per gli eventuali trasferimenti extra-SEE. Il Titolare seleziona i modelli tenendo conto di garanzie di riservatezza, opt-out training e stabilità operativa.

15. Tempi di conservazione per categoria

In conformità con l'Art. 5.1.e (limitazione della conservazione) e con l'obbligo informativo previsto dall'Art. 13.2.a GDPR, la tabella seguente indica il periodo di conservazione — o i criteri per determinarlo — per ciascuna categoria di dati personali trattati da E-CARE. Le durate riportate coincidono con i job di cancellazione automatica documentati nella pagina Sicurezza(retention hook eseguito ogni ora). Per il quadro generale — principi, criteri, titolarità e modalità di cancellazione — vedi il paragrafo 6 di questa informativa.

Nota. Le durate elencate sono i massimi contrattuali applicati dalla piattaforma E-CARE. Per i dati clinico-sociali (diario, terapie, parametri vitali, dati anagrafici del paziente) l'ente aderente — titolare autonomo ex Art. 24 GDPR — può definire policy interne più restrittive nel proprio ambito di titolarità, entro i minimi imposti dalla normativa sanitaria.

Al termine dei periodi indicati i dati sono cancellati o anonimizzati in modo irreversibile tramite job cron orari (soft delete → hard delete definitivo). Puoi richiedere la cancellazione anticipata dei tuoi contenuti dalla sezione Profilo → I tuoi dati personali (GDPR). Alcuni dati clinico-sociali sono di titolarità della cooperativa e non possono essere cancellati prima della scadenza degli obblighi documentali sanitari.

15.1 Revisione periodica delle policy di conservazione (Artt. 5.1.e, 5.2, 24 GDPR)

Le durate elencate nella tabella paragrafo 15 sono soggette a revisione formale annualea cura del DPO, per verificare l'allineamento a normativa vigente (GDPR, Codice Privacy d.lgs. 196/2003, normativa sanitaria nazionale e regionale, Provv. Garante 27/11/2008, Art. 2220 c.c.) e alle finalità dichiarate al paragrafo 3. Ogni revisione è tracciata nel registro interno retention_reviews con revisore, data, esito (confirmed / updated / escalated), sintesi delle modifiche e data della revisione successiva, in adempimento del principio di accountability ex Art. 5.2.

• Oggetto della revisione: (i) coerenza delle durate di ciascuna categoria con obblighi legali aggiornati; (ii) effettiva esecuzione del job orario gdpr-retention (esame dei report e dei conteggi purgati per tabella); (iii) presenza di nuove categorie di dati non ancora mappate; (iv) segnalazioni degli interessati e reclami ricevuti; (v) impatto di eventuali variazioni ai sub-responsabili (paragrafo 5).
• Cancellazione o anonimizzazione: alla scadenza della durata, i dati sono cancellati in modo irreversibile dal database applicativo. Per le categorie in cui la conservazione statistica è utile (es. aggregati di utilizzo), la cancellazione è preceduta da anonimizzazione non reversibile — aggregati senza identificativi diretti o indiretti tali da riconoscere l'interessato ai sensi del Considerando 26.
• Monitoraggio automatico: il job orario gdpr-retention legge la data della revisione più recente e, se scaduta, marca il proprio report con stato overdue. Lo stato è ispezionabile dal DPO senza attese e innesca la revisione entro 30 giorni.
• Escalation: se una revisione rileva disallineamenti sostanziali, la modifica dell'informativa e delle scadenze è pubblicata secondo la procedura del paragrafo 18 e — quando incide sui trattamenti che richiedono consenso — comporta la ri-raccolta del consenso ex paragrafo 14.7.
• Trasparenza: la data dell'ultima revisione e la data prevista per la successiva sono comunicate su richiesta dell'interessato al recapito dpo@cooperiamoinsieme.it.

Dettaglio operativo del job orario e dei relativi report: pagina Sicurezza. Analisi di impatto complessiva dei trattamenti: DPIA.

16. Esercizio dei diritti (Artt. 15-22 GDPR)

In qualità di interessato hai diritto di ottenere dal Titolare:

• Accesso (Art. 15) — copia dei dati che ti riguardano e delle finalità.
• Rettifica (Art. 16) — correzione di dati inesatti o incompleti.
• Cancellazione (Art. 17, "diritto all'oblio") — nei limiti degli obblighi di conservazione clinico-sanitaria.
• Limitazione (Art. 18) — sospensione temporanea del trattamento contestato.
• Notifica ai destinatari (Art. 19) — comunicazione delle modifiche ai sub-responsabili.
• Portabilità (Art. 20) — export in formato JSON strutturato e leggibile da macchina.
• Opposizione (Art. 21) — al trattamento basato su legittimo interesse o interesse pubblico.
• Non essere sottoposto a decisioni automatizzate (Art. 22) — non applicabile in senso stretto: E-CARE non adotta decisioni unicamente automatizzate con effetti giuridici o significativi. Le salvaguardie di trasparenza rafforzata, revisione umana, intervento e contestazione sono descritte in paragrafo 14.5.

A chi rivolgersi in funzione del ruolo GDPR

Poiché Cooperiamo Insieme opera con un modello a tre ruoli (vedi paragrafo 1e paragrafo 13), il canale corretto per esercitare i diritti dipende dalla categoria di dati oggetto della richiesta:

• Dati di titolarità Cooperiamo Insieme (account, profilo, consensi, chat AI, marketplace, fatturazione, log): self-service da Profilo → I tuoi dati personali (GDPR) oppure email a privacy@cooperiamoinsieme.it.
• Dati clinico-sociali di titolarità dell'ente aderente (dati anagrafici dell'assistito, parametri vitali, terapie, diario, calendario, trascrizioni note): richiesta da rivolgere all'ente aderente titolare. Cooperiamo Insieme, come responsabile ex Art. 28.3.e, inoltra la richiesta all'ente entro 72 orese ricevuta tramite la piattaforma e ne conserva traccia in audit log.
• Trattamenti in contitolarità (suggerimenti clinici AI, alert su parametri vitali): puoi rivolgerti indifferentemente a Cooperiamo Insieme o all'ente aderente (Art. 26.3 GDPR); i contitolari cooperano internamente per un riscontro unitario.

Modalità operative

1. In autonomia dall'app: sezione Profilo → I tuoi dati personali (GDPR)per export completo (Art. 20) e cancellazione dell'account (Art. 17).
2. Via email a Cooperiamo Insieme: privacy@cooperiamoinsieme.it, allegando documento d'identità. Risposta entro 30 giorni (prorogabili di 60 giorni per richieste complesse, con comunicazione motivata).
3. Tramite l'ente aderente per le categorie in cui è titolare (vedi paragrafo 13).
4. Reclamo al Garante per la protezione dei dati personali o ricorso all'autorità giudiziaria.

L'esercizio dei diritti è gratuito, salvo richieste manifestamente infondate o eccessive (Art. 12.5 GDPR).

16.1 Procedura interna per il riscontro entro 30 giorni (Art. 12.3 GDPR)

Cooperiamo Insieme adotta una procedura interna documentata per garantire il riscontro alle richieste degli interessati entro 30 giorni dalla ricezione, prorogabili di ulteriori 60 giorni per richieste particolarmente complesse o numerose, previa comunicazione motivata all'interessato entro il primo mese.

Monitoraggio e accountability

• Registro digitale: tutte le richieste sono tracciate nella tabella gdpr_rights_requests (portale self-service /profilo/diritti) con stato, data di apertura e scadenza calcolata a 30 giorni.
• Alert automatici: il DPO riceve promemoria a T-10 e T-3 giorni dalla scadenza per prevenire ritardi.
• Escalation: se la scadenza si avvicina senza istruttoria completata, la richiesta viene marcata overdue e portata a revisione del DPO entro 24 ore.
• Reportistica: KPI trimestrali (numero richieste, tempo medio, tasso di proroga, tasso di rifiuto) inclusi nel programma di audit di paragrafo 10.4.
• Formazione: il personale coinvolto riceve formazione periodica sui tempi e sulle modalità di riscontro, come descritto in paragrafo 10.3.

17. Violazione dei dati personali e notifiche (Artt. 33-34 GDPR)

Cooperiamo Insieme ha adottato una procedura documentata di gestione delle violazioni dei dati personali (personal data breach) in conformità agli Artt. 33 e 34 GDPR, con l'obiettivo di individuare tempestivamente gli incidenti, contenere l'impatto, documentare gli accadimenti e adempiere agli obblighi di notifica all'Autorità Garante e, quando necessario, agli interessati.

Definizione e classificazione

Si considera violazione dei dati personali ogni evento che comporti la distruzione, perdita, modifica, divulgazione non autorizzata o accesso, sia accidentale che illecito, ai dati personali trasmessi, conservati o comunque trattati. Alla scoperta di un incidente, il team di sicurezza e il DPO ne qualificano immediatamente la gravità in base ai seguenti criteri:

• Natura e sensibilità dei dati — dati comuni, dati sanitari (categorie particolari ex Art. 9), dati di minori o persone vulnerabili, dati finanziari o di autenticazione.
• Volume e diffusione — numero di interessati coinvolti e ampiezza della divulgazione (accesso interno limitato, accesso esterno, pubblicazione pubblica).
• Severità e probabilità di danno — danno identificabile o potenziale per diritti e libertà degli interessati (discriminazione, furto d'identità, danno economico, danno alla reputazione, perdita di riservatezza dei dati sanitari).
• Misure tecniche e organizzative attive — cifratura end-to-end, tokenizzazione, pseudonimizzazione, controllo degli accessi, logging, che possono ridurre il rischio concreto.

Fasi della procedura e tempi

Contenuto della notifica al Garante (Art. 33.3)

La notifica all'Autorità di controllo include, nella misura in cui le informazioni sono disponibili:

1. La natura della violazione, incluse le categorie e il numero approssimativo di interessati e di registrazioni personali coinvolte.
2. Il nome e i contatti del DPO o di altro punto di contatto per ulteriori informazioni.
3. La descrizione delle probabili conseguenze della violazione.
4. La descrizione delle misure adottate o proposte per porre rimedio alla violazione, incluse le misure volte a mitigare i possibili danni.
5. Qualora e quando appropriato, la comunicazione delle misure atte a rendere meno probabile il rischio di recidività.

Se la notifica non può essere effettuata contemporaneamente in tutti i suoi elementi, è consentita la notifica in più tempi, purché la notifica iniziale avvenga entro le 72 ore.

Notifica agli interessati (Art. 34.1)

Gli interessati sono informati senza ingiustificato ritardo quando la violazione è idonea a presentare un rischio elevato per i loro diritti e libertà. La comunicazione:

• è formulata in linguaggio chiaro e semplice (Art. 12 GDPR), evitando tecnicismi inutili;
• indica la natura della violazione e le categorie di dati coinvolte;
• descrive le conseguenze probabili e le misure adottate per porre rimedio;
• include i contatti del DPO e le azioni consigliate agli interessati per proteggersi;
• ricorda il diritto di reclamo al Garante.

La notifica agli interessati non è richiesta quando sono state già adottate misure tecniche e organizzative efficaci (es. cifratura irreversibile delle chiavi) che rendano i dati incomprensibili, oppure quando sono state adottate misure successive che garantiscano in modo inequivocabile che il rischio elevato non si realizzerà più (Art. 34.3.a-b). Resta in ogni caso l'obbligo di documentazione interna ex Art. 33.5.

Registro delle violazioni e accountability (Art. 33.5)

Ogni violazione, anche se non notificabile all'Autorità o agli interessati, è registrata in un registro delle violazioni gestito dal DPO. Il registro include:

• data e ora del rilevamento, dell'accertamento e della chiusura;
• descrizione tecnica dell'incidente, cause e vettori di attacco;
• categorie di dati e numero di interessati coinvolti;
• valutazione del rischio e motivazione della notifica o meno al Garante;
• misure di contenimento e correttive adottate;
• notifica agli interessati e, se applicabile, all'ente aderente titolare/contitolare.

Il registro è conservato per il tempo necessario a dimostrare la conformità e a supportare eventuali controlli dell'Autorità, ed è reso disponibile su richiesta del Garante.

Ripartizione di responsabilità con enti aderenti

Quando la violazione riguarda dati di titolarità o contitolarità di un ente aderente (dati clinico-sociali dell'assistito), Cooperiamo Insieme:

• comunica l'incidente all'ente senza ingiustificato ritardo, fornendo le informazioni tecniche disponibili;
• coordina la valutazione del rischio e le notifiche in conformità con gli accordi di responsabilità/contitolarità ex Artt. 26 e 28 GDPR;
• supporta l'ente aderente nell'adempimento degli obblighi di notifica, fermo restando che il titolare del trattamento resta responsabile della notifica al Garante e agli interessati per i dati di sua titolarità.

Misure preventive e di miglioramento continuo

La procedura è integrata nel programma di audit di paragrafo 10.4 e nel piano delle misure tecniche di paragrafo 10.5. Dopo ogni incidente significativo viene effettuata una post-mortem per aggiornare controlli, formazione del personale e test periodici di sicurezza, riducendo il rischio di recidività.

18. Contatti privacy e Responsabile della Protezione dei Dati (DPO)

Titolare del trattamento
Cooperiamo Insieme — Cooperativa Sociale ONLUS
P.IVA 02812020598
Email privacy: privacy@cooperiamoinsieme.it
PEC: cooperiamoinsieme@pec.it

Per gli enti aderenti (contitolari/titolari autonomi ex sezione 12) i contatti del rispettivo DPO sono indicati nell'informativa consegnata dall'ente stesso al momento della presa in carico.

19. FAQ sui ruoli di titolarità

Le domande più frequenti sulla ripartizione delle responsabilità tra Cooperiamo Insieme e l'ente aderente. Per il dettaglio giuridico completo vedi paragrafo 1 e paragrafo 13.

Chi è il Titolare dei miei dati?

Dipende dalla categoria di dati. Cooperiamo Insieme è Titolare dei dati della piattaforma (account, log, sicurezza, fatturazione, marketplace, chat AI generalista). L'ente aderente che ti prende in carico è Titolare dei dati clinico-sociali dell'assistito. Vedi la tabella al paragrafo 1.

A chi chiedo l'accesso alla cartella clinica del mio assistito?

All'ente aderente titolare (cooperativa, ASL, RSA, ADI, studio medico). Se scrivi comunque a Cooperiamo Insieme, inoltriamo la richiesta al titolare competente entro i termini di legge (vedi paragrafo 13.2 e paragrafo 16).

Cooperiamo Insieme può leggere le note cliniche del paziente?

No, non in autonomia. Sui dati clinico-sociali dell'assistito Cooperiamo Insieme agisce esclusivamente come responsabile del trattamento ex Art. 28 GDPR, su istruzioni documentate dell'ente aderente. Accessi tecnici (supporto, sicurezza, manutenzione) sono limitati al minimo necessario e registrati in audit log. Vedi paragrafo 13.2.

Se non c'è un ente aderente, chi è il Titolare?

Se sei un privato che usa E-CARE senza convenzione con un ente aderente (per esempio una famiglia che organizza in autonomia il crew domiciliare), Cooperiamo Insieme è Titolare unico di tutti i dati trattati. Il modello a tre ruoli si applica solo quando c'è un ente aderente. Vedi paragrafo 13.4.

Come esercito i diritti Artt. 15–22 se non so a chi rivolgermi?

Canale unico: privacy@cooperiamoinsieme.it. Se la richiesta riguarda dati di cui è titolare l'ente aderente, la inoltriamo al titolare corretto entro i termini di legge, informandoti. Vedi paragrafo 16.

I miei dati vengono trasferiti fuori dall'Unione Europea?

I dati sono ospitati primariamente in UE/SEE. Alcuni sub-fornitori (Google, OpenAI, Cloudflare, Stripe, Apple) operano anche negli Stati Uniti: in quel caso il trasferimento è coperto dalla decisione di adeguatezza UE–USA (Data Privacy Framework) e, come fallback contrattuale, dalle Clausole Contrattuali Standard UE 2021/914 con misure supplementari post-Schrems II. Vedi la mappa completa fornitore per fornitore al paragrafo 7 e il diritto a ricevere copia delle garanzie ex Art. 46.1 GDPR scrivendo a privacy@cooperiamoinsieme.it (vedi paragrafo 7.4).

I servizi AI (trascrizione, riassunti, chat) sono gestiti internamente?

No. Cooperiamo Insieme non eroga direttamente né sviluppa modelli proprietari di AI sui dati sanitari. I servizi di trascrizione, estrazione parametri, riassunti e chat sono forniti da sub-responsabili esterni — Google Gemini e OpenAI — attraverso il Lovable AI Gateway. Ciascun fornitore è vincolato da un DPA ex Art. 28 GDPR e da SCC UE 2021/914 per i trasferimenti verso gli Stati Uniti. Sono inoltre attive garanzie tecniche (TLS, zero-retention, opt-out dall'addestramento, minimizzazione dell'input) e il consenso AI per assistito è granulare. Le garanzie contrattuali (DPA ex Art. 28) valgono per tutti i fornitori AI, sia che il trattamento avvenga in UE sia che avvenga negli USA; per la parte USA si aggiungono SCC UE 2021/914 e Data Privacy Framework. Vedi paragrafo 14.6 e la mappa dei trasferimenti al paragrafo 7.

Come garantite che l'AI non commetta errori clinici o esiti discriminatori?

Gli agenti AI di E-CARE non decidono: producono suggerimenti che l'operatore rilegge e conferma. L'estrazione dei parametri usa uno schema strutturato con range plausibili; i riassunti sono estrattivi; gli alert usano soglie deterministiche configurate dalla crew clinica (non modelli predittivi). Non profilizziamo la persona, non inferiamo categorie protette (origine, religione, orientamento, opinioni politiche, dati genetici o biometrici), non addestriamo modelli sui dati degli assistiti e abbiamo attivato l'opt-out dall'addestramento contrattuale con i fornitori (Google, OpenAI). Vedi le misure dettagliate al paragrafo 14.3-ter, i diritti al paragrafo 14.4 e il canale di reclamo al paragrafo 16.

20. Modifiche all'informativa

La presente informativa è aggiornata quando cambiano finalità, basi giuridiche, sub-responsabili o tempi di conservazione. Le modifiche sostanziali sono notificate in-app e via email agli utenti registrati con almeno 30 giorni di preavviso. Le versioni precedenti sono conservate per consultazione su richiesta al DPO.