I principi
Quattro patti che governano Studium.
Sono i quattro vincoli che lo studente firma in fase di onboarding. Non sono valori decorativi: sono scritti nel codice, nello schema dati e nel processo di build. Limitano cosa Studium può fare — e questo è esattamente il punto.
Anonimato strutturale
Il singolo studente non è mai visibile, neanche al docente.
Quando il docente apre la heatmap di difficoltà dell'insegnamento, vede cluster di studenti — mai uno studente isolato. La soglia tecnica è sette: nessuna metrica di difficoltà viene mostrata se sotto il cluster ci sono meno di sette persone. Sopra la soglia, l'aggregato è statisticamente anonimo per costruzione.
Questo non è uno strato di privacy che possiamo togliere via configurazione. È una proprietà dello schema dati: identità e cognizione vivono in schemi separati, il join che riconnetterebbe i due passa solo attraverso percorsi audit-loggati e mai esposti al frontend docente.
Lo studente quindi non ha bisogno di fidarsi di una promessa di marketing: se il codice della heatmap fosse modificato per scendere sotto sette, l'audit GDPR (settimanale) lo segnalerebbe.
Esempi concreti
- Per il docente la heatmap mostra "12 studenti su 18 fanno fatica su questo concetto" — mai "Alessandro Devito fa fatica".
- Il Learning Twin di uno studente vede i suoi dati cognitivi, ma non li espone in pagine accessibili da altri ruoli.
- Quando rispondi al questionario di confidence post-concetto, la tua risposta entra nell'aggregato solo se ci sono già almeno altri sei studenti che hanno risposto.
No ricostruzione della lezione
Mai sintetizzare la voce o il discorso del docente.
Studium non clona la voce di nessuno. Non genera un avatar del docente. Non sintetizza un riassunto "come se l'avesse detto lui" della lezione. Il Learning Twin parla con la sua voce — voce sintetica neutra, dichiarata come AI — e mai con la voce di una persona reale.
Le metafore generate dall'AI per spiegare concetti vengono validate dal docente prima di essere mostrate agli studenti. La fonte epistemica resta il docente; l'AI è uno strumento per esprimere lo stesso contenuto in linguaggi cognitivi diversi (testo, voce, disegno, esempi multimodali).
Questo vincolo elimina alla radice il rischio reputazionale per il docente — non potrai mai dire 'il professore ha detto X' basandoti su un output AI — e protegge la relazione didattica come spazio di responsabilità umana.
Esempi concreti
- Il Learning Twin non offre 'la versione del professore' di una spiegazione: offre la spiegazione validata dal professore.
- Le metafore generate sono firmate AI (bootstrap LLM) e marchiate visivamente come tali nel catalogo.
- Nessun TTS impersona la voce del docente — il sistema usa una voce neutra dichiarata.
Non manipolazione
Niente urgency, niente dark pattern, niente 'accetta tutto' magic.
I consensi in Studium sono granulari: ogni trattamento (privacy notice base, notifiche push, voice dialog, email transazionali) ha il suo opt-in esplicito, segnalato in una DPIA versionata. Non esiste un pulsante 'accetta tutto' che precompila scelte: ogni consenso si firma uno alla volta o non si firma affatto.
Non usiamo countdown finti, scarsità artificiale, social proof inventato. Non c'è ranking pubblico fra studenti, non c'è "il 73% dei tuoi colleghi ha già completato" come tattica di pressione. Il tempo di apprendimento è del singolo e il singolo lo gestisce.
Quando un'azione è distruttiva (esportare i dati, cancellare l'account, lasciare Studium) il copy è asciutto e la conferma è separata. Non cerchiamo di farti rimanere — se devi andare, vai.
Esempi concreti
- I 4 consensi del welcome flow si firmano uno per uno, con scroll esplicito e dichiarazione separata per ciascuno.
- La cancellazione account è raggiungibile dal pannello profilo in due click — non nascosta dietro otto livelli di sub-menù.
- Le notifiche push hanno una DPIA dedicata e un toggle indipendente: puoi usare Studium senza notifiche.
GDPR-by-design
Dati EU, right-to-be-forgotten reale, consensi versionati.
I dati personali degli studenti vivono in infrastruttura europea (Railway region EU). Il database è gestito da Studium, non delegato a un fornitore SaaS terzo che potrebbe spostare i dati altrove. Le configurazioni del database forniscono backup point-in-time e restore verificato.
Il diritto all'oblio è effettivo: la richiesta di cancellazione rimuove davvero il record, non lo oscura con un flag. I dati aggregati anonimi (cluster di difficoltà sopra i sette studenti) non vengono toccati perché non contengono più identità per costruzione — il join non è ricostruibile.
La privacy notice è un'entità versionata in database. Ogni cambiamento sostanziale genera una nuova versione e richiede un nuovo consenso esplicito. Le DPIA per ogni trattamento ad alto rischio (notifiche, voce, email) sono pubbliche.
Esempi concreti
- GET /api/privacy-notice/current restituisce la versione attiva — GET /api/privacy-notice/all la storia versionata per audit.
- La privacy notice mostrata in /legal/privacy-notice è la stessa che firmi nel welcome flow, sempre allineata.
- L'export GDPR è un job idempotente: chiedi l'export, ricevi i dati, poi puoi chiedere la cancellazione e i record spariscono davvero.
Se trovi una violazione
Segnalare conta più che protestare.
Se trovi un comportamento di Studium che contraddice uno di questi quattro patti — una heatmap che scende sotto la soglia di sette, una voce che suona troppo simile al docente, un dark pattern in onboarding, una cancellazione che non cancella — segnalalo.
- Email a alessandro.devito@gmail.com per segnalazioni che vuoi tenere riservate.
- Issue pubblica su github.com/UniSa-HCD/studium/issues ↗ per segnalazioni che possono restare in chiaro.
Ogni violazione segnalata viene tracciata, classificata in priorità e diventa un test di regressione: se ricapita, l'audit la rileva al prossimo run.