Flow for Education: le risposte alle domande più frequenti

Che cosa comporta una soluzione interna:

• Costi aperti: si conosce l'investimento iniziale, non quello di esercizio. Infrastruttura, consumi AI, correzioni e adeguamenti si sommano ogni anno, senza un tetto.
• Tempi lunghi: mesi di progettazione, sviluppo e collaudo prima che il primo utente possa usarla. Nel frattempo modelli e tecnologie cambiano.
• Dipendenza da poche persone: la conoscenza resta a chi l'ha costruita. Se cambiano incarico, la soluzione resta senza chi la sa correggere.
• Manutenzione senza fine: aggiornamenti di sicurezza, ritiro dei modelli AI, nuove norme, accessibilità. Ogni voce richiede lavoro ricorrente (domanda 3).
• Evoluzione a pagamento: ogni miglioramento va finanziato e sviluppato in proprio. Senza budget, la soluzione invecchia.

Che cosa resta nelle mani dell'Istituzione con Flow:

• Organizzazione: strutture, dipartimenti, utenti e ruoli sono gestiti dagli amministratori dell'Istituzione, senza passare da Virsion.
• Contenuti e permessi: chi vede che cosa, quali materiali l'assistente può consultare, come sono organizzati i corsi.
• Controllo: consumi, costi e registro delle azioni sono consultabili in ogni momento.
• Dati: restano di proprietà dell'Istituzione, nel formato originale ed esportabili (domanda 8).
• Indirizzo del prodotto: le priorità di sviluppo si concordano con i clienti (domanda 21). Le nuove funzioni, anche quelle nate dalle esigenze di un cliente, arrivano come aggiornamenti della piattaforma.

L'Istituzione decide come usare la piattaforma; Virsion si occupa di farla funzionare, aggiornarla e proteggerla.

• Permessi: un chatbot custom ha di norma un'unica base documentale, uguale per chiunque lo usi. Flow applica i permessi del singolo utente a ogni domanda, quindi lo stesso assistente dà a ciascuno solo ciò che può vedere.
• Documenti duplicati: ogni chatbot ha la propria copia dei file. Quando un documento cambia o va eliminato, bisogna ricordarsi di ogni copia. In Flow il documento è uno solo e, se viene eliminato, sparisce anche dalla ricerca AI.
• Governo: dieci chatbot significano dieci responsabili, dieci configurazioni e nessun punto unico per sapere dove stanno i dati e chi vi accede. Questo pesa proprio sugli adempimenti GDPR.
• Costi: i consumi sono sparsi e senza un tetto comune. Flow ha un budget in euro verificato prima di ogni richiesta e una rendicontazione per utente.
• Manutenzione: i modelli AI vengono ritirati e sostituiti periodicamente, e ogni chatbot va aggiornato e ricollaudato. In Flow l'aggiornamento è centrale. Il dettaglio di ciò che resta a carico dell'Istituzione è nella domanda 3.
• Qualità e accessibilità: citazione delle fonti, calcoli eseguiti dal software e conversione accessibile dei documenti andrebbero ricostruiti in ogni chatbot.

Un chatbot dedicato resta una buona scelta per un uso circoscritto e su contenuti pubblici, ad esempio le informazioni di orientamento sul sito. Il confronto cambia quando i contenuti sono riservati, gli utenti sono molti e le strutture sono diverse.

Allo stato attuale, un provider AI collegato a Moodle offre generazione di testo e immagini nell'editor, riassunto e spiegazione della pagina aperta. La ricerca nei materiali (RAG) non è una funzione standard: arriva da plugin di terze parti o da sviluppi interni, che l'Istituzione sceglie, installa e mantiene.

• Permessi: in molte soluzioni con RAG i permessi vengono copiati nell'indice quando il documento è caricato, e lì restano fermi fino alla reindicizzazione successiva. In Flow il filtro è costruito dal server a ogni domanda e i risultati sono ricontrollati sui permessi effettivi: un accesso revocato vale dalla domanda successiva. Il docente decide, file per file, che cosa l'assistente può consultare.
• Qualità delle risposte: recuperare alcuni frammenti non basta per ogni domanda. Flow aggiunge ricerca ibrida con reranking, lettura integrale e confronto fra documenti, conteggi eseguiti dal software, riconoscimento di formule e tabelle.
• Ciclo di vita: quando un documento viene eliminato o sostituito, anche l'indice deve aggiornarsi. In Flow avviene in automatico.
• Accessibilità: conversione dei PDF in versioni accessibili, sintesi vocale e preferenze di lettura non fanno parte di un chatbot con RAG.
• Costi: budget in euro verificato prima di ogni richiesta, limiti di frequenza e rendicontazione per utente andrebbero costruiti a parte.
• Perimetro: un assistente dentro Moodle vede solo ciò che è in Moodle. Flow copre anche i documenti che non sono corsi: regolamenti, verbali, materiali di segreterie e uffici.

