Moodle e sicurezza sul lavoro: Accordo Stato-Regioni 2025

Se gestisci formazione obbligatoria sulla sicurezza in modalità FAD, l'Accordo Stato-Regioni del 17 aprile 2025 (testo disponibile su lavoro.gov.it) ha cambiato le regole del gioco.

Non è un aggiornamento cosmético. Introduce requisiti tecnici precisi che molte piattaforme Moodle attualmente non soddisfano — e formazione erogata su una piattaforma non conforme non è riconosciuta come valida ai fini di legge.

Vediamo cosa cambia e cosa serve fare.

Cosa cambia con l'Accordo del 17 aprile 2025

Il testo dell'Accordo (che integra le disposizioni del D.Lgs 81/08, art. 37, e dell'Accordo Stato-Regioni del 21 dicembre 2011) introduce requisiti tecnici minimi per le piattaforme FAD. I punti più rilevanti per chi gestisce Moodle:

Identificazione univoca del partecipante. Non basta il login con username/password. La piattaforma deve verificare che chi segue il corso sia davvero il partecipante registrato. L'Accordo prevede meccanismi progressivi: da un quiz di riconoscimento periodico per corsi brevi, fino al riconoscimento biometrico per corsi di lunga durata.

Tracciamento del tempo effettivo. Il sistema deve registrare il tempo di fruizione attiva, non il tempo di sessione aperta. Un partecipante che tiene la finestra del corso aperta ma non interagisce non deve vedere le ore accreditate.

Conservazione delle prove. Log di accesso, completamenti, risultati dei quiz di riconoscimento — tutto deve essere conservato per almeno 5 anni in formato non modificabile.

Attestato con elementi di verifica. L'attestato di completamento deve contenere elementi che ne consentano la verifica (QR code o codice univoco che rimanda ai dati della piattaforma).

Identificazione del partecipante: dalla password al controllo attivo

Il requisito che richiede più lavoro di adeguamento è l'identificazione durante la sessione. Moodle ha un sistema di autenticazione robusto, ma non nasce con funzionalità anti-spoofing.

Le soluzioni implementabili su Moodle, per complessità crescente:

Livello 1 — Quiz di riconoscimento periodici. Ogni N minuti, il modulo formativo mostra una domanda di verifica (posta da un pool casuale) che blocca l'avanzamento finché non viene risposta. Implementabile come attività SCORM personalizzata o tramite un plugin di activity completion con trigger temporale.

Livello 2 — Verifica con codice OTP. All'iscrizione o all'avvio del corso, il sistema invia un OTP al numero di telefono/email registrato del partecipante. Richiede integrazione con un servizio SMS/email transazionale.

Livello 3 — Verifica biometrica. Utilizzo della webcam per il riconoscimento del partecipante all'inizio della sessione e a intervalli durante il corso. Richiede un servizio esterno di face recognition con integrazione LTI o API in Moodle.

Per la maggior parte dei corsi obbligatori standard (formazione generale e specifica per lavoratori a rischio basso/medio), i livelli 1 e 2 sono generalmente sufficienti.

Tracciamento del tempo effettivo

Questo è il problema tecnico più sottile. Moodle registra l'ultima attività dell'utente a livello di sessione — non a livello di contenuto. Se un partecipante apre un SCORM e va a fare altro, Moodle non lo sa.

Il meccanismo che implementiamo: un heartbeat asincrono nel contenuto formativo. Ogni 60 secondi, il contenuto (SCORM, video, pagina H5P) invia una chiamata AJAX al server Moodle che aggiorna un campo active_time nella sessione utente. Se l'utente non interagisce per più di 5 minuti, il heartbeat si blocca e il timer si azzera.

Questo richiede:

// Observer per catturare gli eventi di heartbeat personalizzati
// Registrato in db/events.php del plugin locale
 
$observers = [
    [
        'eventname' => '\local_tracking\event\user_heartbeat',
        'callback'  => '\local_tracking\observer::record_active_time',
        'includefile' => null,
        'internal'  => true,
        'priority'  => 200,
    ],
];

L'observer registra ogni heartbeat nella tabella mdl_local_tracking_sessions:

