Un coach che fa superare, non l'ennesimo chatbot che risponde
Come penserei l'AI Companion di OpenLearning, e perche'.
Preferisci leggerlo su carta? Salva questa pagina in PDFVersione viva e interattiva, con la demo del Companion: digited-companion.prontia.it
Parto da una cosa che mi sono portato dietro costruendo assistenti AI per le aziende, non da una slide: un chatbot che risponde non fa imparare. Lo fa sembrare. La persona ottiene la risposta, annuisce, chiude la scheda, e una settimana dopo non sa rifare la cosa. C'e' uno studio del 2025 che lo misura bene, ed e' quello che mi ha convinto del tutto perche' separa le due cose. Bastani et al. su PNAS danno a quasi mille studenti due AI: una in stile ChatGPT nudo e una con sopra una guida didattica. Con l'AI davanti, tutti vanno meglio. Ma all'esame senza l'AI, chi aveva usato il ChatGPT nudo va peggio del 17 per cento rispetto a chi non l'aveva usata affatto. Chi aveva avuto la versione guidata, no: stesso livello di chi non l'ha mai toccata. La gruccia non e' l'AI. E' l'AI senza guardrail pedagogici. Tutto il mio progetto e' su quella differenza.
Questo per me e' il punto di partenza, perche' un chatbot che risponde voi ce l'avete gia': il Chatbot Contestuale di OpenLearning. Se l'AI Companion deve servire a superare i corsi piu' difficili, rifare quello sarebbe spendere sei mesi e cinque persone per duplicare una cosa che avete gia' in casa. La mia tesi e' un'altra:
Il Companion non e' un risponditore piu' bravo. E' un coach proattivo che ti fa praticare sui corsi obbligatori difficili, interviene quando ti vede in difficolta', e nei domini a rischio (sicurezza, compliance) e' costruito per non sbagliare. Da "assistente che risponde" a "coach che ti fa superare".
Chi usa davvero OpenLearning, e perche' conta
Una cosa che mi ha colpito leggendovi: il vostro utente non e' lo studente curioso. E' un adulto che lavora, e che quasi sempre fa il corso perche' deve. Sicurezza ex D.Lgs 81/08, compliance, ECM per chi e' in sanita' (crediti obbligatori), aggiornamento normativo in banca, da dove tra l'altro nascete (Intesa Sanpaolo Formazione). Tempo zero, motivazione estrinseca, e la barra non e' "si e' divertito" ma "ha completato e ha imparato abbastanza da non combinare guai".
Questo cambia tutto, e cambia anche chi firma l'assegno. Chi compra non e' il discente, e' l'HR o l'L&D manager. A loro non interessa l'engagement: interessa che il corso obbligatorio si chiuda e regga a un audit. E il dato e' brutale: nei corsi di compliance, le organizzazioni con completion sotto il 70 per cento hanno 3,5 volte piu' probabilita' di incappare in una violazione. Il completamento qui non e' vanity, e' gestione del rischio. Per questo vendo il Companion sul completamento. Il meccanismo sotto, pero', e' l'apprendimento: e' l'unico modo perche' quel completamento valga qualcosa.
E il nemico ha un nome: il drop-off. L'e-learning corporate tradizionale chiude tra il 10 e il 15 per cento; col supporto di un coach o di un meccanismo di accountability si arriva al 70 e oltre. Il 72 per cento delle persone ammette di non seguire davvero i video di formazione. Quindi il problema da risolvere non sono le domande senza risposta: e' la gente che molla, o che passa oltre senza che resti niente.
Perche' non e' una scommessa: cosa ha gia' funzionato altrove
"Coach che fa praticare" suona bene, ma la domanda giusta da PO e': qualcuno l'ha gia' provato sul serio, con numeri? Si'. E se guardi cosa ha spostato davvero l'apprendimento in studi controllati, c'e' un filo unico: nessuno di questi sistemi da' la risposta. Ti fanno ragionare o praticare.
- Khanmigo (Khan Academy), tutor socratico che non spoilera: in un RCT a Toronto, +0,36 deviazioni standard.
- Kestin/Harvard 2025 (Scientific Reports): un AI tutor con pacing e probing socratico batte la lezione attiva, learning gain piu' che doppio, effetto 0,63-1,3 SD.
- LearnLM di Google DeepMind, RCT in classi UK (2025): l'AI tutor supervisionato migliora gli esiti in sicurezza e rende gli studenti il 5,5 per cento piu' capaci di risolvere problemi nuovi (transfer, non memoria).
- Duolingo Max: il roleplay (pratichi una conversazione) porta +15 per cento di completamento e il 78 per cento si sente piu' pronto.
- Recupero attivo (Karpicke, Science 2008): chi si ri-testa ricorda l'80 per cento a una settimana, chi si rilegge il 36. Quarantaquattro punti, solo cambiando "leggi" in "prova a ricordare".
E il contrario? I companion corporate (Docebo, 360Learning, SAP Joule) pubblicano quasi sempre metriche di uso: minuti risparmiati, ricerche piu' veloci. Quasi mai learning gain con un gruppo di controllo. Non e' un dettaglio: e' il buco di mercato in cui ci infiliamo. La nostra originalita' non e' un'idea nuova di zecca, e' una combinazione difendibile di cose validate (pratica in scenario, productive failure, recupero spaziato) messe dentro il vostro prodotto, con i guardrail giusti, e misurate sul serio.
B1 L'affidabilita': i tre modi in cui ho visto rompersi questi sistemi
Qui parlo da chi li mette in produzione, non da chi li raccatta da un paper. Quando un assistente AI fallisce in un'azienda, fallisce in tre modi. Sempre gli stessi tre. E in un corso di sicurezza, ognuno dei tre puo' fare un danno vero. Quindi non li tratto come bug da sistemare dopo: li tratto come i requisiti di prodotto che decidono l'architettura.
Una scelta che mi sembra controintuitiva ma che da PO difendo: in un contesto a rischio il Companion deve rifiutare piu' che rispondere, e non decide mai lui se hai superato: segnala, il docente valida. Questa e' una decisione di prodotto, non solo un vincolo legale: e' anche come si rispetta l'Art. 14 dell'AI Act (controllo umano) e come ci si alleggerisce l'onere regolatorio. Perche' c'e' un fatto da non ignorare: un Companion che orienta l'apprendimento e' high-risk per legge (AI Act, Allegato III, punto 3b), e gli obblighi scattano il 2 agosto 2026. Il guardrail, da ultima cosa, diventa la prima.
E l'ho costruito cosi' anche nella demo: il filtro che decide se rispondere, rifiutare o escalare vive nel codice, non nel prompt. Il prompt e' fragile, lo aggiri con una frase. Nel codice no.
Apri la demo viva
A1 Le feature core al lancio, e cosa taglio
Quali sono le funzionalita' core, e come motivi il taglio con team e timeline?
Cinque persone, sei mesi. Se provo a fare tutto, non consegno niente. Quindi taglio, e il taglio e' la risposta, non un compromesso. Tengo due cose core, e una delle due e' la fondazione che permette l'altra. La proattivita' la tengo nella sua forma minima, dove costa poco e regge la tesi.
- 1. Motore di scenari con productive failure, con il trigger di stallo dentro l'attivita'. E' il cuore: scenari job-relevant dove sui concetti ti faccio sbagliare in sicurezza e ti guido, sulle procedure no. La proattivita' che tengo al lancio e' questa, una sola e in-flow: quando ti blocchi sul punto, non ti rispiego, ti faccio praticare. E' cio' che ci distingue dal chatbot e cio' che la ricerca premia.
- 2. Reliability layer. RAG, citazione, refusal/escalation, output strutturato. Non e' una feature da brochure, e' il pavimento: senza, lo scenario in un corso sicurezza non si spedisce.
E qui faccio il taglio che conta: il coach proattivo cross-corso scende a fase 2. Il recupero spaziato e le spinte in "Per Te" e "Agenda" su chi sta mollando prima della scadenza sono giusti, ma sono un secondo sistema: dipendono da una telemetria continua che, su contenuti SCORM, potrebbe non esserci (ci torno sotto). Costruirlo al lancio brucia il team e fonda il prodotto su un'integrazione che non ho ancora validato. Quindi al lancio tengo l'intervento in-flow dentro l'attivita', che la tesi la regge gia', e il layer proattivo che attraversa la piattaforma lo aggiungo quando so che il segnale esiste davvero.
Cosa rimando a dopo, e dove dico no. Generazione automatica dei contenuti, estensione a piu' vertical e piu' formati oltre il pilota, integrazione con la Community, il mobile. Tutta roba sensata, ma in fase 2. E una cosa non la costruisco anche se "fa figo" e se la chiede l'HR: l'AI che mette il voto e fa passare da sola. Sia perche' l'AI Act dice di no, sia perche' e' esattamente il punto dove la responsabilita' deve restare a un umano. Parto da un formato (video) e un vertical (sicurezza) per de-riscare e avere qualcosa di vero da misurare entro sei mesi.
Il pezzo noioso ma decisivo: chi scrive gli scenari. In EdTech il collo di bottiglia non e' il modello, e' il contenuto. Uno scenario a bivi per ogni corso, disegnato a mano dai docenti, non scala: i SME odiano scrivere la logica branching. Quindi nell'MVP ci metto uno Scenario Drafter: l'AI pre-compila lo scenario partendo dal materiale gia' autorizzato del corso, il docente lo valida e lo corregge. L'AI non inventa contenuto, prepara una bozza su fonti vere che un umano firma. Senza questo pezzo il pilota muore di fame di contenuti dopo il primo corso, ed e' la ragione per cui tanti companion restano demo.
Due leve che terrei pronte per la fase 2, ma costruite per adulti, non da arcade: una dashboard di team dove manager e colleghi vedono il completamento del corso obbligatorio, e challenge a squadre sulla scadenza. Non punti e medaglie da bambini: e' accountability sociale, ed e' la stessa leva che porta il completamento dal 10-15 per cento al 70 e oltre (il coaching e l'impegno reciproco, non la gamification fine a se stessa). La metto dopo perche' al lancio voglio prima provare che il meccanismo di apprendimento funziona da solo. Il sociale lo amplifica, non lo sostituisce: se lo metti prima, fai numero senza imparare, ed e' esattamente la trappola che voglio evitare.
A2 Dove interviene, e perche' proprio li'
In quale momento del percorso interviene l'AI? Come cambia l'esperienza rispetto a oggi?
Oggi il discente guarda un video o clicca attraverso uno SCORM, in passivo, e se vuole apre il chatbot. Sul corso obbligatorio difficile questo produce due cose: abbandono e oblio. Domani il Companion sta dentro l'attivita'. Sul video e' ancorato al secondo: se ti vede tornare indietro due volte sullo stesso passaggio, o sbagliare un check, non ti rispiega, ti propone un micro-scenario su quel punto. A fine modulo, un richiamo attivo invece di un "hai completato". Il recupero cross-corso in "Per Te" e "Agenda", che intercetta chi sta mollando e schedula il ripasso prima della scadenza, e' il passo dopo: al lancio l'intervento vive dentro l'attivita', dove il segnale di stallo e' certo; il layer che attraversa la piattaforma lo accendo quando ho la telemetria continua per reggerlo.
Perche' li' e non altrove: il drop-off e l'oblio nascono nel consumo passivo e nel vuoto tra una sessione e l'altra. Si interviene dove si rompe. E si interviene solo su un segnale di stallo reale, mai a tappeto: l'adulto che lavora non vuole un assistente che lo assilla, e c'e' una ragione tecnica (Cognitive Load Theory), non un capriccio. L'esperienza cambia da "ho finito il video" a "so fare la cosa".
B2 Come dimostro che fa imparare, non solo che lo usano
Quali KPI? Come li misuri concretamente sulla piattaforma?
La trappola e' misurare l'uso e chiamarlo apprendimento. Io guardo quattro cose: completion lift sui corsi obbligatori (il KPI che compra l'HR), delta pre/post con un effect size onesto attorno a 0,4-0,8 deviazioni standard (non vi prometto il "2 sigma" di Bloom, e' gonfiato), transfer su compiti nuovi di scenario, e ritenzione a 30, 60, 90 giorni. Le vanity che non guardo: utenti attivi, numero di messaggi, minuti in piattaforma.
Come si misura davvero: con un gruppo di controllo, non con un "prima e dopo" che si fa ingannare dal novelty. Il vostro xAPI scrive gia' il learning record, quindi l'infrastruttura c'e'.
B2 · L'obiezione vera sul gruppo di controllo
E qui anticipo l'obiezione che farei io se fossi dall'altra parte: in un cliente che ha pagato la feature, come fai a tenere un gruppo di controllo a cui la neghi? Non lo fai con un gruppo "punito". Lo fai col rollout sfasato (stepped-wedge): il Companion arriva a ondate, reparto dopo reparto. Chi non l'ha ancora ricevuto e' il controllo di chi ce l'ha gia', e alla fine ce l'hanno tutti. Nessuno resta indietro, e tu hai comunque un confronto pulito. E' un disegno che in sanita' usano proprio quando non puoi negare un trattamento a nessuno. Calza.
C1 Roadmap, e cosa deve essere vero per andare avanti
Fasi di rilascio, condizione per avanzare, cosa giustifica la GA?
| Fase | Cosa | Gate per avanzare |
|---|---|---|
| Alpha | Interno, 1 corso sicurezza | Hallucination < 2% e citazione corretta > 98% su un set di domande validate dai docenti, piu' eval pedagogica (rubric BEA 2025). Si avanza solo se il grounding regge. |
| Beta | Chiuso, 1-2 clienti | Completion lift di almeno +10 punti sul gruppo di controllo, con delta pre/post significativo, zero incidenti compliance, e documentazione tecnica AI Act pronta. |
| GA | Apertura | Learning gain replicato, reliability tenuta su scala, conformita' AI Act piena. |
Come lo consegno: 5 persone, 6 mesi
Perche' un PO si giudica anche sul "lo sai portare a casa".
| Trimestre | Obiettivo | Chi |
|---|---|---|
| Mesi 1-2 | Reliability layer end-to-end (RAG + citazione + refusal/escalation + output strutturato) su 1 corso, e il guardrail nel codice. Alpha interna. | 2 AI eng (RAG + guardrail) · 1 full-stack (integrazione OpenLearning, xAPI) · 1 AI eng a meta' su valutazione |
| Mesi 3-4 | Motore di scenari + productive failure con trigger di stallo in-attivita', e lo Scenario Drafter per i docenti (authoring assistito sul materiale autorizzato). Eval pedagogica con i docenti. | 2 AI eng (scenari + steering + drafter) · 2 full-stack (in-attivita', Profilo via xAPI) |
| Mesi 5-6 | Beta chiuso 1-2 clienti, rollout sfasato per il control group, dossier AI Act, hardening e misura del completion lift. | tutto il team su delivery + misura; 1 AI eng su monitoraggio reliability a scala |
I conti tornano perche' il perimetro e' stretto: un formato, un vertical, e si riusa cio' che avete gia' (xAPI, API REST, struttura percorso-corso-attivita', SSO). Non costruisco infrastruttura, ci salgo sopra.
Dove approfondirei prima di decidere
Il case chiede di segnalare dove guarderei meglio, e lo faccio volentieri perche' un paio di queste decisioni le prenderei con i vostri dati in mano, non a naso: il drop-off reale per vertical (per dimensionare il premio); cloud Azure OpenAI in EU contro open-weight on-prem per i clienti PA e banche con vincoli sul cloud LLM (la demo gira gia' su un modello open-weight, GLM-5.2, proprio per tenere aperta questa strada); il costo per interazione a scala e l'impatto sul pricing; la taratura esatta dei segnali di stallo sulla telemetria vera; la validazione del knowledge base e delle soglie di refusal con i docenti.
E tre rischi che metterei sul tavolo subito, perche' non sono ovvi e si pagano cari se li scopri tardi. Primo, la sorveglianza: un Companion che registra errori, esitazioni e punti deboli del lavoratore tocca lo Statuto dei Lavoratori (art. 4) e il GDPR. I dati di pratica vanno aggregati e anonimizzati verso l'HR, mai usati come scheda individuale di giudizio: e' una scelta di prodotto, non un cavillo legale. Secondo, il vostro Chatbot Contestuale: il Companion non lo sostituisce, lo specializza sul far praticare. Confine e posizionamento vanno decisi prima del lancio, o ci si cannibalizza i budget in casa. Terzo, lo SCORM: molta compliance corporate gira su pacchetti SCORM 1.2/2004, che non espongono la telemetria fine (il rewind come segnale di stallo) ne' reggono bene lo stato di uno scenario. Per questo l'intervento dentro l'attivita' lo validerei sull'architettura reale di OpenLearning prima di darlo per scontato, con un piano B a fine-modulo se il dato granulare non c'e'.
Sull'angolo personale, chiudo onesto: vengo dal GTM engineering, costruisco sistemi AI che devono produrre un risultato di business misurabile, non demo. Questo problema mi attira perche' e' uno dei pochi posti dove "fa imparare" e "fa numero" possono coincidere, se l'affidabilita' la tratti come un problema di prodotto e non di modello. E' il tipo di cosa che vorrei costruire io.