Una soluzione di questo tipo non si installa una volta: va tenuta in vita. Con un chatbot collegato a Moodle questo lavoro resta all'Istituzione:

• Aggiornamenti di Moodle: Moodle rilascia due versioni maggiori l'anno. A ogni aggiornamento il plugin va verificato e, se chi lo sviluppa è in ritardo o lo abbandona, l'Istituzione deve scegliere fra rimandare l'aggiornamento dell'LMS e spegnere l'assistente.
• Ritiro dei modelli: i fornitori ritirano i modelli a scadenze fisse. Sostituire quello che genera le risposte richiede un nuovo collaudo; sostituire quello che costruisce l'indice richiede di reindicizzare tutti i materiali.
• Indice di ricerca: è un'infrastruttura in più da ospitare, monitorare, salvare e riallineare quando qualcosa va storto.
• Documenti che non si leggono: scansioni, formule e tabelle complesse falliscono in silenzio. Serve qualcuno che se ne accorga e intervenga.
• Sicurezza e dati: correzioni di sicurezza, valutazione del plugin e del fornitore AI, aggiornamento della documentazione sul trattamento dei dati a ogni cambio.
• Qualità e supporto: quando l'assistente risponde male, qualcuno deve raccogliere la segnalazione, capire la causa e correggere.

Con Flow queste attività sono parte del servizio: l'Istituzione usa la piattaforma, non la mantiene.

Le due soluzioni non si escludono: gli strumenti AI di Moodle aiutano a scrivere e a leggere dentro l'LMS, Flow risponde sui documenti e lo affianca senza sostituirlo (domanda 14).

• Stesse funzioni, stessi permessi: l'app usa le stesse API della versione web. Documenti, assistente e corsi rispettano gli stessi controlli di accesso, applicati dal server.
• Accesso: sblocco con impronta o riconoscimento del volto dopo il primo accesso con secondo fattore. Un cambio di password chiude tutti gli accessi, anche quelli da telefono.
• Uso da telefono: si può allegare all'assistente una foto scattata sul momento o un'immagine dalla galleria.
• Notifiche: notifiche push senza dati personali né contenuti dei documenti (domanda 5).

Che cosa comporta un'app sviluppata in proprio:

• Due piattaforme: Android e iOS vanno sviluppate, collaudate e aggiornate separatamente, a ogni nuova versione dei sistemi operativi.
• Pubblicazione sugli store: account sviluppatore, revisioni di Apple e Google, dichiarazioni sul trattamento dei dati, regole che cambiano ogni anno.
• Sicurezza specifica: custodia delle credenziali sul dispositivo, biometria, sessioni da revocare a distanza. Sono problemi diversi da quelli di un sito.

Con Flow l'app è parte del servizio e segue gli aggiornamenti della piattaforma.

• Tutti i servizi sono ospitati in regioni Azure europee: West Europe (Paesi Bassi), Sweden Central (Svezia) e Italy North (Milano), tutte nell'Unione Europea.
• Database e archivio documentale sono collegati tramite private endpoint; il traffico in ingresso passa da Azure Front Door con Web Application Firewall.
• Nessun indirizzo di storage viene mai esposto al browser: ogni download transita da un endpoint autenticato che verifica i permessi.
• Oltre a Microsoft, i sub-responsabili sono elencati nell'allegato al contratto. Mathpix riconosce le formule matematiche su infrastruttura AWS a Francoforte, con eliminazione dei dati subito dopo l'elaborazione; può essere disattivato per l'intera Istituzione. Google Firebase recapita le notifiche push dell'app mobile: nei messaggi non transitano dati personali né contenuti dei documenti.