// classes/observer.php
public static function record_active_time(\local_tracking\event\user_heartbeat $event): void {
    global $DB;
 
    $data = $event->get_data();
    $DB->execute("
        INSERT INTO {local_tracking_sessions}
            (userid, courseid, cmid, time_active, timecreated)
        VALUES (?, ?, ?, 60, ?)
        ON DUPLICATE KEY UPDATE time_active = time_active + 60
    ", [
        $data['userid'],
        $data['courseid'],
        $data['contextinstanceid'],
        time(),
    ]);
}

A fine corso, la query di rendicontazione somma i time_active per utente/corso e produce le ore effettive — non il tempo di sessione.

Conservazione delle prove: log e registrazioni per 5 anni

Moodle mantiene il logstore per default per un periodo configurabile. Per la conformità all'Accordo, servono tre azioni specifiche:

1. Aumento del retention period. In Site administration > Plugins > Logstore standard, portare il Log lifetime a 1825 giorni (5 anni).

2. Backup immutabile dei log. I log nel database sono modificabili da un DBA. Per audit legali serve una copia immutabile — esportazione giornaliera dei log in storage esterno (AWS S3, object storage Hetzner) con hash SHA-256 per garantire l'integrità.

3. Log degli attestati generati. Ogni volta che viene generato un attestato, loggare: chi lo ha generato, quando, per quale utente, con quale hash del documento. Questo consente di verificare in audit che l'attestato non è stato alterato dopo la generazione.

Generazione dell'attestato conforme con QR di verifica

L'attestato deve contenere elementi verificabili. L'implementazione che usiamo:

1. Al completamento del corso, il sistema genera un UUID univoco e lo registra nel database insieme ai dati del completamento.
2. L'attestato PDF (generato con mPDF o wkhtmltopdf) incorpora un QR code che punta a https://tuapiattaforma.it/verify/{uuid}.
3. La pagina di verifica mostra (senza login richiesto) nome, cognome, corso, data di completamento, ore effettive — e una firma crittografica che garantisce che i dati non sono stati alterati.

Questo meccanismo soddisfa il requisito dell'Accordo sulla verificabilità dell'attestato.

Piano di adeguamento per una piattaforma Moodle esistente

Se hai una piattaforma in produzione, l'adeguamento all'Accordo 2025 si articola in tre fasi:

Fase 1 — Audit (1-2 giorni). Verificare la versione Moodle (deve essere 4.x minimo), l'attuale configurazione del logstore, i plugin attivi per la gestione della FAD, il formato degli attestati. L'audit produce una lista di gap rispetto ai requisiti.

Fase 2 — Sviluppo e configurazione (variabile). In base ai gap: aggiornamento configurazioni, sviluppo del plugin di tracking del tempo, integrazione del sistema di identificazione scelto, aggiornamento del template attestato con QR.

Fase 3 — Test e validazione (1-2 giorni). Test funzionale su un piano formativo pilota, verifica della correttezza dei log generati, test della pagina di verifica degli attestati.

Per i dettagli sulla rendicontazione ai fondi interprofessionali che spesso si integra con questo processo, leggi il nostro articolo su Moodle e Fondimpresa.

Se hai bisogno di supporto tecnico specifico per l'adeguamento, il riferimento normativo rimane il testo ufficiale del D.Lgs 81/08 su Normattiva.

Conclusione: tre punti da portare via

1. L'Accordo 2025 non è un aggiornamento facoltativo. Formazione erogata su piattaforma non conforme non è riconosciuta. Il rischio legale in caso di infortunio è concreto.

2. SCORM da solo non basta più. Serve tracciamento attivo del tempo di fruizione, non del tempo di sessione. Questo richiede sviluppo custom.

3. L'adeguamento è fattibile in tempi ragionevoli. Con una piattaforma Moodle 4.x già in produzione, l'adeguamento tecnico completo si fa in 1-3 settimane di lavoro, a seconda del livello di identificazione richiesto.

Devi adeguare la tua piattaforma all'Accordo 2025 e non sai da dove partire? Mandaci la versione del tuo Moodle: in 48 ore ti rispondiamo con un piano di adeguamento.