• Flow utilizza i modelli tramite Azure: secondo le condizioni del servizio Microsoft, prompt e risposte non sono usati per addestrare i modelli e non vengono condivisi. Lo stesso impegno è assunto da Virsion nel contratto.
• Nella configurazione standard è attivo il monitoraggio degli abusi di Microsoft, che può conservare prompt e risposte fino a 30 giorni a soli fini di sicurezza.
• L'applicazione raggiunge i servizi Azure con identità gestite (Managed Identity); i segreti residui sono custoditi in Azure Key Vault e non compaiono mai nel codice o nei file di configurazione.
• Gli endpoint AI ammessi sono definiti in una lista chiusa: l'applicazione rifiuta di avviarsi se un endpoint non appartiene ai domini Azure previsti.

• Il contratto comprende gli allegati su trattamento dei dati, misure di sicurezza, livelli di servizio ed elenco dei sub-responsabili. Virsion è una società svizzera: si applicano il GDPR, dove imperativo, e la legge federale svizzera sulla protezione dei dati.
• Eventuali violazioni che coinvolgano dati personali vengono notificate all'Istituzione nei tempi e con le modalità stabiliti dal contratto.
• Cancellazione dell'account ai sensi dell'art. 17, con approvazione del referente e anonimizzazione dei dati personali.
• Conservazione limitata: allegati delle conversazioni e immagini generate vengono eliminati automaticamente dopo 30 giorni.
• Quando un documento viene eliminato, vengono rimossi anche i suoi frammenti dall'indice di ricerca AI.
• Registro delle azioni rilevanti consultabile dagli amministratori; i log applicativi non contengono il testo dei documenti né credenziali. I log diagnostici e di sicurezza dell'infrastruttura sono conservati per 90 giorni.

Alla cessazione l'Istituzione dispone di 30 giorni di accesso in sola consultazione e download per esportare i propri dati; trascorso il periodo, i dati vengono cancellati. I documenti sono conservati nel loro formato originale, senza dipendenze da formati proprietari.

Un supporto all'esportazione con modalità dedicate può essere concordato nell'ordine. Documenti, prompt e risposte dell'assistente restano di proprietà dell'Istituzione per tutta la durata del rapporto.

• Il contesto dell'utente (organizzazione, dipartimento) deriva sempre dalla sessione autenticata, mai da parametri inviati dal browser.
• Ogni interrogazione al database è filtrata per organizzazione direttamente nella query.
• Il filtro di sicurezza sulla ricerca AI è costruito dal server e applicato prima del ranking; i risultati vengono poi ricontrollati sui permessi effettivi del database.
• I documenti hanno tre livelli di visibilità (organizzazione, dipartimento con sotto-strutture, privato) e lo storage è segmentato per organizzazione.
• La suite di test automatici include verifiche negative specifiche: accesso tra organizzazioni diverse, escalation di ruolo, accesso diretto a risorse altrui.

• Audit di sicurezza interni con rilievi tracciati fino alla correzione.
• Analisi delle vulnerabilità note nelle librerie (OWASP Dependency-Check) integrata nella build.
• Revisione di sicurezza sulle modifiche e un registro interno delle aree di codice sensibili, con le regole che non devono essere violate.
• Intestazioni di sicurezza, protezione CSRF, Content Security Policy e HSTS; caricamenti verificati su formato reale del file, non sulla sola estensione.

• Il testo dei documenti è delimitato nel prompt e dichiarato come dato non attendibile: le istruzioni di sicurezza non sono sovrascrivibili dal contenuto.
• Il modello non dispone di strumenti né di funzioni eseguibili: non può accedere a URL, modificare dati o agire per conto dell'utente.
• L'output viene sanificato prima della visualizzazione, senza script né HTML attivo.

Nessun sistema basato su modelli linguistici è immune per definizione; Flow è progettato perché un tentativo di questo tipo non possa tradursi in un accesso a dati non autorizzati.

• Il secondo fattore è un requisito contrattuale: al primo accesso l'utente deve configurarlo prima di poter usare la piattaforma. Può scegliere un'app authenticator (TOTP, con protezione contro il riuso del codice) oppure il codice via email; i dispositivi fidati valgono 30 giorni.
• Blocco temporaneo dopo tentativi di accesso falliti e numero massimo di tentativi sulla verifica del secondo fattore.
• Password con hash BCrypt, revoca delle sessioni al cambio o al ripristino della password.

Oggi Flow gestisce l'autenticazione in proprio. Lo strato di sicurezza è Spring Security, che supporta nativamente SAML 2.0 e OpenID Connect: gli standard utilizzati da Microsoft Entra ID, Shibboleth e dalla federazione IDEM.

Il backend espone un livello di API REST con autenticazione a token (access token di breve durata e refresh token con rotazione). Un connettore LTI e il provisioning automatico degli utenti dall'anagrafica dell'Istituzione non fanno parte del prodotto attuale.

• Corsi organizzati in sezioni e materiali, con avanzamento per partecipante e possibilità di sbloccare i contenuti in sequenza.
• «Chiedi all'assistente su questo corso»: l'ambito della ricerca è ricalcolato dal server e limitato ai materiali del corso che l'utente può vedere.
• Il docente decide, file per file, quali materiali l'assistente può consultare.
• Supporto dell'AI alla stesura di descrizioni e struttura del corso, sempre con validazione del docente.
• Terminologia dedicata al contesto universitario e anteprima del corso dal punto di vista dello studente.

Il modulo è in produzione ed è coperto da test automatici, inclusi quelli di sicurezza.

• Ricerca ibrida (testuale e vettoriale) con reranking semantico; le fonti utilizzate sono elencate sotto la risposta e scaricabili da chi ne ha il permesso.
• L'assistente è istruito a non trarre conclusioni esaustive da estratti parziali; per le domande che lo richiedono è disponibile la lettura integrale dei documenti scelti dall'utente e il confronto fra più documenti.
• Conteggi e somme su più documenti sono eseguiti dal software su dati estratti in modo strutturato, con il dettaglio per documento: il modello linguistico non fa calcoli liberi.

Un modello linguistico può commettere errori: per questo Flow è costruito sulla verificabilità della risposta, non sulla promessa di infallibilità, e il contratto prevede la verifica umana dei risultati prima del loro utilizzo.

• Ogni piano definisce un budget AI mensile in euro e un numero massimo di richieste: una domanda che farebbe superare il budget viene fermata prima di essere inviata al modello. In assenza di configurazione, il sistema nega anziché consentire.
• Le operazioni più onerose (analisi su più documenti, funzioni AI dei corsi, generazione di immagini, sintesi vocale) hanno limiti di frequenza dedicati.
• Consumi tracciati per messaggio, conversazione e utente, calcolati con i prezzi del modello effettivamente usato e al netto della cache dei prompt, che riduce costi e latenza.
• Pannello di controllo per amministratori e referenti con indicatori mensili e andamento dei consumi.

• Ogni PDF caricato viene convertito automaticamente in versioni accessibili HTML e Markdown, con struttura semantica, tabelle con intestazioni, descrizione di immagini e grafici e formule in MathML leggibili dagli screen reader.
• Preferenze per utente: caratteri ad alta leggibilità (Lexend, OpenDyslexic), dimensione e spaziatura del testo, riduzione delle animazioni, temi progettati per il daltonismo.
• Sintesi vocale delle risposte con voci neurali in italiano e inglese; conversazione strutturata per la navigazione con screen reader.
• Interfaccia progettata secondo le WCAG 2.1 livello AA e verificata in un test reale con screen reader condotto da una persona non vedente.

• Database, ricerca, storage e modelli AI sono servizi gestiti, dimensionabili in modo indipendente.
• Le elaborazioni pesanti (estrazione del testo, indicizzazione, conversione accessibile) sono asincrone e non incidono sull'esperienza di chi sta usando la piattaforma.
• Le risposte dell'assistente sono elaborate lato server e non si perdono se l'utente chiude la pagina.

• Flow è uno strumento di lavoro sui documenti, non un archivio di conservazione: salvo diverso accordo, tenere una copia di sicurezza dei propri documenti resta a cura dell'Istituzione, come previsto dal contratto.
• Il piano standard si appoggia ai livelli di servizio di Microsoft Azure. Backup garantiti, disaster recovery con obiettivi di ripristino (RPO/RTO) e SLA applicativi, ad esempio disponibilità dal 99,5% e tempi di risposta del supporto, sono servizi concordabili nell'ordine o con un piano dedicato.
• Manutenzioni programmate comunicate con almeno 48 ore di preavviso, in fasce orarie a basso impatto.
• Schema del database versionato: ogni modifica è tracciata, ripetibile e applicata in modo controllato. Ambienti separati di sviluppo e di produzione.

• Ogni rilascio passa da oltre 1100 test automatici, tra unitari e di integrazione, una parte significativa dei quali dedicata alla sicurezza.
• Build e test sono automatizzati; la messa in produzione è un passaggio supervisionato, preceduto dalla validazione in ambiente dedicato.
• L'evoluzione del prodotto è guidata dai clienti: un progetto con l'Istituzione è anche l'occasione per orientare le priorità della roadmap sul proprio contesto.